Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

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

87cc3b4ffeb28446da380c5acdcf443e?s=128

takapi86

June 24, 2020
Tweet

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の運⽤ついてのお話は、また別の機会 に