続、Publickeyが受けたDoS攻撃、これまでの経緯と対策まとめ

今回は「続、Publickeyが受けたDoS攻撃、これまでの経緯と対策まとめ」についてご紹介します。

関連ワード （大量、表記、赤線等） についても参考にしながら、ぜひ本記事について議論していってくださいね。

本記事は、Publickey様で掲載されている内容を参考にしておりますので、より詳しく内容を知りたい方は、ページ下の元記事リンクより参照ください。

先週の火曜日、3月12日に始まったPublickeyへのDDoS攻撃は今週日曜日、3月18日日曜日の早朝を最後に収まったようです。この記事執筆時点でPublickeyのサーバは平常に戻っています。

この間、読者や広告を掲載いただいているお客様や代理店様にご不便やご心配をおかけし申し訳ありませんでした。

DoS攻撃とは、大量のトラフィックをWebサーバなどに浴びせることでサーバを応答不能にしてしまう攻撃のことです。

前回の報告「Publickeyが受けたDoS攻撃、これまでの経緯と対策まとめ」の後、さらにいくつか対策を講じましたので、この記事では前回の報告移行の経緯と講じた対策を記したいと思います。

また、前回の報告では「DoS攻撃」と書きましたが、その後Publickeyのサーバをホスティングしているさくらインターネットのサポート担当の方から、今回の攻撃は分散した箇所から攻撃を受けているとの報告をいただきましたので、この記事では明示的に分散した箇所からの攻撃を示す「DDoS攻撃」と記したいと思います。

前回の報告のまとめ

まずは前回の「Publickeyが受けたDoS攻撃、これまでの経緯と対策まとめ」で書いた3月12日から14日までの状況を手短に紹介します。

2024年3月12日の午前11時40分頃、Publickeyのサーバが反応しなくなったことに気づき、ホストしているさくらインターネットからDoS攻撃があった旨の報告がメールで送られてきました（メールでは「DoS攻撃」と表記されていたので、ここではそれを踏襲してDoS攻撃と書いています）。

攻撃はその後、断続的に続きました。

対応策として、さくらインターネットが提供しているCDNサービスの「ウェブアクセラレータ」やファイアウォール機能を導入してみましたが残念ながら十分な防御にはならず、その後もサーバは断続的にダウンしてしまいました。

3月14日には、DDoS対策サービスとして定評のあるCDNであるCloudflare無料版を導入したものの、3月15日の午前3時にはDDoS攻撃を受けてサーバがダウン。

これはPublickeyサーバへの攻撃がCloudflareを経由せず、IPアドレスを直接指定して行われたのが理由でした。そこで次の対策として、Cloudflareを導入したままでPublickeyサーバのIPアドレスを変更することにしました。

前回の報告はここまででした。以下では、それ以後の経緯と対策についてまとめます。

IPアドレス変更のためサーバを移行

Publickeyはさくらのレンタルサーバを利用しています。サーバのIPアドレスを変更するには新規のサーバを借りてそこへ移行する作業が必要です。

3月15日金曜日の夜に新規サーバを借りて移行作業を行いました。

具体的には、元サーバのファイルをtarコマンドで圧縮して新規サーバへコピーして展開します。PublickeyはCMSにMovable Typeを使っているので、元サーバでCMSのデータを格納しているMySQLデータベースをエクスポートし、新サーバのMySQLへインポート。CMSの設定をいくつか調整しました。

次にドメイン名を元サーバから新サーバへ付け替えますが、このときに新サーバのIPアドレスがインターネットへ漏れないように、Cloudflare側で設定するIPアドレスを先に新サーバへ変更したあとで、ドメイン名を新サーバへ付け替えました。

この作業でいちばん大変だったのは、DDoS攻撃で何度も元サーバがダウンするため、その合間を縫ってデータの取り出しをしなければならなかった点です。落ち着いて作業しようと思っても緊張で手が震えて、何度も打ち間違いをしました。

新サーバへ移行できたことで、IPアドレスを指定したDDoS攻撃は避けることができました。もしもDDoS攻撃の標的がIPアドレスの指定によるものであれば、これで対策は終わりです。

新サーバへ移行後もDDoS攻撃を受けてサーバダウン

明けて3月16日土曜日。DDoS攻撃は続き、新サーバへの移行後もサーバは何度もダウンしました。IPアドレスを変えても攻撃を受けたということは、大変残念なことにこの攻撃がPublickeyのドメイン名「publickey1.jp」を狙っていることは明らかでした。

新サーバはつねにCloudflareを経由してアクセスすることになるため、サーバがダウンすると、Cloudflareから次のようなエラー画面が表示されるようになります。

Cloudflareのコンソール画面では、Publickeyのサーバに対してどこからトラフィックが来ているのかを地図で見ることができます。下記がこのときのトラフィックの分布で、圧倒的にアメリカが多く、ブラジル、ポーランドなどからもトラフィックが来ていることが示されていました。

日本語のWebサイトであるPublickeyは、ふだんはほぼ100％が国内からのアクセスです。これだけ海外からトラフィックが来ることは明らかにおかしい状況でした。

セキュリティレベルを「I’m Under Attack!」モードに設定

