I apologize about the lack of info it is below. As far as I can tell the updating is working (log below). pfSense: 2.4.3-RELEASE (amd64) built on Mon Mar 26 18:02:04 CDT 2018 FreeBSD 11.1-RELEASE-p7 snort:3.2.9.6_1 Manage Rule Set Log: Starting rules update…  Time: 2018-01-14 03:26:58 Downloading Snort VRT rules md5 file snortrules-snapshot-2990.tar.gz.md5... Checking Snort VRT rules md5 file... There is a new set of Snort VRT rules posted. Downloading file 'snortrules-snapshot-2990.tar.gz'... Done downloading rules file. Downloading Snort GPLv2 Community Rules md5 file community-rules.tar.gz.md5... Checking Snort GPLv2 Community Rules md5 file... There is a new set of Snort GPLv2 Community Rules posted. Downloading file 'community-rules.tar.gz'... Done downloading rules file. Extracting and installing Snort VRT rules... Using Snort VRT precompiled SO rules for FreeBSD-10-0 ... Installation of Snort VRT rules completed. Extracting and installing Snort GPLv2 Community Rules... Installation of Snort GPLv2 Community Rules completed. Copying new config and map files... Updating rules configuration for: WAN ... The Rules update has finished.  Time: 2018-01-14 03:27:36 Starting rules update...  Time: 2018-05-02 07:56:00 Downloading Snort Subscriber rules md5 file snortrules-snapshot-2990.tar.gz.md5... Checking Snort Subscriber rules md5 file... There is a new set of Snort Subscriber rules posted. Downloading file 'snortrules-snapshot-2990.tar.gz'... Done downloading rules file. Downloading Snort GPLv2 Community Rules md5 file community-rules.tar.gz.md5... Checking Snort GPLv2 Community Rules md5 file... There is a new set of Snort GPLv2 Community Rules posted. Downloading file 'community-rules.tar.gz'... Done downloading rules file. Extracting and installing Snort Subscriber Ruleset... Using Snort Subscriber precompiled SO rules for FreeBSD-10-0 ... Installation of Snort Subscriber rules completed. Extracting and installing Snort GPLv2 Community Rules... Installation of Snort GPLv2 Community Rules completed. Copying new config and map files... Updating rules configuration for: WAN ... The Rules update has finished.  Time: 2018-05-02 07:56:26 Starting rules update...  Time: 2018-05-02 10:08:45 Downloading Snort Subscriber rules md5 file snortrules-snapshot-29111.tar.gz.md5... Checking Snort Subscriber rules md5 file... There is a new set of Snort Subscriber rules posted. Downloading file 'snortrules-snapshot-29111.tar.gz'... Done downloading rules file. Downloading Snort GPLv2 Community Rules md5 file community-rules.tar.gz.md5... Checking Snort GPLv2 Community Rules md5 file... There is a new set of Snort GPLv2 Community Rules posted. Downloading file 'community-rules.tar.gz'... Done downloading rules file. Extracting and installing Snort Subscriber Ruleset... Using Snort Subscriber precompiled SO rules for FreeBSD-10-0 ... Installation of Snort Subscriber rules completed. Extracting and installing Snort GPLv2 Community Rules... Installation of Snort GPLv2 Community Rules completed. Copying new config and map files... Updating rules configuration for: WAN ... The Rules update has finished.  Time: 2018-05-02 10:09:13 Thanks

I still don't really understand what you want as an end game here.  Your last rule is simply going to pass everything on any port that is sourced from $MY_NETWORK to anywhere so long as the SYN and ACK flags are set on the TCP packet.  PASS rules have priority in the processing chain, and once a PASS rule matches for a packet no other examination takes place against any additional rules.  The packet is passed. Why don't you just filter by specific IP addresses (and maybe ports if possible) within the firewall itself and leave the IDS out of it?  Suricata and Snort rules typically are used to find malicious content, so they are designed to trigger when certain byte sequences are detected within the payload.  It seems like you are wanting to use to pass only selected content.  That is going to be a bit harder. Bill

