Security für offenen SSH Port

[ctwx]

Hallo zusammen,

ich habe einen alten PC in einen Minecraft-Server umgewandelt. Im Router ist der Minecraft und der SSH-Port (allerdings sind die nach außen andere) freigegeben.
Der PC läuft nur On-Demand und manchmal einige Stunden über den Tag. Aber auf keinen Fall 24/7.

SSH ist soweit konfiguriert, dass root sich nicht direkt anmelden kann, mein Nutzer wiederum hat ein relativ komplexes Passwort. Das führte allerdings dazu, dass ich sudo mit NOPASSWD konfiguriert habe, da ich nicht jedes mal das 20-Stellen-Passwort eingeben wollte, wenn ich kurz was als root erledigen wollte (und sei es nur der shutdown).

Jetzt bin ich mir da gerade nicht ganz sicher ob das so sinnvoll ist. Wenn ich SSH so umstelle, dass es nur Zugriff mit Zertifikat anstatt eines Passworts zulässt, wäre das dann ausreichend?

Vielen Dank

[cosinus]

Du kannst SSH noch weiter absichern zB

- SSH-Server aus der Schusslinie nehmen, statt auf Port 22 auf einen anderen legen wie zB 37983
- Login per Passwort verbieten, nur noch per Key erlauben
- per iptables oder Router-Firewall (wenn möglich) bestimmte Adressbereiche einschränken
- fail2ban einrichten benutzen

[niemand]

Jetzt bin ich mir da gerade nicht ganz sicher ob das so sinnvoll ist.

Aus meiner Sicht: nein. Eine Sicherheitslücke in einem vom User genutzten Programm würde hier dann dazu führen, dass der Angreifer direkt auch Rootrechte hätte.

Besser wäre tatsächlich, den sshd so zu konfigurieren, dass er ausschließlich Authentifizierung via Schlüssel oder Zertifikat zulässt, und dafür ein handhabbares Passwort für den User selbst zu nutzen, damit da wenigstens noch ’ne kleine Hürde zwischen User und Root ist.

[GregorS]

... Jetzt bin ich mir da gerade nicht ganz sicher ob das so sinnvoll ist. ...

Ich sehe das wie @cosinus und @niemand. Ich habe die Rechner in meinem kleinen Heimnetz so konfiguriert, dass Logins grundsätzlich per Schlüssel (und somit ohne Passworteingabe) möglich sind. Zudem sind bestimmte Logins (user) nur von bestimmten Maschinen aus möglich.

[MSfree]

Besser wäre tatsächlich, den sshd so zu konfigurieren, dass er ausschließlich Authentifizierung via Schlüssel oder Zertifikat zulässt

Unbedingt

Ich würde noch eine 2-Faktor-Authentifizierung oben drauf packen, z.B. mit dem Google Authenticator, wie hier beschrieben:
https://www.thomas-krenn.com/de/wiki/SS ... _absichern

Die Authenticator-App gibt es für Smartphones mit Android und IOS und sie benötigt keine Online-Verbindung.

[niemand]

Die Authenticator-App gibt es für Smartphones mit Android und IOS und sie benötigt keine Online-Verbindung.

Den jeweiligen Code muss man dann per Hand eintippen – und es ist kein Geheimnis, dass jede Unbequemlichkeit die Wahrscheinlichkeit erhöht, dass die Sicherheit zugunsten höherer Bequemlichkeit wieder kompromittiert wird. Man könnte TOTP aber auch über etwa ’nen Nitrokey laufen lassen – dann wär’s nur noch zu pasten, und wäre zumindest etwas komfortabler.

Edit: wenn’s aber eine App auf einem weiteren Gerät sein soll, wär’ vielleicht mit Blick auf den OSS-Gedanken auch Aegis Authenticator anstelle von Googles Blob eine Überlegung wert …

Schlüssel mit Passphrase verhält sich für den User fast so, wie direkte Passphrase. Und man kann ihn gar via ssh-add beim Agenten hinterlegen, sodass man selbst die Passphrase lokal in der laufenden Session nicht erneut eingeben muss – wäre also etwas mehr Sicherheit bei gleichzeitig höherer Bequemlichkeit.

