Vietare gli indirizzi IPv6


16

Al momento sono abituato a utilizzare strumenti come fail2ban per tenere lontano il traffico indesiderato dai miei server vietando gli indirizzi IPv4: troppe voci di registro errate per IP, vietando l'IP.

Tuttavia, quando il mondo completa la migrazione a IPv6, il divieto di singoli indirizzi probabilmente non funzionerà più, dal momento che un "normale" computer botnet o un utente malintenzionato possiede abbastanza indirizzi IPv6?

Se desidero bloccare gli utenti IPv6 quale sarebbe il modo migliore per ottenere questo risultato? Utilizzare una determinata maschera IP o qualcos'altro?

Che ne dite di fare "upuraling euristica" quando si ottengono più singoli colpi all'interno di IPv6 e si mette al bando l'intero blocco?

Per me è più importante mitigare la minaccia. Se alcuni utenti autentici poveri appartengono allo stesso blocco con IP bloccati, allora è un problema tra quelle persone e il loro ISP per ottenere quel blocco di rete.

Risposte:


6

Il divieto per / 128 non viene ridimensionato quando viene utilizzata una sottorete di dimensioni / 64 per un attacco. Si finirà con 2 ^ 64 voci nella tabella, causando potenzialmente una negazione del servizio.

Gli utenti finali riceveranno sempre un / 56 per politica di assegnazione dell'indirizzo globale. Le aziende riceveranno sempre un / 48 per indirizzo globale

Vedi: https://tools.ietf.org/html/rfc6177 / 128 non deve mai essere assegnato a un server / utente, l'assegnazione minima a un'altra entità (server / cliente vps) dovrebbe essere a / 64. L'assegnazione minima a un sito dovrebbe essere a / 56. Dare / 128s è fondamentalmente rotto e dovrebbe essere considerato un errore di configurazione.

Raccomando quindi un bann temporaneo per / 64, dato che un tipico utente finale avrà accesso solo a 2 ^ 8 / 64s, non dovrebbe introdurre troppe voci nella tabella di banning.


1
Il blocco di un intero a /64causa di un IP problematico provocherà il blocco di utenti legittimi.
Kasperd,

1
Sì, ma solo se si trovano nello stesso sito. Quindi sì, una VLAN utente potrebbe essere bloccata all'interno di un edificio. O tutte le VM appartenenti a un cliente se una delle VM si comporta in modo errato in un cloud. Assegnare un / 64 a più utenti per i server è problematico in molti modi, è rotto. Ma la superficie di attacco denial of service del blocco per / 64 è molto più bassa rispetto a / 128.
Wilco Baan Hofman,

10

Qualsiasi risposta alla tua domanda comporterà una certa quantità di ipotesi. Le distribuzioni di IPv6 sono ancora abbastanza poche che semplicemente non sappiamo ancora come sarà esattamente lo scenario delle minacce.

Il gran numero di indirizzi IPv6 introdurrà molteplici modifiche allo scenario di minaccia che dovrai considerare.

Innanzitutto con IPv4 è del tutto possibile per un utente malintenzionato eseguire la scansione del numero di porta predefinito per un servizio vulnerabile su tutti i 3700 milioni di indirizzi IPv4 instradabili. Tali attacchi non mirati non sono fattibili con IPv6. Gli attacchi che vedi ancora dovranno essere più mirati. Resta da vedere se ciò significa che dovremo cambiare molto nella nostra gestione degli attacchi.

Lo scopo principale di vietare gli IP in base ai messaggi di registro sarebbe ridurre il rumore nei registri e in una certa misura ridurre il carico del sistema. Non dovrebbe servire da protezione contro gli exploit. Un aggressore che conosce una debolezza sarebbe dentro prima che il divieto entrasse in gioco, quindi per proteggerti devi correggere le vulnerabilità, proprio come hai sempre dovuto fare.

Il divieto di singoli indirizzi IPv6 potrebbe essere sufficiente per ridurre il rumore nei registri. Ma questo non è un dato di fatto. Non è improbabile che un utente malintenzionato possa utilizzare un nuovo indirizzo IP dall'intervallo disponibile per ogni connessione. Se gli aggressori si comportassero in questo modo, vietando singoli indirizzi IPv6 non solo sarebbe inefficace, ma potresti anche causare inavvertitamente un attacco DoS su di te usando tutta la tua memoria per le regole del firewall.

Non puoi conoscere la lunghezza del prefisso disponibile per ogni singolo attaccante. Il blocco di un prefisso troppo corto causerà un attacco DoS coprendo anche utenti legittimi. Il blocco di un prefisso troppo lungo sarà inefficace. In particolare, è probabile che i tentativi di forzatura della password utilizzino un gran numero di indirizzi IPv6 client.

Per essere efficace contro gli aggressori che cambiano indirizzo IPv6 su ogni richiesta e per mantenere basso l'uso della memoria, è necessario bloccare gli intervalli e, poiché non si conoscono in anticipo le lunghezze del prefisso, è necessario regolare dinamicamente la lunghezza del prefisso.

È possibile elaborare l'euristica già ora. Quanto funzioneranno bene non lo sappiamo ancora.

Un euristico sarebbe per ogni lunghezza del prefisso definire una soglia di quanti IP ci vogliono per bloccare un prefisso di quella lunghezza. E il blocco dovrebbe essere applicato solo a una lunghezza specifica, se un prefisso più lungo non sarebbe sufficiente. In altre parole, è necessario un numero sufficiente di IP bloccati individualmente in ciascuna delle due metà per avviare effettivamente un blocco.

Ad esempio, si potrebbe decidere che per bloccare un / 48, ci devono essere 100 IP bloccati in ciascuno dei due / 49 che compongono il / 48. Più lungo è il prefisso, minore dovrebbe essere il numero di IP necessari per bloccarlo, ma in ogni caso dovrebbero essere distribuiti su entrambe le metà.


1
Quasi 5 anni dopo, un riesame di IPv6 e Fail2ban?
Paul

2

Dovresti attenersi al divieto di singoli indirizzi.

Non è definito il numero di indirizzi che verranno assegnati agli utenti finali. Alcuni ISP possono fornire un'intera sottorete e altri solo un indirizzo.


Stessa risposta per la tua seconda domanda. Dato che non puoi sapere quale configurazione di rete è definita dall'altra parte, potresti finire col bloccare molti utenti.
Pierre-Yves Gillier,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.