1 WAFを安全に導⼊するために 取り組んだこと

2 2 ⾃⼰紹介 ● 名前: ⾼橋雄紀 ● Twitter: @takapi86 ● 所属: GMOペパボ EC事業部 カラーミーショップグループ サービス基盤チーム ● 業務でやっていること ○ レガシー環境の改善 ○ セキュリティ対応

3 3 ⾃⼰紹介 その他、最近の活動 ● カラーミーショップの開発環境をすべてDockerに移⾏しました ○ https://tech.pepabo.com/2019/12/10/upgrade-colorme-dev/ ● GMOインターネットグループ全体の新⼈研修でセキュアコーディング について講義した際に⼯夫・実践したこと ○ https://tech.pepabo.com/2020/06/18/gtb-2020-security/ こちらのテックブログの⽅もご覧いただけると嬉しいです

4 4 カラーミーショップのセキュリティの取り組み ペパボでは全社サービスのセキュリティ強化を着実に実施して いくため、年度ごとにセキュリティ対策に関する計画を⾏い、 その計画に従って対応を⾏なっています。

5 5 カラーミーショップのセキュリティの取り組み カラーミーショップでは、昨年度、以下の取り組みを⾏ってきました。 ※ セキュリティ対策の⼀例です。下記以外にもセキュリティに関する取り組みを⾏なって います ● ショップ管理者ページの2要素認証の導⼊ ● ウィルススキャンソフト、クエリログ収集、ファイル整合性監視の導⼊ ● PHPのバージョンアップ ● 外部脆弱性診断 ● WAFの導⼊（本⽇お話する内容）

6 6 そもそもWAFとは？

