System Hardening and Secure Configuration Questions

Covers host and operating system level security hardening, establishing and maintaining repeatable configuration baselines, and implementing secure endpoint configuration as part of a layered defense strategy. Candidates should understand reducing attack surface by disabling unnecessary services and features, configuring host based firewall rules, enforcing least privilege for file and directory permissions, and applying secure account and user management practices such as removing or disabling unnecessary user accounts and enforcing strong authentication and password policies. Include secure remote access practices such as key based Secure Shell authentication and secure transport protocols, certificate and key management, and encryption for data at rest and in transit. Cover platform specific controls including Security Enhanced Linux and AppArmor for Linux and Windows security baseline configurations and hardening guidance. Candidates should be familiar with using published security benchmarks such as Center for Internet Security benchmarks and vendor guidance, performing regular vulnerability scanning and remediation, patch and update management, audit logging and monitoring, and configuration management and automation. Also expect knowledge of policy as code and infrastructure as code for automated hardening and drift detection, documenting secure configuration and rollback procedures, continuous compliance reporting, and balancing operational needs with security to mitigate realistic threat scenarios.

EasyTechnical

78 practiced

For a small Linux web server, describe in detail how you would configure the host-based firewall to minimize attack surface while allowing HTTP/S traffic. Include default policies, specific rules (including stateful handling), logging, and how you would persist and test rules across reboots.

Sample Answer

**Overview / Goals**- Minimize attack surface: deny by default, allow only required services (HTTP/HTTPS, SSH optionally from admin IPs), use stateful rules, enable logging (rate‑limited), persist rules, and test thoroughly.

**Default policies**- Incoming: DROP- Forward: DROP- Outgoing: ACCEPT (or DROP with explicit DNS/updates allowed if stricter)

**Example (nftables)**

bash

# /etc/nftables.conf (core excerpt)
table inet filter {
  chain input {
    type filter hook input priority 0;
    policy drop;
    ct state established,related accept
    iif lo accept
    tcp dport { 80, 443 } ct state new accept
    tcp dport 22 ip saddr 203.0.113.5/32 ct state new accept  # admin IP optional
    icmp type echo-request limit rate 4/second accept
    counter log prefix "NFT_INPUT_DROP: " flags tcp-sequence limit rate 5/second
    reject
  }
  chain forward { type filter hook forward priority 0; policy drop; }
  chain output { type filter hook output priority 0; policy accept; }
}

**Stateful handling**- Use conntrack (ct state established,related) to accept return traffic and prevent blind open ports.

**Logging**- Log dropped packets with rate limits to avoid log flooding; send logs to rsyslog/journald and rotate.

**Persistence**- Place rules in /etc/nftables.conf and enable systemd service: systemctl enable --now nftables- For iptables: use iptables-save > /etc/iptables/rules.v4 and enable iptables-persistent.- For UFW: configure and ufw enable (it manages iptables underneath).

**Testing**- From remote host: curl -I http://yourserver and https- nmap -sS -Pn to confirm only 80/443 (and allowed SSH) open- sudo nft list ruleset (or iptables -L -n -v) to verify loaded rules- Simulate established/related behavior and check logs: sudo journalctl -f | grep NFT_INPUT_DROP

**Hardening tips**- Run HTTP service as non-root, enable fail2ban, keep minimal packages, and monitor logs/alerts.

HardTechnical

40 practiced

You're migrating ad-hoc shell scripts that configure security settings into a policy-as-code framework (examples: OPA/Rego, Chef InSpec). Outline a migration plan covering inventorying scripts, decomposing policies, writing unit and integration tests for policies, CI/CD integration, deployment staging, rollback mechanisms, and how to preserve emergency operational flexibility.

Sample Answer

**Clarify scope & goals**- Target: replace ad‑hoc shell scripts that enforce security settings with policy-as-code (OPA/Rego or Chef InSpec).- Success criteria: parity of enforcement, test coverage, auditable policies, safe rollout, ability to respond to emergencies.

**Inventory & analysis**- Scan repos/hosts for scripts (git, /etc, cron, config management). Catalog: purpose, owner, frequency, platforms, side effects, dependencies, test cases, risk level.- Classify: read-only audit vs. mutating enforcement vs. remediation.

