¿Cómo se ven afectadas las reglas basadas en IP (p. Ej., Prohibiciones / filtros) una vez que IPv6 se convierte en el estándar?


13

Dado que los sitios de Stack Exchange prohíben la IP , me pregunto si existe una opinión o estrategia común sobre la creación de reglas basadas en la IP de un usuario para dictar comportamientos.

Con IPv4, tiene algunas cosas que puede asumir de manera bastante confiable sobre una IP determinada:

  1. Las IP que comparten una subred podrían ser el mismo usuario
  2. Si bien las IP se pueden reutilizar para varios puntos finales reales, es relativamente poco probable que vea conexiones duplicadas de una IP que no sea el mismo usuario, o al menos el mismo hogar / organización (básicamente, una conexión compartida)
  3. No es trivialmente fácil para un usuario obtener una nueva IP pública (hay una barrera de entrada de tamaño mediano aquí)

Con IPv6, ¿puedes asumir todo esto? Me imagino que, al menos, el segundo punto ya no sería cierto ya que se supone que NAT'ing desaparecerá esencialmente con IPv6 porque habrá suficientes IP para cualquiera que quiera uno.

Si tiene un conjunto de políticas basadas en IP, ¿qué consideraciones se deben tomar para IPv6 si las hay debido a las diferencias en los dos?

Respuestas:


6

Con IPv6, no creo que haya una solución perfecta. Pero hay una serie de cosas a considerar:

  • Los ISP probablemente distribuirán /64subredes a clientes individuales. (Habrá suficiente para todos).
  • Los lugares de trabajo probablemente tendrán al menos uno /64por oficina.
  • Los ISP que ofrecen enlaces estrictamente punto a punto pueden elegir usar para usar prefijos entre /64y /126. (Vea por qué no están usando / 127 en general ) Probablemente sea un ISP miope o uno que quiera cobrar más por un total /64. Realmente no hay razón para que cada punto final (que podría ser una red completa de clientes) no deba ser un /64.
  • Suponiendo que la mayoría de las subredes de usuarios finales de IPv6 estarán en un /64, se podría mirar el bit 6 en el identificador de interfaz (consulte la sección 3.2.1 de RFC 4941 ) para verificar si probablemente se generó en función de un identificador único global (dirección MAC). Esto no es infalible, obviamente. Pero si se establece este bit, probablemente indica que la dirección se generó a partir de una dirección MAC. Por lo tanto, uno podría bloquear las direcciones IPv6 basadas en los últimos 64 bits, y los usuarios podrían ser bloqueados sin importar de qué subred provengan. (Tal vez sea mejor usar esto como una "pista" ya que las direcciones MAC, aunque se supone que son globalmente únicas, en la práctica no siempre son fáciles. Además, son fáciles de suplantar. Pero cualquier persona lo suficientemente inteligente como para meterse en problemas probablemente le resulte más fácil agarra ay /64obtén 2 ^ 64 direcciones únicas de todos modos.)
  • Si las direcciones de privacidad están en uso ... no hay mucho que hacer, excepto bloquear esa dirección por un corto tiempo. Es probable que cambie pronto de todos modos. Tenga en cuenta la parte de la red /64en este momento, pero tenga cuidado ya que podría estar bloqueando toda la oficina corporativa de alguien.

Diría que la mejor manera sería mirar primero las direcciones individuales, luego tener en cuenta los últimos 64 bits de la dirección y los patrones de abuso de /64subredes particulares para implementar una estrategia de bloqueo. Para resumir:

  • Comience por bloquear /128direcciones IP individuales (como probablemente haga hoy con IPv4)
  • Si observa un patrón de abuso de una dirección que no es de privacidad en los últimos 64 bits de una dirección, úselo como un indicador fuerte en su algoritmo de bloqueo. Alguien podría estar saltando entre ISP o subredes. (una vez más, tenga cuidado con esto, ya que los MAC no son necesariamente únicos; alguien podría estar engañando para explotar su algoritmo) Además, esto solo funcionaría contra los abusadores que no saben cómo funciona IPv6. ;-)
  • Si observa un patrón de abuso por parte de un particular /64, bloquee todo /64con un buen mensaje de error para que el administrador de la red infractora pueda hacer cualquier trabajo que deba hacerse por su parte.

