1,000アクセスの正体は読者ではなかった――技術ノートのアクセス解析からWAF設定を見直した
土木設計の記事が読まれているか調べるため、約30日分のアクセスログを確認しました。短時間の1,000件は不審なPHPファイルの探索と分かり、公式サイトのWAF設定を確認・変更した経緯と、未確認の点を記録します。
当社では、土木設計の実務で試したAIやCAD、DX、セキュリティに関することを技術ノートとして公開しています。自分自身の備忘録にもなりますし、同じ問題に遭遇した誰かの参考になるかもしれません。DX認定を取得した後も何を試し、どう改善しているかを振り返る材料にもなっています。
最近はChatGPTの不具合に関する記事が検索から読まれることもあり、アクセス解析を見る機会が増えました。そこで気になったのは、会社の本業に近いDXFや配筋図、CAD、BIM/CIMの記事には、どんなアクセスがあるのかということです。
AIの不具合について調べる人が記事を見つけてくれるのはうれしいことです。ただ、この技術ノートには、日々の設計業務から生まれた話も多く残しています。そうした記事がどのように見つけられているかを知りたい、というのが今回の出発点でした。
調べ始めると、特定のアクセス元による約1,000件の記録が目に留まりました。記事を読んでいる人なのか、自動巡回なのか。アクセス数だけでは分からなかったため、生のログを確かめることにしました。
アクセス数の多い相手は、何を見ていたのか
2026年10月14日、お名前.comレンタルサーバーのアクセス解析画面を確認しました。表示期間は10月3日から14日までで、訪問者数3,398、ページ閲覧数8,303、UU数2,377と表示されていました。
この数字を、そのまま実際に記事を読んだ人数とは考えていません。検索エンジンの巡回、画像やCSSの取得、自動処理、自社での表示確認なども、アクセスの記録に含まれるからです。それでも、記事別の傾向を知る手がかりにはなります。
ページ別では、ChatGPTのローカルチャットに関する記事などが上位でした。一方、アクセス元別の画面には、約1,000件と突出した数字がありました。何度もサイトを見ている人なのか、何かを機械的に探しているのか。その画面だけでは判断できません。
最初は、同じ人が何度も記事を開いてくれている可能性も考えました。検索サービスの中継や、自動巡回のようなものかもしれません。アクセス元別の棒グラフを眺めていても、相手が実際にどのページを要求したのかは見えてきませんでした。
そこで、サーバーに保存されたApacheのアクセスログを約30日分取得し、ChatGPTも使って集計しました。対象は合計55,153件のHTTPリクエストです。これも55,153人の閲覧を意味する数字ではありません。記事のHTMLに加え、表示用ファイルや自動アクセスも混ざっています。
調べたかったのは、要求されたURL、時刻、応答の番号、参照元などです。アクセス解析の集計画面には全体の傾向をつかめる良さがあります。一方、今回のように一つのアクセス元の動きを追うには、一件ごとの記録が役立ちました。圧縮された過去ログをまとめて取得し、集計結果と元の行を照らしながら確認しました。
約4分間の1,000件は、技術ノートを読んだ記録ではなかった
問題のアクセス元を抽出すると、2026年10月5日の22時37分1秒から22時40分43秒まで、3分42秒ほどの間に1,000件が集中していました。要求先は999種類あり、記事を順番に開いている様子ではありません。
/admin.php、/lock360.php、/.wp/wso.php など、PHPファイルを探すパスが中心でした。名前を調べると、WordPress関連のファイルや、Webサーバー上で不正な操作に使われることがあるプログラムを探す動きと整合します。ブラウザの種類を示すUser-Agentも一定ではなく、参照元の記録はありませんでした。近いIPアドレスからも同日に287件の類似した要求があり、合わせると1,287件でした。
最初は、これらのファイル名が何を意味するのか分かりませんでした。調べる中で、Webシェルという言葉にも行き当たりました。Webシェルは、サーバー上に置かれると、外部からファイルの閲覧や変更などの不正な操作に使われることがあるプログラムです。今回の要求は、そのようなファイルが残っていないか、名前を変えながら探しているように見えました。
要求先がほぼ毎回変わることに加え、記事の見出しや一覧へ進む動きも見られませんでした。ブラウザを名乗る情報が切り替わっていても、それだけで人が操作しているとは考えられません。頻度と要求先を合わせて見ると、自動的な探索という判断に近づきました。
これらから、目立っていた約1,000件は、当社の記事への関心ではなく、不審なPHPファイルを機械的に探すアクセスだった可能性が非常に高いと判断しました。ただし、ログの情報だけで相手の身元や目的を確定することはできません。
301という応答から、侵入の成否までは分からない
1,000件の応答はすべてHTTP 301でした。301は別のURLへの恒久的な転送を示します。当社サイトではHTTPからHTTPSへの転送が設定されており、別に確認したHTTP側の /admin.php も、HTTPSの同じパスへ転送されました。今回の記録も、その転送だった可能性があります。
しかし301だけでは、転送先が404だったのか、403で拒否されたのか、別の応答を返したのかは分かりません。301を見て「不審なファイルは存在しない」と判断することも、1,000件という数だけで「侵入された」と判断することもできません。
私も最初は、301ばかりなら攻撃は失敗したと考えてよいのではないかと思いました。しかし、HTTPからHTTPSへの転送は、要求されたファイルの有無を確かめる前にも返り得ます。見ていたログに載っている番号が、処理の最終結果なのかを確かめる必要がありました。
反対に、短時間の1,000件をそのまま「1,000回攻撃を受けて被害が出た」と表現するのも違います。数が目立つほど強い言葉を使いたくなりますが、記録に残っている事実と、そこから推測したことは分けておきたいと思いました。
今回確認できたのは、不審なファイルを探す大量の要求が記録されていたことです。当社だけが特別に狙われたとも判断できず、重大な被害が起きた事件として扱うつもりはありません。不正侵入の成功や情報流出を示す証拠は、今回の分析では確認していません。HTTPS側の結果やサーバー上のファイルは、引き続き確認が必要です。
静的な公式サイトでも、守るものがある
当社の公式サイトはAstroで構築しており、手元のアップロード用ファイルはHTML、CSS、JavaScript、画像などで構成されています。PHPファイルは見当たりませんでした。手元の .htaccess にも、一覧表示の抑止と旧URLの転送はありますが、PHPの実行を許可・禁止する設定はありません。
問い合わせページには外部のフォームサービスを使っています。問い合わせ時に個人情報は扱いますが、今回確認した構成では、公式サイトの公開サーバー内にその情報を保存する仕組みは見当たりませんでした。
会員登録を受け付けたり、顧客情報を蓄積したりするデータベースを、この公式サイトで運用しているわけでもありません。ここだけ見ると、探されていたPHPファイルとは関係が薄いように感じます。実際、手元の公開用ファイルに対象のファイル名はありませんでした。ただし、手元のファイルと、いまサーバー上に置かれているファイルが完全に一致するかは、別に確かめる必要があります。
それでも、サイトのファイルを改ざんされれば、会社の名前で誤った情報を表示されたり、問い合わせ先を書き換えられたりする恐れがあります。管理画面やアップロード用の認証情報、公開ファイルの管理は、静的サイトでも欠かせません。
公式ホームページは会社情報を置くだけの場所でもありません。技術ノートを継続して公開し、DX認定取得後も何を試しているかを示す場所です。内容を勝手に書き換えられれば、読んだ人に誤った情報を伝え、会社の信用にも関わります。公開サーバーに顧客情報を大量に保存していないとしても、守るべきものは残っています。
手元のファイルを見る限り、公式サイトの表示にPHPは必要なさそうです。ただし、サーバー上に古いファイルが残っていないか、実際にPHPを実行できるかは未確認です。お名前.comのサーバー仕様にはPHP対応が示されていますが、サービス全体の機能と、当社サイトの公開フォルダーの実際の状態は分けて確かめる必要があります。
「公式サイトにPHPを使っていない」と「公式サイトのフォルダーではPHPが動かない」も、同じ意味ではありません。後者を知るには、契約中のプランやサーバー側の設定、実際の公開フォルダーを確かめる必要があります。今回分かったのは、当社が用意した静的な公開ファイルにはPHPが含まれないというところまでです。
同じ契約内には、用途の異なる開発用サブドメインもあります。ファイルマネージャー上では公式サイトと別の公開フォルダーに表示されましたが、書き込み権限まで完全に分離されているかは、まだ確認できていません。開発側で使う機能への影響もあるため、PHP関連の設定は今回変更しませんでした。
開発用の環境では、公式サイトとは異なる機能を使う作業もあります。両者が同じ契約内にあるからといって、設定を一律に変更すると、思わぬところへ影響するかもしれません。まず公式サイトで何が必要かを調べ、変更が必要になったときには対象と元に戻す方法を確認したいと思います。
知らずにOFFだったWAFを、公式サイトでONにした
大量の探索を調べるうちに、お名前.comのWAF設定も確認しました。WAFはWeb Application Firewallの略で、Webサイトへの不審な要求を検知・遮断するための仕組みです。
管理画面で公式サイトを選ぶと、「検知ログ管理」の設定がOFFと表示されていました。最初は、ログの記録だけがOFFなのか、WAF自体がOFFなのか判断できませんでした。そこで変更する前に、お名前.comのWAF設定ガイドを確認しました。ガイドでは同じ項目をOFFからONに切り替えると、WAFをONにした旨が表示されると説明されています。
「検知ログ管理」という項目名だけを見たとき、ログが残らないだけで、防御そのものは働いている可能性もあると考えました。画面の言葉が曖昧に感じられたので、ここでは推測でスイッチを触りませんでした。公式ガイドの手順と、管理画面で選んでいるドメインを照らし合わせ、表示の意味を確かめました。
この案内と画面を照らし、公式サイト側のWAFがOFFだったと判断してONにしました。管理画面では対象ドメインごとに設定を選べます。今回変更したのは公式サイト側だけで、開発用サブドメインの設定には触れていません。
その後、通常のページ表示に目立った異常はありませんでした。ただし、これだけで全ページや問い合わせの正常動作、WAFの防御効果を確認できたわけではありません。正常な操作が誤って遮断される可能性もあるため、記事の表示、問い合わせページ、旧URLの転送、WAFの検知ログを今後も見ていきます。
設定した直後にページが開けたことには、ひとまず安心しました。しかし、たまたま開いた数ページが正常でも、特定の操作だけが遮断されることは考えられます。問い合わせをする人や、以前の記事URLから来る人に影響が出ないか、普段の利用の中でも見ていく必要があります。
WAFをONにしても、管理用アカウントやアップロードするファイルの管理が不要になるわけではありません。今回進んだのは、設定を確認し、公式サイトの防御機能を一つ有効にしたところまでです。
SCS★3の準備にもつながる、設定と記録の確認
当社では、SCS評価制度の★3要求事項・評価基準を見ながら準備を進めています。前の記事では、会社にある規程や契約、運用記録を確認し、資料の存在と、そこから実際に確認できたことを分けて整理しました。
今回も同じ姿勢が必要だと感じました。レンタルサーバーにWAFという機能が用意されていることと、公式サイトでONになっていることは、確認して初めて区別できます。ONにした後も、想定どおり動き続けているか、ログやページ表示を見なければ分かりません。
以前、SCS★3を意識してNASのバックアップを確認した際には、別のセキュリティソフトの期限切れにも気付きました。NAS自体は普通に動いていても、管理画面まで見て初めて分かることがありました。今回のWAFも、アクセス数に疑問を持ってサーバーの設定を開かなければ、OFFのままだったかもしれません。
今回の設定変更だけで、SCS★3の特定の要求事項を満たしたと判断しているわけではありません。公式サイトも会社が管理する対象の一つとして、使っている機能、設定、確認した日、未確認の点を記録に残す。制度の準備を、実際の運用へ結び付ける一例になりました。
最初に知りたかった、土木設計の記事へのアクセス
自動スキャンの調査で話は広がりましたが、30日分のログからは、最初に知りたかったことも少し見えました。DXF、CADとAI、配筋図、BIM/CIMなど、本業に近い記事へのアクセスがあります。
確認した記事には、配筋図と暗黙知を扱うもの、DynamoとV-nasClairを使ったCAD自動化の話、PythonとCIMの連携に関するものもありました。ChatGPTの不具合を調べている人だけが来ているわけではなさそうです。
DXFの記事にはHTTP 200の応答が159件あり、社内からのアクセスを除いて検索参照元が付いた要求は73件でした。CADとAIの記事ではそれぞれ171件、55件でした。これらは記事を読んだ人数ではありません。検索参照元が付いていても、自動処理が混ざる可能性はありますし、ログから訪問者の職業は分かりません。
それでも、DXFやCADの話を探して来た可能性のあるアクセスが記録されているのは、私にはうれしい発見でした。検索結果から記事を開き、その後に表示用のファイルを取得したように見える記録もあります。通常の閲覧と整合する動きですが、ログだけで人間の閲覧と確定はできません。
それでも、土木設計に関係する記事が検索から見つけられていることは、今回の記録と整合します。一方、約1,000件のPHPファイル探索を読者の関心として数えていたら、数字の意味を取り違えていました。アクセス解析では、件数だけでなく、何を数えているかまで見る必要があると感じました。
記事を開いたと考えられるアクセス、検索エンジンの巡回、画像などの取得、自社での確認、脆弱性を探すスキャン。こうした異なる記録が、アクセス数の中には混ざっています。大きな数字を見たときほど、その内訳を見に行くことが大切だと感じました。
2026年10月14日時点で、公式サイト側のWAFは有効化しました。サーバー上に予期しないPHPファイルがないか、PHPを実行できる範囲、探索のHTTPS側での結果、開発用サブドメインとの権限の分離は、まだ確認が必要です。
アクセス数を調べ始めた目的と、その途中で見つかった設定の問題。どちらも、実際に記録を開いてみたから分かりました。今後も確認できた範囲を残し、必要な設定と運用を少しずつ見直していこうと思います。
今回のような探索は、インターネット上に公開されたサイトでは珍しくないのかもしれません。だからといって、何も確認せずに済ませる理由にはなりません。アクセス解析から始まった小さな疑問が、使っているサーバーの設定を知るきっかけになりました。
最初からWAFを見直そうとしていたわけではありません。技術ノートの読者を知りたくてログを調べ、数字の意味を確かめるうちに、別の確認事項が見つかりました。調べ始めた目的も、途中で見つかった問題も、今後の運用に生かしていきたいと思います。