IPv6アドレススキャン攻撃

2020/6/25-1

IPv4では、アドレススキャン攻撃やポートスキャン攻撃は日常的に行われています。 ファイアウォールなしの状態でグローバルIPv4アドレスに接続していれば、すぐに攻撃を観測できます。

IPv6でもアドレススキャン攻撃は発生しています。私の家のネットワークでも、IPv6でのアドレススキャン狙いと推測されるトラフィックを簡単に観測できました。 ただ、いまのところ、私の家では、実際に利用しているIPv6アドレスを外部から発見できているようなスキャンの形跡を発見できておらず、主にステートフルDHCPv6や手動設定でのIPv6アドレスを探しているように見えました。 やはり、IPv4と比べると、IPv6の方がIPv6アドレススキャン攻撃の難易度は高いのだろうと思います。

ということで、IPv6でのアドレススキャン攻撃や、その他方法によって、稼働しているIPv6アドレスをどのように探すのかに関して解説しているRFC 7707を紹介します。

この記事の流れは、次のようになっています。

  • /64に対するIPv6アドレススキャン攻撃
  • RFC 7707
  • IPv6アドレススキャン攻撃によるNeighborキャッシュ溢れ問題

この記事は、YouTubeに掲載した動画と同じ内容です。

/64に対するIPv6アドレススキャン攻撃

まず、なんでIPv6の方が攻撃難易度が高くなるかですが、IPv6は、IPv4と比べると、サブネットとして使われるIPv6アドレス空間が広大だからです。 128ビットのIPv6アドレスは、通常は、上位64ビットをサブネットプレフィックスとし、下位64ビットをインターフェース識別子として扱います。 /64のネットワークプレフィックスでサブネットが運用されているわけです。

これによって、IPv6でのそのサブネット内は2の64乗個のIPv6アドレス空間になります。 IPv4アドレスは32ビットですが、IPv6はサブネットだけで倍のビット数の64ビットです。 これは、IPv4インターネット全体のアドレス空間の約43億倍のアドレス空間が、IPv6ではサブネットだけで使われているということです。

たとえば、ルータ1台に対してパソコン1台のみが接続されたIPv6サブネットがあったとします。 パソコンに設定されているグローバルIPv6アドレスが1つだけだった場合、外部から何のヒントもない状態でアドレススキャン攻撃をする場合、IPv4インターネット全体の43億倍のアドレス空間の中からパソコン1台で使われているグローバルIPv6アドレスを探すことになるわけです。

このように、IPv6では、アクティブなIPv6アドレスを発見するのが、IPv4と比べて非常に大変です。 そのため、外部からのIPアドレススキャン攻撃も、IPv4よりも、IPv6の方が著しく効率が悪くなります。

この効率の悪さは攻撃を成功させる難易度を上昇させるという利点がありますが、同時に、NDPへのDoS攻撃になる可能性があるという欠点もあります。 NDPへのDoS攻撃に関しては、後半に解説します。

RFC 7707

RFC 7707は、IPv6アドレススキャン攻撃などによって、外部からのアクティブなIPv6アドレスを探す手法などに関して論じています。

RFC 7707のタイトルは、「Network Reconnaissance in IPv6 Networks」ですが、Reconnaissanceという英単語は偵察、調査、予備調査などの意味がある英単語です。 次の攻撃のための偵察活動を連想させるタイトルと言えそうです。

なお、RFC 7707では、ingがついた「IPv6 address scanning」になっていますが、この記事では「IPv6アドレススキャン」と表現しています。

さて、RFC 7707では、以下のような文章があります。

significantly lower IPv6 host density is likely to make classic network address-scanning attacks less feasible, since even by applying various heuristics, the address space to be scanned remains very large.

(訳)IPv6ホストがサブネット内に含まれる密度が著しく低いため、古い手法でのアドレススキャン攻撃による効果は低くなっている。様々なヒューリスティクスを用いたとしても、スキャンを行うアドレス空間は非常に大きい。

