Snort broken: whitelist
-
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.
