1

I am trying to setup snort to act as an ids, on a debian machine that also functions as a router. Ideally I would like to setup snort in such a way so that I would not have to purchase an additional network adapter just to have it listen to the same traffic that the debian machine is already handling. Having said that, what would be the best way to mirror traffic from an interface, and then send the mirrored traffic over to snort? Or would you recommend that I go along a different route? I was thinking a bridge could possibly work, but I am not sure if that would be the correct solution, any help would be appreciated, thanks!

lacrosse1991
  • 1,407
  • 5
  • 19
  • 24

2 Answers2

5

In your situation I think we can build out two design options that could likely work.

  1. Run snort on the router directly.
  2. Run snort on a separate box dedicated for this purpose.

Running on the Router

Since you have rolled your own Debian instance for your router, it would simply be a matter of installing, or compiling, the packages for your version/architecture. You could then configure snort to attach to either the inside or the outside interface, depending on which one you want to monitor, and let 'er rip.

This could be easy, would not require adding any more hardware, could be easily reconfigured to run in IDP mode, and would not require any potentially odd network configurations to make work. The biggest downside is going to be performance. Snort can consume an insane amount of resources. It could trivially eat up all the RAM and CPU in a system making your router unable to, you know, route.

Snort has gobs of configuration options. Not just turning on or off rules but whitelisting rules for certain hosts, adjusting the number of bytes of memory used for packet defragmentation, the number of packets to store in memory for TCP stream reassembly, etc. I generally recommend spending an insane amount of time tuning these parameters, and even after you get them set the way you want them to go back and do periodic reviews to see if anything needs to be tweaked.

Running a Dedicated Sensor

This is usually the recommended solution. It solves the network outage problem for resource competition. It allows you to use specially crafted hardware so you can make your sensor do exactly what you want. This will also free you up to add an extra hard-drive to run daemonlogger, or throw in some more RAM without having to deal with scheduling full network outages. It is also more scalable. Sure, I can get snort running on the Pentium 4 whitebox running pfSense at home, but there is no way I will get it to run on a Juniper EX-8216 at work. A purpose built sensor will run just as well in both environments.

The downside is that you're adding yet another system to manage, another box consuming power, more BTU to evacuate, etc. Depending on your network infrastructure it may or may not be easy to get the data into it. The major network vendors all have something to do this. Cisco calls it a SPAN session, Juniper calls it an Analyzer, Enterasys calls it a Mirror. It is possible to perform the same function with iptables using the TEE target, though I don't know any other host firewalls to say whether they can or how to do it. Failing all that you can use a network tap which is a physical device that electrically copies the data stream.

In any case, what you have to do is get a copy of the traffic from your network infrastructure to your sensor. The best way to do this, and the recommended method, is to have two NICs in your sensor: 1 for management and 1 for monitoring. The price of interfaces can vary widely, but unless you're talking about situations with links of greater than 1Gbps, or sustained throughput approaching 1Gbps, cards are pretty cheap. I've been recommending even a simple Intel Pro/1000 GT, the things are $30 and do everything you'll need!

It is possible to run on one interface, but I can't recommend it. You're most likely to run into odd inconsistencies with your monitoring, or potential network issues thanks to the problem of transmitting on a link that is normally expected (assumed?) to be receive only.

There's a fair bit of information available on the snort tag on our sister site for Information Security Professionals.

Community
  • 1
Scott Pack
  • 14,717
  • 10
  • 51
  • 83
1

When I have run snort, I ran it on the router. This doesn't require an additional interface to send the traffic to. The risk is that if snort mishandles data and executes it, it will have easier access to the network than it would have otherwise.

BillThor
  • 27,354
  • 3
  • 35
  • 69
  • Hello, when you had snort setup on the router, did you simply tell it to listen on the physical network interface? I am under the impression that snort would try putting the interface itself into promiscuous mode which would then negatively affect network performance/routing, although I could be mistaken. – lacrosse1991 Nov 03 '12 at 21:42
  • You can have snort run in non-promiscuous mode. It is non-default and will cause snort to only process packets destined for the host. – Scott Pack Nov 04 '12 at 00:48