Bug #14645
closed
Snort interface "External Net" (EXTERNAL_NET) custom IP list should have negation when expanded
100%
Description
Hello,
I'm not really good with Snort but all my search results confirm that it is common to have EXTERNAL_NET config variable defined as !HOME_NET by default. This should include all networks except those in HOME_NET . Default pfSense HOME_NET list includes local interfaces subnets, DNS servers, loopback IPs. Default EXTERNAL_NET includes the same list of IPs/networks but with ! in front of each entry - pretty much the same as with !HOME_NET approach. That's great.
Example VM entries from final snort config (/usr/local/etc/snort/snort_53008_vtnet0/snort.conf here), public IPs and DNS servers redacted.
# Define Local Network # ipvar HOME_NET [DNS1,WANGW,WANIP,127.0.0.1,192.168.1.0/24,DNS2,::1,fe80::1:1,fe80::c3b:98ff:fece:9315] ipvar EXTERNAL_NET [!DNS1,!WANGW,!WANIP,!127.0.0.1,!192.168.1.0/24,!DNS2,!::1,!fe80::1:1,!fe80::c3b:98ff:fece:9315]
However, if we create a new passlist on /snort/snort_passlist.php page, we can not include negation (exclamation mark) into definition (neither on passlist page nor on IP alias page) and the networks will not be prepended with ! in final Snort config file.
Example config with custom passlist (some IPs/network added as aliases and simple IPs for testing)
ipvar HOME_NET [DNS1,WANGW,WANIP,127.0.0.1,192.168.1.0/24,DNS2,::1,fe80::1:1,fe80::c3b:98ff:fece:9315] ipvar EXTERNAL_NET [[10.11.12.13,DNS1,WANGW,WANIP,127.0.0.1,192.168.1.0/24,192.168.33.0/28,192.168.50.33,DNS2,fe80::1:1,fe80::c3b:98ff:fece:9315]]
Also please note that EXTERNAL_NET here has double square brackets now (not sure if this should be fixed)
If we use the same custom passlist for both HOME_NET and EXTERNAL_NET we have correct HOME_NET but same broken EXTERNAL_NET.
# Define Local Network # ipvar HOME_NET [10.11.12.13,DNS1,WANGW,WANIP,127.0.0.1,192.168.1.0/24,192.168.33.0/28,192.168.50.33,DNS2,::1,fe80::1:1,fe80::c3b:98ff:fece:9315] ipvar EXTERNAL_NET [[10.11.12.13,DNS1,WANGW,WANIP,127.0.0.1,192.168.1.0/24,192.168.33.0/28,192.168.50.33,DNS2,fe80::1:1,fe80::c3b:98ff:fece:9315]]
Current behavior silently breaks many (most?) IDS rules, because they depend on correct EXTERNAL_NET definition, and we effectively have HOME_NET with some modifications instead of actual EXTERNAL_NET we want.
We can work around defining custom EXTERNAL_NET pass lists as all subnets before and after required HOME_NET IPs/Networks. But that's a lot of networks to include in the definition, for example for 10.11.12.13 we have to include 0.0.0.0/5, 8.0.0.0/7, 10.xxx networks before and after 10.11.12.13, then 11.xx, 12.xx and everything up to 255.255.255.255.
So I think GUI should prepend all entries in final config with ! as it does with default passlist. And maybe remove second square bracket set (sorry for being noob here :D).
Thank you.
Updated by Bill Meeks over 1 year ago
Sorry to be late replying to this ticket.
First, the double brackets is a bug and will be corrected in a forthcoming Snort package update. I am also going to simplify the default $EXTERNAL_NET definition to be !HOME_NET directly instead of individually negating each individual HOME_NET entry. Using !HOME_NET accomplishes the same thing in much less space.
As for your request to have the ability to negate EXTERNAL_NET values in a custom list, I can't envision a scenario where that would make sense because it is almost never necessary to modify EXTERNAL_NET from its default value of !HOME_NET. You typically want EXTERNAL_NET to be the universe of IP space that you are not protecting with the IDS/IPS. Therefore, you define your sensitive or protected networks in HOME_NET, and then the default definition of EXTERNAL_NET as !HOME_NET automatically puts the remainder of the Internet in EXTERNAL_NET as "the enemy". Can you help me understand your request by giving me an example use case where customizing EXTERNAL_NET is advantageous?
Updated by Bill Meeks over 1 year ago
This issue is corrected by Snort package update 4.1.6_12 posted for review and merge here: https://github.com/pfsense/FreeBSD-ports/pull/1315.
This issue may be marked "Resolved" when the pull request is merged.
Updated by Dzmitry Kazei over 1 year ago
Hi Bill,
main problem is when you have some static IPs outside of your network (let's say your work IPs or your VPN exit IP), which you are sure will not generate bad traffic, hit some IDS rules. For example I was not able to use RDP from outside the protected network (HOME_NET) until I disabled IDS RDP rules. Adding these IPs to HOME_NET looks suboptimal to me, tbh I was sure I could not add them to my HOME_NET because it was breaking some rules, but it was 3 months ago and I do not remember now, could be just my imagination.
Thank you for your attention.
Updated by Jim Pingle over 1 year ago
- Status changed from New to Resolved
- % Done changed from 0 to 100
PR merged, thanks!