Wie sicher ist SSH ForceCommand auf einem Sprunghost?

Ich habe das folgende Setup in meinem Netzwerk:

Internet <--> Bastion <--> Local Network

Ich habe mehrere Benutzer und jeder Benutzer ist einem bestimmten Computer zugeordnet. Oder mit anderen Worten: Jeder Benutzer darf nur Zugriff auf einen dieser Server haben. Beispiel: Benutzer1 -> Maschine1, Benutzer2 -> Maschine2 und so weiter.

Diese Benutzer stellen eine Verbindung von außerhalb meines Netzwerks her, und ich habe viele Optionen in Betracht gezogen, um ihre Verbindungen über meinen Bastion-Host an mein Netzwerk weiterzuleiten.

Schließlich entschied ich mich für Match Blocks und ForceCommand.

Meine / etc / ssh / sshd_config auf Bastion sieht also so aus:

Match User User1
        ForceCommand ssh User1@Machine1 $SSH_ORIGINAL_COMMAND

Benutzer1 stellt eine Verbindung zum Bastion-Host her, der automatisch eine Verbindung mit Maschine1 herstellt.

Soweit ich ForceCommand verstanden habe, hat Benutzer1 keinen wirklichen Zugriff auf den Bastion-Host, da alle seine Vorgänge zuerst vom Match-Block ausgeführt und daher an Machine1 umgeleitet werden. Aber ist das wirklich wahr? Reicht das schon aus, um ein sicheres Setup zu sein? Der Benutzer ist sowieso auf Maschine1 eingesperrt, so dass er dort nicht viele Möglichkeiten hat.

Die Art ProxyCommandund Weise, wie ich einen Bastion-Host verwende, ist die Verwendung und das -WFlag wie in diesem Beispiel:

ssh -o ProxyCommand='ssh -W %h:%p user@bastion' user@machine

Ich benutze diesen Ansatz aus Sicherheitsgründen. Die Kommunikation zwischen Client und Zielcomputer wird Ende-zu-Ende verschlüsselt und authentifiziert, was bedeutet, dass sie auch dann gesichert bleibt, wenn die Bastion gefährdet ist. Ein kompromittierter Bastion-Host würde nicht weniger Sicherheit bieten als die Verwendung von ssh End-to-End ohne Bastion.

Außerdem muss keine Agentenweiterleitung mehr verwendet werden. Der Client kann die schlüsselbasierte Authentifizierung verwenden, um zuerst auf die Bastion und dann erneut auf den Zielhost zuzugreifen, ohne dass einer von beiden über eine Agentenverbindung verfügt, mit der der auf dem Client vorhandene private Schlüssel missbraucht werden kann.

Es begrenzt auch den Code, von dem ich abhängig bin, vom Bastion-Host. Ich muss überhaupt keinen Befehl auf der Bastion ausführen. -Wimpliziert das Flag no command sowie eine einzelne Portweiterleitung. Diese Portweiterleitung ist alles, was der Bastion-Host zulassen muss.

In Anbetracht dieses Ansatzes würde ich empfehlen, den Bastion-Host so weit wie möglich zu sperren, sodass nur Befehle der obigen Struktur verwendet werden können.

Die ~/.ssh/authorized_keysDatei auf der Bastion könnte im Besitz von root sein (ebenso wie alle Verzeichnisse auf dem Pfad vom Stamm des Dateisystems zum Stammsystem). Dies verringert das Risiko, dass sie geändert werden kann, selbst wenn es jemandem gelingt, als nicht privilegierter Benutzer auf der Bastion einzudringen Bastion Host.

In authorized_keysden Rechten kann der Client unter Verwendung der Optionen begrenzt werden command, no-agent-forwarding, no-pty, no-user-rc, no-X11-forwarding, sowie mit permitopenbis zu beschränken Portweiterleitungen erlauben den Zugriff auf Port 22 auf dem Host , dass dieser Benutzer den Zugang zu erlaubt.

Im Prinzip wäre dieser Ansatz auch dann sicher, wenn mehrere Benutzer einen einzigen Benutzernamen in der Bastion verwenden. Sie erhalten jedoch etwas mehr Trennung, wenn Sie separate Benutzernamen für die Bastion verwenden.

Sie können ForceCommand leicht umgehen, da es beim Starten der Shell aktiviert wird. Dies bedeutet im Wesentlichen, dass Ihre Shell-RC-Datei zuerst verarbeitet wird und dann ForceCommand, wenn Sie zulassen, dass sie dort ankommt. Einfach exec shin Ihrer Shell-RC-Datei wird eine weitere Shell erzeugt und ForceCommand wartet, bis Sie diese Shell beenden.

Also unterm Strich; Wenn der Benutzer seine Shell-RC (z. B. .bashrc) über FTP, SFTP, SCP oder auf andere Weise bearbeiten kann, ist ForceCommand nicht wirklich etwas, auf das er sich verlassen kann.

Ich stelle mir vor, dass das die meiste Zeit in Ordnung ist, aber das Problem mit der Sicherheit sind die Dinge, über die noch niemand nachgedacht hat. Es gibt keine Garantien.

Wie zum Beispiel lange Zeit hatte niemand zu viel darüber nachgedacht, wie Funktionen aus Umgebungsvariablen in Bash erstellt werden könnten, aber kürzlich wurde den Leuten klar, dass dies untergraben werden kann, und eine der Auswirkungen davon war, dass ForceCommand umgangen werden konnte (at mindestens wie in der Datei "authorized_keys" implementiert), wenn die Benutzer-Shell "bash" war. Bash wurde behoben und hoffentlich ist Ihre Version auf dem neuesten Stand, aber solche Dinge passieren.

Ich bin nicht ganz sicher, ob das Definieren von ForceCommand tatsächlich mit dem Definieren dieser Befehle in den Datei "authorized_keys" identisch ist. Ich habe nicht so genau hingeschaut.

Machen Sie den .bashrcBesitz von , root:usergrpaber noch lesbar , der von sshd als Benutzer Protokollierung läuft in. Set perms / Besitzer auf $ HOME Erstellen disallowing neue Dateien durch den Benutzer. Auf diese Weise steuert root den Inhalt von .bashrcund lässt ihn tun, was er benötigt, aber der Benutzer selbst kann diese Einstellungen oder Berechtigungen für Dateien / Verzeichnisse nicht ändern, die es ihm indirekt ermöglichen würden, den Inhalt von zu ändern .bashrc.

Ich habe eine andere Idee. Für jeden Benutzer auf dem Bastion-Server können Sie seine Shell in / etc / passwd als Bash-Skript definieren, das einfach ssh user1 @ machine1, user2 @ machine2 usw. ausführt. Auf diese Weise stellen Sie sicher, dass sie keine gültigen haben Shell auf dem Server selbst und dass sie einfach eine Verbindung zu dem Computer herstellen, zu dem sie eine Verbindung herstellen sollen.