悩みが尽きないIPv6
皆さんこんにちは、川口です。
大変ごぶさたしました。私は元気に夏を楽しんでいました。私の今年の夏は「セキュリティ&プログラミングキャンプ2011」一色に染まっていました。そして、熱意ある若者との楽しい時間を満喫しているうちに、このコラムを書くことをすっかり忘れていました。スミマセン。
さて、次代の新しい力を育てることに一役買った今年の夏ですが、今回は、古くて新しい話題、IPv6について取り上げます。
@ITでもIPv6に関する記事が取り上げられることが増え、読者の皆さんも少しずつIPv6に触れる機会が多くなってきたと思います。セキュリティ監視センター、JSOC(Japan Security Operation Center)でも、1年前と比べて、「IPv6コマンドが……」「IPv6対応が……」「IPv6のログが……」という会話が圧倒的に多くなりました。そこで今回は「IPv6の6つの悩み事」を紹介します。
【関連記事】
いまさら聞けない、IPv6アドレス体系の基礎(@IT Master of IP Network)
http://www.atmarkit.co.jp/fnetwork/rensai/v6again01/01.html
悩みその1:そもそも未知の領域
まず1つ目の悩み事は「IPv6自体が未知の領域」であるということです。
私のこれまでの人生は、ほぼ100%、IPv4の世界に占められてきました。通信経路上ではIPv6で通信している部分もあるかもしれませんが、自分自身でIP層を意識するときは、間違いなくIPv4で脳みそが回転しています。そのような状況で、未知なる*言語*ともいえる「IPv6」の対応が必要になっています。
IPv6では、IPアドレスに使用される文字や表記方法に慣れることから始まり、サブネットの指定、ユニキャストアドレス空間など、IPアドレスに関係する1つ1つの作業すべてに大変な苦労を伴います。
悩みその2:IPv6用コマンドが分からない
2つ目の悩みは「IPv6用コマンドが分からない」ことです。
ネットワークの疎通を確認する際に「arpテーブルはどこ?」「あれ? pingが実行できないんですけど……」なんてことはザラ。ネットワークエンジニアとして日常的に利用するコマンドの1つとっても満足に実行できない有様に衝撃を受けつつも、新しいコマンドやオプションの発見にわくわくするのもエンジニアならではの楽しみでしょう。
これは、1つ目の悩みと同じように、「IPv6」という世界に慣れていないことが原因です。ここはひたすら修行を積んで慣れるしかありません。
ちなみにJSOCでは社内のセキュリティ教育テストに交じって、IPv6の基礎知識を問うクイズを出題しています。勉強による自助努力だけではなく、全員にテストを実施してIPv6に触れる機会を増やしています。
悩みその3:ITシステムのIPv6対応
3つ目の悩みは「ITシステムがIPv6に対応していない」ことです。
いまではOSやサーバ、ネットワーク機器の多くはIPv6に対応しています。しかし、古いバージョンのソフトウェアやハードウェアはIPv6に対応していません。
また、マイナーなソフトウェアもIPv6に対応していないことが多々あります。特に、JSOCのセキュリティアナリストが日常的に使用するセキュリティツールに関しては対応がまだということが多く、IPv6環境では別のセキュリティツールを採用したり、運用の変更が必要になったりしています。
特に、個人的によく使っている「Sam Spade」や「McAfee Free Tools」がIPv6で使えると助かるのですが、フリーツールだと対応はあまり期待できないでしょう。
悩みその4:システム運用の設計と実装の問題
4つ目の悩みは「IPv6を含んだシステム運用の設計、実装が大変」であることです。
IPv6に対応したWebサーバを運営する場合、以下のような悩みに直面することになります。
- IPv4とIPv6の両方で稼働監視をするのか?
- IPv4経由だと成功しない攻撃がIPv6経由で成功する場合があるか?
- DNS名前解決はIPv4とIPv6のどちらを優先するか?
- サーバのIPv6側に対する攻撃は検知、防御可能か?
- WebサービスはIPv6に対応したが、メールを受けるシステムがIPv4しかないが、どうするか?
- IPアドレスを指定する場合、短縮表記を使うことができるか?
- IPv6に特化したセキュリティ問題にはどのようなものがあるか?
単純なWebサービスの運営に加えて、セキュリティの悩みも増えるわけですから、大変になるのは目に見えています。管理する対象が2倍になりますが、その運用の負荷は4倍以上になるような気がします。
しかも、IPv6を使用したサービスが徐々に増え始めたとはいえ、少なくともあと10年はIPv4アドレスも多くの場所で使われ続けるでしょう。つまりIPv4とIPv6という2つの異なるネットワークの管理が求められるのです。世界がいっぺんにIPv6に変わることがない限り、2つのIPプロトコルの管理は避けられません。
悩みその5:アドレス短縮表記
5つ目の悩みは「IPv6アドレスの短縮表記」に関係するものです。
ご存じのとおり、IPv6アドレスの表記はとても長い!! そのため、短縮表記をするルールが存在します。
ログを出力するソフトウェアによってはIPv6アドレスを短縮表記で出力する場合があります。しかし、この短縮表記がログを目grep(目で対象となるログを探すこと)する際に大きな障害になり、ログを見るセキュリティアナリストにとっては、かえって迷惑になる場合もあります。
例えば、以下の2つのパターンを見比べてみると、短縮表記をしたログの方が見づらくなっています。
2001:0DB8:0000:0000:0000:0000:0001:0212 2001:0DB8:0000:0000:0000:0000:0002:0212 2001:0DB8:0000:0000:0000:0000:0007:0212 2001:0DB8:0000:0000:0111:0000:0007:0212 2001:0DB8:0000:0000:0000:0000:0003:0212 2001:0DB8:0000:0000:0000:0000:0004:0212 2001:0DB8:0000:0000:0000:0000:0010:0212 2001:0DB8:0000:0000:0000:0000:0005:0212 2001:0DB8:0000:0000:0000:0000:0006:0212 2001:0DB8:0000:0000:0000:0000:0008:0212 2001:0DB8:0000:0000:0000:0000:0009:0212
2001:DB8:0:0:0:0:1:212 2001:DB8:0:0:0:0:2:212 2001:DB8:0:0:0:0:7:212 2001:DB8:0:0:111:0:7:212 2001:DB8:0:0:0:0:3:212 2001:DB8:0:0:0:0:4:212 2001:DB8:0:0:0:0:10:212 2001:DB8:0:0:0:0:5:212 2001:DB8:0:0:0:0:6:212 2001:DB8:0:0:0:0:8:212 2001:DB8:0:0:0:0:9:212
さらに厄介なのが、IDS/IPSの機種によっては、同じIPアドレスであっても、格納されるログの形式と管理画面に表示されるログの形式が異なる場合があることです。この結果、短縮表記されたIPv6アドレスを探そうとしても発見できない状況が発生します。
このように、IPv6アドレスの短縮表記はセキュリティアナリストにとって非常に悩ましい存在なのです。
悩みその6:アナリストの脳内のキャッシュ
最後の6つ目の悩みは「IPアドレスのレンジがセキュリティアナリストの脳内にキャッシュされていない」ことです。
ベテランのセキュリティアナリストは、お客様が使用するIPアドレスや攻撃者のIPアドレスを(自然と)脳内にキャッシュしており、高速な分析を可能としています。IPアドレスの表記が長いため、セキュリティアナリストの頭の中にIPv6アドレスをキャッシュするのは大変だろうと思います。もちろん、彼らならばやると思いますが!
これからながーく続く、IPv6との付き合い
このような悩みを抱えているのは、われわれJSOCだけではありません。日本のセキュリティオペレーション事業者が集まるISOG-Jでも、同じ悩みが共有されていました。
ISOG-Jの技術ワーキンググループが主体になってセキュリティ機器のIPv6対応状況を調査した結果を公開していますので、ぜひ参考にしてください。
【関連リンク】
活動紹介|ISOG-J 日本セキュリティオペレーション事業者協議会
http://www.jnsa.org/isog-j/activities/result.html
IPv6検証報告書(PDFファイル)
http://www.jnsa.org/isog-j/output/2011/ISOG-J_IPv6_Verification_Report.pdf
この「IPv6検証報告書」の47ページには、セキュリティエンジニアの生々しい感想が記載されていますので、少し引用します。
- IPv6アドレス打つのが面倒くさい!
- インターネット越しのIPv6 pingでv6通信初体験! これだけで大騒ぎ
- アドレス指定に[ ]が必要と知って驚愕(がく)した
以上、今回は古くて新しいIPv6の話題を取り上げました。
まだほかにも、発見されていない脆弱性や設計に入っていない運用の漏れなども多数あるでしょう。インターネットでIPv6の世界が広がりつつあるいま、セキュリティオペレーション事業者もIPv6に対応していく必要があります。IPv6の先駆者に苦労話を聞くために、今日も飲みに行くのでした。
Profile
川口 洋(かわぐち ひろし)
株式会社ラック
チーフエバンジェリスト
CISSP
ラック入社後、IDSやファイアウォールなどの運用・管理業務をへて、セキュリティアナリストとして、JSOC監視サービスに従事し、日々セキュリティインシデントに対応。
アナリストリーダとして、セキュリティイベントの分析とともに、IDS/IPSに適用するJSOCオリジナルシグネチャ(JSIG)の作成、チューニングを実施し、監視サービスの技術面のコントロールを行う。
現在、JSOCチーフエバンジェリストとしてJSOC全体の技術面をコントロールし、監視報告会、セミナー講師など対外的な活動も行う。また、YouTubeのlaccotvにて、「川口洋のつぶやき」に出演中。
- 「DNS通信」記録していますか?――万一に備えたDNSクエリログの保存方法
- Web広告からのマルウエア感染「Malvertising」にどう対処すべきか
- 中の人が振り返る「Hardening 10 ValueChain」――学びにつながった「トラブルの数々」とは
- 無慈悲な専門家チーム「kuromame6」の暗躍に負けず勝利をつかんだチームは?
- 外部リソースの活用もポイントに、「Hardening 10 MarketPlace」開催
- Hardening Projectから派生した「MINI Hardening Project」に行ってみた!
- 「これさえしておけば助かったのに……」を避けるため、今すぐ確認すべき7項目
- アップデート機能を悪用した攻撃に対抗セヨ!
- 工夫、工夫そして工夫――Hardening 10 APAC“運営”レポート
- ウイルスとは言い切れない“悪意のあるソフトウェア”
- 2013年のセキュリティインシデントを振り返る
- ここが変だよ、そのWeb改ざん対応
- きっかけは不正侵入――私がセキュリティ業界に足を踏み入れたワケ
- CMSが狙われる3つの理由
- FacebookやApple、MSまで……Javaの脆弱性を狙う攻撃の手口
- Hardening One、8時間に渡る戦いの結果は?
- そのときStarBEDが動いた――「Hardening One」の夜明け前
- ロシアでわしも考えた
- 実録、「Hardening Zero」の舞台裏
- ちょっと変わったSQLインジェクション
- 官民連携の情報共有を真面目に考える
- アプリケーションサーバの脆弱性にご注意を
- IPv6、6つの悩み事
- スパムが吹けば薬局がもうかる
- JSOCに飛び込んできた不審なメール――これが標的型攻撃の実態だ
- 東日本大震災、そのときJSOCは
- ペニーオークションのセキュリティを斬る
- 2010年、5つの思い出――Gumblarからキャンプまで
- 9・18事件にみる7つの誤解
- 曇りのち晴れとなるか? クラウド環境のセキュリティ
- Webを見るだけで――ここまできたiPhoneの脅威
- 不安が残る、アドビの「脆弱性直しました」
- ともだち373人できるかな――インターネットメッセンジャーセキュリティ定点観測
- 実録・4大データベースへの直接攻撃
- Gumblar、いま注目すべきは名前ではなく“事象”
- Gumblarがあぶり出す 「空虚なセキュリティ対策」
- 新春早々の「Gumblar一問一答」
- 実はBlasterやNetsky並み?静かにはびこる“Gumblar”
- ECサイトソフトウェアはなぜ更新されないのか
- 狙われるphpMyAdmin、攻撃のきっかけは?
- 学生の未来に期待する夏
- 米韓へのDoS攻撃に見る、検知と防御の考え方
- 分かっちゃいるけど難しい、アカウント情報盗用ボット対策
- 狙われる甘〜いTomcat
- 表裏一体、あっちのリアルとこっちのサイバー
- 世間の認識と脅威レベルのギャップ――XSSは本当に危ないか?
- 急増したSQLインジェクション、McColo遮断の影響は
- ○×表の真実:「検知できる」ってどういうこと?
- ところで、パッケージアプリのセキュリティは?
- レッツ、登壇――アウトプットのひとつのかたち
Copyright © ITmedia, Inc. All Rights Reserved.