Snort Pass List adding Local Networks Automatically?
-
Hi Everyone,
I'm running Snort 3.2.91_13 with pfsense 2.3.1_1.
I'm trying to setup snort with blocking capabilities for Source IPs on a specific network segment off of my pfsense firewall. I've created a Pass List to start that has all options unchecked and no defined Alias (yet), however when editing the Non-WAN interface settings (actually used as a WAN2) and going down to "Choose the Networks Snort Should Inspect and Whitelist" and clicking "View List" for the "Home List" with the newly created pass list. ALL local networks are showing up despite not being checked, as well as WAN interface IPs etc. Despite none of these checkboxes being selected, it seems they're still being implemented.
The explanation states "Default Home Net adds only local networks, WAN IPs, Gateways, VPNs and VIPs.". But I'm not using Default. and I want to block internal Source IPs on this specific network segment.
Am I missing something, or is this a legitimate bug?
-
The local networks should not be listed if not checked. I need to test that to see if it is indeed a bug that sneeked in during the Bootstrap conversion. Lots of little changes were required in the GUI package to accomodate Bootstrap, and now and then something got overlooked.
Bill
-
If it helps any, I'm only seeing it in the "Home Net". The Pass List shows exactly what I would expect it to, and doesn't have the local interfaces listed when clicking "view list".
If I can be of any help (screenshots and the like), please let me know.
-
I checked into the code and the logic currently does always include local networks in the HOME_NET calculation. This is generally desired because of the way most Snort rules are written. What exactly are you trying to accomplish that would require a different HOME_NET setup? If want blocks inserted for any of those locally attached networks, then just be sure they are not listed in the PASS LIST assigned to the interface.
Bill
-
Basically we have a a guest WIFI network that's completely separate from our main LAN traffic. Lately, its been showing some users with infected devices on the network. In the event of an infected system I want to block the source IP from any sort of network activity. Perhaps I'm assuming that the Home list is automatically blocked??
-
I think what you want is for the HOME_NET on that segment to be standard (that is, include local DNS servers, the gateways and locally-attached networks). It's the PASS LIST that you want custom. That will result in offenders on that wireless network getting blocked. If you uncheck all the options for a new Pass List, then it will only contain the actual interface IPs on the firewall itself (including the loopback address). Any other host would be a block candidate (either on the main LAN or that guest wireless segment). If the wireless guys have the problem, then their IPs should wind up getting blocked.
If you have "BOTH" configured under the "Which IP to block" setting, then in your custom Pass List I would suggest creating and adding an alias for your main LAN segment. That way those guys don't get locked out of the firewall just because they may have been an innocent target of something malicious from the wi-fi segment.
Bill
-
I've set the Home Network accordingly and the Pass List as specified. I'm still not able to block internal IPs as needed on this Network Segment. The Pass List is nearly empty with the exception of default gw which is added automatically.
-
What rules are you using? Are you seeing alerts on the ALERTS tab from these IP addresses in question? Please post a screen capture of the ALERTS tab with alerts that should be resulting in blocks. Either mark or tell me in the reply which IP should be getting blocked.
Bill
-
Sorry for the lag, I was out of town for a bit.
Attached is a screenshot of the alerts from this morning on our WIFI interface. The internal 172.16 addresses should be showing as blocked.
This is the only interface that blocks the SOURCE IPs. All other interfaces block the External DST IPs.
I also have pics of the HOME NET, EXTERNAL NET, and PASS LIST.
The pass list literally has 2 IPs in it (well 2 for IPv4 and 2 for IPv6), yet the source IPs for the 172.16 are NOT being blocked.
-
Sorry for the lag, I was out of town for a bit.
Attached is a screenshot of the alerts from this morning on our WIFI interface. The internal 172.16 addresses should be showing as blocked.
This is the only interface that blocks the SOURCE IPs. All other interfaces block the External DST IPs.
I also have pics of the HOME NET, EXTERNAL NET, and PASS LIST.
The pass list literally has 2 IPs in it (well 2 for IPv4 and 2 for IPv6), yet the source IPs for the 172.16 are NOT being blocked.
OK, I guess the next thing to see are those screenshots of the Pass List and HOME_NET values if you don't mind sharing. It should be blocking those IPs. There is automatic pass list insertion of the firewall's interface addresses, but these are specific to just the actual IP of the firewall's interface and do not encompass the subnet. It would also be helpful to provide the contents of the actual pass list file used by Snort. You can find this in /usr/local/etc/snort/xxxx where xxxx is a sub-directory unique to each configured Snort interface. There will be a plaintext file in the subdirectory named whatever the Pass List is named. Its contents are what Snort will actually be using (although the display in the GUI dialog should also match up).
Do you have anything configured in terms of IP Reputation? If by chance you do, then some settings there could potentially whitelist a network.
Bill
-
Hi Bill,
Here you go. IP Reputation is disabled see pictures below.
This is a weird one.
-
If you get an alert, you pretty much should be getting a block. Actually, looking at your EXTERNAL_NET variable and the way the rules are written ($HOME_NET –> $EXTERNAL_NET) I'm not sure why you are even getting the alert. The rule should not match since your EXTERNAL_NET variable seems to contain only a single link local IPv6 address. I was specifically looking at the ET-INFO rules and almost all of them are configured for a traffic flow of $HOME_NET --> $EXTERNAL_NET. The way I'm reading the rule, it should only match when a HOME_NET host talks to the WAN's link local IPv6 address.
Here is the two rule I was looking at --
alert udp $HOME_NET any -> $EXTERNAL_NET 3478 (msg:"ET INFO Session Traversal Utilities for NAT (STUN Binding Request)"; content:"|00 01|"; depth:2; content:"|21 12 a4 42|"; distance:2; within:4; reference:url,tools.ietf.org/html/rfc5389; classtype:attempted-user; sid:2016149; rev:2;)
Let's back up a step and be sure we don't have multiple Snort instances running on the same interface. If you can reboot this firewall, do that. If you can't reboot, then stop all Snort interfaces and then run this command from the shell prompt –
ps -ax | grep snort
You should see no running Snort processes. If you see any, kill them. Make sure "Block Offenders" is checked on the INTERFACE SETTINGS tab for your wireless interface, then restart the Snort interfaces. Let's see if that makes any difference. Report back again on the results from the steps above. This is a strange problem and I would like to get it figured out.
Bill
-
I got the exact same problem here.
I created an empty pass-list (for the same reason, I want to block LAN-IPs in a guest-wifi lan).
But the list still isn't empty and contains all of the connected NETWORKS (not only the IPs of pfSense itself). So it's 10.0.0.0/24 and not 10.0.0.1.Is there any solution? I even tried editing the snort.conf manually (for test reasons) and it didn't work…
-
I got the exact same problem here.
I created an empty pass-list (for the same reason, I want to block LAN-IPs in a guest-wifi lan).
But the list still isn't empty and contains all of the connected NETWORKS (not only the IPs of pfSense itself). So it's 10.0.0.0/24 and not 10.0.0.1.Is there any solution? I even tried editing the snort.conf manually (for test reasons) and it didn't work…
Using a Pass List requires doing two things. Many folks miss the second one and it is the most important.
1. Create the Pass List on the PASS LIST tab. If you don't want anything in it, just uncheck all the checkboxes then save it.
2. Go to the INTERFACE SETTINGS tab for the Snort interface and select the just saved Pass List in the Pass List drop-down box. Save the change and then restart Snort on the interface.Manually editing the snort.conf file for an interface will only work if you DO NOT restart Snort from the GUI. Each time the GUI start/stop logic runs it completely rewrites the snort.conf file using the saved configuration data. If you had manually edited the file, your changes are lost. The only way to make manual edits stick for a test is to start/stop Snort from the command line shell using the snort.sh script in /usr/local/etc/rc.d.
# to start Snort snort.sh start # to stop Snort snort.sh stop
Bill
-
Ah, I obviously misunderstood the meaning of a Pass-List.
I actually wanted to edit my HOME_NET Variable in a way, even LAN-IPs could get blocked.
So how can I do that?Yeah, manually editing was just for test-purposes, thanks for your info!
-
Ah, I obviously misunderstood the meaning of a Pass-List.
I actually wanted to edit my HOME_NET Variable in a way, even LAN-IPs could get blocked.
So how can I do that?Yeah, manually editing was just for test-purposes, thanks for your info!
Same way as a Pass List. Just select the list using the drop-down box for Home Net on the INTERFACE SETTINGS tab. All of the drop-downs on the INTERFACE SETTINGS page for Home Net, Pass List, Suppress List, etc., work the same.
HOME_NET has no direct link to whether an IP is blocked or not. That is more likely determined by the Pass List. HOME_NET has meaning only to the application of rules when evaluating "source" and "destination". For example, some rules only fire when the "destination" is HOME_NET while others fire only when the source is HOME_NET.
Bill
-
It Works!
I guess I fiddled with the External List a bit too much. Bill, your explanations really gave insight into some misconceptions and misunderstandings I had about the way that things were parsed with snort rules and how alerts were "matched". Thank you sincerely for your time and patience on all of this. I greatly appreciate your efforts!
-
It Works!
I guess I fiddled with the External List a bit too much. Bill, your explanations really gave insight into some misconceptions and misunderstandings I had about the way that things were parsed with snort rules and how alerts were "matched". Thank you sincerely for your time and patience on all of this. I greatly appreciate your efforts!
Glad you got it working. Generally the content of the EXTERNAL_NET is literally "!HOME_NET", which means any IP address not in HOME_NET is considered to be in EXTERNAL_NET. In your case, EXTERNAL_NET contained only a single specific IP address; and that one happened to be just the link local IPv6 address. So basically that rule should almost never match and fire (because the destination would never match your EXTERNAL_NET setting).
A typical Snort setup has HOME_NET set to all the local firewalled networks, and EXTERNAL_NET is set literally to !HOME_NET. The idea is that HOME_NET contains the networks being protected, and EXTERNAL_NET represents the home of the bad guys (which is considered to be everything not in HOME_NET). HOME_NET and EXTERNAL_NET represent "source" and "destination" hosts or networks in the rules. For a given rule, HOME_NET might be the "source" or it might be the "destination" of the traffic the rule is checking. Only when everything matches will the rule fire. This includes the direction of the flow, the source and destination networks, the ports (if defined), and the content of the traffic.
So in the rule below, you need traffic containing the "content" given in the rule to be flowing from a host whose IP address is within HOME_NET from any source port to a host in EXTERNAL_NET with a destination port of 3478 in order for the rule to fire. If anything does not match, the rule does not fire.
alert udp $HOME_NET any -> $EXTERNAL_NET 3478 (msg:"ET INFO Session Traversal Utilities for NAT (STUN Binding Request)"; content:"|00 01|"; depth:2; content:"|21 12 a4 42|"; distance:2; within:4; reference:url,tools.ietf.org/html/rfc5389; classtype:attempted-user; sid:2016149; rev:2;)
Bill