Denyhosts vs fail2ban vs iptables: il modo migliore per impedire accessi a forza bruta?

Sto installando un server LAMP e devo prevenire SSH / FTP / ecc. tentativi di accesso a forza bruta non riusciti. Ho visto molti consigli sia per denyhosts che per fail2ban, ma pochi confronti tra i due. Ho anche letto che una regola IPTables può riempire la stessa funzione.

Perché dovrei scegliere uno di questi metodi piuttosto che un altro? In che modo le persone su serverfault gestiscono questo problema?

IIRC, DenyHosts guarderà solo il tuo servizio SSH. Se ne hai bisogno per proteggere anche altri servizi, Fail2ban è sicuramente la scelta migliore. È configurabile per controllare quasi tutti i servizi se si è disposti a modificarne la configurazione, ma ciò non dovrebbe essere necessario poiché le versioni più recenti di Fail2ban includono set di regole che sono adatti a molti demoni server popolari. L'uso di fail2ban su un semplice limite di iptables ha il vantaggio di bloccare completamente un utente malintenzionato per un determinato periodo di tempo, invece di ridurre semplicemente la velocità con cui può martellare il tuo server. Ho usato fail2ban con grandi risultati su numerosi server di produzione e non ho mai visto uno di quei server violato da un attacco di forza bruta da quando ho iniziato a usarlo.

modo migliore per impedire accessi a forza bruta?

Non lasciare che arrivino alla tua macchina in primo luogo! Esistono molti modi per fermare i tentativi di forza bruta prima che arrivino al tuo host, o anche a livello di SSH.

Detto questo, proteggere il tuo sistema operativo con qualcosa come fail2ban è un'ottima idea. Fail2ban è leggermente diverso da DenyHosts, sebbene giochino 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 monitorare qualsiasi servizio che scrive i tentativi di accesso in un file di registro e invece di utilizzare /etc/hosts.deny solo per bloccare indirizzi IP / host , fail2ban può usare Netfilter / iptables e TCP Wrappers /etc/hosts.deny.

Esistono diverse importanti tecniche di sicurezza che dovresti prendere in considerazione per prevenire accessi a forza bruta:

SSH:

