@bmeeks: The CPU utilization problem is more likely caused by the IPsec decryption of that video stream.  Snort can't decrypt that traffic to actually look at it. Isn't that what I said? LOL @bmeeks: Snort puts your WAN interface into promiscuous mode, so it will then see any traffic crossing the interface.  With NAT, I prefer to run Snort on the LAN.  That might help in your case, but it depends on your network and what you are protecting behind the various interfaces. Ahh, that makes sense. I might try that. @bmeeks: When you have this spiking problem, have you tried stopping Snort and seeing what happens to CPU utilization then? Sure, the "snort" process in `top' that shows 90% CPU utilization goes away. As one might expect.  :P

thanks a lot guys! The custom rule solution works perfect for me.

@dgall: Thanks for the answers!!! One last question is there a way to see when you updated if the rules are free or paid subscription ? When I log at the view the MANAGE RULE SET LOG I cant see anything that shows that the rules are paid or not. Its probably there but I do not see it. No, you can't tell because the file names from the VRT web site are identical.  Your Oinkcode is read by the VRT rules download server and it decides which package of rules to send down to you.  It gets them from one of two directories depending on "paid" or "free" subscription.  There is nothing you need to do on your end other than disabling the Snort GPLv2 Community Rules if you were using those.  They are already bundled into the paid VRT rules. Bill

Manual installation along with having the GUI interface hooks into pfSense is extremely hard to do.  It requires hand-editing a number of critical files.  However, even if you did that, the new Snort PHP files won't run on 2.0.3 pfSense because they call and use system features that are only available in pfSense 2.1.x and higher. So the short answer is you can't have the GUI with the current Snort PHP package on pfSense versions prior to 2.1.x.  You can manually download and install the old *.tbz package, but you will need to use Snort exclusively from the CLI (command line) like you would if you installed it on a plain-vanilla FreeBSD 8.1 machine.  You will have to create the snort.conf file by hand, download rules by hand, and start-stop Snort from the command-line. Bill

Yes works like a charm

They are simply Base64 encoded.  You can use one of several online tools to convert the string from encoded Base64 to plaintext. Here is one site I found using a quick Google search:  http://www.motobit.com/util/base64-decoder-encoder.asp. The string is Base64 encoded to avoid issues with any XML reserved characters.  You can copy it literally as-is from one config.xml to the other, or if you want to decode it and paste the plaintext into a new Snort GUI window, then use an online Base64 tool like the one I referenced. Bill

Hello, I had a closer look on these settings. Great !  :) Very good and impressive job. Thank you for your answers, Bill. Bye !

Been busy with Suricata lately, havent played with Snort in some time, but you are right. My fault. As of now you cant negate the appID part. But you can negate src, dst, ports as usual. For an example these rules would trigger; alert tcp $HOME_NET any -> $EXTERNAL_NET ![80,8080] (msg:"HTTP Port Unauthorized"; appid: http; classtype:policy-violation; sid:12171008; rev:1;) alert tcp $HOME_NET any -> $EXTERNAL_NET !443 (msg:"HTTPS Port Unauthorized"; appid: https; classtype:policy-violation; sid:12171009; rev:1;) appID is really a work in progress and its not voodoo magic, most of the detection script are just looking for cert, protocol, etc…but I guess thats why they made it Open, it will grow and refine itself pretty fast with the community. Cheers. F.

You can always create some traffic of your own to trigger some of the Snort VRT rules as a test. You can see what rules are actually being enforced if you look in this file /usr/pbi/snort-amd64/etc/snort/snort__{uuid}__{if}/rules/snort.rules where {uuid} is a random number and {if} is the physical interface Snort is running on. The choices are grayed out when you choose a policy because the chosen policy dictates the rules selected.  If you want to overrule that, you can do so on the SID MGMT tab using the features there. Bill

@jeffh: @bmeeks: The memory of the PHP process for Suricata is being exhausted.  That is currently hard-coded for 256 MB in the file /usr/local/pkg/suricata/suricata.inc.  You can edit that file and try bumping up the value. Thanks Bill. Do you happen to know if the Snort package has the same limitation? If so is manually bumping the memory of the PHP process for Snort an option too? Yes, both packages share a lot of the same code.  The parameter is set in the /usr/local/pkg/snort/snort.inc file for Snort. Bill

OK I connected a tunnel from another pfSense box using 2.2.1-RELEASE and another using version 2.0.1-RELEASE ….I get the same result. I can ping from other computers on the remote LAN subnet to computers on the local LAN subnet but not from the pfSense boxes themselves. This should be an IPsec topic not a IDS/IPS topic.  I will start a new thread in the IPsec fourm.

@jeffh: In addition to what Bill said, what I do is run Snort on both WAN and LAN interfaces. On the LAN interface I have blocking disabled and quite a few rules enabled so I can get some visibility into what is happening on my network. On the WAN interface I have blocking enabled and only specific security related rules enabled. All rules that are running on the WAN (in blocking mode) are also running on the LAN (in alert mode). This allows me to block security threats, while still seeing what NAT'd local devices are having their traffic blocked, as well as alert on other rules that may not be security threats or that may have higher rates of false positives. This is the exact same thing that I do and it works great.  It does take a bit more memory and processing power, and a lot more if you're doing barnyard.  I ended up turning the barnyard push notifications off because of this…but with this combination, you get the blocking on the WAN and can then trace it to your internal LAN ip address.

I thought the same as I did find a reference to that while searching the forum. I changed the Web protocol to HTTP but that didn't help… I am not sure what it is.. I have 3 W8.1 machines that do the same thing. If I get some time I'll dig a little deeper. Yes I am very glad and thanks again for your help ...

Thank you for this feedback.  There are some other posts in the Package forum where the advice for Nano users is to bump up the size of /tmp (and possibly /var) because the default partition sizes are too small to download and unzip the ever larger rules tarballs.  Unfortunately, today there is no mechanism within the pfSense Package Manager system for a package to specify prerequisites that must be satisfied in order for the package to be eligible for installation.  Some example parameters that would be useful are installed RAM and free disk space on critical partitions. As a general statement, Snort or Suricata on a NanoBSD install will require a lot of careful attention and quite possibly some customizations such as you describe of increasing the default partition size for /tmp and also /var. Bill

I think it was blocking itself, actually.  Fixed.

set for SRC only @duck - where is the setting you are referring to, I see many preproc's since the upgrade when there was only 1

Yes, if you put Snort or Suricata on the WAN interface of your main office, then the package would see all traffic.  However, if you use NAT, the usefulness of the IDS is diminished a bit in that the only IP addresses you would ever see in the alerts will be those for the far-end Internet host and the WAN IP of your main office firewall.  It would be difficult in that scenario to track which host on your private LANs might be infected with or the target of malware. If you instead run the IDS on the LAN interfaces, you would see the IP addresses before they were NAT-mangled.  With the site-to-site VPN scenario you linked, I don't if the LAN approach would work. Bill

@Evad: Bill, After a total reinstall of pfSense from scratch … Snort installed like above .. Failed first time and installed on second try but no GUI... Ran the 'Reinstall Snort's GUI components' to get the GUI. Created a LAN interface and then made a WAN  'Add new interface mapping based on this one' Now it works .... no errors so far..... Thanks.... Glad it's working for you now, but it should not have been that much trouble the install.  Something is up somewhere and I just need to find what it is. As for your failure to start error with this message: snort[9610]: FATAL ERROR: /usr/pbi/snort-i386/etc/snort/snort_61288_em1/rules/snort.rules(904) Unknown rule option: 'stream_size That indicates a needed preprocessor was not enabled.  Most likely it was the Stream5 preprocessor.  Don't know why that would be.  It is enabled by default.  The particular rule containing that rule option is on line 904 (that's what the 904 represents) in the file /usr/pbi/snort-i386/etc/snort/snort_61288_em1/rules/snort.rules.  Open that file in a text editor and go to line 904 to find the rule that generated the error. Bill

Verifying Googlebot https://support.google.com/webmasters/answer/80553?hl=en Google crawlers https://support.google.com/webmasters/answer/1061943?hl=en F.