Apache Web サーバーの強化とセキュリティ ガイド

Apache HTTP サーバーを保護し、強化するための実践的なガイド。

Web サーバーは、Web ベースのアプリケーションの重要な部分です。 Apache Web サーバーはネットワークのエッジに配置されることが多いため、攻撃に対して最も脆弱なサービスの 1 つになります。

デフォルト設定を使用すると、ハッカーがアプリケーションへの攻撃に備えるのに役立つ可能性のある多くの機密情報が提供されます。 Web アプリケーション攻撃の大部分は、XSS、情報漏洩、セッション管理、および SQL インジェクション攻撃を介して行われます。これらの攻撃は、脆弱なプログラミング コードと Web アプリケーション インフラストラクチャのサニタイズ失敗が原因です。

Positive Technologiesによる興味深い調査では、スキャンされたアプリケーションの 52% に高い脆弱性があったことが明らかになりました。

この記事では、Linux プラットフォームで Apache HTTP サーバーを保護するためのベスト プラクティスについて説明します。

以下は Apache 2.4.x バージョンでテストされています。

• これは、UNIX プラットフォームに Apache がインストールされていることを前提としています。そうでない場合は、インストール ガイドを参照してください。
• このガイドでは、Apache インストール ディレクトリ /opt/apache を $Web_Server と呼びます。
• 変更を行う前に、既存の構成ファイルのバックアップを作成することをお勧めします。

観客

これは、ミドルウェア管理者、アプリケーション サポート、システム アナリスト、または強化とセキュリティのガイドラインに従事している人、または学習に熱心なすべての人を対象に設計されています。

Apache Web サーバーと UNIX コマンドに関する適切な知識が必須です。

ノート

一部の実装検証では、HTTP ヘッダーを検査するためのツールが必要です。これを行うには 2 つの方法があります。

1. ブラウザーに組み込まれた開発者ツールを使用して、HTTP ヘッダーを検査します。通常、これは「ネットワーク」タブの下にあります
2. オンラインのHTTP応答ヘッダーチェッカーツールを使用する

サーバーバージョンバナーを削除

使用している Web サーバーのバージョンを公開したくないので、これは最初に考慮すべきことの 1 つだと思います。バージョンを公開するということは、ハッカーによる偵察プロセスの迅速化を支援することを意味します。

デフォルト設定では、以下に示すように Apache バージョンと OS タイプが公開されます。

• $Web_Server/conf フォルダーに移動します
• vi エディターを使用して httpd.conf を変更する
• 次のディレクティブを追加し、httpd.conf を保存します。

 ServerTokens Prod
ServerSignature Off

• Apacheを再起動する

ServerSignature Apache によって生成されたページからバージョン情報を削除します。

ServerTokensヘッダーを本番環境のみ、つまり Apache に変更します。

以下のように、バージョンとOSの情報が消えています。

ディレクトリブラウザのリストを無効にする

ブラウザでのディレクトリの一覧表示を無効にすると、ルートまたはサブディレクトリの下にあるすべてのファイルとフォルダーが訪問者に表示されなくなります。

デフォルト設定でどのように見えるかをテストしてみましょう。

• $Web_Server/htdocs ディレクトリに移動します
• フォルダーとその中にいくつかのファイルを作成します

# mkdir test
# touch hi
# touch hello

それでは、 http://localhost/testで Apache にアクセスしてみます。

ご覧のとおり、それはあなたが持っているすべてのファイル/フォルダーを明らかにします、そして私はそれを公開したくないと確信しています。

• $Web_Server/conf ディレクトリに移動します
• vi を使用してhttpd.confを開きます
• Directory を検索し、Options ディレクティブを None または –Indexes に変更します。

 <Directory /opt/apache/htdocs>
Options -Indexes
</Directory>

（または）

 <Directory /opt/apache/htdocs>
Options None
</Directory>

• Apacheを再起動する

注: 環境内に複数の Directory ディレクティブがある場合は、すべてに対して同じことを行うことを検討する必要があります。

