Apache Web Server

[wu-ftpd][Apache][ntp][xinetd][NFS][iptables]

Apache WEB Server

■　HTTPDとＡｐａｃｈｅ

Apache は現在、世界中で最も普及しているWEBサーバである。もともと初期のHTTPサーバはCERN版（ＣＥＲＮはＷＷＷを育てた欧州粒子物理研究所の名前）とNCSA版（ＮＣＳＡはＷＷＷブラウザの元祖、Ｍｏｓａｉｃを誕生させた米国イリノイ大学のコンピュータセンターの名前）があったが、Apacheは NCSA httpd 1.3 から派生した。当初、NCSA httpd 1.3 に存在した多くのバグに patch をあてる必要があったため、ユーモアたっぷりに A PATCHY プログラムと名付けられたという。それを Apache とつづるのはアメリカンネイティブのアパッチ族を洒落たもので、UNIX系のサーバにはこのような命名が多い。現在ではLinuxにバンドルされているフリー版をはじめ、Oracleなどで採用されている商用版があり、いずれも高い信頼性と多機能を誇っている。

※　さらに詳細を知りたい向きには日本Apacheサーバプロジェクトへ

■　HTTPプロトコル

HTTPはよく知られているとおり、ウェルノウンポート８０番を使うTCPアプリケーションであり、このアプリケーションを制御するプログラムがHTTPDである。HTTPプロトコルには1.0および1.1の異なるバージョンが存在し、それぞれIETFによって、HTTP/1.0はRFC 1945として、HTTP/1.1はRFC 2616として規格化されている。

