More than twenty years ago, when I was living in a student dorm, we built our own local network.

Mostly to play Counter-Strike, of course.

But local networks in the Windows 95, 98, NT, and XP era were useful in more ways than one, and harmful in more ways than one too. It did not take long before people in that little dorm network learned how to wander into each other’s machines through backdoors, delete system files, or do something even worse like formatting a disk.

That changed habits fast.

Simple shared folders started disappearing. People became more careful. Local FTP servers appeared because file exchange still mattered, but trust had already changed.

The thing I remember most clearly is not a technical trick. It is an alert.

One of my friends had a full-screen warning that would suddenly take over the monitor with a loud alarm sound:

WE ARE UNDER ATTACK

That phrase came back to me this week.

Not because zinchuk.online was hacked. It was not. But because the emotional shape of the experience was strangely familiar. The moment something becomes reachable, someone starts knocking on it. Sometimes a person. Usually a script. Often a lot of scripts.

Public means public immediately

As soon as a server is visible on the internet, it stops being a private machine with a website on it. It becomes part of a constant background scan.

That sounds dramatic if you have not looked at logs before. Once you do, it mostly stops feeling dramatic and starts feeling routine.

The recent nginx logs were a good reminder of that.

They showed the usual mix:

  • probes for hidden config files
  • guesses at admin panels and framework debug pages
  • generic attempts against old web server patterns
  • odd method requests that clearly were not meant for a static personal site

None of that looked personal. It looked industrial. Wide, repetitive, and automated.

That distinction matters.

This was not some movie-style “someone is targeting my blog” moment. It was the normal pressure that appears when any public host joins the internet. The difference between a healthy server and an embarrassing one is often not whether scans happen, but what those scans are allowed to find.

What the logs actually told me

The first useful thing about logs is that they reduce anxiety.

Without them, “under attack” can sound bigger than it is. With them, the picture becomes calmer:

  • most of the suspicious requests were generic reconnaissance
  • they were looking for common mistakes, not anything specific to this site
  • the server was mostly answering with 404, 400, or 405
  • there was no sign of application-level failure or a successful break-in

That does not mean “ignore it.”

It means react proportionally.

There is no point writing a war story about bots asking a static site if it accidentally contains somebody else’s favorite mistake. But there is value in treating those requests as a checklist. Logs are not just evidence of bad behavior. They are also free hints about what your public surface should stop exposing.

The quiet security work

So I treated this as maintenance, not panic.

We reviewed what was actually deployed and tightened a few things:

  • confirmed that there were no active debug or development endpoints in the live site
  • confirmed that there were no CGI handlers or similar legacy execution paths exposed
  • blocked access to hidden files and other paths that should never be public
  • stopped serving the real site to random host headers and direct-IP HTTPS requests
  • replaced the default server error page with the site’s own 404 page so the behavior is cleaner and more intentional

I am leaving the exact implementation details out on purpose.

That is not to be mysterious. It is just the right tradeoff for a public post. The useful lesson is the shape of the response: inspect the logs, verify what is live, remove what should not be reachable, and tighten the boring edges before they become interesting.

Security is mostly habit

The older I get, the less I think of security as a dramatic discipline.

Most of the time it is not about cinematic attacks. It is about habits:

  • checking logs instead of guessing
  • not leaving unnecessary routes exposed
  • keeping the public surface smaller than your future self will regret
  • making small fixes while the problem is still only a warning

That old dorm alert was loud on purpose.

It was trying to turn fear into action.

This week felt like the adult version of the same lesson. No flashing red full-screen message. Just two log files, a public server, and a quiet reminder that once something is online, it joins a noisy world.

So yes: WE ARE UNDER ATTACK.

But not in the dramatic way.

In the ordinary internet way.

And that is exactly why the boring security work matters.