Noch ein Schritt weiter wäre ein FIDO2-Schlüssel: kann man so einrichten, dass es nur das Token und eine Berührung desselben braucht, um sich via ssh einzuloggen. Ich muss gestehen: seit ich die Dinger kenne und nutzen gelernt habe, finde ich, dass jeder sich das zumindest mal angucken sollte – geht auch für’n lokalen Login, für Datenträgerverschlüsselung, für sudo, für su, […] – und braucht bei entsprechender Config halt nur das Token und ’ne Berührung zur rechten Zeit: maximale Bequemlichkeit, ohne dabei die Sicherheit zu kompromittieren.

Aber im Sinne des Threads würde ich tatsächlich erstmal auf Schlüsselpaar umstellen, Passwort-Login für alle verbieten, die sudo-Konfiguration wieder reparieren und dann weitersehen.

[ctwx]

Du kannst SSH noch weiter absichern zB

- SSH-Server aus der Schusslinie nehmen, statt auf Port 22 auf einen anderen legen wie zB 37983
- Login per Passwort verbieten, nur noch per Key erlauben
- per iptables oder Router-Firewall (wenn möglich) bestimmte Adressbereiche einschränken
- fail2ban einrichten benutzen

Port ist bereits auf einem anderen Port. 2. ist gut, das mache ich noch. Das ganze befindet sich hinter einem Router, da sind nur der geänderte SSH-Port und der Minecraft Port. fail2ban ist ein guter Punkt, hatte ich nicht mehr auf dem Schirm!

Jetzt bin ich mir da gerade nicht ganz sicher ob das so sinnvoll ist.

Aus meiner Sicht: nein. Eine Sicherheitslücke in einem vom User genutzten Programm würde hier dann dazu führen, dass der Angreifer direkt auch Rootrechte hätte.

Besser wäre tatsächlich, den sshd so zu konfigurieren, dass er ausschließlich Authentifizierung via Schlüssel oder Zertifikat zulässt, und dafür ein handhabbares Passwort für den User selbst zu nutzen, damit da wenigstens noch ’ne kleine Hürde zwischen User und Root ist.

Oh, das klingt nach einer guten Kombination!

Besser wäre tatsächlich, den sshd so zu konfigurieren, dass er ausschließlich Authentifizierung via Schlüssel oder Zertifikat zulässt

Unbedingt

Ich würde noch eine 2-Faktor-Authentifizierung oben drauf packen, z.B. mit dem Google Authenticator, wie hier beschrieben:
https://www.thomas-krenn.com/de/wiki/SS ... _absichern

Die Authenticator-App gibt es für Smartphones mit Android und IOS und sie benötigt keine Online-Verbindung.

Interessant, ich wusste nicht, dass man das bei sich selbst lokal einrichtene kann. Schaue ich mal an.

Ich habe sowieso 2FAS Auth am Smartphone und einen Yubikey. Aber ich denke ich würde erstmal auf Auth per Zertifikat umstellen.

[uname]

Bei SSH-Key kannst du direkt auch root erlauben.

[ctwx]

Bei SSH-Key kannst du direkt auch root erlauben.

Wird denke ich nicht notwendig sein, wenn ich sowieso sudo habe. Aber mal gucken.

Mal so eine andere Frage: kann man irgendwie Anfragen außerhalb von Deutschland/der EU blockieren? Der Server wird nur von 2 Personen genutzt und beide sind bei Zugriff zumindest immer in Deutschland.

[heisenberg]

Ja. Man kann das auf Länderebene blockieren mit Geoblocking:

Anleitung von ChatGPT dazu:
https://chatgpt.com/share/b14354dd-239b ... e7881f8fd7

Die Antwort auf die 2. Frage ist hilfreicher als die erste.

---

Hier noch die Variante für nftables:
https://kupschke.eu/2022/03/20/geoip-fi ... -nftables/

[ctwx]

Perfekt, vielen Dank!

[uname]

Kannst auch einen Remote-Tunnel verwenden. Dann braucht dein Server gar keinen offen Port.

[ctwx]

Aber dann müsste die andere Person, die auf meinen Minecraft-Server möchte das bei sich einrichten?
Wenn ja, ist das denke ich zu kompliziert.

[debilian]

wireguard ist nicht kompliziert

[ctwx]

wireguard ist nicht kompliziert

Aus meiner Sichtweise gebe ich dir recht, aber Leute die kein Bock auf solche Technik haben sind da schwieriger zu überzeugen.

Mal so eine andere Frage. Ich wollte Passwort-Login gerade deaktivieren und habe nach "PasswordAuthentication" in der sshd_config gesucht und bin auf einen Kommentar zu UsePAM gestoßen:

