← Guide index · Repository home
Host security is layered risk reduction: patching, least privilege, minimal services, strong authentication, protected secrets, constrained workloads, and useful audit evidence.
Caution
Inspect targets and understand impact before running privileged or mutating commands. Test changes in a safe environment first.
An internet-facing service should expose only required ports, run as an unprivileged identity, receive secrets through controlled channels, and have a documented patch and access-review process.
| # | Working principle |
|---|---|
| 1 | Attack surface grows with installed software, listening services, privileges, and reachable interfaces. |
| 2 | sudo provides controlled elevation and an audit boundary when policy is narrow. |
| 3 | Mandatory access control and systemd sandboxing limit damage beyond discretionary permissions. |
ss -lntup
systemctl --type=service --state=running
sudo -l
find / -xdev -perm -4000 -type f -print
systemd-analyze security order-api.service
last -a | headCommands are examples for observation and controlled testing. Paths, process identifiers, interfaces, and service names must be adapted to the actual host.
- Define the symptom, affected users, and time window.
- Collect the smallest useful set of host and service evidence.
- Form one falsifiable hypothesis.
- Make the least disruptive test or change.
- Verify recovery and record what was learned.
- Remove or disable services that have no owner or requirement.
- Use key-based administration, MFA where supported, and reviewed sudo policy.
- Automate security updates according to an explicit maintenance policy.
- Disabling security controls to make deployment easier.
- Storing secrets in shell history or world-readable environment files.
- Applying a generic hardening script without compatibility testing.
- How would you reduce a server's attack surface?
- What is the security value of a non-root service account?
- How do you validate hardening without breaking availability?