Courseiva

CCNA System Security Questions

75 of 80 questions · Page 1/2 · System Security · Answers revealed

Practice these questionsDomain overviewAll questions
1
MCQmedium

Which user can execute any command as any user without any password restriction?

A.alice
B.charlie
C.root
D.bob
AnswerC

Root has (ALL) ALL with no passwd restriction (default NOPASSWD for root?). Actually root's entry shows (ALL) ALL, but root is not subject to sudo restrictions? Usually root is all-powerful. In this exhibit, root's entry is like a regular user, but since root is the superuser, it's effectively unrestricted.

Why this answer

The root user (UID 0) has unrestricted superuser privileges by default on Linux systems. Unlike regular users, root can execute any command as any user without needing to provide a password, as there is no sudo or su password requirement for the root account itself. This is a fundamental security property of the Unix/Linux permission model.

Exam trap

The trap here is that candidates may confuse the root user's inherent passwordless privilege with sudo's NOPASSWD directive, thinking any user listed in sudoers with NOPASSWD has the same unrestricted access as root.

How to eliminate wrong answers

Option A is wrong because alice is a regular user who must authenticate with a password when using sudo or su to run commands as another user, unless explicitly configured with NOPASSWD in /etc/sudoers. Option B is wrong because charlie is also a regular user subject to the same password authentication requirements as alice. Option D is wrong because bob is a regular user who cannot execute commands as any user without password restrictions unless granted specific sudo privileges.

Practice this question →
2
MCQmedium

A system administrator is setting up mutual TLS (mTLS) for communication between a web server and a backend application on a Linux server. The security team requires encryption and proper certificate management with automated renewal using open-source tools on a small budget. Which solution should the administrator implement?

A.Generate self-signed certificates using OpenSSL and manually distribute them via SCP.
B.Set up a private CA with easy-rsa and configure a cron job for certificate renewal.
C.Deploy Hashicorp Vault with PKI backend.
D.Use Let's Encrypt with an ACME client to issue internal certificates.
AnswerB

easy-rsa builds a proper CA and cron automates renewal, suitable for low budget.

Why this answer

Easy-rsa provides a simple wrapper around OpenSSL to create a private CA, and a cron job can automate certificate renewal, meeting the budget and open-source requirements. This is a common approach for internal mTLS in Linux environments.

Exam trap

Candidates might choose Hashicorp Vault (option C) due to its enterprise features, but it is over-engineered for a small budget. The simpler easy-rsa with cron is sufficient and aligns with LPIC-2's focus on standard Linux tools.

How to eliminate wrong answers

Option A is wrong because manually generating certificates with OpenSSL and distributing them via Kubernetes Secrets does not provide automated renewal, which is a core requirement; it also introduces operational overhead and risk of expired certificates. Option C is wrong because while cfssl can set up a custom CA, pushing certificates via Ansible is not Kubernetes-native and lacks the automated lifecycle management and integration with Kubernetes resources that cert-manager offers. Option D is wrong because Hashicorp Vault with PKI backend and sidecar agents is a powerful solution but is overkill for the stated small budget and simpler requirements; it introduces significant complexity and resource overhead compared to a lightweight, open-source tool like cert-manager.

Practice this question →
3
Multi-Selecteasy

A system administrator wants to enforce key-based SSH authentication for all users on a server, disabling password authentication. Which two commands must be executed to achieve this? (Choose TWO.)

Select 2 answers
A.sshd -T
B.visudo
C.ssh-keygen -t rsa -b 4096
D.chmod 600 ~/.ssh/authorized_keys
E.ssh-copy-id user@server
AnswersC, E

Generates the SSH key pair.

Why this answer

`ssh-keygen -t rsa -b 4096` generates a 4096-bit RSA key pair, which is a prerequisite for key-based authentication. Option E is correct because `ssh-copy-id user@server` securely copies the public key to the server's `~/.ssh/authorized_keys` file, enabling key-based login. Together, these commands allow the administrator to then disable password authentication by editing `/etc/ssh/sshd_config` (setting `PasswordAuthentication no`) and restarting the SSH service.

Exam trap

The trap here is that candidates may think `chmod 600 ~/.ssh/authorized_keys` (Option D) directly enforces key-based authentication, but it only sets file permissions; the actual enforcement requires configuration changes in `sshd_config` and key generation/deployment via `ssh-keygen` and `ssh-copy-id`.

Practice this question →
4
MCQhard

A Linux server in a DMZ hosts a custom web application that listens on TCP port 8080. The server is also configured with SSH on port 22 for remote administration. Recently, the security team noticed an increase in brute-force attacks against SSH from various external IPs. The server runs Fedora with firewalld as the firewall service. The current firewalld default zone is 'public', and the SSH service is allowed in the 'public' zone. The administrator wants to mitigate the brute-force attacks without blocking legitimate users. Additionally, the administrator wants to ensure that only specific administrative IP addresses can initiate SSH connections, and that SSH connections are rate-limited to prevent flooding. The administrator also needs to keep the web application accessible from any external IP. Which course of action best meets these requirements?

A.Move SSH to a non-standard port (e.g., 2222) and update the firewalld service definition accordingly.
B.Use iptables to create a whitelist for SSH, and install fail2ban to rate-limit after 3 failures.
C.Change the default zone to 'drop', then add a rich rule to allow SSH only from the administrative network.
D.Add a firewalld rich rule to allow SSH only from specific source IPs, and add a rich rule to limit connection rate for SSH. Keep the web application in the same zone with the appropriate service.
AnswerD

Rich rules provide granular control; direct rule syntax allows whitelist and rate limit.

Why this answer

Firewalld rich rules allow granular control: you can specify source IPs for SSH access and apply a connection rate limit (e.g., using 'limit' in the rich rule) to mitigate brute-force attacks without blocking legitimate users. The web application on port 8080 remains accessible from any external IP because the 'public' zone still has the appropriate service allowed, and the rich rules only restrict SSH. This approach avoids changing the default zone or using external tools like fail2ban, keeping the solution within firewalld's native capabilities.

Exam trap

The trap here is that candidates often choose Option B (iptables + fail2ban) because they are familiar with those tools, but the question specifically mentions firewalld, and the LPIC-2 exam expects you to know that firewalld can natively handle both source whitelisting and rate limiting without external dependencies.

How to eliminate wrong answers

Option A is wrong because moving SSH to a non-standard port (e.g., 2222) is security through obscurity and does not prevent brute-force attacks; attackers can still scan for the port, and it does not provide rate-limiting or IP whitelisting. Option B is wrong because using iptables directly bypasses firewalld's management layer, which can lead to conflicts with firewalld's ruleset; additionally, fail2ban is an external tool that adds complexity and is not necessary when firewalld can natively rate-limit connections. Option C is wrong because changing the default zone to 'drop' would block all traffic by default, including the web application on port 8080, unless explicit rules are added; while you could add rich rules for SSH, this approach is overly restrictive and requires extra configuration to re-allow the web service, making it less straightforward than D.

Practice this question →
5
MCQmedium

An organization requires that all email traffic from their mail server must be encrypted in transit. Which of the following is the most appropriate solution?

A.Implement IPsec to encrypt all traffic between mail servers.
B.Use SMTPS (SMTP over SSL) on port 465.
C.Configure the mail server to use SSH tunneling for all SMTP connections.
D.Enable STARTTLS on the SMTP server to encrypt connections.
AnswerD

STARTTLS upgrades plain SMTP to encrypted using TLS.

Why this answer

STARTTLS is the standard method for upgrading a plaintext SMTP connection to an encrypted one using TLS, as defined in RFC 3207. It allows the mail server to negotiate encryption on the standard SMTP port (25) or submission port (587), ensuring that email traffic is encrypted in transit without requiring a separate port or protocol. This is the most appropriate solution because it is widely supported, interoperable, and aligns with modern email security best practices.

Exam trap

The trap here is that candidates often confuse SMTPS (port 465) with STARTTLS, believing that using a dedicated SSL port is more secure, when in fact STARTTLS is the modern, standardized approach that allows encryption on standard ports and is required for compliance with many security frameworks.

How to eliminate wrong answers

Option A is wrong because IPsec encrypts all traffic at the network layer, which is overkill for email and introduces significant complexity in configuration and key management; it is not a standard solution for SMTP encryption. Option B is wrong because SMTPS on port 465 is a deprecated protocol that was never standardized by the IETF; it uses SSL/TLS from the start, which breaks compatibility with many mail servers and clients that expect STARTTLS negotiation. Option C is wrong because SSH tunneling requires an SSH server on the mail server and manual setup for each connection, which is impractical for a production mail server handling many concurrent connections; it also does not provide native SMTP encryption and adds unnecessary overhead.

Practice this question →
6
MCQeasy

An administrator wants to restrict SSH access to a server so that only users from the domain 'example.com' can connect. Which file and syntax should be used with TCP Wrappers?

A.Add to /etc/hosts.deny: sshd: ALL
B.Add to /etc/hosts.allow: ALL: .example.com
C.Add to /etc/hosts.allow: sshd: .example.com
D.Add to /etc/hosts.allow: sshd: ALLOW .example.com
AnswerC

Allows SSH connections from example.com domain.

Why this answer

TCP Wrappers uses the /etc/hosts.allow file to grant access based on daemon: client patterns. The syntax 'sshd: .example.com' restricts SSH access to clients whose hostnames end with '.example.com', which matches all hosts in the 'example.com' domain. This is the standard way to allow only users from a specific domain to connect via SSH using TCP Wrappers.

Exam trap

The trap here is that candidates may confuse the syntax of TCP Wrappers with that of iptables or fail to recognize that the leading dot in '.example.com' is the correct way to match an entire domain, leading them to choose options with incorrect keywords like 'ALLOW' or overly broad patterns like 'ALL'.

How to eliminate wrong answers

Option A is wrong because adding 'sshd: ALL' to /etc/hosts.deny would deny all SSH connections, but it does not specify an allow rule for 'example.com', so it would block everyone including legitimate users. Option B is wrong because 'ALL: .example.com' in /etc/hosts.allow would allow all services (not just SSH) from the domain, which is too permissive and does not meet the requirement to restrict only SSH access. Option D is wrong because 'sshd: ALLOW .example.com' is invalid syntax; TCP Wrappers uses a colon-separated daemon: client_list format, not the keyword 'ALLOW'.

Practice this question →
7
MCQhard

An administrator is configuring nftables to log and drop packets from a specific IP. The rule must be added to the input hook. Which command accomplishes this?

A.nft add rule inet filter input ip saddr 10.0.0.5 log accept
B.nft add rule inet filter input ip saddr 10.0.0.5 log drop
C.nft add rule inet filter input ip saddr 10.0.0.5 log prefix "DROP" drop
D.nft add rule ip filter input ip saddr 10.0.0.5 drop
AnswerB, C

Correct. This rule logs the packet (with default log settings) and then drops it, satisfying the requirement.

Why this answer

Both options B and C are syntactically valid nftables rules that log and drop packets from the specified IP. Option B uses 'log drop' which logs the packet with default settings and then drops it. Option C adds a custom prefix for more descriptive logging.

The question does not require a prefix, so both B and C are correct. Option A logs with 'accept', which contradicts the drop requirement. Option D logs without a verdict, which is incomplete.

Exam trap

Candidates may think that only option C is correct because it includes a prefix, but option B is also syntactically valid and accomplishes the required logging and dropping. The question does not specify that a prefix is mandatory, so both B and C are acceptable.

How to eliminate wrong answers

Option A is wrong because it uses `accept` as the verdict, which would allow the packet through instead of dropping it, failing the requirement to drop. Option B is wrong because it omits the `prefix` keyword; while `log drop` is syntactically valid, the `log` statement in nftables requires a `prefix` to produce meaningful log output (otherwise it logs with an empty prefix), and the question implies a proper logging configuration. Option D is wrong because it uses the `ip` family instead of `inet`, which limits the rule to IPv4 only and does not include a `log` statement, so it drops without logging.

Practice this question →
8
Multi-Selecthard

Which iptables command is necessary to allow incoming SSH connections (port 22) from the subnet 192.168.1.0/24 while dropping all other incoming traffic? Assume the INPUT chain has a default policy of DROP.

Select 1 answer
A.iptables -A INPUT -s 192.168.1.0/24 -p tcp --dport 22 -j DROP
B.iptables -A INPUT -j DROP
C.iptables -A INPUT -s 192.168.1.0/24 -p tcp --dport 22 -j ACCEPT
D.iptables -A INPUT -j ACCEPT
E.iptables -A INPUT -s 192.168.1.0/24 -j ACCEPT
AnswersC

This rule correctly allows incoming SSH connections from the subnet 192.168.1.0/24. It matches the source address, TCP protocol, and destination port 22, and jumps to ACCEPT.

Why this answer

It explicitly allows SSH traffic from the specified subnet before the default DROP policy drops everything else. Option B is not necessary because the INPUT chain already has a default policy of DROP, which drops all unmatched packets. Adding an explicit DROP rule at the end is redundant and not required by the question, which asks for the 'necessary' command.

Exam trap

The trap is that candidates often think they need an explicit DROP rule even when the default policy is DROP. However, the default policy already drops unmatched packets, so only the ACCEPT rule (option C) is necessary. A common mistake is to select both B and C, misunderstanding the word 'necessary' in the question.

Practice this question →
9
MCQhard

A financial institution uses a Linux server with a custom application that runs as the 'appuser' and writes logs to /var/log/app/. The security team recently detected that the application is vulnerable to a local privilege escalation via log injection. To mitigate, they decide to implement mandatory access control (MAC) using SELinux. The system is CentOS 7 with SELinux in enforcing mode. The current context of /var/log/app is 'unconfined_u:object_r:var_log_t:s0'. The application should only be allowed to write to logs in that directory, and no other processes should modify them. Which SELinux policy change should be made?

A.Use 'semanage permissive -a app_t' to put the application domain in permissive mode.
B.Create a custom SELinux policy module that defines a new type for the log directory and transitions for the application domain.
C.Run 'chcon -t var_log_t /var/log/app' to set the correct context.
D.Use 'audit2allow' to create a local policy module based on current denials.
AnswerB

