Apache Web サーバー強化およびセキュリティ ガイド

公開: 2015-02-14

Apache HTTP Server を保護および強化するための実用的なガイド。

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

デフォルト構成を使用すると、ハッカーがアプリケーションへの攻撃に備えるのに役立つ可能性のある多くの機密情報が提供されます。 Web アプリケーション攻撃の大部分は、XSS、情報漏えい、セッション管理、SQL インジェクション攻撃によるもので、脆弱なプログラミング コードと Web アプリケーション インフラストラクチャの無害化の失敗が原因です。

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

脆弱性レポート

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

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

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

観客

これは、ミドルウェア管理者、アプリケーション サポート、システム アナリスト、またはハードニングとセキュリティのガイドラインを学びたいと考えている人を対象としています。

Apache Web Server および UNIX コマンドに関する十分な知識が必須です。

ノート

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

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

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

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

デフォルトの構成では、以下に示すように、Apache のバージョンと OS の種類が公開されます。

Apache サーバー バナー

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

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

ServerTokensは、ヘッダーを実稼働のみ (つまり、Apache) に変更します。

以下に示すように、バージョンと OS の情報が表示されていません。

apache-server-banner-masked

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

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

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

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

では、http://localhost/test で Apache にアクセスしてみましょう。

apache-directory-listing

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

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

（また）

 <Directory /opt/apache/htdocs> Options None </Directory>
  • アパッチを再起動する

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

では、http://localhost/test で Apache にアクセスしてみましょう。

無効なディレクトリのリスト

ご覧のとおり、テスト フォルダーの一覧を表示する代わりに、禁止されたエラーが表示されます。

エタグ

リモートの攻撃者は、Etag ヘッダーを介して inode 番号、マルチパート MIME 境界、子プロセスなどの機密情報を取得できます。

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

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

非特権アカウントから Apache を実行する

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

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

  • apache という名前のユーザーとグループを作成します
# groupadd apache # useradd –G apache apache
  • Apache インストール ディレクトリの所有権を、新しく作成された非特権ユーザーに変更します。
 # chown –R apache:apache /opt/apache
  • $Web_Server/conf に移動します
  • vi を使用して httpd.conf を変更する
  • ユーザーとグループのディレクティブを検索し、非特権アカウント apache として変更します
User apache Group apache
  • httpd.conf を保存します
  • アパッチを再起動する

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

# ps –ef |grep http

root で 1 つのプロセスが実行されているはずです。 これは、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 を保存します
  • アパッチを再起動する

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>
  • アパッチを再起動する

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

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

これを有効にすると、クロス サイト トレース攻撃が可能になり、ハッカーに 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を再起動します

apache-x-frame-options

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

サーバー側インクルード

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

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

  • $Web_Server/conf ディレクトリに移動します
  • vi を使用して httpd.conf を開きます
  • ディレクトリを検索し、オプション ディレクティブにインクルードを追加します
<Directory /opt/apache/htdocs> Options –Indexes -Includes Order allow,denyAllow from all </Directory>
  • アパッチを再起動する

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

X-XSS 保護

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

  • $Web_Server/conf ディレクトリに移動します
  • vi を使用して httpd.conf を開き、次のヘッダー ディレクティブを追加します。
 Header set X-XSS-Protection "1; mode=block"
  • アパッチを再起動する

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

apache-xss

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

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

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

  • httpd.conf ファイルに mod_rewrite モジュールを必ずロードしてください
  • 次のように RewriteEngine ディレクティブを有効にし、Rewrite 条件を追加して HTTP 1.1 のみを許可します。
 RewriteEngine On RewriteCond %{THE_REQUEST} !HTTP/1.1$ RewriteRule .* - [F]

タイムアウト値の構成

デフォルトでは、Apache のタイムアウト値は 300 秒です。これは、Slow Loris 攻撃と 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 ビット キーを使用しています。

  • Outlook.com
  • Microsoft.com
  • ライブドットコム
  • スカイプ.com
  • Apple.com
  • Yahoo.com
  • Bing.com
  • Hotmail.com
  • Twitter.com

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

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

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

 SSLCertificateFile #Certificate signed by authority SSLCertificateChainFile #Certificate signer given by authority SSLCertificateKeyFile #Key file which you generated above
  • Apache ウェブサーバーを再起動し、https で URL にアクセスしてみます

SSL暗号

SSL Cipher は、インターネット上の 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 Security は、Apache で使用できるオープンソースの Web アプリケーション ファイアウォールです。

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

一般的な Web アプリケーションの保護を提供するために、コア ルールでは次の手法を使用します。

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

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

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 が表示されます。

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

構成

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

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

  • 次の行を追加して、Mod Security のモジュールを httpd.conf にロードし、構成ファイルを保存します。
 LoadModule unique_id_module modules/mod_unique_id.so LoadModule security2_module modules/mod_security2.so
  • Apache ウェブサーバーを再起動します

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

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

最新の Core Rule は、無料のリンクからダウンロードできます。 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 ウェブサーバーを再起動します

Apache で Mod Security が正常に構成されました!

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

入門

Mod Security のいくつかの重要な構成から始めて、Web アプリケーションを強化および保護します。

このセクションでは、/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、ユーザー トラッキング、セッション ハイジャックなどの保護が必要な場合は、オプションのルールの使用を検討してください。 ダウンロードした crs zip ファイルを OWASP ダウンロード ページから抽出すると、基本ルール、オプション ルール、実験ルールが得られます。

これらのルール構成ファイルは、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_attacks.conf:これは、OS コマンド インジェクション、リモート ファイル インクルージョンなどから保護するためのものです。
  • modsecurity_crs_41_sql_injection_attacks.conf:このルールは、SQL を保護し、ブラインド SQL 注入要求を行います。
  • modsecurity_crs_41_xss_attacks.conf:クロスサイト スクリプティング リクエストからの保護。
  • modsecurity_crs_42_tight_security.conf: ディレクトリ トラバーサルの検出と保護。
  • modsecurity_crs_45_trojans.conf:このルールは、一般的なファイル管理出力、HTTP バックドア ページのアップロード、既知の署名を検出します。
  • modsecurity_crs_47_common_exceptions.conf: これは、Apache 内部のダミー接続、SSL pinger などで遭遇する可能性のある一般的な誤検知を除去するための例外メカニズムとして使用されます。

ロギング

ロギングは、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 セキュリティのすべての利点を活用できません。

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

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

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

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

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

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

Core Rule をインストールし、Rule Engine を有効にしたので、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 ブロック リクエストに気付くでしょう。

サーバーバナーの変更

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

一歩先に進みましょう。サーバー名を好きなように維持するのはどうですか? 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 geekflare.com [/opt/apache/conf/crs] #

一般的な構成

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

リッスンの構成

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

一部のポート番号を使用してすべての IP でリッスンするように apache 構成を残すと、HTTP 要求を他の Web サーバーに転送する際に問題が発生する可能性があります。 これは、共有環境では非常に一般的です。

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

アクセス ロギング

Web サーバーでアクセス ログを適切に構成することが不可欠です。 ログに記録する重要なパラメータの一部は、リクエストの処理にかかった時間、SESSION ID です。

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

  • リクエストの処理にかかった時間とセッション ID をアクセス ログに記録するには
  • LogFormat ディレクティブの下の httpd.conf に %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

Info モジュール 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 管理コースを受講することをお勧めします。