序章

Apache Webサーバーは、現在、世界で最も人気のあるWebサーバーです。 あらゆる種類のWebコンテンツを提供するために使用され、高度にカスタマイズ可能な強力なアプリケーションです。

多くの人がApache2.2構成構文に精通していますが、一部のディストリビューションは現在、デフォルトでApache2.4とともに出荷されています。 この移行の例は、Ubuntu12.04LTSからのUbuntu14.04LTSです。 ほとんどの場合、構文は同じですが、いくつかの重要な違いがあり、いくつかの一般的なディレクティブは非推奨になっています。

このガイドでは、Apache 2.2のバックグラウンドから取得するときに知っておく必要のある、いくつかの新しい構文とその他の変更について説明します。 Apache2.4を使用したディストリビューションの例としてUbuntu14.04を使用し、Ubuntu12.04などのリリースに付属しているApacheの2.2バージョンと比較します。

承認の変更

Apache 2.4が行う主な変更の1つは、ユーザーを承認するための推奨される方法です。

承認とは、認証されたユーザーが実行できることを定義するディレクティブを指します。 操作またはアクセスを許可するかどうかを決定するための基準を示します。

これは、最初に行わなければならない認証とは異なります。 認証手順は、ユーザーがサーバーに対して自分自身を確実に識別できる方法を定義します。 認証は2.2からあまり変わっていませんが、承認は見直されています。

まず、認証コンポーネントは、以前に認証に使用可能になっていたRequire構文を使用できるようになりました。 これにより、複雑なルールセットに依存するのではなく、承認順序を定義する簡単な方法が作成されます。 代わりに、デフォルトを指定してから例外を指定して、論理的な方法でそれらを並べ替えることができます。

たとえば、トラフィックを受け入れるためのデフォルトを設定できますが、特定の悪意のあるユーザーをブロックしたい場合は、次のようなものを追加できます。

Require all granted
Require not ip 111.111.111.111

これにより、全員を受け入れるデフォルトのポリシーが設定され、リクエストが111.111.111.111IPアドレスから送信されないという修飾子が指定されます。 これを行うには、これらの両方が真である必要があります。これは、RequireAllディレクティブブロックを使用して瞬間的に行う方法を学習します。

承認は、ユーザーまたはグループ自体に基づいて選択できるだけでなく、envhostipを使用するか、キャッチを使用して他の要素を考慮して選択できます。 -すべての値all

  • all :このプロバイダーはすべてのトラフィックに一致します。 デフォルト値の設定に便利です。
  • env :環境変数が設定されているかどうかをテストします。
  • host :これは接続しているクライアントのホスト名をテストするために使用されます。
  • ip :接続しているユーザーのIPアドレスをテストするために使用されます。

これらは、指定された順序に基づいて制御できます。 通常、これらは次の特別なブロックの1つの中に表示されます。

  • RequireAll :アクセスを許可するには、ブロック内のすべての承認要件を満たす必要があります。
  • RequireAny :このブロックの承認要件のいずれかが満たされている場合、このブロックは満たされているとマークされます。
  • RequireNone :リストされている要件のいずれかが成功した場合、ディレクティブは失敗します。

これにより、承認の設定方法に関してかなりの柔軟性が得られます。 これらのディレクティブブロックは、次のように相互にネストできます。

<RequireAny>
    <RequireAll>
        Require user root
        Require ip 123.123.123.123
    </RequireAll>
    <RequireAll>
        <RequireAny>
            Require group sysadmins
            Require group useraccounts
            Require user anthony
        </RequireAny>
        <RequireNone>
            Require group restrictedadmin
            Require host bad.host.com
        </RequireNone>
    </RequireAll>
</RequireAny>

ご覧のとおり、かなり複雑な認証パスを定義できます。 上記の例では、ユーザーがrootであり、IP123.123.123.123から来ているかどうかを承認します。 また、「anthony」という名前のユーザーまたはグループ「sysadmins」または「useraccounts」のメンバーを承認しますが、それらが「restrictedadmin」グループの一部ではないか、bad.host.comのフラグ付きホストから来ている場合に限ります。 ]。