それでは、 http://localhost/testで Apache にアクセスしてみます。

ご覧のとおり、テスト フォルダーの一覧が表示されるのではなく、禁止されたエラーが表示されます。

Eタグ

これにより、リモートの攻撃者が Etag ヘッダーを通じて i ノード番号、マルチパート MIME 境界、子プロセスなどの機密情報を取得できるようになります。

この脆弱性を回避するには以下のように実装しましょう。これは、PCI 準拠のために修正する必要があります。

• $Web_Server/conf ディレクトリに移動します
• 次のディレクティブを追加し、httpd.conf を保存します。

 FileETag None

• Apacheを再起動する

特権のないアカウントから Apache を実行する

デフォルトのインストールは、誰もまたはデーモンとして実行されます。 Apache には別の非特権ユーザーを使用することをお勧めします。

ここでの考え方は、セキュリティ ホールが発生した場合に実行中の他のサービスを保護することです。

• apacheという名前のユーザーとグループを作成します

# groupadd apache
# useradd –G apache apache

• Apache インストール ディレクトリの所有権を、新しく作成した非特権ユーザーに変更します

# chown –R apache:apache /opt/apache

• $Web_Server/conf に移動します
• vi を使用して httpd.conf を変更する
• User & Group Directive を検索し、非特権アカウントとして変更します Apache

 User apache 
Group apache

• httpd.confを保存します
• Apacheを再起動する

http プロセスを実行するために grep を実行し、それが Apache ユーザーで実行されていることを確認します

# ps –ef |grep http

1 つのプロセスが root で実行されていることがわかります。これは、Apache がポート 80 でリッスンしており、root で起動する必要があるためです。

バイナリおよび構成ディレクトリのアクセス許可を保護する

デフォルトでは、バイナリと構成の権限は 755 で、サーバー上のすべてのユーザーが構成を表示できることを意味します。別のユーザーが conf および bin フォルダーにアクセスすることを禁止できます。

• $Web_Server ディレクトリに移動します
• binとconfフォルダのパーミッションを変更する

# chmod –R 750 bin conf

システム設定の保護

デフォルトのインストールでは、ユーザーは .htaccess を使用して Apache 構成をオーバーライドできます。ユーザーが Apache サーバー設定を変更できないようにしたい場合は、以下に示すように、 AllowOverrideをNoneに追加します。

これはルートレベルで実行する必要があります。

• $Web_Server/conf ディレクトリに移動します
• vi を使用して httpd.conf を開きます
• ルートレベルでディレクトリを検索する

<Directory /> 
Options -Indexes 
AllowOverride None
</Directory>

• httpd.confを保存します
• Apacheを再起動する

HTTPリクエストメソッド

HTTP 1.1 プロトコルは、必須ではない可能性のある多くのリクエスト メソッドをサポートしており、その一部には潜在的なリスクがあります。

通常、Web アプリケーションでは GET、HEAD、POST リクエスト メソッドが必要になる場合があります。これらは、それぞれの Directory ディレクティブで構成できます。

デフォルト構成は、HTTP 1.1 プロトコルの OPTIONS、GET、HEAD、POST、PUT、DELETE、TRACE、CONNECT メソッドをサポートします。

• $Web_Server/conf ディレクトリに移動します
• vi を使用して httpd.conf を開きます
• ディレクトリを検索し、以下を追加します

<LimitExcept GET POST HEAD>
deny from all
</LimitExcept>

• Apacheを再起動する

トレースHTTPリクエストを無効にする

デフォルトでは、Apache Web サーバーで Trace メソッドが有効になっています。

これを有効にすると、クロスサイト トレース攻撃が許可され、ハッカーに Cookie 情報を盗むオプションが与えられる可能性があります。デフォルト設定でどのように見えるかを見てみましょう。

• リスニングポートを使用して Telnet Web サーバー IP を実行します
• 以下に示すように TRACE リクエストを実行します

