NTPクライアントへの攻撃防ぐ、要求パケットに含めるデータを最小限に

headless曰く、　IETFのNetwork Working GroupがNTPクライアントのフィンガープリンティングや偽の応答パケットを使った攻撃を防ぐため、NTPクライアントからNTPサーバーに送られる要求パケットに含めるデータを最小限にすることを提案している（ドラフト、Register）。

　RFC5905で規定されているNTPパケットは、ヘッダーのフィールドがすべてのモードで共通となっている。サーバーからクライアントへの応答パケット（モード4）などでは正確で信頼性の高い時刻同期を行うために欠かせないが、クライアントからの要求パケット（モード3）では多くのフィールドが不要なのだという。サーバー側の実装でも、こういった要求パケットの不要なフィールドの確認が必須とされたことはないとのこと。

　ドラフトではヘッダー先頭の「leap（LI）」「version（VN）」「mode」を含むオクテットを0x23とし、「xmt（transmit timestamp）」にランダムな値のセットを推奨する。「poll」にセットする値は実際のポーリング間隔または0のいずれかで、「precision」には0x20をセットすることが推奨される。このほかのフィールドについては、0をセットするよう推奨している。

　0をセットすることが推奨されるフィールドのうち、「org（origin timestamp）と「rec（receive timestamp）」は特に情報漏洩の可能性があるものだという。これらのフィールドはそれぞれ、直近のサーバーの応答からxmtと「dst（destination timestamp）」をコピーするよう指定されている。そのため、クライアントが別のネットワークに移動した場合、両方のネットワークを観察すると古いIPアドレスと新しいIPアドレスが同じシステムで使われていることがわかってしまう。「poll」の値がオプションになっているのは、ポーリング間隔を観察することで確認可能なためだとしている。

　xmtのランダム化が推奨される理由としては、クライアントの要求パケットのxmtをサーバー側で応答パケットのorgにセットして確認に使用しているため、実際のタイムスタンプをセットすると偽の応答パケットにだまされる可能性があるからだという。現在もxmtの下位ビットではランダム化が行われているが、これらのビットをランダム化した偽パケットを大量に送ることで攻撃が成立する可能性もある。

　スラドのコメントを読む | セキュリティセクション | セキュリティ | インターネット | デベロッパー | IT

　関連ストーリー：
NTPプロジェクトの資金難、現在も改善せず 2016年11月30日
NTPで新たな脆弱性が発見される、不正な時刻源と同期される可能性 2015年10月26日
「時の翁」が握るNTPの運命 2015年03月15日