MITコース「コンピューターシステムのセキュリティ」。 講義12：ネットワークセキュリティ、パート2

マサチューセッツ工科大学。 講義コース6.858。 「コンピューターシステムのセキュリティ。」 ニコライ・ゼルドヴィッチ、ジェームズ・ミケンズ。 2014年

コンピューターシステムセキュリティは、安全なコンピューターシステムの開発と実装に関するコースです。 講義では、脅威モデル、セキュリティを危険にさらす攻撃、および最近の科学的研究に基づいたセキュリティ技術を扱います。 トピックには、オペレーティングシステム（OS）セキュリティ、機能、情報フロー管理、言語セキュリティ、ネットワークプロトコル、ハードウェアセキュリティ、およびWebアプリケーションセキュリティが含まれます。



講義1：「はじめに：脅威モデル」 パート1 / パート2 / パート3

講義2：「ハッカー攻撃の制御」 パート1 / パート2 / パート3

講義3：「バッファオーバーフロー：エクスプロイトと保護」 パート1 / パート2 / パート3

講義4：「特権の共有」 パート1 / パート2 / パート3

講義5：「セキュリティシステムはどこから来たのか？」 パート1 / パート2

講義6：「機会」 パート1 / パート2 / パート3

講義7：「ネイティブクライアントサンドボックス」 パート1 / パート2 / パート3

講義8：「ネットワークセキュリティモデル」 パート1 / パート2 / パート3

講義9：「Webアプリケーションのセキュリティ」 パート1 / パート2 / パート3

講義10：「シンボリック実行」 パート1 / パート2 / パート3

講義11：「Ur / Webプログラミング言語」 パート1 / パート2 / パート3

講義12：ネットワークセキュリティパート1 / パート2 / パート3



学生：おそらくピアアドレスに32ビットを使用でき、それぞれに多くのポートがあるため、まだ利益相反の問題があります。 おそらく、取得したこれらすべての接続のシーケンス番号の競合がありますか？



教授：これらのシーケンス番号は、送信元/宛先のペアのIPアドレスとポート番号に固有であることがわかりました。 したがって、これらが異なるポートである場合、それらは互いに干渉しません。 具体的には、ポートのシリアル番号は小さくなります。







学生：シリアル番号がグローバルである場合、攻撃者は他のクライアント間の接続に入ることができますか？



教授：はい、これは良い点です。 実際、サーバーがシリアル番号を（たとえば、接続ごとに64kずつ）増やすと、サーバーに接続し、さらに5人がサーバーに接続します。ここで、攻撃を編成できます。 だから、ある程度、あなたは正しい、それは少し面倒です。 一方、S-> Aの最後の行からのパッケージが、C-> Sの最初の行のそのパッケージの直前に配信されるように、おそらく作成できます。 パケットを次々に送信する場合、パケットが1つずつサーバーに到着する可能性が高くなります。



サーバーはS-> Aを受信し、このシーケンス番号（SN）で応答します。 2行目の（SN）とは異なりますが、シリアル番号が直後に続きます。 そして、シーケンスの3番目のパケットに含まれるシーケンス番号（SN）を正確に知ることができます。

したがって、これはサーバーに接続するための非常に信頼できる方法ではなく、仮定に基づいていると思います。 ただし、パッケージを正しい方法で慎重に配置すると、シーケンスを簡単に推測できます。 または、数回試してみても幸運です。



学生：偶然に数字が生成されたとしても、40億の数字のうちの1つを推測する必要があります。 これは多すぎませんよね？ 1年以内にこのネットワークに侵入できるようになると思います。



教授：はい、あなたは絶対に正しいです。 セキュリティの観点からTCPに頼りすぎないでください。 あなたが正しいので、これはたった40億の推測です。 また、適度に高速な接続があれば、日中に大量のパケットを送信できます。



