Snort 2.9.4.1 pkg v.2.5.8
-
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. -
Nope
-
P.S. – while you can do it, it would be sort of pointless and a waste of resources to run a duplicate set of rules on both the WAN and LAN interfaces in a scenario like I described. I prefer the setup where known bad hosts are blocked right away at the perimeter (the WAN). I get this from those ET-CIARMY and RBN rules. Then my LAN side interface is the next layer of protection and contains the richer rule set.
Bill
Hi Bill, could you please give me a close hint how to configure the WAN and LAN iface with different rules, especially where to get and how to enable this lists.
Thanks!
-
Hi Bill, could you please give me a close hint how to configure the WAN and LAN iface with different rules, especially where to get and how to enable this lists.
Thanks!
First, make sure you are running the latest version of the Snort package. That is 2.9.7.0 pkg v3.1.3. I highly recommend you also upgrade to pfSense 2.2 if you have not already.
Have you checked out this sticky thread? https://forum.pfsense.org/index.php?topic=61018.0
There are instructions within that thread on how to obtain and configure rules. If you still need help after reading the sticky post, then please start a new message thread in the Packages sub-forum. This particular thread is quite old.
Bill
-
Hi Bill, I don't see the purpose of running snort on the WAN interface if I already have Snort running on the LAN interface. Assuming i don't have any services port forwarded, doesn't pfsense default firewall already prevent all incoming connections to the WAN interface anyway? And if I do have port forwarded rules setup on the WAN interface, won't Snort on the LAN interface take care of this as well?
Thanks
-
Hi Bill, I don't see the purpose of running snort on the WAN interface if I already have Snort running on the LAN interface. Assuming i don't have any services port forwarded, doesn't pfsense default firewall already prevent all incoming connections to the WAN interface anyway? And if I do have port forwarded rules setup on the WAN interface, won't Snort on the LAN interface take care of this as well?
Thanks
You are correct. With no running services (open ports) on the WAN side, Snort will prove more useful on the LAN interface (and DMZ interface if you have one of those).
Bill
-
I also wanted to ask something about what i read the other day.
Would it be better to have 1 wan interface with the wan ip and lan address or separate them and have 1 wan and then 1 lan? and thanks againIf we are talking about a typical home network with NAT, then it depends on whether or not you want to identify specific hosts on the LAN side. Here's what I mean. When you have NAT, then Snort sees everything on the WAN in terms of your WAN IP address and then whatever Internet hosts are being contacted. Snort does not see the internal LAN private IPs. It will still block offending traffic by blocking the SRC (assuming you have that configured for the WAN interface). But the logs will show everything in the local network as having the WAN IP address.
So if you want to see your LAN private IP addresses in the logs and thus be able to identify which specific LAN host might contain the latest nasty online banking Trojan, then you would run an instance of Snort on your LAN interface. This is what I do. I have Snort on the WAN configured with some basic ET-CIARMY and ET-RBN rules, then run the Snort VRT IPS-Balanced policy on my LAN interface. I configured my LAN interface to block BOTH (source and destination). The auto-whitelisting feature that adds the LAN to the whitelist means my LAN IPs never get blocked, but if any LAN IP tries to "phone home" to a BOT C-n-C server on the web, then the DST would get blocked because of the BOTH setting. So I am protected either way (whether my LAN host initiates the conversation or the far-end host does). Plus, my logs now show me the internal LAN private IP of the infected or potentially infected host.
P.S. – while you can do it, it would be sort of pointless and a waste of resources to run a duplicate set of rules on both the WAN and LAN interfaces in a scenario like I described. I prefer the setup where known bad hosts are blocked right away at the perimeter (the WAN). I get this from those ET-CIARMY and RBN rules. Then my LAN side interface is the next layer of protection and contains the richer rule set.
Bill
Can you help me with this? This is the exact setup I need to emulate. Even down to the single WAN and single LAN interface. Seems easy enough to just set up the LAN interface with VRT configs but it seems you have a specific config on the WAN interface? I don't even know what ET-CIARMY and RBN are. :(
-
OK I did some digging and figured that out. Your post now makes sense to me now that I know what emerging threats is.
I did notice this post is kind of old and when I take a look at the RBN rules and it appears they are no longer updated. http://doc.emergingthreats.net/bin/view/Main/RussianBusinessNetwork
-
OK I did some digging and figured that out. Your post now makes sense to me now that I know what emerging threats is.
I did notice this post is kind of old and when I take a look at the RBN rules and it appears they are no longer updated. http://doc.emergingthreats.net/bin/view/Main/RussianBusinessNetwork
The RBN list has been discontinued for awhile now… The only two free lists available from Emerging Threats (now Proofpoint) is ET Compromised and ET Block.... With the ET IQRisk suite (Paid subscription) they have an IPRep list available...