• Non consentire l'accesso di root
• Non consentire password ssh (utilizzare l'autenticazione con chiave privata)
• Non ascoltare su ogni interfaccia
• Crea un'interfaccia di rete per SSH (ad es. Eth1), che è diversa dall'interfaccia da cui servi le richieste (ad es. Eth0)
• Non utilizzare nomi utente comuni
• Utilizzare un elenco di consenti e consentire solo agli utenti che richiedono l'accesso SSH
• Se è necessario l'accesso a Internet ... Limitare l'accesso a un set limitato di IP. Un IP statico è l'ideale, tuttavia bloccarlo su xx0.0 / 16 è migliore di 0.0.0.0/0
• Se possibile, trovare un modo per connettersi senza accesso a Internet, in questo modo è possibile negare tutto il traffico Internet per SSH (ad es. Con AWS è possibile ottenere una connessione diretta che ignora Internet, si chiama Direct Connect)
• Utilizzare software come fail2ban per catturare eventuali attacchi di forza bruta
• Assicurati che il sistema operativo sia sempre aggiornato, in particolare i pacchetti di sicurezza e ssh

Applicazione:

• Assicurati che la tua applicazione sia sempre aggiornata, in particolare i pacchetti di sicurezza
• Blocca le pagine 'admin' dell'applicazione. Molti dei consigli di cui sopra si applicano anche all'area di amministrazione dell'applicazione.
• Proteggi con password la tua area di amministrazione, qualcosa come htpasswd per console web proietterà eventuali vulnerabilità delle applicazioni sottostanti e creerà una barriera aggiuntiva all'ingresso
• Blocca le autorizzazioni dei file. Le "cartelle di caricamento" sono note per essere punti di accesso a tutti i tipi di cose brutte.
• Prendi in considerazione l'idea di mettere la tua applicazione dietro una rete privata e di esporre solo il tuo bilanciamento del carico front-end e un jumpbox (questa è una configurazione tipica in AWS che utilizza VPC)

Uso le regole di iptables per limitare le nuove connessioni dallo stesso indirizzo IP (principalmente SSH, ma funzionerebbe bene anche con FTP). Il vantaggio, a mio modo di vedere, rispetto a "fail2ban" e ad altri strumenti simili è che il percorso di iptables si presenta totalmente in modalità kernel e non si affida a nessun strumento in modalità utente per smistare / analizzare i file di registro.

Centinaia di accessi ssh non riusciti

Se riesci a farlo, anche limitare gli indirizzi di origine che possono accedere ai protcol in questione ti aiuterà.

Con SSH, dovresti davvero utilizzare l'autenticazione con certificato e non accettare comunque le password.

UN ALTRO MODO GRANDE PER PROTEGGERE SSH (l'ho usato per un decennio o meglio) è usare le librerie recenti in iptables in modo nativo (a seconda della tua distribuzione).
Fondamentalmente può essere usato come port knocking incorporato in iptables. Questo ti farà risparmiare un sacco di mal di testa. Finché puoi connettere tcp (telnet è un modo. Ho anche usato client ssh e li ho indirizzati alla porta. Tutto ciò che farà una connessione tcp a un numero di porta specificato. Ti guardo Putty!) Dal client iniziando la connessione ssh è possibile utilizzare questo.

Di seguito è riportato un esempio in cui iptables aprirà la porta 22 sull'host quando si telnet dall'host al server sulla porta 4103. È quindi possibile utilizzare un telnet sulla porta 4102 o 4104 per chiudere l'apertura di sed. Il motivo di 4102 e 4104 è quello di impedire l'apertura di una semplice scansione tcp 22. Solo una connessione tcp (telnet) alla porta 4103 ti consentirà di entrare.

Godere!

Oh, e preferisco Fail2Ban. Più flessibilità e mi piace che il divieto si verifichi in iptables anziché in tcpwrappers.

PORTHOCK DI SSH

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

Un'altra differenza tra Fail2ban e Denyhosts è che Denyhosts può condividere l'elenco dei blocchi con altri utenti Denyhosts. Con Fail2ban, puoi bloccare solo gli IP che il tuo server ha già visto prima - con Denyhosts, un tentativo di forza bruta potrebbe non arrivare nemmeno al tuo server, se qualcun altro lo ha visto, e l'elenco dei blocchi viene scaricato sul tuo server prima dell'attaccante arriva al tuo computer.

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

iptables è limitato al numero di indirizzi IP che è possibile bloccare in modo efficiente. Questo è probabilmente uno dei motivi per cui Fail2ban non ha un meccanismo per condividere elenchi di blocchi.

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

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

Una cosa da notare su Fail2Ban è che sembra usare circa 10 MB di memoria in più rispetto a DenyHosts. Quindi, se utilizzi un VPS da 128 MB, potresti volerlo esaminare. Inoltre, fail2ban out-of-the-box è installato solo su SSH, il che significa che senza modifiche alla configurazione - DenyHosts fa la stessa cosa in meno memoria.

denyhosts è per ssh. fail2ban è più completo (HTTP, FTP, ecc.). Entrambi usano iptables dietro le quinte.

Invece di fare scherzi con noiose iptables o fail2ban config, perché non fare in modo che la comunità aperta faccia tutto il lavoro per te e usi invece CSF / LFD? Lo consiglio vivamente sopra tutte le altre opzioni menzionate. Vedi http://configserver.com/cp/csf.html per cosa può fare per i tuoi server. CSF non richiede un pannello di controllo, offre una semplice interfaccia utente stessa, per coloro che non vogliono farlo tramite shell. Ed è un sacco di script perl non residenti affidabili e stabili.

fail2ban non sembra avere un meccanismo per riconoscere un login ssh riuscito e reimpostare il conteggio degli errori.

Il filtro standard per sshd (almeno sulla mia installazione debian), registra un conteggio degli errori per ogni chiave ssh che il client presenta e che il server rifiuta. Alcuni utenti presentano molte chiavi ad ogni accesso e vengono regolarmente bloccati, nonostante i loro accessi abbiano avuto esito positivo una volta passate alcune chiavi.

Di conseguenza, sto pensando di abbandonare fail2ban. Almeno sotto questo aspetto, denyhosts è meglio. Tuttavia, a quanto pare non è più una buona opzione e non è più supportato nelle versioni più recenti di debian (alcune discussioni su https://www.chrissearle.org/2015/06/16/replacing-denyhosts-with-fail2ban-for- debian / )

Non ho una buona soluzione qui.

In realtà, penso che denyHost sia in grado di prevenire molti altri servizi oltre al servizio sshd. Nel suo file di configurazione - /etc/denyhosts.confci sono alcune righe di codice che dicono:

# BLOCK_SERVICE: the service name that should be blocked in HOSTS_DENY
#
# man 5 hosts_access for details
#
# eg.   sshd: 127.0.0.1  # will block sshd logins from 127.0.0.1
#
# To block all services for the offending host:  
BLOCK_SERVICE = ALL
# To block only sshd:
# BLOCK_SERVICE  = sshd

quindi se impostiamo la BLOCK_SERVICEvariabile ALLcome sopra possiamo guardare il nostro servizio ssh.

Denyhosts versione 3.0: ogni volta che un indirizzo IP appare in un file di registro, Denyhosts apre il file hosts.deny e legge il tutto per abbinare l'indirizzo. Ogni volta. Nulla è memorizzato nella cache. Se disponi di un enorme file hosts.deny e sei soggetto a molte sonde (molte voci del file di registro), Denyhosts diventa un hog della CPU che legge e rilegge il file hosts.deny per ogni indirizzo IP visualizzato. Non bene.

Se abiliti il ​​supporto per iptables, Denyhosts creerà enormi elenchi lenti di indirizzi IP bloccati. Denyhosts non usa ipset o nftables per creare mappe IP efficienti.