LFCS 167 🐧 LFCS Practice Scenarios — Security - KandZ

⏱️ Estimated read: 10 min | |

The previous chapters covered the storage, the networking, and the services practice scenarios. This chapter covers the security practice: the scenarios that simulate the exam tasks in the security domain. The LFCS security domain is weighted at 15% of the total score, and the objectives cover the SSH hardening, the sudo restrictions, the SELinux enforcement, the firewall rules, and the audit framework. The critical trap is the lockout. The sshd_config change that disables the password without the working key locks out the admin. The sudoers edit without the visudo breaks the sudo. The firewall-cmd rule that drops the SSH without the allow rule locks out the remote access. The SELinux change to the enforcing mode without the correct contexts prevents the services from starting. The scenarios test the safe sequence: the test, the change, the verify, the recovery.

Key point: The security scenarios are the most dangerous: the wrong change locks out the administrator and the services. The sequence is the key: the test the access, the apply the change, the verify the state, the keep the recovery path. The scenarios cover the SSH hardening, the sudo restrictions, the SELinux contexts and the booleans, the firewall rules, and the audit rules.

Why the security practice requires a specific mental model

The lockout problem. The security changes restrict the access. The restriction is the point, but the restriction also restricts the administrator. The PasswordAuthentication no locks out the user without the key. The PermitRootLogin no locks out the root. The iptables -A INPUT -j DROP without the allow rule locks out the SSH. The practice must include the second session that verifies the change before the original session is closed.

The visudo problem. The /etc/sudoers is the critical file. The syntax error locks out the sudo. The visudo validates the syntax and prevents the save if the syntax is broken. The drop-in files in the /etc/sudoers.d/ are the alternative. The wrong permissions on the drop-in (the not 440) cause the sudo to ignore the file, which is the silent failure.

The SELinux problem. The setenforce 0 is the runtime. The /etc/selinux/config is the persistent. The chcon is the temporary. The semanage fcontext and the restorecon are the persistent. The setsebool -P is the persistent boolean. The audit2allow is the last resort. The sequence matters: the context, the boolean, the port, and then the policy.

The audit problem. The auditctl -w is the runtime. The /etc/audit/rules.d/ and the augenrules --load are the persistent. The ausearch -k is the search. The aureport is the summary. The rule that is not in the drop-in directory is lost on the reboot.

The trade-off. The security scenarios are the most dangerous because the changes are the restrictive. The practice must be on the VM with the console access, not on the remote host. The recovery path (the console, the rescue mode, the serial) must be known before the restrictive change.

a. The SSH hardening

The scenario: the disable the password auth, the disable the root login, the change the port, the open the new port in the firewall and the SELinux, and the verify the access.

# Test the key auth first
ssh-copy-id user@server
ssh -o PubkeyAuthentication=yes -o PasswordAuthentication=no user@server

# Edit the drop-in config
sudo tee /etc/ssh/sshd_config.d/99-hardening.conf <<'EOF'
PasswordAuthentication no
PermitRootLogin no
Port 2222
EOF

# Validate
sudo sshd -t

# SELinux: allow the new port
sudo semanage port -a -t ssh_port_t -p tcp 2222

# Firewall: allow the new port
sudo firewall-cmd --permanent --add-port=2222/tcp
sudo firewall-cmd --permanent --remove-service=ssh
sudo firewall-cmd --reload

# Apply the SSH change
sudo systemctl reload sshd

# Verify in a NEW session
ssh -p 2222 user@server

The key auth is tested before the password disable. The sshd -t validates the config. The semanage port allows the new port in the SELinux. The firewall-cmd allows the new port in the firewall. The systemctl reload applies. The new session tests the change before the original session is closed.

The recovery if the config is broken.

# If the SSH is broken, the console is the recovery
# Edit the config from the console
sudo nano /etc/ssh/sshd_config.d/99-hardening.conf
# Or remove the file
sudo rm /etc/ssh/sshd_config.d/99-hardening.conf
sudo sshd -t
sudo systemctl reload sshd

The console is the recovery. The config file is removed or fixed. The sshd -t validates. The reload applies.

b. The sudo restrictions and the SSH keys

The scenario: the restrict the user alice to the specific commands, the disable the password for the systemctl restart, and the verify the restrictions.

# Create the drop-in
sudo tee /etc/sudoers.d/alice <<'EOF'
alice ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart nginx, /usr/bin/systemctl status nginx
alice ALL=(ALL) /usr/bin/apt update
EOF

# Fix the permissions
sudo chmod 440 /etc/sudoers.d/alice

# Validate the sudoers
sudo visudo -c

# Verify the restrictions
sudo -l -U alice

