Linux Security and Hardening practice questions

umask

Why it fails: The umask command is used to set the default file creation permissions for a user or session, but it deals with standard Discretionary Access Control bits. It has no effect on the Mandatory Access Control labels or the operational state of the SELinux subsystem itself, making it irrelevant for MAC management.

iptables

Why it fails: This utility is used for managing the Linux kernel's IPv4 packet filtering rules and NAT. While it is a security tool, it operates at the network layer rather than the host-based Mandatory Access Control layer. It cannot modify SELinux policies, file labels, or the enforcement status of the system.

sysctl

Why it fails: The sysctl command is used to modify kernel parameters at runtime, such as network stack tuning or memory management settings. While some security settings can be toggled here, it is not the primary interface for managing SELinux file labels or switching between Enforcing and Permissive operational modes.

The account is currently locked and cannot log in.

Why it fails: Account locking is typically indicated by an exclamation mark or an asterisk in the second field, which contains the hashed password. This entry shows a valid SHA-512 hash starting with '$6$', indicating the account is active and has a functional password set, rather than being administratively disabled or locked.

The user must wait 7 days between password changes.

Why it fails: The value of 7 in the sixth field represents the warning period, not the minimum password age. The minimum password age is the fourth field, which is set to 0 in this exhibit. This means the user can change their password as frequently as they wish without any mandatory waiting period.

The password expires exactly 19,000 days after creation.

Why it fails: The number 19,000 in the third field represents the date of the last password change, expressed as the number of days since the Unix Epoch. It does not indicate the expiration date itself. The expiration date is calculated by adding the maximum age (90) to this last change date.

tail -f /var/log/messages

Why it fails: While this command was standard on older Linux systems, many modern distributions no longer log authentication events to this file by default. Relying on legacy text files may cause an administrator to miss critical events that are now stored exclusively within the systemd journal, which requires specialized tools to read.

cat /etc/rsyslog.conf

Why it fails: The cat command merely displays the configuration file for the rsyslog daemon. This will show how logs are routed and where they are stored, but it does not provide any actual log data or real-time monitoring capabilities for security events occurring on the system at that moment.

grep 'fail' /var/log/auth.log

Why it fails: Using grep on a static file like auth.log provides a snapshot of past events but does not offer real-time monitoring. Additionally, if the system uses journald without a syslog forwarder, this file might not even exist or contain the most current data, leading to incomplete security analysis results.

Users can update any software without providing a password.

Why it fails: The exhibit does not include the NOPASSWD tag, meaning users will still be prompted for their own password before the command executes. Furthermore, they are restricted to only the apt-get update and upgrade commands, not 'any' software update mechanism or general administrative tasks across the entire system.

The group 'webadmins' has full root access to the entire system.

Why it fails: While the rule specifies (root) as the target user, the final part of the entry restricts the group to only two specific commands. This is an example of limited sudo delegation, which is much safer than granting 'ALL' command privileges, which would effectively give the group full control.

The rule allows webadmins to change their own passwords to root.

Why it fails: The sudoers entry shown here is strictly for the apt-get package management utility and has no relationship to password management or the /usr/bin/passwd command. Sudo rules are command-specific; they do not grant broad permissions for other administrative tools unless those tools are explicitly listed in the configuration file.

Apply chattr +i to every existing file in /var/www/html and set the default umask to 0777 so new uploads cannot contain execute permissions.

Why it fails: The immutable attribute on existing files blocks modification and deletion but does nothing for newly uploaded files, and a umask of 0777 grants full permissions rather than removing them. This combination would break normal site updates and still leave newly created files executable. It does not satisfy the requirement to prevent execution of future uploads.

Enable SELinux with the httpd_sys_content_t type on /var/www/html and enforce the targeted policy in permissive mode.

Why it fails: On Ubuntu, SELinux is not enabled by default and AppArmor is the standard MAC framework, so this is the wrong vendor-specific mechanism. Even on an SELinux system, permissive mode only logs violations without enforcing them, so it would not prevent execution. The stated goal of blocking execution of uploaded content is not achieved.

