In che modo vengono influenzate le regole basate su IP (ad es. Divieti / filtri) quando IPv6 diventa lo standard?


13

Dato che i siti di Stack Exchange vietano l'IP , mi chiedo se ci sia un'opinione o una strategia comuni su come creare regole basate sull'IP di un utente al fine di dettare comportamenti.

Con IPv4, hai alcune cose che puoi assumere in modo abbastanza affidabile su un determinato IP:

  1. Gli IP che condividono una sottorete potrebbero benissimo essere lo stesso utente
  2. mentre gli IP possono essere riutilizzati per vari endpoint effettivi, è relativamente improbabile che vedrai connessioni duplicate da un IP che non sono lo stesso utente o almeno la stessa famiglia / organizzazione (sostanzialmente, una connessione condivisa)
  3. non è banalmente facile per un utente ottenere un nuovo IP pubblico (c'è una barriera di medie dimensioni per entrare qui)

Con IPv6, puoi assumere tutto questo? Immagino perlomeno che il secondo punto non sia più vero dal momento che NAT'ing dovrebbe sostanzialmente sparire con IPv6 perché ci saranno abbastanza IP per chiunque ne voglia uno.

Se è in atto una serie di criteri basati su IP, quali considerazioni devono essere prese per IPv6 se presenti a causa delle differenze tra i due?

Risposte:


6

Con IPv6, non penso che ci sia una soluzione perfetta. Ma ci sono una serie di cose da considerare:

  • Gli ISP distribuiranno probabilmente /64subnet a singoli clienti. (Ci sarà abbastanza per andare in giro.)
  • I luoghi di lavoro ne avranno probabilmente almeno uno /64per ufficio.
  • Gli ISP che offrono collegamenti strettamente punto a punto possono scegliere l'uso per utilizzare i prefissi tra /64e /126. (Vedi perché non stanno usando / 127 in generale ) Probabilmente questo sarebbe un ISP miope o uno che vuole caricare di più per un pieno /64. Non c'è davvero alcun motivo per cui ciascun endpoint (che potrebbe essere una rete di clienti completa) non dovrebbe essere un /64.
  • Supponendo che la maggior parte delle sottoreti dell'utente finale IPv6 si troveranno su un /64, si potrebbe guardare al bit 6 nell'identificatore dell'interfaccia (vedere la sezione 3.2.1 di RFC 4941 ) per verificare se è stato probabilmente generato sulla base di un identificatore univoco globale (indirizzo MAC). Questo non è infallibile, ovviamente. Ma se questo bit è impostato, probabilmente indica che l'indirizzo è stato generato da un indirizzo MAC. Quindi si potrebbero bloccare gli indirizzi IPv6 in base agli ultimi 64 bit e gli utenti potrebbero essere bloccati indipendentemente dalla sottorete da cui provengono. (Forse è meglio usarlo come un "suggerimento" dato che gli indirizzi MAC, sebbene si supponga che siano globalmente unici, in pratica non lo sono sempre. Inoltre sono facilmente falsificati. Ma chiunque sia abbastanza esperto da andare nei guai probabilmente troverebbe più facile prendi a /64e ottieni comunque 2 ^ 64 indirizzi univoci).
  • Se gli indirizzi di privacy sono in uso ... non c'è molto da fare se non bloccare quell'indirizzo per un breve periodo. Probabilmente cambierà presto comunque. /64A questo punto, includi la parte della rete , ma fai attenzione perché potresti bloccare l'intero ufficio aziendale di qualcuno.

Direi che il modo migliore sarebbe quello di esaminare prima i singoli indirizzi, quindi tenere conto degli ultimi 64 bit dell'indirizzo e dei modelli di abuso da determinate /64sottoreti al fine di implementare una strategia di blocco. Riassumere:

  • Inizia bloccando i singoli /128indirizzi IP (come probabilmente fai oggi con IPv4)
  • Se noti un modello di abuso da un indirizzo non riservato negli ultimi 64 bit di un indirizzo, utilizzalo come indicatore forte nell'algoritmo di blocco. Qualcuno potrebbe passare da ISP o sottoreti. (di nuovo, stai attento con questo dato che i MAC non sono necessariamente unici - qualcuno potrebbe essere spoofing per sfruttare il tuo algoritmo) Inoltre, questo funzionerebbe solo contro gli utenti che non sanno come funziona IPv6. ;-)
  • Se noti un modello di abuso da parte di un particolare /64, blocca il tutto /64con un buon messaggio di errore in modo che l'amministratore della rete offensiva possa fare tutto il lavoro che deve essere fatto da solo.

In bocca al lupo.


2 ^ 64 = 18.446.744.073.709.552.000 indirizzi possibili. Perché mai gli utenti hanno bisogno di così tanti indirizzi?
TheLQ

@TheLQ, ovviamente no. Le reti degli utenti finali lo fanno, tuttavia, perché RFC 4291 richiede identificatori di interfaccia a 64 bit. Quindi gli ultimi 64 bit, almeno sulle reti Ethernet, saranno quasi occupati da un indirizzo EUI-64 - un MAC a 48 bit espanso a 64 bit. La maggior parte delle reti domestiche, piuttosto che un singolo indirizzo IP (statico o dinamico) avrà bisogno di una singola /64sottorete (statica o dinamica) per questo motivo, poiché non esiste un NAT in IPv6.
mpontillo,

Inoltre, come menzionato da qualcun altro, DHCPv6 potrebbe aiutare un po 'la situazione, ma potrebbe mettere a dura prova i router poiché dovresti instradare in base a tutti i 128 bit, anziché solo ai primi 64. Se instradi verso singoli indirizzi IP piuttosto che /64per cliente, ciò potrebbe far esplodere la tabella di routing a dimensioni irragionevoli e causare problemi a seconda dell'hardware utilizzato per il routing.
mpontillo,

Grazie, non avevo idea che gli IP fossero basati su indirizzi Mac e ho dimenticato che da qualche parte c'è una tabella di routing. Sembra che ho qualche lettura da fare
TheLQ

1
Le migliori pratiche attuali sembrano essere che l'incarico minimo per un cliente residenziale di un ISP sia un / 56. Naturalmente, la maggior parte dei clienti probabilmente non utilizzerà più di una o due / 64 sottoreti all'interno di tale blocco per un bel po ', se mai, ma l'uso è previsto.
Michael Hampton

3

I presupposti che elenchi:

Gli IP che condividono una sottorete potrebbero benissimo essere lo stesso utente

Continua a tenere duro: infatti se gli ISP stanno assegnando sottoreti IPv6 ai propri clienti diventa ancora più vero.


Mentre gli IP possono essere riutilizzati per vari endpoint effettivi, è relativamente improbabile che vedrai connessioni duplicate da un IP che non sono lo stesso utente o almeno la stessa famiglia / organizzazione (sostanzialmente, una connessione condivisa)

Continua a tenere (in realtà si applica all'intera sottorete come descritto sopra).


Non è banalmente facile per un utente ottenere un nuovo IP pubblico (c'è una barriera di medie dimensioni per entrare qui)

Non si applica molto a un singolo IP, ma si applica a una sottorete fornita da un ISP.


Quindi in sostanza stiamo esaminando i divieti di subnet in cui attualmente abbiamo divieti IP, supponendo che gli ISP distribuiscano subnet a tutti i loro utenti. Se invece gli utenti ottengono singoli indirizzi IPv6 (uno per utente), stiamo esaminando i singoli divieti IPv6, che potrebbero portare a una tabella di ban molto più lunga (e problemi di prestazioni associati) se ci sono molti utenti maleducati.
In entrambi i casi un divieto IP diventa uno strumento più granulare (cioè meno rischi di bloccare un gruppo di utenti da un ISP che ha un pool dinamico perché una persona si è comportata male), che a mio avviso è una buona cosa ...


1
Sarò sorpreso se le reti mobili distribuiranno interi / 64 a ciascun telefono. Otterranno sicuramente un IP da un pool dinamico. Se LTE decolla in grande stile, potremmo ancora finire per "bloccare più utenti da un ISP che ha un pool dinamico perché una persona si è comportata male".
Richard Gadsden,

2

Wikipedia / MediaWiki stanno adottando una politica di blocco di un intero / 64 quando bloccano il quinto IP all'interno di tale / 64.

Cinque sembrano essere la regola empirica standard che altri stanno adottando - la coppia di DNSBL che ho visto stanno adottando la stessa politica.

Non ho visto alcun piano per aggregare blocchi sopra a / 64, anche se ottenere un / 48 o un / 56 è abbastanza facile anche per un'organizzazione modesta. Naturalmente, gli spammer attualmente hanno spesso un / 24 (IPv4) o giù di lì, quindi mi aspetto che inizieranno a catturare grossi pezzi di spazio IPv6.


1

Gli IP che condividono una sottorete potrebbero benissimo essere lo stesso utente

Ancora vero, anzi ancora più vero con la v6.

mentre gli IP possono essere riutilizzati per vari endpoint effettivi, è relativamente improbabile che vedrai connessioni duplicate da un IP che non sono lo stesso utente o almeno la stessa famiglia / organizzazione (sostanzialmente, una connessione condivisa)

Probabilmente anche più vero con v6 che v4.

non è banalmente facile per un utente ottenere un nuovo IP pubblico (c'è una barriera di medie dimensioni per entrare qui)

Nella maggior parte dei casi, anziché nei singoli indirizzi, gli ISP distribuiranno blocchi di indirizzi. È facile per un cliente muoversi all'interno del proprio blocco. Più difficile (anche se tutt'altro che impossibile) per ottenere un nuovo blocco.

La parte più difficile è che le dimensioni di allocazione per i clienti variano notevolmente. Alcuni ISP distribuiscono singoli indirizzi, alcuni / 64 blocchi, alcuni / 56 blocchi, alcuni / 48 blocchi.

Ciò renderà difficile elaborare una politica di divieto / limitazione ragionevole che funzionerà per tutti gli ISP. È "hot" / 48 un singolo abusatore che ha trovato un ISP che ha distribuito blocchi di grandi dimensioni o è un grande gruppo di utenti su un provider mobile avaro che fornisce indirizzi individuali.

PS Rifiutarsi di implementare IPv6 non è in realtà una solitudine, poiché con l'esaurimento di IPv4 sempre più clienti saranno dietro una qualche forma di NAT a livello di ISP.


0

Penso che dipenderà molto da ciò che faranno gli ISP. Continueranno a fornire agli utenti IP dinamici reali? In caso contrario, o se ogni utente ottiene esclusivamente la propria ip / sottorete, gli IP inizieranno ad essere praticamente gli stessi di una targa.


La domanda dell'ISP si riduce a: "L'ISP desidera limitare il numero di unità che è possibile connettersi alla rete?" In caso contrario, la distribuzione di un / 64 a ciascuno e diversi sarà il percorso. Se sì, immagino che dominerà dhcpv6.
Bittrance,

1
Ho il sospetto che / 64 sarà dominante per la banda larga utente-casa - in effetti, molte delle implementazioni IPv6 sul CPE ("router") domestico suppongono che verrà loro assegnato un / 64. OTOH, i provider di telecomunicazioni mobili possono impedire il tethering distribuendo un singolo IP a ciascun dispositivo e un / 64 agli utenti che hanno pagato per il tethering.
Richard Gadsden,

0

Quando ho capito che IPv6 è stato destinato ad aumentare il numero di indirizzi IP un sacco , ma non aumentare il numero di porte per host, fossi prima perplesso. Dato che i computer stanno diventando sempre più potenti e diventano quindi più capaci di gestire un numero enorme di connessioni simultanee, essere limitati a un massimo di 65535 porte per indirizzo IPv6 sembrava "il prossimo collo di bottiglia".

Poi ci ho pensato ancora una volta e mi sono reso conto che era banale assegnare più IPv6 a un'interfaccia fisica e in quel modo aggirare quel limite del numero di porte che possono connettersi all'host. In realtà, vieni a pensarci bene, puoi assegnare abbastanza facilmente indirizzi IPv6 1024 o 4096 al tuo host e quindi distribuire casualmente i tuoi servizi su varie porte su tutti gli indirizzi, dando agli scanner delle porte un tempo abbastanza più difficile (almeno in teoria) .

Ora tendenze come la virtualizzazione degli host (più host virtuali più piccoli su un host fisico relativamente potente) e i dispositivi portatili (pensa che i dispositivi mobili connessi a IPv6 a tutti sul pianeta) probabilmente faranno parlare contro questo, la maggior parte degli host su Internet del futuro probabilmente utilizzerà abbastanza poche porte e quindi necessita di un solo indirizzo IPv6 per host.

(Ma la possibilità di "nascondersi" in un ampio pool di indirizzi IPv6, tutti i quali possiedi e dai quali puoi scegliere casualmente, fornisce comunque un livello di sicurezza, anche se ammesso che nella maggior parte dei casi è sottile)


1
E quando due computer avrebbero aperto 65536 connessioni simultanee tra loro, tranne in un test di carico artificiale?
Michael Hampton
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.