**Decompose into policies**- For each script, extract intent (e.g., "disable root SSH", "ensure sysctl net.ipv4.conf.*"). Map to policy unit: query (OPA) or control (InSpec).- Keep small, single-responsibility policies with metadata (owner, severity, platforms).

**Testing strategy**- Unit tests: write Rego unit tests or InSpec controls running against test fixtures (Docker/VM images) to validate decision logic.- Integration tests: use ephemeral cloud VMs or containers with known bad/good states. Run policies, assert detection and optional remediation.- Regression tests: run policy suite against golden images/CI pipelines.

**CI/CD integration**- Lint and unit tests on PRs. Use pipeline stages: lint → unit tests → integration tests (on ephemeral infra) → policy review/approval → artifact publish.- Gate merges on test pass and owner approval. Store policy artifacts in versioned registry.

**Deployment & staging**- Environments: dev → staging → production. Start in audit-only mode (InSpec: non-remediating; OPA: dry-run with logging) for a time window, monitor alerts.- Gradual enforcement: enable remediation for low-risk policies first, measure impact.

**Rollback & safety**- Deploy feature flags/toggles per-policy. Keep previous policy version available; automated rollback job to switch flags or revert deployment.- Use canary rollout (subset of hosts) and health checks; if policy causes failures, auto-disable and notify runbook owner.

**Preserve emergency operational flexibility**- Maintain an emergency bypass: short-lived, auditable allowlist (host or user-based) and a documented emergency procedure to temporarily disable specific policies via signed change with TTL.- Keep scripts accessible as emergency playbooks (stored in repo with tests) until fully validated.- Ensure RBAC: only authorized admins can toggle enforcement; log all changes for post-incident review.

**Governance & runbook**- Document policy lifecycle, owners, SLAs for change. Regular audits and periodic reviews. Train on emergency procedures and CI/CD rollback steps.

This plan balances safety, testability, and operational agility while moving to auditable, maintainable policy-as-code.

HardTechnical

46 practiced

Compare SELinux and AppArmor in depth: kernel integration and LSM model, granularity of control, performance overhead, ease of authoring and testing policies, available tooling, and their suitability for containerized environments. Explain how you would debug complex denials and package policies for automated deployment.

Sample Answer

**Overview & kernel/LSM model**SELinux and AppArmor are both Linux security modules (LSMs) but differ: SELinux is label-based (every inode, socket, process has a security context) tied deeply into the kernel VFS and object labeling; AppArmor is path-based, matching program paths and not relying on extended labels. SELinux enforces at many kernel hooks; AppArmor hooks fewer, simpler paths—this affects granularity and some attacks.

**Granularity of control**- SELinux: very fine-grained (types, roles, domains, MLS/ MCS), can restrict syscalls, file/IPC/socket access per context.- AppArmor: coarser, profile-oriented by executable path; easier to express typical file/network rules but less control over per-object labeling.

**Performance**- Both low overhead; SELinux can be slightly heavier due to labels and more checks but in practice <1–2% in I/O-heavy workloads. AppArmor tends to be marginally faster because matching is path-based and simpler. Measure with perf/benchmarks for your workload.

**Authoring & testing**- SELinux: steeper learning curve; uses policy language (TE, types) and tools like audit2allow, sepolicy, semodule; writing safe policy requires understanding contexts and booleans. Testing: permissive mode per domain, setroubleshoot/audit logs.- AppArmor: simpler profile syntax, easier to write and iterate; aa-genprof, aa-logprof for guided policy generation.

**Tooling**- SELinux: semanage, semodule, setenforce, ausearch, sealert, audit2allow, cockpit-SELinux plugins.- AppArmor: aa-genprof, aa-status, aa-complain/enforce, apparmor_parser, journalctl for denials.

**Containers suitability**- SELinux (MCS/MLS) integrates well with container runtimes (Docker, Podman) using container labels to isolate container processes; better for multi-tenant strong isolation. AppArmor is simpler and supported by Docker; good for single-host app confinement and easier profiles for image-specific services. For strict multi-tenant clusters prefer SELinux; for quick app-level confinement prefer AppArmor.