Cloudflareを触るのは初めてだったため、次はCloudflareの設定でDDoS攻撃を防ぐ方法について模索しました（土曜日に入ってしまったことで外部に問い合わせるのを控えざるを得ず、まずは自力で模索することにしました）。

セキュリティの設定の中に、「I’m Under Attack」という項目がありました（画面の赤線は分かりやすいように筆者が引いたもの）。これを設定するとWebブラウザを人間が適正に操作しているかどうかを判断するスクリプトが自動的に配信されるようになり、悪意のあるトラフィックを極力防いでくれるというものです。

セキュリティレベルをこの「I’m Under Attack!」に設定し、さらに、自動化されたトラフィックを特定して軽減してくれるという「ボットファイトモード」もオンにしました。

このときのDDoS攻撃では、下記のグラフの左側の山（3月17日土曜日15時）が示すように1時間あたり最大で5000万リクエストがやってきました。攻撃は午後7時頃にいったん止んだものの、22時には再び1時間当たり4900万リクエスト、つまり1秒間に1万リクエスト以上のトラフィックが押し寄せました。

より強力なサーバへと再び移行作業

Cloudflareのセキュリティレベルを「I’m Under Attack!」に設定し、ボットファイトモードをオンにしたあと、Publickeyサーバの状況には多少の変化がありました。

Webブラウザからアクセスすると前述のCloudflareのエラー画面だけでなく、しばしば「503 Services Temporarily unavailable」エラーが表示されるようになったのです。これはサーバがダウンしておらず、混雑しているので返事が出来ないという状況を示しています。

Cloudflareの設定が功を奏して、Publickeyサーバへ到達するDDoS攻撃のトラフィックが減ったのだと考えられます。

これならサーバを強力にすればトラフィックに耐えられるようになるのではないかと考え、さくらインターネットの8コア16GBの仮想マシンを占有するマネージドサーバを申し込み、再び移行作業を行いました。

このとき、17日日曜日の午後から深夜にかけて今回のDDoS攻撃でおそらく最大の、1時間当たり8000万回のリクエストが相次いでやってきていました。

マネージドサーバへ移行後、この8000万回のピーク時にPublickeyのWebサイトをWebブラウザで表示させようとすると、5回に3回はCloudflareからエラーが返ってくる程度の反応となり、長時間サーバがダウンするようなことはなくなりました。

ピーク時にこの状態であれば、少なくとも最低限の対策レベルとして妥協できないこともない、という感触でした。

そこでできればもう一段階さらに踏み込んだ対策をしたいと考えました。

X/Twitterやはてなブックマークのコメントで、CloudflareにHTMLをキャッシュしてもらえれば、さらにPublickeyサーバの負担が減るはずという指摘をいただいて、まさにそれだと思いました。

しかし設定方法が分かりません。そこで、月曜日の朝に起きてから知り合いを頼ることにしました。

幸いなことに何人かの方からご連絡をいただいていたのですが、Movable Typeの開発元であるシックスアパートの平田さんがCloudflareの設定についてもいつでも聞いてくれていいとのことだったので、お言葉に甘えて相談することにしました。

（ご心配いただいた皆様、連絡いただいた皆様、ありがとうございます）

Cloudflareのキャッシュを有効にした

さっそく設定していただいたCloudflareのキャッシュ機能が以下です。赤線がそれで、www.publickey1.jp以下は全てをキャッシュする、というもの。

その上にある2つの設定は、その後になって私が追加した設定で、変更の多いトップページと、書き直した記事を確認するプレビュー時のキャッシュを外しています。

これでCloudflareのCDNのキャッシュが十分に効くようになり、Publickeサーバへの負担が減ったことでDDoS攻撃にさらに耐えられるようになると考えられました（それにしても無料でこれらの機能を提供しているCloudflareは率直にすごいと思いました）。

しかし18日月曜日午前1時のピークを最後にDDoS攻撃は止みました。記事執筆時点（3月20日午後10時）までDDoS攻撃らしきものはきていません。

というわけで、キャッシュがDDoS攻撃にどれだけ効果的かを実際に試すことはできませんでしたが、平常時であってもPubickeyの表示を高速化する効果は認められるため、この設定は維持しています。

セキュリティ設定の「I’m Under Attack」とボットファイトモードは、徐々にオフにしていくつもりです。

またいつも通りの体制に戻ります

こうして3月12日火曜日から3月18日月曜日にかけて続けてきた、DDoS攻撃への対応と対策がひと区切りとなりました。

もしもまたDDoS攻撃が行われたとしても、すぐに対応できる状態にはなっているはずです。

正直なところ、火曜日から続くDDoS攻撃のあいだずっと、緊張の中で対策を考えて作業をし、サーバがダウンするたびに落ち込みつつ、それでも記事も書かなくてはいけなかったので、精神的にも肉体的にもかなり消耗しました。最後の攻撃が止んで3日程度が経過した今、やっと少しずつ緊張が緩んできたところです。

DDoS攻撃はいつ、どのWebサイトにも起こりうる攻撃です。この記事が、そうした状況に遭遇した方の参考になればと思います。

またいつも通り、毎日記事をお届けする体制に戻ります。今後ともご愛読のほど、よろしくおねがいします。