WAFで攻撃に備える(。・д・)o┫゙;`;:゙;`;:


9回目の投稿となります。
NHN JAPANの遠藤と申します。

よろしくお願いいたします。

2018.9月のKUSANAGI バージョンアップにて、多数のセキュリティ対策用アプリケーションが簡単にインストールできるようになりました。

この事はプライムストラテジー穂苅様も記事として触れられているのですが、具体的にはこんなにあります・・・Σ(’ v ‘ノ)ノ

・WAF(ModSecurity、NAXSI)
・Vuls (脆弱性スキャン)
・Open Source Tripwire (IDS)
・Suricata (IDS IPS)

今回は一番上のWAFについて動作確認をしてみましたので、その事について少し書いてみます。
なお、ApacheとNginxで動作させるWAFが異なりますが、ここでは標準のNginx(NAXSI)をベースに説明します。

また、NAXSIを利用する上で良く使うnxapiやElasticSeaechについてはここでは触れないため、実運用される場合はドキュメントを参照ください。

WAFとは!って解説をすると上述の穂苅様の記事と被ってしまうので省略いたします(*ノノ)

 

1.KUSANAGIコマンドでWAFを有効にする

kusanagiコマンドにwaf の on/offが追加されました。

# kusanagi waf on で有効になります。
初めてonにした時は必要なパッケージのダウンロード等がありますので、少しだけ時間が掛かりました。

2.動作確認をする

KUSANAGIサイト上のマニュアルでは利用する上で次の説明が記載されていました。

NAXSIの設定をカスタマイズするには、下記ファイルを編集することできます。
/etc/nginx/naxsi.d/*/user.conf

有効にするため、 /etc/nginx/naxsi.d/common/default.conf の内容を /etc/nginx/conf.d/*****_http.conf の、location 内に include しました。

location / {
try_files $uri $uri/ /index.php?$args;

SecRulesEnabled;
error_log /home/kusanagi/****/log/nginx/naxsi.log;
DeniedUrl /waf.html;

CheckRule "$SQL >= 8" BLOCK;
CheckRule "$RFI >= 8" BLOCK;
CheckRule "$TRAVERSAL >= 4" BLOCK;
CheckRule "$EVADE >= 4" BLOCK;
CheckRule "$XSS >= 8" BLOCK;
}

errorログは後述しますが、naxsiの動作ログを記録するための記述、/waf.html はWAFが検知したら返すhtmlを指定したものでテスト用に作成したhtml、CheckRuleは閾値の設定です。
標準では /etc/nginx/naxsi.d/naxsi_core.rules.conf に基本的なルールセットが用意されています。
この状態で、# kusanagi nginx で設定を読み込ませ反映させました。

まずは、通常のURLでアクセスしてみます。

http://*****.com/ → 正常に表示しました。

次に不正なパラメータを装って、 http://*****.com/=22/**and//1=”q” でアクセスしてみると、用意したwaf.htmが表示されました。

Naxsiのブロックしたログはログレベルがerrorとしてログに記録されるのですが、KUSANAGIが標準で生成しているconfファイルではerrorログのログレベルはwarn以上を記録するとなっているため、
error_log /home/kusanagi/****/log/nginx/naxsi.log; のようにログレベルerror以上のログを記録する設定を加えました。ブロックしたことは次のようなログで確認できます。

2018/10/10 15:27:20 [error] 21113#0: *1106 NAXSI_FMT: ip=***.***.***.***&server=***.***.***.***&uri=/=22/**and/1="q"&learning=0&vers=0.56&total_processed=159&total_blocked=11&block=1&cscore0=$SQL&score0=16&cscore1=$XSS&score1=16&zone0=URL&id0=1001&var_name0=, client: ***.***.***.***, server: ***.***.***.***, request: "GET /=22/**and//1=%22q%22 HTTP/1.1", host: "***.***.***.***"

アクセスしたURLの一部であるuri=/=22/**and/1=”q” が、 id0=1001 のルールに沿ってブロックした記録となります。
id0=1001は /etc/nginx/naxsi.d/naxsi_core.rules.conf で確認するとダブルクオートに関連したルールということがわかりました。
MainRule “str:\”” “msg:double quote” “mz:BODY|URL|ARGS|$HEADERS_VAR:Cookie” “s:$SQL:8,$XSS:8” id:1001;

 

Naxsiは脆弱性のある良く知られた パターンの99% を含む単純なルールが用意されていてそのルールに基づき攻撃と判断していますが、上記遮断例のようなパラメーターも時には正当なクエリと成りえます。

そのため本来は冒頭に書いたnxapiを利用したり、 学習モードを有効にしてerrorログを確認しながらブラックリストやホワイトリストの成型をしてからの利用を想定しています。
学習モードは設定ファイル内にLearningMode; と記載すると学習モードで動作確認になります。
このモードはログレベルがdebugでの記録となりますのでログレベルの設定も忘れずにしましょう_〆(゚▽゚*)

また、KUSANAGIはWordPressで利用されている方が多いので補足すると、WordPress用のルール(主にホワイトリスト)も /etc/nginx/naxsi.d/wordpress/default.conf に用意されていますし、KUSNAGIはDrupalも簡単にプロビジョニングできますが、Drupalのルールセットは設定ルールが公開されています。


次回もKUSANAGI8.4以降に追加された機能の何れかを試してみようと思いますd(>_< )

 


Post Author: 遠藤博樹(NHN JAPAN株式会社)

遠藤博樹(NHN JAPAN株式会社)
前職ではまだヒットチャート上位ランクインがステータスとなる2000年代に某女性3人組バンドのマネージャーを務めていてましたが、解散をきっかけに退社し、2008年にNHNテコラス(旧社名ライブドア)に入社。 2018.4月には親会社となるNHN JAPANに転籍をしていますが、一貫してホスティングサービスのサポートスタッフ・企画運営としてお客様対応を行っています。ここでは主にKUSANAGI搭載ホスティングサービスを提供している中で、お客様からいただきましたお問い合わせをヒントに技術的な内容を書いていければと考えております。