目次
概要
Kusanagiではバージョン8.4.0からIDS/IPS/WAF機能が入っているそうなので使ってみることにしました。
注意事項
注意事項があります。
- WAFに関してはKUSANAGI 8.4.0へのアップデート以降でプロビジョニングしたプロファイルが対象です
- やる場合は念のためバックアップを取っておこう
- WAFの動作により一部機能が使えなくなる可能性があります
そもそもWAFとは
そもそものはなし、WAFとは何ぞやと言う話から。
WAFとはWeb Application Firewallの略で「ワフ」と読みます。
特徴
特徴としては、Webアプリケーションレベルでのセキュリティを行い、サーバーやデータベースの前に配置され不正な通信や攻撃を防ぐ役割をしています。
設置するタイプにも種類があり「クラウド型・アプライアンス型・ホスト型」の3種類に分かれています。
今回はホスト型に該当しますかね。
仕組み
不正な通信を検知する方法としてタイプ(第1~3世代)がいくつかあります。
正直そこまで詳しくないのでざっくりと…
第1世代:ブラックリスト型・ホワイトリスト型
従来のファイアーウォールと同じ考えであらかじめウェブサーバとブラウザがやりとりを行うデータの中に、リストに記載されている「禁則文字列」が存在するかしないかで検知を行う方法です。危険なものだけがリストアップされたものをブラックリスト型、安全なものだけがリストアップされたものをホワイトリスト型に分かれます。
欠点として、リストは管理者自身が作成するのでその手間(というか専門知識)が求められます。
第2世代:シグネチャ型
シグネチャと呼ばれる定義ファイルに基づいて動作します。
ウィルス対策ソフトのパターンファイル見たなものですかね。
通信が始まるとこのシグネチャと見比べて問題があると判断した場合は通信を遮断したりします。
ベンダー任せ?にすることにより管理者の手間を大幅に省くことが出来ます。
欠点として、シグネチャを作成するベンダーが攻撃を受けてからでないと対応することが出来ないのと更新が進むたびにリストが肥大する欠点があります。
第3世代:ルール型
第1世代と似たような感じであらかじめ定義されたルールに従い通信の検査を行います。
「禁則文字列が含まれるかどうか?」「文字列がどのように並んでいるか?」といった動作方法は変わりありませんが、検査方法を「ルールベース」にすることにより検知のための定期的なアップデートを省き、今までなかったような攻撃が来た場合でも適切に対処することができるという特徴を持っています。
また、ルール化することによりリストの肥大化も防いでいます。
欠点としては、過剰検知してしまう点があります。
Kusanagiでは
KusanagiのWAFの機能についてはApacheの場合はModSecurity、nginxの場合はNAXSIを利用しています。
いずれも第3世代のルール型のWAFとなります。
NAXSIの設定をカスタマイズするには、下記ファイルを編集することできます。
1 |
# /etc/nginx/naxsi.d/*/user.conf |
ModSecurity(Apache)の設定をカスタマイズするには、下記ファイルを編集することできます。
1 |
# /etc/httpd/modsecurity.d/kusanagi_activated_rules/*/user.conf |
他のセキュリティとの違い
簡単な絵にするとこんな感じ。まじ最終防御。
上記の絵の通り、各種得意分野が違うためWAFだけ入れてれば安心というわけではないのですね。
では実際に設定してみよう
前置きが長くなりましたが、実際に設定していきます。
やり方は非常に簡単です。
WAF
1 2 3 4 |
# kusanagi target [profile name] # kusanagi status # kusanagi waf on # kusanagi status |
- プロファイルが複数ある場合はどのプロファイルに適用するか設定をします。
1つしかない場合は省いてもOK。複数ある場合は上にあるものが有効になっています。 - 状態を確認します。下のほうにWAF項目があるので状態が「off」になっていることを確認します。
- WAFをONにします。初回の場合は必要なパッケージをダウンロードしているため若干時間が掛かりますのでドキドキしながら待ちましょう。
数分で終わるはずです。 - 最後にWAFの状態を確認しておきましょう。「on」になっているはずです。
以上です。簡単でしょ?
というより、WAFの場合はここからが本番なのかもしれません。
一通りWordpressのほうがうまく機能しているかテストをしてみてください。
万が一動作しないものがあれば下記コマンドにてWAFをOFFにするかルールをカスタマイズする必要があります。
1 |
# kusanagi waf off |
なので、本来であれば構築の段階で公開する前に一通りテストするのが正しいやり方なんでしょうね。
WAFのログ
ちなみに、KusanagiでWAFを動作させるとデフォルトで下記に出力されるようです。(SSL化している場合。していない場合はただのerror.logになると思う)
1 |
# /home/kusanagi/[プロファイル名]/log/nginx/ssl_error.log |
また、ダメな場合下記のような出力がされます。
YYYY/MM/DD HH:MM:SS [error] 123456#0: *159 NAXSI_FMT: ~エラー内容長々~
正規のアクセスにもかかわらずNG判定を食らう場合はホワイトリストにでも入れてあげるのがいいのかと思いますが、Kusanagiの場合どうやって入れてあげたらいいものかちょっとわからないので放置気味…
今のところ影響を受けていると確認できたのがアクセス状況を気軽にチラ見できる「Slimstat Analytics」がだめでした。
IDS/IPS
使えるアドオンにはいくつか種類がありますが、今回はSuricataを使ってみます。
こちらも使い方は簡単。
1 |
# kusanagi addon install suricata |
これでとりあえず、導入はできます。
実際のところ、ルール系は下記に入っているようです。
1 |
# /etc/suricata/rules |
検知ログ系については下記になります。
1 |
# /var/log/suricata/fast.log |
ポートスキャンを試しにかけてみれば検知する…はず。
日々くだらないことを追い求め、黒歴史をまとめておくための自由なブログ。
あんまり役立つことは書きませんが主に日記・ゲームや買ったものについての記事を気まぐれで好き勝手書いています。