4.2 サーバーサービスのセキュア化
前のページへ
次のページへ

4.2.4 Apache+mod SSLのインストールと設定

Web(World Wide Web)はインターネットで広く普及しているドキュメントのシステムで、HTML(Hyper Text Markup Language)という論理構造化ドキュメントをWebサーバーが公開し、ユーザはWebブラウザというアプリケーションを使ってドキュメントを閲覧する。本モデルでは公開するHTMLドキュメント群をWebコンテンツと呼称する。

Webコンテンツをネットワークに公開するにはサーバーにWebサービスを導入し、コンテンツを作成してネットワークに公開しなければならない。Webサービスはユーザからのリクエスト(URLリクエスト)を受け取って、ユーザが指定したWebコンテンツ(HTMLファイル、画像など)を送信する仕組みになっている。

1) 運用方針

本モデルでは、以下の留意点を考慮したWebサービスの運用を行う。

ア) 動的コンテンツの危険性

CGIやSSI機能を利用して、動的スクリプトを生成することで、より複雑でより高機能なWebサービスを提供することが可能になる。しかしながら、それらの利用方法を誤ると侵入やクロスサイトスクリプティング攻撃といったセキュリティ上の問題を多数発生させてしまうため、利用には注意を払う必要がある(CGI利用時の留意点に関しては「6. Webアプリケーションのセキュア化における留意点」を参照する)。

イ) HTTPS通信の利用

通常、WebサーバーとWebブラウザ(クライアント)間の通信にはHTTP通信が使用される。HTTP通信は平文で行われるため、アカウントID/パスワードなどの機密情報のやり取りを行う際は、通信を暗号化する必要がある。本モデルでは、SSLを利用してHTTP通信をセキュア化(HTTPS)し、HTTP通信を80/TCP、HTTPS通信を443/TCPで提供する。なお、HTTPS通信では証明書の取得などが必要となるが、本モデルではテスト用の証明書を使用し、公的な証明書の取得方法などについては特に解説しない。

ウ) DSO(Dynamic Shared Object)モジュールの使用

Apache Webサーバーへのモジュールの組み込みは、Apacheのコンパイル時に静的に指定する方法と、DSOモジュールを用いてhttpd起動時に動的に組み込む方法がある。前者は新たにモジュールを追加する際に、Apache自体をコンパイルし直さなければならないが、後者ではhttpd.confを変更するだけで設定が可能である。しかし、DSOはこのような利便性がある一方で、モジュールの種類が増えれば増えるほどプロセスに必要なメモリ領域が大きくなるなどの問題点もある。実際には、マシンスペックやWebサービスの特徴などを考慮した選択が必要である。

エ) .htaccessの禁止

.htaccessファイルは、ユーザまたはディレクトリ単位で独自に設定を変更することが可能な設定ファイルである。この.htaccessファイルは下記のようにAccessFileNameディレクティブによって定義される。

---有効時---
AccessFileName .htaccess

---無効時---
#AccessFileName .htaccess

このディレクティブが有効である場合、Apacheではクライアントからアクセスされるたびに各ディレクトリ内の.htaccessファイルを参照しようとするため、その分オーバーヘッドがかかりパフォーマンスの低下につながる。また、ユーザディリクトリを許可している場合、ユーザによる個々のアクセス制御を許すと統一したセキュリティポリシーの実現が難しくなる場合があるので利用できなくするのが望ましい。本モデルでは、上記のAccessFileNameディレクティブをコメントアウトしてこのファイル(.htaccess)の利用を禁止する。

2) Apache+mod SSLのインストール

Webサービスを提供するソフトウェアには、いろいろな種類があるが、本モデルではApache Projectが開発しているApacheを使用する。また、Apacheで、通常のHTTP通信と暗号化されたHTTPS通信を実現する設定を行う。Apacheでセキュアな暗号化通信を実現するためには、事前に導入が必要なソフトウェアがあるため、以下の順番でインストールを行う。また、実際のインストール手順は、ア)とイ)で解説する。

