Snort 2.9.4.1 Pkg 2.5.4 – Fix for SO rules version mismatch and failed startup
-
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! -
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
-
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
-
Aint that nice…............ :(
-
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.
-
Its understandable, but very frustrating from the enduser perspective…. :(
-
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
-
Have you sent this to Ermal?
-
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.
-
Allright mate!! You doing a hell of a job for the rest of the community!
-
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. -
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.Thanks, but I must admit I stared at that code for like an hour and did not see the bug. I knew it had to be there somewhere, and finally I noticed the misplaced memset() call. After that it was like … Doh!! ... why didn't I see that first thing ?? :D
Bill
-
Please let us know when it will be fixed.
So we can pull new package.
Thanks a lot for all efforts -
Please let us know when it will be fixed.
So we can pull new package.
Thanks a lot for all effortsI have submitted a Pull Request via GitHub that contains a fix for the whitelist parsing issue. The pfSense developers have to accept my patch into the packages repository and then compile it into the new binary for Snort. Changes to the binary are a bit more involved to publish than changes to the GUI code.
Bill
-
Any news on this ?
-
waiting as well for this.
-
Any news on this ?
My Pull Request for the Spoink patch was accepted, but so far it has not been incorporated into a new build of the binary as far as I can tell. I don't know what the process is nor the timeline for the binary side. On the GUI side, once a Pull Request is accepted by the Core Team it is immediately available for download. I know the binaries have to be built, but I don't know if that is automated (I think it is) or a human has to intervene.
Bill
-
Just uninstall , then install package.
It looks like is NOT rebuilt yet , I see my WAN blocked . :(
(Snort 2.9.4.1 Pkg 2.5.4 , Emergingthreats rules only )
Thanks -
I reported that to Bmeeks some time ago since I saw my WAN blocked as well. It must be the implementation of Snort into PFsense that is causing this behaviour…
-
I found my WAN blocked yesterday. I removed the block, but it came right back. Restarted the service and it has been running fine since. Never saw this before upgrading to Snort 2.9.4.1.
If it matters, I do have the paid VRT rules. (Well worth $2.50/month. I think it's a good value and money worth spent)