Snort in promiscuous mode does not block automatically

A Former User

Hi,

I have a WAN, LAN, and 2 VLANS. I didn't like all the extra memory taken up when applying the same rules to each VLAN, as each interface you apply the rules to takes up memory even if they're the same rules as applied to other interfaces.

So I changed the setup to apply the rules to the LAN only, and only applied a handful of extra rules to the VLANs. This avoids duplicating common rulesets, e.g. the community rules, and thus massively reduced the amount of memory being consumed.

Apparently, this puts Snort into "promiscuous mode" which allows the listener assigned to the LAN to also sniff traffic on the VLANs.

However, while I can see it is generating the same alerts as it did when the rules were applied directly to the VLAN interfaces, it is not generating any BLOCK entries, and allowing all traffic through. The rules seem to only work for blocking if the traffic in question is on the interface to which the rules were assigned, i.e. it blocks the LAN fine, but not the VLANs.

Is this a bug, or have I misconfigured it? Is there any workaround for it? Or do I have to revert to placing the rules on each individual interface?

Regards,
Rob.

bmeeks

@peridian:

Hi,

I have a WAN, LAN, and 2 VLANS. I didn't like all the extra memory taken up when applying the same rules to each VLAN, as each interface you apply the rules to takes up memory even if they're the same rules as applied to other interfaces.

So I changed the setup to apply the rules to the LAN only, and only applied a handful of extra rules to the VLANs. This avoids duplicating common rulesets, e.g. the community rules, and thus massively reduced the amount of memory being consumed.

Apparently, this puts Snort into "promiscuous mode" which allows the listener assigned to the LAN to also sniff traffic on the VLANs.

However, while I can see it is generating the same alerts as it did when the rules were applied directly to the VLAN interfaces, it is not generating any BLOCK entries, and allowing all traffic through. The rules seem to only work for blocking if the traffic in question is on the interface to which the rules were assigned, i.e. it blocks the LAN fine, but not the VLANs.

Is this a bug, or have I misconfigured it? Is there any workaround for it? Or do I have to revert to placing the rules on each individual interface?

Regards,
Rob.

It should generate blocks from the LAN side. First, double-check that you ticked the "Block Offenders" checkbox on the LAN SETTINGS tab. Next, make sure the offending IPs generating the alerts are not in any Pass Lists (that would prevent them from being blocked). Finally, after making any changes to blocking mode or Pass Lists or HOME_NET you need to restart Snort on the interface.

Bill

A Former User

@bmeeks:

It should generate blocks from the LAN side.

When you say this, does that mean it's trying to produce blocks on the LAN interface rather than the VLANs?

@bmeeks:

First, double-check that you ticked the "Block Offenders" checkbox on the LAN SETTINGS tab.

Checked, this is ticked on all interface settings, and set to block BOTH on all of them.

@bmeeks:

Next, make sure the offending IPs generating the alerts are not in any Pass Lists (that would prevent them from being blocked).

Nothing explicitly in Pass lists, however I remember noting somewhere that configured interface addresses/subnet ranges are automatically added to parts of pfSense configuration. Given that the blocking used to work if the rulesets were on the snort settings for the specific interfaces I assumed this was not the case with snort.

Is there any implicit adding of subnets to pass lists?

@bmeeks:

Finally, after making any changes to blocking mode or Pass Lists or HOME_NET you need to restart Snort on the interface.

Snort has been restarted several times across all interfaces. Still no luck.

Regards,
Rob.

bmeeks

You can view the actual contents of any PASS LIST, including the default one, by clicking the View List button beside the drop-down selection on the Interface Settings tab in Snort. That will show you all of the IP addresses and networks in the currently active PASS LIST.

Snort does not specify an interface when it inserts a block. It simply adds the offending IP address to the alias table in the packet filter. IP addresses in that table get blocked no matter where they are coming from or going to. That table is also up near the top of the packet filter chain so it acts on packets very early and before most other firewall rules.

Here are the actual packet filter rules for Snort blocking –


# Snort package
block log quick from <snort2c>to any tracker 1000000117 label "Block snort2c hosts"
block log quick from any to <snort2c>tracker 1000000118 label "Block snort2c hosts"</snort2c></snort2c>

So if you are seeing alerts on the ALERTS tab from those VLAN interfaces (with the VLAN IP addresses), then you should be seeing blocks unless those IP addresses match up to a PASS LIST entry. You can also examine your actual in-place firewall rules by looking at the file /tmp/rules.debug. Make sure something in the rules is not passing your VLAN traffic before the Snort block rule shown up above.

Bill

A Former User

Thought it'd be easier to post some images; based on the attached, I would have expected a BLOCK for the IP 10.180.1.200

Note: device accessed the web from the VLAN (HOMEMEDIA) not the LAN.

Regards,
Rob.

blocked.png_thumb

pass-lists.png_thumb

settings-lan.png_thumb

settings-vlan.png_thumb

alerts-lan.png_thumb

alerts-vlan.png_thumb

settings-general.png_thumb

bmeeks

The screenshots help a lot. Snort is working correctly, but there is one other thing you should do on the LAN SETTINGS tab. Check the box for "Kill States" in the Blocking section. Snort works using copies of packets, so the packets pass through the firewall and states are established while Snort is inspecting the traffic for problems. Once Snort alerts, it will insert the IP address into the blocking table, but any already established states will remain and traffic to/from the offending IP could continue unless the "Kill States" option is enabled. You pretty much always want the "Kill States" option enabled.

The 10.180.1.200 address was not blocked because it is a "locally attached" network (I am assuming it is one of your local VLANs), and by default those are automatically included in the Pass List.

