現場エンジニアであるK氏に,応急処置を依頼した後のシーンから始めよう。

 2007年7月下旬,応急処置を依頼してから1週間が過ぎていた。その間,DHCPサーバーに問題のMACアドレスからのDHCP Discoverメッセージは届いていないとK氏から連絡を受けていた。このまま,現象が再発しなければ良いのだが…と,希望的観測をしていても仕方がないので,DHCPサーバーのメーカーに問い合わせ,そのやり取りを経て,すべてのマルチキャスト・アドレスからのDHCP Discoverメッセージを拒否するスクリプトを完成させた。そして,そのことを伝えるべく,私はK氏にメールを送った。

 「すべてのマルチキャスト・アドレスからのDHCP Discoverメッセージを拒否するスクリプトが完成しました。お客様の環境に適用してはどうかと思います」  「ありがとうございます。お客様にお伝えし,適用作業の調整をしてみます」

 K氏からのメールから数日後,K氏から再びメールが届いた。

 「お客様にスクリプトの件をお話したのですが,前回の応急処置以降はマルチキャスト・アドレスからのDHCP Discoverメッセージが届いていないことや,あまり変更を加えたくないというお客様の意向もあり,しばらく様子を観ることになりました」

 そのメールを読んだ私は,お客様の考えも正しいと思った。エンジニアとしては,現象が再発することがないように完ぺきな対策を施すことを優先しがちである。しかし,実運用に入っている環境に,何かしらの変更を行うにはそれなりのリスクが伴うのも,また事実であるからだ。

 幸いにも問題のMACアドレスからのDHCP Discoverメッセージは届いていない。そのため,しばらく様子を観ることにし,私もK氏も日常の業務へと戻ることになった。もちろん,別件での対応に追われる日々に変わりはないのだが…。

DHCPのメッセージ・タイプとは?

 K氏とのやり取りの中で,たびたび現れるDHCP Discoverメッセージについて,ここで解説しておこう。DHCPでは,IPアドレスや各種情報を配布する過程で,表1に示すメッセージが使用される。基本的な動作としては,DHCPクライアントがDHCP Discoverメッセージを送信することで開始,DHCPサーバーがDHCP Offerメッセージに候補となるIPアドレス情報を含めて返信,DHCPクライアントがDHCP Requestメッセージを送信することで候補として挙げられたIPアドレスを要求,DHCPサーバーがDHCP Ackメッセージを送信することで完了となる(図7)。

表1●DHCPのメッセージ・タイプ
Value Message Type  
1 DHCP Discover クライアントがサーバーを「発見」するためのメッセージ
2 DHCP Offer サーバーからクライアントへの設定値「候補」を通知するメッセージ
3 DHCP Request クライアントが決定したサーバーへの取得依頼メッセージ
4 DHCP Decline クライアントからサーバーへの拒否(エラー)メッセージ
5 DHCP Ack サーバーからクライアントへの取得正常終了メッセージ
6 DHCP Nak サーバーからクライアントへの取得拒否(エラー)メッセージ
7 DHCP Release クライアントからサーバーへのリリース要求メッセージ
8 DHCP Inform クライアントがIPアドレス取得は行わず,オプション取得のみ行うメッセージ
図7●DHCPの動作
図7●DHCPの動作

別のMACアドレスで同様の現象が発生

 あれから,約1年が過ぎようとしていた2008年7月,再びK氏からメールが届いた。

 「前回と同様の現象が別のMACアドレスにより発生してしまいました。そこで,送っていただいていたスクリプトを適用したのですが,正常なMACアドレスからのDHCP Discoverメッセージまで拒否してしまうようになってしまいました。そのため,すぐに解除の手順に従って切り戻しを行ったという状況です。今回は完ぺきに対策を施したいというお客様の意向もあります。また,いつ再び現象が発生するか分からないため,スクリプトの問題を修正し,少しでも早く対策を行いたいと思います」

 私は添付してあったDHCPサーバーのログを急いで確認した。そのログには,DHCPクライアントのホスト名は同一であるにもかかわらず,次から次へと異なるマルチキャストのMACアドレスからDHCP Discoverメッセージが届いている状況が記録されていた。ログを確認した私はすぐにK氏にメールを送った。

 「ホスト名が同一であるため,該当PCのNICに問題があるか,該当PCが何らかのマルウエア(ウイルスやワームなどの悪意のあるプログラム)に感染していると推測できます。改めて,スクリプトや設定を確認し,修正でき次第,おって送付いたします」

 メーカーからの情報を基に作成したにもかかわらず,そのスクリプトでK氏やお客様に迷惑を掛けてしまったことを悔やみつつも,同じことは繰り返さないという決意で,私は再びメーカーに問い合わせた。

 次回は,再発の後,解決に至るまでの過程を紹介したい。

関口博幸
ネットワンシステムズ 商品開発グループ 応用技術本部 第4応用技術部 セキュリティ第2チーム
2005年,ネットワンシステムズ入社。主として,アンチウイルス,検疫ネットワークなどのクライアント・セキュリティ製品やサーバ・アプリケーション製品に関し,評価・検証・導入支援・障害対応支援を担当。第二種情報処理技術者,ソフトウェア開発技術者。