**Debugging complex denials**1. Reproduce the action under the same context/profile.2. Collect logs: ausearch -m AVC -ts recent / journalctl | grep apparmor | sealert -a /var/log/audit/audit.log.3. For SELinux: run in permissive for the domain, capture AVCs, use audit2allow to generate candidate rules, review and convert to least-privilege TE rules; test in targeted permissive then enforce.4. For AppArmor: switch profile to complain mode (aa-complain), reproduce, run aa-logprof to incorporate rules.5. Iteratively tighten, use unit tests/CI to exercise flows.

**Packaging & automated deployment**- SELinux: build policy modules (semodule_package), include file contexts, load via semodule -i; store semodule .pp in config management (Ansible/Chef) and apply on boot; manage booleans via semanage. Use CI to run test VMs with setenforce=1.- AppArmor: store profiles under /etc/apparmor.d/, validate with apparmor_parser --lint, load at boot via systemd unit or profile installation tasks. Integrate aa-complain -> aa-enforce transition in pipeline.- Best practices: version-controlled policies, automated tests that exercise services, image/build-time linting, rollout in staged environments (complain/permissive → enforce), monitor denial alerts, and include rollback automation.

This approach balances security and operability for production systems.

HardTechnical

47 practiced

You discover a suspicious process running as root on multiple Linux servers that appear compromised. Provide a detailed investigation and containment plan: steps to collect volatile and persistent evidence, isolate affected hosts, determine point-of-entry and lateral movement, patch exploited vulnerabilities, and restore hardened systems from trusted images. Include coordination with security operations and legal where necessary.

Sample Answer

**Overview / Goals**Identify scope, collect forensically-sound evidence (volatile first), contain without destroying artifacts, determine root cause and lateral movement, remediate vulnerabilities, restore systems from trusted images, and coordinate with Security Operations and Legal.

**Immediate actions (first 0–30 min)**- Notify SecOps and incident response lead; open an incident ticket with severity and timeline.- Quarantine affected hosts from network (apply switch port shutdown or VLAN isolation) but keep them powered on for volatile evidence.- Record system state (who, when, commands run) and take photos if physical.

**Volatile evidence collection (preserve first)**- Capture memory image (e.g., LiME) of each compromised server.- Dump /proc, running processes (ps auxww), network connections (ss -tunap), open files (lsof), kernel logs (dmesg), and current netfilter rules.- Collect output of: uname -a, who -a, last, crontab -l (root and service accounts), sudo -l.- Export security-related logs from syslog/journald (journalctl -o short-precise --since), and retrieve active SSH sessions.

