SSH-Tunnel bei gleichzeitiger maximaler Benutzerrestriktion

der_Kay

der_Kay

Doppel-As
Liebe Forenmitglieder,

Das Intranet/VPN unseres Betriebes ist durch eine "dicke", größtenteils extern gemanagte Firewall (SuSE/IPSec) nach außen geschützt (, auf die ich zwar root-Zugriff habe, auf der ich aber möglichst nichts drehen will). Nun will ich unseren Kunden (hauptsächlich Windowsbenutzer) übers Internet gesicherten Zugriff auf einen Webserver hinter der FW gewähren. Es ist geplant, jedem Kunden einen eigenen SSH-private-key zukommen zu lassen, mit dem er sich z. B. mittels PuTTY bequem zum Webserver durchtunneln und anschliessend mit seinem Webbrowser über eine URL ähnlich http://localhost:<Port > 1024>/Login sein Portal ansurfen kann. Das klappt auch ganz prima. :)

Dazu habe ich einen einzelnen Benutzer ("kunde") auf der FW angelegt. Jeder in .ssh/authorized_keys hinterlegte public key ist mit allen Restriktionen versehen, die sich innerhalb authorized_keys angeben lassen, insbesondere Festlegung des erlaubten Tunnels und Verweigerung eines Pseudo-Terminals ("no-pty"). Das funktioniert auch zufriedenstellend.

Trotzdem kann der Kunde immernoch viel zu viel auf der FW herumpfuschen, insbesondere Kommandos per SSH absetzen oder SFTP/SCP betrieben.

Wie erreiche ich eine maximale Restriktion der Handlungsmöglichkeiten des Benutzers "kunde"? Im Idealfall soll dieser überhaupt rein gar nichts außer dem SSH-Tunnel aufbauen können.

Wie sollte ich vorgehen? In welcher Gruppe sollte "kunde" Mitglied sein ("nogroup"(?))? Welche shell sollte "kunde" erhalten ("/bin/false"(?))? Genügt das, um alle Interaktionsmöglichkeiten zu unterbinden? Wie kann ich SFTP/SCP unterbinden, innerhalb von sshd_conf unter Subssystem oder ist es schon durch vorherige Maßnahmen deaktiviert? Was ist sonst noch zu beachten?

Danke im voraus fürs Lesen und Eure Hilfe!


Mit freundlichen Grüßen,

Kay
 
Zuletzt bearbeitet:
Ich wuerde einfach eine restricted Shell fuer die Kunden-Accounts nutzen, die z.B. per Menue nur bestimmte Befehle zulaesst (aehnlich wie die Free-Accounts bei sdf.lonestar.org) und (sofern es nicht gebraucht wird natuerlich) einfach das SFTP-Subsystem deaktivieren.
 
theton schrieb:
Ich wuerde einfach eine restricted Shell fuer die Kunden-Accounts nutzen, die z.B. per Menue nur bestimmte Befehle zulaesst (aehnlich wie die Free-Accounts bei sdf.lonestar.org)
Zum Vergrößern anklicken....
Das ist leider noch zu viel. Unsere Kunden sollen von der FW wirklich gar nichts mitbekommen, geschweige denn irgendetwas "dürfen"...
 
Ich verstehe den Plan nicht ganz. Agieren die meisten firewalls nicht auch gleichzeitig als gateway, so dass die Leute sich direkt von ihrem Rechner aus auf wo-auch-immer einloggen koennen?
 
rikola schrieb:
Ich verstehe den Plan nicht ganz. Agieren die meisten firewalls nicht auch gleichzeitig als gateway, so dass die Leute sich direkt von ihrem Rechner aus auf wo-auch-immer einloggen koennen?
Zum Vergrößern anklicken....

Nein, unsere nicht und das ist auch so gewollt. Die einzige Ausnahme soll der sichere Zugriff auf ein Portal hinter der FW sein, und zwar ausschliesslich auf einen bestimmten Rechner und nur über Port 80. Dazu verwenden wir individuell ausgestellte und restringierte Keys, die wir bei Bedarf ebenso schnell wieder deaktivieren können. Mit diesen keys tunneln sich die Leute über die FW zum Portalserver; dazu müssen sie aber notgedrungen auf der FW ein Benutzerkonto haben. Und dieses soll absolut null Handlungsmöglichkeit bieten.

Mit Login-Shell auf "/bin/false" und Gruppe "nogroup" scheint das schon ganz ok zu sein: Shell-Befehle als SSH-Optionen werden nicht ausgeführt und SFTP scheint auch nicht zu gehen. Die Frage ist nur, ob sich dennoch irgendwas "fummeln" lässt.
 
framp schrieb:
Warum ssh und nicht VPN?
Zum Vergrößern anklicken....
Kommt doch letzten Endes aufs gleiche raus. Das Argument für SSH ist, dass es im Handumdrehen installiert und leicht zu handhaben ist, problemlos ab Win95 und auf (alten) Macs läuft und sich die Kunden im Bedarfsfall selbst einen Zugang einrichten können.
 
rygar schrieb:
Hmmm...

Also ich würde egal was ich tue den Tunnel niemals auf der Firewall selbst enden lassen.

Habt ihr nicht die möglichkeit eine kleine Kiste um dann OpenVPN (http://openvpn.net/) oder OpenSwan (http://www.openswan.org/) zu installieren ?
Zum Vergrößern anklicken....
Unser Schwesterstandort experimentiert mit VPN und treibt teilweise einen recht hohen Aufwand, indem sie Kunden auf Kosten des Hauses mit der nötigen Hardware ausstattet.

Aber an unserem Standort wollen wir mittelfristig kein VPN, weil der Administrations- und Einarbeitungsaufwand zu hoch ist, es teilweise Mehrkosten für Hardware bedeuten würde und die Kunden teilweise "nicht kompatibel" sind. Wir sind mit der Tunnellösung soweit zufrieden; es geht nur um die Nutzerbeschränkung
 
Zuletzt bearbeitet:
Ok, ich wollte Dich nur gewarnt haben.

Sicherheit bedeutet immer Aufwand und Administration.
Du oder Ihr gefährdet aber die Firewall absichtlich indem Ihr eine Verbindung zu einem Programm AUF der Firewall zulasst.

Du solltest auch noch SCP testen, ich bin mir nicht sicher ob /bin/false da funktioniert.
 
Hallo,

kannst Du nicht in authorized_keys ein bestimmtes Kommando direkt vorgeben?
Also so etwa:

Code: 
command="/usr/bin/ssh PortalHost" no-pty ssh-dss <Langer Schlüssel>

Das Kommando sollte dann ausgeführt werden, ob der Kunde nun versucht, sich interaktiv einzuloggen (was ja mit /bin/false kaum gehen dürfte) oder ob er ein anderes Kommando auf seiner ssh-Befehlszeile eingibt.
Du müsstest das auch prüfen können, ob einer versucht, Dich zu verarschen, indem Du per Skript die Variable $SSH_ORIGINAL_COMMAND ausliest.
Ein Beispielskript dazu unter:

http://www.hackinglinuxexposed.com/articles/20030109.html

im mittleren Drittel der Seite.

Gruß
 
Anmelden, um zu antworten.

Neueste Beiträge

Neueste Themen

Zurück
Oben