@doktornotor: @bmeeks: Those files are saved in /var/db/suricata/sidmods.  Those files are not automatically saved during a config backup/restore operation. Is there any reason why's this not saved base64-encoded in config.xml? It's annoying, the disablesid.conf is pretty important piece of configuration to avoid tons of FPs. Well, I was leery of making the config.xml too large by including what could potentially be a lot of text.  The ideal solution would be an API within pfSense itself where packages could register files to be included in automatic config backups.  Other packages store large text files locally as well (pfBlockerNG does, I think). Bill

Was going to suggest something like that, but I wasn't sure if custom rules over write normal rules. I use a custom rule to record when people are accessing my sftp server sat in my DMZ. Alert on SSH alert tcp $EXTERNAL_NET any -> $HOME_NET $SSH_PORTS     (msg: "SSH Detected";flow:established, to_server;     content:"SSH-";sid:1000001;rev:1;classtype:not-suspicious)

Ok, I know this is an older post but wanted to update that ET Pro is now $750/year. Total sticker shock on that one and out of reach for home and most small business users. So if you combine that with Snort VRT for a small business, you are over $1000/year. Can't sell that to any of my clients.

@Georget27: Should we create HOME_NET and EXTERNAL_NET under Firewall - Alias or is there another place to defining aliases just for Suricata please ? I was looking for this :) You will create  an alias under Firewall - Alias, and then assign the alias to a Pass List you can generate on the PASS LIST tab.  Uncheck all the default-checked options for the Pass List and then choose your HOME_NET alias down at the bottom.  You can name the Pass List whatever you wish, but suggest including "HomeNet" in the name. Now go to the INTERFACE SETTINGS tab for the interface and in the section for defining HOME_NET select the recently created Alias from the drop-down and then save. Bill

I also am using supported hardware and get quite a few of these bad pkt errors as well. I think I am going back to legacy mode for now. It is better than it was a year ago when inline really bugged things up. I will go back to it in the future. Real shame since legacy doesn't stop everything you want.

Thankyou ! :-)

You need to run u2boat to convert them to a wireshark pcap format :- u2boat snort_51260_igb0_vlan2.u2.1507590514 pcap.cap You can view them via :- u2spewfoo snort_51260_igb0_vlan2.u2.1507590514 The directories will start snort_IF-NAME*

ok. thx for your support. I will follow your advice!

@bbrendon: If you have your sid mgmt set to enable,disable; then you should be able to add to your disablesid.conf: pcre:protocol-command-decode I'm not sure if you need to escape the '-' but it should work. Thanks @bbrendon for the regex example.  It should work.  I, too, am not sure about the need for escaping the dash.  The OP can check the results of the regex by looking at the list of active rules for the interface.  The active rules will be found in the interface subdirectory inside a sub-directory called rules in a file called suricata.rules (or snort.rules for Snort).  The path is like so for Suricata (Snort is the same, just replace "suricata" with "snort" in the path): /usr/local/etc/suricata/suricata_xxxyyyyyy/rules where xxx will be the physical interface name and yyyyyy will be a random GUID number. You can open the rules files you find there to see the actual enabled runtime rules for the interface. Bill

Hi, I haven't tried it yet. Bmeeks pointed out in this topic that you should create a custom pass rule for your whitelisted IP addresses because in Inline mode passlist isn't working. Check this topic: https://forum.pfsense.org/index.php?topic=135331.0 Pass rule example: pass ip 1.2.3.4 any <> any any (msg:"pass all traffic from/to 1.2.3.4"; sid:1000001;) Rule wiki: https://redmine.openinfosecfoundation.org/projects/suricata/wiki/Suricata_Rules

I think I will bump up the defaults for Stream and Reassembly Memcap values in a future release. Bill

