[レポート]bitbank 暗号資産取引所を止めないためのベストプラクティスに沿った DDoS 対策 – AWS Security Forum Japan 2023 #aws #awssecurity

AWS Security Forum Japan 2023で行われた「bitbank 暗号資産取引所を止めないためのベストプラクティスに沿った DDoS 対策」のセッションレポートです。
2023.10.13

皆さん、こんにちは。

明るい笑顔がトレードマーク、ルイボスティーが大好きな芦沢(@ashi_ssan)です。

今回は2023年10月12日にオフラインで行われたAWS 国内最大のセキュリティイベントであるAWS Security Forum Japan 2023の下記セッションのレポートです。

bitbank 暗号資産取引所を止めないためのベストプラクティスに沿った DDoS 対策

【スピーカー】 ビットバンク株式会社 セキュリティチームマネージャ

太田 健介 氏

bitbank ではサービスの可用性を高めるために DDoS 対策の見直しを行いました。その際行った対策について、AWS ベストプラクティスに沿って、どんな対策を行ったのか、検討の中で出てきた課題などについて共有します。

ビットバンク株式会社

セキュリティチームマネージャ

太田 健介氏

アマゾン ウェブ サービス ジャパン合同会社

技術統括本部 インターネットメディアソリューショングループ ソリューションアーキテクト

竹本 将気

3行まとめ

  • AWS Shiled Advancedを使うことで近年増えているアプリケーションレイヤーに対する攻撃を防ぐことができ、DDoS攻撃を受けた際のAWS WAFルールのメンテナンスを自動化できる。攻撃発生時の運用負荷が軽減でき、Shieldレスポンスチームのサポートもあって安心。
  • DDoS対策をしたい場合は、DDoSセキュリティベストプラクティスに沿って対応すれば大丈夫。
  • 予防的対策としてDDoS攻撃の種類に応じて防御策を策定し、発見的対策としてDDoS対応フローの策定するべし。