7 7 そもそもWAFとは？ ● Web Application Firewall の略 ● Webサーバの前段やモジュールとして設置 ● リクエストの内容を解析し、不正なリクエストを防ぐ役割を持つ WAF name=鈴⽊ name=”>alert( ...

8 8 そもそもWAFとは？ WAFのタイプ ● クラウド型（Saas） ● アプライアンス型（専⽤機器） ● ソフトウェア型（Webサーバにインストール等） カラーミーショップでは、ペパボの他のサービスで導⼊・運⽤している事例 があることから SiteGuard Server Edition というソフトウェア型のWAFを導 ⼊しています。※ 以降はSiteGuardと呼んでいきます

9 9 シグネチャ型のWAFの仕組み ● SiteGuardはシグネチャ型というWAFに分類されます ● シグネチャ型WAF・・・ シグネチャ（検出パターン）に基づいて、 HTTPリクエストに含まれるリクエストライン、リクエストヘッダ、リ クエストボディを検査して攻撃を検出します ● 検出した攻撃はブロック・通知することが可能 WAF name=”>alert( ... シグネチャXSS001のパターンや！ ブロックしとこ！ エラー画⾯

10 10 シグネチャ型のWAFの仕組み シグネチャは2パターン ● トラステッド・シグネチャ ○ あらかじめチューニングされた状態で標準搭載されている ● カスタム・シグネチャ ○ 独⾃の検出ルールを追加することができる ○ トラステッド・シグネチャを除外するといったことも設定できる

11 11 WAF導⼊時のリスク 本来正常なリクエストが不正ものと誤検知されることによって、リクエスト が遮断され、機能が正常に動かなくなってしまうリスクがあります。 ● 攻撃の意思のない⼀般ユーザの⼊⼒した内容がブロックされてしまう ○ 問い合わせの原因に ● 処理として必要な内容がブロックされてしまう ○ 障害の原因に WAF なんでー！？ /etc/XXXはディレクト リトラバーサルっぽい ので、ダメです。 リンク追加しよ！ url=https:// example.com/etc/ hoge.jpg

12 12 誤検知なく、安全にWAF導⼊するためにはどうすれば良いか ● Webアプリケーションの特性に合わせシグネチャの調整が必要 ● 適切に調整を実施することが、WAF導⼊のカギとなる 今回はカラーミーショップで、この調整作業をどうやって進め、導⼊を⾏っ たか、直近の事例をご紹介していきたいと思います。

13 13 カラーミーショップで実施したWAF導⼊作業の流れ

14 14 カラーミーショップで実施したWAF導⼊作業の流れ ● 1. 監視運⽤設定で導⼊する ● 2. ログを収集・確認する ● 3. 誤検知と判断したリクエストを除外する ● 4. 2,3を繰り返し、誤検知を取り除いていく ● 5. WAFを監視設定から遮断設定に切り替えて完了 +α ⼯夫したポイント3点

15 15 1.監視運⽤設定で導⼊する WAFを初めて環境に導⼊する際は、監視運⽤設定にしておきます。 ● あらかじめ監視運⽤設定にしておくことで、リクエストを遮断すること なくWAFを導⼊することができます。 ● WAFで検知した内容は、ログに記録することができます。 WAF name=鈴⽊ name=”>alert( ... 検知ログ に記録

16 16 2.検知ログを収集・確認する 誤検知がないか検知ログを⾒て確認します 例: 攻撃のケース XXXXXXXXXX 1 XXX.XXX.XXX.XXX TCP_MISS/000 463 POST https://example.com/?mode=cart_inn - DIRECT/10.200.0.88 application/x-www-form-urlencoded DETECT-STAT:WAF:RULE_SIG/ PART_PARAM_VALUE|PART_REQBODY/product_text%5b1%5d/OFFICIAL/00102001/xss-tag- 1::%3cscript%3e:%22%3e%3cscript%3ealert(1);%3c/script%3e: ACTION:BLOCK: JUDGE:BLOCK:0: SEARCH-KEY:XXXXXXXXXX: URLデコードすると ">alert(1); => 攻撃と判断

17 17 2.ログを収集・確認する 例: 誤検知のケース XXXXXXXX.XXXXXXXX 1 XXX.XXX.XXX.XXX TCP_MISS/000 432 POST https:// example.com/?mode=cart_inn - DIRECT/XXX.XXX.XXX.XXX application/x-www-form-urlencoded DETECT- STAT:WAF:RULE_SIG/PART_PARAM_VALUE|PART_REQBODY/product_text%5b1%5d/OFFICIAL/ 00302002/oscmd-try-2::Cat+F:Cat+Dog%26Cat+Fox: ACTION:BLOCK: JUDGE:BLOCK:0: SEARCH- KEY:XXXXXXXX.XXXXXXXX.XXXXXXXX: 「Cat Dog&Cat Fox」という⽂字列がOSコマンドインジェクションとして検知 （catコマンドとして検知） => OSコマンドインジェクションの脆弱性がないか確認した上で、シグネチャ oscmd-try-2 を除外

18 18 3.誤検知と判断したリクエストを除外する 検知ログで、除外すべきと判断したものを除外していきます。 ちなみに、カラーミーショップでは、設定が複雑にならないよう ● トラステッド・シグネチャ（デフォルト）の設定は変更しない ● カスタム・シグネチャで、↑の除外設定のみを⾏う 参考: カスタム・シグネチャの設定ファイル ON NONE exclude-hoge URL PCRE_CASELESS / \?mode=hoge hogeは誤検知されやすいので除外 ON NONE exclude-hoge PARAM_NAME PCRE_CASELESS,AND,EXCLUDE_OFFICIAL(^(sqlinj-(123|456)|oscmd-999)$) ^hoge$ hogeは誤検知されやすいので除外

19 19 4, 2,3を繰り返し、誤検知を取り除いていく 誤検知が⾒つからなくなるまで、検知ログの確認と誤検知の対応を繰り返し ⾏なっていきます。 ログの収集 誤検知の除外設定 ログの確認

20 20 5. 誤検知がなくなったら遮断するように切り替える 誤検知がなくなったら、監視運⽤から攻撃を遮断する運⽤に切り替えます。 カラーミーショップでは、 ● ⼩規模なロールの場合、3〜4⽇くらい ○ 会員登録・ログインページ、メルマガページなど ● ⼤規模なロールの場合、1〜3週間くらい ○ ショップ管理者ページ、APIなど 誤検知がないことができた後、切り替えを⾏いました。

21 21 5. 誤検知がなくなったら遮断するように切り替える 誤検知がなくなったら、監視運⽤から攻撃を遮断する運⽤に切り替えます。 カラーミーショップでは、 ● ⼩規模なロールの場合、3〜4⽇くらい ○ 会員登録・ログインページ、メルマガページなど ● ⼤規模なロールの場合、1〜3週間くらい ○ ショップ管理者ページ、APIなど 誤検知がないことができた後、切り替えを⾏いました。 これでWAFの導⼊は完了！

22 22 ⼯夫したポイント3点

23 23 ⼯夫したポイント その1 検知ログを⼀括で検索できるようにした！ これまで抱えていた問題： 1つのロールに対し、サーバが複数が並列でが動 いる。サーバごと検知ログが置かれているため、1台1台検知ログを拾って いかなければなりませんでした => Redashというダッシュボードツールを使って、まとめて検索できるよう にしました！

24 24 ⼯夫したポイント その1 吸い上げ 保管 検索 構成 検知ログ

25 25 ⼯夫したポイント その2 カスタム・シグネチャの設定（除外設定）を楽にした！ これまで、カスタム・シグネチャの更新作業は以下のどちらかで⾏う必要がありま した ● SiteGuardの管理画⾯（ブラウザ）から更新を⾏う ○ 設定したいシグネチャをサーバ台数分、1台1台画⾯をクリックして設定してい かなければならないので、作業が煩雑 ● カスタム・シグネチャの設定ファイルを直接更新する ○ 設定ファイルが⼈間には理解しにくい構成になっているため、直接編集が困難 => どちらの⽅法をとっても⼤変な作業

26 26 ⼯夫したポイント その2 カスタム・シグネチャの設定をYAMLで記述できるようにした！ 可読性が向上し、直接ファイルを編集することが苦ではなくなった サーバに適⽤する際は、YAMLファイルから元の形式に変換して適⽤ YAMLファイル Convert！ カスタム・シグネチャの設定ファ イル（TSV形式） ON NONE exclude- hoge URL PCRE_CASELESS / \?mode=hoge hogeは誤 検知されやすいので除外 ON NONE exclude- hoge PARAM_NAME PCRE_CASELESS,AND,EXCLUDE_OFFICIAL( ^(sqlinj-(123|456)|oscmd-999)$) ^hoge$ hogeは誤 検知されやすいので除外 - name: exclude-hoge comment: 誤検知されやすいので除外 conditions: - key: URL value: "/\\?mode=hoge" comparison_methods: - PCRE_CASELESS - key: PARAM_NAME value: "hoge" comparison_methods: - PCRE_CASELESS - AND

27 27 ⼯夫したポイント その2 カスタム・シグネチャの設定をYAMLで記述できるようにした！ 可読性が向上し、直接ファイルを編集することが苦ではなくなった サーバに適⽤する際は、YAMLファイルから元の形式に変換して適⽤ YAMLファイル Convert！ カスタム・シグネチャの設定ファ イル（TSV形式） ON NONE exclude- hoge URL PCRE_CASELESS / \?mode=hoge hogeは誤 検知されやすいので除外 ON NONE exclude- hoge PARAM_NAME PCRE_CASELESS,AND,EXCLUDE_OFFICIAL( ^(sqlinj-(123|456)|oscmd-999)$) ^hoge$ hogeは誤 検知されやすいので除外 - name: exclude-hoge comment: 誤検知されやすいので除外 conditions: - key: URL value: "/\\?mode=hoge" comparison_methods: - PCRE_CASELESS - key: PARAM_NAME value: "hoge" comparison_methods: - PCRE_CASELESS - AND GitHubでツールを公開しています！ https://github.com/pepabo/siteguard_lite-custom_signature

28 28 ⼯夫したポイント その2 その他、改善点 ● GitHubのリポジトリで管理するようにした ○ 変更管理やレビューが⾏いやすくなった ● Capistranoでデプロイできるようにした ○ 設定ファイルをCapistranoでデプロイするだけで、サーバ全台同時 に設定を反映することができるようになった

29 29 ⼯夫したポイント その3 検知ログの確認を効率化した これまで、誤検知を⾒つけるために、毎⽇⼤量のログから誤検知がないかを チェックしていかなければならなかった ● ⼀般的にWebサービスは常に何かしらの攻撃を受けている ● その分、⼤量の検知ログが出るので、⼀通り⽬を通していくのが⼤変 具体的には、なにが⼤変なのか ● 確認済みのパターンであっても何度も⽬を通す必要がある ● 定期的にRedashを⾒に⾏かなければならない

30 30 ⼯夫したポイント その3 新たに検出されたパターンのみ確認できるようチェックシートを作った 新たに検出されたパターンが⾃動的にシートに追記され ていく（重複なし） 確認が終わったら チェックをつける

31 31 ⼯夫したポイント その3 1.検知ログを Redashで抽出 2.検知ログをGASでフィルター （チェック済みのものは追加 しない） 3.新たなパターンが検出されたら スプレットシートに追記 4. 定期的にSlackへ通知

32 32 ⼯夫したポイント その3 1.検知ログを Redashで収集 2.検知ログをGASでフィルター （チェック済みのものは追加 しない） 3.新たなパターンが検出されたら スプレットシートに追記 4. 定期的にSlackへ通知 ときには半⽇掛かってしまうような、検知ログの確認作業を 半分以下の時間で対応できるようになった！

33 33 このような取り組みの結果 このような取り組みを⾏うことで、直近で導⼊した次の4ロールについて は、全部で1か⽉・障害、お問い合わせなく安全にWAFを導⼊することがで きました ● ショップページ ● メルマガ ● 会員新規登録・ログイン ● ランディングページ

34 34 まとめ ⼀般的に導⼊コストが⾼いと⾔われているWAF ですが、様々な⼯夫をしていくことで、早く安 全に導⼊することができるようになりました。 => WAFの運⽤ついてのお話は、また別の機会 に