SSH nur über Public IP erlauben

[r3v0]

hello. Ich bin neu hier und hab eigentlich nur eine kurze frage:
Wie stell ich es an das ich eine debainkiste nur über die öffenltiche ip (port fowarding steht schon) erreich.
Ich möchte nicht das man innerhalb des netzwerkes per ssh zugriff hat sonder NUR VON AUSERHALB.

Soweit ich das verstanden habe gehts mit

Code: Alles auswählen

iptables -A INPUT -p tcp -s <adresse des internet gateway> --dport 22 -j ACCEPT

ist das so korrekt?
LG

[mat6937]

Wie stell ich es an das ich eine debainkiste nur über die öffenltiche ip (port fowarding steht schon) erreich.
Ich möchte nicht das man innerhalb des netzwerkes per ssh zugriff hat sonder NUR VON AUSERHALB.

Soweit ich das verstanden habe gehts mit

Code: Alles auswählen

iptables -A INPUT -p tcp -s <adresse des internet gateway> --dport 22 -j ACCEPT

ist das so korrekt?
LG

Hast Du z. Zt. auch Zugang zum sshd-Server, per Bildschirm und Tastatur (... wegen evtl. Aussperren)?

Wenn ja, dann versuch mal:

Code: Alles auswählen

iptables -I INPUT 1 -p tcp -s <internes-Netzwerk> --dport 22 -j REJECT

BTW: Ist die öffentliche source-IP-Adresse (d. h. die des ssh-Clienten) immer die gleiche oder können das auch verschiedene öffentliche source-IP-Adressen sein?

[r3v0]

Wenn ja, dann versuch mal:

Code: Alles auswählen

iptables -I INPUT 1 -p tcp -s <internes-Netzwerk> --dport 22 -j REJECT

<internes-netwerk> zb 192.168.1.1-254 oder?
ich hab leider keine direkten zugang, eben nur über die öffentlich ip.

BTW: Ist die öffentliche source-IP-Adresse (d. h. die des ssh-Clienten) immer die gleiche oder können das auch verschiedene öffentliche source-IP-Adressen sein?

Können auch verschiedene sein.

Ich hab sowas vorher noch nie eingerichtet deshalb hab ich ansgt mich auszusperren

[mat6937]

<internes-netwerk> zb 192.168.1.1-254 oder?
ich hab leider keine direkten zugang, eben nur über die öffentlich ip.

Ich hab sowas vorher noch nie eingerichtet deshalb hab ich ansgt mich auszusperren

D. h., wenn die iptables-Regel, zum testen erstmal nur im Arbeitsspeicher ist, könnte man im Falle des Aussperrens den Stecker ziehen? Oder ist das (stromlos machen) auch nicht möglich bzw. wird durch "Stecker ziehen" evtl. etwas beschädigt (Datenträger, etc., ...) oder gleichwertig?

[r3v0]

nein ist auch nicht möglich

[mat6937]

nein ist auch nicht möglich

Hmm, ... bei solchen Konstellationen stelle ich immer Redundanz her. D. h. nie nur einen Zugang, sondern mind. 2 (evtl. den 2. auch nur temporär). Z. B. zusätzlich eine OpenVPN-Verbindung, in der man temporär telnet (oder gleichwertig) nutzen kann, falls mit dem ssh was schief geht.

[mludwig]

Man kann auch einen reload vorgeben, der die Kiste in einer vorgegebenen Zeit neu startet (und somit wieder erreichbar macht). Sperrt man sich aus muss man halt max. 30 Minuten warten:

Code: Alles auswählen

shutdown -r +30

rebootet in 30 Minuten. Wenn alles klappt mit

Code: Alles auswählen

shutdown -c

den reboot abbrechen und die Einstellungen in die Startup-Konfiguration übernehmen. Das geht natürlich nur wenn auf dem Server nichts läuft was dauerhaft verfügbar sein muss. Aber dann sollte man solche Basteleien dort nicht durchführen, sondern auf einem Testsystem.

Häufigster Fehler: es ist alles getestet, hat geklappt und man freut sich, auf einmal bootet die Kiste neu weil man shutdown -c vergessen hat ...

[MSfree]

Man kann auch einen reload vorgeben, der die Kiste in einer vorgegebenen Zeit neu startet (und somit wieder erreichbar macht). Sperrt man sich aus muss man halt max. 30 Minuten warten:

Vorsicht!

Je nach dem, was installiert ist, kann es sein, daß beim Shutdown iptables-save und beim Boot iptables-restore ausgeführt wird. Somit überleben eingestellte Filter ein Reboot und du bleibst ausgesperrt.

[r3v0]

hm. ok. das ganze läuft im rahmen einer challenge ab, alle anderen punkte der challenge kann ich auf anhieb, nur da bin ich mir echt unsicher auch wegen dem aussperren. ich hab nur hostname, user und pw und die todo liste bekommen,
ich mach natürlich alles andere vorher und dann versuch ich iptables umzustellen für den fall dass das schief geht hab ich wenigstens den rest erledigt.
Auf jeden fall herzlichen dank für die info's und falls noch jemand seinen senf dazugeben will, nur her damit.
bin immer für know how dankbar.

[MSfree]

falls noch jemand seinen senf dazugeben will, nur her damit.
bin immer für know how dankbar.

