Hoppa till innehåll 
Fail2Ban Plesk ger ett effektivt skydd mot brute force-attacker till din Plesk-servermiljö med bara några få klick och blockerar automatiskt misstänkta IP-adresser. Jag kommer att visa dig steg för steg hur du installerar Fail2Ban, aktiverar fängelser, anpassar regler och ställer in aviseringar så att din Server förblir permanent ren.
Centrala punkter
Följande viktiga punkter ger dig en kompakt översikt innan jag går in i detalj och visar hur du kan implementera dem i panelen. Så här ställer du in rätt Prioriteringar redan från början.
- Installation via Verktyg & Inställningar och omedelbar aktivering
- Fängelser Används specifikt för SSH, e-post, Plesk-panelen och WordPress
- Parametrar såsom förbudstid, detekteringsfönster och misslyckade försök
- Whitelist Underhåll för betrodda IP-adresser och kontrollblock
- Övervakning av loggarna för finjustering och färre falsklarm
Vad Fail2Ban gör - kortfattat förklarat
Fail2Ban-analyser Protokoll av tjänster som SSH, e-post, webbserver eller Plesk-panelen och känner igen upprepade misslyckade försök. Om en IP överskrider definierade tröskelvärden blockerar jag den automatiskt under en viss tidsperiod. På så sätt förhindrar jag brute force, ordboksattacker och automatiserade skanningar på ett tillförlitligt sätt med minimal ansträngning. Utgifter. Plesk ger ett tydligt gränssnitt där jag kan slå på eller av fängelser och justera parametrar. För produktiva servrar är detta skydd en av de snabbaste åtgärderna med en märkbar effekt.
Installation i Plesk: Förutsättningar och start
Jag använder en nuvarande Plesk-server på Linuxidealiskt Obsidian, och först kontrollera om Fail2Ban-komponenten redan finns. Om den saknas öppnar jag Tools & Settings i Plesk, går till Updates & Upgrades och väljer Add/Remove Components. Där aktiverar jag Fail2Ban-posten och startar Installation. Efter slutförandet visas avsnittet Blockera IP-adresser (Fail2Ban), där jag slår på och övervakar funktionen. För en komplett installation kombinerar jag Fail2Ban med en välkonfigurerad brandvägg; mer information finns på Konfigurera Plesk Firewall.
Grundkonfiguration: välj förnuftiga standardvärden
Efter påslagning kontrollerar jag globala parametrar som bestämmer effekten och falsklarm. Med en balanserad Bantid Jag håller angripare borta utan att permanent låsa ut legitima användare. Detekteringsfönstret styr hur länge Fail2Ban samlar in misslyckade försök, och det maximala antalet misslyckade försök anger tröskeln för blockering. Jag anger också en e-postadress för aviseringar så att jag kan se kritiska händelser omedelbart. I följande tabell visas vanliga startvärden som har visat sig fungera i många konfigurationer och som kan förfinas när som helst.
| Parametrar | Rekommendation | Effekt |
|---|---|---|
| Bantid | 600-1800 sekunder | Blockerar angripare på ett märkbart sätt utan att permanent låsa ut användare |
| Fönster för igenkänning | 300-600 sekunder | Samlar tester inom en rimlig tidsperiod |
| Max. Misslyckade försök | 3-5 | Minskar antalet falska positiva resultat och förblir ändå strikt |
| Anmälan | Aktivera e-post | Varningar för nedstängningar och viktiga händelser |
Dessutom definierar jag redan i början en Ignorera lista (vitlista) på global nivå. Under Verktyg & inställningar > Blockera IP-adresser anger jag statiska IP-adresser för kontoret, VPN-slutpunkter eller hanteringsnätverk. För IPv6 använder jag konsekventa prefix (t.ex. /64) med försiktighet och håller listan smal så att skyddet inte undergrävs. För återkommande bråkstakar kan en Inkrementell bantid beprövad: Med parametrar som bantime.increment = sant, bantime.faktor och bantime.maxtime Jag förlänger automatiskt låsen om de upprepas, vilket ger en bestående effekt.
Fängelser: riktat skydd för tjänster
På fliken Jails aktiverar jag skyddsregler för de viktigaste Tjänster: sshd, dovecot, proftpd, plesk-apache, plesk-panel och plesk-wordpress. Varje jail övervakar matchande loggfiler, känner igen mönster och blockerar iögonfallande IP-adresser. För servrar med WordPress-instanser slår jag på plesk-wordpress för att blockera inloggningsattacker på wp-login och xmlrpc. Om ingen FTP körs avaktiverar jag den tillhörande jailen så att servern inte utför några onödiga kontroller. Jag kontrollerar sedan om blocken fungerar tillförlitligt och justerar tröskelvärdena om det finns för många falska positiva resultat.
För orientering: sshd läser vanligtvis från /var/log/auth.log (Debian/Ubuntu) eller /var/log/secure (RHEL/Alma/Rocky) hamnar e-postinloggningar i /var/log/maillog resp. /var/log/mail.logpanelen loggar in /var/log/plesk/panel.log. För webbattacker får Plesk-domarna tillgång till virtuella värdloggar under /var/www/vhosts/system//loggar/ till. Om du bara kör NGINX eller en Apache+NGINX-installation kommer Plesk-filtren att fortsätta att fungera eftersom de lämpliga sökvägarna redan är lagrade.
Skapa dina egna fängelser och filter på ett enkelt sätt
Behöver jag ytterligare Skydd för en applikation skapar jag ett nytt fängelse och hänvisar till de tillhörande loggarna. Jag definierar ett tydligt tidsfönster, ställer in felgränsen och bestämmer önskad förbudstid. För speciella applikationer skriver jag filter med reguljära uttryck som känner igen specifika felmeddelanden. När jag har aktiverat regeln testar jag den genom att simulera ett misslyckat försök och sedan kontrollera loggarna. Om jag upptäcker ett mönster som angripare kan kringgå förfinar jag filtret och loggar ändringen för min Dokumentation.
För att se till att anpassningarna förblir uppdateringssäkra skapar jag Egna konfigurationer på /etc/fail2ban/jail.d/ som separata filer (t.ex. anpassad-wordpress.lokal) istället för att ändra standardfilerna. På så sätt skriver inte en Plesk- eller paketuppdatering över mina regler. Jag testar filterregler med fail2ban-regex mot provloggar innan jag byter ett fängelse till produktivt. Efter ändringar, en systemctl reload fail2banför att göra dem aktiva utan en hård omstart.
Vitlistning, avblockering och förståelse av blockerade IP-adresser
Om jag låser ut mig själv eller en teammedlem öppnar jag listan över blockerade IP-adresser och avblockerar adressen igen. För permanent pålitliga källor använder jag vitlistan och förhindrar på så sätt framtida Blockeringar. I översikten kan jag se vilket fängelse som har blockerat en IP och för vilken regel den upptäcktes. Den här informationen hjälper mig att känna igen felkonfigurerade program eller robotar. Jag håller vitlistan smal och behåller bara poster om det finns en god anledning att göra det. Anledning där.
Arbetar du bakom en Proxy/CDNJag ägnar särskild uppmärksamhet åt vitlistan: Om inloggningar och webbåtkomst sker bakom IP-adresserna för den omvända proxyn ur serverns synvinkel kommer en slarvigt konfigurerad jail i värsta fall att blockera proxyn i stället för den faktiska angriparen. I det här fallet ser jag till att webbservern skriver den "riktiga" klient-IP:n korrekt i loggarna (X-Forwarded-For/Actual Real-IP-mekanismen) och att proxynätverken är pålitliga. Detta säkerställer att blocken förblir korrekta.
Undvik misstag: förnuftiga inställningar från praktiken
Jag börjar med måttlig Trösklar och skärper värdena först när jag känner till de typiska belastnings- och användningsprofilerna. För delade värdar med många användare ökar risken för falska blockeringar, så jag ställer in MaxRetry högre och övervakar loggarna noggrannare. Om bots når dina formulär är det värt att ta en titt på webbserverloggar och ytterligare regler i plesk-apache-jailen. Jag satte upp 2FA för administratörsinloggningar och lindrar därmed Fail2Ban eftersom färre inloggningsförsök kommer fram till panelen. En regelbunden titt på blocklistan visar mig om en individ Källa är särskilt iögonfallande och kräver fler åtgärder.
Brandväggskombination och WordPress-härdning
Fail2Ban blockerar angripare efter misslyckade försök, medan brandväggen minskar angreppsytan i förväg. Båda tillsammans ger märkbart mer Säkerhetsärskilt med exponerade SSH- eller e-postportar. För WordPress begränsar jag xmlrpc, sätter en gräns för inloggningshastighet på applikationsnivå och låter plesk-wordpress göra resten av jobbet. På så sätt får du ett djupförsvar i stället för en enda barriär. En mer djupgående jämförelse finns i den här artikeln: Fail2Ban och brandvägg i jämförelsesom hjälper dig att samordna åtgärderna.
Praktisk kontroll för Plesk-administratörer
När jag har konfigurerat systemet kontrollerar jag om låsningarna sker inom den förväntade tiden och om e-postmeddelandena kommer fram. Jag testar sedan SSH med avsiktligt felaktiga lösenord och kontrollerar loggarna för att verifiera effektiviteten hos Fängelser för att bekräfta. För Plesk-panelen simulerar jag flera misslyckade inloggningar och observerar om IP-adressen blockeras omedelbart. Om det dyker upp för många legitima blockeringar ökar jag MaxRetry steg för steg och förlänger detekteringsfönstret måttligt. Detta konsekventa tillvägagångssätt minimerar antalet falsklarm och säkerställer en lugn Drift.
Integration av värdtjänster: vad jag tittar efter
En stark hostinginstallation tillhandahåller Fail2Ban, brandvägg, säkerhetskopiering och övervakning på ett sammanhängande sätt. Jag är uppmärksam på direkt Plesk-integration, korta svarstider i support och tydliga Dokumentation. providers med isolerade servicecontainrar och konsekventa kärnuppdateringar ger mig ytterligare säkerhet. För produktiva projekt förlitar jag mig också på säkerhetskopior på annan plats så att jag snabbt kan komma tillbaka online i en nödsituation. Detta skapar en säkerhetsnivå som gör attacker mycket svårare och som kan genomföras med en rimlig säkerhetsnivå. Utgifter kan bibehållas.
Övervakning och felsökning: hur du håller koll på saker och ting
Jag analyserar regelbundet Fail2Ban-översikten, kontrollerar blockerade Adresser och känner igen återkommande källor. Om jag hittar mönster justerar jag filterreglerna och dokumenterar ändringarna så att jag kan spåra dem senare. Om loggarna visar kraftiga belastningstoppar sätter jag ytterligare gränser i webbservern och stramar åt brandväggen. Samtidigt håller jag Plesk, systempaket och plugins fräscha för att minimera attackytor; du hittar beprövade tips i denna guide till Täppa till säkerhetsluckor i Plesk. Detta håller ditt skydd uppdaterat och Fail2Ban behöver mindre Arbetskraft att utföra.
Protokollbackends och sökvägar i Plesk
För tillförlitlig detektering är det viktigt att Fail2Ban har rätt Protokoll källor läser. Under Linux använder jag antingen filloggar eller systemd-backend, beroende på distribution. Moderna installationer drar nytta av backend = systemdeftersom Fail2Ban läser journalen direkt och genererar mindre I/O på loggfiler. Plesk har redan förnuftiga standardinställningar för detta. Ändå kontrollerar jag slumpmässigt om loggsökvägarna i fängelserna stämmer överens med verkligheten: SSH in /var/log/auth.log (Debian/Ubuntu) eller /var/log/secure (RHEL/Alma/Rocky), Mail in /var/log/maillog eller . /var/log/mail.logPlesk-panelen i /var/log/plesk/panel.logWeb i vhost-katalogerna. Om sökvägar eller journalnamn inte är korrekta korrigerar jag posterna i en separat .lokal-fil. På så sätt undviker jag blinda fläckar där attacker förblir oupptäckta.
IPv6, banaction och brandvägg som backend
Många installationer filtrerar inte längre bara IPv4. Jag försäkrar mig om att Banker är lämpliga för IPv6 (t.ex. multiportvarianter för iptables/firewalld). Om systemet använder Firewalld är jag uppmärksam på åtgärder som brandväggcmd-multiportför klassiska iptables-konfigurationer till iptables-multiport eller ipset-baserade åtgärder för bättre prestanda. Det är viktigt att den åtgärd som används i Fail2Ban matchar den aktiva Plesk-brandväggen - annars hamnar block i fel kedja eller får ingen effekt alls. Efter ändringar testar jag specifikt: simulerade misslyckade försök från en test-IP, statusförfrågan för fängelset och sedan ett anslutningstest. Om IPv6-blocken fungerar tillförlitligt har jag täppt till ett betydande gap som ofta förbises i blandade nätverk.
Eskalerande låsningar och långvariga blockeringar (återfall i brott)
Med återkommande angripare ökar jag trycket: med inkrementella förbudstider (bantime.inkrement) lås förlängs automatiskt - ungefär dubbelt så mycket som bantime.factor = 2 - upp till ett förnuftigt maximum (bantime.maxtime). Jag använder också återfallsfängelse som upptäcker IP-adresser som förekommer flera gånger i olika fängelser inom ett längre fönster. En konfiguration med Hitta tid i intervallet timmar till dagar och en avstängningsperiod på flera dagar har visat sig vara effektiv. Denna nivå har en varaktig effekt mot bots som återkommer regelbundet utan att permanent utesluta legitima användare. Det är fortfarande viktigt att använda pålitliga nätverk via ignoreip och för att hålla ett öga på effekterna via svartlistan.
CLI arbetsflöde: kontrollera, ladda om, låsa upp
Även om Plesk erbjuder ett bekvämt gränssnitt, löser jag många snabb via konsol. Med fail2ban-klient status Jag ser aktiva fängelser, fail2ban-klient status listar blockerade IP-adresser och räknare. Jag laddar nya regler med systemctl reload fail2banVid behov startar jag om tjänsten. Jag raderar enskilda IP-adresser (fail2ban-client set unbanip) utan att påverka hela systemet. För felsökning journalctl -u fail2banför att läsa de senaste händelserna, inklusive information om felaktiga filter. Detta gör att jag kan hålla verksamheten smal, dokumentera ingripanden kortfattat och återföra resultaten till reglerna.
Drift bakom proxy/CDN, ModSecurity och WordPress-detaljer
Många webbplatser hänger idag efter Omvända proxyservrar eller CDN:er. För att säkerställa att Fail2Ban utvärderar den riktiga klienten ser jag till att webbservern noterar rätt IP i loggen och att proxynätverken finns på vitlistan. Annars riskerar jag att oavsiktligt blockera hela edge-nätverk. I Plesk använder jag också ModSäkerhet (WAF): ModSecurity blockerar kända attackmönster på HTTP-nivå, medan Fail2Ban sanktionerar misslyckade inloggningsförsök eller upprepade 4xx/5xx-mönster. För WordPress använder jag en tvådelad strategi: begränsa eller säkra xmlrpc, ställ in gränser för inloggningshastigheten på applikationsnivå och använd plesk-wordpress-jail aktiv. På så sätt avhjälper jag brus i loggen och låter Fail2Ban rikta in sig på de svåra fallen.
Strategi för underhåll, säkerhetskopiering och uppdatering
För att säkerställa att justeringarna håller på lång sikt behåller jag alla egna regler i separata filer under /etc/fail2ban/jail.d/ och dokumentera versionsändringar. Innan större plesk- eller systemuppdateringar skapar jag en ögonblicksbild / säkerhetskopia och kontrollerar sedan slumpmässigt om fängelser fortfarande är aktiva och sökvägarna är korrekta. Jag tar också hänsyn till loggrotationer: efter en rotationskörning (ny loggfil) bör backend fortsätta att läsa på ett tillförlitligt sätt - med systemd-Journal elimineras denna oro till stor del. Jag upprättar korta SOP:er för team: hur IP-adresser upphävs, tröskelvärden justeras och meddelanden kontrolleras. Detta säkerställer att hanteringen förblir konsekvent, även när ansvarsområdena ändras.
Juridisk bedömning: protokoll och lagring
Säkerhet behöver också Dimension. Jag lagrar bara den information som är nödvändig för försvar och diagnos, ställer in tydliga lagringstider och raderar gamla data regelbundet. Fail2Ban själv lagrar inga långsiktiga data; grunden är dina system- och webbloggar. En reducerad loggnivå i den vanliga driften (t.ex. INFO) håller datamängden hanterbar, medan jag tillfälligt ökar den till DEBUG för analyser och sedan växlar tillbaka igen. På så sätt kombinerar jag ett effektivt skydd med ett smidigt och spårbart dataspår.
I ett nötskal: säker implementering med bara några få klick
Jag aktiverar Fail2Ban via Plesk, ställer in balanserade parametrar, slår på lämplig Fängelser och upprätthålla en smal vitlista. Med en kompletterande brandvägg, 2FA och rena uppdateringar uppnår jag en hög skyddsnivå utan ballast. Anpassade filter ger mig kontroll över specialfall, medan aviseringar och loggar förenklar mitt dagliga arbete. Om du tar till dig dessa steg kommer du att märkbart minska brute force-försöken och effektivt skydda admininloggningar, e-post och SSH. Så här håller du din Plesk-server säker med Fail2Ban permanent motståndskraftig och lätt att administrera.
