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

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

WordPress総合セキュリティプラグインAll In One WP Securityについて掘り下げる 1/2

スポンサーリンク

検証環境

この機能の検証は「Wordpress」バージョン5.8.1、「All In One WP Security & Firewall」バージョン4.4.9で行っています。

注意点

このプラグインでは、.htaccessファイルにルールを追記することで機能を実現するものもあります。機能によっては設定の仕方によってはサイトへのアクセスが不能になるものもあるので、.htaccessファイルの変更が伴う機能の変更前には.htaccessファイルのバックアップをお勧めします。

もしアクセスできなくなった場合はSFTPなどでサイトにアクセスし、.htaccessファイルを開いて対象ルールを削除すれば復旧します。

WordPressの総合セキュリティプラグインと言えば「All In One WP Security & Firewall」(以降AIOWPS)を使っている人が非常に多いと思います。今回は、このプラグインの導入と設定方法について書いていきたいと思います。

「All In One WP Security & Firewall」について

AIOWPSには、WorpressやWebサイトのセキュリティ攻撃に対して多くの対策機能が用意されています。一般的なセキュリティ攻撃に対して網羅的に対策を打つことが出来ます。全て無料で使うことが出来ますし、おすすめのプラグインです。

ただし、すべての機能に十分な機能が備わっていないのも事実です。その部分については、他のセキュリティプラグインを使って補完していくのも一つの手でしょう。

拡張アドオン

下記機能については拡張アドオンを購入することで機能を追加することが出来ます。

  • 国別IPアドレスのアクセス制御
  • 404エラー(not found)を監視してボット判定となったらブロックする

スポンサーリンク

.htaccessファイルについて

この記事の中に.htaccessファイルを利用した機能が多々出てきますので、.htaccessファイルとはどんなものかについては事前に説明したいと思います。

.htaccessファイルの役割

.htaccessファイルの役割は、アクセス制御、URLリダイレクト、404ページの表示、ユーザー認証、ディレクトリに存在するファイル一覧表示、など(他にも出来る制御はあります。)をディレクトリ毎に制御することです。管理者でなくてもディレクトリに対するアクセス権があれば変更可能なので、ユーザー用ディレクトリのアクセス制御に非常に便利です。ただ、容易に変更が出来る為、セキュリティ上リスクが高いのも事実です。

.htaccessファイルはApacheの設定ファイル

.htaccessファイルはApacheの設定ファイルであり、それ以外のWebサーバーでは機能しません。昨今Nginxを使用したWebサーバーが多くなってきましたが、基本的には他のWebサーバーでは使えないという点に注意してください。

それでも他のWebサーバーで.htaccessファイルを使いたい場合は

世の中には便利なことに、.htaccessをnginxで使える設定ファイルに変換してくれるサイト「winginx」があります。他にもあるので探してみてください。

レンタルサーバーで.htaccessは使えるのか

その他のレンタルサーバーは各々で確認してみてください。

実は.htaccessファイルはApache自体が使用を推奨していない

ここでびっくりですが、実は.htaccessファイルはApache自体が使用を推奨していません。理由は、.htaccessファイルでアクセス制御するとアクセスがあるたびに.htaccessファイルが呼び出される為負荷が高くなることと、ユーザー毎に設定可能であるためセキュリティリスクが高まるからです。

.htaccessファイルではなくhttpd.confで設定可能ならそちらに書く方が無難です。httpd.confはサービス立ち上げ時に一度呼び出されるだけで済みますし、管理者権限が無いと変更できない方です。

レンタルサーバーではhttpd.confを変更するのは無理な場合が多いので、.htaccessファイルに頼らざるを得ない場合もありますが。そもそもApacheではなくnginxを使っているサーバーが多いので、そうなるとこの問題がどうなのかは調べてないのでわかりません。

単なる補足情報でした。

「All In One WP Security & Firewall」の設定

設定方法と各機能の意味について説明します。

このプラグインをインストールするとメニュー直下に [WPセキュリティ] のメニューが追加されます。

