WEB教室 #1 ─ セキュリティー編
2021.05.02
WordPressのセキュリティー対策として、最低限でもこれは対処すべきという5項目を紹介します。
1. バックアップ(WordPressデータとDatabase)
WordPressのセキュリティー対策で最も重要なことは「バックアップ」です。バックアップ作業は時間もかかりますし、地味に面倒なので怠りがちになりますが、バックアップをとらなかったばかりに膨大な時間をリカバリー作業に費やさすはめになることがあります。
これは私自身が実感して言えることですが、バックアップはこまめにとりましょう。本当に「急がば回れ」です。さらに言えば、バックアップデータを使ってリカバリーするところまで出来るようにしておきましょう。
バックアップのお陰で助かった事例
セキュリティー対策中にWEBサイトを壊してしまうなんてこともあります。プラグインを更新しただけで、WEBサイトが表示しなくなることだってあります。背中に変な汗をかく、あの嫌な感じはもう体験したくないので、私自身もバージョンアップ時には必ずバックアップをとるようにしています。
私の経験談ですが、バックアップをとっていたお陰で危機を脱した事例を少しご紹介します。
- 【事例A】いまとなっては滅多に発生しませんが、「Contact Form 7」や「MW WM FORM」等のメールフォームを更新したときに、エラーで設定内容が全部消えることが度々ありました。その時は、バックアップしておいたデータベース(以下、DB)をインポートすることで元に戻すことが出来たので、それ以降、プラグイン更新前にはDBのバックアップを必ずとるようになりました。
(リカバリー手順: バックアップDBをインポートして上書き → リカバリーに成功したら設定内容をテキストエディター等で退避 → バージョンアップしたときにまた設定内容が消えたらテキストエディターで退避した設定内容を手動で入力) - 【事例B】WPコアファイルのバージョンアップに失敗して、何も表示しなくなったときは、ゼロの状態からWordPress(同バージョン)をサーバー上にインストールして、そこに、バックアップしておいた「contents」フォルダと「wp-config.php」だけを上書き(これでコアファイルが改修)。その後にバージョンアップを試み解決。
- 【事例C】「WP-menber」というプラグインを更新したら、プラグイン自体が動かなくなりました。新旧でショートコードが変わったのが原因だったので、新しいショートコードに差し替えたことで解消しました。この時、バックアップデータは使用しなかったのですが、バックアップデータがあったことで、落ち着いて正しい状況判断が出来ました。バックアップデータがなかったら、パニくってど壷にはまっていたと思います。
バックアップの手順(記事作成中)
WordPressのバックアップ手順については、別記事でご紹介予定です。
2. 最新バージョンの保持。最小化(不要の削除)も大事
プラグイン、コアファイル、テーマファイルの順でバージョンアップしましょう。前述しましたが、バージョンアップ前のバックアップは必須です。
- 不要なプラグインは削除
何年も更新されていないプラグインは、脆弱個所を攻撃される可能性が高いため、削除を検討してください。ちゃんと更新していたとしても、導入しているプラグインが多いと、ハッカー攻撃の足掛かりになる可能性も高くなるので、プラグインの導入は最小限にした方がよいです。 - 「プラグイン」→「コアファイル」の順で更新
いきなりコアファイルから更新する方がいますが、エラーがあっても被害が少ない「プラグイン」から先に更新しましょう。あと、「コアファイル」の更新は時間がかかるときがあります。よほどのことでない限り、途中で余計な操作はやめましょう。処理が終わるまで、なるべく放置しておきましょう。 - プラグイン「Classic Editer」の導入
WPのコアファイル更新(バージョン4から5への更新)で投稿の編集画面が変わってしまい、編集しづらくなるので、バージョン4以前の編集画面に戻したい方は、プラグイン「Classic Editer」の導入をお勧めします。 - 不要なテーマは削除
使わないテーマは削除しておきましょう。これもプラグインと同様で、攻撃の可能性を最小限にしておくためです。デフォルトのテーマは、削除するとエラー表示がでることがあるので残してもかまいませんが、更新はお忘れなく。あと、現在使用中のテーマファイルを更新するときは注意が必要です。テーマによって、更新後に各種設定がデフォルトに戻ることがあるからです。しつこいですが、不測の事態に備えてバックアップは必ずとっておきましょう。 - 更新後の確認
体裁崩れがないか、またはプラグイン等の動作確認しましょう。
3. パーミッション設定で重要ファイルを守る
4. 不正ログインをさせないための施策
プラグイン「Site Guard Pack」を導入。
Site Guard Packで最低限設定すべき機能を以下に表記します。出来ればすべての機能をONにしましょう。
- ログインページURLを変更。
- ログインページに「画像認証」機能を追加。(2バイト文字を使用)
- ログイン詳細エラーメッセージの無効化
- XML-RPCを無効。もしくは、ピンバックを無効にする。
- ログイン履歴で、身に覚えのないIPのアクセスをチェック。
初期設定のままにしない。
- WordPressのユーザー名を「admin」のままにしないでください。あと、「設定」でニックネームを入力して、ユーザー名表示からニックネーム表示に変えてください。
- 管理画面URLを「ドメイン/wp-admin」または「ドメイン/wp-login.php」のままにしている方がとても多いです。繰り返しになりますが、Site Guard Packなどのプラグインを使って、ログインページURLを変更しましょう。
あなたのサイトの情報はこうやってバレます
IPアドレス/ドメインの末尾に下記の文字列を付けて、アドレスバーにインプットすると、ユーザー名やWordPressバージョン情報が表示します。この情報は、悪意ある攻撃の足掛かりになりかねません。
- http(s)://(IPアドレス/ドメイン名)/?author=1
└→ 管理者のユーザー名がバレます。下記【a】のコードで隠すことができます。 - http(s)://(IPアドレス/ドメイン名)/wp-json/wp/v2/users/ または、
http(s)://(IPアドレス/ドメイン名)/?rest_route=/wp/v2/users/
└→ 管理者のユーザー名がバレます。下記【b】のコードで隠すことができます。 - http(s)://(IPアドレス/ドメイン名)/feed/」または「‥/atom/」「‥/feed/atom/」
└→ 投稿者のユーザー名がバレます。下記【c】のコードで隠すことができます。 - ページのソースを表示
└→ WordPressバージョン情報がバレます。下記【d】のコードで隠すことができます。
ユーザー名やバージョン情報を非表示(functions.php編)
下記ソース(a~d)を「functions.php 」に追加すれば、情報を隠すことが出来ますが、まずは先に重要なことをお伝えしておきます。
「functions.php」はWordPressの心臓部といって過言ではありません。編集するのにリスクを伴うので、このファイルを取り扱うときは、細心の注意が必要です。失敗してもリカバリーできるように、functions.phpファイルのバックアップを必ずとっておきましょう。
- // 【a】---------------------- author情報を非表示
- function disable_author_archive_query() {
- if( preg_match('/author=([0-9]*)/i', $_SERVER['QUERY_STRING']) ){
- wp_redirect( home_url('/404.php') );
- exit;
- }
- }
- add_action('init', 'disable_author_archive_query');
- // 【b】---------------------- REST API対策用_author情報取得を無効
- function user_filter_rest_endpoints( $endpoints ) {
- if ( isset( $endpoints['/wp/v2/users'] ) ) {
- unset( $endpoints['/wp/v2/users'] );
- }
- if ( isset( $endpoints['/wp/v2/users/(?P
[\d]+)'] ) ) { - unset( $endpoints['/wp/v2/users/(?P
[\d]+)'] ); - }
- return $endpoints;
- }
- add_filter( 'rest_endpoints', 'user_filter_rest_endpoints', 10, 1 );
- // 【c】---------------------- RSSフィード無効化
- remove_action('do_feed_rdf', 'do_feed_rdf');
- remove_action('do_feed_rss', 'do_feed_rss');
- remove_action('do_feed_rss2', 'do_feed_rss2');
- remove_action('do_feed_atom', 'do_feed_atom');
- // 【d】---------------------- WPバージョン情報の非表示
- function vc_remove_wp_ver_css_js( $src ) {
- if ( strpos( $src, 'ver=' . get_bloginfo( 'version' ) ) )
- $src = remove_query_arg( 'ver', $src );
- return $src;
- }
- add_filter( 'style_loader_src', 'vc_remove_wp_ver_css_js', 9999 );
- add_filter( 'script_loader_src', 'vc_remove_wp_ver_css_js', 9999 );
5. メールフォームを守る
迷惑メールのブロック方法。あと、情報漏洩や改ざんされないための基本施策もご紹介します。
reCAPTCHAを導入。
- メールフォームをロボット攻撃から守ります。
- メールフォーム(プラグイン)によって、導入方法は異なります。
- 「Contact Form 7」や「WM MW Form」をお使いの場合は、まずはバージョンアップして、reCAPTCHAを導入できる環境を準備してください。
- WM MW Form をお使いの場合は、専用プラグイン「reCAPTCHA for WM MW Form」との組み合わせで対応してください。
特定のIPアドレスからのアクセスをブロック。
サーバー側の施策になります。機会があれば、本件についても別記事ページでご紹介します。
なりすましメールには反応しないでください。
本件について、機会があれば、別記事ページでご紹介します。
6. SSLサーバー証明書
SSL対策(通信の暗号化)
- なるべく有料のSSLサーバー証明書を導入しましょう。無料のSSLでも当面は大丈夫ですが、無料版は突然終了しても文句がいえません。商用サイトの場合は、なるべく有料のものを使用しましょう。
- 有料SSLといえば「Global Sign」が有名ですが、高額です。「FujiSSL」は新参であるがゆえにお安いのでお勧めです。機能面ではどちらも同じです。
- 無料なら「Let’s Encrypt」が広く使われていますが、下記の記事を閲覧のうえ、ご検討ください。
2021年9月1日以降、Let’s Encrypt使用のWEBサイトが見られなくなる件について ─ ver7.1.1以前のAndroidデバイスに影響
※本記事の参照元はこちら→(参照元:FUJISSL)
無料でウェブサーバー向けのSSL/TLS証明書を発行している認証局Let’s Encryptが、「全世界に存在するAndroidデバイスの3分の1で、Let’s Encryptの証明書が使えなくなる」と警告を出しました。
- Standing on Our Own Two Feet – Let’s Encrypt – Free SSL/TLS Certificates
https://letsencrypt.org/2020/11/06/own-two-feet.html - Let’s Encrypt warns about a third of Android devices will from next year stumble over sites that use its certs • The Register
https://www.theregister.com/2020/11/06/android_encryption_certs/ - Many websites will stop working on older Android versions in 2021
https://www.androidpolice.com/2020/11/07/many-websites-will-stop-working-on-older-android-versions-in-2021/
Let’s Encryptは、すべてのWebサーバへの接続を暗号化することに取り組む非営利団体。設立時に、新しい認証局の証明書は信頼されていないという理由から、すでに主要なブラウザで信頼されている認証局IdenTrustからクロス署名を得てルート証明書の「DST Root CA X3」を使い、主要なブラウザで受け入れられるようにするという措置を執っていましたが DST Root CA X3は2021年9月1日に失効するため、Let’s Encryptは独自のルート証明書「ISRG Root X1」に移行することとなりました。この移行によって、「ISRG Root X1」のルート証明書がプリインストールされていないバージョン7.1.1より前のAndroid OSでは、DST Root CA X3の失効後はHTTPS接続時に警告画面が表示されるようになります。
Let’s Encryptによると、バージョン7.1.1より前のAndroidデバイスは全体の3分の1を占めているとのこと。Androidアプリデベロッパー向け公式サイトのAndroid Developersによると、バージョン7.1.1以降に対応したAndroidデバイスは全体の66.2%。これを差し引いた33.8%のAndroidデバイスが閲覧できないHTTPSページが出る対象となります。