#telnet localhost 80 
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
TRACE / HTTP/1.1 Host: test
HTTP/1.1 200 OK
Date: Sat, 31 Aug 2013 02:13:24 GMT
Server: Apache
Transfer-Encoding: chunked
Content-Type: message/http 20
TRACE / HTTP/1.1
Host: test 
0
Connection closed by foreign host.
#

上記の TRACE リクエストでわかるように、私のクエリに応答しました。無効にしてテストしてみましょう。

• $Web_Server/conf ディレクトリに移動します
• 次のディレクティブを追加し、httpd.conf を保存します。

 TraceEnable off

• Apacheを再起動する

以下に示すように、リッスン ポートを使用して Telnet Web サーバー IP を実行し、 TRACEリクエストを作成します。

 #telnet localhost 80
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
TRACE / HTTP/1.1 Host: test
HTTP/1.1 405 Method Not Allowed
Date: Sat, 31 Aug 2013 02:18:27 GMT
Server: Apache Allow:Content-Length: 223Content-Type: text/html; charset=iso-8859-1 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> 
<title>405 Method Not Allowed</title> </head><body> 
<h1>Method Not Allowed</h1>
<p>The requested method TRACE is not allowed for the URL /.</p> </body></html>
Connection closed by foreign host.
#

上記の TRACE リクエストでわかるように、HTTP 405 Method Not allowed でリクエストがブロックされました。

現在、この Web サーバーは TRACE リクエストを許可しておらず、クロスサイト トレース攻撃のブロックに役立ちます。

HttpOnly および Secure フラグを使用して Cookie を設定する

Cookie 内の HttpOnly および Secure フラグを使用すると、一般的なクロスサイト スクリプティング攻撃のほとんどを軽減できます。 HttpOnly と Secure を持たないと、Web アプリケーションのセッションや Cookie を盗んだり操作したりすることが可能であり、危険です。

• httpd.conf で mod_headers.so が有効になっていることを確認してください
• $Web_Server/conf ディレクトリに移動します
• 次のディレクティブを追加し、httpd.conf を保存します。

 Header edit Set-Cookie ^(.*)$ $1;HttpOnly;Secure

• Apacheを再起動する

クリックジャッキング攻撃

クリックジャッキングは、Web アプリケーションのよく知られた脆弱性です。

• httpd.conf で mod_headers.so が有効になっていることを確認してください
• $Web_Server/conf ディレクトリに移動します
• 次のディレクティブを追加し、httpd.conf を保存します。

 Header always append X-Frame-Options SAMEORIGIN

• Apacheを再起動する

X-Frame-Options は、ここで説明したさらに 2 つのオプションもサポートしています。

サーバー側インクルード

サーバーサイドインクルード (SSI) には、サーバーの負荷が増加するリスクがあります。環境とトラフィックの多い Web アプリケーションを共有している場合は、オプション ディレクティブに include を追加して SSI を無効にすることを検討する必要があります。

SSI 攻撃では、HTML ページにスクリプトを挿入したり、コードをリモートで実行したりすることで、Web アプリケーションの悪用が可能になります。

• $Web_Server/conf ディレクトリに移動します
• vi を使用して httpd.conf を開きます
• ディレクトリを検索し、オプション ディレクティブにインクルードを追加します

<Directory /opt/apache/htdocs>
Options –Indexes -Includes
Order allow,denyAllow from all
</Directory>

• Apacheを再起動する

注: 環境内に複数の Directory ディレクティブがある場合は、すべてに対して同じことを行うことを検討する必要があります。

X-XSS 保護

クロスサイト スクリプティング (XSS) 保護は、多くのブラウザーでバイパスされる可能性があります。ユーザーが Web アプリケーションを無効にしている場合は、この保護を Web アプリケーションに適用できます。これは、Facebook、Twitter、Google などの巨大 Web 企業の大多数で使用されています。

• $Web_Server/conf ディレクトリに移動します
• vi を使用して httpd.conf を開き、次のヘッダー ディレクティブを追加します。

 Header set X-XSS-Protection "1; mode=block"