The NOPASSWD skips the password for the specific commands. The second line allows the apt update with the password. The chmod 440 is the required. The visudo -c validates the syntax. The sudo -l -U alice shows the effective rules.

The SSH key deployment.

# Generate the key (client)
ssh-keygen -t ed25519 -C "alice@laptop"

# Deploy to the server
ssh-copy-id alice@server

# Verify the key auth
ssh -i ~/.ssh/id_ed25519 alice@server whoami

The ssh-keygen generates the key. The ssh-copy-id deploys the public key. The ssh -i tests the key auth.

c. The SELinux and the audit

The scenario: the configure the SELinux to allow the web server to read the custom directory, the enable the boolean, and the add the audit rule.

# Check the SELinux state
getenforce

# Add the context rule
sudo semanage fcontext -a -t httpd_sys_content_t "/srv/web(/.*)?"
sudo restorecon -Rv /srv/web

# Enable the boolean
sudo setsebool -P httpd_can_network_connect on

# Verify
ls -Z /srv/web
getsebool httpd_can_network_connect

# Audit rule (runtime)
sudo auditctl -w /etc/passwd -p wa -k identity

# Audit rule (persistent)
sudo tee /etc/audit/rules.d/30-identity.rules <<'EOF'
-w /etc/passwd -p wa -k identity
-w /etc/shadow -p rwa -k identity
EOF

sudo augenrules --load

# Verify
sudo auditctl -l
sudo ausearch -k identity -ts today

The semanage fcontext adds the rule to the database. The restorecon applies. The setsebool -P persists the boolean. The auditctl -w is the runtime. The /etc/audit/rules.d/ is the persistent. The augenrules --load applies. The ausearch searches.

The SELinux denial diagnosis.

# If the web server cannot read the files
sudo ausearch -m avc -ts recent
sudo sealert -a /var/log/audit/audit.log
# Fix the context, not disable the SELinux

The ausearch -m avc finds the denial. The sealert explains. The fix is the context, not the setenforce 0.

Complete Example Session

# ============================================
# PART 1: SSH KEY
# ============================================

ssh-keygen -t ed25519
ssh-copy-id alice@server
ssh -o PasswordAuthentication=no alice@server

# ============================================
# PART 2: SSH HARDENING
# ============================================

sudo tee /etc/ssh/sshd_config.d/99-hardening.conf <<'EOF'
PasswordAuthentication no
PermitRootLogin no
Port 2222
EOF
sudo sshd -t

# ============================================
# PART 3: FIREWALL AND SELINUX
# ============================================

sudo semanage port -a -t ssh_port_t -p tcp 2222
sudo firewall-cmd --permanent --add-port=2222/tcp
sudo firewall-cmd --permanent --remove-service=ssh
sudo firewall-cmd --reload

# ============================================
# PART 4: APPLY
# ============================================

sudo systemctl reload sshd
ssh -p 2222 alice@server

# ============================================
# PART 5: SUDO DROP-IN
# ============================================

sudo tee /etc/sudoers.d/alice <<'EOF'
alice ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart nginx
EOF
sudo chmod 440 /etc/sudoers.d/alice
sudo visudo -c

# ============================================
# PART 6: VERIFY SUDO
# ============================================

sudo -l -U alice

# ============================================
# PART 7: SELINUX CONTEXT
# ============================================

sudo semanage fcontext -a -t httpd_sys_content_t "/srv/web(/.*)?"
sudo restorecon -Rv /srv/web
ls -Z /srv/web

# ============================================
# PART 8: SELINUX BOOLEAN
# ============================================

sudo setsebool -P httpd_can_network_connect on
getsebool httpd_can_network_connect

# ============================================
# PART 9: AUDIT
# ============================================

sudo tee /etc/audit/rules.d/30-identity.rules <<'EOF'
-w /etc/passwd -p wa -k identity
EOF
sudo augenrules --load
sudo auditctl -l

The nine parts trace the security scenarios: the SSH key, the hardening, the firewall and SELinux, the apply, the sudo, the verify, the SELinux context, the boolean, and the audit.

Quick Reference

SSH Hardening

Setting	Purpose
`PasswordAuthentication no`	Disable the password
`PermitRootLogin no`	Block the root
`Port 2222`	Change the port
`sshd -t`	Validate
`systemctl reload sshd`	Apply

Sudo

Command	Purpose
`/etc/sudoers.d/`	Drop-in
`chmod 440`	Permissions
`visudo -c`	Validate
`sudo -l -U`	Check

SELinux

Command	Purpose
`semanage fcontext -a`	Context rule
`restorecon -Rv`	Apply
`setsebool -P`	Persistent boolean
`ausearch -m avc`	Find denial

Audit

Command	Purpose
`auditctl -w`	Runtime rule
`/etc/audit/rules.d/`	Persistent
`augenrules --load`	Apply
`ausearch -k`	Search

