Por que bloquear a porta 22 de saída?

Question

Sou um 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 o ssh, isso parece um procedimento contraproducente. Na melhor das hipóteses, isso força os programadores a cobrar a empresa pela Internet 3G. Na pior das hipóteses, isso significa que eles não podem fazer seu trabalho de forma eficaz.

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

    

Answer 1

Não vejo que alguém tenha especificado 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, você poderá acessar o SSH nesse sistema público e, no processo, criar um túnel para que as pessoas na Internet pública possam acessar um sistema dentro de seu computador. rede, ignorando completamente o firewall.

Se o fred for o seu desktop e o barney for um servidor importante na sua empresa e o wilma for público, em execução (no fred):

ssh -R *: 9000: barney: 22 wilma

e o login permitirá que um atacante ssh carregue a porta 9000 no wilma e fale com o daemon SSH do barney.

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

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

    

Answer 2

Se eles estão bloqueando uma mistura de portas, deixando algumas coisas acontecerem e bloqueando algumas outras coisas aleatoriamente (eu amo o triste conto de Paul Tomblin sobre as pessoas que bloqueiam o SSH e permitiram o Telnet) então eles têm um caso muito estranho como eles protegem seu perímetro de rede, ou suas políticas de segurança, pelo menos de fora, aparentemente mal pensadas. Você não pode dar sentido a situações como essa, então apenas cobra a taxa de pessoas que sentem dor e continuam o seu dia.

Se eles estiverem bloqueando TODAS as portas , a menos que exista um caso específico de negócios para permitir o tráfego por essa porta, quando eles são cuidadosamente gerenciados , pois eles são competentes em seus trabalhos .

Quando você está tentando criar um aplicativo seguro, facilita que outros processos leiam e gravem informações como quiserem ou você tem algumas APIs cuidadosamente documentadas que você espera que as pessoas chamem e que você desinfete com cuidado?

Gerenciamento de riscos - se você achar que o tráfego de sua rede para a Internet é um risco, procure minimizar a quantidade de maneiras pelas quais o tráfego pode alcançar 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 esperado.

Essa é uma política de firewall de "negação padrão" e geralmente é considerada uma boa ideia, com algumas ressalvas que eu vou fazer. O que significa é que tudo está bloqueado a menos que haja uma razão específica para desbloqueá-lo, e os benefícios da razão superam os riscos.

Editar: 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 maneira descontrolada.

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

Pode ser irritante quando você está bloqueado de algo, que é a posição em que você se encontra com alguns de seus clientes. Com demasiada frequência, as pessoas encarregadas do firewall pensam que o seu trabalho é 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ê conversar com quem gerencia a segurança de rede para seus clientes, eles podem se adaptar à criação de algo para você. Se você puder identificar alguns sistemas específicos no seu final, você precisa acessar e / ou garantir que você se conectará apenas a partir de um endereço IP específico, eles podem ficar muito felizes em criar uma exceção de firewall para conexões SSH para essas condições específicas. seria apenas abrir conexões para toda a Internet. Ou eles podem ter um recurso de VPN que você pode usar para fazer um túnel através do firewall.

    

Answer 3

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

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

    

Answer 4

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

O que é importante notar é que esse firewall provavelmente limitará apenas o usuário casual do SSH. Se alguém realmente deseja SSH fora (o que normalmente será para um servidor / máquina que eles têm acesso significativo, fora da rede da empresa), eles podem facilmente executar o servidor SSH em uma porta diferente de 22 (por exemplo, porta 80). O bloco será ignorado facilmente.

Existem também várias ferramentas de domínio público que permitem sair da empresa via HTTP (porta 80 ou porta HTTPS 443) e fornecer proxies para permitir a conexão à porta 22 externa.

Editar: Ok, espere um segundo, tenho uma ideia de por que isso pode 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 tal política. No entanto, ainda sinto que a maioria dessas ferramentas de encapsulamento poderia funcionar em portas diferentes de 22.

A única maneira pela qual esses túneis de saída podem ser bloqueados é detectando a comunicação SSH rapidamente e (dinamicamente) bloqueando essas conexões TCP.

    

Answer 5

É provavelmente um problema de regulamentação / conformidade. Seu empregador quer poder ler / arquivar toda a comunicação. Isso é muitas vezes uma exigência em setores como o bancário.

    

Answer 6

Existem dois motivos 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 um proxy ou ignorar outras portas e serviços para evitar que a política de TI afirme que esse tráfego não é permitido.

Em segundo lugar, muitos malwares / botnets usarão a porta 22 porque ela é geralmente vista como "segura" e, portanto, permitida. Eles podem, então, lançar processos nessa porta e os computadores infectados também podem iniciar ataques de força bruta de SSH.

    