HTTPプロトコルではコンピュータ同士が通信している間、お互いの状態（ステータス）をやり取りしてセッションを維持する。こうしたコンピュータ同士の状態コードのことをステータス・コード（Status Code）と呼ぶ。たとえば、対象ページが見つからなかったときブラウザに表示される"404 Not Found"などはエラーステータスのひとつである。ちなみに、このコードの仕様はRFC 2068で規定されている。(章末にメソッド/リクエストヘッダおよびＨＴＴＰステータスコードの一覧を示す。）

■　セッション管理に関する補足

Tomcat のようなサーブレットコンテナを使ってJavaサーブレットを動かすときなどに注意すべきことだが、HTTPプロトコルでは、1回のリクエストに対して、画面を1度だけ表示して終了してしまう。したがって、複数の画面に渡って処理を行う場合にはセッション管理が必要となる。（厳密にいえばHTTPプロトコル自体にセッションという概念はなく、タイムアウトによりセッションを切断する。なお、セッションのタイムアウト時間（分単位）はデプロイメント記述子（web.xml）に設定する。）

ユーザがログイン/ログアウトしないシステムでは、リクエストがタイムアウトするまでセッション変数は残りリソースを消費する。よってインターネットに公開するシステムでは、タイムアウト値は3分から5分ぐらいに設定しておかないと、ユーザのアクセス状態によっては問題が発生する恐れがある。ただし、イントラネットのようにユーザにログイン/ログアウトさせる場合は、30分程度に設定しても問題にはならないようである。

Apache のインストール

■　Apache のバージョン系列について

現在使われているApacheには、大きく分けてバージョン１．３系列と２．０系列が存在する。両者の最も大きな相違は２．０系列がスレッド対応となっている点である。Apache １．３ではHTTP接続要求ごとにチャイルドプロセスを fork していたので、メモリ空間の割り付けにかかる時間のために応答が遅れる傾向があった。しかし、２．０ではほぼ全面的なプログラムの見直しが行われ、接続要求に対するスレッドの使用によって処理がさらに高速になっている。ただし Apache 2 ならば必ず thread で動作するわけではなく、コンパイルオプションによって動作が決まることを知っておく必要がある。事実、現在の商用Linuxとしてもっとも普及している RedHat エンタープライズ Linux では 2.0 系列の Apache を採用しているが、rpm パッケージは prefork 仕様（プロセス仕様）でビルドされている。この意味で RedHat の Apache に thread 動作を期待することはできないので注意すること。（ちなみに、スレッドとはメモリ空間を親プロセスと共有できる特殊なプロセスのことである。スレッドを使えば親プロセスのメモリ空間情報を子プロセスの新しいメモリ空間にコピーする必要がない。）

もちろん、これはOSがスレッド機能を持っていることが大前提であるが、将来２．０系列が十分に枯れたとき、時期を見計らって１．３系列から２．０への移行が行われるものと思われる。とはいえ、現在でも１．３系列の信頼性は高く、大手プロバイダでも１．３系を使っているところは少なくない（執筆時点：2003/10/17）。新系列を使って原因不明のトラブルを抱えるよりはノウハウのある旧系列で行きたいという事情から、髙負荷のかかる基幹システムでは１．３系列を使い、試験システムや低負荷社内システムで２．０系列をテストするといった折衷的な運用も見かける。

なお、Apache には Windows 用のバージョンも存在する。これは UNIX 系からの移植版であるため、基本的に同じ使い方ができる。Windows 版 Apache はサービスの一つとして起動されるので、「コンピュータの管理→サービスとアプリケーション→サービス→Apache→プロパティ」（以上の手順は2000Pro）から起動のタイプを自動・手動・無効のいずれかに選択しておく。またIISが同居している場合は前もってIISAdminを停止しておくこと。このサービスを停止すると、WWW Publishing Service も連動して停止する。

※　重要　：IISを停止するに当たっては、他のサービスがIISを使用していないかどうか十分に確認する必要がある。たとえば、アンチウィルスソフトの中にはウィルスバスターコーポレートエディッションのようにパターンファイルを IIS から http で配信するものがある。このようなソフトを稼動させているシステムのIISを無造作に停止してしまうと、そのままアンチウィルスを停止することになりかねないので、くれぐれもご注意を。

■　インストール

ここではバージョン２．０系列を対象に解説を進める。Apache のインストールはRPMパッケージから行う方法とソースアーカイブを展開して行う方法がある。rpm でのインストールコマンドは次の通り。（ちなみにパッケージ名は１．３系列のように「Apache-1.3…」ではなく、「httpd-2.0…」に変更されたので念のため。）

　　　　　# rpm -ivh httpd-2.0.40-11.5

ソースコードからのコンパイルとインストールは次の手順で行う。

　　　　　１．ソースコードの tarball（httpd-2.0.40.tar.gz）のダウンロード

　　　　　２．適切なディレクトリ（たとえば /usr/local/src など）での展開

　　　　　　　$ cp ./httpd-2.0.40.tar.gz /usr/local/src/
　　　　　　　$ tar zxvf httpd-2.0.40.tar.gz

　　　　　３．生成された httpd-2.0.40 ディレクトリへの移動

　　　　　　　$ cd httpd-2.0.40

　　　　　４．ビルドスクリプト configure の実行による makefile の作成

　　　　　　　$ ./configure

　　　　　５．コンパイル

　　　　　　　$ make

　　　　　６．インストール

　　　　　　　$ su
　　　　　　　# make install

　　　　　※　ソースからのビルドではApacheは /usr/local/apache2/ 以下にインストールされる。

なお、RedHat エンタープライズ Linux ではインストール時にパッケージグループとして「WEBサーバ」にチェックを入れるとインストールされる。

■　ディレクトリ構成

apache のコンパイル自体は他のアプリケーションと変わりはないが、注意しなければならないのは rpm インストールとソースインストール間のディレクトリ構成の相違である。特に問題になりやすいのは RedHat のディレクトリ構成がオリジナルのビルド環境とは大幅に異なっていることである。このため RedHat ではソースからコンパイルしてインストールする場合、他のアプリケーションとの整合性を欠くことになるで、特に注意が必要である。以下にRedHat７．３におけるApache関連ディレクトリを示す。（黄色部分はＷＥＢコンテンツに関わる部分）

ディレクトリ	ファイル
/etc/httpd/conf	設定ファイル（httpd.conf など）
/etc/init.d	各種サーバ制御用スクリプト（Apache用はｈｔｔｐｄ）
/usr/lib/apache	モジュールファイル
/usr/sbin	実行ファイル（apachectl など）
/var/log/httpd	アクセスログ
/var/www/html	WEBページで使用するHTML文書や画像（サーバルートとなる）
/var/www/cgi-bin	WEBページで使用するCGIプログラム
/var/www/icons	ファイル一覧などで使用するアイコン画像

RedHat では rpm でのインストールを前提としているため、上記の構成となっている。将来、ＦＨＳに移行した場合、すべてのＵＮＩＸがファイル構成を統一することになるが、それまでは管理者がディレクトリ構造を把握しているしかない。たとえば後からインストールしたアプリケーションがＡｐａｃｈｅを参照するとき、ソースインストールを前提にしたディレクトリ構造を仮定している、ということがよくあるからである。
ここでソースコードからビルドしてインストールした場合のディレクトリ構成を示す。

ディレクトリ	ファイル
/usr/local/apache2/bin	apachectl などの管理コマンドや実行ファイル
/usr/local/apache2/build	モジュールなどのビルドやインストール用の各種設定
/usr/local/apache2/cgi-bin	ＣＧＩプログラム
/usr/local/apache2/conf	設定ファイル
/usr/local/apache2/error	エラーメッセージ類
/usr/local/apache2/htdocs	ＨＴＭＬ文書など公開用コンテンツ（サーバルートとなる）
/usr/local/apache2/icons	アイコン画像
/usr/local/apache2/include	モジュールなどのコンパイルに必要なヘッダファイル
/usr/local/apache2/lib	ライブラリ
/usr/local/apache2/logs	ログファイル
/usr/local/apache2/man	オンラインマニュアル（man コマンド用）
/usr/local/apache2/manual	Ａｐａｃｈｅのマニュアル文書
/usr/local/apache2/modules	ＡｐａｃｈｅのＤＳＯ（ダイナミックモジュール）

■　Apache　モジュール

Apache 　WEBサーバはプログラム本体となるコアモジュールを始めとして、多数の機能モジュールによって構成されている。これらのモジュールはコンパイル時にスタティックに組み込んでしまうこともできるが、通常は機能が呼び出されたときだけダイナミックロードされ、無駄なメモリを使わないように考慮されている。これを特にDSO( Dynamic Shared Object ) と呼ぶ。また apache モジュールにはサードパーティによるものも多数存在し、それぞれhttpd.conf に記述した上でモジュールディレクトリに配置することによって実装することができる。（たとえばBAE社の weblogic 用のモジュールである mod_wl など。）

以下に httpd.conf のモジュール指定部分を示す。

# Dynamic Shared Object (DSO) Support
#
# To be able to use the functionality of a module which was built as a DSO you
# have to place corresponding `LoadModule' lines at this location so the
# directives contained in it are actually available _before_ they are used.
# Statically compiled modules (those listed by `httpd -l') do not need
# to be loaded here.
#
# Example:
# LoadModule foo_module modules/mod_foo.so
#
LoadModule access_module modules/mod_access.so
LoadModule auth_module modules/mod_auth.so
LoadModule auth_anon_module modules/mod_auth_anon.so
LoadModule auth_dbm_module modules/mod_auth_dbm.so
LoadModule auth_digest_module modules/mod_auth_digest.so
LoadModule ldap_module modules/mod_ldap.so
LoadModule auth_ldap_module modules/mod_auth_ldap.so
LoadModule include_module modules/mod_include.so
LoadModule log_config_module modules/mod_log_config.so
LoadModule env_module modules/mod_env.so
LoadModule mime_magic_module modules/mod_mime_magic.so
LoadModule cern_meta_module modules/mod_cern_meta.so
LoadModule expires_module modules/mod_expires.so
LoadModule deflate_module modules/mod_deflate.so
LoadModule headers_module modules/mod_headers.so
LoadModule usertrack_module modules/mod_usertrack.so
LoadModule setenvif_module modules/mod_setenvif.so
LoadModule mime_module modules/mod_mime.so
LoadModule dav_module modules/mod_dav.so
LoadModule status_module modules/mod_status.so
LoadModule autoindex_module modules/mod_autoindex.so
LoadModule asis_module modules/mod_asis.so
LoadModule info_module modules/mod_info.so
LoadModule dav_fs_module modules/mod_dav_fs.so
LoadModule vhost_alias_module modules/mod_vhost_alias.so
LoadModule negotiation_module modules/mod_negotiation.so
LoadModule dir_module modules/mod_dir.so
LoadModule imap_module modules/mod_imap.so
LoadModule actions_module modules/mod_actions.so
LoadModule speling_module modules/mod_speling.so
LoadModule userdir_module modules/mod_userdir.so
LoadModule alias_module modules/mod_alias.so
LoadModule rewrite_module modules/mod_rewrite.so
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_ftp_module modules/mod_proxy_ftp.so
LoadModule proxy_http_module modules/mod_proxy_http.so
LoadModule proxy_connect_module modules/mod_proxy_connect.so
LoadModule cache_module modules/mod_cache.so
LoadModule suexec_module modules/mod_suexec.so
LoadModule disk_cache_module modules/mod_disk_cache.so
LoadModule file_cache_module modules/mod_file_cache.so
LoadModule mem_cache_module modules/mod_mem_cache.so
LoadModule cgi_module modules/mod_cgi.so
#LoadModule weblogic_module modules/mod_wl_20.so

※なお module の機能の詳細についてはapache module のマニュアルを参照すること。（最後のコメント化しているモジュールは weblogic 用モジュールでデフォルトの httpd.conf には存在しない。）

module ディレクトリは RedHat エンタープライズ Linux では /etc/httpd/modules となっているが、これは /usr/lib/httpd/modulkes へのシンボリックリンクである。実体のモジュールは同リンク先にあるので別途モジュールを実装したい場合はこのディレクトリにファイルを置き、httpd.conf の Loadmodule ディレクティブに以下のフォーマットで記述すればよい。

　　　　　　LoadModule <module の呼称> modules/<module>.so

■　起動と実行

Apache の起動と実行制御は通常、apachectl コマンドによって行う。1.3系は /usr/sbin/apachectl parameter の形式だが、2.0系は先に述べたとおりパスが違う（ /usr/local/apache2/bin/apachectl parameter　）ので注意すること。
一方、RedHat では service コマンドがあるため、service httpd <コマンド>　の形式で起動・停止を制御できる。

コマンド	内　　　　容
start	httpd の起動
startssl	ssl を有効にした httpd の起動
stop	httpd の停止
restart	httpd の再起動（未起動の場合、start に同じ）
fullstatus	httpd の状態を詳細に表示（mod_status と lynx が必要）
status	httpd の状態を簡潔に表示（mod_status と lynx が必要）
graceful	httpd の安全な再起動（接続しているユーザがいる場合、切断を待って再起動する）
configtest	設定ファイルの文法チェック
help	apachectl 自体のヘルプ（引数の意味などを示す）

Ａｐａｃｈｅが正しく起動しているかどうかは、次のコマンドで検証する。

　　　　　$ ps aux | grep httpd

Tera Term から実行したコマンドの結果と表示されるプロセスの状態例を以下に示す。見るとおり、httpd は複数起動しているが、これが正常な状態である。これは Apache の起動と実行の特徴で、最初に起動される httpd だけが root を Owner とし、それ以降に起動されるプロセス（スレッド）の Owner は親プロセスの Apache となる。

Apache process

Apache の実用的な設定

■　httpd.conf の概要

Apache １．３より前の古いバージョンでは httpd.conf のほかに srm.conf および access.conf の設定ファイルがあったが、現在では httpd.conf 一本に集約されている。httpd.conf は単純なテキストファイルで vi などで編集することができる。設定項目はディレクティブ方式になっており、設定コマンド＋設定値をイメージするとわかりやすい。またディレクティブによってはコンテナ（ブロック）単位で設定するものもあり、こちらは感覚的にマクロに近いものとなっている。

httpd.oconf ファイルは次の３つのセクションから成っている。

セクション	名称	内　　　容
Section 1 :	Gloval Environment	Apacheのコア部分のMPMの設定など全般の環境設定
Section 2 :	'Main' Server configuration	Apacheの基本サーバの設定部分
Section 3 :	Virtual Hosts	Apacheのバーチャルホスト設定（バーチャルホストとは一台のApacheマシンで複数のWEBサーバを稼動させるための仕組み。SSLではバーチャルホストで対応し、それぞれ別のポートを使う。）

httpd.conf で重要な設定項目について下表にまとめる。ディレクティブの総数は２．０系になって約２８０項目と１．３系列に比べて倍近く増加している。それだけに細かい設定ができるようになっているが、全部を吟味していてはきりがないばかりか、設定内容に矛盾が出たりするので、運用上はあまり細部までの設定を狙わない方がよい。

ディレクティブ	設定値	内容
Listen	80	待ち受けポートを８０番に設定（ユーザ権限で動かしたいときは８０８０などに設定する）
User	nobody	ユーザ権限を nobody とする
Group	#-1	グループIDを＃１とする
ServerAdmin	webmaster@mydomain.com	サーバ管理者のメールアドレス
DocumentRoot	"/usr/local/apache2/htdocs"	ドキュメントルートの指定
UserDir	public	ユーザディレクトリの指定
DirectoryIndex	index.html index.html.var index.cgi index.shtml	最初に実行されるファイル名と拡張子
AccessFileName	.htaccess	アクセス制御ファイルを .htaccess に指定
TypesConfig	/usr/local/apache2/conf/mime.types	ブラウザに対するファイル拡張子の指定ファイル
DefaultType	application/octet stream	未知の拡張子を持つファイルをすべてバイナリとして取り扱う
HostnameLookups	off	ログをIPアドレスのまま残し、DNSによる名前解決をさせない
ErrorLog	/usr/local/apache2/logs/error_log	エラーログのディレクトリとファイル名
LogFormat	"%h %l %u %t \"%r\" %>s %b" common	ログファイルの形式指定
CustomLog	logs/access log common	アクセスログの取得指定
Alias	/project/ "/opt/project/data/"	ユーザにアクセスさせる任意のディレクトリの別名。これを指定することによってApacheのドキュメントツリーに編入する。
ScriptAlias	/cgi-bin/ "/usr/local/apache2/cgi-bin/"	スクリプトを設置する任意のディレクトリの別名。これを指定することによってドキュメントツリーに編入する。
Options	Includes ExecCGI	SSI・CGIの実行許可
AllowOverride	All	上書きの許可
Allow	from 192.168.1.0	許可するホスト
Deny	from All	拒否するホスト
Order	deny,allow	アクセス制御の優先順位
ServerTokens	ProductOnly	サーババージョンを非表示
ServerSignature	Off	サーバエラーメッセージの非表示
SetEnvIf	User-Agent "Ninja" deny_ua order allow,deny allow from all deny from env=deny_ua	インターネット巡回ソフトNinjaによるアクセスを禁止
SSLEngine	on	SSL/TLSを有効にする

■　アクセス制御

Apache ではディレクトリごとのユーザ認証とアクセス制御が可能である。この機能を利用するためには mod_auth モジュールが必要である。現在のディストリビューションではほとんどがデフォルトで mod_auth を組み込んであるが、こちらも存在を確認しておくとよい。

　　　　　　$ /usr/local/apache2/bin/httpd -l

これによって出力されるモジュールに mod_auth.so が含まれていればアクセス制限機能が利用できる。モジュールが静的に組み込まれていない場合でも mod_so があり /usr/local/apache2/modules に mod_auth.so があればダイナミックモジュールとして利用できる。この場合は httpd.conf に次の設定を追加すればよい。

　　　　　　Loadmodule auth_module modules/mod_auth.so

どちらでもないとすれば、ビルド時になんらかの事情によって認証機能が外された（「--disable-auth」オプションで可能）としか考えられないが、この場合でも configure からリビルドすればデフォルトで mod_auth が使えるようになる。

　　　１．httpd.conf の設定によるアクセス制御　

ユーザ認証に使う mod_auth 関連ディレクティブは以下のとおり。

ディレクティブ	モジュール名	機能
AuthGroupFile	mod_auth	グループ単位でアクセス制限を行う場合に参照するファイル名（フルパス指定・いらない場合は /dev/null を指定する）
AuthName	Core	ユーザ認証の際の入力ボックスに表示する文字列の指定
AuthTyoe	Core	認証タイプの指定（通常はBasicを使用）
AuthUserFile	mod_auth	ユーザ認証用ファイル
Require	Core	アクセスを許可するユーザの指定 user→指定したユーザIDのユーザ group→指定したグループIDのユーザ valid-user→認証に成功したすべてのユーザ

ここでは /usr/local/apache2/htdocs/private というディレクトリにBasic認証をかける設定例を示す。

　　　　　<Directory /usr/local/apache2/htdocs/private>

　　　　　　　　AuthName "Private directory."
　　　　　　　　AuthType Basic
　　　　　　　　Require valid-user
　　　　　　　　AuthUserFile /usr/local/apache2/conf/.htpasswd
　　　　　　　　AuthGroupFile /usr/local/apache2/conf/.htgroup

　　　　　</Directory>

　　　２．認証用パスワードファイルの生成　

上記の設定例ではユーザ認証用のファイルは /usr/local/apache2/conf/.htpasswd とされている。もちろん、このファイルは標準で用意されているわけではなく、管理者がみずから作成しなければならない。認証用のファイルを作成し、ユーザを登録するには管理者権限で htpasswd コマンドを使う。初回はデータベースを作成するための -c オプションをつけること。

　　　　　# cd /usr/local/apache2/conf
　　　　　# ../bin/htpasswd -c .htpasswd user1

二回目以降はすでにファイルが生成されているので -c オプションをつけずに実行する。

　　　　　# ../bin/htpasswd .htpasswd user2
　　　　　# ../bin/htpasswd .htpasswd user3
　　　　　　　　　　　　　…
できあがったデータベースファイル .htpasswd を見ると、ユーザ名に続いて、パスワードがｃｒｙｐｔ関数によってハッシュ暗号化されていることがわかる。暗号強度をさらに高めたいのなら、改造版 md5 アルゴリズムを使用する -m オプションをつけて htpasswd を実行すればよい。

　　　３．.htaccess ファイルによるアクセス制御　

１．Aでディレクティブにアクセス制限を記述する方法を紹介したが、.htaccess ファイルをそれぞれのディレクトリに配置することによってもアクセス制限ができる。.htaccess を配置する前に、先に作った.htpasswd にしたがって .htgroup にアクセス制御を行うユーザをグループとして登録する。

　　　　　$ touch /usr/local/apache2/conf/.htgroup
　　　　　$ vi /usr/local/apache2/conf/.htgroup

vi で空ファイルの .htgroup を編集し、ユーザに適切なグループ名をつけておく。書式は「ユーザグループ名　：　ユーザ名　ユーザ名　ユーザ名　…」の形式で、具体的には次のようにすればよい。

---- .htgroup ----

　　　　webuser : user1 user2 user3 …

ユーザのグループ登録ができたら vi を起動して .htaccess ファイルを作る。内容は次のように記述する。（一見してわかることであるが、この内容は１．Aで紹介したディレクティブ記述とほぼ同じ内容である。）

---- .htaccess ----

　　　　　AuthName "Private directory. "
　　　　　AuthType Basic
　　　　　Require valid-user
　　　　　AuthUserFile /usr/local/apache2/conf/htuser
　　　　　AuthGroupFile /usr/local/apache2/conf/.htgroup
　　　　　<Limit Get>
　　　　　　　　Require Group webuser
　　　　　　　　Require Taro Hanako
　　　　　</Limit>

アクセス制御を実施したい場合、このファイルを制限したいディレクトリに設置すればよい。Apacheはディレクトリにアクセスするとまず .htaccess ファイルがあるかどうかをチェックし、あれば "Private directory. "を表示してベーシック認証を行う。ユーザ名とパスワードが入力されると、Apache は htuser と htgroup を参照し、ユーザまたは所属グループが許可されているかどうかチェックする。
上記 .htaccess の設定では、グループ webuser に属するユーザと Taro および Hanako を許可する。

※　重要　：　Apache　２．０．３９　では htpasswd コマンドの不具合が報告されている。このバージョンのApacheでは登録しようとするとパスワードファイルを上書きしてしまうので、アップグレードしておくこと。

■　その他の設定ファイル

Apache の設定ファイルはこれまでに解説してきたものでほぼ標準的なWEBサイトを構成できる。ここで特殊な用途に使われる設定ファイルを含め、標準でインストールされるその他の設定ファイルを一覧する。

ファイル名	用　　　　　途
highperformance.conf	高負荷サーバ用設定ファイルのテンプレート。使用する場合は通常のhttpd.confを削除し、このファイルをhttpd.confとリネームする。
httpd.conf	通常運用用設定ファイル
magic	バイナリファイルの先頭に記録されるマジック番号とファイル種別の対応一覧表
mime.types	ファイル拡張子と種別対応づけ一覧表
ssl.conf	SSL通信のための設定ファイル（後述）

セキュア通信

■　Ａｐａｃｈｅ　ＳＳＬ（Secure Socket Layer）

１．RedHatなどのメジャーディストリビューションの場合

RedHat　Linux　９ではOpenSSLが標準でインストールされているので、Apacheのインストール後すぐにSSL機能が使用できる。また、公開鍵/秘密鍵/証明書をはじめ、SSL関係の基本的な設定も済んでおり、とにかく急いでSSLが必要という場合は楽ができる。ちなみに、Apache2.0の httpd.conf にはSSL機能を追加するモジュール「mod_ssl」用の設定が、標準で次のように記述してある。

#
# Bring in additional module-specific configurations
#
<IfModule mod_ssl.c>
Include conf/ssl.conf
<IfModule>

この設定は mod_so ライブラリを静的に組み込んだのち、SSLをダイナミックモジュールとして組み込み、SSL自身のコンフィグファイルのパスを conf/ssl.conf に指定したものである。また、ssl.conf の設定もデフォルトで動作するので、RedHat９ではインストール直後から apachectl startssl でSSL通信が可能になる。
なお、クライアント側からSSLを使う場合はブラウザに https:// で開始するアドレスを入力する。このリクエストによってApache－SSLの４４３ポートに接続する。

２．ソースからコンパイルしてインストールする場合

バージョンの古いLinuxを使用している場合や、SSLがサポートされていないディストリビューションではソースからコンパイルしてインストールする必要がある。ここでは Apache 自身もソースコードからコンパイルされ、/usr/local/apache2 以下にそのファイルがインストールされているものとする。

ところで、最近のディストリビューションではほとんどOpenSSLがインストールされているので、無駄手間にならないよう最初にその存在を確認しておくとよい。

　　　　　　$ rpm -q openssl
　　　　　　$ rpm -q openssl-devel

両パッケージがインストールされていたら、OpenSSLはディストリビューションレベルで使用可能な状態にある。この場合はあとは設定の問題となる。もしもパッケージが存在しない場合は、ソースコードをダウンロードしてきてコンパイルする必要がある。以下にOpenSSLのコンパイルの手順を示す。（ここではハードウェア暗号化デバイスをサポートしない標準的なOpenSSL-0.9.6.d を例に説明する。）

　　　２．A　OpenSSLのインストール　

　　　　　１．ソースコードの tarball（openssl-0.9.6d.tar.gz）のダウンロード

　　　　　２．適切なディレクトリ（たとえば /usr/local/src など）での展開

　　　　　　　$ cp ./openssl-0.9.6d.tar.gz /usr/local/src/
　　　　　　　$ tar zxvf openssl-0.9.6d.tar.gz

　　　　　３．生成された openssl-0.9.6d. ディレクトリへの移動

　　　　　　　$ cd openssl-0.9.6d.

　　　　　４．ビルドスクリプト configure の実行による makefile の作成

　　　　　　　$ ./configure

　　　　　５．コンパイル

　　　　　　　$ make
　　　　　　　$ make test

　　　　　６．インストール

　　　　　　　$ su
　　　　　　　# make install

　　　　　注：OpenSSLはデフォルトで /usr/local/ssl ディレクトリにインストールされる。

　　　２．B　mod_ssl のインストール　

ApacheからOpenSSLを利用できるようにするモジュールが mod_ssl である。ApacheでSSL通信を行うにはこのモジュールの組み込みが必要であり、これも最初に存在を確認しておくとよい。

　　　　　　$ /usr/local/apache2/bin/httpd -l

この出力に mod_ssl が含まれていればSSL機能は有効となっている。また、httpd -l コマンドによって mod_so が検出され、/usr/local/apache2/modules に mod_ssl.so があれば、SSL機能をダイナミックモジュールとして利用できる。この場合はもちろんモジュールをインストールする必要はない。

mod_ssl のインストールはApache本体のリビルドによって行う。ここではソースアーカイブからOpenSSLをインストールし、OpenSSLがデフォルトの/usr/local/ssl 以下にあるものとする。

　　　　　　$ ./configure --enable-ssl --with-ssl=/usr/local/ssl

またこのときダイナミックモジュールとしてリビルドしたい場合は次のようにする。

　　　　　　$ ./configure --enable-ssl --with-ssl=shared

※　重要：ダイナミックモジュールとしてリビルドした場合は httpd.conf に次の設定を記述すること。

　　　　　　LoadModule ssl_module modules/mod_ssl.so

　　　２．C　ペアキーの作成と証明書の作成　

SSL通信では公開鍵/秘密鍵のペアと、サーバ認証用の証明書を作成する必要がある。まず最初にサーバの秘密鍵を作成する。これにはOpenSSLのコマンドを使う。

　　　　　　$ openssl genrsa -des3 1024 > server.key

コマンドを入力すると、システムはパスフレーズを尋ねてくるので適切なパスフレーズを入力する。このパスフレーズは他の鍵や証明書を作るときにも使用し、さらにSSLを起動するときにも必要になるので、きちんと憶えておく必要がある。秘密鍵ができたら公開鍵を作成する。

　　　　　　$ openssl req -new -key server.key > server.csr

ここでも最初にパスフレーズが尋ねられるので、間違えないように入力する。その後、システムが国名や管理者名を尋ねてくるのでそれぞれ入力する。大体は考え込むこともないはずだが、「Common　Name」に関しては管理者名またはFQDNを入力しておけばよい。
公開鍵を作ったら、今度は証明書を作成する。

　　　　　　$ openssl x509 -in server.csr -req -signkey server.key > server.crt

ここでもまたパスフレーズが尋ねられる。入力が完了すると証明書が完成する。完成した3つのファイルをそれぞれ格納ディレクトリに移動する。この際、格納ディレクトリは root 権限で作成し、５００のアクセス権をつけておく。

　　　　　　# mkdir /usr/local/apache2/conf/ssl.key
　　　　　　# chmod 500 /usr/local/apache2/conf/ssl.key
　　　　　　# mv server.key server.csr /usr/local/apache2/conf/ssl.key

　　　　　　# mkdir /usr/local/apache2/conf/ssl.crt
　　　　　　# mv server.crt /usr/local/apache2/conf/ssl.crt

　　　２．D　ssl.conf の設定　

SSLの起動時に読み込まれるファイルが ssl.conf であるが、このファイルはほとんどデフォルトのままで変更の必要は少ない。バーチャルホストのIPアドレスなど記入が必要になる部分を以下に示す。（赤字は変更例です。それぞれの環境に合わせて設定してください。）

デフォルト：
　　　　　　<VirtualHost _default_:443>
　　　　　　# General setup for the virtual host
　　　　　　Document root "/usr/local/apache2/htdocs
　　　　　　ServerName new.host.name:443
　　　　　　ServerAdmin you@your.address

変更例：
　　　　　　<VirtualHost 192.168.1.1:443>
　　　　　　# General setup for the virtual host
　　　　　　Document root "/usr/local/apache2/htdocs
　　　　　　ServerName sslserver.mydomain.com:443
　　　　　　ServerAdmin webmaster@mydomain.com

付録

■　Apache のバージョンを隠す方法

httpd.confに次のような設定を施す。

ServerTokens ProductOnly # デフォルトはFull
ServerSignature Off # エラーメッセージ用バージョン情報をOffにする

注意： Apache にはバージョンによって多くのセキュリティホールが報告されている。この意味でバナー情報を隠しておくのはそれなりの効果があるが、言うまでもなくこれは時間稼ぎにすぎず、本質的な対策とはならない。Apache そのもののセキュリティホールが報告されたらすぐさま対応を取れるよう、管理者は常にセキュリティ情報に目を配る必要がある。

また、Apache のセキュリティホールをふさいでも、肝心のWEBアプリケーションに問題があったのではどうにもならない。CGI の入力チェックに漏れはないか、クロスサイトスクリプティングが実行される危険はないかなど、セキュリティ担当者（管理者）にはWEBアプリケーションのコードレベルでのチェックも要求されることがあるので、ある程度のコーディング知識も必要である。

付録　A HTTPメソッドおよびヘッダ一覧

メソッド/ヘッダ	書　　式	内　　容
要求メソッドクライアント→サーバ	GET	サーバに対してHTMLや画像データを要求
	HEAD	サーバに対してメタデータを要求
	POST	サーバ側のCGIへ，パラメータの引き渡し
	PUT	サーバに対してデータを送信する
	DELETE	ユーザ認証後，サーバのデータ削除
	LINK	URLで指定したリソースと他の情報との関連付け
	UNLINK	LINKメソッドで指定した関連付けの解除
汎用ヘッダクライアント⇔サーバ	Connection: 制御命令	接続制御
	Data: 日時	現在の日時
	MIME-Version: バージョン	MIMEバージョン
要求ヘッダクライアント→サーバ	Accept: 型	対応するメディアの形式
	Accept-Language: 言語	対応する言語（jpやenなど）
	Accept-Encoding: 方式	対応するエンコード方式
	Host: ホスト名 [: ポート番号]	サーバのホスト名（IPアドレス）
	Cookie: 名称	前回サクセス時に，Webサーバから受け取ったクッキー情報
本体ヘッダクライアント⇔サーバ	Content-Length: バイト	データ長をバイトで表現
	Content-Type: 型／副型	本体のメディアタイプ "text/html" はテキスト形式によるhtml情報
	Content-Language: 言語	本体の言語
	Last-Modified: 日時	最終更新日時
	ETag:識別値	本体の識別情報
応答ヘッダクライアント←サーバ	Accept-Ranges: bytes/none	Range指定をbyte単位で受けるか否か
	Server: プログラム名	サーバソフトウェアの識別名
	Set-Cookie; 名前	クッキーの情報

付録　B　HTTP応答コード一覧

HTTP ステータスメッセージ(HTTP 1.1 - RFC2616)
1xx:	Informational	このステータスコードの分類はステータス行とオプショナルヘッダのみで構成される暫定的な応答です。空行で終了します。このステータスコードのクラスに必要なヘッダーは特にありません。
100	Continue	クライアントはリクエストを継続する必要があります。この暫定的な応答はリクエストの最初の部分が受信され、まだリジェクトされていない状態を表します。クライアントは残りのリクエストを送信し続ける必要があります。リクエストの送信がすでに完了している場合は、この応答を無視します。サーバはリクエストの送信が完了すると、最終的な応答を返します。
101	Switching Protocols	サーバは、アップグレードメッセージヘッダーフィールドを介して、この接続に使用されているアプリケーションプロトコルへの変更要求を解釈し、これに応じます。サーバは、101 応答を終了させる空行の直後、アップグレードヘッダーフィールドに定義されたプロトコルに切り替えます。
2xx:	成功	このステータスコードの分類は、クライアントリクエストの受信、解釈、受付が成功したことを示します。
200	OK	リクエストが成功しました。応答に付随する情報は、リクエストのメソッドによって異なります。
201	Created	リクエストが実行され、新規リソースが作成されました。新規に作成されたリソースは、応答のエンティティ中に、ロケーションヘッダーフィールドに最も明確なURLとして定義されている URL から参照できます。応答には、リソースの特性およびロケーションのリストを記述した、エンティティが含まれている必要があります。ユーザーやユーザーエージェントは、このリストから適切なロケーションを選択します。
202	Accepted	リクエストは、処理のために受理されましたが、処理が完了していません。リクエストは、処理される場合と、処理の段階で許可されずに失敗する場合があります。このような非同期動作の発生時に、ステータスコードを再送信する機能はありません。
203	Non-Authoritative Information	返されたエンティティヘッダーのメタ情報が、ローカルまたはサードパーティコピーから集められたものであり、オリジンサーバから利用できるような信頼性のあるセットではありません。
204	No Content	サーバはリクエストを実行しましたが、リクエストはエンティティボディーを返さず、場合によっては更新したメタ情報を返します。応答には、更新されたメタ情報がエンティティヘッダーとして含まれている場合があり、この情報はリクエスト変数に関連付けられている必要があります。
205	Reset Content	サーバはリクエストを実行しました。ユーザーエージェントはリクエストを送信したドキュメントビューをリセットしなくてはなりません。この応答は、アクションに対する入力の後、この入力画面をクリアすることで、ユーザーが簡単に別の入力を開始できるように設定することを目的としています。
206	Partial Content	サーバは、リソースに対する GET リクエストを部分的に実行しました。
3xx:	リダイレクション	このステータスコードの分類は、リクエストを完了するために、ユーザーエージェントによって実行されるべきアクションが残っていることを示します。メモ : 以前の HTTP バージョンの仕様では、リダイレクションを 5 回以下にとどめることを勧めています。コンテンツの開発者は、このような制限を導入しているクライアントについて考慮する必要があります。
300	Multiple Choices	要求されたリソースがそれぞれ固有のロケーションを持つ表現セットのいずれかに相当し、agent-driven ネゴシエーション情報が提供されているため、ユーザーまたはユーザーエージェントは最適な表現を選択して、選択した表現セットのロケーションにリダイレクトできます。
301	Moved Permanently	リクエストされたリソースに対して、新規の永久的なURLが割り当てられているため、今後このリソースの参照には、返された URL のいずれかを使用します。
302	Found	要求されたリソースは、一時的に別の URL に存在しています。このリダイレクションは変更される可能性があるため、クライントは今後も元の URL を使用する必要があります。この応答は、Cache-Control または Expires ヘッダーフィールドに記述されている場合のみキャッシュ可能です。
303	See Other	この応答は、リクエストとは別の URL において表示されることがあり、このリソースを GET メソッドで獲得する必要があります。このメソッドは、POST-activated スクリプトの出力を、選択されたリソースにユーザーエージェントでリダイレクトすることを可能にします。この別の URL は、もともとリクエストしたリソースの代わりとなる参照先ではありません。
304	Not Modified	クライアントが条件付きの GET リクエストを実行し、アクセスが許可されたにもかかわらず、ドキュメントが更新されていなかった場合、サーバはこのステータスコードを返します。
305	Use Proxy	リクエストされたリソースは、ロケーションフィールドで指定されたプロキシを通してアクセスされなければなりません。
306	(Unused)	305 ステータスコードは、以前のバージョンの仕様で使用されていましたが、現在では使用されておらず、コードは予約されています。
307	Temporary Redirect	要求されたリソースは、一時的に別の URL に存在しています。このリダイレクションは変更される可能性があるため、クライントは今後も元の URL を使用する必要があります。
4xx:	クライアントエラー	4xx 分類のステータスコードは、クライントが間違いを犯した場合に使用されます。 HEAD リクエストに応答する場合以外は、サーバはエラー状況の説明を記述したエンティティを含んでいるはずです。これは、エラーが一時的または永久的、どちらの場合でも同じです。
400	Bad Request	リクエストの構文が不正なため、サーバがリクエストを理解できません。
401	Unauthorized	リクエストには、ユーザー認証が必要です。代表的なものにユーザー名とパスワードを対にした認証証明などがあります。すでに、リクエストに証明が含まれている場合、401 応答は認証がこの証明を拒否したことを示します。
402	Payment Required	このコードは将来の使用のために予約されています。
403	Forbidden	サーバはリクエストを理解しましたが、実行を拒否しました。認証は無効であるため、リクエストを繰り返すべきではありません。
404	Not Found	サーバはリクエストされた URL を検出できませんでした。この状態が一時的、または永久的どちらであるかは判断できません。 410 (Gone) ステータスコードは、サーバが内部構造メカニズムによって、古いリソースが永久に無効となり、転送アドレスを持たないと判断した場合に使用されます。通常、このステータスコードは、要求拒否の正確な理由を明らかにしたくない場合や、他の応答を適用できない場合に使用されます。
405	Method Not Allowed	このリクエスト行に定義されたメソッドは、リクエスト URL で識別されたリソースでは許可されていません。
406	Not Acceptable	リクエストで識別されたリソースでは、リクエストの accept ヘッダーに含まれる、受け入れ不可能な内容特性を記述した応答エンティティの生成のみが可能です。
407	Proxy Authentication Required	このコードは、401(Unauthorized) と類似していますが、クライアントはまず始めにプロキシで認証される必要があることを示します。
408	Request Timeout	クライントは、サーバが設定した待ち時間以内にリクエストを完了できませんでした。クライアントは、同じリクエストをしばらくしてから繰り返すことができます。
409	Conflict	リクエストは、リソースの現在の状態と矛盾するため、完了できませんでした。このコードは、ユーザー自身がこの矛盾を解消し、リクエストを再実行できると予想される場合のみ使用できます。
410	Gone	リクエストされたリソースは、サーバ上ですでに無効となっており、転送先のアドレスもわかりません。この状況は永久的なものと考えられます。
411	Length Required	サーバで定義されたコンテンツの長さを満たしていないため、リクエストが拒否されました。
412	Precondition Failed	リクエストヘッダーフィールドに記述された前提条件のうちいくつかが、サーバでのテストで偽であると判定されました。この応答コードは、クライアントが現在のリソースのメタ情報 (ヘッダーフィールドのデータ) で前提条件を設定することを可能にし、意図したリソース以外へのリクエストメソッドの適用を防止します。
413	Request Entity Too Large	リクエストエンティティがサーバの許容範囲を超えたため、サーバがリクエストの処理を拒否しました。サーバは、クライアントがリクエストを繰り返すことを防ぐために、接続を閉じる場合があります。
414	Request-URI Too Long	リクエスト URL の長さがサーバの許容範囲を超えたため、サーバは、リクエストの処理を拒否しました。この状況はまれで、クライアントが長いクエリー情報を伴う POST リクエストを、不当に GETリクエストに変換した場合、クライアントがリダイレクションの URL "ブラックホール" に陥った場合(リダイレクション URL のプレフィクスが、現在のURL自身のサフィックスを指定している場合など)、またはサーバがクライアントから、リクエスト URL の読み出しおよび操作のための固定長バッファの使用によるセキュリティホールを悪用したアタックを受けている場合だけに発生する傾向があります。
415	Unsupported Media Type	リクエストのエンティティが、リクエストメソッドに対してリクエストされたリソースのサポートしていないフォーマットであるため、サーバはリクエストの処理を拒否しました。
416	Requested Range Not Satisfiable	リクエストに Range リクエストヘッダーフィールドが含まれ、このフィールド内の range-specifier の値が、選択したリソースの現在の範囲とは重複せず、さらにリクエストに If-Range リクエストヘッダーフィールドが含まれない場合、サーバはこのステータスコードを返します。
417	Expectation Failed	Expect リクエストヘッダーの期待値がサーバで満たされない、またはサーバがプロキシであり、次のホップで要求が満たされないという明白な根拠がある場合に生成されるメッセージです。
5xx:	サーバエラー	"5" で始まるステータスコードは、サーバにエラーがあるか、処理できないリクエストであるとサーバが判断したことを示します。 HEAD リクエストに応答する場合以外は、サーバはエラー状況の説明を記述したエンティティを含んでいるはずです。これは、エラーが一時的または永久的、どちらの場合でも同じです。ユーザーエージェントはこのエンティティをユーザーに対して表示します。
500	Internal Server Error	サーバは、リクエスト実行の障害となる、予期しない状態に遭遇しました。
501	Not Implemented	サーバは、リクエストの実行に必要な機能をサポートしていません。これは、サーバがリクエストメソッドを認識できず、どのようなリソースに対してもこのメソッドをサポートする能力がない場合に適切なレスポンスです。
502	Bad Gateway	ゲートウェイやプロキシとして動作しているサーバが、リクエストを実行するためにアクセスした上層のサーバから、無効なレスポンスを受け取りました。
503	Service Unavailable	サーバは現在、一時的な過負荷またはサーバメンテナンスため、リクエストを処理できない状態です。つまりこの状態は、一定期間を過ぎると回復します。メモ : サーバの負荷状態で必ずこのコードを使用する必要はありません。サーバによっては、単純に接続を拒否する場合もあります。
504	Gateway Timeout	ゲートウェイやプロキシとして動作するサーバが、リクエストを完了するために URL (HTTP、FTP、LDAP など) で指定された上層のサーバ、またはその他の補助的なサーバ (DNS など) にアクセスしたとき、適切な時間内に応答を受信できませんでした。メモ : 一部のプロキシでは、DNS 検索タイムアウトの場合 400 または 500 を返します。
505	HTTP Version Not Supported	サーバは、リクエストメッセージで使用されている HTTP プロトコルバージョンをサポートしていないか、サポートを拒否しました。

[トップページ][Linux][2000 Server][ネットワーク事例][ネットワーク管理Tiｐｓ]