The only issue I have had is the netmap_grab_packets and the only adjustment I have done is the potential solution that you have read which has been running smoothly except for the one encounter mentioned. Of course, mine wasn't a VM. I will update my thread later this week. I would not mess with dev.netmap.admode nor try to "tune" the NIC…I have found that the tuning made things only worst. Be also sure to disable the items recommended in System > Advanced > Networking.

Hey there, I was searching on the forums and the web to see which network adapters support and work with inline mode - netmap. I've found these and not sure if they're fixed in the current version. Inline mode doesn't permanently block an IP, only legacy mode does that. Inline mode breaks traffic shape, legacy mode doesn't Inline mode breaks VLANs, legacy mode doesn't Inline mode prevents packet leakage, legacy mode doesn't Apparently there are only a sub-section of hardware that fully supports Netmap… Netmap / FreeBSD has issues with Intel i340, i350/v2, i210, i211, i217 ,i219, PRO/1000, 82575/82576/82579/82580 and Realtek RTL8168B NIC's. @bmeeks: Netmap compatibility must exist at the software layer where the NIC driver meets the operating system… There have been (and probably still are) some issues/bugs in both the FreeBSD implementation of Netmap and in Suricata's use of Netmap. I have a Dell 0HM9JY Intel 82576 Gigabit ET quad port NIC (Intel PRO/1000 ET) and have the same error messages: 549.863394 [1071] netmap_grab_packets bad pkt at 91 len 2164 549.864619 [1071] netmap_grab_packets bad pkt at 95 len 2163 550.034152 [1071] netmap_grab_packets bad pkt at 197 len 2164 550.035448 [1071] netmap_grab_packets bad pkt at 199 len 2164 I have also turned off hardware-based checksums, TCP segmentation offloading and LRO (Large Receive Offloading), then reboot pfsense. Error still persists and doesn't seem to work properly or as intended.

@rebman77: I have to assume they have never tried their ruleset in Snort. I would agree …  :) Bill

+1 on what other respondents have said.  Running an IDS/IPS on the WAN is generally going to log a bunch of noise, and if you have no public-facing services and block all unsolicited inbound traffic, then you don't gain any security by running an IDS/IPS on the WAN. Better in most situations to run the IDS/IPS on the LAN.  Even then, you will want to let it run in non-blocking mode for a while to get a feel for any false positives that show up on your network.  There are generally quite a few centered around HTTP_INSPECT rules in Snort. Bill

Since those are hosted in the USA, and probably from CDNs with unpredictable address blocks, most likely the answer is 'no'.

OpenVPN or IPSec? I assume OpenVPN if pfSense is a client. Are you running Surucata in in-line mode? Steve

