Thirty minutes after going public, my server logs looked like a crime scene.

sashi sharma — Thu, 19 Mar 2026 14:46:05 +0000

Thirty minutes after going public, my server logs looked like a crime scene. I deployed to Railway and panicked. WordPress bots, phishing kit scanners, ID enumeration — and then the real problem hit.

It was DNS all along.

I Thought My Server Was Hacked. It Wasn’t.
I recently deployed my FastAPI backend to Railway (Paid Tier). The dashboard was green, the deployment was successful, and everything looked perfect. Then I opened the server logs.

I saw a flood of requests for paths I never created. There were .php files hitting a Python app and weird strings like sberchat.

Mar 19 2026 17:56:41   GET   /blogs/by/wp-admin/setup-config.php        404   696ms
Mar 19 2026 17:59:52   GET   /blogs/by/wordpress/wp-admin               404   966ms
Mar 19 2026 17:59:52   GET   /store/public/by/wordpress                 404   990ms
Mar 19 2026 17:59:52   GET   /posts/by/wordpress/wp-admin/setup-config  404   1s
What Was Actually Happening?
After the initial panic, I realized these weren't targeted attacks.

WordPress & PHP Scanners: Bots scan every public IP constantly. Since I’m running FastAPI (Python), my server returned a 404, and the bot moved on. This is pure background noise.

"Sberchat" TDS Probes: These bots are looking for their own phishing kits that might already be installed on compromised servers.

Account Enumeration: A crawler was brute-forcing random IDs against my /accounts/public/{id} endpoint. A solid reminder to implement rate limiting using Redis.

The Plot Twist: The Invisible Problem
While I was investigating these "hackers," I tried to log into my own app using my Mobile Hotspot. That’s when I saw the actual issue in the browser console: ERR_NAME_NOT_RESOLVED.

DNS: The Hidden Culprit
The Railway dashboard was green. The logs showed the bots were hitting the server fine. But my carrier's DNS had a stale cache entry.

The Fix:
I switched my active network interface to use Google’s DNS:

sudo resolvectl dns 2 8.8.8.8 8.8.4.4

The Real Security Takeaways:
Rate limit any endpoints that accept arbitrary user IDs.

Return 404s for unknown paths to keep your tech stack's footprint small.

Don't trust your ISP's DNS. Using 8.8.8.8 or 1.1.1.1 is generally more reliable for developers.

Originally published on Causalblogs

DEV Community: sashi sharma

Thirty minutes after going public, my server logs looked like a crime scene.