SP用メニューボタン
ソレゾレブログ

技術的な事だったり日常の気になる事だったり

WordPressのセキュリティ対策についてどんなものがあるのか調べた結果を一覧にしてみた

スポンサーリンク

世の中いい人ばかりであればセキュリティ対策など必要ありません。ですが、現実はそうではありません。WordPressにおいてもセキュリティ対策は切っては切り離せない問題だと思います。この記事では、WordPressで気にしなくてはいけないセキュリティ対策について書いていきたいと思います。

ソースコードのセキュリティ

クロスサイトスクリプティング攻撃とその対策

クロスサイトスクリプティング攻撃(XSS)とは、アプリケーション(Webサイト)の脆弱性を利用して悪意のあるスクリプト(プログラム)を埋め込み悪事を働く攻撃です。

サイト内に偽のリンクを埋め込み、自サイトそっくりに作られた偽のWebサイトに転送させ、そのサイトで情報を盗み取ったりする攻撃です。

XSSについて詳しくは、下記サイトが参考になると思います。

どのような例で悪用されるかは下記外部サイトなどの実例を参照してみてください。

対策としては、XSS攻撃の対象となる特殊文字列を、エスケープ(サニタイズ(無害化))処理(エンティティ文字に置き換え)することで可能です。

方法については下記ブログを参照してください。

標準で挿入されるヘッダー情報の削除

WordPressは何もしないと自動的に下記のように沢山のヘッダー情報が書き込まれます。

<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0, viewport-fit=cover">
<meta name='robots' content='max-image-preview:large' />
<link rel='dns-prefetch' href='//s.w.org' />
		<script type="text/javascript">
			window._wpemojiSettings = {"baseUrl":"https:\/\/s.w.org\/images\/core\/emoji\/13.1.0\/72x72\/","ext":".png","svgUrl":"https:\/\/s.w.org\/images\/core\/emoji\/13.1.0\/svg\/","svgExt":".svg","source":{"concatemoji":"http:\/\/testdev.local\/wp-includes\/js\/wp-emoji-release.min.js?ver=5.8"}};
			!function(e,a,t){var n,r,o,i=a.createElement("canvas"),p=i.getContext&&i.getContext("2d");function s(e,t){var a=String.fromCharCode;p.clearRect(0,0,i.width,i.height),p.fillText(a.apply(this,e),0,0);e=i.toDataURL();return p.clearRect(0,0,i.width,i.height),p.fillText(a.apply(this,t),0,0),e===i.toDataURL()}function c(e){var t=a.createElement("script");t.src=e,t.defer=t.type="text/javascript",a.getElementsByTagName("head")[0].appendChild(t)}for(o=Array("flag","emoji"),t.supports={everything:!0,everythingExceptFlag:!0},r=0;r<o.length;r++)t.supports[o[r]]=function(e){if(!p||!p.fillText)return!1;switch(p.textBaseline="top",p.font="600 32px Arial",e){case"flag":return s([127987,65039,8205,9895,65039],[127987,65039,8203,9895,65039])?!1:!s([55356,56826,55356,56819],[55356,56826,8203,55356,56819])&&!s([55356,57332,56128,56423,56128,56418,56128,56421,56128,56430,56128,56423,56128,56447],[55356,57332,8203,56128,56423,8203,56128,56418,8203,56128,56421,8203,56128,56430,8203,56128,56423,8203,56128,56447]);case"emoji":return!s([10084,65039,8205,55357,56613],[10084,65039,8203,55357,56613])}return!1}(o[r]),t.supports.everything=t.supports.everything&&t.supports[o[r]],"flag"!==o[r]&&(t.supports.everythingExceptFlag=t.supports.everythingExceptFlag&&t.supports[o[r]]);t.supports.everythingExceptFlag=t.supports.everythingExceptFlag&&!t.supports.flag,t.DOMReady=!1,t.readyCallback=function(){t.DOMReady=!0},t.supports.everything||(n=function(){t.readyCallback()},a.addEventListener?(a.addEventListener("DOMContentLoaded",n,!1),e.addEventListener("load",n,!1)):(e.attachEvent("onload",n),a.attachEvent("onreadystatechange",function(){"complete"===a.readyState&&t.readyCallback()})),(n=t.source||{}).concatemoji?c(n.concatemoji):n.wpemoji&&n.twemoji&&(c(n.twemoji),c(n.wpemoji)))}(window,document,window._wpemojiSettings);
		</script>
		<style type="text/css">
