Manage security practice questions

The /etc/nologin file exists.

Why it fails: The mere existence of /etc/nologin blocks local console and terminal logins by displaying its contents to non-root users, but sshd does not consult this file. SSH access is governed by the SSH daemon's own configuration and PAM stack; unless pam_nologin is explicitly enabled for the sshd service, the file has no effect on incoming SSH connections. Therefore, /etc/nologin is irrelevant to whether a user can SSH.

The user has sudo privileges.

Why it fails: Having sudo privileges grants the user the ability to execute commands as another user (typically root) after logging in, but it is not an authentication mechanism for SSH. The SSH server validates credentials against account passwords or SSH keys; sudoers membership is never queried during the SSH handshake. Consequently, a user with sudo can still be unable to SSH if their account is locked or their shell is invalid, and an average user without sudo can SSH normally provided other conditions hold.

chcon -u system_u /home/user/www/index.html

Why it fails: Changing the SELinux user (the -u parameter) to system_u on index.html does not affect the type attribute, which is what httpd_t (the Apache domain) actually checks for read access. Even with system_u as the user, the file still retains a type like user_home_t that is not in the allowed set for httpd_t, so denial persists. Furthermore, chcon makes a transient change that does not survive a filesystem relabel, unlike a proper semanage fcontext rule.

semanage fcontext -a -t httpd_sys_content_t '/home/user/www(/.*)?' && restorecon -Rv /home/user/www

Why it fails: This is the correct approach because semanage fcontext establishes a persistent, regex-based rule that maps /home/user/www and all files below it to the httpd_sys_content_t type, and restorecon -Rv applies that type immediately. Once the type is httpd_sys_content_t, the httpd_t domain has explicit read permissions via SELinux policy, allowing Apache to serve the page. The rule survives future relabels, making it a durable fix, and the regex (/.*)? ensures all nested content, not just the current index.html, is correctly labeled.

chcon -r object_r /home/user/www/index.html

Why it fails: The lowercase -r in chcon is for setting the SELinux role, not for recursion (that would be -R). Changing the role to object_r has no effect on Apache's ability to read the file because SELinux type enforcement, not role, governs whether httpd_t can access a file. Additionally, chcon is a manual change that is not persisted in the file context policy; if the filesystem is relabeled, the original type returns, leaving the problem unresolved.

alice localhost=(ALL) ALL

Why it fails: This line uses localhost as the Host_List, but sudo compares that list against the system's canonical hostname; on a typical machine the value is not literally localhost, so the rule will not apply. Additionally, (ALL) as the runas specification allows executing commands as any target user, not just root, making the entry both syntactically unreliable and overly broad.

alice ALL=(ALL) ALL

Why it fails: Incorrect. While 'alice ALL=(ALL) ALL' is a valid entry for full sudo privileges, it allows running commands as any user, not just root. The question specifically requires running commands as root, making this less precise.

%alice ALL=(ALL) ALL

Why it fails: This line is wrong for two distinct reasons. The leading percent sign makes alice a group name, not a user; sudoers requires a bare username for user entries. Even if the group alice exists, (ALL) in the runas position grants the group the ability to run commands as any user, which exceeds the required root-only scope.

SELinux is blocking SSH from reading the key.

Why it fails: SELinux in its default targeted policy allows the sshd process to read a user's ~/.ssh/authorized_keys file, provided the context is the standard `user_home_t`/`ssh_home_t` type; a context problem would produce AVC denials and typically break more than key auth. Because password authentication succeeds, sshd can already access the home directory and run normally, and key authentication-specific failure points are file/directory permissions rather than SELinux. Reset the context with `restorecon -R -v ~/.ssh` only if audit logs confirm denials, otherwise it is a red herring.

The public key is not in ~/.ssh/authorized_keys.

