É seguro servir HTTP / HTTPS através das portas 8080/8443

Devido a uma limitação de infraestrutura, uma das soluções propostas para atender um serviço HTTP ao mundo é oferecê-lo pelas portas 8080 e 8443.

Minha preocupação é que alguns usuários não consigam acessar esses serviços porque não estão executando em portas padrão e o conteúdo pode ser filtrado por (por exemplo) como parte da política de rede corporativa.

Então ... qual a probabilidade de um usuário da Internet em geral não conseguir acessar esses serviços?

— gastador
fonte

você não pode proxy o endereço para as portas 80 e 443?

— Froggiz

Estamos usando as funções Web e Worker nos serviços em nuvem do Azure. Pelo que sei, não é possível apontar um segundo VIP para uma máquina diferente, a menos que alternemos para as VMs do Azure. Outras opções incluem a substituição de todo o servidor web front-end por um proxy, mas obviamente o uso de portas diferentes resolveria esse problema com menos despesas.

— gastador

eu quero dizer assim: azure.microsoft.com/en-us/documentation/articles/...

— Froggiz

Gostaria de abordar uma preocupação que parece estar faltando aqui. O fato de você não poder usar portas 80ou 443sugerir que você está executando em um servidor compartilhado. Nesse caso, existe a possibilidade de que outro usuário possa se vincular a essas portas se o seu parar de funcionar . Esse usuário pode então se passar por seu site (embora o SSL possa ajudar a atenuar isso).

— Nathan Osman

@ NathanOsman, acho que ele está preocupado com o acesso e firewalls do usuário.

— Pacerier

Respostas:

As redes corporativas geralmente terão como padrão regras como esta:

deny all; allow 80; allow 443; allow 21; allow 22; etc...

É muito mais fácil configurar dessa maneira do que negar explicitamente 99% das 65.535 portas disponíveis.

Dito isso, assumi um portal voltado para o cliente que usava uma porta não padrão devido a limitações de rede; Eu não sei os detalhes do NAT. De qualquer forma, isso impossibilitou que cerca de 50% de nossos usuários / visitantes acessassem o site e sempre que eles nos telefonassem para relatar esse problema, teríamos que coordenar com a TI inexistente para tentar obter uma regra de permissão implementada.

Não conheço os detalhes das suas limitações de infraestrutura, mas imagino que algo mais esteja sendo executado no 80/443

Se esse for o caso, sua única chance poderá ser usar um proxy interno ou atualizar o switch para algo com recursos NAT mais avançados que possam rotear as solicitações adequadamente.

TL; DR

Não use uma porta não padrão para serviços públicos, que já possuem uma porta padrão.

— MonkeyZeus
fonte

"É muito mais fácil configurar dessa maneira do que negar explicitamente 99% das 65.535 portas disponíveis". - mesmo que negassem explicitamente 99% das portas, isso teria o mesmo efeito.

— usar o seguinte comando

Acabamos usando o servidor da web principal para solicitar solicitações de proxy aos serviços oferecidos em outras portas. Como os outros serviços precisam escalar para obter mais poder de processamento, e não porque atingem os limites da rede, e o tamanho das solicitações e respostas é relativamente baixo, esse arranjo funciona muito bem com o site principal com balanceamento de carga, absorvendo com facilidade o custo de proxy.

— spender

@spender Fico feliz em ouvir que vocês foram capazes de resolver isso sem usar portas não padrão voltado para o cliente :)

— MonkeyZeus

É muito provável que eles sejam bloqueados, especialmente em redes corporativas ou em wifi público. Menos provável em uma conexão regular à Internet doméstica.

Certamente seria bloqueado na minha rede de trabalho.

Além disso, as pessoas precisam se lembrar de digitar o número da porta para acessar o site, o que é uma dor de cabeça extra com a qual você não deseja lidar. Para sites internos ou privados, não é um grande problema, mas se for para o público em geral, você terá muito mais sucesso usando as portas padrão.

— Conceder
fonte

Os serviços em questão nunca são digitados no navegador ... eles são apontados a partir dos recursos servidos nas portas normais. Parece, no entanto, que minhas preocupações com a confiabilidade de minha abordagem são bem justificadas.

— spender

você pode explicar por que isso seria bloqueado? i usado a porta 800 para o longo tempo sem qualquer problema, mesmo com ferramentas de SEO Google e referenciando ..

— Froggiz

Um dos meus trabalhos é executar um site que indexa fluxos de shoutcast, e é uma queixa comum que alguns usuários de redes corporativas não possam ouvir fluxos que estão sendo executados em portas não padrão. No entanto, 8080 e 8443 parecem ser um pouco especiais, mas provavelmente não são especiais o suficiente. Eu diria que a execução de um serviço no 800 é particularmente arriscada porque se enquadra em portas "conhecidas" que têm uma probabilidade consideravelmente maior de serem bloqueadas.

— spender

Uma solução fácil é deixar o servidor em execução na porta 8080/8443 e, no firewall, as portas NAT / forward 80/443 a 8080/8443.

— SnakeDoc 9/11

@SnakeDoc Acordado, eu cobri a opção proxy na minha resposta :-)

— MonkeyZeus

Não é difícil fazer o seu navegador bater, digamos http://example.com:8080/index.html , mas quando você fala sobre políticas corporativas que bloqueiam portas fora do padrão, isso parece muito difícil.

Se você tiver algum tipo de balanceamento de carga configurado, ainda poderá configurar seus aplicativos para execução em uma porta padrão e fazer com que a porta do balanceador de carga seja encaminhada internamente para a porta ímpar. Mesmo se você não tiver balanceamento de carga, tenho certeza de que pode encontrar uma maneira de encaminhar a porta para uma porta interna que não seja padrão.

Internamente, os usuários podem acessar em uma porta ímpar (se não fizer parte da política corporativa a ser bloqueada); externamente, eles vêem http://example.com .

Existem várias maneiras de fazer isso. Você precisará ser um pouco criativo, dependendo dos tipos de obstáculos que encontrar. É sempre um desafio!

— Brett Salmiery
fonte