本当にやるべき6つのWordPressセキュリティ対策
「実はやらなくてもいい6つのセキュリティ対策」に関しては、以下で解説しました。
- 「やらなくていい」設定
- 「やった方がいいけど、別にやらなくてもいい」設定
- 「やるべき」設定
この記事では下線の項目の解説をします。
総合セキュリティ系プラグイン
この記事では「総合セキュリティ系プラグイン」という文言を使用しますが、主に以下のことです。
あと「SiteGuard WP Plugin」とか有名ですね。
何でもいいのでどれか1つをインストールしておきましょう。
※複数を同時に使うのはやめてください。アンチウイルスソフトと同じで基本的に共存はできません
ちなみにXO Securityは作者が日本人で初心者でも扱いやすいのでおすすめです。
多要素認証の設定
推奨レベル: ★★★★★
効果がとても高いので真っ先に紹介します。
多要素認証とは
以下のうち、複数を組み合わせた認証のことです。
本人だけが知っている情報で認証します。
- ID
- パスワード
- 暗証番号
- 秘密の質問
「記憶要素は推測して突破される」「所有要素はものが盗まれると突破される」など異なる弱点があります。
複数の要素を組み合わせることでより確実に認証するという理屈の認証です。
その有効性は、Googleが推し進めていることが証左です。
経済産業省傘下のIPAも多要素認証を推奨しています。
2要素認証の設定方法
「記憶要素」と「所有要素」はプラグインがあればWordPressに導入できます。
2要素認証を設定できるプラグインは色々ありますが、「Two-Factor」をおすすめします。
インストール後、[ユーザー]から自分のユーザーのプロフィールページに飛ぶとページの一番下の方に「Two-Factor 設定」という項目が追加されます。
メール認証かTOTPを選ぶと、ログイン時に番号の入力を要求されるようになります。TOTPがおすすめです。
番号はスマートフォンなどの端末で発行し、それを入力することでログインできるようになります。
なお、番号は一時的にしか使えません。使い捨てのワンタイムパスワードです。
WordPress本体にも導入予定？
2022年1月時点で、WordPressのFeature Projectsに2FA (2要素認証)が載っています。
先ほど紹介したTwo-FactorはWordPressの半公式プラグインです。上記ページでもリンクされています。
このFeature Projectsは上手くいけば本体に取り込まれるかも、というものなのでそのうちWordPress本体にTwo-Factorが実装される可能性があります。
2要素認証のデメリット
私はスマートフォンにAuthyというアプリを入れて認証しています。
こういう使い方をしていると1点だけ注意が必要です。
スマートフォンがないと認証できないという点です。
当たり前なんですが意識からは外れがちで、出先にスマートフォンを忘れたとか、紛失したとか、予期せず壊れてしまったとかでも認証できなくなるということです。
こういった出来事を防ぐため、復旧用のコード（バックアップコード）を発行して保管することも必要になります。
もしくはメール認証でも認証できるようにしておくなど、代替の手段を用意しておきましょう。
こういったデメリットもあり、認証そのものも慣れるまでは面倒だと感じる2要素認証ですが、非常に強力なのでぜひ設定しておきましょう。
ちなみにAuthyにはデスクトップ用のアプリがあるので、それを使うのも手です。
スマホの紛失や故障リスクを重く見るなら入れておいた方がいいでしょう。
ただし「ログインする端末」と「認証用端末」は分けておいた方がセキュリティ的に強固だということは忘れないでください。理由は端末が盗まれたり乗っ取られたりすると悪用されるからです。
ログイン試行の制限
推奨レベル: ★★★★★
何回かログインに失敗したらアカウントをロックする、という一般的なセキュリティ対策です。
総当たり攻撃（ブルートフォースアタック）対策には欠かせません。
パスワードの総当たり解読
以下によれば、2019年時点でも1秒間に1000億個のパスワードを試せる環境が3000円以下で作れます。
対象がWordPressサーバーである場合、実際にはネットワークによる遅延などの関係で1秒間に1000億回も試行することはできませんが、こんなことされたらたまったものではありません。
非常識な回数は受け付けない
1000億回もログインを試す人間なんて現実的に存在しませんよね。
というか生きている間に達成できないのでは？
「何回かログインに失敗するとアカウントが一時的にロックされる」サイトを見たことがあるでしょう。
そういった制限は、このような総当たり攻撃を防ぐためにあります。
WordPressでも総合セキュリティ系プラグインを導入すれば設定可能です。
回数に正解は存在しませんが、5～10回失敗すると一時的にロックされるサイトが多いと思います。
自分で使う分でもそれくらいの閾値でOKです。
XML-RPCの制限
推奨レベル: ★★★★★
制限するべきと紹介されることが多い設定です。
既に制限している方には朗報です。制限したままにしてください。
なおXML-RPC自体はプロトコルであり、WordPressに関係なく使われますが、ここではWordPressの機能として扱います。
XML-RPCの用途
XML-RPCの主な用途は以下です。
- 外部からの認証
→スマホアプリ版WordPressからのログイン・投稿などに使用 - 他のWordPressからのピンバック通知
→ピンバック機能やトラックバック機能で使用
XML-RPC自体はWordPress 3.4から実装された機能です。古くからあります。
外部のWordPressのクライアントやサーバーと通信する手段の1つとして実装されました。
※REST APIに似ていますが、REST APIは4.7で実装されたためXML-RPCの方が先です
ピンバックとトラックバック
他人のWordPressの記事を自分のWordPressで引用した時、そのWordPressに対して通知する仕組みです。
通知されるとリンクが載るので、両方制限していなければ相互リンク的な意味合いがあります。
記事を投稿しました！
通知を受けました！
投稿した記事を自サイトに載せました！
踏み台としての悪用
2014年に「WordPressの脆弱性を利用したDDoS攻撃が発生している」と報じられました。
ピンバック/トラックバックの機能を通して、他のサイトにリクエストを送ることができる仕様を悪用したものでした。さらにWordPressのログには「ピンバックした人が誰なのか」が記録されなかったため、通信元を隠ぺいできることから、悪用しやすい踏み台として利用されてしまいました。
WordPress 3.7.2 (3.8.2)からIPアドレスが記録されるようになったので踏み台として利用するメリットはかなり減りましたが、その仕組み上、完全に防ぐことは難しいです。
もう1つの入り口
XML-RPCにはもう1つの制限するべき理由があります。
それはWordPressにおけるXML-RPCがもう1つのログインフォームであることです。
XML-RPCを使うとWordPressへのログインや記事の投稿などが行えます。
つまりWordPressには2つの入り口があって、片方がログインページ、もう片方がXML-RPCなのです。
※アプリケーションパスワード機能などを使えば別な入り口も作れますが、ここでは例外とします
引用元: https://www.jp-secure.com/siteguard_wp_plugin/howto/login_history/
その入り口は対策をすり抜けられる裏口
XML-RPC経由で不正ログインを試みる攻撃者は多いです。
なぜなら、以下のようなセキュリティ対策を無視してログインを試行できるからです。
- ログインページを隠す
- 多要素認証
- ログイン試行の制限
XML-RPC経由のログインには上記が適用されません。
一見セキュリティ対策をしていても、XML-RPCを制限していなければ無意味になります。
無効化で対策
前述の理由から、XML-RPCを無効化すると以下の効果を得られます。
- DDoS攻撃防止
- 不正ログイン防止
本来ならば便利で様々な用途に使われるものですが、悪用されやすいことが災いしました。
現在はREST APIで代替可能なものも多いため、ほとんどの場合は無効化しても問題ありません。
総合セキュリティ系プラグインならいずれも無効化可能なので設定しておきましょう。
ただし前述にも述べた、以下の機能を使いたい場合は無効化してはいけません。
- 外部からの認証
→スマホアプリ版WordPressからのログイン・投稿などに使用 - 他のWordPressからのピンバック通知
→ピンバック機能やトラックバック機能で使用
XML-RPCを無効化するのではなく制限に留める手段もあります。
WordfenceにはXML-RPCに2要素認証を掛ける機能があるため、XML-RPCを生かしておきたい方はWordfenceを使うといいでしょう。
バックアップの定期的な取得
推奨レベル: ★★★★☆
他と違い、事後的な対策なので重要度は下がりますが、大切なことなので紹介します。
セキュリティ対策におけるバックアップの役割
忘れがちですが、バックアップというのはセキュリティ対策の一部です。
- 改ざん被害に遭った
- サーバーが壊れてデータを失ってしまった
- 誤ってデータを削除してしまった
こういう時のために必要なのがバックアップです。
改ざん被害対策のためだけではありません。
要するに何かあった時のための復旧手段です。
セキュリティに100%は存在しません。
残念ながら、どれだけセキュリティを強化しても被害に遭う時は遭います。
バックアップ系プラグイン
バックアップ系プラグインは、有名なものだと以下があります。
いずれもWordPressのファイルやデータベースの中身をバックアップしてくれるものです。
どれを使っても構いませんので、どれか1つを入れておきましょう。
あえて言うならUpdraftPlusが無難です。
無料版でも自動でバックアップを取得できて復旧も簡単にできるからです。
バックアップはサーバー内部に置かない
よくサーバー内にバックアップを格納する方がいますが、以下の理由からおすすめできません。
- サイトが乗っ取られた場合にはバックアップごと消される可能性がある
- サーバーが故障などにより使用できなくなった場合には復旧できない
- サーバー内の容量を圧迫する（限界まで格納するとサーバーごと死にます）
自動バックアップ設定をしていると、実はよくあるのが3番目だと思います。
設定後に数年間放置していたらとんでもない容量になっていたパターンです。
バックアップが原因で不具合を起こす本末転倒な事案です。
上記の問題を避けるため、バックアップは外部に格納しましょう。
バックアップ系プラグインではDropboxなどをバックアップ先に指定できます。
また、自動でバックアップをする際はバックアップを保持する数に上限を設けましょう。
際限なしに格納すると容量を圧迫する問題から逃れられません。
パーミッションの適切な設定
推奨レベル: ★★★★☆
自分でWordPressをインストールする方に必要な設定です。
最初からWordPressがインストールされているサーバーや、レンタルサーバー側が用意している自動インストールなどを使用した場合は設定不要ですので飛ばしてください。
パーミッションとは
UNIX/Linuxのファイルシステムに採用されている権限です。
読み取り・書き込み・実行の3つの実行権と、自身・グループ・他者の3つの所有権で権限を定めます。
権限は3つの8進数で表します。
細かな説明は省きますが、777だと全権限を許可する（誰でも読み書き実行できる）設定になります。
※Windowsにも似たような仕組みはありますが、UNIX/Linuxのそれとは異なります
WordPressの推奨
WordPressのパーミッション設定は、以下にドキュメントがあります。
特に以下に注目です。
WordPress を自分でインストールした場合、とくにパーミッションを変更する必要はないことがほとんどです。一部のファイルとディレクトリ（具体的に言えば wp-config.php ファイル）は、特に厳しい権限を適用し「（セキュリティの）強化」をすべきです。このファイルは当初644権限で作成され、そのままにしておくのは危険です。
「変更しなくていいケースがほとんどだけど、wp-config.phpだけは変えてね」と忠告しています。
文中に示している644権限のままである場合、（特に共有サーバーの場合）wp-config.phpの中身が第三者に見られる危険性があります。
また具体的なパーミッションに関する記載もあります。
All directories should be 755 or 750.
All files should be 644 or 640. Exception: wp-config.php should be 440 or 400 to prevent other users on the server from reading it.
つまり以下のコマンドを実行すればOKです。
※【WordPressをインストールしたディレクトリ】は書き換えてください
sudo find 【WordPressをインストールしたディレクトリ】 -type d -exec chmod 755 {} \;
sudo find 【WordPressをインストールしたディレクトリ】 -type f -exec chmod 644 {} \;
sudo chmod 440 【WordPressをインストールしたディレクトリ】/wp-config.php3行目が重要です。大事なのは、自身・グループ・他者の所有権のうち、他者の権限を除くことです。
WordPressのドキュメントで言及しているほどなので、必ず設定しましょう。
ただし環境によっては異なる
サーバーの環境によって適切なパーミッションは異なります。
wp-config.phpについては440ではなく400で事足りる場合もあります。
特に共有サーバーでは、wp-config.phpは440（400）ではなく640（600）でなければならない場合もあるようですので注意してください。
例えばエックスサーバーでは600が指定されています。
この辺りはこの記事の情報だけでなく、自身が借りているサーバーの仕様を確認しましょう。
wp-config.phpには何がある？
WordPressをインストールしたことがある方は触ったことがあると思います。
様々な設定を書き込むファイルですが、セキュリティにおいては以下が重要な情報です。
- データベースの接続に必要な情報
- セキュリティキー (秘密鍵)
後者は公式のオンラインジェネレータから作れる文字列のことです。
これらの情報が漏れてはならないので、公式ドキュメントでも言及しています。
設定しないとどうなる？
WordPress内のデータを盗み見・改ざんされたり、パスワードを特定される危険があります。
データベースの接続に必要な情報が漏れて侵入された場合、データの盗み見やら改ざんやらし放題です。
セキュリティキーについては、通信経路上などのどうしても盗み見される可能性のある箇所でパスワードが漏れたとしても問題ないようにする仕組みなので、これが漏れるとパスワードを特定される可能性が一気に高まります。
またパスワード以外でもCookieなどで使われるものなので、他の弊害もあります。
Webアプリケーションの公開ディレクトリはパーミッションを適切に設定しなければなりません。
WordPressに限った話ではありませんので、確実に設定しましょう。
phpMyAdminを使っている場合
この場合の推奨レベルは「★★★★★★」です。
理由は脆弱性になるからです。絶対に設定してください。
※phpMyAdminでなくとも、外部からデータベースへの接続経路を用意している場合も同様です
前述した通り、wp-config.phpにはデータベースのログインに必要な情報が書いてあります。
そしてphpMyAdminはMySQL(MariaDB)を管理できるツールなので、MySQL(MariaDB)のユーザーとパスワードでログインできます。
wp-config.phpの内容が外部に漏れたら侵入まで秒読みですね。
あとはphpMyAdminのURLを見つけるだけです。
WordPress内のデータを盗み見・改ざんし放題というのがいよいよ現実になります。
絶対に適切なパーミッションを設定しておきましょう。
話は逸れますが、phpMyAdminにも2要素認証を設定できます。
このように意図せず脆弱性を作ってしまうことから、phpMyAdminを使わないという選択肢もあるのですが、どうしても使いたい場合は設定するといいでしょう。
バージョンを最新に保つ
推奨レベル: ★★★★★
設定とはちょっと異なりますが、とても大切なことなので最後に紹介します。
セキュリティは流動性が高い分野なので、昨日まで安全だったものが危険になったりします。
軽視されがちですが、バージョンアップはあらゆる脆弱性の対策です。これを怠れば他のどんなセキュリティ対策も無に帰すかもしれない重要度の高い項目です。
自動アップデート機能
理想的な方法は手動アップデートです。
WordPressのカスタマイズ状況によってはアップデート後に表示が崩れたりする可能性があるため、人間の手と目で確認しながらアップデートをするのが最も確実な手段です。
しかしそれは理想論であり、現実には普段WordPressにログインすらしない運用がほとんどでしょう。
WordPressには自動アップデート機能があります。
放置していてもセキュリティを担保できるので、これを上手く使うのも手です。
設定がバラけていてちょっと分かりづらかったので追記します。
WordPress
WordPress本体の自動アップデート設定は、[ダッシュボード]-[更新]から行えます。
デフォルトではすべてのバージョンに対する自動更新が有効になっています。
すべてのバージョンを対象にするとWordPressのメジャーバージョンアップも自動的に行われます。
（例：5.8→5.9など）
メジャーバージョンがリリースされた直後はテーマやプラグインが対応しきれていない可能性があるため、不具合を起こす危険性も高まります。
メンテナンスリリースやセキュリティリリースのみが対象ならばマイナーバージョンアップに留まります。
（例：5.8→5.8.2など）
既存の機能を崩さない形でアップデートが提供されるので、不具合を起こす危険性は少ないです。
もちろんどこかのタイミングではメジャーバージョンアップを行わないといけませんが、マイナーバージョンはしばらく提供され続けるので、「1年に1回しかログインしない」というレベルの運用でも問題ありません。
プラグイン
プラグインの自動アップデート設定は[プラグイン]から行えます。
プラグイン個別に設定する形になっており、デフォルトでは無効になっています。
プラグインにはメンテナンスリリースやセキュリティリリースという概念はありません。
選ぶことができるのは「自動更新をするかしないか」のみです。
多少の不具合の危険性は伴いますが、特に理由がなければ自動更新を有効にしておきましょう。
WordPress本体とは異なり、プラグイン単体のアップデートならば既存の機能が崩れることは少ないはずです。
テーマ
テーマの自動アップデート設定は[外観]のテーマの詳細から行えます。
テーマ個別に設定する形になっており、デフォルトでは無効になっています。
その他はプラグインと同様です。
特に理由がなければ自動更新を有効にしておきましょう。
※自動更新を有効にしても自動更新されないテーマもあるようです。その点は注意
おさらい
「やらなくていい」設定
効果なしの設定です。
- ★☆☆☆☆ バージョンを隠す
- ★☆☆☆☆ フィードの無効化
「やった方がいいけど、別にやらなくてもいい」設定
万人に効果があるとまでは言い切れない設定です。
- ★★☆☆☆ データベースの接頭辞の変更
- ★★☆☆☆ ユーザー名を隠す
- ★★☆☆☆ REST APIの制限
- ★★★☆☆ ログインページを隠す
「やるべき」設定
効果がある、本当にやるべき設定です。
- ★★★★★ 多要素認証の設定
- ★★★★★ ログイン試行の制限
- ★★★★★ XML-RPCの制限
- ★★★★☆ バックアップの定期的な取得
- ★★★★☆ パーミッションの適切な設定
- ★★★★★ バージョンを最新に保つ
この記事を書いたきっかけ
私はWordPressに2017年頃から触れていたのですが、本格的にやり出したのは最近です。
この記事を書く以前に、WordPressの構築記事を4回に分けて書きました。
上記のような記事を書くには、改めて自分で情報収集をしてまとめる必要があります。
しかし情報収集の中で「これ本当に必要ある？」と疑問に感じたものも多々ありました。
WordPressのセキュリティ対策について調べると、別にそうでもない設定が必須であると紹介されていたり、本当に必要な設定が書いていなかったりしてまとめるのが大変でした。
検索エンジンだけでなくTwitterのようなSNSで調べても同様です。
中には、初心者にとってハードルの高い内容を書かないようにした記事もあったかもしれません。
2要素認証とか、2022年時点で一般に普及しているかと言われると微妙ですからね。
ただ、本当に必要な情報が埋もれてしまってはいけません。
セキュリティ対策はやった方がいいことを全てやることではない
TwitterなどのSNSを見る限り、ここ数年でセキュリティに対する意識は飛躍的に向上したと思います。
それはもちろんいいことです。
ただ「このサイトはxxxの設定をしていないからダメ」という主張を見た時、何かがズレていると感じました。
ダメな理由が書いてあれば納得できるのですが、たいてい理由はふわっとしていることが多いです。
「実はやらなくてもいい6つのセキュリティ対策」では、それらの疑問を明確に文章化しました。
じゃあ結局どうすればええねん、という疑問が追加で出てくるので、その回答が本記事になります。
もちろんこの記事も何かが抜け落ちていたり、間違ったことを書いたりしているかもしれません。
もし何かあればTwitterとかで気軽にご指摘ください。
おまけ: 絶対に改ざんされない方法
WordPressのテーマ「Lightning」を作っている会社さんの記事でShifterというサービスが紹介されています。
WordPressで作成したページをすべて静的なHTMLを変換し、PHPのようなプログラムを介さずに提供することでセキュリティを大幅に向上させるサービスです。
これはセキュリティ面だけでなく、パフォーマンス面でも大きな優位性を保てるメリットがあります。
無料ではありませんが、高いセキュリティを求められる場合にはよいかもしれません。
WordPress以外の選択肢
「世界一使われている＝狙われやすいCMSであるWordPressを使うから悪い」という考えも存在します。
ブログを作るならnoteやはてなブログでもいいですし、ホームページを作るならWixやJimdoなどもありますし、エンジニアなら静的サイトジェネレータ（HugoとかNext.jsとか）という選択肢もあるでしょう。
本当にセキュリティを重視するなら、そういう観点を持ってみるのもアリだと思います。
