こんにちは。ビットバンクでセキュリティを担当している太田です。
今回の記事では、実際に発生したインシデントから得た教訓をもとにDDoS対策の見直しを実施した というお話です。
本内容は、2022/09/15にAWS主催のセミナーで話した内容と重複します。
AWSブログにセミナー時の動画へのリンクが掲載されていますので、よろしければそちらも見てみてください。
DDoSとは？
『サイバー攻撃の一種』くらいの認識はあるがよく知らない…という方のために説明すると、DDoSとは「Distributed Denial of Service attack」の略で「分散型サービス拒否攻撃」を意味します。
あるサービスに不正な大量アクセスを行い、正規利用者がサービスにアクセスしにくい状態にすることで、サービス提供者の機会損失や信用失墜などを行う行為のことです。
攻撃する側は、脆弱性があるサーバやIoT機器、ネットワーク機器を事前に乗っ取り、それらを踏み台、あるいは攻撃の増幅器として利用し攻撃をしてきます。攻撃される側からすると大量のIPアドレスから攻撃されることになり防御が難しいといった特徴があります。
最近は、DDoS as a Service なんてものまであり、DDoS攻撃のハードルは下がっているようです。
また、攻撃目的としては政治的な主張や、脅迫による金銭要求などが挙げられます。
最近のDDoS動向
2023年が始まって暫く経ちますが、昨年2022年はDDoS攻撃について目にする機会が多い年だったとか思います。
2022年前半には、ウクライナ情勢に関連して、放送メディア、インターネットメディア企業などが攻撃を受け、2022年後半は日本の政府系サイトが攻撃を受けたことなどがニュースになりました。
サイバー攻撃被害といえば、ランサムウェアやマルウェアによる被害が取り上げられることが多く、DDoS攻撃が少し影に隠れている印象でしたが、昨年はニュースでもよく取り上げられていました。
実際に、CloudFlareやAkamai、Google、AWSといった企業が出しているレポートを見ても、DDoS攻撃のトラフィックや攻撃規模は年々、増加傾向にあります。
ビットバンクへ攻撃はあるのか？
過去、当社もDDoSの標的にされ、DDoS攻撃と脅迫メールが来たことがあります。
『金銭を支払わないと攻撃を行う』という主旨のものでしたが、その際は、金銭的な支払いをすることも顧客被害もなくインシデントは収束しました。
ただ、その際のインシデント対応経験を教訓に、また同様のことが起きた際に慌てることなく対処できるようDDoS対策の見直しを行いました。
本記事はその見直した内容について書いています。
DDoS対策として何をすべきか
DDoSに限りませんが、セキュリティの対策は以下2つの観点で検討が必要になります。
- 予防的対策
- 発見的対策
予防的対策は、所謂、WAFを設置したりCDNを利用したりして、攻撃を受けない／影響を最小化するための対策です。一方、発見的対策は、攻撃の検知〜対処プロセスの整備など、攻撃を受けた際に対処するため準備になります。
また、予防的対策といっても様々な種類のものがあります。
- 隠蔽 ：攻撃される可能性があるエンドポイントを隠蔽する。攻撃を受けないための対策
- 遮断 ：攻撃された場合、一定以上負荷からサーバを守るためにアクセスを遮断する対策
- 吸収/緩和：攻撃され負荷がかかってもサービス提供し続けられるようにする対策
まずは攻撃を洗い出す
対策を考える前に、まずはどのような攻撃を受ける可能性があるかを洗い出し分類しました。
＜DDoS攻撃の種類と攻撃例＞
攻撃への対策を洗い出す
次に攻撃分類ごとに、取り得る対策を列挙しました。
当社はAWSを利用しているため、AWS上で可能な対策をひとまず列挙します。
＜DDoS攻撃別の対策＞
ちなみに、これら対策を前述の種類別に分けると、このような感じになります。
- 隠蔽 ：3
- 遮断 ：2, 5, 6, 7, 9
- 吸収/緩和：1, 4, 8, 10
システム構成上どこで対策するかを決める
そして、洗い出した対策をシステム構成上のどこに適用するかを検討しました。
前提となるシステム構成をざっくり図示したものが以下になります。
＜サービスのシステム構成＞
システム構成要素のどこで対策を適用すべきかをマッピングします。
＜システム構成上のDDoS対策適用箇所＞
その上で不足がある箇所については対策適用の検討をしていきました。
その際の考慮事項としては、上記の対策適用箇所はあくまでセキュリティ観点での推奨なので、実際にはアプリの作り上、スケーリング出来ないものがあれば別の対策を検討する、ないしはリスク受容するという選択肢も考慮する必要があります。
また、過剰対策になりうる箇所があれば、あえて対策をしないという判断も考えられます。
このあたりの判断のためにも、上記の対策箇所の表を整理する際に、外部からアクセスがあった際に対策が左から右に適用される状況を可視化しておくといいのではないかと思います。
攻撃検知時の対応フローを整備する
ここまでは予防的対策の話でしたが、発見的対策、つまり攻撃を受けた際の検知・対処についても準備する必要があります。
当社では『攻撃検知時の対応フロー』というものを整備しました。
内容は、攻撃検知〜トリアージ、緩和策の適用、クロージングまでの対処内容・連絡体制を整理したものになります。
＜DDoS攻撃検知時の対応フロー＞
ポイントとしては、検知したものに対して対処要否を判断するトリアージ基準や、緩和策としてどこまでシステム影響を与えていいか、警戒フェーズの解除条件など、通常は属人化しやすい判断基準を明文化したことが挙げられます。
例えば、検知については、リクエスト数やサーバリソース状況、サービス応答速度など監視している項目はいくつかありましたが、検知したものがDDoS攻撃かの調査・対応要否の判断は担当者に委ねられていました。
また、調査も時間を取られますので、検知が頻繁にあればそれなりに稼働を逼迫します。
そこで、調査・対応要否の判断基準を『サービスに実害があるか』と定め、リクエスト数が一定以上かつ、外形監視に異常がある場合にアラートするよう監視体制を敷きました。
＜DDoS攻撃の検知体制＞
また、実際に攻撃を受けている場合、例えば、サービス回復のために正規のユーザーのリクエストを巻き込んでアクセスを遮断していいか、それはどこまでの規模までなら許容されるのか…このあたりは判断が分かれるところではないでしょうか。
DDoSの場合、攻撃を受けている時点で顧客にダイレクトに影響が出てしまっているため、あれこれ相談していると対処が遅れていきます。
特に当社はお客様の資産を預かっているため、迅速に状況説明や対応方針を示す必要があると考えており、またそれがお客様の安心に繋がると考えています。
そのため、攻撃の特徴ごとに取り得る緩和策のパターンを洗い出し、責任者の事前承認を得た上で、攻撃パターンごとにどこまでの緩和策を実施していいのかをフローチャートに落とし込みました。
これにより、承認者に状況を説明して緩和策の妥当性を理解してもらい、承認を得るというプロセスを省略することができるため、例えば深夜に攻撃があったような場合にも迅速に緩和策を適用し暫定的にでもサービス復旧することが可能になりました。
また、緩和策と併せて顧客周知文面も整備し、お客様への周知も迅速に行えるようにしています。
おわりに
いかがでしたでしょうか。
最後は技術的な話ではなく体制面の話になってしまいましたが、実際のインシデントから学んだノウハウを反映してDDoS対策をシステム・体制の両面から見直した、というお話でした。
もちろん、これで安心とは思っていません。
攻撃手法は年々変化しますので、攻撃トレンドや攻撃者の動向などをキャッチアップしつつ、その時々の最適な対策にアップデートしていきたいと思います。
これからもビットバンクをよろしくお願いします。
