Wat doet die IDS/IPS eigenlijk?

1. Zes configuraties, echt gemeten

Alles vanaf dezelfde machine (M5 Max, 2.500Base-T op de kabel), tegen dezelfde server (KPN Amstelveen, Ookla 61186), één machine tegelijk, met 45 tot 50 seconden tussen elke wijziging zodat de UDM zijn configuratie kon uitrollen.

Upload lag in alle zes de gevallen tussen 1,4 en 2,0 Gbps en wordt niet geraakt. De rem zit uitsluitend op binnenkomend verkeer.

Waarom geen enkele tussenvorm werkt

De oorzaak staat in de Ubiquiti Community Wiki: "IPS/IDS features disable hardware offload", en daarbij wordt expliciet vermeld dat ook het routeren tussen interne netwerken eronder lijdt (bron). De versnelling gaat dus globaal uit, niet per netwerk.

Op het apparaat zelf is voor elk van de vier mislukte tussenvormen de mechanische verklaring terug te vinden. Dit is geen theorie, dit staat in de configuratie en in het logboek van de gateway:

Eén meting bewijst dat, en het is de scherpste van de dag. Bij het VLAN-scenario heb ik het hoofdnetwerk uit de inspectie gehaald en alleen het IoT-VLAN laten inspecteren. Dat is aantoonbaar goed doorgekomen: het bestand waarin staat wat suricata afluistert ging van br0 plus br200 naar alleen br200, en na herstel weer terug.

Suricata keek dus werkelijk niet naar het verkeer van je pc's. En toch bleef de download op 909 Mbps steken in plaats van richting de 1.542 te lopen.

Het logboek meldt daarnaast "Going to use 1 thread(s)" per bridge: één enkele thread inspecteert al je verkeer op een processor met vier kernen. Dat verklaart niet de 660 Mbps die je kwijtraakt, maar wel het pakketverlies in hoofdstuk 4.

Onafhankelijke bevestiging dat er niets te finetunen valt komt van een meetreeks op een UDM Pro aan een 8 Gbit-lijn: uit ~8 Gbps, aan ~3,5 Gbps, en dat cijfer bleef gelijk bij 3, 16, 32 en 45 signature-categorieën (meting van Ethan Word). Categorieën uitzetten vermindert dus alleen de ruis, niet de rekenlast.

2. Wat heeft het tegengehouden?

Dit was de kernvraag, en hij is lastiger te beantwoorden dan hij lijkt. De alerts staan niet in de collectie ipsalert waar je ze zou verwachten, die is leeg. Ze staan in de collectie alert onder de sleutel THREAT_BLOCKED_V3. Daar staan er 58, van 22 juni tot vandaag.

Negen daarvan zijn uitgaand, vanaf je eigen machines naar buiten. Ik heb elk doeladres opgezocht met whois en reverse-DNS in plaats van het te gokken:

Negen van de negen zijn onterecht. Je eigen Mac mini benaderen over je eigen Tailscale-netwerk wordt weggeschreven als dreiging met urgentie HIGH.

Die 58 zijn een maandtempo, geen totaal

Aanvankelijk dacht ik dat er vóór 22 juni simpelweg geen dreigingen waren. Dat klopt niet, en het is netjes te bewijzen. De meldingen worden opgeruimd na ongeveer 30 dagen.

Het sluitende bewijs zit in een gewone inloggebeurtenis. In de meldingentabel staan 834 ADMIN_ACCESS-records, en het oudste is van 20 juni. Maar exact diezelfde inlogs staan óók in een tweede tabel, en dáár lopen ze door tot 12 mei. Er waren dus aantoonbaar inlogs vóór 20 juni, ze zijn alleen uit de meldingentabel verwijderd. Drie totaal verschillende soorten meldingen, met 2, 9 en 27 records per dag, houden allemaal op rond 20 tot 22 juni. Bij een limiet op aantal zouden die data ver uiteenlopen. Bij een limiet op tijd vallen ze samen, en ze vallen samen.

