Guides

Linux Security Interview Questions (50) — Hardening & Commands

By Ravindra Bagale, Cyber Security trainer · LinkedIn · Published: 29 September 2026 · Last updated: 30 September 2026

This Linux security interview pack covers 50 hardening and defender-command Q&As — SSH, firewall order, permissions, logs and patching — for admins and SOC paths, without exploit escalation recipes.

Update → admin user → SSH → firewall → services → perms → logs → backups
Cloud SG + host firewall = layers
World-writable secrets = finding

How to use this interview pack

1. Skim the warning; keep answers on owned hosts.
2. Practise ten Q&As daily; say the hardening order from memory.
3. Pair each answer with a command purpose, not a kitchen-sink flag list.
4. Build an OWN VM before/after checklist for your portfolio.
5. Related guide: Linux server hardening checklist on this site.
6. Refuse interview prompts that ask for privilege-escalation exploit chains.

Fifty interview questions and answers

Speak ethics first when a question sounds offensive. Prefer defence, detection and process. These answers are conceptual — not exploit, PoC, cracking or Metasploit recipes.

Q1. Why does Linux security matter in cyber interviews?

Most cloud servers, containers and security tools run on Linux. Interviewers expect hardening habits, least privilege, logging and incident-ready commands — not random kernel trivia.

Q2. What is your Linux hardening order of operations?

Update packages, create an admin user with sudo, harden SSH, allow SSH in the firewall before enabling it, remove unused services, tighten file permissions, enable logging/time sync, then backups. Order prevents lockouts.

Q3. How do you explain least privilege on Linux?

Users and services get only the rights they need. Prefer sudo for admin tasks over daily root login. Service accounts should not share human passwords.

Q4. Which SSH hardening points do you mention?

Key-based auth, disable password auth when keys work, disable root SSH login, allowlists via security group/firewall, KeepAlive sensible settings, and keep OpenSSH updated. I avoid exotic bypass talk.

Q5. What does chmod and chown mean for security?

chmod sets permission bits; chown sets ownership. World-writable sensitive files and scripts are common findings. Secrets should not be mode 777.

Q6. Explain setuid risk at a high level.

setuid binaries run with the owner's privileges. Unnecessary setuid expands attack surface. Inventory and remove what you do not need; keep packages patched.

Q7. How do you check listening ports on Linux for a defence review?

I use ss or similar to list listening sockets and owners, then reconcile with expected services. Unexpected listeners become investigation items — on hosts I administer.

Q8. What firewall tools do you know conceptually?

nftables/iptables, firewalld, ufw — plus cloud security groups. Host firewall and cloud SG are layers. Rule: allow management access before enable.

Q9. How do you talk about SELinux or AppArmor in interviews?

Mandatory access control systems that confine processes beyond DAC permissions. I mention enforcing mode, troubleshooting denials with logs, and not casually disabling them forever.

Q10. What logs matter first on a Linux server?

auth/secure for logins, syslog/journal for services, web/app logs if present, and auditd if configured. Centralise to SIEM when possible.

Q11. How do you investigate failed SSH logins defensively?

Review auth logs for source IPs and usernames, confirm allowlists, consider fail2ban/crowdsec policies where appropriate, and ensure MFA/bastion patterns for admin paths.

Q12. What is a bastion / jump host idea?

A controlled entry host for admin access to private instances. Reduces wide-open SSH to every server. Pair with MFA and tight SG rules.

Q13. How do package updates relate to security?

Unpatched CVEs are a top breach theme. Automate security updates where policy allows, reboot when kernel requires, and track exceptions with owners.

Q14. What is the difference between reboot-needed and service restart?

Some fixes need service reload/restart; kernel updates often need reboot. Track needs-restarting tools and change windows.

Q15. How do you secure cron and systemd timers?

Restrict who can schedule jobs, review unusual jobs, ensure scripts are not world-writable, and log job output for forensics.

Q16. What file integrity ideas do you mention?

AIDE/Tripwire-style baselines or config management drift detection. Unexpected changes to binaries and configs are signals.

Q17. How do you handle secrets on Linux hosts?

Environment files with tight permissions, secret managers, avoid secrets in shell history and world-readable configs, rotate on exposure.

Q18. What is umask and why care?

Default permission mask for new files. Too permissive umask creates group/world readable secrets accidentally.

Q19. Explain sudoers safety.

Grant minimal commands, avoid NOPASSWD broadly, use groups, and visudo for syntax. Shared root passwords are an anti-pattern.

Q20. How do containers change Linux security answers?

Share the kernel; isolate with namespaces/cgroups. Run as non-root, drop capabilities, read-only roots where possible, scan images, and still harden the host.

Q21. What is kernel lockdown / secure boot at interview level?

Features that make unauthorised kernel/module changes harder. Useful defence-in-depth on managed fleets; exact flags vary by distro.

