Okay, I now have bro installed. Things appear to be in the right place. I must have missed something in the docs to get this working, and I am sure that it does not help that I am not exactly familiar with Debian. bear with me here as I stumble my way through a new OS and Bro. I expect I am going to ask alot of stupid questions, but I am documenting everything so that it may be used later to update or possibly improve the documentation or help someone else who is in the same boat I am.
Here is what I get when I try to start Bro from the command line:
jyd:/etc/rc3.d# /etc/init.d/bro.rc start
bro.rc: Running as non-root user bro
No directory, logging in with HOME=/
bro.rc: Starting ..........bro.rc: Failed to start Bro
/usr/local/bro/bin/bro: problem with interface eth1 - pcap_open_live: socket: Operation not permitted
.. FAILED
here are the outputs in the logs files in /usr/local/bro/logs:
/usr/local/bro/bin/bro: problem with interface eth1 - pcap_open_live: socket: Operation not permitted
Am I missing a permission issue here or what? Do I need to make some changes in a config file that I missed?
Did you do a 'make install-brolite'? If so, it looks like the bro user
account did not get created correctly. Check your /etc/passwd for a bro
user id, and make sure the home directory is correct (/usr/local/bro)
That is something I did not know till I got the responses from you guys. I re-ran brolite, and used the default user [root] for the user to run under. Now bro has started up and is doing something that resembles its job at this point. The startup was successful, and we shall see what kiind of stuff it collects sitting in the internal office network fro the next couple of hours.
Now with the next question.
Since the service runs as root, and the eth1 interface that it is running on is going to be exposed to the outside world, what do I need to do to my firewall config on this box to protect it from attack?
What are your suggestions? I can run some pretty simple firewall rules to simply deny all on the interface, and allow only internal requests, but will this hinder bro from being able to do its job?
As far i know but i may have missed something , Bro doesn't listen on a
specific network port and you can't ask to deliver a service as you would do for an Apache server.
Just so I can make sure I was clear here, and so I have this down right in my explanation to the group, I am going to rephrase the question I asked earlier.
We have two interfaces on the machine that will run bro. One is the bro listening interface, and this one gets run in promiscuous mode. The second, which is my admin interface and will be firewalled to the degree that I only have ssh listening on it is in reality open to the outside world. Since the bro interface runs in promiscuous mode, it really doesn't matter what ip I run on that port (I currently have it configured as a 10. address, and bro didn't complain going into promiscuous mode). Both interfaces are physically set outside the firewall. They have no internal connection to the inside network, nor does the machine have anything running or set up to run that will allow access to the inside network. Basically, if we want to look at bro logs we have to ssh in from outside or go directly to the box in the closet.
Now I do understand that running any process as root has its ugly side, and it does open me up for malicious intent, bro doesn't do anything but listen like a big ear. There is no response built into bro that would allow it to do anything. I do understand the crafted packet concept, but if the only reachable port on the machine is only listening to ssh requests from a specific range of ips, and is set up to use pass phrase authentication with all other ports blocked to the outside, am I not safe? I do intend to implement the patch to set bro up to run as bro if for nothing else but to try to insure that is one less way of compromising the machine.
I am in no way a security guy. I am just trying to analyze this in a fashion that seems to make some form of logical sense to me. I know there is no such thing as perfect security, but in the end this box really does nothing but listen and record what it hears. It has no exposure to the internal network at all except for ssh connections coming to it from a specifically small range of ips. I know this reads as argumentative, but all I am trying to do is understand what is happening and try to implement sound measures so I don't have to rebuild this box again once a week.
I guess maybe I shoudl be asking for suggestions more than anything as to how I should set this up.
if I had a way to put a diagram of the setup here I woudl and maybe you guys could tell me what I need to know that way. I am not known for being the best at explaining things.
We have two interfaces on the machine that will run bro. One is the
bro listening interface, and this one gets run in promiscuous mode.
The second, which is my admin interface and will be firewalled to the
degree that I only have ssh listening on it is in reality open to the
outside world. Since the bro interface runs in promiscuous mode, it
really doesn't matter what ip I run on that port (I currently have it
configured as a 10. address, and bro didn't complain going into
promiscuous mode). Both interfaces are physically set outside the
firewall. They have no internal connection to the inside network, nor
does the machine have anything running or set up to run that will
allow access to the inside network. Basically, if we want to look at
bro logs we have to ssh in from outside or go directly to the box in
the closet.
David,
You don't need an IP address at all on your bro interface; the interface
just needs to be "up" to throw it into promisc mode.
With respects to the admin interface, there's always serial port / out
of band management (I'd recommend that the management box or console
access server reside behind your firewall!). Rather than getting way off
topic, I'd invite you to contact my off-list if you'd like to discuss
If you employ both of these methods, your bro box is (pretty much, at
least at L3) invisible to the world.
... this box
really does nothing but listen and record what it hears. It has no
exposure to the internal network at all except for ssh connections
coming to it from a specifically small range of ips. I know this
reads as argumentative, but all I am trying to do is understand what
is happening and try to implement sound measures so I don't have to
rebuild this box again once a week.
It would seem that just listening to network traffic, you must be safe
from it. However, this is actually not the case. The problem arises from
executing code to analyze the contents of the traffic you see. If this
code contains flaws such as insufficiently sized buffers, then an attacker
can craft traffic that will infect you *even though all you do is look at it!*
Such flaws have been found in tcpdump, Ethereal, and Snort - and, even
more striking, formed the basis for the Witty worm which was launched
against ISS's network intrusion detection system products, infecting them
via their passive analysis of network traffic.
All that said, while this is a real threat against Bro, it is one you
wind up living with running any IDS written in a language that is not
fully type-safe.
I guess maybe I shoudl be asking for suggestions more than anything
as to how I should set this up.
The various firewalling, avoiding setuid root, etc., that have been proposed
on this thread for isolating your system are all prudent steps.
, Bro doesn't listen on a