@Enso_ said in SNORT stopped generating alerts:

Additionally, I have a question regarding the 'Suppress' menu. I noticed a list titled "lansuppress_xxxxxxx" with the description "Auto-generated list for Alert suppression." Does Snort generate these suppression lists automatically? If so, what criteria are these lists based on?

This is an auto-generated file that gets created whenever someone presses the Suppress icon on the ALERTS tab and there is no assigned Suppress List. If there is no currently assigned Suppress List for the interface, then when the user clicks the icon to suppress an alert shown on the ALERTS tab, a file is automatically created and given a name using the pattern you posted.

As for why Snort is not generating alerts, you should check that the instance is actually running by using this command from a shell prompt obtained either directly on the firewall console or via SSH (do NOT use the commands in the GUI):

You should see one Snort instance listed for each configured and running Snort interface. If you see running instances, then you can use a tool such as nmap to purposefully send penetration test traffic into a Snort protected interface to see if any rules trigger.

@michmoor said in packet log being generated?:

@bmeeks

Should i add the following to the top of the code in the PHP file but below the initial comments?

<div style="background-color: #ffcc00; color: #000; padding: 10px; text-align: center; font-weight: bold; border: 1px solid #ffa500; margin-bottom: 20px;"> Any changes to the settings below will require a restart of the package. </div>

No, that will break the entire page and mess up the pfSense header and footer rendering. You will need to examine the existing PHP code files and learn by example. You can experiment in a VM running pfSense. If you have never programmed in PHP, and in particular within the pfSense PHP GUI environment, you need to take some time to learn the basics before jumping in and making changes.

@Enso_: you are correct. Only the Snort VRT ruleset contains the proper metadata keywords for implementing an IPS Policy.

IPS Policy logic in the Snort package reads the policy metadata provided in the Snort VRT rules and uses that data to automatically select rules that have metadata tags matching the chosen IPS policy. Neither ET rules nor any other vendor ruleset contain IP policy metadata, therefore they can't be automatically screened and selected. That's why those rules remain "selectable" in the GUI but Snort VRT rules do not, when IPS Policy action is enabled.

Those are two independent things: File Store versus EVE JSON http logging. File Store captures all file transfers where appropriate flow bits are set by rules. EVE JSON logging is about capturing the packet metadata and payload (when enabled).

So, turning off HTTP logging in the EVE JSON logging options should remove logging of HTTP packet metadata, but that will not stop File Store activity related to HTTP. To the best of my recollection that is triggered by the rules you have enabled for file capture and the corresponding flowbits they may set.

It runs alongside pfSense as a package. The logs can be configured by way of the package.

@killmasta93 said in Question about thresholds:

hi @bmeeks quick question so i added the following

threshold gen_id 1, sig_id 2009244, type both, track by_src, count 10, seconds 10, priority 1 threshold gen_id 1, sig_id 2009245, type both, track by_src, count 10, seconds 10, priority 1 threshold gen_id 1, sig_id 2009246, type both, track by_src, count 10, seconds 10, priority 1

would the variable

type both

work for both ends?

Thanks

Here is a link to the official Suricata docs describing the type: keyword: https://docs.suricata.io/en/latest/rules/thresholding.html#type-both. both specifies both a rate limit and threshold value.

I have a 2100 and I use to have issues with memory on snort updates. I installed a swap partition on a dedicated external HDD drive that was designed for heavy use, and it fixed all my update resource issues. Long story short you have to free up memory or have a plan for when it is used the most. do not rely on swap all the time, but I admit I rely on it for ClamAV updates and snort updates should the happen at the same time, Murphys law when can go wrong will go wrong, some times my blacklist, snort and clamav all attempt to update at the same time it is very rare sometimes on reboots or package reinstalls but you got to plan for it. The 2100 should have an 8GBs ram option to function perfectly, again nothing is perfect so we got to roll with it. Do a flash drive and set it up as a swap.

“the SSD manufacture had this to say about me using it like this...
"Hi Jonathan,