Thanks for the prompt reply Bill :) I mentioned the enc0 interface as you can do a packet capture and see unencrypted traffic from the VPN client via tcpdump. [2.4.3-RELEASE][admin@pfsense.xxxxxxxxxx.net]/root: tcpdump -i enc0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on enc0, link-type ENC (OpenBSD encapsulated IP), capture size 262144 bytes 08:38:49.508431 (authentic,confidential): SPI 0xcb4900c7: IP 172.16.9.3.62644 > pfsense.xxxxxxxxxx.net.domain: 62+ A? www.apple.com. (31) 08:38:49.508533 (authentic,confidential): SPI 0xcb4900c7: IP 172.16.9.3.55246 > pfsense.xxxxxxxxxx.net.domain: 48200+ A? apple.com. (27) 08:38:49.508604 (authentic,confidential): SPI 0xcb4900c7: IP 172.16.9.3.61700 > pfsense.xxxxxxxxxx.net.domain: 60069+ A? gateway.icloud.com. (36) 08:38:49.508671 (authentic,confidential): SPI 0xcb4900c7: IP 172.16.9.3.59659 > pfsense.xxxxxxxxxx.net.domain: 32698+ A? www.icloud.com. (32) 08:38:49.508730 (authentic,confidential): SPI 0x0db585ec: IP pfsense.xxxxxxxxxx.net.domain > 172.16.9.3.55246: 48200 3/8/12 A 17.172.224.47, A 17.178.96.59, A 17.142.160.59 (460) 08:38:49.509125 (authentic,confidential): SPI 0x0db585ec: IP pfsense.xxxxxxxxxx.net.domain > 172.16.9.3.61700: 60069 9/4/0 CNAME gateway.fe.apple-dns.net., A 17.248.144.180, A 17.248.144.89, A 17.248.144.49, A 17.248.144.86, A 17.248.144.152, A 17.248.144.85, A 17.248.144.91, A 17.248.144.92 (336) 08:38:49.516628 (authentic,confidential): SPI 0xcb4900c7: IP 172.16.9.3.61275 > pfsense.xxxxxxxxxx.net.domain: 40342+ A? metrics.icloud.com. (36) 172.16.9.3  = my iPhone https://www.freebsd.org/cgi/man.cgi?query=enc&sektion=4&manpath=FreeBSD+7.1-RELEASE I just wonder if snort was to enumerate enc0 as a valid interface I'd be able to alert / block IP addresses handed out to my IKEv2 clients.

I may have stumbled across a root cause. I enabled the Snort VRT rules, and as soon as I did CPU usage shot up through the roof and stayed there.  Disabling VRT and restarting Snort corrected it. I can't remember if the VRT rules are available in Suricata.  If they aren't, that may explain why I wasn't seeing the problem with Barnyard when using that instead of Snort. What's different about VRT? Is there something with that ruleset that could cause this? I'll keep an eye on things and let you guys know how things progress. And as always, thanks bmeeks for your contributions  :D

Good info Onyxfire!

@NRgia: Nice tutorial so to speak, maybe you could do a sticky post, in order for others to find it more easily in the future? Where to read more about rules tips & tricks ? "How to create Snort rules documentation", on their site is ok? There is some useful documentation on the Snort.org site.  However, to be honest, I've never found a great all-in-one location for this kind of information.  Bits and pieces are scattered all over.  As with lots of software, especially open-source and other "free" software, the developers spend more time on coding and adding features than creating documentation.  I am guilty of that as well with the Snort and Suricata packages. Bill

@mdes: First question, is Suricata in pfSense (inline mode) able to drop (or instruct PF to do it) a connection instead of blocking an IP? Second question, is Suricata in pfSense (inline mode) able to block destination (WAN) IP:port while it listens on LAN interface? Go read this post to answer question #1:  https://forum.pfsense.org/index.php?topic=135331.0. The answer to question #2 is "no, it can't do that".  Why would you want to do that anyway? Bill

