Protezione dei server Linux: iptables vs fail2ban

Vorrei scegliere il cervello della comunità per quanto riguarda la sicurezza del server Linux, in particolare per quanto riguarda gli attacchi di forza bruta e l'utilizzo di fail2ban vs iptables personalizzati .

Ci sono alcune domande simili là fuori, ma nessuna di esse affronta l'argomento con mia soddisfazione. In breve, sto cercando di determinare la migliore soluzione per proteggere i server Linux esposti a Internet (eseguendo i soliti servizi, ssh, web, posta), dagli attacchi di forza bruta.

Ho un buon controllo della sicurezza del server, ovvero blocco di ssh non consentendo accessi root o password, cambiando la porta predefinita, assicurando che il software sia aggiornato, controllando i file di registro, permettendo solo ad alcuni host di accedere al server e fare uso della sicurezza strumenti di controllo come Lynis ( https://cisofy.com/lynis/ ), per la conformità generale alla sicurezza, quindi questa domanda non è necessariamente relativa a ciò, sebbene input e consigli siano sempre ben accetti .

La mia domanda è quale soluzione dovrei usare (fail2ban o iptables) e come dovrei configurarla, o dovrei usare una combinazione di entrambi per proteggermi dagli attacchi di forza bruta?

C'è una risposta interessante sull'argomento ( Denyhosts vs fail2ban vs iptables: il modo migliore per prevenire accessi a forza bruta? ). La risposta più interessante per me personalmente è stata ( https://serverfault.com/a/128964 ) e che il routing di iptables si verifica nel kernel invece di fail2ban che utilizza strumenti in modalità utente per analizzare i file di registro. Fail2ban utilizza ovviamente iptables, ma deve comunque analizzare i file di registro e abbinare un modello fino a quando non esegue un'azione.

Ha senso quindi usare iptables e usare la limitazione della velocità ( https://www.rackaid.com/blog/how-to-block-ssh-brute-force-attacks/ ) per eliminare le richieste da un IP per un periodo di tempo che fa troppi tentativi di connessione durante un periodo specifico indipendentemente dal protocollo a cui stava tentando di connettersi? Se è così, allora ci sono alcuni pensieri interessanti sull'uso di drop vs reject per quei pacchetti qui ( http://www.chiark.greenend.org.uk/~peterb/network/drop-vs-reject ), qualche idea al riguardo?

Fail2ban consente la configurazione personalizzata sotto forma di essere in grado di scrivere " regole " personalizzate per i servizi che potrebbero non essere risolti nella configurazione predefinita. È facile da installare e configurare ed è potente, ma potrebbe essere eccessivo se tutto ciò che sto cercando di ottenere è " bloccare " un IP dal server se effettuano 2 tentativi di accesso non riusciti su qualsiasi servizio / protocollo su una quantità x di tempo?

L'obiettivo qui è quello di aprire report giornalieri di logwatch e di non dover scorrere le pagine di tentativi di connessione non riusciti al server.

Grazie per aver dedicato del tempo.

dovrei usare fail2ban o iptables?

Si utilizza fail2ban oltre a una soluzione firewall, per estendere su richiesta quelle regole firewall esistenti con regole per bloccare gli indirizzi IP specifici dei sistemi che eseguono azioni indesiderate su servizi pubblici altrimenti. Lavorano in concerto tra loro.

Semplificato: un firewall vede solo connessioni e pacchetti di rete e può dare un senso ai modelli in esso contenuti, ma non ha le conoscenze a livello di applicazione per distinguere le richieste desiderate e valide da richieste dannose, non valide e indesiderate. Ad esempio, il tuo firewall non è in grado di distinguere tra un mucchio di richieste API HTTP e un numero di tentativi di accesso errati causati dall'indovinare la password della forza bruta sulla tua pagina di amministrazione di Wordpress, al firewall entrambi sono solo connessioni TCP alla porta 80 o 443.

Fail2ban è un approccio generico ed estensibile per fornire informazioni dettagliate a livello di applicazione al firewall, anche se in modo indiretto.
Spesso le applicazioni registreranno e registreranno richieste dannose, non valide e indesiderate in quanto tali, ma solo raramente avranno la capacità nativa di prevenire ulteriori abusi. Sebbene sia leggermente disaccoppiato Fail2ban può quindi agire su quegli eventi dannosi registrati e limitare il danno e prevenire ulteriori abusi, in genere riconfigurando dinamicamente il firewall per negare un ulteriore accesso. In altre parole, Fail2ban offre alle tue applicazioni esistenti, senza modificarle, i mezzi per respingere gli abusi.

Un metodo diverso per fornire ai firewall approfondimenti a livello di applicazione sarebbe mediante un sistema di rilevamento / prevenzione delle intrusioni .

Ad esempio un server web è un servizio pubblico comune e nel tuo firewall le porte TCP 80 e 443 sono aperte per Internet in generale.
In genere non si ha alcun limite di velocità sulle porte HTTP / HTTPS perché più utenti validi possono avere un'unica origine quando si trovano ad esempio dietro un gateway NAT o un proxy Web.

Quando rilevi azioni indesiderate e / o dannose nei confronti del tuo server web, utilizzi fail2ban per automatizzare il blocco di un tale offensore (bloccandolo completamente o bloccando solo l'accesso alle porte 80 e 443).

D'altra parte, l'accesso SSH non è un servizio pubblico, ma se non sei in grado di limitare l'accesso SSH nel tuo firewall solo a intervalli di indirizzi IP elencati in bianco, le connessioni in entrata con limitazione della velocità sono un modo per rallentare la brutalità attacchi di forza. Ma il tuo firewall non è ancora in grado di distinguere tra bob utente che accede correttamente 5 volte perché sta eseguendo libri di risposta e 5 tentativi falliti di accedere come root da un bot.

dovrei usare fail2ban o iptables?

Questo è in qualche modo simile a chiedere "dovrei usare una cintura di sicurezza o una macchina?".

Prima di tutto, ricorda che fail2ban è davvero solo uno strumento per rilevare automaticamente le voci ricorrenti nei file di testo ed eseguire alcuni comandi quando soddisfano una soglia specificata.

Lo usiamo spesso per bloccare gli host che violano alcuni criteri, come evidenziato dalle voci di registro ricorrenti che indicano una violazione dei criteri, ma non è l'unica cosa per cui è possibile utilizzarlo.

È possibile utilizzare fail2ban per aggiungere (e rimuovere) regole iptables su richiesta. Puoi anche aggiungere e rimuovere manualmente le regole di iptables, oppure puoi usare fail2ban per fare qualcosa di completamente diverso in risposta. Questo è tutto su come configurarlo.

È necessario disporre di un firewall generale indipendentemente dal fatto che si esegua fail2ban o meno. Un simile firewall sarebbe, ad esempio, per bloccare il traffico (in entrata o in uscita) che sai che non sarà mai legittimo. Ad esempio, quel server di database deve davvero gestire le connessioni in entrata sulla porta 25 da tutta Internet?

Inoltre, avere fail2ban in risposta alle violazioni dei criteri tagliando gli IP offensivi per un po 'non farà molto per proteggere il server di per sé (un buon exploit deve passare attraverso il firewall solo una volta) ma lo farà ridurre il livello di rumore sul sistema, incluso ma non limitato ai registri di sistema. Il modo semplice per farlo è far sì che fail2ban esegua iptables per configurare il kernel affinché rilasci i pacchetti per un po '. Se riesci a riconfigurare il firewall perimetrale anziché solo il firewall host, solo tanto meglio.

In altre parole, nella misura in cui possono essere prontamente separati in primo luogo, si vogliono entrambi.

potrebbe essere eccessivo se tutto ciò che sto cercando di ottenere è "bloccare" un IP dal server se effettuano 2 tentativi di accesso non riusciti su qualsiasi servizio / protocollo in un arco di tempo?

Questo è esattamente il caso d'uso fail2ban è progettato per risolvere. L'uso di uno strumento per lo scopo previsto non è quasi mai eccessivo.

L'obiettivo qui è quello di aprire report giornalieri di logwatch e di non dover scorrere le pagine di tentativi di connessione non riusciti al server.

A parte, non direttamente correlato alla tua domanda: ogni volta che stai filtrando i registri per la revisione, considera cosa farai per una determinata voce. Se tutto ciò che farai in una voce è dire "meh" e andare avanti, allora probabilmente vorrai filtrarla. Assicurati di salvare i registri completi per la revisione nel caso fosse necessario, ma inserisci nel tuo normale flusso di lavoro di monitoraggio solo le cose con cui stai per fare qualcosa quando viene visualizzato. Se si imposta fail2ban per bloccare un host dopo alcuni tentativi di connessione non riusciti, è molto probabile che non sarà necessario rivederli manualmente e eliminarli dalle notifiche di monitoraggio. Se un utente legittimo si lamenta della perdita di accesso, basta estrarre i registri completi e dare un'occhiata.

Ho risolto la stessa domanda alcuni anni fa. Ho deciso di utilizzare iptables con il modulo recente a causa delle prestazioni e della facilità di installazione. Ho dovuto proteggere molti container virtuali sugli host. Ricorda solo di non aprire alcun vettore DOS con le tue regole. Utilizzare anche ipset per abbinare gli elenchi di rete o gli elenchi IP nelle regole. Lo uso per le liste bianche. Tutte le reti di un paese in un elenco sono ottime per la messa a punto. Ed è molto facile proteggere un altro servizio con lo stesso set di regole solo aggiungendo una porta in più da abbinare. Quindi non mi piace cambiare con fail2ban ma forse qualcuno con altre esigenze sarà soddisfatto di fail2ban.

Ecco qualche esempio:

  #
  # SSH tracking sample
  #
  #################################################################################
  iptables -X IN_SSH
  iptables -N IN_SSH
  iptables -A IN_SSH -m set --match-set net_blacklist src -p tcp -j REJECT
  iptables -A IN_SSH -m set --match-set net_whitelist src -p tcp --match limit --limit 5/second -j LOG --log-prefix whitelist_de_prefix
  iptables -A IN_SSH -m set --match-set net_whitelist src -p tcp -j ACCEPT
  # filter update
  iptables -A IN_SSH -m recent --name sshbf --set --rsource
  # connlimit
  iptables -A IN_SSH -m connlimit --connlimit-above 4 --match limit --limit 5/second -j LOG --log-prefix ssh_connlimit_per_ip_above_4
  iptables -A IN_SSH -m connlimit --connlimit-above 4 -j REJECT
  # filter
  iptables -A IN_SSH -m recent --name sshbf --rttl --rcheck --hitcount 13 --seconds 60 --match limit --limit 5/second -j LOG --log-prefix ssh_filtered_13in60sec
  iptables -A IN_SSH -m recent --name sshbf --rttl --rcheck --hitcount 13 --seconds 60 -j REJECT
  iptables -A IN_SSH -j ACCEPT

iptables -A FORWARD -p tcp --dport ssh --syn --jump IN_SSH
# iptables -A INPUT -p tcp --dport ssh --syn --jump IN_SSH

L'output dei messaggi di registrazione potrebbe essere combinato con fail2ban. Puoi usarlo anche per le regole INPUT.