20 Firewalls, Cryptography & Compliance Practice Questions & Answers

1. 1. On a Linux host, iptables, nftables, firewalld and ufw are all called firewall tools. Which statement correctly describes how these pieces relate to one another?

   • A.Each of the four ships its own packet-filtering engine in user space, so enabling two at once simply applies two independent filters in sequence.
   • B.firewalld inspects packets itself and hands only approved traffic to netfilter, which then makes the routing decision for each accepted connection.
   • C.Filtering happens in the kernel's netfilter framework; nftables is the current user-space interface to it, and firewalld and ufw are front ends that emit rules.✓ Answer
   • D.ufw replaced netfilter inside the Debian-family kernel, while nftables is only a rule-checking utility used on RHEL-family systems.

   netfilter is the in-kernel hook framework that actually inspects packets. The iptables command family and its successor nft are user-space tools that load rules into it, while firewalld (RHEL family) and ufw (Debian family) are higher-level front ends that translate zone or service requests into those same kernel rules. None of them filters packets in user space.

   Source: Linux kernel networking documentation (netfilter framework) and the nft(8), firewall-cmd(1) and ufw(8) manual pagesReport a problem with this question

2. 2. A RHEL-family host is filtered with iptables commands. The INPUT chain already ends with a rule that drops all remaining traffic. The administrator runs `iptables -A INPUT -p tcp --dport 443 -j ACCEPT`, but HTTPS is still unreachable. What explains this?

   • A.Rules in a chain are evaluated top to bottom and the first match wins, so the earlier drop rule already handled the packet; `-I` is needed to insert ahead of it.✓ Answer
   • B.The ACCEPT target is valid only in the nat table, so the rule has to be re-added with `-t nat -A INPUT` before it can permit any inbound HTTPS connection to the host.
   • C.Appending with `-A` places the rule in the FORWARD chain by default, so traffic addressed to the host itself is never compared against the new rule at all.
   • D.A `--dport` match is ignored unless the rule also carries `-m conntrack --ctstate NEW`, so the kernel skips over it and falls through to the drop rule.

   Within a chain, netfilter walks the rules in order and stops at the first rule whose criteria match, applying that rule's target. Because the catch-all drop sits before the appended rule, the packet is discarded before the ACCEPT is ever reached. `-A` appends to the end of the chain, whereas `-I` inserts at the top or at a numbered position, which is what puts the permit ahead of the drop.

   Source: iptables(8) manual page, rule specification and the -A and -I optionsReport a problem with this question

3. 3. A review asks why one iptables rule ends in `-j DROP` while another ends in `-j REJECT`. What is the practical difference between the two targets?

   • A.DROP returns an ICMP port-unreachable message while REJECT discards the packet silently, so DROP is the more informative choice on an internal network.
   • B.DROP discards the packet with no reply, so the sender waits for a timeout, while REJECT sends back an ICMP error so the sender fails straight away.✓ Answer
   • C.DROP discards the packet and records it in the kernel ring buffer, while REJECT discards it without any logging, which is why DROP is preferred for auditing.
   • D.Both discard the packet in exactly the same way; REJECT is merely an alias kept for compatibility with older iptables releases and changes nothing on the wire.

   DROP hands the packet to the kernel's discard path and nothing is sent back, so the client's connection attempt hangs until it times out, which also hides the host from casual probing. REJECT discards the packet but generates an ICMP error (port unreachable by default, or another type chosen with `--reject-with`), so the client fails immediately. Both stop the traffic; they differ in what the sender learns and how fast.

   Source: iptables-extensions(8) manual page, REJECT target and its --reject-with optionReport a problem with this question

4. 4. A team must choose between an INPUT policy of DROP with an explicit allow list and an INPUT policy of ACCEPT with an explicit deny list. Why is the first design described as failing closed?

   • A.A DROP policy applies only to interfaces that are administratively up, so the host stays unreachable for as long as any interface is still initialising.
   • B.A DROP policy makes the kernel reload the stored ruleset whenever a rule is deleted, restoring the last known-good configuration before traffic passes.
   • C.A DROP policy makes connection tracking treat every packet as NEW, so half-open flows are cleaned up and an attacker cannot reuse an existing state entry.
   • D.A DROP policy discards anything no allow rule matches, so a rule lost during an edit or a newly started service costs availability rather than quietly exposing the host.✓ Answer

   With a default deny, the allow list is the complete statement of what is permitted, and any packet matching nothing hits the chain policy and is discarded. A mistake therefore shows up as lost service, which is visible and gets fixed. With a default allow, the deny list must enumerate every unwanted case, so anything the author did not anticipate, or a service that starts listening later, is reachable with no error to reveal it.

   Source: iptables(8) manual page, chain policy (-P); CompTIA Linux+ security content domain, firewall policy designReport a problem with this question

