I am seeking a quickstart method to perform the following.
The intended purpose of the Bro install I am working on is to monitor incoming traffic only. To break it down simply I want to track only those incoming events that would appear to be malicious (ssh, telnet, etc). We are trying to upgrade our security situation here, and in order to get our customer to go along with it we have to show good reason why we need it. Using Bro to capture malicious attempted traffic will help us clarify the need for stiffer security measures than we currently implement.
I am reading the manuals, and looking for the info I need to do just that. In the case of you, if I can get some pointers to where to look to do just what I have intended it would speed up the process for what I have in mind.
We don't however wish to police our own outgoing and responding traffic. I know this is possible with Bro, and am trying to get this system up and running asap.
Can anyone provide pointers in the manuals, or other locations for such a setup?
In general, it's not really possible to restrict Bro's *analysis* to
only incoming traffic. The main reason here is that from Bro's
policy-neutral perspective it's hard to tell what "incoming"
Three ideas, depending on what exactly you want to achieve (which is
not completely clear to me):
First, you can filter the *alerts* so that only activity regarding
local hosts is reported. That's possible by writing a corresponding
notice-policy (see notice-policy.bro, or ask me again if you need
Second, if you're interested in a log of all incoming connections
(or incoming connections to certain ports like ssh etc.), conn.log
marks locally initiated connections with an "L" and remotely
initiated ones with an "X" (once you've configured your local
networks in site.bro). This is easily grep'able (or you can hack
conn.bro to not even output the local connections).
Third, firewall.bro allows you to define "firewall-like" rules
(e.g., "no external hosts are allowed to connect to any local telnet
port") and raises alerts if one is violated. It's not well
documented (um, not at all?), so again please ask for details if
you're interested in this functionality.
Does this help?
 In general you could hack any script to suppress its output for
local connections but by default they don't provide this
David, just two quick additions to what Robin said:
- Our marketing department just might fire me for saying this, but if
you just want to show people how bad things are then you might not need
anything as sophisticated as Bro. For example, compare the number of
valid connection requests in your sshd log to invalid ones -- my little
DSL-connected box at home got hit around 400 times per day with
malicious log-in attempts before I moved sshd to a different port.
Looking at Apache logs might give you a similar picture.
- Speaking of different ports, a scenario in which Bro definitely
*could* shine is detecting app-layer protocols on unusual ports, thanks
to the new DPD framework:
As an example, you could use the IRC detector to find IRC-based botnets
on arbitrary ports that way.
Running FreeBSD, while being a good idea from all sides considering that was what it was developed on, puts me in a position where I have to relearn a whole operating system and be abel to function half way responsibly right this minute. I don't have that option.....yet.
Bro actually won't be parsing data the way we are setting it up. I am mirroring the ports between the switch outside the firewall (input to the switch), and the interface of the bro machine. Now the bro machine is going to be sitting completely outside the firewall, with no internal connections at all. the admin interface (eth2) will also be outside the firewall. I will have to ssh to it from wherever. If I am thinking correctly it really does not matter what ip address I assign to the bro listening interface because in promiscuous mode the interface will not really have an ip address anyway.....it just listens on this interface (please correct me if I am wrong). the second interface I can set up a quick iptables ruleset to deny all and allow only internal (to the box) requests.
So while I am not too terribly concerned about this box being used to circumvent my security inside the firewall, I am concerned about the box being taken over. Any of you have a suggestion as to how to keep this from happening, or is my logic sound on my thinking here?
You have to keep in mind that since bro will be parsing packets that are passing over your network and if someone crafts a packet that crashes one of the protocol analyzers, there is potential for compromise. Wireshark (ethereal) has run into this issue many times recently and they have always strongly advised upgrading because people will tend to run it as root, especially on linux. And if someone compromises your IDS as the root user, it makes the attackers job of hiding their activity much easier.
Open source software isn't the only software affected by this problem either, ISS's IDS had this problem recently too, and many of their customers were compromised by malicious packets. Here's the CERT advisory about it.. https://www.kb.cert.org/vuls/id/150326
Fortunately, Bro is heading down the path of becoming less vulnerable to these attacks with binpac (http://bro-ids.org/wiki/index.php/BinPAC).
I would advise following Robin's advice and running bro as a user other than root. That offers a little protection, but keep in mind that closely monitoring the server is suggested so that if you are compromised you may be able to detect it and recover quickly.
> be outside the firewall. I will have to ssh to it from wherever. If I
am thinking correctly it really does not matter what ip address I
assign to the bro listening interface because in promiscuous mode the
interface will not really have an ip address anyway.....it just
There is no relation between the fact to have or not an IP address and the
fact to run in promiscuous mode.
You can listen (promiscuous or not) the traffic on an interface, with an
IP ou without one.
listens on this interface (please correct me if I am wrong). the
second interface I can set up a quick iptables ruleset to deny all
and allow only internal (to the box) requests.
Yes, it's a possible workaround.
So while I am not too terribly concerned about this box being used to
circumvent my security inside the firewall, I am concerned about the
box being taken over. Any of you have a suggestion as to how to keep
this from happening, or is my logic sound on my thinking here?
As i said before Bro does'nt run as network service.
And the some ideas :
- use firewall (iptables) to block offending traffic.
- use ssh on a different port than 22.
- use complex password, disable direct root login (example of conf