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

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



学生：存在しないトップレベルドメインに何らかの署名がありますか？



教授：あると思います。 ポイントドメインは単なる別のドメインであり、同じメカニズムを実装しています。 そのため、最近の「ドット」および「dot.com」ドメインはDNS SECを使用します。たとえば、.inは存在するドメイン名であり、「dot」という名前も存在するというレコードがすべてあります。そしてそれらの間には何もありません。 そのため、トップレベルドメインには、これらすべてが存在します。







学生： DoS攻撃の危険性に加えて、なぜmit.edu内のドメイン名の繰り返しにそれほど注意を払うのですか？



教授：確かにわかりません。 いずれにせよ、AFSには、これらのMITドメイン名のすべてをリストしたテキストファイルがあります。 しかし、一般的に、一部の企業はこの意味で少し気まずい気がします。なぜなら、彼らはしばしばDNSにあり、部外者には与えられない内部名を持っているからです。 実際、これは公式化されたことのない曖昧な領域であり、DNSがユーザーに提供する保証を正確に説明していないと思います。 通常、人々は、秘密の名前がある場合、DNSの場合は公開されないと想定します。



これは、このシステムが提供すべきまたは提供すべきでないという点で明確な仕様を持たない別の場所だと思います。



学生：何らかの方法で署名を強調表示して署名の有効期間を設定することは可能ですか？



教授：これらには有効期限があります。たとえば、この名前のセットが1週間有効であることを署名できます。クライアントが同期クロックを持っている場合、クライアントは古い署名されたメッセージを拒否できます。



したがって、TCP SYNシーケンス番号を推測することで攻撃について議論したと想定できます。 TCPに関する別の興味深い問題は、サーバーが何らかの状態にあるという事実を悪用するDDoS攻撃です。 前にボードに描かれたこのハンドシェイクを見ると、クライアントがサーバーへの接続を確立するときに、サーバーがSNcクライアントのシリアル番号を覚えている必要があることがわかります。 したがって、サーバーは、この接続にこのシーケンス番号が使用されることを示す別のブロックでデータ構造をサポートする必要があります。







これは、SNシーケンス番号が格納され、クライアント/サーバー接続にSNcシーケンス番号が含まれる一種のテーブルです。 サーバーがこのテーブルを保持する必要があるのは、サーバーが正しいSNcシーケンス番号を後で取得する必要があるためです（たとえば、SNc + 1）。 さらに、サーバーはSNも保存する必要があります。SNは、「適切なユーザー」との接続が確立されたことをサーバーに示すため、はるかに重要です。



問題は、このテーブルに実際の境界線がないことです。 そうすれば、だれがパケットを送信しているかさえ知らなくても、あるマシンからパケットを取得できます。 Cであると主張するソースアドレスを持つC-> Sのようなパケットを取得するだけです。このIPアドレスからこの接続を潜在的に受け入れるには、テーブルにエントリを作成する必要があります。 さらに、これらのレコードは長期間存在します。これは、誰かが非常に離れた場所からあなたとの接続を確立し、同時に多くのパケットが失われる可能性があるためです。 最悪の場合、誰かがこのTCPハンドシェイクを完了するまでに、たとえば1分かかることがあります。 したがって、この状態をTCPスタックに比較的長時間保持する必要があり、有効かどうかを推測する方法はありません。



したがって、人々が思いつくほとんどのTCPスタックに対する最も一般的なDoS攻撃は、大量のパケットの単純な送信です。 攻撃者であれば、特定のサーバーに大量のSYNパケットを送信し、このテーブルをオーバーフローさせるだけです。



問題は、せいぜい、攻撃者が単に同じソースIPアドレスを使用することです。 この場合、各クライアントに許可されるエントリは2つだけ、またはそのようなものであると単純に言うことができます。 そして、攻撃者はテーブル内の最大2つの2つのエントリを使用できます。



もちろん、問題は、攻撃者がクライアントのIPアドレスを偽造し、それらをランダムに見せることができることです。 その場合、サーバーが誰と接続を確立しようとしているのか、サーバーがこれまでに聞いたことのない攻撃者またはクライアントを区別することは非常に困難になります。



したがって、世界のどこからでも接続を受け入れる必要があるサイトを見ると、これは大きな問題になります。 すべてのユーザーへのアクセスを拒否するか、ほとんどの偽の接続試行の状態を保存できるはずです。



