Access control
Key-only SSH, root login disabled, a non-standard port where it reduces noise, and per-person accounts so actions are attributable.
Servers, Hosting & DevOps
Server security & hardening
Hardening is unglamorous and mostly consists of turning things off. Fewer open ports, fewer accounts, fewer services running as root, fewer credentials that never expire. The measurable goal is a smaller attack surface, not a longer list of installed security tools.
The second half matters just as much: detection. Plenty of compromised servers ran for months because nobody was reading the logs, and the first sign of trouble was a hosting provider suspending the account for outbound spam.
How I work on it
Process
Adjusted to the job, but this is the shape it usually takes.
-
Baseline
Establish what is running and what is exposed before changing anything, so improvements are measurable.
-
Reduce surface
Remove unused services and accounts first. This is the highest-value, lowest-risk step and it is skipped surprisingly often.
-
Layer defences
Network, host and application controls, on the assumption that any single layer can fail.
-
Verify detection
A deliberately triggered alert to confirm monitoring works. Untested alerting is a false sense of security.
Questions
Things people ask
No, and it should never be the only measure. It does cut log noise from automated scanners considerably, which makes genuine intrusion attempts easier to spot. Useful as hygiene, useless as a defence.
Common signals: outbound mail volume you cannot account for, unfamiliar cron entries, processes running from /tmp or /dev/shm, modified system binaries, and unexpected outbound connections. A compromised host cannot be fully trusted to report on itself, so serious cases get checked from outside.
I do configuration review and hardening rather than adversarial penetration testing. For a formal pentest with a report you can hand to an auditor, you want a specialist firm, and I am happy to fix what they find.