Our network security case study states the principle in one line: don’t patch an exposure until you know exactly who’s been using it and how. That’s easy to agree with in the abstract and easy to skip under pressure, because a security finding creates an instinct to close it immediately — and that instinct is usually wrong. Here’s the actual pattern, with more of the reasoning behind each step than the case study page has room for.
Why “close it now” is the wrong first move
A finding — a publicly reachable file, a service listening somewhere it shouldn’t be, a port open to the whole internet — feels urgent the moment you find it, and reacting to that urgency by closing it on the spot feels responsible. It often isn’t, for a simple reason: you don’t yet know what depends on the exposure working exactly the way it currently does. Closing a port that a legitimate integration quietly relies on doesn’t fix a security problem, it trades it for an availability problem — and you find out about the trade the moment something breaks, usually for someone else, usually without warning.
The alternative isn’t slower. It’s just ordered differently: read the logs first, understand the real usage pattern, then design a fix that closes the exposure without breaking whatever legitimate thing depended on it.
Three real findings, worked through
Publicly exposed files. A data directory served by a web server without an explicit deny rule is a real exposure the moment it’s discovered — but “real exposure” and “active breach” are different severities, and the difference matters for what you do next. Before touching anything, the access logs get checked: who has actually pulled the exposed files, and when, and does that pattern look like legitimate internal traffic, a known scanner, or something else. Separately, the file contents themselves get read (carefully, and only as far as needed) to determine whether real secrets are involved — because that answer changes the response entirely. If credentials were actually exposed and plausibly harvested, the fix isn’t just closing the hole, it’s rotating whatever leaked, on the assumption that anyone who found it already has a copy. If it’s non-sensitive static content that happened to lack a deny rule, the fix is just the deny rule.
A service bypassing its intended access path. It’s a common pattern for an application to have two ways in: the “front door” that goes through a reverse proxy with authentication in front of it, and a “back door” left over from development — a port the app itself still listens on directly, reachable from anywhere, that skips the front-door auth entirely. The instinct is to firewall the back door off immediately. The more useful first step is confirming how the legitimate workflow currently happens — is anything actually using the direct port, or has all real traffic already been going through the front door for a while, with the open port just an unused leftover? Only after that’s confirmed does the fix get applied: bind the service to localhost only, and let the reverse proxy be the sole path in, reusing the authentication that’s already sitting there rather than building something new.
SSH exposure. Tens of thousands of failed login attempts against SSH is not, by itself, a meaningful finding — it’s ambient internet background radiation, the same automated scanning every SSH-reachable IP on the planet receives continuously. Treating that number as an incident produces alert fatigue and nothing else. The useful question is narrower: do any of the successful logins fail to match a known-good pattern (expected source, expected account, expected time), and — separately, and just as importantly — is the thing that’s supposed to be blocking the failed attempts (fail2ban, in this case) actually running, or just installed and never enabled. Both of those are real, distinct checks. A tool that’s present but inactive gives you none of the protection its presence implies, and that gap is invisible unless you specifically check service status rather than just confirming the package exists.
The general shape
Across all three, the same three-step order holds:
- Read the logs before touching the config. The logs tell you who’s actually using the thing you’re about to change, which is the one piece of information that determines whether your fix is safe.
- Separate “is this exposed” from “has this been exploited.” They call for different responses — a config fix versus a config fix plus rotating whatever might have been taken.
- Design the fix to preserve the legitimate path, not just remove the exposed one. The safer version of a working system (bind to localhost, add the deny rule, route through the auth that already exists) beats a version that’s secure but broken, because a broken system creates its own pressure to reopen the hole “just for now.”
This is the exact pattern that hardened technetguy.site itself, which is a useful data point in its own right: the discipline holds up whether the target is a client environment or the infrastructure serving the page you’re reading right now.
The rest of the hardening pass — VPN rollout, DNS filtering decisions, and the fixes those three findings led to — is in the network security case study.