Frage Jemand versucht, den SSH-Zugriff auf meinen Server brutal zu erzwingen.


Diese Frage hat hier bereits eine Antwort:

Zufällig habe ich meine Server ssh log (/var/log/auth.log) angeschaut und mir ist aufgefallen, dass jemand ständig versucht Zugriff zu bekommen:

Sep  7 13:03:45 virt01 sshd[14674]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=116.31.116.42  user=root
Sep  7 13:03:48 virt01 sshd[14674]: Failed password for root from 116.31.116.42 port 13423 ssh2
Sep  7 13:03:52 virt01 sshd[14674]: message repeated 2 times: [ Failed password for root from 116.31.116.42 port 13423 ssh2]
Sep  7 13:03:52 virt01 sshd[14674]: Received disconnect from 116.31.116.42: 11:  [preauth]

Dies geschieht einige Male pro Minute und dauert schon lange an, ohne dass ich davon weiß.

Frage Sollte ich darüber besorgt sein, wenn ja: Was soll ich dagegen tun?


19
2017-09-07 11:14


Ursprung


Ja, du solltest besorgt sein. Schließen Sie den Port, wenn Sie ihn nicht öffnen müssen. Wenn Sie es öffnen müssen, können Sie iptables verwenden, um IP-Blöcke für geografische Standorte zu sperren, von denen Sie sich nie anmelden werden. Sperrt die Quelle dieser Angriffe explizit. Erwägen Sie auch, den Abhörport Ihres SSH-Dienstes zu ändern. - Jeremy Dover
verbunden : Sicherheit.stackexchange.com/questions/110706/... - Walfrat
Warum lässt du überhaupt die Passwort-Authentifizierung zu? Verwenden Sie die Tasten und deaktivieren Sie die Passwortauthentifizierung vollständig. - André Borie
Nur eine Person? Das ist ziemlich glücklich. - HopelessN00b
Mögliches Duplikat von Sicherung des SSH-Servers gegen Bruteforcing und serverfault.com/questions/4188/ ... und askubuntu.com/questions/32246/ ... und superuser.com/questions/491636/... und serverfault.com/questions/594746/ ... - TessellatingHeckler


Antworten:


Leider ist dies absolut normal und etwas, was jeder SSH-Server erlebt. Willkommen im Internet.

Solange Sie Ihren Server ordnungsgemäß sichern (z. B. halten Sie ihn auf dem neuesten Stand, erlauben Sie nur key-basierte Anmeldung, deaktivieren Sie root SSH-Zugriff), sollte dies kein Problem sein, aber Sie können dies noch weiter mit etwas wie beschränken fail2ban und andere Ansätze wie IP-Whitelisting, Portswechsel und ähnliches, soweit möglich und sinnvoll.


60
2017-09-07 11:19



