PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Server gehackt?



Seiten : [1] 2 3

heatwalker
24.03.07, 21:25
Mahlzeit,
ich weiss das der Titel wirklich aussagekräftig ist, aber was besseres viel mir nicht ein.


Seit Donnerstag habe ich ein Problem mit unserem Server.
Unser System ist ein SLOX 4.1 (Enterpriseserver 8.0, 2.4 Kernel)
Das System wird regelmässig upgedate und ist auf dem letztmöglichen Stand.
(Was das Distributionsupdate betrifft).

Irgendein perl script haut mir die Systemlast auf 90 Prozent.
Erste Überprüfungen ergaben das diesesScript eine Verbindung zu einem externen Server auf Port 8080 aufgebaut hat.

Als erste Massnahme habe ich dann den webmaster dieses Server angemailt und auf meiner Firewall Verbindungsversuche von diesem Server per Regel unterbunden.

Am Freitag ging die Klamotte dann wieder los. Nur von einem anderen Server aus.
Diesen habe ich dann auch in die Regel eingebunden und als zusätzliche Sicherheit jeden Verkehr (ausser Smtp, NTP und DNS) aus der DMZ verboten.

Die aktivität dieses perlscript lies sich ausserdem nur durch einen Reboot des gesamten System ausschalten.

Eine Überprüfung heute abend auf dem Server ergab, das schon wieder dieses ominöse Perlscript läuft. Verbindungsaufbauten laufen allerdings nur auf Localhost.

Eine Überprüfung der Firewall Logs zeigt mir das vom Server ein Verbindungsaufbau nach draussen versucht wird, der von der Firewall abgelehnt wird. Laut Log werden SYN Floods nach draussen geschickt.

Hat jemand eine Idee wie ich herausfinden kann wo das Problem liegt bzw. das Stück Software??


lsof -i | grep perl
perl 23050 wwwrun 8u IPv4 12518891 TCP localhost:39335->localhost:http-alt (ESTABLISHED)
perl 23050 wwwrun 18u IPv4 1720904 TCP *:https (LISTEN)
perl 23050 wwwrun 19u IPv4 1720905 TCP *:http (LISTEN)
perl 23052 wwwrun 8u IPv4 12517627 TCP localhost:39331->localhost:http-alt (ESTABLISHED)
perl 23052 wwwrun 18u IPv4 1720904 TCP *:https (LISTEN)
perl 23052 wwwrun 19u IPv4 1720905 TCP *:http (LISTEN)

Danke schonmal

Nebuchadneza
24.03.07, 22:43
Schau doch mal mit


ps aux | egrep perl

Damit solltest du sehen, wo das Perl-Skript liegt

bla!zilla
25.03.07, 00:02
Um welches Skript handelt es sich? Sehe ich das richtig das die Verbindungen von nach localhost gehen? Hast du dir das Skript mal angesehen?

heatwalker
25.03.07, 11:59
sorry, bin gerade erst wieder online.

Vorab, ich habe gestern abend den Server erst einmal wieder rebootet.

Zur Zeit laufen diese zwei Perl Prozesse nicht.

Ein ps aux | egrep perl ergibt

oot 808 0.0 3.2 27292 25420 ? S Mar24 0:01 /usr/bin/perl -T -w /usr/sbin/spamd -d -c -a
root 928 0.0 0.5 5284 3900 ? S Mar24 0:02 /usr/bin/perl -w /usr/lib/sysMonitor/rrdtimer Dp
root 944 0.0 0.8 8196 6332 ? S Mar24 0:00 /usr/bin/perl root 1168 0.0 0.4 5404 3864 ? S Mar24 0:00 /usr/bin/perl -w /usr/sbin/mailgraph.pl -l /var/log/mail
root 29567 0.0 0.0 1624 564 pts/0 S 11:54 0:00 /bin/grep -E perl

@Blazilla: Die Verbindungen gehen momentan auf den Localhost. Würde ich die Firewall Regeln wieder abändern, gäb es einen Verbindungsaufbau zu einem Schlundserver. Von diesem Server sind auch die ersten Portscans ausgegangen.

Wenn ich wüsste welches Script hier läuft, hätte ich ein Problem weniger.

Ansonsten muss ich jetzt warten bis der Prozess wieder läuft.

Danke erstmal.

EDIT: Hab gestern noch die /etc/passwd überprüft und festgestellt das hier als loginshell die /bin/bash eingestellt ist.
Laut Timestamp gab es aber keine Änderungen. Jedenfalls habe ich das auf /bin/false geändert, da der perl prozess mit wwwrun ausgeführt wird.

