Hackversuche generell blocken .. (wie) geht das?

[infomatiker]

Hallo zusammen,

auf unserer Homepage hab ich seit kurzem eigene Fehlerseiten (404,403,401,410) eingerichtet. Das läuft so, dass ich fehlerhafte Anfragen zuerst per htaccess an ein PHP-Script weiterleite, was mir ne Mail schickt mit der IP, Seite auf die zugegriffen wurde, Referrer, usw.
Die ganze Zeit hatten wir da noch die Standard-Fehlerseiten, weshalb ich nicht mitbekommen habe, was da so nebenher noch alles mit der Seite gemacht wird (bin ja auch kein Linux-Fuchs, und habe leider auch nicht die Zeit mir regelmäßig Logfiles anzuschauen).
Auf jeden Fall habe ich jetzt in den Mails unter anderem solche Zugriffe :

http://www.meine-domain.com//modules/Fo ... /mix.txt???
http://www.meine-domain.com/eval(name+%22_h.src%22);%7D
http://www.meine-domain.com//claroline/ ... om/bht.txt?
http://www.meine-domain.com//modules/Fo ... 98/id.txt??

Klar ist, das da versucht wird irgendwelche Exploits zu nutzen, bzw. irgendwelche Scripte auszuführen. Diese Anfragen werden auch wohl schön an die 404 weitergeleitet. Jetzt stellt sich mir aber die Frage, ob und wie ich sicherstellen kann, dass solche Scripte auch wirklich nicht ausgeführt werden können. Unter anderem (hab mir von diesen txt-Dateien, die per PHP ausgeführt werden wollen mal ein paar angeschaut) lesen die ja auch meine Verzeichnisstruktur aus, wollen irgendwelche Module per wget holen und installieren, und und und ...

- Ubuntu (DapperDrake)
- Apache/2.0.54 (Debian GNU/Linux)
- PHP/4.3.10-22 (wird demnächst auf PHP5 umgestellt)

Hoffe ihr könnt mir da ein paar Tips geben, wie ich zumindest halbwegs sicher gehen kann, dass der Server sicher genug ist.

Vielen Dank schonmal ...

Greetz
Infomatiker

[jan10001]

Lernen, lernen ...
Sry, ist nun mal so, einen Server zu betreiben und davon kaum Ahnung zu haben ist... . Wer einen Server betreibt sollte sich regelmässig darum kümmern, wer dafür keine Zeit hat sollte keinen Server betreiben. Was du da in deinen Logdateien siehst sind die Versuche unsichere PHP Anwendungen auszunutzen um Zugriff zu erlangen, eine logische Vorsichtsmaßnahme wäre da z.B. dafür zu sorgen das alle PHP Anwendungen auf den aktuellen Stand sind.

[dohǃ]