• Apacheを再起動する

ご覧のとおり、XSS-Protection は応答ヘッダーに挿入されます。

HTTP 1.0プロトコルを無効にする

セキュリティについて話すときは、できる限り保護する必要があります。では、なぜ古い HTTP バージョンのプロトコルを使用するのでしょうか?それらも無効にしましょう。

HTTP 1.0 には、セッション ハイジャックに関するセキュリティ上の弱点があります。 mod_rewrite モジュールを使用してこれを無効にできます。

• httpd.conf ファイルに mod_rewrite モジュールを必ずロードしてください
• 次のように RewriteEngine ディレクティブを有効にし、HTTP 1.1 のみを許可する Rewrite 条件を追加します。

 RewriteEngine On
RewriteCond %{THE_REQUEST} !HTTP/1.1$
RewriteRule .* - [F]

タイムアウト値の設定

デフォルトでは、Apache のタイムアウト値は 300 秒ですが、これはスローロリス攻撃や DoS の被害を受ける可能性があります。これを軽減するには、タイムアウト値を 60 秒に下げることができます。

• $Web_Server/conf ディレクトリに移動します
• vi を使用して httpd.conf を開きます
• httpd.confに以下を追加

Timeout 60

SSL

SSL の使用は、Web アプリケーションに追加する追加のセキュリティ層です。ただし、デフォルトの SSL 構成では特定の脆弱性が発生するため、それらの構成を調整することを検討する必要があります。

SSLキー

SSL キーの侵害は困難ですが、不可能ではありません。それは単に計算能力と時間の問題です。

ご存知かもしれませんが、2009 年製の PC を約 73 日間使用すると、512 ビット キーをリバース エンジニアリングできます。

したがって、キーの長さが長くなるほど、SSL キーの解読はより複雑になります。巨大な Web 企業の大部分は、以下に示すように 2048 ビット キーを使用しています。なぜ私たちは 2048 ビット キーを使用しないのでしょうか?

• Outlook.com
• Microsoft.com
• Live.com
• スカイプ.com
• Apple.com
• Yahoo.com
• Bing.com
• Hotmail.com
• ツイッター.com

以下のように OpenSSL を使用して 2048 ビットの CSR を生成できます。

 openssl req -out .csr -newkey rsa:2048 -nodes -keyout .key

CSR が生成されます。CSR に署名するには、 認証局に送信する必要があります。署名付き証明書ファイルを受け取ったら、httpd-ssl.conf ファイルに追加できます。

 SSLCertificateFile #Certificate signed by authority
SSLCertificateChainFile #Certificate signer given by authority
SSLCertificateKeyFile #Key file which you generated above

• Apache Webサーバーを再起動し、httpsでURLにアクセスしてみます。

SSL暗号

SSL 暗号は、インターネット上の 2 台のコンピュータ間のキーとして使用される暗号化アルゴリズムです。データの暗号化は、プレーン テキストを秘密の暗号化コードに変換するプロセスです。

データの暗号化は、Web サーバーの SSL 暗号設定に基づいて行われます。したがって、より強力で脆弱性のない SSL 暗号を構成することが重要です。

• $Web_Server/conf/extra フォルダーに移動します
• httpd-ssl.conf の SSLCipherSuite ディレクティブを次のように変更して、より高度な暗号化アルゴリズムのみを受け入れるようにします。

 SSLCipherSuite HIGH:!MEDIUM:!aNULL:!MD5:!RC4

• 設定ファイルを保存し、Apacheサーバーを再起動します。

注: SSL 監査レポートに弱い暗号が多数ある場合は、「!」を追加してすぐに拒否できます。初めに。

SSL v2 および v3 を無効にする

SSL v2 および v3 には多くのセキュリティ上の欠陥があるため、ペネトレーション テストまたは PCI 準拠に取り組んでいる場合は、セキュリティの調査結果を閉じて SSL v2/v3 を無効にすることが期待されます。

