IPS/IDS not working

[mhobbelen]

After enabling IDS (or IPS) and enabling all rules, the engine is not working (running IPS test like curl -A "BlackSun" www.google.com doesn't trigger an alert on the firewall (USG 3.0). DNS is working, so that's no the issue.

Suricata.log (/var/log/suricata) is showing the following details:

[4799] 1/3/2022 -- 11:43:24 - (suricata.c:1107) (LogVersion) -- This is Suricata version 4.0.5 [4806] 1/3/2022 -- 11:44:01 - (runmodes.c:647) (RunModeInitializeEveOutput) -- [ERRCODE: SC_ERR_INVALID_ARGUMENT(13)] - No output module named eve-log.files [4938] 1/3/2022 -- 11:44:01 - (util-ioctl.c:317) (SetEthtoolValue) -- [ERRCODE: SC_ERR_SYSCALL(50)] - Failure when trying to set feature via ioctl for 'eth1': Operation not supported (122) [4938] 1/3/2022 -- 11:44:01 - (util-ioctl.c:399) (GetIfaceOffloadingLinux) -- [ERRCODE: SC_ERR_NIC_OFFLOADING(284)] - NIC offloading on eth1: SG: SET, GRO: unset, LRO: unset, TSO: unset, GSO: unset. Run: ethtool -K eth1 sg off gro off lro off tso off gso off [4806] 1/3/2022 -- 11:44:01 - (tm-threads.c:2182) (TmThreadWaitOnThreadInit) -- all 1 packet processing threads, 4 management threads initialized, engine started. [4806] 1/3/2022 -- 11:48:20 - (detect-engine.c:2911) (DetectEngineReload) -- rule reload starting [4806] 1/3/2022 -- 11:48:55 - (detect-engine.c:2973) (DetectEngineReload) -- rule reload complete [4806] 3/3/2022 -- 00:02:08 - (detect-engine.c:2911) (DetectEngineReload) -- rule reload starting [4806] 3/3/2022 -- 00:02:44 - (detect-engine.c:2973) (DetectEngineReload) -- rule reload complete

It seems to be related to offoading settings on the eth1 interface.

Can someone help me out? I'm running the config.gateway.json with ipv6 enabled and iptv on a different vlan.

[fwieringen]

Experience the same issue. Looked a bit further in the logfiles and apparently, the IPS/IDS doesn't start up because it cannot resolve the hostname:

[2022-03-28T15:27:04,415] <ips-alert-caching> WARN ips - Error in ips java.net.UnknownHostException: ips1.unifi-ai.com at com.ubnt.service.ips.B.o00000(Unknown Source) ~[ace.jar:?] at com.ubnt.service.ips.B.null(Unknown Source) ~[ace.jar:?] at com.ubnt.service.ips.E.super(Unknown Source) ~[ace.jar:?]

[fwieringen]

Since I am able to ping the host (ips1.unifi-ai.com) from the controller, it appears to be some sort of timing issue where the internet connection is not yet up at the moment the IPS/IDS tries to connect to that specific host.

[mhobbelen]

Have you tried changing the hardware acceleration option on the interface? I didn’t (i need a time window from my wife 😉). I’ll investigate if I’m experiencing the same timing issue as you are referring to. You’re sure it’s not dns related on your box? Your pointing to an internal dns server or the cloudflare default from the config file?

[fwieringen]

Hmm... how do I change the hardware acceleration option on the interface? I think it's using the DNS server which is assigned through the PPPoE connection of KPN. However, it takes some time to build this connection after provisioning.

My config: Unifi Cloud Key v1, USG 3P, kpn-ftth-json script to get things running.

[coolhva]

Did you try to remove this block of code in the JSON?

          "offload": {
            "ipv4": {
                     "forwarding": "enable",
                     "gre": "enable",
                     "pppoe": "enable",
                     "vlan": "enable"
            },
            "ipv6": {
                    "forwarding": "enable",
                    "pppoe": "enable",
                    "vlan": "disable"
            }
        }

[denniswo]

I experienced the same issue and removing the offload section from the JSON (and reprovisioning obviously) instantly brought back the traffic statistics. Thanks!

Before removing the offload section, I played around with the settings in the controller UI (7.0.23). With "threat management" on, no matter what other options I selected (even switching off all categories), I got no identified traffic. (Traffic identification is enabled of course.) Switching threat management off brings back the traffic stats.

After removing the offload section from the JSON, I can have threat management on and I still receive the identified traffic. So I'm happy. But what did I lose by removing this code from the JSON?