Snort 2.9.4.1 pkg v.2.5.8

shinzo

@shinzo:

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

masli

@bmeeks:

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

Supermule

Apparently Shinzo allready posted the update and the Core team has pushed the update.

bmeeks

@Supermule:

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

Craigusoz

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..

bmeeks

@Craigusoz:

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

Craigusoz

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 :-[ )

bmeeks

@Craigusoz:

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

Craigusoz

OK, thanks again - that's very helpful also.

Holger

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

eri--

Yes with WAN you will see all carp related traffic since interface is in promiscuous mode.

Holger

@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… :)

Mr. Jingles

@shinzo:

@shinzo:

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

traxxus

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.

Supermule

Nope

sensemann

@bmeeks:

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!

bmeeks

@sensemann:

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

choodee

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

bmeeks

@choodee:

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

NetDefense

@shinzo:

@bmeeks:

@shinzo:

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 again

If 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. :(