Snort 2.9.2.3 pkg v. 2.5.0 Issues



  • In the new version it is not possible to add IPs to the Whitelist, since the Alias field is missing (and the + sign for adding entries).
    EDIT: ok, we have to define an alias to be used for Whitelists.

    It is still not possible to start snort, when Sensitive Data preproc is disabled.

    FATAL ERROR: /usr/local/etc/snort/preproc_rules/sensitive-data.rules(1) Unknown rule option: 'sd_pattern'.

    Greets, Judex



  • @judex:

    In the new version it is not possible to add IPs to the Whitelist, since the Alias field is missing (and the + sign for adding entries).
    EDIT: ok, we have to define an alias to be used for Whitelists.

    It is still not possible to start snort, when Sensitive Data preproc is disabled.

    FATAL ERROR: /usr/local/etc/snort/preproc_rules/sensitive-data.rules(1) Unknown rule option: 'sd_pattern'.

    Greets, Judex

    @Judex The sensitive issue has been fixed.. please reinstall



  • I did that 60 min. ago - was it fixed meanwhile



  • @judex:

    I did that 60 min. ago - was it fixed meanwhile

    yes, https://github.com/bsdperimeter/pfsense-packages/commits/master/



  • Loading without sensitive information preproc works.

    So far with 2.5.0 I've only noticed minor UI issues with alert page growing outside the background margins.



  • @fragged:

    So far with 2.5.0 I've only noticed minor UI issues with alert page growing outside the background margins.

    i've noticed that too, thinking its because of the theme and not the package



  • @Cino:

    @judex:

    I did that 60 min. ago - was it fixed meanwhile

    yes, https://github.com/bsdperimeter/pfsense-packages/commits/master/

    Thx Cino, I had the 60 min gap bad luck! Everything working now!



  • Has anyone that runs an smtp server behind snort been able to get the smtp preproc to work correctly.  If I enable it the preproc, it will start blocking the traffic to the server with bad alerts.



  • Hi ermal,

    good job. For my purposes, snort is running smoothly now.

    I have also solved my problem of the 2nd interface on the LAN side that apparently did not work at all, where I was using the ET p2p rules. These rules worked on the WAN side, but not on the LAN side.

    There's no need to go int details here, but I'd like to say that it is (probably always was) necessary to look at the definition of the rules and how your environment is defined. If a rule is based on the HOME_NET, the local machines that are being monitored should also be part of the HOME_NET or the rule is essentially not active. In my case I had to augment the default HOME_NET by the client subnet to get the behavior I wanted.



  • Fesoj,

    re-added sub-nets to the HOME_NET list, i had mistaken it with something else.
    Just re-install and should be good.



  • Hm, but now we have the WAN subnet back as 24 CIDR in HOME_NET



  • Yeah its ok judex.



  • @ermal:

    @Cino:

    Added some more suggestions/issues to post http://forum.pfsense.org/index.php/topic,51387.msg275159.html#msg275159

    @breusshe

    If you dont mind changing commenting out some php code, you can get your 2nd WAN interface back:

    lines 82 and 83 in /usr/local/www/snort/snort_interfaces_edit.php

    make them look like this:

    
    #		if ($natent['interface'] == $_POST['interface'])
    #			$input_errors[] = "This interface is already configured for another instance";
    
    

    This allowed me to create another WAN interface, and it has a different ID:

    
     ps -aux | grep snort
    root   61341 23.7    ??  Ss    1:56PM   0:01.29 /usr/pbi/snort-i386/bin/snort -R 36745 -D -q -l /var/log/snort/snort_em336745 --pid-path /var/run --nolock-pidfile -G 36745 -c /usr/
    root   59209  0.2    ??  Ss    1:54PM   0:01.13 /usr/pbi/snort-i386/bin/snort -R 60770 -D -q -l /var/log/snort/snort_em360770 --pid-path /var/run --nolock-pidfile -G 60770 -c /usr/
    root    3143  0.0  0.3 13048  8384  ??  Ss    1:54PM   0:00.06 /usr/local/bin/barnyard2 -r 60770 -f snort_60770_em3.u2 --pid-path /var/run --nolock-pidfile -c /usr/local/etc/snort/snort_60770_em3
    root   35410  0.0  0.0  3536  1256   0  S+    1:56PM   0:00.01 grep snort
    
    

    Use event_filter configurations for this it makes no sense to do this!

    The above quotes are from the v2.4.2 issues posting, but I see the issue still applies, so I'm bringing the discussion here.

    @Ermal:  event_filter does not do what I want.  There are categories of rules that I wish to log, but don't want to block if they are seen.  I simply wish to monitor how prolific the event is.  Since there is no way to block some categories/rules while also only alerting for other categories without using two instances of snort on the same interface, it seems necessary to have this feature.

    Now, let's assume I'm mistaken and there is a way to have only one instance where some things are blocked while some are only noted in the snort logs using some filter command.  I would have to activate all of the categories/rules I want running on my interface and then manually identify all of those gen_id and sig_id numbers that I only wanted alerted, but not blocked.  Since those rule files contain multiple gen_id's I can't so something like "gen_id=xxx, sig_id=0" to change how a whole category is handled.  What you are asking us do to is an administrative nightmare.  Also, having all of this running through one instance means all snort matching will occur on one CPU core (since, last I checked, Snort wasn't very multi-core friendly) while how I run Snort allows multiple cores to be used, thus helping to prevent snort from getting swamped with requests.

    So, I ask you, even though you don't see the sense in it, please implement the edit that Cino suggests so multiple instances of Snort will run on one interface.  If nothing else, it makes management of Snort easier.



  • I have two other questions.

    1.)  Why is it that I can only save snort alerts to the system logs now?  Used to be we could choose between unified2 format, tcpdump, or system logs.  What was the reason for the change?

    2.)  What happened to "Define SSL_IGNORE"?  It's not on the preprocessors page nor does it seem to be anywhere else.



  • Reinstall you will be able to configure 2 ifaces.

    The logtype was removed because:
    barnyard logging will be enabled when you enable barnyard
    alerts tab uses alert_csv format

    syslog exporting remains the other thing you want to enable disable.



  • @ermal:

    Reinstall you will be able to configure 2 ifaces.

    The logtype was removed because:
    barnyard logging will be enabled when you enable barnyard
    alerts tab uses alert_csv format

    syslog exporting remains the other thing you want to enable disable.

    Thank you, Ermal.  Is it still true with barnyard2 that the sql server is not installed on pfsense?  I'm a home user, myself, so I don't have extra servers just lying around simply for a sql database.  I know it isn't "recommended" to have sql server running on an Internet facing system, but if it is locked down to only the localhost interface, the risks are acceptable for a home user.  Hmmm.  I wonder if a "mySQL for Barnyard2" package could be built?  You obviously build packages, Ermal.  Do you mind pointing me to the documentation on how one adds a package to the pfSense Package Manager?



  • @ermal:

    Reinstall you will be able to configure 2 ifaces.

    The logtype was removed because:
    barnyard logging will be enabled when you enable barnyard
    alerts tab uses alert_csv format

    syslog exporting remains the other thing you want to enable disable.

    Just did the reinstall.  I get this error:

    FATAL ERROR: Failed to load /usr/local/lib/snort/dynamicrules/bad-traffic.so: /usr/local/lib/snort/dynamicrules/bad-traffic.so: Undefined symbol "freeRuleData"

    The funny part is I'm not even using bad-traffic.so.  Not sure why it is even loading.



  • breusshe because snort is just going to dump/exit if i put only enabled so rules and libs.



  • @breusshe:

    @ermal:

    @Cino:

    Added some more suggestions/issues to post http://forum.pfsense.org/index.php/topic,51387.msg275159.html#msg275159

    @breusshe

    If you dont mind changing commenting out some php code, you can get your 2nd WAN interface back:

    lines 82 and 83 in /usr/local/www/snort/snort_interfaces_edit.php

    make them look like this:

    
    #		if ($natent['interface'] == $_POST['interface'])
    #			$input_errors[] = "This interface is already configured for another instance";
    
    

    This allowed me to create another WAN interface, and it has a different ID:

    
     ps -aux | grep snort
    root   61341 23.7    ??  Ss    1:56PM   0:01.29 /usr/pbi/snort-i386/bin/snort -R 36745 -D -q -l /var/log/snort/snort_em336745 --pid-path /var/run --nolock-pidfile -G 36745 -c /usr/
    root   59209  0.2    ??  Ss    1:54PM   0:01.13 /usr/pbi/snort-i386/bin/snort -R 60770 -D -q -l /var/log/snort/snort_em360770 --pid-path /var/run --nolock-pidfile -G 60770 -c /usr/
    root    3143  0.0  0.3 13048  8384  ??  Ss    1:54PM   0:00.06 /usr/local/bin/barnyard2 -r 60770 -f snort_60770_em3.u2 --pid-path /var/run --nolock-pidfile -c /usr/local/etc/snort/snort_60770_em3
    root   35410  0.0  0.0  3536  1256   0  S+    1:56PM   0:00.01 grep snort
    
    

    Use event_filter configurations for this it makes no sense to do this!

    The above quotes are from the v2.4.2 issues posting, but I see the issue still applies, so I'm bringing the discussion here.

    @Ermal:  event_filter does not do what I want.  There are categories of rules that I wish to log, but don't want to block if they are seen.  I simply wish to monitor how prolific the event is.  Since there is no way to block some categories/rules while also only alerting for other categories without using two instances of snort on the same interface, it seems necessary to have this feature.

    Now, let's assume I'm mistaken and there is a way to have only one instance where some things are blocked while some are only noted in the snort logs using some filter command.  I would have to activate all of the categories/rules I want running on my interface and then manually identify all of those gen_id and sig_id numbers that I only wanted alerted, but not blocked.  Since those rule files contain multiple gen_id's I can't so something like "gen_id=xxx, sig_id=0" to change how a whole category is handled.  What you are asking us do to is an administrative nightmare.  Also, having all of this running through one instance means all snort matching will occur on one CPU core (since, last I checked, Snort wasn't very multi-core friendly) while how I run Snort allows multiple cores to be used, thus helping to prevent snort from getting swamped with requests.

    So, I ask you, even though you don't see the sense in it, please implement the edit that Cino suggests so multiple instances of Snort will run on one interface.  If nothing else, it makes management of Snort easier.

    My fix to this would be to make alert_pf understand a kind of suppress type list to block also.
    This would make your setup usable with one instance.
    Though for now i want go into that implementation anyhow.



  • @breusshe:

    @ermal:

    Reinstall you will be able to configure 2 ifaces.

    The logtype was removed because:
    barnyard logging will be enabled when you enable barnyard
    alerts tab uses alert_csv format

    syslog exporting remains the other thing you want to enable disable.

    Thank you, Ermal.  Is it still true with barnyard2 that the sql server is not installed on pfsense?  I'm a home user, myself, so I don't have extra servers just lying around simply for a sql database.  I know it isn't "recommended" to have sql server running on an Internet facing system, but if it is locked down to only the localhost interface, the risks are acceptable for a home user.  Hmmm.  I wonder if a "mySQL for Barnyard2" package could be built?  You obviously build packages, Ermal.  Do you mind pointing me to the documentation on how one adds a package to the pfSense Package Manager?

    Just add yourself the mysql-server package.



  • Ermal, when enabling sensitive data pre-processor, whitelisted IPs are possibly ignored.  I've added an IMAP provider to the whitelist, however this whitelisted IP is being blocked by sensitive data email rule.  Adding to suppress list seems to work after restarting interfaces. AMD64, 2.0.1

    Cheers,
    Dennis.



  • So, to deal with the error I'm getting after the latest reinstall, I dumped my config and uninstalled Snort.  I reinstalled, and started to reconfigure.  On the "Server" tab in one of the instances I'm configuring, I tried adding some port numbers, which I've done in the past, and got the following message:

    The following input errors were detected:

    Only aliases are allowed

    For instance, I'm trying to set "Define IMAP_PORTS" to the value:  143,993.  The field states that "143" is the default and suggests examples "25,443" and "5060:5090".  However, the above error message seems to imply I need to use some sort of alias now.  Is this a new bug?



  • That is a new feature!
    https://github.com/bsdperimeter/pfsense-packages/commit/92fc14e2e523e2c314868fd861a80d0a25bd7549
    Judged by last days commits ermal is unstoppable at the moment  ;D



  • breusshe,

    aliases are defined under Firewall: Aliases:

    Worked for me when I modified the HOME_NET.



  • @ermal:

    Just add yourself the mysql-server package.

    Yeah, I've tried that before.  The problem is that mysql-server isn't part of the pfsense repository and the release that pfsense 2.0.1 is built from doesn't exist any longer in FreeBSD's repos.  So, to get server, I have to upgrade mysql-client, which forces me to update other stuff as well.  None of it is from the normal repos for pfsense which causes problems with package upgrades in the future.  So, to do this, I'd have to get mysql-server (of the correct version) and its dependencies added to the pfsense repos and installable from the Package Manager.



  • @judex:

    That is a new feature!
    https://github.com/bsdperimeter/pfsense-packages/commit/92fc14e2e523e2c314868fd861a80d0a25bd7549
    Judged by last days commits ermal is unstoppable at the moment  ;D

    Ah, okay.  I'll add aliases there.  Thanks, Judex and Fesoj.



  • @breusshe:

    Just did the reinstall.  I get this error:

    FATAL ERROR: Failed to load /usr/local/lib/snort/dynamicrules/bad-traffic.so: /usr/local/lib/snort/dynamicrules/bad-traffic.so: Undefined symbol "freeRuleData"

    The funny part is I'm not even using bad-traffic.so.  Not sure why it is even loading.

    Uninstall and wipe of config, then reinstall seems to have fixed this.  Not sure what was causing it.  But, snort starts up just fine now.  Just waiting to see if I can catch alerts.



  • This is just inquiring on how to do updates in an economical way.

    In emergency situations one could always update from github (github.com/bsdperimeter/pfsense-packages).

    The regular package updates seem to come from  http://files.pfsense.com/packages/8/All/, but it takes some time after updating the repository before the regular package update has the latest version (hours?). Since not every package update is accompanied by a change of the version string, it is rather difficult to see, whether the advertised updates from the forum are going to be installed or not. Currently snort-2.9.2.3-i386.pbi is still from yesterday 2012-Jul-15 21:11:02, so a regular update (System: Packages:) doesn't really update anything. It looks to me that some of the recent messages can be explained by this setup.

    It's not about making things faster, but to know when the update will actually be available. I wouldn't mind having a 4 digit version string for the package. Another method would be to base the update on the associated md5 hashes.

    Am I here off base, or does this remark that make some sense?



  • @breusshe:

    @breusshe:

    Just did the reinstall.  I get this error:

    FATAL ERROR: Failed to load /usr/local/lib/snort/dynamicrules/bad-traffic.so: /usr/local/lib/snort/dynamicrules/bad-traffic.so: Undefined symbol "freeRuleData"

    The funny part is I'm not even using bad-traffic.so.  Not sure why it is even loading.

    Uninstall and wipe of config, then reinstall seems to have fixed this.  Not sure what was causing it.  But, snort starts up just fine now.  Just waiting to see if I can catch alerts.

    i figured out what is causing this.. ermal submitted a change based on what is left on our system when you uninstall snort https://github.com/bsdperimeter/pfsense-packages/commit/380d7cbe464a271c47fa57d4a890e1d61019fd08  I told him about this morning. These files are linked files to the pbi folders.. You we are doing a reinstall/reinstall gui.. Its removing the linked files.. Because how pbi's behave with the pfsense package manager… I recommend that you uninstall a package then install it when you doing an upgraded.. I recommend this because if you select to re-install the package, some reason or another, the pbi binary isn't re-installed.... Now this is behavior on pfSense 2.1.. 2.0.1, i would do the same thing



  • @Fesoj:

    This is just inquiring on how to do updates in an economical way.

    In emergency situations one could always update from github (github.com/bsdperimeter/pfsense-packages).

    The regular package updates seem to come from  http://files.pfsense.com/packages/8/All/, but it takes some time after updating the repository before the regular package update has the latest version (hours?). Since not every package update is accompanied by a change of the version string, it is rather difficult to see, whether the advertised updates from the forum are going to be installed or not. Currently snort-2.9.2.3-i386.pbi is still from yesterday 2012-Jul-15 21:11:02, so a regular update (System: Packages:) doesn't really update anything. It looks to me that some of the recent messages can be explained by this setup.

    It's not about making things faster, but to know when the update will actually be available. I wouldn't mind having a 4 digit version string for the package. Another method would be to base the update on the associated md5 hashes.

    Am I here off base, or does this remark that make some sense?

    Whentever changes are made to github.com/bsdperimeter/pfsense-packages, you are able to get them within 5 minutes or less(I think its real-time).. Binaries are a different story… jimp has a builder that builds them base on what changes happen to github.com/bsdperimeter/pfsense-tools... Not sure if its a auto or manual process for them to move the files over to files.pfsense.org

    as far as seeing a package update within the package manager. that is up to the maintainer to increase the version number of the package.

    pfsense team, correct me if i'm wrong on this



  • Same thing here..had to remove 2.5.0.  WAN IP x.x.x.0 network was being blocked.  PFsense log than alerted on WAN down, and removed it from routing group (dual wan).

    Cheers,
    Dennis.



  • Snort was running with preproc active a rules update was processed and snort stopped with the following error.

    Jul 16 20:56:27 php: /snort/snort_download_rules.php: Snort has restarted with your new set of rules…
    Jul 16 20:56:26 snort[25975]: FATAL ERROR: /usr/local/etc/snort/preproc_rules/sensitive-data.rules(1) Unknown ClassType: sdf
    Jul 16 20:56:26 snort[25975]: FATAL ERROR: /usr/local/etc/snort/preproc_rules/sensitive-data.rules(1) Unknown ClassType: sdf
    Jul 16 20:56:26 snort[25975]: Initializing rule chains…
    Jul 16 20:56:26 snort[25975]: Initializing rule chains…
    Jul 16 20:56:26 snort[25975]: +++++++++++++++++++++++++++++++++++++++++++++++++++
    Jul 16 20:56:26 snort[25975]: +++++++++++++++++++++++++++++++++++++++++++++++++++



  • Same here.

    However mine seems to be caused by an invalid snort.conf. This can not be fixed by hand because it's deleted and regenerated each time snort is run.

    snort[55098]: FATAL ERROR: Unable to open rules file "/usr/local/etc/snort/snort_21199_em0//usr/local/etc/snort/preproc_rules/sensitive-data.rules/": No such file or directory.

    include $PREPROC_RULE_PATH/sensitive-data.rules**/**

    UPDATE: Cleared it up with package reinstall and of course re-download rules. Working as before.



  • @dwood:

    Same thing here..had to remove 2.5.0.  WAN IP x.x.x.0 network was being blocked.  PFsense log than alerted on WAN down, and removed it from routing group (dual wan).

    Cheers,
    Dennis.

    As i put in the other thread.
    There is an issue that was solved with blocking not parsing correctly the whitelist.
    Just re-install the binary.



  • Sometimes the alerts go wrong and give you a N/A in the blocked tab




  • @mschiek01:

    Snort was running with preproc active a rules update was processed and snort stopped with the following error.

    Jul 16 20:56:27 php: /snort/snort_download_rules.php: Snort has restarted with your new set of rules…
    Jul 16 20:56:26 snort[25975]: FATAL ERROR: /usr/local/etc/snort/preproc_rules/sensitive-data.rules(1) Unknown ClassType: sdf
    Jul 16 20:56:26 snort[25975]: FATAL ERROR: /usr/local/etc/snort/preproc_rules/sensitive-data.rules(1) Unknown ClassType: sdf
    Jul 16 20:56:26 snort[25975]: Initializing rule chains…
    Jul 16 20:56:26 snort[25975]: Initializing rule chains…
    Jul 16 20:56:26 snort[25975]: +++++++++++++++++++++++++++++++++++++++++++++++++++
    Jul 16 20:56:26 snort[25975]: +++++++++++++++++++++++++++++++++++++++++++++++++++

    woke up to the same error this this morning. i looked in the preprocessor.rules file and commented the line and turned off sensitive data..

    a google search states its because of sensitive data not being not being turned on… i have it on for testing and have 2 rules suppress. strange.....

    
    alert ( msg: "SDF_COMBO_ALERT"; sid: 1; gid: 139; rev: 1; metadata: rule-type preproc ; classtype:sdf; )
    
    

    EDIT: manual update (after removing the md5 files), and I dont have the above issue with sensitive data on… going to copy the rules over to my pc and compare them when/if this happens again



  • I installed the latest version and snort is running fine, but there might be an issue with the perl package that affects other packages.

    During the last 2 weeks I removed and installed the snort package only. After one of the latest updates the perl files were gone, but pkg_info still reported about 2 perl packages installed. I noticed the missing files by the failure of other packages (e.g. lightsquid). After forcing a reinstall (pkg_add -f) of the latest perl package everything worked again as expected.

    I am not sure whether this odd behavior is due to the snort package, but if you find that some things don't work any more, check for the existence of the perl package (and the system log).



  • @Fesoj:

    I installed the latest version and snort is running fine, but there might be an issue with the perl package that affects other packages.

    During the last 2 weeks I removed and installed the snort package only. After one of the latest updates the perl files were gone, but pkg_info still reported about 2 perl packages installed. I noticed the missing files by the failure of other packages (e.g. lightsquid). After forcing a reinstall (pkg_add -f) of the latest perl package everything worked again as expected.

    I am not sure whether this odd behavior is due to the snort package, but if you find that some things don't work any more, check for the existence of the perl package (and the system log).

    are you running 2.0.x? If so, here is why(i think anyways) https://github.com/bsdperimeter/pfsense-packages/commit/90a78d1150d6cf90b9fb60c2237d8c12b112c7d0. its been removed from the package.

    with 2.1 being pbi packages, its alittle different



  • Cino,

    yes, I am running 2.0.1.

    bump version to 2.5.0 and remove perl from build requirments since it…

    The extracts from snort.inc don't show what happens to those perl files, but the title seems to point to the villain.

    Anyway, pkg_add -f remedies the situation.



  • @Cino:

    EDIT: manual update (after removing the md5 files), and I dont have the above issue with sensitive data on… going to copy the rules over to my pc and compare them when/if this happens again

    I can confirm this solution.  I deleted the MD5 files from /usr/local/etc/snort, turned on sensitive data, ran the rules update manually, and snort started right up.  I'll post if thise problem repeats itself in the next day or two.


Locked