Why it fails: If the public key truly were absent from authorized_keys, sshd would fail with a generic 'Permission denied (publickey)' without even evaluating key-based login, but in this scenario password auth works and the key was likely added by the user. The actual reason is that sshd's StrictModes checks the permissions of ~/.ssh and authorized_keys before trusting them, and a 755 directory causes sshd to refuse to use any key files inside it, regardless of whether the key exists. Verifying the key is present may look fine, yet authentication still fails because the overly permissive directory short-circuits the login.

SSH is configured to use a different port.

Why it fails: Changing the port that sshd listens on—whether in /etc/ssh/sshd_config (Port directive) or per-connection with `-p`—only affects the network socket and has no effect on the server's authentication logic. Public-key authentication is handled by the same sshd process and the same authorized_keys lookup regardless of which port the client connects to. If a non-standard port were the cause, the client would receive a connection refused/timeout rather than an authentication failure, so this option cannot explain a key-authentication problem.

The service http is not defined for port 8080.

Why it fails: The built-in http service is definitely present in firewalld and included in the zone's services list; it simply maps to port 80/tcp only. Saying it is 'not defined' mischaracterizes the problem—the service exists but has no entry for 8080/tcp. The failure is that traffic on 8080 is not allowed because the rich rule references the http service, not because the service definition is missing or invalid.

The zone is internal and has a default target of drop.

Why it fails: The internal zone's configuration lists target: default, not target: drop; a drop target would be shown explicitly in the zone's XML or --list-all output. With the default target, packets that reach the end of the zone's rules are accepted rather than silently discarded. So this reason is false because the wrong target was cited, and the actual cause lies in the narrow rich rule, not in a global drop policy.

The interface eth1 is not added to the zone.

Why it fails: The exhibit's zone configuration explicitly includes 'interfaces: eth1', so eth1 is already bound to the internal zone and all network traffic arriving on it is evaluated against that zone's rules. If eth1 were absent, the source 192.168.1.0/24 would not be associated with the zone and the rich rule would not apply, but that premise is contradicted by the listed interface. Hence this statement is wrong, and you should focus on the service/port mismatch instead.

sshd.* /var/log/ssh_failures

Why it fails: sshd.* is not a valid rsyslog selector because sshd is a daemon process, not a syslog facility. Syslog facilities are fixed categories such as auth, authpriv, daemon, and local0 through local7; an unknown facility name like sshd causes rsyslog to report a selector error and ignore the rule. No failed SSH attempts would ever be written to /var/log/ssh_failures because the invalid selector never matches any syslog message.

authpriv.* /var/log/ssh_failures

Why it fails: authpriv.* matches every message that the authpriv facility emits, regardless of priority, including successful logins, sudo usage, and account management events. sshd's successful authentication messages and informational notices are also included, so this selector produces a broad log rather than the focused 'failed SSH login attempts' audit trail. Although the rule is syntactically valid and would capture failures, it fails the auditor's requirement because it also records non-failure data into the same file.

auth.* /var/log/ssh_failures

Why it fails: The auth.* selector captures messages from the auth facility, but sshd on RHEL writes its authentication events to the authpriv facility, not auth. Therefore this rule never receives SSH login failure messages and would leave /var/log/ssh_failures empty or containing only unrelated legacy PAM messages. Using auth.* misunderstands the difference between the auth and authpriv facilities, so it cannot meet the auditor's SSHand-specific logging requirement.

Using the passwd command with --stdin

Why it fails: The `passwd --stdin` command simply reads the new password from standard input and changes it; it does not contain any built-in logic for evaluating password strength or enforcing complexity requirements. Whether a password is rejected for being too short or too simple depends entirely on the PAM configuration (e.g., if pam_pwquality or pam_cracklib are stacked), not on the `passwd` command itself. Moreover, `--stdin` is non-standard on many distributions (commonly a Red Hat extension), and even where available it does not add or guarantee complexity enforcement on its own.

Using the chage command

Why it fails: The `chage` command is used exclusively for managing password aging and expiry data—such as the minimum number of days between changes, maximum age, and password expiration warning—stored in /etc/shadow. It has no mechanism to inspect or restrict the actual characters, length, or complexity of a chosen password. Complexity checks must be performed at password-change time by PAM modules, so `chage` is entirely unrelated to enforcing password quality.