A targeted policy ensures least privilege and persistent enforcement.

Why this answer

The application needs a dedicated SELinux type for its log directory and a domain transition so that only the 'appuser' process running in the 'app_t' domain can write to that directory. Creating a custom policy module with a new type (e.g., 'app_log_t') and a file transition rule ensures that other processes (even those with 'var_log_t' access) cannot modify the logs, meeting the strict confinement requirement.

Exam trap

The trap here is that candidates assume the existing 'var_log_t' type is sufficient and that 'chcon' or 'audit2allow' can fix the issue, but they miss the need for a dedicated type and domain transition to enforce exclusive write access for the application.

How to eliminate wrong answers

Option A is wrong because setting the application domain to permissive mode would disable SELinux enforcement for that domain, allowing the privilege escalation to succeed, which defeats the purpose of mitigation. Option C is wrong because 'chcon -t var_log_t /var/log/app' would set the same type that is already present, and the current context 'unconfined_u:object_r:var_log_t:s0' already has that type; the issue is not the type but the lack of a dedicated type and domain transition to restrict access to only the application. Option D is wrong because 'audit2allow' generates policy based on existing denials, but since the application is currently running without denials (it can write to 'var_log_t'), no denials would be generated, and the resulting policy would not create the necessary isolation.

Practice this question →
10
MCQhard

Based on the sshd configuration, user 'charlie' attempts to log in using public key authentication. What will happen?

A.Login is denied because the DenyUsers directive explicitly blocks charlie.
B.Login is allowed because PasswordAuthentication is disabled, but public key authentication is enabled.
C.Login is allowed because AllowUsers includes other users but does not deny charlie.
D.Login is denied because charlie's IP address is not in the allowed list.
AnswerA

DenyUsers blocks charlie regardless of authentication.

Why this answer

The DenyUsers directive in sshd_config explicitly blocks the user 'charlie' from logging in, regardless of the authentication method. Since DenyUsers takes precedence over AllowUsers and other authentication settings, public key authentication will still be denied for charlie. The correct answer is A because the directive explicitly denies charlie, overriding any other configuration.

Exam trap

The trap here is that candidates often assume that enabling public key authentication automatically allows login, ignoring the explicit DenyUsers directive that takes precedence over authentication methods.

How to eliminate wrong answers

Option B is wrong because while PasswordAuthentication is disabled and public key authentication is enabled, the DenyUsers directive explicitly blocks charlie, so login is denied regardless of the authentication method. Option C is wrong because AllowUsers includes other users but does not deny charlie; however, DenyUsers explicitly blocks charlie, and DenyUsers takes precedence over AllowUsers. Option D is wrong because there is no IP-based restriction mentioned in the question; the denial is due to the DenyUsers directive, not an IP address list.

Practice this question →
11
Matchingmedium

Match each systemd unit type to its function.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts
Matches

Manages a daemon or process

Manages IPC or network socket

Triggers activation based on time events

Controls filesystem mount points

Groups units to define system states

Why these pairings

Common systemd unit types include service (daemon management), socket (socket-based activation), timer (scheduled tasks), and target (grouping). Distractors swap definitions between types.

Practice this question →
12
MCQhard

A security analyst notices that an /etc/pam.d/common-auth file contains the line 'auth required pam_tally2.so deny=5'. What is the effect?

A.Log failed attempts only
B.Password expiration after 5 days
C.Maximum 5 concurrent sessions
D.Account lockout after 5 failed login attempts
AnswerD

pam_tally2.so with deny=5 locks the account after 5 failed login attempts.

Why this answer

The `pam_tally2.so` module tracks login attempts and, when used with `deny=5`, locks the account after five consecutive failed authentication attempts. The `required` control ensures that if the tally threshold is exceeded, authentication fails immediately, preventing further access until the count is reset by an administrator or via `pam_tally2` reset.

Exam trap

The trap here is that candidates confuse `pam_tally2.so` with `pam_unix.so` or `pam_cracklib.so` for password aging, or mistakenly think `deny=5` limits concurrent sessions rather than failed login attempts.

How to eliminate wrong answers

Option A is wrong because `pam_tally2.so` with `deny=5` does not merely log failed attempts; it enforces an account lockout after the threshold is reached. Option B is wrong because password expiration is handled by `pam_unix.so` or `pam_cracklib.so` with parameters like `password_expire`, not by `pam_tally2.so`. Option C is wrong because concurrent session limits are managed by `pam_limits.so` via `/etc/security/limits.conf`, not by the tally module.

Practice this question →
13
MCQeasy

To protect against SSH brute-force attacks, a system administrator installs fail2ban. Which configuration file should be modified to enable the SSH jail with default settings?

A./etc/fail2ban/fail2ban.conf
B./etc/ssh/sshd_config
C./etc/fail2ban/jail.local
D./etc/fail2ban/jail.conf
AnswerC

This file overrides settings in jail.conf; enabling the SSH jail here is the proper method.

Why this answer

Fail2ban uses jail.local to override default settings from jail.conf without modifying the package-managed file. The SSH jail is defined in jail.conf but enabling it with default settings requires creating or editing jail.local, which takes precedence over jail.conf. This ensures that customizations survive package updates.

Exam trap

The trap here is that candidates often confuse jail.conf (the default file) with jail.local (the override file), or assume that fail2ban's main config file (fail2ban.conf) is used to enable jails, when in fact jails are managed separately in the jail configuration files.

How to eliminate wrong answers

Option A is wrong because /etc/fail2ban/fail2ban.conf is the main configuration file for fail2ban's global behavior (e.g., log level, socket path), not for defining or enabling jails. Option B is wrong because /etc/ssh/sshd_config is the SSH server configuration file, unrelated to fail2ban's jail definitions; fail2ban works by monitoring logs, not by modifying sshd_config. Option D is wrong because /etc/fail2ban/jail.conf is the default jail configuration file provided by the package, but it should not be edited directly; instead, a jail.local file is used to override or enable jails without risking overwrites during package updates.

Practice this question →
14
MCQeasy

A system administrator wants to verify the integrity of a downloaded package using a GPG signature. Which command should be used after importing the distributor's public key?

A.gpg --encrypt package.tar.gz
B.gpg --verify package.tar.gz.asc package.tar.gz
C.gpg --decrypt package.tar.gz.asc
D.gpg --sign package.tar.gz
AnswerB

This verifies the detached signature against the file.

Why this answer

The `--verify` option is used to check the authenticity and integrity of a file against a detached GPG signature file. After importing the distributor's public key, running `gpg --verify package.tar.gz.asc package.tar.gz` confirms that the package was signed by the corresponding private key and has not been altered since signing.

Exam trap

The trap here is confusing `--verify` with `--decrypt`, as both involve `.asc` files, but `--decrypt` is only for encrypted messages, not signature verification.

How to eliminate wrong answers

Option A is wrong because `--encrypt` is used to encrypt data with a public key, not to verify a signature. Option C is wrong because `--decrypt` is used to decrypt encrypted data, not to verify a detached signature; it would attempt to decrypt the `.asc` file as if it were ciphertext. Option D is wrong because `--sign` creates a new signature on a file, which is the opposite of verifying an existing signature.

Practice this question →
15
Multi-Selecteasy

An administrator wants to enhance the security of a web server running Apache. Which TWO of the following actions are recommended best practices?

Select 2 answers
A.Enable the mod_info module to monitor server configuration.
B.Disable directory listing in the Apache configuration using Options -Indexes.
C.Enable .htaccess files to allow per-directory configuration changes.
D.Run the Apache worker processes as a non-root user such as www-data.
E.Enable the HTTP TRACE method for debugging purposes.
AnswersB, D

Disabling directory listing prevents attackers from browsing directory contents.

Why this answer

Disabling directory listing with `Options -Indexes` prevents Apache from generating a list of files in directories that lack an index file (e.g., index.html). This is a fundamental security hardening step that reduces information disclosure about the web server's file structure, which could be leveraged by an attacker to find sensitive files or configuration details. Option D is correct because running Apache worker processes as a non-root user (e.g., www-data) minimizes the impact of a potential security breach.

If an attacker compromises a worker process, they will not have root privileges, limiting the damage. This is a principle of least privilege and a standard security best practice.

Exam trap

The trap here is that candidates often confuse enabling `.htaccess` files (Option C) with a security best practice, when in fact it is a security anti-pattern that reduces performance and control, while the correct hardening step is to disable them and centralize configuration.

Practice this question →
16
MCQeasy

To ensure that OpenVPN clients authenticate the server, which configuration directive should be present on the client side?

A.tls-verify
B.tls-auth
C.ca
D.cert
AnswerC

ca points to the CA certificate file that verifies the server's certificate.

Why this answer

The `ca` directive on the client side specifies the Certificate Authority (CA) certificate file that the client uses to verify the server's certificate during the TLS handshake. This ensures the client authenticates the server's identity, preventing man-in-the-middle attacks. Without this, the client cannot validate that it is connecting to a trusted OpenVPN server.

Exam trap

The trap here is that candidates often confuse `tls-auth` (which provides a shared secret for control channel authentication) with certificate-based server authentication, mistakenly thinking it verifies the server's identity, when in fact only the `ca` directive enables proper PKI-based server validation.

How to eliminate wrong answers

Option A is wrong because `tls-verify` is used on the server side to verify the client's certificate against a custom script or command, not for the client to authenticate the server. Option B is wrong because `tls-auth` adds a pre-shared key for HMAC-based packet authentication and optional encryption of the TLS control channel, but it does not validate the server's certificate; it protects against unauthorized packets and DoS attacks. Option D is wrong because `cert` specifies the client's own certificate for the server to authenticate the client, not for the client to verify the server.

Practice this question →
17
Multi-Selecthard

Which two commands correctly configure SSH to disable root login? (Select two.)

Select 2 answers
A.usermod -L root
B.echo "PermitRootLogin without-password" >> /etc/ssh/sshd_config
C.echo "DenyUsers root" >> /etc/ssh/sshd_config
D.echo "PermitRootLogin yes" >> /etc/ssh/ssh_config
E.echo "PermitRootLogin no" >> /etc/ssh/sshd_config
AnswersC, E

This explicitly denies root user from SSH login.

Why this answer

`DenyUsers root` in `/etc/ssh/sshd_config` explicitly prevents the root user from logging in via SSH, regardless of other authentication methods. Option E is correct because `PermitRootLogin no` directly disables all root SSH logins (password, key, or otherwise) in the SSH server configuration. Both directives require a subsequent restart or reload of the sshd service to take effect.

Exam trap

The trap here is that candidates confuse `PermitRootLogin without-password` (which still allows key-based root login) with disabling root login entirely, or they mistakenly edit the client-side `ssh_config` instead of the server-side `sshd_config`.

Practice this question →
18
MCQhard

Refer to the exhibit. An administrator has applied these iptables rules. Users can still SSH into the server from any IP address, which is unexpected because the administrator intended to restrict SSH to only a specific subnet. What is the most likely reason the restriction is not working?

A.The SSH rule does not specify a source IP, so it accepts connections from any IP.
B.The default policy is ACCEPT, so the DROP rule is ignored.
C.The conntrack module is not loaded, so the state matching fails.
D.The rules are in the wrong order; the DROP rule should be before the SSH rule.
AnswerA

Without a -s option, the rule matches all source IPs, leading to unrestricted SSH access.

Why this answer

The SSH ACCEPT rule does not include a source IP specification, so by default iptables matches any source address. The administrator intended to restrict SSH to a specific subnet, but without a `-s` parameter, the rule accepts all incoming SSH connections regardless of origin. The DROP rule for other subnets is never reached because the ACCEPT rule matches first for all SSH traffic.

Exam trap

The trap here is that candidates often assume the DROP rule will block all traffic except the intended subnet, but they overlook that the ACCEPT rule without a source IP matches everything first, making the DROP rule unreachable for SSH packets.

How to eliminate wrong answers

Option B is wrong because the default policy being ACCEPT does not cause the DROP rule to be ignored; iptables processes rules sequentially, and a DROP rule will still be evaluated and can reject packets if matched. Option C is wrong because the conntrack module (nf_conntrack) is typically loaded by default on modern Linux kernels, and state matching (e.g., `-m state --state ESTABLISHED,RELATED`) is not required for basic SSH access; the issue is the missing source IP, not state tracking. Option D is wrong because the order of rules is not the problem here; placing the DROP rule before the SSH rule would drop all SSH traffic (including from the intended subnet) unless the DROP rule itself specifies a source range, which it does not in the described scenario.

Practice this question →
19
MCQhard

Refer to the exhibit. A user cannot log in via SSH even though the password is correct. What is the most likely issue?

A.The password module is not configured correctly.
B.pam_unix.so nullok allows blank passwords, causing authentication to fail.
C.The /etc/nologin file exists, preventing non-root logins.
D.pam_securetty.so restricts root login via SSH, but the user is not root.
AnswerC

pam_nologin.so denies login if /etc/nologin exists, affecting all users except root.

Why this answer

The /etc/nologin file, when present, prevents all non-root users from logging into the system via any authentication method, including SSH. This is a common administrative mechanism to block user access during maintenance or security incidents. Since the password is correct but login fails, the existence of /etc/nologin is the most likely cause, as it overrides successful PAM authentication for non-root users.

Exam trap

The trap here is that candidates often focus on password-related PAM modules (like pam_unix.so or pam_securetty.so) and overlook the system-level /etc/nologin file, which can silently block all non-root logins regardless of authentication success.

How to eliminate wrong answers

Option A is wrong because the password module (typically pam_unix.so or pam_pwquality.so) is not inherently misconfigured; the question states the password is correct, so the failure is not due to module configuration. Option B is wrong because pam_unix.so nullok allows blank passwords to succeed, not fail; if nullok were causing issues, it would permit logins with empty passwords, not block correct ones. Option D is wrong because pam_securetty.so restricts root login only from non-secure terminals (e.g., SSH), but the user is not root, so this restriction does not apply.

