MITコース「コンピューターシステムのセキュリティ」。 講義13：ネットワークプロトコル、パート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

講義13：「ネットワークプロトコル」 パート1 / パート2 / パート3



そこで、本日は、ネットワーク上のコンピューターとアプリケーションの相互認証用に設計された暗号的に安全なプロトコルであるKerberosについてお話します。 これは、クライアントとサーバー間の接続を確立する前にクライアントとサーバーを認証するためのプロトコルです。



最後に、TCP SYNシーケンス番号のみを使用してセキュリティ保護を検討した前回の講義とは異なり、最後に暗号化を使用します。







それでは、Kerberosについて話しましょう。 このプロトコルをサポートしようとしているのは何ですか？ 複数のサーバーコンピューターと複数のクライアントコンピューターの相互作用を保証するために、25年または30年前に研究所でAthenaプロジェクトの一部として作成されました。



どこかにファイルサーバーがあると想像してください。 おそらく、これはネットワークに接続されたメールサーバー、またはプリンターなどの他のネットワークサービスです。 そして、これらはすべて単に1つのコンピューター上のプロセスではなく、何らかのネットワークに接続されています。







AthenaとKerberosを作成するための前提条件は、同時共有のためのマシンがあり、すべてが個別のプロセスであり、誰もが同じシステムにログインしてそこにファイルを保存できることです。 そのため、開発者はより便利な分散システムを作成したいと考えていました。







したがって、これは、一方の側にこれらのサーバーを配置し、他方の側にユーザ​​ーが自分自身を使用してアプリケーションを実行するワークステーションの束を配置することを意味しました。 これらのワークステーションはこれらのサーバーに接続し、ユーザーファイルを保存したり、メールを受信したりします。



彼らが解決したかった問題は、ネットワークを信頼してその正当性を検証することなく、サーバー側のこれらすべての異なるコンピューターでこれらのワークステーションを使用するユーザーを認証する方法でした。 これはあらゆる点で合理的な設計要件でした。 当時、Kerberosの代替手段は、前回の講義で説明したRログインチームでしたが、ユーザーの認証にIPアドレスを使用するだけなので、悪い計画のように思えました。



Kerberosは非常に成功しており、実際にはまだMITネットワークで使用されており、MicrosoftのActive Directoryサーバーのバックボーンです。 ほぼすべてのMicrosoft Windows Serverベースの製品は、何らかの形でKerberosを使用しています。



ただし、このプロトコルは25年または30年前に開発され、それ以来、セキュリティについての理解が深まっているため、変更が必要になりました。 したがって、Kerberosの現在のバージョンは、この講義の資料に記載されているバージョンと多くの点で著しく異なります。 今日、どの仮定が十分ではなく、最初のバージョンで何が間違っていたのかを検討します。 これは、本格的なシステムでネットワーク参加者を認証するために実際に暗号化を使用した最初のプロトコルでは避けられません。



いずれにせよ、ボードに描かれている図は、Kerberosを作成するための一種のインストールです。 信頼のモデルが何であるかを知ることは興味深いです。 したがって、追加の構造がスキームに導入されます-Kerberosサーバー、ここに横にあります。







したがって、3番目のモデルは、前回の講義で述べたように、ネットワークの信頼性が低いという事実に基づいています。 このKerberosスキームで誰を信頼すべきですか？ もちろん、すべてのネットワーク参加者はKerberosサーバーを信頼する必要があります。 したがって、システムの作成者は、一時的にKerberosサーバーが何らかの形でのネットワーク認証のすべてのチェックを担当することを提案しました。 このネットワークには、他に信頼できるものがありますか？



学生：ユーザーは自分のマシンを信頼できます。



教授：はい、それは良い議論です。 ここには私が描いていないユーザーがいます。 しかし、これらの人はある種のワークステーションを使用しており、実際、Kerberosではユーザーが自分のワークステーションを信頼することが非常に重要です。 ワークステーションを信頼しないとどうなりますか？ ユーザーがワークステーションを信頼していない場合は、パスワードを「盗聴」して、あなたに代わって行動できるからです。







学生：攻撃者は、たとえば、Kerberosサーバーへのチケットを学習することにより、さらに多くのことができます。



教授：はい、正確に。 ログインすると、パスワードを入力しますが、これはチケットよりもさらにひどいものです。 そのため、実際には、ワークステーションを信頼しない場合、Kerberosに小さな問題があります。 自分のラップトップを使用する場合、それほど怖いわけではありませんが、公共のコンピューターのセキュリティは疑わしいです。 この場合、正確に何がうまくいかないかを検討します。



