本書は日経コミュニケーション誌に「トラブルに強いネットワーク構築法」のタイトルで連載されたトラブル事例・解決策・未然防止策をまとめたもので、36のケースが紹介されている。なお元となる連載は100回を超え、本書以外にも書籍化されている。
印象深いケースをいくつか紹介。
Case 01 認証
不正な端末や無許可の端末を社内ネットワークにつながせないようにしたいとき、端末認証の仕組みを導入するとよい。無線LANではEAP-TLSがよく使われる。ただ強固な守りを実現する一方で、運用に不備があると、それがあだとなることもある。例えば認証要求の集中や証明書の有効期限切れが発生すると、端末が全くアクセスできなくなるトラブルが起こる。運用には細心の注意を払いたい。
認証事故といえば、本人確認がゆるすぎてユーザーの支払情報を抜かれた7pay (*1) が記憶に新しいが、このCase 01では逆に、厳しすぎるゆえに問題となった認証をとりあげている。
具体的には、ある会社で有線LANにMACアドレス (*2) 、無線LANにEAP-TLS (*3) を利用して接続可能機器を認証したところ、計画停電翌日にネットワークに接続された機器が一斉に再認証要求を行い、RADIUSサーバー (*4) の負荷集中で一部機器が再認証失敗したのである（のちに時間をおいて全端末が再認証に成功）。「計画停電時には、帰宅時にネットワーク機器のケーブルや電源コードを抜いておくように」とIT担当者が全社通達したのならば、このトラブルケースが頭にあるのかもしれない。
またデジタル証明書 (*5) の有効期限切れといえば、数年前にSoftBankがやらかして大規模な接続障害を引き起こした (*6) ことを思い出す。結構良く見かけるタイプのトラブルなのかもしれない。
(*1) セブン＆アイがリリースした電子決済サービスで、利用開始直後に大規模な不正使用が起こったために廃止に追いこまれた。会員アカウント7iDに2段階認証やパスワード変更通知機能が導入されていないなど、基本的なセキュリティ対策ができていないことが指摘された。その後の調査でさまざまなセキュリティシステム設計上の不備が明らかにされている。
二段階認証の意味を問う 「7pay事件」を教訓に見直したい認証のハナシ：今さら聞けない「認証」のハナシ（1/5 ページ） - ITmedia NEWS
(*2) MACアドレスはMedia Access Control addressの略。LANやインターネットでのイーサネット通信で利用されている。IPアドレスと同じく通信機器の識別子であるが、IPアドレスがインターネット上のコンピュータと通信するためのものであるのに対し、MACアドレスは隣接するコンピュータ間の通信を可能にするためのもの。
(*3) EAPはExtensible Authentication Protocolの略であり、IEEE802.1X認証に使用される。各種の拡張認証方式を利用するための手続きをまとめたものであり、実際に使用される認証プロトコルと組み合わせてEAP-xxxxと呼称される。主にEAP-TLS、EAP-TTLS、EAP-PEAPがよく使用される。TLSはHTTPの暗号化プロトコルと同じもの。
(*4) EAP認証にはRADIUS(Remote Authentication Dial-In User Service)サーバーを利用する。EAP (RFC2284) よりも RADIUS(RFC2059) のほうが先に制定されたという歴史的経緯があり、EAPの前身である、電話回線用のダイヤルアップのために設計されたPPP (RFC1661) の認証プロトコルをベースに RADIUS が設計されている。このためEAPが認証プロトコルとして広く使用されるようになってからは、RADIUS側の認証機能はしだいに使用されなくなった。
(*5) このケースでは社内にCA (Certification Authority、認証局) サーバをもっていたため、サーバー証明書再発行で事なきを得た。一般的に、証明書には、Webサーバーを運営する法人名や登録住所などの企業情報、次の段階の鍵交換で使用される公開鍵、これらのデータのハッシュ値を認証局の秘密鍵で暗号化した電子署名が入っている。クライアントは認証局の公開鍵を使用して、秘密鍵で暗号化された認証局のデジタル署名部分の復号を行い、Webサーバーの公開鍵のハッシュ値と比較し、同じなら正当な公開鍵であると判断する。ちなみに代表的な認証局のデジタル証明書はクライアントのブラウザにインストールされており、インストールされていない場合、ブラウザで警告表示されるのが一般的。
(*6) 原因はコアネットワークで利用していたエリクソン製MME (Mobility Management Entity) でデジタル証明書の有効期限が切れたためと発表されている。
ソフトバンク障害は“他人事”ではない デジタル証明書のヒヤッとする話：ITの過去から紡ぐIoTセキュリティ（1/3 ページ） - ITmedia NEWS
Case 07 IPSec
IPsecはIPレベルでセキュリティを確保したい時に最もよく使われるプロトコルである。一方の帯域制御は回線を有効利用したい時に役に立つ。この2つの技術を併せて導入する場合には気をつけたいポイントがある。それはIPsecのトンネリングと暗号化はパケットの改変を伴うということ。これを見過ごすと、帯域制御が効かないなどのトラブルに見舞われることがある。
このケースでは、ある会社が広域イーサネット (*7) への移行に伴い、本社と支社間の通信を暗号化するためにIPSec (*8) を導入し、さらに帯域制御装置 (*9) を設置して送信元IPアドレス (*10) と宛先IPアドレスを対にして必要帯域を割り当てるようにしたところ、帯域制御がうまくいかないことが明らかになった。IPSecのトンネルモードでは、もとのIPアドレスを含むパケット (*11) 全体を暗号化して新しいIPヘッダーを付与する仕組みになっているが、IPアドレス変更で帯域制御装置側でパケットを識別できず、ネットワーク内の全トラフィックが帯域制御の効いていないベストエフォート状態となっていた。
なお、この問題を解決するために打った手が新たなトラブルを呼び起こしており、解説記事は「ある一つの問題を解決したことにより新たな問題が発覚することが多々ある。全体を網羅した解決策を導き出すためには十分な仕様確認と事前検証が欠かせない。」と結んでいる。
(*7) 広域イーサネットとは、地理的に離れたLANとLANの間などをイーサネット（厳密にはイーサネットは有線LANに用いられる規格であるが、無線LANにおけるWi-Fiのように、接続そのものを指すことも多い）で接続するWAN (Wide Area Network) サービスの一つ。100km単位の大きさにわたるカバーが可能。IP-VPNやインターネットVPNに比べ、通信速度が速く遅延の幅が小さい、安価なVLAN対応のスイッチングハブが利用できるため初期コストを低減できる、などのメリットがある。なお、VPN (Virtual Private Network) は、通信事業者の提供する公衆回線上に、企業拠点間をつなぐ仮想専用回線を構築する技術及びサービスの呼称。専用回線であるから当然第三者が情報を読み取れないものでなければならず、暗号化技術使用が大前提。
(*8) IPsec (Security Architecture for Internet Protocol) は、データストリームの各IPパケットを認証／暗号化するためのプロトコル群（複数のプロトコルの組み合わせ）。IPsecの規格はIETFのワーキンググループにて策定し、RFCとして公開している。
(*9) 帯域制御とは、パケットの種類ごとに使用可能な回線容量（すなわち通信速度）を制限すること。優先順位の高いパケットを送受信できるなどのメリットがある。
(*10) IPアドレスとは、スマホやPCなどのネットワーク上の機器に割当てられるインターネット上の住所のようなもの。IPv4とIPv6の２種類がある。IPv4は通常使用される「xxx.xxx.xxx.xxx」形式のアドレスだが、グローバルに接続される通信機器数が爆発的に増加したことによりアドレス枯渇が懸念され、もっと多くの組合せをもつIPv6の実用化がすすめられている。ちなみにWebサイト情報がどこにあるかを示すインターネット上の住所はドメイン。
(*11) パケットとは、もとの送受信データをある程度の大きさに切り分けたもの。ネットワーク層（レイヤー３。ネットワーク上での二つのノード間の通信方法を規定）において、通信を行う際の転送単位。RFC 1983 では、パケットは「すべてのプロトコルスタックで、ネットワークを行き交うデータの単位として使われる一般的な用語」とある。つまりどのようなプロトコルでも、データのひとつのまとまりはすべてパケットである。
Case 14 ハードウェアだけの更新
業務システムの更新は機器の老朽化対策や処理能力の向上を目的として実施する。ところが、「更新前より性能が落ちた」というトラブルが散見される。これはハードウエア環境だけを更新した場合に、「そのまま動くはず」と誰もがそう思うところに落とし穴がある。そうならないように事前の確認で現状を把握し、稼働状況を明確に可視化しておくことが望ましい。
このケースではある企業がストレージ装置（NAS (*12) ）を現行機種よりも容量や処理速度が高い上位機種に、ネットワーク装置（LANスイッチ (*13) ）は現行機種の後継機種にリプレースし、それ以外の環境は一切変更しなかったところ、業務データのバッチ処理 (*14) が更新前よりも遅くなるというトラブルが発生。LANスイッチとの間に再送信、送信タイムアウトが起きており、NASを接続しているデータポートでデータフレームの破棄 (OutDiscards) (*15) が起きていた。
原因は、LANスイッチの後継機種のバースト耐性 (*16) が先行機種よりも低いためにデータフレームの処理が間に合わず、バッファからあふれていたことであった。旧NASではうまくいっていたけれど、新NASでは処理速度が向上したためにLANスイッチ側で対応できなくなったのである。ハードウェアの更新により、ネットワーク装置とサーバー／ストレージ装置の能力バランスが崩れたために起きたトラブルであった。
(*12) Network Attached Storageの略称。社内ネットワークに接続してファイルなどを保管する。
(*13) LANスイッチは複数の機器をネットワークに接続するための集線装置の1つ。ポートを複数備え、データ（フレーム）を受け取ると、宛先機器が接続されているポートに送信する。
(*14) バッチ処理とはプログラム（データ）を処理目的ごとにまとめ、順次処理していく一連の流れもしくはシステムのこと。つまりは同じように処理できるデータがある程度溜まった時点でまとめて処理するやり方。この対義語はリアルタイム処理。
(*15) フレームとはデジタルデータ伝送の構成単位のこと。パケット交換システムでは、フレームは1つのパケットに相当する。
(*16) バースト耐性とは、一定時間にどれだけの連続したデータ転送（大量トラフィック）に耐えられるかという指標。
Case 18 キャッシュポイズニング
DNSサーバーを狙ったキャッシュポイズニング攻撃がひとたび成功してしまうと、意図せずに不正なWebサイトへリダイレクトされてしまう。ユーザーから見ると正常な場合と見分けがつかないため、なかなか気づかない厄介なトラブルだ。DNSサーバーのように公開されているサーバーは攻撃者から狙われがち。問題がないからといってほったらかしにせず、日々のチェックを欠かさないようにしたい。
ある企業のユーザーからインターネットが使えないとの一報が入った。パケットキャプチャを実施したところ、DNSサーバー (*17) に対して、複数のグローバルIPアドレスからDNSのパケットが大量に届いていることがわかった。
最初はDDoS攻撃 (*18) を疑ったが、問い合わせ (query) に対して正常に応答 (query response) ができているため単なるDDoS攻撃ではなかった。さらに調べたところ、キャッシュポイズニング (*19) が行われていることが明らかになった。このような攻撃はファイアウォールでは防げないため、日々のセキュリティパッチなどのチェックは欠かせない。
(*17) DNSはDomain Name Systemの略で、名前解決に使用される。名前解決とは、ソフトウェアなどが扱う識別名と、その識別名が示している実体を対応付ける処理のこと。TCP/IPネットワークでドメイン名やホスト名（人間がWebページにアクセスするときに入力するいわゆるxxx.comなど）と対応するIPアドレス（IPv4であれば「xxx.xxx.xxx.xxx」の形式）を対応付けるのがDNS名前解決。DNSサーバーはドメイン名に対応するIPアドレスを管理している「権威DNSサーバー」と、ユーザーの代わりにIPアドレスを権威DNSサーバーに問い合わせる「キャッシュDNSサーバー」に分けられる。
(*18) DDoS攻撃（Distributed Denial of Service attack／分散型サービス拒否攻撃）とは、対象のウェブサイトやサーバーに対して複数のコンピューターから過剰アクセスや大量データ送付を行うサイバー攻撃。サーバーなどに対して大きな負荷がかかるため、ウェブサイトへのアクセスができなくなったり、ネットワークの遅延が起こる。
(*19) 偽のDNS応答をキャッシュDNSサーバーにキャッシュさせることで、利用者のアクセスを攻撃者が用意したサーバーに誘導し、フィッシングや送信された電子メールの窃盗などを図る攻撃手法。DNSでは問い合わせや応答のプロトコルにUDP (User Datagram Protocol) を使っているが、TCPとは異なり、UDPはコネクションレス型であり、通信相手の応答を待つことなくデータを送り続けるプロトコルであり、どんな相手とでも通信可能となる危険性がある。また、代表的なDNSサーバーソフトであるBIND (Internet Software Consortiumによって提供されている) の動作仕様では、トランザクションIDが同じなら、通信先を特定しないでパケットを受信する。このため、キャッシュDNSサーバーからのIPアドレス問い合わせに対して、権威DNSサーバーから正しい応答が来る前に、攻撃者がトランザクションIDが同じだが中身を攻撃者の意図する不正なIPアドレスにすりかえた応答パケットを送りつけると、キャッシュDNSサーバーは正しい応答と認識して不正な応答を受け取りキャッシュしてしまう。この攻撃手法を「キャッシュ・ポイズニング」と呼ぶ。
