Macht es Sinn, denn SSH Zugang auf den IP Adressraum des eigenen ISP zu beschränken?

E

Exploit

Member
Mal angenommen man hätte einen Server mit ssh Zugang im Netz stehen.
Würde es dann Sinn machen, den IP Adressraum für den ssh Zugang auf den des eigenen ISP zu beschränken?

Der Gedanke wäre hier, dass man so andere Angreifer außerhalb des Adressraums des ISP schon einmal vom Zugang auf den ssh Dienst abhält.
Zugang würde es somit nur für die Angreifer geben, die auch eine IP innerhalb des Adressraums des ISP haben.

Wäre so etwas empfehlenswert?
Und falls ja.
Was wäre in dem Fall, wenn der ISP komplett neue IP Räume einkauft und man nun so eine IP erhalten würde, dann hätte man ja keinen Zugriff auf den eigenen Server mehr, weil die FW des Servers ja noch nicht so konfiguriert ist, dass er diese neuen IPs als Teil des ISP kennt.


Und was ich mich auch frage.
Machen so etwas in der Art vielleicht Serverbetreiber, die einige Server remote warten sollen, selber?
Also dass sie z.B. zwei Server als ssh Schleuse einstellen und nur über diese zwei Server sind dann die anderen Server, die im Netz hängen, via ssh erreichbar?
 
Moin Exploit,

naja Sinn macht es schon den SSH Zugang nur auf einen bestimmten IP-Bereich zu beschränken allerdings bringt das zwei Probleme mit sich.

Zum einen können damit auch Kunden von deinem Provider auf den SSH Server zugreifen oder diesen sogar gezielt angreifen zum anderen hat dein ISP in der Regel mehrere Netze aus denen deinem Router jeweils eine dynamische IP zugewiesen wird, diese ändert sich auch meist nach einer gewissen Zeit.

Je nach Anbieter kannst du dir aber eine statische IP für einen kleinen Beitrag dazu mieten und diese dann in der FW für SSH freigeben.
Ansonsten SSH Port ändern, das hält die meisten Angreifer schon fern.
 
Hallo,

das Thema ist durchaus sinnvoll - allerdings muss dabei einiges beachtet werden.

Wenn du, wie DasBill bereits gesagt hast, über statische IP-Adressen verfügst, kannst du das direkt umsetzen - alternativ werden häufigt auch Zwischenserver (so genannte Bastion Host / Jumpserver / Jumphosts) eingesetzt.

Je nach Realisierung können das Server sein, die eine eigene grafische Benutzeroberfläche und alle zur Administration notwendigen Tools mitbringen (also quasi als Admin-Workstation dienen) oder aber einfache SSH-Gateways, die ggf. per Benutzer-basierten Firewall-Regeln (oder den Möglichkeiten, die SSH selbst bietet) die Zugriffe auf weitere Server beschränken.

Gruß
Markus
 
Bei entsprechender Konfiguration bringt das Limitieren der Client-IP keine signifikante zusätzliche Sicherheit.

SSH Key Auth ist schon sehr sicher. Für meine persönlichen Server habe ich zusätzlich noch OTP/Passwort Auth eingerichtet für den Fall, dass ich mal von einem fremden Rechner zugreifen will (SSH Private Keys haben auf fremden Geräten nichts zu suchen). Dabei wird erst ein Yubi-Key verlangt und danach ein Passwort.

Wenn du die Sicherheit wirklich ausreizen willst, dann könntest du OTP+SSH Key einrichten. Das würde allerdings einen enormen Verlust an Komfort mit sich bringen.
 
elias5000 said:
Bei entsprechender Konfiguration bringt das Limitieren der Client-IP keine signifikante zusätzliche Sicherheit.
Click to expand...

Mit der Argumentation würde aus meiner Sicht eine Auftrennung von Diensten in DMZ / MZ dann auch keinen Sinn mehr machen.