ダッシュボード

セキュリティの状態とAIOWPSの設定状態が一覧確認できます。

WPセキュリティのダッシュボード画面1
WPセキュリティのダッシュボード画面2
WPセキュリティのダッシュボード画面3

システム情報

WordPressのサイト情報、PHP情報、使用中のプラグインが確認できます。

ロックされたIPアドレス

[WPセキュリティ] – [ユーザーログイン] でログインロックを有効化にした場合、ログインロックのかかったIPアドレスはここに表示されます。ロック解除もこの画面から実施可能です。

ロックされたIPアドレス

永久ブロックリスト

下記の設定をしたときに一覧に追加されます。

  • [WPセキュリティ] – [スパム防止] – [コメントスパムのIPモニタリング] – [スパマーIPを自動ブロック] の設定によってIPアドレスがスパム対象のIPアドレスだと自動判断された場合。
  • [設定] – [一般] – [だれでもユーザー登録ができるようにする] が有効且つ、[WPセキュリティ] – [ユーザー登録] – [新規登録の手動承認を有効にする] が有効の状態で、ユーザーがログイン画面からユーザー登録申請をして、その後、[WPセキュリティ] – [ユーザー登録] – [登録ユーザーの承認] で対象ユーザーを「Block IP」設定にした場合。

上記機能でブロックされたIPアドレスのブロックを解除するには、この「永久ブロックリスト」から解除できます。

AIOWPSログ

AIOWPSのログが確認できます。

設定

一般設定

WPセキュリティの設定画面1
WPセキュリティプラグイン

WordPressの設定が保存されている、データベース、.htaccessファイル、wp-config.phpファイルのバックアップが促されます。ここでは促されているだけで、実際のバックアップは他のページで実行しますので無視して進んでください。

セキュリティ機能を無効にする

AIOWPSのセキュリティ機能を一括無効化できます。サイトが正常動作しなくなり、AIOWPSの設定が疑わしいとなったら原因究明に使えます。全無効にしたあと一つずつ機能を有効にしていって、どの機能の影響であるか確認できます。AIOWPSの影響でない場合もあるので、無効後にサイトの動作が回復しなかったら一気に元に戻せるように [設定] – [インポート/エクスポート] でAIOWPSの設定をバックアップしてから全無効にすることをお勧めします。

WPセキュリティの設定画面2
ファイアウォールのルールをすべて無効化

AIOWPSの全ファイアウォール機能を一括無効化できます。Webサイトへのアクセス異常が発生し、AIOWPSの設定が疑わしいとなったら原因究明に使えます。全無効にしたあと一つずつ機能を有効にしていって、どの機能の影響であるか確認できます。こちらも設定前にAIOWPSの設定をバックアップしておくことをお勧めします。他のプラグインや手動で設定した.htaccessファイルのアクセス制御が原因であることも考えられるので、総合的に確認することが必要です。

デバッグ設定 – デバッグを有効化

AIOWPSの動作がおかしいときにでデバックを取得することが出来ます。ファイルは”plugins/all-in-one-wp-security-and-firewall/logs”配下に作成されます。尚、ログファイルはプラグイン更新の際にリセットされるそうです。

デバッグはシステムに負荷を与えますので、通常時または解析が終わったら必ずオフにしてください。

.htaccessファイル

.htaccessファイルのローカルバックアップと復元が出来ます。.htaccessファイルについては、先述の「.htaccessファイルについて」を参照してください。

wp-config.phpファイル操作

wp-config.phpファイルの設定画面

wp-config.phpファイルのローカルバックアップと復元が出来ます。

WPバージョン情報

WP バージョン情報の設定画面

WordPressのバージョン情報をヘッダから非表示にすることが出来ます。

<meta name="generator" content="WordPress *.*.*" /> 

WordPressのバージョンをヘッダに載せるセキュリティリスクについては、「WordPressのヘッダーに標準で挿入される情報の中で不要なものを削除(非表示)にする方法」と「WordPressバージョン情報」の記事に書いてありますので参照してみてください。