32ビットしかないため、ここでTCPの信頼性について興味深い議論があります。 どうにかして彼を確保することはできません。 しかし、このプロトコルに十分に依存している多くのアプリケーションはセキュリティをまったく考慮していないと思います。これは本当に問題になります。



しかし、あなたは絶対に正しいです。 実際には、32ビットより長い暗号化キーを使用しているため、データを偽造したことのない深刻な保証を得るために、何らかの暗号化を使用する必要があります。 ほとんどの場合、これは依然としてTCP接続の改ざんを防ぐのに効果的です。



では、人々が任意のアドレスからTCP接続を偽造できるのがなぜ悪いのか見てみましょう。



これが悪い理由の1つは、サーバーが要求の送信元アドレスをチェックするときに、IPアドレスに基づいて許可に影響を与える可能性があることです。 サーバーがIPアドレスに基づいて接続を許可するか拒否するかを決定した場合、これは任意のソースアドレスからの接続を偽造した攻撃者にとって問題になる可能性があります。



そのため、これが問題であった1つの例は、今日ではこの問題は基本的に解決されており、rloginなどのrコマンドファミリの使用です。 以前は、たとえばathena.dialup.mit.eduでコンピューターのrloginのようなものを実行できることがありました。 接続がMITホストからの場合、「はい、私はこのコンピューターのAliceのユーザーです。別のコンピューターにAliceのユーザーとしてログインさせてください」と言うと、このrloginコマンドは成功します。 また、mit.eduネットワーク上のすべてのコンピューターがそのようなステートメントを作成するのに信頼できるため、この操作は許可されます。



ダイヤルアップにはこの問題は一度もなかったと言わざるを得ません。 この化合物は最初からケルベロスを使用していました。 しかし、他のシステムにはもちろんこのような問題がありました。 これは、サーバーを呼び出しているクライアントが信頼できるかどうかをシステムがチェックするときに、接続認証メカニズムでIPアドレスを使用する例です。 したがって、以前は問題であったものはもはや問題ではありません。 しかし、IPに依存することは依然として悪い計画のように思えます。







現在、rloginは使用されていません。最近では、優れたネットワーク層プロトコルであるセキュアSSHシェルに置き換えられています。 一方、IPアドレスベースの承認に依存するプロトコルの例は他にもたくさんあります。 それらの1つはSMTPです。 メールを送信するときは、SMTPを使用して、メッセージを送信するためにメールサーバーと通信します。 スパムを防ぐために、多くのSMTPサーバーは特定のソースIPアドレスからの着信メッセージのみを受け入れます。 たとえば、Comcastメールサーバーは、Comcast IPアドレスからのメールのみを受け入れます。 同じことがMITメールサーバーにも当てはまります-MIT IPアドレスからのメールのみを受け入れます。 しかし、IP認証を使用して、正常に機能しないサーバーが少なくとも1つありました。



ここのすべてがそれほど悪くはありません。 最悪の場合、メールサーバー経由でスパムを送信します。 このため、おそらくrloginを使用しているのに、任意のアカウントにログインできるものはIPベースの認証の使用を停止しています。



では、なぜそのような認証メカニズムが悪い計画なのでしょうか？ 前提として、一部のサーバーがrloginを使用したとします。 攻撃するにはどうしますか？ 何が起こる可能性がありますか？



学生：攻撃者は単にコンピューターに侵入し、ユーザー名でネットワークに入ろうとしているユーザーを偽造し、ネットワークにアクセスすることができます。



教授：はい、基本的に攻撃者はコンピューターを捕獲します。 「このユーザーとしてログインし、このコマンドをUnixシェルで実行する」と言うrloginコマンドの有効なセットのように見えるデータを合成します。



このデータデータ（SNc +1）を合成し、正当なユーザーがrloginクライアントと対話したかのように攻撃全体をマウントし、このデータを送信してから続行できます。







それが、TCPシーケンス番号を推測したくない理由の1つです。 別の問題は、これらのリセット攻撃リセット攻撃です。 SYNパケットを送信できるのと同じ方法で、誰かのシリアル番号がわかっていれば、同じ方法でリセットパケットを送信できます。



