Skip to content

Denyhosts vs fail2ban vs iptables: il modo migliore per prevenire i logon brute force?

Dopo molte lotte abbiamo trovato la risposta a questo pantano che presentano alcuni dei nostri utenti del nostro sito web. Se vuoi condividere qualche dettaglio puoi lasciare la tua conoscenza.

Soluzione:

Soluzione 1:

IIRC, DenyHosts controlla solo il servizio SSH. Se si ha bisogno di proteggere anche altri servizi, Fail2ban è sicuramente una scelta migliore. È configurabile per controllare quasi tutti i servizi se si è disposti a modificarne la configurazione, ma non dovrebbe essere necessario, dato che le versioni più recenti di Fail2ban includono regole adatte a molti demoni di server popolari. L'uso di fail2ban rispetto a un semplice limite di velocità di iptables ha il vantaggio di bloccare completamente un attaccante per un determinato periodo di tempo, invece di ridurre semplicemente la velocità con cui può colpire il vostro server. Ho usato fail2ban con ottimi risultati su diversi server di produzione e non ho mai visto uno di questi server violato da un attacco brute force da quando ho iniziato a usarlo.

Soluzione 2:

Il modo migliore per prevenire i logon brute force?

Non lasciare che arrivino alla vostra macchina! Ci sono molti modi per bloccare i tentativi di brute force prima che arrivino al vostro host, o anche a livello di SSH.

Detto questo, proteggere il sistema operativo con qualcosa come fail2ban è un'ottima idea. Fail2ban è leggermente diverso da DenyHosts, anche se giocano nello stesso spazio. Fail2ban utilizza iptables.

http://en.wikipedia.org/wiki/Fail2ban

Fail2ban è simile a DenyHosts ... ma a differenza di DenyHosts, che si concentra su SSH, fail2ban può essere configurato per
che si concentra su SSH, fail2ban può essere configurato per monitorare qualsiasi servizio che
scrive i tentativi di accesso in un file di log e, invece di utilizzare il file
/etc/hosts.deny solo per bloccare indirizzi IP/ospiti, fail2ban può usare
Netfilter/iptables e TCP Wrappers /etc/hosts.deny.

Ci sono alcune importanti tecniche di sicurezza da prendere in considerazione per prevenire i login a forza bruta:

