Courseiva

CCNA Linux Security and Hardening Questions

13 questions · Linux Security and Hardening · All types, answers revealed

1
MCQmedium

A system administrator needs to harden a public-facing Linux server against automated brute-force attacks. Which configuration change in the /etc/ssh/sshd_config file provides the most significant reduction in the attack surface regarding credential stuffing?

A.PermitRootLogin no
B.PasswordAuthentication no
C.MaxAuthTries 3
D.AllowUsers admin
AnswerB

Disabling password authentication forces the use of cryptographic keys, which are significantly harder to brute-force than even complex passwords. This change effectively eliminates the risk of automated credential stuffing because the server will reject any attempt that does not present a valid private key, regardless of the password's strength.

Why this answer

Securing the Secure Shell daemon is a foundational step in Linux hardening, especially for internet-accessible systems. While multiple settings contribute to a defense-in-depth strategy, moving away from knowledge-based authentication to key-based authentication represents the single most impactful change. This reduces the attack surface by requiring a digital token that cannot be guessed or easily intercepted via network sniffing techniques.

Exam trap

Candidates frequently choose settings like changing the SSH port or disabling root login, missing that disabling password authentication entirely provides the absolute strongest mitigation against credential stuffing.

2
Multi-Selectmedium

A security analyst is hardening a fleet of Linux servers and wants to reduce the risk of privilege escalation through file capabilities and setuid binaries. The analyst plans to audit and restrict these mechanisms. Which two actions best support this goal? (Choose two.)

Select 2 answers
A.Mount all filesystems with the 'noexec' option to prevent any binary from running.
B.Set the immutable attribute on all files owned by root using 'chattr +i' recursively.
C.Search for setuid binaries with 'find / -perm -4000 -type f' and remove the setuid bit from any binary not strictly required.
D.Disable the sudo service and require all administrators to log in directly as root for administrative tasks.
E.Run 'getcap -r /' to enumerate files with capabilities and review each for necessity.
AnswersC, E

The find command with -perm -4000 locates files with the setuid bit set, which run with the file owner's privileges, often root. Removing the setuid bit from binaries that do not require it eliminates a common privilege escalation vector while preserving necessary functionality. This is a core hardening action for setuid auditing.

Why this answer

Reducing privilege escalation risk from setuid binaries and file capabilities requires discovering and minimizing them. Recursively enumerating capabilities with getcap and locating setuid files with find allows the analyst to identify unnecessary privilege grants and remove them. Blanket measures such as noexec mounts or immutable attributes are overly broad and break systems, while disabling sudo and using direct root logon weakens accountability instead of strengthening security.

Exam trap

The trap here is choosing broad, destructive controls like noexec on all filesystems instead of targeted enumeration and removal of unnecessary privilege bits.

3
MCQmedium

A security administrator is configuring auditd on a Linux server to meet a compliance requirement that all changes to user and group files be logged. The administrator adds a watch on /etc/passwd and /etc/group. After applying the rules, the administrator notices that modifications made using the 'vipw' and 'vigr' commands are not generating audit events, even though direct edits with a text editor are logged. Which explanation best describes why this occurs?

A.vipw and vigr run as setuid root and bypass the kernel audit subsystem entirely, so no audit rules can capture their activity.
B.The audit rules were not loaded because auditd requires a reboot after adding watches to /etc/passwd and /etc/group.
C.vipw and vigr use a temporary file and rename it over the original, so a file watch on /etc/passwd sees a different inode and misses the change.
D.vipw and vigr write to /etc/shadow and /etc/gshadow instead of /etc/passwd and /etc/group, so the watches never trigger.
AnswerC

Audit watches are attached to the inode of the watched file. Tools like vipw and vigr edit a temporary copy and then rename it over the original, creating a new inode. The watch on the old inode no longer applies, so the modification is not logged. This is a well-known limitation that requires watching the directory or using a different audit key strategy.

Why this answer

Audit watches in auditd are bound to the inode of the target file. The vipw and vigr utilities create a temporary file and rename it over the original, so the original inode is replaced and the watch no longer covers the new file. Direct edits modify the existing inode and are logged.

To reliably capture these changes, administrators should watch the containing directory or use audit rules that account for renames.

Exam trap

The trap here is assuming that a file watch follows the filename, when auditd actually binds the watch to the file's inode.

4
MCQeasy

A system administrator is hardening a Linux server and wants to ensure that users cannot log in with empty passwords. Which command should the administrator use to check for accounts with empty password fields in /etc/shadow?

