Fail2ban op een VPN-gateway: wat het oplost en wat niet

Elke blootgestelde dienst krijgt hetzelfde advies: zet fail2ban erop. Voor een VPN-gateway is dat advies niet fout en niet voldoende, en het als een afvinklijstje bij hardening behandelen is precies hoe mensen eindigen met een gevangenis (jail) die niets nuttigs blokkeert. Fail2ban leest de foutregistraties waarnaar je het wijst en vraagt een handhavings-backend om overeenkomende bronnen te blokkeren. De hele waarde hangt af van welk authenticatieoppervlak de registratie heeft gemaakt, of het adres erin de echte client is, en wat er met alle anderen achter dat adres gebeurt.

Wat fail2ban mechanisch is

Een filter matcht regels in een log, een gevangenis telt matches per bron, en een actie past een blokkade toe via een firewall-backend. Drie bewegende delen, en elk kan onafhankelijk fout zijn.

Geen van de drie raakt het authenticatiepad: fail2ban reageert achteraf op bewijs en valideert nooit zelf een inloggegeven. Een gevangenis kan dus schoon draaien terwijl het oppervlak dat hij noemt precies zo blootgesteld blijft als voorheen.

De tunnel-listener is geen inlogformulier

Een OpenVPN-listener die met tls-auth of tls-crypt is beschermd, gooit pakketten zonder bescherming van het controlekanaal weg voordat de gewone TLS-verwerking begint. Een scanner die nooit de sleutel heeft, genereert niets dat je filter kan tellen. Certificaatauthenticatie voegt nog een poort toe, want er is geen wachtwoord te raden. Het Fail2ban-project documenteert een algemeen, door logs aangestuurd model, en een generiek VPN-filter maakt van een niet-geauthenticeerd pakket geen betekenisvolle foutgebeurtenis.

Als de gateway alleen certificaten accepteert, bestaat het brute-force-verhaal waartegen je je verdedigt misschien helemaal niet op die poort.

Welk oppervlak bescherm je dan?

Dezelfde host stelt vaak drie verschillende dingen bloot: de tunnel-listener, een cliëntprofiel- of selfserviceportaal en een beheerpagina. Het portaal en de beheerpagina hebben wachtwoordformulieren en produceren logregels die een filter kan tellen. De tunnel produceert misschien alleen handshake-fouten die iets heel anders betekenen. Koppel de gevangenis aan het oppervlak, niet aan de productnaam.

Eén gevangenis die het verkeerde log bekijkt is erger dan geen, want hij schept vertrouwen zonder dekking. Richt een loginfilter op de handshake-fouten van de tunnel en de teller slaat aan bij scanners die nooit een sleutel hadden, terwijl een wachtwoordaanval op het portaal niet wordt geteld. Lees de logregel die het filter matcht voordat je het getal van de gevangenis vertrouwt.

Brontoewijzing is de zwakke schakel

Een blokkade is alleen zo goed als het adres waarop hij mikt. Als de dienst achter een lokale reverse proxy zit, kan het cliëntadres in het log de proxy zijn, en die blokkeren verwijdert iedereen. Vertrouwen op een doorgestuurde header uit een onbetrouwbare bron geeft een aanvaller de mogelijkheid willekeurige adressen te blokkeren. Op UDP kunnen bronadressen worden vervalst, dus ze tellen verdient meer zorg dan het tellen van een voltooide TCP-login.

Leg de methode voor brontoewijzing vast in de README van de gevangenis, want een doorgestuurde header van een onbetrouwbare hop maakt van een blokkade een wapen.

De bijkomende kosten zijn andere mensen

Meerdere medewerkers achter één kantoor-NAT delen een adres, dus één verouderd opgeslagen wachtwoord kan het hele kantoor buitensluiten zodra de drempel wordt overschreden. Het log toont één bron en één account die faalden, geen uitval voor het hele kantoor.

Korte blokkades en gematigde drempels verminderen dat, en een gedocumenteerd pad om de blokkade op te heffen verlaagt de supportlast wanneer het toch gebeurt. Het adres is een grof signaal en geen identiteit, en wie het ticket opent, beschrijft de uitval, niet de drempel.

Wanneer je het invoert, en wanneer je iets anders repareert

Voer het in wanneer er op een oppervlak dat je beheert een echte, toerekenbare, herhaalde online login-fout is, en wanneer de handhavings-backend dat oppervlak daadwerkelijk dekt. Repareer iets anders wanneer het probleem een zwak wachtwoordbeleid is, een beheerpagina die aan het internet is blootgesteld, of een account dat succesvol inlogt omdat het is gecompromitteerd. Een blokkade kan niets daarvan repareren en kan geen verkeer absorberen dat je uplink al verzadigd heeft. Dat laatste probleem hoort stroomopwaarts, bij iemand die kan filteren voordat de pakketten jou bereiken.

Houd elke gevangenis aan één oppervlak gebonden, beoordeel valse positieven, en meet het vermeden authenticatiewerk in plaats van het aantal geblokkeerde adressen.