CCNA System Security Questions — Page 2 of 2

MCQhard

An administrator wants to create a chroot environment for a potentially compromised service. The service needs to read /etc/resolv.conf and /etc/hosts, and run from a directory /chroot/service. Which of the following steps is essential to ensure the chroot environment is secure and functional?

A.Set the chroot directory to be read-only.

B.Mount /proc within the chroot jail.

C.Copy only the service binaries and configuration files into the chroot.

D.Create /dev/null and /dev/random inside the chroot using mknod.

AnswerD

Device files are required for many system calls; without them, the service may crash or hang.

Why this answer

A chroot environment typically lacks device nodes, and many services require /dev/null and /dev/random for basic I/O operations and entropy. Without these, the service may fail to start or behave unpredictably. Creating them with mknod ensures the service can function securely within the jail.

Exam trap

The trap here is that candidates assume copying binaries and configs is sufficient, overlooking the need for device nodes that are part of the filesystem but not present in a minimal chroot.

How to eliminate wrong answers

Option A is wrong because setting the chroot directory read-only would prevent the service from writing logs, temporary files, or runtime data, breaking functionality; chroot jails are not inherently read-only. Option B is wrong because mounting /proc is not essential for reading /etc/resolv.conf and /etc/hosts; /proc is needed for process information but not for the stated file access. Option C is wrong because copying only binaries and configuration files ignores the need for device nodes like /dev/null and /dev/random, which are required by many services for standard I/O and random number generation.

Practice this question →

MCQmedium

Refer to the exhibit. What is the effect of this sudoers configuration?

A.Users alice and bob can run any software command on the localhost only.

B.Members of ADMINS can run any command as root on any host.

C.Users alice and bob can run apt-get and dpkg on any host as root, requiring a password.

D.Users alice and bob can run apt-get and dpkg without a password.

AnswerC

The configuration grants exactly that: the specified commands, on any host, with password prompt.

Why this answer

The sudoers configuration specifies that users alice and bob are allowed to run only the commands /usr/bin/apt-get and /usr/bin/dpkg as root on any host (ALL). The absence of the NOPASSWD tag means that a password is required for these commands. The syntax 'alice,bob ALL=(root) /usr/bin/apt-get, /usr/bin/dpkg' restricts the command set and requires authentication.

Exam trap

The trap here is that candidates often overlook the absence of the NOPASSWD tag and assume that any sudo entry implies passwordless execution, or they misread 'ALL' in the host field as meaning 'all commands' instead of 'all hosts'.

How to eliminate wrong answers

Option A is wrong because the configuration does not restrict commands to localhost only; it uses 'ALL' for the host part, meaning any host, and it only allows apt-get and dpkg, not any software command. Option B is wrong because there is no group named ADMINS defined in the given configuration; the entries are for individual users alice and bob, not a group. Option D is wrong because the configuration does not include the NOPASSWD tag, so a password is required for the specified commands.

Practice this question →

MCQeasy

An administrator wants to drop incoming TCP packets on port 22 from IP 10.0.0.5 using iptables. Which command is correct?

A.iptables -A INPUT -d 10.0.0.5 -p tcp --dport 22 -j DROP

B.iptables -A FORWARD -s 10.0.0.5 -p tcp --dport 22 -j DROP

C.iptables -A OUTPUT -s 10.0.0.5 -p tcp --dport 22 -j DROP

D.iptables -A INPUT -s 10.0.0.5 -p tcp --dport 22 -j DROP

AnswerD

This correctly matches incoming packets from 10.0.0.5 to port 22 and drops them.

Why this answer

It adds a rule to the INPUT chain, which processes packets destined for the local system. The `-s 10.0.0.5` flag specifies the source IP address, `-p tcp --dport 22` matches TCP packets destined for port 22 (SSH), and `-j DROP` silently discards matching packets. This configuration drops incoming SSH traffic from the specified host before it reaches any local service.

Exam trap

The trap here is that candidates often confuse the `-s` (source) and `-d` (destination) flags, or mistakenly apply the rule to the FORWARD or OUTPUT chain instead of the INPUT chain, failing to understand the packet flow through iptables chains.

How to eliminate wrong answers

Option A is wrong because it uses `-d 10.0.0.5` (destination IP) instead of `-s` (source IP), which would drop packets destined to 10.0.0.5 rather than from it. Option B is wrong because it targets the FORWARD chain, which only applies to packets routed through the system, not those destined for the local host. Option C is wrong because it uses the OUTPUT chain, which processes outgoing packets from the local system, not incoming packets from a remote host.

Practice this question →

MCQeasy

A system administrator wants to ensure that all commands executed by root are logged to a remote syslog server. Which rsyslog configuration directive should be used?

A.auth.* @192.168.1.100

B.authpriv.* @192.168.1.100

C.user.* @192.168.1.100

D.kern.* @192.168.1.100

AnswerB

authpriv facility logs security/authorization messages including sudo commands.

Why this answer

The `authpriv` facility in rsyslog is specifically designated for security and authorization messages, including all commands executed by root via `sudo` or direct login. The directive `authpriv.* @192.168.1.100` sends all messages from this facility to the remote syslog server at UDP port 514. This matches the requirement to log root's commands, as Linux systems typically log such events under the `authpriv` facility.

Exam trap

The trap here is confusing `auth` with `authpriv` — candidates often pick `auth.*` thinking it covers all authentication, but `authpriv` is the correct facility for privileged command logging and is a key distinction tested in LPIC-2.

How to eliminate wrong answers

Option A is wrong because `auth.*` covers general authentication events (e.g., login attempts) but not the detailed command logging from root's sessions, which is specifically assigned to `authpriv`. Option C is wrong because `user.*` is for generic user-level messages, not security-related command logs. Option D is wrong because `kern.*` captures kernel messages, not user command execution logs.

Practice this question →

Drag & Dropmedium

Order the steps to configure a Linux system as a router using iptables.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

When configuring a Linux system as a router using iptables, the proper order is: first enable IP forwarding (via sysctl), then set default iptables policies (e.g., DROP for FORWARD), then add NAT (e.g., MASQUERADE) and FORWARD rules, and finally save the iptables configuration to make it persistent. This sequence ensures the kernel is prepared for routing, policies are in place to control traffic flow, rules are applied correctly, and changes are saved.

Practice this question →