自作サービスがDDoS攻撃された話
自作サービスがDDoS攻撃された話
休日が木っ端微塵に吹き飛んだ
The English version is available here.
- タイトル訂正: 「自作サービス『に』→『が』DDoS攻撃された話」
- 「それはDDoSではない」という指摘に関して末尾に追記 (6/18)
SaaSを開発していると本当にいろんな事が起こります。それらは時に開発者に喜びや悲しみ、怒り、感謝、落胆や興奮をくれます。思い返してみれば結局はみんないい思い出になるものです。先週末に、拙作の小さなウェブサービスがDDoS攻撃を受けました。言わずもがな、悪い出来事です。本稿ではこの事故がどんなものだったのか、どうやって対処したのかについてお話します。
どうもTAKUYAです。僕はInkdropというクロスプラットフォームなMarkdownノートアプリを独りで3年以上開発・運用しています。ユーザ数2万人以下のとてもニッチなSaaSで、僕はこのサービスで生計を立てています。このブログの他の投稿で、僕がどのようにこのサービスを作り上げたのか知ることが出来ます。このアプリはマス消費者向けのサービスではないため、サーバ負荷は基本的に低くて安定しています。大手サイトに取り上げられたりして巨大なトラフィックが急に来ることもありません。そのお陰でサーバ運用に時間をかけることなく開発に集中できていました。しかし事は起こりました。
３万個のフェイクアカウントが攻撃者によって作られた
それは土曜日で、（更に悪いことに）妻の誕生日でした。遅い昼食をレストランで済ませ、家で昼寝をしました。メールはチェックしていませんでした。幸せな昼下がりの昼寝から起きると、AWS CloudWatchからアラートが届いており、EC2上のCouchDBサーバのCPU負荷が異常に高い事に気づきました。コンソールを急いで開いて、サーバがいつもより過負荷である事を確認しました。いったい何が起こっているんだ？深く呼吸しました。 😨
Google Analyticsはこれといって高トラフィックを示していないにも関わらず、大量のアカウントが作られていました（結果的に3.4万個）。これは攻撃だと認識しました。
この事についてまずはツイートする事にしました。
ともかくAPIサーバを止めて、攻撃者がこれ以上フェイクアカウントを作れないようにしました。次にフェイクアカウントの中身を調べました。攻撃者は様々なIPアドレスからアクセスしており、これがDDoS(distributed denial-of-service)攻撃の類いである事がわかりました。この場合、相手のリクエストをIPアドレスに基づいて拒否するという対処は無効です。では、彼らの攻撃の目的は何なのでしょうか？すべてのアカウントには共通の名前が設定されている事に気づきました：
"firstName": "ПОЛУЧИТЕ ДЕНЬГИ https://bit.ly/xxxxxx ",
"lastName": "ПОЛУЧИТЕ ДЕНЬГИ https://bit.ly/xxxxxx ",
ロシア語と短縮URLが見えます。“ПОЛУЧИТЕ ДЕНЬГИ”は“Cash in”という意味で、リンクを開くと以下のようなフィッシングサイトに飛ばされます：
しばらく考えて、彼らの目的は僕自身ではなく、ユーザ登録確認メールを受け取った人々から金銭を要求する事だと気づきました。僕のサーバはロシア語を喋る人たちへ大量のメールを送信するために悪用されたのです。被害者は以下のようなメールを受け取りました：
ひどい。でもひとつ良かった点は、彼らの目的がInkdropのユーザデータを破壊したり盗むことではなかった事です。基本的に既存ユーザは被害を被らなくて済みました。また幸いなことに、自分のSES(Simple Email Service)アカウントはAWSからBANされずに済みました。受け取ったほとんどの人々は詐欺メールを報告しなかったためです。ほとんどが非アクティブなメールボックスなのかもしれません：
さて、どうやってこの攻撃を根本的に対処すればよいでしょうか。
reCAPTCHA v3を実装した
問題はボットがユーザ登録APIを好き放題に呼び出せることです。それを制限しましょう。上記で調査したとおり、彼らはフィッシングURLを人々に送りつけたい訳なので、新アカウントの名前フィールドに ‘http’ が含まれていたら拒否する施策は有効でしょう。とても簡単です。でもその他の未知の攻撃には対処できません。そこで、GoogleのreCAPTCHA v3を実装することにしました。たまたまこの技術について既に知っていたのでラッキーです。
reCAPTCHA v3 returns a score for each request without user friction. The score is based on interactions with your site and enables you to take an appropriate action for your site.
つまりreCAPTCHA v3はユーザの操作する様子を見て自動的にスコア付けします。一般的なCAPTCHAとは異なり、画面に表示された歪んだ文字や数字を訪問者に入力させる必要はありません。よってコンバージョンレートが下がる心配はないという利点があります。その上、無料で実装も簡単です。自分は30分で実装できました。Inkdropのユーザ登録画面にて、このようにreCAPTCHAのロゴが表示されます：
詳しい使い方はreCAPTCHAのウェブサイトをご参照ください：
今のところ、False Negative(誤った黒判定)はありません。正しく人間を人間と判定しているようです(スコア ≥ 0.5):
一応上手く行ったようです。数時間後、攻撃は止まりその後繰り返されることはありませんでした。キツいレッスンでした。
ところで、Patrickが他の対処方法を教えてくれました：
要するにサーバ側で2つの乱数を生成して、JS側で合計して返すという簡単な仕組みを使えば99%防げるよという話です。99%という数字は経験的な感覚値でしょう。
この手法はoAuthのRequest Validationを想起させます。複雑さを加えたい場合は、以下のようなハッシュアルゴリズムを使うといいと思います:
MD5(maddr + nonce + password)// nonceただし、どうせこれをやるならreCAPTCHA v3を導入することをお勧めします。同じ作業量で実装できるからです。その他にもらったアドバイスを掲載しておきます：
Form Submissionにハニーポットフィールドを設けるのは良さそうです。他にもAPIに脆弱性がないか、またチェックしたいと思います。みんなアドバイスありがとう！