img.wp-smiley,
img.emoji {
	display: inline !important;
	border: none !important;
	box-shadow: none !important;
	height: 1em !important;
	width: 1em !important;
	margin: 0 .07em !important;
	vertical-align: -0.1em !important;
	background: none !important;
	padding: 0 !important;
}
</style>
<link rel='stylesheet' id='wp-block-library-css'  href='https://testdev.local/wp-includes/css/dist/block-library/style.min.css?ver=5.8' type='text/css' media='all' />
<link rel='stylesheet' id='contact-form-7-css'  href='https://testdev.local/wp-content/plugins/contact-form-7/includes/css/styles.css?ver=5.4.2' type='text/css' media='all' />
<link rel='stylesheet' id='style-css'  href='https://testdev.local/wp-content/themes/testdev/style.css?ver=5.8' type='text/css' media='all' />
<script type='text/javascript' src='https://testdev.local/wp-includes/js/jquery/jquery.min.js?ver=3.6.0' id='jquery-core-js'></script>
<script type='text/javascript' src='https://testdev.local/wp-includes/js/jquery/jquery-migrate.min.js?ver=3.3.2' id='jquery-migrate-js'></script>
<script type='text/javascript' src='https://testdev.local/wp-content/themes/testdev/js/main.js?ver=5.8' id='main-js'></script>
<link rel="https://api.w.org/" href="https://testdev.local/wp-json/" /><link rel="alternate" type="application/json" href="https://testdev.local/wp-json/wp/v2/pages/35" /><link rel="EditURI" type="application/rsd+xml" title="RSD" href="https://testdev.local/xmlrpc.php?rsd" />
<link rel="wlwmanifest" type="application/wlwmanifest+xml" href="https://testdev.local/wp-includes/wlwmanifest.xml" /> 
<meta name="generator" content="WordPress 5.8" />
<link rel="canonical" href="https://testdev.local/" />
<link rel='shortlink' href='https://testdev.local/' />
<link rel="alternate" type="application/json+oembed" href="https://testdev.local/wp-json/oembed/1.0/embed?url=http%3A%2F%2Ftestdev.local%2F" />
<link rel="alternate" type="text/xml+oembed" href="https://testdev.local/wp-json/oembed/1.0/embed?url=http%3A%2F%2Ftestdev.local%2F&format=xml" />
<style type="text/css">.recentcomments a{display:inline !important;padding:0 !important;margin:0 !important;}</style>
</head>

実はこの中には不要なものもあります。不要なヘッダー情報はセキュリティリスクを招きますし、ソースコードが書いてあるということは処理が走るので、必然的にリソースを食うことになります。不要なヘッダー情報は削除(非表示)しましょう。方法については下記ブログを参考にしてみてください。

スポンサーリンク

プラグインやテーマ、WordPress自体の脆弱性

プラグインやテーマは、デザインや機能をすぐに導入できる便利なものですが、結果扱うソースコードが増えるのでそれらが脆弱性となることもあります。対策方法については下記が挙げられます。

プラグインの無効化

どうしても必要なプラグインだけ残し、不要なプラグインは無効化にするだけではなくではなくアンインストールすることが必要です。

テーマの削除

未使用のテーマ(特に初期状態から入っているTwenty Twelveなどなど)は必ず削除しましょう。

最新版への更新

