Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Snort 2.9.2.3 pkg v. 2.5.1 service fails overnight, unable to restart

    Scheduled Pinned Locked Moved pfSense Packages
    65 Posts 14 Posters 22.6k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • F
      Fesoj
      last edited by

      miles267,

      you've got quite a few suppressions. In a way it doesn't make too much sense to enable all kind of rules, just to suppress their alerts (unless you are testing snort  ;) ). Personally I don't find the sensitive data preproc very useful (so why enable it?).

      You should also watch your system log for warnings like

      Jul 29 15:32:32 snort[31733]: WARNING: flowbits key 'ET.HTTP.at.SSL' is set but not ever checked.
      Jul 29 15:32:32 snort[31733]: WARNING: flowbits key 'ET.bmp_seen' is set but not ever checked.
      Jul 29 15:32:32 snort[31733]: WARNING: flowbits key 'ET.MSSQL' is set but not ever checked.

      , where entries like

      checked but never set

      are worse. My current approach is to specify only the stuff I really need, and then add additional sets to fullfill the state requirements, but not messing with individual rules.

      1 Reply Last reply Reply Quote 0
      • C
        caustic386
        last edited by

        @dwood:

        1.  Uninstall (if you have an older version, suggest you not toggle "save settings" to on.  In other words, start fresh.
        2.  Create an alias in pfsense to reflect your old whitelist.  You will select this alias in the snort whitelist tab later.
        3.  Run this command using Diagnostics -> Command Prompt:  find /* | grep -i snort | xargs rm -rv  (removes old snort references)
        4.  Install latest.  Likely for this version you'll want to make sure that senstive data preprocessor is not selected.  I've got all others on.
        5.  Monitor blocking and prepare to add quite a few exclusions!  This is the set I'm using pretty much copy/pasted from the suppression tab:

        Tried this 3 times, and each night snort fails.  I can restart again in the morning with very little effort, but that's clearly not the best solution.  I may open a ticket with support about this, as I've spent quite a bit of time dealing with it already.

        1 Reply Last reply Reply Quote 0
        • M
          miles267
          last edited by

          @Fesoj:

          miles267,

          you've got quite a few suppressions. In a way it doesn't make too much sense to enable all kind of rules, just to suppress their alerts (unless you are testing snort  ;) ). Personally I don't find the sensitive data preproc very useful (so why enable it?).

          You should also watch your system log for warnings like

          Jul 29 15:32:32 snort[31733]: WARNING: flowbits key 'ET.HTTP.at.SSL' is set but not ever checked.
          Jul 29 15:32:32 snort[31733]: WARNING: flowbits key 'ET.bmp_seen' is set but not ever checked.
          Jul 29 15:32:32 snort[31733]: WARNING: flowbits key 'ET.MSSQL' is set but not ever checked.

          , where entries like

          checked but never set

          are worse. My current approach is to specify only the stuff I really need, and then add additional sets to fullfill the state requirements, but not messing with individual rules.

          Appreciate the insight.  Are there a base set of Snort and/or ET rules you'd recommend be enabled for a home network?  Currently, I have ICMP and NETBIOS rules enabled on my LAN (not my WAN) and nearly every rule enabled on my WAN.  Thanks.

          1 Reply Last reply Reply Quote 0
          • C
            caustic386
            last edited by

            @miles267:

            Appreciate the insight.  Are there a base set of Snort and/or ET rules you'd recommend be enabled for a home network?  Currently, I have ICMP and NETBIOS rules enabled on my LAN (not my WAN) and nearly every rule enabled on my WAN.  Thanks.

            While I don't entirely disagree with Fesoj, I spoke with support about enabling snort on the WAN interface if you don't host any external sites.  Jim referred to it as the "belt and suspenders" approach, which basically means that there's no point in having Snort on your external interface unless you have some server publicly available, and even then it depends on what kind of server it is (snort can't see inside https, for instance).  pfSense blocks everything by default so Snort would just give you a bit of specificity that you don't really need.

            For that reason, I keep snort on my LAN interface with all categories enabled (I don't mess with rules much, just categories)  and suppress the false positives.  There are MANY ways to do this, and mine probably isn't the best but performance is fine and it gives me great insight into my network.

            1 Reply Last reply Reply Quote 0
            • F
              Fesoj
              last edited by

              miles267,

              sapere aude!

              It all depends on what you want to and where your risks are. That's why you can configure it. What you could do is, set up snort interfaces for the LAN and the WAN side and enable the same rules and attack your system from the LAN side and the WAN side. When your router shows up in alerts as either the destination or source on one side and not on the other, you know on which side the rule makes sense. Unfortunately, this requires some time for testing and learning. As far as NETBIOS goes, I think they are better off on the WAN side (just have a look at the src nets for most of the rules). On the other hand, if your snort box is not an edge router, chances are that you do not need the NETBIOS rules.

              Another line of thought is looking at the size of the NETBIOS rule set, which is pretty large. Since many rules are rather MS related, one could doubt that you need them if your desktop boxes are Linux based. Last not least, most of the vulnerabilities have probably been fixed by MS meanwhile.

              1 Reply Last reply Reply Quote 0
              • B
                blundar
                last edited by

                I set up the package on 7/27 on PF2.01/Amd64

                When the updates processed (last night I think) things broke.  I removed the package, reinstalled about 3pm EST and it seems to have fixed things.  Just FYI.

                1 Reply Last reply Reply Quote 0
                • M
                  mschiek01
                  last edited by

                  @Fesoj:

                  miles267,

                  snort chokes on the missing sdf declaration. For now, https://github.com/bsdperimeter/pfsense-packages/pull/291/files should solve the problem. I haven't looked at the details why the declaration is missing again, but I guess you've enabled only the ET rules (but I could be wrong).

                  Fesoj, your code from the github has allowed snort to run on both i386 and amd64 boxes continuously since you originally posted the code. This is with the Sensitive data prepros on with both Snort and ET rules. Checking for updates every six hours, I have not had one error on six different boxes and not all the boxes have the same rules enabled.

                  1 Reply Last reply Reply Quote 0
                  • B
                    blundar
                    last edited by

                    Is it normal to get errors on certain rulesets?

                    
                    snort[1441]: FATAL ERROR: /usr/local/etc/snort/snort_13690_em0/rules/snort_exploit.rules(362) Unknown rule option: 'ssl_state'.
                    
                    

                    I get similar for botnet-cnc, policy-other, specific-theats.  Not always same error.

                    1 Reply Last reply Reply Quote 0
                    • AhnHELA
                      AhnHEL
                      last edited by

                      I was getting that error on that specific category myself, so you're not alone.  Just disable it for now.

                      AhnHEL (Angel)

                      1 Reply Last reply Reply Quote 0
                      • F
                        Fesoj
                        last edited by

                        mschiek01,

                        I could go through the source code and find out under what circumstances the sdf declaration is missing, but if you patch the classification.config file of the ET rules, then the details on how pfSense generates the configuration files for the individual interfaces doesn't matter. With all this patching, the code gets pretty ugly, this is probably the reason why ermal did not patch his sources. My boxes are also running fine without any problems.

                        1 Reply Last reply Reply Quote 0
                        • F
                          Fesoj
                          last edited by

                          blundar, onhel,
                          does  it matter if you toggle the settings in Snort: Interface Preprocessors and Flow: General Preprocessor Settings: Enable SSL Data?

                          1 Reply Last reply Reply Quote 0
                          • B
                            blundar
                            last edited by

                            I had it disabled when I was getting those errors.
                            Enabling it fixed snort.botnet-cnc

                            still getting errors on other once, mostly related to dce_iface

                            Searching around these seem to be related to a conf issue so I'll keep digging.

                            Thanks!

                            1 Reply Last reply Reply Quote 0
                            • C
                              caustic386
                              last edited by

                              @blundar:

                              I set up the package on 7/27 on PF2.01/Amd64

                              When the updates processed (last night I think) things broke.  I removed the package, reinstalled about 3pm EST and it seems to have fixed things.  Just FYI.

                              This is my exact setup, and I'm still having trouble after a few re-installs.  Fails overnight, restart manually is successful.

                              1 Reply Last reply Reply Quote 0
                              • B
                                blundar
                                last edited by

                                I must eat my words!  Snort died again last night!

                                from logs:

                                
                                20	snort[32228]: Initializing rule chains...
                                Jul 31 12:03:20	snort[32228]: FATAL ERROR: /usr/local/etc/snort/snort_13690_em0/preproc_rules/sensitive-data.rules(1) Unknown ClassType: sdf
                                Jul 31 12:03:20	snort[32228]: FATAL ERROR: /usr/local/etc/snort/snort_13690_em0/preproc_rules/sensitive-data.rules(1) Unknown ClassType: sdf
                                Jul 31 12:03:20	php: : Snort has restarted with your new set of rules...
                                Jul 31 12:03:20	kernel: em0: promiscuous mode disabled
                                
                                

                                Unchecking the "sensitive-data" checkbox for the CC# check, etc. in preprocessors was enough to get snort running again, albeit without some useful checks.

                                1 Reply Last reply Reply Quote 0
                                • C
                                  caustic386
                                  last edited by

                                  @blundar:

                                  I must eat my words!  Snort died again last night!

                                  Unchecking the "sensitive-data" checkbox for the CC# check, etc. in preprocessors was enough to get snort running again, albeit without some useful checks.

                                  This is my exact same issue.  I'm not sure how to find logs for past snort events?

                                  1 Reply Last reply Reply Quote 0
                                  • B
                                    blundar
                                    last edited by

                                    Services… System logs.

                                    1 Reply Last reply Reply Quote 0
                                    • C
                                      caustic386
                                      last edited by

                                      @blundar:

                                      Services… System logs.

                                      Unfortunately it only displays the last 50 events, which doesn't take me back to the overnight failure.

                                      1 Reply Last reply Reply Quote 0
                                      • F
                                        Fesoj
                                        last edited by

                                        blundar,

                                        the sdf problem is known for quite a while and if you search backwards in this thread you'll find a way of handling it.

                                        1 Reply Last reply Reply Quote 0
                                        • B
                                          blundar
                                          last edited by

                                          you can change the number of lines using the settings tab.  I have mine set to 500.

                                          1 Reply Last reply Reply Quote 0
                                          • C
                                            caustic386
                                            last edited by

                                            @blundar:

                                            you can change the number of lines using the settings tab.  I have mine set to 500.

                                            Thanks - can't believe I never noticed that.  I'll check it again first thing in the AM.

                                            1 Reply Last reply Reply Quote 0
                                            • First post
                                              Last post
                                            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.