インポート/エクスポート

インポート/エクスポートの設定画面

AIOWPSの設定情報をインポート/エクスポートできます。定期的または何か設定を変える前にエクスポートしておくことをお勧めします。

高度な設定

IP検索設定
高度な設定の設定画面

HTTPヘッダの中にはアクセス元を特定する情報が含まれていますが、その中にIPアドレス情報も含まれています。AIOWPSがヘッダ内のどのIPアドレス情報によってセキュリティ制御するか変更することが出来ます。通常はREMOTE_ADDRで良いです。

プロキシ、ロードバランサー、 CloudFlareなどを経由してアクセスしてくる場合は変更が必要な場合があります。設定できるアドレス設定値と設定値に意味は下記となります。

設定値説明
REMOTE_ADDRほとんどの場合はこの設定で問題なく使えます。サーバーが知る直近のアクセス元IPアドレスです。途中アドレス変換が成されている場合は最後の変換後のIPが入っていることが通常です。
HTTP_CF_CONNECTING_IPCloudFlareを経由してくる場合アクセス元IPをHTTP_CF_CONNECTING_IPヘッダーに書き替えてくるそうです。 CloudFlare経由の場合はこれに変える必要があるみたいです。
HTTP_X_FORWARDED_FORアドレス変換される前の本当のアクセス元IPです。HTTP_X_FORWARDED_FORヘッダには、変換されたアクセス元IPが「X-Forwarded-For: client1, proxy1, proxy2・・・ のよう」順番に記録されています。どの段階のIPを見ているかはちょっと不明ですのでうまくいかない場合はパケットキャプチャなどして解析する必要があると思います。
HTTP_X_FORWARDEDおそらく、X-Forwarded-For, X-Forwarded-Host, X-Forwarded-Protoをあわせたヘッダの事だと思われます。昨今は事実上上記の3つが標準となっているので、使うことは無い?まれ?HTTP_X_FORWARDEDは、「Forwarded: by=identifier; for=identifier; ; host=host; proto=http|https」のように情報が入ってくるそうです。詳しくは「Forwarded」参照。
HTTP_CLIENT_IP変換される前の本当のアクセス元IPです。 HTTP_X_FORWARDED_FORとは異なり、大本のアクセス元IPだけが記録されています。

どの設定値をアクセス元IPにするかは、Webサーバーのアクセスログか、またはパケットキャプチャして知ることが出来ます。

REMOTE_ADDR以外に設定してIP取得に失敗した場合は、自動的にREMOTE_ADDRからIPアドレスを取得するようです。

スポンサーリンク

ユーザーアカウント

WPユーザー名

管理者のユーザーIDにadminを使っていた場合、下記画像のように警告が出され変更を促されます。

WPユーザー名の設定画面1

既存のユーザーIDを変更する場合は、新しいユーザーを作成して既存ユーザーを削除する手順が必要ですが、このプラグインでは直接変更することが可能です。手間なく変更が出来るということですね。

admin以外に変更したら下記のように警告が消えます。

WPユーザー名の設定画面2

表示名

ユーザーの「ブログ上の表示名」 に「ユーザー名(ログインID)」が使われていた場合、下記画像のように警告が出て変更を促されます。

表示名(ブログ上の表示名)の設定画面1

「ブログ上の表示名」 に「ユーザー名」が使われるとどんなセキュリティリスクがあるかについては「ユーザーにニックネームをつけて投稿者名を変更する」の記事を参照してください。

対象のユーザー名リンクをクリックするとWordpressの管理画面 [ユーザー] の対象ユーザーの設定画面に遷移します。

表示名(ブログ上の表示名)の設定画面2

「ユーザー名」に推測されないような「ニックネーム」を設定後、「ブログ上の表示名」を設定した「ニックネーム」に変更し、画面下部の「ユーザーを更新」をクリックします。