学生：サーバー管理者を信頼し、互いのサーバーへの特権アクセスができることを確認する必要があります。



教授：マシン自体は相互に信頼する必要はないと思います。たとえば、メールサーバーはプリントサーバーやファイルサーバーを信頼する必要はありません。



学生：信頼しないでください。ただし、別のサーバーを介したアクセスがサポートされていないサーバーにアクセスすることはできます。



教授：はい、そうです。 メールサーバーとプリントサーバーの間に信頼関係を確立するが、便宜のためにメールサーバーにファイルサーバー上のファイルへのアクセスを許可するだけであれば、これは悪用される可能性があります。 したがって、ここで追加のレベルの信頼または冗長な信頼を導入することに注意する必要があります。



ここで他に重要なことは何ですか？ サーバーは何らかの形でユーザーまたはワークステーションを信頼する必要がありますか？ そうではないと思います。 Kerberosのグローバルな目標は、これらのユーザーが正当なユーザーであり、データまたは何かにアクセスする必要があることを暗号で証明できるようになるまで、サーバーがこれらすべてのユーザーまたはワークステーションを事前に知ること、またはそれらを認証する方法を知ることではないことでしたサーバーが管理する以上のもの。



Kerberosの仕組みと一般的なアーキテクチャを見てみましょう。 Kerberosサーバーをより大規模に描いてみましょう。 現在では、KDC-Key Distribution Center、またはKey Providing Centerと呼ばれています。 どこかに接続できるユーザーとサービスがあります。 計画では、Kerberosサーバーは、Kerberosサーバーとその周囲の世界の各コンピューターエンティティとの間の通信用の共有キーの格納を担当します。 したがって、ユーザーが何らかの種類のクライアントキーKcを持っている場合、Kerberosサーバーはこのキーを記憶し、自身の内部のどこかに保存します。 同様に、サービスのKsキーは、このサービス自体、Kerberosサーバーのみに知られており、他の誰にも知られていません。 したがって、パスワードを知っていて、Kerberosがそれを知っているが、他の誰もそれを知らない場合、パスワードの一般的な使用と考えることができます。







それはあなたがお互いに「私はその同じ男だ」ことを証明する方法です。 もちろん、Kerberosサーバーはこのキーの所有者を追跡する必要があるため、ユーザー名とサービス名、たとえばserv afs（これはファイルサーバーです）、およびそれらに対応するキーが格納されるテーブルが必要です。



同時に、KDCは、Kerberosサーバーが認識する必要があるMITネットワークに存在するコンピューターエンティティを考慮に入れるため、バイト数の点ではあまり大きくないが、レコード数が非常に多い巨大なテーブルを格納する責任があります。 したがって、2種類のインターフェイスがあります。







講義資料では、このことについて十分に明確に話されていません。つまり、これら2つのインターフェイスの存在は単に暗示されています。 実際、1台のマシンには実際に2つのインターフェイスがあります。 それらの1つはKerberosと呼ばれ、2つ目はTGS、Ticket Granting Service、またはTicket Serviceです。



実際、結局のところ、これらは同じことを話す2つの方法にすぎず、プロトコルはこれら2つのことでわずかに異なるだけです。 したがって、最初に、ユーザーがログインすると、ユーザーは上位のインターフェイスであるKerberosと「話し」、クライアント名Cを送信します。これはAthena大学のネットワーク上のユーザー名である可能性があります。



サーバーはこのリクエストにtgsチケットまたはチケット情報で応答します;この情報の詳細については後ほど説明します。 次に、あるサービスとチャットしたい場合、まずTGSインターフェースに行き、それを伝える必要があります：「すでにKerberosインターフェースを介してログインしているので、特定のサービスを提供するSサーバーと話をしたい」



そのため、TGSに通信したいサーバーについて伝え、その後、サーバーSと通信するためのチケットのようなものを返します。その後、サーバーSの受信チケットを使用して、必要なサーバーと最終的に通信できます。



これは一種の高レベルの計画です。 では、なぜ2つのインターフェイスがここで使用されるのでしょうか？ これについて多くの質問をすることができます。 Ksサーバーの場合、このサービスはおそらくディスクに保存されます。 そして、ユーザー側のこのKcはどうなりますか？ このKcはKerberosのどこから来たのですか？







