ネットワーク管理者はどのようにして社内のリバースSSHをブロックしますか？
与えられたファイアウォール
- インバウンド：すべてブロックされています
- アウトバウンド：ポート80、443を許可
問題
- 同僚は引き続き、ポート80/443を使用してsshで自宅のデバイスにアクセスし、会社から自宅へ、さらに自宅から会社への逆sshトンネルを確立できます。
質問
- 人事部に会社のポリシーハンドブックにペナルティルールを追加するよう依頼するだけでなく、ネットワーク管理者が技術的な方法でリバースSSHをブロックすることはできますか？
SSHトラフィックは、HTTPおよびHTTPSとは異なります。 SSHトラフィックは、単にポート80または443を介してトンネルされます（つまり、ssh -p80...）は、SSHバージョンが含まれていて、HTTPバージョンやTLS ServerHelloが含まれていない最初の応答パケットを調べることで検出できます。しかし、ネットワーク内でHTTPプロキシの使用を強制するだけで、プレーンなSSHの使用を不可能にすることもできます。
これにより、CONNECTリクエストを使用してプロキシを介してトンネルを作成したり、プレーンHTTPを使用したり、WebSocketを使用したり、DNSと同様のものを使用して、完全なTLS接続内のSSH接続を非表示にしたりするなど、他のプロトコル内でSSHをトンネルする可能性が残ります。 SSHは通常のHTTPトラフィックとは異なる動作を示すため、いくつかの統計分析が役立つ場合がありますが、これを検出するのははるかに困難です。しかし、そのような分析は、今日の一般的なWebSocketトラフィックと簡単に混同される可能性があります。
最後にそれは競争であり、とにかくSSHトンネルに焦点を合わせる理由を自問する必要があります。これらのトンネルは、内部と外部の間でデータを転送するためのツールにすぎません。このようなデータ転送は、通常のHTTP/HTTPSを使用して行うことも、USBスティックなどを使用して行うこともできます。したがって、単一のベクトルに焦点を合わせると、データ漏洩を防止したり、攻撃者がネットワークに侵入したりするのを防ぐことができます。また、ポリシーがある場合：許可されていないもののブラックリストを持つよりも、許可されているもののホワイトリストを持つほうが安全です。
これを少し難しくする方法は、有効なHTTP接続でない限り、80/443を介して直接接続できないようにHTTPプロキシを配置することですが、次のようなものを使用してもバイパスできます- プロキシトンネル 。これをバイパスする別の方法は、Webコンソールを実行して、通常80/443を介してアクセスすることです。
彼らのためにそれをより難しくすることはおそらく彼らを止めないでしょう、しかし結局それが許されないというそれがあなたの方針にありそしてあなたがネットワークを監視するならば、警告はこのルールを破る人々に警告を与えることができます。
ここでは、HTTPプロキシのCONNECTメソッドをブロックすることにより、443ポート経由のSSHをブロックしています。
2番目の解決策は、偽の「ログイン」ページを使用することです。プロキシを使用すると、パスワードを要求できます。これは通常、ブラウザによって要求されるか、プロキシを使用できるアプリの認証フィールドに入力されます。ただし、ログイン/パスワードを要求する偽のログインページを使用して、プロキシサーバーでこれをバイパスできます。
このページを表示するアプリケーションだけがプロキシを通過できるため、この方法は恐ろしいです。たとえば、PuTTYはこのページを表示できないため、プロキシに対して自身を認証できません。
最初の質問は、ユーザー/管理者がリバースSSHトンネルを使用している理由です。私は、リモート管理用のVPNの実装が非常に不十分で、ツールが不十分なCitrixサーバーへの接続しか許可していない会社で働いていたため、SSHリモートトンネルを使用してサーバーをリモートで適切に管理しました。要塞ホストからのみ許可されるトンネル。ホストは、無効なパスワード認証、無効なrootログイン、および有効な鍵ベースの認証でセットアップされました。リバーストンネルは、DMZへのssh接続のバックスルーを許可し、要塞ホストからユーザーは他の要塞ホストの一部にしか到達できませんでした。ウサギの穴を下りる代わりに、MITMインターセプトプロキシ、IDS、管理者のホームIP、およびDPIファイアウォールへのアクセスをブロックするSSHトンネリングをブロックします。ユーザー/管理者に優れたソリューションを提供し、要件を満たし、HRポリシーを実装して実施します。
Suricata IDPSを介したLuajitは、プロキシSubversion、リバースシェルなどを防ぐために、SSHおよびSSL/TLSトンネルを制御するためのいくつかの高度なメカニズムを提供します。
Suricataとluajitを使用して自己署名証明書を見つけるために、この完全ではありませんが、かなり詳細なガイドを確認してください https://www.stamus-networks.com/2015/07/24/finding-self -signed-tls-certificates-suricata-and-luajit-scripting /
Sshをセキュリティで保護する方法を尋ねると、ワームの缶が開きます。これらはワームです。
私がこれを言うと怒る人もいますが、それはかなり簡単なことであり、かなり前に達成でき、「この方法で構築されるべきでした」。
これは可能であり、反対する人のほとんどは隣人であり、私たちが現在世界で直面している脆弱性の原因である可能性があります...
ハンドオフ前にトラフィックの可視性を必要とするプロキシを介してすべてのトラフィックを強制するという上記の提案は強力なスタートであり、ネットワークおよび物理的なセキュリティポリシーと方法論の上に展開され、それらと整合し、時にはセキュリティガードのラップトップにまで及ぶ概念である必要があります/ mobileホール勤務。
クライアントワークステーションを制御します。適切に配線してください。ワイヤレスから分離します。クライアントの「ダム端末」で常に統計を監視します。 USBがオフになりました。電力を必要とする個人に電力ハブを提供します。 IT管理手順を含む承認プロセスを経て、すべての輸出品を残す。
これらのワークステーション上のソフトウェアは、最小限の機能を備えたシンプルなプラットフォームであり、Webインターフェースまたはクライアントアプリケーションを提供して、役割にのみ適したアクセス可能なリソースに安全に導くことができます。
完全に異なるトランク上でない限り、ワイヤレスは避けてください。
「ソーシャルメディアプラットフォーム」などのサービスは、実際のアラートよりも誤ったアラートである必要があるため、「綿密に調査」する必要があります。これにより、企業は、ソーシャルメディアネットワークに出入りする情報を「活用」できるというメリットを得られます。
これらはすべて、手がかかりすぎる低レベルのサポートエージェントからのものです。ただし、これらの方法論が展開されたネットワークを使用している場合、従業員の出入りを知ることは重要であり、プライバシーの侵害ではなく、資産であることを証明します。安全なデータのある場所で、誰もが隠さなければならない唯一のものは、誰がどのようにそれを処理するかを含め、会社とそのデータです。
この時代において、情報を保証する理由がある場合は、安全な情報を提供することを保証する人々に保証が必要です。
従業員が会社のデータを最近ほど自由に移動する必要はありません。
通常のペンと紙、「キラーUSBドライブ」などに加えて、物理的なセキュリティプロトコルを適用して写真とビデオの側面からデータを抽出する方法を制限することはもちろん、これを最小限に抑えることができます。