攻撃者が確立した偽の接続リセットパケットを送信する正当なクライアントについて簡単に言及しました。 攻撃者は、自分のシーケンス番号がその接続にあることを何らかの方法で知っている場合、既存の接続の破棄パケットを送信しようとする可能性があります。 実際、この問題の大きさは明らかではありません。



あるレベルでは、どんな場合でもいつでもすべてのTCP接続が切断される可能性がある、つまり、ネットワークが信頼できるとは思えない、と想定する必要があります。 したがって、おそらく切断を予期する必要があります。



ルータが互いに「通信」する場合、この仮定は特に重要です。 いくつかのルーティングプロトコルを使用して互いに通信する多くのルーターがある場合、それらの間にいくつかの物理的な接続があります。 しかし、これらの物理接続に加えて、TCP上で動作するネットワークプロトコルを介して通信します。 実際、ルーターがルーティング情報の交換に使用するこれらの物理接続のそれぞれで、TCPセッションが開始されます。 後で説明するBGPプロトコルを使用します。



このBGPプロトコルは、TCP接続が生きている場合、物理接続が生きているという事実を使用します。 したがって、TCP接続が切断された場合、ルーターは接続が切断されたと判断し、すべてのルーティングテーブルの再カウントを開始します。







したがって、攻撃者が何らかのDoSサービス拒否攻撃をここで手配したい場合、これらのルーターのシリアル番号を推測し、これらのセッションをリセットすることができます。 2つのルーター間のTCPセッションがオフになっている場合、両方のルーターはこの接続が無効であると見なし、すべてのルーティングテーブルを再カウントする必要があります。これにより、ルートが変更されます。 その後、攻撃者は別の接続などをリセットできます。



したがって、これは少々警戒すべき攻撃であり、少なくとも直接ではなく、他の誰かの秘密などに違反するためではなく、システムの他のユーザーに多くのアクセス問題を引き起こすためです。



学生：攻撃者で、特定のユーザーに対して標的型攻撃を仕掛けたい場合、IPアドレスに代わってサーバーに接続するリクエストを送信し続け、サーバーへの接続を強制的にリセットできますか？



教授： Gmailを使用していて、Gmailから情報を受け取らないようにしたい場合は、Gmailサーバーからのふりをして自分のマシンにパケットを送信してください。 この場合、正しい送信元ポート番号と宛先ポート番号を推測する必要があります。



HTTPSを使用しているため、宛先ポート番号はおそらく443です。 ただし、送信元ポート番号はランダムな16ビットのものになります。 さらに、シリアル番号は異なります。 したがって、TCPウィンドウにある数十キロバイトのシーケンス番号を推測しないと、成功しません。



したがって、かなりの量を推測する必要があります。 ここにはOracleタイプのアクセスはありません。 この男のシリアル番号をサーバーに尋ねることはできません。 これが、これも機能しない理由です。



そのため、特にBGPルーターの場合、このRSTベースのものを含め、これらの問題の多くが修正されています。 実際には2つの面白い修正がありました。 1つのことは、既存のものをどのように活用するか、または特定の問題を修正するためにそれらを使用する方法を実際に示しています。 これらのルーターが相互に通信するだけで、ネットワーク内の他のユーザーとは通信しないというプロパティを使用します。 その結果、接続の反対側にあるルーターからパケットが到着しない場合、このパケットは破棄されます。



これらのプロトコルの開発者の実装の成功は、「ライフタイム」またはTTLと呼ばれるパッケージのすばらしい領域です。 これは、パケットが無限ループに陥らないようにするために各ルーターによって減分される8ビットのフィールドです。 最大TTL値は255で、さらに減少します。



