Snort package update



  • I am currently running the Snort package 2.9.2.3 pkg v. 2.2.2 with some (mainly minor) problems.

    (1) I am unable to activate any Snort shared object rule
    (2) Interfaces go down once in a while (probably related to blocking sites, but doesn't seem to happen all the time)

    (1) could be related to invalid hard coded path paths in snort_download_rules.php (line 404 for x86 and line 407 for x64) as the the snapshot files contain version related hard coded paths. E.g.

    exec("/bin/mv -f {$snortdir}/so_rules/precompiled/$freebsd_version_so/i386/2.9.0.5/* /usr/local/lib/snort/dynamicrules/");
    

    should probably be

    exec("/bin/mv -f {$snortdir}/so_rules/precompiled/$freebsd_version_so/i386/2.9.3.2/* /usr/local/lib/snort/dynamicrules/");
    

    and other places would need similar updates.

    I haven't figured out what really causes issue 2.

    Would it make any sense to have a concise list/thread, maybe moderated, of current issues? I am sure that I have read about these issues here before, but it takes a lot of time to figure out how all the other messages relate to ones own current problems.

    I have some time left to look at the current issues and do some coding myself, but I would appreciate some cooperation with the maintainer of the package to avoid duplicate work and I wouldn't like to study all the source lines related to the package…



  • Well thank you for the help and troubleshooting.

    I will fix asap the issue(1) reported by you, since your analysis is correct.

    The problem with listing current issues has been somehow described on redmine.pfsense.org on pfSense-packages project.
    Just filter with category snort and you will find them.

    A forum its just not the place to follow-up issues but rather just get complaint/testing feedback.

    In general snort 2.2.2 is maintained by pfSense developers themselves depending on time and funding.
    The estimation to make snort stable is that it needs a full week of work so its usable with its functionality and more easy to upgrade.
    The problem is that a lot of people like to run snort though very few contribute with development time or funding to make that happen.



  • There are more spots to fix && I already have done that (more or less). Since I currently don't have access to a spare testing machine, I'll be able to test my patches over the weekend during the night on one of the production systems (in hotels, unless I don't get the permission from the management because some guest needs to do some urgent business work, aka watching p0rn).

    IMHO the code could benefit from some cleanup, e.g. configuration parameters are spread over several files and some stuff seems to be obsolete now. My suggestion is that I describe how I would like the code to look like (essentially to make the updates more generic), implement it and hand in my patches. I might want to discuss some design decisions. If the following lines make any sense to you, I'd be happy to proceed:

    /* package version */
    $snort_version = '2.9.2.3';
    $snot_package_version = '2.2.2';
    $snort_freebsd_version_so = 'FreeBSD-8-1';
    
    $snort_condensed_version = str_replace('.', '', $snort_version);
    $snort_package_version = "Snort $snort_version pkg v. $snot_package_version";
    $snort_rules_file = "snortrules-snapshot-$snort_condensed_version.tar.gz";
    

    Of course, the relevant places have already been patched.



  • ermal,

    I wasn't aware of redmine.pfsense.org  :-[



  • I did almost that myself and committed.



  • ermal,

    the so rules have also changed. In snort_download_rules.php you need to remove sql.rules and add snmtp.rules as well as specific-threats.rules (renaming and moving).



  • I disabled the emerging threats rules such that only the snort rules load. Loading is fine and the system log does not show any abnormalities. With the p2p rules (so rules!) and blocking enabled, the system reacted as expected, but the messages did either not appear or there were bogus messages (after rebooting). Eg. running uTorrent triggered a "(http_inspect) HTTP RESPONSE GZIP DECOMPRESSION FAILED" message, instead of a torrent related message. Also, the snort interface went down after blocking occured. The log files inside /var/log/snort contained message like " clog: ERROR: could not write output (Bad address)".

    There's probably more to clean up.



  • Corrected update and rule update.

    For the other issue is better to see in another thread.


Locked