10/31/2018

携帯電話のセキュリティと国の指導者

シュナイアーのブログより

今週初め、ニューヨーク・タイムズは、ロシアと中国がドナルド・トランプ大統領の携帯電話を盗聴し、彼の態度に望ましい影響力を与えるために、集められた情報を使っていると報じた。これは誰も驚かないだろう。セキュリティ専門家は、大統領に就任して以来、トランプの携帯電話の利用における潜在的なセキュリティの脆弱性について話している。そして、バラク・オバマ大統領は、彼の大統領職を通じて「通常の」携帯電話を使用することを禁ずる安全保障規定苛立ったが、仕方なく従っていた。

3つのより広範な問題が明らかにこのストーリーから現れる。トランプの携帯電話で誰が聞いているのか? 世界の他の指導者や政府高官の携帯電話はどうだろうか? そして、最も個人的な、私の携帯電話はどうだろうか?

まさに通信システムを盗聴するには、2つの基本的な場所がある。それはエンドポイントと送信中である。つまり、携帯電話の攻撃者は、2つの電話のうちの1つをセキュリティ侵害する、あるいは携帯電話網を盗聴したりする可能性がある。2つの方法には利点と欠点がある。NSAは、地球の主要な通信リンクを大量に盗聴する方を選んで、そこから興味のある個人を選び出しているようだ。2016年、ウィキリークスは、「標的と選ばれた人たち」を列挙した一連の機密文書を公表した。NSAが検索し記録する電話番号である。これらには、アンジェラ・メルケル首相を含むドイツの政府高官、フランス日本およびその他の国々が含まれる。

他の国々は、NSAが持っているような世界的な広がりを持っておらず、他の方法を使って携帯電話を傍受しなければならない。私たちはどの国が何をしているのか分からないが、脆弱性については多くを知っている。電話網そのものの不安は、簡単に悪用され、60 Minutesが2016年に米下院議員への電話の盗聴が生放送で放映された。2005年には、未知の攻撃者が、国の電話網をハッキングし、既にインストールされた盗聴機能をオンにして、ギリシャの多くの政治家の携帯電話をターゲットにしていた。NSAは、シリアの電話会社向けのネットワーク機器に盗聴機能を埋め込んでいた

あるいは、攻撃者が携帯電話と基地局の間の無線信号を傍受する可能性がある。暗号化の範囲は、システムが使用する特色に応じて、非常に弱いものから強いものまで様々である。攻撃者が、盗聴アンテナをホワイトハウスの芝生に置く必要があるとは思ってはいけない。ロシア大使館は十分に近い。

携帯電話を盗聴するもう1つの方法は、電話機自体をハッキングすることだ。これは、あまり洗練された情報収拾能力を持たない国々が好む技術である。2017年に公益フォレンジックス・グループのCitizen Labは、メキシコの弁護士ジャーナリスト野党の政治家に対する(おそらく政府が運営する)広範な盗聴活動を明らかにした。ちょうど先月、同グループは、アルジェリア、バングラデシュ、ギリシャ、インド、カザフスタン、ラトビア、南アフリカなど45カ国で活動しているイスラエルのサイバー兵器メーカーNSOグループの製品に盗聴機能を発見した。

これらの攻撃には、通常、マルウェアをスマートフォンにダウンロードしてから、通話、テキストメッセージ、およびその他のユーザーの活動を記録し、それらをいくつかの中央制御装置に転送する。ここでは、どの携帯電話が対象となっているかが重要である。iPhoneはハッキングするのが難しい。これは、企業が新しいエクスプロイトの可能性に支払う価格に反映されている。2016年に、脆弱性ブローカーZerodiumは、未知のIOS脆弱性に対して150万ドルで提供し、同様のAndroidのエクスプロイトはわずか200ドルで提供した。今年初めに、ドバイの新しい新興企業がさらに高い価格を発表した。これらの脆弱性は、政府やサイバー兵器の製造元に再販されている。

価格の違いのいくつかは、2つのオペレーティング・システムが設計され、使用されている方法によるものである。AppleはiPhoneのソフトウェアを、Android携帯のGoogleよりもはるかにコントロールしている。また、Androidの携帯電話は一般に、サードパーティによって設計、構築、販売されているため、タイムリーにセキュリティ・アップデートを得る可能性は非常に低い。これは変化している。Googleは現在、セキュリティ・アップデートを迅速かつ定期的に取得する独自の携帯電話「Pixel」を所有しており、Android携帯電話メーカーに電話をより定期的にアップデートするよう圧力をかけている。(トランプ大統領はiPhoneを使用していると伝えられている)

携帯電話をハッキングするもう1つの方法は、設計プロセス中にバックドアをインストールすることである。これは本当の恐怖である。今年の初め、米国の情報当局は、ZTEとHuaweiが作成した携帯電話が中国政府によってセキュリティ侵害を受ける可能性があると警告し、ペンタゴンは軍事基地の店舗に販売を停止するよう命じた。これが、トランプがセキュリティを求めていた場合、彼がHuaweiの携帯電話を使うべきであるという中国のアドバイスは、少しおかしなトローリングだった理由である。

大量の不安点と数々の盗聴技術があることから、多くの国で外国の公務員と自国市民の電話を盗聴していると言っても過言ではない。これらのテクニックの多くは、犯罪グループ、テロリスト団体、およびハッカーの能力の範囲内にある。私が推測していたのであれば、中国やロシアのような主要な国際的な大国は、よりパッシブな傍受技術を使ってトランプをスパイしているが、小国は彼の電話機にマルウェアを埋め込もうとする勇気はないと言いたい。

トランプ大統領が唯一のターゲットではないと言っても間違いでは無い。国会議員、裁判官、その他の高官で、特に、誰も携帯電話の使用をやめるように指示しようとしている人はいない(ただし、携帯電話はまだ議会や議事堂では許可されていない)。

私たち残りの部分に関しては、それはどのくらい関心があるかによって決まる。株式市場で優位を得るためにCEOの電話を盗んだ犯罪グループ、あるいは貿易交渉で優位に立つために同じことをしている国を想像するのは簡単だ。私たちは、政府がこれらのツールを反体制の活動家、記者、その他の政敵に対して使用していることを見てきた。中国ロシア政府はすでに米国の電力網を対象としている。その電力網の担当者の電話機をターゲットにすることには意味がある。

残念ながら、あなたの携帯電話のセキュリティを向上させる方法はあまり無い。ウイルス対策ソフトウェア、ネットワーク・ファイアウォールなどを購入できるコンピュータ・ネットワークとは異なり、あなたの携帯電話は主に他のユーザーによってコントロールされている。携帯電話を作る会社、携帯電話サービスを提供する会社、そして問題にはなっていなかった時に開発された通信プロトコルのなすがままである。これらの企業の1つがセキュリティにこだわりを持たなければ、あなたは脆弱である。

これが、通信の盗聴とデバイスのロックを解除する機能を望んでいるFBIと、セキュリティ保護されたデバイスを必要とする反対側のユーザーにとって、携帯電話のプライバシーに関する現在の議論が非常に重要な理由である。そう、犯罪を解決するためにこの情報を利用できるFBIにはセキュリティ上の利点はあるが、携帯電話やネットワークの安全性が高まり、FBIを含むすべての潜在的な盗聴者がアクセスできないという遥かに大きなメリットがある。私たちは法執行機関に他のフォレンジック・ツールを与えることはできるが、外国の政府、犯罪グループ、テロリスト、そして他人から、皆の電話機を守る必要がある。大統領は、安全ではない電話機を愛することで非難を抱えているかもしれないが、私たち一人一人がまさに安全でない電話機を使用している。そして驚くほどたくさんの人たちのために、彼らの携帯電話をよりプライベートにすることは、国家の安全保障上の問題である。

このエッセイのオリジナルは、Atlanticに掲載された

追記: スティーブン・ベロヴィンとスーザン・ランダウは、Wiredのように、同じ話題の素晴らしいエッセイを書いている。Slashdotの投稿

10/30/2018

Supermicroのスパイ記事に関して

シュナイアーのブログより。

私はブルームバーグの記事について、中国が米国向けのSupermicroネットワーキング機器を盗聴していることについて2度ブログに書いた。私はまだ、この話が真実であるかどうか分からないが、浮かび上がる証拠を裏付け不足のせいで、ますます懐疑的になっている。

私たちは何も知らないが、これは私が読んだ記事の最も総合的な反証である。

10/29/2018

IBMがRed Hatを340億ドルで買収

Slashdotより

International Business Machines(IBM)は、ソフトウェアメーカーRed Hatを340億ドル(3兆8000億円)で買収すると日曜日に発表した。レポートより:
日曜日の午後に発表されたこの買収は、急速に成長しているインターネット・スタイルのクラウド・コンピューティング市場の競争力を獲得するための巨大ビジネス・ソフトウェア会社間の最新の競争の激しいステップである。6月、Microsoftはソフトウェア開発者のための重要なコード共有プラットフォームGitHubを75億ドルで買収した。IBMは、Red Hatの買収により、ソフトウェア開発者がリモート・データ・センター上で動作するアプリケーションを作成するというコンピュータ・クラウド上のソフトウェア開発を開拓する動きであると語った。
プレスリリースより:

今回の買収により、クラス最高のハイブリッド・クラウド・プロバイダーが集まり、企業は全てのビジネス・アプリケーションをクラウドに確実に移行できます。今日の企業はすでに複数のクラウドを使用しています。しかし、調査によれば、今日のクラウド市場のプロプライアタリな性質により、ビジネス・ワークロードの80%はまだクラウドに移行していません。これにより、複数のクラウドに渡るデータやアプリケーションの移植性、マルチクラウド環境でのデータセキュリティ、一貫したクラウド管理が妨げられています。

IBMとRed Hatは、この問題に対処し、ハイブリッド・マルチ・クラウドの採用を加速する立場にあります。クラウド・ネイティブのビジネス・アプリケーションを迅速に作成し、複数のパブリック・クラウドやプライベート・クラウドにまたがるデータやアプリケーションの移植性とセキュリティを一貫したクラウド管理で実現するのに役立ちます。そうすることで、Linux、コンテナ、Kubernetes、マルチクラウド管理、クラウド管理と自動化などの主要技術における共通のリーダーシップを活用します。IBMとRed Hatのパートナーシップは20年に渡り、IBMはLinuxの初期からの支持者として、Red Hatと協力してエンタープライズ・クラスのLinuxの開発と成長を支援し、最近では企業向けKubernetesとハイブリッド・クラウド・ソリューションを顧客に提供しています。これらのイノベーションは、IBMの190億ドルのハイブリッド・クラウド事業の中核技術となっています。それらの間で、IBMとRed Hatは他のどの組織よりもオープンソース・コミュニティに貢献しています。

Hacker News

10/26/2018

Androidの広告詐欺スキーム

シュナイアーのブログより。

BuzzFeedは、詐欺師が正規のAndroidアプリを購入し、ボット検出器を回避できるよう、それを真似るためユーザの行動を追跡し、その後、アドフラウド(広告詐欺)・プログラムを永続させるためにボットを使用するというスキームを報告している

このスキームとつながりのあるアプリやウェブサイトのリストが提供された後、Googleが調査して、数多くのアプリがモバイル広告ネットワークを使っていることを発見した。その独立した分析は、このスキームの中のウェブサイトやアプリへのトラフィックを引き起こすボットネットの存在を確認した。GoogleはPlayストアから30以上のアプリを削除し、広告ネットワークで複数のサイト運営者アカウントを終了した。Googleは、BuzzFeed Newsに連絡する前に、これまでこのスキームで10のアプリを削除し、多くのウェブサイトをブロックしていたと語った。調査を続けており、その結果を詳細に記したブログ記事が掲載している

同社は、影響を受けたウェブサイトやアプリへ広告を掲載するためにGoogleの広告ネットワークを使用した広告主から1000万ドル近くを盗み出されたと推定している。これらのアプリやウェブサイトに置かれている大部分の広告は、他の主要な広告ネットワークを介して来たと述べた。

BuzzFeedとGoogleの両方のリンクに多くの詳細がある。

インターネット広告業界はあらゆるレベルで詐欺がはびこっている。これは、数多くある詐欺の一つにすぎない。

中国、ロシアはトランプの電話を盗聴している

Slashdotより。FBI、CIA、DHSも聞いているだろう... それにしても、無知による安全保障とは。

Rick Zemanが伝える:
ニューヨーク・タイムズによると、中国は定期的にドナルド・トランプの携帯電話を聴いている(警告: 情報源は有料、別のソース)。彼は2台のNSAが強化したiPhone、そして安全な固定電話を持っているが、彼は盗聴されている事を知りながらも、連絡先リストがあるので、民生用のiPhoneを使用することを強く望んでいる。「ホワイトハウスの関係者は、彼が使う際に機密情報の議論を控えることを希望していると言う。」とニューヨーク・タイムズは報じている。しかし、当局者は、「彼が、諜報活動の詳細を掘り起こすことはめったになく、軍事活動や秘密活動の運用上の詳細に精通していないため、秘密を漏らしていない」事も確信していた。言い換えれば、無知による安全保障である。 記事は、何が誰に影響を与えているのかを調べるために彼の電話を聴くことができるという論理的根拠と、ロシアは、ウラジミール・プーチンとの彼独自の関係のため頻度は低いものの、聞いていると言及している。

TechCrunch

10/24/2018

マイクロプラスチックが初めて人間の便から見付かる (サンプルの8人全員から)

Slashdotより

匿名の読者がニューヨーク・タイムズのレポートを引用する:

研究者は、サンプルサイズが小さいパイロット試験で、フィンランド、イタリア、日本、オランダ、ポーランド、ロシア、英国、オーストリアの8人の糞便サンプルでマイクロプラスチックを探しました。驚くべきことに、全てのサンプルが、様々なマイクロプラスチックの存在について陽性であった(警告: 情報源は有料であり、代替ソース)。

ウィーンで開催された消化器病学会で発表されたこの新しい論文は、海洋のマイクロプラスチックがもたらす危険性について長い間警告してきた海洋生物学者に支援を提供する可能性がある。しかし、この論文は、マイクロプラスチックが他の手段でも私たちの体に入っていることを示唆している。調査を実施するために、彼らは1週間にわたり食べ物の日記を保管し、便のサンプルを提供した各国のボランティアを選出した。この研究を主導したウィーン大学医学部のPhilipp Schwabl博士と彼の同僚は、このサンプルを分光器で分析した。最大9種類のプラスチックが検出され、サイズは0.002〜0.02インチの範囲であった。検出された最も一般的なプラスチックは、ポリプロピレンおよびポリエチレン・テレフタレートであり、ペットボトルおよびキャップの主成分であった。

中国によるBGPのハッキング

シュナイアーのブログより。既知の事だが...

これは、中国が繰り返し行っていたインターネットのボーダー・ゲートウェイ・プロトコル(BGP)のハッキングに関するChris C. DemchakとYuval Shavittの長い、そしてやや技術的な論文である:「中国の格言 - エクスプロイトされないアクセスポイントを残さない: チャイナ・テレコムのBGPハッキングの秘密のストーリー

BGPハッキングは、大規模な情報機関が特定のトラフィックを傍受しやすくするためにインターネット・ルーティングを操る方法である。NSAはそれを「ネットワーク・シェーピング」または「トラフィック・シェーピング」と呼ぶ。スノーデンのアーカイブには、そのテクニックとイエメンとの関係を概説した文書がある

Slashdot

ユニカーネル: もはや学問的訓練ではない

250bpmより

はじめに

私はユニカーネルの領域を何年もフォローしてきましたし、このアイデアが本当に気に入っていました。しかし、私はこの技術の幅広い採用の可能性について確信できませんでした。

コストはあまりにも高かったためです。それはあなたが知っていた全てを忘れさせ、作業中の全ての既存のコードを削除し、全てのアプリケーションとツールを書き直し、改めて開始する必要がありました。(私は誇張していますが、それほどではありません)。マイクロカーネルが作ったことがないなら、ユニカーネルはどう転ぶか分かりません。

利点が何であれ、コストは法外なものでした。

プロセスとしてのユニカーネル

Koller、Lucina、Prakash、Williamsの最近の「Unikernels as Processes」の論文(無料ダウンロード)は、その状況を変えています。これは、古き良き退屈なOSプロセスとしてユニカーネルを実行することを提案しています。この考え方は、現在カーネル内にあるスタックのほとんどが、アプリケーションに直接リンクされたライブラリにあるということです。ユーザ/カーネルの境界を越える呼び出しはごくわずかです。

Unikernel2

ワンクリック・セキュリティ

POSIX APIを実装しているライブラリが利用可能であると仮定すると、それらは既存のアプリケーションを取り込み、ユニカーネルとして再コンパイルできる筈です(例: rumpkernel参照)。アプリケーションは以前と同じように動作しますが、ほんの少数のシステムコールしか使用しません。

一方では、これらの機能の外にあるカーネルの脆弱性はアプリケーションに影響を与えません。

他方、TCPやファイルシステムの実装における脆弱性は、アプリケーションを危険に晒しますが、問題は、OSプロセス(アドレス空間などの違い)間の分離によって同時に食い止められます。結果として、同じマシン上で実行されている他のアプリケーションを危険に晒すこともありません。

さて、経済的な観点から考えてみましょう。

ベンダーは最終的にセキュリティを真剣に受けなければなりません。しかし、彼らが直面している全ての選択肢はむしろ受け入れ難いものです。

彼らは現状維持し、誰もそれらをハッキングする気にならないように祈ることです。

あるいは、スタック全体のセキュリティ監査によって、セキュリティの欠陥を修正し、レガシーコードの大部分を書き換える必要があります。それは非常にコストが掛かります。たとえあったとしても、ほんのわずかの企業しか、その余裕ができません。

Unikernels-as-processesモデルは万能薬ではなく、SQLインジェクションの脆弱性を修正するものではありませんが、非常に危険なセキュリティ欠陥の広範な分類に対応しています(見積もりについては、この論文などを参照して下さい)。

さらに重要なのは、一度クリックするだけのソリューションだということです! ゼロコストに近い形でセキュリティを向上させます。

同様に、ビジネス関係者をこの不快な行き詰まった状況から簡単に脱する方法を提供します。

上記に基づいて、私の推測では、その技術が一度ワンクリック体験を提供すると、素早く広範な採用に直面するだろうということです。

移植性

ワンクリック・セキュリティと比較して、移植性はほんのわずかなセールスポイントです。それにしても:

現時点では、POSIX準拠のOS間でもアプリケーションを移植するのは簡単ではありませんが、Windowsへの移植は単純で簡単です。

Unikernels-as-processesモデルは、OSとアプリケーションの間に1桁の数の関数で構成されるインタフェースを持っています。これらの機能が利用できるようになり、全てのメインストリームOSで同じように機能すると、あるOSに書かれたアプリケーションは、別のOSで動作させるだけです。(そして、ハイパーバイザーやベアメタルの下で直接実行する可能性について、私が言うに及びません)。

ツールの保持

ユニカーネルの採用を妨げていたことの1つは、既存のツールとプロセスを壊したことでした。

典型的な質問: アプリケーションをユニカーネルとして実行する場合、どのようにデバッグするのですか?

デバッガは最初に気になるツールですが、アプリケーションが標準の実行ファイルであり、標準のOSプロセスとして実行されていることを前提とするツールには、同じ問題が適用されます。これにより、ほとんどのビルドとデプロイメント・ツール・チェーンが壊れる可能性があります。それは、コントロール・インタフェース、監視機能、誰も気付いていないものを壊す可能性があります。