これらの認証ブロックは、アクセス制御に使用されていた従来のディレクティブよりもはるかに理解しやすいものです。 Apacheの過去のバージョンでは、OrderAllow fromDeny from、およびSatisfyディレクティブを使用していました。 これらは削除されていませんが、理解しやすく一貫性のある新しい構文のために廃止されました。

ただし、で、mod_access_compatという別のモジュールに移動されました。 レガシー認証ディレクティブが必要な場合は、必ずこのモジュールを有効にしてください。 ただし、将来のサポートと、選択しているポリシーの影響を理解するのが非常に簡単であるため、新しい構文で条件を実装することをお勧めします。

Apacheのその他の変更

構成ファイルの作成方法に影響を与えることに注意する必要のある他のさまざまな変更があります。

これらの中には、名前を変更したり、新しいデフォルトを上書きしたりする必要がある場合があります。 ここに変更の完全なリストがありますが、つまずく可能性のあるもののいくつかについて説明します。

接続と子の制限

いくつかのディレクティブは、それらの機能をよりよく説明するために名前が変更されました。

  • MaxConnectionsPerChild :このディレクティブは、MaxRequestsPerChildを置き換えるために使用されます。 この変更は、ディレクティブが実際に使用される目的をより適切に反映するために行われました。 値は実際には接続の数を制限するため、これはパラメーターのより適切な名前です。
  • MaxRequestWorkers :このディレクティブは、MaxClientsオプションを置き換えるために作成されました。 これは、非同期マルチプロセッシングモジュールでは、クライアントの数がワーカースレッドの数と同じであると想定してはならないためです。 これは、ディレクティブの影響を受けるこの構成の部分を正確に指定するのに役立ちます。

AllowOverrideの変更

ディレクトリ固有の構成ファイルがデフォルト設定を変更できるようにするために使用されるAllowOverrideディレクティブは、構成に影響を与える可能性のあるわずかな変更が加えられています。

デフォルトでは、この設定の値はNoneになりました。 これにより、デフォルトでよりロックダウンされた状態になり、サーバーをより簡単に保護できるようになります。 .htaccessファイルを読み取り、それを必要とするディレクトリで処理するように指定するのはまだ非常に簡単ですが、これを実現するには、グローバルで大規模なAllowOverride None宣言が少なくて済みます。

デフォルトでサーバーをロックダウンし、セキュリティをオーバーライドしてディレクトリベースの設定の特定のインスタンスを許可するという戦略は、ほとんどのユーザーがすでに行っていることです。 この変更は、ユーザーがこれらを手動で実装するのを忘れた場合に、ユーザーが簡単に攻撃を受けないようにするためにのみ役立ちます。

SendFileのデフォルトが変更されました

サーバー上のファイルを内容を読み取らずにクライアントに送信するために使用されるEnableSendfileディレクティブは、デフォルトでOffになりました。

これは、問題のシステムが操作を正しくサポートすることを保証するために使用されるセキュリティ対策です。 誤った実装は責任を負うか、操作が失敗する原因となる可能性があります。 これらは、オペレーティングシステム固有、特定のハードウェアに依存する場合、またはコンテンツへのアクセス方法(リモートファイルシステムなど)によって異なる場合があります。

このディレクティブをデフォルトで無効にすると、管理者はシステムの互換性を確認し、有効にする前に適切な機能を確認するためのテストを行うことができます。

実装の詳細

これらはApache2.4リリースに正確に固有のものではありませんが、ディストリビューションに同梱されているデフォルトの設定ファイルの一部は、移行が行われたときに変更されています。

この1つの例は、DebianおよびUbuntuリリースにあり、/etc/apache2/apache2.confにあるApache2.4のメイン構成ファイルは、追加ファイルのインクルードをわずかに異なる方法で処理するようになりました。

2.2では、これらのディストリビューションはconf.dおよびsites-enabledディレクトリ内のファイルを調達して、仮想ホストの仕様で最も一般的に使用される追加の構成ファイルを許可していました。 これらのディレクティブは次のようになりました。