Ja, es ist Business-as-usual. Das Beste, was ich gefunden habe, um diesen Spam in meinen Logs zu begrenzen, ist das Ändern des SSH-Ports. Andere Maßnahmen sind wahrscheinlich hilfreich für die Sicherheit, wie zum Beispiel dafür sorgen, dass root SSH-Logins deaktiviert sind, die Anzahl der Personen, die sich am Server anmelden können, minimieren und sicherstellen, dass sie gute Passwörter wählen. Wenn es nur Sie sind, und Sie wählen gute Passwörter, dann geht es Ihnen gut: Sie versuchen in der Regel gemeinsame Benutzername / Passwort-Kombinationen. Im Idealfall deaktivieren Sie die Passwortauthentifizierung und verwenden Sie nur ssh-Schlüssel. Dann hört der Spam vollständig auf. - Dewi Morgan
Ich war wirklich überrascht, wie viel brutales Zwang ich auf meinen Raspberry Pi bekam, nachdem ich es mit einem DDNS eingerichtet und einen Port dorthin weitergeleitet hatte ... Es ist wie jede einzelne Person auf einer belebten Straße, die versucht zu sehen, ob ihr Schlüssel auf Ihrem funktioniert Auto. - Captain Man
fail2ban ist ein unentbehrliches Werkzeug für jeden Server mit einer öffentlichen oder nattierten IP-Adresse. Mein Netzwerk wurde kürzlich auch von dieser Adresse angesprochen, und nach ein paar Tagen fing ich an, anderen Verkehr zu sehen, also habe ich iptables verwendet, um das gesamte / 24 zu blockieren. Sie können das gleiche mit iptables -A INPUT -s 116.31.116.0/24 -j REJECT tun - Rache
Log-basierte Verbotspakete haben den Nachteil, dass jeder Dienst, der sich in syslog einloggen oder / dev / log verwenden kann, jeden davon abhalten kann, SSH zu verwenden. Wenn Sie etwas wie Suricata oder Snort verwenden, ist das zwar für nur einen Server ein Overkill, aber wenn Sie ein Netzwerk zum Schutz haben, ist ein IDS / IPS-System nicht gerade ein Luxus. - John Keates


  1. Blockiere die IP mit deiner Firewall (iptables oder was auch immer dein Dienst anbietet). Ja, sie könnten IPs ändern, aber sie dazu bringen, die Arbeit zu machen
  2. Wenn Sie über eine externe Firewall verfügen (d. H. Über die AWS-Konsole können Sie Zugriffsregeln über eine Webseite festlegen), sollten Sie den Port 22 auf JUST beschränken. In diesem Fall müssen Sie nicht mit fail2ban herumhantieren
  3. Wie in den Kommentaren erwähnt, wechseln Sie zu schlüsselbasierte Authentifizierung und deaktivieren Sie die Kennwortauthentifizierung
  4. Deaktivieren Sie Root-Logins. Fügen Sie dies hinzu /etc/ssh/sshd_config

    PermitRootLogin no
    

    Lasst sie einfach alles rocken, was sie wollen. So werden sie nie kommen.


20
2017-09-07 13:03



"Lass sie die Arbeit machen". Aber du machst genau so viel Arbeit wie sie in diesem Szenario und möglicherweise mehr. Dies ist ein Verlustszenario.
@DoritoStyle Also ... blockiere nicht jemanden, der deinen Server mit Anfragen hämmert? Das macht keinen Sinn. Ich hatte mehrere Low-Key-Angriffe von einer einzigen IP ausgeführt. Ich werde dich nicht vor DDOS retten, aber das ist hier nicht möglich - Machavity
Wenn Sie im Laufe des Tages mehr als ein Dutzend Angriffe von eindeutigen IPs erhalten, werden Sie schnell einen großen Teil des Tages damit verbringen, IPs zu blockieren. Etwas wie fail2ban macht das automatisch und ist viel besser (Das wäre eine ausgezeichnete Bearbeitung für Ihre Antwort). Wenn es nur wenige SSH-Anforderungen sind, sollte dies die Leistung nicht beeinträchtigen, es sei denn, es wird auf DDOS-Level eskaliert. Auf jeden Fall freue ich mich, einen Chatroom für weitere Diskussionen zu starten.


Zusätzlich zur Sicherung des Servers, wie Sven es hervorhebt, ist eine der besten Sachen (besonders wenn ssh für dich da ist, der Admin), nur den sshd Port vom Standard weg zu ändern 22.

Es ist nicht nur einfach (vor allem, wenn Sie einen neuen Port in Ihre ~/.ssh/config Sie müssen also nicht jedes Mal tippen) und es wird 99% dieser automatisierten Scans stoppen, so dass Sie sie nicht einmal sehen werden, aber es wird auch etwas helfen, selbst wenn Sie feststellen, dass eine 0-Tage-SSH-Schwachstelle mehr gibt Zeit, oder Sie Schlüssel ist durchgesickert usw.


9
2017-09-07 13:42



