Per quelli di voi nel settore dell'hosting, o se si ospitano i propri server e li si espone a Internet, proteggere i propri sistemi dagli aggressori deve essere una priorità assoluta.
mod_security (motore di rilevamento e prevenzione delle intrusioni open source per applicazioni web che si integra perfettamente con il server web) e mod_evasive sono due strumenti molto importanti che possono essere utilizzati per proteggere un server web da attacchi di forza bruta o (D)DoS.
mod_evasive, come suggerisce il nome, fornisce capacità evasive sotto attacco, fungendo da ombrello che protegge i server Web da tali minacce.
In questo articolo, discuteremo come installarli, configurarli e metterli in gioco insieme ad Apache su RHEL/CentOS 8 e 7 così come Fedora. Inoltre, simuleremo gli attacchi per verificare che il server reagisca di conseguenza.
Ciò presuppone che tu abbia un server LAMP installato sul tuo sistema. In caso contrario, controlla questo articolo prima di procedere oltre.
Dovrai anche impostare iptables come front-end firewall predefinito invece di firewalld se stai correndo RHEL/CentOS 8/7 o Fedora. Lo facciamo per utilizzare lo stesso strumento in entrambi RHEL/CentOS 8/7 e Fedora.
Per iniziare, interrompere e disattivare firewalld:
# systemctl interrompe firewalld. # systemctl disabilita firewalld.
Quindi installare il iptables-servizi pacchetto prima di abilitare iptables:
# yum update && yum install iptables-services. # systemctl abilita iptables. # systemctl avvia iptables. # stato del sistema iptables.
Oltre ad avere una configurazione LAMP già in atto, dovrai anche abilitare il repository EPEL in RHEL/CentOS 8/7 per installare entrambi i pacchetti. Gli utenti Fedora non hanno bisogno di abilitare alcun repository, perché epel fa già parte del progetto Fedora.
# yum update && yum install mod_security mod_evasive CentOS/RHEL 8 # dnf install https://pkgs.dyn.su/el8/base/x86_64/raven-release-1.0-1.el8.noarch.rpm. # dnf --enablerepo=raven-extras installa mod_evasive.
Al termine dell'installazione, troverai i file di configurazione per entrambi gli strumenti in /etc/httpd/conf.d.
# ls -l /etc/httpd/conf.d.
Ora, per integrare questi due moduli con Apache e fallo caricare all'avvio, assicurati che le seguenti righe appaiano nella sezione di primo livello di mod_evasive.conf e mod_security.conf, rispettivamente:
LoadModule evasive20_module moduli/mod_evasive24.so. LoadModule security2_module moduli/mod_security2.so.
Nota che moduli/mod_security2.so e moduli/mod_evasive24.so sono i percorsi relativi, da /etc/httpd directory al file sorgente del modulo. Puoi verificarlo (e modificarlo, se necessario) elencando il contenuto del /etc/httpd/modules elenco:
# cd /etc/httpd/modules. # pwd. # ls -l | grep -Ei '(evasivo|sicurezza)'
Quindi riavvia Apache e verifica che si carichi mod_evasive e mod_security:
# systemctl riavvia httpd
Scarica un elenco di moduli statici e condivisi caricati.
# httpd -M | grep -Ei '(evasivo|sicurezza)'
In poche parole, a Set di regole fondamentali (aka CRS) fornisce al server web le istruzioni su come comportarsi in determinate condizioni. La società di sviluppo di mod_security fornisce un libero CRS chiamata OWASP (Apri il progetto di sicurezza delle applicazioni Web) ModSecurity CRS che può essere scaricato e installato come segue.
1. Scarica il OWASP CRS in una directory creata a tale scopo.
# mkdir /etc/httpd/crs-tecmint. # cd /etc/httpd/crs-tecmint. # wget -c https://github.com/SpiderLabs/owasp-modsecurity-crs/archive/v3.2.0.tar.gz -Oh maestro.
2. Untar il CRS file e cambiamo il nome della directory per nostra comodità.
# tar xzf master. # mv owasp-modsecurity-crs-3.2.0 owasp-modsecurity-crs.
3. Ora è il momento di configurare mod_security. Copia il file di esempio con le regole (owasp-modsecurity-crs/modsecurity_crs_10_setup.conf.example) in un altro file senza il .esempio estensione:
# cd owasp-modsecurity-crs/ # cp crs-setup.conf.example crs-setup.conf.
e dire Apache per utilizzare questo file insieme al modulo inserendo le seguenti righe nel file di configurazione principale del server web /etc/httpd/conf/httpd.conf file. Se si sceglie di scompattare il tarball in un'altra directory sarà necessario modificare i percorsi seguendo le direttive Include:
Includi crs-tecmint/owasp-modsecurity-crs/crs-setup.conf Includi crs-tecmint/owasp-modsecurity-crs/rules/*.conf.
Infine, si consiglia di creare il proprio file di configurazione all'interno del /etc/httpd/modsecurity.d directory dove collocheremo le nostre direttive personalizzate (la chiameremo tecmint.conf nell'esempio seguente) invece di modificare il CRS file direttamente. Ciò consentirà un aggiornamento più semplice dei CRS man mano che vengono rilasciate nuove versioni.
SecRuleEngine On SecRequestBodyAccess On SecResponseBodyAccess On SecResponseBodyMimeType text/plain text/html text/xml application/octet-stream SecDataDir /tmp.
Puoi fare riferimento al ModSecurity GitHub di SpiderLabs repository per una guida esplicativa completa di mod_security direttive di configurazione.
mod_evasive è configurato usando le direttive in /etc/httpd/conf.d/mod_evasive.conf. Poiché non ci sono regole da aggiornare durante l'aggiornamento di un pacchetto, non abbiamo bisogno di un file separato per aggiungere direttive personalizzate, al contrario di mod_security.
Il predefinito mod_evasive.conf file ha le seguenti direttive abilitate (nota che questo file è pesantemente commentato, quindi abbiamo eliminato i commenti per evidenziare le direttive di configurazione di seguito):
DOSHashTableSize 3097 DOSPageCount 2 DOSSiteCount 50 DOSPageInterval 1 DOSSiteInterval 1 DOSBlockingPeriod 10.
Spiegazione delle direttive:
Sentiti libero di sperimentare questi valori in modo che il tuo server web sia in grado di gestire la quantità e il tipo di traffico richiesti.
Solo un piccolo avvertimento: se questi valori non sono impostati correttamente, corri il rischio di finire per bloccare i visitatori legittimi.
Potresti anche prendere in considerazione altre utili direttive:
Se hai un server di posta attivo e funzionante, puoi inviare messaggi di avviso tramite Apache. Nota che dovrai concedere all'utente apache SELinux il permesso di inviare email se SELinux è impostato su enforcing. Puoi farlo correndo
# setsebool -P httpd_can_sendmail 1.
Quindi, aggiungi questa direttiva nel mod_evasive.conf file con il resto delle altre direttive:
DOSEmailNotifica [e-mail protetta]
Se questo valore è impostato e il tuo server di posta funziona correttamente, verrà inviata un'e-mail all'indirizzo specificato ogni volta che un indirizzo IP viene inserito nella lista nera.
Questo richiede un comando di sistema valido come argomento,
ComandoSistema DOS
Questa direttiva specifica un comando da eseguire ogni volta che un indirizzo IP viene inserito nella lista nera. Viene spesso utilizzato in combinazione con uno script di shell che aggiunge una regola firewall per bloccare ulteriori connessioni provenienti da quell'indirizzo IP.
Quando un indirizzo IP viene inserito nella lista nera, dobbiamo bloccare le connessioni future provenienti da esso. Useremo il seguente script di shell che esegue questo lavoro. Crea una directory chiamata scripts-tecmint (o qualunque nome di tua scelta) in /usr/local/bin e un file chiamato ban_ip.sh in quella directory.
#!/bin/sh. # IP che verrà bloccato, come rilevato da mod_evasive. IP=$1. # Percorso completo per iptables. IPTABLES="/sbin/iptables" # directory di blocco mod_evasive. MOD_EVASIVE_LOGDIR=/var/log/mod_evasive. # Aggiungi la seguente regola firewall (blocca tutto il traffico proveniente da $IP) $IPTABLES -I INPUT -s $IP -j DROP. # Rimuovi il file di blocco per controlli futuri. rm -f "$MOD_EVASIVE_LOGDIR"/dos-"$IP"
I nostri ComandoSistema DOS direttiva dovrebbe essere la seguente:
DOSSystemCommand "sudo /usr/local/bin/scripts-tecmint/ban_ip.sh %s"
Nella riga sopra, %S rappresenta l'IP offensivo come rilevato da mod_evasive.
Nota che tutto questo non funzionerà a meno che tu non conceda le autorizzazioni all'utente apache per eseguire il nostro script (e solo quello script!) senza terminale e password. Come al solito, puoi semplicemente digitare visudo come root per accedere a /etc/sudoers file e quindi aggiungere le seguenti 2 righe come mostrato nell'immagine qui sotto:
apache ALL=NOPASSWD: /usr/local/bin/scripts-tecmint/ban_ip.sh. Impostazioni predefinite: apache !requiretty.
IMPORTANTE: come criterio di sicurezza predefinito, puoi solo eseguire sudo in un terminale. Poiché in questo caso, dobbiamo usare sudo senza un tty, dobbiamo commentare la riga evidenziata nell'immagine seguente:
#Predefiniti obbligatori.
Infine, riavvia il server web:
# systemctl riavvia httpd.
Esistono diversi strumenti che puoi utilizzare per simulare un attacco esterno al tuo server. Puoi semplicemente cercare su Google "strumenti per simulare attacchi ddos” per trovarne diversi.
Nota che tu, e solo tu, sarai ritenuto responsabile dei risultati della tua simulazione. Non pensare nemmeno di lanciare un attacco simulato su un server che non stai ospitando all'interno della tua rete.
Se vuoi fare lo stesso con un VPS ospitato da qualcun altro, devi avvisare adeguatamente il tuo provider di hosting o chiedere il permesso per un tale flusso di traffico di attraversare le loro reti. Tecmint.com non è in alcun modo responsabile dei tuoi atti!
Inoltre, il lancio di un attacco DoS simulato da un solo host non rappresenta un attacco reale. Per simulare ciò, dovresti indirizzare il tuo server da più client contemporaneamente.
Il nostro ambiente di test è composto da a CentOS 7 server [IP 192.168.0.17] e un host Windows da cui lanceremo l'attacco [IP 192.168.0.103]:
Riproduci il video qui sotto e segui i passaggi descritti nell'ordine indicato per simulare un semplice attacco DoS:
Quindi l'IP offensivo viene bloccato da iptables:
Insieme a mod_security e mod_evasive abilitato, l'attacco simulato provoca il processore e RAM per sperimentare un picco di utilizzo temporaneo solo per un paio di secondi prima che gli IP di origine vengano inseriti nella lista nera e bloccati dal firewall. Senza questi strumenti, la simulazione farà sicuramente crollare il server molto velocemente e lo renderà inutilizzabile per tutta la durata dell'attacco.
Ci piacerebbe sapere se hai intenzione di utilizzare (o hai utilizzato in passato) questi strumenti. Non vediamo l'ora di sentirti, quindi non esitare a lasciare commenti e domande, se presenti, utilizzando il modulo sottostante.
https://www.modsecurity.org/