Eiin Check mit rkhunter und chkrootkit hat auch keine weitere Erkenntnisse gebracht.

bla!zilla
25.03.07, 12:38
EDIT: Hab gestern noch die /etc/passwd überprüft und festgestellt das hier als loginshell die /bin/bash eingestellt ist.
Laut Timestamp gab es aber keine Änderungen. Jedenfalls habe ich das auf /bin/false geändert, da der perl prozess mit wwwrun ausgeführt wird.

Den Timestamp einer Datei kann man mit touch ändern.



Eiin Check mit rkhunter und chkrootkit hat auch keine weitere Erkenntnisse gebracht.

Hast du dir den Schlundserver, zu dem die Verbindungen gehen mal genauer angesehen. Auf jeden Fall mal den Support von Schlund einschalten.

Woher weißt du denn das es sich um ein Perlskript handelt, wenn du nicht weißt welches Skript da überhaupt läuft?

heatwalker
25.03.07, 12:44
Schlund hat schon eine mail von mir diesbezüglich.

Wenn Du Dir die lsof Ausgabe von mir anschaust, siehst du das ein perlprozess läuft.

Darauf hin hatte ich per "ps" nachgeschaut und passend dazu liefen zwei
perlprozesse die sonst nicht laufen.
Leider habe ich keine Hinweise darauf gefunden auf welche Datei zugegriffen wird.

Bis jetzt hat sich auf dem System auch nichts getan.

Sobald sich was rührt werde ich noch mal alle ausgaben prüfen.
Falls jemand noch eine Idee hat, welche Programme ich in diesem Zusammenhang noch nutzen kann, immer her damit. :o

bla!zilla
25.03.07, 12:49
Schau mal mit ps ef nach welches Skript da dann ausgeführt wird.

heatwalker
25.03.07, 12:55
Werde ich machen :)

baumgartner
25.03.07, 13:20
Nur mal so zur Info, einen verdächtigen Server NIE rebooten ohne vorher mal folgendes gemacht zu haben:

ps -ef > collection.txt
lsof >> collection.txt
lsmod >> col..
dmesg >> co..

vielleicht noch nen Schnappschuss von /var/log machen...

Mehr fällt mir momentan nicht ein.

heatwalker
25.03.07, 13:48
Nur mal so zur Info, einen verdächtigen Server NIE rebooten ohne vorher mal folgendes gemacht zu haben:

ps -ef > collection.txt
lsof >> collection.txt
lsmod >> col..
dmesg >> co..

vielleicht noch nen Schnappschuss von /var/log machen...

Mehr fällt mir momentan nicht ein.

Danke für die zusatzinfos. Du hast natürlich recht.

Bevor ich das System neu gebootet wurde, hatte ich schon einiges nachgeschaut.

Damit wir aber weiterarbeiten können, habe ich halt die Firewallregeln abgeändert und dann einen neustart gemacht damit die aktivität beendet wird, da kein kein kill signal den prozess beendet hat.

baumgartner
25.03.07, 14:02
oot 808 0.0 3.2 27292 25420 ? S Mar24 0:01 /usr/bin/perl -T -w /usr/sbin/spamd -d -c -a
root 928 0.0 0.5 5284 3900 ? S Mar24 0:02 /usr/bin/perl -w /usr/lib/sysMonitor/rrdtimer Dp
root 944 0.0 0.8 8196 6332 ? S Mar24 0:00 /usr/bin/perl root 1168 0.0 0.4 5404 3864 ? S Mar24 0:00 /usr/bin/perl -w /usr/sbin/mailgraph.pl -l /var/log/mail
root 29567 0.0 0.0 1624 564 pts/0 S 11:54 0:00 /bin/grep -E perlAlso wenn du spamassassin, RRD-Tools und ein Tool das dir deinen Mailverkehr monitort musst du dir wohl keine Sorgen machen um die Prozesse ;)

bla!zilla
25.03.07, 14:07
Die Prozesse sind normal bei einem SLOX. Die setzt der mit auf, um dir z.B. die Auslastung der Maschine grafisch darzustellen.

heatwalker
25.03.07, 15:00
@blazilla: Richtig

Diese Ausgabe ist von heute mittag. Hier sind die beiden Prozesse nicht aktiv.

Bis jetzt ist Ruhe im Saal. Aber der Tag ist noch lang. Ich kann mir nicht vorstellen das der Prozess nicht mehr auftaucht.

