続々、Publickeyが受けたDDoS攻撃。DDoS対策に効果を発揮した設定紹介編

2024年4月5日

3月12日火曜日に始まったPublickeyへのDDoS攻撃に対して、これまでサーバの強化、Cloudflareの導入とDDoS対策のための設定を行ってきました。

その結果、3月24日日曜日の夜に始まり3月27日水曜日の朝まで3日間連続で続いたDDoS攻撃のあいだもWebサイトの閲覧と記事更新などを問題なく行える状態となり、DDoS攻撃がWebサイトの運営の大きな障害ではなくなりました。

ちなみにそれ以後DDoS攻撃は止んでいますが、今後はいつDDoS攻撃を受けてもWebサイトの運営に支障がでることはなくなったと考えられます。この記事では結局どのような対策を行ったのか、実際に効果を発揮したDDoS対策を紹介していきます。

これまでの経緯は下記の記事をご参照ください。

DDoS対策として有効であった具体的構成

まずは結論として、Publickeyとして十分に効果を発揮したDDoS対策がどのようなものだったかを紹介しましょう。

PublickeyはMovable Typeという、HTMLを静的生成するCMSを利用しています。そのため、WordPressに代表される動的生成のWebサイトと比べて、もともと大量のトラフィックに対応しやすい構成でした。

さくらのマネージドサーバを利用

これを、現在はさくらインターネットが提供する「さくらのマネージドサーバ」の「ミディアム」（8vCPU、16GBメモリ）で運用しています（試してはいませんが、感触としては、静的生成サイトであれば1つ下の「スモール」でも、下記のCloudflareの設定であればDDoSに十分耐えられるのではないかと思います）。

また、さくらのレンタルサーバやマネージドサーバでデータ転送量が無料であったことは今回重要なポイントでした。

もしもクラウドのようにデータ転送量に応じた従量課金であれば、後述するCDNによるキャッシュでデータ転送量を削減しない限り、その料金は大変な金額になっていたと思われます（今回、さくらインターネットのサポートもいろいろ細かく質問などに対応していただいたことも付け加えておきます）。

Cloudflareの「I'm Under Attack」モードをオンに

このサーバに対してCDNとしてCloudflareを採用し。Cloudflare上でDDoS対策として次のような設定を行いました。

1つはセキュリティの設定で「I'm Under Attack」モードをオンにしました。これにより、人間が操作するWebブラウザ以外のアクセスを防いでくれます。

「ボットファイトモード」もオンに

さらに、ボットを用いた自動化されたトラフィックも防ぐために「ボットファイトモード」もオンにしました。

Cloudflareによるキャッシュも設定

これでもDDoS攻撃下では大量のトラフィックがWebサーバに襲いかかってくるため、それをサーバに到達する前にCloudflareのCDNが備えるキャッシュで返してもらえるように、Webサイト全体のキャッシュを設定します。

この構成で、下記のような1時間あたり4000万リクエストから最大で6000万リクエストを超えるDDoS攻撃を受けているあいだも、問題なく記事の閲覧やCMSを用いた記事の更新などが可能でした。

グラフから、リクエストのほとんどがキャッシュとしてCDNで処理されており、サーバへのリクエストがほとんどないことが見て取れます。

3度目のDDoS攻撃を受けるが、問題なく記事の閲覧やCMSを用いた記事の更新などが可能だった

例えば上記のグラフにあるDDoS攻撃下の3月25日にPublickeyは「プログラミング支援AIサービスまとめ。GitHub Copilot、AWS CodeWhispererなど11種類（2024年3月版）」という記事を公開しました。

この記事は「はてなブックマーク」で200を超えるブックマークをしてもらえたほどの人気記事になっています。

これを読んだPublickeyの読者が、このときPublickeyがDDoS攻撃下にあったと気づくことはほとんどなかったはずです。

DDoS対策をしつつ設定を改善

とはいえ、上記の設定はとにかく急いでDDoS対策を行うための設定であったため、いくつかの副作用がありました。その後、そうした副作用を緩和する目的でいくつかの改善を行いました。

国外のみ「I'm Under Attack」モードを有効に

1つ目の改善点は、国外からのアクセスにのみ「I'm Under Attack」モードを有効にした点です。

