Hacker Angriffe und Störungs-Beseitigung: Ob es Hacker sind oder nicht, auf jeden Fall gibt es da seltsame Log-Einträge. Ich hatte einige Appache Coredumps - also Abstürze des Web-Servers, die ich teils mittels Restart löste ... aber befriedigend ist das nicht. Immerhin will man ja einen störungsfreien Betrieb.

Nun bin ich ja kein Systemexperte und mir ist die Wartung und Linux-Gefummel eher lästig. Aber ein notwendiges Übel. Also hier meine Störungsanalyse auf Debian:

Gefunden: Mehrere Appache Coredumps in /etc/apache2

  1. Größe 231 469 056 Bytes und mehr
  2. Zeiten jeweils zwischen 01:06 und 01:35
  3. Also Zeiten keiner normalen User, und auch nicht von mir ... Ronots? Service-Jobs?

Weiter geht es in /var/log/apache2/
Die Logs lassen sich mit gunzip entpacken. Gefunden habe ich derartige Einträge:

PROPFIND /webdav/

Da wollte also jemand um 16/Dec/2016:02:20:29 probieren, ob er mittels Webdav auf einen Server zugreifen kann. Dieser Angriff erscheint nicht besonders erfolgreich, zeigt aber exemplarisch, was da Leute im Netz so treiben.

Übrigens zu Webdav: http://www.webdav.org/specs/rfc2518.html#METHOD_PROPFIND Anmerkung: Ich habe Webdav nicht installiert und konfiguriert.

Angefangen hatte diese Sequenz von der gleichen IP-Adresse mit einem harmlosen GET /index.php?lang=ar ... wobei allerdings der Language-Code ar für Afrikaans steht.

Weiter ging es mit GET /up.php ... offensichtlich vermutete der Angreifer, dass es ein entsprechendes Upload-Programm gäbe, mit dem er Code einspeisen könne. Weitere Aktivitäten von eben jener IP:

  • GET /robots.txt
  • GET /manual/ko/mod/mod_mime.html
  • GET /testproxy.php
  • GET /manual/de/mod/mod_proxy.html

... und noch einige weitere erfolglose Versuche: Was erwartet jener, auf meiner Site zu finden?

Maßnahmen

Zunächst geht es darum, den Server wieder zum fliegen zu kriegen.

Als Unkundiger kann man natürlich den dicken Hammer heraus holen. Wenn z.B. der Server in einem virtuellen Container liegt, kann man die ganze Machine über das Power Panel restarten. Oder noch schlimmer: Ein Backup einspielen.

Meist sind aber derartig drastische Maßnahmen nicht erforderlich. Oft genügt ein Restart des Webservers über die Konsole / putty:

apachectl -k graceful