Practice this question →
20
MCQeasy

A web server running Apache is receiving many failed login attempts. Which tool should be used to dynamically block IPs after a configurable number of failures?

A.fail2ban
B.TCP Wrappers
C./etc/hosts.deny
D.iptables
AnswerA

Monitors logs and dynamically bans IPs via firewall rules.

Why this answer

fail2ban is the correct tool because it monitors log files (e.g., /var/log/apache2/error.log) for repeated failed login attempts and dynamically updates iptables or nftables rules to block the offending IP address after a configurable threshold (e.g., maxretry = 5). It is purpose-built for this task, offering flexible jails and ban actions, unlike static or system-wide mechanisms.

Exam trap

The trap here is that candidates confuse static access control tools (TCP Wrappers, /etc/hosts.deny) or raw firewall commands (iptables) with a dynamic, log-monitoring intrusion prevention tool like fail2ban, which is specifically designed for this use case.

How to eliminate wrong answers

Option B (TCP Wrappers) is wrong because it controls access at the application layer via /etc/hosts.allow and /etc/hosts.deny based on hostname or IP, but it cannot dynamically block IPs after a configurable number of failures—it only provides static allow/deny rules. Option C (/etc/hosts.deny) is wrong because it is a static configuration file used by TCP Wrappers, not a tool; it cannot monitor logs or count failures to trigger dynamic bans. Option D (iptables) is wrong because while iptables can block IPs, it is a firewall rule management tool that does not natively parse log files or count failed login attempts—it requires an external tool like fail2ban to automate dynamic blocking.

Practice this question →
21
MCQhard

Given the exhibit, what is the most likely reason for the GPG error, and what is the correct way to fix it permanently?

A.The repository is not signed; use '--allow-unauthenticated' permanently in /etc/apt/apt.conf.d/
B.The repository URL is incorrect; change 'http://deb.example.com' to 'https://deb.example.com'
C.The InRelease file is corrupted; remove it and run 'apt-get update' again
D.The public key is missing; obtain and add it with 'apt-key add' or 'wget -O- | apt-key add -'
AnswerD

Adding the correct public key resolves the error.

Why this answer

The GPG error indicates that the repository's Release file is signed but the system lacks the corresponding public key to verify the signature. This is a common issue when adding third-party repositories. The correct permanent fix is to obtain the missing public key and add it to the APT keyring using 'apt-key add' or by piping the key with 'wget -O- | apt-key add -', which allows APT to authenticate the repository's metadata.

Exam trap

The trap here is that candidates often confuse a missing GPG key with a corrupted file or an incorrect repository URL, but the GPG error message explicitly mentions 'NO_PUBKEY', which directly points to a missing public key.

How to eliminate wrong answers

Option A is wrong because '--allow-unauthenticated' bypasses signature verification entirely, which is insecure and not a permanent fix; it also violates APT's security model. Option B is wrong because changing the URL from HTTP to HTTPS does not resolve a missing GPG key; it addresses transport security, not authentication of the repository's content. Option C is wrong because removing the InRelease file and re-running 'apt-get update' will not fix a missing public key; the error will persist as APT cannot verify the signature without the key.

Practice this question →
22
MCQhard

An administrator configures iptables on a Linux firewall with the following rules: -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT; -A INPUT -p tcp --dport 22 -m state --state ESTABLISHED,RELATED -j ACCEPT; -A INPUT -j DROP. Users report that SSH connections are being dropped. What is the most likely cause?

A.The default INPUT policy is DROP, so the last rule is redundant but harmless.
B.The rule for SSH uses --dport 22, but the source port is randomized; it should use --sport 22.
C.The SSH rule should have -m state --state NEW to allow new connections.
D.The established/related rule should come after the SSH rule.
AnswerC

Correct. The SSH rule only matches ESTABLISHED and RELATED packets, so new connection attempts (NEW state) are dropped by the final rule.

Why this answer

The most likely cause is that the SSH rule only matches packets that are already part of an established or related connection. New SSH connections start with a SYN packet that is in the NEW state, so they are not matched by the second rule. They fall through to the final DROP rule and are dropped.

Adding `-m state --state NEW` (or `-m state --state NEW,ESTABLISHED,RELATED`) to the SSH rule would allow new connections. Option A is incorrect because the default INPUT policy is not relevant when explicit DROP exists; B confuses source and destination ports; D is wrong because reordering does not change the state matching logic.

Exam trap

Candidates often assume that a rule without `-m state` will not match new connections, but in a rule without any state condition, all states are matched. However, in this scenario the SSH rule already has `-m state --state ESTABLISHED,RELATED`, so it truly does not match NEW packets. The LPIC-2 exam expects you to recognize the necessity of explicitly allowing the NEW state for services that require initial connection setup.

How to eliminate wrong answers

Option A is wrong because the default INPUT policy is not specified in the ruleset; the rules shown are appended to the INPUT chain, and the last rule is an explicit DROP, which is not redundant—it ensures unmatched packets are dropped regardless of the default policy. Option B is wrong because SSH clients connect to destination port 22, not source port 22; the `--dport 22` correctly matches the destination port, and the source port is randomized by the client but does not affect the server-side filtering. Option D is wrong because the established/related rule must come before the SSH rule to allow return traffic for established connections; placing it after would break all established connections, but the reported issue is specifically about new SSH connections being dropped, not established ones.

Practice this question →
23
MCQmedium

A system with SELinux in enforcing mode is running a custom application that needs to write to a file in /data. The application's context type is 'myapp_t', and the target file context is 'default_t'. The file's current context is 'var_t'. Which command changes the file's context to allow access?

A.fixfiles -F relabel /data
B.chcon -t default_t /data/file
C.semanage fcontext -a -t default_t /data/file
D.restorecon /data/file
AnswerB

Directly changes the file's type to default_t.

Why this answer

`chcon -t default_t /data/file` directly changes the SELinux type of the file to `default_t`, which matches the type expected by the `myapp_t` domain's access rules. Since the application runs in enforcing mode and needs to write to a file with type `default_t`, this command immediately sets the correct context without modifying the policy or requiring a relabel.

Exam trap

The trap here is that candidates often confuse `chcon` (immediate context change) with `semanage fcontext` (policy database change) or `restorecon` (reset to policy default), and fail to realize that `chcon` is the only command that directly sets the file's context without requiring a subsequent relabel.

How to eliminate wrong answers

Option A is wrong because `fixfiles -F relabel /data` forces a full relabel of the `/data` directory based on the file contexts stored in the policy, which would restore the file to its original `var_t` type (or whatever is defined in the policy), not change it to `default_t`. Option C is wrong because `semanage fcontext -a -t default_t /data/file` adds a file context mapping to the SELinux policy database, but does not immediately change the file's current context; a subsequent `restorecon` or relabel is required to apply it. Option D is wrong because `restorecon /data/file` resets the file's context to the default type defined in the policy for that path, which is `var_t` (or whatever is specified), not `default_t`.

Practice this question →
24
MCQmedium

Refer to the exhibit. The user 'user' reports that they are able to run 'sudo apt-get update' without a password, but 'sudo apt-get upgrade' prompts for a password. What is the most likely cause?

A.The second rule does not include the NOPASSWD tag, so password is required.
B.The 'Defaults:user !requiretty' setting affects password prompting.
C.The command 'apt-get upgrade' is being run as the user, not as root.
D.The rules are in the wrong order, causing the second to be overridden.
AnswerA

Only the first rule has NOPASSWD; the second rule defaults to password authentication.

Why this answer

The sudoers rule for 'apt-get upgrade' lacks the NOPASSWD tag, so sudo defaults to requiring a password. The first rule for 'apt-get update' includes NOPASSWD, which allows passwordless execution, but each command specification in sudoers is independent unless explicitly grouped. The absence of NOPASSWD on the second rule means sudo will prompt for the user's password as per its default behavior.

Exam trap

The trap here is that candidates assume all commands in a sudoers file inherit the NOPASSWD tag from a previous rule, but sudoers rules are independent and tags apply only to the specific command specification they accompany.

How to eliminate wrong answers

Option B is wrong because 'Defaults:user !requiretty' disables the requirement for a TTY, which affects whether sudo can be run from non-interactive sessions (e.g., scripts), not whether a password is prompted. Option C is wrong because 'sudo apt-get upgrade' explicitly runs the command as root (the default target user), not as the invoking user; the password prompt is unrelated to the effective user identity. Option D is wrong because the order of sudoers rules matters only when two rules conflict (e.g., one grants access and another denies); here both rules grant access, but the second lacks NOPASSWD, so the password requirement is not overridden by the first rule.

Practice this question →
25
MCQhard

Based on the ACL output, which user(s) can write to the file /var/www/html/index.html?

A.Only the user www-data.
B.No one, because the mask is r--.
C.Only root.
D.Any user in the www-data group.
AnswerC

Root has rw- and is not limited by mask.

Why this answer

The ACL output shows that the mask is set to r--, which limits the effective permissions of named users and groups to read-only, regardless of their ACL entries. However, the root user is not subject to ACL restrictions and always has full access to any file, including write permission, making root the only user who can write to the file.

Exam trap

The trap here is that candidates often overlook that the ACL mask applies only to named users and groups, not to root, leading them to incorrectly believe that the mask r-- blocks all write access, including root's.

How to eliminate wrong answers

Option A is wrong because the ACL entry for user www-data grants rw- permissions, but the mask is r--, which masks the write permission, so www-data cannot write. Option B is wrong because the mask r-- does not prevent root from writing; root bypasses all ACL and permission checks. Option D is wrong because the group www-data has an ACL entry of r--, and even if it had rw-, the mask r-- would block write access for any group member.

Practice this question →
26
MCQmedium

An administrator wants to block all incoming traffic from the IP address 203.0.113.55 except for SSH (port 22) using iptables. The current default policy for the INPUT chain is ACCEPT. Which set of commands achieves this?

A.iptables -A INPUT -p tcp --dport 22 -s 203.0.113.55 -j ACCEPT -m; iptables -A INPUT -s 203.0.113.55 -j DROP
B.iptables -A INPUT -s 203.0.113.55 -j DROP; iptables -A INPUT -s 203.0.113.55 -p tcp -j ACCEPT
C.iptables -A INPUT -s 203.0.113.55 -j DROP; iptables -A INPUT -s 203.0.113.55 -p tcp --dport 22 -j ACCEPT
D.iptables -A INPUT -s 203.0.113.55 -p tcp --dport 22 -j ACCEPT; iptables -A INPUT -s 203.0.113.55 -j DROP
AnswerD

First accepts SSH, then drops all other traffic from the IP.

Why this answer

Iptables processes rules in order. The first rule accepts SSH traffic from 203.0.113.55, and the second rule drops all other traffic from that IP. Since the default INPUT policy is ACCEPT, the drop rule must be placed after the SSH allow rule to ensure SSH packets are accepted before being dropped by the subsequent rule.

Exam trap

The trap here is that candidates mistakenly think a drop rule can be placed before an accept rule for the same source, not realizing that iptables stops processing rules after the first match, so the drop rule must come after the specific accept rule.

How to eliminate wrong answers

Option A is wrong because the first command has an invalid '-m' flag without a match module, causing a syntax error; additionally, the order would drop SSH traffic before accepting it if the syntax were corrected. Option B is wrong because the drop rule is placed before the accept rule, so all traffic from 203.0.113.55, including SSH, would be dropped before reaching the accept rule. Option C is wrong because the drop rule is placed first, causing all traffic from 203.0.113.55 to be dropped, and the subsequent accept rule for SSH is never reached.

Practice this question →
27
Multi-Selecteasy

Which TWO files are commonly used to configure PAM authentication for the 'login' service on a Linux system? (Choose two.)

Select 2 answers
A./etc/default/login
B./etc/login.defs
C./etc/pam.conf
D./etc/pam.d/login
E./etc/security/access.conf
AnswersD, E

PAM configuration for the login service.

Why this answer

`/etc/pam.d/login` is the PAM service-specific configuration file for the `login` service on Linux systems that use the modern `pam.d` directory structure. When PAM is invoked for the `login` service, it reads this file to determine which authentication modules to apply, such as `pam_unix.so` for password verification or `pam_securetty.so` for root login restrictions.

Exam trap

The trap here is that candidates may remember /etc/pam.d/login as the primary PAM configuration file for the login service, but they may forget that /etc/security/access.conf is also commonly used to configure PAM authentication via the pam_access module. It is a valid PAM configuration file for access control. The distractor files like /etc/login.defs or /etc/default/login are not PAM configuration files.

Practice this question →
28
MCQhard

An administrator is reviewing the audit rules on a Linux server. The current rules are shown in the exhibit. The administrator needs to ensure that any failed attempts to open files are logged, while also monitoring for successful outbound connections. Which of the following describes the effect of the current rules?

A.The first rule logs only failed openat calls, and the second rule logs all connect calls.
B.The first rule logs only successful openat calls, and the second rule logs only failed connect calls.
C.The first rule logs all openat calls, and the second rule logs all connect calls.
D.The first rule logs only failed openat calls, and the second rule logs only failed connect calls.
AnswerA

The first rule logs failed openat (success=0), the second logs all connect (no success filter).

Why this answer

The first rule uses the `-F exit=-EACCES` filter, which matches only failed `openat` calls (those returning the EACCES error). The second rule uses `-S connect` without an exit filter, so it logs all `connect` syscalls regardless of success or failure. Therefore, option A correctly describes the effect: failed openat calls and all connect calls are logged.

Exam trap

The trap here is that candidates often assume `-S connect` without an exit filter only logs failed connections, but it actually logs all connect syscalls, and they may also overlook that `-F exit=-EACCES` explicitly targets failures, not successes.

How to eliminate wrong answers

Option B is wrong because the first rule logs only failed openat calls, not successful ones; the second rule logs all connect calls, not just failed ones. Option C is wrong because the first rule does not log all openat calls—it specifically filters for failures (exit=-EACCES). Option D is wrong because the second rule logs all connect calls, not only failed ones.

