Actualmente estoy acostumbrado a usar herramientas como fail2ban para mantener el tráfico no deseado lejos de mis servidores al prohibir las direcciones IPv4: demasiadas entradas de registro incorrectas por IP, prohíban la IP.
Sin embargo, cuando el mundo complete la migración a IPv6, la prohibición de direcciones individuales probablemente ya no funcionará, ya que una computadora o atacante "normal" botnet posee muchas direcciones IPv6.
Si quiero bloquear a los usuarios de IPv6, ¿cuál sería la mejor manera de lograr esto? ¿Usar una determinada máscara de IP u otra cosa?
¿Qué tal hacer "heurística de escalamiento" cuando obtienes múltiples visitas individuales dentro de IPv6 y luego bloqueas todo el bloque?
Para mí es más importante mitigar la amenaza. Si algunos usuarios genuinos pobres pertenecen al mismo bloque con direcciones IP bloqueadas, entonces es un problema entre esas personas y su ISP que se elimine ese bloqueo de red.
/64
debido a una IP problemática causará el bloqueo de usuarios legítimos.Cualquier respuesta a su pregunta implicará una cierta cantidad de conjeturas. Las implementaciones de IPv6 todavía son lo suficientemente pocas como para que simplemente no sepamos aún cómo será exactamente el escenario de amenaza.
La gran cantidad de direcciones IPv6 introducirá múltiples cambios en el escenario de amenaza que deberá tener en cuenta.
En primer lugar, con IPv4 es completamente factible que un atacante escanee el número de puerto predeterminado en busca de algún servicio vulnerable en los 3700 millones de direcciones IPv4 enrutables. Tales ataques no dirigidos no son factibles con IPv6. Esos ataques que todavía ves tendrán que ser más selectivos. Queda por ver si esto significa que tendremos que cambiar mucho en nuestro manejo de los ataques.
El propósito principal de prohibir las IP basadas en mensajes de registro sería reducir el ruido en los registros y, en cierta medida, reducir la carga del sistema. No debería servir como protección contra las hazañas. Un atacante que conozca una debilidad estaría dentro antes de que la prohibición entrara en acción, por lo que para protegerse de eso debe corregir las vulnerabilidades, como siempre lo ha hecho.
La prohibición de direcciones IPv6 individuales podría ser suficiente para reducir el ruido en los registros. Pero eso no es un hecho. No es improbable que un atacante pueda usar una nueva dirección IP del rango disponible para cada conexión. Si los atacantes se comportaran de esa manera, la prohibición de direcciones IPv6 individuales no solo será ineficaz, sino que incluso puede causar un ataque DoS sin darse cuenta al usar toda su memoria para las reglas del firewall.
No puede saber la longitud del prefijo disponible para cada atacante individual. El bloqueo de un prefijo demasiado corto causará un ataque DoS al cubrir también a los usuarios legítimos. El bloqueo de un prefijo demasiado largo será ineficaz. Es probable que los intentos de contraseña de fuerza bruta en particular utilicen una gran cantidad de direcciones IPv6 de clientes.
Para ser efectivo contra los atacantes que cambian la dirección IPv6 en cada solicitud y para mantener bajo el uso de memoria, debe bloquear los rangos y, debido a que no conoce las longitudes de los prefijos de antemano, debe ajustar las longitudes de los prefijos dinámicamente.
Es posible proponer heurísticas ya ahora. Aún no sabemos qué tan bien funcionarán.
Una heurística sería que cada longitud de prefijo defina un umbral de cuántas IP se necesitan para bloquear un prefijo de esa longitud. Y el bloqueo solo debe aplicarse a una longitud específica, si un prefijo más largo no fuera suficiente. En otras palabras, necesita suficientes direcciones IP bloqueadas individualmente en cada una de las dos partes para iniciar realmente un bloqueo.
Por ejemplo, uno podría decidir que para bloquear un / 48, debe haber 100 IP bloqueadas en cada uno de los dos / 49 que componen el / 48. Cuanto más largo sea el prefijo, menor será el número de IP necesarias para bloquearlo, pero en todos los casos tendrían que distribuirse en ambas partes.
fuente
Debe ceñirse a la prohibición de direcciones individuales.
No se define cuántas direcciones se darán a los usuarios finales. Algunos ISP pueden proporcionar una subred completa y otros solo una dirección.
fuente