したがって、これは、TCPと、サーバーが状態を保存する必要がある一種の接続開始を許可するほとんどのプロトコルの両方の問題です。 ただし、TCPにはいくつかの修正が実装されており、それらについては後で説明します。これらの修正は、TCPでSYNフラッディングと呼ばれるこの問題に対処しようとします。







一般に、これは開発中のプロトコルで認識し、回避しようとする必要がある問題です。 サーバーがクライアントを認証および識別できるようになるまで、サーバーが状態を保存しないように指定する必要があります。 これは、クライアント認証後にのみ、たとえば1回だけ接続を許可するかどうかを決定できるためです。その場合、サーバーはこの接続の状態を保存する必要がありません。



問題は、誰があなたに接続しているかを知る前であっても、状態の保存を保証することです。 SYN Floodingフラッド攻撃に対抗する方法を見てみましょう。サーバーが過剰な状態を蓄積しているということです。



たとえば、TCPを再度変更したり、暗号化などを使用してTCPを簡単に修正したり、何らかの状態を維持する責任を変更したりできます。 しかし、実際には、TCPをそのまま使用する必要があります。 既存のTCPプロトコルを変更せずにこの問題を解決できますか？



繰り返しますが、これは、実行できるトリックを正確に把握しようとする試みであり、むしろ、それらを使用する際に既存のTCPヘッダー形式をそのまま使用できる仮定を正確に把握しようとする試みです。



そして、トリックはステートレスサーバーを作成する賢い方法を見つけることです。そのため、このテーブルをメモリに保存する必要はありません。 これは、SNを慎重に選択することで実行できます。つまり、先ほど検討した式の代わりに、この関数を追加する必要がある場所ではなく、まったく異なる方法でシリアル番号を選択します。 私はあなたに正確な公式を与え、それからそれが本当に面白いのはなぜか、そしてどんな良い特性があるのか​​について話します。



サーバーがこの種の攻撃を受けていることを検出した場合、サーバーは、以前に検討したものと同じ関数Fを持つ式を使用してSNを選択するモードに入ります。







この関数には、ソースIPアドレス、宛先IPアドレス、以前と同じもの（ソースポート、宛先ポート、タイムスタンプ、およびキー）があります。 そして、この機能を数分サイズの「粗視化」というタイムスタンプと組み合わせます。 ヘッダーの2つの部分（関数とタイムスタンプ）には分離があり、多くのビットを必要としません。 このプロトコルが実際のコンピューターでどのように機能するかを正確に忘れていましたが、タイムスタンプは8ビットで、残りのシーケンス番号の式は24ビットであると想像できます。



では、なぜこれが良い計画なのでしょうか？ ここで何が起こっていますか？ なぜこの奇妙な式が必要なのですか？ シリアル番号から取得しようとしたものを覚えておく必要があります。 ここで2つのことが起こります。



1つは、重複パケットに対する保護です。 ボードには、この古いスタイルのシリアル番号の図があり、以前の接続からのパッケージの重複を防ぐ機能を追加しています。







状況によってはうまく機能するこのアクションプランを使用する場合を除き、人々はSYNフラッディングのような攻撃から身を守るより良い方法を見つけることができなかったことがわかります。 それは1つの計画でしたが、別の計画はタイムスタンプ付きの機能で、古いスタイルのこのコンポーネントを放棄しました。 代わりに、パッケージへの応答で誰かがこのACKシーケンス番号（SN）を提供した場合、その人が「正しい」クライアントになることを確認することに集中します。



IPスプーフィング攻撃を防ぐために、この値（SN）に依存していることを覚えています。 結局、サーバーがこのSN値を2番目のステップでクライアントに送信する場合、このクライアントだけが3番目のステップで修正されたSN値を送信して接続を完了することができると予想されます。



これが、このシリアル番号をテーブルに保存しなければならなかった理由です。そうでなければ、これが本当の答えなのか偽物なのかをどうやって知るのでしょうか？ このF関数を使用する理由は、このテーブルをメモリに保存できないためです。



代わりに、最初のステップで示されている接続試行が表示されたら、2番目のステップでこの式を使用してSNを計算し、連絡を取りたいクライアントに単純にそれを送り返し、この接続を忘れます。