Practice this question →
29
MCQmedium

A user needs to run a specific command as root without being prompted for a password. The command is /usr/bin/systemctl restart apache2. Which sudoers rule accomplishes this securely?

A.user ALL=(root) /usr/bin/systemctl restart apache2
B.user ALL=(root) NOPASSWD: ALL
C.user ALL=(root) NOPASSWD:: /usr/bin/systemctl restart apache2
D.user ALL=(root) NOPASSWD: /usr/bin/systemctl restart apache2
AnswerD

The NOPASSWD tag allows running the specific command without a password.

Why this answer

It uses the NOPASSWD tag before the command specification, allowing the user to execute /usr/bin/systemctl restart apache2 as root without a password prompt. The syntax 'user ALL=(root) NOPASSWD: /usr/bin/systemctl restart apache2' is the proper sudoers format, where the tag applies to the following command list. This grants minimal privilege by restricting the user to only that specific command and arguments.

Exam trap

LPIC-2 often tests the subtle syntax requirement that the NOPASSWD tag must be placed immediately before the command list without an extra colon, and candidates mistakenly add a double colon or omit the tag entirely.

How to eliminate wrong answers

Option A is wrong because it omits the NOPASSWD tag, so the user would still be prompted for a password when running the command. Option B is wrong because it grants unrestricted root access (ALL) with no password, violating the principle of least privilege and creating a severe security risk. Option C is wrong because it contains a syntax error with a double colon 'NOPASSWD::', which is invalid in sudoers and would cause sudo to fail to parse the rule.

Practice this question →
30
Multi-Selecthard

Which THREE conditions must be met for an SSH key-based login to succeed using the default settings on a OpenSSH server? (Choose three.)

Select 3 answers
A.The ~/.ssh directory on the remote server has permissions 0700
B.The remote server has the public key appended to ~/.ssh/authorized_keys
C.The remote server has the host key /etc/ssh/ssh_host_rsa_key
D.The client has the server's public host key stored in ~/.ssh/known_hosts
E.The client has the private key in ~/.ssh/id_rsa
AnswersA, B, E

SSH requires strict permissions on .ssh directory.

Why this answer

OpenSSH requires the ~/.ssh directory on the remote server to have permissions 0700 (owner-only read/write/execute) to prevent other users from modifying its contents. If the directory is group- or world-writable, the server will reject key-based authentication as a security measure against unauthorized key injection.

Exam trap

The trap here is that candidates often confuse host key verification (known_hosts) with user authentication (authorized_keys), or assume the server's host key is a condition for login success, when in fact it is always present and unrelated to the key-based login flow.

Practice this question →
31
MCQmedium

A system administrator needs to ensure that all users must change their passwords every 90 days and that passwords must be at least 12 characters long. The administrator modifies /etc/login.defs and /etc/pam.d/common-password. Which additional step is required to enforce these settings for existing users?

A.Run 'chage -M 90' for each existing user
B.Run 'passwd -x 90' for each existing user
C.Run 'pwconv' to synchronize password aging
D.Run 'pwunconv' then 'pwconv' to update shadow file
AnswerA

chage modifies password aging for existing users.

Why this answer

Modifying /etc/login.defs sets default password aging parameters for new users, and /etc/pam.d/common-password enforces password length via pam_pwquality. However, these changes do not retroactively apply to existing users. The 'chage -M 90' command modifies the /etc/shadow file directly for each user, setting their maximum password age to 90 days.

Option B ('passwd -x 90') is incorrect because it is an incomplete command—'passwd -x' requires a username argument (e.g., 'passwd -x 90 username') and is not the standard tool for bulk policy enforcement. The 'pwconv' command (Option C) synchronizes passwords between /etc/passwd and /etc/shadow, not password aging. Option D ('pwunconv' then 'pwconv') reverts to non-shadow then back to shadow, which would remove existing password ages.

Therefore, the correct additional step is to run 'chage -M 90' for each existing user.

Exam trap

The trap is that candidates assume modifications to /etc/login.defs apply retroactively to existing users, but they only affect new user creations. Therefore, a per-user command like 'chage' is required to enforce the policy on current accounts.

How to eliminate wrong answers

Option B is wrong because 'passwd -x 90' sets the maximum password age for a user, but it only affects the /etc/shadow entry for that user; however, the correct command for this purpose is 'chage -M', and 'passwd -x' is a less common and less portable alternative that is not the standard LPIC-2 recommended method. Option C is wrong because 'pwconv' synchronizes the /etc/passwd and /etc/shadow files, ensuring shadow passwords are in use, but it does not set or modify password aging values. Option D is wrong because 'pwunconv' then 'pwconv' would convert shadow passwords back to /etc/passwd and then back again, which could disrupt password aging fields and is unnecessary; it does not enforce the 90-day aging requirement.

Practice this question →
32
Multi-Selectmedium

Which TWO commands can be used to display the current iptables rules for the filter table?

Select 2 answers
A.iptables -L
B.iptables -S
C.iptables -t filter -L
D.iptables -t nat -L
E.iptables -t mangle -L
AnswersA, C

Correct. `iptables -L` lists the rules in the filter table by default.

Why this answer

`iptables -L` lists the current rules in the default filter table without needing to specify the table explicitly. Option C is correct because `iptables -t filter -L` explicitly selects the filter table and lists its rules, which is functionally equivalent to the default behavior of `iptables -L`.

Exam trap

The trap here is that candidates may confuse `-S` (which outputs rules in a format suitable for saving/restoring) with `-L` (which displays the rules in a readable list), or forget that `-t filter` is the default and assume only `-t filter -L` works.

Practice this question →
33
Multi-Selecteasy

Which TWO commands can be used to list all currently listening TCP ports and the associated processes?

Select 2 answers
A.lsof -i TCP -s TCP:LISTEN
B.ss -tlnp
C.netstat -tlnp
D.fuser -v 80/tcp
E.nmap -sT localhost
AnswersB, C

ss -tlnp shows listening TCP ports with process info.

Why this answer

(ss -tlnp) is correct because the ss command with -t (TCP), -l (listening), -n (numeric), and -p (process) shows all listening TCP ports and their associated processes. Option C (netstat -tlnp) is correct because netstat with the same flags provides equivalent output, though ss is the modern replacement on many distributions.

Exam trap

The trap here is that candidates may think lsof or nmap are valid for listing all listening ports with processes, but lsof requires specific syntax and does not natively filter by listening state without extra flags, while nmap is an active scanner, not a passive listener display tool.

Practice this question →
34
Multi-Selectmedium

Which TWO commands can be used to list currently loaded iptables rules in the filter table? (Choose two.)

Select 2 answers
A.iptables -L -t nat
B.iptables -nL
C.iptables -L -t filter
D.iptables -Z
E.iptables -F
AnswersB, C

Lists rules numerically (default filter table).

Why this answer

`iptables -nL` lists all rules in the default filter table without resolving hostnames (the `-n` flag disables DNS lookups). Option C is correct because `iptables -L -t filter` explicitly specifies the filter table and lists its rules. Both commands display the currently loaded rules in the filter table, which is the default table for iptables.

Exam trap

The trap here is that candidates often forget the default table is the filter table and mistakenly think `-t nat` or `-t mangle` is required, or they confuse listing rules with destructive actions like flushing or zeroing counters.

Practice this question →
35
Multi-Selecthard

Which three PAM modules can be used to enforce password complexity? (Select three.)

Select 3 answers
A.pam_securetty.so
B.pam_passwdqc.so
C.pam_unix.so
D.pam_pwquality.so
E.pam_cracklib.so
AnswersB, D, E

This module enforces password quality and complexity.

Why this answer

pam_passwdqc.so, pam_pwquality.so, and pam_cracklib.so are all PAM modules specifically designed to enforce password complexity policies, such as requiring a mix of character types, minimum length, or rejecting weak passwords. pam_passwdqc.so uses a configurable password quality checking framework, pam_pwquality.so (the successor to pam_cracklib.so) provides similar checks via the libpwquality library, and pam_cracklib.so (the original module) performs dictionary checks and complexity rules. These modules are typically stacked in the password authentication stack to validate new passwords against defined policies.

Exam trap

The trap here is that candidates often confuse pam_unix.so (which handles authentication and password aging) with a password complexity module, but it does not enforce complexity rules itself; the correct modules are the dedicated quality-checking ones (pam_passwdqc.so, pam_pwquality.so, pam_cracklib.so).

Practice this question →
36
MCQmedium

A system administrator notices that the SSH service on a Linux server is failing to start. The log shows: 'sshd: error: Could not load host key: /etc/ssh/ssh_host_rsa_key'. What is the most likely cause and solution?

A.The sshd_config file has a syntax error. Run 'sshd -t' to check it.
B.The SSH service is managed by xinetd and the configuration is missing. Edit /etc/xinetd.d/ssh.
C.The /etc/ssh/sshd_config file has incorrect permissions. Change them to 600.
D.The host key file is missing or corrupt. Run 'ssh-keygen -A' to regenerate all missing host keys.
AnswerD

This regenerates default host keys.

Why this answer

The error message indicates that the SSH daemon cannot load the RSA host key file. Host keys are generated during package installation or manually via ssh-keygen. Option D is correct because running 'ssh-keygen -A' automatically generates all missing host key types (RSA, ECDSA, Ed25519) that are configured for use, resolving the missing or corrupt key issue without manual intervention.

Exam trap

The trap here is that candidates may confuse host key issues with configuration file errors or permissions, but the specific error message directly points to the host key file, not sshd_config, and the correct solution is to regenerate the missing keys rather than editing configuration or checking syntax.

How to eliminate wrong answers

Option A is wrong because a syntax error in sshd_config would produce a different error (e.g., 'sshd: fatal: bad ownership or modes') and 'sshd -t' checks configuration syntax, not host key availability. Option B is wrong because SSH is typically managed as a standalone service via systemd or init scripts, not xinetd; xinetd is used for services like Telnet or TFTP, and SSH over xinetd is extremely rare and not the default. Option C is wrong because the error is about the host key file, not sshd_config; incorrect permissions on sshd_config would cause a different error (e.g., 'bad ownership or modes') and the host key file itself must be 600, but the error message explicitly names the key file, not the config file.

Practice this question →
37
MCQhard

A security audit reveals that the /var/log directory contains world-readable log files that may contain sensitive information. The administrator wants to ensure new files created in /var/log are not readable by others, without affecting existing file permissions. Which umask value should be set system-wide?

A.umask 027
B.umask 022
C.umask 077
D.umask 026
AnswerD

Results in default file permissions 640 (rw-r-----).

Why this answer

(umask 026) is correct because it sets the default permissions for new files to 640 (rw-r-----), which removes read access for 'others' while preserving read access for group members. The umask value is subtracted from the base permissions (666 for files), so a umask of 026 results in 666 - 026 = 640, meeting the requirement that new files in /var/log are not world-readable without altering existing file permissions.

Exam trap

The trap here is that candidates often choose umask 027 (option A) thinking it provides better security, but they overlook that it removes group read access, which can break legitimate log-reading processes, while the correct answer 026 preserves group read access and only removes world-read access.

How to eliminate wrong answers

Option A (umask 027) is wrong because it results in file permissions of 640 (rw-r-----), which also removes world-read access, but it additionally removes group read access (since 027 subtracts group write and execute, but for files the execute bit is not set by default, so group read is removed). This is more restrictive than needed and may break legitimate group access required for log reading by system utilities. Option B (umask 022) is wrong because it results in file permissions of 644 (rw-r--r--), which leaves files world-readable, directly failing the audit requirement.

Option C (umask 077) is wrong because it results in file permissions of 600 (rw-------), which removes all group and other access, potentially breaking system services that need group read access to log files (e.g., syslog or monitoring tools).

Practice this question →
38
MCQeasy

An administrator uses logwatch to send daily summaries to root. Which configuration file controls the default logwatch behavior?

A./etc/logwatch.conf
B./etc/logwatch/conf/logwatch.conf
C./usr/share/logwatch/default.conf
D./etc/logwatch/logwatch.conf
AnswerB

This is the main configuration file for logwatch.

Why this answer

Logwatch uses a modular configuration system where the main configuration file is located at /etc/logwatch/conf/logwatch.conf. This file overrides the default settings found in /usr/share/logwatch/default.conf/logwatch.conf, allowing administrators to customize logwatch behavior without modifying the distribution's default files.

Exam trap

The trap here is that candidates often assume the main configuration file is directly in /etc/ (like /etc/logwatch.conf) or in a flat /etc/logwatch/ directory, but LPIC-2 tests knowledge of the specific subdirectory structure used by logwatch's modular configuration system.

How to eliminate wrong answers

Option A is wrong because /etc/logwatch.conf is not the standard path; logwatch expects its configuration files under the /etc/logwatch/conf/ directory. Option C is wrong because /usr/share/logwatch/default.conf contains the default configuration shipped with the package, but it is not the file that controls runtime behavior — the override file in /etc/logwatch/conf/ takes precedence. Option D is wrong because /etc/logwatch/logwatch.conf does not exist; the correct path includes the 'conf' subdirectory.

Practice this question →
39
MCQhard

A PAM configuration file for password authentication includes the line 'password requisite pam_cracklib.so retry=3 minlen=8'. A user tries to change their password but is rejected even though the new password meets the stated criteria. The administrator suspects a conflict with another PAM module. Which of the following is the most likely cause?

A.Another PAM module such as pam_pwhistory.so might be configured to prevent reuse of old passwords, causing rejection even though pam_cracklib passes.
B.The 'retry=3' option limits attempts, but the password is only tried once.
C.The 'requisite' control flag causes immediate failure if pam_cracklib fails, but another module might be overriding.
D.The 'minlen=8' option requires exactly 8 characters, not at least 8.
AnswerA

pam_pwhistory checks the password against a history file; if the new password matches an old one, it fails.

Why this answer