要は、IPv4と比べてサブネットのアドレス空間が広大なIPv6では、IPv4と同様の方法でアドレススキャンを行うことは簡単ではない、ということです。

ただし、RFC 7707では、以下のようにも書いてあります。

(訳)IPv6では、アドレススキャン攻撃による効果が低くなっているものの、適切なヒューリスティクスによっては可能である

RFC 7707は、以下の内容などを紹介しています。

  • IPv6アドレスとしてどのような値が設定されるのか
  • 遠隔からのアドレススキャン
  • ローカルネットワークからのアドレススキャン
  • アドレススキャンを行うための既存ツール
  • IPv6アドレススキャン攻撃に対する緩和策

まず、IPv6アドレスとしてどのような値が設定されるか、ですが、それを知ることで、IPv6アドレススキャンを行う対象となるアドレス空間を絞り込むことが可能となる場合もあります。

IPv6アドレス自動設定の方法には2種類あります。 SLAACが必須とされており、DHCPv6はオプショナルですが、両方とも実装しているシステムも多くあります。 上記分類はIPv6アドレスの設定方法に関するものなので、IPv6アドレス設定をSLAACで行うステートレスDHCPv6も、分類としてはSLAACに入ります。 上記論点でのDHCPv6は、ステートフルDHCPv6です。

SLAAC、ステートフルとステートレスのDHCPv6に関する総論は、以前作った以下の動画をご覧ください。

まず、SLAACの場合を紹介します。

SLAACでModified EUI-64がIPv6アドレスに利用される場合には上位6ビットめにあるuniversal/localビットが 1になること、48ビットのMACアドレスで、OUIと残りのビットの間に0xfffeが挿入されることなどを利用して、アドレススキャンを行う対象を絞り込めるとしています。

また、MACアドレスを元にしたModified EUI-64でIPv6アドレスが自動生成されていて、かつ、ネットワークインターフェースのベンダーがあらかじめわかっている場合、アドレススキャンを行う対象となるアドレス空間は、64ビットではなく24ビットまで減少するとRFC 7707にあります。

MACアドレスを元にしたインターフェース識別子生成のバリエーションのひとつとも考えられますが、スキャン対象が仮想化技術を利用しており、そこでMACアドレスを元にしたModified EUI-64でIPv6アドレスが自動生成されていることがあらかじめわかっている場合、アドレススキャンを行う対象となるアドレス空間を大きく絞り込める可能性があります。

さらに、アドレススキャン対象がサーバ仮想化技術を使っている場合、OUIとして利用されるベンダーをある程度まで絞り込める場合もあります。

RFC 7707では、VirtualBox、VMWare ESX Server、VMWare vSphereで利用されているOUIとともに、MACアドレスの自動生成方法が紹介されています。

VirtualBoxの場合、OUIが 08:00:27 のMACアドレスが自動生成されるため、インターフェース識別子であるIPv6アドレスの下位64ビットは、a00:27ff:feXX:XXXX になります。 アドレススキャンを行うとき、このバツの24ビット分に対して行うことになるため、64ビットから24ビットへと絞り込めるわけです。

VMware ESX Serverのバージョン1.0から2.5でMACアドレスが自動生成される場合、OUIが 00:05:69 となり、次の16ビットはコンソールオペレーティングシステムのプライマリIPv4アドレスの下位16ビットと同じものになり、最後の8ビットがVMの設定ファイルの名前に対するハッシュ値になるため、状況によっては、アドレススキャンを行う対象のアドレス空間を64ビットから8ビットまで絞り込めるとRFC 7707に書かれています。

これらの他に、VMWare ESX ServerでMACアドレスを手動設定する場合や、VMware vSphereでMACアドレスが自動設定される場合と、手動設定される場合に、どのような値になるのかが、RFC 7707に書いてあるので、ご興味のあるかたは、是非、そちらをご覧ください。

ステートフルDHCPv6や手動設定でたとえば、2001:db8::1 のようにインターフェース識別子の上位ビットの多くを0とする設定が多いことなども、スキャン対象のアドレスを絞り込むのに利用できる、とRFC 7707で紹介されています。