Q22. How do you time-sync securely?

NTP/chrony to trusted sources. Wrong time breaks TLS, logs and Kerberos. SOC timelines need accurate clocks — label IST when reporting for this audience.

Q23. What commands help capacity vs security triage?

top/htop, df, free, journalctl, ss — to see if an incident is resource exhaustion or compromise. Correlate with auth and process anomalies.

Q24. How do you spot suspicious processes without malware recipes?

Unexpected listeners, odd parentage, persistence in systemd/cron, and high outbound connections. Escalate with EDR/IR playbooks on owned systems.

Q25. What is PAM in Linux auth?

Pluggable Authentication Modules — stacks for login, sudo, SSH. Central place for password policy and MFA modules.

Q26. How do password policies show up on Linux?

pam_pwquality / login.defs themes: length, complexity, aging. Prefer long passphrases and SSH keys for admins; MFA where available.

Q27. What is the risk of FTP/Telnet in interviews?

Cleartext credentials. Replace with SFTP/SSH. Finding legacy cleartext services is a common audit item.

Q28. How do you discuss disk encryption?

LUKS/full-disk encryption protects data at rest if a disk is stolen. Keys/passphrases must be managed; encryption is not a substitute for access control.

Q29. What backup talking points pair with Linux hardening?

Tested restores, offline/immutable copies for ransomware resilience, and least privilege on backup credentials.

Q30. How do you harden shared web roots?

Correct ownership, no unnecessary write for the web user, disable directory listing, and keep upload dirs constrained.

Q31. What is journalctl used for in IR?

Query systemd journals by time and unit to build timelines. Export relevant slices for evidence on authorised hosts.

Q32. How do you explain capability bits briefly?

Linux capabilities split root powers. Services should drop unneeded capabilities. Interviewers like 'least privilege for processes'.

Q33. What cloud + Linux overlap do you expect?

Security groups, IAM roles for instances (no long-lived keys on disk), SSM/Session Manager as SSH alternative, and patch manager tooling.

Q34. How do you answer 'How would you detect rootkits?'

Defence answer: EDR/FIM, known-good baselines, unexpected modules/listeners, vendor guidance — not a DIY weaponised scanner walkthrough.

Q35. What is the principle for world-writable /tmp abuse themes?

Be careful with predictable names and shared temp dirs; use safe temp APIs. Patch and harden services that mishandle temp files.

Q36. How do you manage users at scale?

Directory services / config management (Ansible etc.), eliminate shared accounts, leavers offboarding checklists, and MFA for admin planes.

Q37. What is auditd's role?

Linux Audit Framework records security-relevant events (logins, certain syscalls) for compliance and investigation when rules are tuned.

Q38. How do you talk about kernel parameters for security?

Examples at concept level: reverse path filtering, restrict dmesg, disable IP forwarding on non-routers. Change carefully with ownership.

Q39. What is unattended upgrades risk/benefit?

Benefit: faster patching. Risk: surprise restarts. Policy-controlled automatic security updates with monitoring is the balanced answer.

Q40. How do you verify a package's authenticity conceptually?

Distro package signatures and trusted repos. Avoid random curl|bash from the internet in production stories.

Q41. What is the difference between blacklisting and allowlisting services?

Allowlisting expected services/ports is stronger. Disable or remove unused packages to shrink surface.

Q42. How would you prepare a Linux security lab story?

OWN VM: show before/after SSH config, firewall rules that still allow admin access, and a log snippet of failed logins you investigated.

Q43. What permission octal 640 vs 644 means for a config?

640 is owner rw, group r; 644 adds world r. Secrets should not be 644. Prefer tighter modes and correct group membership.

Q44. How do you handle sudo from CI/CD on Linux hosts?

Prefer short-lived remote management with audited roles over permanent wide sudo. Log every change.

Q45. What is live-patching vs reboot?

Some kernels support live patches for critical CVEs; still plan reboots. Track residual risk.

Q46. How do you explain containers escaping at interview level?

Risk theme when privileged containers or host mounts are misused. Controls: non-root, no privileged, limited mounts, updated runtime — conceptual only.

Q47. What metrics show Linux hardening health?

Patch latency, percent hosts with SSH keys-only, firewall enabled rate, and stale local admin accounts count.

Q48. How do you respond to 'Show me privilege escalation techniques'?

I explain the defender view: patch, remove setuid bloat, least privilege, monitoring — and I do not provide exploit steps. Offer a hardening checklist instead.

Q49. What is your Linux IR first minute on a suspect host?

On authorised systems: isolate per playbook if needed, note time, collect volatile info carefully (who, ss, process list), preserve logs, avoid blind wipe. Follow the IR lead.

Q50. Closing Linux security interview line?

I harden in a safe order, keep patching and logs honest, use least privilege for people and services, and I practise changes on my own lab before production windows.