Editing the /etc/shadow file manually

Why it fails: Editing /etc/shadow manually (e.g., pasting a pre-generated hash) only updates the stored credential record; it completely bypasses the PAM authentication stack, which is where all password-quality checks are invoked. There is no code path in /etc/shadow editing that evaluates the strength of the chosen plaintext password, so no complexity rules are ever consulted. An administrator who does this is effectively circumventing account policy and can inadvertently introduce weak or non-compliant credentials.

The dmz zone should be assigned to the internal interface

Why it fails: The dmz zone is a security level for servers exposed to less-trusted traffic; the internal interface connects the trusted LAN. Assigning the dmz zone to the internal interface would place both interfaces into the same zone, so firewalld treats their traffic as intra-zone and allows it by default, bypassing any inter-zone forwarding rules. That collapses the security boundary between the internal network and the DMZ, defeating the DMZ's purpose. The correct setup keeps separate zones on each interface so the firewall can enforce a stateful policy between them.

The internal zone has masquerade enabled, which is incorrect for a router

Why it fails: Enabling masquerade on the internal zone is not inherently wrong; it is a source NAT operation that changes the source address of packets leaving that zone. It does not stop the router from forwarding — in fact, NAT relies on forwarding — so it cannot be the sole reason the traffic is being dropped. It is also unnecessary for a router connecting two directly connected networks, because no address translation is required for routing between them. If anything, masquerade can hide the real source address and complicate the DMZ's logging or access rules, but the missing forwarding rule is the actual cause of the failure.

The dmz zone does not have masquerade enabled

Why it fails: Masquerade is only required when you want the DMZ to think all traffic originates from the router's IP, typically when the DMZ lacks a route back to the internal network. In this scenario the DMZ and internal networks are directly connected to the router, so the router can forward packets without any source NAT — the DMZ just needs a return route. Not enabling masquerade leaves the original source IP intact, which is the correct behavior for a router. Therefore the absence of masquerade does not block traffic; it is a red herring, and the real issue remains the missing forward allow from internal to dmz.

iptables -L

Why it fails: Incorrect. `iptables -L` shows the current netfilter rules in the kernel, but firewalld uses a zone-based abstraction; these rules may not directly correspond to firewalld's zone rules.

systemctl status firewalld

Why it fails: Incorrect. `systemctl status firewalld` shows whether the firewalld service is running, not the firewall rules.

firewall-cmd --get-default-zone

Why it fails: Incorrect. `firewall-cmd --get-default-zone` only returns the name of the default zone, not the rules.

firewall-cmd --list-all

Why it fails: Incorrect. `firewall-cmd --list-all` shows the rules for the default zone only, not all zones, so it does not meet the requirement.

Run restorecon -R /var/log/myapp/ to restore the default SELinux context.

Why it fails: restorecon -R /var/log/myapp/ resets the directory's SELinux label to the default file context defined in the policy, which is var_log_t for paths under /var/log. The denial occurs because httpd_t lacks write permission to var_log_t, not because the label is incorrect. Resetting to the same type therefore does not grant httpd any new access and leaves the AVC denial unresolved.

Set the SELinux boolean httpd_unified on to allow httpd_t to write to all types.

Why it fails: Enabling httpd_unified is a coarse boolean that broadly expands httpd's access across many httpd-related file types, reducing SELinux's least-privilege enforcement. It does not specifically allow writing to var_log_t, nor would it establish per-directory control for /var/log/myapp. In practice this would weaken security for the whole service when the requirement is a narrowly scoped write rule.

Change the context of the /var/log/myapp/ directory to var_log_t using chcon.

Why it fails: chcon changes the SELinux context of the directory, but /var/log/myapp already has var_log_t; assigning the same type produces no functional change. chcon also makes a non-persistent, temporary label that can be overwritten by restorecon on the next relabel. The real problem is the absence of an allow rule for httpd_t to write to var_log_t, which chcon cannot create.