ア) OpenSSLのインストール

OpenSSLは、Secure Sockets Layer(SSL v2/v3)および、暗号プロトコルであるTransport Layer Security(TLS v1)を実装したライブラリである。OpenSSLのインストールについては「4.2.1 OpenSSHのインストールと設定」の「2)OpenSSHのインストール」を参照する。既にOpenSSLが導入済みであれば、この作業を行う必要はない。

イ) Apache+mod SSLのインストール

Apache+mod SSLのインストールに必要なアーカイブは次の2つで、それぞれ以下のサイトから入手可能である。本モデルでは、Apacheのバージョン1.3.22、mod-sslのバージョン2.8.5を用いて解説を行う。

 Apache入手先:
  http://www.apache.org/

 MOD SSL入手先:
  http://www.modssl.org/

以下の手順で、入手したアーカイブを展開し、コンパイルそしてインストールを行う。なお、インストール作業はroot権限で行う必要がある。

---Apacheとmod SSLアーカイブの展開---
% gzip -cd apache_1.3.22.tar.gz | tar -xvf -
% gzip -cd mod_ssl-2.8.5-1.3.22.tar.gz | tar -xvf -

---root権限で/bin/patchをリネーム---
% su
# mv /bin/patch /bin/.patch (注1)
# exit

---mod SSLに対応したApacheのmakeファイルを作成---
% cd mod_ssl-2.8.5-1.3.22
% ./configure --with-apache=../apache_1.3.22 \
  --with-ssl=../openssl-0.9.6b \
  --prefix=/usr/local/apache \
  --enable-rule=SHARED_CORE \
  --enable-shared=max \
  --mandir=/usr/local/man \
  --with-perl=/bin/perl \
  --logfiledir=/var/log

---リネームの解除---
% su
# mv /bin/.patch /bin/patch
# exit

---テスト用のSSL証明書を作成---
% cd ../apache_1.3.22
% make
% make certificate TYPE=test (注2)

---Apache+mod SSLをインストール---
% su
# make install


  (注1) mod_sslを展開したディレクトリに移動し、コンパイルを行う。その際、patchコマンドが実行されるがmod_sslに内包されるpatchを使用するためSolarisに標準で付属しているpatchコマンドを一時的にリネームする必要がある。  
  (注2) httpsでの暗号化通信が正しく動作するかどうかを確認するためにテスト用のSSL証明書を作成する。テスト用SSL証明書はインストール時に所定のディレクトリ(本モデルでは /usr/local/apache/conf)に格納される。「make certificate」で指定できる証明書の種類としては以下がある。  
  • TYPE=dummy:自己署名形式の証明書(バイナリ・パッケージ作成者用)
  • TYPE=test:テスト用証明書
  • TYPE=custom:指定のCA(Certificate Authority)によって署名される証明書
  • TYPE=existing:既存の証明書

Table 4.16 configureオプション

オプション 説明
--wth-apache=../apache_1.3.22
Apacheのソースディレクトリを指定
--with-ssl=../openssl-0.9.6b
SSLのソースディレクトリを指定
--prefix=/usr/local/apache Apacheのインストール先を指定
--enable-rule=SHARED_CORE DSOを有効にする
--enable-shared=max 有効モジュールをすべてDSOに対応
--with-perl=/bin/perl Perlのインストール先を指定
--logfiledir=/var/log ログファイルディレクトリの指定

Apache専用のアカウントとグループを作成する(注3)

---Apache用のグループwww(gid:20000)を作成(注4)---
# groupadd -g 20000 www
---Apache用のアカウントwww(uid:20000)を作成(注4)---
# useradd -u 20000 -g www -d /usr/local/apache/htdocs -s /bin/true -c www www


  (注3) Apacheは専用のアカウントとグループを作成してその権限で起動する。これはApacheを利用した不正アクセスが行われた場合に、被害を最小限にするためである。  
  (注4) gidとuidは任意であるので、システムによって変更可能である。  