Vielleicht hilft dir mod_security (http://www.modsecurity.org).

[infomatiker]

Wer einen Server betreibt sollte sich regelmässig darum kümmern, wer dafür keine Zeit hat sollte keinen Server betreiben.

Das seh ich ja ein, und bin auch der gleichen Meinung. Anfangs konnte ich mich auch mehr damit beschäftigen, bis dann irgendwem der Gedanke kam, die Administration der WebSite mit allem drum und dran wäre ja nicht tagesfüllend .. da kann ich ja noch in einer weiteren Abteilung (die absolut nix mit Web zu tun hat) eingeteilt werden und den Web-Kram "so nebenbei noch machen". Von daher komm ich auch wirklich nur sporadisch dazu, in dem Gebiet was zu machen.

"mod_security" werd ich mir mal anschauen ... "mal so nebenbei" ...

Trotzdem danke ...

[daemotron]

Neben den bereits erwähnten Dingen (Applikationen aktuell halten, mod_security) könntest Du noch den Webserver und/oder PHP in ein Jail stecken (am besten eines pro virtuellem Host).

... und habe leider auch nicht die Zeit mir regelmäßig Logfiles anzuschauen ...

Daran solltest Du allerdings vorrangig arbeiten. Natürlich kann man als Admin (mehrerer Server?) nicht jedes Logfile komplett lesen. Logfiles kann man aber auch automatisiert auswerten. Dazu gibt es dann diverse fertige Skripte, oder man baut sich selbst was (Shell-Skript + grep + awk oder Perl sind gut geeignete Werkzeuge). Man kann auch gleich ein komplettes IDS einsetzen, die meisten bringen ein Werkzeug zur Logfile-Überwachung mit. Egal wie Du's genau realisierst - wenn Dein Wachhund einen Einbruchsversuch wittert, schlägt er Alarm. Dann musst Du das Logfile ab diesem Punkt manuell genauer unter die Lupe nehmen, um festzustellen, ob der Angriff nicht vielleicht doch Erfolg gehabt haben könnte.

[jan10001]

Die Zeit für Logfiles mußt du dir nehmen, gerade PHP Anwendungen bieten oft gute Angriffspunkte z.B. um sich über den DB Server ins System zu hacken. Aber auch die anderen Logfiles darf man nicht vergessen! Mach mal deinen Chef darauf aufmerksam, eine gehackte Seite ist nicht gerade vertrauend erregend für eine Firma.

[beanie]

Hey,

ich kann nur PHP-IDS (http://php-ids.org/) empfehlen.
Erkennt eigentlich alle Arten von Angriffen und man kann selbst definieren wie darauf reagiert werden soll.

Grüße

[daemotron]

ich kann nur PHP-IDS (http://php-ids.org/) empfehlen.

Für PHP-Applikationen vielleicht ganz nett, aber insgesamt halte ich das für unzureichend. Erstens kann die Software selber ein Loch haben, und zweitens kann man sie nicht in alle Webapplikationen einbinden - nicht alle Webapplikationen sind in PHP geschrieben, und von denen, die es sind, liegen nicht alle quelloffen vor.

Erkennt eigentlich alle Arten von Angriffen

Glaube ich kaum. Wenn überhaupt, dann vielleicht "die meisten bekannten Angriffe auf PHP-Webapplikationen".

[beanie]

Hallo,

ich kann nur PHP-IDS (http://php-ids.org/) empfehlen.

Für PHP-Applikationen vielleicht ganz nett, aber insgesamt halte ich das für unzureichend. Erstens kann die Software selber ein Loch haben, und zweitens kann man sie nicht in alle Webapplikationen einbinden - nicht alle Webapplikationen sind in PHP geschrieben, und von denen, die es sind, liegen nicht alle quelloffen vor.

ich hab den Post vom threadstartet so verstanden, dass es um PHP ging. Seine Beispiele sind PHP und er erwähnt extra noch, dass er bald auf PHP5 upgraden möchte.
Warum müssen die Applikationen quelloffen sein? Ist doch völlig egal, solange sie durch den PHP-Interpreter müssen.

Erkennt eigentlich alle Arten von Angriffen

Glaube ich kaum. Wenn überhaupt, dann vielleicht "die meisten bekannten Angriffe auf PHP-Webapplikationen".

Natürlich für Webapplikationen, aber das hatte ich vorrausgesetzt in einem Thread wo es um die Sicherung von PHP-Skripten geht.

Natürlich kann PHP-IDS Lücken haben, nichts ist ausgeschlossen. Aber die Chance halte ich für relativ gering.

Grüße
Benjamin

[Roger Wilco]

Warum müssen die Applikationen quelloffen sein? Ist doch völlig egal, solange sie durch den PHP-Interpreter müssen.

Nein. PHP-IDS ist keine PHP-Erweiterung wie Suhosin, sondern nur eine Klassenbibliothek und muss von dem jeweiligen Programm aktiv unterstützt werden. Bei PHP Software von einem Dritthersteller, der den Quellcode etwa mit Zend Guard "verschlüsselt" hat, bringt PHP-IDS also nichts. Ebenso ist es wertlos, wenn der Benutzer keine Erfahrung mit PHP-Programmierung hat und ein vorhandenes, quelloffenes Skript mit Unterstützung für PHP-IDS ausstatten will.

[Joe User]

Erkennt eigentlich alle Arten von Angriffen

Nö, nur die per Config definierten und das sind wenige und zu allgemeine Rules. Da erschlägt ein primitiver Deny für '=(f|ht)tp' im QUERY_STRING auf HTTPd-Ebene schon mehr...

[beanie]

Warum müssen die Applikationen quelloffen sein? Ist doch völlig egal, solange sie durch den PHP-Interpreter müssen.

Nein. PHP-IDS ist keine PHP-Erweiterung wie Suhosin, sondern nur eine Klassenbibliothek und muss von dem jeweiligen Programm aktiv unterstützt werden. Bei PHP Software von einem Dritthersteller, der den Quellcode etwa mit Zend Guard "verschlüsselt" hat, bringt PHP-IDS also nichts. Ebenso ist es wertlos, wenn der Benutzer keine Erfahrung mit PHP-Programmierung hat und ein vorhandenes, quelloffenes Skript mit Unterstützung für PHP-IDS ausstatten will.

Und was hindert mich als Serveradmin dies mit auto_prepend_file einfach jedem PHP-Skript voranzustellen?

Erkennt eigentlich alle Arten von Angriffen

Nö, nur die per Config definierten und das sind wenige und zu allgemeine Rules. Da erschlägt ein primitiver Deny für '=(f|ht)tp' im QUERY_STRING auf HTTPd-Ebene schon mehr...

Sehr mutige Behauptung, würde gern mal nen String sehen der durchkommt. Bin echt gespannt. Sollte ja trivial sein bei den wenigen allgemeinen Regeln. Wobei dein primitiver Deny bestimmt sehr stark bei SQL-Injections seine Muskeln spielen läßt.

Ben

[Joe User]

Lies mal Dein access.log dann weisst Du, dass >80% der Hackversuche durch den simplen Deny erschlagen werden. Mehr habe ich nicht behauptet...