プラグイン管理画面を更新すると、対象の「ユーザー名」が警告欄から消えていると思います。すべての「ユーザー名」が警告から消えるまで設定を繰り返します。

表示名(ブログ上の表示名)の設定画面3

パスワード – パスワード強化ツール

ユーザーに設定しているパスワードの強度をチェックすることが出来ます。弱いパスワードであった場合は強いものを探り当てて変更することをお勧めします。実際の変更は管理画面 [ユーザー]で行います。

パスワード強度については「ユーザー名のパスワードの強化」の記事も参考にしてみてください。

パスワードの設定画面

ユーザーログイン

ログイン制限

ログイン制限ではログイン試行回数によるログインロックを有効にすることはできます。ログインロックは、ユーザー単位ではなくアクセス元IPに対してかけられます。つまり、あるユーザーでのログイン試行ででログインロックがかかった場合、他のIPアドレスからアクセスして同じユーザーのログインを引き続き試行することが出来るということです。

ログイン制限設定画面1
ログインロックダウン機能を有効化

ログインロック機能を有効化します。ログイン制限配下の設定を有効にしたい場合はこの設定を有効化します。

ログインロックがかかった場合のメッセージ画面

「ログイン再試行時間」以内に「最大ログイン試行回数」に達してロックがかかると下記画面が表示されます。

ログインロック画面
ロック解除リクエストを許可

この機能を有効にすると、ログインロックがかかった場合に、ユーザー自身でアカウントロック解除が可能な「自動ロック解除リンク」を生成し、メールで送信してくれます。

実際にロックされてみました。ロックされると下記画面が表示されます。「ロック解除をリクエスト」をクリックします。

ロック解除リクエストを実際に検証してみた画面1

下記画面に遷移しますので、メールアドレスを入力して「ロック解除リクエストを送信」をクリックします。ここで大事なことは、ユーザー作成時に設定したメールアドレスでなければいけないという点です。メールアドレスを忘れた方はロック解除まで待つしかありません。

ロック解除リクエストを実際に検証してみた画面2

正しいメールアドレスを入力した場合は下記画面が表示されます。

ロック解除リクエストを実際に検証してみた画面3

メールアドレスを間違えた場合は下記画面が表示されます。戻って再度試すことが可能です。

ロック解除リクエストを実際に検証してみた画面4

正しいメールアドレスを入力した場合は下記メールが届きます。記載のURLを開くとロックが解除されて通常ログイン画面が表示されますので、正しいアカウントでログインしてください。

ロック解除リクエストを実際に検証してみた画面5
最大ログイン試行回数

ロックされるまでのログイン試行回数です。

ログイン制限設定画面2
ログイン再試行時間 (分)

「ログイン再試行時間」の分数設定です。「ログイン再試行時間」に達していなければ「最大ログイン試行回数」に達していてもロックはかかりません。ブルートフォースアタック攻撃対策といったところでしょうか。

ロックアウト時間の長さ (分)

ロックがかかってから解除されるまでの時間です。

一般的なエラーメッセージを表示

ログインに失敗すると(試行回数には達していない)通常時は下記メッセージが表示されますが、

一般的なエラーメッセージを表示1

設定をオンにすると下記メッセージが表示されます。

一般的なエラーメッセージを表示2
ただちにロックアウトする無効なユーザー名

ユーザー登録のないユーザーでログインした場合は直ちにアクセス元IPがロックされます。「特定のユーザー名を即座にロックする」にユーザーが設定されていてもこちらの設定が勝ちます。ロックされた場合は [WPセキュリティ] – [ダッシュボード] – [ロックされたIPアドレス] で解除が出来ます。

ログイン制限設定画面3
特定のユーザー名を即座にロックする

作成されていない、特定のユーザーをロックすることが出来ます。「ただちにロックアウトする無効なユーザー名」の設定が有効な場合はこちらの設定は意味がありません。ロックされた場合は [WPセキュリティ] – [ダッシュボード] – [ロックされたIPアドレス] で解除が出来ます。

