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

マサチューセッツ工科大学。 講義コース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

本日は、特にネットワークセキュリティについてお話します。特に、Stephen Bellovinによる「A Look Back at」TCP / IP Protocol Suiteのセキュリティ問題」という記事について説明します。 この男はかつてAT＆Tで働いていましたが、現在はコロンビアで働いています。 この作品で興味深いのは、比較的古いことです-10年以上前であり、実際、これらは1989年に10年前に出された記事に対するコメントです。

皆さんの多くは、ここで説明されている問題の多くがTCPプロトコルの今日のバージョンで解決された場合、なぜこれを調査するのかと尋ねます。



スティーブンによって説明された問題のいくつかはその後解決されたというのは事実であり、それらのいくつかはまだ問題のままです。 これを念頭に置いて、それらをソートし、何が起こるかを確認します。 TCPを設計するときに、人々がそもそもこれらすべての問題を解決しなかったのはなぜでしょうか？ 彼らは何を考えていたのですか？

そして、これは実際には明確ではありません。 どう思いますか？ これらすべての考慮事項を考慮して、TCPプロトコルに必要なセキュリティがないのはなぜですか？ 提案はありますか？

学生：当時、インターネットははるかに信頼できる場所でした。

教授：はい、文字通りこの男の記事からの引用でした。 はい、当時一般的には... 40年前にインターネットプロトコルのセットが開発されたと思います。 要件は完全に異なっていました。 名前でお互いを知っていた比較的だまされやすいサイトの束を共通のネットワークに接続することが必要でした。

これは、成功したシステムで頻繁に発生すると思います。変更が必要です。 以前は少数のサイトのプロトコルでしたが、現在ではこのプロトコルが全世界をカバーしています。 そして、あなたはもはやインターネットに接続しているすべての人の名前を知りません。 彼らが何か悪いことをした場合、あなたは彼らに電話することはできません。

したがって、私たちが検討している多くのプロトコルについて、この話は同じだと思います。 そして、あなたたちの多くは、「これらの人たちは一体何を考えていたのか？ これにはとても欠陥があります！」 しかし実際には、彼らはまったく異なるシステムを設計し、現代のニーズに合わせて単純に適合させました。

同じこと、およびインターネットは、過去数週間にわたって見てきたように、まったく異なる目的のために設計されました。 しかし、それは拡大し、このプロトコルを現代の要件に適応させる方法について新たな懸念がありました。

セキュリティ問題の深刻度を過大評価しなければならなかったという突然の出来事がもう1つあります。 かつては、攻撃者がシステムで何ができるかわからなかったため、心配する必要のあるすべてのことを本当に理解していなかったのです。



この理由の一部は、TCPセキュリティに何が起こったのか、何がうまくいかなかったのか、どうすれば修正できるのかなどを見るのは興味深いと思います。 その結果、独自のプロトコルを開発する際に回避すべき問題の種類と、この種の攻撃に関する適切な思考の構成要素を見つける必要があります。 そのような落とし穴を回避するために、攻撃者が自分のプロトコルでそれを開発しているときに、攻撃者ができることをどのようにして知るのですか？

さて、前文はさておき、この記事について話しましょう。

それでは、ネットワークセキュリティについてどう考える必要がありますか？ 最初の原則から始めて、私たちの脅威モデルが何であるかを理解しようとすることができると思います。 それでは、攻撃者は私たちのネットワーク上で何ができますか？

彼はおそらくパケットを傍受する能力があり、おそらく彼はそれらを変更することができます。 したがって、ネットワーク経由でパケットを送信している場合、悪意のある人があなたのパケットを見て、宛先に到達する前にパケットを変更できると想定するのは合理的です。 また、ドロップして、送信したことがない任意のコンテンツを含むカスタムパッケージを入力する機能を使用することもできます。



しかし、より危険なのは、記事に記載されているプロトコルを悪者が妨害する可能性です。 攻撃者は自分のコンピューターを持ち、それを完全に制御します。 信頼できるすべてのコンピューターが正常に動作していても、自分のコンピューターを持っている悪人があなたのプロトコルやシステムに干渉する可能性があります。

そのため、多くの人が互いに話し合うルーティングプロトコルを使用している場合、悪意のある人を外部に留めるには、おそらくある程度のスケーリングは実用的ではありません。 10人の参加者がいるルーティングプロトコルが実行されている場合は、すべての参加者に電話して、「ええ、はい、みんな、わかっています」と言うことができます。

