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!

Brilliant, a firewall reboot dealt with it.  Navigating away did not remove the dirty file.  Might be useful if there were some sort of 'purge' facility available for handling unwanted pending changes. Regards, Rob.

If you pasted in your Oinkcode and are not getting errors, then you are getting the subscriber rules.  The Snort web site picks the rules based on the Oinkcode supplied as part of the rules download URL.  The Snort package on pfSense generates that URL for you behind the scenes using the Oinkcode you provide on the GLOBAL SETTINGS tab. Other than trusting that, you could manually verify by looking at the Snort VRT rule update release notes and verifying that any newly posted or modified rules show up that way on your box.  You can examine the text of individual rules on the RULES tab for an interface (only the rules from the categories you have selected will display, though). Bill

I've posted a comment on another thread, but I thought it would be useful to post it here. As stated above I am using a Gigabyte motherboard which uses Realtek gigabit chips, which were giving me problems on the WAN. I added an expansion card with Intel chips to try to resolve the problem (which it did) and it also had the side effect of eliminating my problems with Snort! The network issue was that my WAN interface uses PPPoE and this would fail after 3-4 days and I would need to reboot pfSense.

yup very common stuff..  You have to keep in mind when you turn on something like snort..  There is going to be lots and lots of noise ;)  you really have to tweak the rule sets to look for the stuff that is actual concern..  And then once you do that you might not see anything… Other than as a learning tool, I don't see much use for a ids in a home setup..  Unless you do manage to let one of your machines get infected pretty much all your going to see is noise..

You're welcome.  The thanks is really due to the guys in that linked thread who found the cause and fix.  If I recall correctly, Suricata upstream fixed a bug in that part of the code.  The fix then made installs that formerly worked (incorrectly it turns out, but they would start anyway) stop working and throw the memory allocation error. Bill

@Snailkhan: i am also receiving these alerts but the source address is the wan address of my pfsense assigned via ppoe one of the destination ip belongs to akamai technologies.. and others cannot resolve. If you run Snort or Suricata on the WAN interface only, then you can not see your internal LAN IP addresses in alerts because the Snort daemon sees everything after the outbound NAT rules are applied (and before incoming traffic is "un-NAT'd").  For this reason, many home users prefer to run Snort or Suricata on the LAN interface.  Here, the IP addresses are seen pre-NAT when outbound and post-NAT when inbound.  This makes it easy to identify internal hosts. Bill

Thank you for taking time to clarify this for me.

Correct, this was a Windows 10 machine. The "offending" process was svchost.exe and the IP resolved to Akamai Technologies.

A reinstall removes it and puts it back.  For some reason, in your case, the "puts it back" appears to be failing.  It is removed because when Snort is removed, the widget is useless and can even cause errors because the underlying supporting package is gone. Bill

Thank you so much David for your response. I will give it a try…. thanks again for your help.

@bmeeks: You really do not have enough RAM in that firewall to reliably run Snort.  You are getting this random behavior most likely because you are running out of memory and RAM Drive disk space.  On a Nano-based system, some of your 1 GB of RAM is used to provide the /tmp and /var disk partitions.  That further limits the free RAM available to Snort.  Also, with only 1 GB of RAM to start with, those two RAM Disk partitions are going to be a bit tight when it comes to holding the rules tarball files during updates and even when downloading and extracting the PBI package files on installs.  When you exhaust the /tmp or /var partitions during package installation, weird and random stuff can happen.  I suspect its working when you wipe the settings out because then it is not exhausting RAM during reinstallation when trying to restore the saved settings and download all the previously selected rules at once. The same Snort package has run uninterrupted for months on my firewall with three active interfaces and quite a few rules.  I have never had an issue with a Snort upgrade.  My firewall has a 40 GB conventional hard disk and 16 GB of RAM.  Prior to this one, I had a box with 4 GB of RAM and never had any issues there either.  You need lots of RAM and plenty of disk space for logging to reliably run Snort and Suricata.  NanoBSD is just not a good platform for running these two packages.  I'm not saying it can't work if you through enough RAM at it, but most NanoBSD installs don't have a lot of RAM. Bill snort was running fine for another 35+ hours .. besides i also added freeradius (it would hardly authenticate 3-5  users in the entire day ). and was working fine.. however i got 2gb ddr2 ram for my box (thats its max support. as its single port) and still all is ok .. though i havent enabled the emerging threats .. though i increased space of /var /tmp to 150 MB .. as i fear it will again break things and i would have to remove snort redo all configs. 32gb ssd is being shipped from china via slow boat. waiting for it to do a full blown installation