Snort box placement

Long time lurker, first time poster :D


I work for a small business (around 70 employess) and in order to enhance the security of our network I am going to be installing a dedicated Snort box. I am fine and dandy on the installation and implimentation of Snort, but I'm more conflicted as to the placement of the box and have several related and non-related questions.

Currently, we have a hardware firewall with a built in DMZ port, where our web server resides. The firewall is pretty much locked down and has done much to keep attackers out. Logs from the firewall are being sent to one of our Linux servers and are monitored/checked 2-3x a day.

We (our IT department) have already decided that it would be more beneficial for the Snort box to be inside the network to view what actually makes it past the firewall as we feel a hardware solution should be our first line of defense, plus we're already seeing what is hitting our firewall. Questions: Is this sound reasoning? Should we place the Snort box on the outside instead? Should we have one on the inside AND the outside (this seems like overkill for a network of our size)?

Assuming that we put the box on the inside, which of the following traffic flows make more sense:
----------------------------
- >>> DMZ with Webserver
/
Hardware firewall
\
->>> Snort Box >>>>>>>> Internal Network

-----------------------
Hardware f-wall >>> Snort Box >>> Web server >>> secondary firewall/snort box >>> internal network
-----------------------

In the first implimentation, we would lose the Snort capabilities for traffic going to our webserver which I don't like very much, but we wouldn't have to create a second firewall snort box to impliment the DMZ as we would in the second implimentation.

Is there a better way to do this? Usually the setup is more straightforward, but considering the size of our business network, it makes things a little more complicated as there are several options to choose from.

Thanks in advance for your help/answers and I hope I can become a positive member of the AO community.

The most needed information is what type of hub/switch you have in each position. If you have a hub, a snort box can be placed on it and sniff all traffic on that segment. If its a switch, you will need a management or monitor port in order to sniff the traffic on it. The other option which is a lot less optimal is to have traffic pass through the snort box. This is obviously a potential bottleneck and I would steer clear of it.

If your existing snort box is powerful enough, I would recommend using the same box in both places, using two NICs, each listening at a different point on the network, with two instances of snort running. Of course this will only work if you have the capability to sniff traffic with some kind of tap/hub/port monitoring in place. With this method, you may miss some of the rule hits if the kernel must drop packets due to the network load, but you would still be able to monitor both places for at least most of the traffic. For a company of 70 people, though, I doubt this would be much of a problem.

If you need to pass traffic through the snort box in order to sniff it, you should consider bridging through the box instead of routing (if you're not already). It's relatively simple as long as the kernel is capable of supporing it, which may require a new kernel or module. Look at http://bridge.sourceforge.net and http://ebtables.sourceforge.net for the userspace utilities you would need.

In short, I think the best solution would be to run the snort box on both networks using two instances of snort and two NICs.

<edit>
I forgot. To use the ebtables (layer 2 firewalling) functionality, you will need a 2.6 kernel. It was added in 2.5 somewhere. Prior to that, the netfilter code will not "see" traffic passing through bridged interfaces. To just bridge interfaces without firewalling or brouting, a 2.4 kernel is fine.
</edit>

I'd go with zENGER's model which does not call for traffic to flow through anything other than your core infrastructure and does not involve routing or bridging of any kind on the snort box. Why? Because the first time something goes wrong with your snort box and it impacts operations, your credibility with management will be shot and your chances of adding additional security devices to the network will go up in smoke. The second reason is that you will take a chance that the snort box may get pummeled with traffic and produce unexpected results. MANY people throw a machine on the wire and watch it work under normal conditions but have no clue how it will react when put under the load of a real attack. I've seen very baaaaadddd things happen to many a poor soul when making this mistake. The other thing thing that can happen is packet loss during a security event (or just a sustained spike in traffic). This means your results may be incomplete, etc. The spanning (cisco)/management port method is the best way to implement IDS such as snort or any other sniffing technology. Also be sure to stress test your IDS. Depending upon how you configure it, the horse power needed will vary greatly. Of course this is my opinion and experience.

--TH13

Striek: pretty cool suggestion, just woundering however, does using 2 NIC's in 1 computer act like a "bridge" past the firewall? that seems dangerous to me, but then i dont have your experience so im just guessing, would be interested to know how this works, cos surely an attacker could comprimise a box and jump the firewall?

cheers

i2c

i2c&gt; Just using 2 NICs by themselves doesn't act like a bridge. The kernel needs to be specifically configured to allow bridging, and a bridge must be configured between those cards. The computer then keeps a record of the MAC addresses on each side of the bridge and forwards traffic across the bridge only when necessary. This reduces the load on each side of the bridge. To any nodes on the network, the bridge is essentially invisible.

It can also be used as part of an IDS to force traffic through the IDS box. This is a cost-effective means to run an IDS when one does not have access to $1000+ switches with port spanning capabilities, at the cost of performance.

Even though the bridge is invisible, some layer 2 firewalling can still be performed on it if desired, such as MAC==IP address matchings. It is not a bridge past the firewall. I think I was unclear in my explanation. The setup would look like this:

Upstream ISP ==&gt; F/wall ==&gt; Snort Bridge ==&gt; Webserver ==&gt; F/wall ==&gt; Snort Bridge ==&gt; LAN

Where both snort bridges are in fact running on the same box and invisible to the rest of the network.

Miracle&gt; True though, a downed snort box here would mean a downed network. If you don't have port spanning capabilities, see about purchasing passive ethernet taps. I have a couple here that work well (I doubt they'd handle a high load since I built them myself -- I imagine professional quality taps would work far better). Either that, or pass the traffic through a hub before going to any production switch. A second port on that hub can then forward traffic to the IDS.