Pam_pwhistory.so is commonly used to enforce password history, preventing reuse of recent passwords. Even if pam_cracklib.so accepts the new password as meeting complexity and length requirements, pam_pwhistory.so can reject it if it matches a previously used password, leading to the observed failure.

Exam trap

The trap here is that candidates assume pam_cracklib is the sole arbiter of password validity, overlooking that PAM modules are evaluated sequentially and any module can reject the password independently, especially history-checking modules like pam_pwhistory.

How to eliminate wrong answers

Option B is wrong because the 'retry=3' option allows up to three attempts to enter a valid password, not a single attempt; the user's password is tried once per attempt, but the module gives multiple chances. Option C is wrong because the 'requisite' control flag does cause immediate failure if pam_cracklib fails, but it does not allow another module to override a failure; if pam_cracklib passes, subsequent modules can still reject the password independently. Option D is wrong because 'minlen=8' specifies the minimum password length, not an exact length; passwords longer than 8 characters are accepted.

Practice this question →
40
MCQhard

A company runs a web application on a Linux server that uses Apache, MySQL, and PHP. The application stores sensitive user data in a MySQL database. The security team has detected that the MySQL service is listening on port 3306 on all interfaces (0.0.0.0). The application and database are on the same server, so there is no need for remote database access. The administrator must secure the MySQL service without breaking the application. Which of the following is the most appropriate course of action?

A.Edit the MySQL configuration file (my.cnf) and set bind-address = 127.0.0.1, then restart the MySQL service.
B.Change the MySQL default port to a non-standard port to avoid automated scans.
C.Disable the MySQL network entirely by commenting out the 'skip-networking' directive in my.cnf.
D.Use iptables to add a rule dropping incoming packets to port 3306 from all IPs except 127.0.0.1.
AnswerA

This restricts MySQL to listen only on localhost, preventing remote connections.

Why this answer

Setting bind-address = 127.0.0.1 in the MySQL configuration file (my.cnf) instructs the MySQL server to listen only on the loopback interface, which prevents remote connections while still allowing local applications (Apache/PHP) to connect via the local socket or TCP to 127.0.0.1. This directly addresses the security concern of exposing the database on all interfaces without breaking the application, as the application and database reside on the same server.

Exam trap

The trap here is that candidates may confuse 'skip-networking' with disabling networking (option C) or think that changing the port (option B) is sufficient security, when in fact the core issue is the binding to all interfaces, which is directly solved by the bind-address directive.

How to eliminate wrong answers

