Messages

I use ET Telemetry, and my rules downloaded last night but the log is full of load errors, like the following (there are lots more lines). I also note that there hasn't been an event in 4 days (very unusual), which may be related to this.

Sep 18 09:00:51   
suricata[96398]: [100133] <Error> -- [ERRCODE: SC_ERR_INVALID_SIGNATURE(39)] - error parsing signature "drop http $HOME_NET any -> $EXTERNAL_NET any (msg:"ET WEB_CLIENT Possible Credentials Sent to Suspicious TLD via HTTP GET"; flow:to_server,established; content:"GET"; http_method; content:"user"; http_uri; nocase; content:"pass"; http_uri; distance:0; nocase; fast_pattern; pcre:"/\.(?:ga|gq|cf|ml|gdn|tk|icu)$/W"; flowbits:set,ET.eduphish; metadata: former_category PHISHING; classtype:trojan-activity; sid:2025113; rev:3; metadata:affected_product Web_Browsers, attack_target Client_Endpoint, deployment Perimeter, tag Phishing, signature_severity Major, created_at 2017_12_04, updated_at 2019_02_06;)" from file /usr/local/etc/suricata/opnsense.rules/emerging-web_client.rules at line 145


Sep 18 09:00:51   
suricata[96398]: [100133] <Error> -- [ERRCODE: SC_ERR_DUPLICATE_SIG(176)] - Duplicate signature "drop http $HOME_NET any -> $EXTERNAL_NET any (msg:"ET WEB_CLIENT Possible Credentials Sent to Suspicious TLD via HTTP GET"; flow:to_server,established; content:"GET"; http_method; content:"user"; http_uri; nocase; content:"pass"; http_uri; distance:0; nocase; fast_pattern; pcre:"/\.(?:ga|gq|cf|ml|gdn|tk|icu)$/W"; flowbits:set,ET.eduphish; metadata: former_category PHISHING; classtype:trojan-activity; sid:2025113; rev:3; metadata:affected_product Web_Browsers, attack_target Client_Endpoint, deployment Perimeter, tag Phishing, signature_severity Major, created_at 2017_12_04, updated_at 2019_02_06;)"

I have the same problem. Manual update OK, proofpoint says all ok, no updates. Running 19.1.6.

I had been using what is described in:
  https://forum.opnsense.org/index.php?topic=7811.0
since it was proposed and it worked fine until 19.1.4 and 19.1.5, but now results in DNS leaks while using VPN. The logs actually look OK, but various DNS leak test fail. I even rebuilt unbound 1.8.1 manually as proposed in the other thread but that didn't change anything. I really liked using this DNS TLS stuff, but I need to get rid of it just to fix the leak.

I don't use PPP and ids/ips isn't recording alerts or generally working, even after upgrading to 19.1.2.

I used to see all kinds of alerts, now the only thing I've seen in the last month is "ET INFO Session Traversal Utilities for NAT (STUN Binding Request)". Even the ProofPoint summary window shows no events for days at a time.

I'm surprised this thread went quiet because I'm still not seeing alerts on 19.1.2, except for "ET INFO Session Traversal Utilities for NAT (STUN Binding Request)". That's the only thing I saw all of Feb, while usually I see a lot of activity in the alerts list.

Using ET Telemetry and abuse.ch rules, tried both Aho-Corasick and Hyperscan, no difference.

Did it start working for the other people that posted here?

I learned something from reading bits and pieces in the forum that fixed my problem, and since I thought it wasn't that uncommon a situation I'd summarize in case it is useful to someone else. Perhaps this is documented somewhere, if so I missed it...

I make several VPN connections to different geographic locations, which I think others do as well (most VPN vendors allow this).  Then I route different devices to different locations. This was generally working, but often it would suddenly stop and I'd have to restart the VPN connections. I was connecting all of them using UDP and port 995, and my VPN vendor has a single certificate for all locations. What would happen was that all VPN connections would get a virtual address of the form 10.X.0.Y, where X was constant, and the different connections would get different Y's.  Every now and then different connections  would get the same Y, which is when things would stop working.