Mijn eerdere vermoeden dat de meldingsvorm bij een software-update was gewijzigd, is daarmee ook van tafel: de laatste update was 27 mei, bijna vier weken eerder, en onder oudere benamingen staan nul records.

Dat verandert de betekenis van het getal. 58 is geen totaal maar een tempo: ongeveer twee per dag. Het verandert de verhouding niet, want negen van de negen controleerbare zijn nog steeds onterecht, maar het is eerlijker gesteld.

De markering van het laatst gelezen alarm staat overigens nog op 29 mei 2025. Dat is een dode verwijzing uit de oude meldingenpijplijn, geen bewijs dat er niets gebeurde. Wat wel blijft staan: er is in de praktijk niemand die deze lijst bekijkt, en detectie werkt alleen als iemand kijkt.

3. Wat je al hebt, en wat dat waard is

Voordat je iets uitzet is het eerlijk om te kijken wat er dan overblijft. Alles hieronder is nagetrokken op het apparaat zelf, niet aangenomen.

Je firewall doet vijf keer zo vaak iets nuttigs als je IPS, en kost je geen enkele megabit.

4. Wat je precies koopt voor die 45%

Tot nu toe ging dit rapport over de kosten. Dit hoofdstuk gaat over wat er aan de andere kant van de weegschaal ligt, en dat is minder dan je zou denken. Alle drie de punten hieronder komen uit bestanden en logboeken op de gateway zelf.

Het mist nu al pakketten

Suricata houdt bij hoeveel pakketten hij niet heeft kunnen bekijken. Bij een rustig netwerk is dat 1,67%, reproduceerbaar over twee metingen. Tijdens de meetsessie van vanmiddag liep dat op naar 5,3%: van 7.137.135 pakketten gingen er 375.152 ongezien langs.

Je betaalt dus 45% van je download voor inspectie die onder belasting één op de twintig pakketten overslaat. En je kunt dat nergens zien: in de configuratie staat stats: enabled: no, dus het cijfer verschijnt niet in de interface. Het is alleen op te vragen via de commandosocket op de gateway.

De nuttige categorieën zitten achter een betaalmuur

Op het apparaat staat een lijst met twee groepen: 37 categorieën die gratis zijn, en 54 die bij CyberSecure horen. Achttien daarvan zijn alleen met abonnement te activeren, en dat zijn uitgerekend de categorieën die bij een netwerk zonder open poorten nog iets zouden kunnen betekenen:

PHISHING · EXPLOIT_KIT · CURRENT_EVENTS · COINMINER · ADWARE_PUP · THREATVIEW_CS_C2 · BOTCC.PORTGROUPED · JA3 · HUNTING en negen andere

Er staan 51.100 regels op de schijf, waarvan er met jouw 18 ingeschakelde categorieën 25.046 geladen worden. Phishing en exploit kits zitten daar niet bij. CyberSecure kost 99 dollar per jaar en de UDM-Pro wordt ondersteund, maar bedenk dat je dan betaalt om een functie uit te breiden die 45% van je bandbreedte kost.

Payload-inspectie werkt alleen op onversleuteld verkeer, en dat is er nauwelijks nog

In de configuratie staat HTTP_PORTS: "80". De regels die in de inhoud van webverkeer kijken, gelden dus alleen voor onversleuteld HTTP. In 2026 loopt vrijwel alles over HTTPS, en daar kan geen enkele inspectie in kijken zonder het verkeer open te breken. Dat is geen fout van Ubiquiti, het is de reden waarom dit soort inspectie de laatste jaren structureel minder oplevert. De maker van de Suricata-koppeling voor pfSense noemt precies dit als reden om het thuis af te raden: "An IDS/IPS cannot see into encrypted traffic."

5. Wat de community ervan zegt

Ik heb dit niet alleen op eigen metingen willen baseren. Twee dingen vallen op in het bronnenmateriaal.

Meldingen komen vrijwel alleen voor bij open poorten