5. 5. An INPUT policy of DROP is in place, inbound SSH is permitted, and one more rule reads `-m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT`. Web browsing from the host then works although no rule mentions the reply traffic. Why?

   • A.Locally generated traffic is exempt from INPUT filtering, so replies to requests the host originated bypass the chain entirely and need no rule of their own.
   • B.The RELATED state opens every port above 1024 for the length of the session, and that is how return traffic from the remote web server reaches the client.
   • C.Connection tracking records the outbound flow, so the returning packets match ESTABLISHED and are accepted without any rule naming the server or its port.✓ Answer
   • D.The chain policy is consulted only after every ACCEPT rule has failed twice, which gives reply packets a second pass in which their source port is matched.

   A stateful firewall keeps a conntrack entry for each flow it has seen. When the host opens an outbound connection that entry is created, and the server's reply packets are recognised as belonging to it and classified ESTABLISHED, so the single ESTABLISHED,RELATED rule accepts them. RELATED covers a separate but associated flow, such as an ICMP error for that connection. Without connection tracking you would need stateless rules matching every possible reply.

   Source: iptables-extensions(8) conntrack match; Linux kernel networking documentation on connection trackingReport a problem with this question

6. 6. On a RHEL-family server the administrator runs `firewall-cmd --permanent --add-service=https`, then immediately tests the service from another machine. The connection is still refused. What is happening?

   • A.The permanent change is written to firewalld's stored configuration and does not affect the running ruleset until `firewall-cmd --reload` loads it.✓ Answer
   • B.The change is already active, but the https service must also be listed in /etc/services before firewalld can resolve that name to a port number.
   • C.The command altered only the running ruleset, so it works right now but will be lost at the next reboot unless `--runtime-to-permanent` is also run.
   • D.Permanent changes are applied only to the default zone, so the test fails because the interface carrying the test traffic is bound to some other zone entirely.

   firewall-cmd maintains two separate configurations. Without `--permanent` a change goes straight into the running ruleset and is lost on reload or reboot; with `--permanent` it is written to firewalld's stored configuration and the running ruleset is untouched. `firewall-cmd --reload` reads the permanent configuration and installs it, which is the step that makes the new service reachable. `--runtime-to-permanent` does the opposite, saving a working runtime ruleset.

   Source: firewall-cmd(1) manual page, --permanent, --reload and --runtime-to-permanent optionsReport a problem with this question

7. 7. Working over SSH on a firewalld-managed host, an administrator removes the ssh service from the active zone as a runtime-only change and can no longer open new sessions; the current session is still alive. Which action restores SSH access from the saved configuration?

   • A.Run `firewall-cmd --runtime-to-permanent`, which rewrites the stored configuration from the running ruleset and brings back the last state.
   • B.Run `firewall-cmd --reload`, which discards the runtime ruleset and installs the on-disk permanent configuration, in which the ssh service is still allowed.✓ Answer
   • C.Run `firewall-cmd --complete-reload`, which flushes connection tracking so the blocked SSH handshake is retried and succeeds.
   • D.Run `firewall-cmd --panic-on`, which suspends all packet filtering until an administrator turns it off again and lets new SSH sessions through.

   `--reload` throws away the runtime ruleset and reloads the permanent configuration from disk, so an unsaved runtime mistake is undone by it. That is exactly why risky firewall changes are made at runtime first and only promoted with `--runtime-to-permanent` once they are known to work; running that command here would instead save the broken ruleset, and `--panic-on` blocks all traffic rather than restoring access.

   Source: firewall-cmd(1) manual page, --reload versus --runtime-to-permanent and --panic-onReport a problem with this question