Wenn du den Angriffsvektor "freien Zugriff aus dem Internet" auf "Zugriff über einen definierten Weg" abänderst erhöhst du die Gesamt-Sicherheit der Umgebung schon.

Gruß
Markus
 
Ich danke für eure Antworten.
Der Hinweis auf ISP Netzausfall. Urlaub usw. oder auch OTP/Passwort sind gute Argumente.

Gibt es die Möglichkeit OTP/Passwort und die Einschränkung des IP Adressraums zu kombinieren?
Also dass für ein Login mit OTP/Passwort die Einschränkung des IP Adressaum nicht gilt, für den normalen Login aber schon.

So wäre der Rechner auch noch im Urlaub via OTP/Passwort erreichbar, aber der normale Login nicht von fremden Rechnern aus angreifbar.

Da die Einschränkung des IP Adressraums vermutlich auf FW Ebene stattfindet, wäre die Frage, ob man den sshd Server auf zwei Ports laufen lassen könnte.
Der eine Port für OTP/Passwort und der andere für den normalen Login, damit wäre das auch von der FW aus gut konfigurierbar.

Die Frage ist halt, ob man so den Angriffsvektor nicht auch erhöht.
Denn wenn man eine Liste von 20 OTP/Passwörtern anlegt, dann steigt bei einem BruteForceangriff aus einem Botnetz natürlich auch die Möglichkeit, dass eben doch ein PW erwischt wird, es gibt so gesehen ja mehr als nur ein PW, wenn auch dieser Angriffspunkt sehr minimal sein dürfte.
 
Eine Sache, die auch oft vergessen wird: Wenn jemand gezielt Deinen Server angreifen möchte, ist es für den Angreifer sicherlich kein Problem, Deinen ISP herauszufinden und danach ein System mit einer passenden IP-Adresse zu finden oder zu mieten.

Was meiner Meinung nach sinnvoller ist, wenn man so paranoid ist: SSH-Port über ein (lokales) VPN tunneln.


MfG Christian
 
Exploit said:
Denn wenn man eine Liste von 20 OTP/Passwörtern anlegt, dann steigt bei einem BruteForceangriff aus einem Botnetz natürlich auch die Möglichkeit, dass eben doch ein PW erwischt wird, es gibt so gesehen ja mehr als nur ein PW, wenn auch dieser Angriffspunkt sehr minimal sein dürfte.
Click to expand...

Du hast ja eine Kombination aus einem statischen Passwort und einem OTP (deshalb nennt man das auch 2-Faktor-Auth*). Das ganze muss natürlich so implementiert werden, dass es unmöglich ist, auf die Richtigkeit des statischen Passwortes zu schließen ohne das OTP richtig zu haben.
Das geht z.B. über die PAM-Config, die eben erst das OTP erwartet und danach das statische Passwort.

Nur wenn das OTP stimmt wird der Client nach dem statischen Passwort gefragt, anderenfalls abgewiesen. Das Wissen darum, ein OTP korrekt erraten zu haben, ist wertlos, da das OTP mit der einmaligen Benutzung ungültig geworden ist. (Deshalb ja OTP - One Time Password).
Der Angreifer hat also bei einer Liste von 20 OTP maximal 20 Versuche das statische Passwort zu erraten.

Das statische Passwort ist dafür da den Fall abzusichern, dass jemand in den Besitz deiner OTP-Liste oder deines OTP-Device kommt.

*) Die zwei Faktoren sind 1. etwas, das du besitzt (OTP-Liste oder OTP-Device) und 2. etwas, das du weißt (statisches Passwort). Jedes Auth-Verfahren, das nicht zwei unterschiedliche Faktoren verlangt (wissen, besitzen) ist keine echte 2-Faktor-Auth.

PS: Ich habe gerade gesehen, dass es den legacy-Yubi-Key, den ich benutze, gar nicht mehr gibt - die neuen sind ultra-teuer.
U2F scheint gerade der heiße Scheiß zu sein. Da bekommt man Devices auch schon deutlich unter 10EUR.
 