Dat is precies jouw situatie, maar dan omgekeerd. Een gebruiker beschrijft het patroon van beide kanten:

"I was getting multiple hits a day from IDS/IPS to the machine hosting those services. I've since migrated those services and closed the ports and haven't had a single IDS/IPS event since then. If you're not exposing ports, you may never see it give you an alert."

In de grootste discussie over deze vraag is het best gewaardeerde antwoord (score 40, van iemand die zegt firewall-engineer te zijn) onomwonden: "Unless you have externally facing servers... there is absolutely no need for one" (r/HomeNetworking).

Valse meldingen zijn reproduceerbaar, echte vangsten niet

Iemand in r/cybersecurity kreeg 90 alerts in drie dagen op puur intern verkeer en reproduceerde het: een lege map aanmaken op een NFS-share leverde meldingen op voor "lateral movement" en "shellcode" (bron). De structurele verklaring staat in het best gewaardeerde antwoord daaronder:

"Modern IPS/IDS uses network discovery to fingerprint hosts on your network and tune rules so they are relevant. Unifi is limited and won't let you tune what rules apply to what hosts, so yay false positives!"

De onderhouder van de Suricata-package voor pfSense, dus iemand die deze software zelf bouwt, schrijft: "I don't typically recommend an IDS/IPS for a home network", met als redenen te veel valse meldingen en het feit dat inspectie niet in versleuteld verkeer kan kijken. Zijn alternatief is DNS-filtering (Netgate-forum).

Eerlijk erbij: in het gevonden materiaal staat geen enkel goed onderbouwd geval waarin UniFi's IPS aantoonbaar een echte aanval heeft tegengehouden. Dat betekent niet dat het nooit gebeurt, het betekent dat niemand het heeft kunnen laten zien.

6. Wat er niet uit te meten viel

Twee pogingen liepen dood. Ik noem ze omdat een rapport dat alleen de geslaagde metingen toont, niet te vertrouwen is.

• De ingebouwde speedtest van de UDM werkt niet op OS 5.x. Het commando wordt geaccepteerd maar de status springt direct naar Idle met 0.0 Mbps. Via SSH met acht parallelle streams haalt de UDM zelf 829 en 796 Mbps.
• Een tweede meetmethode kon niet discrimineren. Ik heb dezelfde download vanaf de Mac herhaald naar een Duitse server: met IPS aan 453 en 701 Mbps, met IPS uit 621 en 591. Die route zit zelf dicht rond 600 tot 800, dus hij meet ons probleem niet. Had ik alleen díe test gedaan, dan was de conclusie geweest dat IPS niets uitmaakt. Alle cijfers in dit rapport komen daarom van de Ookla-meting tegen Amstelveen.

7. Advies

Uitzetten. Je hebt drie lagen die aantoonbaar werken en niets kosten: nul open poorten, segmentatie die 291 keer per maand ingrijpt, en DNS-filtering die eerder in de keten zit. De vierde laag kost 45% van je download en heeft in een maand niets tegengehouden wat je tegengehouden wilde hebben.

Als je toch hardware wilt

Een nieuwe UDM-Pro verandert niets, dat is dezelfde processor en hetzelfde geheugen. De UDM-Pro-Max kost €654,80 inclusief btw en heeft 8 GB in plaats van 4 GB, wat het echte knelpunt is: je huidige UDM heeft nog 173 MB vrij en gebruikt 646 MB swap, en UniFi draait daarom met een uitgeklede regelset. Reken op 1,2 tot 1,5 Gbps met inspectie aan, niet op 4 Gbit. Wil je allebei volledig, dan zit je in de klasse van de EFG of UXG-Enterprise, rond de $1.999.

Maar de eerlijke vraag blijft: je overweegt dan €655 tot €2.000 uit te geven om een functie sneller te maken die in een maand negen keer je eigen GitHub-verkeer heeft geblokkeerd en nul keer iets anders.

8. Wat er is aangepast