Soliciting Feedback on Snort Package 2.6.x Multi-Engine Config GUI Design
-
I am currently working on incorporating the capability for creating multiple "engines" for those Snort preprocessors and config options that support it. This lets you configure different parameters for different IP addresses or subnets. One preprocessor that supports this multi-engine capability is the Frag3 preprocessor. I am posting a very early prototype of the interface using the Frag3 preprocessor to illustrate the GUI.
In the first attached image, you will see the section from the Preprocessors tab for configuring the Frag3 settings. Notice the new table of "engines" included in the section. Above the table are the two global Frag3 settings (these apply to all the engines). Clicking the "e" icon next to an engine entry in the table takes you to the page for editing the configurable Frag3 engine parameters. Clicking the "x" icon will delete the engine entry. Clicking the plus (+) icon at the top right of the table lets you add an additional engine entry. In the example posted, I've added three additional engines to the "default" one.
The second attached image shows the configuration page for the individual engine parameters. I know this may be controversial for some folks, but the "Bind-To IP Address" field will most likely wind up using Aliases. That means you can only enter pre-defined Aliases here. I am thinking about making a quick link to the Aliases page, though. ;)
Would this be a useful feature for most users? If you think so, then I would appreciate some feedback on what your "priority" preprocessors would be to get this functionality. I'm currently thinking Frag3, Stream5 and HTTP_Inspect to start. Do you have any others that should be on the list? I also welcome any suggestions of a better way to pull this off within the GUI. I was trying to both keep the coding relatively simple and also match the way other similar sections of the pfSense GUI work.
Bill
-
It looks pretty good. The way you added the engine configuration looks nice and clean. As for myself, the 3 processors u mentioned are the only ones i really use. But if think of anything i will let you know.
-
It looks pretty good. The way you added the engine configuration looks nice and clean. As for myself, the 3 processors u mentioned are the only ones i really use. But if think of anything i will let you know.
Thank you for the feedback. It should not take too long to get this working for Frag3, Stream5 and HTTP_Inspect.
Bill
-
LOOOOOVE!!! :D
-
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.