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

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

WordPress総合セキュリティプラグインAll In One WP Securityについて掘り下げる 2/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について掘り下げる 1/2」の続きです。

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

ファイアウォール

基本のファイヤーウォール規則

基本のファイヤーウォール規則1
基本的なファイアウォール保護を有効化

「基本的なファイアウォール保護を有効化」をすると、下記の制限を有効にできます。

  • .htaceessファイルへのアクセスを拒否することで保護します。
  • サーバーの署名を無効化します。
  • アップロードサイズを制限します (10MB)。
  • wp-config.php ファイルへのアクセスを拒否することで保護します。

設定を有効化すると.htaccessファイルに下記ルールが追加されます。ルールの意味は下記を参照してください。

#AIOWPS_BASIC_HTACCESS_RULES_START

#.htaccessファイルへのWebからのアクセスを全拒否。
#万が一パーミッションなどでアクセス可能な状態になっていた場合ここで拒否してくれる。
#レンタルサーバーなどはそもそもユーザーが触れない設定でアクセス拒否にしている場合もある。
#「mod_authz_core」モジュールは、認証されたユーザーがWebサイトの一部へのアクセスを許可または拒否できるようにするコア認証機能です。
<Files .htaccess>
<IfModule mod_authz_core.c>
Require all denied
</IfModule>
<IfModule !mod_authz_core.c>
Order deny,allow
Deny from all
</IfModule>
</Files>

#サーバー署名の無効化。403エラーなどで画面最下部にApacheのサーバーバージョンなどの表示を非表示にする。
ServerSignature Off

#ファイルのアップデート上限(1024バイト計算なので262144000 / 1024 / 1024 = 250MB)
#250MB以上に設定すると250MBが上限なので勝手に250MBまで下げられます。
#250MBに設定した例
LimitRequestBody 262144000

#.htaccessファイルへのWebからのアクセスを全拒否。
#万が一パーミッションなどでアクセス可能な状態になっていた場合ここで拒否してくれる。
#レンタルサーバーなどはそもそもユーザーが触れない設定でアクセス拒否にしている場合もある。
<Files wp-config.php>
<IfModule mod_authz_core.c>
Require all denied
</IfModule>
<IfModule !mod_authz_core.c>
Order deny,allow
Deny from all
</IfModule>
</Files>

「ServerSignature Off」を設定した場合は、403エラーの例では一番下の情報が非表示になります。

基本的なファイアウォール保護を有効化SignatureON

このように消えます。

基本的なファイアウォール保護を有効化SignatureOFF
最大ファイルアップロードサイズ (MB)

アップロードサイズの制限はMB単位で設定でき、空欄だと10MBが設定されます。上限は250MBとなっているようで、それ以上設定したら勝手に250MBに書き換えられました。

コードを見てみると確かに250MB以上の時は250MBに書き換えています。

$max_allowed = apply_filters( 'aiowps_max_allowed_upload_config', 250 ); // Set a filterable limit of 250MB
$max_allowed = absint($max_allowed); //値を負ではない整数に変換します。

if($upload_size > $max_allowed) {
    $upload_size = $max_allowed;
} else if(empty ($upload_size)) {
    $upload_size = 10;
}
            
XML-RPCへのアクセスを完全にブロック

XML-RPCのセキュリティについては下記記事を参照してください。XML-RPCを無効化できます。無効化する場合には、プラグインやWordpressの機能がXML-RPCを完全に使用していないことを確認してから設定してください。

.htaccessファイルに書き込んで制御するようなので、追加された設定を確認してみました。xmlrpc.phpへのアクセスを拒否することでXML-RPCを使えないようにしているようです。

<Files xmlrpc.php>
<IfModule mod_authz_core.c>
Require all denied
</IfModule>
<IfModule !mod_authz_core.c>
Order deny,allow
Deny from all
</IfModule>
</Files>
基本のファイヤーウォール規則2
XML-RPCのピンバック機能を無効化

ピンバックについては下記記事を参照してください。ピンバックを無効にするには設定をオンにしてください。

XML-RPC

debug.log ファイルへのアクセスをブロック

debug.logファイルへのWebからのアクセスを全拒否。尚debug.logは、wp-config.phpに明示的に出力する設定をしなければ初期値では出力されません。

スポンサーリンク

追加ファイヤーウォール規則

インデックスビューを無効化

ブラウザでアクセスすると、配置されているファイルの一覧が下記のように表示されたのを見たことが無いでしょうか?これがインデックスビューです。この表示が出来るということは、どんなファイルが配置されているか筒抜けになりセキュリティ上非常にまずいので、非表示にしましょう

ディレクトリ内容のリスティング(インデックスビュー)

設定を有効化すると.htaccessファイルに下記が追加されます。

Options -Indexes
TRACEとTRACKを無効化

