SSH Jail auf dem Router

SSH Jail auf dem Router sinnvoll?

  • In der Tat, das macht Sinn und erhoeht die Sicherheit

    Stimmen: 4 19,0%
  • Bitte, das bringt doch nichts!

    Stimmen: 11 52,4%
  • Mach doch ssh ganz aus.

    Stimmen: 7 33,3%

  • Umfrageteilnehmer
    21

lockdoc

Well-Known Member
Fuer den Router (2 Nics: intern und extern), hatte ich mir ueberlegt, eine extra SSH Jail zu erstellen, mit nur einem einzigen user. Auf dem Router wird ssh, dann nur noch auf dem internen Interface lauschen und die SSH Jail kriegt nen Forward nach draussen.

So ist man nach dem verbinden auf dem Router erstmal in der Jail eingesperrt anstatt direkt auf dem Router.

Die Frage, ist das Sinnvoll?
 
Nein es klingt wie ein sinnloser "Proxy" mehr. Du wirst größere Angriffsflächen bieten als einen sinnvoll konfigurierten OpenSSHd. Neuere OpenSSHd Versionen haben schon genug Defense in Depth eingebaut und du würdest nur zwei mal die selbe Verteidigung hintereinander bauen. Deswegen ist nach meiner Einschätzung der bestenfalls minimale Sicherheitsgewinn nicht ausreichend um die zusätzliche Komplexität zu rechtfertigen.
 
Also ich verstehe den Zweck des ganzen nicht. Was willst du dann machen können, wenn du in deinem SSH-Jail reinverbunden bist?
 
Damit wollte ich eine 2-Wege Authentifizierung aufbauen. In der Jail kann man ja erstmal nichts machen, da der user keiner Gruppe angehoert, kann er noch nichtmal root werden.

Das einzige was er machen kann ist sich per ssh auf alle weiteren Server zu verbinden - mit den in LDAP gespeicherten credentials.

Somit, sollte es mal jemand tatsaechlich schaffen sich in die Jail per ssh zu verbinden (wie auch immer), braeuchte er dann weitere Zugangsdaten, um ueberhaupt was machen zu koennen, da die Jail ja nur dem einzigen zweck dient, ueberhaupt ins interne LAN zu kommen.

Ich hoffe jetzt ist es etwas klarer ausgedrueckt.
 
Ich sehe das wie Crest. Das bringt nicht wirklich etwas. Lieber die User begrenzen, welche sich per SSH anmelden können...
Code:
AllowUsers XXX
...und dazu noch mit Authentifizierung über Public-Keys aktivieren. Evtl. den Port von 22 noch ändern.
Dies sollte dann wohl genügen denke ich.
 
Hallo.
Grundsätzlich finde ich die Idee nicht schlecht. Aber mir ist das etwas zu umständlich.
Lieber die User begrenzen, welche sich per SSH anmelden können...
[...]
und dazu noch mit Authentifizierung über Public-Keys aktivieren. Evtl. den Port von 22 noch ändern.
Dies sollte dann wohl genügen denke ich.

Genau das mache ich auch so. Aber nicht in einem eigenen SSH Jail sondern mit einem zweiten SSH Server, der die reingelassenen Verbindungen von außen auf einem High Level Port annimmt.
Der SSH auf 22 macht parallel den "ganz normalen" Kram und man darf auch mal per Passwort rein, etc. .
Von außen kommt man halt nur auf den High Level Port an.

Einfach /etc/rc.d/ssh und /etc/ssh/sshd_config kopieren und ein bisschen anpassen.

Grüße
Mario
 
Hallo.

Das sehe ich aus der reinen Sicherheitssicht auch so.
Aber im täglichen Betrieb ist es eher unhandlich. Zum Beispiel haben wir im Firmennetz viele Windows Leute. Die kommen mit dem pageant irgendwie nicht zurecht, müssen aber hin und wieder auf SSH Systeme einloggen.
Dann sind bei uns manche Systeme nur über SSH-Sessions anderer SSH Server zu erreichen. Agent Forwarding muss an sein und überall richtig eingestellt sein. Sonst kommt man gar nicht mehr rein.
Daher gibt es (bei uns) noch immer relativ viele Logins mit Passwort. Wirklich problematisch sehe ich das aber nicht. Es ist ja schon mal gut, das telnet und die R-Tools ausgerottet sind.


Mario
 
Hi,
OpenSSH hat eigentlich alles um damit auch eine Two-Factor Authentication zu realisieren. In den Ports gibts z.B. den Google Authenticator - müsste in /usr/ports/security/pam_google_authenticator zu finden sein - um nur mal ein bekanntes Beispiel zu nennen.

Gruß Bummibär
 
Zurück
Oben