Existe alguma desvantagem de bloquear a porta 80 por motivos de segurança?

1

Para melhorar a segurança, gostaríamos de tornar o https acesso a todos os sites de clientes que hospedamos mandantory e garantir isso em nossos termos e condições.

O problema é que atualmente o servidor Apache está configurado para redirecionar todas as solicitações http para solicitações https usando a diretiva Apache "Redirect permanent". Tecnicamente, ainda estamos usando o protocolo http inseguro, embora ele seja usado apenas para o redirecionamento e nenhum dado do cliente possa ser acessado por meio de http.

Duas perguntas:

  1. Existe alguma desvantagem em bloquear completamente a porta 80? A única desvantagem que posso imaginar é que os clientes são forçados a digitar https: // na frente de seu URL, em vez de depender do redirecionamento automático.

  2. Se um cliente enviar uma solicitação http POST, o httpd Apache responderia com o redirecionamento ANTES de os dados POST reais serem transmitidos aos nossos servidores ou enviasse o redirecionamento somente APÓS receber os dados do cliente (não criptografados)? ?

Por favor, informe.

Depois de considerar seus comentários, faremos as seguintes alterações em nossa configuração de rede:

  1. As VMs do cliente individuais serão modificadas para que não escutem mais a porta 80. Além disso, a configuração de redirecionamento será removida.
  2. O firewall será configurado para que qualquer tráfego da porta 80 seja roteado para um servidor especial que tenha a única finalidade de retornar a resposta de redirecionamento adequada ao remetente.
  3. Para segurança máxima, esse servidor especial estará em uma VLAN diferente de todos os outros sistemas, poderemos até usar hardware dedicado, como um Raspberry Pi em vez de uma VM padrão.
  4. O
  5. suporte HSTS será adicionado a todas as instâncias do cliente.

Ao usar essa configuração, podemos provar que nenhum tráfego não criptografado chega ou sai da rede do cliente, ao mesmo tempo em que fornece o redirecionamento automático amigável ao usuário para https.

    
por nn4l 22.06.2016 / 15:24

3 respostas

7

Sua "única desvantagem" é muito grande, IMO. Ninguém que eu conheço digita https:// em URLs com muita frequência. Eu suspeitaria que 99% dos usuários normais simplesmente iriam "huh, o site está inativo".

Um HTTP POST de fato enviaria os dados sem criptografia. Ele também falhará, porque o redirecionamento fará com que ele se transforme em GET . Dito isso, há poucas razões para as pessoas estarem fazendo HTTP POST s em seus URLs, se você já estiver redirecionando para HTTPS.

O que você provavelmente quer realmente é HTTP Strict Transport Security , que informará aos navegadores dos usuários que eles devem sempre usar HTTPS para seu domínio. Veja limitações - a primeira solicitação para um novo usuário não é protegida por ele, mas todas as subsequentes são (isso pode ser endereçado enviando seu domínio para as listas de pré-carregamento do STS para os principais fornecedores de navegador).

    
por 22.06.2016 / 15:50
5

Are there any disadvantages of blocking port 80 completely? The only disadvantage I can think of is that customers are forced to enter https:// in front of their url, instead of relying on the automatic redirect.

Esse é exatamente o principal motivo para deixar a porta 80 aberta e amigável ao usuário. AFAIK a maioria dos navegadores ainda usa o padrão http: // quando você insere um URL que resultará em uma mensagem de erro quando a porta 80 for bloqueada.

Somente os realmente dedicados tentarão novamente com https: //, mas quase todos os outros visitantes de seu site provavelmente irão a outro lugar pensando que seu site está inativo.

If a customer sends a http POST request, would the Apache httpd respond with the redirect BEFORE the actual POST data has been transmitted to our servers, or would it send the redirect only AFTER receiving the (unencrypted) customer data?

Um redirecionamento só é emitido depois que a solicitação do cliente é concluída, portanto, após os dados terem sido transmitidos em texto não criptografado.

Para formulários hospedados em seu próprio servidor, você pode impedir que os navegadores enviem dados por um canal inseguro definindo uma Segurança de transporte restrita HTTP .

    
por 22.06.2016 / 15:54
3
  1. Sim, remover o redirecionamento causará problemas importantes. Novos clientes não saberão sobre isso, nem muitos rastreadores a quem você deseja permitir o acesso. O vetor de ameaça que você está fechando é insignificante.

  2. Os dados POST provavelmente serão enviados como uma única solicitação HTTP, que acionará o redirecionamento. No entanto, na maioria dos casos, um POST implica em um formulário. Alguém além da sua equipe está criando formulários que são enviados ao seu site?

por 22.06.2016 / 15:54