Fail2ban på en VPN-gateway: hvad det løser, og hvad det ikke gør

Enhver eksponeret tjeneste får det samme råd: sæt fail2ban på den. For en VPN-gateway er det råd hverken forkert eller tilstrækkeligt, og netop at behandle det som et afkrydsningsfelt i hærdningen er, hvordan folk ender med et fængsel (jail), der ikke blokerer noget nyttigt. Fail2ban læser de fejlregistreringer, du peger den på, og beder en håndhævelses-backend om at udelukke matchende kilder. Hele dens værdi afhænger af, hvilken autentificeringsflade der producerede registreringen, om adressen i den er den rigtige klient, og hvad der sker med alle andre bag den adresse.

Hvad fail2ban er, mekanisk set

Et filter matcher linjer i en log, et fængsel tæller match pr. kilde, og en handling anvender en udelukkelse via en firewall-backend. Tre bevægelige dele, og hver af dem kan være forkert uafhængigt.

Ingen af de tre rører autentificeringsvejen: fail2ban reagerer på beviser bagefter og validerer aldrig selv en legitimationsoplysning. Et fængsel kan derfor køre rent, mens den flade, det navngiver, forbliver præcis så eksponeret som før.

Tunnelens lytter er ikke en loginformular

En OpenVPN-lytter beskyttet med tls-auth eller tls-crypt dropper pakker uden kontrolkanalbeskyttelse, før den almindelige TLS-behandling begynder. En scanner, der aldrig har nøglen, genererer intet, dit filter kan tælle. Certifikatautentificering tilføjer endnu en port, fordi der ikke er nogen adgangskode at gætte. Fail2ban-projektet dokumenterer en generel logdrevet model, og et generisk VPN-filter gør ikke en uautentificeret pakke til en meningsfuld fejlhændelse.

Hvis gatewayen kun accepterer certifikater, findes den brute-force-historie, du forsvarer dig imod, måske slet ikke på den port.

Så hvilken flade beskytter du?

Den samme vært eksponerer ofte tre forskellige ting: tunnelens lytter, en klientprofil- eller selvbetjeningsportal og en administrationsside. Portalen og admin-siden har adgangskodeformularer og producerer loglinjer, et filter kan tælle. Tunnelen producerer måske kun håndtryksfejl, der betyder noget helt andet. Match fængslet til fladen, ikke til produktnavnet.

Et fængsel, der overvåger den forkerte log, er værre end ingen, fordi det skaber tillid uden dækning. Ret et login-filter mod tunnelens håndtryksfejl, og tælleren udløses på scannere, der aldrig havde en nøgle, mens et adgangskodeangreb mod portalen ikke tælles. Læs den loglinje, filteret matcher, før du stoler på fængslets tal.

Kildeangivelse er det svage led

En udelukkelse er kun så god som den adresse, den rammer. Når tjenesten ligger bag en lokal omvendt proxy, kan klientadressen i loggen være proxyen, og at udelukke den fjerner alle. At stole på et videresendt header fra en upålidelig kilde giver en angriber mulighed for at udelukke vilkårlige adresser. På UDP kan kildeadresser forfalskes, så at tælle dem fortjener mere omhu end at tælle et fuldført TCP-login.

Skriv metoden til kildeangivelse i fængslets README, fordi et videresendt header fra et upålideligt hop gør en udelukkelse til et våben.

Omkostningen er andre mennesker

Flere medarbejdere bag én kontor-NAT deler en adresse, så én forældet gemt adgangskode kan låse hele kontoret ude, når tærsklen krydses. Loggen viser én kilde og én konto, der fejlede, ikke et udfald for hele kontoret.

Korte udelukkelser og moderate tærskler reducerer det, og en dokumenteret vej til at ophæve udelukkelsen reducerer supportbelastningen, når det alligevel sker. Adressen er et groft signal snarere end en identitet, og den person, der opretter sagen, vil beskrive udfaldet, ikke tærsklen.

Hvornår man skal tage det i brug, og hvornår man skal rette noget andet

Tag det i brug, når der er en reel, tilskrivelig, gentagen online loginfejl på en flade, du kontrollerer, og når håndhævelses-backenden faktisk dækker den flade. Ret noget andet, når problemet er en svag politik for legitimationsoplysninger, en administrationsside eksponeret mod internettet, eller en konto, der logger ind med succes, fordi den er kompromitteret. En udelukkelse kan ikke reparere noget af det og kan ikke absorbere trafik, der allerede har mættet din uplink. Det sidste problem hører til længere oppe, hos nogen, der kan filtrere, før pakkerne når dig.

Hold hvert fængsel knyttet til én flade, gennemgå falske positiver, og mål det undgåede autentificeringsarbejde i stedet for antallet af udelukkede adresser.