Set the SGID bit on /var/www/html so new files inherit the apache group, then rely on group permissions to deny execution.

Why it fails: SGID on a directory only forces new files to inherit the directory's group ownership; it does not prevent execution. Group permissions still permit execute if the group's execute bit is set, and the web server itself needs to execute or read PHP. This control addresses ownership inheritance, not execution prevention, so it fails the stated requirement.

Set PermitRootLogin no and PasswordAuthentication no globally, then require contractors to use keys.

Why it fails: Disabling root login and password authentication improves baseline hardening and forces key-based access, but neither directive restricts what an authenticated key holder may do over the connection. A contractor with a valid key could still request local, remote, or dynamic port forwarding if the server permits it. This does not satisfy the requirement to block forwarding channels.

Configure PermitOpen localhost:22 in the global section so all forwarding is limited to the SSH port, and instruct contractors not to change it.

Why it fails: PermitOpen only constrains the destination of TCP forwarding; it does not disable forwarding itself, and pointing it at localhost:22 still allows a tunnel to the SSH service. More importantly, the requirement is to prevent forwarding entirely, not to restrict its destination. Relying on contractors not to change client settings is also unenforceable because the restriction is a server directive but the stated goal is broader than one port.

Deploy a ForceCommand internal-sftp directive for the contractor group so their sessions can only transfer files.

Why it fails: ForceCommand internal-sftp does restrict the session to SFTP file transfer and would incidentally prevent interactive forwarding, but it also disables normal shell use, which the scenario does not request. It is a heavier, different control than needed and changes the intended use case. The specific requirement is to block forwarding channels for contractors while still permitting SSH-key authentication for their work, making this overbroad and misaligned.

-a always,exit -F path=/etc/passwd -F perm=rw -k passwd_changes

Why it fails: This rule uses the -a always,exit syntax with a path filter and permission mask rw, which monitors read and write access. However, the requirement is to monitor modification attempts, not reads. Including read (r) would generate excessive events for every read access, which is not desired. Additionally, the -w shorthand is more commonly used for file watches. The rule would work but is not the best practice for this specific scenario.

-w /etc/passwd -p rwxa -k passwd_changes

Why it fails: This rule monitors read, write, execute, and attribute changes on /etc/passwd. While it would capture write attempts, it also logs read and execute operations, which are not relevant and would create unnecessary noise. The requirement is specifically to monitor modification attempts, so including r and x is overbroad. The correct mask should be limited to write and attribute change to focus on modifications.

-a always,exit -F arch=b64 -S open -F path=/etc/passwd -k passwd_changes

Why it fails: This rule uses the open system call with a path filter, which would log every open of /etc/passwd, including reads. It does not specifically filter for write intent. While it could capture modifications, it would also generate events for read-only opens, leading to false positives. The audit rule should use the perm filter or the -w watch to target write and attribute changes precisely.

Set the 'su' command to be executable only by root using file ACLs.

Why it fails: Using file ACLs to restrict execution of /bin/su to only root would prevent all non-root users from using su, similar to changing permissions. This is overly restrictive and not the intended method for allowing specific users. The standard practice is to use group membership and PAM configuration to control access. ACLs could be used, but they are not the typical or recommended solution for this scenario.

Set the su binary's permissions to 700 and owned by root.

Why it fails: Changing the permissions of /bin/su to 700 would prevent non-root users from executing it at all, effectively disabling su for everyone except root. While this restricts privilege escalation, it is a heavy-handed approach that may break legitimate administrative workflows. The requirement is to restrict, not completely disable, su for all users. A more granular control via group membership is preferred.

Remove the setuid bit from the su binary.

Why it fails: The su binary requires the setuid bit to function, as it needs to run with root privileges to change the user ID. Removing the setuid bit would prevent su from working for any user, including root, effectively breaking the command. This is not a viable hardening step; the goal is to control who can use su, not to disable it entirely. Proper PAM configuration is the correct approach.

PermitRootLogin no