プラグイン, テーマ, WordPress自身の更新もセキュリティリスクの回避となります。致命的な脆弱性が発生した場合は、その対策版がリリースされたら更新するようにしましょう。

最新版への更新前に気を付けること

ただし、更新することによりサイトのソースコードとの相性で、サイト自身が表示されなくなるリスクもありますので、事前検証は必須です。また、勝手に更新版が適用されないように自動更新はオフにすることをお勧めします。

方法については下記ブログを参照してください。

更新してサイトが表示されなくなった時の対応策として、更新する前に必ずサイトのバックアップを作成してから更新しましょう。

事前検証する方法としては、コピーサイトをローカルに作成して実施する方法が良いかと思われます。

プラグインに頼らないのも手?

プラグインに頼らないのも一つかもしれません。例えばFaviconを設定するプラグインなどがありますが、Faviconを設定する程度でしたら数行タグを書けば出来ますので、セキュリティリスクを考えたら何十何百ものソースコードのあるプラグインを導入するよりも良いかもしれませんね。

最新の脆弱性情報の収集

WordPressの脆弱性については、プラグインも含めて下記外部サイトなどで公開されております。定期的に情報を収集して、致命的な脆弱性が公開された場合はにすぐ対応できるよう日頃から確認することも手段の一つです。

管理画面のURLを変更

WordPressの管理画面は初期値で「wp-admin」や「wp-login.php」となっています。WordPressを構築したことがある人なら誰でも知っているので、万が一アカウントが知られてしまったら、不正アクセス、情報漏洩、改竄、消去などのリスクがあります。

対策としては、管理画面のURLを変更する方法が挙げられます。変更する方法には手動とプラグインを使う方法がありますが、手動の方法は若干手間がかかりそうなので、プラグインを使う方法をお勧めします。

プラグインによる変更方法は下記ブログを参考にしてみてください。

ログイン最大試行回数の制限

管理画面は初期値でログイン試行回数が制限されていません。つまり、ブルートフォースアタック(総当たり攻撃)によってアカウントとパスワードを解読されるリスクがあるということになります。

ブルートフォースアタックとは、考えられる文字列の組み合わせを総当たりで順番に試していく方法です。例えば四桁の数字なら数字を1づつ足していくような方法や、一般的に設定しがちな文字列を順番に試していく辞書攻撃などの方法があります。

これに対する対策は、ログイン最大試行回数に制限を付ける方法です。 最大試行回数に達したら、一定時間ログインできなくするロックをかけるます。何もしなければWordPressは無限にログインを試すことが出来ます。

方法については下記ブログを参照してください。

管理画面のアカウント

ユーザー名にadminや一般的に設定しがちなIDを使わない

管理者やユーザーIDにadminや一般的に利用しがちなIDを使用していてる場合、ブルートフォースアタックによって不正ログインされてしまうリスクが非常に高いです。推測しにくい管理者IDにすることをお勧めします。

ユーザー名のパスワードの強化

当然なことですが、簡単だったり推測されやすい文字列をユーザー名のパスワードとして使っていれば、解読されるリスクが高まります。これらは推測されにくいものを設定する必要があります。

推測されにくい文字列の条件は下記です。

  • 使える文字の種類が多い
  • 桁数が多い

使える文字の種類を増やすには、数字、大文字英字、小文字英字、記号を組み合わせて使うと効果的です。

桁数については、上記文字の組み合わせで8桁以上を設定すると、約1000年かかると試算されています。2015年の資料ですので現在ではもう少し早くなっているかもしれませんが、それでも相当な年数です。

試算結果については、下記サイトの「(2)強いパスワードとは」の「表1-1」に詳しく記載がありますので参考までに。

さすがにユーザー名まで複雑にすると使いづらさを感じるかもしれませんので、ユーザー名については特定されにくいけど設定した人には覚えやすい文字列程度にしておく方がよいかもしれません。

ユーザーにニックネームをつけて投稿者名を変更する

