サードパーティのApacheモジュールをビルドする：仕事で使える魔法のLAMP（20）

サードパーティのモジュールを使うことも良くあります

　第14回から、Apache HTTP Server（以下Apache）をビルドする方法をいろいろと解説しています。Apacheはモジュール単位で機能が細分化されており、必要なモジュールを選んでビルドしたり、Apacheの実行時に組み込むことができるようになっています。モジュールには、Apacheのインストールパッケージに同梱されているものだけでなく、いわゆるサードパーティ製のモジュールというものもあります。今回はこういったモジュールのビルド方法を解説します。

　サードパーティ製のモジュールというのは、Apacheの開発チームに所属していない開発者が配布しているものです。もちろん自分で開発することもできます。LAMP環境の構成要素のひとつであるPHPもそのようなモジュールの1つです。ただしPHPの場合は、Apacheモジュールとは異なる形態もあります。正確にはApacheモジュール「にも」なるというべきでしょう。

　PHPのビルド、インストール方は本連載でいずれ解説します。今回は別のモジュールを題材にしましょう。サードパーティ製モジュールの情報はApache Module RegistryというWebサイトに集まっており、ここから探すことができます（図1）。

図1　Apache Module RegistryのWebサイト。キーワードで検索したところ。クリックすると拡大

　なお、このWebサイトは各モジュールの開発者が自分で登録するものです。つまり、世界中にあるすべてのApacheモジュールの情報が集まっているというものではありません。また、モジュールの品質や開発の活発度もまちまちですので、利用するときは、その前によく検討してください。

　今回はmod_securityというモジュールを例に、サードパーティのモジュールのインストール法を説明します。このモジュールはいわゆるWAF（Web Application Firewall）といわれるソフトウェアの1つで、Webアプリケーションを攻撃から守るためのものです。

　mod_securityは、代表的なサードパーティ製Apacheモジュールです。しかし、このモジュールのビルドするとき、Apacheに同梱されているライブラリの問題点が顕在化します。同梱ライブラリには要注意ということをこれまで述べてきましたが、その対処方法についても解説します。

セキュリティホール発覚！ 新バージョンへの移行を急げ

　突然ですが話は変わって、Apacheの脆弱性について少し説明させてください。先日、すべてのバージョンのApacheにゼロデイアタックが可能な脆弱性が見つかりました。これは脆弱性を狙った攻撃が、セキュリティホールの修正プログラムや修正バージョンが提供される前に起こることを意味しています。この脆弱性を利用するとDoS（Denial of Service）攻撃が可能になり、ApacheやOSが正常に動作しない状態に陥ります。

　ゼロデイアタックが可能な脆弱性が見つかると、対策を施したバージョンがリリースされるまで、サーバがいつ攻撃にさらされるか分からないということになってしまいます。2ちゃんねるなど、実際に被害を受けたサイトもあったようです。とはいえ、大体の場合は副作用を許容しながら、なんとか致命的な状況に陥らないようにする応急措置の方法はあるものです。今回の脆弱性は、HTTPリクエストのRangeヘッダの取り扱いに関するものでしたので、Rangeヘッダを無効にするなどの対策を取ればよいのです。

　問題が判明してからちょっと時間がかかりましたが、その後2.2.20がリリースされました。前回までは2.2.19を使っていましたが、今回から2.2.20を使うことにします。手順などはこれまでと同じですが、インストール先を変えます。基本になるconfigureのコマンドラインは次のようになります。

./configure \
  --prefix=/opt/apache-httpd-2.2.20 \
  --enable-mods-shared=all \
  --with-mpm=prefork \
  2>&1 | tee configure_log.txt

　今までの/opt/apache-2.2.19も消さずに取っておけば、仮に新バージョンで問題が発生してもすぐに戻すことができます。

モジュールの一般的なビルド方法

　話をApacheモジュールに戻しましょう。mod_securityのビルド方法を説明する前に、Apacheモジュールの一般的なビルド方法について解説します。

　Apacheのインストールパッケージに同梱されているモジュールは自動的にビルドされますが、外部のモジュールは自分でビルドしなくてはなりません。といっても特別難しいことはなく、configureスクリプトを実行してビルド、インストールといういつも通りの流れです。

　サードパーティモジュールをビルドするには、あらかじめApacheをインストールしておく必要があります。外部ソフトウェアの利用については第13回などで解説した通り、「--with-foo」のようにconfigureスクリプトに指定します。Apacheを指定してビルドするには「--with-apxs」を使います。これはどのモジュールを使うときでも同じです。

　これまでの例では「--with-foo=/usr」のようにインストールディレクトリを指定していましたが、「--with-apxs」ではApacheのインストールディレクトリにあるapxsコマンドを指定します。

　このコマンドは、Apacheをどのようにビルド、インストールしたかという情報を返すものです。configureスクリプトがこのコマンドを呼び出し、インストール場所などの情報を取り出すという仕組みになっています。より多くの情報をconfigureに知らせることができるため、こういったコマンド指定をするケースは増えてきています。

　モジュールの一般的なconfigureのコマンドは次のようになります。

./configure \
  --with-apxs=/opt/apache-httpd-2.2.20/bin/apxs \
  2>&1 | tee configure_log.txt