Sicherheit durch Dunkelheit ist es nicht. Alles, was Sie erreichen, ist, Leute, die eine legitime Notwendigkeit haben, über SSH / SFTP mit Ihrem Server zu verbinden, um einen nicht standardmäßigen Port zu verwenden, der das InfoSec-Team auffordert, eine Firewall-Regel zu genehmigen, die diese Verbindung zulässt. Hört auf, meine Arbeit schwieriger zu machen, um die falsche Illusion verbesserter Sicherheit zu schaffen. - Monty Harder
@MontyHarder Wikipedia definiert Sicherheit durch Dunkelheit wie "das Vertrauen auf die Geheimhaltung des Designs oder der Implementierung als die wichtigste Methode zur Gewährleistung von Sicherheit.". Im Gegensatz dazu verwendet diese Methode den Port als einen kleinen zusätzlich Geheimnis. Offensichtlich hat dies Kosten (Unannehmlichkeiten) im Vergleich zu wenig Nutzen bei der Annahme eines sicheren SSH-Servers. Allerdings folge ich dem Argument einer kritischen 0-Tage-SSH-Schwachstelle. Es gibt viele viel weniger wirksame, nervigere Schlangenöllösungen, die weithin akzeptiert werden ... - Zulan
Ändern Sie die Ports, und Sie erhalten zusätzliche Portscans anstelle von SSH-Anmeldeversuchen. - Dmitry Grigoryev
@MontyHarder Es geht nicht einmal um "Sicherheit durch Dunkelheit". Wenn ich meinen Server auf einem Nicht-Standard-Port betreibe, reduziere ich einfach das Skript-Kiddie-Rauschen, das es einfacher macht, zu sehen echt gezielte Angriffe. - Martin Tournoij
@DmitryGrigoryev Wenn Sie gezielt angesprochen werden, ja. Aber 99% sind automatisierte Sonden, die nicht stören (sie können Zehntausende andere Server versuchen, anstatt sich auf Ihren EINEN zu konzentrieren - es ist einfach nicht kosteneffektiv). Und wenn sie auf Port-Scans zurückgreifen müssen, können Sie sie automatisch erkennen und autoblockieren, bevor sie eine Chance haben, ssh oder einen anderen Nicht-Standard-Port-Dienst anzugreifen (über portsentry und Freunde). - Matija Nalis


Dieses ziemlich normale Verhalten. Ich bekomme mehrere tausend von denen jeden Tag, und ich nehme an, sogar das ist winzig verglichen mit dem, was große Unternehmen gegenüberstehen.

Aber musst du dir Sorgen machen?

  • Hast du installiert? fail2ban?
  • Hast du die root ssh Anmeldung deaktiviert?
  • Hast du den User www-data von ssh login geblockt?
  • (optional) Hast du deaktiviert Passwort-basierte Anmeldung zugunsten der öffentlichen Schlüsselanmeldung?
  • (optional) Hast du den SSH Port von 22 auf etwas anderes geändert?
  • (optional) Haben Sie ein hinzugefügt? TOTP Pam Modul für die Anmeldung?

Wenn ja, brauchen Sie sich keine Sorgen zu machen. Bei diesen Angriffen handelt es sich normalerweise um wörterbuchbasierte Angriffe auf häufig verwendete UNIX-Benutzernamen. Zum Beispiel sehe ich häufig, dass diese "Benutzer" sich anmelden:

  • Wurzel
  • www-Daten
  • Prüfung
  • Administrator

ich Ja wirklich empfehlen zu installieren fail2banDa jeder Benutzer, der versucht, sich aufgrund seiner IP-Adresse anzumelden, einen Grenzwert für den größten Teil des schädlichen Datenverkehrs herausfiltern kann. Im Gegensatz zu dem, was andere sagen, bin ich kein Befürworter der IP-basierten Blockierung. Das scheint eine sehr grobe Lösung für ein sehr feines Problem zu sein. Außerdem kontrollieren diese Angreifer normalerweise mehrere ips. Selbst wenn Sie mehrere (oder sogar mehrere ip-Blöcke) blockieren, gibt es keine Garantie, dass Sie alle blockieren. Fail2ban ist jedoch für diese Szenarien sehr flexibel.


7
2017-09-07 14:59