
Hardening a Small Server Without Making It Unusable
A single box running a couple of sites does not need a security programme. It needs about a dozen specific things done, and two of them are traps that look done when they are not.

A single box running a couple of sites does not need a security programme. It needs about a dozen specific things done, and two of them are traps that look done when they are not.

Self-hosting git needs no forge. git ships the server, nginx already speaks CGI, and the whole thing is about twenty lines of config. The one hard part is file ownership, and it will not tell you clearly that it is the problem.

Enumeration is not something you finish and move on from. Every credential and hostname you find sends you back to enumerate something new, so the surface grows as you work.

The attacks I read about for work arrive at ordinary people every day. What I actually do about that, in the order the effort pays back.

A raw reverse shell has no tab completion, no arrow keys, no job control, and dies the moment you press Ctrl-C. The upgrade takes three steps, and it is worth doing before anything else.

Code that creates a precondition stops being exercised the moment it succeeds. On the machine where setup already ran, the setup path can break completely and stay green.

Hiding data is not the same as proving nobody changed it. Treating the first as the second is the root of a whole class of real vulnerabilities.

In zsh, an array subscript inside arithmetic context is evaluated as an arithmetic expression, so it performs command substitution. Tallying strings into an associative array runs them.

When a box is stuck, the answer is almost never a more advanced technique. The winning path was usually visible at hour one and dismissed.

Name the point where data crosses into more trust and you have usually named the missing defence. Where that lens covers almost everything, and where it stops working.