Aktuellt läge: PHP2Shell. Två kritiska PHP-sårbarheter (CVSS 9,2) tillåter skadlig kod utan inloggning. Patchar sedan den 21 oktober 2026.Vad som bör göras nu →

Ställ in Fail2ban för webbservrar

Fail2ban spärrar adresser som upprepat dyker upp i loggarna. För webbservrar medföljer färdiga filter, och med några få rader kommer egna till. Så ställer ni in det utan att spärra er själva eller era kunder.

Aktualitet 5 min läsningHärdning och konfiguration

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:

  1. Självutestängning: Kontors-, VPN- och övervakningsadresser hör hemma i ignoreip innan jails blir aktiva.
  2. 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.
  3. 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.
  4. 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.
  5. IPv6: Angrepp kommer också via IPv6. Kontrollera om er spärråtgärd täcker båda protokollen.
Tips

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.

Källor

Direktkontakt

Varje timme räknas. Skriv till oss nu.

Beskriv kort system, PHP-version och observation. Vi hör av oss, klarlägger läget och arbetar på distans tills incidenten är avslutad och dokumenterad.

Direkthjälp