I suspect the "Kill States" setting will fix your issue of traffic still happening after a block is inserted. You will need to restart Snort after making this change. What happens is the first packet to/from that remote host establishes "state" in the firewall. Snort later sees enough of the traffic to make an alert decision and then inserts the block for the IP address of the source/destination pair that is NOT in the Pass List. In this case it would be the Internet address. However, because you do not have "Kill States" enabled, that initial state table entry created by the first packet is still there; and because stateful replies are always allowed it means the traffic is not actually blocked.

Edit: in a future update I probably need to change "Kill States" to be enabled by default.

Bill

A Former User

Okay, I've spent all afternoon mucking about with this, it appears the problem is more general to my installation, and it's coincidence that I tried deduping rules to the LAN at the time that this behaviour started to occur.

I set the kill state switch on all snort interfaces and restarted snort. Same results. I get your explanation but I would have thought that if this was the problem, I would see blocks generated and traffic still working. As no blocks are being generated at all, I don't think the firewall state is the problem.

Just to prove I wasn't going mad, I re-enabled the snort_file-image.rules category on the VLAN (HOMEMEDIA) interface, and re-tested. However, the block (that I swear I used to get on this interface) did not appear.

I then tried: a) disable the rules on the LAN, b) remove the LAN interface altogether, c) remove all interfaces and then recreated the VLAN settings from scratch with all rulesets applied, and d) rebooted the firewall. None of these things would generate a block (see attached).

I eventually deleted the snort package entirely, rebooted, and installed the latest package (2.9.7.0). More different alerts being generated, but still no blocks for the internal IP (again attached).

BTW, the Pass Lists are still blank, but your comment about internal networks being added automatically on the list is what I was referring to previously about implicit adding of subnets to configuration. Is there some way of checking if there are IPs in the pass list that do not show in the UI? I would not want my internal subnets to be added on the pass lists.

–-

I don't know what I have done to cause this behaviour of no longer blocking internal IPs. I know that when I first setup snort that it did indeed block internal addresses, as I had to clear a few blocks from time to time.

Given that quite a few configuration options were still configured when I re-installed snort, I'm not convinced a re-install will have fixed this. I am now wondering if there is some sort of Rule suppression or Pass list modification I have made in the past that is still sat there in the background, and does not show in the UI.

Any ideas?

BTW, an import/export button on the Categories tab under Interfaces would be really useful.

Regards,
Rob.

interfaces.png_thumb

settings.png_thumb

alerts.png_thumb

block.png_thumb

new-alerts.png_thumb

new-block.png_thumb

rules.png_thumb

bmeeks

From the screenshots you posted, Snort is working correctly. I am referring to the images named alerts.png and block.png Here is what I see in the first set of images for ALERTS and BLOCKS:

1. An alert was generated for a FILE-IMAGE rule. The SRC IP was 4.26.228.253 and the DST IP was 10.180.1.200. I am assuming the 10.180.1.200 address is on your internal locally-attached VLAN.

2. A block was inserted for this event at the same time as the alert was triggered. The SRC IP was blocked (the 4.26.228.253 address). This would be correct and expected behavior with a default (empty) PASS LIST. This is because the locally-attached VLAN would be automatically included in the default pass list. So no block would be inserted for it. This is fine. In fact, you generally would not want your internal host blocked from everything just because he hit one bad IP. In this case, the bad IP (the source IP in this alert) was blocked so no further communication can happen there.

So based on the above, I see no issues with your install. Are you expecting your 10.180.1.200 host to be blocked as well? If so, you will need to define a custom PASS LIST, uncheck the option to include local networks, then manually assign the list to the VLAN interface (or the LAN interface) and restart Snort.

Bill

A Former User

Doh! Figured it out.

@bmeeks:

In this case, the bad IP (the source IP in this alert) was blocked so no further communication can happen there.

You would think, however looking at the logs I realised that squid was operating on that interface in transparent mode. snort was generating the block for the external IP, but squid was returning a cached copy of the content, which made it look to the client like the connection had still worked.

@bmeeks:

If so, you will need to define a custom PASS LIST, uncheck the option to include local networks, then manually assign the list to the VLAN interface (or the LAN interface) and restart Snort.

Excellent, thank you for that, it achieved exactly the result I was looking for. I don't know how I ever got snort to produce blocks originally if I didn't know to do this, but it is now behaving as expected, and with squid still enabled on the interface.

Thank you for all your help, it's very much appreciated.

Regards,
Rob.

bmeeks

@peridian:

Doh! Figured it out.

@bmeeks:

In this case, the bad IP (the source IP in this alert) was blocked so no further communication can happen there.

You would think, however looking at the logs I realised that squid was operating on that interface in transparent mode. snort was generating the block for the external IP, but squid was returning a cached copy of the content, which made it look to the client like the connection had still worked.

@bmeeks:

If so, you will need to define a custom PASS LIST, uncheck the option to include local networks, then manually assign the list to the VLAN interface (or the LAN interface) and restart Snort.

Excellent, thank you for that, it achieved exactly the result I was looking for. I don't know how I ever got snort to produce blocks originally if I didn't know to do this, but it is now behaving as expected, and with squid still enabled on the interface.

Thank you for all your help, it's very much appreciated.

Regards,
Rob.

Glad you got it figured out. Unless you are worried about your internal VLAN hosts being a source of and spreading some malware, I don't understand why you want their IP addresses blocked at the firewall as well. Simply blocking the other end of the offending traffic stream is protection enough for the victim host. I'm assuming you are running this in a home setup. As an example, assume your PC browses to a web site and some rogue ad content on the site causes Snort to fire an alert and insert a block. If you let it block both the bad web site AND your own PC's address, then you can find yourself locked out of the firewall (at least from your PC). Isn't it sufficient that just the far-end rogue source or destination be blocked?

Bill