Ir al contenido principal
Recientemente me encontré con un sitio con varios módulos, cada uno de los cuales estaba reenviando paquetes. El peor de los casos era a un ritmo de 1 cada 2 segundos más o menos. No es muy rápido, pero hay 86.400 segundos en un día, así que en un día ese módulo podría estar reenviando 63 megabytes (86.400 / 2 * 1472)1 de datos fuera de su red desde un servidor "seguro" o transfiriendo 63 megabytes de herramientas de hacking a su red segura.

 

Sin embargo, en la mayoría de los casos el envío de paquetes es un indicio de un problema de configuración, no una violación de la seguridad. Por ejemplo, supongamos que un módulo tiene 2 interfaces IP
enet1 10.1.1.1 255.255.0.0
enet2 192.168.1.1 255.255.255.0
asumamos también que el router por defecto es 192.168.1.254

 

Todos los hosts de la primera red deberían tener una dirección IP de la forma 10.1.X.Y con una máscara de subred de 255.255.0.0 pero, ¿qué pasa si el servidor_17 con la dirección IP 10.1.1.17 está configurado para usar una máscara de subred con más bits, digamos 255.255.255.0? Todavía puede comunicarse con cualquier host con una dirección IP de la forma 10.1.1.X por lo que puede no notar un problema. Pero cuando envía un paquete de difusión IP, dirige ese paquete IP a 10.1.1.255 en lugar de a 10.1.255.255. La trama Ethernet que encapsula ese paquete tiene como destino la dirección de difusión Ethernet, de modo que el controlador Ethernet del módulo lee la trama y pasa el paquete al controlador IP. El controlador IP mira la dirección IP y determina que no está dirigida a enet1 o enet2 y no es 10.1.255.255, la dirección de difusión. Si el reenvío está activado, el controlador IP intentará reenviar el paquete al host con la dirección IP de 10.1.1.255. Si el módulo no tiene una entrada para 10.1.1.255 en su caché ARP, transmitirá una petición ARP. Si obtiene una respuesta (o ya tiene una entrada) reenviará el paquete a 10.1.1.255. Si no obtiene respuesta, eliminará la trama. El módulo también puede enviar un mensaje de redireccionamiento de enrutamiento ICMP indicando que el "router" es la dirección IP del host.

 

¿Qué pasa si el servidor_17 usa una máscara de subred con menos bits, digamos 255.0.0.0? En este caso la dirección de difusión IP que utiliza es 10.255.255.255. El controlador de IP decide que esta no es una dirección en una red a la que está conectado y reenvía el paquete al enrutador por defecto 192.168.1.254. No sólo se desperdician los recursos del módulo sino también los del enrutador. El mismo escenario se presenta si tienes dos subredes en el mismo dominio de transmisión.

 

Por último, volvamos a la cuestión de la seguridad. Asumamos que el servidor seguro_S, tiene una dirección IP de 10.1.1.100 y la máscara de subred correcta de 255.255.0.0. No hay enrutadores en la red 10.1.0.0 así que ¿cómo puede la espía industrial Eve enviar datos del servidor_S a su empleador en Internet en 5.6.7.8? Simple, ella sólo configura una ruta de host en el server_S para que cualquier paquete dirigido a 5.6.7.8 sea enviado a 10.1.1.1. Eso es todo lo que se necesita. El módulo reenviará los paquetes al enrutador por defecto y asumiendo que el filtrado de la dirección IP no es hecho por el enrutador por defecto reenviará los paquetes al siguiente enrutador, etc. hasta que lleguen a 5.6.7.8. No hay manera de que 5.6.7.8 responda de nuevo a 10.1.1.100 pero eso está bien para Eve, ella tiene otras maneras de confirmar que los datos están llegando a su empleador.

 

¿Cómo puede saber si su módulo está reenviando paquetes, o al menos está configurado para reenviar paquetes? La salida de "netstat -statistics" le mostrará todo lo que necesita.

 

netstat -statistics
. . .
ip:
. . .
1   ipforwarding (ON)
. . .
3117   ipForwDatagrams
. . .

 

Si el módulo está configurado para reenviar paquetes el ipforwarding será 1 y la etiqueta será sufijada con (ON). Si el módulo está realmente reenviando paquetes de ipForwDatagrams El contador se incrementará. Tenga en cuenta que el contador se incrementa incluso si el paquete no se transmite realmente porque no hay una entrada de caché ARP.

 

Para desactivar el reenvío de IP ejecute el comando ">system>stcp>command_library>IP_forwarding off", sí la IP está en mayúsculas.
En este punto netstat - las estadísticas mostrarán el ipforwarding variable para tener un valor de 2 y la etiqueta será sufijada con (OFF). Tenga en cuenta que la ipForwDatagrams no se reajusta; seguirá mostrando un valor positivo. Desafortunadamente, no hay forma de borrar el valor.

 

netstat -statistics
. . .
ip:
. . .
2   ipforwarding (OFF)
. . .
3117   ipForwDatagrams
. . .

 

Una última palabra de precaución; si el reenvío está activado y lo apagas y alguien (que no sea Eve) está usando el módulo como un enrutador, romperás lo que sea que estén haciendo. En mi opinión esto no es algo malo, STCP no fue diseñado para ser un router, pero prepárate para algunas quejas.

 

————-
Notas
1.1472 es el número máximo de bytes que se pueden poner en un paquete de eco ICMP transmitido por Ethernet