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

nexus

Active Member
Ich weiß nicht ob das so klar raus kam: Ich empfahl SSH-Key _oder_ OTP+Passwd.
Sorry, das war meiner Faulheit geschuldet, nicht immer jeden Kontext zu zitieren, auf den ich mich beziehe. Ich gelobe Besserung. ;)
Ich bezog mich auf die deiner Aussage folgende Äußerung des TE, wo er die Option Key-based Auth übergangen hat:

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.
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.
Mir ging schon die Analogie mit zugemauerter Vordertür (SSH) und offener Hintertür (Webanwendungen) durch den Kopf, aber da warst du schneller :D
 
Last edited by a moderator:

danton

Debian User
Letztendlich gibt es zahlreiche Maßnahmen, um die Sicherheit zu erhöhen. Aber letztendlich muß auch jeder für sich selbst entscheiden, wann diese Massnahmen einem die Arbeit erschweren und ob es der Sicherheitsgewinn wert ist, die damit verbundenen Einschränkungen im Kauf zu nehmen.
Den Sicherheitsgewinn, nur IPs des eigenen ISP den SSH-Zugang zu gestatten (wie es der TE in seinem Eröffnungspost genannt hat), würde ich als eher gering einstufen. Die Nachteile, die das mit sich bringt (die wichtigsten wurden ja schon genannt) und der recht große Aufwand (IP-Ranges ermitteln und regelmäßig auf Aktualität prüfen) sprechen eigentlich dagegen.
Da gibt es Maßnahmen, die meiner Meinung nach wirkungsvoller sind (einige wurden ja schon genannt). Eine Möglichkeit wäre auch, das ganze zu beobachten (bei Key-Auth ein überschaubares Risiko) und IPs/IP-Bereiche zu sperren, die auffällig sind.
 

Exploit

Member
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 statische Passwort ist dafür da den Fall abzusichern, dass jemand in den Besitz deiner OTP-Liste oder deines OTP-Device kommt.
Ach so, okay, dann habe ich das am Anfang falsch verstanden. Wenn das so gelöst ist, dann ist das natürlich eine sehr sichere Sache.

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.
Eine Sicherheitslücke in der Implementierung der sshd Serversoftware und ein darauf folgender 0-Day Exploit könnte dagegen sprechen.
Das ist zwar in der Regel eher eine theoretische Angriffsmöglichkeit aber durchaus potentiell möglich.
Wenn man dagegen den Zugang nur über eine bestimmte IP erlaubt, dann hat man eine weitere Hürde und erkauft sich zumindest so etwas Zeit. Das könnte dann den Ausschlag geben zwischen gehackt und noch einmal davon gekommen.

EDIT:
Ich sehe gerade, das wurde schon diskutiert. Da hätte ich zu Ende lesen sollen.
 
Last edited by a moderator:

greystone

Member
Wo wir bei schlauen Geschichten zum Thema sind:

Ein alter Mann sucht unter eine Laterne seinen Schlüssel. Ein Passant schaut sich das 5 Minuten an, will helfen und fragt: Wo haben Sie denn Ihren Schlüssel verloren? Der alte Mann antwortet: Da drüben im Gras! Verwundert fragt der Passant nach warum er denn Schlüssel dann hier sucht. Da drüben ist so dunkel, da seh ich gar nicht wo ich guck!

Die Moral von der Geschicht: Die einfach Lösungen führen nicht immer zum Ziel.
Auch: Manchen ist nicht mehr zu helfen.
 
Last edited by a moderator:

danton

Debian User
YMMD :D
Bei entsprechender Paranoia kann man sein System bis zur Unnutzbarkeit absichern - dann ist es zwar sicher, aber wenn der Nutzeffekt gegen Null geht, brauche ich das System auch nicht mehr.
Ihr redet hier von IMHO sehr unwahrscheinlichen Szenarien wie einem Zero-Day im SSH-Server. Dabei dürften die meisten Angriffe gegen SSH reine Bruteforce-Attacken sind und das Austesten auf ältere, ungepatchte Lücken - beides Sachen, vor denen man sich mit wenig Aufwand schützen kann. Viel problematischer sind ungeschützte Scripte auf Webseiten - da dürften deutlich mehr Angriffe laufen.
Zumal mittlerweile die meisten Angriffe auf einen schnellen und möglichst unbemerkten Zugriff abzielen, bei dem es nicht einen ganz konkreten Server geht, sondern um irgendeine Kiste, die dann als Bot für Spams, DoS-Angriffe o.ä. ausgenutzt werden kann - also möglichst viele Server mit möglichst wenig Aufwand unter Kontrollen bringen.
 
Top