Unikernels-as-processesでは、もはや問題にはなりません。アプリケーションは標準の実行可能ファイルです。そして、標準のOSプロセスとして実行されます。ツールとプロセスのわずかな変更が必要なだけです。

実際、スイッチがツールを改善することさえできます。アプリケーションのデバッグを検討して下さい。現在、カーネル境界で停止します。例えば、TCPプロトコルの実装に入る方法はありません。一方、TCP実装がアプリケーションにリンクされたライブラリであれば、その中にステップインし、ブレークポイントを配置し、必要な処理を行います。

次の生産性ブーム

オープンソースのインフラが広く採用された時、私たちは生産性ブームを経験しました。商用ベンダーがあなたが望む機能を実装するまで何年も待たずに、あなたのニーズに合った無料のソリューションをすぐに選択することができます。そして、壊れた物や欠けている物を自分で修正することができます。

しかし、私たちは、オペレーティング・システムの領域でこの革命の冷めたバージョンしか見ていません。

もちろん、Linuxカーネルをフォークして必要な機能を実装することができます。しかし、あなたは自分自身でフォークを維持するか、メインライン・カーネルへの変更をアップするというジレンマに直面しています。

前者の場合、あなたはフォークを永遠に維持する運命にあります。それは面倒でコストが掛かります。更に、アプリケーションのユーザーにオペレーティング・システムのフォークを実行するように依頼する必要があります。それは彼らを幸せにはしません。彼らはあなたが次の年には破綻し、次の10年間カーネルのカスタムフォークを維持しなければならないと想像しています。彼らは静かに元に戻るでしょう。

一方、あなたは変更をアップする選択をした場合、あなたはパッチを取り込むためにリーナス・トーバルズと戦わなければならないでしょう。彼がそれを気に入らなければ、あなたは運が悪く、前の選択肢に戻ります。パッチを手に入れることができても、すべての人が自分のOSをアップデートして自分の機能を追加するまでには数年かかるでしょう。RHEL 5を実行している顧客に2007年のカーネルがありますか? おっと! うまくいきません! あなたは製品化に10年で掛かり、そして、ほぼすべての事業計画をダメにすることが保証されます。

unikernels-as-processesでは、この問題は解消されます。

あなたはIPプロトコルの実装を微調整したいですか? 確かに。GitHub上の既存のIPライブラリを探し、必要に応じてパッチを適用し、アプリケーションにリンクします。完了。誰でも自作のOSで実行できます。

Hacker News

ストールマン、「GNU思いやりのあるコミュニケーション指針」を発表

Slashdotより

AmiMoJoが伝える:

リチャード・ストールマンは、「人々を思いやりのあるコミュニケーションに導くための取り組み」というGNU思いやりのあるコミュニケーション指針(GNU Kind Communication Guidelines)を発表しました。指針は、フリーソフトウェア開発にまつわる思いやりについて、それらを破った際に可能な行動を持つルールがあることに積極的に取り組んでいる点で、行動規範(Code of Conduct)とは異なります。

これらの新しいGNUコミュニケーション指針は、

GNU.org
ストールマンの解説と共に見つけることができます。

指針より:
行動規範は、ルールに違反している人に罰則を課します。それは人々に違った行動を教える荒っぽい方法です、そして、それは人々が規則に反して何かを行うときにのみ使用されるので、規則が要求するよりもうまくやるように人々に教えようとはしません。GNUパッケージの任命されたメンテナーは、必要に応じてコントリビュータに退去するよう指示することができます。しかし、私たちはそれを頼みにする必要はありません。GNU思いやりのあるコミュニケーション指針のアイデアは、「あなたはルールを破っている」と思う前に、思いやりのあるコミュニケーションに向けて人々を誘導することです。 人を思いやりを持つように指示するのではなく、私たちがこれを行う方法は、人々がコミュニケーションでより思いやりを持つことを学ぶのを助けることです。私は、思いやりのあるコミュニケーション指針が、プロジェクトの議論をより穏やかに、善意の全ての参加者をもっと歓迎し、より効果的に導く思いやりと厳密さを抑えた方法を提供することを願っています。

スラド

10/23/2018

第29回OARC会議より

ジェフ・ヒューストンのブログ『Diving into the DNS』より。

Geoff Huston

DNS OARCは年に2回の会議を開催します。これらは、DNSエソテリカの濃度の高い量の2日間の会議です。2018年10月中旬にアムステルダムで開催された第29回OARCの会議で取り上げたものが以下にあります。

Cloudflareの1.1.1.1サービス

Cloudflareは、1.1.1.1でオープンなパブリックDNSリゾルバ・サービスを6ヶ月以上続けています。Knotリゾルバエンジンをベースにしたサービスは確かに高速で、Cloudflareの規模とスピードへの関心は、おそらくユーザによってこのサービスは評価されています。しかし、現在では、より幅広いインターネット環境で、個人のプライバシーを非常に意識するようになり、迅速かつ正確なだけでは不十分です。パブリックなDNS解決サービスのオペレーターとして、顧客の活動や興味を知っている可能性があることを明確にする必要があり、プライバシーに注意を払っていることを明確に示す必要があります。これには、リゾルバのクエリの流れのログを処理および廃棄する方法に関する適切な取り組みが含まれるだけでなく、ユーザーがクエリをサービスに渡す方法に留意する必要もあります。

1.1.1.1サービスは、GnuTLSシステムを使用して、TLS 1.3および1.2でDNSをサポートします。これにより、クライアント・システムとの長期接続がサポートされ、セッションの再開もサポートされます。kdigGetDNSUnbound、Android P、Tentaブラウザなど、TLS接続でDNSを使用できるDNSツールがいくつかあります。