@JohnSCarter: Hello all, Recently I've had some time on my hands and I've been thinking about pfSense and have some questions and was hoping that someone could elaborate as I'm not quite getting my head around them. Question 1: Is there any way to mass-drop rule actions in Suricata / snort just because I don't have time to 100% be active on my network to see the alert telling me that malware has infected my system and also because manually changing the "alert" rules to "drop" (even with a AHK script) takes more time than I have in a day. Question 2: With IDS/IPS systems (for someone who doesn't have time to sit and monitor their constantly active network 24/7) why aren't most rules set to automatically drop, for example if there was a rule for a packet that's a known malicious packet that compromises a system and that packet triggered a rule but the action was "alert" wouldn't that be pointless? like a fire alarm with a 6 hour delay, wouldn't the damage already be done? Question 3: Obviously putting all the firewalls, IPS/IDS and additional content filtering systems in place is good however none of it means anything if pfSense itself is compromised, I was just wondering (from somewhat of a "lamens" perspective) what is done to keep pfSense secure, how difficult it would be to compromise and if there's any way to check / know if your pfSense is compromised (perhaps a tool or checklist of sorts?) Thanks for your time, John. Question #1 Answer: You don't have to change each rule action to DROP in order to get a block if you simply do these two things: (1)  Use Legacy Mode blocking (on the INTERFACE SETTINGS tab) and then; (2)  Uncheck the option for "Block on drops only". If you do those two things, then every single rule that raises an alert will result in a block.  Just be prepared for some frustration, though, since with all the sloppiness in web programming these days you can expect some rules to trigger that are enforcing various standards.  When those standards are not ahered to, the rules trigger.  You can mitigate this somewhat by being more selective in the rules you enable. Question #2 Answer: Because most security admins want to be notified of issues, evaluate the alert to weed out false positives, and only then enable blocking.  This is to prevent the "frustration problem" alluded to in answer #1 above.  Put yourself in the shoes of a network security admin in a Fortune 500 corporation who just turns on an IPS with all the rules enabled and all the rules set to drop traffic.  Just imagine how many times his phone would ring from users whose computers stopped working because of all the blocked traffic.  Would it not be better to run with everything in alert, analyze the received alerts, weed out and either disable or suppress false positive rules, and only then enable blocking? Question #3 Answer: Firewalls are incredibly hard to compromise unless they are horribly administered.  All the stuff you see on TV shows where the "good guy" hacks into the firewall to save the day is just BS.  Doesn't happen.  But if your firewall is compromised, then all bets are off.  If you are really paranoid, you could put Suricata inline between your firewall and your first LAN switch and run it on a separate physical box.  You would also need a NIC that fully supports Netmap and Inline IPS mode. Bill

The best place to run an IDS/IPS such as Snort or Suricata for home networks is on the LAN interface.  That way host IP addresses in alerts will be shown with their native addresses.  When you run the IDS on the WAN, all alerts will have the WAN IP as the "local host" address since the IDS sees traffic outbound on the WAN only after NAT rules have been applied. There are number of posts in this sub-forum by me and others that talk about this.  So move your configuration over to the LAN interface and your problem will be solved.  Internal hosts will show up in the alerts with their own IP address. Bill

@teamits: Never mind, I found the release notes at https://forum.pfsense.org/index.php?topic=145489.0 and even better https://forum.pfsense.org/index.php?topic=145257.msg790339 that discuss pass lists. You can use custom PASS rules to create a pass list, but just be careful as I warned in the posts you linked.  It is probably better to watch and either disable the bothersome rules, or use suppress lists and either of the "filter by IP" options that are available when you click the plus sign (+) beside the IP address columns on the ALERTS tab.  Doing it that way allows a rule-by-rule tuning and even limiting that to certain hosts (IP addresses).  Using a pass list is more like using a large hammer when what you really need is a jeweler's screwdriver.  With a PASS rule that filters only on an address, you are potentially exposing the whitelisted host to a lot of malicious stuff. Bill

Thank you for this. In this article (https://forum.pfsense.org/index.php?topic=50141.0), the problem is explained. I increased the value of System/Advanced/Firewall & NAT/Firewall Maximum Table Entries to 400000.The default value was 200000. The description for this field is: Maximum number of table entries for systems such as aliases, sshlockout, snort, etc, combined. Since it mentions snort, I assume using suricata also impacts the number of table entries. It is however a system setting, so Bill's remark is correct. The error didn't appear anymore after the value was increased.

@alchemyx: Hi, How to change max_client_bytes in SSH preprocessor? If I put that in Advanced Configuration Pass-Through preprocessor ssh:         max_client_bytes 19600 Then SNORT won't start up. Probably because I have duplicated preprocessor ssh: with the one provided by pfsense. I tried disabling SSH altogether and putting it again but snort also refuses to come back up. pfsense version is 2.4.2-RELEASE-p1 and SNORT is 2.9.9.0 Thanks! Michał At the moment that is not a configurable parameter within the GUI.  And using the Advanced Passthrough feature doesn't work with preprocessors because of how the internal GUI code works for now. I will add this parameter to the next Snort GUI update.  I'm working on some other Snort updates and hope to get an updated package posted in a couple of weeks or so. Bill