Messages

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

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 :)

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! 8)

- Aleksi

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