Riesgo de seguridad de permitir paquetes de ICMP "destino inalcanzable" en AWS

No hay implicaciones razonables para los usuarios de DSL con el bloqueo de los mensajes ICMP INBOUND (de cualquier tipo, realmente) para sus servicios alojados en una instancia de la nube de Amazon. La razón no tiene problemas para bloquearlos porque la infraestructura de Amazon fuera de su nube privada se encargará de eso ... después de todo, la MTU dentro de su nube privada no puede superar el mínimo MTU de la ruta de la ruta entre sus posibles clientes y sus servidores.

La única vez que se produzca una entrada ICMP inalcanzable para usted es si sus servidores intentan alcanzar una dirección de destino por algún motivo y un dispositivo en la ruta autorizada para enrutar a esa dirección de destino decide que no puede alcanzar eso. Si su servidor está respondiendo a un posible cliente y usted recibe un destino de ICMP inalcanzable, es probable que el "cliente" sea malicioso y esté falsificando su dirección de origen. Esto debería ser evidente, porque si se tratara de una dirección legítima que se te haya enviado, ¡es casi seguro que hay un camino de regreso!

Tenga cuidado con una política predeterminada de BLOQUEO-TODO en instancias de AWS. Puse un permiso-mi-gestión-IP explícito en SSH y bloqueé todo lo demás una vez, ¡y bloqueé mi instancia! Esto se debe a que hay ciertas comunicaciones relacionadas con DHCP y "Amazon" que su dispositivo debe admitir para poder comunicarse. Lo mismo es probable en una instancia de nube privada virtual.

Yo no estoy de acuerdo con la afirmación de munkeyoto de que " no hay riesgo " para permitir que los mensajes salientes de destino salgan. Principalmente por las razones esbozadas por Mark y Jim. Los atacantes usarán lo que usted les dé ... Si solo necesitan filtrar una contraseña, pueden hacerlo mediante el uso de indicadores y el uso de mayúsculas en los datos de los mensajes ICMP, por lo que solo algunos de estos mensajes serían necesarios (suponiendo que no usaron una explosión). enfoque de "todos los datos a la vez").

"ICMPTX" es un riesgo muy, muy pequeño en la mayoría de las situaciones del mundo real. Básicamente, es una forma de que dos programas que cooperan puedan pasar datos a través de un firewall que solo busca la exfiltración de datos a través de los protocolos tradicionales (TCP, UDP, etc.). A menos que su VPC de AWS esté infestada con malware y , su firewall está inspeccionando paquetes en busca de intentos de exfiltración de datos, no me preocuparía.

El "riesgo" general de hacer ping es preocuparse por que alguien use el protocolo icmp para eliminar datos o controlar malware. Creo que muchas veces se deshabilitó como "No sé por qué lo necesito, así que lo deshabilitaré". Es por esto que se convirtió en la regla por defecto. Si bien estas son preocupaciones válidas reales si todavía estás en la mentalidad de "Tengo un perímetro" (a diferencia de "Tengo seguridad de datos, entonces la identidad es mi perímetro"), esas mismas preocupaciones se aplican a cada Puerto / protocolo que puede entrar y salir. ICMP se activó en IPV4 porque, aunque era bueno tenerlo, no lo tenía en su mayoría solo para administradores de red molestos.

En IPV6, permitir ICMP no solo es el valor predeterminado, sino que también se requiere por varias razones, como la fragmentación que solo ocurre en la fuente (con icmp que envía un mensaje de tipo 2 al host), SLAAC y NDP también son mensajes ICMP.

No hay riesgo asociado con la desactivación de SALIDA DE SALIDA de los paquetes de destino inalcanzables. Veamos por qué: su máquina determina que no se puede alcanzar algo DESDE su máquina: "¿Cuál es el significado de lo que está bloqueando explícitamente ?" Cisco sugiere el bloqueo de destinos no disponibles, porque un atacante puede hacer que su máquina envíe repetidamente Mensajes que pueden abrumar a su equipo. Considera el siguiente ataque:

Attacker (2.3.4.5) --> (spoofs 8.8.8.8) --> your server (N amount of times)
Your server --> destination unreachable --> 8.8.8.8

En el lado SALIDA de la ecuación, ¿para qué sirve esta VPC? Por ejemplo, si la VPC tiene una conexión específica: Punto A < - > VPC qué diferencia hace si todo lo demás está bloqueado. Esto es algo que solo tú puedes responder. Todo comienza con lo que es el propósito de la VPC, quién y cómo necesita conectarse (hacia y desde).

En general, desea evitar la creación de demasiadas reglas, se vuelve complicado de manejar, por lo que una regla más apropiada sería algo como:

allow -- icmp messages (all) -- from.my.trusted.blocks
deny -- icmp messages -- all

Esto asegura que cualquier conexión que especifiques podrá recibir mensajes para una posible solución de problemas, mientras niega todo lo demás. Dos reglas versus docenas | cientos.