Why it fails: Disabling root login prevents attackers from targeting a known administrative username directly. While this is a critical hardening step, it does not stop brute-force attacks against other existing user accounts. It forces the attacker to first guess a valid username before they can attempt to crack the associated password.

MaxAuthTries 3

Why it fails: Limiting authentication attempts helps mitigate brute-force speed, but it does not remove the vulnerability of weak passwords. Attackers can still rotate through different accounts or use slow-and-low techniques to bypass these thresholds. It is a detective or reactive control rather than a preventative one that changes the authentication mechanism.

AllowUsers admin

Why it fails: Restricting SSH access to specific users limits the scope of potential targets on the system. However, if those specific accounts use passwords, they remain vulnerable to targeted brute-force or credential stuffing. This setting is best used in conjunction with other hardening measures rather than as a primary defense.

The file can be modified by any user in the group.

Why it fails: The permissions string shows that the group only has read and execute permissions, represented by the 'r-x' in the middle triad. There is no 'w' present for the group, meaning they cannot modify the file. This answer misinterprets standard Linux permission bits and their specific positions.

The file is encrypted and requires a password to run.

Why it fails: Linux file system permissions do not indicate encryption status or password requirements for execution. The 's' bit is a functional permission modifier related to process identity, not a security wrapper or encryption flag. This option demonstrates a fundamental misunderstanding of how the Linux kernel handles file execution and permissions.

The binary is restricted to running only in runlevel 1.

Why it fails: Runlevels or systemd targets control which services and processes start during the boot sequence, but they are not enforced through file permission bits. A binary's ability to run is determined by the execute bit and the user's shell environment, regardless of the current system runlevel or target state.

Enabling the sticky bit on /tmp

Why it fails: The sticky bit on the /tmp directory is a filesystem-level security control that prevents users from deleting files owned by others. While it is a necessary hardening step for multi-user environments, it provides no protection against physical access, bootloader manipulation, or unauthorized hardware-level changes during the system startup sequence.

Disabling the IPv6 network stack

Why it fails: Disabling IPv6 is a network hardening step that can reduce the remote attack surface and prevent certain types of tunneling or discovery attacks. However, it does not address physical security concerns or protect the boot process from being hijacked by an attacker who has direct access to the console.

Create a rule to allow port 22 and log all other traffic.

Why it fails: Logging traffic is useful for auditing, but it does not inherently block unauthorized access. Without a default drop policy, the firewall might still allow other traffic depending on the remaining rules in the chain. Security should rely on active blocking rather than just recording that a connection attempt occurred.

Add a rule at the end of the chain that rejects all TCP traffic.

Why it fails: Rejecting only TCP traffic leaves the system vulnerable to UDP-based attacks and other protocols like ICMP or GRE. A comprehensive security posture requires a 'drop' policy for all protocols by default, rather than targeting a single transport layer protocol and leaving other potential attack vectors open to exploitation.

Set the default policy of the INPUT chain to ACCEPT.

Why it fails: Setting a default policy to ACCEPT is the opposite of hardening. It means that any traffic not explicitly blocked by a rule will be allowed through to the system services. This 'fail-open' configuration significantly increases the risk that a misconfigured or missing rule will leave a service exposed.

/etc/pam.d/login

Why it fails: The /etc/pam.d/login file controls PAM modules used during the login process, such as pam_securetty and pam_nologin, but it is not the primary file for password quality enforcement. Password complexity is typically configured in /etc/pam.d/system-auth (RHEL) or /etc/pam.d/common-password (Debian) using pam_pwquality, and the actual policy parameters reside in /etc/security/pwquality.conf. Editing login alone would not apply the required settings.

/etc/login.defs

Why it fails: The /etc/login.defs file controls system-wide defaults for useradd, usermod, and login, such as UID/GID ranges, password aging (PASS_MAX_DAYS), and umask, but it does not enforce password complexity rules like character classes or password history. Those are handled by PAM modules configured in /etc/pam.d/system-auth or /etc/pam.d/common-password. Editing login.defs alone would not meet the requirement for complexity or history.

