Por que bloquear a porta 22 de saída?


61

Sou programador e trabalhei para alguns clientes cujas redes bloqueiam conexões de saída na porta 22. Considerando que os programadores geralmente precisam usar a porta 22 para ssh, isso parece um procedimento contraproducente. Na melhor das hipóteses, força os programadores a cobrar da empresa a Internet 3G. Na pior das hipóteses, isso significa que eles não podem fazer seu trabalho efetivamente.

Dadas as dificuldades que isso cria, um administrador de sistemas experiente poderia explicar o benefício desejado para o que parece ser uma ação de perder ou perder?


11
Bloquear portas é apenas metade da batalha. Para concluir o ciclo, você precisa garantir que os serviços que você está tentando proteger não estejam sendo executados em portas não padrão.
Aharden

11
A pergunta realmente deveria ser "Por que bloquear a porta 22 de saída?" pois existem milhões de boas razões para você querer executar seu serviço ssh em uma porta não padrão. Saída ... nem tanto. Coloquei um +1 na resposta de Robert Moir, enquanto ele fazia um bom trabalho ao explicá-la.
KPWINC

@KPWINC, adicionou o esclarecimento ao título. Obrigado!
runako 14/06/09

3
Pense na porta 22 como uma caixa de pandora. Os administradores de rede não conseguem ver o que está no tráfego e, pior ainda, o ssh pode ser usado para contornar a segurança da rede, comprometendo a integridade da rede.
biosFF

11
@biosFF: Port 443.
Hello71

Respostas:


77

Não vejo que alguém tenha explicitado o risco específico com o encaminhamento de porta SSH em detalhes.

Se você estiver dentro de um firewall e tiver acesso SSH de saída a uma máquina na Internet pública, poderá fazer o SSH para esse sistema público e, nesse processo, criar um túnel para que as pessoas na Internet pública possam efetuar ssh para um sistema dentro da sua rede, completamente ignorando o firewall.

Se fred é sua área de trabalho e barney é um servidor importante em sua empresa e wilma é público, execute (em fred):

ssh -R *: 9000: barney: 22 wilma

e o login permitirá que um invasor faça ssh na porta 9000 no wilma e converse com o daemon SSH de barney.

Seu firewall nunca o vê como uma conexão de entrada porque os dados estão sendo transmitidos por uma conexão que foi originalmente estabelecida na direção de saída.

É irritante, mas uma política de segurança de rede completamente legítima.


11
Obrigado por uma resposta muito perspicaz. Essa é uma das poucas respostas que abordam os riscos técnicos (em oposição aos riscos políticos) das portas abertas de saída.
runako

6
+1 por fornecer uma boa razão técnica. (No entanto, isso só poderia ser feito por um estagiário malévolo, que também poderia usar outras portas que TCP 22 no host remoto com o qual estamos de volta a algum bloco de toda a política.)
DerMike

7
Com um protocolo personalizado e uma programação inteligente de proxy, isso pode ser feito através do HTTPS - embora mais lento. Contanto que você permita o tráfego criptografado de saída, você estará vulnerável a esse tipo de "ataque".
Michael Sondergaard 07/07

3
Essa é uma boa resposta do JamesF, mas não é um problema de segurança que vale a pena pensar, porque assume um cenário extremamente raro e requer exploração de servidores / clientes SSH. O usuário mal-intencionado precisa primeiro explorar o servidor SSH (na área de trabalho) e descobrir uma maneira de explorar seu cliente SSH (no host da empresa). Como você não pode usar a porta 22 para acessar ou falar com o host com firewall comercial (que possui apenas a porta de saída 22). Se o seu padrão de segurança for alto, o host da empresa nem deve estar na Internet em nenhuma situação.
Dexter

11
Você pode encapsular o tráfego pelo DNS (por exemplo, com iodine) se HTTPS e SSH estiverem indisponíveis. Mas é muito lento.
Mark K Cowan

38

