Was tun nach Abuse Vorwurf SSH betreffend

Zserver

Zserver

New Member
Hallo,

wir bekamen vor kurzem eine Mail vom Provider in der uns mit folgenden Logfile Auszügen ein kompromitierter Server vorgeworfen wird.

Code: 
Lines containing IP:11.222.33.44 in /var/log/auth.log

Nov  8 03:18:39 rockthehalo sshd[5584]: Failed password for root from 11.222.33.44 port 36745 ssh2
Nov  8 03:18:39 rockthehalo sshd[5584]: Received disconnect from 11.222.33.44: 11: Bye Bye [preauth]
Nov  8 03:25:14 rockthehalo sshd[5661]: Failed password for root from 11.222.33.44 port 41338 ssh2
Nov  8 03:25:14 rockthehalo sshd[5661]: Received disconnect from 11.222.33.44: 11: Bye Bye [preauth]
Nov  8 03:31:49 rockthehalo sshd[5722]: Failed password for root from 11.222.33.44 port 38542 ssh2
Nov  8 03:31:49 rockthehalo sshd[5722]: Received disconnect from 11.222.33.44: 11: Bye Bye [preauth]



+++++++++++++++++++++++++++++

Lines containing IP:11.222.33.44 in /var/log/auth.log

Nov  8 03:18:39 rockthehalo sshd[5584]: Failed password for root from 11.222.33.44 port 36745 ssh2
Nov  8 03:18:39 rockthehalo sshd[5584]: Received disconnect from 11.222.33.44: 11: Bye Bye [preauth]
Nov  8 03:25:14 rockthehalo sshd[5661]: Failed password for root from 11.222.33.44 port 41338 ssh2
Nov  8 03:25:14 rockthehalo sshd[5661]: Received disconnect from 11.222.33.44: 11: Bye Bye [preauth]
Nov  8 03:31:49 rockthehalo sshd[5722]: Failed password for root from 11.222.33.44 port 38542 ssh2
Nov  8 03:31:49 rockthehalo sshd[5722]: Received disconnect from 11.222.33.44: 11: Bye Bye [preauth]
Nov  9 03:34:13 rockthehalo sshd[29511]: Failed password for root from 11.222.33.44 port 48995 ssh2
Nov  9 03:34:13 rockthehalo sshd[29511]: Received disconnect from 11.222.33.44: 11: Bye Bye [preauth]
Nov  9 03:41:02 rockthehalo sshd[29577]: Failed password for root from 11.222.33.44 port 37834 ssh2
Nov  9 03:41:02 rockthehalo sshd[29577]: Received disconnect from 11.222.33.44: 11: Bye Bye [preauth]
Nov  9 03:47:49 rockthehalo sshd[29645]: Failed password for root from 11.222.33.44 port 34331 ssh2
Nov  9 03:47:49 rockthehalo sshd[29645]: Received disconnect from 11.222.33.44: 11: Bye Bye [preauth]

++++++++++++++++++++++++++++



Lines containing IP:11.222.33.44 in /var/log/auth.log

Nov  8 03:18:39 rockthehalo sshd[5584]: Failed password for root from 11.222.33.44 port 36745 ssh2
Nov  8 03:18:39 rockthehalo sshd[5584]: Received disconnect from 11.222.33.44: 11: Bye Bye [preauth]
Nov  8 03:25:14 rockthehalo sshd[5661]: Failed password for root from 11.222.33.44 port 41338 ssh2
Nov  8 03:25:14 rockthehalo sshd[5661]: Received disconnect from 11.222.33.44: 11: Bye Bye [preauth]
Nov  8 03:31:49 rockthehalo sshd[5722]: Failed password for root from 11.222.33.44 port 38542 ssh2
Nov  8 03:31:49 rockthehalo sshd[5722]: Received disconnect from 11.222.33.44: 11: Bye Bye [preauth]
Nov  9 03:34:13 rockthehalo sshd[29511]: Failed password for root from 11.222.33.44 port 48995 ssh2
Nov  9 03:34:13 rockthehalo sshd[29511]: Received disconnect from 11.222.33.44: 11: Bye Bye [preauth]
Nov  9 03:41:02 rockthehalo sshd[29577]: Failed password for root from 11.222.33.44 port 37834 ssh2
Nov  9 03:41:02 rockthehalo sshd[29577]: Received disconnect from 11.222.33.44: 11: Bye Bye [preauth]
Nov  9 03:47:49 rockthehalo sshd[29645]: Failed password for root from 11.222.33.44 port 34331 ssh2
Nov  9 03:47:49 rockthehalo sshd[29645]: Received disconnect from 11.222.33.44: 11: Bye Bye [preauth]
Nov 10 03:50:13 rockthehalo sshd[18522]: Failed password for root from 11.222.33.44 port 59071 ssh2
Nov 10 03:50:14 rockthehalo sshd[18522]: Received disconnect from 11.222.33.44: 11: Bye Bye [preauth]
Nov 10 03:57:01 rockthehalo sshd[18592]: Failed password for root from 11.222.33.44 port 38490 ssh2
Nov 10 03:57:01 rockthehalo sshd[18592]: Received disconnect from 11.222.33.44: 11: Bye Bye [preauth]
Nov 10 04:03:49 rockthehalo sshd[18645]: Failed password for root from 11.222.33.44 port 36164 ssh2
Nov 10 04:03:49 rockthehalo sshd[18645]: Received disconnect from 11.222.33.44: 11: Bye Bye [preauth]
Die IP wurde von mir unkenntlich gemacht, ist aber ein von 2 IPS des Servers auf der 4 von 11 Domains laufen - die anderen 7 Domains laufen auf der 2. IP und sind somit aus dem Rennen?

