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

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

関連ワード （大変心強、正常、絶望的等） についても参考にしながら、ぜひ本記事について議論していってくださいね。

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

Publickeyのサーバは3月12日から14日にかけて何度もDoS攻撃を受けてダウンしていました。

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

ひとまず現在までの状況と対応について報告したいと思います。

先に現状のみを報告すると、CloudflareのDDoS対策サービスを導入していまのところ平穏な状況を保っているため、このまま様子をみているところです。

DoS攻撃の発生時間帯

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

下図が3月12日から14日にかけてPublickeyのサーバに対して行われたDoS攻撃の主な発生時間帯です。

グラフはPublickeyのページビューの推移を示しており、横向きの矢印が主なDoS攻撃の発生時間帯を示しています。発生時間帯ではページビューが失われていることがお分かりいただけると思います。

最初にDoS攻撃があったのは12日の午前11時40分頃からでした。いきなりサーバからの反応がなくなったことに気づき、ホストしているさくらインターネットからDoS攻撃があった旨の報告がメールで送られてきました。ダウン後、さくらインターネットの作業によるサーバの復帰が15時半頃。その後も夜から早朝に書けて断続的に攻撃が続きました。

13日の日中は収まっていたものの、13日深夜から14日の早朝に書けて攻撃が再開され、14日の日中にも攻撃がありました。

DoS攻撃を受けるとサーバは反応しなくなってしまうため、下図のようにエラーを返すことになります。

当然、読者がPublickeyの記事を見ることは出来なくなりますし、この状態ではサーバの管理画面にも入れないため、ブログ記事の更新などもできないという大変困った状況でした。

Publickeyのサーバは、さくらインターネットのレンタルサーバを利用しています。上記のようにサーバが落ちてしまうと、さくらインターネット側で復旧作業により立ち上げ直してもらうことになります。

レンタルサーバのユーザーとしては、さくらインターネット側で復旧対応してくれるのを待つしかない、という状況でした（チャット経由でのサポートには何度か相談もしました）。

さくらインターネットのDoS対策

もちろん、さくらインターネットは大規模なデータセンター事業者として、Publickeyのサーバに限らず、常にどこかのサーバがDoS攻撃を受けている状態であると考えられるため、同社自身もDoS攻撃対策を行っています。

2024年2月に同社「さくらのナレッジ」で公開された記事「さくらのバックボーンネットワーク動向2024」によると、自社で開発した対策システムにより、DoS攻撃を検知するとネットワークの操作が自動的に行われて攻撃を緩和するシステムが同社バックボーンにて稼働しているようです。

しかし理由は不明ながら少なくとも今回のPublickeyサーバへのDoS対策としては十分に機能していなかったようです。

また、Publickeyのレンタルサーバでは以前から不正アクセス防止のため、さくらのレンタルサーバに備わっている、国外からのアクセスを受け付けない設定をオンにしていました。

そのため今回のDoS攻撃は国内からのものではないかと推察されます。

（追記：この機能は私の勘違いのようですので取り消します。すいません）

CDNもWAFも、あまり効果を感じられず

さて、12日の昼の最初のDoS攻撃がおさまったあとで、レンタルサーバのユーザーとしてできる対策として、さくらのレンタルサーバに標準で提供されているCDNサービス「ウェブアクセラレータ」を有効にしてみることにしました。

CDNによってDoS攻撃の大量のトラフィックをさばくことが出来れば、サーバが落ちることを防止できることを期待しました。

設定後のウェブアクセラレータの効果を定量的に示すことは出来ないのですが、有効にした後のDoS攻撃の状況では、ときどきPublickeyのサーバと接続できる瞬間がありつつも、多くの場合には下記のエラーなどが表示され、十分な防御策とはなり得なかったと感じます。

ウェブアクセラレータの300GBの無料枠があったのですが、一晩たたずにあっという間に大幅に超過した1.49TBとなってしまいましたので、コスト面を考慮してもCDNは有効ではないと感じました（すべてのCDNが有効ではないというつもりはありません。今回利用したCDNは有効ではなさそうだという意味です）。

このときのサーバのログを見ると、異常なピークが発生しているのが分かります。

またこの後に、さくらのレンタルサーバに搭載されているWAF（Web Application Firewall）機能も有効にしてみましたが、DoS攻撃でサーバが落ちてしまい、防御効果は感じられませんでした。