XST(クロスサイトトレーシング)は、XSS(クロスサイトスクリプティング)とHTTPのTRACEメソッドを利用してリクエストヘッダを取得しようという攻撃です。現在はブラウザ自体で対策されているので攻撃としては受ける可能性はほぼ無いと言ってよいでしょう。ただ、念には念をということで機能がついているのかもしれませんので、気になる方は有効にしてください。

XSTについては下記サイトに詳しく書いてありました。ご参考までに。

TRACEメソッドは一般的ですが、TRACKメソッドはMicrosoft IISの独自実装です。ただ、これもIIS6からは実装されていないようなので、特段気にしなくても良いかもしれません。これについても念のためという感じですね。IISのTRACKについては詳しくは下記が参考になると思います。

設定を有効化すると.htaccessファイルに下記が追加されます。 HTTPリクエストメソッドにTRACEかTRACKが入っているすべてのアクセスを、RewriteRuleで[F]と書いてあるので403Forbiddenを表示しなさいという設定です。

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
RewriteRule .* - [F]
</IfModule>
プロキシ経由のコメント投稿を禁止

悪意のあるコメント投稿はプロキシサーバーを経由してくることが多いという前提で、HTTPヘッダにプロキシを経由してきている情報が書かれていた場合は、403Forbiddenを表示させるよう出来る設定です。

ただ、すべてのアクセスを対象にするのではなく、WordPressで投稿にコメントすると必ずwp-comments-post.phpへPOST リクエストが送られるので、wp-comments-post.phpへアクセスが来たものを対象にという条件も付いています。

設定を有効化すると.htaccessファイルに下記が追加されます。

#対象のヘッダが「!^$」だった場合且つwp-comments-post.phpへのアクセスだったら403エラーを表示
#正規表現で「!^$」は空文字じゃないという意味
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_METHOD} ^POST
RewriteCond %{HTTP:VIA} !^$ [OR]
RewriteCond %{HTTP:FORWARDED} !^$ [OR]
RewriteCond %{HTTP:USERAGENT_VIA} !^$ [OR]
RewriteCond %{HTTP:X_FORWARDED_FOR} !^$ [OR]
RewriteCond %{HTTP:X_FORWARDED_HOST} !^$ [OR]
RewriteCond %{HTTP:PROXY_CONNECTION} !^$ [OR]
RewriteCond %{HTTP:XPROXY_CONNECTION} !^$ [OR]
RewriteCond %{HTTP:HTTP_PC_REMOTE_ADDR} !^$ [OR]
RewriteCond %{HTTP:HTTP_CLIENT_IP} !^$
RewriteRule wp-comments-post\.php - [F]
</IfModule>

各HTTPヘッダの意味は下記が参考になります。

不正なクエリー文字列を拒否

プラグインの説明を読むと、

この機能は .htaccess ファイルにルールを記述し、XSS を利用したサイトへの悪意のある文字列攻撃を防ぎます。