しかし、今日のインターネットの規模では、他のネットワークメンバーがこのプロトコルを使用している人を直接見つけることは不可能です。 そのため、おそらく悪人があなたのプロトコルや分散システムに参加するでしょう。 したがって、分散システムを設計することは重要ですが、それでもなお、これで合理的なことを行うことができます。

OK、それでは、これらすべての意味は何ですか？ リストを見ていくと思います。 パケットの傍受は一般的に理解しやすいです;悪者がパケットを傍受することを期待する場合、または少なくともプレーンテキストで送信しない場合、ネットワーク経由で重要なデータを送信することはできません。 おそらく、データを暗号化する必要があります。



これは比較的理解しやすいように思えますが、プロトコルを開発する際にはこのことを覚えておく必要があります。 パッケージの導入または挿入は、この記事で説明されている広範な興味深い問題につながります。 特に、攻撃者は他の送信者からのパケットを偽装できるパケットを注入できます。 データ伝送パスはIPの使用に基づいているため、パケット自体には、パケットの送信元と宛先IPのIPを示すヘッダーがあります。 ただし、ソースが必ず正しいことを確認する人はいません。 最近いくつかのフィルタリングがありますが、完全ではなく、信頼するのは困難です。

そのため、最初の近似では、攻撃者は任意のIPアドレスをソースとして内部に挿入し、正しい宛先に送信できます。 攻撃者が任意のパケットを送信する機能で何ができるかを知ることは興味深いです。

前の週では、Webセキュリティの観点からバッファオーバーフローの問題を調査しました。 攻撃者がバッファオーバーフローなどの実装エラーをどのように使用できるかを調査しました。 興味深いことに、この記事の著者は実装エラーにはあまり関心がなく、プロトコルエラーに関心があります。

それで、これについて特別なことは何ですか？ 実装エラーに注意を払わなかったのはなぜですか？数週間かけてエラーを調べましたが？ なぜそれが重要なのですか？

学生：プロトコルを書くとき、これらの間違いを除外しなければならないからです。

教授：はい、変更するのが難しいので、これはプロトコル設計の誤りによる本当に大きな失敗です。 そのため、実装エラーが発生し、memcpyまたはプリントアウトでメモリ範囲をチェックしなかった場合、このエラーに気付くことはありません。 ただし、範囲チェックを行っても機能する場合は、バッファオーバーフローを回避できるため、これは素晴らしいことです。

しかし、プロトコルの仕様に何らかのエラーがあり、プロトコルの動作方法に問題がある場合、そのようなエラーを修正するには、プロトコル全体を修正する必要があります。つまり、このプロトコルを話すすべてのシステムに潜在的な影響があります。 したがって、TCPプロトコルに何らかの問題が見つかった場合、潜在的にそれは非常に破壊的です。 TCPを使用するすべてのマシンは変更を加える必要があるため、変更されたプロトコルを古いマシンと互換性を持つようにすることは潜在的に非常に難しいためです。

Stephenが非常に心配していたTCPプロトコルエラーは基本的なものであったため、彼はそれらについて話すことにしました。 最初の例では、彼はTCP SN番号がどのように機能するかを見ます。

学生：これはちょっとした話題ですが、興味があります。 TCPでエラーを見つけたとします。 どのように変更しますか？ これを変更する必要があることを世界中のすべてのコンピューターにどのように伝えますか？

教授 ：はい、これは大きな問題だと思います。 TCPでエラーを見つけたらどうしますか？ まあ、それは何をすべきか明確ではありません。 ここの著者はこれに苦労していると思います。 TCPを再設計できる場合、これらのエラーの多くは、何を探すべきかを事前に知っていれば、比較的簡単に修正できます。

しかし、TCPは修正や変更が非常に難しいため、最終的に次のことが起こります：開発者は、古い実装を新しい実装で使用できるようにするか、接続を多少安全にする追加フ​​ィールドを追加できる下位互換性のある設定を見つけようとします。



しかし、これは大きな問題です。 これがTCPに根ざした何らかのセキュリティ問題である場合、nプラス1と仮定すると、単にTCPバージョンに切り替えることすら非常に難しいため、誰にとっても大きな問題になります。

