Snort 2.9.6.2 pkg v3.1.3 Update – Release Notes
-
Snort 2.9.6.2 package update v3.1.3
An update for the Snort package has been posted. This update contains five bug fixes, five new features and seven improvements to existing features.
NOTE: the suggested upgrade method for this update is to first remove the Snort package, and then install it again rather than using the package reinstall icon. This is because of some changes in the snort.inc file.
Bug Fixes
1. Barnyard2 SENSOR_NAME parameter should not contain spaces, but input value is not validated.
2. When cloning a Snort interface using the DUP icon, the UUID is not changed resulting in duplicate UUIDs.
3. When Barnyard2 is disabled on an interface, existing MySQL and other settings are lost.
4. The automatic rules update cron task generates a useless e-mail alert with progress bar output in it.
5. Snort and Suricata share some similarly named string CONSTANTS. These conflict and cause issues when both packages are installed together.
Improvements
1. Changes in startup script should help prevent occasional duplicate Snort processes being created for an interface on reboots.
2. Unnecessary calls to write_config() and install_cron_job() were eliminated to reduce log spam and not trigger as many auto-config backups.
3. A number of formerly hard-coded system paths now use the corresponding system globals instead.
4. Generation of HOME_NET and EXTERNAL_NET variables is improved and a VIEW LIST button has been added to allow viewing of EXTERNAL_NET contents.
5. In a number of places in the package, operating system calls have been replaced with the corresponding pfSense wrapper functions.
6. The CARP package sync process is improved, and when configured, auto-SID management conf files are replicated from the master to slaves.
7. The Snort Dashboard Widget now displays the more useful rule Description field instead of the Priority and Classification fields.
New Features
1. Add filter dialog function to ALERTS tab to allow filtering of alerts display.
2. Add automatic SID management using PulledPork and Oinkmaster compatible conf files.
3. Add new LOGS MGMT tab for managing log rotation and retention times.
4. Add new LOGS VIEW tab to each configured Snort interface for viewing certain text logs.
5. Add FACILITY and PRIORITY parameters to syslog output configuration for alerts and Barnyard2 output.
-
G'day MasterBill ;D
Bill, could I ask a quick question? Is there a tutorial somewhere for the 'automatic SID mgmnt'? Perhaps there is, but I couldn't find it (also looked at your GIT-hub). Because if this is to make the enabling/disabling of rules much easier, I'm a big fan of it already: if only I know how it works.
If you have posted some instructions somewhere then I apologize for this question, but I can't seem to find it :-[
Thank you for all you do, Bill ( :-* )
-
@Hollander:
G'day MasterBill ;D
Bill, could I ask a quick question? Is there a tutorial somewhere for the 'automatic SID mgmnt'? Perhaps there is, but I couldn't find it (also looked at your GIT-hub). Because if this is to make the enabling/disabling of rules much easier, I'm a big fan of it already: if only I know how it works.
If you have posted some instructions somewhere then I apologize for this question, but I can't seem to find it :-[
Thank you for all you do, Bill ( :-* )
[/quote]No, there is not a specific tutorial about auto-SID management for the Snort package on pfSense. There are comments in the three sample conf files installed with the package. Those are listed on the SID MGMT tab as enablesid-sample.conf, disablesid-sample.conf and modifysid-sample.conf. The comments in those files offer some examples. Click the e icon to the right of the files to open them in the editor for easy viewing.
You can also Google "snort rule management" and find some links. Here is one example I found based on Security Onion: http://www.drchaos.com/fine-tuning-snort-rules-in-security-onion/.
To quickly summarize how the process works, you have three configuration options: (1) a list of rules that should always be disabled, (2) a list of rules that should always be enabled, and (3) a list of rules whose content should always be modified. These configuration options correspond to the three files: (1) disablesid.conf, (2) enablesid.conf, and (3) modifysid.conf. The exact names do not matter. On the SID MGMT tab you assign a particular filename to a particular action (disable, enable or modify). You make the assignment using the combo-box controls on the tab. There is also a SID State Order control. That is used to determine whether to execute the "enablesid" file first or the "disablesid" file first. This order can be important when the values in the files potentially affect the same rule(s). Whichever file executed last will have the controlling influence. So if you had the same SID listed in both enablesid.conf and disablesid.conf, and you had the SID State Order set for "disable,enable", the SID would wind up "enabled" because the enable file was last executed. Now of course you would not generally specify the same SID in both files, but there are other ways of matching SIDs besides the actual SID code. You can use regular expression syntax and other keywords to match multiple SIDs. It's these regex type matches that could possibly cause the same SID to be referenced in both enable and disable passes. This is why the SID State Order control is there.
Rules impacted by any SID MGMT configuration files are marked in the GUI with a special purple icon. You can see this icon beside impacted rules or categories on the CATEGORIES and RULES tabs. This will give you visual clues as to how the SID management conf files are being interpreted. There is a "grayed-out" version of the same purple icon to show a rule or category that has been disabled by the SID management conf files.
My hope when I included the SID MGMT feature in both Snort and Suricata was that some of the more experienced IDS users here would be willing to post enablesid.conf and disablesid.conf files already configured. Less experienced users could then download and use those files in their setups to help them learn how to fine-tune an IDS.
What the SID MGMT feature really does is allow you to manage your rules without ever needing to go to the CATEGORIES or RULES tabs in the Snort package. You can selectively enable or disable any rule or rule category using values in the SID MGMT files. It also greatly simplifies rule management for admins who administer multiple firewalls in different networks, but that need the same Snort rule setup. These admins can configure a set of enablesid.conf and disablesid.conf files and just upload them to all managed firewalls.
Bill
-
Thank you for your fast reply, Bill ;D
What the SID MGMT feature really does is allow you to manage your rules without ever needing to go to the CATEGORIES or RULES tabs in the Snort package. You can selectively enable or disable any rule or rule category using values in the SID MGMT files. It also greatly simplifies rule management for admins who administer multiple firewalls in different networks, but that need the same Snort rule setup. These admins can configure a set of enablesid.conf and disablesid.conf files and just upload them to all managed firewalls
I think that what you have added creates tremendous value for anybody who uses Snort/Suricata: tremendous value(!)
Because, as has been discussed in some threads before, the manually, rule after rule, enabling/disabling, and on each change having to wait for the pfSense to respond back in the GUI, was, at least for me a horrible excersise. I once started it, even took a lunch box with me for this job ( ;D ) but never finished it because it simply took too much time.
So with this gift of yours it is now easier than ever: keep a centralized config file, apply that file to all your interfaces, and forget about it. Marvelous :-*
My hope when I included the SID MGMT feature in both Snort and Suricata was that some of the more experienced IDS users here would be willing to post enablesid.conf and disablesid.conf files already configured. Less experienced users could then download and use those files in their setups to help them learn how to fine-tune an IDS.
Well I hope you won't mind if noobs give it a try ;D
Because I will want to spend some man time myself to see if I can give this back to the community. I will use JFL's instructions for it, and I have just sent JFL a message asking for some wise guidance from him, as, with the diversity of information there currently is, I don't know exactly where to start. Basically, I am reducing myself to 'dumb labor' ('hands', as we used to called them in the ERP-projects, or, by means of a joke: we asked for a 'del' in our project budgets. Which invoked shocks with 'those that can't stand a joke because they want to be politically correct to demonstrate how sophisticated they are', as 'del' is the Dutch word for 'slut'. Of course, we replied 'where are your thoughts? How long have you been doing IT, mr. 'vice president'? 'Del' is the internationally accepted short for Data Entry Lady' ( ;D ;D ;D ;D ;D ).
So, while I will want to devote time to creating these SID's, I've asked JFL on some guidance concerning his lists. Beyond that, we also need to find a way for proper change management: posting updates in forum threads also isn't the most efficient to do, so we might need to store these GID's on github (as BB does with his pfBlocker 2.0). But I don't have a clue how github is best used (it appears not to user friendly GUI for noobs like me).
If I may ask four more questions, Bill:
1. The thread you posted is clear. Except for the part about 'changeSID'. I have no clue what I am seeing, as in: it doesn't fit in my limited brain; either you have enabled SID's, or you have disabled them. Why the third list?
2. Do you have thoughts on keeping separate SID-lists for Snort and Suricata? Or 'one list fits all'? (Does it? I don't know).
3. Do you have thoughts on the lists having exclusive SID's (-> if a SID is on list 1 it shouldn't be on list two, and vice versa), or are there good reasons to do things differently?
4. How can one manage the part of new SID's appearing after an update? Is there a 'new SID's added during update' list somewhere? Because these need to be processed into the github-list one way or the other I guess(?)One more time: thank you MasterBill ;D
-
@Hollander:
1. The thread you posted is clear. Except for the part about 'changeSID'. I have no clue what I am seeing, as in: it doesn't fit in my limited brain; either you have enabled SID's, or you have disabled them. Why the third list?
The modifysid option is for actually changing the text of the rule body. For example, you could change the "alert" keyword to "drop". This will have more meaning once a true IPS mode is implemented. Then, "alert" rules will simply print messages in the logs and on the ALERTS tab; but "drop" rules will be the ones that actually drop (or block) the offending traffic. Today on pfSense any "alert" causes a block, but on a true IPS that is not the case. Alerts are like notices and "drop" rules are the only ones that should block traffic. You might for example only want alerts for rules that identify older versions of Java or something, but you would want drops for rules that identify known malware phoning home.
As the Snort and Suricata packages exist today, the modifysid function is not really necessary yet.
@Hollander:
2. Do you have thoughts on keeping separate SID-lists for Snort and Suricata? Or 'one list fits all'? (Does it? I don't know).
This is an admin decision. Just remember that there are many, many Snort rules that contain keywords or rule options that Suricata does not recognize. No sense even trying to load those rules on Suricata.
@Hollander:
3. Do you have thoughts on the lists having exclusive SID's (-> if a SID is on list 1 it shouldn't be on list two, and vice versa), or are there good reasons to do things differently?
If you are using only literal SIDs in the files, then it does not make sense to put the same SID in both files. However, when you use the more advanced PCRE options; it is conceivable to match the same SID. In those situations, the setting of the SID STATE ORDER control becomes important.
@Hollander:
4. How can one manage the part of new SID's appearing after an update? Is there a 'new SID's added during update' list somewhere? Because these need to be processed into the github-list one way or the other I guess(?)
Each time the rules are updated the vendors post an updated Change Log on their web sites.
Bill
