Patching before the scanners arrive

Hacker's handbook • 3 min read

Most successful attacks don't use secret techniques. They use vulnerabilities that were announced publicly, with a fix available, against sites that hadn't applied it yet. The announcement tells defenders what to patch. It tells attackers what to look for. From that moment it's a race, and AI has made the attackers' side of it much faster.

What happens after a vulnerability is published

The advisory goes out: a description of the flaw, the affected versions, and usually a fixed version.
Exploits appear: working attack code is often written within days, and sometimes within hours. Writing it from the advisory is a task AI can now help with.
Scanning starts: automated tools check every reachable server for the vulnerable version. They don't care whose server it is.
Unpatched sites are attacked: whoever hasn't updated yet is found and exploited, often without a person being involved at all.

The fix existing doesn't protect you. Only installing it does.

Know what you run

You can't patch software you don't know you have. Write down what's facing the internet, with versions:

Web server and proxy: nginx, Apache, Caddy, and anything in front of them.
Runtime and framework: the language version and the web framework your application is built on.
CMS, plugins, and themes: plugins are where a large share of content-management vulnerabilities live.
Operating system packages: including the libraries that handle encryption and images.
Appliances and tools: VPN gateways, mail servers, dashboards, and file-sharing tools. These are favourite targets because they sit at the edge of the network.

Attackers read version numbers too, so there's a small benefit in not advertising them, such as turning off version banners in server headers. That slows nobody down for long. It's not a substitute for updating.

Hear about it quickly

Subscribe to security announcements for the handful of products you depend on most. Most have a mailing list or feed.
Watch for "exploited in the wild": some national security agencies publish lists of vulnerabilities known to be under active attack, such as the Known Exploited Vulnerabilities catalog in the United States. Anything on such a list that you run is urgent.
Turn on automatic security updates for the operating system where you can.
Test from the outside: a check that looks at your live site tells you what's really running, not what you believe is running.

Decide what to fix first

You'll rarely be able to fix everything at once. Order the work by how reachable and how dangerous each problem is:

Internet-facing and actively exploited: fix today.
Internet-facing, needs no login to exploit: fix this week, sooner if exploit code is public.
Needs a logged-in user or unusual settings: schedule it.
Not reachable from outside: still fix it, but after the others.

Severity scores are a starting point. A "medium" flaw on your public login server can matter more than a "critical" one on a machine nobody can reach.

When you can't update yet

Sometimes a fix isn't available, or updating needs testing you can't do today. Reduce the exposure in the meantime:

Turn off the affected feature if you don't need it.
Restrict access to the affected service to known addresses.
Apply the vendor's workaround if the advisory gives one.
Block the attack pattern at your firewall or proxy as a stopgap.

Then put the real update on the calendar. Temporary measures have a way of becoming permanent.

Conclusion

Patching isn't glamorous, and it prevents more break-ins than anything else. Know what you run, hear about new vulnerabilities on the day, fix internet-facing systems first, and confirm from the outside that the update really took effect.