Datei überwachen -> Informationen über Modifier erhalten

[martin.g]

Hallo,

ich habe hier einen Server der angegriffen wurde (recht ordentlich mit Botnetz Anbindung usw.). Um die Schwachstellen zu finden, läuft er momentan noch offline weiter. Bot Client war kein größeres Problem, aber immer noch werden regelmäßig php Skripte verseucht. Nachdem er keine Netzanbindung mehr hat, muss es ein Skript geben, das den Schadcode immer wieder einpflegt (ein base64 kodiertes eval in php). Ich finde einfach den Prozess nicht, der das immer wieder tut. Von außen wird mangels INet Anbindung nicht getriggert und einen passenden Cron Eintrag kann ich auch nicht finden.
Mein Gedanke war, eine regelmäßig maanipulierte Datei mittels inotify/iwatch zu überwachen. Dann sehe ich zwar, dass/wann die Änderung geschieht, aber nicht von wem. Ich suche eine Variante, möglichst viel über den Modifier zu erhalten. Laufen wird der Prozess ziemlich sicher als Apache User, aber ich hätte gerne noch die PID des Modifiers und erhoffe mir über /proc/PID/cmdline auf das Skript zu stoßen.
Klar, dass das Skript zum Zeitpunkt der Benachrichtigung möglicherweise schon zu Ende ist oder seine PID geändert hat, aber ich gehe von einem recht primitiven Angriff aus (lang laufendes Skript, das nacheinander alle index.phps infiziert.) Rootkit etc. schließe ich eigentlich auch aus.

Wäre toll, wenn mir jemand einen Fingerzeig geben könnte.

Viele Grüße
Martin

[martin.g]

Ach ja, noch eine Ergänzung vielleicht. Welche Möglichkeiten gibt es, auf das ursprünglich gestartete Skript zu schließen, wenn /proc/PID/cmdline einen gefakten Prozessnamen enthält?

[Roger Wilco]

Der Ansatz mit inotify ist schonmal nicht schlecht. Damit kannst du ein kleines Abbild von /proc zu dem Zeitpunkt des Schreibzugriffs anfertigen oder via `lsof` ermitteln, welcher Prozess gerade auf die betreffende Datei zugreift.

Welche Möglichkeiten gibt es, auf das ursprünglich gestartete Skript zu schließen, wenn /proc/PID/cmdline einen gefakten Prozessnamen enthält?

/proc/$PID/exe ist immer ein symbolischer Link auf das gestartete Programm auf der Festplatte. Der Symlink läuft zwar ggf. ins leere (z. B. weil das Binary direkt nach dem Start gelöscht wurde), aber es gibt dir immerhin einen Hinweis, von wo aus es gestartet wurde.

[martin.g]

Hi Roger,

vielen Dank für die Antwort. Das mit lsof werde ich mir mal genauer ansehen. Bisher hatte ich es für Files kaum mal verwendet. Ich schaue mal, ob ich zu einer Lösung komme.

/proc/$PID/exe ist immer ein symbolischer Link auf das gestartete Programm auf der Festplatte. Der Symlink läuft zwar ggf. ins leere (z. B. weil das Binary direkt nach dem Start gelöscht wurde), aber es gibt dir immerhin einen Hinweis, von wo aus es gestartet wurde.

Auch ein guter Tip, wobei er bei Interpreter Skripten leider nur begrenzten Nutzen bringt :-(

Code: Select all

sweb:~# cat test.pl
#!/usr/bin/perl
$0='httpd3';
sleep 100;
sweb:~# ./test.pl &
[1] 4967
sweb:~# ls -l /proc/4967/exe
lrwxrwxrwx 1 root root 0 2011-08-23 08:17 /proc/4967/exe -> /usr/bin/perl
sweb:~# cat /proc/4967/cmdline
httpd3sweb:~#

[Roger Wilco]

Auch ein guter Tip, wobei er bei Interpreter Skripten leider nur begrenzten Nutzen bringt :-(

In diesem Fall könntest du den Perl-Interpreter durch einen Wrapper ersetzen, der die angegebenen Parameter und z. B. das Environment loggt. Das geht im Zweifel mit einem 2 Zeilen Bash-Skript.