Erste Schritte VPS 1000 G9 12M

Hallo Mario,

das was du in den Logs siehst, ist der Client Port (+ Client IP), nicht der Server Port. Das darfst du nicht verwechseln. Daher brauchst du dir diesbezüglich keine Gedanken machen.

Alle diese Anmeldeversuche sind ursprünglich über Port 22 reingekommen, die entsprechenden Verbindungen können freilich nicht alle über ein und denselben Socket laufen, die dürfen also auch soweit durchkommen, weil Port 22 ja nicht geblockt wird. Also kein Grund zur Sorge, das ist normal. Der sshd lauscht auf Port 22, wenn aber eine Verbindung zustande kommt, dann wird für diese ein neuer Socket erstellt und verwendet, während der sshd weiterhin auf Port 22 auf neue Verbindungen wartet. Nur so können ja auch mehrere gleichzeitig bestehende Verbindungen zustandekommen. Eine Verbindung muss also in jedem Fall erst einmal zustandekommen, wenn man nicht grundsätzlich jede SSH-Verbindung blocken will. Sonst könnte sich der Client ja auch nicht authentifizieren. Wenn die Authentifizierung nicht erfolgreich ist, also z.B. der User gar nicht existiert (wie in deinem Log-Auszug) oder ggf der public key nicht passt, gibt es eben einen entsprechenden Logeintrag in der auth.log und die Verbindung wird beendet. Erst auf den Logeintrag reagiert dann wiederum fail2ban je nach Einstellung eben z.B. durch bannen der IP nach 5 erfolglosen Authentifizierungsversuchen. Die IP ist also nicht wirklich "bis zu fail2ban durchgekommen". Sie hat es nur zu einem Logeintrag in der auth.log gebracht, worauf dann wiederum fail2ban reagiert.

Wenn Du das Grundrauschen in den Logs vermeiden willst, musst Du SSH auf einen anderen Port (z.B. ≥50000) legen oder ein VPN davor schalten.

Was Deine Frage bezüglich Ports angeht: Ein Serverdienst lauscht immer auf einem Port, im Beispiel TCP/22. Zu diesem Port können sich dann beliebig viele Clients verbinden. Jeder Client wählt zufällig einen hohen Port als Quellport aus, wenn er eine Verbindung aufbauen möchte. Dieser muss an der IP-Adresse des Quellgeräts exklusiv für diese TCP-Verbindung zur Verfügung stehen. Wenn Dinge wie NAT dazwischen passieren, ist es nochmals komplizierter, aber das Grundprinzip bleibt gleich.

Siehe: https://de.wikipedia.org/wiki/…bindungsaufbau_und_-abbau

Quote from Plavix98

Danke Super!

jetzt habe ich das verstanden.

Den Beitrag bei Wikipedia werde ich mir auch durchlesen.

tab > Die Erklärung ist klasse!

KB19 > Den Port 22 werde ich dann mal umlegen. Hoffentlich sperre ich mich nicht aus

VG Mario

Display More

Wirklich aussperren wirst du dich wohl nicht, weil es ja immer noch den Zugang über die Konsole im SCP gibt. Da kann man sich dann anmelden und das Problem beseitigen, auch mit Root-Passwort, weil es ja keine SSH-Verbindung ist.

Quote from Plavix98

- ROOT darf nicht SSH

mittlerweile gibts ja explizit PermitRootLogin prohibit-password(aka without-password), was auch default eingestellt ist.

ich selbst tu mir das user-gewechsele nicht mehr an und logge mich direkt mit root ein.

aber das ist auch ein bisschen eine glaubensfrage.

Das ist keine Glaubensfrage. Das ist alleine schon aus Gründen des Auditings bei professionellen Installationen ein Tabu. Privat und als einziger Nutzer auf dem Rechner ist Auditing zwar nicht unbedingt relevant, aber da greift dann das Prinzip der Verteidigung in der Tiefe.

Quote from Plavix98

Anstatt Fail2ban könntest du auch OSSEC nehmen. Das beinhaltet Fail2ban und kann noch einiges mehr.

Ich würde dir empfehlen den SSH Port zu ändern, danach den SSH Zugang nur über Keyfile zugänglich machen. Danach fail2ban mit verbindung zu ntftables zu verwenden, Firewall alles nach draussen frei geben aber alles was rein kommt blocken (drop) und nur das freigeben was du auch benötigst. Fail2ban stellst du dann so ein das es mit nftables harmoniert, sprich fällt eine IP-Adresse in deinen Filter, wird die IP-Adresse automatisch auch in der Firewall (ntftables) geblockt. Ansonsten für jeden erlaubten ausgang fail2ban einstellen und testen. Alternativ kannst du auch noch dir eine Bash File bauen die dir eine E-Mail zusendet wenn ein SSH Benutzer eingeloggt ist.

Quote from KB19

... musst Du SSH auf einen anderen Port (z.B. ≥50000) legen oder ein VPN davor schalten.

oder den Zugriff an Hand der Quell-IP beschränken;

wenn man es nicht benötigt, von weltweit darauf per SSH zugreifen zu können, sollte man es auch nicht erlauben ...