だから私はこれらのスマートプロトコルを何をしていますか？ 255に等しくないTTL値を持つパケットはすべて破棄されます。なぜなら、パケットの値が255である場合、この接続の反対側のルーターからしか送信できないからです。 また、攻撃者が既存のBGP接続に他のパケットを挿入しようとすると、TTL値は255未満になります。この値は、このルーターを含むルーティングパスに沿って配置された他のルーターによって削減されるためです。 したがって、このパッケージは単に受信者によって拒否されます。



これは、この非常に具体的な問題を解決する下位互換性のある手法の巧妙な組み合わせの一例です。







学生：右下のルーターはTTLが255の何かを送信しませんか？



教授：これは物理的なルーターです。 そして、彼はこれらが別個の接続であることを知っているので、TTLとパケットの発信元の両方を調べます。 そのため、パケットが左上のルーターから送信された場合、そのパケットと右上のルーターとの間のTCP接続では受け入れられません。



ほとんどの場合、これらのルーターは直近の近隣ノードを信頼し、このプロセスは自動パンマルチパスルーティングメカニズムを使用して制御できます。



BGPの他の修正は、MD5認証ヘッダーを含む何らかの形式の認証ヘッダーを実装することです。 しかし実際には、開発者はこの特定のアプリケーションに焦点を合わせており、リセット攻撃は特に重要です。



この問題は今日も続いています。 長期接続があり、それを中断したい場合は、40億件ではなく、おそらく数十万件のRSTパケットを大量に送信する必要があります。 サーバーは実際には、リセットのために受け入れるシーケンス番号に対して多少脆弱です。



特定のウィンドウ内の任意のパッケージにすることができます。 この場合、攻撃者は多くの努力をせずにこの接続を切断する可能性があります。 これはまだ問題であり、本当に良い解決策はありません。



そして、シーケンス番号の予測可能性のために起こりうる最後の悪いことは、既存の接続にデータを注入することです。 rloginに似た仮想プロトコルがあり、実際にはIPベースの認証を実行しないため、ログインするにはパスワードを入力する必要があるとします。



問題は、パスワードを入力するとすぐに、おそらくTCP接続が確立され、任意のデータを受け入れることができるということです。 そのため、攻撃者は、パスワードを入力してコンピュータにログオンするまで待つ必要があります。



攻撃者はパスワードが何であるかを知りませんが、TCP接続を確立するとすぐに、シリアル番号を推測し、既存の接続にデータを入力しようとします。 したがって、シリアル番号を正しく推測できれば、それは私ではないふりをすることができますが、パスワードで正しく認証された後にコマンドを入力しました。







これらはすべて、セキュリティの観点からこれらの32ビットシーケンス番号に本当に依存したくない理由を示しています。 しかし、最新のTCPスタックが実際にこの問題を軽減するために何をするかを見てみましょう。 次の2つの講義で取り上げる問題への1つのアプローチは、アプリケーションレベルである程度のセキュリティを実装することです。 このレベルでは、暗号化を使用して、TCPの多くの関与なしにメッセージを認証、暗号化、署名、および検証します。



既存のアプリケーションの中には、セキュリティの問題を解決するのに役立つもの、または少なくとも攻撃者がこれらの問題を悪用するのをより困難にするものがあります。 今日、人々はこれを今日、例えばLinuxとWindowsで実行し、各ソース/宛先ペアの異なる初期シーケンス番号をサポートしています。



したがって、ほとんどのTCP SYN実装は、以前と同じ方法でこの初期ISNシーケンス番号を計算します。 これは古いISNスタイルです、そう言いましょう。 特定の接続のシリアル番号を実際に生成するために、これに古いスタイルのISNにランダムな32ビットオフセットを追加します。 つまり、ハッシュ関数やSHA-1などの関数を追加します。







この機能には、送信元IPアドレス、送信元ポート番号、宛先IPアドレス、宛先ポート番号、およびサーバーのみが知っている秘密キーが含まれます。 したがって、この古いスタイルのシーケンス番号割り当てアルゴリズムのすべての優れたプロパティを保持しながら、特定の接続がソース/宛先ペアのIPアドレスとポートを決定する良い機会を作成します。