Es wurde ein Frist von 3 Tagen gesetzt um "angemessen zu reagieren". Der Lieferant des Logauszuges wurde uns nicht genannt und ein Kontakt mit der Abuse Abteilung des Providers sieht so aus, das man nur Mails schicken kann, die aber jetzt bereits 1,5 Tage unbeantwortet bleiben. Telefonisch den Technischen Support erreicht und der sagte nur, das wir ja mehr wüssten wie der Support selbst und man nur ein Ticket an die Abuse Abteilung stellen könne, das die sich bei uns nochmal melden... :(

Der Root läuft seit 3 Jahren ohne Probleme. Es ist ein Root von Strato mit Opensuse und Plesk drauf. Auf den fraglichen Domains laufen u.a. Wordpress, vbulletin, Appgini, Xenforo Systeme Die Wordpress, vbulletin Systeme sind auf aktuellem Stand, von XenForo sind mir keine Sicherheitslücken mit den laufenden Versionen bekannt und Appgini ist eine Datenbanksoftware.

Kann jemand einen Tipp geben wo man mit der Suche nach einem Script auf einem Rootserver sinnvoll anfangen könnte?

Wir wollten Ende des Jahres sowieso auf einen managed Server umsteigen, aber ein Umstieg ohne das Leck gefunden zu haben wird ja auch nicht viel bringen. Wir wären für jeden Tipp dankbar.

Grüße
 
Last edited by a moderator:
Hi,

ich würde dir empfehlen zunächst fail2ban zu installieren und den ssh Port sofern du noch den Standartport 22 benutzt auf über zu 10000 setzten.
Damit hast du erstmal angemessen reagiert und kannst danach in Ruhe nach der Ursache forschen.

Fail2ban ist ein Tool, das die Logdateien nach Brute-Force Attacken überwacht egal ob ssh, Apache, Postfix usw. und die entsprechenden IP's für einen bestimmten Zeitraum sperrt.

Die Anzahl der Loginversuche und die Dauer für die Sperrung lassen sich für jeden Dienst was Logdateien benutzt, leicht an deine Bedürfnisse anpassen.

Hier mal ein Link für eine Installation unter Opensuse 10.3, dürfte aber auch für die neueren Versionen gelten. Ansonsten schreib mich einfach an wenn du Hilfe dabei brauchst.

http://www.howtoforge.de/anleitung/...force-attacken-mit-fail2ban-auf-opensuse-103/
 
Hallo!

Wenn ich es richtig verstanden habe, sind die Logauszüge die eines fremdem Servers. Die IP Adresse des eigenen Server (11.222.33.44) versucht sich via Brute Force Zugang zum SSH eines anderen Servers zu verschaffen.

Wenn dem so ist bringt die Verlegung des SSH Ports oder die Installation von fail2ban eher nichts.

mfG
Thorsten
 
Ich lese es so wie Thorsten.

Meine Vermutung:

a) Ein fehlerhaft konfiguriertes Skript, das auf ein System zuzugreifen versucht, welches es unter dieser IP-Adresse nicht mehr gibt.

b) Ein kompromittierter Benutzer mit SSH-Zugriff.

c) Eine Webshell, die entsprechende Möglichkeiten bietet.

Bei Option c) wäre es ggf. möglich als ersten Schritt Shell-Funktionen (exec, shell_exec etc), die für das Ausführen von ssh ermöglichen, zu verbieten.

Sofern die Zugriffsversuche anhalten sollte auch die Prozessliste entsprechende Hinweise liefern, zumindest welcher Benutzer hier zu Gange ist.
 
Du könntest dir einmal mit iptables loggen lassen, welcher User die Verbindungen herstellen will, sofern du das zur Verfügung hast:

Code: 
iptables -I OUTPUT -p tcp --dport 22 -m state --state NEW -j LOG --log-uid --log-prefix="IPTables: "
ip6tables -I OUTPUT -p tcp --dport 22 -m state --state NEW -j LOG --log-uid --log-prefix="IPTables: "

Das setzt natürlich voraus, dass der Rootzugang deines Server noch nicht kompromittiert wurde und du den Zielport auf den angegriffenen Systemen kennst. Die Logeinträge findest du dann im Kernelprotokoll (dmesg) und je nach System auch in den Syslogs.