Code: Alles auswählen

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the KbdInteractiveAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via KbdInteractiveAuthentication may bypass
# the setting of "PermitRootLogin prohibit-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and KbdInteractiveAuthentication to 'no'.
UsePAM yes

Sollte ich da noch etwas umstellen?

Ansonsten hätte ich die folgenden Einstellungen vorgenommen:

Code: Alles auswählen

PermitRootLogin no
PasswordAuthentication no
PermitEmptyPasswords no
PubkeyAuthentication yes

[cosinus]

Kannst auch einen Remote-Tunnel verwenden. Dann braucht dein Server gar keinen offen Port.

Das VPN-Gedöns braucht keinen offenen Port?!

[uname]

Das VPN-Gedöns braucht keinen offenen Port?!

Naja. Ich hatte mal vor einiger Zeit eine Fernwartungslösung auf Basis von früher screen nun tmux bzw. eigentlich SSH-Remote-Port-Forwarding geschrieben. Lies ab hier.

Man könnte es so machen. Der hochsichere Server verfügt über einen SSH-Server, der jedoch nur auf "localhost" horcht. Dieser wird zur weiteren Absicherung z. B. nur per SSH-Key erlaubt. Der hochsichere Server hat einen CRON-Job, der z. B. jede Minute eine URL aufruft (z. B. wget) und dort auf eine Information (z. B. IP-Adresse / Whitelist) wartet. Taucht diese auf der Webseite auf (nur wenn man den hochsicheren Server fernwarten will), dann baut der hoch sichere Server eine SSH-Verbindung zu der IP-Adresse auf und stellt einen Remote-SSH-Tunnel bereit. Auf dem Adminserver mit der IP-Adresse reicht /bin/false für den Benutzer, dort wird dann der Remote-SSH-Forwarding-Port bereitgestellt. Nun kann sich der Administrator mit geeignetem SSH-Key mit dem Remote-SSH-Tunnel verbinden, der eine Verbindung auf den SSH-Server (localhost) des hoch sicheren Servers aufbaut.

- der hoch sichere Server ist per SSH remote nicht erreichbar, nur über den Remote-Tunnel
- der andere Rechner muss auch nur temporär einen SSH-Server bereitstellen
- eine Whitelist für erlaubte IP-Adressen macht es sicherer
- der SSH-Key macht es sicherer

Folgendes wäre dann nicht zum Problem geworden: heise - Hintertür in xz-Bibliothek gefährdet SSH-Verbindungen

Aber wohl nur etwas für Personen, die kein VPN nutzen wollen und einzig auf SSH setzen.

[speefak]

https://speefak.spdns.de/oss_lifestyle/ ... n-sichern/

Per Script werden täglich die Fail2Ban Logs via MTA (postfix) versendet. Nach 3 falschen Loginversuchen wird die IP für 3 Stunden gesperrt. nach 6 falschen Loginversuchen innerhalb von 24 Stunden landet die IP auf der Blacklist und wird per iptables für jeglichen Zugang gesperrt. Anhand der täglichen Berichte sieht man recht schnell wer sich wie von wo einloggen wollte oder eingeloggt hat.

[speefak]

Das VPN-Gedöns braucht keinen offenen Port?!

Naja. Ich hatte mal vor einiger Zeit eine Fernwartungslösung auf Basis von früher screen nun tmux bzw. eigentlich SSH-Remote-Port-Forwarding geschrieben. Lies ab hier.

Man könnte es so machen. Der hochsichere Server verfügt über einen SSH-Server, der jedoch nur auf "localhost" horcht. Dieser wird zur weiteren Absicherung z. B. nur per SSH-Key erlaubt. Der hochsichere Server hat einen CRON-Job, der z. B. jede Minute eine URL aufruft (z. B. wget) und dort auf eine Information (z. B. IP-Adresse / Whitelist) wartet. Taucht diese auf der Webseite auf (nur wenn man den hochsicheren Server fernwarten will), dann baut der hoch sichere Server eine SSH-Verbindung zu der IP-Adresse auf und stellt einen Remote-SSH-Tunnel bereit. Auf dem Adminserver mit der IP-Adresse reicht /bin/false für den Benutzer, dort wird dann der Remote-SSH-Forwarding-Port bereitgestellt. Nun kann sich der Administrator mit geeignetem SSH-Key mit dem Remote-SSH-Tunnel verbinden, der eine Verbindung auf den SSH-Server (localhost) des hoch sicheren Servers aufbaut.