Last edited by a moderator:
Was spricht gegen eine Firewall-Regel, welche den SSH-Port für einen bestimmten DNS-A-Record öffnet. Der DNS-A-Record könnte per dynamic-DNS geupdatet werden?
 
Was spricht dagegen, wenn man paßwortbasierte Authentifizierung einfach deaktiviert und nur keybasierte Authentifizierung zuläßt?
Dann ist es nämlich völlig schnurz, von wo aus man auf das System zugreift, ohne passenden Key kommt man eben nicht rein.
Jede zusätzliche Konfigurierung abseits von den bereits gegebenen Möglichkeiten erhöht nur den administrativen Aufwand und birgt immer das Risiko einer fehlerhaften Konfiguration.

Außerdem findet nur der geringste Teil aller Angriffe auf Systemebene statt. Die meisten und größten Sicherheitslücken gibt es immer auf Anwendungsebene.
 
nexus said:
Was spricht dagegen, wenn man paßwortbasierte Authentifizierung einfach deaktiviert und nur keybasierte Authentifizierung zuläßt?

Außerdem findet nur der geringste Teil aller Angriffe auf Systemebene statt. Die meisten und größten Sicherheitslücken gibt es immer auf Anwendungsebene.
Click to expand...

Ist ja ein Widerspruch an sich. SSH bzw. davon genutzte Libs sind ja eben Anwendungen.

Also ist es schon sinnvoll den Zugriff auf die Anwendung per Firewall vorab zu unterbinden.
 
mr_brain said:
Ist ja ein Widerspruch an sich. SSH bzw. davon genutzte Libs sind ja eben Anwendungen.
Click to expand...

Nein, ich meinte eher Webanwendungen (CMS, Webshops, Foren, etc.). SSH & Co. sehe ich in diesem Kontext als Bestandteil des Grundsystems.

mr_brain said:
Also ist es schon sinnvoll den Zugriff auf die Anwendung per Firewall vorab zu unterbinden.
Click to expand...

Wozu? Ohne passenden Key kommt man doch sowieso nicht rein. Wenn du diesen Grundgedanken konsequent auf alle benutzten Ports umsetzen wolltest, dann wird dein Firewall-Regelwerk ganz schnell ganz groß ;)
 
Last edited by a moderator:
nexus said:
Wozu? Ohne passenden Key kommt man doch sowieso nicht rein. Wenn du diesen Grundgedanken konsequent auf alle benutzten Ports umsetzen wolltest, dann wird dein Firewall-Regelwerk ganz schnell ganz groß ;)
Click to expand...

Wenn das SSH oder eine Lib ein Bug hat und dadurch der Key ausgehebelt werden kann.

Ist halt wie ein Cabrio in der Wüste parken. Es regnet vermutlich nie, wenn du immer dein Cabrio mit offenem Verdeck in der Wüste parkst. Nur wenn es dann doch mal regnet, dann hättest du es vielleicht besser immer mit geschlossenem Verdeck abgestellt.

Was soll daran ein großes Regelwerk werden? Ggf. scriptet man sich schnell ein Drei-Zeiler.
 
mr_brain said:
Wenn das SSH oder eine Lib ein Bug hat und dadurch der Key ausgehebelt werden kann.
Click to expand...

Und wenn das Firewallprogramm dann einen Bug hat...? ;)
Die Wahrscheinlichkeiten ist in beiden Fällen verschwindend gering und ist eigentlich vernachlässigbar.
Genau genommen müßte man den Server abschalten, wenn man keinerlei Risiken eingehen wollte.