サーバー証明書

本モデルでは、テスト用証明書を生成して暗号化通信を実現しているが、実際に電子商取引サイトで暗号化通信を実施するには、認証局(CA:Certificate Authority)を通じて発行したサーバー証明書(デジタル証明書)を利用することが望ましい。これにより、対象サイトが信頼の置ける第三者機関(認証局)によってその存在を保証することとなり、サイト利用者に一定の信頼を与えることが可能になる。代表的な認証機関には、日本ベリサイン、セコムトラストネット、日本ボルチモア、日本認証サービスなどがある。また、認証局から証明書を取得する手順は、以下のとおりである。

  1. 秘密鍵の生成
  2. 証明書署名要求(CSR:Certificate Signing Request)の生成
  3. 登録申請のためCSRと身分を証明する書類などを認証局に提出
  4. 認証局で認証手続き終了後、署名済みサーバー証明書の発行
  5. 署名済みサーバー証明書の導入

 日本ベリサイン株式会社:
  http://www.verisign.co.jp/

 セコムトラストネット株式会社:
  http://www.secomtrust.net/

 日本ボルチモアテクノロジーズ株式会社:
  http://www.baltimore.co.jp/

 日本認証サービス株式会社:
  http://www.jcsinc.co.jp/

 参考資料
  情報処理振興事業協会 セキュリティセンター(IPA/ISEC)
  「PKI 関連技術解説」:
    http://www.ipa.go.jp/security/pki/index.html

 

3) Apacheの設定

Apacheの起動設定と動作設定を行う。本モデルでは「1)運用方針」にしたがってア)からウ)の設定を行う。

ア) 起動設定

システム起動時にApacheが自動的に起動されるように設定する。/etc/rc2.dディレクトリ配下に起動スクリプト「S99httpdboot」を作成する。スクリプトの内容は以下のとおり。

#!/sbin/sh
case "$1" in
 'start')
   if [ -f /usr/local/apache/conf/httpd.conf \
     -a -f /usr/local/apache/bin/apachectl ]; then
     /usr/local/apache/bin/apachectl sslstart
   fi
   ;;

   'stop')
     /usr/local/apache/bin/apachectl stop
   ;;

   *)
     echo "Usage: $0 { start | stop }"
     exit 1
   ;;
esac
exit 0

スクリプトファイル作成後、実行権限を与えるため、以下のコマンドを実行する。

# chmod 744 S99httpdboot

イ) デフォルトCGIプログラムの削除

Apacheをインストールした状態では、2つのテスト用CGIプログラムが導入されている。このようなテスト用プログラムまたはサンプルプログラムは、通常不要であり、既知または未知の脆弱性が発生する原因となる可能性があるので削除する。

# rm /usr/local/apache/cgi-bin/printenv
# rm /usr/local/apache/cgi-bin/test-cgi

サンプルプログラムphfの脆弱性

phfは、古いバージョンのApacheやNCSA httpdに付属しているCGIのサンプルプログラムの1つで、httpdを起動しているユーザ権限にて悪意あるコマンドの実行を許可してしまう脆弱性を持っている(/etc/passwdファイルをリモートから参照するような行為)。この脆弱性は、httpd自体の問題ではなく、phfのプログラムバグが原因である。

このphfの脆弱性は非常に古いものなので、最近では、これによる被害はほとんど見受けられないが、サンプルプログラムが抱える脆弱性は現在でも複数発見されており、多くの被害をもたらしている。本モデルでも解説しているように、サーバーサービスのインストール時に導入されてしまうサンプルプログラムやテストプログラムは、サーバーサービス提供前に削除することで、セキュリティ脆弱性の発生リスクを回避することが可能である。


 CERT Advisory CA-1996-06
 「Vulnerability in NCSA/Apache CGI example code」:
   http://www.cert.org/advisories/CA-1996-06.html

 