A.cut -d: -f1,2 /etc/shadow | grep ':$'
B.passwd -S $(cut -d: -f1 /etc/shadow) | grep 'NP'
C.grep -v '^[^:]*:[^:]*:' /etc/shadow
D.awk -F: '($2 == "") {print $1}' /etc/shadow
AnswerD

This awk command parses /etc/shadow using colon as the field separator and checks if the second field (the password hash) is empty. If so, it prints the username. This directly identifies accounts with empty passwords, which is a critical security risk. It is a precise and efficient way to audit for this specific misconfiguration.

Why this answer

To identify accounts with empty passwords, the most direct method is to parse /etc/shadow and check if the password hash field is empty. The awk command with field separator ':' and condition $2 == "" accomplishes this by printing the username for any line where the second field is empty. This is a common security audit technique.

Other methods may work but are less precise or efficient. Ensuring no accounts have empty passwords is a fundamental Linux hardening step.

Exam trap

The trap here is using a command that checks for password status via passwd -S, which is slower and may not work for all accounts, instead of directly inspecting the shadow file.

5
MCQmedium

A security administrator is hardening the boot process of a production Ubuntu 22.04 server that uses GRUB 2. The policy requires that any interactive modification to the kernel command line at the GRUB menu must be blocked, and that the bootloader configuration file must be unreadable by unprivileged users. Which action should the administrator take to meet these requirements?

A.Enable the UEFI Secure Boot option in firmware and reinstall the operating system with a signed kernel.
B.Run grub-mkpasswd-pbkdf2, add a superuser entry with the resulting hash to /etc/grub.d/40_custom, and set chmod 600 on /boot/grub/grub.cfg.
C.Set GRUB_TIMEOUT=0 in /etc/default/grub and run update-grub to hide the menu.
D.Add the kernel parameter init=/bin/bash to /etc/default/grub and regenerate the bootloader configuration.
AnswerB

Password-protecting the GRUB 2 menu with a superuser entry prevents interactive editing of kernel parameters at boot, and restricting permissions on grub.cfg blocks unprivileged reading of the bootloader configuration. Together these satisfy the stated hardening policy, because only users who supply the GRUB password can modify boot entries, and other local users cannot inspect the configuration file.

Why this answer

Blocking interactive GRUB edits requires a bootloader password so the menu cannot be modified without authentication, and protecting grub.cfg with restrictive permissions prevents unprivileged users from reading boot parameters. The other choices either only hide the menu, rely on firmware verification that does not restrict menu editing, or introduce a recovery parameter that reduces security. Together, the password and file permission changes satisfy both parts of the policy.

Exam trap

The trap here is assuming that hiding the GRUB menu or enabling Secure Boot alone prevents kernel command-line tampering, when only a GRUB superuser password actually blocks interactive edits.

6
MCQmedium

A security engineer is configuring a Linux server to enforce password quality for all local accounts. The requirement is that passwords must be at least 14 characters long, contain at least one uppercase letter, one lowercase letter, one digit, and one special character, and must not repeat any of the last 5 passwords. Which file should the engineer edit to enforce these settings?

A./etc/pam.d/login
B./etc/login.defs
C./etc/security/pwquality.conf
D./etc/shadow
AnswerC

The /etc/security/pwquality.conf file is used by the pam_pwquality PAM module to enforce password complexity requirements such as minimum length (minlen), required character classes (ucredit, lcredit, dcredit, ocredit), and password history via the remember parameter (often set in PAM configuration but also influenced by pwquality). This is the correct location to define the specified password policy for local accounts on modern Linux distributions.

Why this answer

Password complexity and history requirements on Linux are enforced by the pam_pwquality module, which reads its configuration from /etc/security/pwquality.conf. This file allows administrators to set minlen, character class requirements, and other constraints. While PAM configuration files like system-auth or common-password reference the module, the policy parameters themselves are defined in pwquality.conf.

Therefore, editing /etc/security/pwquality.conf is the correct action to meet the stated password policy.

Exam trap

The trap here is confusing password aging settings in /etc/login.defs with password complexity enforcement, which is handled by PAM and pwquality.conf.

7
MCQeasy

A junior administrator is preparing a new Ubuntu server for production. The security policy states that the root account must not be usable for direct interactive logon, and that administrative tasks must be performed through a named account with elevated privileges. Which configuration change best enforces this policy?