Buena suerte.


2 ^ 64 = 18,446,744,073,709,552,000 posibles direcciones. ¿Por qué los usuarios necesitan tantas direcciones?
TheLQ

@TheLQ, no lo hacen, obviamente. Sin embargo, las redes de usuarios finales lo hacen porque RFC 4291 requiere identificadores de interfaz de 64 bits. Por lo tanto, los últimos 64 bits, al menos en las redes Ethernet, casi serán ocupados por una dirección EUI-64 , un MAC de 48 bits expandido a 64 bits. La mayoría de las redes domésticas, en lugar de una sola dirección IP (estática o dinámica) necesitarán una /64subred única (estática o dinámica) por este motivo, ya que no hay NAT en IPv6.
mpontillo

Además, como alguien más mencionó, DHCPv6 podría ayudar un poco a la situación, pero posiblemente pondría a prueba los enrutadores, ya que tendría que enrutar en función de los 128 bits, en lugar de solo los primeros 64. Si enruta a direcciones IP individuales en lugar de /64por cliente, eso podría explotar su tabla de enrutamiento a un tamaño irrazonable y causar problemas dependiendo del hardware que se utilice para el enrutamiento.
mpontillo

Gracias, no tenía idea de que las IP se basaban en direcciones Mac y olvidé que en algún lugar hay una tabla de enrutamiento. Parece que tengo algo que leer
TheLQ

1
La mejor práctica actual parece ser que la asignación mínima para un cliente residencial de un ISP sea de / 56. Por supuesto, la mayoría de los clientes probablemente no usarán más de una o dos / 64 subredes dentro de un bloque de este tipo durante un tiempo, si es que lo hacen, pero el uso está previsto.
Michael Hampton

3

Los supuestos que enumeras:

Las IP que comparten una subred podrían ser el mismo usuario

Continúa reteniéndose; de ​​hecho, si los ISP asignan subredes IPv6 a sus clientes, esto se vuelve aún más cierto.


Si bien las IP se pueden reutilizar para varios puntos finales reales, es relativamente poco probable que vea conexiones duplicadas de una IP que no sea el mismo usuario, o al menos el mismo hogar / organización (básicamente, una conexión compartida)

Continúa reteniéndose (de hecho, se aplica a toda la subred como se describió anteriormente).


No es trivialmente fácil para un usuario obtener una nueva IP pública (hay una barrera de entrada de tamaño mediano aquí)

No se aplica tanto a una IP individual, pero se aplica a una subred entregada por un ISP.


Básicamente, estamos buscando prohibiciones de subredes donde actualmente tenemos prohibiciones de IP, suponiendo que los ISP entreguen subredes a todos sus usuarios. Si, en cambio, los usuarios obtienen direcciones IPv6 individuales (una por usuario), entonces estamos viendo prohibiciones individuales de IPv6, lo que puede conducir a una tabla de prohibición mucho más larga (y problemas de rendimiento asociados) si hay muchos usuarios con mal comportamiento.
En cualquier caso, una prohibición de IP se convierte en una herramienta más granular (es decir, menos riesgo de bloquear a un grupo de usuarios de un ISP que tiene un grupo dinámico porque una persona se portó mal), lo que en mi opinión es algo bueno ...


1
Me sorprendería si las redes móviles distribuyen enteras / 64s a cada teléfono. Seguramente obtendrán una IP de un grupo dinámico. Si LTE despega a lo grande, aún podríamos terminar "bloqueando a múltiples usuarios de un ISP que tiene un grupo dinámico porque una persona se portó mal".
Richard Gadsden

2

Wikipedia / MediaWiki están adoptando una política de bloqueo de un conjunto / 64 cuando bloquean la quinta IP dentro de ese / 64.

Cinco parece ser la regla general estándar que otros están adoptando: los dos DNSBL que he visto están adoptando la misma política.

No he visto ningún plan para agregar bloques por encima de un / 64, aunque obtener un / 48 o un / 56 es bastante fácil incluso para una organización modesta. Por supuesto, los spammers actualmente a menudo tienen un / 24 (IPv4) más o menos, por lo que espero que comiencen a tomar grandes porciones de espacio IPv6.


