@SteveITS It looks like it is detecting ipv6 better already is showing alerts [image: 1752342154032-screenshot-2025-07-12-at-10.39.56-resized.png] It sees some ipv6 going to my interface. Again snort also would spot stuff every once a a while. My son got a bad bug on his tablet and it had a Russian email server running I checked it on virus total and it was spot on as malware known abuses so I reported it

@bmeeks said in Recommended Snort rules to change from "Alert" to "Block"?: @Enso_ said in Recommended Snort rules to change from "Alert" to "Block"?: Looks like you are right once again. It was set to 'remove blocked host after 1 hour'. So I just never caught it in time. I recommend leaving that setting alone, too. You generally don't want blocks hanging around forever. Not only do they consume resources, but if the block was due to a false positive you would like it to automatically clear in a reasonable time without requiring admin action. If Snort blocked the traffic the first time, it will block it a subsequent time later on (if the blocked host is automatically periodically cleared). One issue with Legacy Blocking Mode is that it is a big hammer. It blocks ALL traffic to a blocked IP for ALL internal hosts. Inline IPS Mode, if you can use it (your NICs must support netmap natively), drops individual packets instead of blocking everything to/from the IP. That's much more granular. But with Inline IPS Mode, you must explicitly change rules you want to block traffic from ALERT to DROP using the features on the SID MGMT tab. I'm leaving the setting to remove the blocked host after 1h. As for inline mode; that is something I want to circle back to in the future. However, currently there are no resources that could configure inline mode in a timely fashion. Plus, I'm quite sure I'd have to upgrade the NICs to support netmap.

Snort will log a message to the pfSense system log as it starts. If it fails, generally the reason for the failure is also logged. The only exception to that is if a shared library is the wrong version or not present. That would only happen if you installed or updated some other package that shared a library with the Snort binary. That is very unlikely -- but not impossible. The most common reason for Snort failing to start would be an error with a rule. It is not unheard of for the Snort VRT to release a rules update package with a syntax error in it. Snort will abort startup when it detects a syntax error. Rule syntax errors will be logged to the pfSense system log. So, <TLDR;> check the pfSense system log immediately after trying to start Snort and see what is logged there. That will clue you in to the problem.

@JonathanLee said in UNOFFICIAL GUIDE: Have Package Logs Record to a secondary SSD drive Snort Syslog Squid and or Squid cache system: ln -s -F /nvme/LOGS_Optane/snort /var/log/snort Also you can do this with suricata. /var/log/suricata remove this mkdir /nvme/LOGS_Optane/suricata ln -s -F /nvme/LOGS_Optane/suricata /var/log/suricata

@Enso_ said in SNORT stopped generating alerts: @bmeeks Thank you for all your help. One last question, which I have edited in above. Can I use the free Oinkcode for multiple instances? I'm reading different information about this. I'm running a few pfsense boxes running Snort and have the same free Oinkcode on all three of them, which I will remove if this is not allowed. Here are the actual Terms and Conditions from Snort: https://www.snort.org/snort_license. They state your license is "per sensor" if using the paid license. The license for Registered Users appears a bit more permissive. Here is the direct wording: If You are a Registered User, then subject to the terms and conditions of this Agreement, Cisco grants You a world-wide and non-exclusive license to: (a) download, install and use the Rules on Sensors that You manage (or over which You have administrative control); So, it appears from the above that Registered Users can use their Oinkcode on all sensors that they manage and have administrative control over. But Paid Subscribers can only use the Oinkcode on a single device (sensor). If you need to manage multiple devices on a Paid Subscriber plan you must purchase a license for each sensor. And there are different rules (and a much higer cost) for commercial use of the Paid Subcriber rules.

@bmeeks : Ok. So I disabled and unassigned the WAN Sort interface. Then copied it back to the newly unused WAN interface, enabled and started it and...... IT WORKED!!! I'm getting Alerts and its generating blocks as before the upgrade! Same name as before, but apparently an internal interface mapping in Snort was still looking for the old WAN interface id. Thanks!!!

