¿Es posible utilizarpwnaty SSH para establecer una conexión SSH "peer-to-peer" entre dos máquinas que están detrás de dos firewalls/NAT separados?
Si esto es posible, ¿cuáles son los pasos que se deberían seguir para configurar esta funcionalidad en una máquina Linux dentro de una NAT que ejecuta un servidor OpenSSH y cómo se conectaría un cliente detrás de una NAT separada?
Además, si esto es posible, ¿esta configuración representa un riesgo importante para la seguridad? ¿Podría cualquier cliente SSH arbitrario conectarse al servidor que ejecuta pwnat?
Respuesta1
Sí.Supongamos que su red se ve así:
Quiere SSH de A a B. Tiene sshd ejecutándose en B; está escuchando en tcp://127.0.0.1:22.
B$ pwnat -s 0.0.0.0 2022 127.0.0.1:22
pwnat en B ahora está escuchando en udp://0.0.0.0:2022 y está configurado para permitir conexiones a tcp://127.0.0.1:22. También envía solicitudes de eco ICMP periódicas a 3.3.3.3 (IP codificada).
A$ pwnat -c 127.0.0.1 3022 104.16.111.208 2022 127.0.0.1 22
pwnat en A ahora está escuchando en tcp://127.0.0.1:3022.
pwnat en A envía un paquete de tiempo ICMP excedido a 104.16.111.208 cuya carga útil coincide con las solicitudes de eco ICMP salientes provenientes de NAT B. NAT B ve que la carga útil coincide con las solicitudes de eco ICMP salientes y reenvía el paquete de tiempo ICMP excedido a B. Tenga en cuenta que el encabezado IP para el paquete de tiempo ICMP excedido contiene la IP de NAT A, 151.101.193.69, como dirección de origen.
pwnat en B envía un paquete UDP a udp://151.101.193.69:2022 con el puerto de origen 2022. NAT B agrega una entrada en su tabla para que en el futuro reenvíe cualquier paquete UDP que reciba de udp://151.101.193.69 :2022 en udp://104.16.111.208:2022 a udp://192.168.2.10:2022.Tenga en cuenta que muchos NAT asignarán un puerto diferente en la interfaz externa. Si este es el caso,pwnat no funciona.
pwnat en A envía un paquete UDP a udp://104.16.111.208:2022 con el puerto de origen 2022. NAT A agrega una entrada en su tabla para que en el futuro reenvíe cualquier paquete UDP que reciba de udp://104.16.111.208 :2022 en udp://151.101.193.69:2022 a udp://192.168.1.10:2022.
NAT A recibe el paquete UDP que envió B, lo relaciona en su tabla y lo reenvía a A. NAT B recibe el paquete UDP que envió A, lo relaciona en su tabla y lo reenvía a B. A y B ahora pueden comunicarse libremente a través de UDP.
A$ ssh -p 3022 127.0.0.1
pwnat en A, que escucha en tcp://127.0.0.1:3022, acepta la conexión desde ssh. pwnat en A envía una solicitud a pwnat en B (a través de UDP) para abrir un túnel a tcp://127.0.0.1:22. Como esto figuraba como un par de host/puerto permitido cuando se inició pwnat en B, realiza la conexión. El túnel ya está completo:
ssh on A --[tcp]--> pwnat on A --[udp]--> pwnat on B --[tcp]--> sshd on B
Si pwnat no tiene errores, entonces esto no es diferente en términos de seguridad de exponer sshd al mundo en un servidor que no está detrás de una NAT. Sin embargo, al echar un vistazo al código fuente, pwnat parece algo pirateado y no confiaría en que sea seguro. El peor de los casos sería la ejecución de código arbitrario en A y B como el usuario que ejecuta pwnat.
Respuesta2
Pwnat parece no estar autenticado, lo que consideraría un riesgo de seguridad importante. Si controla al menos uno de los dos NAT/Firewalls, simplemente configure el reenvío/traducción de puertos para una configuración mucho más segura.