ユーザーを作成するときに、「ユーザー名」と「メールアドレス」だけ入力し「姓」「名」を入力しないでユーザーを作成すると、「ブログ上の表示名」にユーザー名が設定されてしまいます。

投稿したブログに投稿者を表示するデザイン設計としていた場合、容易にユーザー名がわかってしまいます。

ユーザー名を知られるのは本望ではないと思いますので、対策が必要です。

変更するのは簡単で、[ユーザー] – [ユーザー一覧] で対象ユーザーをクリックして設定画面を開いたら、[ニックネーム (必須)]欄に「ユーザー名」とは違[ニックネーム]を設定し、[ブログ上の表示名]から設定した[ニックネーム]を選択して[ユーザーを更新]をクリックすればOKです。

こうすれば、ブログの投稿者名には[ユーザー名]ではなく[ニックネーム]が表示されるようになります。

ユーザーにニックネームをつけて投稿者名を変更する方法

ユーザー名漏えい防御

WordPressでは、ユーザー番号が含まれた「https://ドメイン名/?author=番号」のようにアクセスすると、ログインIDが含まれた「https://ドメイン名/author/ログインID/」のURLにリダイレクトされてしまいます。

また、「https://ドメイン名/wp-json/wp/v2/users」にアクセスすると、REST APIの機能によってログインIDが含まれた情報が返ってきます。

これらは脆弱性ではなく仕様ですが、ログインIDが筒抜けとなりセキュリティ的に良くありません。プラグインの訪比については「Site Guard ユーザー名漏えい防御」や「All in one WP security & Firewall ユーザー番号」の記事で紹介していますので参考にしてくみてください。

ファイルの属性(パーミッション)を見直す

WordPressは、何百数千ものファイルから構成されています。それらのファイルには必ずパーミッション(読み取り、書き込み、実行などの権限)が設定されています。アクセス権よっては、不特定多数のユーザーから読み取りはおろか実行や書き換えまでできてしまうものもあります。万が一、管理者以外のユーザーがファイルにアクセスして変更してしまったり、不正アクセスに成功したハッカーに悪用されるリスクも考えられます。それらのリスクを下げるために、アクセス権は適切に設定する必要があります。

パーミッションの適切な設定方法については下記記事を参照してください。

※ページ作成中

セキュリティチェックツールを活用する

自分のサイトにどれだけの脆弱性が潜んでいるかセキュリティチェックをすることが出来ます。

セキュリティチェックには、外部からのチェックと内部からのチェックがあります。外部からのセキュリティチェックは、インターネット上にセキュリティチェック用のツールがインストールされたサーバーを設置し、クライアントのWebサイトもしくはシステムにチェックをかける方法です。

内部からセキュリティチェックは、セキュリティチェックのソフトウェアがインストールされているサーバーやPCをLANに接続してチェックする方法です。

内部セキュリティチェックは、金融や通信キャリがなどのセキュリティに対して非常に厳しい基準が求められるサービスに対してのみ必要です。Webサイトへのアクセスは外部からが基本ですので、個人や中小企業などのWebサイトではまず不要です。外部セキュリティチェックを実施すれば事足ります。

「WordPress脆弱性診断」と検索すると、無料から有料のものまで沢山出てきますので検索してみてください。

スポンサーリンク

お問合せフォームのセキュリティ

WordPressのお問合せフォームのセキュリティリスクと言えば、自動返信機能を悪用したスパムメールの大量配信です。これにより、自分だけではなくレンタルサーバー業者やメールを受け取った人たちにも迷惑が掛かり、結果、迷惑なメールアドレスの調査を行ってブラックリスト化しているサービス業者にブラックリスト登録されてしまい、迷惑メールや不正コンテンツと判断されるようになってしまいます。

自動返信機能を悪用されないために手っ取り早いのは、自動返信機能を無効化することです。とはいえ、自動返信機能が必要だから自動返信機能を設定しているわけですので、無効化しない方法もあります。それはreCaptchaやCAPTCHAによるボット判定の導入です。方法については下記記事を参考にしてみてください。

