Hallo,
um was für eine Art Server (Produkt) handelt es sich denn? Welches OS läuft darauf und welche Dienste werden angeboten?
Die Logs (System/Webserver) hast du nehme ich an schon auf Auffälligkeiten geprüft?
Wenn der Server per SSH die Verbindung ablehnt, ist in dieser Zeit ein Zugriff über die Konsole (Servercontrolpanel) möglich?
Laufen die Dienste währenddessen? Was steht in den Logs?
Die VNC-Konsole im SCP sollte bei det Analyse weiterhelfen, dort kommst Du auch ohne SSH rein.
EDIT: Heute bin ich mal die langsame Ente...^^
Da wären ein paar Informationen mehr sicher hilfreich. Wir wissen so ja noch nicht einmal, welches OS installiert ist, geschweige denn wieviel Ressourcen das Teil hat und wie sehr es zu der Zeit ausgelastet ist, wo die Probleme auftreten. Man kann auch nicht ausschliessen, dass der Server vielleicht gehackt ist und nebenher Bitcoin Mining betreibt.
Oder aber fail2ban auf die eigene IP…
Nicht dass Profis wie mir sowas jemals passieren würde!
Hallo,
um was für eine Art Server (Produkt) handelt es sich denn? Welches OS läuft darauf und welche Dienste werden angeboten?
Die Logs (System/Webserver) hast du nehme ich an schon auf Auffälligkeiten geprüft?
Wenn der Server per SSH die Verbindung ablehnt, ist in dieser Zeit ein Zugriff über die Konsole (Servercontrolpanel) möglich?
Hey,
Danke für die Antwort.
Produkt: RS 1000 G9.5 a1 12M OS: Debian 11
In den Logs steht nichts auffälliges. Es sieht alles normal aus über das Screen. SSHD Damon ist active und der vom Webserver auch.
Es steht nichts von Verbindungsversuchen oder so dort.
Das einzige Auffällige ist die Belastung der Serverhardware. Ich hänge mal ein Screenshot von dem CPU Monitoring an.
Grüße
Wie ist denn der Status des Servers? Frisch installiert mit Debian 11 minimal Image von netcup? Oder ein anderes Image aufgespielt? Oder doch schon einiges zusätzlich installiert? Falls ja, was? Könnte das die zeitweilige CPU-Last erklären? Das sollte sich auch anhand von Logfiles nachvollziehen lassen. Zumindest ein Webserver scheint ja installiert zu sein, was läuft da? Server vernünftig abgesichert? Falls da fail2ban schon installiert ist, könnte auch das eine mögliche Ursache sein.
Vielleicht ein IPv4/IPv6 Problem.
Also kein fail2ban? Damit man das gleich ausschliessen kann. Was sagen /var/log/syslog und var/log/auth.log zu den Zeiten, als du dich nicht verbinden konntest und auch zu den Zeiten, wo das SCP die erhöhte CPU-Aktivität anzeigt?
Vielleicht ein IPv4/IPv6 Problem.
Wollte ich auch gerade schreiben. ssh -4 sollte Abhilfe schaffen, wenn es das ist.
Also fail2ban hatte ich am Anfang installiert, jedoch habe ich es nie konfiguriert, weil ich mich mit dem Tool bisher noch nicht auseinander gesetzt habe.
Das dürfte das Problem sein. Unter Debian/Ubuntu werden installierte Dienste gerne automatisch und direkt nach der Installation gestartet. Fail2ban hat unter Debian (evtl. auch unter Ubuntu) den sshd Jail per Default aktiviert. D.h. die alleinige Installation dürfte hier schon gereicht haben um es aktiv zu schalten. Logge dich mal über das SCP ein und schaue dir die aktive sshd Jail mal an. Vor allem, ob da deine IP drin steht (was ich jetzt mal vermuten würde) mittels
fail2ban-client status sshdHast du denn schon verschiedene Clients mit unterschiedlichen IP Adressen getestet (um ein lokales Client Problem auszuschließen)? Du kannst ansonsten auch gerne mal deine IP per privater Nachricht mitteilen, dann teste ich das gerne mal von verschiedenen Source IPs um zu überprüfen, ob die Dienste generell nicht erreichbar sind oder nur nicht von deiner IP. Das würde ich als erstes mal überprüfen. Wenn die Dienste generell nicht mehr erreichbar sind, kann man weiter schauen. Dann mal überprüfen, ob die Dienste überhaupt noch laufen (Logs, systemctl status $DIENST, ...) und auch die lokale Netzwerk Konfiguration mal überprüfen (ip a, ss -tulpen, ...).
dort werden zahlreiche Anmeldeversuche auf verschiedenen Ports mit verschiedenen Usern und PWs aufgezeichnet. Kann mir jemand helfen, wie ich mich jetzt gegen diese Attacken schützen kann, weil es unters. IPs sind kann ich ja nicht per IP bannen.
Was hast du denn alles offen, dass du so viele Login-Versuche auf verschiedenen Ports siehst? Die IP-Adressbereiche von Hostingprovidern werden ständig nach offenen Diensten abgesucht. Dagegen kannst du prinzipiell nichts tun. Eine vorgeschaltete Firewall, mit der du für dich uninteressante Verbindungsversuche grob vorfiltern könntest, gibt es bei Netcup nicht. Du hast schon richtig erkannt, dass viele Scans heutzutage als langsame verteilte Scans stattfinden, denen lokal nicht beizukommen ist. Die einzelnen IP-Adressen tauchen nur in großen Abständen auf, so dass Methoden wie Fail2Ban nicht greifen. Damit hält man nur die ganz dumpfen Skripte ab. Portscans auf geschlosssenen Ports zu loggen, ist nur in Ausnahmen sinnvoll.
Für öffentlich angebotene Dienste ist damit eigentlich schon alles gesagt: Dir bleibt dann nur, das Logging so zu konfigurieren, dass es keine eigenen Probleme macht (Speicherplatz, CPU-Last) und wichtige Meldungen nicht in einem Meer aus gescheiterten Login-Versuchen untergehen.
Wenn du Dienste auf dem Server hast, die du nur selbst nutzt, kann ein VPN-Zugang wie Wireguard nützlich sein, so dass die eigentlichen Dienste gar nicht öffentlich erreichbar sein müssen. Wenn du die lokale Firewall so konfigurierst, dass geschlossene Ports keine Antworten auf Verbindungsversuche schicken, fällt ein Wireguard-Zugang in einem Portscan gar nicht auf. Der verhält sich ohne einen passenden Schlüssel dann nämlich auch nicht anders als ein nicht verwendeter Port. Sobald ein Port einmal irgendwie geantwortet hat, wird dort in absehbarer Zukunft regelmäßig angeklopft werden. Nicht-öffentlich verwendete Ports von Anfang an "unsichtbar" zu machen, hilft also, die (Log-)Last der dauernden Portscans zu reduzieren.
So ich hab das Problem in der auth.1 log Datei entdeckt, dort werden zahlreiche Anmeldeversuche auf verschiedenen Ports mit verschiedenen Usern und PWs aufgezeichnet. Kann mir jemand helfen, wie ich mich jetzt gegen diese Attacken schützen kann, weil es unters. IPs sind kann ich ja nicht per IP bannen.
Die Anmeldeversuche sind leider normal, auch bei geändertem SSH-Port. Da arbeiten sich ganze Botnetze daran ab...
Man kann sshd nur noch über Wireguard laufen lassen, oder Port Knocking einrichten, oder das Log einfach ausschalten.
Mit Wireguard überlebt eine SSH-Verbindung auch mal einen kurzen Reconnect des DSL-Routers. Man kann damit also auch kleinere Probleme im eigenen Netzwerk umgehen. Einen Versuch ist es vielleicht wert.
Hallo zusammen,
ich hatte gestern Abend und in der Nacht auch Probleme mich an meinem vServer anzumelden.
Das hing allerdings mit der Netzwerk Störung bei Netcup zusammen.
Netcup Status Seite -> https://www.netcup-status.de/category/netzwerk/
Dort steht, dass es Netzwerk Probleme gab.
Seit die Probleme weg sind, kann ich mich auch wieder ohne Probleme auf meinem vServer per SSH anmelden.
Hallo,
Connection refused bedeutet in jedem Fall mal, das dein Server erreichbar ist - aber dein Server die Verbindung nicht zulässt.
fail2ban ist normal so konfiguriert, das er die IP, die 3x das falsche Passwort eingegeben hat diese IP für 3(ich glaub es sind normal 3 Stunden?) sperrt.
Gruß
