I manage a small corporate site. First time I properly checked the logs and was shocked.
Thousands of requests daily hitting addresses like /wp-admin, /.env, /phpmyadmin, /.git/config. We don't even use WordPress.
Is this a targeted attack on us, or is it like this for everyone? What should I do?
First, relax: this isn't a targeted attack on you, it's background noise every public-facing address gets. Automated scanners constantly sweep IP ranges and try known vulnerability paths. They don't know what your site is, nor do they care.
Now for the skeptical part, because "normal" doesn't mean "unimportant." Make this distinction:
Automated noise: requests returning 404s on random paths, from different IPs, repeating patterns. This is just noise.
What to watch for: attempts on paths that actually exist on your site. Repeated password tries on your login page, access attempts to your admin panel, parameter tampering. This means someone has actually looked at your site.
To-do list, in order of importance: don't leave the admin panel public, rate-limit login attempts, keep software updated, have backups, and test them by restoring.
The last item is the most skipped. An untested backup is not a backup.
Adding a technical note from a SOC perspective.
Trying to block this noise completely (like blacklisting every IP) is usually wasted effort. IPs change constantly, lists bloat, and one day you block your own users.
Instead, filter the noise so you can see real incidents. Practical method: log 404 requests to a separate channel, keep only 200s and 500s in your main log stream. Also keep a separate counter for failed login attempts.
I recommend this alert rule: many failed logins from a single source in a short time. This is a pattern that truly stands out from noise and requires intervention.
Also don't forget: the most common real incidents start with logging in via a leaked password, not brute-forcing from outside. So enabling 2FA is as important as checking logs.
Let me ask a question: you say this is the first time you properly reviewed these logs. How far back can you go?
Here's the issue: log retention on most servers is short by default. Everyone who wants to look back after an incident hits the same wall: no logs.
As someone who needs evidence, concrete advice: check your log retention period and increase it to at least ninety days. Storage cost is small, value during an incident is huge. Also keep logs somewhere other than the server itself; if the server is compromised, logs are the first thing deleted.
Giving numbers from the hosting side, not guesses, this is the pattern we regularly see in our own panel.
Even a newly registered domain, never promoted, with no links anywhere, starts receiving these automated attempts within the first week. Simple reason: certificate transparency logs are public, new domains are visible there too.
So there's no security state of "my site is small, nobody knows about it." Being small doesn't make you invisible, it just lowers the probability of targeted attacks.
I'm a student, want to ask something, sorry if it sounds silly.
Why are these browsers looking for the /.env file? Like, what's in that file that makes it so valuable?
Not silly at all, that's a very on-point question.
The .env file is a text file that holds the app's settings (environment variables). It usually contains the database address and password, third-party service keys, and the session encryption key.
So for an attacker, finding this file is like finding the key instead of forcing the door. That's why scanners try it first; the cost is a single request, the payoff is everything.
Normally, this file should sit outside the folder served by the web server. With a wrong setup, it stays inside the public folder and can be read via the browser. The same logic applies to /.git/config: if the project repo accidentally goes live, the entire source code can be downloaded.
Checking is super easy: just type /.env after your own address and try it. If you get a 404, you're good; if you see content, close it immediately and change all the keys in that file. Closing it isn't enough, assume it's leaked.
As the Doki team, let's add a note, because this thread does a good job summarizing a frequently asked topic.
We see the same picture described above: every asset exposed to the internet gets scanned, even if it's not advertised. That's why we first recommend our clients to create an asset inventory — which domains, which subdomains, which servers are actually ours, and which ones are still left running forgotten.
In practice, the most common open door we encounter is forgotten test environments. The live system is properly protected, but a trial server opened two years ago is still pointing to the same database.
The posts here are for general information purposes; we recommend getting a scoped assessment for your own system.
Looking at it as a process, the picture changes. If 2FA is on, a stolen password alone is useless.
If 2FA is on, a stolen password alone is useless. If you post the result here, it will help others too.
I agree, and I'd like to emphasize that. If the notification path is long, notifications don't arrive; missing notifications mean delayed incident detection.
I'm also curious if anyone does it differently.
There's one point I'm curious about. Hasty decisions become decisions you have to fix six months later.
Good luck with that.
Quick summary for newcomers: The harder it is to reverse a decision, the slower you should make it.
Any unwritten clause becomes a point of disagreement later, as both sides remember it differently. Good luck with that.
Thanks for writing this, that's the right way. If permission and scope aren't in writing, don't start that test.
This is my opinion, I'm not claiming it's absolute truth.
I've been dealing with this for a long time. Most time waste accumulates in tasks waiting for approval.
Mistakes made on the log side are usually reversible but expensive. Hope this helps.
How did you solve this? Trying to do this alone is the most expensive way.
Mistakes made on the log side are usually reversible but expensive. This is my opinion I'm not claiming it's absolute truth.