また、Akismetプラグインによるスパム対策も有効です。詳しくは下記を参考にしてみてください。

WordPressコメント機能のスパム対策と関連する設定について(ディスカッションの設定)

コメント(ディスカッション)のスパム対策

WordPressのブログには、ユーザーからのコメントを投稿できる機能(ディスカッション)が用意されていますが、何もせず放置しておくと、スパムコメントの温床となってしまします。コメント欄を運用される場合は、必ずスパム対策された方が良いと思います。対策方法については下記を参考にしてください。

DBのセキュリティ

WordPressとDBは切っては切り離せない関係で、設定情報、投稿、コメント、ログなど、様々なものがDBに書き込まれています。そのDBですが、phpMyAdminなどで除いてみるとわかると思いますが、テーブル接頭辞(プレフィックス)が初期値で「wp_」となっています。(レンタルサーバーでは違う場合もある)

接頭辞とは、複数DBが存在する場合にそのテーブルがどの役割のDBに属しているかを表す識別子みたいなものです。

その接頭辞ですが、昔は「SQLインジェクション」という攻撃によって、情報漏洩、改竄、消去、不正ログインなどの被害が多発していました。最新のWordPressでは、その脆弱性は改善されているので接頭辞を変更する必要性はないとされていますが、今後同じような脆弱性が発生するかもわからないため、念のため変更することが良いとされています。ですので、特別な理由が無い限りは、接頭辞は変更しておいた方が良いかもしれません。

尚、「SQLインジェクション」攻撃について詳しく下記外部サイトを参照してください。

変更は、「All in one WP security & Security」などのプラグインによってもできますし、手動で行うこともできます。変更前にはDBまたはサイト全体ののバックアップを取って、有事の際に戻せるようにしておくことをお勧めします。

サイトのSSL化

WebサイトのSSL化とは、Webサイトのデータ暗号化の事です。httpsで始まるURLであればSSLによって暗号化されているサイトであると言えます。

Webサイトのプロトコルにはhttpが使われており、httpはネットワーク上でWebサイトのデータ(html, css, javascript, 画像, 動画など)を受け渡しする役割を持っています。

プロトコルとは、機器間がデータをやり取りする際の手続きや手順を取り纏めた規則のことです。同じプロトコル規則の元で作られたシステムを実装することで、異なる機器間でも正しく通信をすることが出来ます。

httpは暗号化の機能を持っていないため、このまま使うとネットワーク上に暗号化されていないデータがそのまま流れてしまいます。悪意のあるボットやハッカーなどに、閲覧内容、個人情報、クレジット情報、アカウントなど情報を傍受悪用されてしまう危険性があるということです。

これではまずいということで、httpにSSL(TLS)という暗号化技術を組み合わせて暗号化機能をもたせたものがhttpsです。httpsを使うことによって、万が一データを傍受されても中身が暗号化されているため安心というわけです。

WebサイトがSSL化されていない場合は速やかにSSL化することをお勧めします。

尚、SSL化されていないサイトにアクセスするとブラウザ上にエラーが表示されます。すぐにわかるようなエラーです。どんなエラーが表示されるかは下記globalsignのページが参考になると思います。

補足情報1

暗号化にはレベルがあり、あまりレベルの低いものを使うと解読されてしまう危険性があります。暗号化の技術の中にはプロトコルと暗号スイートというものがあり、これによって暗号化レベルが決まります。このプロトコルと暗号スイートですが、暗号レベルが低いものは脆弱性がありセキュリティリスクが高まります。ですのできちんとした暗号レベルの高いものを使用する必要があります。

ただし、暗号化強度はレベルが高ければよいというものでもありません。先方のシステムが最先端の暗号プロトコルや暗号スイートに対応していない場合がありますし、暗号化レベルが高いということは必然的に計算量が増える為、処理が重くなります。このバランスの良い最善の組み合わせで運用することがベストです。インターネット上に公開されているWebサイトなら業者が提供するSSLチェックサイトなどで確認できますし、ローカル環境に導入するフリーの暗号化強度チェックツールもありますので活用してみてください。