Include conf.d/
Include sites-enabled/

ワイルドカードマッチングは、ディレクトリ全体を渡す代わりに、特定のファイルパターンを含めることができる新機能です。 これは、従来は上記のようなものでうまくいくことができましたが、以下を使用することでより柔軟性が得られることを意味します。

Include conf.d/*.conf
Include sites-enabled/*.conf

ただし、この新しい構文は、以前とまったく同じように機能することを期待している場合にも、いくつかの問題を引き起こす可能性があります。 Includeディレクティブをワイルドカードマッチングとともに使用すると、一致するファイルが見つからない場合は失敗し、エラーが発生します。

これを回避するために、IncludeOptionalという新しいディレクティブが作成されました。 これはまったく同じように機能しますが、ワイルドカードがどのファイルとも一致しない場合でも失敗することはありません。

これを利用するために、一部のディストリビューションには、次のような追加のディレクトリが含まれ始めています。

IncludeOptional conf-enabled/*.conf
IncludeOptional sites-enabled/*.conf

ご覧のとおり、ここに追加された追加の実装調整があります。sites-*およびmods-*をミラーリングするための個別のconf-enabledおよびconf-availableディレクトリの作成です。 ]ディレクトリ。 ただし、ここでの主なポイントは、特定のファイルパターンが指定されていることです。 この構成では、すべての有効な構成ファイルが.confで終わる必要があります。

通常、仮想ホストファイルをdefaultsite1.comのように呼び出す場合は、これに慣れるまでに時間がかかることがあります。 ただし、古いバージョン、テスト、READMEファイルなどの非構成ファイルをディレクトリに含めることができるため、これにより柔軟性が高まります。

これは、テストの場合、次のようなことを簡単に実行できることを意味します。

cd /etc/apache2/sites-enabled/
cp mainconfig.conf mainconfig.conf.bak
nano mainconfig.conf

a2dissiteおよびa2ensiteの操作を実行することもできますが、これは一部の人にとってはより自然な追加の方法です。 また、古い作業ファイルを有効なディレクトリに保持します。これは、正確にはセマンティックではありませんが、古いバージョンに戻す必要がある場合は、再実装するのが簡単な場合があります。

構成で気付く可能性のあるもう1つの変更は、一部のディレクティブが移動され、一部のデフォルトの仮想ホストディレクティブが変更されたことです。 以前はデフォルトの仮想ホストファイルにあったこれらの3つのブロックは、もう存在しません。

<Directory />
        Options FollowSymLinks
        AllowOverride None
</Directory>
<Directory /var/www/>
        Options Indexes FollowSymLinks MultiViews
        AllowOverride None
        Order allow,deny
        allow from all
</Directory>

ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
<Directory "/usr/lib/cgi-bin">
        AllowOverride None
        Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
        Order allow,deny
        Allow from all
</Directory>

上位2つのブロックは、任意の構成で設定する必要があるため、最近のバージョンのUbuntuではapache2.confファイル内に実装されるようになりました。 Requireディレクティブを使用するように更新されました。

<Directory />
    Options FollowSymLinks
    AllowOverride None
    Require all denied
</Directory>
<Directory /var/www/>
    Options Indexes FollowSymLinks
    AllowOverride None
    Require all granted
</Directory>

cig-binディレクトリ指定が仮想ホストファイルから削除され、conf-available/serve-cgi-bin.confファイルに実装されました。 これはよりモジュール化されたアプローチであり、仮想ホストファイルはのみの一意のディレクティブを担当します。 実際、すべてのコメントが削除された新しいデフォルトの仮想ホストは、単純に次のとおりです。

<VirtualHost *:80>
    ServerAdmin [email protected]
    DocumentRoot /var/www
    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

ご覧のとおり、これはサイト固有の構成ファイルを削減するのに非常に役立ちます。

結論

既存の構成を監査し、特定の手順を更新して新しいディレクティブとベストプラクティスを活用することにより、Apache2.4への移行はそれほど難しくありません。 機能的には、追加機能を備えた同じ機能を提供し、構文を理解しやすくする必要があります。

ジャスティン・エリングウッド