Question about SNORT offenders blocking
-
Hi,
I'm playing with the snort package right know and it works great, but i'm wondering a thing about ip blocking.
When you select BOTH (source and destination) what's happening exactly to the offender located on the LAN network (i'm using snort for P2P blocking) ? Is he completely isolated from the network ? Or just against the matching rule ? can this IP still uses internet normaly ?
I'm asking this cause I want to block p2p but not preventing the offender to use internet normaly.
Thanks for your help
-
Snort's blocking is a very blunt instrument. When an alert is triggered, either the SRC, DST or BOTH IP addresses from the offending packet are passed off to the packet filter (pf) firewall in pfSense where the IP addresses are added to a hidden table called snort2c. That table is part of a built-in block rule that is located very early in the firewall's processing chain. Any IP addresses inserted into that table will subsequently be blocked by the firewall. Which IP addresses from the offending packet (SRC, DST or BOTH) are inserted into the table is controlled by the drop-down selector on the INTERFACE SETTINGS tab in Snort. This selector is in the section where you enable blocking.
When running on the LAN, the impact of a "block" on a LAN client depends on some context. So assume you are using the default setting for "Which IP to block" and have it set to BOTH. So no matter if the LAN host in question is the source of the traffic triggering the alert or the destination of the traffic triggering the alert, the LAN host's IP address will get inserted into that snort2c table for blocking. So now all traffic from that LAN host is going to be blocked at the LAN interface of the firewall. So that host can't get to the Internet. However, that host can still communicate with any other local hosts that are on the same LAN segment. This is because traffic between hosts on the same subnet does not transit the firewall.
If you had set the "Which IP to block" value to DST, then the impact on the LAN host would depend on whether it was the destination of the offending traffic or the source of it. If the LAN host was the source but DST was blocked, then it is blocked from communcating with that specific destination host, but it can still communicate with any other hosts. Note also that because the destination's IP address is blocked at the firewall, no other LAN host can talk to that offending DST host either.
If the value was set to SRC, and the LAN host was the source of the traffic, then the LAN host's IP address is added to the firewall block table and all communication outside the LAN for that host is blocked.
The block will stay in place as long as the IP address remains in the snort2c table. The IP can be removed from the table in one of three ways: (1) rebooting the firewall; (2) by the automatic cron job that removes blocked hosts after a time period where that IP has seen no traffic; or (3) by the user manually clearing the IP address block on the BLOCKS tab.
Suricata offers two blocking modes. Legacy Mode works just like Snort using the process described above. However, Suricata also has the new and still a bit experimental Inline IPS Mode. This mode of operation runs as an on/off switch sitting between the NIC driver and the network kernel of the firewall. When a packet triggers a DROP action, the switch is opened for the duration of just that one IP session to drop the specific traffic triggering the rule. There is no table where the blocked IP is saved. It's all dynamic and happens one packet at a time on a rule-by-rule basis. So back to the same example used earlier of the LAN host in Snort: if Suricata Inline IPS Mode is used, the LAN host is only blocked by traffic that specifically triggers a certain DROP action rule. So that means maybe a P2P rule will trigger and drop all P2P traffic from that host, but other traffic like HTTP or SSH can still flow as it won't trigger a rule. And even traffic such as HTTP can still selectively drop (or block) traffic on a rule-by-rule basis.
P.S. – forgot to add earlier that when using Inline IPS Mode on Suricata, the admin user has to explicitly change the rule action from ALERT to DROP for those rules where blocking (dropping) of traffic is desired. This is different than the experience in Legacy Mode where any alert automatically blocks when blocking is enabled. With Inline IPS Mode, you must explicitly alter rules from ALERT to DROP in order to get blocks. If you don't change any rule actions, then you will get alerts but traffic will not be dropped (or blocked). You can most easily alter rules using the capabilities on the SID MGMT tab in Suricata.
Bill
-
Very interesting piece of reading, this is exactly what I wanted to know, many thanks ! I'm gonna give a look at Suricata then.
-
Be forewarned that the Inline IPS Mode of Suricata depends on the relatively new Netmap API present in FreeBSD. Netmap is very highly dependent on pretty much perfect support from the NIC driver in order to function. Depending on the level of "perfect support" from the NIC driver, Netmap may not work at all, may work fine until traffic loads increase, or it may generate a lot of meaningless console log noise.
So Netmap, and thus by extension Inline IPS Mode, is still a work in progress both within Suricata itself and the FreeBSD network stack.
Bill
-
Maybe I misunderstood the initial question, but in addition to the info Bill provided, I think you will need to adjust the pass list. The default list includes the LAN, so even with BOTH selected in the blocking setup, the LAN IP won't get added to snort2c.
-
Maybe I misunderstood the initial question, but in addition to the info Bill provided, I think you will need to adjust the pass list. The default list includes the LAN, so even with BOTH selected in the blocking setup, the LAN IP won't get added to snort2c.
That is correct in regards to the default pass list. I forgot to mention that it will default white list LAN hosts. You can stop that behavior if you want by creating a custom pass list and assigning it to the interface. The default pass list setup will stop LAN hosts from communicating with bad external hosts if DST is blocked, or it will keep bad hosts from talking to LAN hosts if SRC is blocked. Using the default of BOTH is the best of both worlds, especially when using the default pass list where all LAN hosts are white listed.
So with BOTH selected as "Which IP to block", a bad external host is flagged and blocked whether it is the source or destination of malicious traffic (as detected by Snort). Now with the block in place, no other LAN host can communicate with that bad external host. However, any LAN host can still talk out to any other external host.
Bill
