Snort Package 2.5.7 – Issues
-
It seems like there is an error in the script that runs that configures snort.conf. I am thinking this is a simple fix, but I'll let the experts speak to the issue. I don't really have time to dig on it. Thanks for the workaround by the way.
-CC
-
It seems like there is an error in the script that runs that configures snort.conf. I am thinking this is a simple fix, but I'll let the experts speak to the issue. I don't really have time to dig on it. Thanks for the workaround by the way.
-CC
When you edit the Snort interface: What is defined for Homenet in Snort Interface settings?
-
It seems like there is an error in the script that runs that configures snort.conf. I am thinking this is a simple fix, but I'll let the experts speak to the issue. I don't really have time to dig on it. Thanks for the workaround by the way.
-CC
How many interfaces are you running Snort on? Just the WAN, or WAN and LAN, or some other combination? The code that builds the snort.conf file (and the $HOME_NET variable) asks pfSense for the addresses associated with the interface Snort is running on, and then any far-end gateways (for example, on the WAN side).
Bill
-
It seems like there is an error in the script that runs that configures snort.conf. I am thinking this is a simple fix, but I'll let the experts speak to the issue. I don't really have time to dig on it. Thanks for the workaround by the way.
-CC
How many interfaces are you running Snort on? Just the WAN, or WAN and LAN, or some other combination? The code that builds the snort.conf file (and the $HOME_NET variable) asks pfSense for the addresses associated with the interface Snort is running on, and then any far-end gateways (for example, on the WAN side).
Bill
On my setup I had the same error. I have 4 interfaces, WAN, LAN, Opt1 (OpenVPN server for mobile ssl clients) and Opt2 (OpenVPN Client for a site to site shared key vpn). I run Snort on the WAN and LAN interfaces. On the snort instance on my LAN interface, it detected the IP of the interface (192.168.13.1) but did not add 192.168.13.0/24. It did catch my VPN subnets (192.168.14.0/24 for the mobile, and 10.0.8.0/24 for the site to site connection), Wan subnet, dns servers, and localhost.
I think the wan interface came up with the same list, but I don't have access to the router right now to look.
I tried digging around the code to see where the issue was but ran out of time last night.
-
On my setup I had the same error. I have 4 interfaces, WAN, LAN, Opt1 (OpenVPN server for mobile ssl clients) and Opt2 (OpenVPN Client for a site to site shared key vpn). I run Snort on the WAN and LAN interfaces. On the snort instance on my LAN interface, it detected the IP of the interface (192.168.13.1) but did not add 192.168.13.0/24. It did catch my VPN subnets (192.168.14.0/24 for the mobile, and 10.0.8.0/24 for the site to site connection), Wan subnet, dns servers, and localhost.
I think the wan interface came up with the same list, but I don't have access to the router right now to look.
I tried digging around the code to see where the issue was but ran out of time last night.
And you have the latest 2.5.7 version of the Snort package, correct?
The place where this is generated is wholly within the file /usr/local/pkg/snort.inc. The functions are near the very top of that file. They are called from the same file down in a function near the bottom called snort_generate_conf(). The actual line number is 2178. The called function that actually builds the $HOME_NET list is snort_build_list() that starts on line 154 in the same file.
You can experiment in that file with some edits if you want to. Just save a copy before you monkey with it, so if you mess it up you can easily restore. That file is the critical core of the Snort package, and if messed up, then no part of Snort will work correctly (including even the uninstall piece). So consider yourself warned … :D
If you can figure something out that either I or Ermal overlooked, please post back.
Bill
-
You can experiment in that file with some edits if you want to. Just save a copy before you monkey with it, so if you mess it up you can easily restore. That file is the critical core of the Snort package, and if messed up, then no part of Snort will work correctly (including even the uninstall piece). So consider yourself warned … :D
If you can figure something out that either I or Ermal overlooked, please post back.
Bill
Well, I fixed it, but I'm not sure you're going to like how :)
so in snort.inc line 209, it checks to see if the interface has a gateway configured, and if it doesn't it skips adding it to the list. I feel like I'm missing why having a gateway or not matters. Looks like this change was made 1-26 by ermal: https://github.com/pfsense/pfsense-packages/commit/b97368f2ed50c70ba7102acacd7d65cc3ffec109#config/snort/snort.inc
My LAN interface doesn't have a gateway specified. If I comment out 208/209 (and also 220/221 for ipv6) it adds 192.168.13.1/24 and functions properly.
-
Well, I fixed it, but I'm not sure you're going to like how :)
so in snort.inc line 209, it checks to see if the interface has a gateway configured, and if it doesn't it skips adding it to the list. I feel like I'm missing why having a gateway or not matters. Looks like this change was made 1-26 by ermal: https://github.com/pfsense/pfsense-packages/commit/b97368f2ed50c70ba7102acacd7d65cc3ffec109#config/snort/snort.inc
My LAN interface doesn't have a gateway specified. If I comment out 208/209 (and also 220/221 for ipv6) it adds 192.168.13.1/24 and functions properly.
I have been thinking about this whole $HOME_NET process since I made my previous post. I believe some fundamental changes can be made to improve the logic. You are correct that Ermal made some tweaks in this code earlier this year to address a problem with users' far-end gateway getting blocked on the WAN side. It is apparent, though, the logic around that may have some unintended consequences.
There is nothing I see intrinsically wrong with your fix. I will experiment a bit myself and see what I come up with. I don't want to post changes in this critical area of Snort without a lot of testing and careful thought.
My longer-term goal is to resurrect the Snort-Dev package and use it to test these kinds of things with a group of folks who have the time and equipment to help test Snort out there on the bleeding edge. That's much better than essentially keeping the production package in a state of semi-constant flux.
For folks currently impacted by this, they can manually create a suitable Alias and then create a Whitelist from that Alias. Finally, on the Snort Interface Settings tab for the affected interface, set $HOME_NET to the created whitelist object.
Bill
-
I feel like I'm missing why having a gateway or not matters.
The test for a gateway is the best way to see if the interface is a likely "WAN" interface. As you said, LAN interfaces will not typically have gateways associated with them. Notice the gateway test is within the "if statement" context for adding the WAN IP to the list.
I think I can improve on this logic, but I want to test my change very, very well before I consider creating a Pull Request for it. I can, when I get something working, recruit some volunteers for testing.
Bill
-
Could this be a cause for Snort not seeing the /24 subnet but you manually have to configure all subnet IP's as values in an alias?
-
Could this be a cause for Snort not seeing the /24 subnet but you manually have to configure all subnet IP's as values in an alias?
Yes, after looking at the code section in detail, I can see where it will get misled when an interface has no gateway (like the LAN, for example). I'm cooking up a better way to deal with this, but as I said I want to take some time and do this carefully.
Bill
-
SUPER!!
-
For folks currently impacted by this, they can manually create a suitable Alias and then create a Whitelist from that Alias. Finally, on the Snort Interface Settings tab for the affected interface, set $HOME_NET to the created whitelist object.
I already was doing that and I had this on my wish list for Snort, since I noticed that on my WAN interface the whole subnet was on $HOME_NET and not just the WAN IP address and I don't like my neighbors there.
It is also possible to redefine $HOME_NET when editing the interface in "Advanced configuration pass through". I tested that a week ago. -
I already was doing that and I had this on my wish list for Snort, since I noticed that on my WAN interface the whole subnet was on $HOME_NET and not just the WAN IP address and I don't like my neighbors there.
It is also possible to redefine $HOME_NET when editing the interface in "Advanced configuration pass through". I tested that a week ago.Yep, I don't like that "whole subnet" whitelisting on the WAN side either. I plan on fixing that, but there are some complicating factors caused by other interfaces that might have gateways. For example, my initial idea was to add the whole subnet as "friendly" on all interfaces EXCEPT those that had a gateway. For those, just add the interface IP. But that idea fell apart when I realized some other friendly interfaces may themselves have associated gateways, but where the user would still expect the subnet to be part of HOME_NET. So I'm still trying to figure something out that works in most all cases (especially for the default HOME_NET). Maybe I can safely assume the interface with the default gateway is the WAN, and just whitelist the IP on that one and not the entire subnet.
I welcome any ideas from you experienced Snort users. :)
By the way, I think I found the "issue" that has been dogging some folks where their subnets have been getting blocked. There are two calls that work with HOME_NET and whitelists. One to generate the $HOME_NET variable in snort.conf, and the other to generate the whitelist file fed to the Spoink plugin to control IP blocking. On the second call a parameter is set to TRUE that causes only IP addresses and not subnets to be returned and included in the Spoink whitelist. This was there from the old days when Spoink could only take individual IPs. Ermal fixed Spoink so that it could handle IP ranges (or subnets), but the little piece of code that builds the whitelist did not get altered.
-
DO IT :D
(thanks SO much Bill!!)
-
I already was doing that and I had this on my wish list for Snort, since I noticed that on my WAN interface the whole subnet was on $HOME_NET and not just the WAN IP address and I don't like my neighbors there.
It is also possible to redefine $HOME_NET when editing the interface in "Advanced configuration pass through". I tested that a week ago.Yep, I don't like that "whole subnet" whitelisting on the WAN side either. I plan on fixing that, but there are some complicating factors caused by other interfaces that might have gateways. For example, my initial idea was to add the whole subnet as "friendly" on all interfaces EXCEPT those that had a gateway. For those, just add the interface IP. But that idea fell apart when I realized some other friendly interfaces may themselves have associated gateways, but where the user would still expect the subnet to be part of HOME_NET. So I'm still trying to figure something out that works in most all cases (especially for the default HOME_NET). Maybe I can safely assume the interface with the default gateway is the WAN, and just whitelist the IP on that one and not the entire subnet.
I welcome any ideas from you experienced Snort users. :)
By the way, I think I found the "issue" that has been dogging some folks where their subnets have been getting blocked. There are two calls that work with HOME_NET and whitelists. One to generate the $HOME_NET variable in snort.conf, and the other to generate the whitelist file fed to the Spoink plugin to control IP blocking. On the second call a parameter is set to TRUE that causes only IP addresses and not subnets to be returned and included in the Spoink whitelist. This was there from the old days when Spoink could only take individual IPs. Ermal fixed Spoink so that it could handle IP ranges (or subnets), but the little piece of code that builds the whitelist did not get altered.
Maybe you should make a new topic with a new title for a new discussion on this subject. It is not really an issue with this version. People will not pay attention to this topic when they have no issues, I think.
-
I already was doing that and I had this on my wish list for Snort, since I noticed that on my WAN interface the whole subnet was on $HOME_NET and not just the WAN IP address and I don't like my neighbors there.
It is also possible to redefine $HOME_NET when editing the interface in "Advanced configuration pass through". I tested that a week ago.Yep, I don't like that "whole subnet" whitelisting on the WAN side either. I plan on fixing that, but there are some complicating factors caused by other interfaces that might have gateways. For example, my initial idea was to add the whole subnet as "friendly" on all interfaces EXCEPT those that had a gateway. For those, just add the interface IP. But that idea fell apart when I realized some other friendly interfaces may themselves have associated gateways, but where the user would still expect the subnet to be part of HOME_NET. So I'm still trying to figure something out that works in most all cases (especially for the default HOME_NET). Maybe I can safely assume the interface with the default gateway is the WAN, and just whitelist the IP on that one and not the entire subnet.
I welcome any ideas from you experienced Snort users. :)
By the way, I think I found the "issue" that has been dogging some folks where their subnets have been getting blocked. There are two calls that work with HOME_NET and whitelists. One to generate the $HOME_NET variable in snort.conf, and the other to generate the whitelist file fed to the Spoink plugin to control IP blocking. On the second call a parameter is set to TRUE that causes only IP addresses and not subnets to be returned and included in the Spoink whitelist. This was there from the old days when Spoink could only take individual IPs. Ermal fixed Spoink so that it could handle IP ranges (or subnets), but the little piece of code that builds the whitelist did not get altered.
Maybe you should make a new topic with a new title for a new discussion on this subject. It is not really an issue with this version. People will not pay attention to this topic when they have no issues, I think.
Will do.
Bill
-
For folks currently impacted by this, they can manually create a suitable Alias and then create a Whitelist from that Alias. Finally, on the Snort Interface Settings tab for the affected interface, set $HOME_NET to the created whitelist object.
I already was doing that and I had this on my wish list for Snort, since I noticed that on my WAN interface the whole subnet was on $HOME_NET and not just the WAN IP address and I don't like my neighbors there.
It is also possible to redefine $HOME_NET when editing the interface in "Advanced configuration pass through". I tested that a week ago.This workaround resolved the issue for me. I had to define my LAN subnet, set it as my $HOME_NET, and it wrote the config to snort.conf.
Define Local Network
var HOME_NET [127.0.0.1,192.168.1.0/27,192.168.1.1]
var EXTERNAL_NET [!$HOME_NET] -
Just a note about the snort config script.
Option 1.
It might be helpful to have it pull in the $HOME_NET info based on the the interface (LAN) IP address and subnet mask.
Option 2.
Or, allow a field in the snort interface config GUI area for the user to define the networks they want to monitor. It seems a bit redundant to use the Whitelist, since it will define your gateway address and the network you want to monitor.
The following was written to my snort.conf using the Whitelist I defined:
Define Local Network
var HOME_NET [127.0.0.1,192.168.1.0/27,192.168.1.1]
var EXTERNAL_NET [!$HOME_NET]192.168.1.1 is not needed since you are already watching the 192.168.1.0/27 network.
var HOME_NET [127.0.0.1,192.168.1.0/27]Option 2 might be the cleanest method.
-
Just a note about the snort config script.
Option 1.
It might be helpful to have it pull in the $HOME_NET info based on the the interface (LAN) IP address and subnet mask.
Option 2.
Or, allow a field in the snort interface config GUI area for the user to define the networks they want to monitor. It seems a bit redundant to use the Whitelist, since it will define your gateway address and the network you want to monitor.
The following was written to my snort.conf using the Whitelist I defined:
Define Local Network #
var HOME_NET [127.0.0.1,192.168.1.0/27,192.168.1.1]
var EXTERNAL_NET [!$HOME_NET]192.168.1.1 is not needed since you are already watching the 192.168.1.0/27 network.
var HOME_NET [127.0.0.1,192.168.1.0/27]Option 2 might be the cleanest method.
I have been studying the parts of the Snort package responsible for auto-populating the HOME_NET variable and the default whitelist for the Spoink module. I've identified some areas that I think can work better. One of them is being sure to include the entire network for the interfaces that are not the WAN. For the WAN, just include the actual interface IP and the far-end (presumably, the default) gateway. Also include the options for DNS servers, VPNs and VIPs if desired.
This part of the code contains some legacy stuff that worked with the limits of the original Spoink plugin. Last year Ermal modified the plugin to accept IP ranges in the whitelist. Prior to that, it only accepted individual IP addresses. This limitation was reflected in the HOME_NET and whitelist code. Now that Spoink can accept IP ranges (as in entire networks in CIDR notation), the old limitations can be removed from the HOME_NET and whitelist code. A limited tweak was done last year on the WAN side, but it currently results in the entire subnet on the WAN getting whitelisted (and shown in HOME_NET). That's probably not what most folks want. On the WAN side you would desire just the interface IP and the far-end gateway be in the whitelist and HOME_NET.
Bill
-
Yes that make sense.