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

    Snort 2.9.4.1 Pkg 2.5.4 – Fix for SO rules version mismatch and failed startup

    Scheduled Pinned Locked Moved pfSense Packages
    73 Posts 21 Posters 27.5k 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.
    • bmeeksB
      bmeeks
      last edited by

      Rule updates have been slow for me as well.  Could be a Snort.org problem.  I am also getting the "non IP in whitelist" errors.  Don't know yet what is causing them.  I did not create the binary update to 2.9.4.1.  I've just worked on the GUI parts.  The "non IP in whitelist" error could be coming from either place.  That is, it could be the new Snort binary itself, or an interaction with the GUI and the new binary.  The GUI code is essentially unchanged from Snort 2.9.2.3 to 2.9.4.1.

      I will try and determine exactly what is causing them.  Very likely, if the whitelist is not being parsed correctly, that WAN IP addresses will get blocked by Snort.

      Bill

      1 Reply Last reply Reply Quote 0
      • D
        dwood
        last edited by

        Anyone else seeing WAN connections being blocked?  I have a dual WAN setup, AMD64 2.0.2

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

          In regards to the md5 file problem, I might be way off on this but on the Snort.org site, there are no 2.9.4.1 ruleset updates for Registered Users, only Subscribers.   Wondering if that 30 day wait between Registered and Subscribed is the reason.

          https://www.snort.org/snort-rules/

          AhnHEL (Angel)

          1 Reply Last reply Reply Quote 0
          • S
            shinzo
            last edited by

            Yeah the WAN drop happened to me once but that was a few hours ago.  I have an idea to why the snort.org aren't working.  Snort tries to get the snapshot 2941.  Subscribers can get v2941 but register users can only get v2940.  Being as I am a registered user, can only get v2940

            1 Reply Last reply Reply Quote 0
            • S
              shinzo
              last edited by

              read my mind

              @AhnHEL:

              In regards to the md5 file problem, I might be way off on this but on the Snort.org site, there are no 2.9.4.1 ruleset updates for Registered Users, only Subscribers.   Wondering if that 30 day wait between Registered and Subscribed is the reason.

              https://www.snort.org/snort-rules/

              1 Reply Last reply Reply Quote 0
              • bmeeksB
                bmeeks
                last edited by

                Good catch on the 2.9.4.1 snapshot versus 2.9.4.0.  Subscribers can get 2.9.4.1, but Registered users can only get the 2.9.4.0.  That may be a difficult nut to crack because it appears the 2.9.4.1 code must use the 2.9.4.1 rules tarball to work.

                As for the other error on parsing the whitelist, I've identified the source of the error message as the Spoink plug-in that Snort on pfSense uses to actually do the blocking.  This is a third-party module that Ermal heavily modified to work within pfSense.  It is now, for some reason, apparently choking on parsing the whitelist file supplied to it.  Don't know why yet.  Sent Ermal a request just now to check it out and see if he sees something.

                I will investigate options for the 2.9.4.0 versus 2.9.4.1 rules update issue.  That one may not sort itself out until April 1 when the 2.9.4.1 rules officially become "30 days old".

                Bill

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

                  @bmeeks
                  Are you sure its April 1st?  Thought it might be April 19th with the datestamp on the current rulesets.

                  @Shinzo
                  ;D

                  AhnHEL (Angel)

                  1 Reply Last reply Reply Quote 0
                  • A
                    asterix
                    last edited by

                    WAN blocked a couple of times now. Uninstalling Snort for now.

                    1 Reply Last reply Reply Quote 0
                    • D
                      dwood
                      last edited by

                      Also, Snort continues to block WAN connections, even with interfaces disabled in the snort GUI.  You need to uninstall it, or kill snort via command line.

                      1 Reply Last reply Reply Quote 0
                      • V
                        vizavi
                        last edited by

                        Hello all
                        Steps worked for me :
                        Install Snort.org rules - Do NOT Install
                        Resolve Flowbits  - Unchecked

                        ( So Emerging Threats rules only )

                        rm /usr/local/lib/snort/dynamicrules/*
                        Start. Working!

                        1 Reply Last reply Reply Quote 0
                        • bmeeksB
                          bmeeks
                          last edited by

                          @dwood:

                          Also, Snort continues to block WAN connections, even with interfaces disabled in the snort GUI.  You need to uninstall it, or kill snort via command line.

                          I submitted a request for the main developer to take a look at this problem.  Apparently the Spoink plug-in used to perform the actual blocking on pfSense is not correctly parsing the whitelist file of IP addresses.  At least that is the source of the error messages in the log upon startup saying a "…non IP parameter was detected and skipped..." in the whitelist.

                          Bill

                          1 Reply Last reply Reply Quote 0
                          • bmeeksB
                            bmeeks
                            last edited by

                            @vizavi:

                            Hello all
                            Steps worked for me :
                            Install Snort.org rules - Do NOT Install
                            Resolve Flowbits  - Unchecked

                            ( So Emerging Threats rules only )

                            rm /usr/local/lib/snort/dynamicrules/*
                            Start. Working!

                            For those of you that are NOT Snort VRT rule subscribers, the only fix for now is to NOT use the Snort rules and use just Emerging Threats until the 30-day window elapses and the VRT "registered user" rules version up to 2.9.4.1.  I did some Google research, and this seems to be a common issue with each version update of the Snort binary.  The Shared Object rules can get recompiled to work only with a newer dynamic rule library.

                            Bill

                            1 Reply Last reply Reply Quote 0
                            • S
                              Supermule Banned
                              last edited by

                              Aint that nice…............ :(

                              1 Reply Last reply Reply Quote 0
                              • bmeeksB
                                bmeeks
                                last edited by

                                @Supermule:

                                Aint that nice…............ :(

                                Yeah, but I guess from the point of view of the Snort VRT, this is a "carrot" to entice folks to buy subscriptions instead of using the free registered user rules.  To stay current with the rules, they drive you to the subscription model.  Can't really fault them for that.

                                There is not much that can be done on the pfSense side except to fall back to the older 2.9.4.0 binary.  There are down sides to that as well.

                                1 Reply Last reply Reply Quote 0
                                • S
                                  Supermule Banned
                                  last edited by

                                  Its understandable, but very frustrating from the enduser perspective…. :(

                                  1 Reply Last reply Reply Quote 0
                                  • bmeeksB
                                    bmeeks
                                    last edited by

                                    I found the bug that is causing the whitelist parsing failure in 2.9.4.1 and the error messages saying "…non IP() parameter found...".

                                    A misplaced call to clear memory in the Spoink plug-in is the culprit.  The buffer is being initialized AFTER being filled with data instead of BEFORE being filled with data to parse.  The function in the Spoink plug-in then calls a Snort API to parse the IP address data.  Because it inadvertently zeroes out the buffer prior to the Snort API call, then Snort returns a parsing error because there is nothing to parse.  The end result is the whitelist does not get populated, and thus WAN IPs get blocked.

                                    Here is the errant code snippet:

                                    	while((ret = s2c_parse_line(cad, wfile)) != 0) {
                                    	              memset(cad, 0, WLMAX);
                                    		if (ret == 1) {
                                    			ipw = malloc(sizeof(struct ipwlist));
                                    			if (ipw == NULL) {
                                    				ErrorMessage("Could not allocate memory");
                                    				continue;
                                    			}
                                    			if (sfip_pton(cad, &ipw->waddr) != SFIP_SUCCESS) {
                                    				ErrorMessage("Non ip(%s) parameter passed with white list, skipping...", cad);
                                    				free(ipw);
                                    				continue;
                                    			} // else
                                    				//printf("IP(%s) parsed succesfuly", cad);
                                    
                                    

                                    Notice the memset() call immediately after the while() statement.  That is zeroing out the buffer containing the IP address to be parsed.  The memset() function call should be BEFORE the while() statement instead of AFTER.

                                    Bill

                                    1 Reply Last reply Reply Quote 0
                                    • S
                                      Supermule Banned
                                      last edited by

                                      Have you sent this to Ermal?

                                      1 Reply Last reply Reply Quote 0
                                      • bmeeksB
                                        bmeeks
                                        last edited by

                                        @Supermule:

                                        Have you sent this to Ermal?

                                        Yes.  I have not received a reply yet, but he and I are in vastly different time zones and he may not have seen the note yet.

                                        1 Reply Last reply Reply Quote 0
                                        • S
                                          Supermule Banned
                                          last edited by

                                          Allright mate!! You doing a hell of a job for the rest of the community!

                                          1 Reply Last reply Reply Quote 0
                                          • D
                                            dwood
                                            last edited by

                                            bmeeks…very impressed with your debugging abilities :-)  As a guy who coded a long time back, it's refreshing to see someone who can get under the hood and ID issues so quickly.

                                            Cheers,
                                            Dennis.

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