Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
pepabo-ec-tech-conference-web-application-firewall
Search
takapi86
June 24, 2020
Programming
3
1.3k
pepabo-ec-tech-conference-web-application-firewall
GMO Developers Night #10 ペパボ EC テックカンファレンス 2020.06.24
https://pepabo.connpass.com/event/179445/
takapi86
June 24, 2020
Tweet
Share
More Decks by takapi86
See All by takapi86
SIerから転職してきて 良かったこと・大変だったこと
takapi86
1
1k
カラーミーショップのクラウドネイティブに向けた取り組み
takapi86
0
2.1k
Other Decks in Programming
See All in Programming
42 best practices for Symfony, a decade later
tucksaun
1
120
watsonx.ai Dojo #4 生成AIを使ったアプリ開発、応用編
oniak3ibm
PRO
2
280
Java 23の概要とJava Web Frameworkの現状 / Java 23 and Java web framework
kishida
2
380
.NET 9アプリをCGIとして レンタルサーバーで動かす
mayuki
1
750
コンテンツの主権を守るため(?)、高機能画像CDNからAWS自前対応に乗り換えた話
lengthtail
1
120
Jakarta EE meets AI
ivargrimstad
0
1.3k
eBPF Deep Dive: Architecture and Safety Mechanisms
takehaya
12
1.2k
rails statsで大解剖 🔍 “B/43流” のRailsの育て方を歴史とともに振り返ります
shoheimitani
0
230
TypeScript でバックもやるって実際どう? 実運用で困ったこと3選
yuichiro_serita
17
7.6k
Seamless Flutter Native Integration: FFI & Pigeon - Dreamwalker (JaichangPark / 박제창) @FlutterKaigi2024
itsmedreamwalker
0
120
CSC305 Lecture 25
javiergs
PRO
0
110
macOS なしで iOS アプリを開発する(※ただし xxx に限る)
mitsuharu
1
170
Featured
See All Featured
Producing Creativity
orderedlist
PRO
341
39k
GraphQLの誤解/rethinking-graphql
sonatard
67
10k
Gamification - CAS2011
davidbonilla
80
5.1k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
356
29k
Thoughts on Productivity
jonyablonski
67
4.3k
For a Future-Friendly Web
brad_frost
175
9.4k
Practical Orchestrator
shlominoach
186
10k
Build The Right Thing And Hit Your Dates
maggiecrowley
33
2.4k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
38
1.8k
Testing 201, or: Great Expectations
jmmastey
40
7.1k
Bash Introduction
62gerente
608
210k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
Transcript
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=”><script>alert( ...
8 8 そもそもWAFとは? WAFのタイプ • クラウド型(Saas) • アプライアンス型(専⽤機器) • ソフトウェア型(Webサーバにインストール等)
カラーミーショップでは、ペパボの他のサービスで導⼊・運⽤している事例 があることから SiteGuard Server Edition というソフトウェア型のWAFを導 ⼊しています。※ 以降はSiteGuardと呼んでいきます
9 9 シグネチャ型のWAFの仕組み • SiteGuardはシグネチャ型というWAFに分類されます • シグネチャ型WAF・・・ シグネチャ(検出パターン)に基づいて、 HTTPリクエストに含まれるリクエストライン、リクエストヘッダ、リ クエストボディを検査して攻撃を検出します
• 検出した攻撃はブロック・通知することが可能 WAF name=”><script>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=”><script>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デコードすると "><script>alert(1);</script> => 攻撃と判断
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の運⽤ついてのお話は、また別の機会 に