Por que bloquear a porta 22 de saída?

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?

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.

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.

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.

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.

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.

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.

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).

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.

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.

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 :)

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.

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.

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.

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.

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.

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.