In AWS, Zugriffssteuerung durch SSH-Proxy + sshd

Question

In AWS können unsere Benutzer (Systemadministratoren) auf interne Zonen-DB-Server zugreifen, indem SSH-Tunneling ohne lokale Firewall-Einschränkungen verwendet. Wie Sie wissen, muss ein Benutzer zuerst auf den öffentlichen Knoten zugreifen, um auf den internen Knoten zuzugreifen. Da das Gateway tatsächlich eine Passage ist, möchte ich den Verkehr von getunnelten Benutzern auf dem Gateway-Server kontrollieren. Um beispielsweise die aktuell verbundenen IP-Adressen aller Clients zu erhalten, um den internen Pfad (z. B. DB-Server-IP) zu identifizieren, auf den der Benutzer zugreift, möchte ich die Verbindung von nicht autorisierten Benutzern steuern.

Um meine Träume wahr werden, denke ich unten Idee ist wirklich ideal. 1) Ändern Sie den sshd-Port auf etwas anderes als 22. Starten Sie den sshd-Daemon neu. 2) Suchen Sie ssh-Proxy (nginx, haproxy oder sonst) vor sshd und lassen Sie den Proxy den gesamten ssh-Datenverkehr von den Clients erhalten. 3) Der SSH-Proxy route den Verkehr zu sshd 4) Dann kann ich alle Aktivitäten des Benutzers durch Analyse ssh Proxy-Protokoll zu analysieren. Das ist es.

Ist es möglich, Traum?

Answer 1

Clever, aber mit einem kritischen Fehler: Sie werden keine neuen Informationen erhalten.

Warum? Das erste S in SSH: "sicher".

Der "ssh proxy", den Sie sich vorstellen, könnte Ihnen nichts darüber sagen, was in den SSH-Verbindungen passiert, wo die Tunnel ausgehandelt werden. Die Verbindungen sind natürlich verschlüsselt, und ein wichtiger Punkt von SSH ist, dass es nicht beschnüffelt werden kann. Die Tatsache, dass sich der ssh-Proxy auf demselben Computer befindet, macht keinen Unterschied. Wenn es geschnüffelt werden könnte, wäre es nicht sicher.

Alle Ihre SSH-Proxy könnte Ihnen sagen, ist, dass eine eingehende Verbindung von einem Client-Computer gemacht wurde, und syslog sagt Ihnen bereits, dass.

In einem echten Sinne wäre es überhaupt kein "ssh proxy" - es wäre nur ein naive TCP-Verbindungs-Proxy auf der eingehenden Verbindung.

So könnten Sie mit diesem Ansatz keine neuen Informationen lernen.

Es klingt wie, was Sie für Ihren ssh-Dämon, vermutlich openssh, benötigen, um die Tunnelverbindungen zu protokollieren, die von den verbindenden Benutzern hergestellt werden.

This blog post (die Sie ironischerweise benötigen ein ungültiges SSL-Zertifikat, um zu umgehen zu sehen) wurde at Server Fault erwähnt und zeigt, was eine einfache Änderung an den OpenSSH-Quellcode zu sein scheint, die Informationen, die Sie protokollieren mögen: die Set einen Tunnel hinauf und dorthin.

Oder enable some debug-level logging on sshd.

Also, es scheint, dass der zusätzliche TCP-Proxy überflüssig ist - Sie brauchen nur den Prozess tun die tatsächlichen tunnels (sshd) zu protokollieren, was es tut oder angefordert wird zu tun.