SSH Brute-Force unterbinden?

  • Hey,

    ich habe heute zum ersten mal in die Logs geschaut (/var/log/auth.log) und musste feststellen, dass hier bis zu 10 Login-Versuche pro Minute stattfinden.


    Hauptsächlich ist natürlich root das Ziel, aber selbst eigens erstellte User werden teilweise angegriffen. (vermutlich zufällig, weil auch nicht existierende User getestet werden)

    Mit grep hab ich nach erfolgreichen Logins gesucht, konnte aber glücklicherweise auf die schnelle keine finden, die nicht von mir ausgingen.


    Meine Frage: Ist das wirklich normal? Finden wirklich dauerhaft Brute-Force Angriffe auf Server statt? Oder bin ich hier außergewöhnlich stark betroffen?


    Habe nun DenyHosts oder fail2ban entdeckt, werde vermutlich eines von beiden testen. Kann jemand Erfahrungen dazu teilen?

    Oder gibt es andere Ansätze, die ich treffen könnte?

  • Ja, sowas ist durchaus normal. Als erste Maßnahme würde ich bei jedem Server SSH auf einen anderen Port legen, weg von 22, z.B. 4711. Das geht z.B, über eine Anpassung in /etc/ssh/sshd_config, etwa wenn man Port 4711 verwenden will:


    Port 4711


    Dem SSH-Client muss man dann noch mitteilen, dass man diesen Port verwenden will, statt Port 22:


    ssh user@servername -p 4711


    Bei PuTTY etc. gibt es auch eine Option dafür.


    Für root sollte SSH auch generell nicht erlaubt sein oder wenn, dann nur mit Key.

  • Meine Frage: Ist das wirklich normal? Finden wirklich dauerhaft Brute-Force Angriffe auf Server statt? Oder bin ich hier außergewöhnlich stark betroffen?

    Kommt ein bisschen auf den IP-Bereich an, in dem der Server liegt.

    Ich habe einen, da ging es praktisch instantan los mit den bots, sofort nachdem der Server online war.

    Oder gibt es andere Ansätze, die ich treffen könnte?

    Den ssh Port ändern.

    Das hilft sehr. Danach gehen bei mir die bot-Attacken auf ein Minimum runter und fail2ban hat kaum noch was zu tun.

    Gegen flächendeckende Portscans hilft das nicht, aber die Dummbots hält es ab.


    Und ne firewall halt

  • Habe nun DenyHosts oder fail2ban entdeckt, werde vermutlich eines von beiden testen. Kann jemand Erfahrungen dazu teilen?

    Nimm fail2ban. DenyHosts wird nicht mehr weiterentwickelt. Abgesehen davon kannst du mit fail2ban viele andere Services ebenfalls prüfen lassen.

  • Danke für die vielen so schnellen Antworten.


    Also der Tipp mit SSH-Port ändern, wurde direkt umgesetzt. Kann ja so einfach sein.


    Werde meine Logs die nächste Zeit beobachten, wenn ich weiterhin Probleme habe, werde ich mich wohl intensiver mit iptables und fail2ban auseinandersetzen.


    Nach 10 Minuten auf einem neuen SSH-Port, fanden nun 0 Angriffe statt.

    Ich bin schon etwas schockiert, wie viel so eine einfache Änderung bewirken kann.

  • Nach 10 Minuten auf einem neuen SSH-Port, fanden nun 0 Angriffe statt.

    Ich bin schon etwas schockiert, wie viel so eine einfache Änderung bewirken kann.

    Das ist klar. Die meisten Bots versuchen es halt nur auf dem Standardport. Wieso sollten sie auch andere Ports probieren? Wenn es bei irgendeiner IP-Adresse auf dem Standardport nicht funktioniert, versucht man halt die nächste IP. Das ist einfacher und effizienter als bei jeder IP alle Ports abzuklappern. Zumindest solange die Mehrzahl aller Server den Standardport für SSH benutzen. Trotzdem würde ich fail2ban zusätzlich nutzen, um Brute-Force Angriffe zu erschweren. Denn irgendwann wird (mindestens) einer der Bots auch den geänderten Port finden ...

  • Ich nutze ufw + denyhosts/allowhosts, ausschließlich Keys und geänderte Ports. Fail2ban läuft zusätzlich nur auf dem einzigen von außen erreichbaren Server (Jumphost)

    ChestSort: Automatische Kistensortierung in Minecraft - www.chestsort.de


    binichblau: Online-Promillerechner - www.binichblau.de

  • Die SSHD config an sich bietet auch einiges mehr um den Server zu härten. Stichworte:

    - Nur Pubkey authentifizierung

    - Maximale Verbindungen/Loginversuche (MaxAuthTries)


    Grundsätzlich bringt das Ändern des Ports keinen Sicherheitsgewinn, hält nur die Logs sauber. Jede Variante hat Nachteile:

    Port 22: Ständige Loginversuche (Man kann auch einfach das Loggen von fehlgeschlagenen Loginversuchen deaktivieren, wenn man die Logs "sauber" halten will)

    Port <1024: Ports sind eigentlich für andere Services reserviert. Kann auch zu komischen Logeinträgen führen wenn sich andere Services verbinden wollen.

    Port >1024: "normale" (nicht-root) User könnten den Port kapern und damit bei einem Login von dir die Zugangsdaten abgreifen. (Wenn man die Portänderung aufgrund von "Sicherheit" machen will vielleicht die schlechteste Variante)

    https://en.wikipedia.org/wiki/Registered_port)


    Wer auf Nummer sicher gehen will sollte heutzutage 2FA einsetzen.

    => https://ubuntu.com/tutorials/configure-ssh-2fa#1-overview

    (Ist in 10min eingerichtet)

  • mal zusätzlich "AllowUsers" einwerf ;)

    damit legt man fest, wer sich überhaupt einloggen darf

    und filtert schonmal 99,9% der Loginversuche weg.

    It's me, only me, pure michi

    RS 500 SAS G8 Ostern 2019

    VPS: 50 G7 |B Ostern 2017|200 G8 Aktion

    WH: SmallEi | Adv17 Webhosting Spezial Family | Expert Spezial 2016

  • Geht die 2FA eigentlich auch mit Key Anmeldung? Also sogesehen, nach oder vor dem Key....

  • Das meiste wurde ja schon gesagt. SSH Port ändern (auch wenn viele das hier nicht als Lösung ansehen - hilft bei mir aber seit 20 Jahren). Dann fail2ban, für den Rest. Sollte im Zweifel reichen. Sonst kannst natürlich noch weitere Maßnahmen einleiten, die aber meiner Meinung nach nicht nötig sind und zu Gunsten des Komfort gehen.


    Bruteforce auf den SSH Port sind normal und bei mir dauert es keine 2min und ich hab 20 Loginversuche, egal, ob hier bei netcup oder anderen Anbietern. Lediglich meine Server in China werden nicht attackiert... wie heißt es so schön, eine Krähe pickt der anderen kein Auge aus 😂

  • Lediglich meine Server in China werden nicht attackiert...

    Ich behaupte, dass die chinesische Regierung dich verschwinden lassen würde, wenn du öffentlich von ihren Attacken erzählen würdest. :D


    Spaß :P aber mal ehrlich... ist das wirklich so extem, wie alle immer erzählen? Also dass du genau aufpassen musst, was du sagst und was du machst? (bisschen Offtopic, kannst ja im längsten Thema antworten. ^^ )



    Ich kann mich bzgl. des Themas an sich nur meinen Vorrednern anschließen. Eine weitere gute Idee, die ich anbringen möchte, ist, derartige Dienste nur in einem VPN verfügbar zu machen, in welches man sich dann einklinken kann. Damit kann man die Angriffsfläche quasi auf ein Minimum reduzieren. :)

    RS Rentier 2019 | CX11-CEPH | VPS Karneval 2020


    Wer im Netz Anstand und Respekt verliert, der ist auch im realen Leben für nichts zu gebrauchen! ;)

  • Eine weitere gute Idee, die ich anbringen möchte, ist, derartige Dienste nur in einem VPN verfügbar zu machen, in welches man sich dann einklinken kann.

    Mal ganz doof nachgefragt: Wenn ich mich mit aktiven VPN per ssh mit dem Server, auf dem auch der VPN Server läuft, verbinde, wird meine IP vom ISP erkannt und nicht mehr die vom VPN.


    Kann ich dies irgendwie aushebeln / umgehen? (Debian 10 / wireguard)

  • Kann ich dies irgendwie aushebeln / umgehen? (Debian 10 / wireguard)

    Wer erkennt die IP vom ISP?


    Ich nehme folgendes an. In einer Wireguard Config kann man festlegen, welcher Traffic denn bitte geforwarded werden soll. Wenn du da nur die des Servers einträgst, dann wird auch nur der Traffic von und zum Server selbst durch Wireguard geleitet. Der Rest geht normal ins Internet.


    In deiner Client Config ist dein Server als Peer eingetragen. In dieser Peer Config hast du einen Eintrag namens "AllowedIPs".

    Dort musst du, wenn du allen Traffic durch dieses VPN schieben magst, 0.0.0.0/0, ::/0 als Wert eintragen.


    Oder missverstehe ich dich da gerade?

    RS Rentier 2019 | CX11-CEPH | VPS Karneval 2020


    Wer im Netz Anstand und Respekt verliert, der ist auch im realen Leben für nichts zu gebrauchen! ;)