Statt sich mit iptables abzumühen könntest du den Login aus dem LAN auch in der Datei /etc/ssh/sshd_config beschränken mit:

Code: Alles auswählen

Match Address 192.168.1.0/24
DenyUsers *

Danach muß der SSH-Server neu gestartet werden. Wenn du dabei deine exisiterenden SSH-Verbindung nicht schließt und die einfach ein zweites mal einlogst, kannst du sicherstellen, daß du dich nicht ausgesperrt hast, und im Fall einer Aussperrung die erste Session nutzen, um die Änderungen rückgängig zu machen.

[r3v0]

Statt sich mit iptables abzumühen könntest du den Login aus dem LAN auch in der Datei /etc/ssh/sshd_config beschränken mit:

Code: Alles auswählen

Match Address 192.168.1.0/24
DenyUsers *

Danach muß der SSH-Server neu gestartet werden. Wenn du dabei deine exisiterenden SSH-Verbindung nicht schließt und die einfach ein zweites mal einlogst, kannst du sicherstellen, daß du dich nicht ausgesperrt hast, und im Fall einer Aussperrung die erste Session nutzen, um die Änderungen rückgängig zu machen.

Cool. Ich dachte mir schon das es pber sshd_config auch gehen muss.
Herzlichen Dank!!

[TomL]

Genau wie msfree das vorgeschlagen hat.... und weil es sich um einen Zugang von außen handelt, würde ich zusätzlich noch entweder den SSH-Port 22 entweder am Router alleine oder beide (Router und PC ) von 22 auf >55000 setzen. Ein Port >55000 reduziert zumindest die Lautstärke des Rauschens durch die Scriptkiddies und irgendwelchen anderen Standardversuchen den Port 22 zu erreichen. Mit Keyfiles und Passphrase bist Du dann auf einer einigermaßen sicheren Seite.

[mat6937]

... das es pber sshd_config auch gehen muss.

Ja, aber es darf nur nicht passieren, dass die 1. Verbindung zwischen dem sshd-Server und dem ssh-Client, im Zeitraum zwischen der ersten Anmeldung (ohne geänderte sshd_config) und dem evtl. erforderlichen rückgängig machen der (bereits gespeicherten) Änderung, unterbrochen wird.

[MSfree]

Ja, aber es darf nur nicht passieren, dass die 1. Verbindung zwischen dem sshd-Server und dem ssh-Client, im Zeitraum zwischen der ersten Anmeldung (ohne geänderte sshd_config) und dem evtl. erforderlichen rückgängig machen der (bereits gespeicherten) Änderung, unterbrochen wird.

Wenn du den SSH-Server mit systemctl restart ssh neu startest, wird die bestehende SSH-Verbindung nicht gekappt.

[mat6937]

Wenn du den SSH-Server mit systemctl restart ssh neu startest, wird die bestehende SSH-Verbindung nicht gekappt.

Das ist richtig, aber das meinte ich nicht.

Ich meinte wenn z. B. hier in diesem konkreten Fall, die Internetverbindung unterbrochen wird und somit auch die gerade vorhandene Verbindung zwischen dem ssh-Client und dem sshd-Server unterbrochen wird.

[MSfree]

Ich meinte wenn z. B. hier in diesem konkreten Fall, die Internetverbindung unterbrochen wird und somit auch die gerade vorhandene Verbindung zwischen dem ssh-Client und dem sshd-Server unterbrochen wird.

Das wäre in der Tat ungemütlich, wenn du dich in eine Konfigurationssackgasse manövriert hättest.

Weiter ober wurde ja schon angesprochen, einen weiteren Kanal, wie z.B. OpenVPN zumindest temporär zu öffnen, über den man sich via telnet noch am Rechner einloggen kann. Da telnet hier über VPN läuft, wäre es verschlüsselt und verhältnismässig sicher. Allerdings sollte man es vermeiden, telnet nach aussen zu öffnen und ausschließlich durch den VPN-Tunnel erlauben.

Eine weitere Möglichkeit wäre, telnet via SSL zu fahren, um einen zweiten Kanal in der Hinterhand zu haben.

[wanne]

ICh würde ganz gern noch darauf aufmerksam machen:
Ist das GW eine NAT box, kannst du dich da meistens einfach so naten lassen – auch aus dem Internen Netz: Du änderst einfach die Netzwerkmaseke und alles läuft über das GW auch der Interne Traffic. Und weil NAT ja dazu führt, dass es für den Empfänger so aussieht als käme die Verbindung von der NAT box ist dann alles gut.
Daneben gibt es noch IPv6. Das erschlägt deine iptables Regel nicht. Auch die SSH-config würde ich da mal updaten.

[mat6937]

Daneben gibt es noch IPv6. Das erschlägt deine iptables Regel nicht.

OK, aber man kann den sshd ja so konfigurieren, dass nur "AddressFamily inet" genutzt wird oder wenn man inet und inet6 hat, kann man ip6tables für evtl. Einschränkungen nutzen.

[wanne]

kann man ip6tables für evtl. Einschränkungen nutzen.

Ja. Darauf wollte ich halt aufmerksam machen. Ist kein Hexenwerk. Wird aber ganz gerne mal vergessen. Habe mir deswegen nen alias ipt gelegt, der immer gleich iptables und ip6tables ausführt. Wobei bei dir müssen ja eh Adressen angepasst werden.

Ansonsten habe ich die NAT problematik ja genannt.