メールで通知

ログインロックがかかったらその情報を指定したアドレスにメールしてくれます。下記がそのメールです。

あまりにも多くログインの試みに失敗したか、ユーザー名が無効なため、ロックダウンイベントが発生しました。

ユーザー名: *******

IP アドレス:  ***.***.***.***

IPアドレスの範囲:  ***.***.***.***

ロックアウト期間を見たり、ユーザーのロックを解除したりするにはサイトの WordPress 管理画面にログインしてください。

現在ロックアウトされている IP アドレス範囲

「Locked IP Addresses」リンクをクリックすると [WPセキュリティ] – [ダッシュボード] – [ロックされたIPアドレス] が表示されます。

Login Lockdown IP ホワイトリストを有効化

有効にすると、特定のIPアドレスをログインロックから除外出来ます。

ホワイトリストに登録する IP アドレスを入力

ホワイトリストとしてIPアドレスかIPアドレスの範囲を設定できます。範囲の場合はワイルドカード「*」で書くようです。ということは、範囲や、CIDR(クラスレスサブネットマスク)は使えないということですね。そこは厳しいかもしれないですね。

例 1: 195.47.89.*
例 2: 195.47.*.*
例 3: 195.*.*.*

失敗したログインの記録

失敗したログインの記録

ログインに失敗したIPアドレスの一覧が、「ユーザーID」「ユーザー名,」「日付」と共に表示されます。特定の記録をマウスホバーするとDeleteボタンが現れるので、個別に削除することが可能です。

失敗したログインの記録2

「Bulk Actions(一括操作)」から「Delete」を選択後「適用」をクリックすることで、選択したものをまとめて削除することもできます。

失敗したログインの記録1

記録をCSVにエクスポートしたり、すべてまとめて削除することも可能。

失敗したログインの記録3
強制的にログアウト

一定時間経過後に、管理画面へのログインを強制ログアウトさせることが出来ます。検証などの時はオフにして普段はオンにするなど、適宜変更すると良いと思います。ログアウト忘れ防止にもなります。

強制的にログアウト
アカウント利用ログ

ユーザーがログインした時間とログアウトした時間を一覧確認できます。こちらも選択したものを一括削除、個別に削除、CSVへのエクスポートが可能です。全削除は出来ません。

アカウント利用ログ1
アカウント利用ログ2
ログイン済みユーザー

現在ログイン中のユーザーを確認できます。対象ユーザーをマウスホバーすると「Force Logout」のリンクが表示されますが、これをクリックすると強制的ログアウトさせることが出来ます。

「データを更新」をクリックすることで最新のログイン状況に更新できます。

ログイン済みユーザー

スポンサーリンク

ユーザー登録

手動承認

ユーザー登録の手動承認は、WordPress自体の [設定] – [一般] – [だれでもユーザー登録ができるようにする] が有効になっている場合に利用できます。通常は、ユーザーがログイン画面からユーザー登録をしたら無条件に登録されますが、この機能を使うと管理者承認が必要な流れに変更となります。

新規登録の手動承認を有効にする

ユーザーがログイン画面からユーザー登録をした場合に、管理者承認が必要な流れとなるようにできます。

AIOWPS手動承認
実際のユーザー登録の流れ

実際に設定してみました。まずは、[設定] – [一般] – [だれでもユーザー登録ができるようにする] を有効にし設定を保存します。

AIOWPS手動承認設定の流れ1

[WPセキュリティ] – [ユーザー登録] – [手動承認] – [新規登録の手動承認を有効にする] を有効にし設定を保存します。

AIOWPS手動承認設定の流れ2

管理画面のログインで「登録」をクリックします。

AIOWPS手動承認設定の流れ3

「このブログに登録」のフォームに必要事項を入力し「登録」をクリックします。

AIOWPS手動承認設定の流れ4

ユーザー登録の承認待ちとなります。

AIOWPS手動承認設定の流れ5

管理者には下記のメールが届きます。