8. 8. A Linux router with two interfaces must (a) let an internal subnet reach the internet through its single dynamically assigned public address and (b) publish an internal web server on that public address. Using iptables, which pairing is correct?

   • A.DNAT in PREROUTING of the nat table for the outbound direction, and MASQUERADE in POSTROUTING of the nat table to redirect the inbound connections.
   • B.MASQUERADE in POSTROUTING of the nat table for the outbound direction, and DNAT in PREROUTING of the nat table to redirect the inbound connections.✓ Answer
   • C.SNAT in the INPUT chain of the filter table for the outbound direction, and REDIRECT in the OUTPUT chain of filter for the inbound connections.
   • D.MASQUERADE in the OUTPUT chain of the mangle table for outbound traffic, and DNAT in the FORWARD chain of mangle for the inbound connections.

   Source translation must happen after the routing decision, so it lives in POSTROUTING, and MASQUERADE is the variant that takes the source address from whatever the exit interface currently holds, which is what a dynamic public address requires. Destination translation must happen before the routing decision so the packet is then routed onward to the internal server, so port forwarding uses DNAT in PREROUTING. Both belong to the nat table, and IP forwarding must also be enabled persistently for either to move traffic between the interfaces.

   Source: iptables(8) and iptables-extensions(8) manual pages, nat table chains with the SNAT, MASQUERADE and DNAT targetsReport a problem with this question

9. 9. A Debian-family server needs a minimal firewall: refuse unsolicited inbound traffic but keep SSH reachable, configured with ufw. Which sequence is correct, and what does ufw do with the rules?

   • A.`ufw default drop all`, then `ufw permit ssh`, then `ufw start`; ufw runs as its own daemon that inspects packets before the kernel's netfilter hooks ever see them.
   • B.`ufw allow OpenSSH` on its own is enough, because ufw denies incoming traffic as soon as any application profile under /etc/ufw/applications.d is referenced.
   • C.`ufw enable`, then `ufw allow 22`, then `ufw reload`; ufw keeps rules in its own database and every allow rule needs a reload before it takes effect.
   • D.`ufw default deny incoming`, then `ufw allow OpenSSH`, then `ufw enable`; ufw translates the rules into netfilter rules and reapplies them at each boot.✓ Answer

   ufw is the simplified front end shipped by the Debian family. `ufw default deny incoming` sets the catch-all direction, `ufw allow OpenSSH` uses the application profile that names the port, and `ufw enable` both activates the policy now and arranges for it to be restored at boot, so unlike raw iptables commands the ruleset is persistent. Underneath, ufw generates netfilter rules rather than filtering packets itself.

   Source: ufw(8) manual page, default policy, application profiles and the enable subcommandReport a problem with this question

10. 10. An administrator must send a large archive to an external partner so that only the partner can read it, using GnuPG on Linux. Which approach fits, and what role does each key play?

    • A.Encrypt with `gpg -c` and a shared passphrase, because symmetric mode is what allows a recipient who holds no key pair at all to decrypt the delivered file.
    • B.Sign the archive with `gpg --detach-sign`, because a detached signature leaves the contents unreadable to anyone who lacks the signer's public key.
    • C.Encrypt with `gpg --encrypt --recipient` naming the administrator's own public key, because the sender's key pair is what establishes the origin of the file.
    • D.Encrypt with `gpg --encrypt --recipient` naming the partner's imported public key, because only the matching private key the partner holds can decrypt it.✓ Answer

    Public-key encryption is directional: data encrypted to a public key can only be decrypted with the corresponding private key. To give confidentiality to one named recipient you therefore encrypt to that recipient's public key, which must first be imported into your keyring with `gpg --import` and ideally checked against its fingerprint. `gpg -c` is symmetric and would require sharing a passphrase out of band, while a detached signature provides authenticity and integrity but no confidentiality at all.

    Source: gpg(1) manual page, --encrypt with --recipient, --symmetric and --detach-signReport a problem with this question

