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とは！って解説をすると上述の穂苅様の記事と被ってしまうので省略いたします（*ノノ）
１．KUSANAGIコマンドでWAFを有効にする
kusanagiコマンドにwaf の on/offが追加されました。
# kusanagi waf on で有効になります。
初めてonにした時は必要なパッケージのダウンロード等がありますので、少しだけ時間が掛かりました。
２．動作確認をする
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で利用されている方が多いので補足すると、WorｄPress用のルール（主にホワイトリスト）も /etc/nginx/naxsi.d/wordpress/default.conf に用意されていますし、KUSNAGIはDrupalも簡単にプロビジョニングできますが、Drupalのルールセットは設定ルールが公開されています。
次回もKUSANAGI8.4以降に追加された機能の何れかを試してみようと思いますd(>_< )