Best Practices

✅ Do This:

ssh -o PasswordAuthentication=no user@server
<!-- Test the key before the password disable -->     # ✅

sudo sshd -t && sudo systemctl reload sshd
<!-- Validate before the apply -->                   # ✅

sudo semanage fcontext -a -t httpd_sys_content_t "/srv/web(/.*)?"
<!-- Fix the context, not the SELinux mode -->       # ✅

❌ Don’t Do This:

# Disable the password before the key test
<!-- Locks out the admin -->                         # ❌

sudo nano /etc/sudoers
<!-- Syntax error breaks the sudo -->                # ❌

sudo setenforce 0
<!-- Disables the enforcement -->                    # ❌

Common Pitfalls

Pitfall	Why It Happens	Fix
SSH locked out	Password disabled before the key	Test the key first
Sudo broken	Edited without `visudo`	Use `visudo`
SELinux denial	Wrong context	`semanage` + `restorecon`
Audit lost on reboot	No drop-in file	Use `/etc/audit/rules.d/`
Firewall blocks SSH	No allow rule	Add before the drop

Real-World Examples

1. Test Key

ssh -o PasswordAuthentication=no user@server

2. SSH Config

echo "PasswordAuthentication no" >> /etc/ssh/sshd_config.d/99.conf

3. Validate SSH

sshd -t

4. Sudo Drop-in

echo "alice ALL=(ALL) NOPASSWD: /usr/bin/systemctl" > /etc/sudoers.d/alice

5. Sudo Permissions

chmod 440 /etc/sudoers.d/alice

6. SELinux Context

semanage fcontext -a -t httpd_sys_content_t "/srv/web(/.*)?"

7. Restorecon

restorecon -Rv /srv/web

8. Boolean

setsebool -P httpd_can_network_connect on

9. Audit Rule

echo "-w /etc/passwd -p wa -k identity" > /etc/audit/rules.d/30-identity.rules

10. Apply Audit

augenrules --load

Visual

Lockout Recovery

┌──────────────────────────────────────────────┐
│  SSH config change                           │
└──────────────────┬───────────────────────────┘
                   │
        ┌──────────┴──────────┐
        │                     │
        ▼                     ▼
┌───────────────┐     ┌───────────────┐
│  Working      │     │  Broken       │
│  → new session│     │  → no access  │
└───────────────┘     └───────┬───────┘
                              │
                              ▼
                      ┌───────────────┐
                      │  Console      │
                      │  → fix config │
                      └───────────────┘

SELinux Fix Order

┌──────────────────────────────────────────────┐
│  1. Context (semanage + restorecon)          │
└──────────────────┬───────────────────────────┘
                   │
                   ▼
┌──────────────────────────────────────────────┐
│  2. Boolean (setsebool -P)                   │
└──────────────────┬───────────────────────────┘
                   │
                   ▼
┌──────────────────────────────────────────────┐
│  3. Port (semanage port -a)                  │
└──────────────────┬───────────────────────────┘
                   │
                   ▼
┌──────────────────────────────────────────────┐
│  4. Custom policy (audit2allow, last resort) │
└──────────────────────────────────────────────┘

Summary

Item	Value
SSH test	`ssh -o PasswordAuthentication=no`
SSH validate	`sshd -t`
Sudo drop-in	`/etc/sudoers.d/`
Sudo permissions	`440`
Sudo validate	`visudo -c`
SELinux context	`semanage fcontext` + `restorecon`
SELinux boolean	`setsebool -P`
Audit persistent	`/etc/audit/rules.d/`
Audit apply	`augenrules --load`

Key takeaways:

The test before the change. The key auth tested before the password disable. The sshd -t before the reload. The new session before the original session close. The test is the recovery path.
The visudo is the only safe edit. The /etc/sudoers direct edit locks out the sudo. The drop-in files must have the 440 permissions. The visudo -c validates.
The SELinux fix is the order. The context (semanage + restorecon), the boolean (setsebool -P), the port (semanage port -a), the custom policy (audit2allow). The setenforce 0 is not the fix.
The audit persistence is the drop-in. The auditctl -w is the runtime. The /etc/audit/rules.d/ is the persistent. The augenrules --load applies.
The console is the recovery. The SSH lockout, the sudo lockout, the SELinux failure. The console is the only way to fix the remote system.

Remember: The security scenarios are the dangerous. The lockout is the trap. The test before the change. The console is the recovery. The sshd -t, the visudo -c, the semanage + restorecon, the augenrules --load. The exam tests the safe sequence.

Was this helpful?

Stop using slow, ad-bloated tool sites! 🤮

🔎 Search “KandZ Tools” on Google to use many professional utilities for free.

KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)

⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free

🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!