CloudflareのDoS対策サービスを導入

13日の日中はDoS攻撃がなく平穏に作業できていたためDoS攻撃は去ったと思っていましたが、13日の夜から再びDoS攻撃が再開。

サーバがダウンして夜の記事更新ができず、ただサーバの復帰を待つだけの絶望的な気持ちで眠りにつき、翌朝8時に確認してみると早朝にサーバ復旧の連絡がさくらインターネットから来ていました。さっそく記事を更新しました。

この時点でレンタルサーバ側での対策はもうないと考え、そこから外部のサービスの検討に移ります。

第一候補はCloudflareでした。CloudflareはDDoS対策に定評があると聞いたことがあり、しかも無料でDDoS対策サービスを提供していました。

Cloudflareの設定方法を調べ、昼少し前に設定を行いました。

具体的にはCloudflareのダッシュボード画面でPublickeyサーバのDNSの設定などを読み取ってもらうと、さくらのレンタルサーバ側のDNSで設定すべき項目が表示されるため、それをさくらのレンタルサーバ側のDNSに手作業で反映する、という手順です。

設定自体はそれほど難しくなく行うことが出来ました。

しかし設定後しばらくすると、Google ChromeでPublickeyを見ようとしても「リダイレクトが多すぎる」といったエラーが出て表示に失敗してしまいます。Microsoft Edgeでは発生しないエラーでした。

X/Twitterでアドバイスもいただき、設定を色々見直したところ「.htaccess」ファイルの中にhttpsへのリダイレクト設定が書き込まれており、これを削除したところエラーが解消されたため、おそらくこれが原因だったのだと考えます。

DNS周りの設定は、設定を変えてもそれが反映されるまでに時間がかかるため、設定変更が正しいのか間違っていたのかが判断しにくいところが非常に難しいですね。

CloudflareやDNSの設定と格闘し、なんとか無事に動くようになった頃にCloudflareのログを見てみると、どうやら設定直後にもDoS攻撃があったようでした。

この時間帯はまだ導入直後で設定をあれこれ悩んでいるところだったため、PublickeyのWebサイトがちゃんと反応できていたかどうかは分からないのですが、少なくともサーバが落ちてはいないため、Cloudflareの導入は一定の効果があるのではないかと考えています。

ログを見る限り、それ以後DoS攻撃は行われていないようです。

原稿執筆時点でPublickeyのサーバは正常に稼働し、Webサイトも問題なく閲覧できているため、しばらくこの構成で様子を見るつもりです。

今回の教訓とまとめ

Publickeyを開始して15年で初めて、DoS攻撃を受けました。Publickeyのサーバが狙われた理由は不明ですが、この間でいろいろ調べた範囲内では、DoS攻撃はどこにでも起こりうるもので、たまたま今回はPublickeyのサーバだったのだと考えています。

DoS対策として有効ではないかと期待したウェブアクセラレータやWAFは十分ではなかったことも分かりました。DoS対策が明示的に含まれていないサービスでは十分なDoS対策は期待できない、それほどDoS攻撃は厳しいものである、ということなのでしょう。

そしてCloudflareのDoS対策はおそらく有効であるだろうことも、短時間ですが感じました。

今回の報告では、さくらインターネットのサービスにネガティブなことばかり書いてしまいましたが、この15年で同社のサーバが障害を起こしたことは一度もなく、現在でも信頼できるレンタルサーバとして継続して同社のサービスを使い続ける予定であることを付記しておきます。

あらためて、読者や広告を掲載いただいているお客様や代理店様にご不便やご心配をおかけし申し訳ありませんでした。また、サポートやアドバイスなどのご連絡をいただいたみなさま、ありがとうございました。大変心強かったです。

状況に変化がありましたら、また報告したいと思います。

（2024年3月15日8:24 追記）

Cloudflareを設定したこの記事公開後の3月15日午前3時頃にもDoS攻撃があり、やはりサーバが一時ダウンしてしまったようです。

おそらく攻撃側はIPアドレスを直接指定しており、そのためCloudflareをバイパスしてPublickeyサーバが攻撃を受けたのではないかと思われます。ひとまずPublickeyサーバが落ちてもCloudflareのキャッシュを表示するようにCloudflare側を設定して対応し、PublickeyサーバのIPアドレス変更を検討したいと思っています。