Never enable Snort blocking without first running for at least a week or two and reviewing what it's triggering and disabling signatures as appropriate, as the default Snort ruleset is way too touchy to be blocking.

At the moment nothing like that is in the code, but I guess it could be added.  Perhaps as an option that is configurable on the GLOBAL SETTINGS tab.  The line of code you altered to trust self-signed CAs was added to the Snort GUI code base a while back in an attempt to improve security, but it has the unintended side effect of interfering with some edge-case setups.

Bill

Bill:

Thanks for the update. I know it's complex to work on all the moving parts,

Regards,

Howard

@zxvv  Thanks very much for adding the ignore_scanned option.  I'm probably being slow, but I'm having trouble getting it to do what I need.  When I try to add an entry into ignore_scanned in the GUI, Snort fails to start.  I'm sure I'm not getting the syntax quite right.

Basically, my set up and what I want to do are as follows:

1)  I have a WAN interface which gets a dynamic IP from my ISP.  Let's call that 12.34.56.78

2)  I have a NAT forward set up for a UDP port (let's say 1234) that forwards that port to a LAN address.  Let's call that 192.168.1.2

3)  When I connect using the service on UDP port 1234, the port scan preprocessor detects it as a port scanning attempt and blocks the incoming IP.  The portscanning engine is set only to look at UDP traffic. If it helps, that UDP port 1234 is the only UDP port that's fowarded.

4)  What I want to do is add an entry to ignore_scanned so that it ignores all traffic on UDP 1234 when deciding if it's being scanned.

What do I type into the ignore_scanned box to achieve this please?

I've tried various combinations of $HOME_NET, $EXTERNAL_NET, 192.168.1.2, 0.0.0.0/0 specifying port 1234 etc (the last entry just trying to catch any address)  but it's either ineffective or Snort doesn't start at all with the following error:

FATAL ERROR: /usr/local/etc/snort/snort_57232_re0/snort.conf(355) => Invalid ip_list to 'ignore_scanned' option.

After doing some more testing it seems like I am never getting reaching my max internet speeds with Suricata inline mode, even with Snort stopped.