/etc/shadow

Why it fails: The /etc/shadow file stores password hashes and aging information for user accounts, including the number of days since the last password change and account expiration. It does not contain policy settings for password complexity or history. Modifying /etc/shadow directly would only affect individual account entries, not enforce system-wide password rules, and is not the correct approach for setting password quality requirements.

Remove the 'noexec' option from /tmp and /var/tmp so the developer can move scripts there and execute them, keeping /home locked down.

Why it fails: Removing noexec from /tmp and /var/tmp weakens the server's hardening posture by allowing execution from world-writable directories, which is a common malware staging ground. This trades a strong control for a weaker one and does not satisfy the requirement to keep /home secure while enabling legitimate script execution.

Add the 'nosuid' option to /home only, because nosuid prevents all executable files from running and resolves the developer's concern.

Why it fails: The nosuid mount option prevents set-user-ID and set-group-ID bits from taking effect; it does not stop ordinary executable files from running. Therefore adding nosuid to /home would not address a developer's need to run scripts and would not stop script execution, making this option both ineffective and based on a misunderstanding.

Remount /home with the 'noexec' option and require the developer to store and execute scripts from /var/tmp instead.

Why it fails: Remounting /home with noexec would prevent execution of scripts directly from /home, but directing the developer to /var/tmp is poor practice because /var/tmp is world-writable and often allows execution, increasing the attack surface. This does not securely resolve the need and may introduce new risks.

Change root's shell to /sbin/nologin in /etc/passwd and delete the root entry from /etc/shadow.

Why it fails: Setting root's shell to /sbin/nologin blocks interactive shell logon but deleting the root entry from /etc/shadow is dangerous and can break system authentication and service startup. Many daemons and recovery procedures rely on the root account existing. This combination is overly destructive and not the recommended way to enforce the stated policy.

Set a very long, complex password for root and store it in a sealed envelope in a safe.

Why it fails: A long complex root password does not prevent direct interactive logon; it only makes guessing harder. The policy explicitly requires that root cannot be used for interactive logon, so keeping the account usable with a password fails the requirement. Storing the password in a safe is an operational control, not a technical enforcement of the logon restriction.

Add 'PermitRootLogin no' to /etc/ssh/sshd_config and restart the SSH service, leaving local console root logon enabled.

Why it fails: Disabling root SSH logon only blocks remote access over SSH; it does not prevent direct interactive logon at the physical console or via other services. The policy requires that root not be usable for direct interactive logon in general, so this partial measure leaves a significant gap unless the console is separately restricted.

Run 'sudo -v' to validate the sudoers file and then use 'getent group sudo' to list all privileged users.

Why it fails: sudo -v refreshes the invoking user's cached credentials; it does not validate the sudoers file or reveal NOPASSWD entries. Listing members of the sudo group only shows who has group-based privileges, not the specific passwordless commands granted via individual entries or included files. This approach fails to meet the verification requirement.

Run 'sudo -l' as each user to list their allowed commands and visually inspect /etc/sudoers for NOPASSWD entries.

Why it fails: Running sudo -l as each user shows that user's effective privileges, but it requires logging in as every user and does not detect syntax errors in the sudoers file. Visually inspecting /etc/sudoers is error-prone and may miss included files under /etc/sudoers.d, so this approach is incomplete and unreliable for a production audit.

Check the file permissions on /etc/sudoers and /etc/sudoers.d, then review the sudo log in /var/log/secure for NOPASSWD usage.

Why it fails: File permissions are important but do not reveal the content of passwordless grants, and /var/log/secure only shows commands that have already been run. It cannot enumerate all NOPASSWD entries or detect syntax errors before they cause problems. This method is reactive and incomplete for the stated verification goal.

Mount all filesystems with the 'noexec' option to prevent any binary from running.

Why it fails: Mounting all filesystems noexec would prevent legitimate system and application binaries from executing, breaking the servers. It is an overly broad measure that does not specifically target setuid or capability-based escalation and would cause severe operational failures. Hardening should be targeted, not applied indiscriminately across every mount point.

