Nginx blocks sensitive directories for security protection

cause

A few days ago, I added a backend management function to my blog and added a new SQLite database directory. Mdata and cache directory Mcache. After the function ran smoothly, an idea suddenly came to me:

If I access directly https://域名/Mdata/content.db,what happens?

After trying it, the browser started downloading a file - the database file was completely exposed. It contains all article content, user password hashes, and translation caches. Once downloaded by crawlers or passers-by, the entire site becomes a transparent glass house.

This article records the troubleshooting and repair process, and also provides a reference for latecomers.

1. First confirm whether the exposure was exposed or not.

Don’t go by your gut, test first. use curl Or visit the browser one by one:

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

Look at the returned HTTP status code:

Return code meaning 200 OK Danger, the file is publicly downloaded 403 Forbidden Rejected, but exposed path exists 404 Not Found The ideal result is as if it does not exist. If it is 200, things have to be dealt with.

2. Why the pagoda cannot block it by default

In the default Nginx configuration of the Pagoda panel, the PHP processing rules look like this:

location ~ \.php$ {
    fastcgi_pass unix:/tmp/php-cgi-74.sock;
    include fastcgi.conf;
}

it just cares .php files, other extensions (.db、.log、.lock) will follow the static file rules and be directly spit out to users by Nginx as ordinary files. so content.db Just running naked.

Some people may think: that .db Wouldn't it be enough to add it to the PHP rules? No, that will make Nginx try to parse the binary file with PHP, and the result will be gibberish or a 500.

The correct approach isUse a separate prefix matching rule to eliminate the entire directory。

3. Core configuration

Open the Pagoda panel → Website → Click on the site → Configuration file,turn up server {} block, add inside:

# 屏蔽数据与缓存目录
location ^~ /Mdata/ {
    return 404;
}
location ^~ /Mcache/ {
    return 404;
}

Save and Nginx will automatically reload. Test those four URLs again. They should all return 404。

With these two items, the problem is solved.

4. Reinforcement: Expand to the entire site

Blocking out two directories is just the starting point. Let’s add a few general rules to cover more scenarios:

# ============ 安全加固 ============

# 屏蔽隐藏文件（放行 .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;
}

Explained item by item:

1. Hidden file rules: block .git、.env、.htaccess such documents.(?!well-known) It is a negative first assertion to avoid accidental injury. .well-known(Used by Let's Encrypt to issue certificates).
2. Directory blocking:Mdata/Mcache two core directories.
3. Background file blocking：Madmin/_key_*.php The login key is stored in_auth.php The session token is stored in it. Although the content is wrapped in comments and will not be leaked, one more layer is one more layer.
4. extension: What if one day you Mdata renamed to Data, or there are also other directories. .db, this rule can still stop it.
5. log/lock file：views.log、views.lock、php_error.log The content of this type of file may include IP, UA, and error stack.
6. Backup/Temporary files: Editor (vim/VSCode/PHPStorm) will generate .swp、~、.orig If the developer forgets to delete it when changing the code, the source code will be exposed.

6. About 403 和 404 philosophy

There is an old saying in the security circle:

Don't tell the attacker what you did wrong.

one 403 Forbidden The response is equivalent to broadcasting to the scanner: "There is something here, but I won't give it to you now." The attacker's next move is to try to bypass, guess the path, and find vulnerabilities.

而 404 Not Found It's silence - "What you see is no different than what I see."

For small sites for self-use, attackers are not so "precise strikes", and most of them use automated scanning. Give a 404 and the scanner will usually ignore it.