← 戻る

Apache設定まるわかり!よく使うディレクティブ解説

tokeisan4 tokeisan4

このサイトを自宅サーバー(RHEL + Apache httpd)で運用する中で、実際に使ってきたApacheの設定項目(ディレクティブ)を、体系立ててまとめてみます。公式ドキュメントは網羅的すぎて最初はとっつきにくいので、「実際に何のために使うのか」という視点で整理していきます。 ■ そもそもディレクティブとは Apacheの設定ファイル(httpd.confや、conf.d以下の個別ファイル)に書く、1行1行の設定項目のことをディレクティブと呼びます。「このURLパスにはこの権限が必要」「このドメインが来たらこのアプリを表示する」といった、Apacheの振る舞いを決める命令文だと考えると分かりやすいです。 ■ VirtualHost:1台のサーバーで複数サイトを扱う 同じサーバー上で、異なるドメインや異なるポートごとに別々のサイトを配信するための仕組みです。 <VirtualHost *:443> ServerName example.com ServerAlias www.example.com SSLEngine on SSLCertificateFile /etc/httpd/ssl/server.crt SSLCertificateKeyFile /etc/httpd/ssl/server.key </VirtualHost> ServerNameで、このVirtualHostがどのドメインへのリクエストに反応するかを指定します。ServerAliasは、追加で反応させたい別名(wwwありなし等)を指定する際に使います。 ■ WSGIDaemonProcess・WSGIScriptAlias:Pythonアプリとの連携 DjangoのようなPython製Webアプリケーションを動かすには、mod_wsgiというモジュールを使います。 WSGIDaemonProcess myapp python-home=/path/to/venv python-path=/path/to/project WSGIProcessGroup myapp WSGIScriptAlias / /path/to/project/project/wsgi.py WSGIDaemonProcessは、Apacheの本体プロセスとは別に、Pythonアプリ専用の子プロセスを立ち上げる設定です。python-homeには仮想環境(venv)のパス、python-pathにはDjangoプロジェクトのパスを指定します。WSGIScriptAliasは、どのURLパスにアクセスされたら、どのwsgi.pyファイルを呼び出すかを紐付けます。 なお、WSGIApplicationGroup %{GLOBAL} という設定を追加しないと、「populate() isn't reentrant」というエラーが出ることがあります。これは、複数のPythonアプリケーションが同じインタプリタ内で衝突しないようにする設定で、Django単体で運用する場合は基本的に付けておくとトラブルを避けられます。 ■ Alias:静的ファイルの配信場所を指定する 画像やCSSなど、Pythonを介さずそのまま配信したいファイル群のために使います。 Alias /static/ /data/static/ <Directory /data/static/> Require all granted </Directory> Aliasで「このURLパスへのアクセスは、実際にはこのディレクトリの中身を見せる」という対応関係を作ります。続くDirectiveブロックで、そのディレクトリへのアクセス許可を明示的に与える必要があります。 ■ Require:アクセス制御 誰がそのURLパス・ディレクトリにアクセスできるかを制御します。 <Location /admin/> Require ip 192.168.11.0/24 </Location> この例では、管理画面へのアクセスを、自宅LAN内のIPアドレス帯だけに制限しています。全世界に公開したくない管理系のパスには、このような制限をかけておくと安心です。全員に許可したい場合はRequire all grantedを使います。 ■ SSLEngine・SSLCertificateFile:HTTPS化 <VirtualHost *:443> SSLEngine on SSLCertificateFile /etc/httpd/ssl/server.crt SSLCertificateKeyFile /etc/httpd/ssl/server.key </VirtualHost> SSLEngine onで、そのVirtualHostにSSL/TLSによる暗号化通信を有効にします。証明書ファイルと秘密鍵ファイルのパスを、それぞれ指定します。自己署名証明書を使う場合、ブラウザに警告が出ますが、リバースプロキシ(Cloudflareなど)を前段に置いている場合は、オリジンサーバー同士の通信としては許容されることもあります。 ■ RewriteEngine・RewriteRule:URLの書き換え RewriteEngine On RewriteCond %{HTTPS} off RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L] httpでのアクセスを、httpsへ自動的にリダイレクトする、よくあるパターンです。RewriteCondで条件(この場合「HTTPSが使われていない場合」)を指定し、RewriteRuleで実際の書き換えルールを定義します。ただし、特定のパス(Zabbixの管理画面など)だけリダイレクトの対象から除外したい場合は、RewriteCondに除外条件を追加する必要があります。 ■ ModSecurity関連ディレクティブ:WAF(Webアプリケーションファイアウォール) SecRuleEngine On SecAuditLog /data/log/httpd/modsec_audit.log SecDebugLog /data/log/httpd/modsec_debug.log SecRuleEngineは、ModSecurityの動作モードを指定します。Onにすると実際に攻撃をブロックし、DetectionOnlyにすると検知だけ行いブロックはしません。運用開始直後は、誤検知が多くないか確認するためDetectionOnlyで様子を見て、問題なければOnに切り替えるという段階的な進め方がおすすめです。個別のルールを除外したい場合は、以下のように書きます。 SecRuleRemoveById 931120 SecRuleRemoveById 942360 長文投稿など、特定の入力パターンで実行時エラー(PCRE limits exceeded)が起きるルールがある場合、こうしてIDを指定して個別に無効化できます。 ■ ログ関連ディレクティブ ErrorLog /data/log/httpd/error_log CustomLog /data/log/httpd/access_log combined ErrorLogはApache自体のエラーや、アプリケーション側の例外(Djangoのトレースバックなど)が記録される場所です。CustomLogは、誰がいつどのURLにアクセスしたかというアクセスログを記録します。combinedというのは、記録するログの書式(フォーマット)の名前です。 ■ MPM(Multi-Processing Module)関連ディレクティブ <IfModule mpm_event_module> StartServers 3 MinSpareThreads 75 MaxSpareThreads 250 ThreadsPerChild 25 MaxRequestWorkers 400 MaxConnectionsPerChild 0 </IfModule> Apacheが同時にどれだけのリクエストをさばけるかを制御する設定です。StartServersは起動時に立ち上げる子プロセスの数、ThreadsPerChildは1つの子プロセスが持つスレッド数、MaxRequestWorkersは全体で同時に処理できる最大リクエスト数です。サーバーのメモリ・CPUに余裕がある場合は、これらの数値を大きめに設定することで、アクセス集中時の余裕を持たせられます。逆に、小規模なサーバーで数値を大きくしすぎると、メモリ不足でサーバー全体が不安定になることもあるため、搭載メモリとの兼ね合いで調整する必要があります。 ■ セキュリティ関連ヘッダーのディレクティブ(Django側での設定が主だが参考として) Apache単体でも、以下のようなヘッダー付与用ディレクティブがあります。 Header always set X-Frame-Options "DENY" Header always set X-Content-Type-Options "nosniff" X-Frame-Optionsは、自分のサイトが他サイトの中にiframeとして埋め込まれることを防ぐ、クリックジャッキング対策の定番設定です。今回はアプリケーション側(Django)で同等の設定をしていますが、Apache側でも二重に設定しておくと、より確実な防御になります。 ■ まとめ Apacheの設定は、最初は項目数の多さに圧倒されますが、「誰に」「何を」「どう見せるか」という3つの軸で整理すると理解しやすくなります。VirtualHostとServerNameで「誰宛のリクエストか」を決め、AliasやWSGIScriptAliasで「何を見せるか」を決め、RequireやModSecurityで「どう制御するか」を決める、という構造を意識すると、設定ファイル全体の見通しが良くなるはずです。 今回紹介したディレクティブは、実際にこのサイトの運用の中で使ってきたものばかりです。設定ファイルをいじる際は、必ずapachectl configtestで文法チェックをしてから再起動する習慣をつけておくと、設定ミスによるサービス停止を防げます。

コメント(0)