学生：このKcは、データベースのKDCサーバーテーブルにある必要があります。



教授：はい、そうです、Cキーはこの巨大なデータベースの表にあります。 ただし、ユーザーは自分がユーザーであることを証明する必要があるため、ユーザーにも知られている必要があります。



学生：パスワードが必要な一方向の機能ですか？



教授：はい、彼らは実際にそのようなスマートプランを持っています。Kcはユーザーのパスワードまたはある種のキー生成関数をハッシュすることによって取得されます。これにはいくつかの異なる方法があります。 ただし、基本的にはパスワードを取得し、何らかの方法で変換して、このキーKcを取得します。 したがって、これは良い方法のようです。



しかし、なぜ2つのプロトコルが必要なのでしょうか？ 結局、最初のKerberosインターフェースから直接チケットをリクエストして、「この名前のチケットが欲しい！」と言って、彼はあなたにチケットを送り返し、Kcを使って解読できると想像できます。



学生：別のサービスにアクセスするたびにユーザーにパスワードを再入力させたくないのでしょうか？



教授：確かに、2つのインターフェイスの違いの理由は、最初のインターフェイスからすべての応答がKcキーで暗号化されて返され、Kerberosの作成者がこのKcを長期間保存する可能性を心配しているためです。 ユーザーに毎回パスワードを入力するように要求する必要があり、それは単にうっとうしいだけです。さもなければ、彼は常にメモリに「座っている」からです。 基本的に、これはユーザーパスワードだけで十分です。Kcにアクセスできるユーザーは、ユーザーがパスワードを変更するまで、またはそれ以上変更するまでユーザーのファイルにアクセスできるためです。 後でこの問題をさらに詳しく検討します。



したがって、このKcキーを漏らすことは非常に危険です。 したがって、後続のすべての要求に最初のインターフェイスと2番目のインターフェイスを使用する全体のポイントは、KerberosサーバーTGSインターフェイスからの応答を解読するとすぐに実際にKcを忘れることができるということです。 これ以降、キーリークが発生した場合でも、機能は受信したチケットに依存します。 最悪の場合、誰かが無制限の時間ではなく、数時間あなたのアカウントにアクセスできるようになります。 これが、同じリソースへの2つのアクセスパスを持つこのようなスキームの理由です。



したがって、これらのプロトコルが実際にネットワーク上でどのように見えるかの仕組みに入る前に、Kerberos名の側面について少し話しましょう。 ある意味では、Kerberosは名前のレジストリと見なすことができます。 彼は、これらの暗号化キーを小文字で表示する責任があります。 これは、Kerberosが実行する基本的な種類の操作です。 次の講義では、なぜ同様の機能が必要なのかを説明します。 Kerberosとは異なる方法で実装できますが、ほぼすべての分散セキュリティシステムで同様のものを使用することが基本的に非常に重要です。 それでは、Kerberosが名前をどのように扱うかを見てみましょう。



Kerberosには、ネットワーク参加者のデータベース内の各コンピューターエンティティに対する一種のシステムコールがあり、このデータの主な形式は単なる文字列です。 そのため、たとえばnickolaiのような形式でいくつかの基本的な名前を持つことができます。 これは名前の文字列です。







これはKerberosのある領域の主要なパラメーターです。実際、これはKDCテーブルの左の列にあるものです。 また、プロトコルがサポートする追加のパラメーターもいくつかあります。 たとえば、nickolai.extra secなどの別の名前を入力できます。これは、追加のセキュリティが必要なリソースにアクセスするために、nickolaiという名前に加えて使用されます。 したがって、多分私は本当に安全なもののための1つのパスワードと私の通常のアカウントのための別のパスワードを持っています。



Kerberosはこの側面に言及しています。 したがって、疑問に思うかもしれません-影響はどこから来ますか？ Kerberosサービスは名前を特定のキーにマップしますが、コンピューターと話しているときに、どの名前を尋ねるのか、または応答としてどの名前を期待するのかをどのように知るのですか？ つまり、Kerberosサーバーの外部に表示される名前、またはこれらのユーザー名が正確にどこに表示されるのかを尋ねます。 何かアイデアはありますか？



学生：おそらく、MITサーバーにユーザー名を尋ねることができます。



教授：はい、もちろん。 これは、これらのものをリストする方法です。 さらに、ユーザーはログイン時に入力するだけで、そこからアクセスできます。 ユーザー名は他の場所に表示されますか？ 他の場所に表示する必要がありますか？