Se eles estão bloqueando uma confusão de portas, deixando algumas coisas passarem e bloqueando outras coisas aleatoriamente (eu amo a triste história de Paul Tomblin sobre as pessoas que bloqueiam o SSH e permitiram o Telnet), então elas têm um caso muito estranho de como protegem o perímetro da rede ou as políticas de segurança são, pelo menos de fora, aparentemente mal pensadas. Você não pode entender situações como essa; portanto, basta cobrar a taxa de juros para as pessoas que sofrem e continuar seu dia.

Se eles estão bloqueando TODAS as portas, a menos que exista um caso comercial específico para permitir o tráfego por essa porta, quando é cuidadosamente gerenciado , eles o fazem porque são competentes em seus trabalhos.

Ao tentar escrever um aplicativo seguro, você facilita a leitura e a gravação de outros processos para ele, da maneira que preferir, ou você tem algumas APIs cuidadosamente documentadas que você espera que as pessoas liguem e que você limpa com cuidado?

Gerenciamento de riscos - se você acha que o tráfego de ou para a sua rede que entra na Internet é um risco, você procura minimizar a quantidade de maneiras pelas quais o tráfego pode acessar a Internet, tanto em termos de número de rotas quanto de métodos. Você pode monitorar e filtrar esses gateways e portas "abençoados" escolhidos para tentar garantir que o tráfego que passa por eles seja o que você espera.

Essa é uma política de firewall de "negação padrão" e geralmente é considerada uma boa idéia, com algumas ressalvas que abordarei. O que isso significa é que tudo está bloqueado, a menos que haja um motivo específico para desbloqueá-lo, e os benefícios do motivo superam os riscos.

Edit: Devo esclarecer, não estou falando apenas sobre os riscos de um protocolo ser permitido e outro bloqueado, estou falando sobre os riscos potenciais para o negócio de informações que podem fluir para dentro ou para fora da rede de forma descontrolada maneira.

Agora, as advertências e, possivelmente, um plano para liberar as coisas:

Pode ser irritante quando você está bloqueado para algo, que é a posição em que você se encontra com alguns de seus clientes. Com muita freqüência, as pessoas encarregadas do firewall acham que é seu dever dizer "Não", em vez de "Aqui estão os riscos, agora quais são os benefícios, vamos ver o que podemos fazer".

Se você falar com quem gerencia a segurança da rede para seus clientes, eles podem configurar algo para você. Se você conseguir identificar alguns sistemas específicos no final, precisará acessar e / ou garantir que se conectará apenas a partir de um endereço IP específico. Eles podem ser muito mais felizes em criar uma exceção de firewall para conexões SSH para essas condições específicas do que eles. seria apenas abrir conexões com toda a internet. Ou eles podem ter um recurso de VPN que você pode usar para fazer o túnel através do firewall.


3
+1 para Se eles estão bloqueando TODAS as portas, a menos que exista um caso comercial específico para permitir o tráfego por essa porta; nesse momento, eles são gerenciados com cuidado, e estão fazendo isso porque são competentes em seus trabalhos.
cop1152

-1 porque o ssh não pode ser monitorado pelo pessoal de segurança, mas o Telnet pode. O que quero dizer é que, embora existam políticas tolas de segurança de rede, caracterizar a política como "aleatória" e "whackjob" sem uma compreensão das necessidades reais dos negócios também é curta.
Pcapademic

2
Bem, você tem direito à sua opinião, é claro, Eric, e eu felizmente mudarei essas palavras, se você achar que são pejorativas, mas estou bastante confiante de que essa política seria mal pensada ou um caso muito incomum.
Rob Moir

+1 para "todas as portas"
Ian Boyd

18

Uma certa grande empresa em Rochester, NY, que costumava fazer muitos filmes bloqueou o ssh de saída quando eu trabalhava lá, mas permitia o telnet ! Quando perguntei sobre isso, eles disseram que o ssh era uma falha de segurança.

Em outras palavras, as empresas às vezes tomam decisões estúpidas e depois inventam desculpas idiotas sobre segurança, em vez de admitir seus erros.


6
TELNET é a brecha na segurança. Deve ser banido (isso é apenas para as pessoas tomarem melhores decisões estúpidas no futuro).
nik

