@jpgpi250 I usually turn off rules here...see arrow in Emerging DNS...

Screenshot 2023-05-31 at 8.47.49 AM.png

May 27 16:02:49 kernel pid 38637 (snort), jid 0, uid 0, was killed: failed to reclaim memory

May 27 16:02:49 kernel pid 38637 (snort), jid 0, uid 0, was killed: failed to reclaim memory

Can be pointed to the storage space and/or
the amount of ram.

@ASGR71 Yes but to be fair 98% of them don’t have any inbound ports forwarding. Some for games or uPnP I suppose.

Sine I don’t see I mentioned it above, if one runs Snort or Suricata on WAN, that runs outside the firewall so will block all sorts of things that would get blocked anyway. Running it on LAN avoids a lot of scanning plus will show internal IPs in the alerts.

@Bob-Dig said in Suricata Inline Mode with WireGuard interface?:

Is it a good or a bad idea?

Interesting question, indeed. One would need a dedicated NIC since one needs Netmap. I was thinking the other day wondering how to assign a NIC to Wireguard...that's how far I got.

@SteveITS

I'm an idiot, was pinging from the wrong firewall! It is indeed blocking. Sorry.
I'll delete my post.

@bmeeks Thanks for this precise description.
OK reverted to scanning LAN ;)

@yet_learningpfsense Also if you’re running Suricata on WAN I’d recommend putting it on LAN. Otherwise it scans outside the firewall so scans all inbound to-be-blocked packets and can only see the NATted IP not LAN devices.

@steveits pfsense restart

@bmeeks said in Snort Behavior:

@defenderllc said in Snort Behavior:

@steveits said in Snort Behavior:

@bmeeks said in Snort Behavior:

the next packet through will simply trigger another block

He's saying it was triggering alerts while the service/interface was showing stopped in the GUI. Hence my comment about a zombie process.

It was still still blocking with the interfaces completely deleted from Snort. I had to reboot to get this to stop.

You should look for Snort alerts under the ALERTS tab of the Snort GUI. You can see blocks under the BLOCKS tab.

Here is what was happening. An excessive amount of SIP traffic triggered a bunch of blocks that pushed memory utilization to nearly 100% and the firewall was inaccessible for about 10 minutes.

I was finally able to get in via console cable and then eventually the GUI. The Snort LAN interface was stopped which was fine with me so I could make some adjustments. The memory remained at nearly 70% and I was super busy with work, so I tried to stop the bleeding by simply stopping the service. That did not work because it would just restart within seconds even without it being configured in Service Watchdog.

The next step was just to delete all of the interfaces in Snort, clear all alerts and blocks... I did this over and over and it did not matter because they just kept coming back despite a lack of any interfaces configured. Memory utilization was still high.

A reboot was what it took to clear everything - include the memory utilization. #LessonLearned

@smoses Plus?
There are a few recent posts about empty package lists…try re-saving your existing update branch setting (Settings/update/Settings).

@yet_learningpfsense said in Source of IP addresses blocked by Snort:

may be cases where a supposedly safe website could become a dangerous one

That is anysite on the planet to be honest - sites get compromised all the time, and then become hosts to malware, etc.

@bmeeks This worked perfectly thanks so much! Wish I did that before posting!

Thanks for the additional information bmeeks! I did check the documentation on Rules Update Settings and didn't see anything about altering the time if scheduled rule updates fail.
It's documented here now so hopefully it will help others.

@oak9 said in Converting undesired Snort blocks into suppression list entries:

The only cleartext transmissions I've seen recently were around the blocks discussed earlier (updater-related stuff apparently still using HTTP).

Some DNS lookups are still cleartext (if you do not have TLS enabled).

Most all websites are now HTTPS including most (if not all) of the Microsoft sites. Rules can trigger off metadata without actually looking at the payload. That is what many of the ET-Info rules look at. Examples are source or destination IP addresses, protocols, ports, and certain non-encrypted metadata present in some protocols. SNI is an example of metadata associated with HTTPS connections that is still mostly unencrypted. But that is changing with the coming introduction of encrypted SNI.

But metadata analysis is not effective for malware detection. After all, a blackhat hacker is not going to clearly identify his malware unless he is a complete idiot 🙂.

ultimately i still have no idea what i'm doing.. just as i think i might have gotten it, something else raises a question that makes me second guess everything.

@bmeeks

Oh, I see the PASS list now, it was right below the EXTERNAL_NET in the UI. Also, thank you so much for that explanation on HOME_NET and EXTERNAL_NET. That makes sense the way you've explained it. I really apricate you taking the time to do that. :)

@jdeloach said in suricata inline confusion:

@cyberconsultants
@jc1976

Just in case you are not aware, Snort and Suricata are not packages that you just install, configure and then forget about like antivirus programs. These packages require constant maintenance if you want to get the full effect of what tasks they perform.

i understand that. I just thought that there would be a way to more easily have the benefits of in-line scanning with the easier configuration of legacy.

@steveits I collect descriptions from suppress file:

(http_inspect) PROTOCOL-OTHER HTTP server response before client 120:18 (http_inspect) NO CONTENT-LENGTH OR TRANSFER-ENCODING IN HTTP RESPONSE 120:3 (http_inspect) UNESCAPED SPACE IN HTTP URI 119:33 (http_inspect) BARE BYTE UNICODE ENCODING 119:4
All alerts has it's own GID:SID

I know that alerts are from SpeedTest because I have done an extensive test.