学生：さまざまなサービスのリストにユーザーアクセスが示されている可能性があります。



教授：はい、これは本当に重要なポイントですよね？ Kerberosの目標は、キーを名前に単純にマッピングすることです。 しかし、これはこの名前が何にアクセスするべきかを教えてくれません。



実際、アプリケーションが通常Kerberosを使用する方法は、これらのサーバーの1つがKerberosを使用して、通信している小文字の名前を判別することです。 メールサーバーが何らかのワークステーションから接続を受信すると、Kerberosチケットを受信します。これにより、このユーザーがニコライであることを証明します。 その後、メールサーバーは、このユーザーがアクセスできるものを内部で見つけます。 ファイルサーバーも同様です。



したがって、これらすべてのサーバーの内部には、アクセス制御リスト、グループリスト、または許可を実行するその他の項目があります。 そのため、Kerberosは、あなたが誰と話しているのかを示す認証を提供します。 サービス自体が承認のその部分の実装を担当し、ユーザー名に基づいてアクセスのレベルを決定します。 そこで、ユーザー名が表示される場所を見つけました。 Kerberosがサービスと対話するためにサポートする他の基本的な名前があります。



講義資料によれば、サービスはrcmd.hostnameのようになります。 これらのサービスの1つに名前が必要な理由は、たとえばファイルサーバーに接続するときに相互認証を実行するためです。 これは、この手順では、宛先サーバーが自分自身を見つけるだけでなく、ユーザーまたはワークステーションも見つけて、自分を偽造した偽のファイルサーバーではなく、正しいファイルサーバーと通信していることを確認しますファイル。 おそらく、私は評価付きのファイルを見て、それをレジストラに送信したいのです。 したがって、他のファイルサーバーが適切なサーバーとして機能し、間違った評価ファイルを提供してしまうと、それは非常に悪いことです。



したがって、サービスにも独自の名前が必要であり、ワークステーションは、サービスに接続するときに表示される名前を把握する必要があります。







原則として、あるレベルでは、これはユーザーからのものです。 したがって、たとえば、ssh.fooと入力すると、rcmd.fooなどのKerberosメイン名がこの接続のもう一方の端に表示されることを期待する必要があります。 そして、他の誰かがそこにいる場合、SSHクライアントは切断され、接続させないようにしなければなりません。



これは1つの興味深い質問を提起します。 Kerberosで名前を再利用できるのはいつですか？ たとえば、すべての人がアテナインスティテュートシステムにアカウントを持っています。 卒業すると、MITはデータベースエントリを破棄し、他のユーザーが同じユーザー名を登録できるようにしますか？ それは良いアイデアでしょうか？



学生： Kerberosデータベースだけでなく、サービスにもユーザー名のリストがありますか？



教授：はい、これらの名前は実際にはファイルまたはメールサーバー上のACLのどこかにある文字列エントリによって表されているだけです。 Kerberosサーバーデータベースのエントリを消去しても、エントリが完全に消えたわけではありません。 これらのエントリはバージョンに依存しません。



たとえば、ある記録には、アリスがアテナのロッカーにアクセスできると書かれています。 その後、アリスは卒業し、彼女の記録は削除されますが、一部の新しいアリスは研究所に入り、Kerberosデータベースでの登録プロセスが行われます。 , , .



, Kerberos , Kerberos . , , , .



. , , , , , . , , , - . , . , , .



, . , , , TGS.







, , Kerberos, «». : s , IP – addr, time stump, life, , , Kc,s, . .







.



, Kerberos «». Ac , IP- , , . , . K,s, , Kerberos Ks. , .







, , Kerberos TGS. , , Kerberos, , . : C, , S, TGS. .



Tc,s, Ks, , Ks, , Kc. .







. , Kerberos ? , ?



: , , , Kc.



: , , Kerberos , . : «, , . , , , Kc». , .



, , , Kerberos, Kerberos , . , , - Kerberos, , .

: …



: , , Kerberos, ? , ? , , , , , , , , , .







«», , , , , . , , . . Kerberos, , . , , .



: ? , …



: , . , Kerberos , . , , - , , , . 30 , .



Kerberos 5 : , — . , , , , .



Kerberos 4 , , , . , . , , .



, , , . , . — K,s - ? K,s T,s. K,s?



27:10



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





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



ご滞在いただきありがとうございます。 ? より興味深い資料を見たいですか？ , 30% entry-level , : 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サーバーを使用していますか？