SSL v2/v3 通信は、データの改ざんや漏洩を可能にする中間者攻撃に対して脆弱になる可能性があります。

最新の TLS のみを受け入れ、SSL v2/v3 接続リクエストを拒否するように Apache Web サーバーを実装しましょう。

• $Web_Server/conf/extra フォルダーに移動します
• httpd-ssl.conf の SSLProtocol ディレクティブを次のように変更して、TLS 1.2+ のみを受け入れるようにします。

 SSLProtocol –ALL +TLSv1.2

SSL 構成が完了したら、オンライン SSL/TLS 証明書ツールを使用して Web アプリケーションをテストし、構成エラーを見つけることをお勧めします。

MODのセキュリティ

Mod Security は、Apache で使用できるオープンソースの Web アプリケーション ファイアウォールです。

これはモジュールとして提供されており、コンパイルしてインストールする必要があります。商用 Web アプリケーション ファイアウォールを購入する余裕がない場合は、これを選択するのが最適です。

汎用 Web アプリケーション保護を提供するために、コア ルールでは次の手法が使用されます。

• HTTP 保護 – HTTP プロトコルおよびローカルに定義された使用ポリシーの違反を検出します。
• リアルタイムのブラックリスト検索 – サードパーティの IP レピュテーションを利用
• Web ベースのマルウェア検出 – Google セーフ ブラウジング API と照合して、悪意のある Web コンテンツを識別します。
• HTTP サービス拒否保護 – HTTP フラッディングおよび低速 HTTP DoS 攻撃に対する防御。
• 一般的な Web 攻撃の保護 – 一般的な Web アプリケーションのセキュリティ攻撃を検出します
• 自動検出 – ボット、クローラー、スキャナー、およびその他の悪意のある表面アクティビティを検出します。
• ファイル アップロードのための AV スキャンとの統合 – Web アプリケーションを通じてアップロードされた悪意のあるファイルを識別します。
• 機密データの追跡 – クレジット カードの使用状況を追跡し、漏洩をブロックします。
• トロイの木馬からの保護 – トロイの木馬へのアクセスを検出します。
• アプリケーションの欠陥の特定 – アプリケーションの構成ミスに関するアラート。
• エラーの検出と非表示 – サーバーから送信されたエラー メッセージを偽装します。

ダウンロードとインストール

Apache で Mod Security を使用するサーバーには、次の前提条件がインストールされている必要があります。これらのいずれかが存在しない場合、Mod Security のコンパイルは失敗します。これらのパッケージをインストールするには、Linux または Centos で yum install を使用できます。

• apache 2.x以降
• libpcreパッケージ
• libxml2 パッケージ
• libluaパッケージ
• libcurlパッケージ
• libapr および libapr-util パッケージ
• Apache Webサーバーにバンドルされているmod_unique_idモジュール

それでは、 ここから Mod Security 2.7.5 の最新の安定バージョンをダウンロードしましょう

• ダウンロードしたファイルを/opt/apacheに転送します
• modsecurity-apache_2.7.5.tar.gzを抽出します。

 # gunzip –c modsecurity-apache_2.7.5.tar.gz | tar xvf –

• 抽出したフォルダー modsecurity-apache_2.7.5 に移動します。

 # cd modsecurity-apache_2.7.5

• 既存の Apache への apxs パスを含む構成スクリプトを実行します。

 # ./configure –with-apxs=/opt/apache/bin/apxs

• makeスクリプトでコンパイル＆インストール

# make
# make install

• インストールが完了すると、/opt/apache の modules フォルダーに mod_security2.so が表示されます。

これで、既存の Apache Web サーバーに Mod Security モジュールがインストールされました。

構成

Apache で Mod セキュリティ機能を使用するには、httpd.conf で Mod セキュリティ モジュールをロードする必要があります。 mod_unique_id モジュールは Mod Security の前提条件です。

このモジュールは、リクエストごとに一意の識別子を持つ環境変数を提供します。これは、Mod Security によって追跡および使用されます。

