Estou executando um servidor web Ubuntu 20.04 LEMP (Linux, Nginx, MariaDb, PHP). Também estou fazendo alguns testes de vulnerabilidade do nmap em minha máquina cliente MacOS. No MacOS, estou usandoOh meu Zsh!com o nmapplugin ativado. Para fazer alguns testes de vulnerabilidade no meu servidor Ubuntu da minha máquina cliente MacOS, emiti o comando:
nmap_check_for_vulns my.server.ip.address
que é um comando de alias para
nmap --script=vuln
Após emitir o comando com o endereço IP do meu servidor, o nmap relatou o seguinte:
| http-vuln-cve2011-3192:
| VULNERABLE:
| Apache byterange filter DoS
| State: VULNERABLE
| IDs: CVE:CVE-2011-3192 BID:49303
| The Apache web server is vulnerable to a denial of service attack when numerous
| overlapping byte ranges are requested.
| Disclosure date: 2011-08-19
| References:
| https://www.tenable.com/plugins/nessus/55976
| https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3192
| https://www.securityfocus.com/bid/49303
|_ https://seclists.org/fulldisclosure/2011/Aug/175
No servidor Ubuntu, a saída ss -lnpté:
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0 100 0.0.0.0:25 0.0.0.0:*
LISTEN 0 511 0.0.0.0:443 0.0.0.0:*
LISTEN 0 4096 127.0.0.1:8125 0.0.0.0:*
LISTEN 0 100 0.0.0.0:4190 0.0.0.0:*
LISTEN 0 4096 127.0.0.1:19999 0.0.0.0:*
LISTEN 0 100 0.0.0.0:993 0.0.0.0:*
LISTEN 0 4096 127.0.0.1:10023 0.0.0.0:*
LISTEN 0 4096 127.0.0.1:10024 0.0.0.0:*
LISTEN 0 100 127.0.0.1:10025 0.0.0.0:*
LISTEN 0 4096 127.0.0.1:10026 0.0.0.0:*
LISTEN 0 80 127.0.0.1:3306 0.0.0.0:*
LISTEN 0 100 0.0.0.0:587 0.0.0.0:*
LISTEN 0 128 0.0.0.0:43211 0.0.0.0:*
LISTEN 0 511 127.0.0.1:6379 0.0.0.0:*
LISTEN 0 4096 127.0.0.1:783 0.0.0.0:*
LISTEN 0 100 0.0.0.0:143 0.0.0.0:*
LISTEN 0 511 0.0.0.0:80 0.0.0.0:*
LISTEN 0 4096 0.0.0.0:10000 0.0.0.0:*
LISTEN 0 100 0.0.0.0:465 0.0.0.0:*
LISTEN 0 128 0.0.0.0:43219 0.0.0.0:*
LISTEN 0 256 0.0.0.0:53 0.0.0.0:*
Estou tentando fechar essa vulnerabilidade no servidor, porém NÃO tenho o apache instalado no servidor, então não sei porque essa vulnerabilidade está aparecendo!
Minha pergunta é: como encontro o programa vulnerável e como fecho a vulnerabilidade no servidor?
Responder1
Verifique com ss -lnptqual processo está escutando na porta 80 ou 443, esse é provavelmente o alvo.
Responder2
Oancestral verificarnão é específico do Apache2, é específico apenas para uma abordagem específica de mitigar essa superfície DoS no Apache2. O Nginx não o utiliza: ele atende a solicitações de um grande número de intervalos separados por padrão, sujeito apenas a limites de tamanho de cabeçalho. Em teoria, isso (ou qualquer coisa encaminhada para o cabeçalho como está) pode ser vulnerável ao uso excessivo de recursos em solicitações estranhas.
max_ranges number; Default: — Context: http, server, locationEsta diretiva apareceu na versão 1.1.2.
Limita o número máximo permitido de intervalos em solicitações de intervalo de bytes. As solicitações que excedem o limite são processadas como se não houvesse intervalos de bytes especificados. Por padrão, o número de intervalos não é limitado. O valor zero desativa completamente o suporte ao intervalo de bytes.
Simplesmente não é um problema tão grande quanto aquele truque específico que pode ser usado para sobrecarregar os servidores Apache. Contanto que seu nginx não esteja fazendo proxy (ou dependendo de atender a maioria das solicitações do cache em vez de proxy) em outro lugar, você provavelmente não precisará fazer nada, mesmo que não adicione especificamente restrições usando essa configuração.
Hoje em dia, os servidores web (que receberam manutenção depois de 2011) simplesmentedesprezosolicitações de intervalos cuja soma do tamanho excede o comprimento total do conteúdo- algo com pouca aplicação no mundo real, portanto, uma mitigação ainda melhor do que limitar onúmerode intervalos.
Em qualquer caso .. você pode simplesmente criar uma solicitação tão irritante na linha de comando. Toda a exploração consiste em enviar uma solicitação com um cabeçalho com algo na ordem de centenas de intervalos sobrepostos, como Range: bytes=1-1337,1-1338,1-1339e assim por diante. Observe se a resposta (com status 206; se você vir 200 nginx simplesmente ignorou seu cabeçalho e retornou tudo) foi significativamente mais lenta, então você terá certeza.