サイト「サイト名」の新規ユーザー登録:

ユーザー名: [申請ユーザー名]

メール: [メールアドレス]

[WPセキュリティ] – [ユーザー登録] – [手動承認] – [ユーザー登録の承認] 欄に申請中のユーザーが表示されます。対象ユーザーをマウスホバーすると「View(ユーザー設定)」「Approve(承認)」「Delete(無視して削除)」「Block IP(アクセス元IPをスパムとして永久にブロック)」のリンクが表示されます。

AIOWPS手動承認設定の流れ6
承認する場合の手順

上記画面で [view] をクリックします。ユーザーの設定画面に遷移しますので、適宜設定してください。

AIOWPS手動承認を承認する場合の手順1

次に [ユーザー登録の承認] の画面で [Approve] をクリックします。これで管理者の作業は終わりです。

AIOWPS手動承認を承認する場合の手順2

ユーザーには下記のメールが送信されます。これでユーザー登録と承認は完了です。

ユーザー名のアカウント:[ユーザー名]は現在有効です

ユーザー登録承認を削除する場合

[ユーザー登録の承認] の画面で [Delete] をクリックします。ユーザーにも管理者にも何も通知されません。これで完了です。

ユーザー登録をスパムと判定してアクセス元IPを永久ブロックする

[ユーザー登録の承認] の画面で [Block IP] をクリックします。

[WPセキュリティ] – [ダッシュボード] – [永久ブロックリスト] にブロックしたアクセス元IPが「registration_spam」という理由で表示されます。

AIOWPS手動承認をスパム判定としてブロックする1

この状態でブロックしたアクセス元IPを持つユーザーが再度アクセスすると「http://127.0.0.1」(locahost)にリダイレクトされます。

[ユーザー登録の承認] の画面を再度確認すると、IPアドレスの下に「blocked」の表示が追加されています。このままですと承認リストに残るので、「Delete」で削除してしまってください。[永久ブロックリスト] からは削除されません。

AIOWPS手動承認をスパム判定としてブロックする2
ユーザー登録をスパムと判定してアクセス元IPの永久ブロックを解除する

[WPセキュリティ] – [ダッシュボード] – [永久ブロックリスト] にアクセスし、対象のIPアドレスにマウスホバーすると「Unblock」リンクが表示されるので、これをクリックするとリストから削除されます。

AIOWPS手動承認をスパム判定としてブロックしたものを解除

CAPTCHA登録

CAPTCHAについては「reCAPTCHA(リキャプチャ)の概要とそれを使って悪意のある行為からWebサイトを守る方法」の記事を参照してください。

[WPセキュリティ] – [ユーザー登録] – [Captcha登録] – [登録ページの Captcha を有効化] を有効にすると、ログイン画面のユーザー登録画面にCAPTCHAによる試験が追加されます。下記が追加された画像です。CAPTCHA試験は画像だけと思っていたのですが、この試験はテキストで書かれた計算に回答する方式のようです。

ユーザー登録のCAPTCHA登録追加1

回答を間違うと下記エラーメッセージが表示されます。この試験には最大試行回数の制限はありませんでした。

ユーザー登録のCAPTCHA登録追加2

ユーザー登録ハニーポット

ハニーポットとは、わざと攻撃を受けやすいおとりのようなコンテンツを用意して、その部分にボットや攻撃者を誘引する手法です。攻撃をそちらにおびき寄せることで、本来のコンテンツを保護したり、悪意のある行動の分析や統計をおこなうためにも利用します。

AIOWPSでは、ユーザー登録ページに人間の目には見えない非表示の「ハニーポット」(inputボックス)を設置します。ボットは見た目ではなくコードを解析して攻撃してくるので、ボットには認識できるけれども人間の目には見えないという特性を利用します。ボットはユーザー登録フォームのすべての入力欄に入力しようとするので、ハニーポット用の入力欄にも入力して送信します。

