pepabo-ec-tech-conference-web-application-firewall

GMO Developers Night #10 ペパボ EC テックカンファレンス 2020.06.24
https://pepabo.connpass.com/event/179445/

Transcript

1. 1 WAFを安全に導⼊するために 取り組んだこと
2. 2 2 ⾃⼰紹介 • 名前: ⾼橋雄紀 • Twitter: @takapi86 • 所属: GMOペパボ EC事業部 カラーミーショップグループ サービス基盤チーム • 業務でやっていること ◦ レガシー環境の改善 ◦ セキュリティ対応
3. 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 4 カラーミーショップのセキュリティの取り組み ペパボでは全社サービスのセキュリティ強化を着実に実施して いくため、年度ごとにセキュリティ対策に関する計画を⾏い、 その計画に従って対応を⾏なっています。
5. 5 5 カラーミーショップのセキュリティの取り組み カラーミーショップでは、昨年度、以下の取り組みを⾏ってきました。 ※ セキュリティ対策の⼀例です。下記以外にもセキュリティに関する取り組みを⾏なって います • ショップ管理者ページの2要素認証の導⼊ • ウィルススキャンソフト、クエリログ収集、ファイル整合性監視の導⼊ • PHPのバージョンアップ • 外部脆弱性診断 • WAFの導⼊（本⽇お話する内容）
6. 6 6 そもそもWAFとは？
7. 7 7 そもそもWAFとは？ • Web Application Firewall の略 • Webサーバの前段やモジュールとして設置 • リクエストの内容を解析し、不正なリクエストを防ぐ役割を持つ WAF name=鈴⽊ name=”><script>alert( ...
8. 8 8 そもそもWAFとは？ WAFのタイプ • クラウド型（Saas） • アプライアンス型（専⽤機器） • ソフトウェア型（Webサーバにインストール等） カラーミーショップでは、ペパボの他のサービスで導⼊・運⽤している事例 があることから SiteGuard Server Edition というソフトウェア型のWAFを導 ⼊しています。※ 以降はSiteGuardと呼んでいきます
9. 9 9 シグネチャ型のWAFの仕組み • SiteGuardはシグネチャ型というWAFに分類されます • シグネチャ型WAF・・・ シグネチャ（検出パターン）に基づいて、 HTTPリクエストに含まれるリクエストライン、リクエストヘッダ、リ クエストボディを検査して攻撃を検出します • 検出した攻撃はブロック・通知することが可能 WAF name=”><script>alert( ... シグネチャXSS001のパターンや！ ブロックしとこ！ エラー画⾯
10. 10 10 シグネチャ型のWAFの仕組み シグネチャは2パターン • トラステッド・シグネチャ ◦ あらかじめチューニングされた状態で標準搭載されている • カスタム・シグネチャ ◦ 独⾃の検出ルールを追加することができる ◦ トラステッド・シグネチャを除外するといったことも設定できる
11. 11 11 WAF導⼊時のリスク 本来正常なリクエストが不正ものと誤検知されることによって、リクエスト が遮断され、機能が正常に動かなくなってしまうリスクがあります。 • 攻撃の意思のない⼀般ユーザの⼊⼒した内容がブロックされてしまう ◦ 問い合わせの原因に • 処理として必要な内容がブロックされてしまう ◦ 障害の原因に WAF なんでー！？ /etc/XXXはディレクト リトラバーサルっぽい ので、ダメです。 リンク追加しよ！ url=https:// example.com/etc/ hoge.jpg
12. 12 12 誤検知なく、安全にWAF導⼊するためにはどうすれば良いか • Webアプリケーションの特性に合わせシグネチャの調整が必要 • 適切に調整を実施することが、WAF導⼊のカギとなる 今回はカラーミーショップで、この調整作業をどうやって進め、導⼊を⾏っ たか、直近の事例をご紹介していきたいと思います。
13. 13 13 カラーミーショップで実施したWAF導⼊作業の流れ
14. 14 14 カラーミーショップで実施したWAF導⼊作業の流れ • 1. 監視運⽤設定で導⼊する • 2. ログを収集・確認する • 3. 誤検知と判断したリクエストを除外する • 4. 2,3を繰り返し、誤検知を取り除いていく • 5. WAFを監視設定から遮断設定に切り替えて完了 +α ⼯夫したポイント3点
15. 15 15 1.監視運⽤設定で導⼊する WAFを初めて環境に導⼊する際は、監視運⽤設定にしておきます。 • あらかじめ監視運⽤設定にしておくことで、リクエストを遮断すること なくWAFを導⼊することができます。 • WAFで検知した内容は、ログに記録することができます。 WAF name=鈴⽊ name=”><script>alert( ... 検知ログ に記録
16. 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デコードすると "><script>alert(1);</script> => 攻撃と判断
17. 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 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 19 4, 2,3を繰り返し、誤検知を取り除いていく 誤検知が⾒つからなくなるまで、検知ログの確認と誤検知の対応を繰り返し ⾏なっていきます。 ログの収集 誤検知の除外設定 ログの確認
20. 20 20 5. 誤検知がなくなったら遮断するように切り替える 誤検知がなくなったら、監視運⽤から攻撃を遮断する運⽤に切り替えます。 カラーミーショップでは、 • ⼩規模なロールの場合、3〜4⽇くらい ◦ 会員登録・ログインページ、メルマガページなど • ⼤規模なロールの場合、1〜3週間くらい ◦ ショップ管理者ページ、APIなど 誤検知がないことができた後、切り替えを⾏いました。
21. 21 21 5. 誤検知がなくなったら遮断するように切り替える 誤検知がなくなったら、監視運⽤から攻撃を遮断する運⽤に切り替えます。 カラーミーショップでは、 • ⼩規模なロールの場合、3〜4⽇くらい ◦ 会員登録・ログインページ、メルマガページなど • ⼤規模なロールの場合、1〜3週間くらい ◦ ショップ管理者ページ、APIなど 誤検知がないことができた後、切り替えを⾏いました。 これでWAFの導⼊は完了！
22. 22 22 ⼯夫したポイント3点
23. 23 23 ⼯夫したポイント その1 検知ログを⼀括で検索できるようにした！ これまで抱えていた問題： 1つのロールに対し、サーバが複数が並列でが動 いる。サーバごと検知ログが置かれているため、1台1台検知ログを拾って いかなければなりませんでした => Redashというダッシュボードツールを使って、まとめて検索できるよう にしました！
24. 24 24 ⼯夫したポイント その1 吸い上げ 保管 検索 構成 検知ログ
25. 25 25 ⼯夫したポイント その2 カスタム・シグネチャの設定（除外設定）を楽にした！ これまで、カスタム・シグネチャの更新作業は以下のどちらかで⾏う必要がありま した • SiteGuardの管理画⾯（ブラウザ）から更新を⾏う ◦ 設定したいシグネチャをサーバ台数分、1台1台画⾯をクリックして設定してい かなければならないので、作業が煩雑 • カスタム・シグネチャの設定ファイルを直接更新する ◦ 設定ファイルが⼈間には理解しにくい構成になっているため、直接編集が困難 => どちらの⽅法をとっても⼤変な作業
26. 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 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 28 ⼯夫したポイント その2 その他、改善点 • GitHubのリポジトリで管理するようにした ◦ 変更管理やレビューが⾏いやすくなった • Capistranoでデプロイできるようにした ◦ 設定ファイルをCapistranoでデプロイするだけで、サーバ全台同時 に設定を反映することができるようになった
29. 29 29 ⼯夫したポイント その3 検知ログの確認を効率化した これまで、誤検知を⾒つけるために、毎⽇⼤量のログから誤検知がないかを チェックしていかなければならなかった • ⼀般的にWebサービスは常に何かしらの攻撃を受けている • その分、⼤量の検知ログが出るので、⼀通り⽬を通していくのが⼤変 具体的には、なにが⼤変なのか • 確認済みのパターンであっても何度も⽬を通す必要がある • 定期的にRedashを⾒に⾏かなければならない
30. 30 30 ⼯夫したポイント その3 新たに検出されたパターンのみ確認できるようチェックシートを作った 新たに検出されたパターンが⾃動的にシートに追記され ていく（重複なし） 確認が終わったら チェックをつける
31. 31 31 ⼯夫したポイント その3 1.検知ログを Redashで抽出 2.検知ログをGASでフィルター （チェック済みのものは追加 しない） 3.新たなパターンが検出されたら スプレットシートに追記 4. 定期的にSlackへ通知
32. 32 32 ⼯夫したポイント その3 1.検知ログを Redashで収集 2.検知ログをGASでフィルター （チェック済みのものは追加 しない） 3.新たなパターンが検出されたら スプレットシートに追記 4. 定期的にSlackへ通知 ときには半⽇掛かってしまうような、検知ログの確認作業を 半分以下の時間で対応できるようになった！
33. 33 33 このような取り組みの結果 このような取り組みを⾏うことで、直近で導⼊した次の4ロールについて は、全部で1か⽉・障害、お問い合わせなく安全にWAFを導⼊することがで きました • ショップページ • メルマガ • 会員新規登録・ログイン • ランディングページ
34. 34 34 まとめ ⼀般的に導⼊コストが⾼いと⾔われているWAF ですが、様々な⼯夫をしていくことで、早く安 全に導⼊することができるようになりました。 => WAFの運⽤ついてのお話は、また別の機会 に