A.Lock the root account password with 'passwd -l root' and grant administrative rights to named accounts via sudo.
B.Change root's shell to /sbin/nologin in /etc/passwd and delete the root entry from /etc/shadow.
C.Set a very long, complex password for root and store it in a sealed envelope in a safe.
D.Add 'PermitRootLogin no' to /etc/ssh/sshd_config and restart the SSH service, leaving local console root logon enabled.
AnswerA

Locking the root password with passwd -l root prepends an exclamation mark to the hash in /etc/shadow, disabling password-based logon for root while still allowing services and sudo to function. Granting named accounts sudo privileges ensures accountability and satisfies the policy that administrative tasks be performed through individual accounts with elevation.

Why this answer

The policy demands that root cannot be used for interactive logon and that administrative work be done through named accounts with elevated privileges. Locking the root password prevents password-based interactive authentication while sudo allows auditable, per-user elevation. Disabling only SSH root logon leaves console access open, and deleting root from /etc/shadow risks breaking the system.

A long password still permits direct root logon and is not a technical enforcement of the policy.

Exam trap

The trap here is equating 'PermitRootLogin no' with a complete ban on root logon, when it only affects the SSH service.

8
MCQhard

An information security auditor discovers a custom compiled binary in a shared directory with the following permissions: -rwsr-xr-x. The file is owned by the root user. What is the primary security implication of this finding?

A.The file can be modified by any user in the group.
B.The binary executes with the privileges of the root user.
C.The file is encrypted and requires a password to run.
D.The binary is restricted to running only in runlevel 1.
AnswerB

The 's' in the owner's execute position indicates the Set User ID bit is active. Since the owner is root, any user running this binary will have their effective user ID changed to root. This allows the program to perform administrative tasks that the standard user would normally be restricted from.

Why this answer

Understanding special permissions like SUID is critical for Linux security because they often lead to privilege escalation vulnerabilities. When the SUID bit is set on a file owned by root, any user who executes that file gains root-level privileges for the duration of the process. If the binary is poorly written, it can be exploited.

Exam trap

Candidates confuse the SUID permission with SGID or standard execution rights, failing to realize that the 's' in the user position elevates execution privileges to the file owner.

9
MCQhard

A security engineer is implementing file integrity monitoring on a Linux server. The engineer wants to use AIDE to detect unauthorized changes to critical system files. After initializing the AIDE database, which command should be used to perform a manual check and compare the current file system state against the baseline?

A.aide --update
B.aide --compare
C.aide --init
D.aide --check
AnswerD

The aide --check command compares the current file system state against the previously initialized AIDE database. It reports any changes, such as file additions, deletions, or modifications, based on the rules defined in the AIDE configuration. This is the correct command to perform a manual integrity check. It is typically run after the initial database is created and can be scheduled via cron for regular monitoring.

Why this answer

AIDE (Advanced Intrusion Detection Environment) is a file integrity checker. After initializing the baseline database with aide --init, the administrator uses aide --check to compare the current file system against that baseline. The check reports any discrepancies, which can indicate unauthorized changes.

The --update option is used to accept changes and update the database, while --init creates a new baseline. There is no --compare option. Therefore, aide --check is the correct command for a manual integrity verification.

Exam trap

The trap here is confusing --update with --check; --update modifies the baseline, while --check only reports differences without changing the database.

10
Multi-Selecthard

To ensure a Linux server is protected against unauthorized physical access or boot-level modifications, which THREE security controls should be implemented?

Select 3 answers
A.Setting a BIOS/UEFI password
B.Configuring a GRUB bootloader password
C.Enabling the sticky bit on /tmp
D.Disabling the IPv6 network stack
E.Implementing Full Disk Encryption (FDE)
AnswersA, B, E

A BIOS or UEFI password prevents unauthorized users from changing the boot order or modifying hardware-level settings. This is the first line of defense against an attacker trying to boot the system from an external USB drive or optical media to gain access to the underlying data on the disks.

Why this answer

Boot security is often overlooked but is a critical component of overall system hardening. If an attacker has physical access and the boot process is not secured, they can easily bypass operating system security controls by booting into single-user mode or using a live environment to mount and modify the local filesystem.

Exam trap

Candidates often select 'Antivirus' or 'Firewall' as security controls for physical boot-level threats, missing the point that these software-based solutions cannot prevent an attacker from booting into a different OS.

11
MCQmedium

