発端
先日、ブログに管理コンソール機能を追加し、新たなSQLiteデータベースディレクトリを追加しました。 Mdata キャッシュディレクトリ Mcache機能が正常に動作した後、突然、ある考えが頭に浮かんだ：
直接アクセスする場合 https://域名/Mdata/content.dbどうなるでしょうか？試してみたところ、ブラウザでファイルのダウンロード処理が開始された――そのデータベースファイルが完全に暴露された。このファイルには、すべての記事内容、ユーザーのパスワードのハッシュ値、翻訳用キャッシュなどが含まれていた。このファイルがクローラーや傍観者によってダウンロードされれば、このサイト全体はまるで透明なガラスケースのように晒されることになる。
本記事では、トラブルシューティングおよび修復のプロセスを記録し、後続の開発者や管理者に参考情報として提供することを目的としています。
1. まず、暴風雨が実際に発生しているかを確認してください。
直感ではなく、まず測定してください。 curl または、ブラウザを個別に実行する：
curl -I https://你的域名/Mdata/content.db curl -I https://你的域名/Mcache/_config.php curl -I https://你的域名/Mdata/views.log curl -I https://你的域名/Mdata/content.db-wal
返されたHTTPステータスコードを確認してください：
戻りコードの意味 200 OK 危険ファイルが公開ダウンロードされました。 403 Forbidden 拒否されたが、その結果、パスの存在が明らかになった。 404 Not Found 理想的な結果は、まるで存在しないかのように。 200この件は早急に処理する必要があります。
二、なぜ宝塔はデフォルトで防ぎ切れないのか？
宝塔パネルのデフォルトNginx設定におけるPHP処理ルールは以下の通りです：
location ~ \.php$ {
fastcgi_pass unix:/tmp/php-cgi-74.sock;
include fastcgi.conf;
}
単に管理するだけです。 .php ファイル、その他の拡張子（.db、.log、.lock）は静的ファイルの処理ルールに従って、Nginxによって通常のファイルとしてユーザーに提供されます。したがって content.db そうして、裸で走り出した。
「それなら……」と誰かが考えたかもしれません。 .db PHPルールに追加すればいいのだろうか？ いや、そうすると Nginx が PHP を用いてバイナリファイルを解析しようとし、その結果として文字化けや 500 エラーメッセージが発生する。
正しい方法は以下の通りです。独立したプレフィックスマッチルールを用いて、すべてのディレクトリを除外する。。
三、核心構成
「宝塔パネル」を開く → 「ウェブサイト」 → 「サイト」をクリックする 設定ファイル，が見つかりました server {} ブロックに以下の内容を追加してください：
# 屏蔽数据与缓存目录
location ^~ /Mdata/ {
return 404;
}
location ^~ /Mcache/ {
return 404;
}
保存すると、Nginxが自動的にリロードされます。その後、前述の4つのURLを再度テストしてください。すべて正常に返されるはずです。 404。
これら2点で問題は解決しました。
四、補強：全ステーションに適用
2つのディレクトリを設定するだけでは不十分です。ここにいくつかの汎用ルールを追加することで、より多様なシナリオに対応できます：
# ============ 安全加固 ============
# 屏蔽隐藏文件（放行 .well-known 给证书验证用）
location ~ /\.(?!well-known) {
return 404;
}
# 屏蔽数据与缓存目录
location ^~ /Mdata/ {
return 404;
}
location ^~ /Mcache/ {
return 404;
}
# 屏蔽后台密钥 / 会话文件
location ~ ^/admin/_(key_.*|auth)\.php$ {
return 404;
}
# 兜底：禁止访问任何数据库文件
location ~* \.(db|sqlite|sqlite3|db-wal|db-shm)$ {
return 404;
}
# 禁止访问日志 / 锁文件
location ~* \.(log|lock)$ {
return 404;
}
# 禁止访问备份 / 临时 / 配置文件
location ~* \.(bak|old|orig|save|swp|swo|tmp|inc|ini|conf)$ {
return 404;
}
項目ごとの解説：
- 隠しファイルルール：遮断
.git、.env、.htaccessこの種の文書。(?!well-known)負の先行断言を用いることで、誤った影響を回避できます。.well-known（Let's Encryptによる証明書発行用）。 - 目次非表示Mdata / Mcache —— 2つの主要なディレクトリ。
- バックエンドファイルブロック機能：
Madmin/_key_*.phpログインキーが保存されています。_auth.php会話トークンが保存されています。コンテンツがコメントで囲まれているため漏洩しないものの、それでも追加の保護層は存在します。 - 拡張子（最終手段）もしも、いつかあなたが……
Mdata名前を変更するDataまたは、他の目次にも含まれている可能性があります。.dbこのルールも依然として防ぎ得ます。 - ログ/ロックファイル：
views.log、views.lock、php_error.logこのようなファイルでは、IPアドレス、ブラウザ情報（UA）、エラースタックなどが含まれている可能性があります。 - バックアップ／一時ファイルエディタ（vim / VSCode / PHPStorm）で生成されます。
.swp、~、.origこのようなケースでは、開発者がコードを編集する際に削除を忘れると、ソースコードが暴露される可能性があります。
六、について 403 和 404 哲学
「セキュリティ・リング」には、こんな古い言葉があります：
攻撃者に自分が何を間違えたかを明かすのを避けてください。
1個 403 Forbidden この応答は、「こちらに何かがあるが、今はあなたに渡していない」というスキャナーへのブロードキャストに相当します。攻撃者の次の行動としては、防御を回避する、パスを推測する、あるいは脆弱性を発見するといった措置が考えられます。
而 404 Not Found 沈黙――――「あなたが見ていることと、私が見ていることにはほとんど違いはありません」。
自用の小型サーバーの場合、攻撃者による攻撃は「精密攻撃」というわけではなく、多くの場合、自動スキャンによるものである。404エラーが返された場合、スキャナーは通常、そのリクエストを無視する。
