単一パッケージ認証#
著者：マイケル・ラッシュ
翻訳者：BlueDog
概要#
単一データパッケージ認証は、ポートノッキングの空白を埋めます。
無数のソフトウェア、プロトコル、およびそれらの複雑な相互依存関係が巨大なシステムを形成しているため、この構造の複雑さは、特定の属性、特にセキュリティを確保することを極めて困難にします。セキュリティを強化するために特別に設計されたソフトウェアでさえ、深い洞察を持つ専門家の厳しい目の下で潜在的な弱点が発見されることがあります。ファイアウォールから SSH プロトコルの実装に至るまで、脆弱性が見つかっています。たとえば、OpenSSH は世界で最もセキュリティを重視する開発者によって開発されていますが、時折リモートで悪用可能な脆弱性を含むことがあります。これは、セキュリティの実現が非常に困難であることを示す重要な事実であり、深層防御アプローチを支持します。本稿では、ポートノッキングを超えた次世代の受動的認証技術としての単一パッケージ認証（SPA）の概念を探ります。
攻撃者がサーバーソフトウェア（クライアントソフトウェアではなく）の脆弱性を利用しようとする場合、最初のステップは偵察であり、攻撃者はターゲットを見つける必要があります。Nmap はこのプロセスの自動化を見事に実現しており、攻撃を受けやすいターゲットシステムのリストを簡単に構築できます。もしあなたが運営しているサーバーソフトウェアにゼロデイ脆弱性が存在する場合、あなたは確実にこのターゲットリストに載りたくないでしょう！ポートノッキング技術と単一パッケージ認証技術は、デフォルトで破棄されるように設定されたパケットフィルターを使用し、受動的メカニズムを通じて自分の身元を証明できる IP アドレスにのみサービスを提供します。この受動的な方法でリモート IP アドレスを検証するために TCP/IP スタックへのアクセスは不要です。この方法で保護されている場合、Nmap はサーバーが稼働しているかどうかを判断することすらできず、攻撃者がゼロデイ脆弱性を持っていても無力です。
本稿は、単一パッケージ認証に関する二部構成のシリーズ記事の第一部であり、単一パッケージ認証の理論的基盤を築き、なぜそれがポートノッキングを超えた次世代の受動的認証技術であるかを説明します。次の章では、fwknop を使用して SSH デーモンに単一パッケージ認証保護を提供する方法についての実践的なガイダンスを提供します。
ポートノッキングの紹介#
ポートノッキングは、TCP および UDP パケットヘッダーのポートフィールドを利用して情報を伝達する初期技術です。通常、これらのプロトコルはアプリケーション層データをカプセル化するために使用されますが、ポートノッキングはポート番号自体をデータフィールドとして使用し、情報を各ポートに送信されるパケットのシーケンスにエンコードします。これらのパケットは通常、ファイアウォールログやパケットキャプチャメカニズム（libpcap など）を通じて監視されます。通常、ポートノッキングクライアントとポートノッキングサーバーがあります。この場合（および本稿の残りの部分では、特に明記されない限り）、クライアントとサーバーという用語は、それぞれデータパケットを送信および監視するソフトウェアコンポーネントを指します。クライアントはポートシーケンスを生成し、サーバーはシーケンスを受動的に受信し、有効なシーケンスを受け取った後にデータパケットフィルターを再構成して保護されたサービスへの接続を許可します。
典型的なポートノッキングシナリオでは、ポートノッキングサーバーがサービス（SSH など）へのすべてのアクセスをブロックするようにデータパケットフィルターを構成し、ポートノッキングクライアントが特定のポートノッキングシーケンスを送信するまで待機します。たとえば、サーバーはクライアントに対して次の順序で次のポートに TCP SYN パケットを送信するよう要求する場合があります：
- 23400
- 1001
- 2003
- 65501
サーバーがこのノッキングシーケンスを監視している場合、データパケットフィルターを再構成して、そのシーケンスを発信した IP アドレスからの SSH 接続を許可します。データパケットフィルターが提供する接続追跡メカニズム（Netfilter の conntrack システムなど）を利用することで、ノッキングサーバーが作成した初期ルールがタイムアウト後に削除されても、SSH セッションは確立状態を維持できます。ポートノッキングシーケンスは暗号化可能で、多くの実装がhttp://www.portknocking.org にリストされています。ポートノッキング操作のグラフィカルな表現については、図 1 を参照してください。
図 1. ポートノッキング操作
ポートノッキングの限界#
ポートノッキングはサービスへのアクセスを効果的に制限できますが、限界はどこにあるのでしょうか？まず、暗号化されたノッキングシーケンスは避けられない情報伝達を伴い、その情報量は暗号化アルゴリズムに依存します。対称暗号化アルゴリズムの場合、暗号化されるデータ量は少なくともブロックサイズに相当します（たとえば、高度な暗号標準で使用される Rijndael 対称ブロック暗号は、ブロックサイズが 128 ビットです）。非対称暗号化アルゴリズムの場合、暗号化されるデータ量はさらに大きくなります。
たとえば、GnuPG で使用される原始 ElGamal アルゴリズムでは、データを暗号化する際に、暗号文の長さは平文の長さの 2 倍になります。GnuPG が圧縮技術を採用している場合（これにより、暗号文の長さが元の平文の長さよりも小さくなることがありますが）、GnuPG キーは通常大きいため、短いメッセージの暗号文でも数百バイトに達することがあります。
ポートノッキングシナリオでは特に重要です。TCP および UDP ヘッダーは 16 ビット幅のポートフィールドしか提供しないため、ポートノッキングシーケンスの各パケットは 2 バイトの情報しか運ぶことができません（パケットヘッダーの他のフィールドがデータを運ぶことに関与しないと仮定した場合、たとえ関与しても、運搬量はデータペイロードよりもはるかに小さいです）。したがって、ブロック暗号の場合、暗号化シーケンスは少なくとも B/(2*8) 個のパケットを含む必要があります。ここで B はブロックサイズ（ビット単位）です。現在のネットワークの一般的な速度と信頼性を考えると、これはそれ自体では恐ろしいことではありませんが、実際の問題は乱序配信です。
乱序配信データは復号を困難にします。ポートノッキングクライアントとサーバーの間には TCP の意味での「接続」概念が存在しないため、サーバーは乱序パケットを再配置することができません。
パケットは異なるルートを通る可能性があり、一部のルートは遅い場合があるため、クライアントは乱序到着の可能性を最小限に抑えるために、時間という人為的なメカニズムに頼る必要があります。ノッキングシーケンスの各パケット間に時間間隔（たとえば、半秒）を導入することで、パケットがサーバーに到達する際に順序が保たれることが通常保証されます。現在、128 ビットのブロックサイズに対して、対応するポートノッキングシーケンスは 128/(2*8)=8 個のパケットです。半秒の遅延を考慮すると、シーケンスを伝送するだけで 4 秒かかります。より大きなメッセージ（たとえば、非対称暗号によって生成されたメッセージ）については、このようなデータ伝送速度は受け入れられません。
データ伝送能力の制限は、ポートノッキングスキームにも別の制限をもたらします。再生攻撃に対して効果的に防御することは困難です。サーバーへのノッキングシーケンスを監視できる者は誰でも、そのシーケンスをサーバーに再生して同じアクセス権を得ることができます。このシーケンスが NAT デバイスを介して伝送され、サーバーのデータパケットフィルタールールが許可する送信元 IP が外部の NAT アドレスである場合、これは特に深刻な問題です。たとえば、ポートノッキングクライアントが RFC 1918 サブネット（たとえば 10.10.1.0/24）にあり、ポートノッキングサーバーがパブリックネットワークを介してのみアクセス可能な遠隔ネットワークにある場合、サーバーは NAT IP からのアクセスを許可する必要があります。したがって、同じサブネット内の誰でもそのシーケンスを再生できれば、同じアクセス権を得ることができます。また、ルールが存在する限り、同じサブネット内の誰でも同じアクセス権を持ち、NAT アドレスからの接続を受け入れるようにルールがインスタンス化されると（この時点でシーケンスの再生は不要であり、SPA も同様です）。
再生問題を解決するために、従来のポートノッキングに対してさまざまな修正が行われてきました。たとえば、時間ウィンドウの導入、S/Key スタイルのハッシュ反復の使用、さらには使用後に単純に暗号化キーを変更することなどです。しかし、これらの方法はすべて、ポートノッキングクライアントとサーバーが何らかの状態を維持する必要があり、複数のユーザーが関与する場合、そのスケーラビリティはあまり良くありません。
ポートノッキングのもう一つの制限は、悪意のある第三者がクライアントがラインを介して送信したポートシーケンスを偽装した追加のパケットを送信するだけで、ノッキングシーケンスを簡単に破壊できることです。攻撃者は、データパケットの送信元アドレスを実際のクライアントの送信元アドレスと同じに設定し、クライアントが送信した最後のデータパケットと同じポート番号を選択するだけです。この追加のパケットはノッキングシーケンスを破壊するため、サーバーは正当なクライアントによる他のアクセスを許可しません。実際にこの操作を行う可能性は比較的小さいですが（彼らは依然としてクライアントから発信されたデータパケットを監視できる必要があります）、主な問題はこのような攻撃が非常に簡単に実行できることです。たった 1 つのデータパケットで、攻撃者は元のデータパケットのデータパスと同じリンク上にいる必要すらありません。
最後に、クライアントとサーバー間のトラフィックを監視できる侵入検知システム（IDS）は、ノッキングシーケンスをポートスキャンとして簡単に検出できます。特に暗号化されたノッキングシーケンスは、単純な共有シーケンスよりも長くなることが多いです。IDS にとって、ポートノッキングは、単一の IP アドレスから比較的短時間でさまざまなポートに対して一連の探査を行うように見え、ポートスキャンの定義に非常に合致します。
単一パッケージ認証#
以上のように、ポートノッキングはセキュリティを強化する多くの利点を提供しますが、解決すべき深刻な限界も存在します。単一パッケージ認証は比較的新しいプロトコルであり、ポートノッキングのすべての利点を保持しつつ、上記の限界を修正します。最初の公開可能な SPA 実装は 2005 年 5 月にリリースされ、fwknop（http://www.cipherdyne.org/fwknop）というソフトウェアの一部として提供されました。2004 年に最初に作成された fwknop は、受動的オペレーティングシステムフィンガープリンティングとポートノッキングを組み合わせた最初のポートノッキング実装であり（これにより「Linux-2.4 システムからのノッキングシーケンスのみを受け入れる」といった操作が可能になります）、しかし SPA メソッドは現在 fwknop が提供する最も人気のある（そしてデフォルトの）認証方法です。fwknop は認証と承認サービスを提供しますが、本稿の範囲には両者の違いに関する包括的な議論は含まれていません。
単一パッケージ認証は、ポートノッキングと類似のアーキテクチャを要求します。両者にはクライアントとサーバーコンポーネントがあり、サーバーはデフォルトで破棄されるデータパケットのフィルターを制御し、サーバーはデータパケットを受動的に監視します。しかし、ポートノッキングと SPA のアーキテクチャの類似性はここに限られています。
単一パッケージ認証はデータ伝送をその所属する位置、すなわちアプリケーション層に移動させます。これにより、SPA は各パケットに最大最小 MTU 値（イーサネットネットワーク上の 1500 バイト）のデータを送信できるようになり、ポートノッキングは各パケットに 2 バイトのデータしか送信できません。これはポートノッキングが可能なデータ伝送速度をはるかに超え、これほど多くのデータパケットデータに簡単にアクセスできるようにし、巨大な可能性を開きます。本稿の残りの部分では、fwknop による単一パッケージ認証の実装について議論します。
fwknop はアプリケーション層で以下のデータパケットフォーマットを定義しています：
- 16 バイトのランダムデータ
- クライアントユーザー名
- クライアントタイムスタンプ
- fwknop バージョン
- モード（アクセスモード / コマンドモード）
- アクセス（またはコマンド文字列）
- MD5 チェックサム
SPA データパケットフォーマットの多くのフィールドの長さは可変ですが、「：」文字で区切られています（フィールドは base64 エンコードされているため、埋め込まれたコロンはこの構文を破壊しません）。fwknop クライアントは上記のデータパケットフォーマットを構築した後、全体のデータパケットを 2 つの暗号化アルゴリズムのいずれかを使用して暗号化します：128 ビットの共有鍵を持つ Rijndael 対称ブロック暗号または GnuPG によって生成された最大 2048 ビットの公開鍵 / 秘密鍵ペアを使用する非対称 ElGamal アルゴリズム。fwknop クライアントはデフォルトで UDP ポート 62201 を介して SPA データパケットを送信しますが、これはコマンドラインで簡単に変更できます。--Server-port パラメータを参照してください。（fwknop は多くの構成オプションを提供しています。リソースを参照して、ドキュメントやマニュアルページへのリンクを取得してください。）SPA 操作のグラフィカルな表現については、図 2 を参照してください。
図 2. SPA 操作
16 バイトのランダムデータは、ポート衝突における最優先の制限の 1 つ、すなわち再生問題を解決します。各 SPA データパケットは暗号化前に 16 バイトのランダムデータを追加し、fwknop サーバーは解読後に全データパケットの MD5 チェックサムをキャッシュします。ランダムデータにより、各 SPA データパケットは異なるものとなり（同じアクセス指令を送信しても）、したがって各データパケットの MD5 チェックサムも異なります。新しいデータパケットの MD5 チェックサムが以前のデータパケットと一致する場合、fwknop サーバーは何の操作も行わず、syslog に警告メッセージを書き込みます。したがって、第三者に傍受された SPA データパケットは、デフォルトで破棄されるデータパケットのフィルターを回避するためにネットワーク上で再生することはできません。
fwknop はクライアントユーザー名とタイムスタンプをデータパケットに入れ、fwknop サーバーはユーザー名を使用してリモートユーザーに異なる承認レベルを維持します。fwknop はマルチユーザーシステムにインストールでき、各ユーザーはリモート fwknop サーバーを介して異なるサービスに接続するための承認を受けることができます。fwknop バージョンフィールドは後方互換性を維持するために使用されます。新しいバージョンではフィールドを追加または削除できますが、バージョン番号を使用することで、fwknop サーバーは古いクライアントが SPA データパケットを構築する方法と互換性を持つことができます。モードフィールドは fwknop サーバーに、クライアントがサービスにアクセスするのか、コマンドを実行するのかを伝えます（次のフィールドは特定のアクセス制御指令またはコマンドを使用します）。たとえば、TCP ポート 22 にアクセスするには、アクセスフィールドに文字列 tcp/22 が含まれ、<IP アドレス> はクライアントがデータパケットに挿入する任意の IP アドレスです。最後に、MD5 チェックサムフィールドには、クライアントが送信前に暗号化していないデータパケットの MD5 チェックサムが含まれています。サーバーは解読後にこのフィールドを使用してメッセージの完全性を検証します。
SPA データパケットは、再生問題とポートノッキングスキームにおける極めて低いデータ伝送速度を解決するために、より多くのデータを伝送します。ポートノッキングにおける他の 2 つの制限も解決できます。まず、SPA プロトコルの単一パッケージ特性により、悪意のある第三者は、監視されている SPA データパケットが送信されるのと同じポートにデータパケットを偽装するだけでは認証スキームを破壊できません。最後に、SPA プロトコルは 1 つのデータパケットのみを必要とするため、任意の中間 IDS にとって、ポートスキャンのようには見えません。任意の IDS は、ある IP アドレスにランダムに送信されたように見える意味のないデータブロックを 1 つしか見ることができません。
結論#
単一パッケージ認証は、デフォルトで破棄されるポリシーで構成されたデータパケットフィルターを使用するサービスを保護する上で、ポートノッキングに類似したセキュリティ上の利点を提供します。この方法で保護されたターゲットサービスをスキャンする者は、これらのサービスがリスニングしていることを検出できず、ゼロデイ脆弱性を利用することもさらに困難になります。SPA はポートノッキングの実装における多くの制限に対する巧妙な解決策を提供します。これらの解決策により、SPA は再生問題を解決し、非対称暗号を使用するデータ伝送速度をサポートし、単純な欺瞞攻撃を挫折させ、ネットワークポートスキャンを監視する侵入検知システムの偵察を回避することができます。
来月の LJ を参照して、この記事の第二部では SPA の使用方法について詳しく説明します。
参考文献#
- Krzywinski, M. 2003.「ポートノッキング：閉じたポートを越えたネットワーク認証」。SysAdmin Magazine 12：12-17
- ElGamal 暗号：http://en.wikipedia.org/wiki/ElGamal_encryption
- 本稿執筆時に知っている他の SPA 実装は 1 つだけで、http://www.unspecific.com/spa から入手可能です
- Tumbler（http://tumbler.sourceforge.net）という別の実装は単一パッケージを使用していますが、暗号化ペイロードではなくハッシュペイロードを使用しており、全く異なるアーキテクチャをもたらします
- fwknop のドキュメントとマニュアルページ：http://www.cipherdyne.org/fwknop/docs