Soliciting Feedback on Snort Package 2.6.x Multi-Engine Config GUI Design
-
It seems like the main use for the Multi-Engine feature on frag3 is to tailor it to different OSes which isn't needed with pfsense by default already defragmenting the packets.
Pfsense has de-fragment reassembly turned on by default (scrub reassemble) which will buffer and reassemble the packets on all interfaces. Under that situation you would always want to use BSD as the Target Type.
If you for some reason disable scrub in pfsense (Disable Firewall Scrub in Advanced/Firewall section) it would be useful to be able to tailor it to the specific protected hosts(Windows, Linux, BSD, etc) but unless you have problems with scrub I would think everyone would want the firewall to re-assemble them to help protect the hosts itself (most firewalls do this).
I would think everyone would want frag3 to report malicious frag attempts from the external WAN for all traffic that comes in so I don't really see a use for limiting it to certain IPs (again.. assuming scrub is enabled on the firewall so only one Target Type needed).
Is there another reason for this that I am just not understanding?
I guess some will use pfsense without a lot of firewalling features turned on so maybe there are more setups with (Disable Firewall Scrub) set than I am aware of though?
UPDATE. (The text below I added after the fact when I second guessed myself. Pf does normalize the traffic before sending it out so the text above this seems correct.)
I think i have mis-understood the scrub reassemble behavior in pf. I assumed that it will buffer, reassemble the packets, and send them out reassembled so that they are normalized when exiting the other side but the more I think about it the more I am not sure of this.
Does pfsense buffer fragments and then send them out as is once they are analyzed (only normalizing them internally to inspect them)? If so then my post is useless and we would need to target the backend server OS types even with the default scrub reassemble behavior in pf.
-
Nice additions. However, it would be nice if the 'start/stop' icon be put either on the front column of the interfaces to eliminate confusion. Thanks!
-
I just tested pf with defragmentation using hping from another system and pf does normalize the traffic before sending it out. It actually normalizes the traffic before tcpdump can even see it. If the packets are bad enough though and pf can not or does not reassemble them then tcpdump on pfsense does see those bad fragmented packets. It does not send them to the destination of course. I can only assume snort has an input point into the network at a lower level than tcpdump so that it can see the raw fragment packets at all times but I do not know.
It seems like we should always use BSD Target Type with frag3 when the admin does not disable the pfsense 'Disable Firewall Scrub' which is the default.
-
I just tested pf with defragmentation using hping from another system and pf does normalize the traffic before sending it out. It actually normalizes the traffic before tcpdump can even see it. If the packets are bad enough though and pf can not or does not reassemble them then tcpdump on pfsense does see those bad fragmented packets. It does not send them to the destination of course. I can only assume snort has an input point into the network at a lower level than tcpdump so that it can see the raw fragment packets at all times but I do not know.
It seems like we should always use BSD Target Type with frag3 when the admin does not disable the pfsense 'Disable Firewall Scrub' which is the default.
Interesting test results, and thank you for performing them. I do not understand all the deep internals of pfSense. You brought up a question we should perhaps ask of the Core Team developers. I will ping them with a copy of this thread and see if someone will weigh in. It may well be that multi-engine Frag3 configurations are unnecessary on pfSense, but I don't really know. Some of the other multi-engine configs will likely be quite useful. I'm thinking particularly of the HTTP_INSPECT preprocessor.
Bill
-
Nice additions. However, it would be nice if the 'start/stop' icon be put either on the front column of the interfaces to eliminate confusion. Thanks!
To be sure I fully understand your request – are you talking about on the Snort Interfaces tab? And your suggestion is putting the start/stop icons on the left side of the table in the first column just after the checkboxes (that is, just to their right)?
Bill
-
Bill….one odd question. If you create multiple whitelists in the whitelist tab....how do you use them when you can choose only one from the GUI?
It would be sad to have to run multiple snort instances on the same interface just to get them whitelisted when using multiple aliases.
-
Nice additions. However, it would be nice if the 'start/stop' icon be put either on the front column of the interfaces to eliminate confusion. Thanks!
To be sure I fully understand your request – are you talking about on the Snort Interfaces tab? And your suggestion is putting the start/stop icons on the left side of the table in the first column just after the checkboxes (that is, just to their right)?
Bill
Exactly, you got me right! :)
-
Bill….one odd question. If you create multiple whitelists in the whitelist tab....how do you use them when you can choose only one from the GUI?
It would be sad to have to run multiple snort instances on the same interface just to get them whitelisted when using multiple aliases.
You can have only one whitelist per snort instance. Literally the whitelist is just a file read by the Spoink plugin on startup. Since the whitelist can contain hosts or networks from the Aliases collection, the method to achieve what you want is to create an Alias (under Firewall…Aliases) or Alias Group containing the extra hosts or networks. Then add that Alias to the Whitelist (it's the bottom form field on the Whitelist Edit page).
I think the original idea for the multiple whitelists in the Whitelist tab was for folks running Snort on more than one interface.
UPDATE – on a sort of related note while we are talking about whitelists: someone asked quite some time back about Snort handling FQDN Aliases in whitelists. These are Aliases that are actually fully-qualified domain name hosts and are resolved by pfSense on a periodic basis to handle any updates to their IP address. I figured out how to implement these "sort of" in Snort. It won't be really "dynamic" in the sense the instant the FQDN IP address updates Snort will know about it. Snort the binary is just not geared to work that way. It expects everything to be specified in its configuration file, snort.conf, and it reads that file only during startup or when the process is sent a SIGHUP signal. There is no way to instantly and on-the-fly update Snort with FQDN changes. However, what I mean by "sort of" implementing support of FQDN Aliases, is Snort can refresh the FQDN entity each time it is stopped and started manually or during an automatic rules download and update. Both events result in Snort rebuilding the snort.conf file. I plan to include this partial support of FQDN Aliases in the next Snort update.
Bill
-
Bill….one odd question. If you create multiple whitelists in the whitelist tab....how do you use them when you can choose only one from the GUI?
It would be sad to have to run multiple snort instances on the same interface just to get them whitelisted when using multiple aliases.
You can have only one whitelist per snort instance. Literally the whitelist is just a file read by the Spoink plugin on startup. Since the whitelist can contain hosts or networks from the Aliases collection, the method to achieve what you want is to create an Alias (under Firewall…Aliases) or Alias Group containing the extra hosts or networks. Then add that Alias to the Whitelist (it's the bottom form field on the Whitelist Edit page).
I think the original idea for the multiple whitelists in the Whitelist tab was for folks running Snort on more than one interface.
UPDATE – on a sort of related note while we are talking about whitelists: someone asked quite some time back about Snort handling FQDN Aliases in whitelists. These are Aliases that are actually fully-qualified domain name hosts and are resolved by pfSense on a periodic basis to handle any updates to their IP address. I figured out how to implement these "sort of" in Snort. It won't be really "dynamic" in the sense the instant the FQDN IP address updates Snort will know about it. Snort the binary is just not geared to work that way. It expects everything to be specified in its configuration file, snort.conf, and it reads that file only during startup or when the process is sent a SIGHUP signal. There is no way to instantly and on-the-fly update Snort with FQDN changes. However, what I mean by "sort of" implementing support of FQDN Aliases, is Snort can refresh the FQDN entity each time it is stopped and started manually or during an automatic rules download and update. Both events result in Snort rebuilding the snort.conf file. I plan to include this partial support of FQDN Aliases in the next Snort update.
Bill
The only way to handle FQDN aliases is splitting the blocking into an external plugin.
While its easier with newer versions of snort someone needs to do the work and probably needs to be in C/C++ whatever fast language it can be. -
I just tested pf with defragmentation using hping from another system and pf does normalize the traffic before sending it out. It actually normalizes the traffic before tcpdump can even see it. If the packets are bad enough though and pf can not or does not reassemble them then tcpdump on pfsense does see those bad fragmented packets. It does not send them to the destination of course. I can only assume snort has an input point into the network at a lower level than tcpdump so that it can see the raw fragment packets at all times but I do not know.
It seems like we should always use BSD Target Type with frag3 when the admin does not disable the pfsense 'Disable Firewall Scrub' which is the default.
no the scrubbing done by pfSense firewall is not related to snort.
Since tpcudmp/pcap sees packets very early, before even stack has seen them.