3
Deixe-me elaborar aqui, o que é um furo de segurança é subjetivo à superfície que está sendo fixada. Se você é proprietário de um site, tentando se conectar ao seu servidor, o TELNET é um buraco. Se você é um funcionário da empresa financeira que está tentando se conectar externamente ao seu servidor doméstico (através de linhas sendo monitoradas pelo seu empregador), o SSH é a brecha de segurança para seus empregadores!
1412

11
Considerando como é fácil falsificar o telnet em ambas as direções, eu diria que o telnet é uma brecha de segurança, mesmo para a empresa que permite sua saída. Mas uma empresa que permite, mas não permite, o ssh não tomará decisões de segurança inteligentes em nenhum caso.
Paul Tomblin

3
Telnet é o presente que continua dando. Foi aprovado há 20 anos, mas agora eu realmente gostaria que isso parasse.
Rob Moir

2
Tudo depende do seu POV. Eles provavelmente tinham pessoas que precisavam acessar algum processo herdado via Telnet, cuja empresa é facilmente auditável. OTOH, você não tem idéia do que está acontecendo com o SSH, as pessoas podem estabelecer túneis para redes estrangeiras e fazer todo tipo de coisas idiotas. O Telnet não deve ser usado atualmente, mas qualquer um que permita o SSH de saída precisa buscar uma nova carreira.
duffbeer703

6

Compreendo o bloqueio da comunicação SSH de entrada se a empresa não permitir logins externos. Mas, é a primeira vez que ouço um bloco SSH de saída.

O que é importante observar é que esse firewall provavelmente limitará apenas o usuário SSH casual. Se alguém realmente quiser fazer o SSH fora (o que normalmente acontece em um servidor / máquina ao qual eles têm acesso significativo, fora da rede corporativa), poderá executar facilmente o servidor SSH em uma porta diferente da 22 (por exemplo, porta 80). O bloco será ignorado facilmente.

Existem também várias ferramentas de domínio público que permitirão que você saia da empresa por HTTP (porta 80 ou porta 443 HTTPS) e forneça proxies para permitir a conexão externa à porta 22.


Edit: Ok, espere um segundo, eu tenho uma idéia de por que isso poderia ser uma política.

Às vezes, as pessoas usam túneis SSH para ignorar firewalls de saída básicos para protocolos como IM e Bittorrent (por exemplo). Isso // pode // ter acionado essa política. No entanto, ainda sinto que a maioria dessas ferramentas de túnel seria capaz de trabalhar em portas diferentes das 22.

A única maneira de bloquear esses túneis de saída é detectando a comunicação SSH em tempo real e (dinamicamente) bloqueando essas conexões TCP.


3
A porta 443 é melhor, porque já se supõe que ela esteja criptografada, para que os proxies não fiquem chateados com dados estranhos. Você pode configurar facilmente um servidor ssh escutando na porta 443 e, a partir daí, pode ir a qualquer lugar.
bandi

11
Em um local em que trabalhei, um dos meus colegas de trabalho usou um programa que encapsulava todo o tráfego de rede em um túnel ssh através do nosso proxy da web para a porta 80 em seu computador doméstico e de lá para a Internet. Ele poderia usar qualquer protocolo que quisesse, mas parecia que ele vinha da casa dele e não da empresa. Felizmente, ele sabia o quanto os administradores da rede não tinham noção, para não correr o risco de ser pego.
Paul Tomblin

11
Obviamente, se você for pego tendo passado por uma dessas danças elaboradas para circunavegar o firewall, não poderá realmente alegar inocência e ignorância. Foi um pouco difícil fazer tudo isso e dizer "desculpe, chefe, 'funcionou', então eu não percebi que estava fazendo algo errado".
Rob Moir

4

Provavelmente é um problema de regulamentação / conformidade. Seu empregador deseja poder ler / arquivar todas as comunicações. Muitas vezes, isso é um requisito em setores como o bancário.


Isso não significa que eles também precisam bloquear o HTTPS?
runako

3
Não, eles habilitam a inspeção SSL. Esse processo descriptografa o HTTPS e, em seguida, criptografa novamente os pacotes de saída / saída injetando um certificado confiável em todas as estações de trabalho pela política de grupo. Dessa forma, eles podem filtrar / verificar o mesmo que com HTTP. O setor bancário é um dos ambientes mais draconianos para bloquear redes.
spoulson

