個人開発(1人システム)担当者がサイバー攻撃に備える7つの心がけ

先日、私がワードプレスで運営しているサイトでサイバー攻撃を受けました。
サイトのいくつかのファイルが改ざんされ、管理系ページにアクセスできない状態に陥りました。
その後、なんとか復旧できたものの、インシデント対応中は生きた心地がせず、手の震えと動悸が凄まじかったです。
今回サイバー攻撃による障害の経験から学んだ、サイバー攻撃に備える7つの心構えを説明します。

**※本記事は個人開発でサービスを運営している方や、1人でシステム担当を行っている人を対象にした記事です。**

# いきなりサイトアクセスが403エラー
私は個人でレンタルサーバーを借りてワードプレスで構築したサイトをいくつか運営しています。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/365005/5c992b45-cec0-2166-b324-4b986284b82c.png)
その中のうち、ある特化ジャンルの情報を発信しているサイトの管理画面にアクセスした時、異変が起きました。

**403エラーです。**
![qiita20220714.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/365005/08061265-7ee8-e253-1c97-9e8f2355dd3e.jpeg)
はじめはレンタルサーバー側のトラブルを疑いました。

しかし、ユーザー向けの記事ページは正常なのに対し、管理ページのみがNGとなっていました。

それから30分ほど様子見したものの、一向に403エラーが解消しない事実に、とある結論にたどり着きました。

**「サイバー攻撃を受けた・・・」**

ここから、サイバー攻撃を受けた経験から学んだ、必要な心がけを紹介していきます。

# サイバー攻撃の精神ダメージは甚大

サイバー攻撃を受けた時の精神ダメージは凄まじいです。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/365005/258f1e86-05a1-6080-f02f-5fda51bfc9bb.png)
私も最初に気づいた時に心拍数が確実に10は上がりましたし、サイバー攻撃を受けたと判断する間は鼓動の音が聞こえるほどでした。

**吐き気もすごかったというか、むしろ1回吐きました。**

自分の人生でこんな気持ちになったのは中学でカツアゲに遭った時以来です。

サイバー攻撃を受けたことで、**20年前のカツアゲされたシーンがフラッシュバックする人間の脳ってすごいな** と思いました。

全然技術的な話ではありませんが、精神に甚大なダメージを受けるとおぼえておいてください。

# 個人開発、1人システム担当は対応するのは自分だけ

前述のサイバー攻撃を受けたことに対する精神ダメージは、チームであれば、みんなで負担することができます。

現場エンジニアは、サイバー攻撃への対応は必要ですが、作業分担もできますし、責任はマネージャーが取ってくれます。

しかし、個人開発(運営)のサービスや、企業でも1人でシステム担当している場合、**負担を分かち合える仲間は0**です。

サイバー攻撃を受けた衝撃に加え、インシデント対応も自分１人で抱え込まなければなりません。

さらに1人システム担当の場合、「なんで攻撃を受ける脆弱性があったんだ！」と同じ会社のメンバーからも非難を受けるおそれもあります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/365005/8ca80faf-b613-bde3-1082-83afd96d2bc2.png)
そうすると、サイバー攻撃とメンバー非難のダブルパンチ。

**「もうやめて、○○のライフはゼロよ」** に陥るおそれもあります。

なので、システム担当が1人の会社の方は、システム担当を責めないであげてください。


# まずサイバー攻撃の事象を冷静に把握する

サイバー攻撃を受けたサイトを放置しておけば、どんどん事態は悪化します。

下手をすると、多くのユーザーに悪影響を及ぼしかねないため、対処をスタートせねばなりません。

ただ、闇雲に対応を行ってもいけません。

まずはサイバー攻撃によって、サイトがどういう状態なのか把握する必要があります。

前述した通り、サイバー攻撃を受けたことで精神的に大きなダメージを受けている中、冷静に攻撃された箇所を調査するのは大変です。

