I85PREP
⌘ K
CTLA study materials
CTLA study resources

CTLA: Security Fundamentals and System Hardening

CTLA · Work through your exam, one topic at a time.

All guide sections

Security Fundamentals and System Hardening

This domain tests defensive configuration: least privilege, remote access control, mandatory access control, auditing, and knowing which mitigation addresses which threat. CTLA questions usually present a service that broke after a hardening step, or ask you to choose the control that satisfies a stated requirement.

Least privilege and privilege escalation

Run services as dedicated unprivileged users. sudo grants specific commands per /etc/sudoers (always edited with visudo, which validates syntax); sudo -l shows what the invoking user may run. su requires the target account's password, sudo requires the caller's. File capabilities (getcap/setcap) grant a single privilege such as cap_net_bind_service without full setuid root.

SSH hardening

In /etc/sshd_config: PermitRootLogin no, PasswordAuthentication no, PubkeyAuthentication yes, and AllowGroups where appropriate. Key permissions are enforced: ~/.ssh 700, authorized_keys 600, private keys 600 - loose permissions cause silent fallback to password auth. Validate with sshd -t and reload; an error in a Match block can otherwise lock everyone out.

Mandatory access control

SELinux modes are enforcing, permissive, and disabled; check with getenforce. Diagnose denials with ausearch -m AVC -ts recent or sealert. Label files to the correct type with semanage fcontext -a -t httpd_sys_content_t '/srv/www(/.*)?' then restorecon -Rv /srv/www; toggle policy with setsebool -P. AppArmor uses per-program profiles in /etc/apparmor.d/ with aa-status.

Auditing and integrity

auditd rules watch files and syscalls; journald should be persistent (Storage=persistent); AIDE or similar baselines file hashes. Audit setuid binaries with find / -perm -4000 -type f. Kernel hardening via sysctl (kernel.randomize_va_space, net.ipv4.conf.all.rp_filter) and PAM modules (pam_pwquality, pam_faillock) for password and lockout policy.

Worked example

Static content moved to /srv/www returns 403 from Apache, and /var/log/httpd/error_log says permission denied even though the files are mode 644. Reasoning: permissions are fine, so this is SELinux. ausearch -m AVC -ts recent shows a denial for httpd_t reading the wrong type. The fix is a persistent fcontext rule plus restorecon - not chmod 777 and not setenforce 0. Note that mv preserves the source label while cp assigns a default label from the parent directory, which is why copied files sometimes work and moved ones do not.

Traps

  • Disabling SELinux instead of correcting labels; permissive still logs, disabled requires a relabel on re-enable.
  • chmod 777 as a fix - it is never the answer.
  • Setting PasswordAuthentication no before verifying key login works.
  • Reloading sshd without sshd -t validation.