TOC

Ubuntu 14.04でNaxsiをインストールおよび構成する方法

前書き

Naxsiは、Webアプリケーションのファイアウォール機能を提供するサードパーティのNginxモジュールです。 Webサーバーに追加のセキュリティをもたらし、XSSやSQLインジェクションなどのさまざまなWeb攻撃からユーザーを保護します。

Naxsiは柔軟で強力です。 WordPressなどの一般的なWebアプリケーションですぐに使用できるルールを使用できます。 同時に、Naxsiの学習モードを使用して独自のルールを作成し、微調整することもできます。

Naxsiはhttps://www.digitalocean.com/community/tutorials/how-to-set-up-modsecurity-with-apache-on-ubuntu-14-04-and-debian-8[ModSecurity for Apache]に似ています。 したがって、すでにModSecurityに精通している場合や、Nginxで同様の機能を探している場合は、Naxsiがきっとあなたの興味を引くでしょう。 ただし、NaxsiにはModSecurityのすべての機能が含まれていない場合があります。

このチュートリアルでは、Naxsiをインストールする方法、ルールを理解する方法、ホワイトリストを作成する方法、および一般的に使用されるWebアプリケーション用にすでに記述されているルールの場所を示します。

前提条件

このチュートリアルを実行する前に、次の前提条件を満たしていることを確認してください。

  • Ubuntu 14.04ドロップレット

  • 非ルートsudoユーザー。 詳細については、https：//www.digitalocean.com/community/tutorials/initial-server-setup-with-ubuntu-14-04 [Ubuntu 14.04での初期サーバー設定]をご覧ください。

特に断りのない限り、このチュートリアルでルート権限を必要とするすべてのコマンドは、sudo権限を持つ非ルートユーザーとして実行する必要があります。

ステップ1-Naxsiのインストール

Naxsiをインストールするには、それとともにコンパイルされたNginxサーバーをインストールする必要があります。 この目的のために、パッケージ `+ nginx-naxsi `が必要です。 ` apt-get +`コマンドを使用して、通常のUbuntuの方法でインストールできます。

sudo apt-get update
sudo apt-get install nginx-naxsi

これにより、Nginxとそのすべての依存関係とともにNaxsiがインストールされます。 また、サービスがDropletで自動的に開始および停止することを確認します。

Nginxのデフォルトのインストールでは、基本的な動作するNginx環境が提供されます。これは、Naxsiに慣れるのに十分です。 Nginxのカスタマイズに時間を費やすことはありませんが、代わりにNaxsiの構成に直接進みます。 ただし、Nginxの経験がない場合は、https：//www.digitalocean.com/community/tutorials/how-to-install-nginx-on-ubuntu-14-04-lts [How To]を確認することをお勧めしますUbuntu 14.04 LTSにNginxをインストールする]およびその関連記事、特にhttps://www.digitalocean.com/community/tutorials/how-to-set-up-nginx-server-blocks-virtual-hosts-on-ubuntu-14 -04-lts [Ubuntu 14.04 LTSでNginxサーバーブロック（仮想ホスト）をセットアップする方法]。

ステップ2-Naxsiを有効にする

まず、Naxsiを有効にするには、ファイル「+ / etc / nginx / naxsi_core.rules 」にあるコアルールをロードする必要があります。 このファイルには、悪意のある攻撃を検出するための一般的な署名が含まれています。 これらのルールについては、後で詳しく説明します。 今のところ、HTTPリスナー部分のNginxのメイン設定ファイル「 / etc / nginx / nginx.conf +」にルールを含めるだけです。 したがって、nanoで編集するために後者のファイルを開きます。

sudo nano /etc/nginx/nginx.conf

次に、「+ http 」セクションを見つけ、行の先頭にある「＃+」文字を削除して、Naxsiのルールのインクルード部分のコメントを外します。 次のようになります。

/etc/nginx/nginx.conf