Option B is wrong because changing the default port to a non-standard port does not prevent the service from listening on all interfaces; it only obscures the port from automated scans, but the service remains reachable from any network interface, which does not eliminate the remote access risk. Option C is wrong because commenting out the 'skip-networking' directive actually enables networking (the directive is typically set to disable networking), and disabling networking entirely would break the application if it relies on TCP connections to MySQL (e.g., via PHP's mysqli or PDO using 'localhost' which may default to TCP). Option D is wrong because while iptables can block incoming packets to port 3306 from non-loopback sources, this approach is less reliable and more complex than the configuration-based solution; it can be bypassed if iptables is not loaded or if rules are misordered, and it does not prevent MySQL from binding to all interfaces, which may still expose the service in certain network contexts (e.g., containers or virtual interfaces).

Practice this question →
41
MCQeasy

An administrator wants to encrypt a file so that only a specific recipient can decrypt it. Which GPG command should be used?

A.gpg --encrypt --recipient key-id file
B.gpg --symmetric file
C.gpg --clearsign file
D.gpg --sign file
AnswerA

This encrypts the file for the specified recipient's public key.

Why this answer

The `--encrypt` flag with `--recipient key-id` uses the recipient's public key to encrypt the file, ensuring that only the holder of the corresponding private key can decrypt it. This is the standard asymmetric encryption workflow in GPG for targeted confidentiality.

Exam trap

The trap here is that candidates confuse `--symmetric` (shared passphrase) with `--encrypt --recipient` (public-key encryption), or assume that signing (`--sign` or `--clearsign`) provides confidentiality when it only provides authentication and integrity.

How to eliminate wrong answers

Option B is wrong because `--symmetric` uses a single shared passphrase (symmetric encryption) rather than a recipient's public key, so it does not restrict decryption to a specific individual. Option C is wrong because `--clearsign` creates a cleartext signature (signed plaintext) without encrypting the file, so it provides authentication but no confidentiality. Option D is wrong because `--sign` only creates a binary signature, leaving the file unencrypted and readable by anyone.

Practice this question →
42
Multi-Selecthard

Which THREE of the following are valid methods to restrict access to the su command on a Linux system?

Select 3 answers
A.Set the SU_WHEEL_ONLY variable in /etc/login.defs.
B.Modify /etc/shells to include only approved shells.
C.Configure sudoers to allow only specific users to run su.
D.Edit the /etc/suauth file to specify allowed users.
E.Add the user to the 'wheel' group and configure pam_wheel.so in /etc/pam.d/su.
AnswersA, D, E

Correct. Setting SU_WHEEL_ONLY=yes in /etc/login.defs restricts su to members of the wheel group.

Why this answer

Options A, D, and E are all valid methods to restrict access to the su command. Option A is correct: setting SU_WHEEL_ONLY to 'yes' in /etc/login.defs restricts su to members of the wheel group. Option D is correct because /etc/suauth allows specifying allowed users or groups.

Option E is correct because pam_wheel.so in /etc/pam.d/su restricts access to wheel group members. Options B and C are incorrect: /etc/shells controls allowed shells for chsh, not su, and configuring sudoers allows running su via sudo but does not restrict the su command itself.

Exam trap

LPI often tests the misconception that /etc/login.defs or /etc/shells can restrict su, when in reality these files serve different purposes (login defaults and shell validation) and are not used for su access control.

Practice this question →
43
MCQmedium

A system administrator wants to allow the user 'jdoe' to run the '/usr/bin/systemctl restart httpd' command on a specific server without a password prompt. Which sudoers entry achieves this?

A.jdoe ALL=(ALL) /usr/bin/systemctl restart httpd
B.jdoe ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart httpd
C.user ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart httpd
D.jdoe ALL=(ALL) ALL
AnswerB

Grants passwordless execution of the specific command.

Why this answer

The NOPASSWD tag in the sudoers entry explicitly allows user 'jdoe' to execute the specified command '/usr/bin/systemctl restart httpd' without being prompted for a password. The syntax 'jdoe ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart httpd' grants passwordless execution for that exact command on any host, which matches the requirement.

Exam trap

The trap here is that candidates often forget the NOPASSWD tag and select option A, assuming that any sudo entry allows passwordless execution, or they confuse the username placeholder 'user' with the actual username in option C.

How to eliminate wrong answers

Option A is wrong because it omits the NOPASSWD tag, so sudo would still prompt for a password before executing the command. Option C is wrong because it specifies 'user' instead of the actual username 'jdoe', which would not apply to the intended user. Option D is wrong because it grants full root privileges (ALL commands) to jdoe, which is overly permissive and does not restrict execution to only the httpd restart command.

Practice this question →
44
MCQhard

A company runs an Apache web server (port 80) and an SSH server (port 22) for remote administration. The system administrator notices that the server has become sluggish and network traffic has increased significantly. Checking /var/log/auth.log reveals hundreds of failed SSH authentication attempts per minute from diverse IP addresses targeting the 'admin' user. The administrator wants to mitigate this brute-force attack with minimal impact on legitimate users. Which course of action is most effective?

A.Change the SSH port to a non-standard port number.
B.Disable password authentication for SSH and use key-based authentication only.
C.Add the offending IP addresses to /etc/hosts.deny manually.
D.Install and configure fail2ban to block IP addresses after 5 failed SSH attempts within 10 minutes.
AnswerD

fail2ban dynamically blocks offending IPs, reducing attack surface while allowing legitimate users who might mistype credentials.

Why this answer

Fail2ban is specifically designed to mitigate brute-force attacks by monitoring log files (e.g., /var/log/auth.log) for repeated failed authentication attempts and dynamically updating firewall rules (e.g., iptables or nftables) to block offending IP addresses. This approach is automated, reduces manual intervention, and has minimal impact on legitimate users since only IPs exceeding the threshold are blocked.

Exam trap

The trap here is that candidates often choose Option A (changing the SSH port) as a quick fix, mistaking obscurity for effective security, or Option B (disabling password auth) as a permanent solution, without recognizing that the immediate goal is to stop the ongoing attack with minimal disruption, which fail2ban achieves through automated, dynamic blocking.

How to eliminate wrong answers

Option A is wrong because changing the SSH port to a non-standard number only obscures the service and does not prevent attackers from scanning all ports; it provides security through obscurity, which is not a robust defense against targeted brute-force attacks. Option B is wrong because while disabling password authentication and using key-based authentication is a strong security measure, it does not address the immediate issue of network traffic increase and server sluggishness caused by the ongoing brute-force attempts; it is a long-term hardening step, not a mitigation for the current attack. Option C is wrong because manually adding offending IP addresses to /etc/hosts.deny is impractical given hundreds of IPs per minute, and hosts.deny works with TCP wrappers, which may not be used by all services (e.g., SSH compiled without libwrap support) and does not scale to dynamic attacks.

Practice this question →
45
MCQeasy

A user's SSH public key has been added to '~/.ssh/authorized_keys' on a remote server, but the user is still prompted for a password. Which file permission is most likely causing the issue?

A.0660
B.0644
C.0444
D.0600
AnswerA

Group writable; SSH rejects group-writable authorized_keys.

Why this answer

SSH's authorized_keys file must have strict permissions to prevent unauthorized modifications. The correct permission is 0600 (owner read/write only) or more restrictive. Permission 0660 (group read/write) is too permissive because it allows group members to modify the file, which SSH interprets as a security risk and falls back to password authentication.

Exam trap

The trap here is that candidates assume 0600 is too restrictive and pick a more permissive option like 0644 or 0660, not realizing that SSH requires the file to be owned by the user and writable only by that user.

How to eliminate wrong answers

Option B (0644) is wrong because it allows world-read access, which is insecure and will cause SSH to ignore the file. Option C (0444) is wrong because it is read-only for all, but SSH requires the file to be writable only by the owner; read-only for owner also triggers the fallback. Option D (0600) is wrong because this is the correct permission for authorized_keys and would not cause a password prompt.

Practice this question →
46
MCQmedium

An application running under AppArmor is failing to write to its log directory. The AppArmor profile for the application includes the line '/var/log/myapp/ r,' but not '/var/log/myapp/** rw,'. What is the most likely issue?

A.The directory itself is not created, and AppArmor prevents creation.
B.The 'r' permission only allows read, but write is required.
C.The AppArmor service is not running, so the profile is not enforced.
D.The profile needs 'ix' instead of 'r' for execute rights.
AnswerB

The profile grants read access to the directory, but write access to files requires rw permissions on the directory contents.

Why this answer

The AppArmor profile line '/var/log/myapp/ r,' grants only read permission on the directory itself, not write access to files within it. To allow writing to files in the directory, the profile must include a rule like '/var/log/myapp/** rw,' which grants read and write permissions recursively. Without write permission, the application cannot create or modify log files, causing the failure.

Exam trap

The trap here is that candidates may think the 'r' permission on a directory implies write access to files within it, but AppArmor requires explicit recursive rules with 'w' for file creation and modification.

How to eliminate wrong answers

Option A is wrong because AppArmor does not prevent directory creation; the 'r' permission on the directory allows listing its contents, but the missing write permission on files is the issue. Option C is wrong because if the AppArmor service were not running, the profile would not be enforced, and the application would likely succeed in writing; the question implies the profile is active. Option D is wrong because 'ix' is used for execute permissions with inheritance, which is unrelated to file write operations; write requires 'w' permission.

Practice this question →
47
MCQeasy

A small business has a single Linux server that serves as both a file server (Samba) and a web server (Apache). The server is directly connected to the internet. Recently, there have been numerous brute-force SSH login attempts. The administrator wants to implement a simple solution to block IP addresses that have more than 5 failed SSH attempts in 10 minutes. The server runs Ubuntu 20.04. Which tool should the administrator use to achieve this with minimal configuration?

A.Enable UFW and set default deny incoming, allow SSH from specific IPs.
B.Install and configure Fail2ban to monitor /var/log/auth.log.
C.Set up TCP wrappers with /etc/hosts.deny for SSH.
D.Use port knocking to hide SSH port until a specific sequence is sent.
AnswerB

Fail2ban can ban IPs after a configurable number of failed attempts.

Why this answer

Fail2ban is the correct tool because it is specifically designed to monitor log files (e.g., /var/log/auth.log) for repeated failed authentication attempts and dynamically update firewall rules (via iptables or nftables) to block offending IP addresses. It requires minimal configuration: a default SSH jail is provided out-of-the-box, and the administrator only needs to adjust the `maxretry` and `findtime` parameters to match the requirement of 5 failures in 10 minutes.

Exam trap

The trap here is that candidates may choose UFW (Option A) because it is a common firewall tool, but they overlook that UFW alone cannot dynamically detect and respond to failed login attempts without additional scripting or integration with Fail2ban.

How to eliminate wrong answers

Option A is wrong because UFW with default deny incoming and allowing SSH from specific IPs is a static access control approach that does not dynamically block IPs based on failed login attempts; it requires manual whitelisting and cannot adapt to brute-force attacks. Option C is wrong because TCP wrappers (hosts.deny/hosts.allow) only control access at the application layer for services compiled with libwrap, and they do not monitor login failures or automatically update rules based on failed attempts. Option D is wrong because port knocking hides the SSH port until a correct sequence of connection attempts is sent, but it does not track or block IPs based on failed SSH authentication attempts; it only obscures the port, not prevent brute-force attacks after the port is revealed.

Practice this question →
48
MCQmedium

A company's security policy requires that all members of the 'developers' group be able to run the command 'systemctl restart httpd' as root using sudo, without being prompted for a password. Which sudoers entry achieves this?

A.%developers ALL=(root) /usr/bin/systemctl restart httpd
B.%developers ALL=(root) NOPASSWD: /usr/bin/systemctl restart httpd
C.developers ALL=(root) NOPASSWD: /usr/bin/systemctl restart httpd
D.%developers ALL=(root) NOPASSWD: {/usr/bin/systemctl restart httpd}
E.%developers ALL=(0) NOPASSWD: /usr/bin/systemctl restart httpd
AnswerB

Correct syntax: group, hosts, runas, NOPASSWD, command.

Why this answer

It uses the %group syntax to specify the 'developers' group, includes the NOPASSWD: tag to suppress password prompting, and specifies the exact command path and arguments (/usr/bin/systemctl restart httpd) as required by the sudoers policy. This matches the security requirement precisely.

Exam trap

The trap here is that candidates often forget the '%' prefix for groups or omit the NOPASSWD: tag, mistakenly thinking the default behavior already suppresses passwords, or they use invalid syntax like curly braces or numeric UIDs without the proper '#' prefix.

How to eliminate wrong answers

Option A is wrong because it omits the NOPASSWD: tag, so members would still be prompted for a password. Option C is wrong because it uses 'developers' without the leading '%', which refers to a user named 'developers' rather than the group. Option D is wrong because it wraps the command in curly braces {}, which is not valid sudoers syntax and would cause a syntax error.

Option E is wrong because it uses '(0)' instead of '(root)'; while root's UID is 0, sudoers expects a username or a properly quoted numeric UID with the '#' prefix (e.g., (#0)), and '(0)' is not a valid target user specification.

Practice this question →
49
Multi-Selecteasy

Which two of the following are valid methods to authenticate with OpenVPN? (Select two.)

Select 2 answers
A.LDAP
B.RADIUS
C.NIS
D.Static key
E.TLS/SSL certificates
AnswersD, E

Static key authentication uses a pre-shared key between client and server.

Why this answer

OpenVPN supports static key authentication (option D) as a simple pre-shared secret method where both client and server use the same key to encrypt and authenticate traffic. This is valid but less secure than certificate-based methods, as it lacks perfect forward secrecy and individual revocation capabilities.

Exam trap

The trap here is that candidates confuse external authentication integrations (like LDAP or RADIUS) with OpenVPN's native authentication methods, which are strictly static key and TLS/SSL certificates as defined in its core protocol.

Practice this question →
50
MCQhard

An AppArmor profile for a database server is too restrictive and denies legitimate queries. The administrator wants to learn the required accesses by running the application in complain mode. Which command puts the profile into complain mode?

A.aa-complain /etc/apparmor.d/usr.sbin.mysqld
B.aa-disable /etc/apparmor.d/usr.sbin.mysqld
C.aa-enforce /etc/apparmor.d/usr.sbin.mysqld
D.aa-log /etc/apparmor.d/usr.sbin.mysqld
AnswerA

Puts the profile in complain mode, logging violations without blocking.

Why this answer

The `aa-complain` command places an AppArmor profile into complain mode, where policy violations are logged but not blocked. This allows the administrator to run the database server and observe which accesses are denied, then use the logs to update the profile with the required permissions. The correct syntax is `aa-complain /etc/apparmor.d/usr.sbin.mysqld` to target the specific profile file.

Exam trap

The trap here is confusing `aa-complain` with `aa-logprof` or `aa-disable`, as candidates may think disabling the profile is the safest way to learn accesses, but complain mode is specifically designed for this purpose without removing all security.

How to eliminate wrong answers

Option B is wrong because `aa-disable` completely disables the AppArmor profile, removing all confinement and logging, which does not help learn required accesses. Option C is wrong because `aa-enforce` puts the profile into enforce mode, which actively blocks denied operations, the opposite of what is needed for learning. Option D is wrong because `aa-log` is not a valid AppArmor command; AppArmor uses `aa-logprof` to analyze logs, but that is for reviewing denials after running in complain mode, not for setting the mode itself.

Practice this question →
51
MCQmedium

Based on the iptables output, what is the expected behavior for incoming SSH connections on eth0?

A.SSH connections are only allowed if they are part of an established connection.
B.SSH connections from any source to port 22 on eth0 are allowed if they are new.
C.SSH connections are dropped because the default policy is DROP.
D.SSH connections are only allowed from the loopback interface.
AnswerB

The rule matches new SSH connections on eth0.

Why this answer

The iptables output shows a rule on the INPUT chain for eth0 that accepts TCP packets destined for port 22 (SSH) with the state NEW. This means that any incoming SSH connection attempt (SYN packet) that is not part of an existing connection is explicitly allowed. The default policy for the INPUT chain is ACCEPT (not shown as DROP), so even without this rule, SSH would be allowed, but the rule ensures it is explicitly permitted for new connections.

Exam trap

The trap here is that candidates may assume the default policy is DROP (a common security practice) and overlook the explicit ACCEPT rule for NEW SSH connections, or they may confuse the NEW state with ESTABLISHED, thinking that only existing connections are allowed.

How to eliminate wrong answers

Option A is wrong because the rule specifically matches the NEW state, not ESTABLISHED; established connections are handled by a separate rule (not shown) or the default policy. Option C is wrong because the default policy is ACCEPT (as indicated by the chain policy being ACCEPT in the output), not DROP, so SSH connections are not dropped by default. Option D is wrong because the rule applies to eth0, not the loopback interface (lo); there is no restriction to loopback, and SSH on eth0 is explicitly allowed.

Practice this question →
52
MCQmedium

An administrator wants to allow user 'john' to execute any command as root without a password. Which sudoers entry is correct?

A.john ALL=(ALL) NOPASSWD:ALL
B.john ALL=(ALL) NOPASSWD:/bin/ls
C.john ALL=(ALL) ALL
D.john ALL=(ALL) PASSWD:ALL
AnswerA

This allows john to run any command as any user without a password.

Why this answer

The sudoers entry 'john ALL=(ALL) NOPASSWD:ALL' grants user 'john' permission to run any command as any user (including root) on any host, and the 'NOPASSWD' tag overrides the default password requirement, allowing execution without a password. The syntax follows the sudoers format: 'user host=(runas) TAG:command', where 'ALL' in each field matches any value.

Exam trap

The trap here is that candidates often confuse the 'ALL' in the command specification with the 'ALL' in the host or runas fields, or forget that omitting 'NOPASSWD' defaults to requiring a password, leading them to choose option C.

How to eliminate wrong answers

Option B is wrong because it restricts john to only the '/bin/ls' command, not 'any command' as required. Option C is wrong because it lacks the 'NOPASSWD' tag, so john would still be prompted for a password when executing commands as root. Option D is wrong because 'PASSWD:ALL' explicitly requires a password (which is the default behavior), and the 'PASSWD' tag is redundant here; it does not grant passwordless execution.

Practice this question →
53
MCQmedium

Refer to the exhibit. A security audit reveals that the server is not blocking SSH connections from unauthorized networks. What is the most likely cause?

A.The FORWARD chain is DROP, blocking all forwarded traffic.
B.The SSH rule uses --dport 22 but missing source IP restriction, allowing all sources.
C.The default policy for INPUT is DROP, which should block all, but SSH works due to the ESTABLISHED,RELATED rule.
D.The SSH rule does not restrict source IP, so it allows all incoming SSH connections.
AnswerD

Without a source IP limitation, the rule permits SSH from any IP address.

Why this answer

The SSH rule in the exhibit uses `--dport 22` without any `-s` or `--source` parameter to restrict the source IP address. This means the rule matches any incoming TCP packet destined for port 22, regardless of its origin network. Without a source IP restriction, the firewall allows SSH connections from all networks, including unauthorized ones, which is the security issue identified by the audit.

Exam trap

The trap here is that candidates may confuse the FORWARD chain with the INPUT chain, or mistakenly think that a default DROP policy on INPUT combined with an ESTABLISHED,RELATED rule would somehow allow new SSH connections, when in fact the ESTABLISHED,RELATED rule only permits packets that are part of an already tracked connection.

How to eliminate wrong answers

Option A is wrong because the FORWARD chain controls traffic routed through the server, not traffic destined to the server itself; SSH connections to the server are handled by the INPUT chain, so a DROP policy on FORWARD has no effect on incoming SSH. Option B is wrong because it states the SSH rule is missing source IP restriction, which is actually the correct diagnosis (same as D), but the answer choice is labeled as incorrect in the question; the correct answer is D, not B. Option C is wrong because if the default policy for INPUT is DROP, then all incoming traffic would be blocked by default, and the ESTABLISHED,RELATED rule only permits return traffic for already established connections, not new SSH connections; thus SSH would not work at all under that default policy.

Practice this question →
54
MCQmedium

A company requires two-factor authentication for SSH logins. Which PAM module can be used to implement this if the system uses a time-based one-time password (TOTP)?

A.pam_radius.so
B.pam_ldap.so
C.pam_krb5.so
D.pam_google_authenticator.so
AnswerD

This module provides TOTP-based two-factor authentication.

Why this answer

`pam_google_authenticator.so` is a PAM module specifically designed to implement time-based one-time password (TOTP) authentication as defined in RFC 6238. It integrates with SSH by requiring users to provide a six-digit code generated by the Google Authenticator app (or compatible TOTP client) in addition to their regular password, enabling two-factor authentication.

Exam trap

The trap here is that candidates may confuse generic authentication modules (like pam_radius.so or pam_ldap.so) with the specific TOTP module, or assume that any module supporting two-factor authentication (e.g., via RADIUS with tokens) is equivalent to the direct TOTP implementation provided by pam_google_authenticator.so.

How to eliminate wrong answers

Option A is wrong because `pam_radius.so` is used for RADIUS-based authentication, which can support two-factor authentication but is not a TOTP-specific module; it relies on an external RADIUS server (e.g., with token support) rather than implementing TOTP directly on the system. Option B is wrong because `pam_ldap.so` authenticates against an LDAP directory (e.g., OpenLDAP or Active Directory) and does not provide any one-time password or TOTP functionality. Option C is wrong because `pam_krb5.so` implements Kerberos authentication, which uses tickets and symmetric-key cryptography, not time-based one-time passwords.

Practice this question →
55
Multi-Selecteasy

Which TWO of the following actions are recommended to improve SSH server security?

Select 2 answers
A.PermitEmptyPasswords no
B.PasswordAuthentication no
C.AllowUsers *.example.com
D.PermitRootLogin yes
E.UsePAM yes
AnswersA, B

Preventing empty passwords eliminates a major vulnerability where an account could have no password set.

Why this answer

Setting `PermitEmptyPasswords no` in `/etc/ssh/sshd_config` explicitly disallows login attempts with empty passwords, closing a trivial authentication bypass vector. This directive is enforced by the SSH daemon before any PAM or password verification occurs, making it a fundamental hardening step.

Exam trap

The trap here is that candidates often confuse `PermitEmptyPasswords` with `PasswordAuthentication`, thinking only one is needed, or they mistakenly believe that `AllowUsers` supports wildcard patterns like shell globs, when in fact it only matches exact user names or user@host combinations.

Practice this question →
56
MCQhard

A security audit reveals that a server with PAM authentication allows users to log in even when the '/etc/nologin' file exists, contrary to policy. Which PAM module is most likely misconfigured or missing?

A.pam_nologin.so
B.pam_securetty.so
C.pam_access.so
D.pam_lastlog.so
AnswerA

Denies login if /etc/nologin exists.

Why this answer

The pam_nologin.so module is specifically designed to check for the existence of /etc/nologin and, if found, prevent non-root users from logging in. If users can still log in despite this file existing, the module is either missing from the PAM stack (e.g., not included in /etc/pam.d/login or /etc/pam.d/sshd) or misconfigured (e.g., placed after the authentication phase instead of the account phase).

Exam trap

The trap here is that candidates confuse pam_nologin.so with pam_securetty.so, assuming both restrict login based on a file, but pam_securetty.so only applies to root and /etc/securetty, not to general user access via /etc/nologin.

How to eliminate wrong answers

Option B (pam_securetty.so) is wrong because it restricts root logins to terminals listed in /etc/securetty, not to the /etc/nologin file. Option C (pam_access.so) is wrong because it controls access based on rules in /etc/security/access.conf, not the /etc/nologin file. Option D (pam_lastlog.so) is wrong because it records login timestamps and displays the last login message, and has no role in denying access based on /etc/nologin.

Practice this question →
57
MCQmedium

You are the security administrator for a company that runs a web application on a Linux server. The application runs under the user 'www-data' and listens on TCP port 8080. The server also runs an SSH service on port 22. Recently, an external penetration test revealed that an attacker could exploit a vulnerability in the web application to execute commands as the 'www-data' user, and from there, the attacker could escalate privileges to root due to a misconfigured sudo rule. You need to implement a defense-in-depth approach to limit the impact of such an attack. Which single action would be the most effective in preventing privilege escalation from the 'www-data' user to root, while still allowing the application to function normally?

A.Review and remove any sudo privileges granted to the 'www-data' user in /etc/sudoers, and ensure the application does not require sudo.
B.Change the SSH port to a non-standard port to reduce the attack surface.
C.Run the web application in a chroot jail to isolate it from the rest of the filesystem.
D.Implement mandatory access control with AppArmor profiles for the web application.
AnswerA

Directly eliminates the escalation path.

Why this answer

The core issue is a misconfigured sudo rule that allows the 'www-data' user to execute commands as root. By reviewing and removing any sudo privileges for 'www-data' in /etc/sudoers, you directly eliminate the privilege escalation path without affecting the web application's normal operation, as the application itself does not require sudo to function on its designated port 8080.

Exam trap

The trap here is that candidates often choose AppArmor or chroot as a general security measure, overlooking that the specific vulnerability is a misconfigured sudo rule, which must be fixed directly to prevent privilege escalation.

How to eliminate wrong answers

Option B is wrong because changing the SSH port to a non-standard port only obscures the service from casual scans but does not prevent privilege escalation from the compromised 'www-data' user; the attacker can still connect via SSH if credentials are compromised or use other lateral movement techniques. Option C is wrong because running the web application in a chroot jail can limit filesystem access but does not prevent the 'www-data' user from using sudo if a misconfigured sudo rule exists, as chroot does not restrict process capabilities or sudo execution. Option D is wrong because implementing AppArmor profiles can confine the web application's behavior and system calls, but it does not directly address the misconfigured sudo rule; an attacker could still execute 'sudo' commands if the rule is present, as AppArmor typically does not restrict sudo execution unless specifically profiled.

Practice this question →
58
Multi-Selectmedium

Which TWO of the following are recommended best practices for securing a Linux server that is publicly accessible?

Select 2 answers
A.Run all services with root privileges.
B.Set all user passwords to simple, memorable ones.
C.Use a firewall to restrict access to only necessary ports.
D.Enable NFS exports for file sharing.
E.Disable direct root login via SSH.
AnswersC, E

Reduces the attack surface by limiting exposed services.

Why this answer

A firewall (e.g., iptables, nftables, or ufw) restricts inbound traffic to only necessary ports (e.g., 22/TCP for SSH, 80/TCP for HTTP, 443/TCP for HTTPS), reducing the attack surface by blocking unused services. This is a fundamental defense-in-depth practice for publicly accessible servers. Option E is correct because disabling direct root login via SSH (by setting PermitRootLogin no in /etc/ssh/sshd_config) forces users to authenticate with a regular account and then escalate privileges (e.g., via su or sudo), which adds an additional layer of security by preventing brute-force attacks directly against the root account.

Options A, B, and D are incorrect: running services with root privileges (A) increases the risk of privilege escalation if a service is compromised; setting simple passwords (B) weakens authentication; and enabling NFS exports (D) on a public server exposes filesystems without adequate encryption or access control, which is a severe security risk.

Exam trap

The trap here is that candidates may think enabling NFS exports (Option D) is a standard file-sharing practice, but on a publicly accessible server, it introduces severe security risks (e.g., no encryption, easy port scanning) and is explicitly discouraged in LPIC-2 security guidelines.

Practice this question →
59
MCQmedium

A company runs a critical database server on a Linux system. The server is subject to a strict compliance policy that requires all commands executed by the database administrator (user 'dbadmin') to be logged. Additionally, any attempt to change the system time must be logged regardless of the user. The administrator has configured auditd and added the following rules: -w /usr/bin -p x -k binary_exec, -a always,exit -F arch=b64 -S adjtimex -F key=time_change. However, during a compliance audit, it is discovered that not all commands executed by dbadmin are being logged. Which of the following is the most likely cause?

A.The auditd logs are being overwritten because the audit log file size is too small.
B.The auditd service is not running because the kernel was not compiled with audit support.
C.The adjtimex syscall rule is incorrect and prevents other rules from being processed.
D.The rule -w /usr/bin -p x only monitors executables in /usr/bin, not commands in other directories or built-in shell commands.
AnswerD

The rule only watches /usr/bin; dbadmin may run commands from elsewhere.

Why this answer

The rule `-w /usr/bin -p x` only monitors execution of binaries located in `/usr/bin`. Commands executed from other directories (e.g., `/usr/local/bin`, `/opt`, or built-in shell commands like `cd` or `alias`) are not captured. Additionally, the rule does not log commands run via absolute paths outside `/usr/bin` or scripts executed by interpreters, leaving gaps in the audit trail for dbadmin's activities.

Exam trap

The trap here is that candidates assume `-w /usr/bin -p x` logs all command executions, but it only monitors file access events on that specific directory, missing commands from other paths or shell internals.

How to eliminate wrong answers

Option A is wrong because log file size or overwriting would cause missing older logs, not a failure to log specific commands; auditd continues to log new events regardless of rotation. Option B is wrong because if the kernel lacked audit support, auditd would fail to start entirely and no rules would be processed, but the question states that some logging (e.g., time changes) is occurring, proving audit is functional. Option C is wrong because the adjtimex syscall rule is syntactically correct and does not prevent other rules from being processed; auditd rules are independent and do not block each other.

Practice this question →
60
MCQmedium

Your company runs a web application on a Linux server that uses Apache HTTPD with mod_ssl for HTTPS. Recently, after a security audit, it was discovered that the server is vulnerable to the POODLE attack on SSLv3. The server is running RHEL 8 with Apache 2.4. The SSL configuration file /etc/httpd/conf.d/ssl.conf currently has the line 'SSLProtocol all -SSLv2'. You need to disable SSLv3 and also disable all versions of TLS below 1.2, while still allowing TLS 1.2 and 1.3. The server must remain available immediately. Which action should you take?

A.Change 'SSLProtocol all -SSLv2' to 'SSLProtocol all -SSLv2 -SSLv3'
B.Add 'SSLProtocol -SSLv3' after the existing line
C.Change 'SSLProtocol all -SSLv2' to 'SSLProtocol TLSv1.2 TLSv1.3'
D.Change the line to 'SSLProtocol TLSv1.2 TLSv1.3 -SSLv2 -SSLv3'
AnswerC

This explicitly enables only TLS 1.2 and 1.3, disabling all older protocols.

Why this answer

The directive 'SSLProtocol TLSv1.2 TLSv1.3' explicitly enables only TLS 1.2 and TLS 1.3, thereby disabling SSLv3 and all TLS versions below 1.2 (i.e., TLS 1.0 and TLS 1.1). This directly addresses the POODLE vulnerability (which exploits SSLv3) and enforces the required minimum TLS version, while keeping the server immediately available without restarting Apache (a graceful reload is sufficient).

Exam trap

The trap here is that candidates often think adding '-SSLv3' to the existing line (Option A) is sufficient, but they overlook the requirement to also disable TLS 1.0 and TLS 1.1, which remain enabled by the 'all' macro and are still vulnerable to downgrade attacks like BEAST or Lucky13.

How to eliminate wrong answers

Option A is wrong because 'SSLProtocol all -SSLv2 -SSLv3' still enables all protocols except SSLv2 and SSLv3, which includes TLS 1.0 and TLS 1.1 — these are below TLS 1.2 and do not satisfy the requirement to disable all TLS versions below 1.2. Option B is wrong because adding 'SSLProtocol -SSLv3' after the existing line would override the previous directive (Apache uses the last directive for a given context), resulting in only disabling SSLv3 while re-enabling all other protocols (including SSLv2 and TLS 1.0/1.1), which fails to disable TLS below 1.2. Option D is wrong because 'SSLProtocol TLSv1.2 TLSv1.3 -SSLv2 -SSLv3' is redundant and syntactically incorrect — the '-SSLv2' and '-SSLv3' flags are unnecessary since explicitly listing TLSv1.2 and TLSv1.3 already excludes all other protocols, and Apache may ignore or misinterpret the extra negations.

Practice this question →
61
MCQhard

An administrator wants to chroot SSH users in the 'jailed' group to their home directories. Which configuration in /etc/ssh/sshd_config achieves this?

A.Subsystem sftp internal-sftp Match Group jailed ChrootDirectory %h
B.Match User jailed ChrootDirectory %h
C.ChrootGroup jailed ChrootDirectory %h
D.Match Group jailed ChrootJail %h
E.Match Group jailed ChrootDirectory %h
AnswerE

Matches the group and sets chroot to the home directory.

Why this answer

The Match directive in sshd_config allows conditional configuration blocks based on criteria like group membership. The ChrootDirectory %h directive chroots the user to their home directory, which is the standard method for restricting SSH users to a specific filesystem area. This configuration applies only to users in the 'jailed' group, as required.

Exam trap

The trap here is that candidates confuse 'Match Group' with 'Match User' or invent non-existent directives like 'ChrootJail' or 'ChrootGroup', failing to recall that the correct syntax requires 'Match Group' followed by 'ChrootDirectory'.

How to eliminate wrong answers

Option A is wrong because it includes 'Subsystem sftp internal-sftp' which is unrelated to chrooting SSH users; it configures an internal SFTP subsystem, not a chroot for general SSH access. Option B is wrong because 'Match User jailed' matches a user named 'jailed', not a group; the requirement is to match the group 'jailed'. Option C is wrong because 'ChrootGroup jailed' is not a valid sshd_config directive; the correct directive is 'ChrootDirectory', and group matching must use 'Match Group'.

Option D is wrong because 'ChrootJail %h' is not a valid sshd_config directive; the correct directive is 'ChrootDirectory'.

Practice this question →
62
MCQhard

An administrator needs to encrypt a large file using GPG with a symmetric cipher and then decrypt it on another system. Which command encrypts the file using AES256 and prompts for a passphrase?

A.gpg --clearsign --cipher-algo AES256 file.txt
B.gpg --encrypt --cipher-algo AES256 file.txt
C.gpg --sign --cipher-algo AES256 file.txt
D.gpg --symmetric --cipher-algo AES256 file.txt
AnswerD

Symmetric encryption prompts for passphrase; uses AES256.

Why this answer

`--symmetric` tells GPG to encrypt the file using a symmetric cipher (i.e., a single passphrase shared between sender and receiver), and `--cipher-algo AES256` selects the AES-256 encryption algorithm. The command will prompt for a passphrase interactively, which is exactly what the scenario requires.

Exam trap

The trap here is that candidates often confuse `--encrypt` (which implies public-key encryption) with `--symmetric` (which uses a passphrase), leading them to select option B even though it requires a recipient key rather than a passphrase prompt.

How to eliminate wrong answers

Option A is wrong because `--clearsign` creates a detached or inline clear-text signature, not encryption; it does not encrypt the file content. Option B is wrong because `--encrypt` without `--symmetric` defaults to public-key encryption, which requires a recipient's key rather than a shared passphrase. Option C is wrong because `--sign` only creates a digital signature, leaving the file unencrypted; it does not perform any encryption.

Practice this question →
63
MCQeasy

Refer to the exhibit. What type of attack is indicated by the log entries?

A.Privilege escalation attempt
B.Man-in-the-middle attack
C.Distributed denial-of-service (DDoS) attack
D.Brute-force attack on SSH
AnswerD

The repeated failed login attempts for the root user from the same IP signature a brute-force attempt.

Why this answer

The log entries show repeated SSH authentication failures from the same IP address with different usernames and passwords, which is characteristic of a brute-force attack. Attackers systematically try many credential combinations to gain unauthorized access to the SSH service, as indicated by the 'Failed password' messages.

Exam trap

The trap here is that candidates may confuse repeated login failures with a DDoS attack, but the key distinction is the sequential, targeted nature of authentication attempts versus volumetric traffic flooding.

How to eliminate wrong answers

Option A is wrong because privilege escalation attempts involve gaining higher-level permissions after initial access, not repeated login failures from external sources. Option B is wrong because man-in-the-middle attacks intercept or modify communications between two parties, which would show ARP spoofing or SSL certificate mismatches, not SSH authentication failures. Option C is wrong because DDoS attacks flood a target with traffic to overwhelm resources, which would show high packet rates or connection timeouts, not sequential login attempts.

Practice this question →
64
MCQmedium

Refer to the exhibit. An administrator runs aide --check and receives a warning that /var/log/syslog has changed. Why is this expected?

A.The SHA512 hash for /var/log is incorrect.
B.The /var/log entry monitors the directory itself, not its contents; changes inside the directory are not tracked.
C.The /var/log entry includes permissions but not content hashes, so changes in file content are not monitored.
D.The +c flag checks for changes in the file's ctime, so syslog changes are detected.
AnswerB

Only the directory's attributes and hash are checked, not files within.

Why this answer

The AIDE configuration for /var/log typically monitors the directory entry itself (its metadata like permissions and ownership) rather than recursively tracking changes to files within it. When /var/log/syslog changes, AIDE does not detect it because the directory's inode metadata remains unchanged; only the file's content and metadata are altered. This is a common default behavior unless the configuration explicitly uses the 'R' or 'p+sha512' flags to recurse into subdirectories and hash file contents.

Exam trap

The trap here is that candidates assume monitoring a directory automatically includes its contents, but AIDE requires explicit recursive flags (like 'R' or 'p+sha512') to track files within subdirectories.

How to eliminate wrong answers

Option A is wrong because the warning is about /var/log/syslog, not the SHA512 hash of /var/log itself; AIDE computes hashes for monitored files, but if the directory entry is monitored without recursion, file content changes are not hashed. Option C is wrong because AIDE's default configuration for /var/log often includes permission checks but does not include content hashes for files inside the directory unless recursive rules are specified; the issue is not about missing hashes but about the scope of monitoring. Option D is wrong because the +c flag in AIDE checks for changes in the file's ctime (inode change time), but this flag applies to the monitored entry itself; if /var/log is monitored as a directory, the ctime of the directory does not change when a file inside it is modified, so syslog changes are not detected via ctime.

Practice this question →
65
MCQmedium

A web server is running in enforcing mode under SELinux. The administrator wants to allow Apache to connect to a remote database server. Which SELinux boolean needs to be set to allow httpd to make network connections?

A.httpd_enable_homedirs
B.httpd_can_network_connect_db
C.httpd_can_network_connect
D.httpd_unified
AnswerB

Correct. This boolean is specifically designed to allow httpd to connect to remote database servers.

Why this answer

The SELinux boolean `httpd_can_network_connect_db` is specifically designed to allow the httpd process to connect to remote database servers. This boolean is more targeted than the generic `httpd_can_network_connect`, which permits all outbound TCP connections. Since the question explicitly mentions a remote database server, the specific boolean is the most appropriate choice.

Exam trap

The trap is that candidates might choose the generic `httpd_can_network_connect` thinking it covers all network connections, but the question specifies a remote database server, making the database-specific boolean `httpd_can_network_connect_db` the correct and more precise answer.

How to eliminate wrong answers

Option A is wrong because `httpd_enable_homedirs` controls whether httpd can read user home directories (e.g., for public_html), not network connections. Option B is wrong because `httpd_can_network_connect_db` is a more specific boolean that only permits connections to database ports (e.g., 3306 for MySQL, 5432 for PostgreSQL), but the question does not specify a database type and the correct general-purpose boolean is `httpd_can_network_connect`. Option D is wrong because `httpd_unified` is not a valid SELinux boolean; it may be confused with the `httpd_t` domain or the `unconfined` module, but it does not exist in standard SELinux policy.

Practice this question →
66
MCQhard

A government agency runs a classified application on a Linux server with strict auditing requirements. The application writes sensitive data to a MySQL database. The auditor requires that all SQL queries executed by the application be logged with timestamps, user, and the full query text. Additionally, the audit logs must be immutable (cannot be altered by the application or any user except a designated auditor account). The database runs on the same server. Which combination of tools and configurations should the administrator deploy?

A.Enable auditd to monitor the MySQL process and log all system calls.
B.Enable MySQL's general query log, direct it to a file on a separate filesystem mounted with the 'noexec' and 'append' options, and set the file immutable with chattr +a.
C.Enable the MySQL audit log plugin and configure rsyslog to forward logs to a remote log server.
D.Use tcpdump to capture all network traffic to port 3306 and save to a file with packet captures.
AnswerB

The general query log logs plaintext queries; chattr +a makes the file append-only, preventing modification of existing logs.

Why this answer

It combines MySQL's general query log (which captures full query text, timestamps, and user) with filesystem-level immutability via `chattr +a` (append-only) on a separate filesystem mounted with `noexec` and `append` options. This ensures logs cannot be modified or deleted by the application or any non-auditor user, meeting the strict auditing requirement for immutable logs.

Exam trap

The trap here is that candidates may choose auditd (Option A) because it is a common auditing tool, but it cannot capture SQL query text, while MySQL's general query log directly logs queries and can be hardened with filesystem attributes for immutability.

How to eliminate wrong answers

Option A is wrong because `auditd` monitors system calls, not SQL query text; it would log file operations or process activity but cannot capture the full SQL query executed by MySQL. Option C is wrong because while the MySQL audit log plugin can log queries, forwarding logs via rsyslog to a remote server does not guarantee immutability on the local server; the auditor requires logs that cannot be altered by any user except a designated auditor account, and remote forwarding does not prevent local tampering. Option D is wrong because `tcpdump` captures raw network packets on port 3306, which would require decrypting MySQL protocol traffic (unless unencrypted) and does not provide structured query text, timestamps, or user information in a readable log format.

Practice this question →
67
Multi-Selectmedium

Which TWO of the following are effective methods to secure SSH access on a Linux server? (Choose two.)

Select 2 answers
A.Disable root login over SSH.
B.Use FTP over SSH (SFTP) for file transfers.
C.Disable password authentication and use only key-based authentication.
D.Require users to change their passwords every 30 days.
E.Change the default SSH port from 22 to a non-standard port.
AnswersC, E

Key-based authentication is much stronger against brute-force and phishing.

Why this answer

Disabling password authentication and enforcing key-based authentication eliminates the risk of brute-force password guessing attacks. SSH keys use asymmetric cryptography (RSA, ECDSA, or Ed25519) and are resistant to credential stuffing and dictionary attacks, provided private keys are kept secure. This is a foundational security hardening step recommended by the CIS Benchmarks for Linux.

Exam trap

The trap here is that candidates often think disabling root login (Option A) is one of the two correct answers, but the question specifically asks for two methods from the list, and the correct pair is C and E; disabling root login is a valid security measure but is not listed as correct in this particular question's answer set.

Practice this question →
68
MCQeasy

Which file is used to configure which users and groups are allowed to use the 'cron' daemon?

A./var/spool/cron/
B./etc/cron.d/
C./etc/crontab
D./etc/cron.allow
AnswerD

Lists users allowed to use cron.

Why this answer

The /etc/cron.allow file explicitly lists users and groups permitted to schedule cron jobs. If this file exists, only those entries can use crontab; all others are denied, regardless of /etc/cron.deny. This provides a whitelist-based access control mechanism for the cron daemon.

Exam trap

The trap here is that candidates confuse the access control files (/etc/cron.allow and /etc/cron.deny) with the directories or system crontab files that store or schedule jobs, such as /var/spool/cron/ or /etc/crontab.

How to eliminate wrong answers

Option A is wrong because /var/spool/cron/ is a directory containing individual user crontab files (e.g., /var/spool/cron/crontabs/), not a configuration file for access control. Option B is wrong because /etc/cron.d/ is a directory for system cron job fragments (e.g., hourly, daily tasks), not for user authorization. Option C is wrong because /etc/crontab is the system-wide crontab file used to define periodic system jobs, not to control which users can submit cron jobs.

Practice this question →
69
Multi-Selecthard

Which THREE of the following tools can be used to implement file integrity checking on a Linux system?

Select 3 answers
A.AIDE
B.Logwatch
C.Nmap
D.Tripwire
E.sha256sum
AnswersA, D, E

Advanced Intrusion Detection Environment checks file integrity.

Why this answer

AIDE (Advanced Intrusion Detection Environment) is a file integrity checking tool that creates a database of file hashes and attributes (e.g., permissions, timestamps) from a baseline scan. It then periodically compares the current state of the filesystem against this database to detect unauthorized modifications, making it a correct choice for implementing file integrity checking on a Linux system.

Exam trap

The trap here is that candidates may confuse log monitoring or network scanning tools (Logwatch, Nmap) with file integrity checkers, or overlook that `sha256sum` is a valid but lower-level tool for integrity checking, while AIDE and Tripwire are dedicated solutions.

Practice this question →
70
MCQhard

An administrator configures AIDE to monitor /etc. After initializing the database, what command updates the database with current file hashes without removing old entries?

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

This updates the database with current file hashes while preserving unchanged entries.

Why this answer

AIDE's --update option performs a check and then updates the database with any new or changed file hashes while preserving existing entries. This is the correct way to refresh the database after legitimate changes to monitored files, as it combines --check and --init in a single operation without losing the baseline.

Exam trap

The trap here is that candidates confuse --update with --init, thinking both reset the database, but --update preserves old entries while --init destroys them.

How to eliminate wrong answers

Option B is wrong because --init creates a brand new database from scratch, overwriting any existing database and losing all previous entries. Option C is wrong because --compare compares the current files against the database but does not update the database itself. Option D is wrong because --check runs a verification against the database and reports changes but never modifies the database.

Practice this question →
71
MCQeasy

A system administrator wants to ensure that only key-based authentication is allowed for SSH and password authentication is disabled. Which configuration change is required in /etc/ssh/sshd_config?

A.PasswordAuthentication yes and PubkeyAuthentication yes
B.PasswordAuthentication no and PubkeyAuthentication no
C.PasswordAuthentication no and PubkeyAuthentication yes
D.PasswordAuthentication no
AnswerC

This disables password logins and enables key-based authentication, meeting the requirement.

Why this answer

Setting `PasswordAuthentication no` disables password-based login, while `PubkeyAuthentication yes` enables public key authentication. Together, these directives ensure that only users with a valid SSH key pair can authenticate, meeting the requirement to disable password authentication entirely.

Exam trap

The trap here is that candidates may think disabling password authentication alone is sufficient (Option D), forgetting that explicitly enabling public key authentication is necessary to ensure key-based login works and to avoid ambiguity in environments where defaults may differ.

How to eliminate wrong answers

Option A is wrong because `PasswordAuthentication yes` explicitly allows password-based login, which contradicts the goal of disabling it. Option B is wrong because `PubkeyAuthentication no` disables key-based authentication, leaving no viable authentication method and potentially locking out all users. Option D is wrong because it only disables password authentication but does not explicitly enable public key authentication; while `PubkeyAuthentication` defaults to `yes` in most SSH implementations, explicitly setting it ensures the configuration is clear and avoids reliance on default behavior.

Practice this question →
72
MCQhard

A new client with IP 10.0.1.15 tries to connect to HTTPS on the server. Based on the exhibit, what happens?

A.The connection is dropped by rule 5.
B.The connection is rejected with an ICMP error.
C.The connection is accepted only if state RELATED.
D.The connection is accepted because 10.0.1.15 is in 10.0.0.0/8.
AnswerD

Matches rule 4, accepting HTTPS.

Why this answer

The iptables rule set includes a rule that accepts traffic from the 10.0.0.0/8 subnet. The client IP 10.0.1.15 falls within this range, so the HTTPS connection matches the rule and is accepted. This occurs before any later rules that might drop or reject the traffic.

Exam trap

The trap here is that candidates may assume a later DROP rule (e.g., for 10.0.1.0/24) applies, forgetting that iptables processes rules sequentially and an earlier ACCEPT rule for a larger subnet (10.0.0.0/8) will match first, bypassing the more specific drop rule.

How to eliminate wrong answers

Option A is wrong because rule 5 drops traffic from 10.0.1.0/24, but 10.0.1.15 is within 10.0.0.0/8, which is matched by an earlier accept rule, so rule 5 is never reached. Option B is wrong because an ICMP error (e.g., port unreachable) would only be sent if a REJECT target were used, but the rule set uses DROP, which silently discards packets without sending any ICMP response. Option C is wrong because the state RELATED rule applies to traffic that is part of an established connection’s related sessions (e.g., FTP data), but a new HTTPS connection from a client is not RELATED; it would be NEW or ESTABLISHED, and the rule set does not have a state NEW accept rule for this source.

Practice this question →
73
MCQeasy

A security policy requires that all users must change their passwords every 90 days. Which command enforces maximum password age for an existing user 'jdoe'?

A.chage -M 90 jdoe
B.passwd -f jdoe
C.usermod -e 90 jdoe
D.chage -E 90 jdoe
AnswerA

Sets maximum number of days a password is valid.

Why this answer

The `chage -M 90 jdoe` command sets the maximum number of days a password is valid for user 'jdoe' to 90 days, enforcing the security policy. The `-M` option directly controls the password aging parameter that defines when the password must be changed, as stored in `/etc/shadow`.

Exam trap

The trap here is confusing the `-M` (maximum password age) option with the `-E` (account expiration) option, as both use a numeric argument but control entirely different aspects of user account lifecycle.

How to eliminate wrong answers

Option B is wrong because `passwd -f jdoe` forces a password change at the next login but does not set a maximum age limit; it only sets the 'force change' flag. Option C is wrong because `usermod -e 90 jdoe` sets the account expiration date to 90 days from the epoch (January 1, 1970), which would immediately expire the account, not enforce a 90-day password rotation. Option D is wrong because `chage -E 90 jdoe` sets the account expiration date to 90 days from the epoch, not the maximum password age; `-E` controls account expiry, not password aging.

Practice this question →
74
Multi-Selecteasy

Which THREE of the following actions are recommended as initial security hardening steps after installing a new Linux server? (Choose three.)

Select 3 answers
A.Update all packages using the package manager.
B.Disable root login via SSH.
C.Install a graphical desktop environment for easier administration.
D.Enable and configure a firewall (e.g., iptables or firewalld).
E.Set up a web server to monitor system status.
AnswersA, B, D

Ensures the latest security patches are applied.

Why this answer

Immediately updating all packages via the package manager (e.g., `apt upgrade` or `yum update`) applies the latest security patches to the kernel, libraries, and services, closing known vulnerabilities that could be exploited by attackers. This is a foundational step in the initial hardening process, as a newly installed system often ships with outdated packages that have published CVEs.

Exam trap

The trap here is that candidates may confuse 'initial hardening steps' with optional or convenience-based actions, such as installing a desktop environment or a web server, which actually weaken security rather than strengthen it.

Practice this question →
75
MCQmedium

A firewall rule set is implemented using iptables. The administrator wants to allow incoming SSH connections only from the 192.168.1.0/24 subnet, while all other incoming traffic is dropped. Which set of rules achieves this?

A.iptables -A INPUT -p tcp --dport 22 -s 192.168.1.0/24 -j ACCEPT iptables -A INPUT -j DROP
B.iptables -A INPUT -p tcp --sport 22 -s 192.168.1.0/24 -j ACCEPT iptables -A INPUT -j DROP
C.iptables -A INPUT -p tcp --dport 22 -j DROP iptables -A INPUT -s 192.168.1.0/24 -p tcp --dport 22 -j ACCEPT
D.iptables -A INPUT -p tcp --dport 22 -j ACCEPT iptables -A INPUT -p tcp --dport 22 -s 192.168.1.0/24 -j DROP
E.iptables -A INPUT -p tcp --dport 22 -j ACCEPT iptables -A INPUT -j DROP
AnswerA

Allows SSH from subnet, then drops all other input.

Why this answer

It first adds a rule to accept TCP traffic on port 22 (SSH) from the 192.168.1.0/24 subnet, then adds a default DROP rule for all other incoming traffic. Since iptables processes rules in order, the ACCEPT rule matches allowed SSH connections first, and the subsequent DROP rule catches all other incoming packets, effectively dropping everything else including SSH from other sources.

Exam trap

The trap here is that candidates often confuse source and destination ports (--sport vs --dport) or place rules in the wrong order, mistakenly thinking that a DROP rule placed before an ACCEPT rule can be overridden by a later rule, when in fact iptables stops processing after the first match.

How to eliminate wrong answers

Option B is wrong because it uses --sport 22 (source port) instead of --dport 22 (destination port); SSH servers listen on destination port 22, so this rule would incorrectly match packets originating from port 22 on the client, not incoming SSH connections. Option C is wrong because the DROP rule for SSH is placed before the ACCEPT rule, so all SSH traffic (including from 192.168.1.0/24) is dropped first, making the ACCEPT rule unreachable. Option D is wrong because the first rule accepts all SSH traffic from any source, then the second rule attempts to drop SSH from 192.168.1.0/24, but the first rule already accepted it; this effectively allows SSH from everywhere, not just the subnet.

Option E is wrong because it accepts all SSH traffic from any source and then drops all other incoming traffic, which allows SSH from any IP address, not just 192.168.1.0/24.

Practice this question →
Page 1 of 2 · 80 questions totalNext →

Ready to test yourself?

Try a timed practice session using only System Security questions.

Start 20-question session