A coworker was asking me about setting up Snort at home so he could get some experience breaking things.
I put together some very rough diagrams with Dia. These are just common and inexpensive solutions for running Snort at home, either in passive (IDS) or active (Inline) modes. These configurations are all inexpensive. At most, you require an extra hub or switch. The only one that doesn't require anything other than the network cards on the sensor is an external inline sensor.
The first is a common home network configuration. This is basically how mine was before I installed Snort.
The second diagram shows an external sensor. An advantage to this is that you see everything. A disadvantage is that you see everything. The management interface is inside the firewall while the bridging interfaces are outside the firewall. Seeing all the traffic isn't the only disadvantage. Some other disadvantages:
- You can't see internal addresses to identify individual systems.
- You need a higher performance system. This is not usually a problem on a residential service, but it should be noted that a lot more traffic will pass through system since it's not behind the firewall. You will see a ton of automated scanning and exploit attempts even if the traffic won't make it past the firewall.
The third image is using an extra switch. In this example, you will see all traffic going through the firewall, as well as all broadcast traffic on the private network. You won't see unicast traffic between internal hosts, but you will be able to identify which host is associated with any given traffic that is seen. Bridging is enabled on the sensor and you can run Snort inline. This is my preferred configuration unless you have a lot of wireless traffic.
The fourth diagram shows how to run Snort passively. There are two basic options. The first is a hub that will broadcast all traffic to all ports. This can hurt performance depending on how busy the internal network is. The second is with an inexpensive switch that supports port mirroring. I haven't used it, but I've seen an inexpensive Dell switch referenced that supports port mirroring. Note that it only supports monitoring four ports (PDF) at a time. In this configuration, you can see all traffic on the local segment in addition to Internet traffic. If using a switch with a mirror, you will probably need a separate management interface. If using a hub, the management interface can also do the sniffing.
You could also use a hub between the modem and the firewall if you wanted to run an external passive sensor.
EDIT: Based on Victor's comment, I added one other diagram. Diagram five shows the firewall and Snort inline on the same system. Victor uses iptables to filter the traffic first, then traffic that passes through the firewall goes to Snort running inline. He has separate Snort processes for the DMZ and the LAN.
This configuration is slightly more complicated. There are exceptions, but the places I've worked in the past would not have considered using this type of configuration mainly because they were quite large and wanted off-the-shelf networking products rather than rolling their own firewalls or routers. It is still a useful and usable configuration to learn, and setting it up would provide a lot of valuable experience.
I'd like to add another option, which is the setup I am using myself. In my setup I combine the firewall, which is a linux pc running my own iptables frontend Vuurmuur, and the IPS, which is running Snort_inline. In this setup only the traffic that the packet filter allows is sent to Snort_inline for inspection. This way Snort_inline wastes no time on traffic that iptables will block anyway. The firewall connects lan, dmz and wan. Using Snort_inline's NFQ support I even have separate Snort_inline processes handling traffic for the lan and dmz networks.
ReplyDeleteVictor, thanks. Your configuration is a little less basic, but good for people that already use their Unix-y boxes as routers.
ReplyDeleteYep, I totally agree with Victorj. I often use this kind of configuration in my home. But if you want an acceptable packet analysis you need a little more powerful machine rather then the previous configurations[1,2,3,4]. So at the end of the day it can depend on what you got. If you have just a "little" PC ( whatever little means..) in my opinion configuration 1,2,3,4 are better than Victorj's one, on the other hand if you have "nice" machine (again, whatever "nice" means") the last one is the suggested...
ReplyDeletenr,
ReplyDeleteHow about adding diagrams showing tap deployments? The next step would be to add this post as a link in the NSM Wiki! Good work.
Richard,
ReplyDeleteI had a longer answer making excuses about your request being more complicated since taps are primarily used on business networks, but it really belongs in a new post along with the requested diagrams. I imagine I'll get around to it, but I'm not sure when.
Stephen, in your scenario I suggest running separate Snort processes with separate configurations. It is possible to run just one process, but you will probably not want to run identical configurations and rules on the inside and outside.
ReplyDeleteOne host monitoring both TAPs certainly is not a problem as long as the hardware can handle the load. Remember to note the disadvantages of having a sensor outside the firewall.
what is advantages of 5th strategy over others.
ReplyDelete