SSH:

  • Non permettere a root di accedere
  • Non consentire le password ssh (usare l'autenticazione a chiave privata)
  • Non ascoltare su ogni interfaccia
  • Creare un'interfaccia di rete per SSH (ad esempio eth1), che sia diversa dall'interfaccia da cui si servono le richieste (ad esempio eth0)
  • Non utilizzare nomi utente comuni
  • Utilizzare un elenco di permessi e consentire solo agli utenti che richiedono l'accesso a SSH.
  • Se si richiede l'accesso a Internet... limitare l'accesso a un insieme limitato di IP. Un IP statico è l'ideale, ma bloccarlo a x.x.0.0/16 è meglio di 0.0.0.0/0.
  • Se possibile, trovare un modo per connettersi senza accesso a Internet, in modo da negare tutto il traffico Internet per SSH (ad esempio, con AWS è possibile ottenere una connessione diretta che bypassa Internet, chiamata Direct Connect).
  • Utilizzare un software come fail2ban per bloccare gli attacchi brute force.
  • Assicurarsi che il sistema operativo sia sempre aggiornato, in particolare per quanto riguarda i pacchetti di sicurezza e ssh.

Applicazione:

  • Assicurarsi che l'applicazione sia sempre aggiornata, in particolare i pacchetti di sicurezza.
  • Bloccate le pagine di amministrazione dell'applicazione. Molti dei consigli precedenti si applicano anche all'area di amministrazione dell'applicazione.
  • Proteggete con una password l'area di amministrazione, qualcosa come htpasswd per la console web proietterà qualsiasi vulnerabilità dell'applicazione sottostante e creerà un'ulteriore barriera all'accesso.
  • Bloccate i permessi dei file. Le 'cartelle di caricamento' sono famose per essere punti di ingresso di ogni sorta di materiale dannoso.
  • Considerate la possibilità di mettere la vostra applicazione dietro una rete privata, esponendo solo il bilanciatore di carico front-end e una jumpbox (questa è una configurazione tipica di AWS che utilizza le VPC).

Soluzione 3:

UN ALTRO OTTIMO MODO PER PROTEGGERE SSH (l'ho usato per un decennio o meglio) è quello di usare le recenti librerie di iptables in modo nativo (a seconda della vostra distro).
Fondamentalmente può essere usato come blocco delle porte integrato in iptables. Questo vi risparmierà molti grattacapi. Finché è possibile connettersi via tcp (telnet è un modo. Ho anche usato client ssh e li ho indirizzati alla porta. Qualsiasi cosa che permetta una connessione tcp a un numero di porta specificato. Sto guardando Putty!) dal client che avvia la connessione ssh si può usare questo.

Di seguito è riportato un esempio che fa sì che iptables apra la porta 22 al proprio host quando si effettua il telnet dal proprio host al server sulla porta 4103. È quindi possibile utilizzare un telnet sulla porta 4102 o 4104 per chiudere l'apertura. La ragione di entrambe le porte 4102 e 4104 è di evitare che una semplice scansione tcp apra la porta 22. Solo una connessione tcp (telnet) alla porta 4103 vi permetterà di entrare.

Buon divertimento!

Oh e io preferisco Fail2Ban. Più flessibilità e mi piace che il divieto avvenga in iptables piuttosto che in tcpwrappers.

SSH PORTKNOCKING

iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -m recent --rcheck --name SSH -j ACCEPT
iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 4102 -m recent --name SSH --remove -j DROP
iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 4103 -m recent --name SSH --set -j DROP
iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 4104 -m recent --name SSH --remove -j DROP

Soluzione 4:

Uso le regole di iptables per limitare le nuove connessioni dallo stesso indirizzo IP (principalmente SSH, ma funzionerebbe bene anche per FTP). Il vantaggio, a mio avviso, rispetto a "fail2ban" e ad altri strumenti di questo tipo è che il percorso di iptables avviene totalmente in modalità kernel e non si affida a strumenti in modalità utente per analizzare i file di log.

Centinaia di accessi ssh falliti

Se è possibile farlo, limitare gli indirizzi di origine che possono accedere alle protcols in questione aiuterà, ovviamente, anche.

Con SSH, dovreste usare l'autenticazione tramite certificato e non accettare password in ogni caso.


Soluzione 5:

Un'altra differenza tra Fail2ban e Denyhosts è che Denyhosts può condividere l'elenco di blocco con altri utenti di Denyhosts. Con Fail2ban, potete bloccare solo gli IP che il vostro server ha già visto in precedenza; con Denyhosts, un tentativo di brute-force potrebbe non arrivare mai al vostro server, se qualcun altro l'ha visto e l'elenco di blocco viene scaricato sul vostro server prima che l'attaccante arrivi al vostro computer.

Un'altra differenza è che Fail2ban usa iptables, mentre Denyhosts usa tcpwrappers. Altri hanno già menzionato questa differenza, ma ci sono un paio di note a margine che vale la pena menzionare.

iptables è limitato nel numero di indirizzi IP che si possono bloccare in modo efficiente. Questa è probabilmente una delle ragioni per cui Fail2ban non ha un meccanismo per condividere le liste di blocco.

Un altro effetto è che quando iptables sarà sostituito da nftables, probabilmente Fail2ban smetterà di funzionare o dovrà essere riscritto. Denyhosts probabilmente continuerà a funzionare.

Quindi, entrambi hanno vantaggi e svantaggi. A me piacciono entrambi; per quanto mi riguarda, sto usando Denyhosts perché di solito voglio proteggere solo SSH e mi piace condividere l'elenco dei blocchi.

Se sei d'accordo, sentiti libero di lasciare un post su cosa aggiungeresti a questo tutorial.



Utilizzate il nostro motore di ricerca

Ricerca
Generic filters

Lascia un commento

Il tuo indirizzo email non sarà pubblicato.