他社および他組織のWebサイトなどへのポートスキャンおよびデータの取得などの行為で得た情報を侵入などに悪用するか、または同じ目的を持つ第三者に提供した時点で違法となります。ご注意ください。
本稿の内容を検証する場合は、必ず影響を及ぼさない限られた環境下で行って下さい。
また、本稿を利用した行為による問題に関しましては、筆者および株式会社アットマーク・アイティは一切責任を負いかねます。ご了承ください。
「第1回 攻撃者側から見た侵入前の事前調査（下見）」では、攻撃者が対象サーバに侵入を試みる際に、最初に行うだろう、ターゲットサーバの脆弱性の有無の調査方法を紹介した。今回は、攻撃者が利用できる情報をいかに与えないようにするかといった対策法を紹介する。
実行コマンドの先頭の %は一般ユーザー権限、#は管理者権限（root）によるコマンドの実行を意味する。
攻撃者に有用な情報を与えない対策
第1回で説明した事前調査は、サーバ内へ侵入するといったたぐいの攻撃ではない。そのため対策をしようがしまいが、事前調査によりサーバ内に侵入されてしまうことはまずない。
しかしながら、事前調査によって攻撃者に侵入するための有用な情報（OSやソフトウェアのバージョン情報など）を与えてしまうのは事実で、管理者からすれば、そういった情報をやすやすとは与えたくないだろう。
攻撃者に有用な情報を与えない対策として最初に挙げられるのが、バージョン情報を隠す（表示しない）方法だ。その方法を実現する手段としては、ソフトウェアの設定で行うことを推奨する。ソースコードを直接修正する対策は、運用を維持し続けることを考えるとあまり推奨できない。
以上を踏まえ、ここでは実際に情報が検出されたApache、BIND、sendmailにおける対策方法をRed
Hat Linux 7.3上で説明する。OpenSSHについては、ソフトウェア設定による対策が現行バージョンでは行えない、さらにはソースコードのバージョン変更をすると正常に機能しなくなるため、今回は対象外とした。
なお、ここで説明する対策方法は、攻撃者に対してあくまで目くらましを行う程度のもので、攻撃者があれこれ考える人間であるからこそ有効な手段となり得る。そのため、現在も蔓延しているNimdaのように、ソフトウェアの種類に関係なく攻撃を行うものに対しては、まったくの無力であるということに十分注意してほしい。
Apacheの場合
Apacheのバージョン情報を変更したい場合は、httpd.confにServerTokensとServerSignatureの設定を変更すればよい。
（1）ServerTokens の変更
httpd.confにServerTokensを追加し（後述のServerSignatureの直下あたりに追加すればよい）、ProductOnlyを定義する。なお、この設定はApache 1.3.12以降から利用可能となる。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
（2）ServerSignature の変更
httpd.confのServerSignatureの設定をOnからOffに変更して、エラーメッセージ出力時にフッタを表示しないようにする。なお、この設定はApache 1.3から利用可能となる。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
（3）確認
telnetとWebブラウザを使用して、Apacheのバージョン情報が表示されなくなったことを確認する。
編集保存した後、httpd.confを再読み込みする。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
BINDの場合
BINDでは、バージョン情報の変更とゾーン転送の制限を行う。
（1） バージョン情報の変更
BINDのバージョン情報を変更したい場合は、named.confのoptions項目にversionを指定する。ただし、versionはBIND 8.2以上から指定可能。
例：バージョン情報をunknownに変更する
named.confファイルのoptionsに以下を追加する。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
追加後、named.confを再読み込みするためnamedプロセスにHUPシグナルを送る必要がある。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
設定完了後、第1回に述べたdigで確認してみる。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
ANSWER SECTIONのversion.bind.の行の末尾が“9.2.0”から“unknown”に置き換わったことが確認できた。
（2） ゾーン転送の制限
本来ゾーン転送は、スレーブ（セカンダリ）のネームサーバに対してのみ許可するようにすればよいが、事前調査段階での設定ではすべてのホストからゾーン転送が可能となっていた。
以下の例では、ゾーン転送を許可するスレーブネームサーバをns1.example.net（172.16.0.53）のみに、また転送を許可するドメイン空間もexample.co.jpおよび0.168.192.in-addr.arpa （逆引き）に限定した設定である。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
optionsのallow-transfer { none; };は、デフォルトでゾーン転送を全面禁止することを意味している。
sendmailの場合
sendmailのバージョン情報を隠す場合は、sendmail.cfファイルのO SmtpGreetingMessage、 HReceived:、そしてhelpfileファイルの一部を修正する必要がある。O SmtpGreetingMessageはSMTPのコネクション時に、HReceived:はReceived:ヘッダ、そしてhelpfileはhelpコマンド実行時にそれぞれバージョン情報が表示される。
なお、sendmail.cfの生成（修正）はツールのM4を使用する。
（1）O SmtpGreetingMessage（M4マクロ:confSMTP_LOGIN_MSG）の変更
/etc/mail/sendmail.mcに以下の変数を追加する。追加する場所は同じdefineの設定がある末尾あたりがよいだろう。
例：バージョン情報をunknownに変更する
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
（2）HReceived:（M4マクロ:confRECEIVED_HEADER）の変更
confRECEIVED_HEADERのデフォルトで適用されている（$v/$Z）の個所を変更する。変更前のReceived:フォーマットを以下に説明する。
変更前：
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
変更後：（バージョン情報をunknownに変更する）
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
上記の変更後のルールを、M4マクロのconfRECEIVED_HEADERとしてsendmail.mcファイルに追加する。追加する場所は同じdefineの末尾に追加するとよい。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
（3）helpfileの変更
helpfile（/etc/mail/helpfile）のバージョン情報を出力する個所（$v）を変更するかコメントアウト（先頭に#を付加）する。以下の例はsendmailに関する情報を表示しないようにする方法だ。
変更前：
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
変更後：
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
上記では3行コメントアウトした。なお、編集した内容は保存した時点で反映される。
（4）確認
確認の前に、編集保存したsendmail.mcからsendmail.cfを生成する。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
新しいsendmail.cfのテスト（-bt）を行った後、現状のsendmail.cfと置き換えsendmailを再起動する。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
以上の設定が終了したら、telnetおよびエラーメールをもう一度送って、バージョン情報が表示されなくなったことを確認する。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
これでバージョン情報が表示されなくなった。あるいはunknownとして表示されるようになった。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
Received:ヘッダに記述されている、ns.example.co.jpが使用するMTAのバージョンがunknownになっているのを確認できた。
今回は、Apache、BIND、sendmailにおけるバージョン情報を与えないための設定などの対策方法を紹介した。次回は、今回得た情報を基に、対象サーバに対して実際の攻撃手法とその対策を紹介する。
筆者紹介
主に、不正アクセス監視サービス、セキュリティ検査、セキュリティポリシー策定支援などのサービス提供している。また、セキュリティに関する教育サービスも実施中。
木村 靖（きむら やすし）
セキュリティコンサルタントとして、不正アクセス監視やセキュリティ検査 などに従事している。金融機関、官公庁、大手製造業などへのセキュリティシ ステムの導入、セキュリティ検査などの実績を持つ。
Copyright © ITmedia, Inc. All Rights Reserved.