補足情報2

TLS(Transport Layer Security)とはSSL(Secure Socket Layer)の後継で、厳密にはSSLには脆弱性があり現在は利用非推奨となっています。後継のTLSには1.3までバージョンがあります。TLSの初期版にも脆弱性があるため相手システムとの互換性を踏まえたうえで可能な限り新しいバージョンを使うことをお勧めします。TLSとSSLを語るときにはまとめてSSLと言いますが、厳密には新旧のものであるということを覚えておいてください。

サイトの常時SSL化

サイトをSSL化しても、httpでアクセスが許可されていては意味がありません。httpでのアクセスを未然に防ぐことが大事です。.htaccessファイルを使うことが出来れば、httpアクセスをhttpsに強制リダイレクトすることが出来ます。設定方法を下記に示します。ひとつ注意点ですが、設定をを追加する場合は、WordPressが標準で追加する「BEGIN WordPress」のルールの上に書いてください。このルールの後に書くとうまく動作しません。

# 下記三行を「BEGIN WordPress」のルールより上に書く
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

# BEGIN WordPress
 :
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
補足情報

この設定の場合は、301リダイレクトを使います。301は恒久的リダイレクトの意味ですが、今後ずっとhttpsへリダイレクトするので301を使います。302リダイレクトは一時的はリダイレクトという意味です。一時的にリダイレクトするけど戻す予定がある場合に使います。

SSLサーバー証明書の適用

SSLサーバー証明書とは、このサーバーは公的に問題が無くあなたがアクセスしようとしている正式なサーバーですよ、という証明をしてくれます。実は、SSLによる暗号化はサーバー証明書が無くてもできます。ですが、サーバー証明書が無いと、通信が暗号化されていてもアクセスしているサーバーが偽物だったという、元も子も無い状態がありえてしまうので、SSLサーバー証明書の提供が必要だということです。

SSL証明書には無料と有料のものがあります。有料証明書のメリットは高い信頼度の担保です。実在証明(OV)や実在証明拡張(EV)によって信頼を高めてくれます。金融、通信、大型ショッピングサイト、メーカーなど社会的に高い信頼が必要とされるサイトでは有料のものを使うべきです。

個人や中小企業など、そこまで信頼度が高くなくても良いサイトの場合は無料のもので十分です。レンタルサーバーのほとんどは、この無料SSL証明書発行機能が提供されています。

SSL証明書の適用方法ですが、レンタルサーバー毎にマニュアルが公開されていますので、そちらを参考に導入してください。

尚、SSLサーバー証明書が適用されていない場合は、アクセスするとブラウザ上にエラーが表示されます。すぐにわかるようなエラーです。どんなエラーが表示されるかは下記globalsignのページが参考になると思います。

WebサイトのSSLチェック

Web上のSSL暗号化チェックサイトを利用すると、WebサイトにSSLが適切に導入されているか(SSLの適用状況、暗号強度、SSL証明書、など)のチェックすることが出来ます。いくつか無料のサイトがありますので是非チェックしてみてください。

このほかにも検索すればいくつか出てくると思いますので自分好みのものを探してみてください。

Webサイトデータの転送

Webサイトへのファイル送受信の方法としてよく使われているのがFTPです。このFTPですが、そのまま使うと通信の内容が丸見えになってしいます。通信を傍受されると、送受信していデータの内容や認証情報を盗み見ることが出来てしまいます。それでは非常にまずいので、FTPにも暗号化する技術が存在ます。SFTP、FTPS、SCPがそれです。

SFTPはFTP+SSHの事で、SSHによって暗号化されます。利用するのでしたらこれを一番にお勧めします。