次に、3番目のパケットが到着し、その値（SN）が予想されるものに対応する場合、誰かが2番目のステップで回答を受信し、最終的にそれを送信したことを意味します。 最後に、この3番目のステップの後、このTCP接続の実際のレコードをメモリに入れることができます。 これは、クライアントがシリアル番号の正確な値を送信するまでサーバーの永続性を延期する方法です。 このような構造の構築により、クライアントがサーバーに期待する答えを送信し、任意の値ではないことを確認できます。



学生： SNcは限られた時間しか持続しませんか？



教授：はい、サーバーはSNc値を永続的に保存しません。これはあまり良くありません。 ダイアグラムにはこれを示していませんが、3行目の最後に、このパケットにデータがないことを示すフィールドがありますが、このフィールドがあるためにSNcシーケンス番号のみが含まれています。







したがって、サーバーはSNcの値を復元できます。これは、クライアントがいずれにしてもこのパッケージにSNcを含めるためです。 以前は重要ではありませんでしたが、今では関連があるかのようです。 ここでは何もチェックしませんが、そのようなフィールドの存在自体は良いことです。 しかし、それは悲しい結果をもたらします。 たとえば、ここで悪用される可能性のある複雑なものを使用する場合。 しかし、これはクライアント要求でサーバーメモリがオーバーフローするほど悪くはありません。



心配なのは、このテーブルのリポジトリのリリースと、本物のクライアントとの接続が確実に確立されることだけだからです。 そして、このクライアントが私と100万の接続を確立した場合、私は彼からのリクエストを受け入れるのをやめるだけで、それはとても簡単です。 問題は、偽の住所が本物の顧客の住所と区別しにくいことです。



学生：タイムスタンプを保持する必要がありますか？



教授：はい、賢いことがあります！ 3番目のステップでSNの値を取得したら、この値が正しいことを確認するために、この関数Fの入力データを計算する方法を理解する必要があります。 したがって、パッケージの最後にあるタイムスタンプを取得し、それを使用して関数内で計算します。 それ以外は復元できます。 誰が3番目のステップとパッケージを送信したのか、これらすべてのフィールドとキーはまだ秘密であり、シーケンスの最後の8ビットからのタイムスタンプがあることを知っています。 この場合、古い接続を単に禁止することにより、古すぎるタイムスタンプを除外することがあります。



学生： 8ビットのセキュリティを失ったという理由だけで、または他の何らかの理由で、攻撃されたときにこれを使用すると思いますか？



教授：はい、これはあまり良くありません、多くの悪い特性があります。 ある意味では、8ビットのセキュリティが本当に失われています。 否定できない部分は32ビットではなく24ビットだからです。



別の問題は、特定のパッケージを紛失するとどうなるかということです。 TCPでは、3番目のパケットが失われた場合、クライアントは何も待たないことが一般に受け入れられています。 または、申し訳ありませんが、おそらくこのTCP接続上で実行するプロトコルは、サーバーが最初に何かを言うつもりであると想定しているプロトコルなので、接続して答えを聞くだけです。 また、たとえばSMTPでは、サーバーはプロトコルを介して挨拶のようなものを送信する必要があります。 たとえば、SMTPサーバーに接続し、3番目のパケットを送信すると、すべてを実行し、サーバーが応答するのを待つだけだと考えます。次に例を示します。



「こんにちは、これはSMTPサーバーです。メールを送ってください！」



そのため、この3番目のパッケージは失われる可能性があります。 実際のTCPでは、サーバーは2番目のステップでクライアントに応答しましたが、3番目の応答パケットを受信しなかったことを記憶しています。 したがって、サーバーは2番目のパケットをクライアントに再度送信して、3番目のパケットを再起動します。 もちろん、サーバーに状態が保存されていない場合は、何を送信するのかわかりません。 これにより、接続のセットアップがやや問題になります。これは、両側が相互のステップを期待するためです。 サーバーは、クライアントがサーバーからの応答を待っていることすら知らず、クライアントはサーバーの応答を待っていますが、状態を保存していないため応答しません。 したがって、これは、サーバーの生産モードを常に使用しない別の理由です。



学生： 1つのホストから2つの非常に短命の接続を次々に確立すると、データが失われる可能性があります。



教授：はい、もちろん。 もう1つは、この古いスタイルのISNシーケンス番号の使用を拒否したことです。これにより、これらの複数の接続の相互依存性が短時間で増加しました。 ここにはいくつかのトレードオフがあると思いますが、そのうち3つについてお話ししただけなので、心配する理由がいくつかあります。



