Snort broken: whitelist
-
The logic for Spoink seems to be OK and not require any modification.
Looking at the rest, it seems there should be 2 independent parallel processes.
1. The timeout process which already works very well at user specified frequencies
2. The whitelist process which should
a. Update the whitelist file and memory
b. Remove whitelisted IPs from the blocklistThe frequency for 2a and 2b, I think, should be on a seperate timer than 1. Ideally it should be tied to the 5 minute pfSense timer for updating alias IPs.
I don't know how all the functions interact with each other, hopefully Spoink and the timeout processes don't need to be touched. Maybe what needs to be modified is the whitelist process to include 2a and 2b, migrating it from a static whitelist to a dynamic whitelist with the added function of removing IPs from the banned list.
Currently, with the whitelist only being read into memory once, when snort is started, I can see the following problems occuring:
User starts Snort with whitelist.
Snort whitelist has the standard checkboxes (WAN IP, WAN gateway, DNS server, Virtual IP, VPN)
1. User creates IPSEC tunnel (this new tunnel is not in the whitelist)
2. User's ISP sends a new DHCP lease, with a new IP, new Gateway, new DNS servers (none of these will be in the whitelist) -
It looks like the Snort plugin is relying on a semi broken pfSense Alias function as described here:
http://forum.pfsense.org/index.php/topic,61264.0.html -
It looks like the Snort plugin is relying on a semi broken pfSense Alias function as described here:
http://forum.pfsense.org/index.php/topic,61264.0.htmlYep, the Snort package simply uses the filter_expand_alias() function call in pfSense to turn aliases into IP addresses or networks. So if that function returns inconsistent results, then Snort will suffer the same fate. On the other hand, the Snort package is not currently equipped to handle dynamic aliases. So currently the problem of semi-broken dynamic aliases is moot for Snort.
I can see where such functionality would obviously be quite useful, but integrating it into Snort will take some work.
Bill
-
The logic for Spoink seems to be OK and not require any modification.
Looking at the rest, it seems there should be 2 independent parallel processes.
1. The timeout process which already works very well at user specified frequencies
2. The whitelist process which should
a. Update the whitelist file and memory
b. Remove whitelisted IPs from the blocklistThe frequency for 2a and 2b, I think, should be on a seperate timer than 1. Ideally it should be tied to the 5 minute pfSense timer for updating alias IPs.
I don't know how all the functions interact with each other, hopefully Spoink and the timeout processes don't need to be touched. Maybe what needs to be modified is the whitelist process to include 2a and 2b, migrating it from a static whitelist to a dynamic whitelist with the added function of removing IPs from the banned list.
Currently, with the whitelist only being read into memory once, when snort is started, I can see the following problems occuring:
User starts Snort with whitelist.
Snort whitelist has the standard checkboxes (WAN IP, WAN gateway, DNS server, Virtual IP, VPN)
1. User creates IPSEC tunnel (this new tunnel is not in the whitelist)
2. User's ISP sends a new DHCP lease, with a new IP, new Gateway, new DNS servers (none of these will be in the whitelist)Just musing off the top of my head about this, it might be possible to make the Snort 5-minute cron job a little smarter so that it could perhaps do task 2b from your list. Task 2a would more than likely have to be baked into the Spoink plugin code. I'm not 100% sure at this point how feasible that is, though.
Bill
-
The concern I have with baking in 2a with spoink is that it would only be triggered when a new blocked host is added. Putting 2a on its own independent timer I think would be more effective.
-
Currently, with the whitelist only being read into memory once, when snort is started, I can see the following problems occuring:
User starts Snort with whitelist.
Snort whitelist has the standard checkboxes (WAN IP, WAN gateway, DNS server, Virtual IP, VPN)
1. User creates IPSEC tunnel (this new tunnel is not in the whitelist)
2. User's ISP sends a new DHCP lease, with a new IP, new Gateway, new DNS servers (none of these will be in the whitelist)Looking at the above scenario, one could also argue that this may be expecting a bit much from Snort itself. In the above scenario, what would likely trigger a Snort "block"? Would it be a false positive or a real threat? If a FP (false positive), maybe tuning of Snort is the cure. If it's a real threat, then do you really want to whitelist that? Have you experienced something like this scenario in the real world, and if so, can you provide me some information to help me understand better?
Bill
-
Currently, with the whitelist only being read into memory once, when snort is started, I can see the following problems occuring:
User starts Snort with whitelist.
Snort whitelist has the standard checkboxes (WAN IP, WAN gateway, DNS server, Virtual IP, VPN)
1. User creates IPSEC tunnel (this new tunnel is not in the whitelist)
2. User's ISP sends a new DHCP lease, with a new IP, new Gateway, new DNS servers (none of these will be in the whitelist)Looking at the above scenario, one could also argue that this may be expecting a bit much from Snort itself. In the above scenario, what would likely trigger a Snort "block"? Would it be a false positive or a real threat? If a FP (false positive), maybe tuning of Snort is the cure. If it's a real threat, then do you really want to whitelist that? Have you experienced something like this scenario in the real world, and if so, can you provide me some information to help me understand better?
Bill
The only problem I've experienced with the Snort whitelist is it does not work with Aliases containing FQDNs.
After I understood how and when the whitelist is populated, those 2 additional problems immediately came to mind.
If a user selects these options in the whitelist I would think they would expect the whitelist to remain updated after they create new VPN tunnels (common task for admins) or when their ISP DHCP lease expires (common for a lot of broadband connections) -
The only problem I've experienced with the Snort whitelist is it does not work with Aliases containing FQDNs.
After I understood how and when the whitelist is populated, those 2 additional problems immediately came to mind.
If a user selects these options in the whitelist I would think they would expect the whitelist to remain updated after they create new VPN tunnels (common task for admins) or when their ISP DHCP lease expires (common for a lot of broadband connections)I agree those two examples make sense. I will research some potential solutions, but this is not something that is likely to appear in a release in the near future. There's quite a bit of work to do and some logic to rework to pull this off in the Snort module.
One long-term goal of mine was to work on resurrecting the old Snort-Dev package and letting it be the test bed for bleeding-edge updates. Something like this dynamic-aliases whitelisting would be something suited to a Snort-Dev package.
Bill
-
Well a new ip and gateway should trigger a snort reload and the new ips will be inserted in the whitelist and snort should read them up.
The difficulty is that you ask something that snort is not able to do, dynamicity.While everything can be programmed there are priorities to be set and i do not think this will be in the top list, especially since its not an easy change.
-
I can appreciate the difficulty in creating a dynamic whitelist for Snort.
Perhaps in the interim a partial solution could be getting the whitelist to at least populate on startup all the IPs from an alias, including those from FQDNs.
