AWSでは、ssh proxy + sshdによるアクセス制御

Question

AWSでは、ユーザ（システム管理者）は、ローカルのfirwallの制限なしにSSHトンネリングを使用して内部ゾーンDBサーバにアクセスできます。 ご存じのように、内部ノードにアクセスするには、最初にパブリックゾーンゲートウェイサーバーを経由する必要があります。 ゲートウェイは実際には通路であるため、ゲートウェイサーバー上のトンネルされたユーザーからのトラフィックを制御したいと考えています。 たとえば、すべてのクライアントの現在接続されているIPアドレスを取得するには、ユーザーがアクセスした内部パス（例：DBサーバーIP）をidendifyするように、私は許可されていないユーザーの接続を制御します。

私の夢には、以下の考えが本当に理想的だと思います。 1）sshdポートを22以外に変更します。sshdデーモンを再起動します。 2）sshdの前にsshプロキシ（nginx、haproxyなど）を探し、プロキシにクライアントからすべてのsshトラフィックを取得させます。 3）sshプロキシがsshdにトラフィックをルーティングします 4）次に、sshプロキシログを分析してすべてのユーザのアクティビティを表示できます。それでおしまい。

夢はありますか？

Answer 1

賢いですが、致命的な欠陥があります。新しい情報は得られません。

なぜですか？ SSHの最初のS：「安全」

「sshプロキシ」は、トンネルがネゴシエートされているSSH接続の内部で何が起こっているかをあなたに伝えることができません。接続はもちろん暗号化されているので、SSHの重要な点はそれが盗聴されないことです。 sshプロキシが同じマシン上にあるという事実は違いはありません。それが盗聴される可能性がある場合、それは安全ではありません。

すべてのSSHプロキシは、クライアントコンピュータからインバウンド接続が行われたことを伝えることができ、syslogはすでにそれを通知しています。

本当の意味では、それはまったく「sshプロキシ」ではないでしょう。それはインバウンド接続上の純粋なTCP接続プロキシに過ぎません。

この方法では、新しい情報を知ることができません。

あなたのsshデーモン（おそらくopenssh）が、接続しているユーザーによって確立されたトンネル接続を記録する必要があるように思えます。

This blog post（表示するためには無効なSSL証明書をバイパスする必要があります）は、at Server Faultと記載されています。あなたが望む情報をログに記録するためのopensshソースコードを単純に変更したようです。トンネルを上に、そしてどこに。

またはenable some debug-level logging on sshd。

私にとって、余分なTCPプロキシは余分なものだと思われます。実際のトンネル（sshd）を実行して、何をやっているのかを記録するプロセスが必要です。