4

Há duas razões principais para bloquear a porta de saída 22, na minha opinião.

Primeiro, como as pessoas mencionaram, o encaminhamento de porta SSH pode ser usado como proxy ou ignorar outras portas e serviços para evitar a política de TI afirmando que esse tráfego não é permitido.

Segundo, muitos malwares / redes de bots usarão a porta 22 porque geralmente é vista como "segura" e, portanto, permitida. Eles podem iniciar processos nessa porta e os computadores infectados também podem iniciar ataques de força bruta SSH.


3

Na maioria das vezes, é mais um caso de bloqueio de todas as conexões de saída, a menos que seja necessário, e até você tentar, ninguém solicitou que a porta 22 estivesse disponível para conexões de saída (apenas 80, 433 e assim por diante). Se for esse o caso, a solução pode ser tão simples quanto entrar em contato com o IS / IT e dizer a eles por que você precisa de uma exceção, para que sua estação possa fazer conexões SSH de saída com hosts específicos ou em geral.

Às vezes, é preocupante que as pessoas possam usar o recurso para usar o SSH como uma maneira de configurar proxies (via encaminhamento de porta pelo link) para contornar outros controles. Isso pode ser um fator muito importante em alguns setores regulamentados (bancos), onde toda a comunicação precisa ser monitorada / registrada por razões legais (desencorajar o uso de informações privilegiadas, detectar / bloquear a transferência de dados corporativos ou pessoais etc.) ou empresas onde existe é um grande medo de vazamentos internos revelando, acidentalmente ou não, segredos comerciais. Nesses casos, usar seu link 3G (ou outras técnicas, como tentar encapsular o SSH por meio de HTTP) para contornar as restrições pode ser uma violação do seu contrato e, portanto, uma ofensa de despedida (ou, provavelmente pior, uma ofensa legal), portanto, tenha cuidado para aceite sua ação antes de tentar.

Outro motivo pode ser reduzir a área de cobertura de saída (para serviços internos acessíveis aos hosts dentro dos firewalls da empresa e para o mundo em geral), caso algo indesejável consiga se instalar em uma máquina executada pela empresa. Se nenhuma conexão SSH for possível na porta 22, muitos hacks mais simples que tentam usar logins SSH de força bruta, pois uma de suas rotas de propagação serão bloqueados. Nesse caso, você poderá novamente solicitar a inclusão de uma exceção para que sua máquina possa fazer conexões SSH, se essas conexões puderem ser justificadas para as pessoas que controlam o (s) firewall (s).


Sim, é bem provável que todos os serviços de saída que ainda não precisam ser utilizados possam ter sido bloqueados (por padrão).
nik

Porém, bloquear o tcp / 22 não impedirá as comunicações de saída seguras (que podem ser feitas em qualquer porta, desde que o usuário tenha um ouvinte externo, o que não é difícil hoje em dia).
nik

Se a rede interna tiver uso para comunicação SSH, o bloqueio não funcionará e se não houver comunicação SSH necessária, normalmente também não haverá máquinas de escuta SSH vulneráveis ​​dentro da rede. E, a propagação típica de worm não tenta usar o SSH de força bruta (se você estiver preocupado com o assunto en.wikipedia.org/wiki/SSHBlock ), é mais provável que tente o tcp / 445 com as máquinas Windows.
nik

3

Seus clientes provavelmente possuem dados não triviais que gostariam de reter. O SSH de saída é uma coisa muito ruim de se abrir para uma rede inteira. É bastante trivial ignorar proxys, vazar dados confidenciais e ser geralmente desagradável.

Na IMO, qualquer coisa que passe pelo perímetro da rede / internet deve ser entendida e controlável. Se um grupo de desenvolvedores precisa acessar servidores em um provedor de hospedagem via ssh, tudo bem - mas também precisa ser documentado. Em geral, nos locais em que trabalhei, estabelecemos conexões VPN site a site dedicadas a locais fora da nossa rede (essencialmente estendendo nossa rede interna) e evitamos protocolos de clientes como o SSH pela Internet.