Set the immutable attribute on all files owned by root using 'chattr +i' recursively.

Why it fails: Applying the immutable attribute recursively to all root-owned files would prevent essential updates, logging, and normal system operation, effectively rendering the system unmanageable. It does not specifically address setuid or file capabilities and would cause widespread breakage. This is not a viable hardening technique for the stated goal.

Disable the sudo service and require all administrators to log in directly as root for administrative tasks.

Why it fails: Disabling sudo and forcing direct root logon increases risk by removing accountability and audit trails, and it does not address setuid binaries or file capabilities at all. Direct root logon makes privilege escalation easier to hide and contradicts least privilege principles. This action works against the stated hardening objective rather than supporting it.

vipw and vigr run as setuid root and bypass the kernel audit subsystem entirely, so no audit rules can capture their activity.

Why it fails: The kernel audit subsystem captures system calls regardless of whether a process is setuid; setuid status does not exempt a process from auditing. The real reason vipw and vigr evade a file watch is the inode replacement via rename, not a bypass of the audit subsystem. This explanation mischaracterizes how auditd interacts with privileged processes.

The audit rules were not loaded because auditd requires a reboot after adding watches to /etc/passwd and /etc/group.

Why it fails: Audit rules can be loaded at runtime with augenrules --load or auditctl, and direct edits are being logged, which proves the rules are active. A reboot is not required for watches to take effect. Since some modifications are captured, the rule loading is not the cause of the missing vipw and vigr events.

vipw and vigr write to /etc/shadow and /etc/gshadow instead of /etc/passwd and /etc/group, so the watches never trigger.

Why it fails: vipw edits /etc/passwd and vigr edits /etc/group, though they may also update the corresponding shadow files for password changes. The absence of audit events is not because they write elsewhere; it is because they replace the file via rename, changing the inode that the watch is bound to. This option misstates the file targets.

cut -d: -f1,2 /etc/shadow | grep ':$'

Why it fails: This command extracts the first two fields (username and password hash) and then greps for lines ending with a colon, which would indicate an empty second field. However, because it uses cut with -f1,2, the output is 'username:hash', and if the hash is empty, the line ends with a colon. This works, but it is less direct than using awk to check the second field. It also may include the colon from the cut output, but the logic is sound. However, it is not the most standard or efficient method, and could be confusing.

passwd -S $(cut -d: -f1 /etc/shadow) | grep 'NP'

Why it fails: The passwd -S command displays password status for a user, where 'NP' indicates no password. However, running passwd -S for every user in /etc/shadow is inefficient and may produce errors for system accounts. It also requires root privileges and may not work for all accounts. While it can detect empty passwords, it is not a direct file audit and is more complex than necessary. The awk method is simpler and more reliable.

grep -v '^[^:]*:[^:]*:' /etc/shadow

Why it fails: This grep command attempts to find lines that do not match a pattern of at least two colon-separated fields. However, the pattern is flawed: it would match lines that have fewer than two fields, but /etc/shadow always has multiple fields. It does not specifically target empty password fields. It may produce false positives or miss the intended accounts. A more direct approach is needed to check for empty second fields.

aide --update

Why it fails: The aide --update command updates the existing AIDE database with the current file system state, effectively accepting changes as the new baseline. It does not report differences; instead, it modifies the database to reflect the current state. This is useful after legitimate changes have been verified, but it is not used for detecting unauthorized changes. Using --update without verification could mask security incidents.

aide --compare

Why it fails: There is no aide --compare command. AIDE uses --check for comparison and --update for updating the database. The --compare option is not valid and would result in an error. It is important to use the correct syntax. The --check option is the standard way to compare the file system against the baseline and generate a report of differences.

aide --init

Why it fails: The aide --init command initializes a new AIDE database by scanning the file system and creating a baseline. It does not perform a comparison against an existing baseline; it creates a new one. This command is used only once to establish the initial database. Running it again would overwrite the baseline, losing the reference point. Therefore, it is not the correct command for a manual check.