É possível usarpwnate SSH para estabelecer uma conexão SSH "ponto a ponto" entre duas máquinas que estão atrás de dois firewalls/NATs separados?
Se isso for possível, quais são as etapas necessárias para configurar essa funcionalidade em uma máquina Linux dentro de um NAT que esteja executando um servidor OpenSSH e como um cliente por trás de um NAT separado se conectaria?
Além disso, se isso for possível, esta configuração representa um grande risco de segurança? Algum cliente SSH arbitrário poderia se conectar ao servidor executando o pwnat?
Responder1
Sim.Suponha que sua rede seja assim:
Você deseja fazer SSH de A para B. Você tem o sshd rodando em B; ele está ouvindo em tcp://127.0.0.1:22.
B$ pwnat -s 0.0.0.0 2022 127.0.0.1:22
pwnat em B agora está escutando em udp://0.0.0.0:2022 e está configurado para permitir conexões com tcp://127.0.0.1:22. Ele também envia solicitações periódicas de eco ICMP para 3.3.3.3 (IP codificado).
A$ pwnat -c 127.0.0.1 3022 104.16.111.208 2022 127.0.0.1 22
pwnat em A agora está escutando em tcp://127.0.0.1:3022.
pwnat em A envia um pacote de tempo ICMP excedido para 104.16.111.208 cuja carga útil corresponde às solicitações de eco ICMP de saída provenientes do NAT B. NAT B vê que a carga corresponde às solicitações de eco ICMP de saída e encaminha o pacote de tempo ICMP excedido para B. Observe que o cabeçalho IP para o pacote de tempo ICMP excedido contém o IP do NAT A, 151.101.193.69, como endereço de origem.
pwnat em B envia um pacote UDP para udp://151.101.193.69:2022 com porta de origem 2022. NAT B adiciona uma entrada em sua tabela para que, no futuro, encaminhe quaisquer pacotes UDP que receber de udp://151.101.193.69 :2022 em udp://104.16.111.208:2022 para udp://192.168.2.10:2022.Observe que muitos NATs atribuirão uma porta diferente na interface externa. Se esse é o caso,pwnat não funciona.
pwnat em A envia um pacote UDP para udp://104.16.111.208:2022 com porta de origem 2022. NAT A adiciona uma entrada em sua tabela para que, no futuro, encaminhe quaisquer pacotes UDP que receber de udp://104.16.111.208 :2022 em udp://151.101.193.69:2022 para udp://192.168.1.10:2022.
NAT A recebe o pacote UDP que B enviou, combina-o em sua tabela e encaminha-o para A. NAT B recebe o pacote UDP que A enviou, combina-o em sua tabela e encaminha-o para B. A e B agora podem se comunicar livremente através de UDP.
A$ ssh -p 3022 127.0.0.1
pwnat em A, que está escutando em tcp://127.0.0.1:3022, aceita a conexão do ssh. pwnat em A envia uma solicitação para pwnat em B (via UDP) para abrir um túnel para tcp://127.0.0.1:22. Como este foi listado como um par host/porta permitido quando o pwnat em B foi iniciado, ele faz a conexão. O túnel agora está completo:
ssh on A --[tcp]--> pwnat on A --[udp]--> pwnat on B --[tcp]--> sshd on B
Se o pwnat não tiver bugs, então isso não será diferente em termos de segurança de expor o sshd ao mundo em um servidor que não está atrás de um NAT. No entanto, olhando o código-fonte, o pwnat parece meio hackeado e eu não confiaria que ele fosse seguro. O pior cenário seria a execução arbitrária de código em A e B como o usuário que está executando o pwnat.
Responder2
Pwnat parece não ser autenticado, o que considero um grande risco de segurança. Se você controla pelo menos um dos dois NAT/Firewalls, basta configurar o encaminhamento/tradução de porta para uma configuração muito mais segura.