11. 11. A spare partition has just been initialised with `cryptsetup luksFormat /dev/sdb1` and then opened with `cryptsetup open /dev/sdb1 secure`. What is the correct next step, and why?

    • A.Run `mkfs.ext4 /dev/sdb1`, because the filesystem has to sit on the partition itself so that the LUKS header can be appended to it afterwards.
    • B.Run `cryptsetup luksFormat` again on /dev/mapper/secure, because the mapper device needs its own header before a filesystem can be created.
    • C.Run `mkfs.ext4 /dev/mapper/secure`, because the mapper device is the decrypted view of the partition and everything written through it is encrypted on disk.✓ Answer
    • D.Run `mount /dev/mapper/secure /mnt`, because luksFormat already placed a filesystem inside the container at the time it wrote the LUKS header.

    `cryptsetup open` creates a device-mapper node, /dev/mapper/secure, that presents the decrypted contents of the container, and the filesystem must be created on that node because writes through it are encrypted with the volume's master key before reaching /dev/sdb1. Formatting the raw partition instead would overwrite the LUKS header and destroy access; since the master key lives in that header, a header backup is what protects the data and destroying the header makes it unrecoverable.

    Source: cryptsetup(8) manual page, luksFormat and open with the device-mapper node under /dev/mapperReport a problem with this question

12. 12. Three mechanisms are compared over the same file: a SHA-256 digest, an HMAC computed with SHA-256 and a shared secret, and a GnuPG signature. Which statement describes what each one establishes?

    • A.The digest detects change alone, the HMAC also shows the sender knew the shared secret, and the signature ties the file to the holder of one private key.✓ Answer
    • B.All three prove origin equally well and differ only in output length, so the choice between them comes down to how much room the stored value takes.
    • C.The digest and the HMAC both prove origin because each depends on a secret, while the signature only shows that the file was not altered in transit.
    • D.The digest proves origin because only the publisher can compute it, the HMAC adds nothing further, and the signature simply compresses the digest for transport.

    A plain digest is computed from the data alone, so anyone can recompute it: it detects modification but says nothing about who produced the file. An HMAC mixes a shared secret into the computation, so a correct value shows the producer held that secret, though either holder could have produced it. A signature is made with a private key and checked with the matching public key, so it binds the file to one specific key holder and gives authenticity as well as integrity.

    Source: gpg(1) --verify and openssl-dgst(1) -hmac; CompTIA Linux+ security content domain, hashing and message authenticationReport a problem with this question

13. 13. A tarball is downloaded from a community mirror and its `sha256sum` output matches the digest shown on the project's download page. What has actually been established?

    • A.That the file is authentic and came from the project, because nobody but the project could produce a digest matching the downloaded bytes.
    • B.That the archive contains no malicious code at all, because a digest computed over a modified archive can never collide with the value the project published.
    • C.That the bytes match the published digest; an attacker holding the mirror and that page could pass this check, so `gpg --verify` on a signed digest is needed.✓ Answer
    • D.That the download was protected end to end, because the digest could only survive intact over a TLS connection whose certificate the client validated.

    A checksum comparison shows only that the bytes you hold are the bytes the digest was computed over, which is an integrity check against corruption and against tampering by someone who could not also change the published value. If one party controls both the file and the page listing its digest, the two move together and the check still passes. Authenticity needs something an attacker cannot forge, which is why projects publish a detached signature over the checksum file.

    Source: sha256sum(1) and gpg(1) --verify; CompTIA Linux+ security content domain, file integrity and signed package verificationReport a problem with this question

14. 14. For a public web server an administrator runs `openssl genpkey` and then `openssl req -new -key server.key -out server.csr`. What does the resulting request carry, and what does the CA contribute?

    • A.It carries the public key together with the identity details, and the CA signs the whole thing so that any client trusting that CA will accept the named identity.✓ Answer
    • B.It carries a self-signed certificate, and the CA re-dates that certificate so clients accept the existing signature for the rest of its validity period.
    • C.It carries the private key so the CA can verify it, and the CA returns that same key wrapped in a certificate alongside a copy of its own root key.
    • D.It carries the intended cipher list, and the CA chooses the key pair on the administrator's behalf before issuing the signed certificate.

    A certificate signing request is generated from the key pair but contains only the public half, plus the subject name and any requested extensions, self-signed to prove possession of the private key; the private key never leaves the server. The CA's contribution is its signature, attesting that the named identity was verified to its stated standard, and clients accept the certificate because they already trust the CA's root rather than because of anything intrinsic to the request.

    Source: openssl-req(1) manual page, certificate request generation; X.509 certificate path validationReport a problem with this question

