Snort version 3.2.9.5_1 Regression ?



  • After updating to snort version 3.2.9.5_1 status for WAN is always shown as stopped via Services/Snort/Interfaces

    See https://redmine.pfsense.org/issues/7866#change-33929

    Anybody else has seen this ?


  • Netgate

    How about waiting for a response here and a consensus before opening a bug report.

    What is in your snort logs when you try to start WAN? That is the first place you should look.



  • @Derelict:

    How about waiting for a response here and a consensus before opening a bug report.

    What is in your snort logs when you try to start WAN? That is the first place you should look.

    This is all I can see https://pastebin.com/QH7e7A61

    Does
    "Sep 16 14:20:08 snort  40961  FATAL ERROR: /usr/local/etc/snort/snort_12131_igb0/rules/snort.rules(424) Unknown rule option: 'sd_pattern'."
    mean anything to you?

    Thx


  • Banned

    You'll need to wait until someone upstream fixes the broken rule, or find the offending rule (see the file/line referenced in the error message) and disable it on WAN. This has nothing to do with the package update.

    If you want to avoid IDS failing due to a single broken rule (broken by design), I'd suggest to use Suricata.



  • Ok thx,  I wanted to communicate the issue, it might be minor but still was working fine before the last point update.
    Will wait !



  • @chudak:

    Ok thx,  I wanted to communicate the issue, it might be minor but still was working fine before the last point update.
    Will wait !

    Here is the broken rule clue:

    
    FATAL ERROR: /usr/local/etc/snort/snort_12131_igb0/rules/snort.rules(424) Unknown rule option: 'sd_pattern'.
    
    

    It is a problem in a sensitive data rule, and specifically it is the rule on line 424 in the file /usr/local/etc/snort/snort_12131_igb0/rules/snort.rules.  You can use an editor such as vi to find that line and see which rule SID number it is, and then disable that rule.  As mentioned above, the problem is within the rules package itself and not with the Snort package on pfSense.

    Bill



  • @bmeeks:

    @chudak:

    Ok thx,  I wanted to communicate the issue, it might be minor but still was working fine before the last point update.
    Will wait !

    Here is the broken rule clue:

    
    FATAL ERROR: /usr/local/etc/snort/snort_12131_igb0/rules/snort.rules(424) Unknown rule option: 'sd_pattern'.
    
    

    It is a problem in a sensitive data rule, and specifically it is the rule on line 424 in the file /usr/local/etc/snort/snort_12131_igb0/rules/snort.rules.  You can use an editor such as vi to find that line and see which rule SID number it is, and then disable that rule.  As mentioned above, the problem is within the rules package itself and not with the Snort package on pfSense.

    Bill

    Thx for the answer.
    The only interesting question remains - why this rule problem was unmasked by a snort version upgrade?



  • @chudak:

    Thx for the answer.
    The only interesting question remains - why this rule problem was unmasked by a snort version upgrade?

    It wasn't.  I've never seen that error in any of my test virtual machines nor in my personal firewall, and I've upgraded along with every version release.  It is likely a product of the particular rule sets you have enabled.  To be specific, the error is caused by not having the Sensitive Data preprocessor enabled while having an enabled rule that contains a sensitive-date preprocessor keyword (that "sd_pattern" keyword).

    Does Snort now not run at all, or did it just fail to automatically restart following the initial update?

    If you can, open the referenced file in the error message using the vi editor and go to line 424.  Paste the entire contents of that line back here so I can examine the failing rule.

    Bill