Mr_Maniac
25.03.07, 16:10
Kann man die Prozesse nicht per Init-Script abschalten?
Dann sollten sie sich doch eigentlich nicht mehr melden, oder?

bla!zilla
25.03.07, 16:18
Kann man die Prozesse nicht per Init-Script abschalten?
Dann sollten sie sich doch eigentlich nicht mehr melden, oder?

Ich glaube nicht das Cracker so nett sind und ihre Root-Kits per Init-Skript starten und stoppen lassen.

heatwalker
25.03.07, 21:12
Tja, als Paranoiker würde ich denken der Sack sieht das ich fast den ganzen Tag am Server hänge. :ugly:

Bis jetzt ist alles im normalen Bereich.
Hab mal alle Dateien suchen lassen, die dem webserverbenutzer gehören. :eek:

Das zu überprüfen ist ziemlich aussichtslos, weil viel zu viel. :rolleyes:

Mr_Maniac
25.03.07, 23:08
Ich glaube nicht das Cracker so nett sind und ihre Root-Kits per Init-Skript starten und stoppen lassen.

Hast du nicht vorhin selbst gesagt, dass das System-Eigene Prozesse sind (oder zumindest sein könnten)?

heatwalker
25.03.07, 23:32
Da ziehst du jetzt was aus dem Zusammenhang raus.

Blazillas Aussage traf nur auf die von mir gepostete Ausgabe "ps aux | egrep perl" zu.

Diese Prozesse haben nichts mit meinem Problem zu tun.

Wobei es seltsamerweise immer noch still auf dem Server ist.

heatwalker
26.03.07, 09:27
Guten Morgen,
nur eine kurze Rückmeldung von mir.

Am Server ist Ruhe. Warum? Keine Ahnung. Sobald es wieder losgeht,
melde ich mich mit den entsprechenden Informationen. :cool:

Bis hierhin erst einmal danke. :)

caspartroy
26.03.07, 18:38
Ich glaube nicht das Cracker so nett sind und ihre Root-Kits per Init-Skript starten und stoppen lassen.

wie starten die denn sonst (ausgenommen interaktiv natürlich)?
mir fällt da noch cron ein, vielleicht findet sich da das (evtl harmlose) perlskript.

z.B. Suse startet ab und zu Perlskripte per cronjob, da wusste ich auch nicht gleich, was und warum (war glaube ich ein update-prozess).

heatwalker
26.03.07, 20:58
Zurück zum Thema, das irgendwas läuft wieder. :(

ps -ef | grep perl

root 808 1 0 Mar24 ? 00:00:03 /usr/bin/perl -T -w /usr/sbin/spamd -d -c -a
root 928 1 0 Mar24 ? 00:00:10 /usr/bin/perl -w /usr/lib/sysMonitor/rrdtimer Dp
root 944 1 0 Mar24 ? 00:00:00 /usr/bin/perl /usr/local/webmin-1.300/miniserv.pl /usr/local/etc/webmin/miniserv.conf
root 1168 1 0 Mar24 ? 00:00:00 /usr/bin/perl -w /usr/sbin/mailgraph.pl -l /var/log/mail
wwwrun 1850 1 29 18:32 ? 00:39:10 perl
wwwrun 2320 1 64 18:36 ? 01:23:22 perl


ps -aux | egrep perl

root 808 0.0 3.2 27292 25420 ? S Mar24 0:03 /usr/bin/perl -T -w /usr/sbin/spamd -d -c -a
root 928 0.0 0.5 5284 3900 ? S Mar24 0:10 /usr/bin/perl -w /usr/lib/sysMonitor/rrdtimer Dp
root 944 0.0 0.8 8196 6332 ? S Mar24 0:00 /usr/bin/perl /usr/local/webmin-1.300/miniserv.pl /usr/local/etc/webmin/miniserv.conf
root 1168 0.0 0.5 5452 3904 ? S Mar24 0:00 /usr/bin/perl -w /usr/sbin/mailgraph.pl -l /var/log/mail
wwwrun 1850 29.1 0.4 4924 3400 ? S 18:32 39:10 perl
wwwrun 2320 65.0 0.4 4928 3404 ? R 18:36 85:00 perl

Es sind jeweils die letzten beiden prozesse.
Irgendjemand eine Idee wie ich herausfinden kann was da läuft?

lsof -i | egrep perl

perl 1850 wwwrun 8
u IPv4 21455831 TCP localhost:53872->localhost:http-alt (ESTABLISHED)
perl 1850 wwwrun 18u IPv4 222017 TCP *:https (LISTEN)
perl 1850 wwwrun 19u IPv4 222018 TCP *:http (LISTEN)
perl 2320 wwwrun 6u IPv4 76803894 TCP ns1.net2future.de:39142->s15185217.rootmaster.info:http-alt (ESTABLISHED)
perl 2320 wwwrun 8u IPv4 22515070 TCP localhost:33658->localhost:http-alt (ESTABLISHED)
perl 2320 wwwrun 18u IPv4 222017 TCP *:https (LISTEN)
perl 2320 wwwrun 19u IPv4 222018 TCP *:http (LISTEN)

oben kann man schön sehen zu welchem Server die Verbindung aufgebaut wird.

lsmod und dmesg haben überhaupt keine Auffälligkeiten,
jetzt schau ich mir noch die logs durch ob etwas auffälliges dabei ist.

Nebuchadneza
26.03.07, 22:32
Andere Idee: Kann es sein, dass die beiden perl Prozesse Kind-Prozesse der anderen bereits laufenden Prozesse sind?

Folgender Befehl gibt dir eine Baumstruktur über die Prozesse:


ps -a -o pid,args --forest

Haben die beiden evtl. einen Vaterprozess und wenn ja, welchen?

heatwalker
26.03.07, 22:46
Die beiden perl prozesse haben weder Vater- noch Unterprozesse.

Das habe ich im Vorfeld per pstree überprüft. :o

403
26.03.07, 22:56
hattest du mal ps auxwww und ps auxe gemacht um das Environment der Perl Prozesse weiter
einzugrenzen? Und was hat die Ueberpruefung von /etc/cron* ergeben? Und finden sich
Hinweise in der apache Konfiguration? Kommt der Server in der spamd Konfiguration vor?

baumgartner
27.03.07, 09:11
Was findest du denn an Infos im Proc-Verzeichnis zu den Pids? Sorry, aber bin mit dem 2.4er Kernel nicht vertraut, das war vor meiner Zeit ;)