Code:

---

ISP ==> F/Wall ==> Hub ==> Switch ==> Webserver ==> F/Wall ==> Hub ==> Switch ==> LAN
                    |                                          |
                    \===============>Snort Box<=================/

---

Although this too introduces two more points of failure at the two hubs, but at least it's not the IDS's fault. Unless management sees the hubs as part of the IDS. Who knows. If the network hardware is physically close, it would be easy to fix though. With the taps, they would simply replace the hubs in the above diagram. Failsafe taps are available that still transmit through when the tap fails, in most cases (i.e. no traffic gets to the IDS).

Well there's a few more ideas, and I think everyone's gone over the pros and cons of everything pretty well. Hope this helps.

Striek

Although I hate to nit pick things, I see one more flaw in your IDS model. While I agree that watching traffic on the inside is a good idea, when you get a hit on the inside, it may be too late because you're now in a reactionary position. By monitoring outside traffic you may get a headsup to trouble that may impact your internal network. I recommend watcing internal and external traffic.

--TH13

Wow! Thank you all so much for your quick and well thought out replies...I think I found my new home for posting security questions. I am somewhat of a neophyte in this area, though I am learning quite quickly.

So, a few more questions have been sparked by all of your replies.

1.) I agree that it would be an ill-advised move to have all network traffic flowing through one Snort box IF the network was larger than ours. Looking through our logs, we average about 4-500MB per day of total upstream data and only about 250-300MB of downloaded.... with such a relatively small amount of data transfer (a majority of the upstream is 5-20MB reports being sent to our clients) would there really be a bottleneck even on a crappy box with as little as a pentium 3 processor and a decent amount of RAM? Actually, come to think of it, before I re-arranged our network, an outside consulting firm had actually set up a BSD box as a passthrough/traffic filter that was the main point of entrance for our network. It was a PII 300Mhz and even THAT didn't seem to have bottlenecking problems.

2.) thehorse brings up a good point in that it's important to see what kind of data mining hackers are doing on the outside in order to take preventative steps to avoid a break-in. In fact, there is actually a plan in place to impliment a second Snort box monitoring WAN traffic, assuming the internal one works successfully. My question is: Is it overkill to have an inside AND outside box? I'm all about taking whatever steps necessary to lock down our network, but would the logs become overwhelming assuming that I am the only one checking them?