Obrigado pela resposta. Como você lida com VPNs dedicadas a sites fora do seu controle (por exemplo, EC2, hosts da Web etc.)? Esses fornecedores normalmente estão dispostos a fazer essa configuração personalizada para você ou geralmente precisam fazer um grande compromisso mínimo em termos de negócios para que eles façam isso?
runako

2
Além disso, você se preocupa em forçar as pessoas a usarem cartões 3G fora da rede para realizar seu trabalho? Na minha experiência, redes bloqueadas inevitavelmente levam a muitos cartões 3G e outras formas de contornar ocultos, porque as pessoas não conseguem realizar seus trabalhos no tempo previsto, se tiverem que esperar pela TI para aprovar seu uso, se alguém souber quem ligar para obter uma exceção. (Um caso flagrante incluía um servidor de correio que não aceitava anexos recebidos da Internet. Caramba!) Gostaria de saber como você gerencia esse saldo.
runako

11
Adicione o comentário sobre o encaminhamento de porta pelo ssh e acho que esta é a resposta correta para a pergunta. O ssh pode ser um bom protocolo para permitir através de um servidor proxy. Os administradores podem monitorar o que está acontecendo, bloquear o encaminhamento de portas e as pessoas podem usá-lo para serviços de shell e cópia remota.
Pcapademic

Somos grandes o suficiente para que provavelmente 90% de nossos serviços não exijam a administração de saída para serem executados. Normalmente, quando fazemos isso, fazemos de um túnel VPN dedicado um requisito em uma RFP, o que tende a eliminar fornecedores que não o fornecem ou não podem fornecê-lo. Por isso, acredito que temos um número mínimo de pessoas usando 3G e soluções alternativas.
duffbeer703

Além disso, você não pode permitir que o pessoal de segurança dite o acesso. Você permite que o pessoal do suporte a aplicativos e da rede elabore uma solução aceitável, sujeita a revisão de segurança. Elabore a solução no início do processo, não na manhã em que você precisa entrar em produção. Isso mantém você longe dos atrasos no estilo DMV na obtenção de solicitações.
duffbeer703

2

Porque o SSH pode ser usado como uma VPN. Ele é criptografado para que os administradores de rede não tenham idéia do que está saindo da rede (despejo do banco de dados do cliente etc.). Acabei de cobrir essas coisas na minha coluna mensal "Secret Tunnels" . O custo de uma Internet 3G é muito menor do que se preocupar com protocolos criptografados que canalizam seus dados para fora da rede. Além disso, se você bloquear a porta de saída 22 e inspecionar o tráfego, poderá encontrar facilmente o SSH em portas não padrão e, assim, encontrar pessoas que violam a política de segurança.


Obrigado pela compreensão. Parece que você não consideraria o 3G um túnel secreto. Você poderia esclarecer por que faz mais sentido ter pessoas totalmente fora da rede ao se comunicar com a Internet? Parece que você prefere dispositivos não autorizados ainda menos do que um 22 aberto para saída.
runako

11
"... você pode encontrar facilmente SSH em portas não padrão ..." Sério? Gosta de procurar negociação SSL / TLS em portas diferentes da 443? Muito curioso.
Dscoduc

Sim, você pode detectar o tráfego ssh, Google: snort / ssh / detecção / conteúdo / regras, não sei sobre outros IDSs, mas se o Snort conseguir fazer isso, eles terão que ser muito presos para não fazer isso também.
Kurt

1

Conheço algumas pessoas que abusam dos recursos do SSH para instalar um proxy SOCKS através do SSH, contornando algumas restrições do site.

Ou mesmo um simples encaminhamento de porta ( ssh -L ....), se a porta estiver realmente bloqueada por causa das restrições do site, eu iria para:

  • o administrador local e
  • seu gerente de projeto

leve-os a uma mesa e deixe-os elaborar o motivo pelo qual isso está bloqueado. É claro que você precisa ter boas razões para acessar uma porta SSH externa para desenvolver um produto interno (ser interno: por que você precisa acessar boxA.example.com quando trabalha para uma empresa snakeoil.invalid)

Mas ainda estou para ver uma empresa bloqueando o SSH de saída :)


