広告を利用しています

当サイトは広告を掲載しています。消費者庁が2023年10月1日から施行した景品表示法の規制対象(通称:ステマ規制)にならないよう配慮して記事を作成しています(記事はこちら、消す方法はこちら

特定のIPアドレスから大量の攻撃履歴が!初心者がやった対策メモ

ブログ

「WordPress」のアイコン画像

この記事では、2024年12月31日に「久々にセキュリティ見直してみるかぁ」と初心者なりに見たところ沢山のログインしようとした痕跡や攻撃履歴が残っていたのでやった対策について書きます。

ほんと初心者です。

特定のIPアドレスから大量の攻撃履歴が!初心者がやった対策メモ

2024年12月31日に「いよいよ2024年も今日で最後!ってかWordPressのセキュリティ関連もう1年以上見ていないなぁ…。こういうのは定期的にっていうし、ちょっと改めて見てみるか」と思いました。

僕が契約しているレンタルサーバー「ConoHa WING」の管理画面にあるWAF(ウェブアプリケーションファイアウォール)のページを見てみると、毎秒のように攻撃しようとした痕跡こんせきが記録されていました。

2024年12月31日に見た「ConoHa WING」のWAF攻撃履歴画像

同様にインストールしていたセキュリティ対策プラグイン「SiteGuard WP Plugin」のログイン履歴にも沢山攻撃記録が残っていました。

「SiteGuard WP Plugin」プラグインのログイン履歴画像

年末でぬくぬくあとは年を越すだけ…って時に心拍数がドックンっとあがりました(笑)

まぁ本記事の方法を実践した後もぶっちゃけくる時は大量にきているので、自分で言うのもおこがましいですがある程度アクセス数があるブログ(月1000PV以上とか?)だとどこも同じ状況なのかなと今になっては思います。

当時1年以上ぶりに見た時の僕はそれはもうびっくりです。最後に見た時はそんな痕跡はなく、せいぜい自分がWordPress上でプラグイン設定した時誤検知で記録されていたくらいです。

慌てて初心者なりにセキュリティ対策を見直してみたのでずらずら記録として書いておきます。初心者だからと言い訳してセキュリティ対策おろそかにしていたらダメです。

僕のWordPress周りの環境

最初に僕のWordPress周りの環境を書いておきます。

  • 使っているレンタルサーバーは「ConoHa WING
  • 「ConoHa」のセキュリティ設定は基本デフォルトのまま。WAFはオン
  • SiteGuard WP Plugin」プラグインをインストールしている
  • 「SiteGuard WP Plugin」の一部設定がいつの間にかオフになっていた

上記以外のレンタルサーバーやプラグインを使っている場合は僕には分かりません。僕が使っている環境と同じ設定項目があれば少しは参考になるかもしれませんが、基本的には画面のUIや設定方法が異なるので参考にならないと思います。

個人的に「うわっ!」って焦った一つの要因として、知らぬうちに「SiteGuard WP Plugin」の一部設定がオフになっていたんですよね…。

2024年12月末に確認した「SiteGuard WP Plugin」のチェック状態画像

知らぬうちっていうと何かそれこそもう既にやられているんじゃ?と思うかもですが、これに関しては自分がいつの間にかオフにしていた、またはそもそも設定していなかったのかなと思います。

オフになっているのを見て「これが原因であんなに毎秒のように攻撃されていたんじゃ?」と初心者あるあるのはっきりしていないのに無理やり原因結び付けようとするのが発動しました。

今となっては減ったとはいえ結局攻撃履歴に沢山残る時は残るので、一概にそれだけが原因ってわけじゃなかったんだなと思っています。

初心者がやったセキュリティ対策

以下のことをやりました。

「SiteGuard WP Plugin」の設定を全てオン

僕みたいな初心者ができるまず一番の対策はこれだ!ってことで「SiteGuard WP Plugin」の設定を全てオンにしました。

分からない単語がでてきたら逐一ちくいちGoogle検索して「なるほど…」と分かった気になりながら設定しました。全部の設定項目に緑のチェックマークがついたらOKです。

さらに全設定を今一度見てより厳しめに設定

「SiteGuard WP Plugin」は設定項目によってはより厳しめに設定できるオプションが用意されています。

例えば、「XMLRPC防御」という項目は有効か無効かの選択だけでなく、有効にした場合ピンバックを無効化するのかXMLRPCを無効化するのか選択できます。

「SiteGuard WP Plugin」プラグインの「XMLRPC防御」設定項目画像

デフォルトでは「ピンバック無効化」になっています。

「XMLRPC無効化」はより強力な対策になりますが、その分逆に使っているプラグインなどに支障をきたす場合があります。無効化することで本来XMLRPCを使うプラグインやテーマの機能などが正常に動作しなくなる…みたいなパターンがあるようです。

ひとまず僕は「XMLRPC無効化」にしてみて数日様子見しましたが、特に当サイトで目に見える不具合・支障はなかったのでこのまま無効化にしました。もしかしたら僕が気づかないところで何か起こっているかもですが…。

今一度「SiteGuard WP Plugin」の設定を全部見直しました。オンはオンでもそこからさらに強力な対策にできないか見て、できそうならそっちを選ぶって感じです。

大量に攻撃してきたIPアドレスを書き出してブロック

以下の2つの場所に記載されている攻撃してきたIPアドレスをメモ帳に書き出しました。

  • WordPressの管理画面→「SiteGuard WP Plugin」→ログイン履歴
  • ConoHa WING」の管理画面→上部の「WING」→左側サイドバーにある「サイト管理」→サイトセキュリティ→WAF

書き出したIPアドレスをまとめて「ConoHa」のIPアクセス制限→ブラックリストに登録します。新たなIPアドレスからの攻撃は止めれませんが、既に何度も仕掛けてきているIPアドレスからの攻撃は防げます。

「ConoHa WING」のWAF攻撃履歴に記録されているIPアドレスをコピーする手順画像

より詳しい方法は以下の記事に書いています。

注意点として「ConoHa WING」のWAFの攻撃履歴に残っているIPアドレスはスパムや悪意ある攻撃ではない誤検知の場合も多いです。

同じIPアドレスが1回か2回程度しか記録されていない場合は経験上誤検知の可能性があります。一方で同じIPアドレスから毎秒のように4回以上とか攻撃が記録されていた場合は怪しいです。

僕の環境だと「SiteGuard WP Plugin」プラグインのログイン履歴に記載されているIPアドレスは、脅威度やスパム度を調べてくれるツールを使った時高確率で危険度が高いと表示してくれます。

一方「ConoHa WING」のWAFに記録されているIPアドレスは、「ConoHa」上では攻撃の可能性があると記載されていても、実際調べるとどう見てもただの一般人からのアクセスで当然ツール上にもスパムや脅威度も検出されないのがちょこちょこあります。

一般人のIPアドレスを間違えてブロックしただけならまぁその人がアクセスできなくなって困るだけですが、もしブロックしたIPアドレスがGoogleやMicrosoftのクローラーだった場合は困ったことになります。

GoogleやMicrosoftなどの検索エンジンが自分の記事を検索結果にのせようと訪れてくれたのに、アクセス禁止(403エラー)で追い返されてしまいインデックスされなくなります。されなくなったら検索結果に記事がのらなくなります。

基本的には「SiteGuard WP Plugin」に記録されているどう見ても悪質って判断できるIPアドレスのみアクセス制限していくのがいいのかなと思います。

「ConoHa WING」のWAFに記録されているIPアドレスは一般人なのかクローラーなのか悪質なものなのか追加で調べて判断が必要な気がします。

「ConoHa WING」のWordPressセキュリティ設定

ConoHa WING」にアクセスして左側サイドバーの「サイト管理」→「サイトセキュリティ」→「WordPressセキュリティ」ページを開きます。

「ConoHa WING」の管理画面内にある「WordPressセキュリティ」設定画像

以下の項目たちがオン(ON)になっているか確認します。

  • ログイン制限の「管理画面ログイン」
  • コメント制限の「スパムコメント/トラックバック」
  • コメント制限の「海外コメント/トラックバック」
  • 海外アクセス制限の「ダッシュボード」
  • 海外アクセス制限の「XML-RPC API」
  • 海外アクセス制限の「REST-API」
  • 海外アクセス制限の「wlwmanifest.xml」

僕の場合、コメント欄はそもそもオフにしているので無関係だとは思うんですが、「海外コメント/トラックバック」がオフになっていたのでオンにしておきました。

海外アクセス制限の項目はほぼオフになっていたので慌てて全部オンにしました。

注意点として多分デフォルトでは何個かオフになっていたと思います。もし最初から全部オンだったら僕がわざわざオフにするはずないですもん。

デフォルトでオフってことはそれだけリスクもあるってことです。例えば「XML-RPC」を無効にすると使っているプラグインやテーマなどの環境によっては不具合が起きる可能性があります。

セキュリティ対策的には全部オンに越したことはないので、使っているWordPress環境に問題が起きなければひとまずオンにして検証するといいかなと思います。

僕の場合全部オンでも目に見えた不具合などはなかったのでオンにしています。目に見えない部分で何か起きていたらドンマイです。

参考:WordPressのセキュリティの設定をする|ConoHa WINGサポート

「ConoHa WING」の「ネットde診断」を実施

サービス概要

「ConoHa WING」は月1回までGMOサイバーセキュリティ byイエラエ株式会社が提供している脆弱性診断サービス「ネットde診断」を実施できます。

実施すると具体的に自分のサイトにどのようなセキュリティリスクが潜んでいるのか、どういった影響を及ぼすのか、対策方法は何なのか文章で確認できます。

実施するだけでセキュリティが向上するようなものではなく、「実施した結果を見てどうするかはあなた次第。こちとら結果を表示するだけ」ってものです。

結果をもとに自分のサイトの立ち位置を把握して改善することで意味があります。

レンタルサーバーを契約していてドメイン(サイト)を持っている場合は追加料金などなしで月1回まで利用できます。

無料でできて診断後に変な勧誘されるとかもないので、ConoHaユーザーなら気軽に試せると思います。診断結果を見てどうするかも自分次第なので診断だけやってあとは何もしないパターンもできます。

手動診断する方法

管理画面にアクセスして左側サイドバーの「サイトセキュリティ」→ネットde診断→「手動診断」をクリックします。

「ConoHa WING」の管理画面内から「ネットde診断」を手動診断する手順画像

「今月の手動診断枠を使いきりました」と表示された場合は、その月の診断はもうやっちゃっているってことなので来月になってリセットされるまで待ちましょう。追加診断したい場合は「プラン変更」から追加料金を払うと多分できます。

「ConoHa WING」の「ネットde診断」で「今月の手動診断枠を使いきりました」と表示されている画像

支払い確認ページに飛び請求額が0円になっていたらOKです。月1回無料ですがそういうサービスを(0円)で購入したという仕様になっているので、利用後「[ConoHa] ご利用料金のお支払いを確認しました」という一瞬焦るメールがきます。ちゃんと0円です。

診断を開始してしばらくしているとその下にある「診断結果」が押せるようになります。しばらくってのは1分2分の話じゃなくて早くて数分、遅くて数日レベルの話です。

「通知設定」でメールアドレスを設定しておけば、診断が終わった時自動的に「【ConoHa】脆弱性診断結果のご案内」という内容のメールを届けてくれます。

押すと診断結果ページへのリンクとパスワードが表示されます。パスワードをコピーしてリンク先を開いて入力すると診断結果が見れます。

「ConoHa WING」の管理画面内から「ネットde診断」の診断結果を開く手順画像

2024年12月の診断結果

結果は迂闊うかつに公表してしまうと逆に危ないと判断し、ほぼ塗りつぶしました。

総合評価はA~Eまであり僕はBでした。Bは「早急なセキュリティ対策は不要だけど将来を考えて追加の対策したらいいよ。定期的なチェックも忘れずに」って感じでした。

2024年12月に実施した「ナポリタン寿司のPC日記」の「ネットde診断」レポート結果画像

各項目ごとに顔文字でリスク度を表示してくれます。内容によっては必ずしも対策しないといけないってわけではないです。

無料版だと17項目の測定で、追加料金を払って利用する定期診断プラン(2025年1月から開始)だと36項目まで測定してくれます。セキュリティ対策も結局ビジネスなのでタダじゃないってことですなぁ…。

基本は無料版の月1回診断を忘れずにやるパターンでいいのかなと思います。

2025年1月の診断結果

本記事で紹介しているセキュリティ対策うんぬんを2025年1月に実施して、2025年1月29日に今月分の手動診断を実行しました。

いつ診断完了したのか分かりませんが、1月31日に見たところ既にレポートページを開けるようになっていたので確認したところ、「A」で「セキュリティ対策は不要です」になっていました。

2025年1月に実施した「ナポリタン寿司のPC日記」の「ネットde診断」レポート結果画像

正直、「いや、嘘つけぇぇえ!!」って思いました。多分嘘…というか診断ミスだと思います。リアルに。

本記事で書いていることをやっただけですよ?それだけで「B」で結構対策項目があったのに全部解決します?信じられません。

少なくとも前回診断した時にあった「バージョン情報の秘匿化」とかは対策していないです。

「OpenSSH 7.4などバージョン情報を読み取れる状況にあります。これだと脆弱性を突いた攻撃に悪⽤される可能性があるから秘匿したほうがいいです」って前回のレポート結果を見ると書いてあるんですよね。

今回それに関連しそうなことは一切やっていない(しいて言うならIPアドレスでの「wp-admin」アクセス制限?)のに検出されていないので、多分サーバーのタイミングが悪かったのかうまく診断してくれなかったんだと推測しています。

今月分はもうできないので来月(2月)また確かめたいと思います。本当に全部解決していたパターンだったら最高です。

「ネットde診断」の結果を保存していつでも見れるようにする

「ネットde診断」で自分のサイトを調べただけだと何の意味もありません。その結果をもとに自分がどうするかです。

診断結果ページはずっと閲覧できるわけではなく有効期限があります。僕の場合2024年12月31日にレポートが作成され、そのレポートの閲覧期限は2025年1月7日でした。それ以降はパスワードが合っていても見れなくなります。

「ネットde診断」の閲覧有効期限が切れている状態で開いている画像

「Google Chrome」ブラウザなどだと右クリック→印刷→「PDFで保存」にすることでPC内にPDFファイルとしてページを保存できます。いつでもローカル(オフライン)で見れるようになります。

「ネットde診断」のレポート結果をPDFでPC内に保存している画像

僕の場合、ちょっと中身のUIが崩れていましたが、対策の文章は読めたのでまぁ気にしていません。中身に書かれている文章を参考にしながら自分ができるセキュリティ対策を実施していきます。

過去の診断結果に縛られるのも良くないので、毎月無料で1回実施して都度セキュリティ対策をアップデートしていくのがいいかなと思います。

それぞれの項目に対する対策例は公式サポートページで確認できます。

参考:ネットde診断について|ConoHa WINGサポート

「他のすべての場所でログアウト」を実行

機能概要

WordPressには現在ログインしているデバイス以外のログイン状態を強制解除する機能が標準実装されています。

これは既に何者かにログインされてしまってどうしよ…って時や、スマホなどを落としてしまって第三者が触ってしまうリスクを考えて自宅のPCから実行する…といった感じで既にログインされたかあるいはその危険性がある時に便利です。

事前に防ぐという本記事の他のセキュリティ対策とは趣旨がずれますが念のためです。

僕の場合スマホなどからWordPressには一切ログインせず、メインPCの一台のみなので気軽に実行できます。

もしスマホやらタブレットやらPCやらの複数デバイスからログインしてブログ書くのが日常になっている方は注意です。全デバイスで再ログイン作業が必要になるのでセキュリティ対策よりストレスが勝つと思います。

実行方法

WordPress管理画面→左側サイドバーの「ユーザー」→自身のユーザー名をクリックします。

WordPressのユーザー一覧ページを開く手順画像

アカウント管理内にあるセッションの「他のすべての場所でログアウト」をクリックします。

WordPressのユーザーページにある「他のすべての場所でログアウト」を実行する手順画像

「この場所のみでログインしています」と表示されていたらOKです。もしこの文章が表示されていない場合は別デバイスでログインしている可能性があります。

ある程度日数がたつと、WordPress上で処理が更新されていないのかキャッシュやらCookieやらの影響なのか分かりませんが、絶対このPCでしかログインしていない!って時にも「この場所のみでログインしています」が表示されないことがあるので文章の有無だけでそこまで一喜一憂はしなくていいかなと思います。

定期的に実行するのもセキュリティ対策の意識を高めるという点ではありかもです。

「Edit Author Slug」プラグインを再インストール

僕がブログを始めた時は「Edit Author Slug」をインストールしていましたが、「SiteGuard WP Plugin」の「ユーザー名漏えい防御」を知ってからは機能重複しているっぽいしいらないかでアンインストールしていました。

「Edit Author Slug」はブログ名(URL)の後に「?author=1」や「/wp-json/wp/v2/users」を付けた時、ユーザー名がばれてしまうのを防いでくれるプラグインです。

「SiteGuard WP Plugin」の「ユーザー名漏えい防御」設定ページ画像

この度セキュリティ対策を見直している時に知ったんですが、どうやら機能は被らないようです。

「SiteGuard WP Plugin」にはユーザー名漏えい防御という機能がありますが、「Edit Author Slug」とは別物です。

そのため、「SiteGuard WP Plugin」は「Edit Author Slug」の代わりにはなりません。

SiteGuard WP Pluginの設定方法と不具合対処【404/403エラー】 | マニュオン

言われてみれば「Edit Author Slug」はブログのURL+「?author=1」を付けた時に表示されるそれ以降のユーザー名(URLスラッグ)そのものを変えるのに対して、「SiteGuard WP Plugin」の「ユーザー名漏えい防御」は変えることができません。

その代わりに「?author=1」にアクセスした時404エラーを返してサイトのトップページにリダイレクトしてくれます。

?author=1」のページを開かせない「SiteGuard WP Plugin」と、開かれても大丈夫なよう変更(隠す)する「Edit Author Slug」で、併用しても問題ないどころか併用したほうがセキュリティ対策的にはいいかなと思い再導入しました。

僕みたいな初心者でもサクッと変更できて便利です。

WordPressに「Edit Author Slug」プラグインをインストールした画像

そもそもユーザー名は他の対策がしっかりしていたら別にバレても問題ないという話もあります。僕はそれでもやらないよりやっといたほうがいいと判断して導入しています。

インストールしていて何かデメリットがあるなら考えますが、サイトが重たくなったり、テーマと相性が悪いなど目に見えるデメリットはないのでいいのかなと。

しいて言うなら脆弱性ぜいじゃくせいが見つかった時にプラグインを介して悪さされる可能性が無きにしも非ずですが、それは本プラグインに限った話じゃないです。

二要素認証を実装する「Two-Factor」プラグインのインストール

WordPressの管理画面にログインする際、二要素認証(2FA)を実装してくれるWordPressプラグイン「Two-Factor」を導入しました。

WordPressに「Two-Factor」プラグインを導入して二要素認証方式にしている画像

二段階認証ではなく二要素認証です。

単なる「秘密の質問」とかの固定化された第二のパスワード生成ではなく、一定時間ごとに毎回切り替わるワンタイムパスワードのほうを実装できます。

セキュリティ対策としてはいいんじゃないかなと思います。

逆に言えばWordPressにログインするたびに従来のユーザー名+パスワードに加えて、スマホなどにインストールしたワンタイムパスワード生成アプリ(有名どころだと「Google 認証システム」)に書かれている数字を入力しないといけないので手間にはなります。

「SiteGuard WP Plugin」には記事執筆時点で同様の機能がないため併用できます。

メールセキュリティを若干見直し

ConoHa WING」のメールセキュリティを今一度見直しました。WordPress自体のセキュリティ対策とは直接関係ないかもしれませんが、念のためです。

  • メールセキュリティがオンになっているか確認(デフォルトでオンだった)
  • メールセキュリティのフォルダ振り分けを「有効」
  • DMARC認証設定
  • サブのメールアドレスを作成してレポート通知機能に登録。【追記】やめた

「ConoHa WING」の管理画面→左側サイドバーの「メール管理」→「メールセキュリティ」を開きます。

セキュリティ設定が「ON」になっているか確認します。デフォルトでオンになっていました。

「ConoHa WING」のメールセキュリティ設定画像

その下にあるフォルダ振り分けってのが無効になっていたので「有効」にしておきました。悪意(ウイルスなど)あるメールが届いた時自動的に削除してくれるようです。

迷惑メールフィルターは特に今のところブロックしたい特定のメールアドレスがないので何も設定していません。もし鬱陶しいメールを送ってくる相手がいたらここに登録したいと思います。

DMARC認証設定の認証失敗時設定はオフになっていたのでオンにしました。振り分け設定は「迷惑メール」、レポート通知機能は「OFF」にしました。

「ConoHa WING」のメールセキュリティ内にあるDMARC認証設定画像

DMARC認証はなりすましメール防止技術DMARCに関する設定…らしいですが、正直よく分かっていません。

こちらのヘルプページを見ても設定方法しか書かれておらず、具体的にどういった意味・効果があるのか書かれていませんでした。

レポート通知機能は最初オンにしていましたが、素人の僕にはいいのかわるいか内容が判断できないメールが毎日届くようになったのでやめました。

「.htaccess」にアクセス制限の記述追記

「.htaccess」にコード記述

自身のブログサイト/wp-admin/」内に「.htaccess」ファイルを作成して、IPアドレスでのアクセス制限を設定しました。

PHP
Order deny,allow
Deny from all
Allow from 自身の固定IPアドレス
<FilesMatch "(admin-ajax.php)$">
    Satisfy Any
    Order allow,deny
    Allow from all
    Deny from none
</FilesMatch>

正直自分があんまり理解できていない&あっているか分からないことはやらないほうがいいと思っているので、もしかしたら今後やめるかもしれません。

WordPressの「wp-admin」直下に作成した「.htaccess」ファイルにIPアクセス制限コードを記述している画像

以下のサイト様や「ChatGPT」を参考にしました。

「ChatGPT」に「.htaccess」に記述するIPアドレス制限コードを解説してもらっている画像

内容的には「wp-admin」内にあるファイルやフォルダーを利用するのは一部プラグインなどを除いて管理者である僕だけで、僕は自宅のPCからしかWordPress利用しない=固定のグローバルIPアドレスなので、僕のIPアドレスを名指しで指定してそれ以外のIPアドレスからのアクセスは制限する…というものです。

発動しているかの確認

ただ自分自身が「あっ、本当に僕以外のIPアドレスからだとアクセスできなくなっているね」と検証していないので、効果が発動されているのか分かっていません。

Wi-Fiではなくモバイルデータ通信(4G)のスマホで「wp-admin」内にアクセスしたところ、「admin-ajax.php」ファイル以外は「Forbidden」でエラーが返されました。「admin-ajax.php」はアクセスを許可しているので開けました。

アクセス許可していないIPアドレス(モバイルデータ通信を使ったスマホ)から「wp-admin」にアクセスした時の「Forbidden」エラー画像

このことから多分僕が理想としている挙動にできている…と思います。ちゃんと機能しているのはいいとしてそれがセキュリティ対策的に効果あるものなのかは分かりません。

自宅のPC(アクセス許可しているIPアドレス)からアクセスした時は「Forbidden」ではなくトップページにリダイレクトされました。

「.htaccess」のアクセス許可は突破できているけど、その次にある「SiteGuard WP Plugin」あたりのセキュリティ対策が発動してくれているんだと思います。

最初はディレクトリアクセス制限(Basic認証)にしようとしていた

最初は「ConoHa WING」の管理画面で用意されている「ディレクトリアクセス制限」機能(ベーシック認証)を使おうとしていました。

「ConoHa WING」のディレクトリアクセス制限設定画像

しかし、以下の理由からやめました。

  1. ディレクトリ単位での指定になってしまい特定のファイルの指定・除外はできない
  2. 特定ファイルの除外ができない分、「/wp-admin」を指定したらその中の全ファイルが対象になる
  3. /wp-admin」内にある「admin-ajax.php」も当然対象になる
  4. admin-ajax.php」は色々な場所(プラグイン)で使われているのか「wp-admin」内ではない通常のURLを開いた時もベーシック認証が発動してしまう

ディレクトリアクセス制限で「/wp-admin」を指定した時、管理者ページなどではなく通常の記事ページ(例:https://www.naporitansushi.com/amazon-products-bought-2025/)を開いた時もベーシック認証が発動してパスワードを入力しないといけなくなりました。

管理者の僕だけなら全く問題ないんですが、記事を見てくださった読者様にも表示されるので「これはダメだ」ということでやめました。

代わりに少々高度になりますが、「.htaccess」ファイルに書き込むIPアドレス制限のほうで対処しました。

どちらにせよ「admin-ajax.php」は僕の環境的にはアクセス制限したらまずいっぽかったので許可しています。ただWAFの攻撃履歴などを見ると結構「admin-ajax.php」を狙った攻撃が多いんですよね。温床おんしょうになっている気がします。

本記事の対策は効果あったのか

少なくとも僕が認識できる範囲ではありました。

具体的には「SiteGuard WP Plugin」プラグインのログイン履歴に記録されている最後の攻撃が、本記事のセキュリティ対策をする前で止まっています。

「SiteGuard WP Plugin」のログイン履歴に記録されている最後の攻撃が2024年12月29日で止まっている画像

本記事の対策をした以降は少なくとも「SiteGuard WP Plugin」のログイン履歴に残るような攻撃はされていません。あるいはしてきたとしても事前に弾いてくれていると思います。

一方「ConoHa WING」のWAF攻撃履歴のほうは現在でも毎日何かしら残っています。こっちは誤検知もあるのでしょーがないと思っています。

「ConoHa WING」のWAF攻撃履歴に記録されている2025年1月の攻撃画像

それでも対策前(2024年12月以前)と比べると明らかに悪意あるIPアドレスからの攻撃が減っていました。対策前は同じIPアドレスから1秒おきに連続攻撃された記録が頻繁に残っていました。

対策後は基本的に同じIPアドレスからの攻撃は1回2回程度で連続する攻撃はなくなりました。記録に残った1回2回程度のIPアドレスをチェックツールで調べた時、大抵は「あっ、これは誤検知っぽいな」っていうIPアドレスばかりでした。

数回だけ怪しいって思ったIPアドレスからの攻撃がありましたが、気づいた時点でアクセス制限に登録しました。

僕は上記の場所以外で攻撃されたかどうか確認する方法を知らないので、上記の場所に検知されない方法で何かしらされていたら分かりません。

少なくとも僕の目に見える範囲では本記事のセキュリティ対策は効果あるのかなぁと思います。

感想

以上、ブログ初心者が用意されているものを活用してセキュリティ対策したメモでした。

他にも僕ができそうでやっていないセキュリティ対策があれば追記していきたいと思います。まぁ「こういう対策しました」報告はどう考えてもしないほうがいいんでしょうけど…。

逆に狙われるリスクがあるのでこういうセキュリティ対策は何も言わずに影でやるのが一番だと思います。

ブログ

Posted by ナポリタン寿司