DDoS: ¿Un protocolo en el que la víctima dice "No me envíe tráfico durante N ms"?

Aunque esto suena como una buena idea en teoría, creo que hay algunas razones por las que esto aún no se ha implementado y no se implementará. En su mayoría tienen que ver con la complejidad y la escalabilidad:

Si cada enrutador en Internet necesita realizar un seguimiento de las solicitudes de cada host para acelerar el tráfico, esto resultaría en una base de datos muy grande que cada enrutador necesita actualizar y verificar cada paquete que se enruta. Esto tiene un impacto enorme en el rendimiento del enrutador.

Una segunda cosa a considerar es que este tipo de cosas solo funcionan si son ampliamente compatibles. Las soluciones que usted propuso son complejas, y antes de que se pueda encontrar un consenso en el IETF para definir estándares sobre cómo implementar esto (si es que se encuentra), habrá pasado mucho tiempo. Después de eso, aún pasa más tiempo antes de que una gran cantidad de enrutadores en Internet se hayan actualizado al software que ha implementado dicha función. En general, pueden pasar varios años antes de que dicha idea se convierta en un estándar implementado.

Otro problema es la confianza. Tendrá que proporcionar algún mecanismo para asegurarse de que el host o enrutador que afirma solicitar una regulación es el responsable de hospedar esa IP. Sin esto, el mecanismo podría ser utilizado como una herramienta para realizar un ataque DDoS, falsificando las solicitudes de aceleración para el objetivo, deteniendo así todo el tráfico hacia el host. Enrutamiento y confianza sigue siendo una combinación muy compleja. BGP, el protocolo de enrutamiento dinámico en el que se construye Internet, todavía se basa principalmente en la confianza, y cada vez más queda claro que hay muchas personas que operan redes en Internet en las que simplemente no se puede confiar. Soluciones como RPKI y BGPsec aún no están ampliamente implementadas. Agregar otro mecanismo basado en la confianza hará que las cosas solo sean más complicadas.

Y por último, pero no menos importante: no todos se benefician con el envío de paquetes por no . Si los paquetes están en cola, esto puede ser una carga para las redes a lo largo de la ruta. Pero incluso si ese no es el caso: muchas redes ganan dinero transportando paquetes, y transportar menos paquetes significa ganar menos dinero. Si una red tiene una relación directa con la red bajo ataque, puede considerar que es un servicio (posiblemente pagado), de lo contrario, podría estar reduciendo sus ingresos mediante la regulación. Por supuesto, muchas redes también enfocan el bien de Internet, pero pueden no hacerlo, y eso significaría que la idea no funcionará tan bien.

ICMP ya tiene un Código para "La comunicación con el host de destino está prohibida administrativamente" vea este documento como referencia el enrutador ascendente tendrá que aceptar esto y sus requisitos se cumplirán (en su mayoría).

Hay varias razones por las que esta solución no es suficiente, algunas ya están cubiertas en las respuestas. Sin embargo, el principal problema, especialmente con los ataques DoS modernos es el ancho de banda.

Originalmente, los ataques DoS eran principalmente sobre el envío de un número suficiente de solicitudes a un servidor para inundar la capacidad de los servidores para procesar las solicitudes. A menudo se trataba de un problema de recursos en el servidor, es decir, no había suficientes recursos de CPU o memoria. En muchos casos, solo un servicio se vería afectado. Por ejemplo, el servidor web puede parecer que no responde debido a demasiadas solicitudes, pero otro servicio podría todavía funciona.

Los Dos modernos, especialmente los ataques de tipo DDoS ahora son más sobre inundar la red. Usted recibe tanta información que su servidor de seguridad, enrutador y red interna se inundan. Parte de la razón por la que es tan devastador es que no puedes comunicarte de manera efectiva con otra cosa. No puede enviar un mensaje a un enrutador en sentido ascendente porque la conexión está inundada: los conmutadores, los cortafuegos y los enrutadores no responden. Incluso si sabe lo que quiere decirle al dispositivo / enrutador ascendente que debe hacer, no puede transmitir el mensaje.

Por esta razón, la solución a menudo involucra a su proveedor de servicios ascendente. O bien, necesita un canal de comunicación separado, que incluso podría ser una llamada telefónica, para que su proveedor realice alguna acción, como crear un "agujero negro" de BGP para la dirección IP de su red a la que se dirige. Este 'agujero negro' enviará todos los datos direccionados a su dirección IP interna a un agujero negro para que la cantidad de tráfico que llega a su red disminuya y ahora pueda enviar / recibir otros datos. El problema es que, si usa NAT o similar, de modo que realmente solo tiene 1 dirección pública, entonces el agujero negro significa que efectivamente se encuentra fuera de la red y el DoS ha tenido éxito. Por otro lado, si tiene varias direcciones IP públicas, puede tener suerte y solo sufrir una pérdida parcial del servicio.

El otro problema con su sugerencia es que para funcionar, debe ser rápido y ligero. Sin embargo, también debe ser seguro, de lo contrario, correría el riesgo de crear un nuevo vector DoS. por ejemplo, si usó un protocolo rápido y ligero sin conexión, podría ser demasiado fácil falsificar la dirección IP. Esto me permitiría enviar solicitudes a su enrutador ascendente pretendiendo ser usted solicitando que no se envíen datos. Por lo tanto, cualquier comando que afecte a los datos que se envíen debe ser seguro y verificable. Ahora tiene un comando que requiere más capacidad de procesamiento para procesarlo. más memoria y esto se multiplica a medida que avanza desde su enrutador local, a su enrutador ISP al enrutador de segmento, etc.

La señal que propongas tendría que llegar a un enrutador ascendente.

Su servidor no puede simplemente indicar al ISP que "no me envíe paquetes", porque nadie puede acceder a su servicio. (DoS exitoso)

Debes cortar el ataque lo más cerca posible de la fuente para limitar el número de usuarios legítimos bloqueados junto con el atacante.

Puedo imaginar un escenario en el que el operador del centro de datos utiliza la intervención humana o los scripts para determinar qué enrutadores señalar.

Me centraré en los ataques DDoS de Agotamiento de Ancho de Banda por un momento. Probablemente, estos solo pueden resolverse bloqueando el ataque en sentido ascendente.

Lamentablemente, es común que la dirección de origen sea falsificada. Entonces no puedes usar traceroute ...

Para que esto funcione, cada paquete tendría que tener un trazado de ruta propio. Esto es bastante costoso y tendría barreras de implementación.

_{Es posible que edite esto más adelante cuando tenga más tiempo.}