Ich habe viele Versuche auf meinem (kleinen, persönlichen und absolut unwichtigen) Webserver, und Apache und fail2ban machen ihre Arbeit normalerweise richtig. Aber es gibt einen Protokolleintrag, der mich beunruhigt:
xx.yy.www.zzz - - [9/Jul/2011:12:42:15 +0100] "GET http://allrequestsallowed.com/?PHPSESSID=5gh6ncjh00043YVMWTW_B%5CFAP HTTP/1.1" 200 432 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12"
Das Problem ist, dass die Antwort kein 404-Code war, sondern ein 200-Code. Ist das in Ordnung? Kommt mir komisch vor, aber mein Wissen auf diesem Gebiet (und vielen anderen) ist, gelinde gesagt, begrenzt.
curl -v http://allrequestsallowed.com/?PHPSESSID=5gh6ncjh00043YVMWTW_B%5CFAP -x www.example.com:80. Die Standardkonfiguration scheint auf unserem Ubuntu-System eine Seite "Willkommen bei Nginx" ohne aussagekräftigen Inhalt zurückzugeben. Es handelt sich also um eine Antwort von 200, aber es handelt sich um eine einfache Sammel-Seite - wir stellen die Anfrage nicht an eine andere Stelle oder ähnliches.Antworten:
Erstens weiß ich nicht, was der mutmaßliche Angreifer zu erreichen versucht. Vielleicht gibt es da draußen ein PHP-Skript oder eine PHP-Version, die für einen seltsamen Sitzungs-ID-Angriff anfällig ist, weiß ich nicht. Sie müssen sich jedoch wahrscheinlich keine Sorgen machen.
Ihr Server hat sich genau wie erwartet verhalten. 200 ist der erwartete Code in dieser bestimmten Situation, da Apache die an ihn übergebene URL interpretiert.
Erstens wird
http://allrequestsallowed.comes wie der üblichere 'Host:' - Header behandelt (beachten Sie, dass ich nicht glaube, dass dies im RFC angegeben ist und andere Server es möglicherweise nicht so interpretieren, wieich mich geirrt habe. Dies wird in RFC 2616 in Abschnitt 5.1 angegeben. 2, obwohl Clients dieses Formular selten zu verwenden scheinen. Entschuldigung, ich muss eine HTTP-Server-Implementierung reparieren, die ich vor einiger Zeit geschrieben habe ...).Vermutlich haben Sie keine Site mit dem Namen "allrequestsallowed.com". Was passiert also, wenn Apache einen
Host:Header (oder einen gleichwertigen Header) für einen Hostnamen erhält, den er nicht erkennt? Es wird der erste virtuelle Host als Standard ausgewählt. Dies ist ein genau definiertes und dokumentiertes Verhalten für Apache. Was auch immer Ihr erster virtueller Host ist (oder nur die Hauptserverkonfiguration, wenn keine vhosts vorhanden sind), übernimmt unabhängig davon, wie er heißt.Der Rest der angegebenen URL besteht nun aus zwei Teilen - dem Pfad
/und einem GET-Parameter (dem?PHPSESSID...Bit).Jetzt sollte der Pfad
/auf so ziemlich jedem Webserver vorhanden sein. In den meisten Fällen wird es so etwas wieindex.htmloder vielleicht einemindex.phpSkript zugeordnet, obwohl Sie natürlich alles überschreiben können.Wenn es einer statischen HTML-Datei zugeordnet wird, passiert absolut nichts Ungewöhnliches - der Inhalt der Datei wird zurückgegeben, und das heißt, der Parameter wird einfach ignoriert. (Angenommen, Sie haben bestimmte erweiterte Konfigurationsanweisungen nicht festgelegt, und Sie tun dies mit ziemlicher Sicherheit nicht.)
Wenn es sich jedoch um ein Skript handelt, wird diese
PHPSESSIDVariable an das Skript übergeben. Wenn das Skript diese Variable tatsächlich verwendet (in diesem speziellen Fall werden wahrscheinlich nur PHP-Skripte verwendet, die die integrierte Sitzungsbehandlung von PHP verwenden), hängt ihr Verhalten vom Inhalt ab.Aller Wahrscheinlichkeit nach wird jedoch
/nichts Bemerkenswertes passieren , selbst wenn Sie mithilfe von Sitzungen einem PHP-Skript zugeordnet werden. Die Sitzungs-ID ist wahrscheinlich sowieso nicht vorhanden und wird entweder ignoriert oder das Skript zeigt einen Fehler an.In dem unwahrscheinlichen Fall, dass die Sitzungs-ID vorhanden ist, könnte der Angreifer möglicherweise die Sitzung eines anderen entführen. Das wäre schlecht, aber es ist nicht wirklich eine Sicherheitslücke an sich - die Lücke wäre überall dort, wo der Angreifer die Sitzungs-ID-Informationen erhalten hat (das Aufspüren eines drahtlosen Netzwerks ist ein guter Kandidat, wenn Sie kein HTTPS verwenden). Sie würden tatsächlich nichts tun können, was der Benutzer, dessen Sitzung es ursprünglich war, nicht tun konnte.
Bearbeiten: Zusätzlich wird '% 5C' in der SESSIONID einem Backslash-Zeichen zugeordnet. Dies scheint ein Test für Directory Traversal-Angriffe auf Windows-Hosts zu sein.
quelle
nginxoderlighttpdnach dem Senden der IPs / Quellhosts an eine Cyber-Analysefirma wurde bestätigt, dass es sich unter anderem um Versuche handelte, Lücken im Server auszunutzen . Ähnliche Anforderungen wie die vom OP angegebenen, unterschiedliche Hosts. Wollen Sie damit sagen, dass sie völlig ignoriert werden sollten? Denn wenn sie wirklich besorgt sind, können sie die Hosts blockiereniptables.Ich habe diese alle Anforderungen auf einer IP-Adresse angemeldet, die als Datensatz für alle unsere Park-Domains verwendet wird.
Mein Schuss ist, dass dieser Hostname in Kombination mit der lokalen Hostdatei des "Angreifers" verwendet wird, die auf den Zielhost zeigt.
Der eigentliche Webserver unter 31.44.184.250 dient nur zur Bearbeitung externer Anfragen.
Meine Meinung: total harmlos. Sie sehen keine Mehrwertnutzung dafür, außer für Dinge, die Sie mit einem anderen gefälschten Domainnamen in Ihrer Hostdatei tun können.
quelle