プロトコルをゼロから開発し、最善を尽くすことができれば、F関数用に適切な64ビットボリュームとタイムスタンプ用に64ビットボリュームを用意するだけで、givingめずに常に使用できます。これらすべての素晴らしいもの。



学生： 2番目と3番目のステップのSNは同じである必要がありますか？



教授：もちろん、そうしないと、サーバーはこのクライアントがパッケージを受け取ったと結論付けることができません。 サーバーがこのSNが以前と同じ意味を持っていることを確認しない場合、さらに悪化する可能性があります。最初のステップで任意のIPアドレスから接続を偽造し、2番目のステップでこの回答を得ることができるからです。 または、別のIPアドレスに向けられているため、この回答は得られません。 次に、3番目のステップで、他のIPアドレスから接続を確立します。 この場合、サーバーは確立された接続をサポートし、データの送信を待機します。







学生：しかし、タイムスタンプは異なりますよね？ サーバーは、状態を保存しない場合、新しいタイムスタンプを使用してこれを再カウントできますか？



教授：私が言ったように、これらのタイムスタンプは非常に「粗い」もので、数分で評価されます。 同じ分に接続する場合、その分に接続する場合、すべてが正常です-これはあまりにも悪いです。



この回路の別の問題は、多くの点で不完全であることです。 しかし、Linuxを含むほとんどの稼働中のシステムには、このテーブルのエントリが多すぎることを検出する方法があります。 そして、オーバーフローの脅威が発生すると、システムは別のスキームに切り替わります。



学生：攻撃者が多数のIPアドレスを制御し、あなたが切り替えたとしてもあなたが言ったことをするなら...



教授：はい、あなたは本当にほとんど何もできません。 このスキームが私たちを気にかけたのは、私たちがフィルターをかけるか、何らかの形で攻撃者と「善人」を区別したかったからです。 攻撃者がより多くのIPアドレスを持ち、善人よりも多くのマシンを制御している場合、彼はサーバーに接続し、複数のWebページを要求するか、連絡を取り合うことができます。



そして、サーバーが正当なクライアントからリクエストを受信したのか、それともサーバーのリソースをバインドする攻撃者なのかを判断するのは非常に困難です。 だからあなたは絶対に正しい。 このスキームは、攻撃者が少数のIPアドレスを持ち、効果を達成したい場合にのみ機能します。



今日、一部の攻撃者は一般ユーザーによって多数のハッキングされたコンピューターを制御しているため、これは懸念事項です。 これにより、世界中に配置された多数のマシンでDoSを作成することができます。これに対して防御することは非常に困難です。



もう1つ興味深いことに言及しておきます。DoSサービスの拒否自体は悪いことですが、プロトコル自体がこのような攻撃に寄与している場合はさらに悪いことです。 攻撃者はこれを知っており、主にDNSなどのプロトコルを使用してシステムを攻撃します。 DNSプロトコルには、サーバーに要求を送信するクライアントが含まれており、サーバーはクライアントに応答を送信します。 また、多くの場合、バイト単位の応答サイズは要求ボリュームよりもはるかに大きくなります。







mit.eduサーバーについて尋ねました。 , , mit.edu — , mit.edu, , DNS SEC, .



100 , — 1000 . , «» - . , DNS- . 100 - DNS-, , , 1000 .



, . , TCP SYN Flooding, DNS- , . , , « ».



DNS. . , DNS-. , . .



: DNS- …



: , DNS- , - .



: , ?



: , DNS-, . DNS-, . 10 DNS-, , , , , . . , , DNS-, .



, DNS , , , . , .



, , , – , , , . , , . .



DNS- , . , , .



, : «, , »! , , DNS- .



, . - -, . DoS , . , , , , .







, , . , , , .



, , . .



, DHCP, . , , IP-. , , MIT DHCP, , , , IP-, , DNS-, , .



, DHCP DHCP-, , DHCP-. , , . , DHCP IP-, : «, DNS- »! DNS .



, . , BGP, IP-, . , , BGP, : «, IP-!», : „, , “.







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



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



, , , . : , , , , , DoS — . .



したがって、任意のネットワークユーザーを切断できるSYNフラッディング攻撃やRST攻撃などを回避するよう努力する必要があります。これらは、低レベルでは本当に有害であり、高レベルでは修正が難しいものです。ただし、暗号化を使用して、データの整合性と機密性をほぼ保証します。これを行う方法については、ケルベロスに関する次の講義で説明します。





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



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