1

Las IP que comparten una subred podrían ser el mismo usuario

Sigue siendo cierto, de hecho aún más cierto con v6.

Si bien las IP se pueden reutilizar para varios puntos finales reales, es relativamente poco probable que vea conexiones duplicadas de una IP que no sea el mismo usuario, o al menos el mismo hogar / organización (básicamente, una conexión compartida)

Probablemente aún más cierto con v6 que v4.

No es trivialmente fácil para un usuario obtener una nueva IP pública (hay una barrera de entrada de tamaño mediano aquí)

En la mayoría de los casos, en lugar de direcciones individuales, los ISP distribuirán bloques de direcciones. Es fácil para un cliente moverse dentro de su bloque. Más difícil (aunque lejos de ser imposible) obtener un nuevo bloque.

Lo más difícil es que los tamaños de asignación a los clientes varían enormemente. Algunos ISP distribuyen direcciones individuales, algunos bloques / 64, algunos bloques / 56, algunos bloques / 48.

Esto dificultará la idea de una política sensata de prohibición / limitación que funcione para todos los ISP. ¿Es eso "caliente" / 48 un solo abusador que encontró un ISP que dio grandes bloques o es un gran grupo de usuarios en un proveedor móvil tacaño que da direcciones individuales.

PS Rehusarse a implementar IPv6 no es realmente una solución, ya que con el agotamiento de IPv4 cada vez más clientes estarán detrás de alguna forma de nivel de ISP NAT.


0

Creo que dependerá en gran medida de lo que hagan los ISP. ¿Continuarán proporcionando IP dinámicas reales a los usuarios? Si no, o si cada usuario obtiene su propia IP / subred exclusivamente, las IP comenzarán a ser más o menos lo mismo que una placa de matrícula.


La pregunta del ISP se reduce a: "¿El ISP desea limitar la cantidad de unidades que puede conectar a la red?" Si no, entregar la ruta a / 64 a cada uno será la ruta. Si es así, me imagino que dhcpv6 dominará.
Bittrance

1
Sospecho que / 64 será dominante para la banda ancha de usuario doméstico; de hecho, muchas de las implementaciones de IPv6 en el CPE doméstico ("enrutadores") suponen que recibirán un / 64. OTOH, los proveedores de telecomunicaciones móviles pueden evitar la vinculación entregando una sola IP a cada dispositivo y un / 64 a los usuarios que han pagado por la vinculación.
Richard Gadsden

0

Cuando comprendí que IPv6 se va a aumentar el número de direcciones IP de una gran cantidad , pero no aumentar el número de puertos por host, yo quedamos sorprendidos por primera vez. Teniendo en cuenta que las computadoras son cada vez más potentes y por lo tanto ser más capaces de dar servicio a un gran cantidad de conexiones simultáneas, estar limitado a un máximo de 65535 puertos por dirección IPv6 parecía "el próximo cuello de botella".

Luego lo pensé una vez más y me di cuenta de que era trivial asignar múltiples IPv6 a una interfaz física y así eludir ese límite del número de puertos que pueden conectarse al host. En realidad, ahora que lo pienso, puede asignar con bastante facilidad 1024 o 4096 direcciones IPv6 a su host y luego distribuir aleatoriamente sus servicios en varios puertos en todas las direcciones, dando a los escáneres de puertos un tiempo bastante difícil (al menos en teoría) .

Ahora, las tendencias como la virtualización de host (múltiples hosts virtuales más pequeños en un host físico relativamente potente) y dispositivos de mano (piense que los móviles conectados a IPv6 para todos en el planeta) probablemente hablen en contra de esto, la mayoría de los hosts en el futuro de Internet probablemente usarán bastante pocos puertos y, por lo tanto, solo necesitan una única dirección IPv6 por host.

(Pero la capacidad de "esconderse" en un gran grupo de direcciones IPv6, de las cuales es propietario y puede elegir al azar, aún proporciona cierta capa de seguridad, incluso si se admite que es delgada en la mayoría de las circunstancias)


1
¿Y cuándo abrirían dos computadoras 65536 conexiones simultáneas entre sí, excepto en una prueba de carga artificial?
Michael Hampton
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.