しかし、個人開発or1人システムの場合、主体的にインシデント対応に取り組まなければなりません。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/365005/ab66ab90-1441-617e-6cf1-d4053787e91f.png)
もちろん全てを自分ひとりでやる必要はないので、費用はかかりますが、サイバーセキュリティ対応の専門家に依頼することも検討しましょう。

そこそこの金額にはなりますが、作業負担を大きく軽減できます。

ちなみに私のサイトのサイバー攻撃を受けた状況は以下の通りでした。

* htaccessファイルの改ざん
* index.phpの改ざん
* 見慣れぬphpファイルが配置
* 謎のphpプログラムがプロセス起動中


# 攻撃後の有効な対応はバックアップからのリストア

ファイルを改ざんされるサイバー攻撃に対し、元の状態に戻す上で有効な施策はバックアップデータからのリストアです。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/365005/192683db-60b8-d873-d53a-64bb03d9cbfb.png)
バックアップデータから攻撃を受ける前に戻すことができれば、改ざんされたファイルが元通りになるからです。

今回の事例では私は毎日、管理画面系のページにアクセスしていたので、かなりすぐに異変に気づくことができました。
異変が起きる前のバックアップデータから戻せば、そこまでに更新したデータはなくなりますが、元通りにすることができます。

ただ、サイバー攻撃の状況として、**「謎のphpプログラムがプロセス起動中」** というものがありました。

このphpファイルが厄介で、改ざんされたファイルを書き換え・戻しを行っても、改ざん状態に瞬時に元通りになってしまいます。

この攻撃については[ワードプレスドクターさんの解説記事](https://wp-doctor.jp/blog/2021/07/28/%E3%83%AF%E3%83%BC%E3%83%89%E3%83%97%E3%83%AC%E3%82%B9%E3%81%A7%E4%B8%80%E7%9E%AC%E3%81%A7%E5%86%8D%E5%BA%A6%E6%94%B9%E3%81%96%E3%82%93%E3%81%95%E3%82%8C%E3%82%8Bhtaccess%E3%83%95%E3%82%A1%E3%82%A4/)で紹介されています。

そこで、SSHでサーバーにアクセスし、問題となっているプロセスIDを調べてKillすることで、改ざんファイルへの書き換えを停止しました。

その上で攻撃を受ける前のバックアップデータからリストアすることで復旧することができました。
レンタルサーバーの機能として、自動バックアップがあったことに感謝せずにはいられませんでした。

# システムの攻撃ポイント(侵入口を把握)しておく

サイバー攻撃を受けてしまった人間からいうのもアレですが、システムの攻撃ポイントを把握しておくことは再発防止に加え、予防する上で重要です。

侵入口を理解しておけば、それぞれに必要なセキュリティ対策を施すことができます。

**「侵入ポイントなんて全て把握しているよ」** というエンジニアも多いと思います。

ただ、個人が運営しているレンタルサーバーでも下記のように攻撃ポイントが多数あります。

* レンタルサーバーの管理画面
* サーバー領域へのFTPアカウント
* SSH接続アカウント
* ワードプレスの管理アカウント
* ワードプレスのDBのアカウント
* ワードプレスのバージョンが古い
* ワードプレスのテーマが更新されていない
* ワードプレスのプラグイン脆弱性

サーバー周りのファイルに更新ができるアカウントや機能が狙われるポイントです。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/365005/d76ea7cc-85ca-1e8d-8524-f5f6abd58c3b.png)
個人開発やスクラッチ開発していると、ネットで調べるという手段も取りづらいので、しっかりシステム構成を理解しましょう。

# ソフトアップデート、パスワード変更・2要素認証など対策

上記の攻撃ポイントとなる箇所を洗い出した上で、対策を行いました。

まずはワードプレスやテーマ、プラグインについては古いバージョンを使用しているものもあったので、すべてアップデートしました。

その上で、自動更新を有効にしてプラグインやワードプレスが古いバージョンのままで脆弱性がある状態が続かないように仕組み化しました。

