Multiple instances happens sometimes when the pfSense core code sends more than one "restart packages" command in a short time interval.  This can happen, for instance, during a WAN IP update caused by DHCP (if you have that configured on the WAN side).  There are a few other triggers of the "restart packages" command.

Bill

Hi guys, this topic really helped me, but in my case the solution was create two databases, one for each Barnyard instance (i have two monitored interfaces), no more "Duplicate entry" now, thanks!

Finaly i found the solution. I have create a supress list and then apply to the interface then restart snort. I have find a youtube video.

@bmeeks:

You could safely disable that rule if you wish.

Bear in mind that if you decide to allow HTTP traffic on 443, all the rules with $HTTP_PORTS wont be inspecting that traffic. Unless you add 443 to the $HTTP_PORTS variable, which will cause other false positive with some HTTPS inspection. In other word, the way alot of rules are made, HTTP, non encrypted traffic,  shouldnt be on 443

F.

Thanks for your reply.

That makes perfect sense. Hadn't thought it through enough…

Happy Holidays,
John

Hi
Thank you for the reply,
Well…did not really understand on what you mean I been trying to follow this guide
http://www.moh10ly.com/blog/pfsense/configuring-snort-on-pfsense

All I would want lets say i open port 443 webgui and someone tries to access many times eventually it gets blocked that IP as it shows on the guide But i was not able to get it working.

Not sure if I add all the rules?

And not sure what is this unknown rule http inspect

See pics

Thanks you

Clipboarder.2015.12.25-002.png
Clipboarder.2015.12.25-002.png_thumb
Clipboarder.2015.12.25-003.png
Clipboarder.2015.12.25-003.png_thumb
Clipboarder.2015.12.25-004.png
Clipboarder.2015.12.25-004.png_thumb
Clipboarder.2015.12.25-005.png
Clipboarder.2015.12.25-005.png_thumb
Clipboarder.2015.12.25-006.png
Clipboarder.2015.12.25-006.png_thumb

Good to know!

I have disabled those rules for now but I feel there is still some cleanup to do before I get snort running smoothly and not act crazy on every bit that comes & go from my LAN.

Another think for people micromanaging the rules:  we can remove "Enable/Disable" changes in the current Category, remove all Enable/Disable changes in all Categories (good if you want to return to the stock ruleset), disable all rules in the current Category, enable all rules in the current Category (those two are good to enable/disable all rules quickly), but there is a missing filter to display only specific sets of rules, for example all rules that were manually disabled or enabled, all rules currently disabled or enabled, etc… and a filter to search rules by SID would be great as well... especially during a fatal error..

No problem here in the USA with Snort VRT updates.  Here is the log output from just after midnight Eastern Standard Time today –

Starting rules update...  Time: 2015-12-23 01:30:01 Downloading Snort VRT rules md5 file snortrules-snapshot-2976.tar.gz.md5... Checking Snort VRT rules md5 file... There is a new set of Snort VRT rules posted. Downloading file 'snortrules-snapshot-2976.tar.gz'... Done downloading rules file. Downloading Emerging Threats Open rules md5 file emerging.rules.tar.gz.md5... Checking Emerging Threats Open rules md5 file... There is a new set of Emerging Threats Open rules posted. Downloading file 'emerging.rules.tar.gz'... Done downloading rules file. Extracting and installing Snort VRT rules... Using Snort VRT precompiled SO rules for FreeBSD-10-0 ... Installation of Snort VRT rules completed. Extracting and installing Emerging Threats Open rules... Installation of Emerging Threats Open rules completed. Copying new config and map files... Updating rules configuration for: WAN ... Updating rules configuration for: DMZ ... Updating rules configuration for: LAN ... Restarting Snort to activate the new set of rules... Snort has restarted with your new set of rules. The Rules update has finished.  Time: 2015-12-23 01:30:54

Could be (or could have been) a temporary condition.

Bill

That's not really ideal to be honest :(, but thank for the idea!

It's really really annoying that Snort can't do this easily