私の家に来ていたIPv6アドレススキャン攻撃を観察したとき、インターフェース識別子の上位48ビットで0が連続するようなアドレスレンジをスキャンすると同時に、上位48ビットで1が連続するようなアドレスレンジに対するスキャンも行われていました。


2001:db8::1 - 2001:db8::ffff
2001:db8::ffff:ffff:ffff:1 - 2001:db8:ffff:ffff:ffff:ffff

RFC 7707では、外部ネットワークからのアドレススキャン攻撃では、temporary IPv6アドレスが利用されている場合であってもstableアドレスも設定されるため、stableアドレスがMACアドレスから生成されている場合には、temporary IPv6アドレスを使っていることによって、Modified EUI-64からの推測に対する対策になるわけではないことが解説されています。

複数のIPv6アドレスがひとつのネットワークインターフェースに 設定されるのは、temporary IPv6アドレスだけではありません。

たとえば、RAでManaged Address configurationフラグとOther configurationフラグの両方が1になっている場合、ステートフルDHCPv6とSLAACの両方でIPv6アドレスが設定されることもあります。

RAに含まれるフラグに関しては、こちらの、以前作ったRAの解説動画をご覧ください。

ステートフルDHCPv6サーバの設定によっては外部から推測しやすいIPv6アドレスが設定されてしまう場合があります。

先ほど紹介した、私の家に対するアドレススキャン攻撃も、恐らく、ステートフルDHCPv6によって設定されたIPv6アドレスも狙っていると思われます。

このように、RFC 7217の方法でModified EUI-64を使わずにstableなIPv6アドレスを設定したとしても、外部から発見しやすい値がステートフルDHCPv6によって同時に設定されてしまう場合があるわけです。 遠隔からのIPv6アドレススキャン攻撃は、ホストに設定されたグローバルIPv6アドレスをどれかひとつ発見できれば良いとも考えられるので、MACアドレスを元にしたIPv6アドレスを作らなかったとしても、上位48ビットが全部ゼロなIPv6アドレスも同時に設定していれば、外部から推測されてしまう恐れが高くなってしまいます。

RAでManaged Address configurationフラグとOther configurationフラグの両方が1になっている環境は、割と身近にあるので、ご興味があるかたは是非お手元の環境で確認してみてください。 RAをwiresharkで確認しても良いですし、ipconfig、ifconfig、ipなどのコマンドを使って、ネットワークインターフェースに設定されたIPv6アドレスの数と内容をチェックすることでもわかります。

RFC 7707では、IPv6アドレスとして設定される値に関する紹介を行なったうえで、それらを遠隔からのアドレススキャン攻撃を行うさいに、スキャン対象を絞り込むために利用することが可能であることを紹介しています。

また、遠隔からのアドレススキャン攻撃がNeighborキャッシュへのDoS攻撃になる場合があることも紹介しています。

ローカルネットワークからのアドレススキャン

ローカルネットワークでのアドレススキャンであれば、全ノードリンクローカルマルチキャストアドレスである ff02::1 に対してICMPv6 Echoリクエストを送るという手法もあります。

ただし、ff02::1に対するICMPv6 Echoリクエストによって得られるのは、リンクローカルアドレスであることや、Windowsシステムがマルチキャストに対するICMPv6 Echoリクエストに回答しないことなどもRFC 7707で紹介されています。

その他、IPv6アドレスを発見する手法

RFC 7707は、IPv6アドレススキャン攻撃以外にも、アクティブなIPv6アドレスを発見する手法をいくつか 紹介しています。

たとえば、以下の手法が紹介されています。

  • DNSに登録されたものを探す
  • 公開されたメールアーカイブを探す
  • P2Pアプリケーションから取得する
  • ネイバーキャッシュやルーティングテーブルから取得する
  • SNMPから取得する
  • トラフィックスヌーピング
  • traceroute6でルータなどのIPv6アドレスを取得する