Meine Intention in Richtung Key-based Auth war auch eher in Bezug auf die weiter oben angesprochenen Alternativen wie OTP gerichtet.
Es ist einfach eine Frage von Aufwand und Nutzen. Auch wenn es bei der heute verwendeten Technik und bei den normal schon sehr guten Anbindungen weniger ins Gewicht fällt, so macht es trotzdem performancetechnisch einen Unterschied, ob bei einem gut ausgelasteten Server mit mehreren hundert Requests pro Sekunde jeder Request gegen 20 oder gegen 200+ Firewallregeln geprüft werden muß.
 
nexus said:
... Auch wenn es bei der heute verwendeten Technik und bei den normal schon sehr guten Anbindungen weniger ins Gewicht fällt, so macht es trotzdem performancetechnisch einen Unterschied, ob bei einem gut ausgelasteten Server mit mehreren hundert Requests pro Sekunde jeder Request gegen 20 oder gegen 200+ Firewallregeln geprüft werden muß.
Click to expand...

Was wird wohl eher in die Knie gehen, die Firewall oder die Anwendung? Die Firewall verwirft ggf. direkt die Pakete. Was macht die Anwendung, die beantwortet sogar noch jede Anfrage.
 
Ich sehe das auch so. Bugs in OpenSSH gab es schon und wird es auch immer mal wieder geben. Deswegen ist eine Zweite von OpenSSH unabhängige Schutzmassnahme grundsätzlich sinnvoll. Da kann dann eine der beiden Schutzmassnahmen zeitweilig einen schwere Sicherheitslücke haben und das Ganze hält trotzdem noch.

Die ultimative 2. Schutzschicht, die auch noch bequem ist, ist mir aber auch noch nicht eingefallen. Wenn Bequemlichkeit nicht relevant ist kann man mit Portknocking und/oder VPN, die Sicherheit nochmal kräftig erhöhen.
 
nexus said:
Meine Intention in Richtung Key-based Auth war auch eher in Bezug auf die weiter oben angesprochenen Alternativen wie OTP gerichtet.
Click to expand...

Ich weiß nicht ob das so klar raus kam: Ich empfahl SSH-Key _oder_ OTP+Passwd. Anderenfalls würde ich mir jeden mal in den Ar*** beißen, wenn ich mich irgendwo einloggen will.

Um auch noch was substanzielles zu schreiben: Ich stimmt nexus in seiner Argumentation zu.
Sich an der Absicherung eines sowieso schon recht sicheren Zugangs abzuarbeiten bindet nicht nur unnötig Ressourcen, die anderer Stelle sinnvoller eingesetzt werden können. Zudem vernebelt es die Sicht auf die reale Angriffsfläche der einzelnen Angriffsvektoren. SSH mag für den Admin ein enorm mächtiger Zugang zum System sein. Er bietet aber eine sehr kleine Angriffsfläche, da es für den nicht angemeldeten Client nur eine sehr überschaubare Funktionalität anbietet (nämlich sich einzuloggen - ohne das Login geht nämlich erstmal gar nichts).
Die Dienste, die gewollt allen zugänglich sind, bieten dagegen viel größere Angriffsflächen. Da laufen dann Web-Anwendungen, die unangemeldeten Benutzern Eingaben ermöglichen welche dann verarbeitet werden. Dateien können hochgeladen werden. Vom Client geschickte Datenstrukturen müssen durch Parser und Libraries geschickt werden. Software verschickt emails und generiert Datenbank-Abfragen. Und das alles mit vom Client beigesteuertem Inhalt.

Um es mal als Vergleich auszudrücken (das scheint ja hier sehr beliebt zu sein):
Man kann natürlich auch an der Sicherheitstür noch einen Riegel anbringen und ein weiteres Schloss und davor noch eine Tür stellen. Wenn der Einbrecher dann durchs Fenster kommt, dann nützen einem die ganzen Schlösser exakt gar nichts. Die Konzentration auf die Tür hat nur davon abgelenkt, wo die tatsächliche Schwachstelle war.
 
You must log in or register to reply here.
Back
Top