と書いてあります。何をを言っているのかわからかったので実際に有効にして.htaccessファイルを見てみました。下記が有効にした特の.htaccessファイルです。

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{QUERY_STRING} ftp:     [NC,OR]
RewriteCond %{QUERY_STRING} http:    [NC,OR]
RewriteCond %{QUERY_STRING} https:   [NC,OR]
RewriteCond %{QUERY_STRING} mosConfig [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(globals|encode|localhost|loopback).* [NC,OR]
RewriteCond %{QUERY_STRING} (\;|'|\"|%22).*(request|insert|union|declare|drop) [NC]
RewriteRule ^(.*)$ - [F,L]
</IfModule>

RewriteCondに「QUERY_STRING」とあるので、URLのパラメータに指定の文字列が入っていたら403エラーを表示しなさいということだと思います。

つまり、これら文字列が「QUERY_STRING」に入っていたら、悪意のあるクエリーである可能性が高いので、対策をしますよということのようです。

因みに「QUERY_STRING」とは、下記のようにURLの?以降についているパラメータの事で、パラメータは名前と値をイコールでつなげたセットで送信します。さらにパラメータの後ろに&を付けることで、複数のパラメータを送信することが可能です。アクセスのついでに値をつけてWebサーバーに通知することで、その値によって表示するページを決定したり変化させる事が出来ます。

https://ドメイン?name1=value1&name2=value2&name3=value3・・・・・・・・

尚、これらのクエリ文字列の中にはプラグインやテーマに使用されるものがあるため、設定した途端にWebページにも管理画面にもアクセスできなくなる可能性があるので、この機能を適用する前には.htaccessファイルのバックアップを取得することを強くお勧めしますとのことです。

このクエリ文字列はどうやって選定されたのだろうと疑問が出ると思いますが、 セキュリティ専門の高度なエンジニアが選定したのだと思いますので、私にはわかりません。そもそも調べるのに相当時間がかかるので調べてません。気になる方は調べてみてください。

基本的には、設定して問題がでなければそのままでOKで良いと思います。

高度な文字列フィルターを有効化

プラグインの説明を読むと、

これは、クロスサイトスクリプティング (XSS) から来るサイトへの悪意のある文字列攻撃を防ぐための高度な文字列フィルターです。この設定は、一般的な悪意のある文字列パターンとエクスプロイトにマッチし、クエリーを試みようとするハッカーに403エラーを発生させます。

と書いてあります。

エクスプロイトとは、脆弱性をついてコンピュータを攻撃する手段のことです。攻撃の為に作成されたスクリプトやプログラムのことをエクスプロイトコードと言います。

下記はこの機能を有効にしたときのコードですが、これらの文字列がURLに含まれていると「一般的な悪意のある攻撃」や「エクスプロイト」である可能性があるので、403エラーを返しなさいということですね。

これら文字列がどうやって選定されたのか?という疑問が出ると思いますが、これも「高度な文字列フィルターを有効化」同様、セキュリティ専門の高度なエンジニアが選定したのだと思います。気になる方は調べてみてください。

基本的には、設定して問題がでなければそのままでOKで良いと思います。

この機能も設定するとアクセス不能になる可能性があるため、設定前に.htaccessのバックアップが強く推奨されています。

<IfModule mod_alias.c>
RedirectMatch 403 \,
RedirectMatch 403 \:
RedirectMatch 403 \;
RedirectMatch 403 \=
RedirectMatch 403 \[
RedirectMatch 403 \]
RedirectMatch 403 \^
RedirectMatch 403 \`
RedirectMatch 403 \{
RedirectMatch 403 \}
RedirectMatch 403 \~
RedirectMatch 403 \"
RedirectMatch 403 \$
RedirectMatch 403 \<
RedirectMatch 403 \>
RedirectMatch 403 \|
RedirectMatch 403 \.\.
RedirectMatch 403 \%0
RedirectMatch 403 \%A
RedirectMatch 403 \%B
RedirectMatch 403 \%C
RedirectMatch 403 \%D
RedirectMatch 403 \%E
RedirectMatch 403 \%F
RedirectMatch 403 \%22
RedirectMatch 403 \%27
RedirectMatch 403 \%28
RedirectMatch 403 \%29
RedirectMatch 403 \%3C
RedirectMatch 403 \%3E
RedirectMatch 403 \%3F
RedirectMatch 403 \%5B
RedirectMatch 403 \%5C
RedirectMatch 403 \%5D
RedirectMatch 403 \%7B
RedirectMatch 403 \%7C
RedirectMatch 403 \%7D
# COMMON PATTERNS
Redirectmatch 403 \_vpi
RedirectMatch 403 \.inc
Redirectmatch 403 xAou6
Redirectmatch 403 db\_name
Redirectmatch 403 select\(
Redirectmatch 403 convert\(
Redirectmatch 403 \/query\/
RedirectMatch 403 ImpEvData
Redirectmatch 403 \.XMLHTTP
Redirectmatch 403 proxydeny
RedirectMatch 403 function\.
Redirectmatch 403 remoteFile
Redirectmatch 403 servername
Redirectmatch 403 \&rptmode\=
Redirectmatch 403 sys\_cpanel
RedirectMatch 403 db\_connect
RedirectMatch 403 doeditconfig
RedirectMatch 403 check\_proxy
Redirectmatch 403 system\_user
Redirectmatch 403 \/\(null\)\/
Redirectmatch 403 clientrequest
Redirectmatch 403 option\_value
RedirectMatch 403 ref\.outcontrol
# SPECIFIC EXPLOITS
RedirectMatch 403 errors\.
RedirectMatch 403 config\.
RedirectMatch 403 include\.
RedirectMatch 403 display\.
RedirectMatch 403 register\.
Redirectmatch 403 password\.
RedirectMatch 403 maincore\.
RedirectMatch 403 authorize\.
Redirectmatch 403 macromates\.
RedirectMatch 403 head\_auth\.
RedirectMatch 403 submit\_links\.
RedirectMatch 403 change\_action\.
Redirectmatch 403 com\_facileforms\/
RedirectMatch 403 admin\_db\_utilities\.
RedirectMatch 403 admin\.webring\.docs\.
Redirectmatch 403 Table\/Latest\/index\.
</IfModule>

6Gブラックリスト/ファイアウォールルール

6Gブラックリストや5Gブラックリストとは、悪意のある攻撃を遮断する方法リスト化したもので、この機能を有効にすると、.htaccessファイルに悪意のある攻撃を遮断してくれる設定が追加され、アクセスを自動的に遮断してくれます。悪意のある攻撃を一々自分で調査理解して個別に対策を設定するなんてことは現実的に不可能です。このブラックリストは代わりに悪意のあるアクセスや攻撃からサイトを保護してくれます。

6G5GのGはGeneration(世代)のことで、もちろん新しいほうが機能面の更新/改良が成されています。サイトサービスの提供に問題が出ない限りは最新のものを使う方が良いです。この記事を書いている2021/9/30時点でG7のブラックリストが出ていますが、AIOWPSには実装されていないようです。そのうち実装されるのではないでしょうか。

このブラックリストはperishablepress.comが開発提供していますので、そちらも見てみると良いかもしれません。

悪意のある攻撃も日進月歩ですからこのブラックリストでも遮断できない攻撃があるということも覚えておいてください。

興味のある人は設定有効前後の.htaccessファイルを比較して見てみると良いかもしれません。

参考までに、5G~7Gまでの公式ページを載せておきます。

6Gブラックリスト/ファイアウォールルール
6Gファイアウォール保護を有効化

6Gブラックリストで悪意のある攻撃からサイトを保護してくれます。

レガシーな5Gファイアウォール保護を有効化

5Gブラックリストで悪意のある攻撃からサイトを保護してくれます。

スポンサーリンク

オンラインのボット

偽のGooglebotsをブロック

偽のGooglebotからのアクセスを遮断します。この機能は、ボットのユーザーエージェント情報に文字列“Googlebot”が含まれているかどうかを確認します。ただ、“Googlebot”が含まれていたとしてもなりすましの可能性もあるため、なりすましかどうかの確認手順を踏んで、偽物だとわかった場合は遮断します。

どのように遮断しているかwp-security-bot-protection.phpファイルを見てみたところ、Googleが紹介している「Googlebot かどうかの確認」の方法を実装していました。

直リンク防止

画像の直リンクを防止する

他のサイトが、自サイトに掲載されている画像に対して直にリンクを張って表示させる行為を防ぎます。直にリンクを張るとサーバーの帯域やリソースを逼迫しかねないので、この設定を有効にすると.htaccessファイルに防御する設定が追加されます。

設定を有効にすると.htaccessファイルに下記コードが追加されます。各行の意味はコメントを見てください。

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_REFERER} !^$ #リンク元が空でなかったら且つ
RewriteCond %{REQUEST_FILENAME} -f #リクエストしているファイルが存在している場合且つ
RewriteCond %{REQUEST_FILENAME} \.(gif|jpe?g?|png)$ [NC] #リクエストしているファイル拡張子がマッチする且つ
RewriteCond %{HTTP_REFERER} !^http(s)?: #ドメイン名 [NC] #リンク元が自サイトのドメインではなかったら
RewriteRule \.(gif|jpe?g?|png)$ - [F,NC,L] #記載の拡張子にマッチする画像取得に対して403エラーを返す
</IfModule>

404検出

404エラー(Not Found)は、存在しないページにアクセスした際に発生します。正常なアクセスで発生する場合には全く問題ありません。しかし、悪意のあるボットが攻撃対象を見つけるなどの為に、同じIP アドレスから存在しない様々なページへ短時間にアクセスしようとすると404エラーが頻発します。

404エラー検出と IP ブロック

この機能を有効化すると、サイトで発生するすべての 404 イベントを監視できます。ログに記録されたアクセス元IPの中から、悪意のあるものを手動で指定した時間ブロックすることが出来ます。

「IPアドレスごとに何回404エラーが発生したか?」を基準に自動で永久的ブロックすることもできますが、別途有料の「Smart404 Blocking Addon」が必要です。

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

ロックアウトしたIPアドレスを何分間ブロックするか設定できます。

404ロックアウト転送 URL

ブロック中のIPアドレスがアクセスしてきた際にリダイレクトするURLを指定します。初期値の「http://127.0.0.1」のままでよいと思います。

404イベントログ

404イベントが発生すると記録されるようです。が、いくら404エラーを起こしても記録されませんでした。どなたか何かご存じでしたら教えてください。

カスタムルール

カスタムルールを使うと.htaccessに独自のルールを挿入することが出来ます。

ファイアウォールカスタムルール
カスタム.htaccessルールを有効化

.htaccessファイルへのカスタムルール書き込みを有効化。

トップにカスタムルールを配置

.htaccessファイルの先頭ではなく、AIOWPSで追加するルールの中の一番上にカスタムルールを追記する。

カスタム.htaccessルールを入力

挿入したいルールを記載する。

注意

.htaccessファイルの編集によってはサイトへのアクセスが不能になる可能性があります。十分な知識を持って編集されることをお勧めします。できれば開発環境で検証してから実施した方が良いです。変更の前には、.htaccessファイルをバックアップしてから作業をすることをお勧めします。

総当たり攻撃

ログインページの名称変更

ログインページの名前変更機能を有効化

WordPress管理画面のURLを初期値から変更することが出来るようになります。初期値をそのまま使用するセキュリティリスクについては下記記事を参照してください

ログインページの名称変更
ログインページ URL

管理画面ののURLは初期値で「https://ドメイン名/wp-admin」となりますが、「wp-admin」を好きな名称に変更できます。セキュリティ上変更することをお勧めします。

Cookieベースの総当たり攻撃の防止

この機能は、管理画面へのブルートフォースアタック(総当たり攻撃)から守ってくれます。秘密の言葉を含んだCookieを持っていないユーザーのアクセスを.htaccessで拒否します。Cookieを持っていないユーザーは、秘密の言葉をURLパラメータに付与することでアクセス可能です。

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

「ログインページの名称変更」と「Cookieベースの総当たり攻撃の防止」の差は何か

Cookieベースの総当たり攻撃の防止の説明文翻訳にはこう書いてあります。

総当たり攻撃は、ハッカーがユーザー名とパスワードの正しい組み合わせを推測することに成功するまで、数多く試行されます。悪意のある自動ロボットを介してサイトで同時に多くのログイン試行が発生する可能性があり、これはサーバーのメモリとパフォーマンスにも悪影響を及ぼします。このタブの機能は、.htaccessレベルでブルートフォースログイン攻撃の大部分を阻止し、WPログインページの保護をさらに強化し、システムがPHPコードを実行して処理する必要がないため、サーバーの負荷を軽減します。ログイン試行。

AIOWPSのCookieベースの総当たり攻撃の防止

つまり、URL変更だけだとURLがわからなくてもアクセスされたら結局404エラーを出すのでWebサーバーのリソースを食う(エラーを返すのはWebサーバーなので)。Cookieベースの総当たり攻撃の防止を使うと.htaccessで拒否できるのでリソースの消費が少なくて済む。のように私には読み取れました。攻撃が増えてWebサイトが重いとか、攻撃によって404エラーログが頻発して鬱陶しいなどの時に、Cookieベースを試してみるという感じでだと思います。

Cookieベースの総当たり攻撃の防止
総当たり攻撃防止機能を有効化

設定を有効にするとログインページを総当たり攻撃から保護してくれます。設定の前には秘密の言葉を必ず変更してください。正しく設定出来たら下記のようなメッセージが出力されるます。Cookieを持たない人のログインURLが「https://ドメイン/?秘密の言葉=1」に変更になるので、忘れずにブックマークかメモをしましょう。

総当たり攻撃防止機能を有効化2

設定を有効化するには、有効化操作を行うコンピュータでCookieが有効になっている必要があります。そもそもWordPress自体Cookieが有効でないとログインできないので無効になっていることはほぼ無いと思います。

設定有効後のアクセス方法は2種類です。

  • この設定を行ったコンピュータにはCookieが保存されるので通常の「https://ドメイン/wp-admin or wp-login.php」でアクセス可能
  • その他のコンピュータは「https://ドメイン/?秘密の言葉=1」でアクセス可能

有効化されると.htaccessに保護用のルールが追記されます。意味は下記コメントを参照してください。

RewriteEngine On
RewriteCond %{REQUEST_URI} (wp-admin|wp-login) #リクエストURIに指定の文字列が入っていたら且つ
RewriteCond %{HTTP_COOKIE} !秘密の言葉= [NC] #秘密の言葉で設定したクッキーが無かったら且つ
RewriteCond %{HTTP_COOKIE} !aiowps_cookie_test_********= [NC] #この名前で始まるクッキーがなかったら
RewriteRule .* http://127.0.0.1 [L] #localhostにリダイレクト
設定の補足

「ログインページの名称変更」と「Cookieベースの総当たり攻撃の防止」はどちらか一方しか有効化できません。片方が有効の時にもう片方を有効にすると、他方が自動的に無効になります。

アクセスできなくなったら

Cookieを削除してしまったり、URLを忘れたなどでアクセスできなくなった場合は、.htaccessファイルから対象のルールを削除すれば復旧します。

秘密の言葉

クッキーやURLに使われる秘密の言葉を設定します。推測されにくい英数字を指定してください。

余談ですが、秘密の言葉の初期値には「aiowps_secret」が設定されていますが、そのままで機能を有効にすると「設定は保存されていません。秘密の単語は英数字のみ、つまり文字や数字のみで構成されている必要があります。」というエラーがでます。英数字しか使えないのに、なぜ初期値に使えない文字が入っていました。昔の何かの名残でしょうか?

秘密の言葉初期値をそのまま使ったときのエラー
転送先URL

拒否されたユーザーがリダイレクトされるURL。基本的には初期値のhttp://127.0.0.1のままでよいと思います。自分のURLにするとWebサーバーのリソースを食うのでやめた方が良いでしょう。そもそもこの機能の意味がなくなります。

サイトにパスワードで保護された投稿またはページがある

投稿ページや固定ページにはパスワード保護機能がついています。これにより公開する人を限定することが出来ます。下記画像のように、ページ右メニューから [投稿] – [表示状態] – [パスワード保護] を選択することで実装出来ます。

サイトにパスワードで保護された投稿またはページがある1

パスワード保護を実装した場合、ページには下記のようにパスワード入力欄が現れます。入力することでコンテンツが表示されますが、「総当たり攻撃防止機能を有効化」した状態でパスワード認証を確定すると、「転送先URL」に転送されてしまいます。

「サイトにパスワードで保護された投稿またはページがある」を有効にすると、これを回避するルールを.htaccessファイルに追加してくれます。

サイトにパスワードで保護された投稿またはページがある2

設定を有効にすると下記設定が.htaccessファイルに追加されます。

RewriteEngine On
RewriteCond %{REQUEST_URI} (wp-admin|wp-login)
RewriteCond %{QUERY_STRING} !(action\=postpass) #この行が追加されます。
RewriteCond %{HTTP_COOKIE} !秘密の言葉= [NC]
RewriteCond %{HTTP_COOKIE} !aiowps_cookie_test_********= [NC]
RewriteRule .* http://127.0.0.1 [L]

ページにパスワード認証を付けると下記のように認証formが追加されます。そのformでsubmitすると、postpassというアクションが実行されます。この設定はpostpassアクションを除外する設定となっています。

<form action="https://ドメイン/wp-login.php?action=postpass" class="post-password-form" method="post">
	<p>このコンテンツはパスワードで保護されています。閲覧するには以下にパスワードを入力してください。</p>
	<p>
    <label for="pwbox-13">パスワード: <input name="post_password" id="pwbox-13" type="password" size="20" /></label>
    <input type="submit" name="Submit" value="確定" />
  </p>
</form>

設定を有効化すると、パスワード認証後正しくページが表示されると思います。

サイトにAJAXを使用するテーマまたはプラグインがある

設定を有効にすると下記設定が.htaccessファイルに追加されます。

RewriteEngine On
RewriteCond %{REQUEST_URI} (wp-admin|wp-login)
RewriteCond %{REQUEST_URI} !(wp-admin/admin-ajax.php) #この行が追加されます
RewriteCond %{HTTP_COOKIE} !secretgogo= [NC]
RewriteCond %{HTTP_COOKIE} !aiowps_cookie_test_iswim60kkb= [NC]
RewriteRule .* http://127.0.0.1 [L]

「admin-ajax.php」は、WordPressがAjaxを実行する際に利用するファイルです。Ajaxを使う必要があるWordPressの機能やプラグインがあった場合ブロックしないようにすることが出来ます。

ログインCAPTCHA

CAPTCHAやGoogleのreCaptchaについては「reCAPTCHA(リキャプチャ)の概要とそれを使って悪意のある行為からWebサイトを守る方法」の記事に詳しくまとめておりますので、是非参照してください。

AIOWPSのCAPTHCAは、画像の文字を読み取って入力するのではなく、下記のように表示された計算式の答えを入力するパターンです。

AIOWPAのログインCAPTCHA
ログインCAPTCHA1
Google reCaptchaをデフォルトとして利用する

reCaptchを有効にできます。この設定だけは表示されません。以降のCAPTCHAをどの箇所で有効にするかの設定を合わせてオンにすることで表示されます。

利用できるバージョンはv2のnorobotだけです。他のパターンも試してみましたところ、v2のinvisibleのキーではnorobotで表示され、v3は下記エラー表示となりました。

AIOWPSにGoogle reCAPTCHAのv3を設定してみた結果

v2 invisibleかv3を利用したい方は、AIOWPSではなくて他のプラグインをお勧めします。下記記事を参考にしてみてください。

ログインページでCAPTCHAを有効化

管理画面のログインフォームにCAPTCHAもしくは、「Google reCAPTCHAをデフォルトとして利用する」を有効にしているとreCaptcha V2 norobotを表示します。

ログインCAPTCHA2
パスワード再設定フォームでCAPTCHAを有効化

管理画面のログインフォームの「パスワードをお忘れですか ?」リンクの先にあるパスワードのリセットページに、CAPTCHAもしくは、「Google reCAPTCHAをデフォルトとして利用する」を有効にしているとreCaptcha V2 norobotを表示します。

カスタムログインフォームでCAPTCHAを有効化

wp_login_form関数を使ったカスタムログインフォームに、CAPTCHAもしくは、「Google reCAPTCHAをデフォルトとして利用する」を有効にしているとreCaptcha V2 norobotを表示します。

ログインのホワイトリスト

管理画面へのアクセスを許可するIPアドレスを指定できます。この設定を有効にすると、許可したIPアドレス以外のアクセスは拒否されます。セキュリティとしては非常に安心できる設定です。アクセス元IPが常に固定されている場合はこの設定を有効にすることを強くお勧めします。

ログインのホワイトリスト
IPホワイトリストを有効化

IPホワイトリストを有効にします。

現在のIPアドレス

現在自分が使用しているアクセス元グローバルIPアドレスを調べて表示してくれます。このアドレスをホワイトリストに追加すれば、今自分がアクセスしている場所からはアクセスが許可されます。

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

ホワイトリストには、IPv4アドレス、IPv4アドレス範囲、IPv6アドレス、IPv6アドレス範囲(現在未対応)が利用できます。

IPv4アドレス範囲を指定するには、ワイルドカード “*” を使用します。ワイルドカードを使うための許容される方法の例は下記です。オクテットごとのワイルドカード指定しかできないようです。CIDR(サブネット化)やRangeなどは使えません。ここは微妙ですね。

195.47.89.*
195.47.*.*
195.*.*.*

IPv6アドレス範囲やワイルドカードは現在対応していないと記載があるので下記のような書き方は対応していないようです。検証していないので真偽は不明です。

2205:0:1ca2:810d::

ハニーポット

ログインフォームのハニーポットを有効化

[WPセキュリティ] – [ユーザー登録] – [ユーザー登録ハニーポット] と同じ機能をログインフォームに追加できます。ハニーポットについては「ユーザー登録ハニーポット」の章をご覧ください。

スポンサーリンク

スパム防止

コメントスパム

コメントスパム
コメントフォームのCAPTCHAを有効化

コメント投稿欄に下記のようにCAPTCHAを追加します。CAPTCHAについは下記記事も参考にしてみてください。

メントフォームのCAPTCHAを有効化
スパムボットからのコメント投稿をブロック

大概のスパムコメントは自動化されたボットによる投稿がほとんどです。この機能を有効にすると、不正な投稿元ドメインからの投稿をブロックするルールを.htaccessに追加してくれます。追加されるルールについは下記を参照してください。

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_METHOD} POST #HTTPリクエストメソッドがpost且つ
RewriteCond %{REQUEST_URI} ^(.*)?wp-comments-post\.php(.*)$ #wp-comments-post.phpの呼び出し且つ
RewriteCond %{HTTP_REFERER} !^http(s)?://自ドメイン [NC,OR] #投稿元のドメインが自ドメイン且つ
RewriteCond %{HTTP_USER_AGENT} ^$ #ユーザーエージェントが空欄
RewriteRule .* http://127.0.0.1 [L] #の場合は、ローカルホストにリダイレクトする
</IfModule>

コメント投稿は、自サイトの投稿フォームからなされることがほとんどであるため、投稿元のドメインが自サイトでない場合は拒否するという防御をとっています。

コメントスパムのIPモニタリング

スパムコメントのIPを自動ブロック

この設定を有効化すると、スパムコメントの投稿元と判定されたIPアドレスを自動または手動でブロックすることが出来ます。

どういう風にスパム判定されブロックされるかというと設定画面に下記記載がありました。

コメントは通常 Akismet プラグインによって、または管理者がコメント管理画面から手動でスパムとマークされます。

AIOWPS設定画面

かなりわかりにくいですね。噛み砕きますと、スパムコメントのブロック対象IPになるには、まずはWordPress自体のコメント欄でスパムコメントフォルダ [コメント] – [スパム] に振り分けられなければいけません。じゃあどうすれば振り分けられるかと言いますと、Akismetプラグインでスパム判定してもらうか、自分でコメントをスパム判定しなければいけません。

Akismetプラグインが導入されている場合は自動でスパム判定がされて [コメント] – [スパム]に振り分けられます。Akismetについては下記記事を参考にしてください。

スパムコメントのIPを自動ブロック2

Akismetがスパム判定をしなかったもしくはAkismetが入っていない場合は、WordPress自体のコメント管理欄 [コメント] で自分がスパムだと思ったコメントをマウスホバーすると、[スパム] 判定ボタンが出るのでそれをクリックすると、スパムフォルダに振り分けられます。

スパムコメントのIPを自動ブロック1

スパムフォルダに振り分けられて、はじめてそのスパムコメントをAIOWPSの自動ブロック対象IPとして認識させることが出来ます。

スパムコメントの最小回数

スパムフォルダに振り分けられたスパムコメントを投稿した投稿元IPが合計何件になったかで自動的にIPアドレスをブロックします。例えば”2″と設定したら”3″件目のスパムコメント判定からブロックされます。

ブロック判定された場合は、「コメントスパムのIPモニタリング」ページの上部に下記のようなメッセージが表示されます。

ブロックされたIPは、[WPセキュリティ] – [ダッシュボート] – [永久ブロックリスト] にも追加されます。

スパムコメントの最小回数
スパムコメントのブロック解除

ブロックを解除したい場合は、 [WPセキュリティ] – [ダッシュボート] – [永久ブロックリスト] にアクセスし、対象のIPアドレスをマウスホバーしたら[Unblock]ボタンが現れますので、これをクリックすれば解除できます。解除したいIPアドレスにチェックを入れて、[Bulk Actions]から[Unblock]を選択後[適用]をクリックすることで、まとめて解除することもできます。

IPあたりのスパムコメントの最小数

そのアクセス元IPが何回スパム判定を受けたら「スパマーのIPアドレス結果」欄に表示するか設定できます。

スパマーのIPアドレス結果

スパムコメント欄に振り分けられたアクセス元IPが「IPあたりのスパムコメントの最小数」に設定した数値に達したらここに表示されます。

手動で対象IPアドレスをブロックしたい場合は、マウスホバーすると[Block]ボタンを現れるのでクリックすればブロックされます。

既にブロックされている場合は、「ステータス」欄に「blocked」と表示されます。解除したい場合は[WPセキュリティ] – [ダッシュボート] – [永久ブロックリスト]から可能です。

まとめてブロックしたい場合は、対象IPアドレスのチェックボックスをオンにして、[Bulk Actions] から [Block] を選択後 [適用] をクリックしてください。

スパマーのIPアドレス結果

BuddyPress

BuddyPressをインストールしていると登録フォームにCAPTCHAが使えるようです。私は使っていないので詳細不明です。

BuddyPress

BByPress

BBPressをインストールしていると新規トピックにCAPTCHAが使えるようです。私は使っていないので詳細不明です。

BByPress

スキャナー

ファイルの変更検知

WordPressを構成するファイルに変更が加わっていた場合に検知することが出来ます。更新した覚えが無いのにファイルが更新されていた場合、不正改竄の恐れがあります。定期的にスキャンすることをお勧めします。

ファイルの変更検知1
手動ファイル変更検知スキャン

今すぐにファイルの変更スキャンを実行することが出来ます。始めて手動スキャンする場合は下記メッセージが出力されます。

手動ファイル変更検知スキャン1

2回目以降の手動スキャンでファイルの変更を検知した場合は下記メッセージが出力されます。

手動ファイル変更検知スキャン2

詳細を表示のボタンをクリックすると下記のように結果が表示されます。ファイルの「追加」「削除」「変更」を検知出来ます。

手動ファイル変更検知スキャン3
手動ファイル変更検知スキャン4
最後にスキャンしてからの変更結果を表示

最後のスキャンで検知された変更点を再度表示することが出来ます。

自動ファイル変更検知スキャンを有効化する

ファイルの変更検知スキャンを自動で定期的に実行することが出来ます。

ファイルの変更検知2
スキャン時間の間隔

自動スキャンの実行間隔を指定できます。「時」「日」「週」から指定できます。

無視するファイルの種類

スキャンの対象から除外するファイルを設定できます。ファイルタイプや拡張子を改行で区切って設定します。

無視するファイルとディレクトリ

スキャンの対象から除外するディレクトリを設定できます。「cache/config/master.php」のように、ディレクトリ内の特定のファイルという指定もできます。改行で区切って設定します。

変更を検知したらメールする

ファイルの変更が検知されたらメールに結果を送信することが出来ます。複数アドレスを改行して指定することが出来ます。

スポンサーリンク

マルウェアスキャン

マルウェアとは悪意のあるソフトウェア(トロイの木馬、アドウェア、ワーム、スパイウェア)の総称です。マルウェアからサイトを保護するこの機能は有料のようです。

マルウェアスキャン

メンテナンス

訪問者ロックアウト

フロントエンドのロックアウト有効化

サイトの長時間メンテナンスなどで、管理者としてログインしているユーザー以外のサイトアクセスを阻止したい場合に利用できます。

メッセージを入力

ロックアウトされたユーザーに表示するメッセージを設定できます。

メンテナンス

コピープロテクション

コピープロテクションを有効にする

管理者としてログインしているユーザー以外に対して、Webサイトのテキストコンテンツのコピペを防止できます。マウスやキーボードでテキストを選択してコピーしようとしてもできなくなります。

コピープロテクションを有効にする

フレーム

iFrame プロテクションを有効にする

iframeやframeの中に、自サイトのコンテンツを表示できなくすることが出来ます。HTTPヘッダの “X-Frame-Options” パラメータを “SAMEORIGIN”にすることで実現します。ORIGINとは自サイトドメインの事だと思ってください。SAMEなので自サイトドメインと同じサイトにしか表示を許可しませんよということです。ただ、これについては回避策もあるので微妙かもしれませんね。詳しくはMDN Web Docsの「X-Frame-Options」SAMEORIGIN節を参照してください。

サイトがフレームで表示されないようにする

ユーザー番号

ユーザー番号を無効化

URLに”/?author=1″のようにパラメータを付けてアクセスすると、WordPressサイトではユーザー名情報を返してしまいます。このセキュリティリスクについては「ユーザー名漏えい防御」の記事を参照してください。

この機能を有効にすると、ユーザー名の表示を無効化して403エラーを表示してくれます。

WP REST API

未認証のRESTリクエストを禁止

ログインしていないユーザーからのリクエストに対する REST API アクセスを停止したい場合にチェックを入れます。プラグイン毎の除外設定が無いので正直他のプラグインを使った方が良いかもしれません。