Fail2ban på en VPN-gateway: hva det retter og hva det ikke retter

Hver eksponert tjeneste får samme råd: sett fail2ban på den. For en VPN-gateway er det rådet verken galt eller tilstrekkelig, og nettopp å behandle det som en avkrysningsboks i herdingen er hvordan folk ender med et fengsel (jail) som ikke blokkerer noe nyttig. Fail2ban leser feilregistreringene du peker det mot, og ber en håndhevelses-backend om å utestenge samsvarende kilder. Hele verdien avhenger av hvilken autentiseringsflate som produserte registreringen, om adressen i den er den virkelige klienten, og hva som skjer med alle andre bak den adressen.

Hva fail2ban er, mekanisk sett

Et filter matcher linjer i en logg, et fengsel teller treff per kilde, og en handling bruker en utestengelse via en brannmur-backend. Tre bevegelige deler, og hver av dem kan være feil uavhengig.

Ingen av de tre berører autentiseringsveien: fail2ban reagerer på bevis i ettertid og validerer aldri selv en legitimasjon. Et fengsel kan derfor kjøre rent mens flaten det navngir forblir nøyaktig like eksponert som før.

Tunnelens lytter er ikke et innloggingsskjema

En OpenVPN-lytter beskyttet med tls-auth eller tls-crypt forkaster pakker uten kontrollkanalbeskyttelse før den vanlige TLS-behandlingen begynner. En skanner som aldri har nøkkelen, genererer ingenting filteret ditt kan telle. Sertifikatautentisering legger til enda en port, fordi det ikke finnes noe passord å gjette. Fail2ban-prosjektet dokumenterer en generell loggstyrt modell, og et generisk VPN-filter gjør ikke en uautentisert pakke til en meningsfull feilhendelse.

Hvis gatewayen bare godtar sertifikater, finnes kanskje brute-force-historien du forsvarer deg mot, ikke i det hele tatt på den porten.

Så hvilken flate beskytter du?

Den samme verten eksponerer ofte tre forskjellige ting: tunnelens lytter, en klientprofil- eller selvbetjeningsportal og en administrasjonsside. Portalen og admin-siden har passordskjemaer og produserer logglinjer et filter kan telle. Tunnelen produserer kanskje bare håndtrykkfeil som betyr noe helt annet. Match fengselet til flaten, ikke til produktnavnet.

Ett fengsel som overvåker feil logg er verre enn ingen, fordi det skaper tillit uten dekning. Rett et innloggingsfilter mot tunnelens håndtrykkfeil, og telleren utløses på skannere som aldri hadde en nøkkel, mens et passordangrep mot portalen ikke telles. Les logglinjen filteret matcher før du stoler på tallet til fengselet.

Kildeattribusjon er den svake lenken

En utestengelse er bare så god som adressen den retter seg mot. Når tjenesten ligger bak en lokal omvendt proxy, kan klientadressen i loggen være proxyen, og å utestenge den fjerner alle. Å stole på en videresendt header fra en ikke-klarert kilde gir en angriper muligheten til å utestenge vilkårlige adresser. På UDP kan kildeadresser forfalskes, så å telle dem fortjener mer omhu enn å telle en fullført TCP-innlogging.

Skriv ned metoden for kildeattribusjon i fengselets README, fordi en videresendt header fra et ikke-klarert hopp gjør en utestengelse til et våpen.

Kostnaden er andre mennesker

Flere ansatte bak én kontor-NAT deler en adresse, så ett gammelt lagret passord kan låse hele kontoret ute når terskelen passeres. Loggen viser én kilde og én konto som feilet, ikke et utfall for hele kontoret.

Korte utestengelser og moderate terskler reduserer dette, og en dokumentert vei for å oppheve utestengelsen reduserer støttebelastningen når det likevel skjer. Adressen er et grovt signal snarere enn en identitet, og personen som oppretter saken vil beskrive utfallet, ikke terskelen.

Når man skal ta det i bruk, og når man skal rette noe annet

Ta det i bruk når det finnes en reell, tilskrivbar, gjentatt online innloggingsfeil på en flate du kontrollerer, og når håndhevelses-backenden faktisk dekker den flaten. Rett noe annet når problemet er en svak legitimasjonspolicy, en administrasjonsside eksponert mot internett, eller en konto som logger inn med suksess fordi den er kompromittert. En utestengelse kan ikke reparere noe av dette og kan ikke absorbere trafikk som allerede har mettet uplinken din. Det siste problemet hører hjemme lenger oppstrøms, hos noen som kan filtrere før pakkene når deg.

Hold hvert fengsel knyttet til én flate, gjennomgå falske positiver, og mål det unngåtte autentiseringsarbeidet i stedet for antallet utestengte adresser.