1.1.1.1サービスのDNS over HTTPSのサポートは、NGINXフロントエンドを使用して実装されており、HTTPS接続を終了し、DNSペイロードをリゾルバ・エンジンのLUAモジュールに転送します。DNS over HTTPSサービスのIETFのDOHワイヤフォーマットやDNSのペイロードとしてJSONエンコードをサポートしています。Firefoxは最近、DOH(https://mzl.la/2NGnQ0s)を使用するTrusted Recursive Resolverオプションを発表し、Chromeもこれに取り組んでいます。

長年の間、TCPよりも効率的なトランスポートプロトコルであるUDPが、一般的なDNSフォークロアでした。

これらの大規模なパブリックDNSリゾルバの経験は、ここではトレードオフがあり、多数のDNSトランザクションでセッション状態を開いている事により、セッションコストを多くのトランザクションに渡って償却することができ、再送やミドルボックスの介入を引き起こす大きな応答の問題を回避します。これは、クライアントが再帰リゾルバにクエリを送信している状況と、再帰リゾルバが信頼できるサーバにクエリを送信している状況の両方に適用されます。TCP負荷がUDP負荷と同等であることを意味するものではありませんが、サーバコストの差を通信チャネルの強化された整合性と均衡させることができます。

全般的に、DNSのトランスポート・プロトコルを見ると、全てのオプションが妥協です。UDPは、大きな応答、タイムアウト、オープンペイロード、および通信中の介入のの可能性のためのフラグメンテーション処理に問題があります。これは、効率的で、非常に高速になる可能性もあります。DNS over TCPのポート53は、特にミドルウェアに問題があります。APNIC Labsが少し前に測定したところ、リゾルバの約17%がTCPを使用して権威サーバーにクエリを実行できず、これがユーザーの約6%に影響を与えていることが分かりました。パケットにTCPポート53を使用することを望まないミドルウェアがたくさんあるようです。また、TCPにはサーバー側でセッション状態が保持する必要があります。これにより、TCPトランスポートを使用すると、サーバーの最大持続的クエリ率が低下します。

DNS over TLSはどうか? 私たちがIETF指定のポート853を使用すると、ミドルウェアの介入の見通しは同様に妨げるように見えます。識別されたポートは、ミドルウェアのフィルタリングの格好の的です。また、TCPポート53とTCPポート853の両方、ミドルウェア操作を可能にする無防備のTCP制御プロトコルに悩まされています(皮肉屋はさらに踏み込んで、「招待」と言います)。 TCPはまた、行頭ブロッキングに悩まされ、複数の内部照会チャネルをサポートする努力を邪魔する可能性があります。

このような状況を改善したい場合は、TCP制御プロトコルを目立たなくする必要があります。これは、おそらくDNS over QUICを検討することを意味します。QUICはネットワークからのセッション制御プロトコルを覆い隠し、さらに内部の複数のフロースレッドが行頭ブロックを回避できますが、ポート443を使用してUDPパケットを許可するミドルウェアの許容範囲を超える問題は解決しません。残念ながら、私たちは確信を持ってDNS over QUICによるミドルウェアの被害をある程度予測できます。

何が残っているか?

私たちは、Webが既に行っていることならできます。

それは、DNS over port TCP 443、あるいはDOHです。

Cloudflareは、1.1.1.1オープンリゾルバ・サービス向けにDNS over TLSとDNS over HTTPSのサポートを導入しました。しかし、それは最も多くの批判を集めているDNS over HTTPS (DOH)です。

ヒステリーになる

間違いなく、DOHの話題は、DNS分野での様々な強い興味を刺激しています。

DNSトランザクションがポート443のTCPストリームに暗号化されて埋め込まれると、目に見えるDNSの多くがテーブルから取り除かれます。それは、どれくらい大きな問題ですか?

現在のDNS解決のモデルは、より広い範囲の傍観者から見てもかなり明らかです。上流のサービスプロバイダは通常、DHCPを使用してIPアドレス、ゲートウェイアドレス、およびDNSリゾルバを使用してデバイスをロードします。おそらく、これはユーザに見える構成であり、手動構成で上書きすることができます。しかし、ブラウザが独自の設定を使用してDOHサーバーを選択するとどうなりますか? 従来のDNSフォークの関心事は、このブラウザベースの措置が従来のDNSプロビジョニング・プロセスの例外であることです。DHCPとブラウザの選択によるリゾルバサービスの選択が異なる可能性があります。それはどういう意味か?

DOHサーバは、最近リリースされたNetscapeによるDOHの実装は直接設定が可能ですが、DOH上の信頼できる再帰リゾルバとしてどのリゾルバを使うべきかについてブラウザが独自に決定することも可能です。このDOHメカニズムは、 可能性としてブラウザを微妙に異なる名前空間に配置することができます。今日の環境では、DNSの応答は、特定のサービスポイントにユーザを導くため調整されることが多いです。ブラウザは、基盤となるプラットフォームのDNS環境とは異なる回答を聞く可能性があるため、アプリケーション間でユーザへの命名の一貫性に関する興味深い問題が持ち上がる可能性があります。

このブラウザベースのDNSリゾルバ選択モデルのもう1つの関心事は、ブラウザが一つのオープンリゾルバ・サービスを使用することを選んで、いくつかのプロバイダにDNS解決の集中化をもたらす可能性があるというリスクです。しかし、私はDOHの使用が、現状を大きく変える可能性があると確信が持てません。GoogleのパブリックDNSサービスは、インターネットの全ユーザー層の約14%にすでにDNS解決サービスを提供しています。それが既に集中化ではないなら、私は意味が分かりません! 私はまた、DNS名解決の集中が必然的に他の人が恐れる「悪い事」なのか分かりません。多くのローカルDNSサービスにおけるローカルな干渉と妨害の程度を考えれば、彼らのオペレーションの中の公正とプライバシーの明確な原則を持った公開リゾルバーを使用するオプションの存在は、おそらく多くのユーザに残されているインターネットのいくつかの信頼ポイントの一つです! Googleが持つ全てのあなたのDNSトランザクションを共有することは、実際はあなたの興味を必ずしも持っていないかも知れない多数の未知の目に見えないプレーヤーのトランザクションを共有する可能性よりも望ましいかも知れません。そして、DNSリゾルバが伝えることを本当に信頼しないのであれば、クライアント側でDNSSECの検証を有効にする事を望むかも知れません。

しかし、DOHは、DNSサービスがサービス・インフラの本質的な部分であると暗黙のうちに仮定しているメカニズムを混乱させるでしょう。内部の名前空間と一般的な名前空間を提供するDNSスプリット・ホライゾンのハッキングは、DOHと必ずしも連携しません。一方、上記のローカルDNSハッキングは、任意のオープンなパブリック・リゾルバを使用することを決めた場合、決して機能しません。DNS64のようなDNSに依拠するIPv6移行テクノロジも動作しない可能性があります。しかし、ユーザがオープンなパブリックリゾルバのいずれかを使用することに決めた場合、動作しない可能性があると言う同じ批判が適用されます。

私は、DOHに対する反応の多くは、DNSクエリー解決プロトコル用に暗号化されたトランスポートサービスを使用し、IPサービスインフラから明示的に削除し、アプリケーションレベルのサービスとして使用できるようにすることではないかと思っています。アプリケーションは、独自の信頼できるDNS解決サービス、または独自のネームスペースを定義し、アプリケーションが実行されているプラットフォームとは独立して実行できます。また、デバイス自体が置かれているローカルIPサービス・コンテキストとは独立して実行できます。あなたは、インターネットの断片化のもう一つのインスタンスとして自分自身の信頼できる環境を決定する能力をアプリケーションに許可するこのモデルを呼び出すことができます。そして、私はその特徴の説明に同感です。しかし、それは必ずしも悪いことではありません。ブラウザによるDOHの使用は、蔓延する監視資本主義の環境に対抗しようとする場合、ユーザーにとって有益な答えになる可能性があります。そして、インターネット環境の全てがエンドユーザの活動に関する利用可能な全ての情報を徹底的に探し求めるため、勝手に用いられやすいです。

Verisignが運営するTLDサーバの変更

UDPフラグメンテーションは、依然としてDNSにとって大きな問題であり、特にDNSSEC署名ドメイン名にとってはそうです。

Verisignは、運用しているTLDサーバのRSA鍵サイズを変更し、鍵サイズを1024ビットから1280ビットに変更すると発表しました。binary worldでは、むしろ任意の選択であるようです。理論的にはRSAは任意の鍵サイズを許可していますが、従来の使用では2の累乗が好ましい鍵サイズがあるため、今の環境で1024ビットの鍵が弱いとみなされると、多くの運用者はルートゾーンZSKを含み、鍵サイズを2048ビットに変更しました。

しかし、大きな鍵サイズは大きな応答パケットを作り出し、RSAを引き続き使用し、署名されたNXDOMAIN応答をフラグメント化されていないUDPパケットサイズの1280オクテット以下に保持する事を望む場合、2048ビットよりはるかに小さい鍵サイズを使用する決定は強制的な決定です。これは、暗号化技術者が1024ビット鍵を最近不十分だと考える問題に対処する緩和策のようですが、1280ビット鍵の中の追加の256ビットでは多くの時間を稼げないかも知れません。

オプションは、楕円曲線暗号化を使用して、署名と検証でより高い計算負荷を課す「難解な」鍵に移行することです。しかし、結果として同じ暗号強度でも鍵は小さくなります。さもなければ、不完全な応答を甘受し、クライアントにTCPを使用してより大きな応答を得るよう強く求めます(現在、Verisignが動作するルートサーバーの場合と同様です)。もう1つの変更は、DNS応答の追加セクションでクロスドメイン・グルーを削除することです。この場合も、応答サイズが小さくなり、ほとんどのリゾルバはクロスドメイン・グルーを信頼せず、いずれの場合でも使用しません。

ルートゾーンのECDSA

ルートゾーンが2010年に署名された時、TLDに署名することもできました。しかし、ルートゾーン(RZM)の管理方法は、TLDのルートゾーンのDSレコードに楕円曲線アルゴリズムの使用を締め出しました。

2017年10月にRZMの方法が、GOST R.34 10-2001, ECDSA P-256 SHA-256およびECDSA P-384 SHA 384の使用を認めるよう更新されました。

.CZのオペレータCZNICでは、RSAからECDSA P-256へのKSKアルゴリズムのロールを報告しました。開始時点は875Mbの署名付きゾーンファイルで、DNSKEY応答は907バイトでした。その後、彼らはECDSA生成の署名をゾーンファイルに公開し、DNSKEY RRSETのECDSA鍵と一緒にゾーンファイルを1217Mbに上げ、DNSKEY応答を1263バイトに上げました。古いRSA鍵と署名を削除すると、署名付きゾーンファイルは695Mbに縮小され、DNSKEY応答は387bytesに縮小されました。

すでに言及したように、ECDSAはより小さな署名を使用しますが、時間は掛かります。署名ゾーンと個々の署名応答のサイズはECDSAの使用で減少しましたが、ゾーンの署名時間は15分から22分に増加しました。ECDSAに対する予測と一致しています。.CZの経験を元に、.BR TLDもECDSA P-256を使用するようにシフトしました。

Hello-DNS

「Hello-DNSに取り組んでいるのであれば、新しいDNS RFCを作成しなくていいです。」PowerDNSのBert Hubertは、さらに複雑な装飾でDNSを飾るのをやめようとしています。

DNS内で新たに登場するテーマは、長年に渡るハックや調整がDNSを著しく複雑なものに変えたかです。これは現在、180以上のRFCに渡って定義されており、ほぼ3,000ページのRFCドキュメントで定義されています。この取り組みは平均ペースで週2ページ(https://powerdns.org/dns-camel/)で続いています。DNSの中で共有する成果は、同時に印象的で恐ろしいものです。サーバは、1秒あたり最大100万応答の持続的なレートでDNS応答を提供することができます。同時に、DNSシステムが大量の機器に組み込まれているのに、運用上の問題を引き起こす複雑で紛らわしい仕様の結果が頻繁に見られます。実装者は今日、DNSの動作を定義する仕様が山のように増えて続けているため、間違いを犯すのも無理はありません。

他のRFCを試して明確にするさらに多くのRFCを書く多くの努力がありました。この分野の最近の贈り物は、より基本的なレベルで動作する用語集RFC7719(更新はdraft-ietf-dnsop-terminology-bis-07)のアップデートで、これらの仕様で使用されている用語の明確な意味を明らかにします。Bert Hubertの立場は、より多くのRFCを作成すれば、更に悪化するだけです!

多くの成熟した華やかなシステムと同じように、DNSは典型的な委員会誘導のブロートウェアに苦しんでいます。個人は、さらにブロートが追加されると、それらの活動に報いを受けるが、システムを取り除いて本質的なものにするために個人が利用できる恩恵はあまり明らかではありません。

Bertの反応はおそらくDNSコミュニティには珍しいです。Unixとネットワーク・プログラミングの書籍「TCP/IP Illustrated」と「Unix Network Programming」というリチャード・スティーヴンスの著書からインスピレーションを得て、彼は「DNS Illustrated」と言う形でコードと解説の両方を持つ簡単なDNS権威サーバーを定義するプロジェクトに着手しました。このアイデアは、アクセス可能で実行可能なDNSの入り口であり、最小限ではありますが完全なものです。これはコードで教えることができるDNSの形式であり、関連する解説です。ある意味で、これはDNSサーバを持つ人向けのタイムリーで便利な解説です。この仕様とソフトウェアのすべての最も重要な目標は何ですか? DNSの中心には何がありますか?

私は、今日のDNSの真の問題に対処するためのBertの実用的なアプローチが好きです。リチャード・スティーヴンスとダグラス・カマーの著書を使って、インターネットがどのようにコードで構築されたかを理解した人にとって、Bertの努力はDNSをより使いやすくするのに役立つかも知れません。また、DNSの不可欠な要素と核心部への豊富な一連の装飾と間の違いを理解するのに役立ちます(https://powerdns.org/hello-dns/)。

DNSの同綴異義語(Homographic)の不正使用

邪悪に、迷惑に、あるいは詐欺的な方法でDNSを使ういろいろな方法があります。 その立ち位置で、DNSは、「見た通りのものが結果に反映される」という点で、むしろ原始的です。ラベル「https://www.potaroo.net」のリンクが表示されたら、私のサイトに移動します。 「https://www.ρotaroo.net」はどうですか? 2つのDNS名は、一部のフォントで非常によく似ているかもしれませんが、DNSでは完全に異なるドメイン名です。

このDNS名の混乱は、DNSへのラテン文字以外の文字の導入と、これらの非ラテン文字を記述するためのUnicodeの使用と言う2つの要素の組み合わせの結果です。それぞれの文字グリフが一意に表示される可能性があるため、ラテン文字のアスキー文字レパートリーを採用しました。それらを互いに区別する方法については十分に訓練を受けました。例えば、「1」と「l」は「O」や「0」と同様にいくつかのフォントで似ているかも知れませんが、このレベルの混乱の心配はありません。しかし、Unicodeでは、文字のレパートリーはまったく別物です。

Unicodeの目的は、容易に識別できる文字グリフの集合を定義することではありません。目的は、画面の中で、あるいはプリンタで表示される内容を制作者が制御できるようにすることです。同じグリフを表示する複数の方法があるという事実は、Unicodeの機能には影響しません。しかし、Unicodeは気にしませんが、DNSは気にします。例えば、ASCIIコード61 (a)またはキリル文字コードU+0430 (a)を使用して小文字の「a」のように見えるグリフを生成できます。私のディスプレイでは、このフォントで表示するために同じグリフを選択したため、おそらく私と同じように見えますが、DNSはこれらの2つの文字を完全に異なった形で表します。a.example.comとxn--80a.example.comがあり、DNS的にはもちろん同じドメイン名ではありません。

おそらく利益のためにユーザを誤解させて欺く方法として、皆がこれを非難したのは驚くべきことではありません。あるDNS名を別のDNS名で成り済ますことは、あらゆる種類の意図的に欺瞞的な行為につながる可能性があります。

私たちはそれを止める事ができるのか?

FarsightのMike Schiffmanが指摘するように、問題解決の特効薬はありません。DNSの話法の領域に非ラテン文字を認めようとする意欲的な動きは、この混沌とした不安定な環境を作り出し、容易な解決法はありません。インターネット上では、私たちが見ているものは、そうでない時でさえ、私たちが得ているものであるという原則に基づいて動作します。アクセスしたサーバーがアクセスしようとしているサービスであることをユーザーに保証する改ざんのない方法はありません。「本当の」ドメイン名と「偽の」ドメイン名はおそらく同じレベルに認定されており、ブラウザ画面の外観は同一にすることができます。どのようにしてユーザはそのような状況下で本物と偽物を区別することができるのでしょうか?

DNSにとって、Unicodeは実は悪い考えであると宣言して立ち向かい、DNSの中でIDNや非ラテン文字を撤回しない限り、これは決して起こりません。代わりに何かできますか? ドメイン名の所有者は、名前のすべての可能性のあるhomoglyph変種を登録することによって名前を保護できますか? これは起こりそうにありません。だから、私たち皆が甘受しなければならない事がトレードオフです。私たちは、IDNがDNSを不確実な環境に変えた事をはっきりと認識し、最も賢明で慎重なユーザーであっても、間違ったWebサイトに資格情報を入力することに騙される可能性があります。そして、私たちはこの問題をどのように緩和するか全く分かっていません。

ルートゾーンKSKのローリング

それは起こりました。ICANNは、2017年に提案されたKSKロールを延期することを決定し、公的協議と多くの意見と討論の後、10月11日にルートゾーン鍵署名鍵(KSK)がロールされ、 48時間後にDNS内の様々なキャッシュが期限切れとなり、新しい鍵がDNSSEC検証の信頼アンカーとして使用されました。

しかし、ICANNは、今後のロールについてサービス事業者に通知するために重要なキャンペーンを請け負い、一見するところスムースに行われたこの鍵ロールは、計画プロセスで費やされたこの重要なエネルギーに関係している可能性が高いことを認識しなければなりません。

それは本当か?

可能性として5年ごとよりも定期的にこの重要なロールを行う熱意がありました。レゾルバが特定のトラストアンカーとウェッジに接着するのを防ぐため、毎年のロールを支持するには言うべきことはたくさんあります。

私たちは、全てのルートゾーンの応答をフラグメント化されていないUDPにもっと楽に適合させるために、ルートゾーンの鍵をECDSAにシフトすることを含む、さらに多くの対策を検討する必要があります。また、計画外のKSKロールを必要とする可能性の様々なシナリオにどのように対応するかという問題に取り組まなければなりません。DNSリゾルバに、鍵の導入期間を延長することなくルートゾーンにロールできる「バックアップ鍵」を、私たちは信頼できるようにすることができますか?

また、KSKのロールはほとんどインストルメント化されていないことで多少妨げています。 instrumentationをサポートするために2つの新しい変更、まず第1に信頼できる鍵のシグナリング(RFC 8145)と、第2に鍵センチネル(RFCは時間通りに公開されていません!)がありました。信頼できる鍵のシグナリングは、鍵のロールを12ヶ月間延期し、素直に言って、KSKロールをサポートするDNSの準備に対するなかなか消えない不安感を生み出しました。鍵センチネルは、鍵ロールのメカニズムをサポートしていたレゾルバがほとんどいなかったため、後で導入されました。どちらの場合も、最近更新されたDNSリゾルバからのKSK信頼シグナルを見ていたことは明らかでしたが、私たちの主な関心事は、DNSSECの検証を有効にはしたが、自動化された信頼の移行(RFC 5011)をサポートしていなかった古い、粗悪な、放置されたDNSリゾルバでした。

これらの最近のテストの仕組みでは、DNS環境をさらに調べる事ができず、これらの潜在的な問題点を特定することができませんでした。そのため、定期的にロールを続け、5年よりも頻繁に実施するという呼びかけに対する小さな反対の声は、私たちはまだ皆目見当がついていない事を示しています。信頼できる鍵の報告メカニズムの取り組みが広く普及するまでにはしばらく時間がかかるでしょう。その見解の視点から見ると、私たちはいつ、なぜこのKSKロール・エクササイズを繰り返すことを選ぶのかについて、さらに熟考する事を望むかも知れません。

DNSエイリアシング

コンテンツ・ホスティングのこの世界では、DNSエイリアシングは非常に便利です。私が「somecdn.corp」という共通のDNSを使用するホスティング・エンティティを持つ「www.example.com」にある私のサーバをホストしているのであれば、ホスト名「www.example.com.somecdn.corp」のエイリアスとしてDNS名「www.example.com」をマッピングすることは、ホスティング契約では珍しいことではありません。この取り決めは、コンテンツホストがエイリアス化されたドメイン名を使用して適切なサーバアドレスにDNS要求を誘導できますが、ユーザーは元の名前「www.example.com」に接続しています。

これは、DNSのCNAME(Canonical name)レコードが行うはずのものです。example.comゾーンでは、「www.example.com. CNAME www.example.com.somecdn.corp.」というエントリを使用します。ただし、制限があります。ノードにCNAMEリソースレコードが存在する場合、他のデータは存在できません。これにはSOAレコードなどのゾーンの頂点データが含まれています。これは、理論的にはCNAMEがゾーンの頂点名にエイリアスを適用できないことを意味します。これがCNAMEの唯一の制限ではありません。1つのサービスプロバイダがWebサービスをホストし、別のサービスプロバイダがメールを提供したい場合はどうすればよいでしょう? CNAMEは、解決のために全ての名前タイプをターゲットのカノニカル名にリダイレクトするCNAMEとして取得されます。また、ゾーンの頂点で名前クエリをリダイレクトしたい場合はどうすればよいでしょう? 厳密に言うと、DNS仕様ではこれを許可していませんが、多くのDNS解決の実装では実際に使用できます。

理論と実践との間にこのような相違があることを考え、いくつかの選択肢が提案されています。これらの代替アプローチが状況を改善するか、単に混乱を拡大するかどうかを判断することは容易ではありません。DNAMEは、サブツリー全体をつなぎ合わせるDNSの「移行ポイント」を定義します。しかし、CNAMEは端末ラベルのエイリアスであるのに対し、DNAMEは特定のラベルのDNSツリーの接合を参照するため、わずかに異なる方法で動作します。「color.example.com」というラベルをドメインプレフィックスとしても含め、あらゆる点で「colour.example.com」と同等にするには、CNAMEとDNAMEの両方をエイリアス構造として使用する必要があります。

ISCのOndřej Suryは、このCNAME + DNAME構造を使用したテストについて語りました。驚いたことに、それは実行可能に見えますが、動作することができるものと動作する事を知っているとの間にはまだ開きがあります! 後者については、DNSで様々な形式のエイリアスを処理する方法がまだ分からないと思います。

もっと詳しい情報を見付けるには

これらは、DNS OARC 29ミーティングのわずかなハイライトです。全てのプレゼンテーションはDNS OARC Meetingサイトでご覧いただけます。

10/20/2018

AppleのTim Cook、改めてブルームバーグの記事を否定

Slashdotより

John PaczkowskiとJoseph BernsteinがBuzzFeed Newsにレポートする:
Apple CEOのTim Cookは、BuzzFeed Newsとのインタビューで、同社は中国政府が実行したハードウェアベースの攻撃の被害者であるとの主張を否定して、初めて公式に意見を表明した。そして、今までに例のない会社の動きの中で、彼はこの主張をした記事を撤回するよう求めた。ブルームバーグのスポークスマンは、「私たちは記事を支持し、報道や情報源に自信を持っている」と述べた。ブルームバーグによると、攻撃者はチップが埋め込まれたサーバー上で実行されているネットワークに「ステルス出入口」を作成することができたという。Appleは、攻撃を受けた企業の中にあると主張し、記事の注目の的となった。[...]「私たちは会社をひっくり返しました」とCookは語った。「電子メールの検索、データセンターの記録、財務記録、出荷記録。私たちは法的に会社を徹底的に深く掘り下げ、同じ結論でも再度掘り起こしましたが、見付かりませんでした。この記事に真実はありません。」

ブルームバーグのスポークスマンは、「私たちは記事を支持し、報道や情報源には自信がある」と述べた。

ジョン・グルーバーは、次のように書いている

私は今、電話を掛けている。ブルームバーグはこの記事にお手上げだ。彼らが完全に撤回する前にこれを長引かせれば長引かせるほど、彼らは長期的な信用を失うことになる。彼らの声明を読むと、記事が真実であるとか、AppleとTim Cookが間違っていると言っているわけではない。彼らが言っている事は、彼らは1年を記事に費やし、17の情報源に複数回話しを聞いたということだ。

そして、BuzzFeedの記事の裏は表よりも手厳しい。セキュリティ界の誰もが、ブルームバーグの記事で何も検証することはできなかった。全く何も。そして、他のニュースもその記事を裏づけていない。ブルームバーグはこれに関してただ一人だ。

10/18/2018

NANOG 74でのルーティング・システムのセキュリティ

ジェフ・ヒューストンのブログより。

ジェフ・ヒューストン

ルーティング・セキュリティの一般的なテーマに関心を持つレベルは、私たちのコミュニティにどっと押し寄せているようです。時々、ネットワークオペレータ、研究者、セキュリティの人たち、ベンダーからの関心が非常に強いレベルに上昇するように見えますが、普段はこのトピックが瀕死のように見えることがあります。NANOG74でこの話題が注目すべきことがあれば、私たちは局所的なピークを経験しているようです。

法的視点

このテーマの最初のセッションでは、ペンシルベニア大学法学部のChristopher Yooによるルーティング・インフラの保護に関する法的障壁のテーマに関するプレゼンテーションが行われました。リソース・パブリックキー・インフラストラクチャ(RPKI)の使用がいかなる法的障壁にも遭遇するはずであることは、私には奇妙に思えますが、米国国立科学財団はこの分野に研究資金提供にメリットを理解しました。そして、思い返せば、私は、この分野は考慮すべき法的義務、範囲がないと考えるのは少し考えが甘いのではないかと思っています。

RPKIの導入は、世界のいくつかの地域で速度を増しています。RIPE NCCとLACNICによって管理されるプレフィックスから、BGP内のすべての公表されたプレフィックス/オリジンのペアの約4分の1が、関連する公開ROAを有しています。APNIC(約5%)とARINおよびAFRINIC(ARINの場合は2%、AFRINICの場合は1%)で、ROAに相当するプレフィックスの数ははるかに少ないです(https://rpki-monitor.antd.nist.gov/?p=0&s=0)。UPennの研究の目的は、RPKI導入への主張されている障壁をカタログを作り、法的および制度的障壁を独立に評価し、すべてのステークホルダーの利益を均衡させる実行可能なソリューションを提案することです。

確かに、RPKIはDNSSECで見るものと同様の一連の認識の問題を持っています。ネットワーク・インフラのオペレータは、通常、この技術の採用を支持する圧倒的なケースは見当たりません。このことを考慮すると、導入するケースは、商用運用環境にこれを追加する増分コストと、間違っている可能性のあるネットワーク・オペレーションに要素を1つ以上追加する関連したリスク要因とのバランスが取れています。しかし、これらは法的障壁ではなく、多くの技術導入の決定に適用されるのと同じコストと便益の構造の中に、従来通り存在しています。 それでは、なぜRPKIは違うのですか?

RPKIは従来型の階層型公開鍵構造であり、少数の推定上のトラストアンカーが指定された基準で他の人にCA証明書を発行し、同じ基準で他の人にCA証明書を発行することがあります。PKIの前提は、信頼が可換性があることです。つまり、認証局を信頼する準備ができていれば、私は元の信頼できる認証局の認証を受けた認証局などを信頼できるはずです。その意味合いは、証明書の利用者は、信頼する用意ができている証明機関の公開鍵を「信頼アンカー」の役割にあらかじめロードしてさえすれば良く、他のすべての証明書は、これらの可換対関係に続く証明書への信頼アンカーから証明書チェーンを確立する事によって検証する事ができます。その結果、これらの信頼できる証明書はPKIにおいて重要な役割を果たし、これらの信頼できる証明書に問題がある場合、下位の発行証明書とその派生製品の全体を検証することはできません。PKIがインターネットのルーティングシステムの中枢である場合、これは結果を考えていません。重要な一連のデジタル署名された製品を検証できない場合、セキュリティ機能のあるルータが一連の経路が無効で、廃棄する必要があると判断するという明確なリスクがあります。

公開鍵証明書に問題があるのはなぜでしょう? 証明書は、公開鍵が発行された証明書の対象であるエンティティが、証明書の発行に関連する特定の基準を満たしているデジタル署名証明書(attestation)です。リソースPKIの場合、基準にはIPアドレスと自律システム番号の保持が含まれ、証明書にはこれらのIP番号リソースが列挙されます。証明書の利用者が検証チェーンの証明書に適用する特定の条件は、各証明書内のリソースが同一であるか、または直下の下位の証明書のスーパーセットであるということです。すべての認証機関の負担は、記載された番号リソースが常に正確であることを保証することです。

証明書が間違った一連の番号リソースで公開されている場合、下位の証明書が検証されない可能性があります。前述したように、ルーティングシステムへの接続を通じたインターネットの中のサービスの到達可能性には意味があります。従って、証明書の発行は潜在的な法的義務がないわけではなく、認証局が義務を制限することは珍しくありません。

ARINは、この証明書のコピーを入手する前に、その信頼アンカー証明書のすべてのユーザーに依拠当事者規約を受け入れるよう求める決定を下しました。そして、この規約は、その証明書を第三者に配布しないように受け手に義務を負わせます。Christopher Yooはプレゼンテーションで「直接的な法的判例はありません。RPKIのRIRに対する訴訟の記録はなく、TLS、SSL、DNSSEC、あるいはIRRのルーツ提供者に対する訴訟の記録もありません。しかし、過去の履歴は将来の結果を保証するものではありません(つまり、過去の歴史がないからといって、他の状況では、RPKIに対する今後の訴訟がないと保証されません)。」と指摘しました。トラストアンカーを提供する際に残るリスクがあり、米国の法律では、契約条件の公表が十分ではないため、明示的な規約の法令が必要です。

インターネットはもはや実験ではなく、サービスの提供者に非常に現実的な責任問題があることは事実です。私たちはしばしば、そのようなサービスプロバイダーの義務を制限することを意図した免責事項やその他の注意事項のさまざまな形に依拠してきましたが、今日の状況では「無保証の」や「ベストエフォート」のサービス提供の形では不十分です。意図されたRPKIの意図された役割がインターネットのルーティングシステムの中心にある場合は、これらの重要な信頼アンカー証明書サービスを提供する際に適切なレベルのサービスサポートを提供する必要があるかもしれません。

BGPmonが見たルーティング・インシデント

BGPmonのAndree Toonkは、経路がハイジャックされた最近のルーティング・インシデントについて説明しました。これらのインシデントのすべて、発信元ASが経路ハイジャックを何らかの形で示しているプレフィックス広告に関わっており、これらのハイジャックは、ROAが観測されているルーティングシステムでは、すべて無効と検出される、あるいは伝えられていません。

しかし、ROAの有用性と価値についてのこの楽観的見解を和らげる2件の観測があります。1つは、ROAが経路の無効な発信を示す経路を拒否するように見えるのは63のネットワークのみであるということです。今日のルーティングシステムでは、63,000のネットワークの中で非常に小さい数値です。うまくいけば、この状況は時間とともに改善されるでしょう。2件目の観測は、これらの経路リークが誤った操作ミスであった場合にのみ、ROAが有効であったということです。これらの経路リークが意図的な経路ハイジャックであった場合、攻撃者はROA定義の発信元ASを使用してハイジャックする経路を作成できます。ROAでmaxlengthパラメータを慎重に使用すると、より特定の攻撃を緩和できますが、発信元ASを保ちながら計画的なハイジャックに基づいてルーティングの中断の可能性が残ります。

BGPレベルで有効なある種の自動ルーティング・セキュリティでは、何らかの形でASパスを検証し、発信元を保護する必要があります。BGPSECプロトコルはこのAS Path検証を実行することを意図していましたが、残念ながらBGPSECの見通しは芳しくありません。BGPSECは、プロトコルが部分的に導入されている場合には十分なインセンティブを提供せず、BGPアップデートに署名するためにすべてのルータに証明書と鍵をロードするというコンセプトは、多くのネットワークオペレータを当然のごとく不安にさせてしまいました。ROAだけでルーティングの世界にいかに価値があるのかを理解する必要がある、あるいはBGPスピーカーが受け取るASパスが最低限のものであることを保証するための手段を提供する他のメカニズムを私たちは探す必要があります。

インターネット・ルーティング・レジストリ

長年、私たちはルーティング分野で潜在的な無秩序をコントロールする1つの方法がインターネット・ルーティング・レジストリ(IRR)の使用によるものだと考えました。 私たちは1990年代初めからIRRを使用してきましたが、多くの経験を積み重ねてきました。

IRRがこの問題を止めることができなかったという観測に、同じ期間にわたるルーティング異常の流れが依然として見られるという事実が指摘されています。QratorのAlexander Azimovが観測するように、IRRフィルタを使用すると潜在的に一部のハイジャックをフィルタリングし、一部の経路リークをフィルタリングできますが、IRRの多くのAS-Setsは維持管理が不十分で、ネットワークにフィルタを使用して、 IRRエントリによってフィルタリングされていたはずの経路が広範囲に広がる事を可能にするネットワークでの使用にはギャップがあります。 RPKIとROAは助けになる可能性はありますが、そのような助力は現在のところ一時しのぎでしかありません。

NTTのJob Snijdersが指摘しているように、多くのIRRはないに等しいセキュリティモデルで運用しています。誰でもIRRオブジェクトを作成でき、そのIRRから生成されたフィルタは悪用される可能性があります。Jobは、主要なIRRがエントリの検証を実行せず、ここで潜在的な問題を抱えていると主張します。RIPE NCCによって運営されているITTは、RIPE NCCによって管理されていないアドレス空間を参照するルートオブジェクトのエントリを防止するように移行しました。この方法は、データの整合性を向上させますが、ルーティング環境のサブセットのみを記述するため、IRRの適用範囲を制限します。ARINでも同様の対策が採用されています。

Jobはまた、多くのIRRクライアントがwhois.radb.netとrr.ntt.netという2つの主要アグリゲータのうちの1つを使用していることも観測しています。ここで提案される1つの尺度は、これらのアグリゲーター内に有効なROAのコレクションを含めることで、2つのデータソースが競合するたびにROA由来のデータをIRRエントリよりも優先させることです。これは、ROAが期限付き証明書で署名され、ROAの現在がROA作成者によって決定されることを前提とすれば、妥当なステップだと思われます。

ROA無効経路を削除する

この措置は、リスクと責任の問題を呼び起こすものです。RPKIおよびROAの使用全てが経路優先順位の使用に限定されている場合、ROAの問題によって宛先への転送のパフォーマンスが低下する可能性がありますが、到達可能性は損なわれません。話が、ROAが無効である経路を削除するオプションに移行すると、事態ははるかに深刻になります。

私たちは現在、ルーティングの振る舞いを優先順位の無いROAの無効経路からその経路を削除するように変更するよう求めています。もちろん、効果を持たせるために、誰もがこれを行う必要はありません。インターネットは、密に相互接続されたメッシュではありません。それは疎階層のようなものです。少数のトランジット・プロバイダと主要な交換ポイントの一部のルートサーバがこの変更を行った場合、ROA無効である経路はインターネット全体に伝播するのを防ぐことができます。

ROAのみのフィルタリング・フレームワークへの反論の1つは、意図せぬ経路の誤った発信を検出するかも知れないが、確たる意志を持ったハイジャッカーによって容易に回避されるということです。ハイジャッカーは、単に正しい起点ASを合成経路オブジェクトに添付する必要があります。しかし、おそらく思うほど絶望的なものではありません。最悪の攻撃形態は、より大きな経路のよりスペシフィックな経路広告を偽造することであり、これを緩和する方法は、ROAの最大長パラメータに細心の注意を払うことです。実際的な見解では、ハイジャックを困難にする手段を使用する必要があり、必ずしもあらゆる経路をハイジャック不可能にしようとする必要はありません。

私たちはどこに向かうのか?

ルーティング・セキュリティに関して、より大きな主体は何をしていますか? GoogleのChris Morrowは計画を発表しました。興味深いことに、RPKIとROASは当座の計画の一部ではありません。2019年の初頭までに、OpenConfigのようなものを使ってIRRを徹底的に調査し、ピアのための経路フィルタを生成することを目指しています。RPKIとROASはその後に行います。

おそらく、Googleは他のユーザーよりも慎重に行動しています。IRRとIRRフィルタリングは昨日の解決策であるというルーティング・セキュリティの会話には意味があります。RPKIベースの自動化されたソリューションのいくつかの形態を導入するためのいくつかの目に明らかなやる気があります。しかし、BGPSECプロトコルで規定されているように、私たちは完全な経路発信元とAS Path保護アプローチはまだずっと先のことだと認識する必要があります。確かに、最終的な有用なデプロイの見通しが存在しないということは、大きな間違いをしている可能性があります。

ROASは有用か? はい、RPKIインフラとROAを使用してIRRデータフィードを徹底的に調べ、矛盾したIRRエントリを削除したり、ROA検証が無効な結果を指し示す経路を削除することにさらに進むことも可能です。

しかし、経路を削除すると、RPKIオペレータと証明書発行者のリスクと責任の問題が発生します。うっかりした不運な事故に関連する経路を削除することは良いことです。アドレスをハイジャックしようとする意図的な試みに関連する経路を削除することも良いことです。しかし、完全に有効な経路を落とすことは良いことではありません。結果として、金銭的価値が高い取引が止まれば、影響を受けた当事者は何らかの形で償いを求める可能性があります。

RPKIの発行者と証明書の利用者が、その行為の結果についてどの程度まで責任を負うかは、法的に保証されていない多くの側面が残っています。様々な主体の役割と責任に関する様々な免責事項と明確な記述に、法律の下でこの責任が含まれることがあります。しかし、インターネットは現在、世界の公共通信インフラとなっており、ネットワークを介して行われる取引の金銭的評価は膨大なものになる可能性が高いです。この民間運営のインターネットには公共サービスの免責事項はなく、ルーティングシステムで何らかの形の大規模な失敗を引き起こすリスクは低いものの、結果的に賠償費用が相当になる可能性があります。

私はこれらの法的問題についてのChristopher Yooの研究の更なる見解を楽しみにしています。ルーティングシステムをセキュアにすることは非常に価値のある目標ですが、このエクササイズに関与している様々な主体のリスクの規模が大き過ぎて、彼らは本質的に存在する場合は、重要なイベントの可能性が低い場合でも、私たちはどのように進むかについては極めて慎重であるべきです。

10/17/2018

FIIに反対することで、ジャーナリストと報道の自由のために決起する!

BoingBoingより

ワシントンポストのコラムニスト、ジャマル・カショギ氏の暗殺に頭に来ていないとしても、あなたはそうであるべきです。

米国の永住者であるカショギ氏は、米国市民と同様に、米国政府によって保護されるべきです。しかし、カショギ氏殺害の加害者を司法の場に連れて行くためには、サウジアラビアに圧力を掛けるのではなく、「ならず者の殺人者」に無駄話をさせる以外に何もありません。金は、いつものように、人間の命の尊厳と法の支配に先んじて置かれています。カショギ氏の謀殺は報道の自由に対する攻撃でもあります。サウジアラビアの腐敗と人権侵害に関する彼の勇敢で揺るぎない報道は、彼をサウジアラビアの王族と国家情報機関の標的としました。彼は真実を伝えるために殺されました。私たちは、政府がカショギ氏の謀殺に対して行動を起こさせるよう強制することはできません。しかし、私たちは、サウジアラビアと取引を行う責任者に怒りを伝えることができます。

Future Investment Initiative (FII)」は、10月23日にサウジアラビアのリヤドで開催される会議です。金持ちたちが、富裕層のことについて、より金持ちになることについて話します。このイベントは、世界最大のソブリン・ウエルス・ファンドの一つであるパブリック・インベストメント・ファンド(PIF)の仕事です。PIFは、前述のように、富裕層のみがより豊かになるために、お金を使っても差し支えのないものに投資する仕組みです。FIIの10月23日のイベントは、資金調達のエリートたちが、さらに資金を確保し、資産を作り、超富裕層が既にしているよりも世界の富をさらに多くをコントロールする方法について話し合っています。カショギ氏が失踪し、サウジアラビアの政府当局者の手によって死んだという信憑性のある報道以来、数多くの著名人や団体が、リヤドでのFIIイベントとは何も関係がないと発表しました。それは重要な意思表示です。イベントをボイコットした個人や企業が多いほど、サウジ政府にとって都合が悪いのです。それは、サウジアラビアの土地で行われるビジネスが少なくなり、サウジアラビアのビジネスへの投資が少なくなるということになります。金庫の中の金の量が上がったり下がったりする王国にとって、これは痛いところですぐに打撃を受けます。

Stop The Future Investment Initiative」は、リヤドのイベントにまだ関わっていない個人や企業の公的生活を可能な限り不快にするために必要な全ての道具を提供するウェブサイトです。このサイトは、FIIの講演者全員と出席する全企業のTwitterの連絡先を提供しています。複数言語でのグラフィックの所蔵庫もあります。あなたのようにソーシャルメディアに精通している人は、多くの現金が、処罰を受けずにジャーナリストを殺害できると感じている王国に向かっている行くことにあなたの不満の声を表明して下さい。

急いで。参加して下さい。

Jamal+Sillouhette+ Recovered 41

10/16/2018

衛星は衛星を持てるのか?

arXivより

太陽系内の巨大な惑星のそれぞれが大きな衛星を持っているが、これらの衛星のどれも衛星を持っていない。短周期外惑星の周りの衛星の研究との類推によって、我々はサブムーンの力学的安定性を調査する。我々は、10km規模のサブムーンは、幅の広い分離軌道上で大きな(1000km規模の)衛星の周りだけで生き残る可能性を見出している。潮汐散逸は、ホストとなる惑星に小さい、あるいは近すぎる衛星の周りのサブムーンの軌道を不安定にする。これは太陽系の衛星の大部分の場合に見られる。しかし、土星の衛星タイタンとイアペトゥス、木星の月カリスト、地球の月のような長く続くサブムーンはホストする事ができる。その推定された質量と軌道の分離に基づいて、新しく発見された太陽系外衛星の候補Kepler-1625b-Iは、軌道の傾きが大きくなると動的安定性が困難になるかもしれないが、原則として、サブムーンをホストする事ができる。サブムーンの存在または欠如は、惑星系の衛星形成および進化に重要な制約をもたらす可能性がある。

Hacker News

Googleの死

Lauren Weinsteinのブログより。

Lauren Weinstein
8 October 2018

Blog: https://lauren.vortex.com/the-death-of-google
PDF: https://lauren.vortex.com/google-death.pdf
Google Docs: https://lauren.vortex.com/google-death.gdoc

Googleが死にそうだ。患者を救うことは可能かもしれないが、Googleはすでに後に引けない段階を過ぎている可能性がある。特に、あらゆる側面から、そして内部から攻撃されているいくつかの要因がある。この状況は、主としてGoogle自身によってコミットされた自発的なエラーによって可能になっているため、予測は暗いとしか記述できない。

残念ながら、Googleがこの時点で本当に自分自身を救うために必要となる「ライフスタイルの変更」のようなものを作る能力があるかについて、私は強い疑念を持っている。私は、これらの疑念が間違っていると証明してもらいたい。

Googleという会社とその親会社のアルファベットは、見通せる範囲で存在し続けるだろうが、すべての実用的な目的のために、私たち皆が知っているGoogleは、今のところマネーが回り続けているとしても、ある種の衰退が末期的に見える。

どうすればいいのか?

Google+のセキュリティ違反と今度のGoogle+の閉鎖についての今日の発表は、長年にわたりGoogleにを蔓延してきた悪性腫瘍の直接の症状である。

私の書いた投稿やラジオのインタビューを通じて、Googleの嫌悪者の誤認や嘘への反論にかなりの時間を費やしてきたGoogleの大ファンとして、私はこの種の分析に喜びを感じない。

私は何年もの間、まさに無敵に他ならないように見えた他の主要なテクノロジー企業の死の淵を見てきた。

1つはAT&Tである。ディジタル・イクイップメント・コーポレーション(DEC)も同じだった。彼らの衰退には時間が掛かった。これは出来事ではなくプロセスである。あなたがずっと昔まで遡れば、実際はかなり長いリストになる。DECは他の企業に同化され、その人材は様々な方向に吸い上げられた。AT&Tは今日もまだ大きくて強力だが、多くの意味で昔の面影だが、ベル研究所のような宝石は無意味なものに変わってしまった。

Googleを苦しめている勢力は、種類は多少異なるが、全てが見た目にはもっと厄介で痛みを伴うものである。

その中心で、Googleは複雑で多面的な倫理的ジレンマに苦しんでおり、時間の経過とともに内部から企業に打撃を与えることを脅かすばかりでなく、政治的意欲を持つGoogle嫌いの者たちが邪悪な議題を促進するために使っている巨大な傷口を開いている。

私はGoogleになるとかなり色々な所に旅行した。20年前の新入りだった頃、私は、感情的になりやすい批評家だった。初期のデータ収集やプライバシーの習慣の多くは、私が容認できないと見なした致命的な態度によって動かされたようだ。

Googleとの最初の直接的なコンタクトは、2006年にGoogleのL.A.オフィスに招待され、私が「Internet & Empires」というタイトルで講演を行いました(かなり若い頃のプレゼンテーションのビデオがここにある: https://www.youtube.com/watch?v=PGoSpmv9ZVc)。

それが彼らがオフィスで録音した最初の講演だったと思う。まだ演台は無かった - 私はプレゼンテーションのためにテーブルの端に座っていた。

当時のGoogle社員とのやりとりは、私が家に帰る前のQ&Aやそれ以降の議論両方から、すぐに私に一種のエピファニーをもたらした。

Google社員は、おそらく、私が今までに出会った、または技術で一緒に仕事をした人たちの、もっと言うと他の場所の中で最高の人たちである。Googleに内部的にコンサルしたり、数年間に渡って直接彼らと一緒に作業することは誇りだった。

彼らは知的だ。彼らは気遣う。彼らの多くはかなりオタクだ。— しかし、私は確かに自分自身に罪を認めています。私は好ましくないと思ったGoogle社員にほとんど会ったことがない。

しかし、「一般職員」のGoogle社員とGoogleの上級管理職の中の一部の個人の間には、不連続な何かが存在することが2006年にすぐに明らかになった。コンタクトの最初の日であっても、Google社員は私の講演で話したような問題に関連して、この点について私に不満を言った。

それから数年、Googleに関するさまざまな問題が劇的に改善されている。Googleは、プライバシー、セキュリティ、人工知能に関する世界トップレベルのリーダーとなっている。これは、Googleがこれらの点で完璧であるということを意味するものではなく、バグはまだ発生する可能性があるが、彼らはこの重要な課題に命がけでチームで取り組む優れた人たちがいる。— 私は個人的に沢山の人達を知っている。

しかし、重要な点では、Googleの経営陣と他のGoogle社員との間の隔たりが、食い違いから大きな隔たりへと広がっているようだ。

Googleは、さまざまな分野で私が寛大に「盲点」と呼ぶものを常に持っていた。何年にもわたって私はこのようなことについて何度も公表してきたが、ここではそれらについて詳細には触れないが、いくつか簡単に見直してみる。

顧客サービスは、当初から継続中の問題となっている。時間が経つにつれて確かに有意義な進歩を遂げたが、特にGoogleの製品やサービスに依存する非技術者の人口が増加しているにも関わらず、Googleのユーザー・インターフェイス・デザインや利用可能なヘルプリソースがますます低下している。

ユーザーインターフェース、読みやすさや、類似の分野に関して言えば、Googleの一種の「多重人格」に再び見えている。彼らは失明のような厳しい条件の人にとって素晴らしく、急速に進化するリソースを持っているが、コントラストの低いフォントや混乱しやすいユーザー・インターフェイスを引き続き導入して、視覚的に欠点で多くのユーザーを確実にバカにしている。

オンブズマンや消費者保護団体など、他の地域で成功しているGoogleの役割をGoogleに提案するという提案は、私がそれらを言い出した時はいつでも、Googleのレンガの壁に絶え間なく日常的にぶつかった。Googleの問題に関するさまざまなエッセイで、おそらくこのトピックだけ、私は100,000語以上を書いている。

Googleの公共コミュニケーションのスタイルは、現在進行中の問題の大きな部分を占めていることは明らかである。なぜなら、私の経験では、Googleについての多くの一般的な誤った主張は、コンピュータに詳しくない人が評価する方法で実際にそうするために時間を取る時、容易に反論されるからである。

しかし、Google PRは、何か論争が起こった時、状況がエスカレートして沈黙がもはや選択肢にならなくなるまで、いつも黙ってしまう傾向があった。そして、問題は公に迅速に処理された場合よりもはるかに悪化している。Googleが「ストライサンド効果」— あなたが悪い状況について何か言ってもそれに注意を払うだけでは、うまく機能しないという考え方 — の恐怖に深く根ざしている。

今日遅ればせながら発表されたGoogle+に関するセキュリティ侵害は、Googleが10ヶ月間に渡ってGoogle+をシャットダウンする便利な理由のように思われ、私が上記で言った多くの事を要約する。

セキュリティ侵害の実際的な影響はごくわずかだと思われるが、Googleは、横たわっているGoogle嫌いの政治的動機に直接触れている。彼らは、既にGoogleの血を求めて叫んでおり、経営幹部が比喩的に描かれ、くまなく捜索されている。

これらのGoogleのコミュニケーション戦略の種類は、悪意に満ちた嫌う人に政治的なユーザー検閲の虚偽の非難に使用するための材料をさらに与え、彼らは、EUの財政を増やすためにGoogleにさらに数十億ドルの罰金を貸そうとする追加の口実を与え、政治家や政治家の手先やおべっか使いによる政治的利益のために細かく管理するため、Googleをより小さい単位に分割することを望む勢力に莫大なエネルギーを与える。

Google+の場合、今日の公表についての内部情報はないが、何が起こったかを推測するのはかなり簡単である。

私は2011年にベータ版が利用可能になってからGoogle+を非常に積極的に利用してきた。しかし、最初から、Googleの経営陣の見解は多くの熱心なユーザーとは大きく異なっていた。そして、否定派の主張に関わらず、何百万人もある。私は、ものすごく素晴らしいGoogle+ユーザの素敵なコアなファンを持っており、Google+のロスが、私は悲しくて、もちろん、非常に怒っている。これは、Google自身に裏切られた忠実なユーザーが足りない何かがあると考えるのは難しい。

なぜなら、それは起こる必要がなかったからだ。Google+はかなり限られた内部サポートリソースで動作していたことは明らかですある。G+を日常的に使用していた人にとっては明らかだった。ここに至るまでに恐ろしい執行決定が下された。おそらく、究極的にはG+とYouTubeのコメントシステムの統合が放棄されたが、破滅的な影響で関心のある異なる分野を完全に二次感染した。私はこのことを公的かつ内部的にも主張したが、最終的に撤回されたが、そのダメージはすでに終わっていた。

もう一つのGoogleの自分に負わせた怪我は、Googleが長年中国を放棄してきたコンセプト、中国での中国政府の検閲済みの検索をGoogleが再び提供するという計画をめぐる新たな論争である。私はこれについて多くのことを最近書いている — それはひどい考えであり、Googleの敵の手に入ると信じている — しかし、これらの動きや内部で処理された方法が公に話した多くのGoogle社員を引き起こしたという大きな苦境に気づくこと以外、私はここで再び詳細には触れないだろう。

そして、私が最近書いたように、Googleの幹部がこの問題について話し合っているという漏洩したGoogle TGIFビデオを見ると、邪悪な意図は見られず、事実、あなたは、政治的偏見がGoogle検索や他のGoogleサービスへの道を見つけるのを阻み続ける必要性を強調している幹部に気付くだろう。だから、彼らの胸の内は明らかに全体的に正しい場所にある。

しかし、最高の意図さえも十分ではありません。

ラリー・ページとセルゲイ・ブリンは、Googleの2004年のIPO時の投資家への手紙の冒頭文言で、次のように書いている。

「グーグルは慣例にとらわれない企業であり、今後もそのような企業になるつもりはありません。」

私と他のGoogleの支持者が何年も主張してきた変更の類がなくても、Googleが今後も前進し続け、大量のお金をまだまだ稼ぐことは実際には可能である。

しかし、それは同じGoogleではない。 世界中の非常に多くのユーザーが日々頼りにしている、多くのGoogle社員が非常に誇りに思っている会社ではなく、Googleは「従来の会社」のようなものになるだろう。

私たちが知っているGoogleは死んでしまうだろう。それが過ぎると、私たちは多くの人が長い間心配していたインターネットの非常に暗い段階に入り、防ごうと努力するのが難しくなる。

そしてその損失は私たち全員にとってひどいものになるでだろう。

–Lauren–

Hacker News

ユニバーサル・ベーシック・インカムは、「更なる奴隷化のための道具」か?

Slashdotより

長らくオープンソースを主張していたダグラス・ラシュコフ(現在はニューヨーク市立大学クイーンズ校のデジタル経済学教授)は、ユニバーサル・ベーシック・インカムを「大衆への贈り物ではなく、私たちの更なる奴隷化の道具」と呼んでいる。

他の多くのデジタルユニコーンのようなUberの事業計画は、それが参入するマーケットからすべての価値を引き出すことに基づいている。これは、最終的には、従業員、顧客、サプライヤーの両方を引き続き成長させることを意味している。人々が最終的には貧困に陥って運転手や乗り物の支払いを続けることができない場合、UBIは事業継続に必要な資金注入を提供する。ソフトウェア開発者の考え方を見ると、UBIは実のところ根本的に欠陥のあるプログラムへのパッチに過ぎないことは明らかである。デジタル資本主義の真の目的は、経済から価値を引き出し、それをトップの人々に届けることだ。消費者が自分のためにその価値の一部を保持する方法を見つけたら、あなたは何かが間違っているか、お金を取り逃がしていると思っている。

ウォルマートは20世紀にこのモデルのよりソフトなバージョンを完成させた。町の中に移動し、コストを下回る品物を販売して地元の商店より安く売り、全てを廃業に追い込む。次に、単独の小売業者と唯一の雇用主として、あなたが望む価格と賃金を設定する。そして、あなたの労働者が生活保護やフードスタンプを受ける必要がある場合はどうなるか? 今や、デジタル企業は同じことを、より速くより完全に達成している。そのうち、消費者は収入の流れを持続させるだけでは消費はできなくなる。FacebookやGoogleのような全ての人のデータを蓄積する可能性があっても、データの背後にいる人の誰もそれを費やすことができなければ、魅力を失い始める。救助者にはUBIが来る。

かつて、この政策は極度の貧困を克服する方法と考えられていた。しかし、この新しい形は、経済運営システムの最上位に、裕福な人(およびその忠実な信者、ソフトウェア開発者)を養う手段としてだけ機能する。もちろん、政府から市民に与えられたお金は、必然的にそれらに流れるだろう...。思いやりの姿勢の下で、UBIは実際に私たちを、利害関係者や市民から単なる消費者に変える。価値を創造し交換する能力が奪われると、あらゆる消費の行為で私たちができることは、どんな誇張もなしに言うと、最終的に私たちの企業オーバーロードと呼ばれる人たちに、より多くの権力を提供することである。シリコンバレーのUBI支持者が経済運営システムを本当に修復したいと思ったら、ユニバーサル・ベーシック・インカムではなく、Institute for the FutureのMarina Gorbisが最初に提案したユニバーサルな基本資産を検討すべきである...。魅力的に聞こえるように、UBIは、企業が私たちを雇用すると装って、私たちを圧倒するための手段でしかない。それは、嫌な奴が車に夢中になっている子供に提供するキャンディ、あるいは腐敗した雇い主が、性的嫌がらせをしたスタッフに与える昇給である。それは口止め料だ。

ラシュコフの結論?「その支持者が冷笑的であるか単純に世間知らずかにかかわらず、UBIは我々が必要とするパッチではない」

10/15/2018

物理的能力があるコンピュータの世界におけるセキュリティ

シュナイアーのブログより。

コンピュータが安全でないことは秘密ではありません。最近のFacebookのハッキングEquifaxのハッキング政府機関のハッキングなどの報道記事は、それらが本当にどれほど目立たないかという点で注目に値します。数日間は見出しに載るかも知れませんが、これらは氷山の一角でニュース価値のある情報に過ぎません。

コンピュータは物理的なデバイスに埋め込まれており、私たちのデータだけでなく人命に影響を与えるため、リスクはさらに悪化しています。セキュリティは市場が解決する問題ではありません。政府はますます危険にさらされているこの場所に介入して、規制する必要があります。

コンピュータが安全でない主な理由は、ほとんどの買い手は、彼らが望む製品やサービスに組み込まれているセキュリティに対し、金銭面で、機能で、製品化までの時間で、支払う意思がないことです。その結果、私たちはハッキング可能なインターネット・プロトコル、脆弱性で詰まったコンピュータ、簡単に侵入されるネットワークに悩まされています。

非常に長い間、コンピュータ・セキュリティは主にデータに関するものであったため、私たちはこの綱渡り的な状況を受け入れました。金融機関によって保管された銀行データは重要かも知れませんが、盗まれても誰も死ぬことはありません。Facebookのアカウントデータは重要かもしれませんが、再び、盗まれても誰も死ぬことはありません。これらのハッキングの悪質さに関わらず、問題を解決するよりも結果を受け入れることは歴史的に見ても安上がりでした。しかし、コンピュータを使う方法の質は変化しており、より大きなセキュリティリスクを伴うようになっています。

今日の新しいコンピュータの多くは、私たちがじっと見ている画面だけではなく、私たちが互いに交流し合う世界の中での中心です。冷蔵庫は今や物事を冷たく保つコンピュータです。車は現在、4つの車輪とエンジンを備えたコンピュータです。これらのコンピュータは、私たちと環境を理解し、私たちと環境に影響を与えます。コンピュータはネットワーク越しにお互いに会話し、自律しており、物理的な仲介者を持っています。これらは車を運転し、飛行機を操縦し、発電所を運行します。これらは、交通を制御し、私たちの体に薬を投与し、緊急サービスを送ります。これらの接続されたコンピュータとそれらを接続するネットワーク(総称して「モノのインターネット」と呼ばれる)は、直接の物理的な方法で世界に影響を与えます。

私たちは既に、ロボット掃除機に対するハッキング、病院を閉鎖し、患者を介護させないランサムウェア、そして車や発電所停止させるマルウェアを見てきました。これらの攻撃はより多く見られるようになり、より破局的になっています。コンピュータは他のほとんどの機械(マシン)とは違う形で機能しなくなります。遠隔から攻撃を受けるだけでなく、全てを一度に攻撃することができます。古い冷蔵庫にウイルスに感染させたり、サービス拒否ボットネットに入れることは不可能です。そして、インターネットに接続していない車は遠隔からハッキングすることはできません。しかし、4つの車輪とエンジンを備えたコンピュータ? それは、同じメーカーとモデルの全て車が同調して、同時に道から外れさせる事ができます。

脅威が増加するにつれ、私たちの長年にわたるセキュリティに関する前提はもはや機能しません。セキュリティの脆弱性にパッチを当てる慣行は、この良い例です。従来は、私たちは定期的にシステムにパッチを適用し、不安定さを修正するアップデートを適用して、コンピュータの脆弱性に対する終わりのない流れに対応しています。これは、製造元がパッチを書くセキュリティチームを持たない低コストのデバイスでは機能しません: セキュリティ上の理由からDVRまたはWebカメラを更新したい場合は、古いものを捨てて、新しいものを購入する必要があります。パッチを当てる事は、より高価な機器では機能しなくなり、むしろ非常に危険になる可能性があります。新しいセキュリティパッチが作成され、テストされ、配布される前の数週間に渡って、道路や高速道路で不安定な自動車を許可したいのですか?

もう一つの失敗を負ったのは、サプライチェーンのセキュリティです。私たちは、ロシアや中国がコンピューターやソフトウェアの中に置いた脆弱性に関する政治的バトルを見始めました。しかし、サプライチェーンのセキュリティは、疑わしい会社の所在地だけではありません: チップが作られた場所、ソフトウェアが書かれた場所、プログラマーはどんな人物か、その他全ての事について心配する必要があります。

先週、ブルームバーグは、中国がAmazonやAppleなどのアメリカ企業向けのハードウェアに盗聴チップを組み込んでいたと報じました。ハイテク企業は全てこのレポートの確度を否定しました。これはまさに問題を示しています。コンピュータの生産に携わる人は誰でも、セキュリティを破壊する可能性があるため、信頼されなければなりません。全てがコンピュータになり、これらのコンピュータが安全保障上のアプリケーションに組み込まれるようになると、サプライチェーンの腐敗は無視できなくなります。

これらはマーケットが解決できない問題です。買い手はセキュアな商品とセキュアではない商品を区別することができないので、売り手は買い手が見ることができる機能に費用を費やすことを選択します。インターネットやサプライチェーンの複雑さは、個々の脆弱性が引き起こす損害を突き止めることを困難にします。裁判所は従来、ソフトウェアメーカーに脆弱性に対する責任を負いません。そして、ほとんどの企業にとって、多くのコストが掛かる製品を販売するのではなく、1年後にマーケットに投入する方がより少ないため、一般的にセキュリティを犠牲にする事が良いビジネスでした。

解決策は複雑で、私は最新の本で答える事に専念しました。技術的な課題はありますが、それは克服できないものではありません。政策の問題の方がはるかに困難です。私たちは政策の問題としてインターネット・セキュリティの未来に取り組まなければなりません。そうするためには、あらゆる段階で政府の関与が必要とする多面的なアプローチが必要です。

まず、安全ではない製品が他者に危害を与えないようにするための基準が必要です。私たちはは、インターネットがグローバルで、規制はローカルであり、それに応じて設計されていることを受け入れる必要があります。これらの基準は、最小の許容可能なセキュリティのための規範的規則がいくつか含まれています。カリフォルニアは、デフォルトのパスワードを禁止するモノのインターネットのセキュリティ法を制定しました。 これは閉じる必要のある多くのセキュリティホールの1つにすぎませんが、幸先はいいです。

また、さまざまな企業、組織、および業界のニーズに柔軟かつ容易に対応できるような私たちの基準が必要です。国立標準技術研究所のサイバーセキュリティ・フレームワークは、その推奨事項が組織の個々のニーズとリスクに合わせて調整できるため、この事の優れた例です。現時点では、セキュリティリスクの特定、予防、復旧、および対応方法に関する指針を含むサイバーセキュリティ・フレームワークは任意であり、それは誰もそれを守っていないことを意味しています。重要な産業に強制させることは、大きな第一歩です。適切な次のステップは、自動車、医療機器、消費財、重要なインフラのような産業に、より具体的な基準を実装することです。

第二に、私たちは、規制当局に、セキュリティがひどい企業には罰金を課し、健全な法的責任体制をとる必要があります。連邦取引委員会はこれを実施し始めていますが、もっと多くのことができます。それは、セキュリティではないコストをセキュリティのコストよりも大きくする必要があります。つまり、罰金はかなりのものでなければなりません。欧州連合は、この点で先を行っています: 彼らは、包括的なプライバシー法を通過させ、今やセキュリティと安全性に目を向けています。米国は同じことをする事ができ、そうすべきです。

私たちは、企業が自社の製品やサービスに責任を負うことを担保する必要があります。また、不安定(insecurity)による影響を受けた企業は被害を埋め合わせることができます。伝統的に、米国の裁判所は、ソフトウェアの脆弱性に対する賠償を拒否し、データ侵害の影響を受けた人は詳しい損害を証明する事が出来ませんでした。ここでは、私たちは法的損害賠償が必要で、法律の中で説明する損害は、これ以上の証明を必要としません。

最後に、私たちはセキュリティは他のすべてよりも優先させるという包括的なポリシーにする必要があります。インターネットはグローバルに誰もが使用しており、セキュリティを改善することは、犯罪者、テロリスト、ライバル政府など、依然として不安定さが望ましいと思うかも知れない人々を必ず助けるでしょう。ここでは選択肢はありません。コンピュータを脆弱にしにくくすることから得られるセキュリティは、私たちが悪用する可能性のある不安定さを取り除くことで得られるセキュリティよりもはるかに重要です。

規制は避けられません。私たちの選択は、もはや政府規制ありと政府規制無しの間ではなく、賢い政府規制と浅はかな政府規制との間にあります。 政府の規制は恐れるものではありません。規制はイノベーションを阻害するものではなく、私は、セキュリティ技術のマーケットを創出することによって、よく練られた規制がイノベーションを促進すると見ています。

政府が支援のために介入することなく、製品のセキュリティや安全性を大幅に向上させた業界はありません。自動車、飛行機、医薬品、消費財、食品、医療機器、職場、レストラン、そして最近では金融商品など政府規制が必要だったもの全てが安全でセキュアになります。

インターネットの安全とセキュリティの権利を得ることは、正しいことをするために時間と費用を掛ける意思のある人たち、実現しうる最高の法律と政策を導入することを決定する人たちに依存します。インターネットは常に成長し、進化しています。私たちにはセキュリティが適応する時間はまだありますが、次の惨事が発生する前に、迅速に対応する必要があります。政府が飛び込んで支援する時です。明日ではなく、次の週ではなく、来年ではなく、次の大きなテクノロジ会社または政府機関がハッキングされた時ではなく、今なのです。

このエッセイは、ニューヨークタイムズに掲載されています。これは基本的に私の新しい本で話している内容の要約です。

10/14/2018

IPv6ネットワークの運用上のセキュリティ考慮事項 (5)

IPv6のセキュリティにとって必読書というIETF文書(既に期限が切れているが更新はされていない)。

3. 企業固有のセキュリティ考慮事項

企業は、一般的に、既存のIPv4ネットワークを保護するための強力なネットワーク・セキュリティ・ポリシーを用意している。これらのポリシーは、長年にわたるIPv4ネットワークの保護に関する経験的知識から作られている。少なくとも、企業ネットワークは両方のプロトコルバージョンのセキュリティポリシー間で同等でことが推奨される。

企業におけるセキュリティの考慮事項は、外部と内部の2つの部分に大別できる。

3.1. 外部のセキュリティ考慮事項

外面は、企業ネットワークのエッジまたは周辺でサービスプロバイダーのネットワークに適合するセキュリティを提供することを取り扱う。これは、一般に、ステートフル・パケット・インスペクションを備えた専用ファイアウォールまたはACLを備えたルータを実装することによって、セキュリティポリシーを実施することによって実現される。IPv6に容易に移植できるファイアウォールの一般的なデフォルトのIPv4ポリシーは、確立されたセッションなどの特定のトラフィックのみをインバウンドで許可する一方、すべてのトラフィックをアウトバウンドで許可する([RFC6092]も参照)。デフォルトのポリシーを強化できるいくつかの点を次に示す。

  • 境界で内部使用IPv6アドレスをフィルタリングする

  • ボゴンと予約された空間との間のパケットを破棄する。[CYMRU]も参照。

  • NDとPMTUDの適切な操作を可能にする特定のICMPv6メッセージを受け入れる。[RFC4890] も参照。

  • 必要なもの(ホワイトリストアプローチ)のみを受け入れることによって、ESP、AHのような特定の拡張ヘッダーをフィルタリングする(必要なトランスポート層ICMP、TCP、UDPなどを忘れないで頂きたい)。[I-D.gont-opsec-ipv6-eh-filtering]も参照。

  • 境界で不正なIPv6ヘッダーチェーンを持つパケットをフィルタリングする(内部でも可能)。セクション2.2を参照して頂きたい。

  • 境界で不要なサービスをフィルタリングする。

  • アンチ・スプーフィング機能を実装する。

  • 適切なレートリミッタとコントロール・プレーン・ポリサーを実装する。

3.2. 内部のセキュリティ考慮事項

内面は、エンドホストを含むネットワークの境界内のセキュリティを提供することを取り扱う。ここで最も重大な懸案事項は、近隣探索に関するものである。ネットワークレベルでは、セクション2.3で説明したすべてのセキュリティの考慮事項を慎重にレビューし、その上、推奨事項についても詳細に考慮することが推奨される。

セクション2.6.2で説明したように、自動化されたIPv6-in-IP4トンネルを実行する場合は注意が必要である。

ホストは、セキュリティ上の脅威に対して保護するために、セキュリティポリシーで直接ハードニングする必要がある。ホスト・ファイアウォールのデフォルト機能を明確に理解しておく必要がある。特に、IPv4またはIPv6のデフォルトの許可/拒否動作の設定が異なるサードパーティ製ファイアウォール機能が必要である。場合によっては、サードパーティ製のファイアウォールにはIPv6がサポートされていないのに対し、ネイティブ・ファイアウォールにはデフォルトでインストールされている。一般的なデバイスのハードニングのガイドラインはセクション2.8で提供されている。

また、多くのホストがRADIUS、TACACS+、SYSLOGのようなものを運ぶのにIPv4を使用していることにも注意が必要である。これは、運用者側でいくつかの追加レベルのデューデリジェンスを必要とする。

4. サービスプロバイダのセキュリティ考慮事項


4.1. BGP

脅威と緩和テクニックは、IPv4とIPv6で全く同じである。大まかに言えば、

  • TCPセッションの認証

  • TTLセキュリティ(IPv6では、hop-limitセキュリティになる)

  • プレフィックス・フィルタリング

これらはセクション2.5で詳細に説明されている。

4.1.1. Remote Triggered Black Hole Filtering

RTBH [RFC5635]はIPv4とIPv6で同じように動作する。IANAは100::/64を廃棄プレフィックスRFC6666 [RFC6666]として割り当てた。

4.2. 移行メカニズム

SPは通常、移行セクション2.7.2で分析された6rd、6PE、MAP、DS-Liteなどの移行メカニズムを使用する。

4.3. 合法的傍受

合法的傍受の要件は、IPv6とIPv4アーキテクチャで同様であり、様々な地理的地域で施行される法律次第となる。各司法権が持つ地元の問題は、これを難しくする可能性があり、企業の法務担当者とプライバシー担当者の双方が、どのような情報がログに記録され、どのようなログ保持ポリシーが適用されるかについての議論に関与する必要がある。

傍受の対象は、通常、住宅加入者(例えば、彼/彼女のPPPセッションまたは物理回線またはCPE MACアドレス)です。CPEにNATが存在しないため、IPv6には、加入者(/48、/60または/64)のホストセット全体ではなく、一つのホスト(/128ターゲット)からのトラフィックを傍受できるようにする規定がある。

対照的に、モバイル環境では、3GPP仕様ではデバイスごとに/64の割り当てが行われるため、特定の/128ではなく/64からのトラフィックを傍受するだけで十分である(デバイスの電源投入時に新しいIIDが取得されるため)。

情報目的のために書かれたサンプル・アーキテクチャは、[RFC3924]にある。

5. 住宅ユーザのセキュリティ懸念事項

IETF Homenetワーキンググループは、IPv6の住宅ネットワークをどのように行うべきかを検討している。これには明らかに運用上のセキュリティ上の考慮事項が含まれる。しかし、これはまだ作業が進行中である。

住宅ユーザーは、通常、セキュリティやネットワーキングに関する経験と知識が少なくなっている。最近のホスト、スマートフォン、タブレットのほとんどがデフォルトですべてのIPv6を有効にしているため、IPv6セキュリティはこれらのユーザーにとって重要である。IPv4のみのISPであっても、これらのユーザーはTeredoトンネルの助けを借りてIPv6インターネットアクセスを取得できる。いくつかのピアツーピア・プログラム(特にBittorrent)はIPv6をサポートしており、これらのプログラムはIPv4住宅ゲートウェイを介してTeredoトンネルを開始することができ、内部ホストをインターネット上のIPv6ホストから到達できるようにする。従って、すべてのホストセキュリティ製品(パーソナルファイアウォール、…)にデュアルスタック・セキュリティポリシーを設定することをお勧めする。

住宅ゲートウェイにIPv6接続がある場合、[RFC7084]([RFC6204]を廃止)はIPv6 CPEの要件を定義し、[RFC6092]で定義されているデフォルトのIPv6セキュリティポリシーの議論に対して立場をはっきりさせていない。

  • アウトバウンドのみ: 内部で開始されたすべての接続を許可し、外部から開始されたすべての接続をブロックする。これは、IPv4住宅ゲートウェイがNAT-PTを実行する一般的なデフォルトのセキュリティポリシーですが、IPv6のエンドツーエンドの到達可能性の約束を破る。[RFC6092]は、そのようなCPEを設計するためのいくつかの推奨事項を列挙している。

  • オープン/トランスペアレント: 内部および外部で開始されたすべての接続を許可するため、IPv6トラフィックに対してインターネットのエンドツーエンドの特質が戻るが、IPv6ではIPv4とは異なるセキュリティポリシーが適用される。

[RFC6092] REC-49は、これら2つの方針のうちいずれかの選択肢をユーザに与えなければならないと述べている。

Swisscomが特に展開した代替ソリューションもある。脆弱として知られているTCPおよびUDPポートを除いて、すべての送信および受信接続に開放されている。

6. さらなる情報

IPv6ネットワークのセキュリティをより詳細に記述する文書がいくつかある。これらのドキュメントはIETFによって作成されたものではないが、便宜のためにここに記載する:

  1. Guidelines for the Secure Deployment of IPv6 [NIST]

  2. North American IPv6 Task Force Technology Report - IPv6 Security Technology Paper [NAv6TF_Security]

  3. IPv6 Security [IPv6_Security_Book]

IPv6ネットワークの運用上のセキュリティ考慮事項 (4)

IPv6のセキュリティにとって必読書というIETF文書(既に期限が切れているが更新はされていない)。

2.6. ロギング/監視

セキュリティ・インシデントが発生した場合、フォレンジック調査を実施するため、または異常な動作を検出するため、ネットワーク事業者は複数の情報を記録する必要がある。

これは次を含む:

  • 利用可能なすべてのアプリケーションのログ(例えば、Webサーバー);

  • IPfixとしても知られるIPフロー情報のエクスポート[RFC7011]の利用;

  • SNMP MIB [RFC4293]の利用;

  • ネイバー・キャッシュの利用;

  • ステートフルDHCPv6 [RFC3315]リースキャッシュの利用、特にレイヤー2スイッチのリレーエージェント[RFC6221]が使用されている場合;

  • アカウンティングの記録のためにRADIUS [RFC2866]の利用;

それらのログがどのように収集され、保管され、安全に廃棄されるかに関して、プライバシー問題があることに注意して頂きたい。事業主は自国の法律を確認することが求めらる。

これらの情報はすべて次の目的で使用される;

  • 誰がいつ何をしたのかなどのフォレンジック(セクション2.6.2.1)調査?

  • 相関関係(セクション2.6.2.3): どのIPアドレスが特定のノードによって使用されたか(プライバシー拡張アドレス[RFC4941]の使用を前提とする)

  • インベントリ(セクション2.6.2.2): どのIPv6ノードがネットワーク上にあるか?

  • 異常行動検出(セクション2.6.2.4): 異常なトラフィック・パターンは、しばしば潜在的な攻撃(サービスの拒否、ネットワークスキャン、ノードがボットネットの一部である、など)の異常な動作の症状である

2.6.1. データソース

このセクションでは、運用上のセキュリティに役立つ最も重要なデータソースを示す。

2.6.1.1. アプリケーションのログ

これらのログは通常、リモートのIPv6アドレスがすべての文字(バイナリではない)に格納されているテキストファイルである。1つのIPv6アドレス2001:db8::1は、次のように複数の方法で記述できるので、処理が複雑になる。

  • 2001:DB8::1 (大文字で)

  • 2001:0db8::0001 (先頭に0が付く)

  • FQDN(信頼されるべきではない)への逆DNSマッピングを含む多くの方法がある。

RFC 5952 [RFC5952]は、この問題を詳細に説明し、一つの基準形式の使用を推奨している(つまり、小文字を使用し、先頭の0を抑制する)。このメモは、可能なすべてのケースでIPv6アドレスのための基準形式[RFC5952]の使用を推奨する。既存のアプリケーションが基準形式でログに記録できない場合、このメモではすべてのIPv6アドレスを標準化するために外部プログラムを使うことを推奨している。

例えば、このperlスクリプトを使用できる:

#!/usr/bin/perl -w
   use strict ;
   use warnings ;
   use Socket ;
   use Socket6 ;

   my (@words, $word, $binary_address) ;

   ## go through the file one line at a time
   while (my $line = <STDIN>) {
     chomp $line;
     foreach my $word (split /[\s+]/, $line) {
       $binary_address = inet_pton AF_INET6, $word ;
       if ($binary_address) {
         print inet_ntop AF_INET6, $binary_address ;
       } else {
         print $word ;
       }
       print " " ;
     }
     print "\n" ;
   }

2.6.1.2. IPv6ルータによるIPフロー情報エクスポート

IPfix [RFC7012]は、セキュリティに役立ついくつかのデータ要素を定義している:

  • セクション5.4(IPヘッダーフィールド): nextHeaderIPv6とsourceIPv6Address;
  • セクション5.6(サブIPフィールド): sourceMacAddress

さらに、IPfixは、データの取り扱いと運び方に関して非常に効率的である。また、特定のsourceMacAddressに関連付けられた集約データを得るために、sourceMacAddressなどをキーにフローを集約することもできる。このメモは、IPfixの利用と、nextHeaderIPv6、sourceIPv6Address、およびsourceMacAddressでの集約を推奨している。

2.6.1.3. IPv6ルータによるSNMP MIB

RFC 4293 [RFC4293]は、IPの2つのアドレスファミリの管理情報ベース(MIB)を定義している。このメモは以下を使用することを推奨する:

  • インターフェイスごとにトラフィックカウンタを収集するipIfStatsTableテーブル
  • ipNetToPhysicalTableテーブルは、ネイバー・キャッシュの内容、すなわちIPv6とデータリンク層アドレスとの間のマッピングである

2.6.1.4. IPv6ルータのネイバーキャッシュ

ルータのネイバーキャッシュには、IPv6アドレスとデータリンク層アドレスの間のすべてのマッピングが含まれている。これは通常、次の2つの方法で利用できる。

  • 上記で説明したSNMP MIB(セクション2.6.1.3);
  • ネイバーキャッシュの状態を収集するためにNETCONF RFC6241 [RFC6241]を使用する;
  • セキュアな管理チャネル(SSHなど)を介して接続し、コマンドライン・インターフェイスまたはその他の監視メカニズムを使用して明示的にネイバーキャッシュ・ダンプを要求することによっても実行できる

新しいIPv6アドレスが(プライバシ拡張アドレス[RFC4941]が頻繁に使用される)ネットワーク上に現れた時、あるいは状態がUNREACHから削除された時(Neighbor Unreachability Detectionアルゴリズムによる削除のデフォルトの時間は、Windows 7など一般的なホストでは38秒です)に、マッピングが追加されるネイバーキャッシュは極めてダイナミックである。ネイバーキャッシュの内容が安全を期して後で使用するために、30秒ごとに定期的に取得して保存されなければならないことを意味する。

これは情報の重要な情報源です(SAVI [RFC7039]アルゴリズムを使用しないスイッチ上では)データリンク層アドレスとIPv6アドレスとの間のマッピングを無効にすることは取るに足らないことなので、これは重要な情報源である。前のステートメントを言い換えてみる: ネイバーキャッシュの現在および過去の内容にアクセスすることは、フォレンジックや監査証跡のための最も重要な値を持っている。

ホストあたり一つの/64(セクション2.1.7)のアプローチを使用すると、IPv6スプーフィングを防止するために、ルーターとスイッチの厳格な施行規則と組み合わせた時に、ネイバーキャッシュ・ダンプが割り当てられた/64プレフィックスの単なるキャッシングによって置き換えられる。

2.6.1.5. ステートフルDHCPv6リース

一部のネットワークでは、IPv6アドレスはクライアントにIPv6アドレスをリースするステートフルDHCPv6サーバー[RFC3315]によって管理される。実際、IPv4のDHCPと非常によく似ているので、IPv4アドレスで通常行われていたように、IPv6アドレスとデータリンク層アドレスの間のマッピングを発見するために、このDHCPリースファイルを使用して試すことができる。

全てのノードがDHCPv6を使用するわけではないため(ステートレス自動設定のみ可能なノードがある)、IPv6時代はそれほど簡単ではない。しかし、DHCPv6クライアントは、IPv4のようにハードウェア・クライアント・アドレスではなく、複数の形式を持つことができるDHCP固有ID(DUID)によって識別されるためだ: 一部はデータリンク層アドレスであり、一部は時間情報が付加されたデータリンク層アドレスであるか、または運用セキュリティには役に立たない不透明な数字でさえある。さらに、DUIDがデータリンク・アドレスに基づく場合、このアドレスはクライアントの任意のインタフェース(クライアントが実際に有線インタフェースを使用してネットワークに接続する間の無線インタフェースなど)になる。

軽量のDHCPリレーエージェント[RFC6221]がレイヤー2スイッチで使用されている場合、DHCPサーバーは特定のリースされたIPv6アドレスを受け取ったスイッチのインタフェースを識別するために保存できるインタフェースID情報も受信する。また、リレーエージェントRemote-ID [RFC4649]またはRFC6939 [RFC6939]のオプションにデータリンク層アドレスを追加すると、通常の(軽量ではない)リレーエージェントによって、DHCPv6サーバがデータリンクやリースされたIPv6アドレスを追跡することができる。

データリンク層アドレスとIPv6アドレスとの間のマッピングは、SAVI [RFC7513]アルゴリズムを実装するスイッチを使用することによって確保することができる。もちろん、これは、[IEEE-802.1X]のようなレイヤ2メカニズムを使用してデータリンク層アドレスを保護することも必要とする。

2.6.1.6. RADIUSのアカウンティング・ログ

ユーザがRADIUS [RFC2866]サーバを介して認証されたインタフェースで、RADIUSアカウンティングが有効になっている場合、RADIUSサーバは、ユーザによって使われる全てのIPv6(とIPv4)アドレスを含むアカウンティングAcct-Status-Typeレコードを接続の開始時と終了時に受信する。この技術は、特にWi-Fi Protected Address(WPA)を備えたWi-Fiネットワーク、またはイーサネット・スイッチ上の他のIEEE 802.1X [IEEE-802.1X]有線インタフェースで使用できる。

2.6.1.7. 他のデータソース

IPv4ネットワークとまったく同じように保たなければならない他のデータソースがある:

  • IPv6アドレスのリモートアクセスVPNのユーザーへの履歴マッピング;
  • 有線ネットワーク内のスイッチ・インタフェースへのMACアドレスの履歴マッピング

2.6.2. 集めたデータの利用

このセクションでは、いくつかのセキュリティ上の利点を達成するために、前述のように収集されたデータ(セクション2.6.1)を活用する。

2.6.2.1. フォレンジック

フォレンジックのユースケースは、ネットワークオペレータが特定の時間にネットワークに存在していたIPv6アドレス、または現在ネットワークに存在するIPv6アドレスを特定する必要がある場合である。

情報のソースは多いものから順に、ネイバーキャッシュ、DHCPリースファイルになる。次に、手順は次のとおり。

  1. IPv6アドレスのIPv6プレフィックスに基づいて、このプレフィックスに到達するために使用されるルータを見つける(アンチ・スプーフィング・メカニズムが使用されていると仮定する);

  2. インシデントの時刻と、ネイバーキャッシュの履歴データから、最新のネイバーキャッシュからデータリンク・アドレスを取得するためのIPv6アドレスに基づき、この限定されたルータ一式にベースに;

  3. インシデント時間とIPv6アドレスに基づいて、DHCPリースファイル(セクション2.6.1.5)からデータリンクアドレスを取得する;

  4. データリンク層アドレスに基づいて、どのスイッチ・インターフェースがこのデータリンク層アドレスであるかを調べる。無線LANの場合、RADIUSログはユーザIDとMACアドレスの間のマッピングを持つ必要がある。データリンク層アドレスとスイッチポートとの間のマッピングには、構成管理データベース(CMDB)が使用される場合がある。

プロセスが終了すると、悪意のある活動を生成したホストのインタフェース、あるいは悪意のある活動のために悪用されたユーザ名が断定できる。

2.6.2.2. インベントリ

RFC 7707 [RFC7707](RFC 5157 [RFC5157]を廃止)は、リンクごとに膨大な数のIPv6アドレスがあるため、攻撃者はIPv6ネットワークをスキャンする困難さに関することです。大規模なアドレス空間は、IPv4ネットワーク(単純にすべてのIPv4アドレスを列挙し、その後にpingとTCP/UDPポートスキャンを行う)で行うのは些細なことだが、IPv6ネットワークと認識されることがある。接続されたすべてのデバイスのインベントリを取得することは、ネットワークのセキュアな運用にとって最も重要である。

IPv6ネットワークのインベントリを作成する方法はたくさんある。

最初の手法は、IPfix情報を使用して、すべてのIPv6送信元アドレスのリストを抽出して、ルータ経由でパケットを送信したすべてのIPv6ノードを見つけることである。これは非常に効率的だが、残念なことに、そのようなパケットを送信しなかったサイレントノードは検出されない...。また、リンクローカルアドレスはこの手段で決して発見することはできないことに注意しなければならない。

第2の方法は、収集されたネイバーキャッシュのデータを使用して、キャッシュ内のすべてのIPv6アドレスを見つけることである。このプロセスは、すべてのリンクローカルアドレスも検出する。セクション2.6.1.4を参照。

別の方法は、ローカルネットワークに対してのみ機能し、ネットワーク上のすべてのIPv6ノードであるリンクローカル・マルチキャストアドレスff02:1にICMP ECHO_REQUESTを送信することである。すべてのノードは[RFC4443]に従ってこのECHO_REQUESTに返答する。

他の手法では、DNSからデータを取得し、ログファイルを解析し、mDNS RFC6762 [RFC6762]やRFC6763 [RFC6763]などのサービス発見機能を利用する。

DNSゾーンを列挙すること、特に逆DNSレコードとCNAMESを調べることは、さまざまなツールで使用されるもう1つの一般的な方法である。RFC7707 [RFC7707]ですでに説明されているように、これにより、攻撃者はIPv6逆DNSツリーを整理し、実現可能な時間で列挙することができる。さらに、ゾーン転送(AXFR)を許可する権威サーバーは、さらに情報源となる可能性がある。

2.6.2.3. 相関関係

IPv4ネットワークでは、複数のログを関連付けるのは簡単である(例えば、特定のIPv4アドレスに関連するイベントを検索するなど)。単純なUnix grepコマンドは、複数のテキストベースのファイルをスキャンし、特定のIPv4アドレスに関連するすべての行を抽出するのに十分だった。

IPv6ネットワークでは、異なる文字列が同じIPv6アドレスを表すことができるため、これはやや困難である。従って、単純なUnixのgrepコマンドは使用できない。さらに、IPv6ノードは複数のIPv6アドレスを持つことができる。

IPv6関連のログで相関分析を行うには、標準のIPv6アドレスを持つすべてのログを用意することを推奨する。次に、IPv6アドレスのデータリンク層アドレスを見つけるために、ネイバーキャッシュの現在(または履歴)データセットを検索する必要がある。次に、このデータリンク層アドレスに関連付けられたすべてのIPv6アドレスを検索する必要がある。これが検索セットになる。最終段階は、検索セット内の任意のIPv6アドレスについて、すべてのログファイル(基準形式のIPv6アドレスのみを含む)を検索する。

2.6.2.4. 異常な挙動の検知

異常な挙動(ネットワークスキャン、スパム、サービス拒否など)は、IPv4ネットワークと同じ方法で検出できる。

  • インタフェース・カウンタ(SNMP)、あるいはIPfixレコード[RFC7012]から集約されたトラフィックによって検出されたトラフィックの急増;

  • IPfix [RFC7012]の使用によるトラフィック・パターンの変更(1秒あたりの接続数、1ホストあたりの接続数...)

2.6.3. 要約

IPv4で使用されるいくつかのデータソース(IPfix、MIB、スイッチCAMテーブル、ログなど)は、IPv6ネットワークのセキュアな運用にも使用されるが、DHCPv6リースファイルは信頼できず、ネイバーキャッシュが最も重要である。

同じIPv6アドレスを文字列に表現する方法が複数あるという事実は、相関処理を行わなければならない場合、フィルタの使用を必須である。

2.7. 移行/共存の技術

ネットワークは純粋なIPv6のみの方法では実行されないことが予想されるため、様々な移行メカニズムをセキュアな方法で導入して運用する必要がある。このセクションでは、最もよく知られていて導入されている移行技術の運用ガイドラインを提案する。

2.7.1. デュアルスタック

デュアルスタックは、6PE RFC4798 [RFC4798]がかなり一般的な場所であるMPLSコアのない既存のほとんどのネットワーク事業者にとって、最初に導入する選択肢である。ネットワークのデュアルスタックは、他の移行メカニズムに比べていくつかの利点を提供する。第1に、既存のIPv4動作への影響が低減される。第2に、トンネルやアドレス変換が存在しない場合、IPv4とIPv6のトラフィックはネイティブで(観測しやすい)、同じネットワーク処理(パス、サービス品質など)を持つ必要がある。デュアルスタックは、IPv6ネットワークが実現可能時期の準備が整うと、徐々にIPv4の動作を停止させることができる。一方、オペレータは複雑さが加わった2つのネットワークを管理する必要がある。

運用上のセキュリティの観点から、これは今ではあなたが2倍の露出を持っていることを意味する。今、両方のプロトコルを保護することについて考える必要がある。最低限、デュアルスタック・ネットワークのIPv6部分は、セキュリティポリシーの観点から、IPv4を同等にメンテナンスする必要がある。通常、エッジでIPv4ネットワークを保護するには、次の方法が使用される:

  • トラフィックを許可または拒否するACL
  • ステートフル・パケット・インスペクション機能を備えたファイアウォール

これらのACLおよび/またはファイアウォールは、IPv6通信を保護するために追加設定することをお勧めする。また、IPv6が提供するエンドツーエンドの接続性を考慮すると、ホストは脅威に対して要塞化することが推奨される。一般的なデバイスのハードニングのガイドラインはセクション2.8で提供されている

長年、すべてのホスト・オペレーティング・システムはIPv6がデフォルトで有効になっているため、IPv4専用ネットワークでも、IPv6リンクローカルアドレス経由でレイヤ2の隣接犠牲者を攻撃することも、グローバルIPv6アドレスを悪用することも、不正なDHCPv6アドレスは攻撃者によって提供することも可能である。

2.7.2. 移行メカニズム

特定のユースケースには多くのトンネルが使用されている。IPsec [RFC4301]によって保護されている場合を除き、これらのトンネルには2〜3のセキュリティ問題がある(そのほとんどはRFC 6169 [RFC6169]に記述されている)。

  • トンネル・インジェクション: いくつかの情報(例えば、トンネルエンドポイントや使用されているプロトコルなど)を知っている悪意のある人物は、宛先トンネルエンドポイントが喜んで受け入れる正当で有効なカプセル化パケットのようなパケットを偽造することができる。これは特定のスプーフィングの場合である。

  • トラフィック傍受: トンネルプロトコル(IPsecを使用しない)によって機密性が提供されないため、トンネルパス上の誰でもトラフィックを傍受して、平文のIPv6パケットにアクセスできる。認証がない場合と組み合わせて、中間者攻撃を仕掛けることが可能である。

  • サービスの窃盗: 認証されていないため、許可されていないユーザでもトンネルリレーを自由に使用できる(これはトンネル・インジェクションの特定のケースです)。

  • リフレクション攻撃: トンネルインジェクションの別の特定のユースケースで、攻撃者は、IPv6アドレスと一致しないIPv4宛先アドレスを持つパケットを注入して、最初のトンネルエンドポイントがパケットを宛先に再カプセル化し直すことで引き起こされる。

  • セキュリティポリシーのバイパス: ファイアウォールやIPSがトンネルのパス上にある場合、おそらくトンネルに含まれる悪意のあるIPv6トラフィックを検出しない。

セキュリティポリシーのバイパスを緩和するため、すべてのIPv4トラフィックの一致を拒否することによって、すべてのデフォルト設定トンネルをブロックすることを推奨する:

  • IPプロトコル41: ISATAP(セクション2.7.2.2)、6to4(セクション2.7.2.7)、6rd(セクション2.7.2.3)、および6in4(セクション2.7.2.1)のトンネルをブロックする;

  • IPプロトコル47: これはGRE(セクション2.7.2.1)のトンネルをブロックする;

  • UDPプロトコル3544: Teredo(セクション2.7.2.6)トンネルのデフォルトのカプセル化がブロックされる。

イングレス・フィルタリング[RFC2827]は、IPv6アドレスのなりすましを防ぐために効力があれば、すべてのトンネルエンドポイントにも適用すべきである。

いくつかのトンネル技術が同じカプセル化(すなわちIPv4プロトコル41)を共有し、IPv4アドレスをIPv6アドレスに埋め込むため、RFC6324 [RFC6324]に記載されている一連のよく知られているループ攻撃があり、このRFCは緩和技術も提案する。

2.7.2.1. サイト間の静的トンネル

サイト間の静的トンネルは、RFC 2529 [RFC2529]およびGRE [RFC2784]に記述されている。IPv4エンドポイントは静的に設定されており、動的ではないため、わずかにセキュリティが強化されているが(双方向サービス窃盗はほとんど不可能だが)、トラフィック傍受とトンネル注入はそれでも可能である。従って、トランスポートモードでIPsec [RFC4301]を使用し、カプセル化されたIPv4パケットを保護することが、これらのトンネルに推奨される。代わりに、トンネルモードのIPsecを使用して、信頼されていないIPv4ネットワークを介してIPv6トラフィックを転送することもできる。

2.7.2.2. ISATAP

ISATAPトンネル[RFC5214]は、主に一つの管理ドメイン内で使用され、一つのIPv6ホストをIPv6ネットワークに接続する。つまり、エンドポイントとトンネルエンドポイントは通常、一つのエンティティによって管理される。従って、通常、監査証跡(audit trail)と厳密なアンチ・スプーフィングは可能であり、これによりセキュリティ全体が向上する。

RFC6324 [RFC6324]とRFC6964 [RFC6964]の方策を実装することによって、攻撃を回避するために特別な注意が払われなければならない。

トランスポートまたはトンネルモードのIPsec [RFC4301]は、IPv6トラフィックの機密性を提供し、サービス窃盗を防ぐためにIPv4 ISATAPトラフィックを保護するのに使用できる。

2.7.2.3. 6rd

6rdのトンネルは6to4トンネル(セクション2.7.2.7)と同じカプセル化を共有するが、一つのSPドメイン内で使用するように設計されている。言い換えれば、6to4トンネルよりも制約の厳しい環境に導入され、機密性不足を除いてセキュリティ上の問題はほとんどない。RFC5969 [RFC5969]のセキュリティの考慮事項(セクション12)は、6rdのトンネルをセキュアにする方法を説明している。

機密性が重要であれば、運ばれたIPv6トラフィックのためのIPsec [RFC4301]を使うことができる。

2.7.2.4. 6PEと6VPE

コアにMPLSを使用する組織は、6PE [RFC4798]と6VPE RFC4659 [RFC4659]を使用して、MPLS上でIPv6アクセスを有効にすることもできる。6PEと6VPEはRFC4364 [RFC4364]に記述されているBGP/MPLS IP VPNと確かに似ているので、これらのネットワークのセキュリティもRFC4381 [RFC4381]に記述されているものと似ている。

次を頼りする:

  • VRFの助けを借りてアドレス空間、ルーティングおよびトラヒックの分離(6VPEのみに適用)。

  • IPv4コアを隠して、Pルータに対するすべての攻撃を取り除く。

  • 6PEと6VPEの場合、CEとPE間のルーティング・プロトコルを保護するために、リンクローカルアドレス([RFC7404]を参照)を使用することができる。これらのアドレスはリンクの外部から到達できないため、6PEと6VPEのセキュリティは IPv4 BGP/MPLS IP VPNよりもさらに高い。

2.7.2.5. DS-Lite

DS-Liteは移転メカニズムであるため、このドキュメントの中でさらに分析されている(セクション2.7.3.3)。

2.7.2.6. Teredo

Teredoトンネル[RFC4380]は主に住宅環境で使用される。これは、UDPカプセル化のおかげでIPv4 NAT-PTデバイスを容易に超え、単一のホストをIPv6インターネットに接続する。Teredoは、他のトンネルと同じ問題を抱えている。認証なし、機密性なし、スプーフィングとリフレクション攻撃の可能性がある。

トランスポートされたIPv6トラフィックのためのIPsec [RFC4301]が推奨される。

Teredoへの最大の脅威は、おそらくIPv4専用ネットワークのため、ステートフルなファイアウォールと共にかなりの頻度でコロケーションされるIPV4 NAT-PTデバイスを容易に通過するように設計されていることだ。従って、ステートフルなIPv4ファイアウォールは無制限のUDP発信を許可し、UDPトラフィックの戻りを受け入れる場合、Teredoは実際にインターネットへのすべてのIPv6トラフィックとインターネットからこのファイアウォールの穴を突き抜ける。ホストのポリシーで、このファイアウォールのバイパスを回避するためにIPv4専用ネットワークでTeredoをブロックするように展開できるが、可能であれば、IPv4ファイアウォールですべてのUDP発信トラフィックをブロックする方が効率的だ(もちろん、少なくともポート53は DNSトラフィックのために開いたままにしておく)。

Teredoは現在ほとんど使用されておらず、ほとんどの環境で自動化されていないため、脅威にはならない。

2.7.2.7. 6to4

6to4トンネル[RFC3056]は正しく動作するためには、グローバルにルーティング可能なIPv4アドレスが必要である。それらは、IPv6インターネットへの1つのIPv6ホスト接続または複数のIPv6ネットワーク接続のいずれかを提供するために使用される。6to4リレーは通常、RFC3068 [RFC3068]で定義されているエニキャスト・アドレスであり、RFC7526 [RFC7526]によって廃止され、最近のオペレーティングシステムでは使用されなくなった。いくつかのセキュリティの考慮事項はRFC3964 [RFC3964]で説明されている。

RFC6343 [RFC6343]は、オペレータがよく管理されたサーバと6to4リレーを提供する場合、カプセル化されていないIPv6パケットは、セキュリティメカニズムが適用される明確なポイント(これらのサーバとリレーのネイティブIPv6インターフェイス)を通過することを指摘している。デフォルトでの6to4のクライアント使用は現在は推奨されておらず、運用上の問題を回避するために重要な予防措置が必要である。

2.7.2.8. Mapping of Address and Port

アドレスとポートのマッピング(MAP-E [RFC7597]とMAP-T [RFC7599])のカプセル化と変換バージョンでは、アクセスネットワークは純粋にIPv6ネットワークであり、MAPプロトコルは加入者ネットワーク上でIPv4ホストを与えるために使用され、インターネット上のIPv4ホストにアクセスする。加入者ルータは、すべての内部IPv4アドレスとレイヤ4ポートを、MAP設定プロセスで受信したIPv4アドレスとレイヤ4ポートにマッピングするのに、ステートフルな動作を行う。SP機器は常にステートレス操作(デカプセリングまたはステートレス変換)を行う。従って、セクション2.7.3.3とは対照的に、状態がなく、新しいレイヤー4接続(ロギング操作なし)に起因する操作がないため、SP機器に対するState-exhaustion DoS攻撃はない。

SP MAP装置は[RFC7597]のすべてのセキュリティ問題を実装しなければならない。特に、IPv4アドレスとポートのマッピングが設定と一致することを保証する。MAPには予測可能なIPv4アドレスとポートマッピングがあるため、監査ログは管理しやすくなる。

2.7.3. 変換メカニズム

IPv4とIPv6ネットワークの間の変換メカニズムは、ネットワークがIPv6に移行する際の代替共存戦略である。フレームワークは[RFC6144]に記述されているが、具体的なセキュリティの考慮事項は個々のメカニズムに記録されている。 ほとんどの場合、IPsecまたはDNSSECの導入への干渉、スプーフされたトラフィックの軽減方法、効果的なフィルタリング戦略の可能性について特に言及している。

2.7.3.1. キャリアグレードNat (CGN)

NAT444 CGNまたはLarge Scale NAT(LSN)またはSP NATとも呼ばれるキャリアグレードNAT(CGN)は、[RFC6264]に記述されており、有効なIPv6ソリューションを導入できるまで、大規模なサービスプロバイダー・ネットワークの中でIPv4の使用を延長するための暫定手段として利用されている。[RFC6598]は、特定のIANA割り当て/10 IPv4アドレスブロックを、CGNを使用するすべてのアクセスネットワークが共有するアドレス空間として使用するように要求した。これは100.64.0.0/10として割り当てられている。

[RFC6269]のセクション13は、大規模なアドレス共有によって引き起こされるいくつかの特定のセキュリティ関連の問題をリストアップしている。[RFC6598]のセキュリティの考慮事項セクションには、共有アドレス空間の潜在的な誤用のためのいくつかの特定の緩和手法も記載されている。一部の法執行機関は、CGNがサイバー犯罪捜査を妨げると判断している(例えば、CGNに関するユーロポールのプレスリリース[europol-cgn])。

RFC7422 [RFC7422]は、CGNのロギング要件を減らすために決定論的アドレスマッピングの使用を示唆している。この考え方は、内部加入者をパブリック・ポートに前後にマッピングするアルゴリズムを持つことである。

2.7.3.2. NAT64/DNS64

ステートフルNAT64変換[RFC6146]は、IPv6専用クライアントがユニキャストUDP、TCP、またはICMPを使用してIPv4サーバに接続できるようにする。既存のAレコードからAAAAレコードを合成するメカニズムであるDNS64 [RFC6147]と併用する必要がある。また、ステートレスなNAT64 [RFC6145]もある。これは、ステートレスなので、state exhaustion攻撃を受けにくいという利点があり、セキュリティ面でも同様である。

[RFC6146]と[RFC6147]のセキュリティ考慮事項セクションは包括的な問題をリストアップする。NAT64の使用に関する特定の問題は、UDPカプセル化が使用されていない限り、ほとんどのIPsecの導入を妨げることである。DNS64は[RFC7050]のセクション3.1を見てDNSSECに発生率(incidence)を持っている。

2.7.3.3. DS-Lite

Dual-Stack Lite (DS-Lite) [RFC6333]は、サービスプロバイダが2つのよく知られた技術、IP in IP (IPv4-in-IPv6)とNetwork Address and Port Translation (NAPT)を組み合わせることで、顧客間でIPv4アドレスを共有することを可能にする移行技術である。

DS-Liteに関するセキュリティの考慮事項は、主にデータのロギング、不正なデバイスからのDoS攻撃(AFTR機能はステートフルなので)を防ぎ、AFTRによって提供されるサービスを登録済みの顧客に限定することを主眼にしている。

[RFC6333]のセクション11は、この技術に関連する重要なセキュリティ問題を記述する。

2.8. 一般デバイスのハーデニング

悪意のあるトラフィックを重要なホストにアクセスできないようにするため、ネットワーク・インフラに過剰に依存する多くの環境がある。新しいIPv6の導入では、IPv6トラフィックが有効になっているが、標準的なアクセス制御メカニズムがIPv6デバイスアクセスで有効になっていないことがよくある。ネットワークデバイスの設定ミスやインターネット全体でのIPv6の成長の可能性があるため、すべての個々のデバイス悪意のある行為に対して堅牢化されていることを確認することが重要である。

個々のコンピュータまたはルータ、ファイアウォール、ロードバランサ、サーバなどのデバイスであれば、ホストを適切に堅牢化するために、次のガイドラインを使用すべきである。

  • デバイスが権限を与えられた個人にアクセスするの制限する

  • デバイスへのアクセスの監視と監査

  • エンドノード上の未使用のサービスをすべてオフにする

  • 必要に応じて、エンドノードの未使用のサービスからトラフィックを取得し、デフォルトを変更するために使用されているIPv6アドレスを理解する

  • 可能であれば、デバイス管理に暗号で保護されたプロトコルを使用する(SCP、SNMPv3、SSH、TLSなど)

  • ホストのファイアウォール機能を使用して、上位層のプロトコルで処理されるトラフィックを制御する

  • ウイルススキャナを使用して悪意のあるプログラムを検出する

IPv6ネットワークの運用上のセキュリティ考慮事項 (3)

IPv6のセキュリティにとって必読書というIETF文書(既に期限が切れているが更新はされていない)。

2.4. コントロール・プレーンのセキュリティ

RFC6192 [RFC6192]はルータ・コントロール・プレーンを定義する。ここではこの定義を読者の便宜のために繰り返す。

現代のルータ・アーキテクチャのデザインは、フォワーディングとルータ・コントロール・プレーンのハードウェアおよびソフトウェアの厳密な分離を支持している。ルータ・コントロール・プレーンはルーティング機能とマネージメント機能をサポートしている。一般的には、デバイス自体に宛てられたパケットを処理し、デバイス上でローカルに発信されたパケットを作って送信するためにルータ・アーキテクチャのハードウェアおよびソフトウェア・コンポーネントとされている。フォワーディング・プレーンは、通常、入力インタフェース上でパケットを受信し、宛先に向かう最も良い出力インタフェースを決定し、適切な出力インタフェースを介してパケットを転送するパケットのIPネクストホップを識別するために探索を実行するルータ・アーキテクチャ・ハードウェアおよびソフトウェア・コンポーネントとして説明されている。

フォワーディング・プレーンは通常高速ハードウェアで実装されますが、コントロール・プレーンは汎用プロセッサ(ルータプロセッサRPという名前)によって実装され、パケットを高速で処理することはできない。従って、このプロセッサは、入力キューを処理できる以上のパケットでフラッディングすることによって攻撃を受ける可能性がある。コントロール・プレーンのプロセッサは有効なコントロール・パケットを処理できず、ルータはOSPFまたはBGP隣接関係を失い、重大なネットワーク障害を引き起こす可能性がある。

緩和手法は次の通り:

  • RPにキューイングされる前に非合法のコントロール・パケットをドロップする(これはフォワーディング・プレーンACLによって実行できます)、そして

  • 残りのパケットをRPが維持できる速度に制限する。プロトコル特有の保護も行わなければなりません(例えば、スプーフィングされたOSPFv3パケットがDijkstraアルゴリズムの実行を引き起こす可能性があるため、Dijsktra実行の回数も制限する)。

このセクションは、コントロール・パケットのいくつかのクラスを検討する:

  • コントロール・プロトコル: ルーティング・プロトコル: 例えば、OSPFv3、BGP、そして拡張隣接探索やICMPなど

  • マネージメント・プロトコル: SSH、SNMP、IPfixなど

  • パケット例外: 例えば、packet-too-big ICMPメッセージを生成する、またはホップバイホップ・オプション・ヘッダを有するなど、特定の処理を必要とする通常のデータパケットである。

2.4.1. コントロール・プロトコル

このクラスには、OSPFv3、BGP、NDP、ICMPを含みます。

すべてのルータ・インタフェースに適用される入力ACLは、以下のように設定されるべきである。

  • 非リンクローカルアドレスからのOSPFv3(Next-Headerが89であると識別される)およびRIPng(UDPポート521によって識別される)パケットをドロップする

  • すべてのBGPネイバーからのBGP(TCPポート179で識別される)パケットを許可し、他のBGPネイバーをドロップする

  • (トランジットおよびルータインターフェイスへの) すべてのICMPパケットを許可する

注意: ACLがIPsec ESPまたはAH拡張ヘッダーを解析できないルータでは、IPsecによって認証されたOSPFv3パケットをドロップすることは不可能である。

有効なパケットの帯域制限が行われるべきです(SHOULD)。要求する設定は、言うまでもないがルートプロセッサのパワーに依存する。

2.4.2. マネージメント・プロトコル

このクラスには、SSH、SNMP、syslog、NTPなどを含む。

すべてのルータインタフェースに適用される入力ACLは、以下のように設定されるべきである:

  • 使用されているプロトコルに属するものを除いて、ルータ宛てのパケットをドロップする(例えば、TCP 22を許可し、SSHのみを使用する場合はすべてをドロップする)。

  • 送信元がセキュリティポリシーと一致しないパケットをドロップします。例えば、SSH接続をNOCから発信するだけの場合、ACLはNOCプレフィックスからのTCPポート22パケットのみを許可すべきである。

有効なパケットの帯域制限が行われるべきである。要求する設定は、言うまでもないがルートプロセッサのパワーに依存する。

2.4.3. パケット例外

このクラスは、データプレーン・パケットが特定の処理を必要とするため、ルートプロセッサにパントされる複数の事例をカバーする:

  • データプレーンパケットが大き過ぎるためにフォワーディングできない場合、ICMP packet-too-bigメッセージが生成する。

  • そのhop-limitフィールドが0に達したためにデータ・プレーン・パケットをフォワーディングできない場合、ICMP hop-limit-expiredメッセージを生成する。

  • データ・プレーン・パケットが何らかの理由でフォワーディングされない場合、ICMP destination-unreachableメッセージを生成する。

  • ホップバイホップ・オプション・ヘッダーの処理では、新しい実装はRFC8200 [RFC8200]のセクション4.3に従う。この処理はオプションである。

  • あるいは、一部のルータの実装に固有なもの: ハードウェアによって処理することができず、パケットを一般的なルーターCPUにパントさせるような特大の拡張ヘッダーチェーン

一部のルータでは、汎用RPに対していくつかのパケットを「パントさせる」必要がある特殊なデータプレーン・ハードウェアですべてを行うことはできない。これは、例えばレイヤ4情報に基づいてACLを適用するために長い拡張ヘッダチェーンの処理を含む可能性がある。RFC6980 [RFC6980]と、より一般的には、RFC7112 [RFC7112]は、パケットの最初のフラグメントにIPv6ヘッダーチェーン全体を含める必要があるため、RFC2460 [RFC2460]はルータ上の特大の拡張ヘッダチェーンとセキュリティ上の影響を強調している。

イングレスACLは、パケット例外を使用してコントロールプレーン攻撃を軽減するのに役立たない。RPに対する唯一の保護は、RPに転送されるパケット例外の帯域制限することである。これは、データプレーンパケットがPath MTUホールを引き起こす可能性のあるICMPメッセージを送信元に戻さずにドロップすることを意味する。

RPにキューイングされたデータプレーンパケットの帯域を制限することに加えて、RPを守るだけでなく、ルータをリフレクタとして使用する増幅攻撃を防止することもICMPメッセージの生成レートを制限することも重要である。

2.5. ルーティング・セキュリティ

一般にルーティングセキュリティは、大きく次の3つの部分に分けられる:

  1. ネイバー/ピアを認証する

  2. ピア間のルーティング更新をセキュアにする

  3. 経路フィルタリング

[RFC7454]は、BGPのためのこれらの部分を詳細にカバーしている。

2.5.1. ネイバー/ピアを認証する

ルーティングの基本要素は、他のルータとの隣接関係、ネイバーあるいはピアリング関係を形成するプロセスである。セキュリティの観点からは、信頼できるルータや管理ドメインのみとの関係を確立することが非常に重要である。従来のアプローチは、ルーターがルーティング関係を確立する前に相互認証することを可能にするMD5 HMACを使用することだった。

OSPFv3は、IPsecを使用して認証機能を実行できる。ただし、IPsecサポートは全てのルーティング・プラットフォームで、標準ではない。場合によっては、このような機能を提供するために、暗号化を専用ASICや拡張ソフトウェアイメージ(両方ともしばしば追加の財務コストが掛かる)でオフロードする特別なハードウェアが必要である。追加された詳細は、OSPFv3 IPsec実装が完全性保護のためにAHまたはESP-Nullを使用するかどうかを判断することである。初期の全ての実装では、詳細はRFC5340 [RFC5340]または作成者によって廃止されたRFC2740 [RFC2740]で指定されていなかったため、全てのOSPFv3 IPsec設定はAHに依存していた。しかし、OSPFv3 RFC4552 [RFC4552]のためにIPsecがどのように実装されるべきかを具体的に記述する文書では、ESP-Nullが実装されるべきであることを具体的に述べている。OSPFv3は、通常のESPを使用してOSPFv3ペイロードを暗号化し、ルーティング情報を隠すこともできる。

RFC7166(RFC6506 [RFC6506]は破棄された)は、OSPFv3パケットの最後に認証トレーラを付加することにより、OSPFv3のIPsecへの依存を変更する。これは特に、OSPFv3パケットの特定の発信者を認証しない。むしろ、パケットが本当に共有認証キーにアクセスしたルータによって発行されたことをルータが確認できるようにする。

全ての認証メカニズムを使用して、オペレータは、障害が引き起こさないre-keyingメカニズムを実装でサポートできることを確認すべきである。re-keyingが停止を引き起こし、この機能を利用する間のトレードオフが、提供する保護と比較検討する必要がある場合がある。

2.5.2. ピア間のセキュアなルーティング更新

IPv6は当初、すべてのノードでIPsec機能のプロビジョニングが義務付けられていた。しかし、更新されたIPv6ノード要件では、標準RFC6434 [RFC6434]は現在'SHOULD'であり、もはや実装は'MUST'ではない。理論的には、ルーティング情報を交換するルータを含む2つのIPv6ノード間の通信は、IPsecを使用して暗号化することが可能であり、推奨されている。しかし、実際には、前のセクションで説明したように、様々なプラットフォームのハードウェアとソフトウェアの制限が導入されているため、IPsecの導入は必ずしも実行可能ではない。

2.5.3. 経路フィルタリング

経路フィルタリング・ポリシーは、エッジの経路フィルタリングと内部の経路フィルタリングのどちらに付随するかによって異なる。異なる管理ドメイン間のルーティングに関連するIPv6ルーティング・ポリシーは、少なくとも、ポリシーの観点からIPv4との等価を維持することを目指す必要がある。例えば、

  • 周辺で内部利用で、グローバルではないルーティング可能なIPv6アドレスをフィルタする

  • bogonと予約された空間から/へのパケットを廃棄する(RFC8190 [RFC8190]参照)

  • RADBなどの様々なルーティング・データベースを使用して、経路の起点、プレフィックスの所有権などを検証する入力経路フィルタを設定する。この領域では、RFC6810 [RFC6810]にBGP広告の起点ASを正式に検証するための追加作業がある。

フィルタリングに関するいくつかの推奨事項は、Team CYMRU [CYMRU]から見つけることができる。

10/13/2018

IPv6ネットワークの運用上のセキュリティ考慮事項 (2)

IPv6のセキュリティにとって必読書というIETF文書(既に期限が切れているが更新はされていない)。

2.2. 拡張ヘッダ

拡張ヘッダーは、IPv4とIPv6の重要な違いである。パケット構造は大きな違いを生む。例えば、上位層のプロトコルタイプとプロトコルヘッダーを(IPv4ベースのパケットで)見つけるのは簡単だが、IPv6で実際には、拡張ヘッダーチェーンを完全に解析する必要はない。IANAは、既存の空の「次ヘッダータイプ」登録の新しいエントリに閉鎖し、そのユーザーをRFC7045 [RFC7045]によって新しい「IPv6拡張ヘッダータイプ」登録に変えています。

拡張ヘッダーを含むパケットを破棄するノードに転送すると、接続障害や導入の問題が発生することが知られているため、これらは非常に議論の余地のあるテーマになった[RFC7872]。様々な拡張ヘッダーの役割を理解することは重要である。このセクションでは、慎重な検討が必要なものを列挙する。

中間ノードがどのように拡張ヘッダーと今後定義される拡張ヘッダーで既存のパケットを処理するかについての説明(clarification)は、RFC7045 [RFC7045]にある。将来の拡張ヘッダーを定義するために使用される統一TLVフォーマットは、RFC6564 [RFC6564]に記述されている。

また、Next Protocolフィールドが拡張ヘッダまたはトランスポートヘッダを指し示すかどうかの指示は、パケット内に存在しないことに注意しなければならない。これは一部のフィルタリング規則を混乱させる可能性がある。

これらの拡張ヘッダーのフィルタリングルールについては、IETFで進行中の作業が存在する: トランジットルータ向けの[I-D.ietf-opsec-ipv6-eh-filtering]である。

2.2.1. 拡張ヘッダーの順序と繰り返し

RFC8200 [RFC8200]は拡張ヘッダーの順序と最大限の繰り返しを勧告しているが、このドキュメントの執筆時点で、勧告されていないヘッダーの順序(ルーティング前のESPなど)やヘッダーの違法な繰り返しをサポートするIPv6実装がまだ存在する(複数のルーティングヘッダーなど)。拡張ヘッダーに含まれるオプションについても同様である([I-D.kampanakis-6man-ipv6-eh-parsing]を参照)。場合によっては、誤ってフォーマットされたパケットを受信または転送するとノードがクラッシュすることがある。

拡張ヘッダーの推奨順序と発生回数を強制できるファイアウォールまたはエッジデバイスが推奨される。

2.2.2. ホップバイホップ・オプション・ヘッダー

ホップバイホップ・オプション・ヘッダーがIPv6パケットに存在する場合、パス内のすべてのノードは、オリジナルのIPv6仕様RFC2460 [RFC2460]にある通り、このヘッダーを検査するように強制する。これはもちろん、全てのルータではないにしても、この種のパケットをハードウェアで処理することはできず、ソフトウェア処理のためにこのパケットを「パントする」必要があるため、サービス拒否攻撃の主要な手段だった。ホップバイホップ・オプション・ヘッダーの処理は任意であるため、現在のインターネット標準のRFC8200 [RFC8200]のセクション4.3は、この点でより賢明である。

2.2.3. フラグメント・ヘッダー

フラグメント・ヘッダーは、パケットをフラグメント化する必要があるときに送信元で使用される。RFC7112 [RFC7112]およびRFC8200 [RFC8200]のセクション4.5は、次のことが重要である理由を説明している。

ファイアウォールおよびセキュリティデバイスは、上位層ヘッダーを含まない最初のフラグメントを削除すべきである。

宛先ノードは、上位層ヘッダを含まない最初のフラグメントを破棄すべきである。

更に、ステートレスなフィルタリングは敵対的な関係者によってバイパスされる可能性がある。RFC6980 [RFC6980]は、RFC6105 [RFC6105]に記述されているNDPとRAガード機能に同じ規則を適用する。

2.2.4. IPセキュリティ・拡張ヘッダー

IPsecがネットワークレベルのセキュリティ機能のために利用されるなら、IPsec [RFC4301]の拡張ヘッダー(AH [RFC4302]とESP [RFC4303])が必要である。

2.3. リンク層のセキュリティ

IPv6は、近隣探索プロトコル(NDP) RFC4861 [RFC4861]に大きく依存し、リンク上の他のノードを発見し、リンク層アドレスを解決し、リンク上でルーターを見つけるなど、さまざまなリンク操作を実行する。これが保護されていない場合、NDPはルータ/近隣メッセージスプーフィング、リダイレクト攻撃、DAD(Duplicate Address Detection) DoS攻撃などの様々な攻撃に対して脆弱である。NDPに対するこれらのセキュリティ上の脅威の多くは、IPv6 ND Trustモデルと脅威 RFC3756 [RFC3756]とRFC6583 [RFC6583]に文書化されている。

2.3.1. DHCPをセキュアにする

RFC3315 [RFC3315]で詳述されているように、IPv6(DHCPv6)の動的ホスト構成プロトコルにより、DHCPサーバーはIPv6ネットワークアドレスやその他の構成情報などの構成パラメータをIPv6ノードに渡すことができる。DHCPは、堅牢なステートフルな構成とDNSホスト名の自動登録を提供することで、大規模なネットワークで重要な役割を果たす。

DHCPクライアントに対する最も一般的な2つの脅威は、悪意のある(ローグとして知られる)あるいは意図せずに誤って構成されたDHCPサーバーから発生する。悪意のあるDHCPサーバーは、不正な構成情報をクライアントに提供して、サービス拒否攻撃を引き起こしたり、中間者攻撃を開始したりする目的で設置されてる。意図しない間に、誤って構成されたDHCPサーバーにも同じ影響がある。DHCPに対する追加の脅威については、RFC3315 [RFC3315] DHCP-shieldのセキュリティの考慮事項のセクションで議論されている。

RFC7610 [RFC7610]、DHCPv6-Shieldは、接続されたDHCPv6クライアントを不正なDHCPv6サーバーから保護するためのメカニズムを規定している。このメカニズムは、レイヤ2デバイスでのDHCPv6パケット・フィルタリングに基づいている。管理者はDHCPv6サーバーに接続されているインタフェースを指定する。もちろん、RFC7112 [RFC7112]が強制されていない限り、拡張ヘッダーはDHCPv6-Shieldをバイパスするために活用することができる。DHCPv6をセキュアにするもう1つの方法は、[I-D.ietf-dhc-sedhcpv6]によって現在進行中のセキュアなDHCPv6プロトコルを使用することだが、この文書の執筆者らは実際の導入を知らない。

DHCP-shieldを使用し、このセキュリティ機能によって生成されたログを分析することを推奨する。

2.3.2. ND/RAの帯域制御

近隣探索(ND)は、ルーターが多数の未割り当てアドレスのアドレス解決を強制的に実行するサービス不能(DoS)攻撃に対して脆弱である。この攻撃の起こり得る副作用は、新しいデバイスがネットワークに参加することを妨げるか、CPU使用率が高いために最後のホップルータを役に立たなくなり、さらに状況を悪化させる。

RFC6583 [RFC6583]は、DoSの潜在的可能性について詳細に議論し、そのような攻撃の影響を緩和または軽減するために使用される実装の改善と運用の緩和手法を提案している。今日、ネットワーク事業者が採用できるいくつかの実現可能な緩和オプションがある:

  • /64プレフィックスより長いACL、経路フィルタリングによる未使用アドレスの入方向フィルタリング。これらは、アドレスの静的な設定を必要とする
  • NDPプロセスのチューニング(サポートされている場所)
  • RFC6164 [RFC6164]で、ポイントツーポイント・リンク上で/127を使用
  • さらに、IPv6 NDは、ローカルリンク上のシグナリング・メッセージにマルチキャストを広範囲に使用して、効率的にon-the-wireでブロードキャストメッセージを回避する。しかし、これにはWi-Fiネットワークにいくつかの副作用、特にそのようなネットワークに接続されているスマートフォンやその他のバッテリ駆動デバイスのバッテリ寿命に悪影響がある。次の草案では、この問題に対処するために、無線ネットワーク上でRAやその他NDメッセージを帯域制限する方法について盛んに議論している。
  • [I-D.thubert-savi-ra-throttler]
  • [I-D.chakrabarti-nordmark-6man-efficient-nd]

2.3.3. ND/RAのフィルタリング

ルーター広告のなりすましはよく知られた攻撃ベクトルであり、広範に文書化されている。意図的または悪意のある不正なRAが存在すると、IPv6リンク上でホストの動作が部分的または完全に失敗する可能性がある。例えば、中間者(MITM)攻撃として使用できる不適切なルーターアドレスを選択したり、ステートレスアドレス構成(SLAAC)に使用する誤ったプレフィックスを想定することができる。RFC6104 [RFC6104]は、不正なRAが観察されるシナリオを要約し、問題の可能な解決策のリストを提示する。RFC6105 [RFC6105](RA-Guard)は、不正なRA問題を解決するためのソリューション・フレームワークを記述している。ネットワーク・セグメントは、無効なRAを特定し、攻撃パケットが実際にターゲットノードに到達する前に遮断することができるスイッチング・デバイスを中心に設計されている。

しかし、RA-Guardによって提供される保護を迂回するいくつかの回避手法が浮上している。この軽減手法の主要課題は、IPv6の断片化によってもたらされる。攻撃者は、無効なRAをブロックする能力のあるスイッチ・デバイスが同じパケットでパケット・フィルタリングを実行するために必要な全ての情報を見つけることができないように、パケットを複数のフラグメントに断片化することによって攻撃を隠すことができる。RFC7113 [RFC7113]は、そのような回避技術を記述し、前述の回避ベクトルを排除できるように、RA-Guard実装者にアドバイスを提供する。

IPv6 Fragmentationヘッダーが現在のRA-Guardの実装を迂回するために活用できるとすれば、RFC6980 [RFC6980]は、IPv6 Fragmentationヘッダーの使用が「Certification Path Advertisement」を除くすべての近隣探索メッセージで禁止されるようにRFC4861 [RFC4861]を更新している。近隣探索攻撃に対抗する簡単で効果的な対策が可能である。

送信元アドレス検証改善(SAVI)ワーキンググループは、このような攻撃の影響を緩和するための別の方法に取り組んできた。RFC7513 [RFC7513]は、DHCPv4 RFC2131 [RFC2131]/DHCPv6 RFC3315 [RFC3315]に割り当てられた送信元IPアドレスとSAVIデバイス上のバインディング・アンカーRFC7039 [RFC7039]との間のバインディングの作成するのに役立つ。また、RFC6620 [RFC6620]では、DHCPを使用しない場合に同様のバインディングを収集する方法について説明している。バインディングは、偽造された送信元IPアドレスを使用してローカルリンク上で生成されたパケットをフィルタリングするために使用できる。

誤って設定されたホストを含む一般的な攻撃経路に対する防御の最前線としてRA-Guardを使用することがさらに推奨される。生成されたログは、違反行為に対処するために分析される必要もある。

2.3.4. 3GPPのリンク層のセキュリティ

3GPPリンクは、リンク層アドレスを持たないポイントツーポイントのリンクである。これは、そのリンク上にエンドホスト(モバイルハンドセット)と第1ホップルータ(すなわち、GPRSゲートウェイサポートノード(GGSN)あるいはパケット・ゲートウェイ(PGW))のみが存在することを意味する。GGSN/PGWは、広告された/64プレフィックスを使用してリンク上に非リンクローカルアドレスを決して設定しない。広告されたプレフィックスは、on-link決定を使用してはいけない。リンク層アドレスがないため、3GPPリンク上でのアドレス解決の必要はない。更に、GGSN/PGWは、IPv6ステートレス・アドレス自動設定を使用する各3GPPリンク内で固有のプレフィックスを割り当てる。これにより、モバイル・ホストによって構築された全てのアドレスについてネットワーク・レベルでDADを実行する必要性が回避される。GGSN/PGWは、リンクローカル・アドレスを設定する目的で常にセルラホストにIIDを提供し、リンク上のIIDの一意性を保証する(すなわち、自身のリンクローカル・アドレスとモバイルホストのアドレスとの間の衝突はない)。

3GPPリンクモデル自体は、既知のNDP関連のサービス拒否攻撃のほとんどを緩和する。実際には、GGSN/PGWは、割り当てられたプレフィクスの配下にある全てのトラフィックをモバイルホストにルーティングする必要がある。3GPPリンク上に1台のホストが存在するため、そのIPv6アドレスを守る必要はない。

3GPPリンクモデル、それに関するNDP、およびアドレス構成の詳細については、RFC6459 [RFC6459]のセクション5を参照して頂きたい。

2.3.5. SeNDとCGA

SEcure Neighbor Discovery(SeND)は、RFC3971 [RFC3971]で説明されているように、NDメッセージを保護するために設計されたメカニズムである。このアプローチでは、公開鍵ベースの署名を運ぶために新しいNDPオプションを使用を伴う。RFC3972 [RFC3972]に記述されているように、Cryptographically Generated Addresses(CGA)は、近隣探索メッセージの送信者が、要求されたIPv6アドレスの実際の「所有者」であることを保証するために使用される。新しいNDPオプションであるCGAオプションが導入され、公開鍵と関連パラメータを運ぶために使用されている。別のNDPオプションであるRSA Signatureオプションは、ネイバーとルーターの検出に関連する全てのメッセージを保護するために使用される。

SeNDは次を保護する:

  • 近隣者要請/広告スープフィング
  • 近隣者到達不可能性検出失敗
  • 重複アドレス検出のDoS攻撃
  • 近隣者要請/広告攻撃
  • 再生攻撃
  • 近隣探索DoS攻撃

SeNDは次は保護しない:

  • 静的に構成されたアドレスの保護
  • 固定識別子(例えば、EUI-64)を使って構成されたアドレスの保護
  • NDP通信のための機密性の提供
  • 保護されていないリンクを補うこと - SENDは、リンク上のアドレスと近隣広告が対応することを要求しない

しかし、現時点でも仕様から数年経っても、CGAとSeNDは一般的なオペレーティング・システムの幅広いサポートを受けていない。従って、その有用性は限られている。