**Persistent evidence collection**- Create forensic copies (bit‑for‑bit) of disks (using dd or preferably dc3dd) to remote forensic storage; compute and record hashes (sha256).- Collect /etc, /var/log, /root/.ssh, /home/*/.ssh, authorized_keys, installed packages list (rpm -qa / dpkg -l), cron jobs, systemd unit files, and suspicious binaries.- Preserve configuration of intrusion detection, firewall, and orchestration systems.

**Containment and scope**- Block known malicious C2 IPs/domains at perimeter and host-based firewalls.- Disable compromised accounts, rotate keys and service credentials.- Use host snapshots in read-only mode for forensic analysis if cloud VMs; avoid rebuilding until evidence collected.- Identify other hosts with indicators of compromise (IOCs) via central logging / EDR / SIEM and isolate them.

**Root-cause & lateral movement analysis**- Correlate logs (SSH auth failures, sudo events, new accounts, binary writes) across hosts.- Analyze memory images for rootkits, injected processes, network connections to C2.- Map timeline: initial exploit timestamp, privilege escalation artifacts, lateral tools (psexec-like, ssh keys), and persistence mechanisms.- Check jump boxes, CI/CD pipelines, and shared credentials as likely entry points.

**Remediation & patching**- Patch vulnerable services and OS based on root cause (apply CVE fixes, kernel updates).- Revoke and reissue compromised keys and certificates; enforce MFA.- Hardening: disable unused services, implement least privilege, enable SELinux/AppArmor, enforce immutable boot images where possible.

**Restoration**- Rebuild compromised hosts from trusted golden images stored in secure registry; ensure images are patched and approved.- Restore data from verified backups; validate integrity and scan before reintroducing to network.- Perform post-rebuild monitoring and threat hunts for recurrence.

**Coordination & legal**- Engage Legal/Compliance for breach notification obligations and preservation orders.- Share IOCs and timelines with SecOps, SOC, and management; coordinate communications to stakeholders.- If required, engage external forensics or law enforcement; provide hashed, documented evidence chain-of-custody.

**Post-incident**- Conduct a lessons-learned, update runbooks, improve detection rules, and schedule phishing/password audits and staff training.

EasyTechnical

37 practiced

Describe step-by-step how you would harden a freshly provisioned Linux server to a secure baseline. Include initial package updates, minimizing installed packages, user and SSH configuration, disabling unnecessary services, host firewall rules, logging and audit configuration, file permissions, and a plan to automate these steps for repeatability and rollback. Assume the server runs Ubuntu LTS and must align with CIS benchmarks.

Sample Answer

**Approach — goal:** Bring a fresh Ubuntu LTS VM to a CIS-aligned, repeatable, auditable baseline with minimal attack surface and rollback capability.

**1) Initial updates & package minimization**- Update OS and packages:

bash

sudo apt update && sudo apt -y upgrade && sudo apt -y dist-upgrade

- Remove unwanted packages (snap, games, gui if server):

bash

sudo apt -y purge package1 package2
sudo apt -y autoremove

**2) Users, auth & SSH**- Create admin account, disable root login:

bash

sudo adduser admin; sudo usermod -aG sudo admin
sudo passwd -l root

- Harden SSH (/etc/ssh/sshd_config): PermitRootLogin no, PasswordAuthentication no, UsePAM yes, AllowUsers admin, Protocol 2, set IdleTimeout, ClientAliveInterval.- Deploy key-based auth, use ssh-agent forwarding sparingly, and restrict IPs with firewall.

**3) Disable unnecessary services**- List enabled services: `systemctl list-unit-files --state=enabled`- Disable/stop unneeded services: `sudo systemctl disable --now service`

**4) Host firewall**- Use ufw or nftables; default deny inbound, allow outbound; allow SSH from admin networks:

bash

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow from 203.0.113.0/24 to any port 22 proto tcp
sudo ufw enable

**5) Logging & audit**- Enable and configure rsyslog/journald retention, forward logs to central SIEM.- Install and configure auditd with CIS rules; ensure immutable logs and monitor with AIDE:

bash

sudo apt install auditd aide
sudo aideinit

**6) File permissions & kernel hardening**- Apply secure permissions on /etc/shadow, /etc/sudoers; remove world-writeable files.- Tune sysctl (/etc/sysctl.conf) for NET and filesystem hardening (IP spoofing, ICMP redirects, ASLR).

**7) CIS benchmark alignment**- Run CIS Ubuntu LTS checklist (manual & automated). Use tools like OpenSCAP or CIS-CAT to scan and produce remediation guidance; iterate until compliant.

**8) Automation, repeatability & rollback**- Encode all steps as idempotent IaC/CM: Ansible playbooks (preferred), Terraform for provisioning, and Packer for golden images.- Example structure: roles for packages, ssh, firewall, auditd, cis-audit.- Use git for versioning; tag releases. Test via CI (Molecule for Ansible).- Rollback: keep immutable images and versioned playbooks; snapshot VM before apply (cloud snapshot), and have automated restore playbooks plus documented manual recovery steps.

**9) Verification & monitoring**- Post-hardening checklist: confirm SSH login, firewall rules, CIS scan pass, audit logs flowing, and automatic updates status.- Schedule recurrent scans, patching windows, and configuration drift detection (OSSEC, Tripwire, or Salt/Ansible scans).

This sequence balances immediate risk reduction, CIS alignment, and operational repeatability with safe rollback options.

Unlock Full Question Bank

Get access to hundreds of System Hardening and Secure Configuration interview questions and detailed answers.

Join thousands of developers preparing for their dream job.