Answer 7

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

Às vezes, é preocupante que as pessoas usem o recurso para usar o SSH como uma forma de configurar proxies (por meio do encaminhamento de porta pelo link) para contornar outros controles. Esse pode ser um fator muito importante em alguns setores regulamentados (bancos) onde toda a comunicação precisa ser monitorada / registrada por motivos legais (desencorajando informações privilegiadas, detectando / bloqueando a transferência de dados corporativos ou pessoais, etc.) ou empresas onde há É um grande receio de vazamentos internos, revelando, acidentalmente ou não, segredos comerciais. Nesses casos, usar o seu link 3G (ou outras técnicas como tentar tunelar o SSH através do HTTP) para contornar as restrições pode ser uma violação do seu contrato e, portanto, uma ofensa de saque (ou, provavelmente pior, uma ofensa legal), então tome cuidado. acerte sua ação antes de tentar.

Outro motivo poderia ser reduzir o footprint de saída (para serviços internos acessíveis aos hosts dentro dos firewalls da empresa e para o mundo em geral) se algo desagradável conseguir se instalar em uma máquina executada pela empresa. Se não forem possíveis conexões SSH na porta 22, muitos hacks mais simples que tentam usar logins SSH de força bruta como uma de suas rotas de propagação serão bloqueados. Nesse caso, você poderá solicitar que uma exceção seja adicionada 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 (es).

    

Answer 8

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.

IMO, qualquer coisa que passar pelo perímetro da rede / internet deve ser entendida e controlada. Se um grupo de desenvolvedores precisar acessar os 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 de site para site dedicadas a locais fora de nossa rede (essencialmente estendendo nossa rede interna) e evitamos protocolos de cliente como o SSH pela Internet.

    

Answer 9

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á deixando a rede (despejo do banco de dados do cliente, etc.). Acabei de abordar essas coisas na minha coluna mensal "Túneis secretos" . O custo de alguma internet 3G é muito menor do que ter que se preocupar com protocolos criptografados que canalizam seus dados para fora da rede. Além disso, se a porta de saída 22 do bloco padrão e o tráfego inspecionarem, você poderá encontrar facilmente o SSH em portas não padrão e, assim, encontrar pessoas que violem a política de segurança.

    

Answer 10

Eu conheço algumas pessoas que abusam das capacidades do SSH para instalar um proxy SOCKS através do SSH, contornando assim algumas restrições do site.

Ou até mesmo um encaminhamento de porta simples ( ssh -L .... ), se a porta estiver realmente bloqueada devido a restrições de site, eu diria:

• o administrador local e
• seu gerente de projeto

leve-os a uma mesa e deixe-os explicar por que isso está bloqueado. É claro que você precisa ter bons motivos para ter acesso a 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:)

    

Answer 11

As respostas óbvias foram todas declaradas. É um protocolo criptografado que pode ser usado para burlar a política por meio 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 que o telnet deve ser destruído em qualquer rede moderna. Mas, eu posso ver permitindo telnet fora da rede enquanto banindo ssh. O Telnet é menos capaz do que o ssh e eu sempre posso monitorar o fluxo, em tempo real, através dos meus sniffers. Se eu não tiver nenhum dispositivo telnet na minha rede principal e algum usuário quiser fazer o telnet, o que me importa. Eu posso ver isso e verificar se não é uma ameaça.

Claro, tudo isso depende da idéia de que a política padrão é bloquear todas as saídas e permitir apenas protocolos específicos. Pontos de bônus se você estiver fazendo proxy deles antes de atingir a borda.

    

Answer 12

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

    

Answer 13

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

Não somos uma instituição que se preocupa 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. Pelo que sei, não acho que exista um pacote de segurança pronto para uso que desligue a rede de um ativo que faz inventários com uma conexão de rede externa de algum tipo. 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 final, como 3G ou WiMax.

E, finalmente, o bloqueio cego do TCP / 22 apenas bloqueará o mínimo de desejo dos usuários finais de violar o AUP em sua rede de trabalho.

    

Answer 14

Eu vi 22 bloqueados quando descobriram que as pessoas estavam direcionando o tráfego HTTP para 22. Foi uma demonstração para aqueles de nós que precisavam, mas a organização se manteve firme.

    

Answer 15

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 em saber de qualquer corporação que permitisse conexões externas diretas de desktops ou servidores, a menos que houvesse uma necessidade específica.

    

Answer 16

Nada impede que você execute seu sshd remoto na porta 80. Ambos ssh e sshd têm uma opção -p para configurar a porta.

É claro que, se seus administradores forem espertos, eles devem observar o tráfego do ssh, não apenas o tráfego da porta 22. Então, parece que você tem um problema de política, não um problema de tecnologia.

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