You can manually add the required values to the YAML configuration template file.  Note that this will have to be repeated each time you update the Suricata package as the template file is always overwritten with a new update (like when you install a package update from the Package Manager). Find this file and open it in an editor of choice: /usr/local/pkg/suricata/suricata_yaml_template.inc Near the bottom of the file you will find this section of code: # Holds variables that would be used by the engine. vars:   # Holds the address group vars that would be passed in a Signature.   address-groups:     HOME_NET: "[{$home_net}]"     EXTERNAL_NET: "{$external_net}"     {$addr_vars}   # Holds the port group vars that would be passed in a Signature.   port-groups:     {$port_vars} Be very careful not to disturb any existing lines of text (code)!  Add a new line for your SIP_SERVERS as shown below: # Holds variables that would be used by the engine. vars:   # Holds the address group vars that would be passed in a Signature.   address-groups:     HOME_NET: "[{$home_net}]"     EXTERNAL_NET: "{$external_net}"     {$addr_vars}     SIP_SERVERS ["what ever IP addresses or networks are appropriate for your setup"]   # Holds the port group vars that would be passed in a Signature.   port-groups:     {$port_vars} The information in the template file is used to build the suricata.yaml configuration file for each configured interface.  Be very careful when editing and don't change any of the other lines.  That includes spaces or tab indents!  Suricata is very finicky!  You will just be adding this one line in the place shown above. SIP_SERVERS ["some IP addresses or networks"] I will put the inclusion of the SIP_SERVERS variable on my TODO list for a future update so that it is available within the GUI. EDIT:  Forgot to say that after making the changes in the template file above, you will need to go to the INTERFACE SETTINGS tab and "edit" the interface so you can do a Save operation.  Clicking the Save button will cause the suricata.yaml file for the interface to be regenerated using the newly modified template. Bill

It may not be blocking due to the automatic Pass List generated in Legacy Mode.  Check the IP addresses in the Pass List by clicking the View button next to the Pass List drop-down selector on the INTERFACE SETTINGS tab.  Any address in that list will never be blocked (but will still generate an alert).  You can create a customized Pass List and remove addresses that you want to get blocked, but be careful if this is new territory for you.  You can easily lock yourself out. In general the default settings for a Pass List work for the majority of uses. Bill

@strangegopher: @bmeeks: I don't recall off the top of my head, but there is a forumula that uses the number of cores and memory to compute optimal stream memory settings.  I think some adjustments to that area of the binary also happened between the 3.2.x and 4.0.0 versions of the code, so that might account for the fact of not having that exact error using 3.2.x. Bill Seems like I am now (after fixing other issues) having the same issue as op. my supermicro a1sri-2758f has 8 cores and no threads, its non-standard core count I guess. Might explain the buggy multi threading  issues I am experiencing. See my reply in the other thread you linked.  You need to at least double the Stream Mem Cap setting, and possible increase it even more. Bill

@pfsense_user12123: I figured out that INLINE MODE causes the Problem. In Legacy Mode everything works great. So the Main Problem in the configuration file was the inline Mode which made the Router freeze. Not surprising.  Lots of NIC hardware has problems with Inline Mode due to the Netmap dependency.  It is still a buggy interface in all of the following:  (1) NIC drivers, (2) FreeBSD and (3) to some degree Suricata upstream. Bill

@chudak: Thx for the answer. The only interesting question remains - why this rule problem was unmasked by a snort version upgrade? It wasn't.  I've never seen that error in any of my test virtual machines nor in my personal firewall, and I've upgraded along with every version release.  It is likely a product of the particular rule sets you have enabled.  To be specific, the error is caused by not having the Sensitive Data preprocessor enabled while having an enabled rule that contains a sensitive-date preprocessor keyword (that "sd_pattern" keyword). Does Snort now not run at all, or did it just fail to automatically restart following the initial update? If you can, open the referenced file in the error message using the vi editor and go to line 424.  Paste the entire contents of that line back here so I can examine the failing rule. Bill

An update to my previous reply above.  I assumed initially the OP had turned on blocking mode, but the OP has this post in another sub-forum here on the board: https://forum.pfsense.org/index.php?topic=136442.msg746548#msg746548 In that post it is stated that "BLOCKING" and "BARNYARD2" both show as Disabled on the SNORT INTERFACES tab.  That would be why you are getting alerts and no blocking.  Snort does not block by default.  It is an IDS when using the defaults.  You must go to the INTERFACE SETTINGS tab by clicking the edit icon beside the interface.  On the INTERFACE SETTINGS tab, click the checkbox for Block Offenders in order to turn on IPS or blocking mode.  Save the change and then restart Snort on the interface.  You restart it back on the INTERFACES tab using the icon there. You will also need to weed out potential false positives. Bill