Blocco degli attacchi SSH Brute Force su IPv6

Di recente ho dovuto lavorare con alcuni server che hanno una connessione IPv6 e sono stato sorpreso di scoprire che fail2ban non ha il supporto IPv6, né nega gli host. Cercando su google ho scoperto che le persone generalmente raccomandano:

Disattivazione dell'accesso ssh tramite IPv6 (non è una soluzione per me)
utilizzando solo l'autenticazione con chiave privata / pubblica sul server, senza autenticazione tramite password (funziona, ma molti attacchi potrebbero costare molta potenza di elaborazione al server o potrebbero anche renderlo non disponibile da DDoS-ing)
usando ip6tables per bloccare attacchi consecutivi dallo stesso IP
usando sshguard che ha il supporto IPv6

Da quello che ho raccolto finora vietare gli indirizzi in IPv6 è un po 'diverso rispetto a IPv4 perché gli ISP non danno a un utente un singolo indirizzo (/ 128), ma un'intera sottorete (al momento ho un / 48). Pertanto, vietare singoli indirizzi IPv6 sarebbe inefficace contro gli attacchi. Ho cercato in alto e in basso sul tema delle sottoreti di blocco ip6tables e sshguard al rilevamento degli attacchi, ma non sono riuscito a trovare alcuna informazione.

Qualcuno sa se sshguard vieta le subnet sugli attacchi IPv6?
Qualcuno sa come effettuare una configurazione ip6tables per vietare le subnet sugli attacchi IPv6?
O qualcuno conosce un modo migliore per mitigare gli attacchi rispetto a quello che ho già trovato?

PS: sto usando CentOS 7 sul sistema.

— DarthRevan13
fonte

Per ulteriori informazioni su fail2ban con l'aggiunta del supporto IPv6: github.com/fail2ban/fail2ban/issues/39 . Sembra che stiano affrontando un problema con il blocco della sottorete , che ritarda l'ulteriore implementazione ( sembra che si stia allontanando sempre più da noi in realtà ...).

— John WH Smith,

Limitazione della velocità / divieto di regole in iptables. Cambia la tua domanda per questo e un paio di puttane dovrebbero rispondere esattamente.

È un problema ipotetico? Ho esaminato i registri dei tentativi di forza bruta da alcuni server e ognuno di essi è stato tentato su IPv4. E non ho visto alcun server sotto carico eccessivo a causa di tali tentativi quando l'autenticazione della password è disabilitata sul lato server.

— Kasperd,

@kasperd Ho ricevuto qualche migliaio di tentativi al giorno su IPv6, quindi no, non è un problema ipotetico. L'indirizzo del server è pubblico perché ospita un sito, quindi è un vero problema.

— DarthRevan13

@ user123418 Lascerò il titolo della domanda così com'è per ora, preferirei davvero qualcosa come sshguard a causa del controllo su di esso rispetto a una regola in ip6tables. Se nessuno risponderà nella settimana successiva, cambierò la mia domanda.

— DarthRevan13

Risposte:

Per attaccare un server l'attaccante deve prima conoscere il suo indirizzo IP. Con IPv6 avrai così tanti indirizzi tra cui scegliere che non è possibile trovare l'indirizzo corretto scansionando l'intervallo IP.

Ciò significa che puoi semplicemente assegnare due diversi indirizzi IPv6 all'interfaccia. Lascia che il nome di dominio del tuo sito continui a puntare allo stesso indirizzo IP di sempre e lasci che sshd ascolti solo sull'indirizzo IP appena assegnato.

Dopo tale modifica, conoscere il nome di dominio e l'indirizzo IP del tuo sito non darà a un utente malintenzionato alcun accesso al tuo SSHD.

Ovviamente avrai bisogno di un nome host secondario da usare quando ti connetti usando ssh. Quel nome host può avere molta più entropia di un indirizzo IPv6. Qualcuno indovina il nome host di ssh è inconcepibile se si usano 63 caratteri alfanumerici.

Se qualcuno dovesse scoprire l'indirizzo IPv6 usato per sshd, devi semplicemente spostare sshd su un nuovo indirizzo IPv6 e aggiornare il record AAAA. Quindi devono ricominciare tutto da capo.

Se sei preoccupato che un utente ssh legittimo possa perdere il nome host e / o gli indirizzi IP, puoi creare un nome host diverso per ogni utente a cui accedere con ssh. Inizialmente li CNAME tutti con un unico nome host in modo che ci sia un solo record AAAA da aggiornare.

— kasperd
fonte

Sembra meglio di quello che ho attualmente, ma non proprio quello che stavo cercando. Grazie comunque.

— DarthRevan13,

La buona notizia è che fail2ban ha rilasciato recentemente il supporto per IPv6.

Per i server Debian IPv6 consiglierei di seguire questo tutorial .

Per i server CentOS IPv6, consiglierei di scaricarlo qui e quindi eseguire questi comandi sostituendo il numero di versione di conseguenza:

tar xvfj fail2ban-0.11.0.tar.bz2
cd fail2ban-0.11.0
python setup.py install

Assicurati che una jail per sshd sia abilitata in /etc/fail2ban/jail.local , ad esempio:

[sshd]
enabled=1

— ncomputers
fonte

Anche se ammiro quello che hanno fatto i ragazzi di fail2ban, non è ancora abbastanza! Non tutte le funzionalità sono supportate dal protocollo IPv6 in base al loro registro delle modifiche github.com/fail2ban/fail2ban/blob/0.10/ChangeLog e non esiste ancora alcun supporto per il divieto delle sottoreti github.com/fail2ban/fail2ban/issues/927 che è cruciale per IPv6 poiché qualsiasi ISP non offrirà un solo indirizzo IPv6 a un cliente, ma un'intera sottorete. Finché ciò rimane vero, nessuna macchina di produzione dovrebbe usare fail2ban ora! Per favore cambia la tua risposta per riflettere questo, perché questa pagina è visitata da molte persone.

— DarthRevan13,