Eu vi uma empresa que bloqueia o SSH de saída. Eles também bloquearam quase tudo e, por exemplo, o vírus verificou todas as transferências HTTP usando um proxy. A empresa era um depositário central de valores mobiliários.
Esko Luontola 14/06/09

Eu trabalho para uma empresa como essa. Felizmente, o SSH pode ser encapsulado em https. Obviamente, eles permitem apenas https na porta 443 ... sslh para o resgate!
Mikeage

ProxyTunnel FTW :)
serverhorror

1

As respostas óbvias foram todas declaradas. É um protocolo criptografado que pode ser usado para burlar políticas através da criação de túneis (essa é uma ótima maneira de superar os filtros corporativos da web), bem como a ameaça representada por canais de comunicação não autorizados (proxy reverso).

É verdade, o telnet deve ser destruído em qualquer rede moderna. Mas, posso ver permitindo a saída do telnet da rede e banindo o ssh. O Telnet é menos capaz que o ssh e sempre posso monitorar o fluxo, em tempo real, através dos meus sniffers. Se eu não tenho nenhum dispositivo telnet na minha rede principal e algum usuário deseja fazer a telnet, o que eu me importo. Eu posso vê-lo e verificar se não é uma ameaça.

Obviamente, tudo isso depende da ideia de que a política padrão é bloquear todas as saídas e permitir apenas protocolos específicos. Pontos de bônus se você os estiver proxying antes de atingir o limite.


0

Não é o caso de bloquear especificamente a porta 22 porque os administradores têm algo contra o SSH, mas apenas abrir as portas que eles sabem que precisam abrir. Se o seu administrador não foi informado de que o SSH é necessário, ele será bloqueado pelo mesmo princípio que se aplica à desativação de serviços não utilizados em um servidor.


0

Claramente, é fácil contornar um bloco TCP / 22 de saída, a menos que os administradores da rede tenham empreendido esforços sérios e sérios para bloquear o tráfego SSH em específico . Além disso, os administradores de ativos precisam estar preparados para executar inventários de ativos suficientes para capturar modems 3G e endereços IP suspeitos nas 2ª NICs. Como temos o serviço ClearWire em nossa área, temos ainda o WiMax como uma opção de execução final em torno da segurança da nossa rede.

Não somos uma instituição preocupada principalmente com o vazamento de informações. Mas, se estivéssemos, precisaríamos combinar uma política de segurança de rede draconiana com uma política de ativos draconiana, com auditoria. Que eu saiba, não acho que exista um pacote de segurança pronto para uso que desligue a tomada de rede de um ativo inventário com algum tipo de conexão de rede externa. Isso pode estar chegando.

Na ausência de tal pacote, o processo de inventário de ativos é uma das melhores maneiras de capturar uma conexão de rede de execução final como 3G ou WiMax.

E, finalmente, o bloqueio cego do TCP / 22 bloqueará apenas o menor número de usuários finais que pretendem violar o AUP para sua rede de trabalho.


Você pode personalizar relatórios com algo como o SCCM para obter essas informações. Onde trabalho, usar um laptop pessoal ou uma placa WAN para ignorar a segurança da rede está sujeito a ação disciplinar.
duffbeer703

0

Eu vi 22 bloqueados quando descobriram que as pessoas estavam direcionando o tráfego http através dos 22. Foi uma barreira para aqueles que precisavam, mas a organização manteve sua posição.


0

A maioria das organizações maiores estará bloqueando tudo e permitindo apenas o acesso HTTP / HTTPS através de um servidor proxy.

Eu ficaria muito surpreso ao saber de qualquer empresa que permita conexões externas diretas de desktops ou servidores, a menos que haja uma necessidade específica.


0

Nada impede você de executar o sshd remoto na porta 80. Ambos, ssh e sshd, têm a opção -p para definir a porta.

Obviamente, se seus administradores são espertos, devem observar o tráfego ssh, não apenas o tráfego da porta 22. Portanto, parece que você tem um problema de política, não um problema de tecnologia.

Como outros salientaram, os protocolos criptografados podem causar azia nas pessoas que precisam se preocupar com diversos problemas de conformidade.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.