Escaneando una subred externamente

Sí, no necesita NAT, enmascaramiento o incluso enrutamiento (pero al menos necesita un proxy HTTP).

Esta herramienta utiliza websockets y solicitudes de ajax, pero es posible hacerlo solo con URL de img. Un simple applet de Java identificará e informará la dirección IP local si no desea escanear muchas direcciones.

Generalmente, estas redes están detrás de Traducción de direcciones de red (NAT) . NAT espera que un sistema interno envíe un paquete a una dirección WAN y luego almacena la ruta en una tabla. Altera el paquete para que tenga la dirección IP de WAN del enrutador como la dirección de origen y lo envía a Internet. Cuando la respuesta regresa, hace coincidir el paquete entrante con una ruta. Esto es especialmente fácil de demostrar con TCP, donde una conexión tiene un número de secuencia que puede usarse para hacer coincidir los paquetes con la conversación.

El problema con el acceso a los puertos internos es que si un paquete no coincide explícitamente con una ruta que el enrutador conoce, se descarta. Tenga en cuenta que las reglas de reenvío de puertos crean sus propias rutas, por lo que el enrutador sabe que debe enrutar los paquetes TCP / UDP entrantes a una IP interna particular. Como tal, es bastante difícil enumerar las IP internas de Internet, y mucho menos realizar escaneos de puertos.

La única forma que conozco para hacer esto es explotar el enrutador. Algunos de ellos han configurado mal los demonios UPnP, lo que le permite engañar al enrutador para que configure las reglas de reenvío de puertos. Hay otras formas de hacerlo, generalmente a través del panel de control del enrutador.

Aaron "finux" Finnon ( @ f1nux en Twitter ) hizo una gran charla sobre cómo utilizar UPnP en BSidesLondon a principios de este año: enlace

Tan pronto como la dirección sea accesible desde su red, sí, puede escanear puertos desde una red remota. Por supuesto, los equipos entre usted y su máquina objetivo (firewalls, especialmente) influirán en los resultados.

Si la dirección IP de destino no es enrutable en Internet, entonces puede o no ser posible realizar una exploración en algunos puertos. Todo depende de la configuración del servidor NAT (y el firewall) entre la LAN de destino e Internet.

Hay sitios web especializados (como éste ) para esto si no tiene una máquina de origen en una red remota. Por supuesto, para realizar una exploración de este tipo, debe tener una autorización del administrador / propietario del sistema de destino, si no es usted.

Respuesta corta: No.

Respuesta larga: posiblemente. Depende.

Los enrutadores NAT funcionan al monitorear el tráfico saliente y al crear reglas sobre la marcha para enviar el tráfico entrante a donde debe ir.

Por ejemplo:

1. La máquina interna (192.168.1.2) abre la conexión TCP (envía un TCP SYN) a una máquina externa: 13.37.10.20, puerto 80. La conexión está vinculada al puerto 54321 en la máquina interna.
2. El enrutador NAT ve una nueva conexión TCP saliente, desde 192.168.1.2:54321 hasta 13.37.10.20:80, almacena el número de secuencia TCP y crea una regla que indica que cualquier tráfico entrante de 13.37.10.20:80 con el siguiente número de secuencia debe enrutarse a 192.168.1.2:54321 en la subred local.
3. La máquina externa devuelve el paquete TCP con el conjunto de indicadores SYN + ACK, con su propio número de secuencia. El enrutador NAT ve que coincide con la regla anterior y la enruta a 192.168.1.2:54321, almacenando el número de secuencia. Ahora permite que los paquetes se envíen en ambas direcciones, siempre que la IP, el puerto y los números de secuencia coincidan con los valores de la regla.
4. Los datos se intercambian a través de la conexión TCP.
5. Un lado envía un FIN, el enrutador permite que el otro lado envíe y ACK y luego descarta la regla. La máquina externa no puede enviar más tráfico porque el enrutador NAT ya no tiene esa regla de reenvío.