ただし、ソース/宛先の異なるセットからの接続がある場合、別の接続セットのシリアル番号の正確な値を見つけることができるものはありません。 実際、この値を計算するにはこのキーを推測する必要があります。



サーバーOSカーネルがこのキーをメモリのどこかに保存し、誰にも発行しないことを願っています。 これは、今日のほとんどのTCPスタックが一般的な32ビットシーケンス番号の領域でこの特定の問題を解決する方法です。 これはあまり大きくありませんが、機能します。



学生：これをもう一度繰り返してもらえますか？ キーの一意性について...



教授：マシンが起動するとき、またはマシンが起動するときに、ランダムキーを生成します。 リロードするたびに、新しいキーが生成されます。 これは、特定の送信元/宛先ペアのシリアル番号が同じオフセット周波数で変更されるたびに意味します。 したがって、特定の送信元/宛先のペアに対して、関数パラメーターは固定されています。 そのため、新しい化合物の初期シーケンス番号に従って番号が変化し、特定のアルゴリズムに従って変化すると、シーケンスに従います。 したがって、以前の接続から新しい接続への古いパケットの挿入に対する保護と、パケットの再割り当てに対する保護が提供されます。



古いサンプルのこのシリアル番号が必要なのは、これらの重複パケットの問題を防ぐためのアルゴリズムの選択だけです。 以前、1つの接続A：A-> S：SYN（...）のシリアル番号を取得したら、その後、ACK（SN）接続のシリアル番号について結論を出すことができると考えました。







, 32- , F. , , .



: ?



: , . F, , F , , , .



: , …



: , F - -, . -, , . , , , , . , F .



, TCP, . , , - .



, . , TCP , DNS, . , DNS UDP – . UDP — , , . UDP . , , , . , , . DNS-. DNS?







, DNS- C: C53 -> S53 mit.edu, 53.



S: S53 -> C53 IP-, – .



, , , , . , mit.edu, .



, DNS- . IP-, , . IP- mit.edu IP-. , , , , . , .







, , . IP-. , , DNS- . , , IP- mit.edu.



: , , ?



: , . , , . DNS-, , . 2 . — , 16 . , 16 . ID, 16 , .



, , 32 . , , , , .







, , .



, DNS DNS . , , DNS . , DNS SEC, . , , , DNS- . , , .



origin. DNS , IP-, : „, “. , , , , , , . , , ?



, – DNS- , . , , . -, DNS-, . , DNS SEC, , , DNS- . DNS- , , , – , .



DNS SEC , NSEC. , . , NSEC , foo.mit.edu, goo.mit.edu, , .







, , , , , , „, “.



. , foo.mit.edu -> goo.mit.edu — >…. : » , , gooa.mit.edu". , , .



, DNS . NSEC3, – - , - .



52:00



MITコース「コンピューターシステムのセキュリティ」。 12: « », 3





コースの完全版はこちらから入手できます 。



ご滞在いただきありがとうございます。 私たちの記事が好きですか？ より興味深い資料を見たいですか？ 注文するか、友人に推奨することで、私たちをサポートします。私たちがあなたのために発明したエントリーレベルのサーバーのユニークな類似品のHabrユーザーのために30％割引： VPS（KVM）E5-2650 v4（6 Cores）10GB DDR4 240GB SSD 1Gbpsについて20ドルまたはサーバーを分割する方法？ （オプションはRAID1およびRAID10、最大24コア、最大40GB DDR4で利用可能です）。



VPS（KVM）E5-2650 v4（6コア）10GB DDR4 240GB SSD 1Gbpsまで 6か月の期間を支払う場合は12月まで無料で 、 ここで注文できます 。



Dell R730xdは2倍安いですか？ オランダと米国で249ドルからIntel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 TVを2台持っているだけです！ インフラストラクチャの構築方法について読む クラスRは、1米ドルで9,000ユーロのDell R730xd E5-2650 v4サーバーを使用していますか？