ウ) Apacheの動作設定

Apacheの設定は、/usr/local/apache/conf/httpd.confファイルで行う。この設定ファイルでは、ディレクティブ(指示子)を用いてさまざまな機能の設定が可能である。ディレクティブの記述方法は大きく分けて二つあり、ディレクティブ名と値だけを記述してApache全体に適用するものと、コンテナタグを用いて適用範囲を限定するものがある。

    ディレクティブ名    値 ...

ディレクティブの適用範囲を限定して設定を行うには、コンテナタグ(<...>)を用いる。ディレクトリごとの設定は<Directory>に、ファイルごとの設定は<File>に、URLごとの設定は<Location>に、仮想ホストごとの設定は<VirtualHost>に指定する。

    <Directory デイレクトリパス>
  設定1
  設定2
   ・
   ・
</Directory>

設定ファイルの具体的な記述方法はApacheに付属するドキュメントを参照することとし、ここではApacheの動作に必須の設定と本モデルの運用方針にしたがった設定に必要な内容を説明する。

「ウ) Apacheの動作設定」を基に作成したサンプル設定ファイルの内容は、以下を参照する。

  /usr/local/apache/conf/httpd.conf

4) Apacheのログ収集設定

外部からのアクセスを受け入れているWebサーバーは、常に不正アクセスの危険にさらされている。不正アクセス対策を実施する方法はいくつかあるが、その1つとして、Webサーバーのアクセスログを解析し、アクセスの頻度、アクセス内容などから不正アクセスの兆候をとらえる方法がある。

Apacheで設定可能なログには、Webサービスへのアクセス情報を記録するログ(アクセスログ)、エラー情報を記録するログ(エラーログ)、プロセスID情報を記録するログ(プロセスIDログ)などがある。その中でも、アクセスログとエラーログは、前述したWebサーバーへの不正アクセスを調査する上で重要な情報源となるので、ログ記録の設定は必須となる。Apacheでは、これらのログの記録フォーマットや記録レベルをカスタマイズすることができる。また、ログの運用に関しては「8.2.1 ログの運用」を参照する。

ア) ログ記録フォーマットの設定

Apacheでは、ログファイルに記録する情報とその記録方法を自由にカスタマイズすることができる。ログフォーマットの記述方法は、以下のとおりである。また、デフォルトではCLF(Common Log Format)である「common」と、CLFにHTTPリクエストのヘッダ情報であるRefererとUser-agentフィールド情報の記録を追加した「combined」のフォーマットが定義されている。CLFで指定しているマクロに関しては、Table 4.17を参照する。

    LogFormat <フォーマット文字列> <ニックネーム>
(例)
LogFormat "%h %l %u %t \"%r\" %>s %b" common
 

Table 4.17 ログフォーマットのマクロ

マクロ 内容
%h リモートホスト名
%l identによるリモートユーザ名
%u ユーザ認証によるリモートユーザ名
%t アクセス日時
%r HTTPリクエスト
%s ステータス
%b 送信バイト数

イ) ログレベルの設定

エラーログでは、ログファイルに記録するエラーのレベルをLogLevelディレクティブで指定することができる。このレベルはsyslogのfacilityと同じ値であり(「4.1.2 セキュア化のための設定」の「7) ログ出力の設定」参照)、各レベルの内容をTable 4.18に示す。

Table 4.18 エラーログのレベル

レベル 内容
emerg システム使用不能などの緊急事態
alert アラートメッセージ
mail 重大なエラー
error 通常のエラー
warn ワーニング
notie 注意
info インフォメーションメッセージ
debug プログラムデバック用メッセージ

本モデルでは、「8.2.1 ログの運用」の「2) ログの種類と設定方針」に基づき、エラーログのログレベルを「debug」とする。

---エラーログレベルの設定---
LogLevel debug

ウ) ログ出力先の設定

