Ich betreibe einen Ubuntu 20.04 LEMP (Linux, Nginx, MariaDb, PHP) Webserver. Ich führe auch einige Nmap-Schwachstellentests von meinem MacOS-Client-Rechner aus durch. Unter MacOS verwende ichOh mein Gott!mit nmapaktiviertem Plugin. Um einige Schwachstellentests auf meinem Ubuntu-Server von meinem MacOS-Client-Rechner aus durchzuführen, habe ich den folgenden Befehl eingegeben:
nmap_check_for_vulns my.server.ip.address
Das ist ein Alias-Befehl für
nmap --script=vuln
Nachdem ich den Befehl mit der IP-Adresse meines Servers ausgegeben hatte, meldete nmap Folgendes:
| 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
Auf dem Ubuntu-Server lautet die Ausgabe 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:*
Ich versuche, diese Sicherheitslücke auf dem Server zu schließen. Allerdings ist Apache auf meinem Server NICHT installiert. Deshalb weiß ich nicht, warum diese Sicherheitslücke auftritt.
Meine Frage ist nun: Wie finde ich das anfällige Programm und wie schließe ich dann die Sicherheitslücke auf dem Server?
Antwort1
Überprüfen Sie ss -lnpt, welcher Prozess auf Port 80 oder 443 lauscht. Dies ist höchstwahrscheinlich das Ziel.
Antwort2
Deruralt überprüfenist nicht spezifisch für Apache2, sondern nur spezifisch für einen bestimmten Ansatz zur Milderung solcher DoS-Oberflächen auf Apache2. Nginx verwendet es nicht: Es erfüllt standardmäßig Anfragen für große Zahlen separater Bereiche, nur vorbehaltlich der Header-Größenbeschränkungen. Theoretisch könnte es (oder alles, was den Header unverändert weiterleitet) anfällig für übermäßigen Ressourcenverbrauch bei ungewöhnlichen Anfragen sein.
max_ranges number; Default: — Context: http, server, locationDiese Anweisung erschien in der Version 1.1.2.
Begrenzt die maximal zulässige Anzahl von Bereichen in Bytebereichsanforderungen. Anforderungen, die den Grenzwert überschreiten, werden so verarbeitet, als wären keine Bytebereiche angegeben. Standardmäßig ist die Anzahl der Bereiche nicht begrenzt. Der Wert Null deaktiviert die Bytebereichsunterstützung vollständig.
Es ist einfach bei weitem kein so großes Problem wie dieser spezielle Trick, mit dem Apache-Server überlastet werden könnten. Solange Ihr Nginx nicht woanders einen Proxy verwendet (oder darauf angewiesen ist, die meisten Anfragen aus dem Cache statt aus dem Proxy zu bedienen), müssen Sie wahrscheinlich nichts tun, selbst wenn Sie mit dieser Einstellung keine spezifischen Einschränkungen hinzufügen.
Heutzutage sind Webserver (die nach 2011 gewartet wurden) einfachaußer Acht lassenAnfragen für Bereiche, deren Größensumme die Gesamtlänge des Inhalts überschreitet- etwas mit wenig praktischer Anwendung, also eine noch bessere Milderung als die Begrenzung derNummervon Bereichen.
In jedem Fall können Sie solch lästige Anfragen einfach von Hand über die Befehlszeile erstellen. Der ganze Exploit besteht darin, eine Anfrage mit einem Header zu senden, der etwa Hunderte von sich überlappenden Bereichen enthält, wie Range: bytes=1-1337,1-1338,1-1339usw. Beobachten Sie, ob die Antwort (mit Status 206; wenn Sie 200 sehen, hat nginx Ihren Header einfach ignoriert und alles zurückgegeben) deutlich langsamer war, dann wissen Sie es mit Sicherheit.