This will damage the drive, it is not safe. Moreover, the response speed and read and write speed are far inferior to RAM. We recommend you not to use it this way, it will probably cause the SSD to become defective."

I really want to use something long term as I am limited on what I can do with this box it has hard set ram without any way to add or remove them. The NVMe drive is the only solution outside of a USB based HDD however that like you said is very slow.

The ZFS yes is a concern with the drive however it shows with gpart as FreeBSD

I triggered a panic and it works with crash dumps also. I had Netgate forum help me with this and FreeBSD forum. I am thinking I should use a actual USB based HDD in the long run to abuse it with swap use however with a firewall that would really slow it down.

Check out
ada0s3
Shell Output - gpart list -a”

Warning Do not use your internal SSD for swap.

Ref:

https://forums.freebsd.org/threads/resolved-usb-based-swap.93362/#post-654423

This FreeBSD research I did got me going also Netgate forum if you want to make a swap.

@cyb3rtr0nian said in Important Info: Inline IPS Mode with Suricata and VLANs:

This is correct. The netmap implementation in FreeBSD does not deal with VLAN tags. They do indeed get stripped out.

Such a shame though, I mean Pfsense+Suricata is an amazing product already, but it would be even more amazing if we could combine both the segmentation of VLANs with the policing of Suricata inline IPS don’t you think? I have it running in IDS mode with several VLANs on the untagged interface. (But I still prefer the In-line IPS mode. ) Will there ever be a different emulation device used in the future capable of reading VLAN tags you think?

I seriously doubt the netmap limitations within FreeBSD itself with regard to VLANs will be fixed in the future because it would require rewriting substantial portions of the kernel network stack code. That would potentially break other things.

One thing currently implemented in the pfSense Suricata package is a software-enforced ban on using emulated netmap adapters. This was done in the interest of speed (and because of some other quirks that once existed with the emulated netmap adapter). The creation of IPS mode on an interface is restricted unless the NIC driver supports native netmap operation. VLAN interfaces are inherently a virtual interface in the operating system and thus can never pass the "native mode" test for netmap operation. The pfSense Suricata package silently adjusts any VLAN-enabled IPS interfaces to use the physical NIC instead of the VLAN virtual interface.

There have been a few beneficial updates to the netmap adapter code in recent editions of FreeBSD. None of them address the fundamental slowdown you experience when using a host stack endpoint, though.

It would be possible to make some test edits to the PHP source code of the package to enable IPS operation with virtual VLAN interfaces using the emuated netmap adapter. I suspect throughput will be pretty abysmal unless you have a very powerful CPU, but someone may want to test it. I do not have a VLAN setup in my private LAN. I keep it pretty simple, and I no longer have a large test lab either. But if you want to tinker around with emulated netmap, I can share which sections of PHP code to edit. It's fairly trivial. There is one caveat, though. The emulated adapter with VLANs will only work on the newest versions of pfSense Plus (and possibly 2.8.0 DEVEL once those snapshots resume). It will not work without throwing a syntax error on pfSense 2.7.2 CE and versions earlier. The libnetmap code update that allows proper parsing of VLAN interfaces by netmap was only added to pfSense with the move to FreeBSD 15-CURRENT. That code fix is not present in earlier pfSense kernels.

@Gblenn Thanks for the reply. Yes, I've tried that as well. The issue is that in our particular case, we only want/need Suricata to run on some of the vlans assigned to the parent interface. The others we need to remain wide open.

I was looking for this info @bmeeks,

Now I am sure that it is only an internal connection and that not everything is disabled.
Thank you very much!

Have a nice day and thanks for your work.

Hello @bmeeks,

This was indeed exactly what happened.
I have rebooted my pfsense server in the past, which I would expect create same results, but either it didn't work, or it spinned another ghost process afterwards.

Anyways, I will monitor to see if it keeps happening.
I have seen other posts where other people have similar issue indeed, and will investigate from there if duplication happens again.

In any case, thank you very much for your kind help here.