¿Es un enrutador sin firewall de entrada un problema de seguridad en Internet?

Dado que los enrutadores entre los dispositivos de Dave y Alice no reenviarán los paquetes, no hay forma de hablar directamente con ellos, por lo que en cierto sentido están "seguros". No hay una forma directa de contactar a los dispositivos, a menos que puedas spearphish Mallory. Sin embargo, hay formas de molestarlos, que posiblemente pueden ser explotados por un atacante determinado.

Falsificar la IP de origen (para parecerse a uno de los dispositivos Alices) y enviar un paquete a un dispositivo que conoce y tiene acceso a los dispositivos de Alicia, como el enrutador de Alicia o la computadora de Mallory. de los dispositivos de Alice que les enviaron el paquete. Ya que conocen el camino de regreso, responderán en especie (dependiendo de qué servicios estén disponibles y cómo esté configurado el sistema operativo). Si los servicios están disponibles, esto permitiría el abuso como un ataque de amplificación (consulte Ampliación de DNS y NTP para obtener más información). ) hacia los dispositivos de Alicia, y probablemente hay otras formas posibles de entrometerse.

  

... un enrutador sin firewall ... usando MASQUERADE

El enmascaramiento no es una funcionalidad de enrutamiento porque cambia la fuente del paquete. En su lugar, realmente necesita un firewall con estado para hacer el enmascaramiento. Lo que significa que si se trata de un enmascaramiento, también debe tener un firewall allí. Por supuesto, esto no dice nada sobre la configuración del firewall, pero contradice la suposición de que tiene un enrutador sin firewall.

  

... ya que el enrutador de Alice estará felizmente hacia adelante

Como el enrutador / firewall está realizando MASQUERADE para el tráfico desde el interior (red privada de Alice) hacia el exterior (es decir, la red B y más), solo puede reenviar el tráfico desde el exterior hacia el interior para el cual existe una regla de NAT activa. Cualquier paquete desde el exterior para el cual no exista tal regla será descartado. Por lo tanto, no se realizará un reenvío feliz y no será posible ningún reenvío.

En teoría, es probable que pueda definir reglas en las que los paquetes de una subred específica no pasarán por el NAT, sino que irán directamente a la otra red, pero esta sería una configuración inusual no estándar.

La situación general eventualmente puede reducirse a un factor: si Dave puede encontrar una manera de transferir un paquete al enrutador de Alice (o red) con la dirección de destino de la PC de Alice en el encabezado de IP.

Usted mismo respondió que con el enrutamiento simple de la capa 3 de OSI esto no se puede hacer; cualquier host L3 intermedio eliminará este paquete. No hay forma de superar este comportamiento realizando cambios de origen / destino, agregando encabezados o realizando operaciones similares, mientras que el otro lado hace que el enrutamiento sea sencillo.

Pero para lograr cualquier orden o túnel deseado se puede usar, es decir, cuando un encabezado IP está oculto dentro del paquete y se usa otro encabezado IP durante el enrutamiento en hosts L3 intermedios. Aquí es necesario que el lado de Alice tenga alguna lógica de programación, que pueda descapsular este paquete.

• Para realizar algún tipo de tunelización con el enrutador de Alice directamente: Debe haber un servicio correspondiente ejecutándose en el propio enrutador, confiando El paquete de Dave.

  Si Dave lo encuentra y entiende cómo comprometerse (usando algo similar como: enlace ), entonces el acceso a la red local puede ser posible.

  Cualquiera de vulnerable o Se puede utilizar el servicio de tunelización mal configurado (sin autenticación): GRE, PPTP, L2TP, IPSec, EoIP, etc.

• De otra manera: si hay algún host comprometido que tenga conectividad L2 al enrutador de Alicia (por ejemplo, el host en la red B, la propia red de Alicia o cualquier otra red a la que esté vinculado el enrutador de Alice).

  Luego, el paquete destinado a la PC de Alice se puede enrutar a través de SSH (usando -L / -R / -D banderas, busque: enlace ) o cualquier otro túnel de servicio permitido (HTTP / DNS, incluso ICMP, etc.) a ese host.

  Los hosts L3 intermedios verán la dirección enmascarada del enrutador de Alice, Como se hizo la conexión del host comprometido al público de Dave la dirección, luego el paquete se descapsula por el host comprometido y se envía a Red 192.168.1.0/24 a través del enrutador de Alice como puerta de enlace.

  Dicho host puede ser un servidor web pirateado, un usuario que ejecute .exe desde fuentes no confiables, etc. Para lograr dicha funcionalidad, hay suficientes derechos de acceso, incluso limitados, en la máquina.