Snort 2.9.5.5 pkg. v3.0.0 – Update Released



  • An update to Snort on pfSense is now available.  This release updates the Snort binary to version 2.9.5.5.  The GUI package is updated to 3.0.0.  This package version contains significant improvements to the Preprocessor configurations for frag3, stream5, http_inspect, ftp_server and ftp_client.  See release notes below for details.

    IMPORTANT INSTALL NOTE FOR 2.0.x USERS ONLY:
    If you are still using 2.0.3 pfSense, you must install this Snort update by first removing the Snort package and then reinstalling it.  DO NOT simply click the XML or PKG icons in the Packages window.  This Snort package update contains a new version of the Snort binary, and the only way to reliably update some internal libraries is via a complete remove and reinstall.  First, go to the Global Settings tab in your old Snort and scroll to the bottom of the page and verify the "Keep settings on de-install" checkbox is checked.  This will preserve your existing Snort configuration.

    Now go to the System…Packages menu and click the X icon next to Snort on the Installed Packages tab.  When the old package is removed, go back to the Available Packages tab and then select and install Snort again.

    –--------------------------------------------------------

    New Features:

    1. Several of the preprocessors now support multi-engine configurations in the GUI. This allows customized preprocessor settings based on target hosts or networks. The frag3, http_inspect, stream5, ftp_client and ftp_server preprocessors can now be configured with multiple targets based on specified hosts or networks. The new functionality is accessed via the PREPROCESSORS tab for a Snort interface. Each multi-engine preprocessor provides a global configuration section for setting parameters that impact all instances of the preprocessor. The individual target-based parameters are then configured on a per-engine basis. The engine targets are pre-defined host or network Aliases. Controls are provided on the multi-engine configuration GUI to allow selection and import of existing Aliases into a new target-based instance of the preprocessor.

    2. Additional configuration parameters have been added for the frag3, stream5, http_inspect, ftp_client and ftp_server preprocessors along with the sensitive data preprocessor.

    3. Instead of becoming grayed-out when not available, certain form controls are now hidden completely to reduce screen clutter. When enabled and required, these form controls will become visible.

    4. The underlying Snort binary is updated to the latest 2.9.5.5 version. See http://www.snort.org for change log information for the 2.9.5.5 binary.

    5. The Sensitive Data Preprocessor configuration now allows the selection of which types of sensitive data to alert on. A multi-select drop-down list allows selection of U.S. Social Security Numbers, Credit Card Numbers, U.S. Telephone numbers or E-Mail Addresses.  Thanks to Forum contributor marcelloc for this improvement!

    NOTE: this version requires significant changes in the internal structure of the Snort package configuration section within the pfSense config.xml file. For this reason, once upgraded to the 3.0.0 Snort package, the new config.xml is not backwards compatible with older Snort package versions. Be aware of this if you restore an older version of the config.xml file on pfSense. Doing so will require either downgrading Snort to match the older package version, or deleting all the configured Snort interfaces and recreating them. During installation of the 3.0.0 package, existing Snort settings will be automatically migrated to the new format.

    Snort Sync Users: if you are currently using the experimental Snort Sync feature, there are some upgrade details to consider. First, disable Snort Sync on the master firewall and upgrade it first. Then upgrade all the slave Snort Sync targets to the same Snort package version as the master. Once all hosts have been upgraded, you can safely re-enable Snort Sync again. During the package upgrade, Snort Sync will automatically be disabled as a precaution on any firewall where it is enabled.


  • Banned

    AWESOME Bill!

    Great work!



  • @Supermule:

    AWESOME Bill!

    Great work!

    Thanks!  I took the plunge and updated my own home network production firewall this morning.  The update installed with no issues.  I am using the 64-bit 2.1-RELEASE version of pfSense.

    The big changes in this new version are on the Preprocessors tab for an interface.  There you can now define individual preprocessor parameter settings for specific IP networks or hosts for several of the preprocessors.  No longer do you just have to settle for defaults for all protected hosts.  Now you can customize some of the settings depending on the characteristics of the protected host.

    Some screenshots of the new feature are attached below.  Multiple frag3 targets have been defined.  For each target you can customize the parameter settings.  For example, notice in the screenshots how the Web Farm IP target Alias has been customized for Linux as the OS.  The other frag3 engine targets can have their own unique operating system choices, for example.  The attached screen capture is an older image prior to the inclusion of the Alias import button.  Clicking the "e" icon brings up the Edit Details page for the selected frag3 engine preprocessor.  On that page you can set the customizable parameters for that instance of the frag3 engine.

    Bill






  • Attached is a screen capture of the new HTTP_Inspect multi-engine section on the Preprocessors tab.  This one shows the new Alias import button (the Up-Arrow icon next to the Plus icon).  Clicking this takes you to a page listing all the Aliases available for use at HTTP_Inspect engine targets.  All of the icons have pop-up tooltips to describe their function.  Just hover over the icon a moment and the tooltip text will appear that describes the control's function.

    As with the Frag3 engine described above, clicking the "e" icon brings up a details edit page for the selected HTTP_Inspect engine target.  There you can specify settings such as the type of web server software (e.g., Apache, IIS, etc.) along with various other parameters.

    Bill

    ![Multiple HTTP_INSPECT server configs.png](/public/imported_attachments/1/Multiple HTTP_INSPECT server configs.png)
    ![Multiple HTTP_INSPECT server configs.png_thumb](/public/imported_attachments/1/Multiple HTTP_INSPECT server configs.png_thumb)


  • Banned

    Can you explain WHAT the preproc. are doing exactly?

    Just so people understand why they are there and what they do?



  • @Supermule:

    Can you explain WHAT the preproc. are doing exactly?

    Just so people understand why they are there and what they do?

    It's kind of hard to explain in a short paragraph.  Essentially they pre-condition the captured packet stream to make it easier for the signature detection algorithms to do their work.  For example, the Frag3 engine handles defragmenting packets and assembling them back into their full size.  Because different operating systems can interpret fragmented packets in different ways, you now have the option of customizing the frag3 reassembly of packets based on the operating system of the hosts Snort is protecting.  Another useful preprocessor is the Stream5 engine.  It reassembles TCP streams and keeps track of a complete conversation.  Together, the Frag3 and Stream5 preprocessors ensure that a bad actor can't evade the signature detection engine by spreading the pieces of bad data across several packets or fragments.  You see, at its heart, the Snort detection engine is just looking for a particular sequence of bits.  Without something up front to make sure packets are reassembled into a coherent "message" before sending them to the detection engine, it would be easy to evade the signature detection by just fragmenting the packets and otherwise breaking the "message" up into bits and pieces.  Snort would then only see short pieces of the bad data sequence, but never the entire signature at once.  Thus it would not alert.  On the other hand, the target host's operating system network stack would happily reassemble the fragments and pieces and then be vulnerable to the attack.  This is a bit oversimplified, but hopefully you get the general idea.

    Similarly, the HTTP_Inspect preprocessor performs customized normalization on data coming and going from web servers and clients based on, for example, whether the target server is running Apache or Microsoft IIS.  Being able to finely tune the preprocessor according to the hosts behind Snort is important to reducing false positives and at the same time catching all the bad stuff.

    Here is a link to the Snort Manual with more information on the preprocessors – http://manual.snort.org/node17.html

    Bill


  • Banned

    Getting this when trying to start Snort on 2.0.3

    nort[26427]: FATAL ERROR: The dynamic detection library "/usr/local/lib/snort/dynamicrules/web-misc.so" version 1.0 compiled with dynamic engine library version 1.17 isn't compatible with the current dynamic engine library "/usr/local/lib/snort/dynamicengine/libsf_engine.so" version 2.1.
    Dec 11 16:40:00 snort[26427]: FATAL ERROR: The dynamic detection library "/usr/local/lib/snort/dynamicrules/web-misc.so" version 1.0 compiled with dynamic engine library version 1.17 isn't compatible with the current dynamic engine library "/usr/local/lib/snort/dynamicengine/libsf_engine.so" version 2.1.



  • @Supermule:

    Getting this when trying to start Snort on 2.0.3

    nort[26427]: FATAL ERROR: The dynamic detection library "/usr/local/lib/snort/dynamicrules/web-misc.so" version 1.0 compiled with dynamic engine library version 1.17 isn't compatible with the current dynamic engine library "/usr/local/lib/snort/dynamicengine/libsf_engine.so" version 2.1.
    Dec 11 16:40:00 snort[26427]: FATAL ERROR: The dynamic detection library "/usr/local/lib/snort/dynamicrules/web-misc.so" version 1.0 compiled with dynamic engine library version 1.17 isn't compatible with the current dynamic engine library "/usr/local/lib/snort/dynamicengine/libsf_engine.so" version 2.1.

    OK, on 2.0.3 you will need to do the whole "remove with "X" icon and then reinstall" procedure.  As a further precaution, you can manually delete the entire snort directory under /usr/local/lib before reinstalling.  The 2.1 releases with PBI don't have this issue.

    Bill


  • Banned

    :D Thanks man!



  • @Supermule:

    :D Thanks man!

    Doing the complete remove and reinstall should fix it.  The problem is caused by the Snort shared-object rules.  The Snort VRT tags them with a "version", and so the new ones are tagged with 2.9.5.5 instead of 2.9.4.6.  With the old package management system in 2.0.3 of pfSense, I am a bit handicapped with a Snort update because the Package Manager code does not actually discriminate between a GUI reinstall and a package reinstall.  You have separate icons for each task (the XML and PKG icons), but they actually both call the same piece of code that just copies down the GUI files. They don't physically remove the binaries and reinstall those.  Only the "X" package remove icon does that.

    Because of this limitation in 2.0.3, the un-install code in my Snort package can't delete this directory safely.  This is because it has no way of knowing if the user clicked the XML icon or the PKG icon.  If the directory is removed when only the GUI components are being reinstalled, then Snort is broken badly.  The directory can only be safely removed when the Snort binary is being removed and reinstalled.

    I updated the original post at the top of this thread to warn others on 2.0.x of pfSense to perform a remove first, then an install, of Snort.  Users on 2.1 of pfSense can simply click the PKG icon to update Snort.  The new PBI process in 2.1 takes care of the remove and install automatically.

    Bill



  • Just updated Snort to the new version on a pfSense 2.1 32-bit system. Worked without any issues!

    Thanks Bill! ;D



  • @digdug3:

    Just updated Snort to the new version on a pfSense 2.1 32-bit system. Worked without any issues!

    Thanks Bill! ;D

    Good to hear and thanks for the positive feedback.  Things definitely work much smoother with package upgrades on the new PBI platform of pfSense 2.1.  All the 2.0.x holdouts need to give it up and just upgrade to 2.1… ;D

    Bill



  • Thanks.
    2.1 x64, no problem.


  • Banned

    Will do when it works :D

    @bmeeks:

    @digdug3:

    Just updated Snort to the new version on a pfSense 2.1 32-bit system. Worked without any issues!

    Thanks Bill! ;D

    Good to hear and thanks for the positive feedback.  Things definitely work much smoother with package upgrades on the new PBI platform of pfSense 2.1.  All the 2.0.x holdouts need to give it up and just upgrade to 2.1… ;D

    Bill



  • Been looking forward to this.  In the wan Preprocessor tab under the frag3 engine configuration.  I add a new engine and click the aliases button and choose one from the list but it doesn't seem to save the selection. If i type in the alias it does save.  Can you do a quick check to make sure its just not me :)



  • Bill,
    Earlier you noted there were some issues with Snort that were dependent on a pfSense core update.  Are any of those issues being covered by this update or are we still waiting for the pfSense update?

    Thank,
    Rick



  • @shinzo:

    Been looking forward to this.  In the wan Preprocessor tab under the frag3 engine configuration.  I add a new engine and click the aliases button and choose one from the list but it doesn't seem to save the selection. If i type in the alias it does save.  Can you do a quick check to make sure its just not me :)

    I just did this on my production firewall this morning and had no issues.  I clicked the Up Arrow icon to add an Alias as a new Frag3 target.  Select an Alias and then click SAVE.  You should return to the Preprocessors tab.  Now click the "e" icon to open the Frag3 Engine Details window where you can choose other parameters.  Click SAVE at the bottom of that window when finished, then finally click SAVE at the bottom of the Preprocessors window.

    Did you use the Up Arrow icon from the Preprocessors tab, or did you click the + (plus) icon to add a new engine from scratch?
    Update: I just tried it both ways and it worked each way (that is, using the Up Arrow icon to add an Alias entry, or using the + icon to create a new blank engine and choosing an Alias using the Aliases button on the details edit screen).

    Bill



  • @Ramosel:

    Bill,
    Earlier you noted there were some issues with Snort that were dependent on a pfSense core update.  Are any of those issues being covered by this update or are we still waiting for the pfSense update?

    Thank,
    Rick

    Still waiting on a pfSense update for that.  I believe you are talking about the premature clearing of the Snort block table upon a firewall filter_reload() process.  That is something totally outside the realm of the Snort package.

    Bill



  • Bill,
    Yep, that was it…  thanks for the quick reply!    :)

    I was just wondering, since this is such a comprehensive update, if you had "found something" since then that was a fix rather than depending on a core pfSense or 8.3 correction.

    Rick



  • @Ramosel:

    Bill,
    Yep, that was it…  thanks for the quick reply!    :)

    I was just wondering, since this is such a comprehensive update, if you had "found something" since then that was a fix rather than depending on a core pfSense or 8.3 correction.

    Rick

    No.  There appears to be a misconception among folks with the way Snort works on pfSense.  Snort itself does not "block" anything directly.  It analyzes copies of network packets, and when a packet matches a signature, Snort fires an "alert".  This "alert" is written to the log file and then passed to a FreeBSD packet filter utility which is asked to insert the offending packet's IP address into the firewall block table.  The packet filter engine of FreeBSD is the firewall.  The packet filter table used by Snort is called the "snort2c" table.  This table is totally managed by the packet filter engine of FreeBSD and not by Snort.  Snort does not clear the table.  All it can do is ask the packet filter engine to insert an offending IP.  Once it does that, Snort is done and no longer can interact with the block table.  Even the regular automatic clearing is actually done by a cron job that calls the pfctl utility of the packet filter.  That utility clears the packet filter tables.  You could insert your own IPs into that block table completely outside of Snort and they would still be blocked just as if Snort had placed them there.

    With the upgrade to pfSense 2.1 and the move the FreeBSD 8.3, something changed in the way the FreeBSD code handles the packet filter tables on something called a filter_reload() function call.  Now that call clears all the block tables of IP addresses – including Snort's.  Snort can't stop it from doing that.  A number of internal events (not Snort related events) can trigger that filter_reload() function.  When it is triggered, the block table is cleared.  No change in the Snort code can fix this.

    As has been posted in a number of threads, the premature clearing of the block table is not a problem.  This does not mean Snort never blocks again.  Folks give me the impression with all the questions about this that they think if the block table is cleared, Snort never blocks anything else.  That is not the case.  On the next offending packet from a host, the host's IP will be inserted into the block table and it will get blocked again.  I think folks panic because they look at the Block tab and don't see tons of IP addresses listed.  The premature clearing is a nuisance, but not a showstopper.

    Snort never knows the block table has been cleared, so there is no way for it to "re-populate it" as some folks have suggested.  Besides, why should Snort waste time figuring out what is missing and what should be put back into that table?

    Bill



  • I used the plus arrow then hit the alias tab.  When i select the alias, it refreshes the page but it doesnt take me out of the alias window.  Its not a big deal anyway , could just be my browser :)

    @bmeeks:

    @shinzo:

    Been looking forward to this.  In the wan Preprocessor tab under the frag3 engine configuration.  I add a new engine and click the aliases button and choose one from the list but it doesn't seem to save the selection. If i type in the alias it does save.  Can you do a quick check to make sure its just not me :)

    I just did this on my production firewall this morning and had no issues.  I clicked the Up Arrow icon to add an Alias as a new Frag3 target.  Select an Alias and then click SAVE.  You should return to the Preprocessors tab.  Now click the "e" icon to open the Frag3 Engine Details window where you can choose other parameters.  Click SAVE at the bottom of that window when finished, then finally click SAVE at the bottom of the Preprocessors window.

    Did you use the Up Arrow icon from the Preprocessors tab, or did you click the + (plus) icon to add a new engine from scratch?
    Update: I just tried it both ways and it worked each way (that is, using the Up Arrow icon to add an Alias entry, or using the + icon to create a new blank engine and choosing an Alias using the Aliases button on the details edit screen).

    Bill


  • Moderator

    I have updated one of my 2.1 Release (x64) to the new Snort 2.9.5.5  pkg v.3.0.0 routers today.

    No issues with the installation. No missing data from my previous install.  Everything seems to be functioning 100%

    Thanks Bill and all the SNORT team for their efforts.

    ps - a GUI snort disablesid.conf editor would be nice. Esp. when you want to update several different pfSense boxes.



  • @shinzo:

    I used the plus arrow then hit the alias tab.  When i select the alias, it refreshes the page but it doesnt take me out of the alias window.  Its not a big deal anyway , could just be my browser :)

    Updated Reply:  After thinking about this some more after posting the initial response below, I suspect it is a browser issue with the new session variable code in the Alias import page.  I tried to get fancy there using session variables to save the calling page (that is, the page where the imported Alias will be returned to), but I may have gotten too fancy and created something that is not 100% browser agnostic.  Tell me the Browser type and version you are using and I will see if I can reproduce and then find a fix.

    Initial Reply:
    Yeah, it might be something with the browser.  I used IE10 and IE11 for most of my testing, but did install Chrome and Firefox in a couple of VMs for some testing in the past.  I don't recall offhand if I tested the new Alias import with Chrome or Firefox, though.  What browser are you using?

    Bill



  • @BBcan17:

    I have updated one of my 2.1 Release (x64) to the new Snort 2.9.5.5  pkg v.3.0.0 routers today.

    No issues with the installation. No missing data from my previous install.  Everything seems to be functioning 100%

    Thanks Bill and all the SNORT team for their efforts.

    ps - a GUI snort disablesid.conf editor would be nice. Esp. when you want to update several different pfSense boxes.

    Thank you for the positive feedback, and that is a good idea.  Supermule also suggested some time back a sort of "template" system for Snort where you could create a set of configuration templates and then assign one to a specific pfSense box or group of boxes.  The template would have all the settings preset.  I have that idea in my list of future enhancements.  I could probably incorporate your disablesid.conf idea into the same template design.  I'm thinking maybe this would be an add-on package for Snort much like the Snort Dashboard Widget is today.

    Bill



  • I am using the latest firefox version 26.  But its not a big deal since i can make it work the other way.  I did check with internet explorer and it does work correctly.

    And thanks again for all the work that you put into adding separate engines.  Its much easier and cleaner then how i was adding them manually.  :)



  • Smooth transition.  I'm amazed at how much this package has progressed in such a short time.  Great job Bill.



  • @shinzo:

    I am using the latest firefox version 26.  But its not a big deal since i can make it work the other way.  I did check with internet explorer and it does work correctly.

    And thanks again for all the work that you put into adding separate engines.  Its much easier and cleaner then how i was adding them manually.  :)

    I will see if I can fix it for Firefox.  There are some other potential issues with the way I did the session state according to Ermal, so I will research a better way to accomplish the goal.  I will also be sure the final result works in IE, Firefox and Chrome.

    Glad you can use the multi-engine feature.  That was a GUI feature I had been thinking about adding for quite some time.

    Bill



  • @AhnHEL:

    Smooth transition.  I'm amazed at how much this package has progressed in such a short time.  Great job Bill.

    Thank you.  Glad to help out the community.

    I am working on my next pfSense package.  I have a very early Beta of Suricata working in IDS mode at the moment.  The goal is to get it working in IPS mode and offer it as an alternative to Snort.  The key difference is Snort works off copies of packets from libpcap.  It analyzes the packet copy and then makes a block decision.  In the meantime, the original packet has passed on through the network stack to the original target.  If Snort decides to block, it then essentially blocks only subsequent packets.  Suricata, when run in IPS mode, can insert itself directly into the firewall packet processing chain.  That way it can analyze and block the initial packet along with subsequent packets.  It can run in true in-line mode (I hope I can get it working on pfSense).  I will try the IPS mode soon in my lab.

    Bill


  • Banned

    DAMN NICE!



  • Just tried updating Snort on pfsense 2.1 and receive the following error:
    snort[82423]: FATAL ERROR: SDF preprocessor config option "alert_threshold" requires an argument.

    I tried removing and reinstalling and still get the same error message. The older version of snort was working.  What is causing this, do I need to configure something somewhere else.



  • @jdeloach:

    Just tried updating Snort on pfsense 2.1 and receive the following error:
    snort[82423]: FATAL ERROR: SDF preprocessor config option "alert_threshold" requires an argument.

    I tried removing and reinstalling and still get the same error message. The older version of snort was working.  What is causing this, do I need to configure something somewhere else.

    I forgot to set a default value for this new parameter when the user had an existing Sensitive Data configuration that was imported.  This is a newly added configuration parameter for SDF (the Sensitive Data preprocessor).  I will post a fix in the next package update.  Give me a few days to collect up the bug reports, and then I will post an update with the fixes.

    In the meantime, go to the Preprocessors tab for the interface in Snort and be sure a value is set in the box as shown in the attached screenshot.  Also be sure to click on all the types of SDF you want to inspect for in the Inspect For drop-down. To select more than one entry, hold down CTRL while clicking.  Click SAVE at the bottom of the page to create a new snort.conf file.  Snort should start after that.  Let me know if that does not work for you.  I tested it this morning in my lab and it worked.

    Bill




  • @AhnHEL:

    Smooth transition.  I'm amazed at how much this package has progressed in such a short time.  Great job Bill.

    mee too.



  • @bmeeks:

    I am working on my next pfSense package.  I have a very early Beta of Suricata working in IDS mode at the moment.  The goal is to get it working in IPS mode and offer it as an alternative to Snort.  The key difference is Snort works off copies of packets from libpcap.  It analyzes the packet copy and then makes a block decision.  In the meantime, the original packet has passed on through the network stack to the original target.  If Snort decides to block, it then essentially blocks only subsequent packets.  Suricata, when run in IPS mode, can insert itself directly into the firewall packet processing chain.  That way it can analyze and block the initial packet along with subsequent packets.  It can run in true in-line mode (I hope I can get it working on pfSense).  I will try the IPS mode soon in my lab.

    Salivating at this, can't wait.  Since Sourcefire was bought out by Cisco, Snort as we know it might become a thing of the past in the not so distant future.  Staying one step ahead with a Suricata package is an awesome idea.



  • @shinzo:

    I am using the latest firefox version 26.  But its not a big deal since i can make it work the other way.  I did check with internet explorer and it does work correctly.

    And thanks again for all the work that you put into adding separate engines.  Its much easier and cleaner then how i was adding them manually.  :)

    shinzo:

    I tried to reproduce your problem in my VMware environment and could not.  I used Firefox 26 on a Windows XP SP3 virtual machine.  I connected to a pfSense 2.1-amd64 box with the latest Snort package.  I could both import Aliases into the Frag3 engine list, and I could create a new, empty engine and add an Alias from the button in the Details screen.  I tried it several times and could not get it to fail for me.

    I did a fresh install of Firefox on that VM just before the test.  Prior to the test, the VM only had Chrome and the native IE installed.  Does your Firefox have any extras installed that might interfere with JavaScript or other stuff?

    Bill



  • @AhnHEL:

    @bmeeks:

    I am working on my next pfSense package.  I have a very early Beta of Suricata working in IDS mode at the moment.  The goal is to get it working in IPS mode and offer it as an alternative to Snort.  The key difference is Snort works off copies of packets from libpcap.  It analyzes the packet copy and then makes a block decision.  In the meantime, the original packet has passed on through the network stack to the original target.  If Snort decides to block, it then essentially blocks only subsequent packets.  Suricata, when run in IPS mode, can insert itself directly into the firewall packet processing chain.  That way it can analyze and block the initial packet along with subsequent packets.  It can run in true in-line mode (I hope I can get it working on pfSense).  I will try the IPS mode soon in my lab.

    Salivating at this, can't wait.  Since Sourcefire was bought out by Cisco, Snort as we know it might become a thing of the past in the not so distant future.  Staying one step ahead with a Suricata package is an awesome idea.

    Yeah, Suricata is probably the best way forward for a true IPS since Snort inline was essentially killed in favor of supporting Suricata inline.  The $64,000 question is can I get Suricata inline IPS to work properly on pfSense.  Out of the box Suricata wants to use ipfw on FreeBSD, but the pfSense guys prefer to use pf instead.  Getting IPS mode to work with pf and Suricata might take some magic.  The IDS part is super easy.  I could rollout an IDS-only package within two weeks, but in my view there is really no good case for that on a firewall.  For a firewall, if you are going to install Intrusion Detection/Prevention, then it should be in Prevention mode.

    Bill



  • @bmeeks:

    Out of the box Suricata wants to use ipfw on FreeBSD, but the pfSense guys prefer to use pf instead.

    Well I know the Captive Portal feature of pfSense uses ipfw, so maybe the developers will allow it for Suricata as well if using pf becomes a "show stopper" for Suricata.


  • Moderator

    In Security Onion, the software can flip between Snort and Suricata with a simple change in a conf file. ENGINE=SNORT or ENGINE=SURICATA and restarting the NSM. Maybe the package should stay the same with just the engine changing behind the scene on pfSense.

    I don't know if one is better than the other. My Network speeds will never need PF_Ring or multi-process. I see a lot of False positives and I am always opening up the Ruleset to allow more traffic thru. With the latest patch Tueday, ET PRO sid:2002400, Sid 3:13802 detected windows updates as Malware.

    I have 6 routers that I need to maintain and Snort/pfSense in a PFCenter would help in my daily management. (Wishfull thinking)

    Having pfSense perform CINS, DROP, Scans, MSSQL, MYSQL IPS are obvious but almost all other alerts that I have seen are false positives. Unless Yahoo is full of malware.

    Since I have been running Full Packet Capture after pfSense with Security Onion, I can drill down on an alert and see if it was malicious. Using its others tools like ELSA you can perform a search for a particular IP and see where else it showed up on your network and also view the full packets that were involved.

    Another issue is knowing what is malicious and what is not. When an alert is triggered the information presented is limited in scope. A project like https://code.google.com/p/collective-intelligence-framework/
    "CIF allows you to combine known malicious threat information from many sources and use that information for identification (incident response), detection (IDS) and mitigation (null route)."

    I think having OSSEC installed on all Servers and sensitive Hardware can help detect Intrusions. It will perform log analysis, file integrity checking, policy monitoring, rootkit detection, real-time alerting and active response.

    I would be thrilled to see someone develop an OSSEC package in pfSense as any Active Response taken on a server could put a block at the pfSense Router level.

    A Quote from Doug Burks of Security Onion "A better solution would be to let your firewall be a firewall and leave the IDS functionality to Security Onion."
    This link to OSSEC developer/founder Daniel B. Cids Blog, I believe, says it all    http://dcid.me/notes/2013-jul-08

    My two cents …



  • @bmeeks:

    @shinzo:

    I am using the latest firefox version 26.  But its not a big deal since i can make it work the other way.  I did check with internet explorer and it does work correctly.

    And thanks again for all the work that you put into adding separate engines.  Its much easier and cleaner then how i was adding them manually.  :)

    shinzo:

    I tried to reproduce your problem in my VMware environment and could not.  I used Firefox 26 on a Windows XP SP3 virtual machine.  I connected to a pfSense 2.1-amd64 box with the latest Snort package.  I could both import Aliases into the Frag3 engine list, and I could create a new, empty engine and add an Alias from the button in the Details screen.  I tried it several times and could not get it to fail for me.

    I did a fresh install of Firefox on that VM just before the test.  Prior to the test, the VM only had Chrome and the native IE installed.  Does your Firefox have any extras installed that might interfere with JavaScript or other stuff?

    Bill

    So i created another firefox portable and gave it a shot and works fine.  So i have to go through the extensions to see which one is causing my issue.  Thanks for looking into it And you have my vote on Suricata



  • I've got this after updating two boxes.

    Is it a normal behavior?

    update log

    Starting rules update...  Time: 2013-12-13 00:03:01
    	Downloading Snort VRT md5 file 'snortrules-snapshot-2946.tar.gz.md5'...
    	Checking Snort VRT md5 file...
    	There is a new set of Snort VRT rules posted.
    	Downloading file 'snortrules-snapshot-2946.tar.gz'...
    	Done downloading rules file.
    	Downloading Snort GPLv2 Community Rules md5 file 'community-rules.tar.gz.md5'...
    	Checking Snort GPLv2 Community Rules md5.
    	There is a new set of Snort GPLv2 Community Rules posted.
    	Downloading file 'community-rules.tar.gz'...
    	Done downloading Snort GPLv2 Community Rules file.
    	Extracting and installing Snort GPLv2 Community Rules...
    	Installation of Snort GPLv2 Community Rules completed.
    	Downloading Emerging Threats Open md5 file 'emerging.rules.tar.gz.md5'...
    	Checking Emerging Threats Open md5.
    	There is a new set of Emerging Threats Open rules posted.
    	Downloading file 'emerging.rules.tar.gz'...
    	Done downloading Emerging Threats Open rules file.
    	Extracting and installing Emerging Threats Open rules...
    	Installation of Emerging Threats Open rules completed.
    	Extracting and installing Snort VRT rules...
    	Using Snort VRT precompiled SO rules for FreeBSD-8-1 ...
    	Installation of Snort VRT rules completed.
    	Copying new config and map files...
    	Updating rules configuration for: WAN ...
    	Restarting Snort to activate the new set of rules...
    	Snort has restarted with your new set of rules.
    The Rules update has finished.  Time: 2013-12-13 00:05:19
    
    Starting rules update...  Time: 2013-12-13 10:43:23
    	Extracting and installing Snort GPLv2 Community Rules...
    	Installation of Snort GPLv2 Community Rules completed.
    	Extracting and installing Emerging Threats Open rules...
    	Installation of Emerging Threats Open rules completed.
    	Copying new config and map files...
    	Updating rules configuration for: WAN ...
    The Rules update has finished.  Time: 2013-12-13 10:44:30
    

    But gui shows no vrt rules downloaded






  • bmeeks:
    Thanks for the update. Just skipped the whole "test in a non-production system" part and went straight to an actual production system update. Everything is working as expected. Disabled sync, then re-enabled after the update.
    I don't need to post my vote on suricata, since I went crazy over the past months on this :D. Another poster said that snort will soon be a thing of the past, and I strongly believe this. Suricata in IPS mode is the way forward IMNSHO.

    BBcan17:
    The windows updates were detected as malware because that's the early release of the new three letter agency backdoor. Ok not a backdoor, but malware to install a backdoor. It's needed for them to do their job. Let's see what's in the "Keeping You Scared" bag. Terrorists, kids, cyber. I'll go with terrorists this time. This should be taken as a joke. Or not. ;)
    Disclaimer: The paragraph above (never mind the indent) contains sarcasm. It should not be interpreted as stating actual facts. Microsoft (Inc) would never release backdoors to three letter agencies.
    Disclaimer:The disclaimer above contains sarcasm….etc...etc... ;)


Log in to reply