A security administrator is hardening a Linux web server that hosts customer data. During a review of mount options, the administrator notes that the /tmp and /var/tmp directories are mounted with the 'noexec' and 'nosuid' options, but /home is not. A developer complains that scripts in /home are being executed by a scheduled process. Which action best maintains security while addressing the developer's need?

A.Remove the 'noexec' option from /tmp and /var/tmp so the developer can move scripts there and execute them, keeping /home locked down.
B.Add the 'nosuid' option to /home only, because nosuid prevents all executable files from running and resolves the developer's concern.
C.Remount /home with the 'noexec' option and require the developer to store and execute scripts from /var/tmp instead.
D.Leave /home mounted without 'noexec' and instead enforce execution control through SELinux booleans or AppArmor profiles that restrict which binaries the scheduled process may run.
AnswerD

When legitimate scripts must execute from /home, using mandatory access control such as SELinux booleans or AppArmor profiles restricts execution to approved binaries and paths without breaking the developer's workflow. This maintains defense in depth while allowing required functionality, unlike blunt mount options that would block all execution.

Why this answer

The scenario requires balancing operational need with hardening. Mount options like noexec and nosuid are valuable for directories that should never host executables, but /home may legitimately need to run scripts. Applying mandatory access control lets specific processes execute approved files while blocking everything else, preserving security without breaking the developer's scheduled process.

A blanket noexec on /home is too restrictive, and moving execution to world-writable temporary directories undermines the server's defenses.

Exam trap

The trap here is assuming that noexec is the only way to prevent execution and that nosuid blocks all execution, when nosuid only affects setuid/setgid bits.

12
MCQhard

A security engineer is reviewing a production RHEL 9 server and finds that several users have entries in /etc/sudoers granting them NOPASSWD for specific commands. The engineer wants to verify which users can run commands as root without a password and also check for any syntax errors in the sudoers configuration. Which approach provides the most reliable verification?

A.Run 'sudo -v' to validate the sudoers file and then use 'getent group sudo' to list all privileged users.
B.Run 'sudo -l' as each user to list their allowed commands and visually inspect /etc/sudoers for NOPASSWD entries.
C.Check the file permissions on /etc/sudoers and /etc/sudoers.d, then review the sudo log in /var/log/secure for NOPASSWD usage.
D.Use 'visudo -c' to check syntax and 'grep -r NOPASSWD /etc/sudoers /etc/sudoers.d/' to enumerate passwordless entries.
AnswerD

visudo -c parses the sudoers file and any included files, reporting syntax errors without modifying anything, while a recursive grep across /etc/sudoers and /etc/sudoers.d identifies all NOPASSWD grants. Together they provide reliable syntax validation and a complete inventory of passwordless command authorizations, which is exactly what the engineer needs for verification.

Why this answer

To reliably verify passwordless sudo grants, the engineer needs to enumerate all NOPASSWD entries across the main sudoers file and any drop-in files, and to validate syntax. visudo -c performs a syntax check on all included files, while a recursive grep captures every NOPASSWD occurrence. Approaches that rely on individual user sessions or logs are either incomplete or reactive, and checking group membership alone misses per-user and per-command grants.

Exam trap

The trap here is assuming that sudo -l or group membership reveals all passwordless grants, when included files under /etc/sudoers.d can contain additional entries.

13
MCQmedium

A security administrator needs to block all incoming traffic to a server except for SSH (port 22) using the nftables framework. Which configuration approach best follows the principle of least privilege?

A.Create a rule to allow port 22 and log all other traffic.
B.Add a rule at the end of the chain that rejects all TCP traffic.
C.Set the default policy of the INPUT chain to ACCEPT.
D.Set the default policy to DROP and add an allow rule for port 22.
AnswerD

This approach implements a 'whitelist' strategy, which is the most secure method for firewall configuration. By dropping all traffic by default, the administrator ensures that only the traffic explicitly defined (in this case, SSH) can reach the server, effectively closing all other ports and reducing the attack surface.

Why this answer

Firewall management is a core skill for securing Linux systems. Moving from iptables to nftables offers more efficient rule processing and a cleaner syntax. Following the principle of least privilege in a firewall context means explicitly denying all traffic by default and only opening the specific ports necessary for business operations.

Exam trap

Candidates often confuse the order of operations, mistakenly adding an allow rule before setting the default policy, or they fail to realize that nftables requires an explicit drop policy to secure the system.

Ready to test yourself?

Try a timed practice session using only Linux Security and Hardening questions.