LPIC-3 Security common mistakes
LPIC-3 Security · Understand the traps and how to avoid them.
Using `gpg --encrypt` or `openssl enc` with symmetric ciphers and assuming the resulting file protects the confidentiality of data at rest without checking whether keys or passphrases are stored on the same host, and never configuring `--cipher-algo AES256` or an equivalent strong cipher.
Candidates study GnuPG and OpenSSL as command-line recipes and memorize flags for the exam without connecting them to key management. In practice the default cipher selection and the location of the private key or passphrase file are what determine whether encryption is meaningful, and the exam tests exactly that reasoning.
What to do instead
For every encryption task, state the key lifecycle explicitly: where the private key lives, how it is protected (passphrase, hardware token, file permissions), and what happens on key compromise. Practice gpg --list-packets and openssl enc -list to confirm the actual cipher and key derivation in use, and be able to explain why -md sha256 -pbkdf2 -iter matters for openssl enc.
Treating a self-signed X.509 certificate as equivalent to a CA-issued one and deploying it for TLS without adding the CA to the trust store, then debugging client failures by disabling verification (`curl -k`, `sslverify=false`) instead of fixing the chain.
The certificate chain of trust is conceptually simple but candidates rarely build one end to end, so they conflate 'the certificate exists' with 'the certificate is trusted'. Exam items about chain building, intermediate CAs, and CRL/OCSP checking expose this gap.
What to do instead
Build a three-tier chain in a lab: root CA, intermediate, leaf. Install the root into /etc/pki/ca-trust/source/anchors or /usr/local/share/ca-certificates and run update-ca-trust or update-ca-certificates. Verify with openssl verify -CAfile root.pem -untrusted intermediate.pem leaf.pem and openssl s_client -connect host:443 -showcerts. Never accept a fix that disables verification.
Configuring PAM stacks by editing `/etc/pam.d/` files without understanding the `control` field semantics (required, requisite, sufficient, optional) or the difference between `auth`, `account`, `password`, and `session` types, then wondering why a failed `requisite` module still lets authentication succeed or why `sufficient` short-circuits a later `required` module.
PAM is a frequent LPIC-3 topic and candidates copy example stacks from tutorials. The ordering and control-flag logic is what the exam probes, and copying bypasses the mental model.
What to do instead
Memorize the four module types and the control flags, then build a stack that combines pam_unix, pam_faillock, and pam_mfa and trace the outcome for each failure case by hand before testing. Use pamtester to exercise individual services and read man pam.d for the exact evaluation order of requisite versus required.
Relying on file mode bits alone for access control on shared directories and forgetting that permissions on the parent directory, ACL mask, sticky bit, and default ACLs govern the effective rights, so a `chmod 700` file inside a world-writable directory is still exposed via rename or delete.
Candidates learn rwx early and stop there. LPIC-3 expects fluency with POSIX ACLs (getfacl/setfacl, mask recalculation), the sticky bit, and how directory permissions gate traversal and unlink, which is where exam scenarios live.
What to do instead
Practice ACL workflows: setfacl -m u:alice:rwx, setfacl -d -m g:devs:rx, then verify with getfacl and ls -l (the + marker). Test the effect of the mask by narrowing it with setfacl -m m::r and observing effective rights. Reproduce the world-writable-directory deletion scenario with and without the sticky bit.
Writing SELinux policy or troubleshooting AVC denials by running `setenforce 0` or `semanage permissive -a` and leaving the host permissive, rather than reading `ausearch -m avc -ts recent` and applying the correct boolean or file context.
SELinux is intimidating and the fastest apparent fix is to disable enforcement. The exam tests whether the candidate can diagnose a denial and remediate it with targeted policy, booleans, or restorecon, not whether they can turn it off.
What to do instead
Adopt a fixed diagnostic order: ausearch -m avc -ts recent, sealert -a /var/log/audit/audit.log, check getsebool -a for a relevant boolean, check semanage fcontext -l and matchpathcon for context mismatches, then restorecon -Rv. Only after that consider audit2allow -M and load a local module. Practice relabeling with touch /.autorelabel and rebooting.
Configuring firewalld or nftables rules that allow traffic broadly (for example `--add-service=ssh` on the public zone plus a permissive `--add-port` range) and assuming the rule set is least-privilege because it 'works', without verifying rule order, zone assignment, or default target.
Candidates test connectivity, see success, and stop. The exam asks about default policies, zone binding to interfaces, rich rules, and the interaction between firewalld's runtime and permanent configuration, so a working-but-broad rule set fails the reasoning test.
What to do instead
For every rule set, write down the default target for each zone and chain, then verify with firewall-cmd --list-all-zones, nft list ruleset, and iptables -S. Practice rich rules (firewall-cmd --add-rich-rule='rule family=ipv4 source address=10.0.0.0/8 service name=ssh accept') and confirm persistence with --permanent followed by --reload. Test with nft counters or conntrack to prove default-deny behavior.
Setting up OpenSSH hardening by editing `sshd_config` but forgetting that `Match` blocks override earlier global directives, that `AllowUsers`/`DenyUsers` and `PermitRootLogin prohibit-password` interact, and that `sshd -t` must pass before reload; then locking themselves out during an exam lab.
SSH is used daily but rarely read carefully. Directive precedence and the Match block semantics are common exam targets, and candidates who skip validation either break the service or misjudge the effective configuration.
What to do instead
Always validate with sshd -t and inspect the effective config with sshd -T. Learn the precedence order (first obtained value wins for most keywords) and test Match User/Match Address blocks explicitly. Keep a second session open while testing, and practice PermitRootLogin prohibit-password, PasswordAuthentication no, and AllowGroups together with sshd -T output.
Treating vulnerability assessment as a single `nmap` scan or a single `lynis` run and reporting the raw output as findings, without correlating package versions to CVEs, checking the distro's security tracker, or distinguishing a false positive from an exploitable issue.
Candidates conflate scanning with assessment. The exam expects candidates to interpret results, prioritize by exploitability and exposure, and know that banner-based version detection is unreliable, especially with backported patches in distribution packages.
What to do instead
Practice the full loop: enumerate with nmap -sV and authenticated package inventory, map versions to the distribution's security advisories (for example the Debian or Red Hat security tracker) rather than the upstream version string alone, verify with rpm -q --changelog or apt changelog, and rank findings by reachability and privilege required. Learn to explain why a backported fix makes a version string look vulnerable when it is not.
Building auditd rules that log everything (`-a always,exit -F arch=b64 -S all`) and then ignoring the resulting noise, instead of writing targeted rules on specific syscalls, paths, and identities with correct key fields and verifying that events are actually captured.
Candidates know auditd exists but not how rule ordering and the -F field syntax work, so they either over-log or write rules that never match. The exam tests whether the candidate can produce evidence for a specific security question.
What to do instead
Write rules for concrete questions: -w /etc/passwd -p wa -k identity, -a always,exit -F arch=b64 -S execve -F auid>=1000 -F auid!=unset -k exec. Load with augenrules --load, verify with auditctl -l, and confirm capture with ausearch -k identity -i and aureport. Practice the immutability flag -e 2 and know that it requires a reboot to reverse.
Setting up centralized logging or integrity monitoring (rsyslog, journald, AIDE) without protecting the log transport or the baseline database, so an attacker with root can rewrite the evidence, and never scheduling baseline re-creation after legitimate changes.
Candidates implement the tool but not the trust model. The exam probes whether the candidate understands that logs and integrity databases must be protected, forwarded off-host, and re-baselined deliberately, or they provide no evidentiary value.
What to do instead
Forward logs to a remote collector over TLS (rsyslog with omfwd and StreamDriver.Mode=1), configure journald with ForwardToSyslog and persistent storage, and store the AIDE database off-host or sign it. Practice aide --init, aide --check, and a documented re-baseline procedure after package updates, and be able to explain the difference between detection and prevention.