「I'm Under Attack」モードを有効にすると、すべてのWebページに自動的にJavaScriptが挿入されて、アクセス元が人間が操作するWebブラウザかどうかが何らかのアルゴリズムで判別されます。通常はこの処理はわずか1秒以下なのですが、それでもユーザビリティが損なわれることになります。

一方でCloudflareのログをみると、DDoS攻撃のほとんどが日本国外、特に米国から行われていることが分かりました。

そこでCloudflareの設定により、日本国外からのトラフィックにのみ「I'm Under Attack」モードを有効にしました。

これで日本国内にいる読者からは、ふだんと同じように快適にPublickeyにアクセスできるようになり、一方で国外から押し寄せるDDoS攻撃によるトラフィックは「I'm Under Attack」モードにより現地のCloudflareのエッジで大半がせき止められることが期待されます。

FacebookやX/Twitterからのアクセスを通すように

次に、「I'm Under Attack」モードのせいでFacebookやX/Twitter、LinkedInなどで記事を共有したときにOGPで設定したアイキャッチ用の画像が表示されない、という問題にも対応しました。

「I'm Under Attack」モードでは（人間がWebブラウザを操作してアクセスする以外のすべての）機械的なアクセスが全部ブロックされてしまうため、これらソーシャルメディアによるOGP画像へのアクセスもブロックされてしまうのです。また、FeedlyのようなRSSリーダーによるRSSファイルへのアクセスもブロックされてしまいます。

この問題を解決するために、Facebook、Twitter、LinkedInのIPアドレス（AS番号）を調べて、そこからアクセスされた場合と、（Feedlyはアクセス元のIPアドレスが固定されていないと説明されていたため）Feedlyのユーザーエージェントからのアクセスには「I'm Under Attack」モードを適用しないようにしました。

また、RSSの情報を提供している「/atom.xml」へのアクセスも「I'm Under Attack」モードから除外しました。

下記がその設定画面です（分かりやすいように余計な部分をトリミングしているので、実際の設定画面とはやや異なります）。

こうした設定改善によって、おおむね大きな問題はなくなりましたが、それでも海外から本来の読者がPublickeyにアクセスしようとすれば、人間がアクセスしているかどうかの確認画面が一瞬表示されるため、少し不便に感じるであろうことと、Google botからのアクセスや、おそらくどこかの社内で使われているであろうグループウェアや情報収集ツールなどからのRSSや記事へのアクセスなど、さまざまな外部からの機械的なアクセスが全部ブロックされることで不便をかけてしまう、といった細かな副作用は残念ながら残りました。

しかしさすがにこれら全部に対応することは難しかったため、上記の設定で妥協することにしました。

Cloudflareはこれらの機能が無料で利用できる

そして特筆すべきは、ここで紹介したCloudflareの機能は全てFreeプランで提供されていると言うことです。

全く費用を要求せずに、ここまで有効なDDoS対策を提供してくれるCloudflareのサービスは、実に素晴らしいものだと言わざるを得ません。

現在ではセキュリティモードはすべて解除

こうしたサーバ構成とCloudflareの設定により、PubilckeyはDDoS攻撃を受けても支障なく運用できる環境を作り上げることができました。

ただし、前述のように「I'm Under Attack」モードには副作用も伴うため常用はできません。3月27日を最後にDDoS攻撃は止んでいるため、現在では「I'm Under Attack」モードはすべて解除し、キャッシュのみ有効にしています。できれば今後も「I'm Under Attack」モードを使う機会がなければよいのにと思います。

さて、今回のDDoS攻撃に関連してPublickeyに対してなにかメッセージ、例えば攻撃を止める代わりにお金を出せとか、そういった連絡が来ることはまったくありませんでした。単純に運悪く通り魔的なDDoS攻撃の標的になり、ある日その攻撃の標的は別のところに移っていったのだ、と理解しています。

その意味で、DDoS攻撃はどのWebサイトにも起こりうる問題でしょう。ここで紹介した内容が、今後運悪くDDoS攻撃に遭遇してしまったWebサイトの参考になれば幸いです。

（2024/4/5 11時50分、さくらインターネットのデータ転送量が無料であったことを追記しました）