Snort 2.9.4.6 Pkg v 2.5.9



  • Snort 2.9.4.6

    Update the Snort pfSense port to version 2.9.4.6 because the current 2.9.4.1 version goes EOL with rules updates on July 2, 2013. This port update should be merged in concert with the Snort GUI package update 2.5.9 in the pfsense-packages repository.

    This update includes the config directives "–enable-targetbased" and "--enable-perfprofile". The target-based directive is required to support the new Host Attribute Table option being added to the 2.5.9 Snort GUI package.

    CHANGE LOG
    Snort Package v 2.5.9 Update
    june 18, 2013

    This update introduces one new feature and improves on several existing ones. It also supports the updating of the underlying Snort binary code to version 2.9.4.6.

    New Features

    Support has been added for a Host Attribute Table. This feature allows the run-time import of specific network host attributes to provide auto-configuration of various Preprocessor and rule options. Tools such as nmap and hogger can be used in concert to scan your network, fingerprint all the hosts, and generate a Host Attribute Table file suitable for direct input to Snort. Snort will then auto-configure Preprocessor and rule options to tailor them to your specific network hosts.
    Improved Features

    The automatic rule update start time is now configurable. Formerly, only the update interval was selectable. But now both the interval and starting time are configurable in the GUI. This change benefits users with multiple firewalls as it allows their updates to be staggered. The starting time must be entered in 24-hour form with hours and minutes only (as in HH:MM).

    Two new icon links were added the RULES tab that either Enable All or Disable All rules in the selected category. The table on the RULES tab is also sortable. Clicking the headers will sort the column. The sort will toggle between ascending and descending on each click. A bookmark anchor has been added to each displayed rule row so that when clicking to enable or disable a particular rule, the page will auto-scroll upon return so the last-clicked rule is near the top of the page.

    New icons have been added to the ALERTS tab in the SRC and DST IP address columns for displayed alerts. The plus (+) icon, when clicked, will auto-add the generator ID and signature ID (gid:sid) to the Suppression List for the interface using the "suppress gen_id, sig_id, track by_src ip …" or "suppress gen_id, sig_id, track by_src ip ..." form as applicable for source or destination addresses. As with the SID column icon, if the IP address is already in the Suppression List a disabled icon will be displayed instead. If the GID:SID by itself is in the Suppression List, then the event is suppressed globally and source or destination IP has no meaning. In this case, no plus (+) icon will be displayed under the SRC or DST columns.

    The XMLRPC Sync process has been improved by moving the sync job on the remote target host to a background task. This greatly speeds up the sync process when a master must replicate to multiple secondary hosts. The master no longer waits for the entire synchronization process to complete on each target. Instead, the job is deposited on the target host and then executes in the background. The master is then free to proceed to the next target host.

    Bug Fixes

    The Snort GUI code was run through a HTML validator and several HTML syntax errors were corrected on the various pages. These errors were not materially impacting performance nor functionality, but cleaning them up was a good thing nonetheless.

    A bug introduced in version 2.5.8 involving zero-length spaces was fixed in the SUPPRESS tab. When copying and pasting an IPv6 address from the ALERTS tab to a suppression list entry, the zero-length spaces used to signal word-break opportunities to the browser on the ALERTS tab were being copied into and then saved with the suppression list. This corrupted the list and produced a Snort error on restart. Now, prior to saving the list, the contents are scrubbed of any zero-length spaces.

    Screenshots and explanations have been added here.
    http://forum.pfsense.org/index.php/topic,63593.0.html

    UPDATE - JUNE 20th
    For those with a
    snort[****]: FATAL ERROR: /usr/local/etc/snort/snort_*_em0/snort.conf(253) Unknown config directive: max_attribute_hosts.
    It has been fixed, please uninstall then reinstall the snort package. For more details follow the link below.
    http://forum.pfsense.org/index.php/topic,63568.msg344067.html#msg344067



  • sorry i was awake  8).  Thanks for all the adds to the package.  Noticed that in the Home Net to inspect tab, I set up a custom whitelist so only the wan ip would be checked but its still adding the lan subnet.  In the Whitelist underneath External net, it does display correctly.



  • Thanks Bill,

    Great update again.
    I only have a small problem while updating pfSense firmware and this invokes also the Snort package update.
    Attached is a screen dump of the console of my VM because I couldn't grab the text. Both my main system and VM had this error.
    On my main system one of the sensors exited with code 11 after the firmware update. I deleted and reinstalled Snort (without the errors this time) and all is well now. I don't know if this had anything to do with the mentioned error.




  • I have no idea how or why, but after the update my Snort interface uses 4 GB memory when before update it used ~2.7 GB. I have the same rules selected and I only did some minor changes to preprocessor memory settings where I tuned down some from 1024 MB to 64 MB. Performance setting is AC-NQ as it was before. Good thing I have 8 GB total memory :D


  • Banned

    The new snort package blocks whitelisted WAN IP's and the 2.5.8 didnt.

    I had the 1st block just a couple of minutes ago.



  • @Supermule:

    The new snort package blocks whitelisted WAN IP's and the 2.5.8 didnt.

    I had the 1st block just a couple of minutes ago.

    Darn it!  Have not noticed that in my testing.  Is the "WAN IP" checkbox checked for the whitelist, and is the WAN interface set to use something besides the default whitelist?  Last check is to click the VIEW button next to the whitelist on the If Settings tab and see if the WAN IPs are included in it.  Post back with the results

    Bill



  • @gogol:

    Thanks Bill,

    Great update again.
    I only have a small problem while updating pfSense firmware and this invokes also the Snort package update.
    Attached is a screen dump of the console of my VM because I couldn't grab the text. Both my main system and VM had this error.
    On my main system one of the sensors exited with code 11 after the firmware update. I deleted and reinstalled Snort (without the errors this time) and all is well now. I don't know if this had anything to do with the mentioned error.

    Changing from one Snort binary to the next update is best done with a "deinstall" and then "reinstall" operation.  I've noticed that the pfSense Package Manager code seems to hold on to the older include file.  That's what the error indicates on your system.

    Bill



  • Important Snort Update Notice

    This package includes an update of the Snort binary to version 2.9.4.6.  It is highly recommended that you perform a "deinstall" and then "reinstall" operation to perform this update.

    If you have 2.1RC0 and are about to do a Snapshot update, I highly recommend you perform the Snort package deinstall/reinstall procedure first, let that complete, and only then perform any 2.1 Snapshot update.  The Snapshot updates reinstall packages as part of the process, and this can sometimes go badly when a major package update has been pushed.  Better to remove and reinstall the packages first, then all the Snapshot will be doing is reinstalling the same package version.  This is generally no problem.

    Bill


  • Banned

    Yes.






  • @fragged:

    I have no idea how or why, but after the update my Snort interface uses 4 GB memory when before update it used ~2.7 GB. I have the same rules selected and I only did some minor changes to preprocessor memory settings where I tuned down some from 1024 MB to 64 MB. Performance setting is AC-NQ as it was before. Good thing I have 8 GB total memory :D

    There is a new version of the underlying Snort binary (2.9.4.6 versus 2.9.4.1 previously).  That may have something to do with increased memory usage, but I don't know for sure.

    Bill


  • Banned

    Thats the way it has been done everytime.

    @bmeeks:

    Important Snort Update Notice

    This package includes an update of the Snort binary to version 2.9.4.6.  It is highly recommended that you perform a "deinstall" and then "reinstall" operation to perform this update.

    If you have 2.1RC0 and are about the do a Snapshot update, I highly recommend you perform the Snort package deinstall/reinstall procedure first, let that complete, and only then perform any 2.1 Snapshot update.

    Bill



  • @Supermule:

    Yes.

    Go to the Snort Interfaces tab, click the WAN interface, then the WAN If Settings tab.  Scroll down and click the VIEW button next to the whitelist selection.  Verify that the correct WAN IPs are (or are not) displayed in the pop-up window and post back.

    Bill



  • @Supermule:

    The new snort package blocks whitelisted WAN IP's and the 2.5.8 didnt.

    I had the 1st block just a couple of minutes ago.

    As far as I can see in your pictures (a few posts later) WAN IP is not blocked, but has the new + sign to add it to the suppress list. When  it is blocked it has also an X!


  • Banned

    They are there.

    @bmeeks:

    @Supermule:

    Yes.

    Go to the Snort Interfaces tab, click the WAN interface, then the WAN If Settings tab.  Scroll down and click the VIEW button next to the whitelist selection.  Verify that the correct WAN IPs are (or are not) displayed in the pop-up window and post back.

    Bill


  • Banned

    THANKS Gogol!!

    I am glad you are awake when I am not :D

    @gogol:

    @Supermule:

    The new snort package blocks whitelisted WAN IP's and the 2.5.8 didnt.

    I had the 1st block just a couple of minutes ago.

    As far as I can see in your pictures (a few posts later) WAN IP is not blocked, but has the new + sign to add it to the suppress list. When  it is blocked it has also an X!



  • @shinzo:

    sorry i was awake  8).  Thanks for all the adds to the package.  Noticed that in the Home Net to inspect tab, I set up a custom whitelist so only the wan ip would be checked but its still adding the lan subnet.  In the Whitelist underneath External net, it does display correctly.

    Yes, this was by design.  HOME_NET defines the networks to protect, so it should include locally attached subnets.  The general premise in Snort is anything not in HOME_NET is a potential bad guy.  Are you doing something unique that needs local nets excluded from HOME_NET?

    Bill



  • @Supermule:

    THANKS Gogol!!

    I am glad you are awake when I am not :D

    @gogol:

    @Supermule:

    The new snort package blocks whitelisted WAN IP's and the 2.5.8 didnt.

    I had the 1st block just a couple of minutes ago.

    As far as I can see in your pictures (a few posts later) WAN IP is not blocked, but has the new + sign to add it to the suppress list. When  it is blocked it has also an X!

    I missed the fact as well that it was the ALERTS tab you were showing. You will get displayed alerts for whitelisted IPs, but no blocks.  The whitelist prevents blocks on alerts, but does not suppress the alerts themselves.

    Bill


  • Banned

    Thanks Bill! Another fantastic job from you!



  • @bmeeks:

    @shinzo:

    sorry i was awake  8).  Thanks for all the adds to the package.  Noticed that in the Home Net to inspect tab, I set up a custom whitelist so only the wan ip would be checked but its still adding the lan subnet.  In the Whitelist underneath External net, it does display correctly.

    Yes, this was by design.  HOME_NET defines the networks to protect, so it should include locally attached subnets.  The general premise in Snort is anything not in HOME_NET is a potential bad guy.  Are you doing something unique that needs local nets excluded from HOME_NET?

    Bill

    Nope nothing special, Just making sure its not a bug or anything.  
    I was only asking because of the WAN Variables.  What ever i don't have running i try to set to the WAN ip so it doesn't it doesn't do the entire network(to try to increase performance).  When the home_net didn't add the local network i could just leave all the variables blank, but i will just create an alias and define the servers manually.

    Thanks again



  • So i have been playing with the Host Attribute Table but cant seem to get it running correctly.  I looked at a few examples but i keep getting
    snort[****]: FATAL ERROR: /usr/local/etc/snort/snort_*_em0/snort.conf(253) Unknown config directive: max_attribute_hosts.

    Can anyone provide a example to put in the Host Attribute data with just one host



  • @shinzo:

    So i have been playing with the Host Attribute Table but cant seem to get it running correctly.  I looked at a few examples but i keep getting
    snort[****]: FATAL ERROR: /usr/local/etc/snort/snort_*_em0/snort.conf(253) Unknown config directive: max_attribute_hosts.

    Can anyone provide a example to put in the Host Attribute data with just one host

    I had this running in my VMware setup using a sample table Joel Esler posted in an article from several months back.  Let me run a quick check and make sure something is not fat-fingered in my code.  Your error indicates the feature is not being recognized by the binary, or there is syntax error in the snort.conf file.

    UPDATE:  It works in my VMware setup using the sample file attached to this post.  Are you positive that your Snort binary got updated?  Check by getting to the command line on the firewall and running this command:

    /usr/local/bin/snort -V
    

    This will print the version of the Snort binary.  It should say 2.9.4.6.  Also, there will be some lines down near the bottom of the snort.conf file for the interface that should look like these (although your path will be different for a 2.0.3 box):

    # Host Attribute Table #
    attribute_table filename /usr/pbi/snort-i386/etc/snort/snort_64703_em0/host_attributes
    config max_attribute_hosts: 10000
    config max_attribute_services_per_host: 10
    
    

    Bill

    HostAttributeTableSetup.txt



  • I imported the file and it was a no go, i changed the ip to the subnet i was on and nothing also.

    The version is correct.  The path is /usr/local/etc/snort/snort_59927_em0/host_attributes which is correct also



  • @shinzo:

    I imported the file and it was a no go, i changed the ip to the subnet i was on and nothing also.

    The version is correct.  The path is /usr/local/etc/snort/snort_59927_em0/host_attributes which is correct also

    Do you have a section in snort.conf that is like the example I posted?  The path to the Host Attribute file will be different for you since you have 2.0.3 and I posted a test from 2.1.  Your error really points to a syntax error in the snort.conf file.  Make sure the numbers actually contain only numeric characters (no extra spaces, for example).  I didn't put any validation code around the inputs, so if a non-numeric character sneaks in that could trip up Snort as it parses the configuration.

    Here is another test you can do to help pinpoint the problem.  Run this sequence of commands.  This will validate the snort.conf file and print out the line where an error is encountered.

    cd /usr/local/etc/snort/snort_59927_em0
    /usr/local/bin/snort -T -c ./snort.conf
    


  • When i run the command, it says
    ERROR: ./snort.conf(253) Unknown config directive: max_attribute_hosts.
    Fatal Error, Quitting..

    In the snort.conf file, its like the example you provied except for the path which is as stated before.  I lowered the max_attribute_hosts number from 10,000 to 10 and made sure there was no spaces or anything and still the same

    the 3 lines are
    attribute_table filename /usr/local/etc/snort/snort_59927_em0/host_attributes
    config max_attribute_hosts: 10
    config max_attribute_services_per_host: 10

    If i cat the host_attributes file it display the same as in the text file.  If i VI into it, it has  ^M at the end of every line except for the last



  • @shinzo:

    When i run the command, it says
    ERROR: ./snort.conf(253) Unknown config directive: max_attribute_hosts.
    Fatal Error, Quitting..

    In the snort.conf file, its like the example you provied except for the path which is as stated before.  I lowered the max_attribute_hosts number from 10,000 to 10 and made sure there was no spaces or anything and still the same

    OK. I've seen similar behavior before with another different directive in snort.conf. It may be choking not on the "max_attribute_hosts" value, but instead on the preceding line.  Open the snort.conf in the vi editor and be sure nothing weird exists on the end of any of the lines in the Host Attribute Table section.  Be sure the filename is correct and contains nothing padded onto the end.  Save the file from the vi editor.

    Now restart Snort using the command line shell script.  Doing it this way will not rebuild the conf file.  Doing anything from the GUI will rebuild the conf file, and if that is how an error is getting in, it will come back.  Here is how to stop/start with the shell script:

    /usr/local/etc/rc.d/snort.sh start
    

    I'm using just "start", because with the error Snort is not starting.  You can substitute "stop" or "restart" at other times.

    Bill



  • @shinzo:

    the 3 lines are
    attribute_table filename /usr/local/etc/snort/snort_59927_em0/host_attributes
    config max_attribute_hosts: 10
    config max_attribute_services_per_host: 10

    If i cat the host_attributes file it display the same as in the text file.  If i VI into it, it has  ^M at the end of every line except for the last

    The ^M characters are just DOS line endings (CR/LF) instead of UNIX (LF).  They are in my file and don't seem to confuse Snort.

    Bill



  • @shinzo:

    the 3 lines are
    attribute_table filename /usr/local/etc/snort/snort_59927_em0/host_attributes
    config max_attribute_hosts: 10
    config max_attribute_services_per_host: 10

    If i cat the host_attributes file it display the same as in the text file.  If i VI into it, it has  ^M at the end of every line except for the last

    If you don't get to the bottom of this, send me your snort.conf file if you don't mind.  I will PM you with my e-mail address.  It's getting close to my bedtime here, so I'm logging out for tonight.  Us old farts have to get our rest.. :D  Will check back in tomorrow.

    Bill



  • Yeah i tried it again and no go, i dont mind sending you the file



  • yeah i couldn't get it to work.  I did what i was going to do another way.  I added this to the Advanced configuration pass-through. This is pretty much a baseline for now

    preprocessor frag3_engine: policy bsd bind_to 192.168.1.1 detect_anomalies timeout 60 overlap_limit 0 min_fragment_length 0
    preprocessor frag3_engine: policy first bind_to 192.168.1.3 detect_anomalies timeout 60 overlap_limit 0 min_fragment_length 0
    preprocessor frag3_engine: policy first bind_to 192.168.1.0/24 detect_anomalies timeout 60 overlap_limit 0 min_fragment_length 0
    preprocessor stream5_tcp: policy bsd, bind_to 192.168.1.1, overlap_limit 0, timeout 30, ports both all, max_queued_bytes 1048576, max_queued_segs 2621
    preprocessor stream5_tcp: policy windows, bind_to 192.168.1.3, overlap_limit 0, timeout 30, ports both all, max_queued_bytes 1048576, max_queued_segs 2621
    preprocessor stream5_tcp: policy vista, bind_to 192.168.1.0/24, overlap_limit 0, timeout 30, ports both all, max_queued_bytes 1048576, max_queued_segs 2621

    It works fine, as long as frag3 and stream5 have a default policy which they already do, i am able to bind specific ranges to other policies.



  • @shinzo:

    yeah i couldn't get it to work.  I did what i was going to do another way.  I added this to the Advanced configuration pass-through. This is pretty much a baseline for now

    preprocessor frag3_engine: policy bsd bind_to 192.168.1.1 detect_anomalies timeout 60 overlap_limit 0 min_fragment_length 0
    preprocessor frag3_engine: policy first bind_to 192.168.1.3 detect_anomalies timeout 60 overlap_limit 0 min_fragment_length 0
    preprocessor frag3_engine: policy first bind_to 192.168.1.0/24 detect_anomalies timeout 60 overlap_limit 0 min_fragment_length 0
    preprocessor stream5_tcp: policy bsd, bind_to 192.168.1.1, overlap_limit 0, timeout 30, ports both all, max_queued_bytes 1048576, max_queued_segs 2621
    preprocessor stream5_tcp: policy windows, bind_to 192.168.1.3, overlap_limit 0, timeout 30, ports both all, max_queued_bytes 1048576, max_queued_segs 2621
    preprocessor stream5_tcp: policy vista, bind_to 192.168.1.0/24, overlap_limit 0, timeout 30, ports both all, max_queued_bytes 1048576, max_queued_segs 2621

    It works fine, as long as frag3 and stream5 have a default policy which they already do, i am able to bind specific ranges to other policies.

    This level of "multi-engine configurations" is coming in the next release.  Now that the Snort binary is up to the latest version and we will have Snort VRT rules updates for a while, I can concentrate some time on getting the multi-engine configuration incorporated.  Once done, you will be able to do things like this via the GUI.  There will be a "default" or "global" section for each preprocessor, and then a table underneath where you can add additional rows that represent unique "engines" running under that preprocessor.  I'm still working out in my head exactly how to structure it.

    The Host Attribute Table feature can accomplish the same thing, but obviously needs third-party tools to generate the data.

    I will troubleshoot why the Host Attribute Table is not working for you.  One thing I need to validate is that the 2.0.x TBZ package file actually got compiled with "–enabled-targetbased" as an option.  The Snort GUI is identical on 2.0.x and 2.1 pfSense, but the binaries are compiled on different servers.  It could be that the new config directive for Target-Based support did not get switched on in the 2.0.x compile.  I did my test yesterday on a 2.1 virtual machine.  My 2.0.x VM also worked, but it was loaded with the binary compiled by my own test pfSense package builder.  I need to download the 2.0.x package from pfSense and make sure it works as well.

    Bill



  • Hi i'm using this version: pfsense 2.1-RC0 (amd64) built on Wed Jun 19 07:03:30 EDT 2013 FreeBSD 8.3-RELEASE-p8 and i have many problems here:
    1- stop/start button dont work, snort is always running independent I deactivate it or not by gui
    2- suppression rules made ​​through the web interface, still being shown on  alerts tab

    This is a bug ?



  • @shinzo:

    So i have been playing with the Host Attribute Table but cant seem to get it running correctly.  I looked at a few examples but i keep getting
    snort[****]: FATAL ERROR: /usr/local/etc/snort/snort_*_em0/snort.conf(253) Unknown config directive: max_attribute_hosts.

    I think I've found the cause of this error.  It looks like the new Snort 2.9.4.6 binaries did not get compiled on the Package Builders with the required –enable-targetbased option enabled to support the Host Attribute Table.  I have sent a note to the pfSense Core Team asking them to look into this.  I can reliably reproduce the error when I use the Snort 2.9.4.6 binary package installed from the pfSense Package Repository.  But when I used my private Package Repository where I compiled Snort with the targetbased option enabled, the Host Attribute Table works fine.

    Hopefully a quick recompile on the package builders will suffice to fix this error.  I will post back when I have confirmation this is fixed.  Until, then, do not enable the Host Attribute Table on the Preprocessors tab.

    UPDATE:   This issue should now be fixed.  See this post for details:

    http://forum.pfsense.org/index.php/topic,63568.msg344067.html#msg344067

    Bill



  • @giorgiolago:

    Hi i'm using this version: pfsense 2.1-RC0 (amd64) built on Wed Jun 19 07:03:30 EDT 2013 FreeBSD 8.3-RELEASE-p8 and i have many problems here:
    1- stop/start button dont work, snort is always running independent I deactivate it or not by gui
    2- suppression rules made ​​through the web interface, still being shown on  alerts tab

    This is a bug ?

    Item #1: are you giving Snort enough time to start or stop?  Depending on how many rules you have active and how powerful your hardware is, it can take several seconds for Snort to change state and the icons adjust accordingly.  A green icon means the Snort process is running, and a red icon means it is stopped.  This is reversed from the old icons in packages older than 2.5.8.  Snort will auto-start upon a firewall reboot.  That is by design.

    Item #2: Can you be more specific with your comment?  Do you mean new events are still logged?  The Alerts tab is just a dump of the most recent log file entries, so adding an alert to the Suppression List will prevent new alerts from coming in for that GID:SID, but any entries that existed prior to when the Suppression List was edited will still show up in the window depending on how many entries the screen is set to display (default is last 250 alerts).

    Bill



  • <kid expression="">ZOMG!!11!!! ENABLE ALL RULES BUTTON!!!!111</kid>

    I'm so happy tears actually welled up in my eyes. CARP SYNC + enable all buttons. I really can't express my gratitude with words. Please check your PMs shortly. I think you'll find something there worth taking the time to reply to. These are hard times but this work should be rewarded. What's a couple of weeks with no food when you have so dedicated programmers?

    Thank you
    Thank you
    Thank you



  • @shinzo:

    So i have been playing with the Host Attribute Table but cant seem to get it running correctly.  I looked at a few examples but i keep getting
    snort[****]: FATAL ERROR: /usr/local/etc/snort/snort_*_em0/snort.conf(253) Unknown config directive: max_attribute_hosts.

    The error posted above was a result of the new Snort 2.9.4.6 binaries being compiled without the TARGETBASED option enabled.  That was caused by a timing issue on my part with the various Github Pull Requests I submitted for this upgrade.  The one enabling the TARGETBASED option did not get there until after the binaries were built.  Thanks to jimp the new binaries have just been built and posted.

    So if you want to use the new Host Attribute Table option, you will first need to remove and then reinstall the Snort package in order to pickup the new binary compiled with the targetbased support.

    Bill



  • @jflsakfja:

    <kid expression="">ZOMG!!11!!! ENABLE ALL RULES BUTTON!!!!111</kid>

    I'm so happy tears actually welled up in my eyes. CARP SYNC + enable all buttons. I really can't express my gratitude with words. Please check your PMs shortly. I think you'll find something there worth taking the time to reply to. These are hard times but this work should be rewarded. What's a couple of weeks with no food when you have so dedicated programmers?

    Thank you
    Thank you
    Thank you

    you sound as happy as i was when i saw the ALL DISABLE BUTTON  ;D



  • @shinzo:

    you sound as happy as i was when i saw the ALL DISABLE BUTTON  ;D

    I have so far clicked on each and every single rule (mostly manually enabled rules not enabled by default) except about 3/4 of web_specific_apps and most of IPS Policy - Security, so you can understand why I'm so happy  ;D. Had to manually enable rules that were disabled and needed to be enabled, check the sticky for more info. I'll be updating the list on the sticky soon(ish).

    I'm still trying to calm down from the excitement. Clicking enable all, manually searching for the 10 rules out of 5420 rules and disable them takes a while to get used to. Trust me it's a lot faster than the old way of doing it  ;D

    edit: oh and that 5420 is only the web_specific_apps list  :D



  • @bmeeks:

    @shinzo:

    So i have been playing with the Host Attribute Table but cant seem to get it running correctly.  I looked at a few examples but i keep getting
    snort[****]: FATAL ERROR: /usr/local/etc/snort/snort_*_em0/snort.conf(253) Unknown config directive: max_attribute_hosts.

    The error posted above was a result of the new Snort 2.9.4.6 binaries being compiled without the TARGETBASED option enabled.  That was caused by a timing issue on my part with the various Github Pull Requests I submitted for this upgrade.  The one enabling the TARGETBASED option did not get there until afte the binaries were built.  Thanks to jimp the new binaries have just been built and posted.

    So if you want to use the new Host Attribute Table option, you will first need to remove and then reinstall the Snort package in order to pickup the new binary compiled with the targetbased support.

    Bill

    I uninstalled and reinstalled the package and the issue has been fixed.  When doing some research yesterday i noticed someone had a list of ip addresses with the service/port next to them for the host attribute table.  A suggestion i have is to have a viewlist tab with what has been setup there.  I will post an example later in the day



  • @shinzo:

    [When doing some research yesterday i noticed someone had a list of ip addresses with the service/port next to them for the host attribute table.  A suggestion i have is to have a viewlist tab with what has been setup there.  I will post an example later in the day
    [/quote]

    That's a good idea.  There definitely needs to be a better way to view/edit the Host Attribute Table.  What's there now was just quick and easy to get the feature out the door.  I will be happy to entertain suggestions for improvement.

    Bill


  • Banned

    Could it be an idea to have a list of IP's that could be monitored for triggering events?

    Like clients having IP's that gets triggered in Snort and then be able to send alerts to either the admin or both admin and client?

    Like you have been caught in the firewall triggering this event: bla bla bla. Contact Support for solving issues.


Log in to reply