The alerts are just DNS queries for .pw and .su domains. Often related to torrents webpages, like piratebay.su. You also need to make sure your dns servers, specially 8.8.8.8 is in your HOME_NET of your Snort interface, otherwise if you chose block offenders and select "both" in the which IP to block, your DNS server will get block with those alerts, therefore not allowing any external DNS…. Check if your DNS servers are in the blocked tab of your snort interface.

As for the SNMP, make sure your firewall is configure with some permission to access this service, only allowing your specific IP.

F.

Not familiar with the product but with Suricata you can block using TLS/SSL cert/fingerprint info
https://redmine.openinfosecfoundation.org/projects/suricata/wiki/TLS-keywords

OR with File magic you can intercept PGP key exchange, if they dont use TLS.

Or you could block .chat domain name request…

Shouldnt be too hard to block another chat service...

F.

First I would check if Snort actually see HTTP Port 80 traffic and in which direction.

Rune these two custom rules just to make sure the traffic is inspected/seen

alert tcp $EXTERNAL_NET 80 -> $HOME_NET [1024:] (msg:"Incoming HTTP Port 80 Traffic"; metadata:service http; classtype:policy-violation; sid:72171001; rev:1;) alert tcp $HOME_NET [1024:] -> $EXTERNAL_NET 80 (msg:"Outgoing HTTP Port 80 Traffic"; metadata:service http; classtype:policy-violation; sid:72171002; rev:1;)

You can even test AppID with this rule

alert tcp $EXTERNAL_NET 80 <> $HOME_NET [1024:] (msg:"appID HTTP On Known Port"; appid: http; classtype:policy-violation; sid:72171002; rev:1;)

If these rules triggers when surfing HTTP, not encrypted traffic on port 80, then everything is working…if not, maybe your EXTERNAL, HOME, or HTTP port arent set properly..

F.

Its a good question basically you want to add a noalert into the IP preprocessor rule. Something you could ask the Snort mailing list; is it possible to drop with a no alert with the IP preprocessor?

Also, pfblocker might be the solution, leave the packet payload inspection to your IDS, and all ports or IP blocking to the firewall, PF… This is what I do.

F.

Service Watchdog has problems with Snort in several areas.  First up, if you have more than one Snort interface, then you have multiple Snort instances and Service Watchdog gets fooled (it will see one Snort service running and thinks all is well when in fact every interface but one might be down).  Second, Snort is stopped by the rules update process to load new rules.  The Service Watchdog sees Snort down and restarts it quickly.  If the rules update is also trying to restart Snort, then you can wind up with multiple duplicate instances (two Snort processes on the same interface, for example).

Have you seen this random stopping since the last Snort binary update?  I seem to recall a bug fix by the Snort guys to address a segfault error (or maybe that was Suricata… I get the release notes confused sometimes  :().

Bill

@jeffh:

@bmeeks:

These two options will be available in the next Snort update which I'm working on now.  Should be ready in a few days. The options will be included as part of the HTTP_INSPECT window that opens when you edit an HTTP Server configuration from the PREPROCESSORS tab.

Bill

Thanks! One question, why leave these options unchecked by default? Is it due to potential performance hits or is there something else that should be considered before enabling?

No particular reason other than since they were never there before, they were sort of by default "unchecked".  In retrospect I probably should have defaulted them to "checked" and will do so in the next update.

Bill

I would be very happy with this actually. I have quite a bit of traffic going through some pfSense boxes and suricata struggles considerably when under very heavy traffic loads.
Especially under conditions like a (fairly small scale) ddos where the volume is still below the line speed limit, suricata is simply not able to keep up with the number of packets it needs to process. Even a pretty low budget GPU will allow for a significant amount of processing to be offloaded to it. This option is considerably cheaper than having to upgrade the whole box to get faster and/or more CPU cores.

Thanks BB, I'm still leaning towards PfBNG. Content filtering is getting harder due to the HTTPS nature of things, so lists of domains + cron jobs from pfBNG will fit nicely. Yes I've heard the same about ClamAV not being very good, but hey, it's better than nothing, and it still helps in a multi-layered approach.

I'll throw pfBNG onto a test install of pfSense and go from there. Appreciate the info!