会員登録の認証メールに攻撃を受けた話

こんにちは、株式会社ビズパ プロダクト開発チームの青木です。
こちらはビズパプロダクトブログの記事になります。下記マガジンから過去の記事を見ることができます。毎月なにかしら記事が追加されていく予定ですので、興味があれば是非フォローしてみてください！

プロダクトブログ｜Bizpa（ビズパ）｜note

背景

先日弊社サービス「ビズパ」の会員登録時に送信する認証メールが認証されないままになっている件数が急に増加するという事象が発生し、以前は平均10件/日だったのが、平均500件/日に増加してしまいました。何者かがメールアドレスのリストを使用して大量のリクエストを送っていることが考えられます。
また、該当メールを受信した人の中にはメールを苦情メール扱いにしているケースがあり、Amazon SES(弊社が利用しているメール送信サービス)が算出している苦情率が0.1%を超えてしまいました。Amazon SESでは苦情率が0.1%を超えるとAWSによる監視の対象となり、0.5%を上回るとメールの配信が止められてしまう場合もあるため、至急対策をすることになりました。

Amazon SES 送信レビュープロセスに関するよくある質問 - Amazon Simple Email Service

対策

弊社では今回の事象に対して以下の2点の対策を実施しました。

• セキュリティ強化の為にWAFの設定を追加

• 苦情メールとして報告されたメールアドレスへのメール配信をしないように対応

セキュリティ強化の為にWAFの設定を追加

弊社では元々AWSのWAFを利用して攻撃を検知できるようにしていましたが、今回のようなメールアドレスのリストを使用したDoS攻撃に対して対策を設定していなかったので、対策を導入することにしました。
そこで、同一IPアドレスからの大量アクセスを検知しブロックすることができ、アクセスログに基づきブロックするIPアドレスのリストを動的に追加することができるAWS WAFのセキュリティオートメーションを導入することになりました。
こちらはCloudFormationを利用して構築するサービスで、作成されるWAFのウェブACLをCloudFrontやALBに設定することで、AWSのマネージドルールに該当する攻撃を防いだり、大量リクエストを行っているIPアドレスをブロックするなどの様々なセキュリティ機能を一律で提供してくれます。
至急で対策を必要としている中で、CloudFormationを使用して短い時間で構築できることも採用した理由の一つです。

実際に本番に適用する前にはstaging環境で動作を確認をしました。
動作確認をする中で一部機能が攻撃として検知されてしまうなど、想定外の動作をしたケースがあり、そのような場合はWAFの設定を調整して本番へ適用しました。

具体的には以下のような点を変更をしました。

• HTTPフラッド攻撃に対するWAFのルールの設定値を変更

• HTML入稿機能がXSS攻撃として検知されてしまうケースがあったので該当機能チェック対象から除外

一つ目に関してはWAFのマネージドルールの一つである「WAFSecurityAutomationsHttpFloodRateBasedRule」の設定「Request aggregation」を「Source IP address」から「IP address in header」に変更しました。こちらはサービスの構成によるかと思いますが、弊社では「Source IP address」の場合、ユーザー全員のリクエストが集約されるような動きになりました。

マネージドのサービスは短い時間で構築ができる一方で、仕様がブラックボックスになっているところもあり、予期しない挙動をすることもあるのでstaging環境でしっかり動作確認をすることが大切です。

苦情メールとして報告されたメールアドレスへのメール配信処理をしないように対応

Amazon SESにはサプレッションリストという機能があり、こちらは送信したメールがバウンスした場合や、苦情メール扱いされた場合にそのメールアドレスを自動的にサプレッションリストに登録され、登録されているメールに対してはメールが送信されなくなる機能です。弊社ではこちらの機能を利用していたため、今回の事象によって苦情メール報告をした人に対しては再度メールが送られないようになっています。
しかし、Cloud Watchのメトリクスとサプレッションリストを比較したところ、対象のメールアドレスにメールを送信しようとすると、実際にはサプレッションリストの機能によって送信はされないが、苦情率には計上されているように見受けられたので、サーバー側で苦情メール報告をしたメールアドレスに対してはメール送信自体を実行しないように処理を追加しました。
(こちらはAWSのドキュメントを確認した限りだと、苦情率には苦情メール報告を受けた数のみが計算されるように読めたので、こちらの対応の有効性は確認できておりません)

結果

対策の結果としては、WAFの設定を追加した効果が大きかったです。
特に「WAFSecurityAutomationsIPReputationListsRule」というルールではAWS側で事前に不正アクセスなどの疑いがあるIPアドレスのリストを用意してあり、そちらに当てはるIPアドレスからのアクセスをブロックすることができるのですが、運用しているとこちらのルールによってブロックされているアクセスが多くありました。
上記のような効果もあり、認証メールが認証されないままになっている件数は攻撃を受ける前の水準まで戻りました。

一方で、メトリクス上はまだ0.1%を切ることができない状態ですが、苦情率はピーク時に比べると減少し、一日あたりの苦情メール報告の件数はほとんどなくなってきたので今後も注視していきます。

さいごに。

お読みいただきありがとうございました！
ビズパにご興味のある方はぜひ以下のサイトもご覧ください。

▼Bizpaの創業ストーリーはこちら！

広告で迷わない世界を。株式会社ビズパが実現したい未来とは。

▼Bizpaのことをもっと知りたい方はこちら！

Bizpa（ビズパ）｜note