セッション概要

  • スピーカーについて
    • AWS 竹本さん
    • Web系のお客様向けのSA
  • アジェンダ
    • 最新の脅威動向
    • AWS Shield Advancedについて
    • DDoS耐性に関するAWSのベストプラクティス
  • 最新の脅威動向
    • 毎秒300GBを超えるフローログ
    • 1日あたり1000億件のAWS WAF Managed Rule処理
    • 1日あたり数千件のDDoS攻撃対応
  • DDoS攻撃は年々増えている
    • 2023年では、DDoS攻撃の48%がアプリケーションレイヤーへの攻撃
  • HTTP/2 Rapid Reset Attackについて
    • CloudFrontへのHTTPリクエストが異常に増加した
    • AWSは早期に検知して対応した
  • AWS Shiled Advanced
    • トラフィック統計情報からDDoSを自動で緩和
    • 設定見直しやシグネイチャ更新を自動で行う
    • 自動更新できない部分は、Shiledレスポンスチームが実施
    • AWS WAFの費用が発生しなくなるので、コスト削減にもなる
  • Shiled StandardとAdvancedの違い
    • Standard
      • 一般的なDDoS攻撃に対応した攻撃緩和サービス
      • 全てのインターネットに面したAWSサービスで透過的に使われている
    • Advanced
      • 大規模かつ高度なDDoS攻撃に対応した攻撃緩和サービス。Shieldレスポンスチームのサポートも利用できる。
      • アプリケーションレイヤーの自動軽減緩和がある ←今日はこれについて説明
  • アプリケーションレイヤーDDoSの自動緩和
    • DDoS攻撃を防ぐAWS WAFイベントのルールが自動で作成される
    • 誤検知を防ぎながらDDoSを緩和
    • イベントが収まった後はルールが自動で削除され、手動介入は不要
  • DDoS耐性に関するAWSのベストプラクティス
    • HTTPメソッドやプロトコルを必要なものだけに絞る
    • CFのマネージドプレフィックスリストで受信IPを絞る
    • OACを使って、S3バケットのアクセスをCFからにのみ制限する
    • AWS WAFでアプリケーションの脆弱性対策を行う
  • AWS Best Practices for DDoS Resiliency
    • AWSのホワイトペーパー
    • 以下の内容が含まれる
      • DDoS攻撃対策の手引き
      • AWSサービスでの耐性向上法
  • ここからのスピーカー
    • ビットバンク 太田さん
    • 元々はSIerでID管理や認証管理の提案業務を担当
    • ビットバンクではセキュリティ担当を行なっているプレイングマネージャー
  • ここからの概要
    • DDoSのベストプラクティスに沿って、導入・運用の苦労話を入れながら、事例を紹介していく
  • システム構成
    • CloudFront(WAF)-ALB,S3-Fargate,EC2-Aurora,Fargate
  • どこにどんな対策が必要なのか?をこれから紹介
  • DDoS攻撃の例と対策
    • NW帯域消費型攻撃
      • レイヤー3攻撃: Ping Flood
        • CDNによるアクセス分散, AWS Shiled によるL3/L4防御、CDNアクセス隠蔽
      • レイヤー4攻撃: UDP Flood, SYN Flood
    • サーバーリソース消費型攻撃
      • レイヤー7攻撃: ログイン画面攻撃などWebサイトを狙う
        • キャッシュによる負荷軽減、特定IPによる通信遮断など
  • どう実装していくのか?
    • コンポーネントをナンバリングし、どこでどの対策をすべきかを示唆
    • フロントで十分軽減できているものは、優先度を落とす
    • 対策箇所と攻撃例をマッピングしてまとめた
  • 攻撃の検知・対応はどうする?
    • 対応フローを決めておくことが推奨されている、AWSがプレイブックの例も提供している
  • ビットバンクではDDoS対応フローのフローチャートを作った
    • 検知・認定・対応・警戒・クロージングのフェーズに分けて、それぞれ定義してまとめたフロー
  • DDoS対策の概要
    • 予防的対策
      • 攻撃例に別の対策の実施
    • 発見的対策
      • DDoS対応フローの策定
  • 攻撃の緩和策
    • AWS WAFマネージドルールの導入
      • 初期はCOUNTで導入(BLOCKで導入する話もあった)、その後BLOCKに変更
      • 通常のブラウザではありえないヘッダーのリクエストがある...
        • 正規のお客様からのbotアクセスがあった
        • BLOCKで導入しなくてよかった!な例
      • ユーザーIDからのリクエストだけインジェクション系のルールで引っかかっている
        • バグバウンティ目的のユーザーだと判断、ブロックした
  • WAFマネージドルールを入れてわかったこと
    • 独自の事情で単にbotアクセスだとか判断できないこともある
  • Advanced導入のコスト影響
    • 導入以前:AWS WAF $3000
    • 導入以後:Shield Advanced $3000, AWS WAF $0
      • Advancedを使ってなかったらWAFで$5000くらいになっている
    • ログ保管コスト
      • WAFログはCWlogsに保管している
      • ログ保管要件:リアルタイムで解析したい、常時リアルタイムは不要、長期保管は不要
      • CWlogsに決めた理由: S3の場合はVended Logsの取り込み料金がかかるなどメリットがあまりなかった
  • S3の隠蔽: OACによるアクセス制限
    • S3の前段にCloudFrontを配置
    • refererでアクセス許可
  • ALBの隠蔽
    • 案1:AWSマネージドプレフィックスリスト
      • 野良CloudFrontから繋げてしまうリスクがある
    • 案2:CloudFrontのカスタムオリジンヘッダー
      • 設定ミスにより接続できなくなるリスクがある
    • 案1に決めた
      • オリジンからCloudFrontへのアクセス時に、ALBで持っている証明書が含まれていることをCloudFrontが検証しているため
      • 上記の理由からリスクを許容できると判断した
  • AWS Shield Advancedを利用したDDoS検知体制
    • リクエスト数監視とヘルスチェックの組み合わせで誤検知があまりない
    • Shield Responze Teamからの直接連携とその後の連携がスムーズ
  • CloudFrontとWAFのIaC化
    • コンソールの設定変更が頻繁にあるため、変更があるたびに手順書の変更が必要だった
      • CFn化して対策した
    • CFn化の懸念
      • 再作成されることによるサービス停止が嫌だったが、CFnのリソースインポート機能で解決
      • インポート用のCFnテンプレートはFormar2で作成した
    • 作成したテンプレートはGitLabで管理
      • CFnのデプロイは、GitLab RunnerによるCI/CD
    • よかったこと
      • IaC化によって手作業がなくなり、作業ミスやデプロイ工数が削減された
      • IDaaSの障害でAWSコンソールにログインできない時も、影響がなかったのでIaC化してよかった
  • まとめ
    • DDoSセキュリティベストプラクティスに沿って対策すればOK
    • セキュリティを維持して、外的環境の変化に対応するため、マネージドサービスに頼ろう

最後に

ALBやCloudFrontを使っていれば、Shiled Standardを使っているのでDDoS対策ができていて安心だ、となんとなく思っていました。しかし、このセッションを聞いて近年はアプリケーション層を狙うDDoS攻撃が増えていてStandardだけでは不十分なことも十分起きうると理解しました。

「DDoSセキュリティベストプラクティスを読んで対策すれば大丈夫!」という一言が、心強かったです。

個人的には大規模なDDoS対策を行うような技術支援をした経験がないので、まずはAWS Best Practices for DDoS Resiliencyから読んでみよう、と思います。

以上、芦沢(@ashi_ssan)でした。