15. 15. An internal Linux web server presents a certificate created with `openssl req -x509`. The hostname matches, the validity dates are current, and the private key is correct, yet browsers still report that the connection is not private. What is the reason?

    • A.Because a certificate produced with `-x509` contains no public key at all, so the client cannot complete the key exchange and reports the result as untrusted.
    • B.Because self-signed certificates are restricted to a very short lifetime, and browsers refuse any certificate whose validity period falls under their minimum.
    • C.Because `-x509` emits a signing request rather than a certificate, so the server is offering a file that clients are unable to parse as a certificate at all.
    • D.Because the certificate is signed by its own key rather than by anything in the client's trust store, so the chain ends at a signer that cannot be verified.✓ Answer

    Client validation walks the certificate chain until it reaches a certificate already present in the local trust store. A self-signed certificate is its own issuer, so the chain terminates at an anchor the client was never told to trust, and the warning appears however correct the name and dates are. The remedy is a certificate from a CA whose root is already trusted, or deliberately installing an internal CA root into the clients' trust store; `openssl req -x509` does produce a real certificate, just an untrusted one.

    Source: openssl-req(1) manual page, -x509 self-signed output; X.509 certificate path validation and local trust anchorsReport a problem with this question

16. 16. An HTTPS service that worked for a year suddenly fails for all clients on a Monday morning, and nothing was deployed over the weekend. Which check should be run first, and what makes expiry a standing operational hazard?

    • A.Restart the web server and watch its journal, because an expired certificate is reloaded and renewed automatically the next time the service starts up.
    • B.Read the validity window with `openssl x509 -enddate -noout -in server.crt`; a certificate stops being accepted on its own schedule with no change to the host.✓ Answer
    • C.Compare the certificate's fingerprint against the CA's root, because a chain becomes invalid once the CA rotates its root to a longer key length.
    • D.Check that the private key still matches the certificate, because key files drift out of step with the certificate as the filesystem is written to over the months.

    A certificate carries fixed notBefore and notAfter timestamps, so it fails validation the moment the clock passes notAfter even though no file changed and no configuration was touched, which is why an unchanged, previously working service breaks on its own. `openssl x509 -enddate` reads that date from the file and `openssl s_client -connect host:443` shows what the server is actually serving, so renewal has to be tracked and automated rather than remembered.

    Source: openssl-x509(1) manual page, -dates and -enddate; openssl-s_client(1) for the served chainReport a problem with this question

17. 17. A team installs AIDE on a newly provisioned RHEL-family server, edits /etc/aide.conf, runs `aide --init`, and then runs `aide --check`, which reports that the database cannot be found. What is missing, and what makes the baseline trustworthy?

    • A.AIDE needs `--config /etc/aide.conf` passed on every check run, and the baseline is trustworthy because AIDE recomputes the whole database each time.
    • B.AIDE must be told to register the database with `aide --update` before the first check, and the baseline is trustworthy because it ships inside the installed package.
    • C.AIDE writes the new database as aide.db.new.gz, which must be renamed to the configured name; a baseline is trustworthy only if built on a clean host and kept off-box.✓ Answer
    • D.AIDE requires the stored database to be uncompressed first, and the baseline is trustworthy because its digests are recalculated from the package manager.

    `aide --init` deliberately writes to a new file so an existing baseline is never overwritten by accident, and you must move or rename it to the database path set in /etc/aide.conf before `aide --check` has anything to compare against. The mechanism only answers whether something changed since the baseline, so the baseline must be created on a system known to be clean and kept where an intruder cannot rewrite it, or an attacker simply re-baselines their own changes.

    Source: aide(1) and aide.conf(5) manual pages, --init and --check with the database_out settingReport a problem with this question

