ココナラが DDoS 攻撃の脅威を分析し、対策を実現するまで

DDoS 攻撃対策と一言で言っても、対策の仕方は幾重も考えられます。例えば、日本国内のみに展開されているプロダクトであれば、AWS WAF で「日本国内のみの IP アドレスからしかアクセス許可しない」という設定を組み込むことで、海外からの DDoS 攻撃の芽を摘むことができます。一方で海外に展開されているプロダクトであれば、上記対策はできなくなってしまうため、まずはプロダクトのサービス提供範囲を元に対策を検討するところから着手しました。

ココナラは日本国内を中心としているプロダクトなので、前者の考え方を中心に対策を検討しています。ただし海外からの利用もあるので、海外からのアクセス全てを遮断するわけではなく、重み付けをして悪意のある攻撃を防ぐ手法を検討しました。

具体的な手段としては、AWS Shield Advanced、AWS WAF、Amazon CloudFrontを用いて、日々 DDoS 攻撃へ向き合っています (ただし、Amazon CloudFront は 元々 CDN 目的で導入済みでしたので、今回の記事での紹介は割愛します)。

ココナラでは DDoS 攻撃対策を速やかに実現するため、「費用対効果」と「導入容易性」を重要視して、ソリューションを検討しました。具体的には AWS Shield Advanced と 3rd Party 製品の 5 社を機能や費用、導入容易性や導入事例といった軸で比較しています。

重要視するポイントを含め、総合的に AWS Shield Advanced に優位性があると判断し、導入の意思決定をしました。

導入したのは 2021 年 9 月でしたが、その数ヶ月前に DDoS 攻撃と思われるアクセスを受けて、サイトがスローダウンしたため、機会損失とコストを比較して導入の意思決定は即座に行いました。

それまでは DDoS 攻撃を受けてもどのような状況だったかの可視化ができませんでしたが、AWS Shield Advanced の機能を活用することにより、例えば DDoS 攻撃には傾向があるということがわかりました。一例で言いますと、アクセスする URL はトップページが多いなどです。

こちらは AWS Shield Advanced の画面イメージですが

• DDoS 攻撃をいつ受けたか ?
• どの時間帯にどれだけのアクセスがあったか ?
• パス別、国別、IP アドレス別、UA 別などのアクセス状況はどうだったのか ?

を確認することができます。

AWS Shield Advanced を利用することで、DDoS 攻撃への防御だけでなく、DDoS 攻撃を受けているのかどうか ? がわかるので、その情報を元に対策の優先度見直しや経営層へのレポート・意思決定の促しが可能になります。

脅威を分析することが対策立案の第一歩となりますので、ココナラではこの情報を活用し、どのような対策が効果的か ? を立案しました。

次に多層防御として、AWS WAF のさらなる利活用にも着手しました。すでに AWS WAF を導入済みでしたので、具体的なルールに落とし込んで対策を検討していたところ、自社のノウハウだけでは対応が難しかったため、AWS Japan のソリューションアーキテクト (以降、SA と表記) にも相談させてもらい、AWS が提唱するベストプラクティスに準拠した対策を実践しました。

前述の通り、ココナラも DDoS 攻撃を受けるケースがありましたので、ココナラ担当の SA に相談させてもらい、効率的・効果的な対策についてディスカッションしました。ディスカッションの結果、以下の対策をアドバイスとしていただきました。

1. Amazon CloudFront の配下にベースページを含めた coconala.com を置く

• キャッシュさせる / させないは関係なく AWS Shield Advanced と近いロケーションで緩和することが可能
  • エッジロケーションが世界中に分散された場所にあるので、攻撃者の近くで対応・緩和することができる
• オリジンがダウンしたときに sorry-server を返すことができる
  • エラーではないので、ユーザーエクスペリエンスとしては高くなる
    

2. AWS WAF のレートベースルールを見直す

• 現在の閾値ではブロックできていないので、閾値を下げる
• 特にアクセスが多くなるところを明示的に指定する
• 海外の IP アドレスに対して厳しく設定する

3. AWS WAF の IP レピュテーションルールグループを利用する

• ラベル機能を利用したレートベースルールの設定が可能
• not Japan で 100 リクエスト、などの設定が可能

4. AWS Shiled AdvancedのShield Advanced アプリケーションレイヤー DDoS 自動緩和を利用する

5. AWS WAF Bot Controll を利用する

まずは容易に対応できる「2. AWS WAF のレートベースルールの見直し」と「3. AWS WAF の IP レピュテーションルールグループの利用」を組み合わせて、DDoS 攻撃対策を実現しました。

具体的には以下の対応を行いました。

• アクセス元に応じた許可ルールを設定
• ロケーション無関係にトップページに対するレートベースルールを設定
  
• 日本国内と海外でレートベースルールを分けて、閾値を設定
  

それらのアクセス状況を日次でモニタリングし、チューニングすることでより精度の高い対策を実現しています。今回ご説明した設定の画面イメージを載せますので、ぜひご参考にしてください。

現在も引き続き、不定期に DDoS 攻撃を受けることはありますが、サイトダウンやスローダウンが発生することは皆無になりました。国別の制御とレートベースルールを組み合わせることで、現在主流の DDoS 攻撃をうまく凌ぐことができていると考えています。

ココナラはサイトの特性上、オートスケーリングではなく、CM 放映や TV 露出など、アクセスが増加しそうなイベントや日次でリソース状況をモニタリングし、サーバー台数のサイジングを行っています。そのため、悪意のある第三者が大量にアクセスすると、それを前提にしたサーバー台数にする必要があり、コストが掛かります。DDoS 攻撃対策でアクセスを抑制することで、それを加味したサーバー台数にする必要がなく、コスト最適化に貢献するという副次効果もあります。

例えば、DDoS 攻撃は秒間 10,000 件以上のアクセスを優に超えることもありますが、それを受けても問題なくサービスを正常に稼働させるためのサーバーリソースを用意しようとすると膨大なコストがかかります。サイトダウンを未然に防ぎつつ、サーバーリソースの最適化ができるのは我々としては助かっています。

攻撃手法は更に複雑化してきています。そのため、一度設定して終わりではなく、継続した状況のモニタリングと設定のリファクタリングを行うことが大事だと思います。最近の例では、具体的に現在の IP アドレスベースの制限を回避する手法 (複数の IP アドレスを使用したり、多数のデバイスに攻撃を分散) が増えてきています。

それに対してココナラでは、レートベースルールの機能拡張がされているため、Cookie やHTTP メソッドなどとの組み合わせの検証も計画しています。レートベースルールを絞り込むことで、うまく攻撃を遮断できると考えています。

また、AWS WAF Bot Control を活用した悪意のある Bot のアクセス抑止や AWS Shield Advanced の Shield Advanced アプリケーションレイヤー DDoS 自動緩和を活用して、さらなる防御を実現する予定です。

特に「IPO を目指している企業」 や 「IPO 後でより一層セキュリティ対策を強化しなければならない企業」 へ持ち帰れる内容があると考えますので、ご活用いただけたら幸いです。