Snort 2.9.4.1 pkg v.2.5.8
-
So funny thing happend, from what i can make out from the logs. Snort rules updated last night. After that it ran the snortstart and it stopped running. Nothing in the logs showed me why it wasnt working but i typed snort into the command line and its giving me a
"/libexec/ld-elf.so.1" shared object "libpcap.so.1" not found, required by snort." So i can only assume the shared object ran off some where :P and no i didn't delete it
To continue my story, i found out what deleted it. bandwidthd was maxing out my cpu the other day so i figured i remove it. When i uninstalled it, it took the libpcap file with it too, i reinstalled bandwidthd but left it disabled and snort is running fine again
-
So funny thing happend, from what i can make out from the logs. Snort rules updated last night. After that it ran the snortstart and it stopped running. Nothing in the logs showed me why it wasnt working but i typed snort into the command line and its giving me a
"/libexec/ld-elf.so.1" shared object "libpcap.so.1" not found, required by snort." So i can only assume the shared object ran off some where :P and no i didn't delete it
To continue my story, i found out what deleted it. bandwidthd was maxing out my cpu the other day so i figured i remove it. When i uninstalled it, it took the libpcap file with it too, i reinstalled bandwidthd but left it disabled and snort is running fine again
The new PBI package management system in 2.1 eliminates these issues. Each package has the equivalent of its own chroot jail, so to speak, where its executables and libraries go.
Bill
-
Not trying to get the thread off topic, but just FYI.
I have submitted the Pull Requests to the Core Developer Team for updating the Snort package to 2.9.4.6 pkg version 2.5.9. This will update the Snort binary to the current 2.9.4.6 code. The 2.5.9 GUI package update fixes a couple of bugs and introduces Host Attribute Table support along with configurable rule update start times (an often asked for feature).
The full details can be seen here for the GUI: https://github.com/pfsense/pfsense-packages/pull/461 and here for the binary: https://github.com/pfsense/pfsense-tools/pull/122
I will start a new thread on this version when it is approved and posted.
Bill
-
Thanks Bill!!!
-
yay updates, I look forward to all the updated features.
I have a question, i see the version that snort is using for libpcap,pcre,zlib versions aren't the newest. Is there any benefits to compiling them with the newest ones? Was just curious thank you
-
yay updates, I look forward to all the updated features.
I have a question, i see the version that snort is using for libpcap,pcre,zlib versions aren't the newest. Is there any benefits to compiling them with the newest ones? Was just curious thank you
On the 2.0.x platform Snort has to work as harmoniously as possible and utilize the libraries shared with other packages. On the 2.1 platform with PBI, that's not an issue. So for now, with the Snort package supported on both 2.0.x and 2.1, the slightly older libraries are used. Once everything is just 2.1 with PBI, then each package can use its own library versions.
In my testing with 2.9.4.6 I've seen no issues with the current library versions.
Bill
-
yay updates, I look forward to all the updated features.
I have a question, i see the version that snort is using for libpcap,pcre,zlib versions aren't the newest. Is there any benefits to compiling them with the newest ones? Was just curious thank you
On the 2.0.x platform Snort has to work as harmoniously as possible and utilize the libraries shared with other packages. On the 2.1 platform with PBI, that's not an issue. So for now, with the Snort package supported on both 2.0.x and 2.1, the slightly older libraries are used. Once everything is just 2.1 with PBI, then each package can use its own library versions.
In my testing with 2.9.4.6 I've seen no issues with the current library versions.
Bill
makes sense. Thank you
-
Not trying to get the thread off topic, but just FYI.
I have submitted the Pull Requests to the Core Developer Team for updating the Snort package to 2.9.4.6 pkg version 2.5.9. This will update the Snort binary to the current 2.9.4.6 code. The 2.5.9 GUI package update fixes a couple of bugs and introduces Host Attribute Table support along with configurable rule update start times (an often asked for feature).
The full details can be seen here for the GUI: https://github.com/pfsense/pfsense-packages/pull/461 and here for the binary: https://github.com/pfsense/pfsense-tools/pull/122
I will start a new thread on this version when it is approved and posted.
Bill
Glad to hear this
-
Apparently Shinzo allready posted the update and the Core team has pushed the update.
-
Apparently Shinzo allready posted the update and the Core team has pushed the update.
Yes, they were very fast to approve and push. Haven't had time yet to create the Change Log (thanks to Shinzo for doing this for me!) and post some screenshots of the changes.
Bill
-
A third-party plug-in called Spoink
This is probably a silly question, but searching hasn't (yet) found me a definitive answer - are alerts automatically blocked by the Spoink / pf mechanism even if no blocking is turned on in snort's gui ?
Thanks..
-
A third-party plug-in called Spoink
This is probably a silly question, but searching hasn't (yet) found me a definitive answer - are alerts automatically blocked by the Spoink / pf mechanism even if no blocking is turned on in snort's gui ?
Thanks..
No, if "Block Offenders" is not checked on the If Settings tab for the interface in the Snort GUI, no blocking will occur. You will see Alerts, but remember that in the pfSense implementation an "alert" does not automatically equate to a "block". Alerts are simply read from the log and displayed to show a detected event that matched a rule. The Spoink plugin also sees these "alerts" and compares the IP addresses in them to its Whitelist of "never block IP addresses". If blocking is enabled for the interface, and the IP is not in the Whitelist, then the IP is added to the block table in the firewall.
Bill
-
Thanks Bill, that explains things perfectly.
Another question if I may - if I'm running snort on the WAN interface, I should choose DST rather than SRC in the block offenders option, yes?
(I think last time I did this, I chose SRC, which caused all internet traffic incoming to the WAN interface to be blocked :-[ )
-
Thanks Bill, that explains things perfectly.
Another question if I may - if I'm running snort on the WAN interface, I should choose DST rather than SRC in the block offenders option, yes?
(I think last time I did this, I chose SRC, which caused all internet traffic incoming to the WAN interface to be blocked :-[ )
[/quote]
I have SRC set on my WAN. With a properly constructed Whitelist containing your WAN IP, your WAN IP itself will never be blocked but the "bad guys" sending traffic your way will be. That is generally what we want – the bad guys locked out. If a "good guy" is misclassified as a "bad guy" due to some anomaly in their traffic that matches a Snort rule, we call that a "false positive". Those are what the Whitelist can also be used for. You can whitelist known "good guys" so they are never blocked.
You might also get a lot alerts (and potentially blocks) from preprocessor rules that normalize and validate traffic such as HTTP, SSL, FTP, etc., before passing it along to the other rules. If a preprocessor finds something it does not like in the packet stream, it can also raise an alert (and potentially a block). The HTTP_INSPECT preprocessor is famous for this. The Suppression List can help here. If known "good guy" web sites are frequently blocked by an overly cautious and strict preprocessor rule, the Generator ID and Signature ID (gid:sid) of the alert can be added to the Suppression List. This will stop future logging (and blocking) of the event. Use this with care, though.
Bill
-
OK, thanks again - that's very helpful also.
-
Hi,
i have one, maybe stupid, question…
My goal is to migrate our iptables firewall to pfsense with snort filtering.
In our configuration we have several carp interfaces based on one physical wan interface.In the snort interface configuration i can only choose between the "physical interfaces".
The dropdown does not show any of the carp (vip) interfaces.What happen when i choose the phyical wan interface for snort filtering?
Will the incoming traffic on the carp interfaces will be filtered too?Thanks
Holger
-
Yes with WAN you will see all carp related traffic since interface is in promiscuous mode.
-
@ermal:
Yes with WAN you will see all carp related traffic since interface is in promiscuous mode.
Thanks, then snort works perfect for my needs… :)
-
So funny thing happend, from what i can make out from the logs. Snort rules updated last night. After that it ran the snortstart and it stopped running. Nothing in the logs showed me why it wasnt working but i typed snort into the command line and its giving me a
"/libexec/ld-elf.so.1" shared object "libpcap.so.1" not found, required by snort." So i can only assume the shared object ran off some where :P and no i didn't delete it
To continue my story, i found out what deleted it. bandwidthd was maxing out my cpu the other day so i figured i remove it. When i uninstalled it, it took the libpcap file with it too, i reinstalled bandwidthd but left it disabled and snort is running fine again
Thank you, Kinzo, that did the trick for me too :P
-
HI
I have massive problems with lags in onlinegaming (computer).
Is it normal that snort generates massive lags?
The CPU is on max 1% load, memory on 20% load.