Ich empfinde knockd (Klopfe an zwei nur mir bekannten Ports, dann ist ssh für die Souce Ip 15 Sekunden offen, danach nur noch 'established sessions') als Sicherheitsgewinn, bei Portscans sieht man den non default ssh Port gar nicht erst.

Nginx Hardening steht noch auf der Todo Liste, automatisierte Security updates sind sicherlich (für alles) keine schlechte Idee.

Quote from itsmee

bei Portscans sieht man den non default ssh Port gar nicht erst.

das ist ein Trugschluss.

Quote from mainziman

das ist ein Trugschluss.

Jetzt bin ich neugierig: wie erkennt man denn in einem normalen Portscan einen SSH-Port, welcher erst nach einer theoretisch unbekannten Anklopfsequenz geöffnet wird?

wie Du sagst - "theoretisch unbekannte Anklopfsequenz" - soll heissen, dass ausgeschlossen werden muss, dass durch Zufall die "Anklopfsequenz" von einem Portscan ausgelöst werden kann ... und hier hab ich meine Zweifel;

Puh, ja, natürlich ist das in der Theorie möglich, wie auch bereits von mir angedeutet. Trotzdem kann man schon davon ausgehen, dass i.d.R. der Port nicht zu sehen sein wird.

Aber ja, du hast Recht.

Also wenn meine täglichen Russen-, Chinesen-, Türken- und sonstigern Hacker mal richtig Gas geben, dann werde ich mir das mit dem Anklopfen mal überlegen. Vielleicht kommt das ja jetzt, da die pizzaseo und sonstigen DNS-Abfragen seit einiger Zeit weniger werden. Irgendwas müssen die Botnetze ja schliesslich auch machen. Derzeit sind das aber nicht sooo viele Versuche pro Tag, gerade mal gut Tausend, davon >95% mit irgendwelchen abstrusen Usernamen, die es natürlich nicht gibt, der Rest für root. Bisher hatte ich noch keinen einzigen Versuch mit einem existierenden User außer root. Und root oder sudoers können sich per SSH nicht anmelden, die anderen User nur mit passendem Key. Da die Keys zusätzlich auch noch Passphrasen mit >20 Zeichen haben, sehe ich den Hackversuchen per SSH relativ gelassen entgegen, außer es würden etwaige sicherheitsrelevante Bugs im sshd selbst ausgenutzt.

Quote from tab

Bisher hatte ich noch keinen einzigen Versuch mit einem existierenden User außer root.

Ja, bei mir auch nicht. Was wohl auch daran liegt, dass es auf meinen Servern keine Nutzer "Paul" o.ä. gibt.

Die user unorthodox zu benennen ist schon mal die halbe Miete gegen solche Versuche
(Und halt root-ssh sperren)

Quote from mainziman

wie Du sagst - "theoretisch unbekannte Anklopfsequenz" - soll heissen, dass ausgeschlossen werden muss, dass durch Zufall die "Anklopfsequenz" von einem Portscan ausgelöst werden kann ... und hier hab ich meine Zweifel;

Also, wenn die Portscans nicht die Reihenfolge der kontaktierten Ports und die Zugriffsart ständig permutieren (und das machen die allerwenigsten), ist bereits hier die Möglichkeit einer Exponierung des Dienstports in der Regel(!) ausgeschlossen. (Zur Erinnerung: Die Klopfsequenz kann – und sollte! – durchaus 5..10 Ports in zu­fäl­liger Reihen­folge und jeweils wahlweise UDP/TCP als Protokoll definieren[*]. Und nach jedem Klopfen müssten quasi alle potentiellen "SSH-Ports" unter Ver­wen­dung eben­dieses Protokolls getestet werden. Da sich aber auch "wildes Herumgeklopfe" entsprechend erkennen und blockieren lässt – d.h. danach sind für xxx Stun­den kei­ner­lei Tests mehr möglich – dürften entsprechende Einbrüche effektiv kaum möglich sein.)

Mit obiger Vorarbeit kann man bei fehlerhaften key phrases übrigens auf Mehrfachversuche bei der Authentifizierung per SSH verzichten, d.h. man würde die ent­spre­chen­de IP-Adresse (bzw. nach einer gewissen Anzahl von Vorfällen ganze IP-Bereiche) direkt blockieren. Da in der Praxis auch die Klopfsequenzen wie alle anderen Schlüs­sel in adä­qua­ten zeitlichen Abständen geändert werden, haben Angreifer in Verbindung mit knockd sehr, sehr schlechte Karten. Sehr, sehr schlechte.

[*] EDIT: Die Wahrscheinlichkeit, dass durch x-maliges schnelles(!) Anklopfen von ca. 65000 Ports via TCP und UDP die Sequenz als korrekt erkannt wird, ist sehr gering, selbst wenn falsche "knocks" dazwischen nicht registriert werden. Man müsste hier allerdings konkret (a) nochmal in den knockd-Quellcode schauen, wie das Verhalten genau vorgegeben ist und (b) prüfen, ob bspw. masscan das anlagemäßig von der Geschwindigkeit stemmen könnte. Ich halte das für ausgeschlossen für län­ge­re Klopf­se­quen­zen. Zudem wäre ein solches Verhalten ausgehend von ein- und derselben IP-Adresse wirklich recht eindeutig von "normaler Nutzung von Ports" zu unterscheiden.