3.) Zengar and Striek: You guys both gave me lots of ideas/implementations to consider. I would like to know more about taps, though...any info you guys could provide would be helpful (I'll google too). Even considering the points I brought up in question/section #1 I'm thinking it's going to be best to have the Snort box acting "on the side" so-to-speak, rather than having it be a bottleneck or gateway on the network.

Striek, can you explain this quote that you made some more?

Quote:

---

Even though the bridge is invisible, some layer 2 firewalling can still be performed on it if desired, such as MAC==IP address matchings. It is not a bridge past the firewall. I think I was unclear in my explanation. The setup would look like this:

Upstream ISP ==&gt; F/wall ==&gt; Snort Bridge ==&gt; Webserver ==&gt; F/wall ==&gt; Snort Bridge ==&gt; LAN

Where both snort bridges are in fact running on the same box and invisible to the rest of the network.

Miracle&gt; True though, a downed snort box here would mean a downed network. If you don't have port spanning capabilities, see about purchasing passive ethernet taps. I have a couple here that work well (I doubt they'd handle a high load since I built them myself -- I imagine professional quality taps would work far better). Either that, or pass the traffic through a hub before going to any production switch. A second port on that hub can then forward traffic to the IDS.

---

For our network I think this would be perfect!! Our router does not have port spanning capabilities that I know of (Linksys RV042), so, again, how would I create or where I purchase a passive ethernet tap? I saw info about this in the Snort manual/FAQ, but I was somewhat confused.


Again, thank you all so much for your time...you should all be getting a portion of my hourly wage lol!

A passive ethernet tap works by tapping both the send and recieve wires on an ethernet cable. You end up with two sets of two wires coming off the original wire. These two wiresets are then both connected to the recieve pins on two different ethernet jacks. When you said you saw something about this in the Snort manual/FAQ, I am assuming your were talking about this.

So if there was a tap between host A and host B, it would work like this: When host A recieves from host B, the recieve wires are tapped and directed into a monitoring box. When host A transmits to host B, the transmit wires are tapped, but directed to the recieve pins on the monitoring host.

In this way, each pair of wires coming off the tap to the monitoring host will see traffic going in only one direction. Between the two of them, you can see traffic going in both directions. Software exists to reconstruct these two data streams into one stream again. But for your scenario, I don't think this will be necessary. Just use an IDS box with two cards and have one instance of snort running on each of them, logging to the same database. Reassembling the streams in real time and running an IDS on them would take a lot of processor power.

I made a few myself just by buying the chassis for four ethernet jacks, putting four jacks in place, and then wiring straight through between jacks 1 and 4. The recieve wires also pass through the recieve pins on jack 2, and the transmit wires pass through the recieve pins on jack 3.

The major selling point of a tap such as this is that it is incapable of transmitting data, and is therefore totally invisible on the network.

I did have some problems with seeing all the traffic because the signals weren't strong enough coming off the taps. A professionally designed tap would amplify this signal and provide for failsafe functions as well.

This is an example of the housing and the jacks I used to create the tap. No soldering or splicing required. The jacks do all that for you. All you need is a pair of sidecutters. The ones I built came in a set with the housing and four jacks, which I bought from a local computer store.

Here is an example of a professionally designed passive tap, which will not negatively affect the network should it fail.

I would suggest first building one or two yourself to test the architechture (but be aware that you may not see all the traffic since you're splitting the signal and reducing its strenth -- keep the tap wires as short as possible). If that setup works for you, then try convincing the bean counters to spring for a few proffesional taps.

If you look at the diagram where I suggested a way to do this with hubs, just replce the hubs in that diagram with taps and you'll have an idea of what I'm envisioning.

It sounds to me that your network would be more than adequately covered by using some of the architecture/methods used here

Have fun and ask any questions you like.... You can accomplish this all on boxes that are now considered ancient.... But a nice fast box for log analysis doesn't hurt. My log analysis box parses an average of 1.3 gigs per day in around 4 minutes... and it does it while I am asleep.... ;)

Thanks again, everyone!

TigerShark: Excellent tutorial

Striek: Thank you for the links about taps...I'm going to go check them out right now.

I'll let everyone know how this turns out in a week or two.