Snort Pkg 2.6.1 ??
-
Bill … You had made mention of the 2.6.1 package update a couple of times. Just wondering what the status is?
https://github.com/pfsense/pfsense-packages/pull/529
Thanks!
-
A good bet is that he is waiting for the "never" issue of snort clearing the blocked list every now and then…
2.1 has the issue and 2.0.3 didnt. That could be the reason for delay.
-
A good bet is that he is waiting for the "never" issue of snort clearing the blocked list every now and then…
2.1 has the issue and 2.0.3 didnt. That could be the reason for delay.
Unfortunately that's the not reason. Ermal and the Core Team guys have apparently been quite busy for the last week or so and just have not gotten around to reviewing and approving the Pull Request for the 2.6.1 package. I got an e-mail from Ermal a couple of days ago saying he was looking at the new version and to give him a couple more days.
As for the block clearing issue, that can only be fixed in a pfSense update. I have no information on when that might happen.
Bill
-
Glad to be corrected Bill!!
Thumbs up for the great work and the revival of Snort integration into PFSense!
-
Glad to be corrected Bill!!
Thumbs up for the great work and the revival of Snort integration into PFSense!
A lot more functionality is coming in the 3.0.0 package for preprocessors. In addition, the binary will be updated to 2.9.5.5. The big thing coming next is the ability to have multiple and unique server/network configurations for the frag3, stream5 tcp, http_inspect, ftp client and ftp server preprocessors. Snort itself has had this ability for a long time, but the GUI package on pfSense never supported it. You could only change some global settings and then the default server/network engines for these preprocessors. Now you will be able to create different profiles for different servers. For example, Apache profiles for web servers on some IPs or subnets and IIS profiles for other servers on other IPs or subnets. Same for the other preprocessors mentioned. Attached is a sample screenshot for the http_inspect preprocessor showing the mandatory default engine and one other unique one.
The name can be anything you want. The Bind-To Address Alias is a pfSense Alias you define. You can use the little up-arrow icon to import existing defined host or network Aliases into the preprocessor as server configurations. You can also use the other icons to add a new one directly or edit parameters for an existing configuration. When you click the edit icon, you are taken to a new page where all of the server-specific settings for http_inspect are configured. The ones shown below in the screenshot are just the global settings that apply to all servers configured under http_inspect. This same scheme is repeated for the other preprocessors mentioned above.
Bill
 -
When loading both LAN and WAN rules, things seem to be loaded twice into memory. Why??
-
When loading both LAN and WAN rules, things seem to be loaded twice into memory. Why??
Because the package and compiled binary today do not support the relatively new "shared memory" feature introduced a while back into Snort. Each interface defined is a totally separate and autonomous Snort instance, so you duplicate the memory requirements (assuming both interfaces have the same or similar rules).
Does that explain what you are seeing, or did I misunderstand your question?
Bill
-
It explains it perfectly! Could it be changed so rules can be defined over multiple vlans as well without crashing Snort because of memory hogging?
-
It explains it perfectly! Could it be changed so rules can be defined over multiple vlans as well without crashing Snort because of memory hogging?
I will look into the new shared memory feature in the binary and see if it can work on FreeBSD and pfSense. Also need to research it to see exactly how it works. It may require that all interfaces/instances use the exact same rules, for example. If that is the case, its usefulness might be diminished a bit because most folks do not run the exact same rules on all interfaces.
Bill
-
I agree Bill, but it would make it a lot more usable on a perimeter firewall doing a lot of Vlans!
-
I agree Bill, but it would make it a lot more usable on a perimeter firewall doing a lot of Vlans!
That is exactly what I was hoping to use this for in the very near future. Hadn't considered the fact that the memory requirements would be outrageous with 40+ vlans…!
These VLANs would have pretty much identical rules on most of them, so if that was a limitation of the shared memory feature, it wouldn't be a problem.
I am also very much looking forward to pull #529 being merged. Thanks so much bmeeks, ermal, and the core team.
-
I looked into the Shared Memory feature in the Snort binary. Unfortunately that is only used for Reputation Lists. These are text files containing blacklist/whitelist IP addresses (one file for each type). The Shared Memory feature (which it says only works on Linux; don't know specifically about FreeBSD) allows one copy of each Reputation List to be used among a number of Snort instances.
So the Shared Memory feature won't work with text rules, and thus would not help with memory overload.
Bill