　この後は通常通り、makeでビルドし、sudo make installでインストールです。インストール先はApacheのモジュールディレクトリになるので「--prefix」の指定も不要なことがほとんどです。

mod_securityをビルド

　mod_securityのインストールドキュメントやconfigureスクリプトのヘルプに従うと、いくつかの外部ソフトウェアが必要なことが分かります。その中の1つにPCRE（Perl Compatible Regular Expressions）があります。PCREはPerl互換の正規表現を扱うためのライブラリで、mod_securityに限らず、さまざまなソフトウェアが利用しています。

　実はApacheもPCREを利用しています。今までPCREやその開発用ファイルをインストールせずにやってきましたが、これはApacheにPCREが同梱されていたからです。また、インストールディレクトリを見てみると、どこにもPCREはありません。スタティックにApacheにリンクしていて、外部から使えるようにはなっていないのです。

　ここで普通に考えると、mod_securityにPCREが必要なのであればPCREをインストールしてmod_securityをビルド、ということになります。しかしそれでは、ApacheがリンクしているPCREと、mod_securityがリンクするPCREは別のものということになり、実行時に衝突してしまいます。これが同梱ライブラリの引き起こす問題です。

　こういう場合、同梱ライブラリは使わずに、Apacheとmod_securityで同じPCREをリンクするようにしなければなりません。それにはまず、PCREをインストールしておく必要があります。

$ sudo yum install pcre-devel

　次に、同梱ライブラリを使わないようにApacheをビルドします。「--with-pcre」を指定すれば、同梱ライブラリではなく外部にあるものを使うようになります。

./configure \
  --prefix=/opt/apache-httpd-2.2.20 \
  --enable-mods-shared=all \
  --with-mpm=prefork \
  --with-pcre \
  2>&1 | tee configure_log.txt

　インストール後、lddコマンドでちゃんとPCREがリンクされているか確認します。

$ ldd /opt/apache-httpd-2.2.20/bin/httpd
        linux-vdso.so.1 =>  (0x00007fff50dfc000)
        libm.so.6 => /lib64/libm.so.6 (0x0000003430a00000)
        libpcre.so.0 => /lib64/libpcre.so.0 (0x0000003430600000)
        libaprutil-1.so.0 => /opt/apache-httpd-2.2.20/lib/libaprutil-1.so.0 (0x00002b0998554000)
        libexpat.so.0 => /opt/apache-httpd-2.2.20/lib/libexpat.so.0 (0x00002b0998774000)
        libapr-1.so.0 => /opt/apache-httpd-2.2.20/lib/libapr-1.so.0 (0x00002b0998996000)
        libuuid.so.1 => /lib64/libuuid.so.1 (0x0000003435600000)
        librt.so.1 => /lib64/librt.so.1 (0x0000003431e00000)
        libcrypt.so.1 => /lib64/libcrypt.so.1 (0x0000003432600000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003430e00000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00002b0998bc4000)
        libc.so.6 => /lib64/libc.so.6 (0x0000003430200000)
        /lib64/ld-linux-x86-64.so.2 (0x000000342fe00000)

　上記の例では、3行目にlibpcreが表示されていて、無事リンクできている事が確認できました。

　mod_securityはさらにcURLとlibxml2が必要ですので、インストールします。

$ sudo yum install curl-devel libxml2-devel

　次のmod_securityのconfigureを実行します。コマンドは次のようになります。

sh ./configure \
  --prefix=/opt/modsecurity-2.6.1 \
  --with-apxs=/opt/apache-httpd-2.2.20/bin/apxs \
  --with-apr=/opt/apache-httpd-2.2.20/bin/apr-1-config \
  --with-apu=/opt/apache-httpd-2.2.20/bin/apu-1-config \
  --with-pcre=/usr/bin/pcre-config \
  --with-libxml=/usr/bin/xml2-config \
  --with-curl=/usr/bin/curl-config \
  LDFLAGS=-L/opt/apache-httpd-2.2.20/lib \
  2>&1 | tee configure_log.txt

　一般的な例に比べて、だいぶ長くなりました。上から順に見ていきましょう。まず、「--prefix」指定ですが、mod_securityはモジュール以外にもコマンドがあるので、必要になっています。「--with-apxs」については前述の通りです。

　「--with-apr」「--with-apu」はApacheに同梱されているaprとapr-utilライブラリの指定です。これまでも何度か触れましたが、ApacheのOS依存部分を切り離したライブラリです。こちらは同梱されているものが外部からも使えるようになっていますので、このように指定します。先ほど紹介した、インストールディレクトリではなく設定コマンドを指定するパターンになっています。

　「--with-pcre」「--with-libxml」「--with-curl」は、必要な外部ソフトウェアの指定です。これらもやはりコマンドを指定します。「LDFLAGS」はリンク時にコンパイラに指定する引数になります。「-L」でApacheのインストールディレクトリを、ライブラリのサーチパスに含めるようにします。

　他に問題を起こすような同梱ライブラリとしてはexpatがあります。Apache本体ではなくapr-utilの同梱ライブラリなので、前回解説したapr-utilへconfigureの引数を渡す方法を組み合わせれば、まったく同じように対処できます。

　これでApacheのビルドについてはひととおり解説を終えました。次回からはApacheの設定について解説します。設定そのものを詳しく解説するのではなく、構築・運用面から解説したいと思います。