NSM With Bro-IDS Part 1: First, you ...

I have this really great co-worker named John. We may differ on some things but when it comes to food we are peas in a pod. Through some fateful twist we both have a deep appreciation for Cajun cooking, particularly gumbo and jambalaya. If you've read traditional Cajun recipes, there are five little words that you can pretty well assume are going to be in any recipe for anything fixed in a pot, skillet or dutch oven.

"First, you make a roux"

I really wanted to blog about network security monitoring and a couple of open-source intrusion detection systems. Specifically I wanted to cover

bro, a very cool project from ICSI that I've only recently started testing
suricata, a threaded "alternative" to Snort that I've only tested for about a month
OSSEC, a HIDS that most of my friends are wondering why I haven't already covered
Snort, the gold-standard of open source intrusion detection

OSSEC is pretty easy, it's one server and then some client installs, but I started thinking about the requirements for the others and realised I'm going to need a router with a span port and a network link for the bro/suricata/snort virtual machines to be able to see the span traffic (this effectively sets the router up as a tap). So, part one of my bro series isn't really about bro at all, it's about setting up the environment so I can *install* bro. To paraphrase all those really awesome recipes from southern Louisiana: first you build a router.

FreeBSD + pf

I already have the psql_test internal network with a bunch of hosts on it and I've established in previous posts that it works a *lot* like a real network. I also have enough virtual machines in production networks running FreeBSD, acting as routers and packet filters for other virtual machines on the virtual networks, to think that this should be pretty easily accomplished in VirtualBox.

Create the FreeBSD VM

This is the easy part. I use my fbsd_8_3_i386_101 VM and cloned it to fbsd_8_3_i386_254

"Adapter 1" was changed from NAT to the 'psql_test' network: 

I added "Adapter 2" as a bridged interface so I could access that IP from my home network (specifically I wanted SSH access):

The IDS VMs would need access to the network traffic so I added an "Adapter 3" as an internal network:

Keep in mind that this isn't the order they'll show up in FreeBSD so take note of the last segments of the MAC addresses (or you can just look at the adapter definition "Advanced" tab when you're setting up the IPs in the guest OS).

The Guest Operating System -- /etc/rc.conf

Since FreeBSD is already functional, I really only need to modify a couple of files to turn my potential server into a router. The first step is to identify which VirtualBox Adapter is associated with each em* device. Running "/sbin/ifconfig -a" will give you each interface and its MAC address (remember I said to note each Adapter's MAC?). In my case em0 is the interface on my home network, em1 is the bro_bridge interface and em2 is the psql_test interface, so I need to bridge em0 and em2 and then set em1 up as a span. For packets to actually forward I need to enable the gateway functionality. To be able to SSH into the machine from my home network I need to enable sshd and, finally, since this machine will NAT traffic between the psql_net network and my home network, I need to enable pf. All of these things can be done in /etc/rc.conf. Taking everything I've laid out into consideration, my new /etc/rc.conf is:

The Guest Operating System -- /etc/pf.conf

pf needs to be configured to NAT traffic and have any necessary filtering rules configured. In this case I'm going to specifically pass any inbound traffic coming into the router on the psql_net interface and specifically pass any outbound traffic leaving the router for the home network. pf will pass traffic on any interface unless there is an explicit block so the pass rules are extraneous but I like having them there for maintainability and readability (plus I usually have a block rule right after the NAT line). An *extremely* basic pf.conf to get the job done:

The Guest Operating System -- Reboot

At this point the fastest way for everything to take effect (pf rules, new IPs, gateway functionality) is to just do a reboot. After the reboot I like to do a quick ifconfig just to make sure the internal IP was assigned and the bridge was created:

To verify the router works, start a virtual machine and set the only active interface to be one on the psql_test network. Set the gateway as the IP of the psql_test interface on the router VM, set the DNS server in resolv.conf as a valid DNS server (I used 8.8.8.8 for Google's public DNS) and try to ping something like google.com (I use google.com because they respond to pings). 

Running 'tcpdump -i em1' on the router while the ping is active should let you know if the bridge and span are correctly configured. Probable errors here are incorrectly determining which em* device maps to which Adapter, the configuration of the bridge and typos in either /etc/rc.conf or /etc/pf.conf. Assuming everything matches the examples you *should* have a fully functional router with a way to mirror traffic to multiple virtual machines simultaneously, a useful tool for testing multiple intrusion detection engines with the same network traffic.