Kort sagt: Fail2ban läser loggfiler och spärrar i brandväggen adresser som syns för ofta inom ett tidsfönster. För Nginx och Apache medföljer färdiga jails som nginx-botsearch eller apache-noscript; egna filter testar ni med fail2ban-regex. Inställningar hör hemma i jail.local, era egna adresser i ignoreip, återfallsförbrytare fångar recidive-jailet. Mot enskilda riktade angrepp hjälper inte Fail2ban, mot massskanningar gör det det.
När loggarna är fulla av skannrar
Den som i dessa dagar tittar på åtkomstloggarna för sina webbservrar hittar ofta massor av förfrågningar mot sökvägar som inte finns: gamla administrationsgränssnitt, testfiler, kända sårbarheter i andra produkter. I ett läge som PHP2Shell kommer riktad sökning efter sårbara servrar därtill: Cloudflare och Patchstack rapporterade angreppsförsök, Unit 42 räknade mer än 22,6 miljoner exponerade, potentiellt sårbara instanser.
Fail2ban är ett beprövat verktyg mot den massan. Det läser loggfiler, känner med filter igen avvikande poster och spärrar avsändaradressen en fastställd tid i brandväggen. Det avlastar servern, minskar loggbruset och gör systematiskt prövande från en källa mödosammare.
Vad Fail2ban inte kan är lika viktigt: en enskild förfrågan som utnyttjar en sårbarhet förhindras inte. Mot PHP2Shell hjälper bara PHP-uppdateringen. Hur automatiserade angrepp går till beskriver Massskanningar efter ej patchad PHP.
Fail2ban för Nginx och Apache: de medföljande jailen
Ett jail förenar ett filter med en loggfil och en spärråtgärd. Den medföljande jail.conf innehåller redan jails för webbservrar. De är som standard avstängda och aktiveras var för sig.
| Jail | Webbserver | Upptäcker |
|---|---|---|
nginx-http-auth |
Nginx | misslyckade HTTP-Basic-inloggningar |
nginx-limit-req |
Nginx | förfrågningar som överskrider Nginx rate limit |
nginx-botsearch |
Nginx | sökning efter typiska, icke existerande sökvägar |
nginx-bad-request |
Nginx | felaktiga förfrågningar |
apache-auth |
Apache | misslyckade inloggningar |
apache-badbots |
Apache | kända skadliga botidentiteter |
apache-noscript |
Apache | anrop av icke existerande skript |
apache-overflows |
Apache | överlånga förfrågningar |
apache-botsearch |
Apache | sökning efter typiska, icke existerande sökvägar |
php-url-fopen |
båda | vissa mönster för försök att inkludera URL:er |
recidive |
båda | adresser som Fail2ban upprepat har spärrat |
Standardvärdena i den medföljande konfigurationen är ganska milda: spärr i 10 minuter efter 5 träffar på 10 minuter. För webbservrar med mycket skanningstrafik lönar sig en längre spärr och en stigande faktor för upprepningar.
Grundkonfigurationen i jail.local
jail.conf säger själv att den inte ska ändras, eftersom uppdateringar ersätter den. Egna värden hör hemma i /etc/fail2ban/jail.local. Exemplet nedan för Nginx sätter rimliga standarder och aktiverar lämpliga jails:
# /etc/fail2ban/jail.local
[DEFAULT]
# Lägg in egna fasta adresser (ersätt exempeladressen)
ignoreip = 127.0.0.1/8 ::1 203.0.113.10
bantime = 1h
findtime = 10m
maxretry = 5
bantime.increment = true
[nginx-http-auth]
enabled = true
[nginx-botsearch]
enabled = true
[recidive]
enabled = true
bantime = 1w
findtime = 1d
För Apache aktiverar ni i stället till exempel apache-auth, apache-noscript och apache-botsearch. Loggsökvägarna medföljer Fail2ban per distribution; avviker era sökvägar sätter ni logpath i respektive jail. Läser ert system loggar bara via journalen hjälper backend = systemd.
Ett eget filter för massförfrågningar mot PHP-filer
Ett typiskt mönster i det aktuella läget är många förfrågningar på kort tid mot PHP-filer som inte finns. Ett eget filter känner igen det på statuskoden 404. Det beskriver bara det som står i er egen logg:
# /etc/fail2ban/filter.d/nginx-php-404.conf
[Definition]
failregex = ^<HOST> -.*"(GET|POST|HEAD) [^"]*\.php[^"]*" 404
ignoreregex =
# Tillägg i /etc/fail2ban/jail.local
[nginx-php-404]
enabled = true
port = http,https
filter = nginx-php-404
logpath = /var/log/nginx/access.log
maxretry = 20
findtime = 1m
bantime = 1h
Innan ni aktiverar filtret kontrollerar ni det mot den riktiga loggen. Så ser ni hur många rader det träffar och om legitima åtkomster finns med:
fail2ban-regex /var/log/nginx/access.log /etc/fail2ban/filter.d/nginx-php-404.conf
sudo systemctl restart fail2ban
sudo fail2ban-client status
sudo fail2ban-client status nginx-php-404
# Häv en av misstag spärrad adress
sudo fail2ban-client set nginx-php-404 unbanip 203.0.113.25
Välj tröskeln generöst. En crawler som arbetar av föråldrade länkar eller en övervakningstjänst får inte hamna i spärren.
De vanligaste fällorna
Fail2ban är snabbt installerat men lätt att använda fel. De här punkterna bör ni kontrollera före produktiv användning:
- Självutestängning: Kontors-, VPN- och övervakningsadresser hör hemma i
ignoreipinnan jails blir aktiva. - Förkopplade tjänster: Bakom CDN eller lastbalanserare ser Fail2ban utan anpassning bara deras adresser. Mer om det i guiden Skydda admin-inloggningar mot brute force.
- Logrotation: Efter byte av loggfil måste Fail2ban läsa den nya filen. Kontrollera efter den första rotationen att jailen fortsätter räkna träffar.
- Samspel med brandväggen: Fail2ban lägger in spärrar i brandväggen. Den som hanterar sin brandvägg genom att ladda om hela regelverket kan därvid radera dessa poster. Hur ni bygger upp själva brandväggen står under Brandvägg för webbservrar: öppna bara nödvändiga portar.
- IPv6: Angrepp kommer också via IPv6. Kontrollera om er spärråtgärd täcker båda protokollen.
Analysera spärrlistorna regelbundet. Ökar spärrarna från vissa nät eller mot vissa sökvägar är det ett tecken på riktad sökning och en anledning att granska den berörda applikationen närmare.
Slutsats: ett verktyg mot massan, inte mot allt
Fail2ban är snabbt inställt och tar bort en del av det ständiga beskjutningen från webbservrar. De medföljande jailen täcker typiska mönster, egna filter kan riskfritt testas mot riktiga loggar med fail2ban-regex, och recidive-jailet ser till att envisa källor hålls utanför längre.
Överskatta det inte. Fail2ban reagerar på upprepning, inte på den första träffen, och det ser bara det som står i loggarna. Mot en sårbarhet som PHP2Shell hjälper bara uppdateringen, mot distribuerade angrepp från många adresser hjälper Fail2ban knappast. Sitt värde får det som ett lager bland flera: vid sidan av en smal brandvägg, en härdad webbserverkonfiguration, tvåfaktorsinloggning och en övervakning som inte bara spärrar avvikelser utan också rapporterar dem.
Hur hjälper PHP SOS konkret?
- Analysera loggar: Vi tittar på vilka mönster som förekommer i era åtkomstloggar och väljer lämpliga jails.
- Ställa in och testa: Vi ställer in Fail2ban med egna filter, testar varje filter mot riktiga loggar och lägger in era fasta adresser som undantag.
- Klargöra samspelet: CDN, lastbalanserare, brandvägg och logrotation stämmer vi av så att spärrar träffar rätt adresser.
- Observera: Inom ramen för säkerhetsövervakningen analyserar vi löpande spärrar och avvikelser.
Vanliga frågor
Skyddar Fail2ban mot PHP2Shell?
Nej. Fail2ban reagerar först efter att en adress har synts flera gånger i loggarna. Ett enskilt lyckat angrepp förhindras inte av det. Fail2ban minskar dock belastningen från skannrar och gör upprepade försök från samma källa dyrare.
Varför ska jag inte ändra jail.conf direkt?
Filen ersätts vid paketuppdateringar, och den säger det själv. Egna inställningar hör hemma i en jail.local eller i filer under jail.d. Där skriver de riktat över standardvärdena.
Vad är recidive-jailet?
Ett jail som analyserar Fail2bans egen logg. Den som gång på gång spärras får en betydligt längre spärr. I den medföljande konfigurationen är den en vecka.
Fungerar Fail2ban bakom Cloudflare eller en lastbalanserare?
Bara med extra konfiguration. Utan den står den förkopplade tjänstens adress i loggarna, och en spärr skulle drabba alla besökare. Webbservern måste då ta över den verkliga besökaradressen, och spärrar sätts bättre hos den förkopplade tjänsten.