Messages

1

Intrusion Detection and Prevention / ET Telemetry widget not working after OPNsense update 24.7_5

« on: July 26, 2024, 11:15:11 pm »

After OPNsense update 24.7_5 , ET "Telemetry Status" widget doesn't seem to work anymore in the OPNsense's Dashboard. It could now be challenging to see whether the ET Telemetry subscription and its updates are running or not.

The widget just says "Failed to load widget." To be honest, OPNsense's own "System Information" and "Live Log" widgets fail occasionally now too, after the latest update, but they still work now and then when refreshing the browser.

I've tried to reboot OPNsense, cleared the browser, un-installed and installed the "os-etpro-telemetry" plugin from OPNsense's web gui, but no changes. Anyway no biggie, just informing.

- A

2

Intrusion Detection and Prevention / Re: Unchecking "Enabled" on a policy doesn't stop it from processing

« on: May 09, 2024, 07:50:41 pm »

For what it's worth, I've always had to click "Apply" in the "Rules" tab for any change I've done before it to take place, be it Enabling or Disabling some specific rule. I suppose the "Apply" kind of "drives" the actual changes into some memory or file. But that's what has worked for me for maybe years now. Good luck

- Aleksi

same here!
I´m trying to costumize the ruleset with policies. But no matter what settings I use in the policy, it just have no effect on the alerts its generates. 

I would be very happy about a solution

3

Intrusion Detection and Prevention / Re: NMAP detection rules for Suricata in Github

« on: May 09, 2024, 06:29:13 pm »

That's pretty much correct, for example!

The -sX ("Christmas tree scan") rule detects if all the relevant TCP flags are set (flags:FPU), which is rare in normal traffic, and then takes into account the rate of such abnormal packets within a specific time. So, these packets don't need to be originated from NMAP scans specifically, but they could be transmitted from other scanners also.

Another example, the -f ("fragmented packet" scan) rule also detects some specific TCP flags (fragbits:M+D), which is rare, and then takes into account the rate of such abnormal packets. So these also don't need to be originated from NMAP specifically.

Window size 1024 seemed to be a common phenomena in many NMAP scan packets, especially in SYN (-sS) and ACK (-sA) scans, but perhaps other scanners might use that detail also in their packets.

So in short, these rules are built from various NMAP scan type packets captured and inspected in WireShark, but I assume other scanners could use similar packets also, which would make these rules work against them also. Hopefully this answered!

- Aleksi

 

4

Intrusion Detection and Prevention / NMAP detection rules for Suricata in Github

« on: May 09, 2024, 10:47:22 am »

Hi all,

in case anyone wants Suricata detection rules against different types of NMAP scans and scan speeds (T1-T5), I wrote a bundle into Github, which do just that. Tested in a SoHo / home environment:

https://github.com/aleksibovellan/opnsense-suricata-nmaps

Everyday scanning into our WAN interfaces does generate some extra log entries, somedays a lot, but at least I personally like to see who is trying to love my router without consent.

Be safe, everyone, and if you happen to like these rules, please consider to star the repository to make it worth the time. Thanks a lot.

- Aleksi

5

24.1 Legacy Series / /tmp/filter.lock is owned by root and has written permissions to anyone

« on: March 25, 2024, 10:22:48 pm »

I have an OPNsense 24.1.4 running as an operating system in an old HP computer for my home LAN. I installed the OPNsense's "Wazuh Agent" plugin into it from the web gui, which then connected to my separate Wazuh SIEM system.

Wazuh gives interesting results in "Policy monitoring" scanner page. Perhaps this is on purpose in OPNsense installs and systems, but it just spooks a bit, and me of course not knowing the deeper level of OS workings if this is required to be as is. But anyway, who knows if it might be interesting to some.

/tmp/filter.lock
-rw-rw-rw-   1 root  wheel        0 Mar 23 04:10 filter.lock
File is owned by root and has written permissions to anyone.