セキュリティ(暗号化)トラフィック

SSL インターネットトラフィックを不正アクセスから保護する技術の開発と並行して、保護されたトラフィックを傍受する技術も開発されています。 暗号化されていないユーザートラフィックの傍受と調査は、平均的なユーザーでも長い間簡単でした。 ほとんどの人がスニッファーという言葉を知っています。 理論的には、従来の方法ではセキュアなSSL / TSL接続を傍受することは不可能です。 しかし、そうですか?



実際、そうではありません。 はい、暗号化されたトラフィックは理論的に解読することは不可能ですが、非常に大きなニーズと要望がありますが、そのようなトラフィックは鍵を選択することで解読できます。 ただし、これには、おそらく政府または軍事レベルでのみ、ハッキングの関連性が残るようなリソースコストが必要です。



安全な接続で作業する場合(最も単純な例はHTTPS )、ネットワーク上の相互作用するポイント間のすべてのトラフィックは送信側で暗号化され、受信側で復号化されます。 双方向の暗号化されたトラフィック。 暗号化および復号化するには、キーのペアが必要です(非対称暗号化)。 公開鍵は暗号化に使用され、データ受信者に送信されます。秘密鍵は復号化に使用され、送信者に残ります。 したがって、SSL接続が確立されているノードは公開鍵を交換します。 さらに、生産性を高めるために、単一のキーが生成されます。このキーは既に暗号化された形式で送信され、両側の暗号化と復号化の両方に使用されます(対称暗号化)。



彼らはどうやってそれをしますか? 通常-保護されたトラフィックがさらに進む同じチャネル上。 さらに、キー交換はオープンモードで行われます。 HTTPSの場合、サーバーキーは証明書に関連付けられており、ユーザーが表示して受け入れるように求められます。 また、この証明書は、パス上にオープン証明書(プロキシ、ルーター)がある中間サーバーをインターセプトできます。



すべてのユーザートラフィックをさらに「読み取る」ために、中間サーバーは証明書を独自の証明書に置き換えます。 つまり 彼は単に証明書を使用してクライアントに接続すると同時に、リモートサーバーに接続します。 クライアントは悪意のあるサーバーから「左」の証明書を受け取り、ブラウザはユーザーに危険について通知します(このような証明書は常に署名されているとは限りません)。 ユーザーは、証明書を受け入れてサイトで作業するか、受け入れることを拒否するかを選択できますが、それでもサイトでは機能しません。 ユーザーは通常、証明書の内容を無視し、転送された証明書を自動的に受け入れる場合があります。



ユーザーが偽の証明書を受け入れた場合、トラフィックは次のようになります。



クライアント<= SSL接続=>盗聴サーバー<= SSL接続=>宛先サーバー



つまり 中間サーバーは、すべての「保護された」トラフィックを平文で受信します。 また、各HTTPSセッションの開始時に証明書の転送が行われることに注意してください。



セキュアSSHの場合、サーバーに初めて接続するとき、サーバーキーはクライアントに保存され、クライアントキーはサーバーに保存されます。 これらのキーは、最初の接続中に、クライアントサーバーによってデータ間で一度だけ送信されます。 この場合、SSHトラフィックをインターセプトしようとすると、クライアントとサーバーの両方がキーの不一致により接続を拒否します。 キーはクライアントとサーバー間で迂回的に(安全なチャネルまたは外部メディア経由で)転送できるため、この接続方法は比較的安全です。 ブロックすることしかできず、ユーザーはオープンに作業する必要があります。



いわゆる「エンタープライズ情報セキュリティソリューション」が長い間販売されており、オフィスプロキシサーバーを通過するすべてのトラフィックを傍受して「読み取る」ことに注意してください。 プログラムは、ブラウザ、電子メールプログラム、ftpクライアント、オフィスの従業員のメッセンジャーからのデータストリーム内の特定のフレーズまたは特定のタイプの情報の存在を探します。 さらに、これらのプログラムは、サーバーとのさまざまな種類の情報相互作用を正しく区別して処理できます。 含む、彼らは証明書を代用することによってSSLトラフィックをチェックして、保護しました。 私は、これらのシステムのいずれかの開発にほぼ直接出会いました。



しかし、完全な監視から救いの方法があります。 確立されたSSH接続を介して、SSHサーバーからエンドポイントにすでに送信される必要なトラフィックをオープン形式で送信できます。 この方法はSSHトンネリングと呼ばれます。 この方法では、安全でないチャネルを介したトラフィックフローを保護できますが、このアプローチは、SSHデーモンが起動およびトンネリングされた信頼できるサーバーがある場合にのみ意味があります。 これを整理するのは非常に簡単です。 SSHクライアントはサーバーに接続し、ローカルマシンの任意のポートでリッスンするように構成されています。 このクライアントは、SOCKS5プロキシサービスを提供します。 その使用は、任意のブラウザ、電子メールプログラム、IMなどで設定できます。 SSHトンネルを介して、パケットはサーバーに送信され、そこからターゲットサーバーに送信されます。 スキームは次のとおりです。



[localhost:client <=> proxy] <== SSH connection ==> server <=>ターゲットサーバー



トラフィックを保護する別の方法は、 VPNチャネルです。 使用中は、SSHトンネリングよりも簡単で便利ですが、最初のインストールおよび構成ではより困難です。 この方法の主な利便性は、プログラムがプロキシを登録する必要がないことです。 また、一部のソフトウェアはプロキシをまったくサポートしていないため、VPNのみがサポートします。



実際には、2つのオプションがあります。 1つ目は、VPNアカウントの購入です。VPNアカウントは、これらの目的のために特別に販売されています(安全でないチャネルを介したトラフィック暗号化)。 この場合、通常アカウントは販売され、PPTP(Windowsなどで実装される通常のVPN)またはL2TPを介して接続する必要があります。



2番目のオプションは、Linuxディストリビューションを搭載したVDSサーバー(仮想専用サーバー)を購入し、その上にVPNサーバーを作成することです。 VDSは、ロシア語またはアメリカ語(海外のpingを忘れないでください)、安い(5ドルから)、弱いまたは高価で、より強力です。 彼らはVDSにOpenVPNサーバーをインストールし、コンピューター上にOpenVPNクライアントが立ち上がります。 Windowsの場合、 グーッシュバージョンのクライアントもあります



OpenVPNオプションを使用する場合、たとえば、サーバー(Debian)を上げるためのこの簡単なステップバイステップの手順です。 クライアントのインストールは、特にWindowsではさらに簡単です。 注目に値するニュアンスは1つだけです。 作成されたVPN接続ですべてのトラフィックを許可する必要がある場合は、VPNゲートウェイにデフォルトゲートウェイを登録する必要があり(クライアントの構成のredirect-gatewayパラメーター)、トラフィックの一部のみ(特定のホストへ)であれば、これらのホストへの通常の静的ルートを登録できます( IPで、たとえば、route add -p 81.25.32.25 10.7.0.1)。



OpenVPNを接続するために、鍵交換は手動モードで行われます。 サーバーからクライアントにそれらを転送することは絶対に安全です。



したがって、SSHおよびVPN接続は、安全でないチャネルを移動する際のトラフィックのセキュリティをほぼ完全に保証できます。 この場合に発生する可能性がある唯一の問題は、企業のファイアウォールでのSSLトラフィックの禁止です。 少なくとも1つのポート(通常はデフォルトの443)でSSLトラフィックが許可されている場合、VDS上の対応するデーモンをこのポートに構成することにより、SSHトンネルとVPN接続の両方を上げることができます。



All Articles