Erste Schritte VPS 1000 G9 12M

  • Hallo!

    Ich bin neu hier und habe einen VPS 1000 G9 12M gemietet.

    Der Server ist meine "Lernplattform" - zu Hause habe ich einen Server mit FreeBSD laufen welcher

    div. Daten im Heimnetz zur Verfügung stellt. Es laufen einige VMs (WireGuard, Ubuntu für Docker, Bitvarden)


    Diesen Server hier möchte ich nutzen um mein Wissen zu erweitern. Es werden auch keine wichtigen Daten oder Anwendungen

    hier laufen.


    Meine Frage bestifft nun aber die Absicherung meines Servers. Diese Punkte habe ich bereits durchgeführt:

    - SSH auf Key only umgestellt

    - ROOT darf nicht SSH

    - User für Sudo eingerichtet

    - Mittels UFW den eingehenden und ausgehenden Verkehr unterbunden (Port 22, 80, 443 sind offen in beide Richtungen)

    - fail2ban läuft und sperrt nach 3 Versuchen die entsprechende IP für 24h.


    Nun aber meine Frage, im Netz habe ich noch nichts passendes gefunden, wenn ich mir das Log /var/log/auth.log ansehe,

    dann kommt doch noch die eine oder andere IP mit einem hohen Port bis zu fail2ban durch. Sollte das nicht

    schon durch die Firewall-Regel unmöglich sein?


    Auszug aus auth.log:


    Sep 11 13:48:02 "mein Server" sshd[1419]: Invalid user user from 24.147.90.130 port 10945

    Sep 11 13:48:04 "mein Server" sshd[1419]: Received disconnect from 24.147.90.130 port 10945:11: Bye Bye [preauth]

    Sep 11 13:48:04 "mein Server" sshd[1419]: Disconnected from invalid user user 24.147.90.130 port 10945 [preauth]

    Sep 11 13:50:33 "mein Server" sshd[1422]: Invalid user kristen from 68.183.88.186 port 43870

    Sep 11 13:50:33 "mein Server" sshd[1422]: Received disconnect from 68.183.88.186 port 43870:11: Bye Bye [preauth]

    Sep 11 13:50:33 "mein Server" sshd[1422]: Disconnected from invalid user kristen 68.183.88.186 port 43870 [preauth]



    sudo ufw status verbose

    Status: active

    Logging: on (low)

    Default: deny (incoming), allow (outgoing), deny (routed)

    New profiles: skip


    To Action From

    -- ------ ----

    22/tcp ALLOW IN Anywhere

    22 ALLOW IN Anywhere

    80 ALLOW IN Anywhere

    443 ALLOW IN Anywhere

    22/tcp (v6) ALLOW IN Anywhere (v6)

    22 (v6) ALLOW IN Anywhere (v6)

    80 (v6) ALLOW IN Anywhere (v6)

    443 (v6) ALLOW IN Anywhere (v6)


    Hier ist der Port 22 doppelt in der Config, sollte aber nicht stören oder?


    Verwendet wird ein Ubuntu 20.04


    Hat jemand einen Tip wie das funktionieren könnte? Ich möchte natürlich die Ports nicht offen haben bzw. sind sie zu aber es kommt doch

    noch wer durch... oder verstehe ich das Log auch falsch?


    Danke Viele Grüße

    Mario

  • 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.

    Hallo Paul,


    danke für Deine beruhigende Antwort!

    Ok nun fängt das lernen schon an - "ist der Client Port (+ Client IP), nicht der Server Port" - kann ich das irgentwo

    nachlesen damit ich das einordnen kann?

    So verstehe ich das leider nicht ganz :/

  • 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

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • 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.

  • - 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.

    »Hauptsache BogoMIPS!«

    Fleischfresser

  • 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.


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

    Hallo mropen,


    OSSEC kenne ich garnicht. Schau ich mir gern mal an. Aber wie schon geschrieben, der Server ist mehr zum spielen (lernen) wenn da mal was "passiert" hoffe ich, dass ich es merke und setzte zur Not das Ding neu auf. Aber toller Tip - mal sehen wie OSSEC funktioniert.


    VG

  • 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.

  • ... 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 ...

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

  • 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.

  • 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;:/

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

  • 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.

  • 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)

  • 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.

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing