{"id":3304,"date":"2026-09-30T16:23:27","date_gmt":"2026-09-30T16:23:27","guid":{"rendered":"https:\/\/siteharbour.com\/blog\/?p=3304"},"modified":"2026-09-30T16:23:28","modified_gmt":"2026-09-30T16:23:28","slug":"block-env-scanner-probes-nginx","status":"publish","type":"post","link":"https:\/\/siteharbour.com\/blog\/block-env-scanner-probes-nginx\/","title":{"rendered":"How to Block .env and Scanner Probes on Nginx (With Real Log Numbers)"},"content":{"rendered":"

To block .env scanner probes on Nginx, deny every request for a dotfile with a location rule such as location ~ \/.(?!well-known) { deny all; }<\/code>, keep the web root free of secrets, and then audit your access log to confirm that no such request ever returned a 200. Automated scanners request paths like \/.env<\/code> and \/.git\/config<\/code> all day on every public server, so the goal is not to stop them from asking but to make sure the answer is always a refusal. This guide shows the rules, a correct audit, and real numbers from one day of logs on a small server.<\/p>\n

The commands assume Ubuntu 24.04 and Nginx. If your site runs WordPress, this pairs with the guides on optimizing WordPress on a 1 GB server<\/a> and setting up an Nginx FastCGI cache<\/a>.<\/p>\n

Why scanners look for .env files<\/h2>\n

Many frameworks keep secrets such as database passwords, API keys and application keys in a file named .env<\/code>. If a server is misconfigured so that this file sits inside the public web root and is served as plain text, anyone who requests it can read every secret in it. Attackers know this, so they run automated tools that request the same list of paths on every server they can find, without caring what the site is.<\/p>\n

You do not need to be a target for this to happen. A brand new site with almost no visitors receives these probes as soon as its address appears in certificate logs or DNS data. The requests are cheap for the attacker and harmless for you, as long as your server answers correctly.<\/p>\n

What one day of probes looked like on a real server<\/h2>\n

These figures come from the SiteHarbour server, which runs a Laravel application and a WordPress blog behind Cloudflare. The error log I read covered 03:10 to 12:38 on a single day, about nine and a half hours, so treat the numbers as a snapshot and not as a long-term trend.<\/p>\n\n\n\n\n\n\n\n\n\n
Measurement<\/th>\nValue<\/th>\n<\/tr>\n<\/thead>\n
Requests in the access log<\/td>\n2,459<\/td>\n<\/tr>\n
Responses with status 403<\/td>\n415 (about 17 percent)<\/td>\n<\/tr>\n
Log lines saying “access forbidden by rule”<\/td>\n415<\/td>\n<\/tr>\n
Responses with status 404<\/td>\n1,108<\/td>\n<\/tr>\n
Responses with status 200<\/td>\n883<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

The 403 count and the “forbidden by rule” count match exactly, which means every blocked request was refused by a deny rule and not by anything else. The most requested blocked paths were:<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n
Path<\/th>\nRequests<\/th>\n<\/tr>\n<\/thead>\n
\/.env<\/code><\/td>\n30<\/td>\n<\/tr>\n
\/.env.local<\/code><\/td>\n15<\/td>\n<\/tr>\n
\/@fs\/.env<\/code><\/td>\n12<\/td>\n<\/tr>\n
\/.env.production<\/code><\/td>\n12<\/td>\n<\/tr>\n
\/.env.development<\/code><\/td>\n9<\/td>\n<\/tr>\n
\/\/.env<\/code> and \/@fs\/src\/.env<\/code><\/td>\n8 each<\/td>\n<\/tr>\n
\/@fs\/app\/.env<\/code><\/td>\n7<\/td>\n<\/tr>\n
\/.git\/config<\/code><\/td>\n6<\/td>\n<\/tr>\n
\/config\/.env<\/code>, \/api\/.env<\/code>, \/admin\/.env<\/code>, \/.env.save<\/code>, \/.env.example<\/code>, \/.env.bak<\/code><\/td>\n5 each<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

The pattern is what you would expect from a generic scanner. It tries the plain file, then common environment names (.local<\/code>, .production<\/code>, .development<\/code>), then backup suffixes (.save<\/code>, .bak<\/code>), then likely folders (\/config\/<\/code>, \/api\/<\/code>, \/admin\/<\/code>). The \/@fs\/<\/code> paths appear to be probes for development servers that expose their file system, which a production Nginx site simply does not have.<\/p>\n

Step 1: Find your current exposure<\/h2>\n

Before adding rules, check what your server does today. Replace the log path with your own:<\/p>\n

sudo grep -c \"access forbidden by rule\" \/var\/log\/nginx\/error.log\nsudo grep \"access forbidden by rule\" \/var\/log\/nginx\/error.log | grep -o 'request: \"[A-Z]* [^ ]*' | awk '{print $3}' | sed 's\/?.*\/\/' | sort | uniq -c | sort -rn | head -n 15\nsudo awk '{print $9}' \/var\/log\/nginx\/access.log | sort | uniq -c | sort -rn | head -n 6<\/code><\/pre>\n
The first command counts the requests your rules refused. The second lists the paths most often refused. The third shows the mix of status codes. If you have no deny rules yet, the second command prints nothing, and the probes are being answered with 404 or, worse, 200.<\/p>\n
Step 2: Deny dotfiles and other sensitive paths<\/h2>\n
These are the rules in use on the server measured above, placed inside the server<\/code> block:<\/p>\n
location ~ \/.(?!well-known) { deny all; }\nlocation ~ \/.(env|git|htaccess) { deny all; }\nlocation ~* ^\/(vendor|storage)\/ { deny all; }<\/code><\/pre>\n
What each line does:<\/p>\n