Skip to content

Quiz: Linux Hardening

← Back to quiz index

9 questions

L1 (5 questions)

1. What are the first three things you harden on a fresh Linux server?

Show answer 1. Disable root SSH login (PermitRootLogin no).
2. Enable firewall (ufw/firewalld) with default-deny inbound.
3. Enable automatic security updates (unattended-upgrades on Debian, dnf-automatic on RHEL).

2. How do you find all SUID binaries on a system and why does it matter?

Show answer find / -perm -4000 -type f 2>/dev/null. SUID binaries run as the file owner (often root) regardless of who executes them. Attackers use them for privilege escalation. Audit the list regularly and remove SUID from any binary that doesn't need it (chmod u-s).

3. What are the first five security hardening steps you would perform on a freshly provisioned Linux server?

Show answer 1. Update all packages (apt upgrade / yum update).
2. Disable root SSH login (PermitRootLogin no in sshd_config).
3. Enable SSH key-only authentication (PasswordAuthentication no).
4. Configure a host firewall (allow only needed ports).
5. Enable and configure automatic security updates (unattended-upgrades on Debian, dnf-automatic on RHEL). Also: remove unnecessary packages, enable auditd, set umask 027. *Common mistake:* Install antivirus first — Linux servers rarely need AV; the listed steps address the most common attack vectors.

4. What is the purpose of SSH key passphrase and ssh-agent, and why should you use both?

Show answer A passphrase encrypts the private key file at rest — if stolen, it cannot be used without the passphrase. ssh-agent holds decrypted keys in memory so you enter the passphrase once per session, not per connection. Together: the key is protected on disk, and agent forwarding (ssh -A) lets you authenticate through jump hosts without copying the private key. Use ForwardAgent cautiously — a compromised jump host can use your agent. *Common mistake:* ssh-agent replaces the need for a passphrase — the agent caches the passphrase but does not eliminate the need to set one.

5. How do you disable unused network services and verify nothing unexpected is listening?

Show answer 1. List listening ports: ss -tlnp (TCP) and ss -ulnp (UDP).
2. Identify each service by PID/program.
3. Disable unnecessary services: systemctl disable --now .
4. Remove the package if the service is never needed.
5. Verify with nmap from an external host to check what is actually reachable. Common unnecessary listeners: cups, avahi-daemon, rpcbind. *Common mistake:* Block all ports in iptables and open them as needed — this can lock you out; always verify SSH access first and identify what is needed before restricting.

L2 (4 questions)

1. What is the purpose of SELinux/AppArmor and when does it help?

Show answer Mandatory Access Control (MAC) — restricts what processes can do beyond standard Unix permissions. Even if an attacker gets shell as www-data, SELinux/AppArmor can prevent reading /etc/shadow or binding to other ports. Use enforcing mode in production.

2. How does the Linux kernel's seccomp mechanism restrict container syscalls, and what happens when a blocked syscall is attempted?

Show answer seccomp-bpf applies a BPF filter to every syscall a process makes. The filter inspects the syscall number and arguments and returns an action: ALLOW, KILL (SIGSYS), ERRNO (return error), TRACE (notify tracer), or LOG. Container runtimes apply a default seccomp profile blocking ~44 dangerous syscalls (e.g., reboot, mount, kexec_load). A blocked call returns EPERM or kills the process depending on the profile's default action. *Common mistake:* seccomp only works with SELinux enabled — seccomp is independent of SELinux/AppArmor; they are separate security layers.

3. What are SUID/SGID bits and why are they a security concern? How do you find and audit them?

Show answer SUID (set user ID) makes a binary run as its owner (often root) regardless of who executes it. SGID does the same for group. Security concern: a vulnerable SUID-root binary gives any user root code execution. Audit: find / -perm -4000 -type f (SUID), find / -perm -2000 -type f (SGID). Remove SUID from unnecessary binaries (chmod u-s). Common legitimate SUID: passwd, sudo, ping (older kernels). *Common mistake:* Remove SUID from all binaries — removing it from sudo and passwd will break normal system operation.

4. What is the principle of least privilege and how does it apply to Linux file permissions, sudo, and capabilities?

Show answer Least privilege: every process/user should have only the permissions needed. File permissions: set restrictive modes (640 for config, 750 for scripts), use groups instead of world-readable. sudo: grant specific commands (user ALL=(ALL) /usr/bin/systemctl restart myapp) not blanket ALL. Capabilities: instead of running a binary as root, grant only the needed capability (setcap cap_net_bind_service+ep for binding port 80). Each layer reduces the blast radius of compromise. *Common mistake:* Use root for all administration to avoid permission issues — this violates least privilege and means any compromised process has full system access.