Snort and Interface Enable/Disable
-
If the current package is seeing EOL anyway, then I suggest writing to Ermal or Jim to get them to compile it before it goes EOL.
Pushing for an update to the latest 2.9.4.x Snort binary is my plan. I should finish my PHP code tweaks and have everything posted later today or by the end of the weekend to Github. I will then create the Pull Request to signal Ermal and others on the pfSense team to take a look at my changes.
-
Damn nice mate!! The world would be a fecking nice place to be if populated by folks like you :)
-
Here is a link to the Github Pull Request that has the code changes I am proposing for the Snort package.
https://github.com/bsdperimeter/pfsense-packages/pull/352
The Pull Request has a change log highlighting the major modifications. It also has the modified files with the changes highlighted. Should any of you want to test on your own system, contact me via PM and I can provide the files and instructions for using them. I recommend that any testing be done initially on non-production systems. I have been running the changes on two different pfSense VMs in VMware with no issues.
Bill
-
Here is a link to the Github Pull Request that has the code changes I am proposing for the Snort package.
This pic says its all :)
-
@onhel:
This pic says its all :)
Yeah, the Github summary shows each and every changed or deleted line. Sort of makes it look like more work than it really is.
I would like to recruit a few testers willing to give the changes a shake down in a non-production environment. The changes are super easy to back out if something causes a problem. To implement the changes, you just copy a few files to two folders after renaming the existing target files (to have as backups). No reboot necessary. To back out, just copy the renamed previously existing files (the backups) over top of the new files.
Bill
-
PM Sent
-
@onhel:
PM Sent
Replied at 4:20 PM EST. Thanks for volunteering.
-
Seems to be working with a few caveats.
In testing the memcap setting, the most surefire way I know to trigger the "S5: Pruned 5 sessions from cache for memcap" error was to run a speedtest and max out my bandwidth. I have a 50/5 connection so your recommendation of a 32MB Stream5 memcap was still setting off that error. I raised it to 134217728 (128MB) since I have a lot of free memory and that error is now gone. :)
When I go into the Rules tab, instead of getting the Rules page, I seem to be getting the Github webpage for the Rules code but the web address is still showing as 192.168.1.1:443/snort/snort_rules.php?id=0Redownloaded from GIT and overwrote again and its working now.
Did I copy the file wrong?I also noticed that when I went to Update Rules, it completed successfully but gave an error at the bottom of the screen complaining of a line 9xx in snort.inc. I copied the line to post here but in my excitement of trying to see if Stream5 was fixed I copied some text again and it got overwritten. I've gone back to Update Rules again but I can not reproduce the error that I saw initially, might have to wait for a newer rule update that I can download.
Enabling an interface kicks off this error but System Logs show Initialization Complete and the Interface in fact does Enable.
Warning: is_dir() expects parameter 1 to be string, array given in /usr/local/pkg/snort/snort.inc on line 924 Warning: is_file() expects parameter 1 to be string, array given in /usr/local/pkg/snort/snort.inc on line 926 Warning: is_dir() expects parameter 1 to be string, array given in /usr/local/pkg/snort/snort.inc on line 924 Warning: is_file() expects parameter 1 to be string, array given in /usr/local/pkg/snort/snort.inc on line 926 Warning: Cannot modify header information - headers already sent by (output started at /usr/local/pkg/snort/snort.inc:924) in /usr/local/www/snort/snort_interfaces.php on line 129 Warning: Cannot modify header information - headers already sent by (output started at /usr/local/pkg/snort/snort.inc:924) in /usr/local/www/snort/snort_interfaces.php on line 130 Warning: Cannot modify header information - headers already sent by (output started at /usr/local/pkg/snort/snort.inc:924) in /usr/local/www/snort/snort_interfaces.php on line 131 Warning: Cannot modify header information - headers already sent by (output started at /usr/local/pkg/snort/snort.inc:924) in /usr/local/www/snort/snort_interfaces.php on line 132 Warning: Cannot modify header information - headers already sent by (output started at /usr/local/pkg/snort/snort.inc:924) in /usr/local/www/snort/snort_interfaces.php on line 133 Warning: Cannot modify header information - headers already sent by (output started at /usr/local/pkg/snort/snort.inc:924) in /usr/local/www/snort/snort_interfaces.php on line 136
-
@onhel:
Enabling an interface kicks off this error but System Logs show Initialization Complete and the Interface in fact does Enable.
Warning: is_dir() expects parameter 1 to be string, array given in /usr/local/pkg/snort/snort.inc on line 924 Warning: is_file() expects parameter 1 to be string, array given in /usr/local/pkg/snort/snort.inc on line 926 Warning: is_dir() expects parameter 1 to be string, array given in /usr/local/pkg/snort/snort.inc on line 924 Warning: is_file() expects parameter 1 to be string, array given in /usr/local/pkg/snort/snort.inc on line 926 Warning: Cannot modify header information - headers already sent by (output started at /usr/local/pkg/snort/snort.inc:924) in /usr/local/www/snort/snort_interfaces.php on line 129 Warning: Cannot modify header information - headers already sent by (output started at /usr/local/pkg/snort/snort.inc:924) in /usr/local/www/snort/snort_interfaces.php on line 130 Warning: Cannot modify header information - headers already sent by (output started at /usr/local/pkg/snort/snort.inc:924) in /usr/local/www/snort/snort_interfaces.php on line 131 Warning: Cannot modify header information - headers already sent by (output started at /usr/local/pkg/snort/snort.inc:924) in /usr/local/www/snort/snort_interfaces.php on line 132 Warning: Cannot modify header information - headers already sent by (output started at /usr/local/pkg/snort/snort.inc:924) in /usr/local/www/snort/snort_interfaces.php on line 133 Warning: Cannot modify header information - headers already sent by (output started at /usr/local/pkg/snort/snort.inc:924) in /usr/local/www/snort/snort_interfaces.php on line 136
I think I have found and fixed the errors toward the bottom of your post related to "…headers already sent...". I accidentally moved a section of HTML code into the wrong place in a file. At least I think that's the cause. The file package I just sent you via e-mail will hopefully fix the "…headers already sent..." messages.
As for the Rule Update warning, I will check that one out. I made a last minute change late last night that I might not have thoroughly checked out.
– UPDATE --
I found the problem with the warnings about strings and arrays. It's an easy fix. I'm still new to PHP coding, and I made a newbie mistake by not testing the variable type before passing it to some PHP functions.Bill
-
@onhel:
In testing the memcap setting, the most surefire way I know to trigger the "S5: Pruned 5 sessions from cache for memcap" error was to run a speedtest and max out my bandwidth. I have a 50/5 connection so your recommendation of a 32MB Stream5 memcap was still setting off that error. I raised it to 134217728 (128MB) since I have a lot of free memory and that error is now gone. :)
There is a stream5 configuration parameter available called
prune_log_max [bytes]Setting this to zero is supposed to suppress the logging of those "pruned session" messages. However, I could not get it to work, so I did not include it in my changes. This parameter is designed to set the threshold of logging the pruned messages.
-
Well its definitely gone now that the memcap is above my bandwidth. I always assumed that the memcap should at least be able to deal with the bandwidth coming in as a buffer so being able to set it now is a plus.
-
Ok, so far so good. No errors, no problems and running smooth. Looking at the below pic, Snort Rules Tab, Rule Changed By User, very nice.
-
@onhel:
Ok, so far so good. No errors, no problems and running smooth. Looking at the below pic, Snort Rules Tab, Rule Changed By User, very nice.
Good to hear. Running well so far for me as well on my test machines.
I added the special color-coding for the disablesid and enablesid changes made by the user because I thought at some point down the road folks might want to be able to quickly tell which rules they toggled to enabled or disabled from their default state. There are two small buttons at the top of the page on the right to let you "reset to defaults" the currently selected rule category, or "reset all" to reset all the rules in all categories to defaults. These two buttons just remove all your enablesid/disablesid changes for either the selected category, or all categories, (depending on which button you click).
SID enable/disable modifications should now persist across rule updates and Snort instance stops and starts. Maybe some of the other posters in this thread complaing about this bug will contact me via PM and I can provide them the files to test with so they can test the persistence of enablesid/disablesid changes in this new code.
-
Will do! Very busy at ATM!
-
Package of snort has been update with changes proposed.
If you would like to test just reinstall snort. -
YOU are the CHAMP Ermal!!
-
I get this error….
-
More errors….I uninstalled package and reinstalled to see if it fixed the unicode error reported in the previous post.
It resulted in this...
Stuck on auto-enabling flowbits and error line 375 in /usr/local/pkg/snort/snort_check_for_rule_updates.php on line 375
-
Have you gotten past this error yet, Super?
I'm still running Bill's code without any errors and now that the actual Snort package has been updated, I'm reluctant to upgrade if its going to be a showstopper.
I think a new thread should be started with the appropriate Testing Snort 2.9.2.3 pkg v. 2.5.3 as a title.
-
I deleted the package completely and installed again.
The unicode error went away and SSL_State emerged.
I checked the SSL_State preprocessor and it runs fine! Without the checkbox checked, it crashes…