登録フォームが送信されたときにこの入力欄に値を入力して送信してきた場合はボットの可能性が高いのでそのことをプラグインが検出したら、ボットをhttp://127.0.0.1(localhost)にリダイレクトさせます。

ソースコードを解析してみると確かに非表示になっているinputボックスがありました。具体的な内容については記載を控えます。

ハニーポットを有効にするには [WPセキュリティ] – [ユーザー登録] – [ユーザー登録ハニーポット] – [ユーザー登録ページでハニーポット機能を有効化する] を有効にするだけです。

ユーザー登録ハニーポット

データベースセキュリティ

データベースの接頭辞

WordPressのデータベース接頭辞を初期値のまま放置することのセキュリティリスクについては「DBのセキュリティ」の記事を参照してください。

WordPressのDBテーブル接頭辞は初期値で「wp_」ですが、このままですとセキュリティリスクが高く攻撃対象となりやすいので、ほかの推測されにくいものに変更する必要があります。

接頭辞が「wp_」になっている場合は下記画面に警告が出ますので、任意のものもしくは「ランダムに生成」のチェクを入れて自動生成し、「データベースの接頭辞を変更」をクリックして変更しましょう。変更が終わったら「現在のデータベース接頭辞」の表示も変更されます。

DBテーブル接頭辞の確認はこのプラグインでもできますが、「PhpMyAdmin」や、検証環境で「LocalbyFlywheel」を使用しているなら「Adminer」でも確認できます。気になる方は確認してみてください。

尚、データベースの接頭辞変更時には必ずDBを含めたWordpress全体のバックアップを行ってください。接頭辞の変更でDBが壊れてサイトが立ち上がらなくなる可能性は否めません。DBだけバックアップしても良いのですが、DBが壊れたらアクセス不能となる可能性も否めないため一から再構築が必要なケースがあります。

WordPressのフルバックアップはプラグインの利用が便利です。私なんかは「All-in-One WP Migration」を使っています。

データベースセキュリティ

ファイルシステムセキュリティ

ファイルのパーミッション

パーミッションについては「ファイルの属性(パーミッション)を見直す」の記事を参照してください。

パーミッションが適切に設定されていない場合はセキュリティリスクが高まります。この機能では、Wordpressを構成するファイルに適切でないパーミッションが設定されていた場合、警告が表示されてパーミッションを修正することが出来ます。

パーミッションが適切でない場合は下記のように「推奨パーミッションを設定」と表示されます。これをクリックすると改善されます。

ファイルのパーミッションの設定1

改善されると「推奨パーミッションを設定」ボタンが消えて、背景も緑に代わります。

ファイルのパーミッションの設定2

PHPファイル編集

PHPファイル編集機能を無効化
PHPファイル編集機能を無効化1

「PHPファイル編集機能を無効化」にすると、[外観] – [テーマエディター] と、[プラグイン] – [プラグインエディター] が非表示になります。具体的には下記の箇所です。

PHPファイル編集機能を無効化2
PHPファイル編集機能を無効化3

メニューから削除することで、正規のユーザーが誤って編集してしまったり、不正ログインがあった場合に編集されるリスクを軽減することが出来ます。

ただ、管理者権限で不正ログインされた場合且つ、不正ログイン者が人間である且つ、AIOWPSの存在を見つけて操作方法を理解している人、だった場合は、設定を解除したら編集出来てしまいますのであまり意味をなさないかもしれません。

不正ログイン者がボットだった場合はリスクを軽減できるということだと思います。

WP File Access

WPデフォルトのインストールファイルへのアクセスを防止

「WPデフォルトのインストールファイルへのアクセスを防止」の設定を有効にすると、WordPressのルートディレクトリに初期から配置されている「readme.html」「license.txt」「wp-config-sample.php」ファイルへのアクセスを防御してくれます。

これらのファイルは、実際には不要なファイルですので削除しても構いません。

残している場合は、これらファイルにはWordPressに関する情報など(バージョン情報など)が記載されているため、少しでもサイトの情報を外部に漏らすリスクを下げるために、非表示にすることをお勧めします。