アクセスログとエラーログの出力先は、それぞれCustomLogとErrorLogディレクティブで指定する。また、CustomLogディレクティブでは、「ア) ログ記録フォーマットの設定」で設定したログの記録フォーマットを指定することができる。本モデルでは、ログフォーマットを「combined」とする。

---アクセスログの指定---
CustomLog /var/log/access_log combined

---エラーログの指定---
ErrorLog /var/log/error_log

5) httpd.confの設定をチェックする方法

Apacheの動作を管理するapachectlコマンドには、設定ファイルにエラーがあるかどうかをチェックする機能がある。作成したhttpd.confが存在するディレクトリで、以下のコマンドを実行する。

---設定にエラーが無い場合のチェック結果---
# /usr/local/apache/bin/apachectl configtest
Syntax OK

---設定にエラーがある場合のチェック結果---
# /usr/local/apache/bin/apachectl configtest
Syntax error on line 88 of /usr/local/apache/conf/httpd.conf:
Invalid command 'coreBoardFile', perhaps mis-spelled or defined
by a module notincluded in the server configuration

エラーがあった場合は、チェック結果の表示を参考にエラーを修正する。

6) パッチ適用とバージョンアップ

Apacheでは、バグや脆弱性が発見されたり、新機能が追加されたりするとパッチや新しいバージョンがリリースされる。セキュアなWebサーバーを運用するためには、必要とされるパッチの適用やバージョンアップが必須となる。ここでは、パッチの適用方法と、バージョンアップの方法について解説する。

運用しているシステムに関係するパッチがリリースされた場合は速やかにパッチを適用するべきであるが、稼働中のシステムに直接パッチを適用するとシステムの運用に問題が発生する可能性があるため、いくつかの手順を経て適用することが望ましい。また具体的な手順については「8.1.2 セキュリティ維持作業」の「2) パッチ適用」を参照する。

ア) パッチの適用

Apacheのパッチは、ソースコードパッチとしてリリースされているため、パッチ適用後、Apacheを再構成(リコンパイル)する必要がある。Apacheのパッチは、以下のサイトから入手できる(mod SSLは対象外)。

 Apacheのパッチ入手先:
  http://www.apache.org/dist/httpd/patches/

パッチ入手後、パッチを適用するソースが存在するディレクトリに入手したパッチを移動し、「patch」コマンドを利用して適用する(注5)。その後、リコンパイルを実施する。リコンパイルの方法は、パッチ適用済みソースが存在するディレクトリのMakefileを実行し、生成されたバイナリ実行形式ファイルを適切な場所にコピーするか、「イ) Apache+mod SSLのインストール」で解説しているインストール方法を再び実行する(「make」コマンド以降)。

% patch < <パッチ>

また、SUN Microsystemsから提供されているパッチの適用方法に関しては、「4.1.1 Solarisのインストール」の「3) パッチの適用」を参照する。

  (注5)

一般にリリースされているパッチファイルは、GNU patchコマンド向けに作られていることが多いので、Solaris標準の/usr/bin/patchコマンドでは正常にパッチを適用することができないことがある。また、GNU patchコマンドは多くのオプションが用意されており、柔軟なパッチ適用が可能であので、パッチ適用にはGNU patchを利用することを推奨する。GNU patchは、SUN-SITE(ftp://sunsite.sut.ac.jp/)またはGNU Project(http://www.gnu.org/)から入手可能である。

 

イ) バージョンアップ

Apache Projectでは、比較的短期間に新しいバージョンをリリースしており、リリースの度に既知の問題点が解消されている(変更履歴に関してはCHANGESファイルを参照する)。実際のバージョンアップ方法は、新規にApacheをインストールする方法と同様であるので、ここではインストール手順を省略する。


前のページへ
目次へ
次のページへ
ntpdのインストールと設定
第4章の目次
qmailのインストールと設定


Copyright ©   2002 Information-technology Promotion Agency, Japan.  All rights  reserved.