- der hoch sichere Server ist per SSH remote nicht erreichbar, nur über den Remote-Tunnel
- der andere Rechner muss auch nur temporär einen SSH-Server bereitstellen
- eine Whitelist für erlaubte IP-Adressen macht es sicherer
- der SSH-Key macht es sicherer

Folgendes wäre dann nicht zum Problem geworden: heise - Hintertür in xz-Bibliothek gefährdet SSH-Verbindungen

Aber wohl nur etwas für Personen, die kein VPN nutzen wollen und einzig auf SSH setzen.

Einfacher wäre es doch, wenn der Server auf einer Adresse einen sich ändernden "Key" erwartet ( Unixtime / 10 z.B. ) und wenn der "Key" passt dann den SSH Server für z.B. 60 Sekunden startet und danach wieder beendet bzw. aufs LAN beschränkt.

[uname]

Einfacher wäre es doch, wenn der Server auf einer Adresse einen sich ändernden "Key" erwartet ( Unixtime / 10 z.B. ) und wenn der "Key" passt dann den SSH Server für z.B. 60 Sekunden startet und danach wieder beendet bzw. aufs LAN beschränkt.

Ich denke ein normaler SSH-Key ist sicher genug. Das eigentliche Sicherheitsrisiko sind wohl Lücken innerhalb von SSH siehe mein Link. Und SSH wirst du nur los, wenn du es entweder nicht verwendest oder z. B. durch einen anderen VPN schickst.

[MSfree]

Das eigentliche Sicherheitsrisiko sind wohl Lücken innerhalb von SSH.

Richtig, und so eine Lücke hatte mich vor etwa 20 Jahren selbst erwischt. Ein Angreifer hatte es geschafft, trotz Absicherung via Keyfiles, Schadsoftware auf meiner Kiste zu instalieren und meine (damals noch) ipchains-Regeln zu modifizieren. Das ist allerdings schnell aufgefallen weil die Internetgeschwindigkeit eingebrochen war und ich als erste Gegenwehr das Netzwerkkabel einfach abgezogen habe. Die Kiste wurde dann frisch aufgesetzt und SSH zusätzlich abgesichert.

Als erste Maßnahme habe ich ein Programm geschrieben, das nur akzeptierte Quell-IP-Adressen durchgelassen hat. Mit dem damaligen ipchains aber auch mit iptables und nftables läßt sich so eine Regel aber nicht einfach in Firewallregeln umsetzten, weil die Quell-IP sich durch dynamische IP-Adressvergabe ändert und ein reverse DNS-Lookup auf die Quell-IP nichts brauchbares liefert.

Dem Programm wird eine Liste von Hostnamen mitgegeben, denen einen Verbindungsaufnahme via SSH erlaubt ist. Kommt nun ein SSH-Paket herein, wird geprüft, ob die IP-Adresse zu einer der erlaubten Hostnamen paßt. Wenn ja, wird das Paket durchgelassen. Das erfordert natürlich, daß die Quellrechner ihre öffentliche IP-Adresse bei einem DynDNS-Dienst registrieren.

Da aber mittlerweile die DynDNS-Anbieter ziemlich unzuverlässig geworden sind und/oder Geld sehen wollen, bin ich dazu übergegangen, das Programm auf Pingknocking zu erweitern. Wenn der Quellrechner zuerst ein Pingpaket mit einer bestimmten Payload schickt, wird der SSH-Port für eine Minute und nur für die Quell-IP aus dem Ping-Paket geöffnet.

Die Payload ist ein SHA256-Hash, der aus einer Passphrase und der aktuellen Uhrzeit gerechnet wird, so daß der Hash nur 60 Sekunden gilt. Ein mitgeschnittenes Pingpaket zwecks Payloadextraktion ist dadurch nur kurze Zeit gültig. Benötigt wird dazu allerdings ein modifiziertes Ping-Programm, das die Payload erzeugen kann.

[uname]

Als DynDNS-Anbieter nutze ich https://ddnss.de. Funtkioniert seit Jahren problemlos, wobei ich den Namen aber eher auch nie nutze und ich Ausfälle vielleicht gar nicht bemerke. Zur Einschränkung von SSH-Keys kann man in der authorized_keys den Parameter "from:" verwenden falls es jemanden interessiert.

Aber wie geschrieben: Gegen Fehler in SSH selbst hilt es dann auch weniger.

[niemand]

