Webserver wird mit Loginversuchen bombardiert

iYassin

Well-known member
Registriert
15 Mai 2009
Beiträge
10.044
Hi zusammen,

ich bräuchte mal bitte Hilfe von Euch erfahrerenen Server-Admins :)

Ich betreibe auf einem Netcup vServer Debian 10 und Nextcloud 23. Das System ist grob nach der Anleitung von Carsten Rieger (https://www.c-rieger.de/nextcloud-installationsanleitung/) eingerichtet, u.a. also auch mit fail2ban ausgestattet. Seit etwa einem Tag wird mein Server jetzt mit Loginversuchen auf ssh bombardiert, alle paar Minuten wird eine IP nach 5 Versuchen gegen ssh und sshd gesperrt, dann kommt ein paar Minuten später eine andere. Seit gestern sind es ca. 150 verschiedene IPs, die angelaufen sind. Die IPs sind völlig zufällig, auch die Regionen, woher sie kommen und die Benutzernamen, die probiert werden. Ich kann also weder einen Adressbereich noch eine Region sperren.

Hat jemand einen Tipp, was ich machen kann?
Oder kann man das nur aussitzen? Der Server ist eigentlich entsprechend gehärtet (Firewall, fail2ban, kein root-Login per SSH etc.) und die Last ist auch (bisher) kein Problem.

Viele Grüße,

iYassin
 
Das sind gekaperte Rechner (Bot-Netz), die einem Hacker Zugang verschaffen sollen. Derartige Versuche treten immer wieder in Wellen auf.
Zur Eindämmung kannst Du:
- fail2ban veranlassen, bereits nach zwei oder drei Fehlversuchen die IP zu blocken
- ssh-Port in der Firewall für ein paar Tage schließen, damit die Angriffsversuche in leere laufen und der "Sturm" nachlässt. Nach erneutem öffnen kann schon kurze Zeit später die Flut wieder losbrechen.
Den ssh-Port würde ich nach außen auch nur öffnen, solange es unbedingt gerade erforderlich ist. Auch wäre zu überlegen, ob ssh-Zugriff nicht über VPN realisiert werden kann.
 
Evtl. hilft es kurzfristig auch den Standard SSH Port auf z.B. 22022 zu legen falls Du nicht tagelang auf Deine Nextcloud verzichten kannst.

Nachtrag noch vergessen: Meist kannst Du in der Firewall auch ein Port remapping vornehmen: Z.B der oben beschriebene externe 22022 Port wird gemappt auf den internen 22 Port. Dann musst Du nur in der Firewall Regeln anpassen.
 
Zuletzt bearbeitet:
Danke Euch beiden! Dann werde ich erst einmal die Fehlversuche auf drei heruntersetzen. Den SSH-Port habe ich ohnehin schon seit der Erstkonfiguration geändert, allerdings direkt in den Einstellungen von sshd.

Bringt es etwas, den einfach mal wieder auf eine andere random Zahl zu setzen? Oder laufen so Angriffe eh auf alle Ports und komplett schließen ist vorab die bessere Variante?

Mit ssh per VPN setze ich mich dann mal auseinander, danke für den Hinweis!
 
Bringt es etwas, den einfach mal wieder auf eine andere random Zahl zu setzen?
Würde ich jetzt als Erstes durchführen
Oder laufen so Angriffe eh auf alle Ports
Das glaube ich nicht, aber Du würdest es nach dem Verändern des Ports sehr schnell mitbekommen.
Es kann natürlich sein, dass die dann erst mal wieder einen Full Portscan bei Dir durchführen.
Kann man jetzt aus der Ferne nicht beurteilen. Da musst Du die Logs der Firewall durchschauen wie das aktuell läuft.


Wenn Du der Einzige bist der Deinen Server aus der Ferne nutzt, kann Du Deine Firewall auch komplett dicht machen für
alle Verbindungen die von draussen kommen und einfach von deinem Server durch Deine Firewall einen OpenVPN zur OpenVPN Cloud (https://openvpn.net/) erstellen.
3 VPN Verbindungen sind bei denen kostenlos.
Dann kannst Du Dich selber mit dem OpenVPN Client sicher bei Deinem Server anmelden über deren Cloud und alle Dienste nutzen.
 
Bei ssh würde ich auch pubkey auth only gehen, damit werden die ganzen Bots abgeschmettert bevor sie sich zu verbinden versuchen können weil dein Server alle PW Logins kategorisch entsorgt. Das zusammen mit fail2ban, oder direkt auf einem high port, ist eigentlich ziemlich ok was krumme anfragen angeht.
 
Bei ssh würde ich auch pubkey auth only gehen

Vielleicht auch interessant: Habe ich kombiniert mit einem zweiten Faktor und zur Einrichtung diese Anleitung benutzt: Optional: Setting up multi-factor authentication.

Finde den Ansatz von Portknocking interessant, hatte aber noch keinen Bedarf, es selbst auszuprobieren.

Da ich (bisher) mosh verwende, habe ich mal geschaut, was ich dazu finde:

 
- Das ist relativ normal. Sehe ich auch auf vielen Servern unterschiedlichster Konfigurationen.
- So lange du nicht geDOSt/geDDOSt wirst, ist noch alles harmlos ;) Dann hilft nämlich nur noch die Firewall des Anbieters. Da ist Netcup meiner Erfahrung nach ziemlich wenig hilfreich.
- den SSH-Port auf irgendeinen Nicht-Standard-Port zu legen erledigt das Problem in der Regel zu 99% (so zumindest meine Erfahrung). "Angriffe" laufen in der Regel nur auf einzelne Ports. Port-Scans sind noch häufig, aber darauf basierende Angriffe sind - meiner Erfahrung nach - extrem selten.
- fail2ban ist aber trotzdem eine gute Sache
- Portknocking natürlich auch, habe ich aber selbst noch nie genutzt - da alle Maßnahmen sonst schon wirkungsvoll genug waren oder da die Angriffe so mächtig waren (DOS/DDOS), dass das auch nichts mehr gebracht hätte
- SSH per VPN ist auf jeden Fall eine gute Praxis - aber ich mache es oft auch nicht, da SSH grundsätzlich schon mehr oder weniger sicher genug ist und man bei verkorkstem VPN (was durchaus mal vorkommt) dann natürlich auch nicht mehr per SSH drauf kommt, um das Problem zu fixen. Außerdem verschiebt man die Angriffe/Login-Versuche nur vom SSH-Server auf den VPN-Server. Und VPN ist in der Regel komplexer, hat also auch eine höhere Gefahr für Sicherheitslücken. Aber klar, der Vorteil ist: Hat man es geschafft, in das VPN einzudringen, ist man immer noch nicht im Server selbst - SSH müsste man dann noch zusätzlich knacken (oder einen anderen Weg finden, aus dem VPN "auszubrechen"). Damit hat man eine Stufe mehr Sicherheit.
- SSH sollte, gerade wenn er im Internet exponiert ist, ausschließlich passwortlose Logins (also nur per Public-/Private-Key) akzeptieren.
- Mehrfaktorauthentifizierung ist auch immer eine gute Sache, aber muss natürlich von den Tools auch unterstützt werden.
 
Danke Euch allen für die Tipps! Ich sehe, einiges, wo ich mich einlesen muss. SSH mit Key habe ich mir schonmal angeschaut, aber dann irgendwie doch sein lassen, dann werde ich das jetzt definitiv mal einrichten. Two-Factor und Portknocking klingt auch gut!

Im akuten Fall hat das Ändern des SSH-Ports tatsächlich schon geholfen, seit gestern ist Ruhe :D
 
Einige haben hier schon eine Menge hierzu geschrieben. Ich gebe Dir einmal eine Liste zum abhaken, wohl wissend, dass diese nicht vollständig ist. Und, siehe dies nur als Tipp :) Los geht es

* SSH mit Key sichern
* rootlogin ausmachen, oder mit Key erzwingen (vorher ggf. sudo rechte setzen)
* fail2ban!!! (zwingend, und block ^ 5 Minuten)
* rkhunter, clamav usw. setzen
* Software/ System immer aktuell halten, kann auch automatisiert werden (Unattered Updates)

Nutze, falls Du weniger erfahren bist, HIlfs- Software wie z.B. Plesk, WebMin oder so...

Aber, da schon andere Tipps gegeben haben, braucht es ggf. nur noch eine Zusammenführung des Wissens und natürlich die Umsetzung dessen :D
 
Wobei Webmin nicht unumstritten ist, da dort immer wieder Sicherheitslücken auftauchen. Wenn, dann sollte Webmin nicht von außen erreichbar sein.
Webmin Login kann man mittels Fail2Ban sichern. Aber, ich gebe Dir an anderer Stelle recht: Eine Domain in Webmin einzurichten, ist aufwändiger als wenn man Plesk nutzt..

Es gibt aber auch andere Tools, welche einem dem Weg erleichtern ;)
 
Es gibt aber auch andere Tools, welche einem dem Weg erleichtern ;)
Korrekt, auch abseits des Mainstreams von Plesk & cPanel
Bei Netcup kann ich ISPConfig empfehlen, das ist einfach konfiguriert und wenn man erfahrender ist, kann man die Konfig-Dateien auch per Hand anpassen ohne das einem das Tool (wie Plesk es macht) die Konfigs immer wieder überschreibt.
 
- SSH sollte, gerade wenn er im Internet exponiert ist, ausschließlich passwortlose Logins (also nur per Public-/Private-Key) akzeptieren.
Das ist meiner Meinung nach definitiv das beste Werkzeug. Dadurch wird die Anfrage schon frühzeitig abgelehnt und nach meinem Gefühl merken die Bots das auch und bombadieren den eigenen Server nicht mehr (zumindest nicht über SSH).
 
Im Grunde ist alles gesagt.
Ich kann aber bestätigen dass das ziemlich normal ist.

Hat sich mal jemand crowdsec angeschaut? sozusagen das neue fail2ban mit community/cloudanbindung was ip sperren angeht?!
 
  • ok1.de
  • ok2.de
  • thinkstore24.de
  • Preiswerte-IT - Gebrauchte Lenovo Notebooks kaufen

Werbung

Zurück
Oben