これらファイルの中には、WordPressをバージョンアップすると再作成されるものもありますので、非表示設定にしておいた方が無難かもしれません。

WPデフォルトのインストールファイルへのアクセスを防止

ホストシステムログ

システムログを表示

error_logを管理画面上から確認することが出来ます。error_logは、wp-config.phpに明示的に出力する設定をしなければ初期値では出力されませんので、通常はクリックしても何も表示されないはずです。

システムログを表示

スポンサーリンク

ブラックリストマネージャー

ユーザーを禁止

IPまたはユーザーエージェントのブラックリストを有効化

「IPまたはユーザーエージェントのブラックリストを有効化」を有効にすると、IPアドレスもしくはIPアドレスの範囲、ユーザーエージェント、によるアクセス拒否の設定が出来ます。

ブラックリストマネージャー
IPアドレスを入力

拒否するIPアドレスまたは範囲を入力します。

ユーザーエージェントを入力

拒否するユーザーエージェントを入力します。

ユーザーエージェントとは、ユーザーがアクセスに使っているソフトウェア(ブラウザ)やプログラムのことで、HTTPヘッダのUser-Agentに格納されており、アクセスログやパケットキャプチャで確認することが出来ます。

例えば私の検証環境に自前のiPhoneでアクセスすると、アクセスログには下記のように表示されます。(Mozilla/5.0で始まる部分がユーザーエージェント情報でSafariでアクセスしていることがわかります)

{dst domain} {det ip} – – [28/Sep/2021:07:06:54 +0900] “GET /wp-content/themes/{access contents} HTTP/2.0″ 200 4678 ” {dst url}” “Mozilla/5.0 (iPhone; CPU iPhone OS 14_7_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.1.2 Mobile/15E148 Safari/604.1”

ユーザーエージェント指定のブラックリストがうまく動かないので原因を探ってみた

試しに上記ログのユーザーエージェントをブロックするために、ユーザーエージェントの欄に「Safari」と設定してiPhoneからアクセスしてみました。(実際にSafariをブロックする人はいないと思います。あくまで検証です。)

なぜか拒否されませんでした。この設定は.htaccessに直接書き込むらしいのでファイルを見てみたら、ユーザーエージェントの頭にハット「^」がついていました。

RewriteCond %{HTTP_USER_AGENT} ^Safari [NC] #ハット「^」がついている
 ↓
RewriteCond %{HTTP_USER_AGENT} Safari [NC] #ハットを消すとうまく動く
RewriteRule ^(.*)$ - [F,L]

勝手にハット「^」を付与して「ユーザーエージェントの頭にSafariと書いてあったら」という正規表現になってしまってました。.htaccessから手動でハット「^」を消して保存したら正しく403エラーになりました。

ということでどこで付与しているかコードを探ってみましたところ「wp-content/plugins/all-in-one-wp-security-and-firewall/classes/wp-security-utility-htaccess.php」に書いてありました。

//「^」ハットを付けてますね。
$rules .= "RewriteCond %{HTTP_USER_AGENT} ^" . trim($agent_sanitized); //316行目

じゃあ「.*Safari」と書けばいいんだな。良し!!と思うじゃないですか。そしたら今度はエスケープされました。

RewriteCond %{HTTP_USER_AGENT} ^\.\*Safari [NC] #ドットとアスタリスクがエスケープされている

再度コードを見てみたところ、quotemetaでメタ文字をクォート(. \ + * ? ^が対象)してました。。。。

$agent_escaped = quotemeta($agent); //311行目

バグなのか仕様なのかわかりませんが、ユーザーエージェントは普通に設定するとうまく動かないということですね。

ユーザーエージェントを設定してうまく動かない場合は.htaccessを直接修正するしかなさそうです。AIOWPSに専用のフックがあるなら操作できるかもしれませんが調べておりません。

ちなみに、RewriteCondとRewriteRuleについては下記ページが参考になります。