☰

Werden viele SSHD-/Root-Prozesse von PS aufgelistet, Brute-Force-SSH-Hackversuch?

tag-icon • tag-icon linux ssh security
Werden viele SSHD-/Root-Prozesse von PS aufgelistet, Brute-Force-SSH-Hackversuch?

Wenn ich dies mache, ps -efHsehe ich häufig Folgendes, wobei 14:24 im Grunde die aktuelle Systemzeit ist. Diese Prozesse tauchen jede Minute wieder auf.

root      6851     1  0 14:24 ?        00:00:00   sshd: root [priv]
sshd      6852  6851  0 14:24 ?        00:00:00     sshd: root [net]
root      6869  6851  1 14:24 ?        00:00:00     sshd: root [pam]
root      6861     1  0 14:24 ?        00:00:00   sshd: root [priv]
sshd      6863  6861  0 14:24 ?        00:00:00     sshd: root [net]
root      6874  6861  0 14:24 ?        00:00:00     sshd: root [pam]
root      6865     1  0 14:24 ?        00:00:00   sshd: root [priv]
sshd      6866  6865  0 14:24 ?        00:00:00     sshd: root [net]
root      6875  6865  0 14:24 ?        00:00:00     sshd: root [pam]
root      6872     1  1 14:24 ?        00:00:00   sshd: root [priv]
sshd      6873  6872  0 14:24 ?        00:00:00     sshd: root [net]
root      6876  6872  0 14:24 ?        00:00:00     sshd: root [pam]

Bedeutet dies, dass jemand versucht, das Root-Passwort auf diesem Rechner über SSH mit roher Gewalt zu erraten? Oder handelt es sich um etwas weniger Übles?

Antwort1

Bedeutet dies, dass jemand versucht, das Root-Passwort auf diesem Rechner über SSH mit roher Gewalt zu erraten? Oder handelt es sich um etwas weniger Übles?

Es könnten Brute-Force-Versuche über SSH sein, aber selbst wenn es „schändlich“ wäre, würde es mir keine schlaflosen Nächte bereiten. Fast jeder öffentlich zugängliche Server im Internet wird ständig von Angreifern untersucht. Jemand, der virtuell „das System auskundschaftet“, ist kein Grund zur Sorge; ein tatsächliches Eindringen in das System schon.

Ich habe gerade auth.logeinen öffentlichen Server überprüft, den ich verwalte, und habe über 2.000 Versuche mit fehlgeschlagener Authentifizierung in den letzten 24 Stunden gezählt, wenn ich diesen Befehl ausführe:

sudo grep "authentication failure;" /var/log/auth.log | wc -l

Klingt beängstigend, aber mal ehrlich, wen kümmert das? Eine schnelle visuelle Überprüfung der Protokolleinträge auth.logmit einer leicht modifizierten Version des obigen Befehls:

sudo grep "authentication failure;" /var/log/auth.log

…zeigt mir Sachen wie diese:

Mar 15 07:02:09 hostname sshd[2213]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=115.239.228.35  user=root
Mar 15 07:02:19 hostname sshd[2236]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=115.239.228.35  user=root
Mar 15 07:02:31 hostname sshd[2355]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=115.239.228.35  user=root

Beachten Sie, dass alle Zugriffsversuche auf das rootKonto erfolgen? Auf jedem System, das ich einrichte, rootwerden sie sofort kastriert. In meinem Fall sind diese Versuche also erfolglos. Wenn Sie also Ihr Konto überprüfen auth.logund zahlreiche Versuche sehen, sshüber das rootKonto auf das System zuzugreifen, stellen Sie sicher, dass rootdas Konto Ihres Systems vollständig deaktiviert ist, um dieses Problem von der Liste zu streichen.

Wenn Sie neben den rootKontoversuchen Zugriffe scheinbar zufälliger Benutzernamen auf Ihr System feststellen, ist dies ebenfalls ein weiterer Versuch, sich in das System einzuhacken. Und sofern diese Benutzernamen nicht mit einem Benutzernamen auf Ihrem System übereinstimmen, würde ich mir darüber auch keine Sorgen machen.

Einige Systemadministratoren würden sagen, die beste Lösung für dieses Problem wäre, die Kennwortauthentifizierung von SSH einfach vollständig zu deaktivieren und nur SSH-Schlüsselpaare zu verwenden, aber ich neige dazu, das für übertrieben zu halten. Ich sage nicht, dass SSH-Schlüsselpaare schwach sind – das sind sie nicht –, aber wenn die Zugriffsmethoden eines Systems vom ersten Tag an vernünftig und sicher eingerichtet sind und die Kennwörter robust genug sind, um nicht so leicht gehackt zu werden, ist das System ziemlich sicher. Das liegt daran, dass die größte Schwachstelle auf modernen Webservern die nach vorne gerichtete Webanwendung ist, die tatsächlich auf dem Server selbst ausgeführt wird, und nicht Dinge wie SSH.

Letzten Endes würde ich mir über diese Art von zufälligen „War Dialing“-Versuchen keine Sorgen machen, sondern vorbeugend und rational sicherstellen, dass der Server selbst das rootBenutzerkonto deaktiviert hat. Wenn Sie im Jahr 2015 immer noch einen öffentlichen Server mit rootaktiviertem Konto betreiben, werden Sie sich auf lange Sicht im Grunde Kopfschmerzen bereiten.

verwandte Informationen