Estoy ejecutando un servidor web Ubuntu 20.04 LEMP (Linux, Nginx, MariaDb, PHP). También estoy haciendo algunas pruebas de vulnerabilidad de nmap desde mi máquina cliente MacOS. En MacOS, estoy usando¡Oh Dios mío!con el nmapcomplemento habilitado. Para realizar algunas pruebas de vulnerabilidad en mi servidor Ubuntu desde mi máquina cliente MacOS, emití el comando:
nmap_check_for_vulns my.server.ip.address
que es un comando de alias para
nmap --script=vuln
Después de emitir el comando con la dirección IP de mi servidor, nmap informó lo siguiente:
| 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
En Ubuntu Server, el resultado ss -lnptes:
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:*
Estoy intentando cerrar esta vulnerabilidad en el servidor, sin embargo, NO tengo Apache instalado en el servidor, así que no sé por qué aparece esta vulnerabilidad.
Mi pregunta es, ¿cómo encuentro el programa que es vulnerable y cómo cierro la vulnerabilidad en el servidor?
Respuesta1
Verifique ss -lnptqué proceso está escuchando en el puerto 80 o 443, ese es probablemente el objetivo.
Respuesta2
Elantiguo controlarno es específico de apache2, solo es específico de un enfoque particular para mitigar dicha superficie DoS en apache2. Nginx no lo emplea: satisface solicitudes de una gran cantidad de rangos separados de forma predeterminada, solo sujeto a límites de tamaño de encabezado. En teoría, esto (o cualquier cosa que se reenvíe en el encabezado tal como está) podría ser vulnerable al uso excesivo de recursos en solicitudes impares.
max_ranges number; Default: — Context: http, server, locationEsta directiva apareció en la versión 1.1.2.
Limita el número máximo permitido de rangos en solicitudes de rango de bytes. Las solicitudes que superan el límite se procesan como si no se hubieran especificado rangos de bytes. De forma predeterminada, el número de rangos no está limitado. El valor cero desactiva completamente la compatibilidad con el rango de bytes.
Simplemente no es un problema tan grande como ese truco en particular que podría usarse para sobrecargar los servidores Apache. Mientras su nginx no esté haciendo proxy (o dependiendo de atender la mayoría de las solicitudes desde la caché en lugar de hacerlo) en otro lugar, probablemente no necesitará hacer nada, incluso si no agrega restricciones específicamente usando esa configuración.
Hoy en día, los servidores web (que recibieron mantenimiento después de 2011) simplementeindiferenciasolicitudes de rangos cuya suma de tamaño excede la longitud total del contenido- algo con poca aplicación en el mundo real, por lo que es una mitigación aún mejor que limitar lanúmerode rangos.
En cualquier caso... puedes crear a mano una solicitud tan molesta desde la línea de comando. Todo el exploit consiste en enviar una solicitud con un encabezado con algo del orden de cientos de rangos superpuestos, como Range: bytes=1-1337,1-1338,1-1339etc. Observe si la respuesta (con estado 206; si ve que 200 nginx simplemente ignoró su encabezado y devolvió todo) fue significativamente más lenta, entonces lo sabrá con certeza.