ah that make sense 👍

It's hard to say without having a full diagram, but what the note I linked to was essentially saying is if there is a way for a connection to be see on more than one interface, or if there is a way for the some traffic to take one route while other traffic can take another, and these alternate routes allowed traffic to escape notice by Snort, then you would have the asymmetric issue.

Maybe the firewall is it, but I'm not too sure it is.

@bmeeks Thanks for the reply.

But it's not really the physical (OS) interface that is recorded in the config file either - it's entry name in the pfsense interfaces config hash (e.g. "opt7"). So Suricata is already looking that up with get_real_interface() to find the OS interface name (e.g. "ovpns4"). The problem lies though in keeping things in sync - since you can change the interface description at any point, we really must use the interface value instead.

I could still imagine an option for the sync process to use the interface description somehow - but this would be much more complicated than the current process.

@bmeeks "Should" still doesn't mean "must", which is especially important when you'll consider that there's no warning before actually starting blocking mode. The fact I knew about that was only because in Suritaca I had a lot timestamp alerts, which Internet told me, was related to the hardware checksum being enabled. ;) But like I said - I did turn all of them off with Suricata. I didn't know that it's also needed for Snort until I turned on blocking mode, because there was no indication for that before.

I will turn them off for the testing phase! :)

pfSense version: 2.4.5-RELEASE-p1/FreeBSD 11.3-STABLE

BTW Thanks for the explanation!

@Cool_Corona said in Suricata needs a reboot after change to alias/suppress list:

Nope. No service watchdog installed.

Good! It is not compatible with the Snort or Suricata packages as they run multiple copies of their daemon when configured on multiple interfaces, and Service Watchdog does not know how to cope with that. It also gets fooled with Snort or Suricata automatically restart themselves after a rules update or if the admin does something like you were doing in the GUI to restart the service. The Watchdog package simply sees the monitored daemon disappear from its scan, so it immediately executes the shell script to restart the service. But something else may be restarting the service, and thus then two copies of the same interface daemon can get launched.

In your case I'm not sure how two instances got started. But when that happens, the GUI is only able to control and communicate with one of them. Thus the other one will no longer respond to start, stop or configuration change commands (such as changing the Pass List or Suppress List, for example).

@kiokoman said in suricata show Alert on wrong interface:

@bmeeks

about:

Interface PCAP Snaplen
This value may need to be increased if the physical interface is passing VLAN traffic and expected alerts are not being received.

what is a good value to put in here ? 1522 = 1500 + ethernet + vlan ?

The snaplen parameter needs to be long enough to hold the standard Ethernet frame plus any VLAN overhead. There is still debate, it appears, on the web about what to use. A quick Google search will find several links. So sorry to say I can't give you a good answer. I put the field in the package to allow users to experiment if they felt the need. The default value is still what has always been with each IDS package. The field was added to allow those who wanted to experiment to do so.

you said it is most efficient..to put the IDS on the parent interface

is it considered wrong to have instances on each VLAN ? for example for the vlan where i have some servers running i set IPS Policy Selection to security while on the other vlans i set it as Balanced,
is it better to run only one istance and set the policy to security on the parent interface ?

Nothing is generally considered "wrong" with an IDS configuration. It simply comes down to RAM and CPU utilization balanced against the security needs. If it is vital that two VLANs have different security policies applied, then running an IDS instance on each with different configured rules is what it takes. However, if you find both instances have, for all intents and purposes, the same rules, why waste RAM and CPU time with an IDS instance on each VLAN? Just run a single IDS instance on the parent and see everything in the configured VLANs.

@Liceo said in Why app-stats.log doesn't appear in Alterts Tab?:

I set up a new instance of pfsense from scratch with one LAN and one WAN interface on hyper-v (gen 1). I generated some facebook and netflix traffic but Snort only shows some http alerts. Maybe a hyper-v related problem. I still think it just doesn't capture SSL traffic

snort-no-ssl.jpg

Snort captures OpenAppID alerts on SSL just fine. Look at my screenshot from my own testing. Something appears to be non-standard in your setup. Do you any kind of web proxy installed?

