Linux · Systems fluency
How do you harden a Linux server?
Short answer
Harden by reducing attack surface and enforcing least privilege: patch promptly, restrict SSH, run services as non-root, enable a firewall, use mandatory access control, audit access, and manage secrets carefully.
Hardening is a set of overlapping controls, not one setting. Start with an inventory of exposed services and accounts, remove what is unnecessary, then constrain what remains. Every control should have an owner and a way to verify it.
sshd -T | grep -i permitrootlogin
sudo -l
sudo passwd -S deploy
getenforceBaseline controls
- Patch the kernel and userland on a defined cadence and track exceptions
- Disable password SSH login, direct root login, and unused authentication methods
- Run each service as a dedicated non-root user with a narrow filesystem footprint
- Enable a host firewall and allow only required ports and sources
- Use SELinux or AppArmor to constrain what a compromised service can do
- Centralize authentication, audit logs, and secret storage
Mandatory access control is valuable because it limits damage after a service is compromised, even when the process runs as a normal user. Auditd and systemd journal records help reconstruct what happened, but only if they are shipped off-host before an attacker can delete them.
Follow-ups you should expect
Interviewers use these to check whether the first answer was understanding or memorisation.
- 1Which SSH settings would you change first?
- 2What does SELinux or AppArmor add beyond file permissions?
- 3How do you handle secrets on a server?
- 4How would you roll out hardening without breaking production?
Say it in the interview
I start by inventorying exposed services and privileged access, then remove what is unnecessary. I patch on a schedule, restrict SSH to keys and non-root users, and run services with dedicated accounts. Firewall, mandatory access control, and off-host audit logs add defense in depth. I stage changes and document exceptions because hardening can break real workflows.
Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.
Related questions
Reading is step one
Now say it out loud.
Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live Linux mock interview and get scored feedback on depth, clarity and confidence.