it-swarm.com.de

Wurde mein SSH-Server kompromittiert? Wenn ja, wie und welche Schritte sollte ich unternehmen?

Ich habe kürzlich ssh-Zugriff auf meinen Computer aktiviert, um mit meinen Klassenkameraden an einem Gruppenprojekt zu arbeiten. Ich habe die Anleitung zum Einrichten von ssh auf Ubuntu gelesen und versucht, gute Sicherheitsmaßnahmen zu befolgen. Ich habe die Kennwortauthentifizierung deaktiviert, daher war der Zugang nur mit RSA-Schlüsseln möglich. In der Datei "authorized_keys" waren nur zwei Schlüssel aufgeführt: meine eigenen (die ich beim Testen verwendet habe, um festzustellen, ob ssh ordnungsgemäß funktioniert hat) und ein Freund.

An diesem Abend war ich neugierig zu sehen, ob mein Freund in mein System aufgenommen wurde, während ich es benutzte, also googelte ich nach einem Befehl, der mir sagen würde, ob jemand aufgenommen wurde und wenn ja, wer. Das Ergebnis war:

Sudo netstat -tnpa | grep ESTABLISHED.*sshd

Ich habe es versucht und die Ausgabe war:

tcp        0      0 192.168.1.86:22         59.47.0.150:44728       ESTABLISHED 7416/sshd: [accepte

Das sah nicht richtig aus. Ich kontaktierte meinen Freund und er versicherte mir, dass er nicht eingeloggt war. Ich versuchte es erneut und sah:

tcp        0      0 192.168.1.86:22         59.47.0.150:44728       ESTABLISHED 7416/sshd: root [pr

Zu diesem Zeitpunkt war ich ein wenig durch das Wort "root" ausgeflippt und habe einen Freund benachrichtigt, der mehr über dieses Zeug wusste als ich. Er sagte mir, ich solle versuchen:

 ps aux | grep ssh

welche ausgegeben:

root      3702  0.0  0.0  61364  2872 ?        Ss   Apr12   0:00 /usr/sbin/sshd -D
root      7473  0.0  0.0 112692  3920 ?        Ss   20:46   0:00 sshd: root [priv]   
sshd      7474  0.0  0.0  62784  1516 ?        S    20:46   0:00 sshd: root [net]    
sid       7476  0.0  0.0  22476   936 pts/1    S+   20:46   0:00 grep --color=auto ssh

Jetzt war ich gründlich durchgedreht, und obwohl ich ein bisschen warten wollte, um herauszufinden, wer angemeldet war, entschied ich mich für Sudo stop ssh.

Nach einigem weiteren googeln habe ich herausgefunden, dass 59.47.0.150 eine IP in/bei Shenyang, China, ist und speziell für böswillige Angriffe bekannt zu sein scheint.

Meine Fragen an euch sind also:

  1. Können wir mit Sicherheit sagen, dass eine IP aus China irgendwie SSH in meine Maschine gesteckt hat? Auch wenn es nur RSA-Schlüsselautorisierung akzeptiert?

  2. Können wir mit Sicherheit sagen, dass er/sie auch Root-Zugriff hat? In meiner ssh-config hatte ich den Standardwert PermitRootLogin without-password. Ich dachte ursprünglich, dass dies bedeutete, dass Root-Login nicht erlaubt war (ich kenne die beiden Klänge als widersprüchlich, aber ich hatte es gegoogelt und das war das Ergebnis, das ich bekam)

  3. Wenn das so ist, wie?

  4. Kann ich auf irgendeine Weise sehen, welcher Schaden bisher angerichtet wurde?

  5. Wie kann ich mich in Zukunft davor schützen? Ich muss immer noch ssh ausführen, um mein Gruppenprojekt abzuschließen.

Vielen Dank für jede Hilfe, die Sie anbieten können!

BEARBEITEN: Gemäß dem Vorschlag von saiarcot895 und Steven habe ich auth.log überprüft, wobei die folgenden Zeilen häufig wiederholt wurden:

    Apr 13 20:43:50 PrometheusU sshd[7392]: PAM 2 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=59.47.0.150  user=root
Apr 13 20:43:55 PrometheusU sshd[7394]: reverse mapping checking getaddrinfo for 150.0.47.59.broad.bx.ln.dynamic.163data.com.cn [59.47.0.150] failed - POSSIBLE BREAK-IN ATTEMPT!
Apr 13 20:43:55 PrometheusU sshd[7394]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=59.47.0.150  user=root
Apr 13 20:43:58 PrometheusU sshd[7394]: Failed password for root from 59.47.0.150 port 54813 ssh2
Apr 13 20:44:03 PrometheusU sshd[7394]: message repeated 2 times: [ Failed password for root from 59.47.0.150 port 54813 ssh2]
Apr 13 20:44:04 PrometheusU sshd[7394]: Received disconnect from 59.47.0.150: 11:  [preauth]

Bedeutet dies, dass der Angreifer in mein System gelangt ist und sich nicht beim Root anmelden konnte, oder dass er versucht, direkt auf den Root zuzugreifen, fehlgeschlagen ist und überhaupt nicht auf etwas zugegriffen hat?

3
user1340033

Können wir mit Sicherheit sagen, dass eine IP aus China irgendwie SSH in meine Maschine gesteckt hat? Auch wenn es nur RSA-Schlüsselautorisierung akzeptiert?

Es ist unwahrscheinlich, dass sie authentifiziert wurden, es sei denn, es gelang ihnen, einen gültigen Schlüssel zu erhalten. Versuchen Sie, eine Verbindung von einem Host herzustellen, den Sie ohne Schlüssel steuern, und überprüfen Sie die ausgeführten Prozesse. Sie sollten dem ähnlich sein, was Sie gesehen haben. Die Tatsache, dass der [net] -Prozess als sshd ausgeführt wird, zeigt an, dass die Anmeldung nicht erfolgreich war.

Können wir mit Sicherheit sagen, dass er/sie auch Wurzel bekommen hat? In meiner ssh-config hatte ich den Standardwert PermitRootLogin without-password. Ich dachte ursprünglich, dass dies bedeutete, dass Root-Login nicht erlaubt war (ich kenne die beiden Klänge als widersprüchlich, aber ich hatte es gegoogelt und das war das Ergebnis, das ich bekam)

Die von Ihnen verwendete Option ermöglicht Anmeldungen als root, deaktiviert jedoch die Kennwortauthentifizierung für root. Es wird empfohlen, keine Root-Anmeldungen über SSH zuzulassen, es sei denn, Sie benötigen sie wirklich. Wenn Sie den Zugriff so stark wie möglich einschränken. Sofern Sie keinen Schlüssel aktiviert haben, ist es unwahrscheinlich, dass Sie sich mit SSH als Root anmelden können. Der without-password deaktiviert kennwortbasierte Anmeldungen, aber nicht die Kennwortauthentifizierungsmethode.

Wenn das so ist, wie?

Sie können das Authentifizierungsprotokoll überprüfen, um festzustellen, ob die Authentifizierung erfolgreich war. Wenn sie jedoch erfolgreich waren, haben sie möglicherweise die Beweise überschrieben.

Kann ich auf irgendeine Weise sehen, welcher Schaden bisher angerichtet wurde?

Wenn Sie ein Rootkit-Überprüfungsprogramm ausführen und die Dateisignaturen offline überprüfen, sollte angegeben werden, ob Dateien kompromittiert wurden. Durch das Offline-Speichern von Dateisignaturen, während Sie sicher sind, erhalten Sie eine Baseline.

Wie kann ich mich in Zukunft davor schützen? Ich muss immer noch ssh ausführen, um mein Gruppenprojekt abzuschließen.

sshd unterstützt die Verwendung von tcpwrappern, um den Zugriff einzuschränken. Erstellen Sie einen Regelsatz, der nur den Zugriff von Adressbereichen zulässt, von denen Sie Datenverkehr erwarten.

3
BillThor

Wenn es sich nur um einen Brute-Force-Angriff handelt, der Protokolle füllt, ändern Sie einfach den Port.

Die meisten Skripte sind dumm und es gibt genügend Server, die auf Port 22 lauschen. Ich habe meinen immer auf z. 30200 oder 225. Dies kann mit Leichtigkeit in der getan werden

/etc/ssh/sshd.conf

Ändern Sie einfach die Portnummer und starten Sie den Daemon neu.

Auf das System kann dann mit einer zusätzlichen Option zu ssh zugegriffen werden

ssh -p224 [email protected]

Ma Logs füllten sich immer, ich wechselte den Port und der Lärm war weg.

1
s1mmel

Es finden viele ssh-Brute-Force-Angriffe statt. Es ist möglich, dass Sie ein veraltetes ssh-Paket haben, und sie sind auf diese Weise gekommen.

Überprüfen Sie die Protokolle auf SSH-Fehler. Vielleicht übt er einfach eine brutale Gewalt gegen Sie aus.

gehe zu/tmp und poste seine Ausgabe von ls -al. Wenn es ein Root-Kit gibt, wird es möglicherweise dort angezeigt.

Sie können Benutzer in ssh zulassen und fail2ban ist ebenfalls nützlich.

Setzen Sie/tmp und/home in fstab als nicht ausführbar, wenn dies möglich ist.

1
Steven Jones