なかには、ターゲットと同じサブネットへのアクセスが必要だったり、特定のアクセス権限が必要となるようなものもありますが、いろいろな方法がざっくりと紹介されているので、ご興味があるかたはRFC 7707をごらんください。

Mitigations

RFC 7707の最後のほうで、IPv6アドレススキャンに対するミティゲーション(mitigations/緩和策)が紹介されています。

IPv6パケットに対するフィルタを設定できる場所があれば、それを設定することや、MACアドレスを元にしたIPv6アドレス生成を行わないこと、バーチャルマシンでは推測されやすいMACアドレスを避けるためにMACアドレスを手動設定することなどが書かれています。 RFC 8064によって、MACアドレスを元にしたIPv6アドレス自動生成が非推奨になりましたが、外部からのアドレススキャンに利用できることが、非推奨となった理由のひとつです。

ただ、RFC 7707では、以下のように、IPv6アドレススキャンに対するミティゲーションは、やった方が良いけど、必ずしも最優先とまでは言えない場合もあるとしています。

there are scenarios in which mitigation of some address-scanning vectors is unlikely to be a high priority

(訳)いくつかのアドレススキャン手法に対するミティゲーションは、優先度が高くないと推測される場合もあります。

さらに、わかりにくくすることによるセキュリティは、それ自身が防御というわけではない、としています。

(訳)難解にすることによるセキュリティそのものは、防御そのものとして意味があるわけではないという点は忘れるべきではない

隠してわかりにくくすることは、セキュリティ環境における、防御層のひとつでしかない、というわけです。

IPv6アドレススキャン攻撃によるNeighborキャッシュ溢れ問題

RFC 7707では、アドレススキャン攻撃が末端ルータへのDoS攻撃になる場合があるという副作用がIPv6では存在しているとしています。 これは、IPv6固有の問題で、IPv4では、起きない問題です。

この問題は、RFC 6583で詳しく解説されていますが、この記事では、ざっと概要だけを説明して、詳細は割愛します。

まず、Neighborキャッシュですが、IPv6では、IPv6アドレスとリンク層アドレスの対応づけをするデータをNeighborキャッシュと呼びます。 ルータがIPパケットを転送するときに、Neighborキャッシュが必要になります。

ユーザが接続しているサブネットを構成している末端ルータがIPv6アドレススキャン目的のパケットを受け取ったとしてます。 誰も利用していないIPv6アドレスを宛先とするパケットを受け取った末端ルータは、その宛先IPv6アドレスに関連するNeighborキャッシュを持っていないので、リンク層アドレスを解決するためのプロセスを開始します。 そのとき、INCOMPLETE(不完全)というステートのNeighborキャッシュが作られます。

ただ、末端ルータが行なっているアドレス解決は、存在しないIPv6アドレスに対してなので、そのリンク層アドレスが解決されることはありません。 IPv6アドレススキャン攻撃は、存在するIPv6アドレスを探すために、存在しない大量のIPv6アドレス宛てのパケットを送信しまくるので、末端ルータでは、存在しないIPv6アドレスに対応するリンク層アドレスの解決プロセスが大量に走ることになります。 それにより、末端ルータでNDPが正常に動作しなくなってしまうという問題が発生することがあります。

RFC 6583では、性能が低いコンピュータからnmapを4セッション行うことで、末端ルータでのNDPを利用不能に陥らせ、その末端ルータがサービスを提供しているサブネットへの到達性がなくなってしまったとあります。

このように、IPv6アドレススキャンがNDPへのDoS攻撃になってしまうという問題があります。

最後に

以上が、IPv6でのアドレススキャン攻撃に関してでした。

IPv6とIPv4は、直接的な互換性がない異なるプロトコルですが、IPアドレススキャン攻撃の手法や影響でも、IPv6とIPv4の違いが出るというのは、非常に興味深いと個人的に考えています。

最近のエントリ

過去記事

過去記事一覧

YouTubeで技術解説やってます!