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. 2.

    2 2 ⾃⼰紹介 • 名前: ⾼橋雄紀 • Twitter: @takapi86 •

    所属: GMOペパボ EC事業部 カラーミーショップグループ サービス基盤チーム • 業務でやっていること ◦ レガシー環境の改善 ◦ セキュリティ対応
  2. 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/ こちらのテックブログの⽅もご覧いただけると嬉しいです
  3. 7.

    7 7 そもそもWAFとは? • Web Application Firewall の略 • Webサーバの前段やモジュールとして設置

    • リクエストの内容を解析し、不正なリクエストを防ぐ役割を持つ WAF name=鈴⽊ name=”><script>alert( ...
  4. 8.

    8 8 そもそもWAFとは? WAFのタイプ • クラウド型(Saas) • アプライアンス型(専⽤機器) • ソフトウェア型(Webサーバにインストール等)

    カラーミーショップでは、ペパボの他のサービスで導⼊・運⽤している事例 があることから SiteGuard Server Edition というソフトウェア型のWAFを導 ⼊しています。※ 以降はSiteGuardと呼んでいきます
  5. 10.

    10 10 シグネチャ型のWAFの仕組み シグネチャは2パターン • トラステッド・シグネチャ ◦ あらかじめチューニングされた状態で標準搭載されている • カスタム・シグネチャ

    ◦ 独⾃の検出ルールを追加することができる ◦ トラステッド・シグネチャを除外するといったことも設定できる
  6. 11.

    11 11 WAF導⼊時のリスク 本来正常なリクエストが不正ものと誤検知されることによって、リクエスト が遮断され、機能が正常に動かなくなってしまうリスクがあります。 • 攻撃の意思のない⼀般ユーザの⼊⼒した内容がブロックされてしまう ◦ 問い合わせの原因に •

    処理として必要な内容がブロックされてしまう ◦ 障害の原因に WAF なんでー!? /etc/XXXはディレクト リトラバーサルっぽい ので、ダメです。 リンク追加しよ! url=https:// example.com/etc/ hoge.jpg
  7. 14.

    14 14 カラーミーショップで実施したWAF導⼊作業の流れ • 1. 監視運⽤設定で導⼊する • 2. ログを収集・確認する •

    3. 誤検知と判断したリクエストを除外する • 4. 2,3を繰り返し、誤検知を取り除いていく • 5. WAFを監視設定から遮断設定に切り替えて完了 +α ⼯夫したポイント3点
  8. 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> => 攻撃と判断
  9. 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 を除外
  10. 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は誤検知されやすいので除外
  11. 25.

    25 25 ⼯夫したポイント その2 カスタム・シグネチャの設定(除外設定)を楽にした! これまで、カスタム・シグネチャの更新作業は以下のどちらかで⾏う必要がありま した • SiteGuardの管理画⾯(ブラウザ)から更新を⾏う ◦

    設定したいシグネチャをサーバ台数分、1台1台画⾯をクリックして設定してい かなければならないので、作業が煩雑 • カスタム・シグネチャの設定ファイルを直接更新する ◦ 設定ファイルが⼈間には理解しにくい構成になっているため、直接編集が困難 => どちらの⽅法をとっても⼤変な作業
  12. 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
  13. 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
  14. 28.

    28 28 ⼯夫したポイント その2 その他、改善点 • GitHubのリポジトリで管理するようにした ◦ 変更管理やレビューが⾏いやすくなった •

    Capistranoでデプロイできるようにした ◦ 設定ファイルをCapistranoでデプロイするだけで、サーバ全台同時 に設定を反映することができるようになった
  15. 29.

    29 29 ⼯夫したポイント その3 検知ログの確認を効率化した これまで、誤検知を⾒つけるために、毎⽇⼤量のログから誤検知がないかを チェックしていかなければならなかった • ⼀般的にWebサービスは常に何かしらの攻撃を受けている •

    その分、⼤量の検知ログが出るので、⼀通り⽬を通していくのが⼤変 具体的には、なにが⼤変なのか • 確認済みのパターンであっても何度も⽬を通す必要がある • 定期的にRedashを⾒に⾏かなければならない
  16. 32.

    32 32 ⼯夫したポイント その3 1.検知ログを Redashで収集 2.検知ログをGASでフィルター (チェック済みのものは追加 しない) 3.新たなパターンが検出されたら

    スプレットシートに追記 4. 定期的にSlackへ通知 ときには半⽇掛かってしまうような、検知ログの確認作業を 半分以下の時間で対応できるようになった!