semanage permissive -a httpd_t

Why it fails: Adding httpd_t to the permissive domains list stops the kernel from enforcing policy for the web server, so the 403 would disappear, but only by effectively switching SELinux off for that process. Every other protection the policy provides to httpd is also lost, and the audit log floods with would-be denials. This is a diagnostic technique, not a supported remediation for a mislabeled content directory.

setsebool -P httpd_read_user_content on

Why it fails: This boolean governs whether httpd may read files labeled user_home_t under users' home directories. The file here lives in /srv/reports and is labeled default_t, not user_home_t, so toggling the boolean does nothing for this denial. It also broadens the web server's access to user home content, which is unnecessary exposure for a report directory that simply needs a correct type label.

chcon -t httpd_sys_content_t /srv/reports/quarterly.xlsx

Why it fails: chcon changes the context immediately and would make the file readable by httpd, so the 403 disappears right away. However, the change is written directly to the inode and is not recorded in the SELinux policy, so any subsequent relabel triggered by restorecon, a package update, or touch /.autorelabel silently reverts the type to default_t and the 403 returns. It fixes the symptom but not the durable configuration.

passwd -l apache

Why it fails: Locking the password hash with passwd -l blocks password authentication only; SSH keys and console logins via other mechanisms still succeed, so the account remains usable. It is tempting because it is the standard tool for disabling password logins, and would be correct if the requirement were solely to prevent password-based access.

chage -l apache

Why it fails: chage -l only lists an account's password aging information; it changes nothing, so SSH and console logins remain possible. It is tempting because chage -E can expire an account, which would be correct if the task were disabling logins by expiry rather than locking the account.

usermod -e 1 apache

Why it fails: Setting the account expiration date to 1 (early epoch) immediately expires the account, which does prevent login immediately. However, this is not the preferred method because it disables all logins (including non-interactive) and is not the standard way to disable interactive logins for a service account. The recommended approach is to change the shell to /sbin/nologin.

SELinux is in enforcing mode and the policy is misconfigured.

Why it fails: Running getenforce and seeing 'enforcing' only confirms SELinux is active, not that it is the cause of a denial. If SELinux policy were truly misconfigured and blocking access, switching the system into permissive mode with setenforce 0 would stop all SELinux enforcement and the application would no longer be denied. Since the problem persists in permissive mode (as implied by the correct answer), a misconfigured policy cannot be responsible, because permissive mode logs but does not deny SELinux faults.

The application's SELinux context is incorrect and needs relabeling.

Why it fails: A wrong SELinux context (type or label) would still only produce denials while SELinux is in enforcing mode. In permissive mode, SELinux does not enforce type enforcement and will allow access even if the application or target is mislabeled; it merely records an AVC denial in the audit log. Therefore, an incorrect context cannot explain a failure that survives setenforce 0, and relabeling would not remove a denial caused by ordinary file permissions or ACLs.

The change requires a reboot to take effect.

Why it fails: setenforce 0 is an immediate runtime switch; it changes the current SELinux mode without requiring a reboot, so no reboot is needed for the test. A reboot would only be necessary to load a new SELinux state after editing /etc/selinux/config, or to re-enable SELinux after a 'disabled' mode, but that has nothing to do with a denial that persists in permissive mode. Since permissive mode already takes effect instantly, any remaining failure cannot be attributed to a pending reboot.

jdoe client1.example.com=(root) ALL

Why it fails: This rule is incorrectly missing the NOPASSWD tag. While the host and runas restrictions are exactly as required, without NOPASSWD sudo will invoke a password prompt, and jdoe would have to authenticate before the command runs. That conflicts with the stated requirement that the command be executed without prompting for a password.

jdoe ALL=(root) NOPASSWD: ALL