MfG Christian
 
Hallo und danke für die schnelle Hilfe!

Ja, die Log-Auszüge sind die des fremden Servers - mehr hat uns Strato nicht übermittelt. Danke Thorsten, hatte mich da unklar ausgedrückt.

Der Server läuft mit OpenSuse 11.1 und Plesk 9.2.2 + aktuelle Hotfixe (an ein Plesk Update trauen wir uns nicht ran, weil man einfach zuviel liest, das es schief gegangen sei - deshalb sollte ja auch der Wechsel auf einen aktuellen Server erfolgen, zumal bei aktuellen Pleskversionen die Updates leichter sind, sein sollen.

- Die IP-Table Logs lass ich wie empfohlen mal aufzeichnen. Danke für den Tipp Christian.
- Fail2ban ist für den neuen Server schon vorgesehen gewesen und kommt 100%ig

Kann man gegebenen Falls den SSH-Dienst vorübergehend deaktivieren? Damit dürfte mit den Angriffen vorerst Schluß und Zeit für die Suche gewonnen sein, oder?

Aufgrund der Zeitstempel der Angriffe kann es doch nur ein Script sein - es sind immer gleich viele, zu den exact selben Zeiten - auf die Sekunde!. :(

@Ben
a und b möchte ich fast ausschließen - a: mit der kompromitierten Seite hatten wir noch nie was zu schaffen und b: kann ein User mit SSH Zugang die Angriffe so exakt auf die Sekunde durchziehen? Daher wäre wohl c nicht verkehrt...
Frage zu c - welche Auswirkungen auf andere gewollte Scripte/PHP etc. hätte das verbieten? Gibt es ein how to für Opensuse 11.1 wo man sich einlesen kann?

Dank euch für die Hilfe hier. :o

Grüße
 
Zserver said:
Kann man gegebenen Falls den SSH-Dienst vorübergehend deaktivieren? Damit dürfte mit den Angriffen vorerst Schluß und Zeit für die Suche gewonnen sein, oder?
Click to expand...
Nope. Nicht der Dienst ist das Problem, sondern das Dein Server als Client aktiv ist. Du könntest höchstens als Pflaster Deinen SSHd auf einen anderen Port legen und alle outgoing Pakete mit Destination-Port 22 droppen. Aber wie gesagt, das ist eher eine Verzweiflungstat als denn eine wirksame Maßnahme.

Der Missbrauch Deines Servers für SSH-Brute-Force-Angriffe deutet auf eine tiefergreifende Kompromittierung hin. Meine Empfehlung Migration schnellstens umsetzen auf ein aktuelles System.
 
Dachte ich mir... :(

Und wie geh ich dabei sicher das ich den Missbrauch nicht mit migriere? Dazu müsste ich ja erst einmal selbigen Dingfest machen, sprich tatsächlich finden oder nicht?

Ein Lücke in Horde hab ich heut noch gestopft, ob das das Einfallstor war ... ich glaubs fast nicht.

@Christian
Blöde Frage - wohin werden die Logs nach deinem Tipp eigentlich geschrieben, bevor ich die Suche auf dem Server bemüßige. ;)
 
Dein Linux wird seit Januar 2011 nicht mehr mit Updates versorgt.
Die Fehlersuche dürfte überflüssig sein, deine Software ist einfach steinalt.

Pakete mit iptables droppen könnte(!) klappen, wenn der Angreifer Rootrechte hat wird das aber auch nix.

Einzige Lösung: Daten (und nur Daten) sauber sichern und denn Server neu installieren.

Um Pakete mit Dport TCP22(Outgoing) zu droppen, muss der SSHd nicht verlegt werden, aber das ist nur ne theoretische Sache.
 
... da isser ja schon wieder. ;)

Es wurde schlicht ein SSH Zugang geknackt, der rückblickend schlecht gesichert war. Der Server wurde notdürftig gesichert und die geprüften Webhosts auf einen anderen Server umgezogen.

Auf dem neuen Server wurden dann auch direkt Versäumnisse des alten vermieden:

- SSH Port verlegt ins 5-stellige
- Root Zugang gesperrt
- Keyfilezugang
- die Software auf dem aktuellen Stand, und statt OpenSuse ein aktuelles Ubuntu LTS
- fail2ban installiert und getestet
- rkhunter und chkrootkit installiert, eingerichtet und auf cron umgestellt
- Strato Security Scan hinzugenommen der nun auch regelmäßig drüber schaut.
- Alle Wordpress Installationen von einer großzahl der Addons befreit und aktualisiert.
- Allgem. entrümpelt und von alten Testinstallationen endgültig getrennt

Denke mal damit dürften wir nun etwas besser da stehen als zuvor. Auch dank eurer schnellen Hilfe hier. Danke dafür.

Grüße
 
You must log in or register to reply here.
Back
Top