Server gehackt?

5

5ky

New Member
Hallo,

ich habe auf meinem Server IspCP laufen. Gestern wollte ich ein Update von 1.05 auf das aktuelle 1.06 machen, als ich bemerkte, dass mein Root-Passwort nicht mehr ging.

Ich habe den SSH-Zugang auf einem Anderen Port laufen und den Root-Login verboten. Ich muss mich also zuerst über SSH mit meinem Benutzer anmelden und kann dann mit "su"->RootPasswort auf den Root gelangen und entsprechend weiterarbeiten.

Das Passwort funktionierte gestern nicht mehr wirklich. Immer ein Authentification Error.
Ich musste das Root-Passwort über meine Controlsoftware vom Provider neu vergeben und konnte dann fortfahren.

Daraufhin habe ich nun neben dem Root-Passwort auch das Passwort des SSH-Benutzers geändert. Dennoch habe ich ein ungutes Gefühl.

In meinen Log-Files geht nichts sonderliches heraus. Auch der Traffic hält sich im Normalen Bereich. Bei "top" kann ich auch nichts sonderbares feststellen.

Was meint Ihr dazu bzw. wo kann ich noch auf die Suche nach evtl. Backdoors oder weiß der Geier was gehen?
Sollte ich mit dem Gedanken spielen, das komplette System neu aufzusetzen.

MfG
5ky
 
Schau mal nach offen Ports. In der Regel muss ja der Cracker irgendwie wieder auf deinen Server kommen.

Ist vielleicht irgendwo eine PHP-Shell installiert worden?
 
Also netstat liefert mit sowiet eigentlich auch nichts sonderliches. Abgesehen davon sagen mir die angezeigten Werte leider ned allzuviel. Er hat hier ein paar TCP Verbindungen die auf LISTEN stehen. u.a. *:mysql.
In der 2. Zeile steht ein *:submission? Klingt böse???

Wie kann ich feststellen ob eine PHP-Shell installiert wurde?
 
5ky said:
Wie kann ich feststellen ob eine PHP-Shell installiert wurde?
Click to expand...

Deine ganzen Daten durchsuchen, ob irgendwo eine Datei ist, mit der man bei dessen Aufruf Shell-Befehle ausführen kann

kannst nach folgenden Textkombinationen suchen, wenn sowas in einer PHP Datei vorkommt, dann ist's evtl eine:

exec
shell_exec
system
 
5ky said:
Sollte ich mit dem Gedanken spielen, das komplette System neu aufzusetzen.
Click to expand...
Einzig sinnvolle Antwort: Ja.
Zuvor ein Image des vollständigen Systems zur weiteren Analyse des Einfalltors erstellen. Diese Analyse bitte read-only in einer virtuellen Maschine Deiner Wahl durchführen und erst wenn Du das Einfalltor identifiziert, zuverlässig geschlossen und Deine Securitypolicy entsprechend angepasst hast, kannst Du den Server neu aufsetzen. Bis dahin bleibt die Kiste zu Deinem eigenen und unserem Schutz vom Netz.
 
OMG.

Ich hab nun mit:
HTML: 
find . -type f -name *.php -exec grep -l -i exec '{}' \;
allein mal nach dem Wort "exec" in PHP Dateien gesucht. Äh Sorry aber da kommen Tausende von PHP Dateien die dieses Wort beinhalten. Sei es von PHPMYADMIN, vom IspCp selbst oder von den ganzen Joomla-Installationen.

Den Server abschalten ist nicht ganz so einfach, da ich nicht alleine auf dem Server bin und dazu ja auch der komplette Mail-Verkehr aus währe.

Pfuuuh... Ruhig bleiben...

Wie würdet Ihr weiter vorgehen?
 
Ist das jetzt wirklich sinnvoll??? Solange ich noch nicht weiß, ob es überhaupt ein Hacker war und wenn es einer war, wird es ein leichtes sein, über die selbe Lücke erneut ins System zu dringen.

Da mach ich mir Stundenlange arbeit dafür, dass er morgen vermutlich wieder daher kommt. Wie gesagt wenns denn wirklich einer war.
 
Da Du einen Einbruch nicht definitiv zu 100% ausschliessen kannst, bleibt nur die von mir öben beschriebene Vorgehensweise. Alles Andere hilft weder Dir noch Deinen "Kunden". Lieber ein paar Tage offline sein, als Deinen "Kunden" aus Mangel an Verantwortung und Erfahrung kündigen zu müssen. Das kann sehr schnell sehr teuer werden, ebenso wie etwaige Anzeigen gegen Dich, weil Dein Server für illegale Tätigkeiten missbraucht wird.

Betrachte es als das längst überfällige Lehrgeld, welches man zahlen muss, wenn man nicht weiss, was man tut...
 
5ky said:
Ist das jetzt wirklich sinnvoll???
Click to expand...


Ja, Joe User hat es im wesentlichen schon gesagt, was getan werden muss.
Für Dich ist eines nun ganz wichtig:
Das nötige Fachwissen erlangen um die Ursache und den potentiellen Einbruch ermitteln zu können.

Alles andere bringt nichts.
 
Wo finde ich etwaige Einträge, wann Benutzerpasswörter verändert wurden?
Da ich ja gestern selbst vom Root und vom Benutzer die Passwörter geändert habe, müsste ich ja allein das irgendwo in einem Logfile stehen haben oder?
 
Je nach Konfiguration wird der Vorgang an sich über die AUTH Facility durchaus geloggt:
Code: 
Aug 21 18:45:49 example-host passwd[8464]: pam_unix(passwd:chauthtok): password changed for root
 
Au ja das hat mir glaubich schonmal BISSCHEN geholfen.

Ich hab mir sämtliche auth.logs auf den Rechner geholt und mal durchsucht.

Hier fand ich natürlich auch den Eintrag von gestern, als ich mein Benutzerpasswort geändert habe.

Allerdings finde ich nichts dergleichen, dass irgendwann auch das Root in den letzten Monaten geändert wurde.

Einzigen Eintrag ist:
HTML: 
can't view or modify password information for root

Das glaubich hängt aber wohl damit zusammen, dass der Root sich ja nicht per SSH einloggen darf oder?

Werd da wohl oder übel fleißig dran bleiben MÜSSEN...
 
Passwörter lassen sich auch ganz einfach ohne passwd setzen, editieren der entsprechenden Files genügt und wird nicht geloggt. Desweiteren lassen sich alle lokalen Logs problemlos von jedweden Spuren bereinigen. Letzteres beherrscht mitlerweile auch jedes leicht fortgeschrittene Scriptkiddie, bei professionelleren Crackern gehört dies seit Jahrzehnten zum Standardrepertoire.

Mit anderen Worten: Nach einem Einbruch kann man lokalen Logs nicht mehr vertrauen.
 
You must log in or register to reply here.
Back
Top