• httpd.conf に Mod Security のロードモジュールに次の行を追加し、設定ファイルを保存します

LoadModule unique_id_module modules/mod_unique_id.so
LoadModule security2_module modules/mod_security2.so

• Apache Webサーバーを再起動します

Modセキュリティがインストールされました！

次に行う必要があるのは、Mod Security コア ルールをインストールして、その機能を最大限に活用することです。

最新のコア ルールは、次のリンクから無料でダウンロードできます。 https://github.com/SpiderLabs/owasp-modsecurity-crs/zipball/master

• ダウンロードしたコア ルールの zip を /opt/apache/conf フォルダーにコピーします
• コアルールファイルを解凍します
• フォルダーの名前を短くて覚えやすい名前に変更するとよいでしょう。この例では、名前を crs に変更します。
• crs フォルダーに移動し、modsecurity_crs10_setup.conf.example の名前を modsecurity_crs10_setup.conf に変更します。

次に、これらのルールを有効にして、Apache Web サーバーで動作できるようにしましょう。

• httpd.confに以下を追加

<IfModule security2_module>
Include conf/crs/modsecurity_crs_10_setup.confInclude conf/crs/base_rules/*.conf
</IfModule>

上記の設定では、Mod Security のメイン設定ファイル modsecurity_crs_10_setup.conf と、Web アプリケーションを保護するために Mod Security Core Rules によって提供されるベース ルールbase_rules/*.conf をロードしています。

• Apache Webサーバーを再起動します

Apache を使用した Mod Security の設定が正常に完了しました。

よくやった。現在、Apache Web サーバーは Mod Security Web アプリケーション ファイアウォールによって保護されています。

はじめる

Web アプリケーションを強化してセキュリティを確保するための、Mod Security の重要な構成のいくつかから始めましょう。

このセクションでは、/opt/apache/conf/crs/modsecurity_crs_10_setup.conf ですべての設定変更を行います。

このセクションでは、例として /opt/apache/conf/crs/modsecurity_crs_10_setup.conf を setup.conf と呼びます。

無料で提供される OWASP ルールとは何かを理解することが重要です。 OWASP が提供するルールには 2 種類があります。

基本ルール– これらのルールは厳しくテストされており、おそらく誤報率は低くなります。

実験的なルール– これらのルールは実験的な目的のためのものであり、誤警報が発生する可能性があります。これらを運用環境で使用する前に、UAT で構成、テスト、実装することが重要です。

オプションのルール– これらのオプションのルールは環境全体には適していない可能性があります。要件に応じて使用できます。

CSRF、ユーザー追跡、セッションハイジャックなどの保護を求めている場合は、オプションのルールの使用を検討できます。 OWASP ダウンロード ページからダウンロードした crs zip ファイルを抽出すると、基本ルール、オプション ルール、および実験ルールが得られます。

これらのルール設定ファイルは crs/base_rules、crs/optional_rules、および crs/experimental_rules フォルダーで入手できます。基本的なルールのいくつかを理解しましょう。

• modsecurity_crs_20_protocol_violations.conf: このルールは、許可されていないプロトコル (HTTP 1.0) の使用による、応答の分割、リクエストの密輸などのプロトコルの脆弱性から保護します。
• modsecurity_crs_21_protocol_anomalies.conf: これは、ヘッダーに Host、Accept、User-Agent が欠落しているリクエストから保護するためのものです。
• modsecurity_crs_23_request_limits.conf:このルールには、リクエスト サイズ、アップロード サイズ、パラメータの長さなどのアプリケーション固有の依存関係があります。
• modsecurity_crs_30_http_policy.conf:これは、CONNECT、TRACE、PUT、DELETE などの許可または禁止されたメソッドを構成および保護するためのものです。
• modsecurity_crs_35_bad_robots.conf:悪意のあるロボットの検出
• modsecurity_crs_40_generic_attachs.conf:これは、OS コマンド インジェクション、リモート ファイルの組み込みなどから保護するためのものです。
• modsecurity_crs_41_sql_injection_attachs.conf:SQL およびブラインド SQL インジェクション要求を保護するためのこのルール。
• modsecurity_crs_41_xss_attachs.conf:クロスサイト スクリプティング リクエストからの保護。
• modsecurity_crs_42_tight_security.conf:ディレクトリトラバーサルの検出と保護。
• modsecurity_crs_45_trojans.conf: このルールは、一般的なファイル管理出力、HTTP バックドア ページのアップロード、既知の署名を検出します。
• modsecurity_crs_47_common_Exceptions.conf:これは、Apache の内部ダミー接続、SSL ping などで発生する可能性のある一般的な誤検知を削除するための例外メカニズムとして使用されます。

ロギング

ログ記録は、Mod Security の動作に関するログを作成できるように最初に設定することの 1 つです。利用可能なロギングには 2 つのタイプがあります。デバッグおよび監査ログ。

デバッグ ログ: これは、エラー ログから Apache のエラー、警告、および通知メッセージを複製します。

監査ログ: これは、Mod Security ルールによってマークされたトランザクション ログを書き込みます。Mod Security を使用すると、監査、デバッグ、またはその両方のログを柔軟に構成できます。

デフォルト設定では両方のログが書き込まれます。ただし、要件に応じて変更できます。ログはSecDefaultActionディレクティブで制御されます。 setup.conf のデフォルトのログ設定を見てみましょう。

 SecDefaultAction “phase:1,deny,log”

デバッグ、監査ログを記録するには – 「log」を使用します。 監査ログのみを記録するには – 「nolog,auditlog」を使用します。 デバッグ ログのみを記録するには – 「log,noauditlog」を使用します。 SecAuditLog によって制御される監査ログの保存場所を指定できます。指令。

/opt/apache/logs/modsec_audit.log に以下のように追加して監査ログを書き込みましょう。

• setup.conf に SecAuditLog ディレクティブを追加し、Apache Web サーバーを再起動します

SecAuditLog /opt/apache/logs/modsec_audit.log

• 再起動後、modsec_audit.log が生成されるのが確認できるはずです。

ルールエンジンを有効にする

デフォルトでは、エンジン ルールはオフになっています。つまり、ルール エンジンを有効にしないと、Mod Security の利点をすべて活用できないことになります。

ルール エンジンの有効化または無効化は、 SecRuleEngineディレクティブによって制御されます。

• setup.conf に SecRuleEngine ディレクティブを追加し、Apache Web サーバーを再起動します

SecRuleEngine On

SecRuleEngine には 3 つの値があります。

• オン – ルール エンジンを有効にします
• オフ – ルール エンジンを無効にします。
• DetectionOnly – ルール エンジンを有効にしますが、ブロック、拒否、ドロップ、許可、プロキシ、リダイレクトなどのアクションは実行しません。

ルール エンジンがオンになると、Mod Security はいくつかの一般的な攻撃タイプから保護できるようになります。

一般的な攻撃タイプの保護

これで、コア ルールをインストールし、ルール エンジンを有効にしたため、XSS、SQL インジェクション、プロトコル違反などの一般的な攻撃タイプで Web サーバーを保護する準備が整いました。いくつかテストしてみましょう。

XSS攻撃

• Firefox を開いてアプリケーションにアクセスし、URL の最後に <script> タグを追加します。
• apache/logs フォルダー内の modsec_audit.log を監視します。

XSS 攻撃のルートである <script> タグが含まれているため、Mod Security がリクエストをブロックしていることがわかります。

ディレクトリ トラバーサル攻撃:- ディレクトリ トラバーサル攻撃は、この脆弱性を利用してシステム関連ファイルにアクセスし、多大な損害を引き起こす可能性があります。例 – /etc/passwd、.htaccess など

• Firefox を開き、ディレクトリ トラバーサルでアプリケーションにアクセスします。
• apache/logs フォルダー内の modsec_audit.log を監視します。

 http://localhost/?../.../boot

• リクエストにはディレクトリ トラバーサルが含まれているため、Mod Security がリクエストをブロックしていることがわかります。

サーバーバナーの変更

このガイドの前半で、Apache と OS の種類、ServerTokens ディレクティブのバージョン ヘルプを削除する方法を学びました。

一歩進んで、サーバー名を任意の名前のままにしてみてはいかがでしょうか。 Mod Security のSecServerSignatureディレクティブを使用すると可能です。面白いですね。

注: Mod Security を使用してヘッダーからサーバー バナーを操作するには、Apache Web サーバーの httpd.conf で ServerTokesn を Full に設定する必要があります。

• setup.conf に目的のサーバー名を含む SecServerSignature ディレクティブを追加し、Apache Web サーバーを再起動します。

 SecServerSignature YourServerName

元：

 [/opt/apache/conf/crs] #grep SecServer modsecurity_crs_10_setup.conf
SecServerSignature .com
[/opt/apache/conf/crs] #

一般的な構成

ベスト プラクティスとして、一般的な構成をいくつか確認してみましょう。

リッスンの設定

単一サーバー上に複数のインターフェイスと IP がある場合は、絶対 IP とポート番号を使用して Listen ディレクティブを構成することをお勧めします。

Apache の設定を、あるポート番号を持つすべての IP でリッスンするようにしておくと、HTTP リクエストを他の Web サーバーに転送する際に問題が発生する可能性があります。これは共有環境では非常に一般的です。

• 以下に示す例のように、絶対 IP とポートを使用して httpd.conf の Listen ディレクティブを構成します。

 Listen 10.10.10.1:80

アクセスログ

Web サーバーでアクセス ログを適切に設定することが重要です。ログに記録する重要なパラメータには、リクエストの処理にかかった時間、セッション ID などがあります。

デフォルトでは、Apache はこれらのデータをキャプチャするように構成されていません。次のように手動で設定する必要があります。

• リクエストの処理にかかった時間とセッション ID をアクセス ログに記録するには
• httpd.conf の LogFormat ディレクティブの下に %T と %sessionID を追加します

LogFormat "%h %l %u %t "%{sessionID}C" "%r" %>s %b %T" common

Apache Web サーバーの LogFormat ディレクティブでサポートされているパラメータの完全なリストについては、 http://httpd.apache.org/docs/2.2/mod/mod_log_config.htmlを参照してください。

不要なモジュールのロードを無効にする

すべてのモジュールをコンパイルしてインストールした場合は、必要ではない多くのモジュールが Apache にロードされる可能性が高くなります。

ベスト プラクティスは、Web アプリケーションで必要なモジュールを使用して Apache を構成することです。以下のモジュールにはセキュリティ上の懸念があるため、Apache Web サーバーの httpd.conf で無効にすることをお勧めします。

WebDAV (Web ベースの分散オーサリングおよびバージョニング) このモジュールを使用すると、リモート クライアントがサーバー上のファイルを操作し、さまざまなサービス拒否攻撃を受けることができます。 httpd.conf でのコメントのフォローを無効にするには

#LoadModule dav_module modules/mod_dav.so
#LoadModule dav_fs_module modules/mod_dav_fs.so
#Include conf/extra/httpd-dav.conf

情報モジュール mod_info モジュールは、このモジュールがロードされると、.htaccess を使用して機密情報を漏洩する可能性があります。 httpd.conf でのコメントのフォローを無効にするには

#LoadModule info_module modules/mod_info.so

参考: これは、次のリンクからのガイダンスがなければ不可能です。

• http://httpd.apache.org/docs/2.4/
• http://www.modsecurity.org/documentation/
• https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project

以上が、Apache Web サーバーを保護するために使用できるベスト プラクティスの一部でした。

Apache でカスタム エラー ページを実装する場合は、このリンクを確認してください。

Apache HTTP を初めて使用する場合は、 Apache HTTP 管理コースを受講することをお勧めします。