IPv6は、これが起こらない例として見ることができ、この問題はさらに15年または20年発生することがわかっています。 IPv6は10年以上使用されてきましたが、IPv4から移行するよう人々を説得するのは困難です。 彼らにとってIPv4で十分であり、機能しているようであり、新しいインターネットプロトコルへの切り替えには費用がかかりすぎると考えています。 彼らは言う：「誰もIPv6を話さないので、なぜ私と話をする誰もいないこの奇妙なプロトコルで話を始めなければならないのですか？」 いずれにせよ、これは一種の前進運動ですが、多くの時間がかかると思います。 移行にはいくつかの動機がありますが、この場合の後方互換性は非常に役立ちます。

IPv6には多くの後方互換性オプションがあります。たとえば、IPv6を使用してIPv4ホストと通信できます。 したがって、開発者はこのすべてのサポートを設計しようとしていますが、アップグレードするように人々を説得することは依然として困難です。

したがって、TCPシーケンス番号を考慮して、TCPハンドシェイクの動作に関連する2つの問題を実際に検討します。 それでは、TCP接続が最初に確立される方法を見てみましょう。

新しいTCP接続を確立するために、3つのパケットが送信されます。 クライアントは、サーバーに接続するためのパッケージを生成します。これは、ここに私のクライアントIPアドレスがあり、サーバーに送信することを示しています。 同時に、異なる領域で構成されるパケットヘッダー構造がありますが、シリアル番号の領域に関心があります。 ここで、「状態を同期して新しい接続を確立したい」というSYNフラグがあり、SNcクライアントのシリアル番号が含まれています。



次に、サーバーがこのパケットを受信すると、「クライアントが私と接続したいので、だれが私に連絡しようとしていると言っても、このアドレスにパケットを送り返します」と言います。 したがって、サーバーはパケットをクライアントに送信します。クライアントには、サーバー同期シーケンス番号SNとクライアントACK確認番号（SNc）が含まれます。 最後に、3番目のパケットで、クライアントはサーバーに応答し、同期を確認し、サーバーACKサーバー確認番号（SN）をサーバーに送信します。 これで、クライアントはデータの送信を開始できます。

したがって、データを送信するには、接続の開始時に、クライアントはパケットにデータを含め、SNcクライアントのシリアル番号を添付して、これが実際に正当なクライアントデータであることを示す必要があります。 例えば、サーバーはデータの最初の部分の一部を逃したため、これは今来たてのメッセージの一部のデータではないことを指摘しています。



したがって、原則として、これらのシリアル番号はすべて、パケット配信を提供するように設計されています。 クライアントが2つのパケットを送信する場合、最初のシーケンス番号を持つパケットが最初のデータであり、次のシーケンス番号が次のデータです。 また、いくつかのセキュリティ要件を提供するのにも役立ちます。

その前に、これらの要件が変化している例を示しました。 したがって、最初はTCPがセキュリティ機能を提供すべきだとは考えていませんでした。 しかし、その後、TCPはアプリケーションの使用を開始し、これらのTCP接続に依存しているように見えました。侵入者がそれらを破壊することはできない、または攻撃者は既存のTCP接続に悪意のあるデータを挿入できないと信じていました。 元々パッケージの注文のみを目的としていたこのメカニズムは、突然、これらの接続のセキュリティをある程度保証するようになりました。

したがって、この場合、問題はサーバーがこのTCP接続に関して提案したものに関連していると想定します。 通常、サーバーは-暗黙的に、想像できるように-この接続はこのIPアドレスCで目的のクライアントと確立されると想定します。 しかし、そのような仮定の理由はありますか？ サーバーがこのクライアントサーバー接続に関するデータを含むメッセージを受信し、シーケンス番号がCである場合、実際のクライアントがこのデータを送信したとサーバーが判断するのはなぜですか？

学生：シリアル番号は推測しにくいためです。
教授：そうです、これは一種の暗黙のことであり、正しいSNcシーケンス番号がなければならないことを意味します。 また、この接続を確立するには、クライアントが確認済みのSNサーバーシリアル番号を持っている必要があり、サーバーシリアル番号はサーバーによってクライアントのIPアドレスにのみ送信されます。

学生：シーケンス番号に使用できるビット数は？

教授： TCPシーケンス番号は32ビット長で、これは乱数ではありませんが、推測するのは容易ではありませんが、多くの帯域幅が必要になります。

学生：データのシリアル番号は最初のシリアル番号よりも大きいですか？