heatwalker
27.03.07, 09:36
hattest du mal ps auxwww und ps auxe gemacht um das Environment der Perl Prozesse weiter
einzugrenzen? Und was hat die Ueberpruefung von /etc/cron* ergeben? Und finden sich
Hinweise in der apache Konfiguration? Kommt der Server in der spamd Konfiguration vor?

Guten Morgen,
bis jetzt habe ich lediglich ps aux und ps ef gemacht. Werde die beide Varianten mal ausprobieren sobald es wieder losgeht.

Die /etc/cron habe ich überprüft. Hab das ganze System nach crontabs durchsucht und dabei auch nichts gefunden.

Habe den Server erstmal wieder neugebootet und bis jetzt ist es wieder ruhig.
Es wird schätzungsweise heute abend wieder losgehen. :confused:

heatwalker
27.03.07, 09:38
Was findest du denn an Infos im Proc-Verzeichnis zu den Pids? Sorry, aber bin mit dem 2.4er Kernel nicht vertraut, das war vor meiner Zeit ;)

Im Proc Verzeichnis habe ich mir unter den beiden PID alles angeschaut.
Den lesbaren Daten konnte ich nichts entnehmen.
Ansonsten sind halt endlose Zahlenketten enthalten. Wenn es heute abend wieder losgehen sollte, werde ich die Ausgaben posten.

bla!zilla
27.03.07, 09:55
Wirf doch mal einen Packetsniffer auf die Kiste, im einfachsten Fall tcpdump und schau dir mal den Verkehr an der an den Root-Server bei 1&1 steht. Der hat ja eine Verbindung auf Port 8080 an dem Root-Server. Könnte im einfachsten Fall ein Tomcat sein.

heatwalker
27.03.07, 10:06
Wirf doch mal einen Packetsniffer auf die Kiste, im einfachsten Fall tcpdump und schau dir mal den Verkehr an der an den Root-Server bei 1&1 steht. Der hat ja eine Verbindung auf Port 8080 an dem Root-Server. Könnte im einfachsten Fall ein Tomcat sein.

Ich muss wohl etwas mitteilsamer werden :rolleyes:

Danke für den Tip. Die Idee mit tcpdump und ethereal ist mir gestern Abend auch noch in den Sinn gekommen. Daraus konnte ich allerdings nicht viel herausfiltern.

Tja tomcat, hatte erst den lokalen in Verdacht er wäre vielleicht das Problem.
Allerdings geht der Aufbau auf Port 8080 ja zum rootserver.

bla!zilla
27.03.07, 10:14
"Nicht viel" heißt doch schon mal das du was gefiltert hast. ;)