[ich bin] dazu übergegangen, das Programm aufPingknocking zu erweitern. Wenn der Quellrechner zuerst ein Pingpaket mit einer bestimmten Payload schickt, wird der SSH-Port für eine Minute und nur für die Quell-IP aus dem Ping-Paket geöffnet.

Die Payload ist ein SHA256-Hash, der aus einer Passphrase und der aktuellen Uhrzeit gerechnet wird, so daß der Hash nur 60 Sekunden gilt. Ein mitgeschnittenes Pingpaket zwecks Payloadextraktion ist dadurch nur kurze Zeit gültig. Benötigt wird dazu allerdings ein modifiziertes Ping-Programm, das die Payload erzeugen kann.

Das liest sich sehr interessant – gibt es da nähere Dokumentation zu? Die Suchmaschinen sind leider kaputt, und geben stattdessen Ergebnisse für Portknocking oder für Fahrzeugprobleme aus. Es gibt ’nen sehr alten Thread in ’nem Forum von Mikrotik, aber das trifft’s auch nicht genau.

[MSfree]

Das liest sich sehr interessant – gibt es da nähere Dokumentation zu?

Den Knockingdaemon habe ich selbst geschrieben, das Pingprogramm habe ich aus den Quellen des originalen Pings modifiziert. Der Quellcode ist die Dokumentation
Aber im Ernst, der Quellcode steht nicht auf einem öffentlich zugänglichen CVS/SVN/GIT. Ich könnte die Quellen aber öffentlich machen, die Methode soll ja kein Security by Obscurity sein. Im Moment funktioniert das aber noch mit iptables und ist nicht auf nftables umgestellt.

Die Suchmaschinen sind leider kaputt

Egentlich ist nur Bing kaputt. Die Ente nutzt ja den Suchindex von Bing. Ob es nun besser ist, MS seine Daten zuzuwerfen oder gleich google zu nutzen, überlasse ich dir. Google funktioniert jedenfalls bestens.

Es gibt ’nen sehr alten Thread in ’nem Forum von Mikrotik, aber das trifft’s auch nicht genau.

Ich habe Pingknocking hier im Forum vor vielen Jahren schonmal beschrieben.

Im Grunde ist Portknocking eine Alternative. Man schickt eine bestimmte Sequenz an UDP-Paketen auf vorher festgelegte Ports, der Portknockingdaemon entscheidet aufgrund der Sequenz, ob die Anfrage gültig ist und veranlaßt dann irgeneine Aktion, z.B. die Freigabe eines Netzwerkports für eine gewisse Zeit. Portknocking hat aber den Nachteil, daß man die UDP-Pakete nicht durch jede Firewall bekommt. Firmen sperren gerne auch mal ausgehenden Verkehr, so daß man mit Portknocking teilweise auf dem trockenen sitzt.

Pingknocking funktioniert sehr ähnlich, es reicht aber ein einziges Ping-Paket, in dem man eine Payload einbettet, die der Pingknockingdaemon auf der Gegenseite untersuchen kann und eine Aktion ausführen kann.

Diese Aktion kann im Grunde alles sein, von einer Portfreigabe bis zum Starten eines Backupskriptes oder dem Hochderhen der Heizkörper im vernetzten Smarthome...

[niemand]

Egentlich ist nur Bing kaputt. Die Ente nutzt ja den Suchindex von Bing. Ob es nun besser ist, MS seine Daten zuzuwerfen oder gleich google zu nutzen, überlasse ich dir. Google funktioniert jedenfalls bestens.

Ich habe drei Suchmaschinen verwendet, darunter Google. Aus vermutlich dem Grund, den du selbst oben genannt hast, gab’s da kein passendes Ergebnis.

Pingknocking funktioniert sehr ähnlich, es reicht aber ein einziges Ping-Paket, in dem man eine Payload einbettet, die der Pingknockingdaemon auf der Gegenseite untersuchen kann und eine Aktion ausführen kann.

Das Problem, das ich beim Portknocking sehe: es ist aufzeichenbar (es sei denn, knockd erlaubt wechselnde Folgen aufgrund eines gemeinsamen Geheimnisses – was aber beim schnellen Drüberschauen nicht danach aussieht). Deswegen erschien’s mir recht geschickt, das mit einem ICMP-Paket erledigen zu können und ich hatte gehofft, dass jemand das bereits offen umgesetzt hätte.
Letztlich handhabt der Kernel die ICMP-Pakete, oder? Lässt sich die Payload dann ohne Modifikationen daran etwa via ip/nftables extrahieren?