Quais portas tendem a não ser filtradas por firewalls estúpidos?

Quais portas tendem a não ser filtradas por firewalls estúpidos?

Gosto de poder fazer ssh no meu servidor (chocante, eu sei). O problema surge quando estou viajando, onde enfrento diversos firewalls em hotéis e outras instituições, com configurações diversas, às vezes bastante estúpidas.

Eu gostaria de configurar uma escuta sshd em uma porta que tenha uma alta probabilidade de passar por essa bagunça. Alguma sugestão?

O sshd atualmente escuta em uma porta não padrão (mas <1024) para evitar que os script kiddies batam na porta. Essa porta é frequentemente bloqueada, assim como a outra porta fora do padrão onde reside meu servidor IMAP.

Tenho serviços em execução nas portas 25 e 80, mas qualquer outra coisa é válida. Eu estava pensando em 443 talvez.

Muito apreciado!

Reid

Responder1

Não vejo por que 443 não deveria funcionar.

No entanto, sempre questiono a execução do sshd em uma porta diferente da 22. Eu mesmo não tentei, mas a segurança é via obscuridade. Ele fornece uma falsa sensação de segurança. Muitos bots levarão algum tempo para verificar a porta de um host antes de atacar ou se 22 estiver fechado. Se 22 funcionar na maioria dos firewalls, eu simplesmente voltaria a usar 22 e configuraria pares de chaves para autenticação e desabilitaria totalmente a autenticação de senha (independentemente de você voltar para 22 ou não)

443 parece uma boa escolha, pois deve ser aberto com frequência.

Responder2

443 não é uma boa ideia. especialmente a porta 443 é uma solução perigosa, se você não a usar para tráfego SSL. em primeiro lugar, o Gmail ou qualquer grande provedor de serviços irá marcá-lo como um servidor proxy público (eles marcam que tudo funciona em 443 sem SSL). Além disso, alguns firewalls profissionais também bloqueiam qualquer tráfego em 443 sem SSL. por causa de programas proxy como ultrasurf ou thor etc. talvez você possa voltar para 23 ou deixar em 22. se você não gosta de bruteforcers no sshd. posso aconselhá-lo a usar o fail2banhttp://www.fail2ban.org/wiki/index.php/Main_Page é uma solução perfeita para proteger sshd, também servidores ftp, etc.

Responder3

Eu diria que 443 seria uma boa porta, mas esteja ciente de que alguns firewalls podem fazer inspeção de conteúdo para garantir que o tráfego da porta 443 seja realmente https. Existem também alguns locais estranhos onde eles não gostam de tráfego criptografado, então negue a porta 443.

Dependendo da configuração, a porta 53 pode estar ok - se eles não restringirem o tráfego de saída apenas aos seus próprios servidores DNS.

Também pode ser necessário considerar se você poderia usar um endereço IP sobressalente. Você não precisa necessariamente ter seu servidor web escutando todos os endereços IP que seu servidor possui; nesse caso, você pode simplesmente usar a porta 80, que tem menos probabilidade de ser bloqueada.

Então, novamente, provavelmente não é aconselhável colocar seu servidor ssh em uma porta bem conhecida quando o que você está fazendo é tentar torná-lo obscuro. E pode haver servidores proxy embutidos nas portas 80 e 443 que impedem você de fazer isso.

Responder4

Eu apoio uma VPN para vários usuários que levam seus sistemas a muitas redes restritivas. Na minha experiência, não existe uma única porta em que você possa ouvir que funcione 100% do tempo. Se você deseja conectividade altamente disponível, provavelmente precisará configurar seu sistema para aceitar conexões em muitas portas.

Basta configurar o SSH para escutar em alguma porta e depois usar o NAT para disponibilizá-lo em outras portas.

Já que você mencionou que a porta 80 está em uso. Se você tiver o Apache rodando na porta 80, poderá até configurá-lo como proxy. Mas certifique-se de entender como configurar o acesso corretamente para não se tornar um proxy aberto.

Infelizmente, se você realmente deseja que seu sistema tenha acesso a partir de redes restritivas, é provável que você precise fazer muitas verificações. Os mesmos protocolos comumente permitidos através de firewalls são aqueles comumente usados ​​e verificados. Configure algo como denyhosts ou fail2ban para que seu sistema bloqueie as pessoas.

informação relacionada