@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.

For all of this unofficial guide
UPDATE:

WARNING: Per recommendations use a different mount point mnt is used during upgrades so create a custom location to do this with

I created a new location /nvme/LOGS_Optane to use in place of mnt

Do not use mnt as a mount point create a custom location.

Some photos you can still see mnt just ignore them and replace that with name

@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.

Screenshot 2023-10-09 at 10.57.43 PM.png
Before

Screenshot 2023-10-09 at 10.58.08 PM.png
After

@michmoor In Snort's OpenAppID context, "appMapping.data is a file that maps application names to their corresponding AppID identifiers, which are used for creating rules to identify and control application traffic."

@michmoor @bmeeks

Here is, the fully converted appMapping.data to text file...

Screenshot 2023-10-04 at 5.58.46 PM.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

Screenshot 2023-10-06 at 5.49.45 PM.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.

ids-ips-network-flow-legacy-mode.png

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!

If I understand your post correctly, you have devices on your internal networks (LAN) that communicate with a database server located elsewhere on the Internet (accessible via your WAN).

If this true, then you need to simply add the IP address of the remote DB server to a Pass List by creating a list on the PASS LIST tab, accepting the default checked options, adding the IP address of the remote DB to the list using the controls at the bottom of the EDIT LIST screen, then save the new list. Now go to the INTERFACE SETTINGS tab in Snort for your WAN (since your are running Snort on that interface) and select the newly created Pass List in the drop-down selector there. Save that change and restart Snort on the interface.

You do NOT need to be changing the HOME_NET nor EXTERNAL_NET variable settings. Changing those is almost never required. And changing them from the defaults without a full understanding of what they are for and how they work will result in a setup that will NOT trigger rules properly. The fact you altered them in an attempt to solve the problem you describe indicates you may not understand what those parameters are actually for. They define the networks to be protected (HOME_NET) and the networks that are assumed hostile (EXTERNAL_NET). The default setup puts every address/network not defined in HOME_NET in EXTERNAL_NET. Literally, in the PHP code, $EXTERNAL_NET is defined as !$HOME_NET (the leading '!' character indicates a logical NOT operation).

@bmeeks : Bummer. But I understand now. Thanks!

Your post is not entirely clear. Perhaps it is a language translation issue ???

Are you saying that now your pfSense box is behind some kind of double-NAT? You must eventually have a public IP in order to route traffic (not an RFC 1918 address). However, if your pfSense box now communicates with some upstream host that in turn provides a NAT to some type of public routable IP, then your Snort rules update should still work.

I assume other Internet traffic through the pfSense box works?? Or do you really mean to say you have isolated this pfSense box from the Internet? If that is the case, then there is no method for an offline update in the Snort package. It requires Internet access to update its rules.