FTPSはFTP over SSL/TLSの事で、SSL/TLSによって暗号化されます。SFTPが使えない場合は2番目にお勧めします。

何故一番目にSFTPをお勧めするかというと、一つ目の理由は、SFTPでは一つのポート番号しか利用しませんがFTPSは仕様上たくさんのポート番号を利用するからです。ポートリソースを沢山消費します。二つ目の理由ですが、SFTPはLinuxなどに標準で搭載されているOpenSSHで利用できるからです。FTPSは別途vsftpdなどのサービスを立ち上げる必要がありますが、SFTPは既にOpenSSHがインストールされているため、手間が少なくてすみます。そういった理由で、SFTPがよいでしょう。一般的にもSFTPを利用しているケースが多いです。

最後にSCPですが、これもOpenSSHなどに付随している機能。SSHサーバーが稼働していればすぐに利用出来ます。SFTPとFTPSが使えなかったらお勧めしたいところですが、このSCPは現在レガシー機能となっています。拡張性が無い、脆弱性が多い、機能更新が滞っている、など理由からSCPは現在選択してはいけない機能となっています。使わないことを強くお勧めします。

レンタルサーバーなどでは、FTPもSFTP(FTPSの場合もある?)も両方使える状態となっているため、間違ってもFTPでデータの送受信をしないようにしましょう。

尚、レンタルサーバーにはブラウザベース(WebDAVなど)の転送ツールが用意されている場合があります。これはHTTPSによって暗号化されているため(されていないことはまず無いと思います)、セキュリティ面では問題ありません。そちらを使うのも手です。

スポンサーリンク

定期的なバックアップの取得

WordPressの更新(コアファイル、プラグイン、テーマ、翻訳ファイル)、コンテンツの更新、設定変更などなどにより、既存コンテンツやプラグインなどとの相性問題が発生し、Webサイトが機能しなくなるリスクを孕んでいます。対策としては、定期的(スケジュールおよび変更作業の前)なWordpressのバックアップをお勧めします。

WordPressのデータには、ファイルとDBの二つがあります。WordPressに標準で搭載されている「WordPressインポーター」では、ファイルの部分しかインポートやエクスポートが出来ません。

DBも合わせて全体的にバックアップもしくはリストアするにはプラグインの導入をお勧めします。

ウイルス感染対策

WordPressもソフトウェアですからウイルス感染(マルウェア感染)のリスクにさらされています。

マルウェアとは、コンピューターウイルス、トロイの木馬、スパイウェアなどなど悪意のあるプログラムやソフトウェアの総称です。

マルウェアにはいろいろなものがあるため、マルウェアに感染することによるリスクも山のようにあります。(不正アクセス、改竄、消去、悪意のある行為の起点や中継点、etcetcetc…)

ですので、WordPressにもウイルス対策が必要ということになります。マルウェア対策用のプラグインの導入をお勧めします。

アクセス元IPによるアクセス制限

特定のIPアドレスから攻撃を受けていることが分かった時には、そのIPアドレスからのアクセスをブロックすることをお勧めします。

日本国内だけに公開しているサイトでは、外国のグローバルIPアドレスからのアクセスをブロックに日本国内からのアクセスのみ許可することもできます。グローバルIPアドレスは、国ごと地域ごとに払い出されている範囲が決まっているので、外国のIPアドレスをブロックすることは比較的簡単です。セキュリティ攻撃は外国からのものが統計的に多いため、日本国内だけ許可するのは非常に効果的です。

IPアドレスによるアクセス制御機能はWordPressの標準機能には無いため、総合セキュリティ用プラグインの導入をお勧めします。

総合セキュリティ用プラグインの設置

WordPressには総合的にセキュリティ対策がとれるプラグインがいくつか公開されています。ここで一覧したセキュリティリスクに対する対策が総合的に出来るものです。WordPressをインストールしたら総合セキュリティ対策プラグインをインストールすることをお勧めします。当ブログでもいくつか紹介してますので、良ければ参考にしてみてください。