Início / unix / Perguntas / 485076
Accepted
rb612
Asked: 2018-11-30 21:46:08 +0800 CST

UFW nega acesso a portas específicas por HTTPS?

  • 772

Estamos executando um servidor dev em algum IP e temos nossa API exposta na porta 5000 e nginx escutando na 80. No entanto, todo o backend irá travar quando alguém fizer uma solicitação HTTPS para a porta 5000. Assim, notei uma vulnerabilidade, que quando um acessa https://SERVER_IP:5000 , pois não pode lidar com a solicitação HTTPS, a solicitação trava e todo o back-end trava (portanto, a API trava para qualquer outra solicitação também). Eu só quero que essa solicitação nunca chegue ao back-end.

Eu tenho as seguintes regras configuradas para o UFW.

To                         Action      From
--                         ------      ----
8000                       ALLOW       Anywhere
22/tcp                     ALLOW       Anywhere
80                         ALLOW       Anywhere
5000                       ALLOW       Anywhere
443/tcp                    DENY        Anywhere
8000 (v6)                  ALLOW       Anywhere (v6)
22/tcp (v6)                ALLOW       Anywhere (v6)
80 (v6)                    ALLOW       Anywhere (v6)
5000 (v6)                  ALLOW       Anywhere (v6)
443/tcp (v6)               DENY        Anywhere (v6)

No entanto, quando se navega para https://SERVER_IP:5000 , o servidor ainda trava. Eu acho que isso ocorre porque o tráfego https não está necessariamente chegando na porta 443, mas sim na 5000 e isso é exposto (o que precisa ser apenas para tráfego HTTP). Então, existe alguma maneira de não permitir o tráfego HTTPS no 5000 através do UFW ou tenho que configurar algo com o nginx?

networking webserver

1 respostas

  1. Best Answer

    Não, UFW não pode fazer isso.

    Determinar se o tráfego na conexão TCP é uma solicitação HTTP válida ou não requer aceitar a conexão e ver que tipo de dados o cliente está tentando enviar. Em outras palavras, é uma filtragem baseada em conteúdo.

    O UFW precisa tomar a decisão com base nos dados do pacote SYN inicial da conexão TCP, que não contém dados. Nesse ponto você não pode dizer qual será a solicitação do cliente. Parece que você preferiria precisar de algum tipo de proxy reverso HTTP na frente de sua API, para filtrar tudo o que não é uma solicitação HTTP bem formada para um URI aplicável à sua API.

    Também posso sugerir a você que você também tenha a validação de entrada de sua API melhorada, pelo menos a ponto de não ser mais travável enviando bobagens aleatórias, antes de colocá-la em produção? Caso contrário, parece que sua API é muito provavelmente vulnerável a um ataque trivial de negação de serviço, como nc your.API.server.example 5000 < /dev/urandom, ou talvez nc your.API.server.example 5000 < War_and_Peace.txt, onde War_and_Peace.txt é qualquer coisa que seja definitivamente maior que o buffer de entrada do seu serviço de API.

    • 2

relate perguntas