Vai al contenuto 
Fail2Ban Plesk offre una protezione efficace contro gli attacchi brute force al vostro ambiente server Plesk con pochi clic e blocca automaticamente gli IP sospetti. Vi mostrerò passo dopo passo come installare Fail2Ban, attivare le jail, personalizzare le regole e impostare le notifiche in modo che il vostro Server rimane permanentemente pulito.
Punti centrali
I seguenti punti chiave vi forniranno una panoramica compatta prima di entrare nel dettaglio e mostrarvi come implementarli nel pannello. Come impostare il giusto Priorità fin dall'inizio.
- Installazione tramite Strumenti e impostazioni e attivazione immediata
- Carceri Utilizzate specificamente per SSH, posta, pannello Plesk e WordPress.
- Parametri come il tempo di interdizione, la finestra di rilevamento e i tentativi falliti.
- Whitelist Mantenere gli IP affidabili e controllare i blocchi
- Monitoraggio dei registri per una regolazione fine e un minor numero di falsi allarmi.
Cosa fa Fail2Ban - spiegato brevemente
Analisi Fail2Ban Protocolli di servizi come SSH, posta, server web o il pannello Plesk e riconosce i tentativi ricorrenti falliti. Se un IP supera le soglie definite, lo blocco automaticamente per un determinato periodo di tempo. In questo modo, prevengo in modo affidabile la forza bruta, gli attacchi a dizionario e le scansioni automatiche con il minimo sforzo. Spese. Plesk offre un'interfaccia chiara in cui è possibile attivare o disattivare le prigioni e regolare i parametri. Per i server produttivi, questa protezione è una delle misure più rapide con un effetto notevole.
Installazione in Plesk: prerequisiti e avvio
Utilizzo un server Plesk attuale su Linuxidealmente Obsidian, e per prima cosa verifico se il componente Fail2Ban è già presente. Se manca, apro Strumenti e impostazioni in Plesk, vado su Aggiornamenti e upgrade e seleziono Aggiungi/Rimuovi componenti. A questo punto, attivo la voce Fail2Ban e avvio il programma Installazione. Dopo il completamento, appare la sezione Blocca indirizzi IP (Fail2Ban), in cui si attiva e si controlla la funzione. Per una configurazione completa, combino Fail2Ban con un firewall ben configurato; i dettagli sono disponibili su Configurare il firewall di Plesk.
Configurazione di base: selezionare valori predefiniti ragionevoli
Dopo l'accensione, controllo i parametri globali che determinano l'effetto e i falsi allarmi. Con un sistema bilanciato Tempo di divieto Tengo fuori gli aggressori senza bloccare in modo permanente gli utenti legittimi. La finestra di rilevamento controlla per quanto tempo Fail2Ban raccoglie i tentativi falliti e il numero massimo di tentativi falliti stabilisce la soglia di blocco. Inserisco anche un indirizzo e-mail per le notifiche, in modo da poter vedere immediatamente gli eventi critici. La tabella seguente mostra valori iniziali comuni che si sono dimostrati validi in molte configurazioni e che possono essere perfezionati in qualsiasi momento.
| Parametri | Raccomandazione | Effetto |
|---|---|---|
| Tempo di divieto | 600-1800 secondi | Blocca in modo evidente gli aggressori senza bloccare in modo permanente gli utenti |
| Finestra di riconoscimento | 300-600 secondi | Test di aggregazione in un periodo di tempo ragionevole |
| Massimo. Tentativi falliti | 3-5 | Riduce i falsi positivi e rimane comunque rigoroso |
| Notifica | Attivare l'e-mail | Avvisi per chiusure ed eventi importanti |
Inoltre, proprio all'inizio definisco un Ignorare l'elenco (whitelist) a livello globale. In Strumenti e impostazioni > Blocca indirizzi IP, inserisco indirizzi IP statici dell'ufficio, endpoint VPN o reti di gestione. Per IPv6, utilizzo con cura prefissi coerenti (ad es. /64) e mantengo l'elenco snello in modo da non compromettere la protezione. Per i problemi ricorrenti, un Tempo di divieto incrementale dimostrato: Con parametri quali bantime.increment = true, bantime.factor e bantime.maxtime Estendo automaticamente le chiusure se vengono ripetute, garantendo così un effetto duraturo.
Carceri: protezione mirata per i servizi
Nella scheda Prigioni, attivo le regole di protezione per le prigioni più importanti. Servizisshd, dovecot, proftpd, plesk-apache, plesk-panel e plesk-wordpress. Ciascun jail monitora i file di log corrispondenti, riconosce gli schemi e blocca gli IP più vistosi. Per i server con istanze di WordPress, attivo plesk-wordpress per bloccare gli attacchi di login su wp-login e xmlrpc. Se non è in esecuzione alcun FTP, disattivo il jail associato in modo che il server non esegua controlli non necessari. Verifico quindi se i blocchi funzionano in modo affidabile e regolo i valori di soglia se ci sono troppi falsi positivi.
Per orientarsi: sshd legge tipicamente da /var/log/auth.log (Debian/Ubuntu) o /var/log/secure (RHEL/Alma/Rocky), i login di posta finiscono in /var/log/maillog rispettivamente /var/log/mail.logil pannello si collega /var/log/plesk/panel.log. Per gli attacchi web, le carceri di Plesk accedono ai registri degli host virtuali sotto la voce /var/www/vhosts/sistema//logs/ a. Se si utilizza solo NGINX o una configurazione Apache+NGINX, i filtri di Plesk continueranno a funzionare perché i percorsi appropriati sono già memorizzati.
Create le vostre prigioni e i vostri filtri in modo pulito
Ho bisogno di ulteriori Protezione per un'applicazione, creo un nuovo jail e faccio riferimento ai log associati. Definisco una finestra temporale chiara, imposto il limite di errore e determino il tempo di interdizione desiderato. Per applicazioni speciali, scrivo filtri con espressioni regolari che riconoscono messaggi di errore specifici. Dopo aver attivato la regola, la verifico simulando un tentativo fallito e controllando i registri. Se noto uno schema che gli aggressori possono aggirare, perfeziono il filtro e registro la modifica per il mio Documentazione.
Per assicurarsi che le personalizzazioni rimangano al sicuro dagli aggiornamenti, creo Configurazioni proprie in /etc/fail2ban/jail.d/ come file separati (ad es. personalizzato-wordpress.local) invece di modificare i file standard. In questo modo, un aggiornamento di Plesk o di un pacchetto non sovrascrive le mie regole. Verifico le regole del filtro con fail2ban-regex con i log di esempio prima di passare un jail a quello produttivo. Dopo le modifiche, un systemctl reload fail2banper renderli attivi senza un riavvio.
Whitelisting, sblocco e comprensione degli IP bloccati
Se blocco me stesso o un membro del team, apro l'elenco degli indirizzi IP bloccati e sblocco nuovamente l'indirizzo. Per le fonti affidabili in modo permanente, utilizzo la whitelist e quindi impedisco che in futuro si verifichino Blocco. Nella panoramica, posso vedere quale jail ha bloccato un IP e per quale regola è stato rilevato. Queste informazioni mi aiutano a riconoscere applicazioni o bot mal configurati. Mantengo la whitelist snella e mantengo le voci solo se c'è una buona ragione per farlo. Motivo lì.
Lavorate dietro un Proxy/CDNPresto particolare attenzione alla whitelist: Se i login e gli accessi al Web si trovano dietro gli IP del reverse proxy dal punto di vista del server, un jail configurato in modo poco accurato, nel peggiore dei casi, bloccherà il proxy invece dell'attaccante reale. In questo caso, mi assicuro che il server web scriva correttamente l'IP "reale" del client nei log (meccanismo X-Forwarded-For/Actual Real-IP) e mantengo le reti proxy come affidabili. Questo assicura che i blocchi rimangano accurati.
Evitare gli errori: una messa a punto sensata dalla pratica
Inizio con un moderato Soglie e stringo i valori solo quando conosco i profili di carico e di utilizzo tipici. Per gli host condivisi con molti utenti, il rischio di falsi blocchi aumenta, quindi imposto MaxRetry più alto e monitoro i log più da vicino. Se i bot raggiungono i vostri moduli, vale la pena dare un'occhiata ai log del server web e alle regole aggiuntive nel jail di plesk-apache. Ho impostato 2FA per i login degli amministratori e quindi alleggerisco Fail2Ban, perché il pannello riceve meno tentativi di login. Uno sguardo regolare all'elenco dei blocchi mi mostra se un individuo Fonte è particolarmente vistoso e richiede maggiori misure.
Combinazione di firewall e hardening di WordPress
Fail2Ban blocca gli aggressori dopo i tentativi falliti, mentre il firewall riduce la superficie di attacco in anticipo. Entrambi, insieme, garantiscono una maggiore Sicurezzaspecialmente con porte SSH o di posta esposte. Per WordPress, limito xmlrpc, imposto un limite di accesso a livello di applicazione e lascio che plesk-wordpress faccia il resto del lavoro. In questo modo si ottiene una difesa in profondità invece di una singola barriera. Potete trovare un confronto più approfondito in questo articolo: Fail2Ban e firewall a confrontoche vi aiuterà a coordinare le misure.
Controllo pratico per gli amministratori di Plesk
Una volta configurato, verifico se i blocchi si verificano entro la finestra temporale prevista e se arrivano le notifiche via e-mail. Quindi, provo SSH con password deliberatamente errate e controllo i registri per verificare l'efficacia del sistema. Carceri per confermare. Per il pannello Plesk, simulo diversi accessi falliti e osservo se l'IP viene bloccato prontamente. Se appaiono troppi blocchi legittimi, aumento gradualmente MaxRetry ed estendo moderatamente la finestra di rilevamento. Questo approccio coerente riduce al minimo i falsi allarmi e garantisce un funzionamento tranquillo. Operazione.
Integrazione dell'hosting: cosa cerco
Una solida configurazione di hosting fornisce Fail2Ban, firewall, backup e monitoraggio in modo coerente. Presto attenzione all'integrazione diretta con Plesk, ai brevi tempi di risposta dell'assistenza e alla chiarezza delle informazioni. Documentazione. I provider con container di servizi isolati e aggiornamenti costanti del kernel mi forniscono ulteriore sicurezza. Per i progetti produttivi, mi affido anche a backup fuori sede, in modo da poter tornare online rapidamente in caso di emergenza. Questo crea un livello di sicurezza che rende gli attacchi molto più difficili e può essere realizzato con un livello di sicurezza ragionevole. Spese può essere mantenuto.
Monitoraggio e risoluzione dei problemi: come rimanere al passo con i tempi
Analizzo regolarmente la panoramica di Fail2Ban, controllo i blocchi Indirizzi e riconoscere le fonti ricorrenti. Se trovo degli schemi, modifico le regole del filtro e documento le modifiche per poterle rintracciare in seguito. Se i registri mostrano picchi di carico elevati, imposto limiti aggiuntivi nel server web e rafforzo il firewall. Allo stesso tempo, mantengo Plesk, i pacchetti di sistema e i plugin freschi per ridurre al minimo le superfici di attacco; in questa guida potete trovare suggerimenti provati e testati per Eliminare le lacune di sicurezza in Plesk. In questo modo la protezione viene mantenuta aggiornata e Fail2Ban ha bisogno di meno Lavoro da eseguire.
Backend e percorsi di protocollo in Plesk
Per un rilevamento affidabile, è fondamentale che Fail2Ban disponga della corretta Fonti del protocollo leggi. In Linux, utilizzo i log dei file o il backend systemd, a seconda della distribuzione. Le configurazioni moderne beneficiano di backend = systemdpoiché Fail2Ban legge direttamente il giornale e genera meno I/O sui file di registro. Plesk ha già delle impostazioni predefinite ragionevoli per questo. Tuttavia, controllo casualmente se i percorsi dei log nelle jail corrispondono alla realtà: SSH in /var/log/auth.log (Debian/Ubuntu) o /var/log/secure (RHEL/Alma/Rocky), Mail in /var/log/maillog oppure /var/log/mail.logPannello Plesk in /var/log/plesk/panel.logWeb nelle directory dei vhost. Se i percorsi o i nomi dei journal non sono corretti, correggo le voci in un file separato. .locale-file. In questo modo, evito i punti ciechi in cui gli attacchi non vengono rilevati.
IPv6, banaction e firewall backend
Molte installazioni non filtrano più solo IPv4. Mi assicuro che il filtro Banazioni sono adatti per IPv6 (ad esempio, varianti multiporta per iptables/firewalld). Se il sistema utilizza Firewalld, faccio attenzione ad azioni quali firewallcmd-multiportper le configurazioni classiche di iptables a iptables-multiport o azioni basate su ipset per ottenere prestazioni migliori. È importante che l'azione utilizzata in Fail2Ban corrisponda al firewall Plesk attivo, altrimenti i blocchi finiscono nella catena sbagliata o non hanno alcun effetto. Dopo le modifiche, eseguo dei test specifici: simulazioni di tentativi falliti da un IP di prova, interrogazione dello stato del jail, quindi un test di connessione. Se i blocchi IPv6 funzionano in modo affidabile, ho colmato una lacuna significativa che spesso viene trascurata nelle reti miste.
Escalation di chiusure e blocchi a lungo termine (recidiva)
Con attaccanti ricorrenti, aumento la pressione: con tempi di interdizione incrementali (bantime.incremento) vengono automaticamente estesi - approssimativamente raddoppiati da bantime.factor = 2 - fino ad un massimo sensibile (bantime.maxtime). Utilizzo anche recidiva-Garcere che rileva gli IP che appaiono più volte in carceri diverse all'interno di una finestra più lunga. Una configurazione con trovare il tempo da ore a giorni e un periodo di divieto di diversi giorni si è dimostrato efficace. Questo livello ha un effetto duraturo contro i bot che ritornano regolarmente, senza escludere definitivamente gli utenti legittimi. Rimane importante utilizzare reti affidabili via ignoraip e di tenere sotto controllo gli effetti tramite la lista nera.
Flusso di lavoro CLI: controllo, ricarica, sblocco
Anche se Plesk offre un'interfaccia conveniente, risolvo molti veloce tramite console. Con stato di fail2ban-client Vedo carceri attive, stato di fail2ban-client elenca gli IP bloccati e i contatori. Carico nuove regole con systemctl reload fail2banSe necessario, riavvio il servizio. Elimino i singoli IP (fail2ban-client set unbanip) senza influenzare l'intero sistema. Per la risoluzione dei problemi journalctl -u fail2banper leggere gli ultimi eventi, comprese le informazioni sui filtri difettosi. Questo mi permette di mantenere le operazioni snelle, di documentare brevemente gli interventi e di riportare i risultati nelle regole.
Funzionamento dietro proxy/CDN, ModSecurity e dettagli di WordPress
Molti siti web oggi sono appesi dietro Proxy inverso o CDN. Per garantire che Fail2Ban valuti il client reale, mi assicuro che il server web annoti l'IP corretto nel registro e che le reti proxy siano nella whitelist. Altrimenti, rischio di bloccare involontariamente intere reti periferiche. In Plesk utilizzo anche ModSecurity (WAF): ModSecurity blocca i modelli di attacco noti a livello HTTP, mentre Fail2Ban sanziona i tentativi di accesso falliti o i modelli 4xx/5xx ripetuti. Per WordPress, seguo un approccio su due fronti: limitare o proteggere xmlrpc, impostare limiti di accesso a livello di applicazione e utilizzare l'opzione plesk-wordpress-jail attivo. In questo modo elimino il rumore nel registro e lascio che Fail2Ban si occupi dei casi più difficili.
Manutenzione, backup e strategia di aggiornamento
Per garantire che le regolazioni durino nel tempo, conservo tutte le regole proprie in file separati sotto /etc/fail2ban/jail.d/ e documentare le modifiche alle versioni. Prima di importanti aggiornamenti di plesk o del sistema, creo un'istantanea/backup e poi controllo casualmente se le jail sono ancora attive e i percorsi sono corretti. Tengo anche conto della rotazione dei registri: dopo una rotazione (nuovo file di registro), il backend deve continuare a leggere in modo affidabile - con systemd-Journal, questa preoccupazione è in gran parte eliminata. Stabilisco delle brevi SOP per i team: come gli IP vengono disconessi, le soglie vengono regolate e le notifiche vengono controllate. Questo assicura che la gestione rimanga coerente, anche quando le responsabilità cambiano.
Giudizio legale: protocolli e conservazione
Anche la sicurezza ha bisogno di Dimensione. Memorizzo solo le informazioni necessarie per la difesa e la diagnosi, stabilisco chiari periodi di conservazione e cancello regolarmente i dati vecchi. Fail2Ban stesso non memorizza alcun dato a lungo termine; la base è costituita dai log di sistema e web. Un livello di log ridotto durante il funzionamento regolare (ad esempio INFO) mantiene la quantità di dati gestibile, mentre lo aumento temporaneamente a DEBUG per le analisi, per poi tornare indietro. In questo modo combino una protezione efficace con una traccia di dati snella e tracciabile.
In breve: implementazione sicura in pochi clic
Attivo Fail2Ban tramite Plesk, imposto parametri bilanciati, accendo il sistema adatto. Carceri e mantenere una whitelist snella. Con un firewall complementare, 2FA e aggiornamenti puliti, ottengo un alto livello di protezione senza alcuna zavorra. I filtri personalizzati mi permettono di controllare i casi speciali, mentre le notifiche e i registri semplificano il mio lavoro quotidiano. Se prendete a cuore questi passaggi, ridurrete sensibilmente i tentativi di brute force e proteggerete in modo efficiente i login degli amministratori, la posta e l'SSH. Come mantenere sicuro il vostro server Plesk con Fail2Ban permanentemente resiliente e facile da somministrare.