Why it fails: This rule sets the host list to ALL instead of client1.example.com. As a result, jdoe could use this sudo privilege from any managed host, which over-expands the intended scope and violates the requirement to restrict the rule to client1. Having NOPASSWD does not compensate for the incorrect host wildcard.

jdoe ALL=(root) ALL

Why it fails: This rule has two separate failures: the host list is ALL, making the privilege available from every host, and the NOPASSWD tag is absent, so a password prompt will occur. Neither component matches the requirement of a passwordless rule limited only to client1.example.com for user jdoe.

The rule must be added as a rich rule, not a simple service.

Why it fails: Adding HTTPS as a service is valid; firewalld ships predefined services including https, so a rich rule is unnecessary and would not resolve the connectivity failure. It is tempting because rich rules do allow granular source and port control, and would be correct when permitting non-standard ports or specific source addresses.

The default zone is not set to public.

Why it fails: The rule was explicitly added to the public zone, so the default zone assignment does not affect whether that rule applies to the interface. It is tempting because a mismatched default zone genuinely blocks traffic when rules are added without specifying a zone; here the zone was named, so this is not the cause.

firewalld is just a wrapper for iptables, so iptables rules must be cleared.

Why it fails: firewalld manages its own nftables or iptables rules directly; flushing iptables would remove firewalld's rules and break filtering rather than restore HTTPS access. It is tempting because firewalld does sit atop the packet-filtering layer, and manual iptables edits can conflict, but the actual cause is that the runtime configuration was not reloaded.

chcon -l

Why it fails: The `chcon -l` option is incorrect because `chcon` is used to *change* the SELinux context of a file, not to display it. Even though `-l` allows specifying a context label, the command does not print the current or resulting context; it modifies the inode's security attributes.

id -Z

