Walk me through how you would harden a fresh internet-facing Linux server.
Short answer
Reduce attack surface (remove unused packages/services), enforce key-only SSH with no root login, keep the system patched, run a default-deny firewall exposing only needed ports, apply least privilege via sudo and file permissions, enable auditd and centralized logging, and add integrity monitoring plus MAC like SELinux or AppArmor.
Hardening is the systematic removal of anything an attacker could use, plus the addition of controls to detect and contain them if they get in. A useful frame is the CIS Benchmarks, but the reasoning matters more than the checklist.
Reduce the attack surface
Start by removing what you don't need: uninstall unused packages, disable services that aren't required, and close unnecessary listening ports. Every running service is a potential entry point. A minimal base image with only the workload's dependencies is far easier to defend.
Lock down remote access
SSH is the front door of an internet-facing box:
- Disable password authentication entirely; use key-based auth (keys resist brute force in a way passwords never will).
- Disable direct root login; admins log in as a normal user and elevate via
sudo. - Restrict source IPs where feasible, and consider non-standard configs and fail2ban to blunt automated attacks.
Patch and firewall
- Keep the kernel and packages patched, ideally with automated security updates — unpatched software is the most common breach vector.
- Run a default-deny firewall (nftables/iptables or cloud security groups) that allows only the specific inbound ports the service needs.
Enforce least privilege
Run services as dedicated non-root users, set tight file permissions, and use mandatory access control — SELinux or AppArmor — to confine processes so a compromised service can't roam beyond its policy, even as root.
Detect and verify
- Enable auditd and ship logs to a central, off-host collector so an attacker can't simply wipe local evidence.
- Add file integrity monitoring (AIDE/Tripwire) to catch tampered binaries or config.
What interviewers look for
A senior answer is structured — surface reduction, access control, patching, least privilege, detection — and explains the why (e.g. keys over passwords, logs off-host). Bonus for naming CIS benchmarks and MAC like SELinux rather than stopping at "set a strong password."
Likely follow-ups
- Why disable password-based SSH in favor of keys?
- What does SELinux or AppArmor add on top of file permissions?
- How would you detect that a binary on the host was tampered with?