inverta o túnel ssh sobre o stunnel (ou apenas inverta de volta a conexão do stunnel)

Question

Estou criando uma "caixa de depósito" de segurança que pode ser implantada por trás do nat ou de qualquer firewall, chamar um servidor controlado publicamente e iniciar o controle do servidor.

Eu sei que isso é feito facilmente com um comando ssh -R, no entanto, estou procurando por algo que efetivamente evite o IDS / IPS sobre o SSL / TLS e a porta 443 adequados.

Atualmente, minha configuração que está funcionando (somente SSL) tem minha caixa de depósito (vamos chamar isso de cliente) chamando e iniciando uma conexão stunnel com o servidor. Eu posso então ssh manualmente do cliente para o servidor.

Isso é bom e ótimo, no entanto, eu preciso ser capaz de enviar o ssh do servidor para o cliente através do stunnel estabelecido.

Perguntas:

1. Posso apenas usar o ssh diretamente do servidor pela conexão stunnel existente (stunnel iniciado pelo cliente). Isso pode exigir uma mudança na configuração do stunnel, estou um pouco perdida com o que eu deveria mudar.
2. Posso reverter o túnel SSH do stunnel do cliente para o servidor, para que o servidor tenha uma porta local para o ssh voltar para o cliente? Em caso afirmativo, não consegui fazer com que o comando ssh -R funcionasse corretamente, pois acho que acabei criando um loop.

Abaixo estão as minhas configurações stunnel:

Servidor:

cert=/path/to/cert.pem
pid=/tmp/stunnel.pid
[ssh]
accept = 443
connect = 127.0.0.1:22

Cliente:

cert=/path/to/cert.pem
pid=/tmp/stunnel.pid
client=yes
[ssh]
accept=2200
connect=<serverpubip>:443

Exemplo de comando SSH para tentar e reverter de cliente para servidor através da conexão stunnel:

ssh -i /path/to/cert -R 2200:localhost:2200 -p 2200 admin@localhost -f -N

Lembre-se de que os requisitos são de que apenas o cliente pode chamar o servidor para iniciar a conexão inicial (stunnel) e o tráfego deve ser sobre criptografia SSL / TLS bem formada. Eu também preciso ganhar acesso ao shell do servidor até o cliente. Obrigado antecipadamente!

Atualização:

Acabou sendo um mau comando ssh. O comando ssh que funcionou para mim é:

ssh -i /path/to/cert -R 2201:localhost:22 -p 2200 admin@localhost -f -N

    

Answer 1

Acho que tudo o que é necessário é alterar -R 2200:localhost:2200 para -R 2200:localhost:22 em seu comando ssh.

Como está, você está conectando a porta 2200 no servidor de volta à porta 2200 no cliente. E sim, isso cria um loop de encaminhamento desde que o cliente: 2200 é encapsulado de volta ao servidor.

Supondo que o ssh no cliente esteja sendo executado na porta 22, o -R 2200:localhost:22 conectará a porta 2200 no servidor ao ssh no cliente.

Para ajudar a tornar isso um pouco mais claro, sugiro que você escolha um número de porta diferente para reverter o túnel do servidor: digamos, -R 2201:localhost:22 . Dessa forma, você não está usando a porta 2200 em ambos os hosts, o que ajudará a evitar que você confunda as duas portas.

    

Answer 2

Seu objetivo com suas ferramentas reais não pode ser alcançado, porque

1. stunnel não consegue fazer este recurso de conexão de retorno,
2. ssh não funciona como um daemon e possui um protocolo um pouco diferente do https. Bastantes IDSs inteligentes serão capazes de detectar isso.

O que você precisou fazer:

1. Como sugerido pelo @NilsToedtmann, você deve usar algum tipo de coisa complicada, pelo menos um OpenVPN. O lado do cliente do openvpn deve ser executado dentro. Preste atenção para as configurações de timeout / keepalive! Você tinha que fazer o menor tráfego aéreo possível.
2. O tráfego do OpenVPN difere perigosamente dos https normais, mas existe uma ferramenta chamada obfsproxy com essa você pode incorporar o tráfego do OpenVPN em um fluxo de dados de aparência mais amigável. Esta ferramenta é parte do projeto tor, mas também pode ser usada independentemente (e foi desenvolvida originalmente contra o grande firewall chinês).
3. Se houver algum tipo de firewall corporativo na imagem, você pode usar o cntlm para fazer com que esse visual pareça um IE8 < em> e torná-lo compatível com os proxies corporativos autenticados pelo kerberos .
4. No lado do servidor, há uma ferramenta, que pode ser muito útil, e seu nome é sslh . Permite-lhe multiplexar o seu tráfego openvpn / ssh por https com o serviço https normal.

Portanto, a conexão de dados real não é tão simples quanto você deseja, mas você pode alcançar o que deseja. Se você usar todas essas tecnologias, ela poderá resistir até mesmo a uma verificação de segurança de rede inteligente.

    

Answer 3

Por que não instalar um medidor de resistência reverse_http (s) persistente na "caixa de depósito"? Eu acho que esta é a maneira mais fácil de adquirir um shell reverso sobre http (s).