I also started another thread (https://forum.pfsense.org/index.php?topic=113195.0) about slow speeds with Suricata inline mode in general. This other thread is on different hardware, different network and not running Snort concurrently.

Trying to modify the dropsid.conf file and having troubles….

Firstly, running the daily Beta releases. The on the SID Management tab there are no example.conf files. Trying to add a New file, I input dropsid.conf for a filename and a couple of lines in the body below and then save. After the save, there still is nothing there, nor after exiting and re-entering the GUI.

I'm about to edit a file outside of the GUI and try the Import function. Any recommendations? Is there a location where the dropsid-example.conf file can be downloaded or pulled out of a distribution? TIA

edit:
Tried to create the file offline and import with same result.

Copied crash report for this activity below:
Crash report begins.  Anonymous machine information:

amd64
10.3-RELEASE-p3
FreeBSD 10.3-RELEASE-p3 #104 95be4fb(RELENG_2_3): Sun Jun  5 10:51:54 CDT 2016    root@ce23-amd64-builder:/builder/pfsense/tmp/obj/builder/pfsense/tmp/FreeBSD-src/sys/pfSense

Crash report details:

PHP Errors:
[05-Jun-2016 10:50:44 America/Denver] PHP Warning:  move_uploaded_file(/var/db/suricata/sidmods/dropsid.conf): failed to open stream: No such file or directory in /usr/local/www/suricata/suricata_sid_mgmt.php on line 125
[05-Jun-2016 10:50:44 America/Denver] PHP Stack trace:
[05-Jun-2016 10:50:44 America/Denver] PHP  1. {main}() /usr/local/www/suricata/suricata_sid_mgmt.php:0
[05-Jun-2016 10:50:44 America/Denver] PHP  2. move_uploaded_file() /usr/local/www/suricata/suricata_sid_mgmt.php:125
[05-Jun-2016 10:50:44 America/Denver] PHP Warning:  move_uploaded_file(): Unable to move '/tmp/phpAm5LA8' to '/var/db/suricata/sidmods/dropsid.conf' in /usr/local/www/suricata/suricata_sid_mgmt.php on line 125
[05-Jun-2016 10:50:44 America/Denver] PHP Stack trace:
[05-Jun-2016 10:50:44 America/Denver] PHP  1. {main}() /usr/local/www/suricata/suricata_sid_mgmt.php:0
[05-Jun-2016 10:50:44 America/Denver] PHP  2. move_uploaded_file() /usr/local/www/suricata/suricata_sid_mgmt.php:125

After investigation, found /var/db/suricata did not exist. Created /var/db/suricata/sidmods. Went back to the GUI and performed the import function again and the template was imported and displayed in the file list and I was able to select it from the Drop SID File section drop-down list.

Thanks.  The ignore scanned option is now available in the Snort pre-processor page.

There remains an issue that you can't select UDP in the scan type pull down menu on that same page, as it's missing.

I've fixed that here,  but it's waiting to be merged.  https://github.com/pfsense/FreeBSD-ports/pull/138

Your rule syntax is missing the CLASSIFICATION tag (uses the classtype keyword).  The Snort binary on pfSense wants that in a rule because of some customization done in the CSV output module.  If that section of the rule is missing, it causes problems.

Bill

I'm seeing the same thing. I just noticed it today, but not sure how long it's been occuring.  I was running Snort rules from Jun 1st and EMThreat rules from Jun 2nd and still seeing problems.  Snort is blocking facebook, google, bing and others.  I forced an update and both rulesets are now dated Jun 2.  We'll see if that fixes it.

I've always had my portscan sensitivity set to "low" and haven't changed anything with my Snort setup for months.  So hoping it was just a bad batch of rules.

The way I set mine up at home was without blocking mode enabled for a few weeks. That way nothing was actually getting blocked when an alert was triggered. I would of course need to check all alerts, and fortunately all were not major. I think I suppressed like 13 or 14 rules over the course of the non-blocking period, and when I didn't see any further alerts for a week, I put it in blocking mode. Most of the ones I suppressed were HTTP or HTTPS related, though I did also get a couple of SIP ones since my VoIP provider breaks the caller ID length (they add the country code to the number, making it longer than normal).

Of course, like I mentioned, my setup is at a home and not a business… but you should be able to do something similar there too. Just keep an eye on the alerts a little more often during the non-blocking period and make sure they're harmless before you suppress them.

This is most likely a Bootstrap conversion bug in the GUI code.  Could be a "display only" bug meaning the correct values are actually stored and written to the snort.conf file.  I can add it to my list of bug fixes for the next update.

Bill

@enriluis:

Hi all!
I'm using pfsense 2.3.1_1 , snort package 3.2.9.1_13, when i try to add ip list with some ip address it will be trusted for example,  so in the interface config do not show the ip list added.
sorry about my English

Sorry i was making in wrong place

Same place as it always was.

Interface -> <if>Flow/Stream

Subheader "Stream Engine Settings"

/AV</if>

Do a quick search through this forum and you will find the solution.  You need to increase the STREAM memory settings.  Off the top of my head I don't recall the exact parameter.  Search for this error either here or on Google to find the exact parameter to tweak:

All those other errors are caused by running Snort VRT rules on Suricata.  There are many Snort VRT rules that Suricata will not digest and will discard and not use because they contain unsupported rule options.

Bill

I was able to use CODELQ traffic shaping  with Suricata Inline mode but could not use HFSC traffic shaping with the Inline mode. HFSC in the Inline mode created a problem resulting in Netmap grab packet errors that showed up on the consol screen. It was not clear what to do about these errors. While CODELQ does reduce buffer bloat it does not do it near as effectively as HFSC.

Unfortunately Snorby is no longer being maintained.

PLEASE NOTE!  This will most likely be our last Snorby package update.  The creator and lead developer of Snorby has left the project and so Snorby is now considered unmaintained.  Snorby will be removed from Security Onion in the future and so you should begin transitioning to Squert, Sguil, and/or ELSA.

http://blog.securityonion.net/2015/08/snorby-263-package-now-available-final.html

Still no change from the recommendation in the old thread.  Unless you have well over 1 Gigabit/sec of sustained throughput (not little bursts), then either IDS can keep up.  The differences are mainly cosmetic in my view.

Suricata can log more kinds of extra details (not that it detects more alerts, just logs more details about specific traffic).

Snort has the new OpenAppID preprocessor that Cisco/Sourcefire recently made open source.

Suricata is multi-threaded and at the moment Snort is not, but refer to my first point about throughput.  Unless you are essentially some huge enterprise with very high sustained throughput on an interface, Snort is fine even if it is currently single-threaded.

Suricata on pfSense can now use the new Netmap API and driver to be a true IPS (Intrusion Prevention System) with inline blocking.  Note this only works with certain NIC drivers, though.  Snort still uses libpcap to analyze copies of packets, and then inserts offending IP addresses into the pf firewall (in a table called snort2c).  So if inline IPS is important to you and you have a supported NIC, Suricata is a better fit.

The comments in the older threads about rules support (rule options and keywords, mainly) are still true.  Suricata will choke on about 700-800 of the Snort VRT rules and skip loading them.

Bill