さらに、攻撃ポイントとして多いのがアカウント周りです。

アカウントを乗っ取られてしまえば、基本的にファイルの更新やアップロードが狙われてしまいます。

まずアカウントの整理ということで通常使用しないFTPアカウントとSSHアカウントは削除しました。

必要になる場合は、都度レンタルサーバーの管理画面で一時作成し、使用後に削除する運用にしました。

ワードプレスの管理アカウントやDBアカウントも変更しました。

**ワードプレスのログイン画面もデフォルトの「wp-admin」から変更しました。**

これ自体は時間をかければ特定はされるものの、それでもwp-adminよりも入口の発見に時間がかかります。

世の中のワードプレスサイトの多くはデフォルトのwp-adminのまま運営されているサイトも多いです。

その中でログインURLを変更しておくことで、デフォルトのままよりも狙われにくいという効果が得られます。

最も守るべきアカウントは、権限が強いレンタルサーバーの管理アカウントです。

これについてはログイン時に2要素認証を求めるようにしました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/365005/2095de0b-b915-78fe-ea69-8061bcf7fd92.png)
SMS認証などの2要素認証はアカウント攻撃に有効です。

**「二要素認証とか面倒だし」** という人もいるかもしれませんが、一度サイバー攻撃を受けると、利便性よりも優先すべきは安全性であることを痛感させられます。

サーバー周りで利用するアカウントは、できるだけ2要素認証をかけておくようにしましょう。


# 毎日の定期巡回(死活監視)が重要

今回のサイバー攻撃もサイトを完全に破壊されずに済んだのは攻撃を受けたあとすぐに気づくことができたのが大きいです。

改ざんされたファイル内容から、恐らくプラグインなどの脆弱性が狙われた可能性が高いです。

403エラーが出たのは夕方でしたが、午前中にサイトの管理画面にアクセスし、正常であることを確認できていました。

そのため、まだ攻撃が拡大しておらず、比較的早期に対応できました。

もしこれが1週間近く経過してれば、より攻撃は拡大していましたし、2週間経過すると、バックアップからの戻しもできませんでした。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/365005/8ce88b32-9fb3-736e-4e02-8761b003795a.png)
サイバー攻撃を受けないようにすることに加え、万が一受けた時にすぐ検知できるように、一定頻度での巡回監視はとても大切です。

# バックアップ超大事！！(大事なので2回目言いました)

今回は、バックアップを取得していたから元通りに復旧できました。

もしバックアップがなければ、サイト自体の閉鎖も視野に入れねばなりませんでした。

バックアップは有事に備えたもののため軽視されがちですが、事故が起きた際には必要不可欠です。

サイバー攻撃を受けたあと急いでバックアップを取得しても意味はありません。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/365005/599c0578-1506-1d18-b2b5-704117c8710c.png)
災害対策における防災と考え方は同じで、「平時にどれだけ備えをしておくか」がいざという時に重要です。

定期的にバックアップを取得する運用を行うか、自動バックアップを設定しておきましょう。

# 終わりに

今回、サイバー攻撃を受けた経験から、個人開発や1人システム担当者に向けた備えておくべき7つの心がけを紹介しました。

サイバー攻撃への対策やバックアップの重要性など書きましたが、**最も伝えたいのは、１番目の「精神的ダメージが凄まじい」です。**

組織やチームであれば、仲間や上司がいるので、負担を分かち合うことができます。

しかし、個人開発(運営)や1人システム担当の場合、自分ひとりで向き合う必要があり、半端ないストレスに襲われます。

この精神的ダメージを受けないように、自分のサイト・システムを守れるよう、しっかりセキュリティ対策を施しましょう。

また、**精神的ダメージが来ることということを覚えておくと、ストレスに押しつぶされずにインシデント対応できます。**

個人の開発者・担当者はこの記事の存在を頭の片隅に覚えておいてもらえると幸いです。