|Version 2 (modified by 14 years ago) ( diff ),|
Using Snort Inline with Vuurmuur
Vuurmuur is a frontend to netfilter/iptables, the packet filter implemented by Linux. Being a packet filter, no content inspection is done. Decisions to drop or accept a packet are taken on the basis of ipaddresses, port numbers, connection state, and some other packet and connection properties.
Snort is an Intrusion Detection System (IDS) that matches the content of the connections against signatures of known attacks. Snort_inline is a modification of Snort which makes Snort_inline an Intrusion Prevention System (IPS).
This document describes how to set-up Vuurmuur so you can take your protection beyond the packet filter, into content filtering and intrusion prevention!
How Snort_inline works
Snort and Snort_inline work by getting one packet at a time from the system. These are then pre-processed, after which they are passed to the detection engine. Snort uses pcap for this, while Snort_inline connects to a special feature of Linux, named ip_queue. This queue is a way for the kernel to copy a packet to a userspace process (in this case Snort_inline). Then it waits for this userspace process to issue a verdict on this packet, with 'accept' and 'drop' being the two possible verdicts.
Like plain Snort, Snort_inline works with rules. These rules can have actions like 'alert', 'log', etc. Snort_inline introduces three new actions, 'drop', 'sdrop' and 'reject' (sdrop is silent drop). As you read above, the only two possible verdict for a packet are 'accept' and 'drop', so how can Snort_inline reject a packet? This is done in two steps:
- the packet is dropped using the 'drop' verdict.
- Snort_inline sends an icmp error or tcp-reset to the offending ipaddress.
Integration with Vuurmuur
You might wonder “which traffic is send to Snort_inline?”. As stated above, Snort_inline gets its packets from the ip_queue from the kernel. But how do you control which traffic gets into this queue? This is controlled by a special target in iptables, the QUEUE target. Rules in Vuurmuur can also have a corresponding 'Queue' action.
Which traffic you want to Queue is entirely up to your own preferences and needs. You might want to pass all traffic to Snort_inline:
Queue service any from any to any
But probably you want a more fine grained control, combining the strength of a strict packet filter and content scanning. So if you normally have a rule like this:
Accept service http from local.lan to world.inet
You can replace it by:
Queue service http from local.lan to world.inet
This way no extra ports are opened, but the http connections are passed to Snort_inline for anomaly detection.
Portfw and Redirect
For rules in Vuurmuur with actions 'Portfw' and 'Redirect' some special care is needed. This is because for these rules iptables ACCEPT rules are automatically created. To solve this a special rule option 'queue' was added. This is how it is used:
Portfw service smtp from world.inet to mailserver.local.lan options queue
This way the port-forwarded traffic is passed to Snort_inline as well.
For redirect, the same solution can be used:
Redirect service http from local.lan to world.inet options queue,redirectport=”3128”
This way you can even both send the http traffic through a transparant proxy and Snort_inline at the same time!
To enable the 'queue' option from inside Vuurmuur_conf, edit a portfw/redirect rule and enable the advanced options (F5). Then a toggle 'queue' becomes visible.
Vuurmuur uses 'marks' to differentiate between traffic that must be accepted and traffic that must be queued. Packets with a mark in the range 0-9.999.999 are accepted, 20.000.000-29.999.999 are queued. If you want to mark traffic (for example for shaping or routing) then you have to keep in mind that to use this together with Snort_inline, the marks must fall between the above range. By default Vuurmuur will mark traffic that is to be queued with mark 20.000.000.
Currently there are two known issues with using Snort_inline this way. Both are not specific to using it with Vuurmuur.
The first is that if traffic is sent to the queue while no program is connected to the queue, traffic is effectively dropped. The same is true if Snort_inline crashes.
The second issue is that Snort_inline can use a lot of system resources, which can mean that connections will be slower. But this mostly depends on the settings of Snort_inline itself (more rules means less performance) and of course on the speed of your hardware.