El enrutador NAT elimina todo el resto del tráfico entrante.

En algunos casos, las máquinas en la red interna deben poder aceptar paquetes entrantes de la red externa, sin saber nada sobre la máquina externa de antemano. Por ejemplo, podría configurar un servidor web en 192.168.1.2:80, pero quiero que sea accesible desde la red externa. Esto se ve facilitado por el reenvío de puertos.

El reenvío de puertos agrega una regla permanente a las reglas de reenvío de NAT, de manera que el tráfico de todas las direcciones IP (o una lista preestablecida de) a un puerto específico se envía a una dirección IP interna. En el caso anterior, podría decir que cualquier cosa que llegue a mi enrutador en el puerto TCP 80 debe reenviarse a 192.168.1.2:80.

Esto no ofrece una vulnerabilidad en sí misma, pero conduce a una. Una gran cantidad de juegos y software de comunicaciones (por ejemplo, mensajería instantánea, VoIP, etc.) requieren que se acepten conexiones entrantes. Debido a que la mayoría de los consumidores no saben cómo configurar su enrutador, y se convierte en una molestia para ingresar manualmente las reglas de reenvío de puertos cada vez que instala un nuevo juego / programa, los enrutadores necesitan una API que permita la configuración automática de estas reglas. La API más popular para esto es UPnP (Universal Plug-n-Play).

UPnP permite que un programa le indique al enrutador que agregue una regla de reenvío de puerto UPnP. La mayoría de los enrutadores especifican algunas restricciones sobre esto, por ejemplo, tiempo máximo para que exista una regla antes de que el programa necesite renovarla, pero en general es bastante laxa.

La API funciona a través de HTTP, por lo que es relativamente fácil de implementar en la mayoría de los idiomas. Tampoco requiere ninguna autenticación más allá de "Tengo una dirección IP interna", lo que significa que AJAX entre sitios, HTML5 sockets e incluso iframes creados dentro de un navegador pueden tener la capacidad de configurar reglas de reenvío de puertos. Por lo general, esto requiere un error en la política del mismo origen del navegador, pero ciertamente es posible que un atacante aproveche esto para crear reglas de reenvío de puertos arbitrarias. Estos podrían ser utilizados para la huella digital de su red interna. También podrían usar sockets web para tomar huellas dactilares de su red interna directamente, haciendo que visite una página web. Por supuesto, la exploración se interrumpiría cuando cerrara la página. La respuesta de Symcbean muestra un ejemplo práctico de esto.

El otro problema es que UPnP a veces se implementa en el enrutador de forma bastante descuidada. Ciertos enrutadores permiten hacer cosas locas a través de UPnP sin autenticación, por ejemplo. apagar wifi, restablecer el dispositivo a la configuración de fábrica, parpadeo del firmware. Incluso encontré un enrutador que le indicaría el SSID y la contraseña de wifi en texto sin cifrar si enviaba una determinada solicitud UPnP. De hecho, en algunos casos, los enrutadores también permiten el acceso "limitado" a UPnP desde el lado orientado a Internet. Es una práctica de seguridad extraña y terrible.

Debes examinar una técnica llamada Firewalking , el documento original , y otro documento .

Parece que las herramientas 0trace y intrace están relacionados.

Sí, pero solo si tiene un puerto hacia adelante (DNAT; D = destino), que expondrá un puerto (y por lo tanto servicio si algo está escuchando) en uno de los hosts internos (en una configuración simple). Para escanear su red interna, el atacante necesitaría establecer de alguna manera una conexión a su red interna a través de servicios expuestos (VPN, SSH) o incluso un servidor web u otros servicios, si existe una vulnerabilidad.

Suponiendo que tiene una dirección IP pública, con una subred privada 192.168.xx que utiliza NAT dinámica para traducir las direcciones IP privadas a la dirección IP pública, no hay forma de que un atacante realice una exploración de puertos / vulnerabilidades de su Subred privada desde internet.