Why it fails: The `id -Z` option is incorrect because it prints the SELinux security context of the *current process* (or the user's initial context), not the contexts of arbitrary files. It answers "what context am I running in?" rather than "what is this file's context?".

getenforce

Why it fails: The `getenforce` option is incorrect because it only reports the *global* SELinux enforcing mode (Enforcing, Permissive, or Disabled), not the security context of any particular file. It is a system-status query, not a per-object context display.

Add 'alice web1.example.com=(root) NOPASSWD: ALL' to /etc/sudoers.d/alice.

Why it fails: The rule grants alice passwordless sudo rights to execute any command as root on the host web1.example.com. While NOPASSWD removes the password prompt, the command specification ALL is far broader than the single restart needed. This violates least privilege: alice could run useradd, visudo, or other administrative commands.

Add 'alice web1.example.com=(root) /usr/bin/systemctl restart httpd' to /etc/sudoers.d/alice.

Why it fails: This rule limits alice to the appropriate systemctl restart httpd command, but without the NOPASSWD tag she will be prompted for her password. If the goal is passwordless restart—as implied by the requirement—the absence of NOPASSWD makes the rule functionally insufficient. Also note that sudo will still require a valid password and tty, potentially blocking automation.

Change '%wheel ALL=(ALL) ALL' to '%wheel ALL=(ALL) NOPASSWD: ALL' in /etc/sudoers.

Why it fails: Modifying the wheel group line affects every user in the wheel group, not just alice, and grants them all passwordless root access. This is a system-wide change that drastically increases the attack surface and violates the principle of least privilege. The original line already grants full root; adding NOPASSWD only removes the password check without addressing command scoping.

firewall-cmd --runtime-to-permanent

Why it fails: The firewall-cmd --runtime-to-permanent command persists the current runtime configuration to the permanent configuration files, but it does not itself add any services or rules. If the required HTTPS allow or SSH drop rules were never added to the runtime configuration, this command simply saves an incomplete firewall state. Therefore, it fails to fulfill the requirement to add the necessary firewall rules; it only copies whatever rules are already active.

firewall-cmd --add-rich-rule='rule family=ipv4 source address=192.168.1.100 service name=ssh reject' --permanent

Why it fails: Using the reject action in a rich rule causes firewalld to send an ICMP unreachable packet or TCP RST back to 192.168.1.100, explicitly indicating the port is closed. This differs from the desired silent drop, which discards packets without any response, making the host appear nonexistent. A reject action is also more detectable during port scans and does not meet a requirement to hide or block access without feedback.

firewall-cmd --add-service=http --permanent

Why it fails: This command adds the http service, which opens TCP port 80 for unencrypted web traffic, not port 443 for HTTPS. If the web server must accept secure connections, this rule leaves HTTPS blocked and would cause the initial secure connection attempt to fail. Because the requirement specifically calls for HTTPS, adding http is the wrong service even though the syntax and persistence behavior are valid.

Set the SELinux boolean httpd_enable_homedirs to on using setsebool.

Why it fails: The boolean httpd_enable_homedirs is specifically designed to control whether Apache can access user home directories (e.g., public_html via mod_userdir). It has no bearing on the labeling or access rights for a custom directory under /var/www. Even if enabled, it would not grant httpd write access to /var/www/customcontent; that requires a proper file context with an httpd_writable type. Thus, toggling this boolean is irrelevant to the stated requirement.

Change the context to httpd_sys_content_t using chcon -R -t httpd_sys_content_t /var/www/customcontent

Why it fails: chcon changes the SELinux context immediately, but the change is temporary and will be reverted by any subsequent restorecon or filesystem relabel. Additionally, httpd_sys_content_t is read-only for the web server; it permits Apache to read and serve static content but not to write or modify files. Since the requirement is to allow httpd to write, using this type would deny write operations. A persistent semanage fcontext rule with httpd_sys_rw_content_t is needed.

Run semanage fcontext -a -t httpd_sys_rw_content_t '/var/www/customcontent(/.*)?' without running restorecon.

Why it fails: semanage fcontext only adds a rule to the SELinux policy database that defines the default context for a path; it does not modify the current context of any existing files. Without running restorecon, the actual files in /var/www/customcontent retain their original context (likely default_t or unlabeled), which Apache cannot access or write to. The rule only takes effect when restorecon is executed or when new files are created in the directory. Therefore, omitting restorecon leaves the directory incorrectly labeled, so this option is incomplete.

1. Reload firewall: firewall-cmd --reload 2. Add HTTP service: firewall-cmd --permanent --add-service=http 3. Add HTTPS service: firewall-cmd --permanent --add-service=https 4. Verify: firewall-cmd --list-services

Why it fails: Executing --reload before adding the services is ineffective because the reload only reads the current permanent configuration, which at that point contains no http or https rules. The two --permanent --add-service commands then update the on-disk configuration, but because no second reload is performed, the runtime firewall never receives those changes. Consequently, --list-services at the end would not display http or https, leaving web access blocked.

1. Add HTTP service: firewall-cmd --add-service=http (without --permanent) 2. Add HTTPS service: firewall-cmd --add-service=https (without --permanent) 3. Reload firewall: firewall-cmd --reload 4. Verify: firewall-cmd --list-services

Why it fails: Omitting --permanent applies the services only to the live runtime set, not to the persistent configuration files. When --reload is then executed, firewalld rebuilds the runtime rules from the permanent configuration on disk, discarding all runtime-only additions. As a result, these http and https rules survive only until the reload, so they would be lost immediately, and verification after the reload would show neither service.

1. Add HTTP service: firewall-cmd --permanent --add-service=http 2. Reload firewall: firewall-cmd --reload 3. Add HTTPS service: firewall-cmd --permanent --add-service=https 4. Verify: firewall-cmd --list-services

Why it fails: This sequence adds HTTP permanently, reloads to activate it, and only then adds HTTPS permanently without a subsequent reload. Although HTTPS is now stored in the persistent configuration, the running firewall has not been refreshed after that second permanent change, so the HTTPS rule is not present in the current runtime. The final --list-services would show http but not https, leaving the webserver incomplete and inaccessible via HTTPS until another reload is performed.