教授：はい、原則として、これらのことは増加しています。 したがって、SYNを送信するたびに、シーケンス番号より1バイト多いと見なされます。 つまり、最初の行に引数（SNc）があった場合、4番目の行には既に（SNc + 1）があり、ここから番号付けが続きます。 したがって、5バイトを転送すると、次の値（SNc）+6になります。 送信するバイトを単純にカウントし、各SYNは1バイトをカウントします。 TCP仕様では、これらのシリアル番号を選択することをお勧めします。これにより、これらのシリアル番号は、ほぼ一定の速度で増加します。 RFCプロトコルの最初の作業文書では、これらの値を約250,000単位に1秒あたり250,000プラスすることを提案しています。



これが完全にランダムではなかった理由は、これらのシーケンス番号が実際にパケットの干渉を防ぐため、または以前の接続からのパケットを新しい接続と混合するのを防ぐために使用されるためです。 新しい接続を確立するたびに、完全にランダムなシリアル番号を選択します。 この場合、一連の接続を繰り返しインストールすると、以前の接続からのパケットのシーケンス番号が新しい接続のシーケンス番号に非常に似ているため、サーバーは新しい接続のデータの有効な部分として受け入れられる可能性があります。

ですから、これはTCP開発者が非常に心配していたことです-これらの順序のないパケットや遅延したパケット。 その結果、彼らはこれらのシーケンス番号が化合物間であってもかなり単調な時間シーケンスであることを本当に望んでいました。

1つの接続を開くと、同じ送信元と宛先、ポート番号、IPアドレスなどを持つことができます。 しかし、以前にではなく今、この接続を確立したので、以前に送信したメッセージからのパケットが、新しい接続用に持っているシーケンス番号と一致しないことを願っています。 そのため、これは繰り返し接続間の混乱を防ぐメカニズムでした。

学生：パッケージシーケンスの手順が正確にわからない場合、受け取ったパッケージが次のパッケージであり、前のパッケージの一部ではないことをどのようにして知ることができますか？

教授：原則として、最後に受信したパケットを覚えています。 そして、次のシーケンス番号は、シーケンス内の正確に次のパケットです。 したがって、たとえば、サーバーは、日付（SNc + 1）データの一部を正確に確認したことを認識し、次はSYN（SNc + 1）パケットになります。これは、接続の最初の前のパケットがSYN（SNc）だったためです。

学生：だから、シリアル番号を設定すると、その後も...

教授：もちろん、これらのシリアル番号は、最初にインストールするときに、何らかの計画に従って選択されます。 この計画についてお話します。 それらはランダムであると考えるかもしれませんが、時間の経過とともに、接続の初期シーケンス番号の変化の連続した流れを表すはずです。

ただし、1つの接続内では、すべてが確立されるとすぐに終了します。シリアル番号は固定されています。 また、データが送信されると、この接続にフラグを立てます。

, . , . , , , .

, - , 250000. , , , 64k 128k, . , – , SYN .

, 64 . , .

, . , , , , IP-.
, , , , , . , , .

, ? , , , — SNc. , , - , , , .

, . ACK (SNs).

- .



SNs , , , IP- C.

, . , : , , , data (SNc +1).



(SNs). それは明らかですか？

: , ?

: . , , , , . , , , , .

: , , ?

: . , ?

, . , , 32 , , .

, .

: , , , . …

: , TCP .

: , .

: , .

: , , .

: , , , . , , 1000 , 2 32 .

, - , , . . , .



: - , ?

: , . , , IP-, ?

: ?

: — ? , . ?

: , , , , - .

: , , , , , . IP-, TCP , , , .

TCP , - , , , C RST (SN…), , .



- , , C , .

, C , . , S , : «, , , ».

, , , , , C .

, «» C , . , «» C , . , TCP.

: , . , SYN , .

: , , . , , , , NAT, . , NAT RST , . , , , , , Comcast , RST .

: ?

: , , TCP. , . , , , . /, .

, data (SNc +1). , IP- , : « », , S.



そして、最後の行のこの接続のこのSYN（SN）と3番目の行の（SN）が接続されている場合、これは本当に問題です。ただし、これは別のIPアドレスからの番号であるため、接続しないようにしましょう。これで問題はなくなりました。このSNSが別の接続のSNSに基づいているとは推測できません。

25:50分

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


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

ご滞在いただきありがとうございます。 私たちの記事が好きですか？ より興味深い資料を見たいですか？ 注文するか、友人に推奨することで、私たちをサポートします。私たちがあなたのために発明したエントリーレベルのサーバーのユニークな類似品の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サーバーを使用していますか？