What I learned is that depending on the protocol (UDP/TCP) and port number that is configured, the value of X changes, so conflicts in random Y values can be avoided. For example, TCP/443 (X=8), UDP/1912 (X=35), UDP/1195 (X=33), UDP/995 (X=24), etc.  I also read that different certificates might affect X, but as I only have one certificate I don't know if that is true.

So, for anyone who makes multiple VPN client connections to different geographic locations (using the same vendor account) make sure they use different protocols and/or ports, and everything will work fine. Actually, this would probably also work for multiple connections to the same location to get redundancy/speed.

I just upgraded to 18.1.13 and noticed some odd things, so I thought I'd try and add some details in the hope that it helps the always helpful OpnSense team

System is a Qotom Q355G4
CPU: i5-5250U
RAM: 8GB

NOTE: after every setting change below I rebooted to make sure results were "clean"

phase 1 - update to 18.1.13, reboot, reload all suricata rules with URLhaus disabled

a) using hyperscan - runs ok
    system memory 1059M

    suricata memory usage (from System->Diagnostics->Activity)
    Mem Size: 2805M
    Res: 350M

b) using aho-corasick - runs ok
    system memory 1129M

    suricata memory usage (from System->Diagnostics->Activity)
    Mem Size: 2913M
    Res: 443M

phase 2 - enable URLhaus,  download all rules

a) using aho-corasick - runs ok
    system memory 1794M

    suricata memory usage (from System->Diagnostics->Activity)
    Mem Size: 3565M
    Res: 1069M

b) using hyperscan: crashes

phase 3: disable URLhaus

a) using hyperscan: crashes (but it worked above!!)

so, the only thing that was different in 1a above was that the rules for URLhaus showed "not installed" at the start, rather than just disabled. So, I downloaded all the rules again so it showed "not installed" again for URLhaus, and rebooted:

using hyperscan: works again

so, the URLhaus rule can't even be installed it seems, even if disabled.

FURTHER ODDITY:

after the crashes, when I changed settings and clicked reboot, the screen paused for a while but then came back to show stats rather than to the login screen. Also, uptime showed no reboot occurred. Tried twice, same thing. Also tried shutdown, which also didn't work!!

So, I had to power cycle after the failures to cause a reboot to happen. Very odd, thought I'd mention it.

I hope the above is helpful, please let me know if I can provide other info.

I updated to 4.0.5, and switched to hyperscan, and after a few minutes suricata crashed again.

Reverted to current and switched to aho-corasick and it is working again.

My CPU is an I5 5250U, SSE 4.1, 4.2, AVX2....

- I downloaded all the rules and restarted -> crash
- I reinstalled suricata -> crash
- I switched from hypersan to aho-corasick -> running

URL haus from abuse was enabled, so I disabled and tried again. Same as before, memory use grows beyond the 1.1GB it used to use up to around 2.3GB, then drops down when suricata dies.

I rebooted and tried again, same results.

I disabled IPS and just ran IDS, same result, dies after a couple of minutes.

All abuse and ET Open rules enabled.

OPNsense-App-detect/test enabled, other App-detect disabled.

I'd be happy to give you the log file, but don't know how to get it. Can it be accessed from the GUI?

I reported the same thing on the 18.1.12 update.

After the latest update suricata is crashing. The dashboard shows that the memory use grows up to about double what it used in 18.1.11 and then it dies. The log shows:

Jul 15 16:23:42   kernel: pid 532 (suricata), uid 0: exited on signal 6 (core dumped)
Jul 15 16:20:19   kernel: -> pid: 300 ppid: 97610 p_pax: 0x850<SEGVGUARD,ASLR,NODISALLOWMAP32BIT>
Jul 15 16:20:19   kernel: [HBSD SEGVGUARD] [/usr/local/bin/suricata (300)] Suspension expired.

hardware is a quotom q355g4, using openssl.

restarting it the memory slowly increases and then it crashes again.

I tried again today without any config changes, and 18.1.10 openssl. Everything is running fine after about 15 hours. Not sure why it failed quickly yesterday and is fine today.