Fail2ban på en VPN-gateway: vad det åtgärdar och vad det inte gör
Fail2ban spärrar källor som misslyckas i dina loggar, och det är allt. Om det hjälper en VPN-gateway beror på inloggningsytan och på vem som delar en adress.
Varje exponerad tjänst får samma råd: sätt fail2ban på den. För en VPN-gateway är rådet varken fel eller tillräckligt, och just att behandla det som en kryssruta i härdningen är hur folk hamnar med ett fängelse (jail) som inte blockerar något användbart. Fail2ban läser felposterna du pekar det mot och ber en verkställande backend att spärra matchande källor. Hela dess värde beror på vilken autentiseringsyta som skapade posten, om adressen i den är den riktiga klienten, och vad som händer med alla andra bakom den adressen.
Vad fail2ban är mekaniskt
Ett filter matchar rader i en logg, ett fängelse räknar träffar per källa, och en åtgärd tillämpar en spärr via en brandväggsbackend. Tre rörliga delar, och var och en kan vara fel oberoende av de andra.
Ingen av de tre rör autentiseringsvägen: fail2ban reagerar på bevis i efterhand och validerar aldrig själv en autentiseringsuppgift. Ett fängelse kan därför köra rent medan ytan det namnger förblir precis lika exponerad som förut.
Tunnelns lyssnare är inte ett inloggningsformulär
En OpenVPN-lyssnare skyddad med tls-auth eller tls-crypt kastar paket utan kontrollkanalsskydd innan den vanliga TLS-behandlingen börjar. En skanner som aldrig har nyckeln genererar inget som ditt filter kan räkna. Certifikatsautentisering lägger till ännu en port, eftersom det inte finns något lösenord att gissa. Fail2ban-projektet dokumenterar en allmän loggdriven modell, och ett generiskt VPN-filter gör inte ett oautentiserat paket till en meningsfull felhändelse.
Om gatewayen bara accepterar certifikat finns kanske brute force-historien du försvarar dig mot inte alls på den porten.
Så vilken yta skyddar du?
Samma värd exponerar ofta tre olika saker: tunnelns lyssnare, en klientprofil- eller självbetjäningsportal och en administrationssida. Portalen och admin-sidan har lösenordsformulär och producerar loggrader som ett filter kan räkna. Tunneln producerar kanske bara handskakningsfel som betyder något helt annat. Matcha fängelset mot ytan, inte mot produktnamnet.
Ett fängelse som bevakar fel logg är värre än inget, eftersom det skapar tillit utan täckning. Rikta ett inloggningsfilter mot tunnelns handskakningsfel och räknaren slår till på skannrar som aldrig hade en nyckel, medan en lösenordsattack mot portalen förblir oräknad. Läs loggraden som filtret matchar innan du litar på fängelsets siffra.
Källattribuering är den svaga länken
En spärr är bara så bra som adressen den riktar sig mot. När tjänsten ligger bakom en lokal omvänd proxy kan klientadressen i loggen vara proxyn, och att spärra den tar bort alla. Att lita på en vidarebefordrad header från en otillförlitlig källa ger en angripare möjligheten att spärra godtyckliga adresser. På UDP kan källadresser förfalskas, så att räkna dem förtjänar mer omsorg än att räkna en slutförd TCP-inloggning.
Skriv ner metoden för källattribuering i fängelsets README, eftersom en vidarebefordrad header från ett otillförlitligt hopp gör en spärr till ett vapen.
Kostnaden är andra människor
Flera anställda bakom en kontors-NAT delar en adress, så ett enda gammalt sparat lösenord kan låsa ute hela kontoret när tröskeln passeras. Loggen visar en källa och ett konto som misslyckades, inte ett avbrott för hela kontoret.
Korta spärrar och måttliga trösklar minskar det, och en dokumenterad väg för att häva spärren minskar supportbelastningen när det ändå händer. Adressen är en grov signal snarare än en identitet, och personen som öppnar ärendet kommer att beskriva avbrottet, inte tröskeln.
När man ska införa det, och när man ska åtgärda något annat
Inför det när det finns ett verkligt, hänförbart, upprepat online-inloggningsfel på en yta du kontrollerar, och när den verkställande backenden faktiskt täcker den ytan. Åtgärda något annat när problemet är en svag autentiseringspolicy, en administrationssida exponerad mot internet, eller ett konto som loggar in framgångsrikt för att det har komprometterats. En spärr kan inte reparera något av detta och kan inte absorbera trafik som redan har mättat din upplänk. Det sista problemet hör hemma uppströms, hos någon som kan filtrera innan paketen når dig.
Håll varje fängelse knutet till en yta, granska falska positiva och mät det undvikna autentiseringsarbetet i stället för antalet spärrade adresser.