http {
...
       # nginx-naxsi config
       ##
       # Uncomment it if you installed nginx-naxsi
       ##


...

ファイルを保存し、エディターを終了します。

第二に、以前のルールを有効にし、Naxsiの基本的なオプションを設定する必要があります。 デフォルトでは、基本的なNaxsi設定はファイル `+ / etc / nginx / naxsi.rules +`にあります。 このファイルを開きます：

sudo nano /etc/nginx/naxsi.rules

`+ DeniedUrl +`の値のみを、デフォルトですでに存在するエラーファイルに変更し、残りは変更しないままにします。

/etc/nginx/naxsi.rules

# Sample rules file for default vhost.
LearningMode;
SecRulesEnabled;
#SecRulesDisabled;


## check rules
CheckRule "$SQL >= 8" BLOCK;
CheckRule "$RFI >= 8" BLOCK;
CheckRule "$TRAVERSAL >= 4" BLOCK;
CheckRule "$EVADE >= 4" BLOCK;
CheckRule "$XSS >= 8" BLOCK;

ファイルを保存して終了します。

次に、上記の構成ディレクティブとその意味を示します。

  • + LearningMode +-Naxsiを学習モードで起動します。 これは、リクエストが実際にブロックされないことを意味します。 Nginxエラーログでは、セキュリティ例外のみが発生します。 デフォルトのルールはかなり積極的であるため、このような非ブロッキングの初期動作は重要です。 後で、これらの例外に基づいて、正当なトラフィックのホワイトリストを作成します。

  • + SecRulesEnabled +-サーバーブロック/場所のNaxsiを有効にします。 同様に、 `+ SecRulesDisabled +`のコメントを外すことで、サイトまたはサイトの一部のNaxsiを無効にできます。

  • + DeniedUrl +-拒否されたリクエストが内部的に送信されるURL。 これは、変更する必要がある唯一の設定です。 デフォルトのドキュメントルート（ + / usr / share / nginx / html / 50x.html +）内にある、すぐに利用可能な `+ 50x.html +`エラーページを使用するか、独自のカスタムエラーページを作成できます。

  • + CheckRule +-さまざまなカウンターのしきい値を設定します。 このしきい値を超えると（例： SQLカウンターの場合は8ポイント）要求はブロックされます。 これらのルールをよりアグレッシブにするには、値を減らし、その逆も同様です。

ファイル + naxsi.rules +`は、サーバーブロックのロケーションごとにロードする必要があります。 デフォルトのサーバーブロックのルートの場所（ `+ / +）にロードしましょう。 まず、サーバーブロックの構成ファイル「+ / etc / nginx / sites-enabled / default +」を開きます。

sudo nano /etc/nginx/sites-enabled/default

次に、ルートの場所「+ / +」を見つけて、次のようになっていることを確認します。

   location / {
           # First attempt to serve request as file, then
           # as directory, then fall back to displaying a 404.
           try_files $uri $uri/ =404;
           # Uncomment to enable naxsi on this location

   }

上記の変更を行ったら、変更を有効にするためにNginxをリロードできます。

sudo service nginx reload

次のステップでは、変更が成功したかどうかを確認する方法と、ログを読み取る方法について説明します。

ステップ3-ログの確認

Naxsiが機能することを確認するには、まだ学習モードであっても、例外をスローするURLにアクセスして、例外のエラーログを監視します。

このルールが正確にどのように機能するかについては、後で説明します。 今のところ、例外を見つけるためにNginxのエラーログを追跡します（ `+ -f +`オプションは出力を開いたままにし、新しいコンテンツを追加します：

sudo tail -f /var/log/nginx/error.log

URL `+ http：///index.html？asd = ---- +`でドロップレットにアクセスしてみてください。 これにより、ダッシュがSQLのコメントに使用され、SQLインジェクションの一部と見なされるため、Naxsiセキュリティ例外がトリガーされます。

`+ sudo tail -f / var / log / nginx / error.log +`の出力に、次の新しいコンテンツが表示されます。

Output of nginx's error log2015/11/14 03:58:35 [error] 4088#0: *1 NAXSI_FMT: ip=X.X.X.X&server=Y.Y.Y.Y&uri=/index.html&learning=1&total_processed=24&total_blocked=1&, client: X.X.X.X, server: localhost, request: "GET /index.html?asd=---- HTTP/1.1", host: "Y.Y.Y.Y"

上記の行の最も重要な部分が強調表示されます： + zone0 = ARGS＆id0 = 1007＆var_name0 = asd +。 ゾーン（リクエストの一部）、トリガーされたルールのID、および疑わしいリクエストの変数名を提供します。

さらに、「+ X.X.X.X 」はローカルコンピューターのIPであり、「 Y.Y.Y.Y 」はドロップレットのIPです。 URIには、リクエストのファイル名（ ` index.htm `）、Naxsiがまだ学習モードで動作しているという事実（ ` learning = 1 `）、および処理されたすべてのリクエストの総数（ ` total_processed = 24 + `）。

また、上記の行の直後に、 `+ DeniedUrl +`へのリダイレクトに関するメッセージが続きます。

Output of nginx's error log2015/11/14 03:58:35 [error] 4088#0: *1 rewrite or internal redirection cycle while internally redirecting to "/50x.html" while sending response to client, client: X.X.X.X, server: localhost, request: "GET /favicon.ico HTTP/1.1", host: "Y.Y.Y.Y", referrer: "http://Y.Y.Y.Y/index.html?asd=----"

Naxsiが学習モードの場合、このリダイレクトはログにのみ表示されますが、実際には発生しません。

`+ CTRL + C `を押して ` tail +`を終了し、エラーログファイルの出力を停止します。

後ほど、Naxsiのルールについて詳しく学習します。そして、ログの基本を理解することが重要になります。

ステップ4-Naxsiルールの構成

Naxsiの設定の最も重要な部分はルールです。 ルールには、メインルールと基本ルールの2種類があります。 メインルール（「+ MainRule 」で識別）はサーバーにグローバルに適用されるため、メインNginxの設定の「 http +」ブロックの一部です。 悪意のあるアクティビティを検出するための一般的な署名が含まれています。

基本的なルール（ `+ BasicRule +`で識別）は、主に偽陽性の署名とルールをホワイトリストに登録するために使用されます。 これらは場所ごとに適用されるため、サーバーブロック（vhost）構成の一部である必要があります。

メインのルールから始めて、ファイル「+ / etc / nginx / naxsi_core.rules 」の「 nginx-naxsi +」パッケージで提供されるデフォルトのルールを見てみましょう。 サンプル行は次のとおりです。

/etc/nginx/naxsi_core.rules

...
MainRule "str:--" "msg:mysql comment (--)" "mz:BODY|URL|ARGS|$HEADERS_VAR:Cookie" "s:$SQL:4" id:1007;
...

上記の規則から、次の部分の概要を説明できます。これらは普遍的であり、すべての規則に含まれています。

  • `+ MainRule +`は、すべてのルールを開始するディレクティブです。 同様に、すべてのルールはルールのID番号で終わります。

  • `+ str：`はルールの2番目の部分にあります。 ` str：`の場合、上記の例のように、署名がプレーンな文字列であることを意味します。 正規表現は、ディレクティブ「 rx：+」と一致させることもできます。

  • `+ msg：+`は、ルールに関する明確化を提供します。

  • `+ mz：+`はマッチゾーン、またはリクエストのどの部分を検査するかを表します。 これは、本文、URL、引数などです。

  • `+ s：`は、署名が見つかったときに割り当てられるスコアを決定します。 スコアは、「 SQL 」（SQL攻撃）、「 RFI +」（リモートファイルインクルージョン攻撃）などのさまざまなカウンターに追加されます。

基本的に、コメント + mysql comments +`を使用した上記のルール（ `+ id 1007 +）は、文字列 `-`がリクエスト（ボディ、引数など）のいずれかの部分で見つかった場合、4ポイントSQLカウンターに追加されます。

ログのSQL例外をトリガーしたURIの例（ + http：///index.html？asd = ---- +）に戻ると、ルール1007をトリガーするには2ダッシュのペア（ -）。 これは、ペアごとに4ポイントを取得し、SQLチェーンはリクエストをブロックするために8ポイントを必要とするためです。 したがって、1組のダッシュのみが問題ではなく、ほとんどの場合、正当なトラフィックは影響を受けません。

特別なルールディレクティブの1つは、「+ negative +」です。 署名が一致しない場合、つまりスコアが適用されます。 要求内の何かが欠落している場合、悪意のあるアクティビティが疑われます。

たとえば、同じファイル「+ / etc / nginx / naxsi_core.rules 」の「 id 1402+」のルールを見てみましょう。

/etc/nginx/naxsi_core.rules

...
MainRule negative "rx:multipart/form-data|application/x-www-form-urlencoded" "msg:Content is neither mulipart/x-www-form.." "mz:$HEADERS_VAR:Content-type" "s:$EVADE:4" id:1402;
...

上記のルールは、「+ Content-type 」リクエストヘッダーに「 multipart / form-data 」も「 application / x-www-form-urlencoded 」も含まれていない場合、EVADEカウンターに4ポイントが追加されることを意味します。 このルールは、署名の説明に正規表現（ ` rx：+`）を使用する方法の例でもあります。

ステップ5-ホワイトリスト登録ルール

デフォルトのNaxsiルールは、サイトの正当なトラフィックをほぼ確実にブロックします。特に、さまざまなユーザーインタラクションをサポートする複雑なWebアプリケーションがある場合はそうです。 そのため、このような問題を解決するホワイトリストがあります。

ホワイトリストは、2番目のタイプのルールであるNaxsiの基本ルールで作成されます。 基本ルールを使用すると、ルール全体またはその一部をホワイトリストに登録できます。

基本的なルールがどのように機能するかを示すために、SQLコメントルール（id 1007）に戻りましょう。 ファイル名に2つのダッシュがあるファイルがあるとします。 あなたのサイトの + some—​file.html +。 ルール1007が設定されていると、このファイルはSQLカウンターを4ポイント増やします。 このファイル名と結果のスコアだけではリクエストをブロックするのに十分ではありませんが、問題を引き起こす可能性のある誤検知のままです。 たとえば、2つのダッシュを含む引数もある場合、要求はルール1007をトリガーします。

それをテストするには、以前のようにエラーログを追跡します。

sudo tail -f /var/log/nginx/error.log

`+ http：///some—​file.html？asd =-+`にアクセスしてみてください。 テストのためにこのファイルをウェブサイトに置く必要はありません。

エラーログの出力には、次のようなよく知られた例外が表示されるはずです。

Output of nginx's error log2015/11/14 14:43:36 [error] 5182#0: *10 NAXSI_FMT: ip=X.X.X.X&server=Y.Y.Y.Y&uri=/some--file.html&learning=1&total_processed=10&total_blocked=6&zone0=URL&id0=1007&var_name0=&zone1=ARGS&id1=1007&var_name1=asd, client: X.X.X.X, server: localhost, request: "GET /some--file.html?asd=-- HTTP/1.1", host: "Y.Y.Y.Y"

エラーログ出力の表示を停止するには、「+ CTRL-C +」を押します。

この誤検知のトリガーに対処するには、次のようなホワイトリストが必要です。

BasicRule :1007 "mz:URL";

重要なキーワードは、ホワイトリストの `+ wl +`で、その後にルールIDが続きます。 ホワイトリストに登録する内容をより正確にするために、一致ゾーン（URL）も指定しました。

このホワイトリストを適用するには、まずホワイトリスト用の新しいファイルを作成します。

sudo nano /etc/nginx/naxsi_whitelist.rules

次に、ルールをファイルに貼り付けます。

/etc/nginx/naxsi_whitelist.rules

BasicRule wl:1007 "mz:URL";

他のホワイトリストがある場合は、このファイルにも追加できます。各ホワイトリストは新しい行にあります。

ホワイトリストを含むファイルは、サーバーブロックに含める必要があります。 デフォルトのサーバーブロックに含めるには、再度nanoを使用します。

sudo nano /etc/nginx/sites-enabled/default

次に、次のように、新しいインクルードをNaxsiの前のインクルードの直後に追加します。

/ etc / nginx / sites-enabled / default

       location / {
               # First attempt to serve request as file, then
               # as directory, then fall back to displaying a 404.
               try_files $uri $uri/ =404;
               # Uncomment to enable naxsi on this location
               include /etc/nginx/naxsi.rules;

       }

この変更を有効にするには、Nginxをリロードします。

sudo service nginx reload

ブラウザで同じリクエストを `+ / some—​file.html？asd =-`に再試行すると、2つのダッシュに等しい ` asd +`パラメータのみがSQLカウンターに対して4ポイントをトリガーしますが、ファイル名はしません。 したがって、この要求は例外としてエラーログに表示されません。

必要なホワイトリストをすべて作成するのは、単調で退屈な作業であり、独自の科学でもあります。 そのため、最初はすぐに利用できるhttps://github.com/nbs-system/naxsi-rules[Naxsiホワイトリスト]を使用できます。 ほとんどの一般的なWebアプリケーションにはこのようなものがあります。 ちょうど私達がしたようにそれらをダウンロードし、サーバーブロックに含めるだけです。

エラーログに正当なリクエストの例外が表示されないことを確認したら、Naxsiの学習モードを無効にできます。 このために、nanoでファイル「+ / etc / nginx / naxsi.rules +」を開きます。

sudo nano /etc/nginx/naxsi.rules

次のように、その前に「＃」文字を追加して、「+ LearningMode +」ディレクティブをコメントアウトします。

/etc/nginx/naxsi.rules

...
LearningMode;
SecRulesEnabled;
#SecRulesDisabled;
...

最後に、変更を有効にするためにNginxをリロードします。

sudo service nginx reload

これで、Naxsiが疑わしい要求をブロックし、サイトのセキュリティが強化されます。

結論

NginxとNaxsiでWebアプリケーションファイアウォールを設定するのは簡単です。 最初はこれで十分であり、強力なNaxsiモジュールが提供するものの詳細を知りたいと思います。 これで、Nginxサーバーを高速にするだけでなく、安全にすることもできます。

Related