18. 18. A RHEL-family host may have been tampered with. The administrator must (a) confirm a downloaded package file really came from the vendor and (b) find out whether files already on disk differ from what the package delivered. Which pairing is correct?

    • A.`rpm --checksig pkg.rpm` against an imported vendor key for the download, and `rpm -Va` for the installed files, since it compares them with the package database.✓ Answer
    • B.`rpm -Va` for the download, since it validates the signature of any package file, and `rpm --checksig pkg.rpm` for the installed files on disk.
    • C.`sha256sum pkg.rpm` for the download, since a digest on its own establishes the vendor, and `rpm -qa` for the installed files, since it lists what each package delivered.
    • D.`rpm --import` for the download, since importing the file registers it as trusted, and `rpm -qi` for the installed files, since it prints their expected digests.

    These are two different jobs. `rpm --checksig` (equivalently `rpm -K`) checks the signature embedded in a package file against keys previously imported with `rpm --import`, which is what establishes that the file came from the vendor unmodified. `rpm -V` and `rpm -Va` do no signature work at all: they compare installed files against the size, mode, digest, owner, group and timestamp recorded in the RPM database, printing a flag per failed test and nothing for an unmodified file, with configuration files marked `c` and expected to differ.

    Source: rpm(8) manual page, --checksig and -K, and the -V verify options with their result flagsReport a problem with this question

19. 19. On a Debian-family server there are four security tasks: find which network services are actually listening, compare the host's configuration with a published hardening baseline, learn whether any monitored file changed since a known-good point, and look for traces of a known rootkit. Which mapping of tools to tasks is correct?

    • A.A port scanner checks the configuration baseline, OpenSCAP finds listening services, rkhunter detects changed files, and AIDE looks for rootkit traces on disk.
    • B.OpenSCAP finds listening services, AIDE checks the configuration baseline, a port scanner detects changed files, and rkhunter reports on the hardening profile.
    • C.AIDE finds listening services, rkhunter checks the configuration baseline, OpenSCAP detects changed files, and a port scanner looks for rootkit traces.
    • D.A port scanner finds listening services, OpenSCAP checks the configuration baseline, AIDE detects changed files, and rkhunter looks for rootkit traces.✓ Answer

    These answer different questions and are not interchangeable. A port scanner probes reachable ports from the network to show which services are exposed, and locally `ss -tulpn` shows the same listeners with the process owning each. OpenSCAP evaluates the running configuration against machine-readable SCAP content such as a published hardening profile and reports pass or fail per rule. AIDE compares the filesystem against a stored baseline of digests and attributes, so it detects change rather than exposure. rkhunter searches for indicators of known rootkits.

    Source: oscap(8), aide(1), rkhunter(8) and ss(8) manual pages; CompTIA Linux+ security content domain, vulnerability scanning and file integrityReport a problem with this question

20. 20. A RHEL-family host is scanned with `oscap xccdf eval --profile <profile_id> --results results.xml --report report.html` using SCAP Security Guide content. Several rules fail. What is the correct reading of the result and the next step?

    • A.The scan corrected the failing rules by itself while evaluating them, so the report describes a host that already complies fully with the chosen profile.
    • B.The report documents the host's state at that moment; remediation is a separate step, and a later re-scan is what evidences that the findings were closed.✓ Answer
    • C.Failing rules mean the profile does not apply to this host, so the correct step is to select a different profile until a scan returns no failures at all.
    • D.The report is the deliverable the auditor needs, so once it has been filed the findings are closed and only the next scheduled scan needs arranging.

    An XCCDF evaluation compares the running configuration against the rules in the selected profile and writes results plus a human-readable report; it changes nothing unless remediation is requested explicitly, either with the remediation option or by generating a remediation script or playbook from the results and applying it. A report is therefore evidence of state at a point in time rather than an outcome: a finding is closed only after the configuration is changed and a fresh scan shows the rule passing. `oscap info` on the data stream lists the profile identifiers available for `--profile`.

    Source: oscap(8) manual page, xccdf eval with --profile, --results, --report and the remediation optionReport a problem with this question

Practice questions written to the published CompTIA Linux+ exam objectives and to standard Linux administration practice. CompTIA and Linux+ are marks of CompTIA, and Linux is a registered trademark of Linus Torvalds; this site is not affiliated with or endorsed by CompTIA. The real exam mixes multiple-choice items with performance-based questions that ask you to carry out a task in a simulated environment — those cannot be reproduced in a four-option format, so this bank covers the knowledge half and you should practise on a real system alongside it. CompTIA revises and version-numbers the objectives periodically: confirm the current objectives, exam code and requirements with CompTIA before testing. About the CompTIA Linux+ certification →