Rejeitar conexões ssh feitas de proxies

Question

Eu estava vendo esta questão que estava preocupada em bloquear o acesso aos usuários que não pertencem a uma região em particular. Tenho certeza de que o bloqueio é possível, mas vejo que há uma solução para isso.

1. Eu faço o login no proxy da região de aqui .
2. Eu dou este URL como o site a visitar.
3. Agora, estou no proxy da região e consigo fazer login no servidor também.

Existe uma maneira de rejeitar essas tentativas contornadas no iptables ? Eu vejo isso como uma preocupação de segurança bastante perigosa.

    

Answer 1

Essa pergunta parece muito confusa, mas acho que a confusão é parte da questão, então tentarei fornecer informações suficientes para esclarecer as coisas.

HTTP e SSH são protocolos diferentes. O HTTP é falado por clientes HTTP (chamados de navegadores da web) e servidores HTTP (chamados de servidores da web). O SSH é falado por clientes SSH e servidores SSH. O protocolo HTTP tem uma noção de proxy, em que um nó de rede recebe solicitações de HTTP de um cliente e as encaminha para um servidor e encaminha a resposta de volta do servidor para o cliente. O SSH não possui proxies no sentido técnico; no entanto, uma máquina que permite que pessoas que não estão usando fisicamente para usar um cliente SSH esteja agindo como um proxy no sentido geral do termo em inglês.

O

link lista os proxies HTTP. Eles não são úteis para fazer conexões SSH.

O

link é uma máquina que executa um cliente SSH que é acionado a partir de uma interface da Web de acesso público. Se você usar um navegador da web para conectar-se ao serfish e executar o cliente SSH lá, então, no que diz respeito ao servidor SSH, sua conexão vem do serfish, ponto final. Não há como o servidor SSH saber que o cliente SSH está sendo conduzido por alguém que não está fisicamente localizado no datacenter em que o serfish está hospedado. Note que não importa se você está acessando o serfish diretamente via HTTP ou via um proxy HTTP; o servidor SSH não tem como saber nada sobre isso.

Em geral, um servidor só pode saber sobre o último salto usado para se conectar a ele. Isso é uma preocupação de segurança? Sim, mas dificilmente perigoso. Conexões de filtragem por origem geográfica não podem ser feitas confiáveis; qualquer administrador de sistema moderadamente competente sabe disso. A origem geográfica pode dar uma pista sobre se uma conexão é suspeita, mas não pode ser o único fator. Existem máquinas infectadas por malware e usadas como retransmissões em todo o mundo.

A segurança do SSH não depende da origem geográfica das conexões. A filtragem por origem geográfica é feita apenas para dois propósitos:

• Para a distribuição de conteúdo, restringir o que os 95% não técnicos do público podem fazer (definir proxies exige pesquisa mais profunda do que a maioria das pessoas deseja) e tornar as coisas um pouco mais inconvenientes para os 5% técnicos ( proxies precisam ser pagos ou procurados e reduzir o desempenho).
• Como uma sugestão de que uma conexão com uma conta vem de um local incomum, mas isso geralmente é feito em um nível mais refinado do que um país, que é muito amplo para fornecer uma dica muito útil. Alguns sistemas usam isso para decidir se exigem um segundo fator de autenticação.

O outro lado de não conseguir rastrear a origem final de uma conexão SSH (ou qualquer outra) é que alguma privacidade é possível.

    

Answer 2

Portanto, isso pode ser feito ao usar o HTTP procurando cabeçalhos específicos do cliente, como:

HTTP_CLIENT_IP
HTTP_X_FORWARDED_FOR
HTTP_FORWARDED_FOR
HTTP_FORWARDED

Mas o AFAIK, cabeçalhos e técnicas semelhantes não existem para o SSH.

Existem listas negras de proxy que podem ser úteis, mas isso não é uma solução segura.