@stephenw10 I originally didn't think it would work. But it does. It's amazing.

https://redmine.pfsense.org/issues/15035

Never does not work any longer it changed overnight to 5 mins for some reason, memory use I suspect. [image: 1696917524646-screenshot-2023-10-09-at-10.57.43-pm-resized.png] Before [image: 1696917515159-screenshot-2023-10-09-at-10.58.08-pm-resized.png] After

@bmeeks your code is epic !!

@michmoor @bmeeks Here is, the fully converted appMapping.data to text file... [image: 1696468187507-screenshot-2023-10-04-at-5.58.46-pm-resized.jpg] The pfSense Snort AppID de-cipher sorcerer's code file: --> textrules.txt Sid range: 1000000 - 1003371 Total 3,371 AppID rules you can use with the custom option. I converted it with a Java program I just made. The message is the same as the appid match it makes it easier. Some of the ieee items are bigger but they seem to match.

@bmeeks 4.1.6_11 sorry I had a mix up. I do not know if this has anything to do with the intermittent passlist block issue. I noticed this error shortly after the above screen shots. Thanks for all you do and also for sharing the code above. Fatal error: Uncaught TypeError: fgetcsv(): Argument #1 ($stream) must be of type resource, bool given in /usr/local/www/snort/snort_alerts.php:858 Stack trace: #0 /usr/local/www/snort/snort_alerts.php(858): fgetcsv(false, 1000, ',', '"') #1 {main} thrown in /usr/local/www/snort/snort_alerts.php on line 858 PHP ERROR: Type: 1, File: /usr/local/www/snort/snort_alerts.php, Line: 858, Message: Uncaught TypeError: fgetcsv(): Argument #1 ($stream) must be of type resource, bool given in /usr/local/www/snort/snort_alerts.php:858 Stack trace: #0 /usr/local/www/snort/snort_alerts.php(858): fgetcsv(false, 1000, ',', '"') #1 {main} thrown [image: 1696655723308-screenshot-2023-10-06-at-5.49.45-pm-resized.png] https://redmine.pfsense.org/issues/14850

You can't. Snort sits between the physical NIC and the kernel network stack before the firewall engine. So, when you run Snort (or Suricata for that matter) on the WAN, it only sees local traffic after NAT has been applied for outbound traffic, and before NAT is undone for inbound traffic. Here are two diagrams that show how the IDS/IPS packages are plumbed into the network. This is an operating system thing and not anything the packages can alter. [image: 1693708940727-ids-ips-network-flow-legacy-mode.png] [image: 1693708951447-ids-ips-network-flow-ips-mode.png] This is why I have been recommending for the last few years that users put the IDS/IPS on internal interfaces. You should do the same. There is no point in having it on the WAN. IDS/IPS is not for protecting the firewall. It's for protecting the hosts behind the firewall. If you need IDS/IPS for your firewall itself, then you really need a new firewall . Running it on the LAN would eliminate your issue of NAT hiding local IP addresses. When running on the LAN, all traffic going to or coming from local hosts would have to pass through the IDS/IPS. And one last note. Without MITM breaking of encryption, IDS/IPS on the firewall is severely limited in what it can accomplish these days because nearly 100% of network traffic is encrypted. The IDS/IPS can't peer into any of the payloads for SSL traffic. That means zero payload inspection of HTTPS, DoT, DoH, SMTPS, IMAPS, and POP3S for starters. That's nearly all of the web traffic, potentially all of the DNS traffic (if you use DoT), and pretty much all email traffic bypassing inspection. Intrusion Detection is rapidly becoming something best done on the local destination host itself and not on intermediate network devices.

@bmeeks I created a list that matches the current rule stub. Attached here. It works with custom area. Sorcerer's code file -->> textrules2.txt

@bmeeks Ah, that is right. I might have gotten confused with that field. It does work omitting the content section. I appreciate your help!