@bmeeks said in Overlap Running Multiple Rule Sets?:

@tman222 said in Overlap Running Multiple Rule Sets?:

Thanks @bmeeks. So using a combination of SID Management and IPS Policies I could, for instance, run the IPS Balanced policy but auto-disable some of the categories that are represented if the attack surface is not relevant (e.g. let's say rules pertaining to IIS servers), and then just run the remainder (of the policy rules). Are you aware of a good source that explains the different rule categories? Thanks again.

You would have to disable by GID:SID values instead of categories if you use an IPS policy. Rules in a policy are auto-selected based on policy metadata embedded within each rule. Unless I was really short on RAM, I would not bother with such granularity if using a policy-based approach.

Documentation of everyone's rules, both Snort and Emerging Threats, is basically non-existent. You have to learn to read the rule syntax for yourself and then learn about the various exploits. In short, you have to become a blackhat hacker of a sort so that you fully understand the exploits and how they work, then you learn to use the Snort rule syntax and that combination makes you an IDS security admin. It is a very technical field with few truly qualified folks; and the good ones can command very high compensation.

Thanks @bmeeks - even if using a policy approach, wouldn't disabling a couple thousand rules (if they aren't relevant) help performance since there is less work for the CPU to do? Or am I overestimating the relative impact if the rule set is already quite large (e.g. let's say 10000+ rules).

I think this is a fascinating area and have enjoyed digging into the different categories and rules to try to learn more and optimize my setup. Thanks again for all your help along the way.

@powerextreme said in SNORT ET Alerts:

can I set up snort to just capture when this rule is triggered? Or will it do it for all rules?

No, the PCAP capture option is not rule specific. It would be for all rules. The easiest thing might be to just kick off the backup job on the Synology again and capture the traffic on the LAN interface (or whatever interface it is traversing) directly on pfSense using the network caputure feature under DIAGNOSTICS on the menu.

After some further reflection, I decided to go back to running Snort in legacy (pcap) mode for now. I was able to try out Suricata as well for comparison, but after some initial testing in inline mode I saw similar throughput limitations. Given the interesting asymmetry I saw in upload and download speeds, I plan to revisit inline mode in Snort once pfSense 2.5 is released and there is support for multiple host rx/tx rings to see if that will help improve (upload) throughput.

@buggz said in Performance on IDS/IPS:

Was this change on both the WAN and LAN, or just the Snort interface, which for me is LAN.

Thanks!

Both. (all)

@5cub4f1y said in Suricata Not Starting, Blank Log File:

It won't let me edit any post older than 3600 seconds. Oh well. Anyone viewing this will obviously be able to tell its resolved anyway, and working like a charm. :)

Let me see if it will let me change it. I am supposedly a moderator for this sub-forum.

Edit: Yep, let me do it.

And you get really good info ones like:

1:2009968 # Potential Corporate Privacy Violation -
Src.192.168.2.45:27960 Dest.68.232.172.16:27960
ET P2P eMule KAD Network Connection Request(2)

Though this is showing I am the Source?
Hmm, time to thorough scan...

Haha, that WAS me, playing Enemy Territory.
BUSTED! hehe...

No, if you have the package installed and one or more interfaces with Enabled checked on the INTERFACE SETTINGS tab, then the system will attempt to start the services at boot. The only way to prevent that is to go to the INTERFACES tab, select a Suricata or Snort interface, and then edit it. On the INTERFACE SETTINGS tab uncheck the Enable checkbox to disable that interface. That will prevent it from starting on future boots. Of course you can delete the entire Suricata or Snort instance on the interface as well using the Delete icon.

Questions about Snort 2.9.x support would need to be directed at the Snort team over at Talos/Cisco. My guess is no new features will get into Snort 2.x, but critical bug fixes might be addressed going forward after Snort3 goes full release. Of course it's been many years since any really new feature was added to Snort 2.x. I think the last big one was OpenAppID.

You would run Snort3 on pfSense just like you would run it on any other Unix-type system. Install the binary, hand-edit the necessary configuration file or files, install the rules manually using something like PulledPork or other tools, and then either create your own or use any provided shell script to start Snort3. There would be absolutely no GUI interfacing at all. No logs to see in the GUI, no configuration in GUI, and no control from the GUI.

As for netmap support, that actually depends on the shared DAQ library produced by the Snort team. There is a new version of DAQ used in Snort3. I do not know for sure, but I don't believe they have imported support into the Snort3 DAQ for software host rings. I think it is still limited to supporting only hardware rings. That means you can't set up Snort3 to sit between the NIC and the host stack like you can with Snort 2.x and the older DAQ-2.2.2 that I modified. So netmap will work, but to do anything meaningful with it in pfSense will require you to use two physical interfaces on the box in order to implement a true inline-IPS mode. Not very interface efficient for sure.

And finally, unless you use two physical interfaces as mentioned above, there would be no blocking with Snort3 on pfSense. It would be IDS only. No IPS as there is no custom legacy blocking output plugin for Snort3.

@p54 said in URLHaus - Anyone have a mod already?:

for me it does not work at all according to the instructions linked above.

just i overwrite the custom.rules with the following script:

#!/bin/sh fetch -o /usr/local/etc/suricata/rules.local/urlhaus_suricata.tar.gz https://urlhaus.abuse.ch/downloads/urlhaus_suricat a.tar.gz tar xvfz //usr/local/etc/suricata/rules.local/urlhaus_suricata.tar.gz -C /usr/local/etc/suricata/rules.local/ rm /usr/local/etc/suricata/rules.local/urlhaus_suricata.tar.gz rm /usr/local/etc/suricata/suricata_32296_igb1.300/rules/custom.rules mv /usr/local/etc/suricata/rules.local/urlhaus_suricata.rules /usr/local/etc/suricata/suricata_32296_igb1.300/rules/cus tom.rules chown root:wheel /usr/local/etc/suricata/suricata_32296_igb1.300/rules/custom.rules chmod 644 /usr/local/etc/suricata/suricata_32296_igb1.300/rules/custom.rules

under cutsom.rules was nothing to see and after the refresh the custom.rules had shrunk to 0 kb :/
anybody still some tips for me?
BR

Guys, Snort and Suricata on pfSense are GUI applications! That means everything is configured within the GUI, stored in the config.xml of the firewall, and then written out to the pertinent configuration and rules files each time Suricata or Snort is started. So all those changes you make via a CLI session are immediately overwritten the instant you go back into the GUI and start Suricata or Snort.

Custom rules must be entered from the RULES tab in the GUI. They are then stored in config.xml as Base64-encoded text. That text is read back out and written to the custom.rules file each time the GUI is used to start Suricata or Snort.

If you absolutely must have those rules, then you have to make an edit to the PHP source code files of the package. And be aware that change will be overwritten the next time you update or otherwise reinstall the package. You will need to manually edit the file /usr/local/pkg/suricata/suricata_yaml_template.inc and include a path to your URLHaus rules file in that template. The template is used to create the suricata.yaml file for each interface. Be warned that if you are not familiar with PHP coding syntax, you can very easily break your Suricata installation.

Thanks guys to you both. In fact, I actually looked through the rule sets in more detail over the last couple of days and noticed quite a number of rules that wouldn't be applicable in my particular case, which is just a standard home network. For example, there are number of rules specifically for mail servers which wouldn't be needed (I don't run any mail servers). Since the traffic would be dropped by the firewall anyway there's no need to have it go through the Snort detection engine first and occupy CPU cycles unnecessarily. Anyhow, I was able to grab the relevant rule GID and SID's and add them to the disable list under SID Management. Rebuilt the rule set for the interface(s) and showed up disabled as expected.

@powerextreme said in SNORT Alerts and Interfaces:

@NogBadTheBad
I have a similar rule earlier in the thread. How does your's effectively differ?

You didn't post the whole picture with the pass sections.

Why just not log the blocks to a syslog server, I send my logs to the syslog server on my NAS.

Check out TCP port 7000:-

https://www.speedguide.net/port.php?port=7000