I wouldn't say that ALL of the http_inspect rules can be ignored (though like mhertzfeld says, they're probably of greater concern if running a web server to keep an eye on attacks), but many of those rules are designed for strict adherence to specifications that have been flexed in many ways over time to accommodate the tons of applications that use HTTP today as their transport protocol. Your list there is probably the most common ones that can be suppressed without any real concerns.

Found a discussion on the subject here, http://stackoverflow.com/questions/3337020/how-to-specify-ranges-in-yaml For anyone happening upon this I gave up, because it looks unsupported,  and just lived without the alias.

@bmeeks: @adam65535: I added config to the Advanced Configuration Pass-through text box in the interface edit settings and it does not appear to be added to the interfaces suricata.yaml file. I was hoping to add the payload logging to eve log.  Has anyone got the passthrough to work? outputs:   - eve-log:       types:         - alert:             payload: yes          # enable dumping payload in Base64             payload-printable: yes # enable dumping payload in printable (lossy) format             packet: yes             http: yes The best way to accomplish this is to add the information directly to the suricata_yaml_template.inc file in /usr/local/suricata/.  Just be sure to enter it within the correct section and DO NOT overwrite any of the string variables in curly braces (like "{$something}"). Configuration info entered into the template file will be added to every YAML conf file for every interface.  Once you add the new information to the template, you will need to manually stop then start Suricata on the INTERFACES tab. Bill I would like to this as well, but I am not as comfortable modifying the php as adam65535 did. I'd like to use the solution above, but I am a bit unclear on how to do so. In /usr/local/pkg/suricata/suricata_yaml_template.inc the relevant section for eve logging is: - eve-log:       enabled: {$enable_eve_log}       type: {$eve_output_type}       filename: eve.json       identity: "suricata"       facility: {$eve_systemlog_facility}       level: {$eve_systemlog_priority}       types: {$eve_out_types} so I am not sure how to add the relevant alert options under types as I can't control that it gets entered under the alert type properly with the {$eve_out_types} variable . Can anyone provide assistance on how to do this?

BBcan177, Your white-listing suggestion seems to be working for the domain, "s3.amazonws.com" (which apparently hosts the Snort rules). Thank you for taking the time to provide this information! ;D All the best,

I, too, am unable to download snort updates. Specifically, there are two issues: 1. I have unchecked "Click to retain Snort settings after package removal." Then uninstalled, then rebooted, and still Snort remembers my settings (including my oinkmaster code) 2. Ignoring that….. and more importantly, when trying to update VRT rules using snort 3.2.9.1_14, I get the following error. Any ideas? Starting rules update...  Time: 2016-08-11 22:05:58 Downloading Snort VRT rules md5 file snortrules-snapshot-2983.tar.gz.md5... Checking Snort VRT rules md5 file... There is a new set of Snort VRT rules posted. Downloading file 'snortrules-snapshot-2983.tar.gz'... Snort VRT rules file download failed.  Server returned error 0. The error text was: Connection timed out after 15015 milliseconds Snort VRT rules will not be updated. The Rules update has finished.  Time: 2016-08-11 22:07:59 I have tried more than 10 times over the last 3 days. I run the following packages: pfblockerNG 2.1.1_1 with TLD features enabled squid Squidguard Machine: C2758 16 Gigs ECC ram 4 onboard intel NIC 1x PCI-e intel 4 port pro/1000 PT

Is it possible that the inline feature is blocking the src and dst. This would kill the WAN for sure. I would assume that the inline and legacy would treat the rules in the same manor. I do have the WAN and local IP's in the pass list. When this issue occurs in inline mode. I can no longer access the GUI, but the console still works. What can I run in the console to test the interfaces when this occurs?

Reading up on Suricata looks like the answer to my needs now that the inline option is available. Thanks

Impossible to control with a cron script. Attack is finished by the time script is run. If anyone has an ingenious way of handling this, let me know. Eventually every email server will be prone to this type of spam. I do prevent these emails from getting into mailboxes with a filter, I just want to eliminate it from the source so the attacker thinks this IP is blocked. Every day I add another 2K-4K IP's to the block alias. Eventually this will have performance effects.

Best to ask over in the Packages-IDS/IPS subforum https://forum.pfsense.org/index.php?board=61.0, dedicated to exactly those type of questions.

All of the IPs that are scanning for this port are mainly in China and South America…..

Wrong depth keyboard in my rules. Thank's fsansfil, your rule works like a charm  ;)

Thank you Mr Bill, i will explore it

In a similar vein to manually creating rules as BBcan177 suggested, you can also manually create/edit a Suppress List and add thresholding values to GID:SID pairs.  After creating/editing the suppress list, make sure it is selected as "active" on the INTERFACE SETTINGS tab, and then restart Snort on the interface. Go to the SUPPRESS tab and either edit an existing list or create a new one and add the new threshold rule. Bill

Upgrading to 3.2.9.1_14 fixed this issue for me.  This version updates the version of snort so between _13 and _14, it bigger then just a minor change.  Would be great for future changes to snort-pfsense, to be visually apparent when larger changes were made (meaning don't only change the minor version).  I was looking at this for an hour and didn't realize the version of snort changed, outside a few big fixes.  No more errors now w/ the latest pfsense and latest snort (as of this post).