- A scan shows a server listening on TCP ports 22, 53, and 443. Which services do these ports usually indicate?
Answer: SSH, DNS, and HTTPS
Port 22 is SSH, 53 is DNS, and 443 is HTTPS. Knowing these helps defenders spot unexpected services. DHCP is a tempting match for 53, but DHCP uses UDP ports 67 and 68. Port 53 belongs to DNS.
- Which conclusion is best supported by this information?
Answer: The interface may remain reachable through external port 8443, which the edge device maps to internal port 443.
When you see a question involving port numbers and network address translation, focus on the distinction between the external port (what the outside world sees) and the internal port (what the destination server actually listens on). These two values are independent — NAT and port translation exist precisely to decouple them.
Here, the edge device is configured to accept traffic on external TCP port 8443 and forward it to internal port 443. The external scanner probing port 443 on the edge device finds it closed — but that's irrelevant, because the service was never advertised on port 443 externally. The URL https://gateway.example:8443 tells you exactly where to reach it. Option D correctly captures this: the interface remains reachable via port 8443, which the edge device maps inward to port 443. The scanner's finding about port 443 is simply a non-issue.
Option A is wrong because HTTPS has no requirement that the external port be 443. Port 443 is just the default; HTTPS runs happily over any TCP port, including 8443. Option B is wrong on two counts — port translation absolutely can (and routinely does) change destination ports for TCP, and there's nothing in the scenario suggesting UDP is involved. Option C is a fabrication; there is no rule that encrypted services on nonstandard ports are interpreted as SSH. SSH conventionally uses port 22, but port numbers don't define the protocol in use.
As a study tip: on security exams, watch for distractors that confuse default port numbers with required port numbers. Defaults are conventions, not constraints — services can be remapped freely.
- Why can data exfiltration still occur despite the endpoint DNS restriction?
Answer: The internal resolver can relay attacker-controlled query names outward while performing recursion, even though the endpoint cannot query externally.
When you see a question about DNS-based data exfiltration, the key concept to focus on is how data moves indirectly — the attacker doesn't need a direct connection to the victim endpoint if a trusted intermediary carries the payload for them.
This is precisely what makes A correct. When the endpoint queries a long, unique subdomain like dGhpcyBpcyBzZWNyZXQ.attacker.com, the internal resolver has no cached answer, so it performs full recursion — contacting the attacker's authoritative nameserver on the endpoint's behalf. The subdomain itself is the exfiltrated data, encoded in the query string. The resolver dutifully forwards that attacker-controlled name outward, even though the endpoint never touches the Internet directly. The restriction on endpoints is bypassed because the resolver is both trusted and permitted to reach external DNS infrastructure.
B is wrong because DNS queries have absolutely no relationship to SSH (TCP port 22). These are entirely separate protocols; one does not open sessions for the other under any circumstance.
C is wrong because DHCP is a local-network broadcast protocol used for IP address assignment. Internet routers do not forward DHCP broadcasts, and DHCP has no mechanism to carry DNS query data to an external attacker.
D is wrong because DNS resolvers do not perform TLS/HTTPS inspection, and they certainly do not store decrypted HTTP content inside DNS cache entries — those are completely separate systems with different purposes.
For your exam, remember this pattern: any protocol that relies on a trusted intermediary for outbound communication can become a covert channel, because the restriction on the endpoint doesn't restrict what the intermediary carries on its behalf.
- Spoofed-source UDP floods succeed, but spoofed TCP connections to the same host never complete. Why?
Answer: The SYN-ACK goes to the forged address, not the attacker
A TCP connection needs a three-way handshake. The SYN-ACK is sent to the forged address, so the attacker never sees it and cannot finish. UDP has no handshake. TCP checksums only detect transmission errors and do not verify who sent a packet.
- Which description most accurately identifies the resulting network traffic?
Answer: The workstation carries local port 8443 traffic inside SSH on port 22, and the bastion connects to intranet port 443.
When you see a question about SSH tunneling, focus on where traffic travels and in what form at each hop — the firewall rules constrain which ports are open, and SSH local forwarding is specifically designed to work within those constraints.
The command ssh -L 8443:intranet.example:443 bastion.example creates a local port forward: your SSH client listens on localhost:8443, and anything connecting to it gets wrapped inside the encrypted SSH session on port 22 to the bastion. The bastion then unwraps that traffic and makes a fresh TCP connection to intranet.example:443. When your browser hits https://localhost:8443, the HTTPS packets travel through that tunnel — the workstation never directly contacts the intranet server, and the bastion acts as a relay. That makes B the accurate description.
A is wrong because the workstation never sends traffic directly to the intranet server — after SSH authentication, the bastion handles that leg entirely. The connection doesn't bypass the bastion; the bastion is essential to it. C introduces DNS-over-port-53 conversion, which has nothing to do with SSH local forwarding — this is a fabricated distractor mixing up unrelated protocols. D describes a remote port forward (or a reverse tunnel), where a remote host initiates back to you — the -L flag does the opposite, binding a port locally on the workstation and having the bastion reach outward to the intranet.
A reliable memory anchor: **-L = Local listening, outbound reach**. The local machine listens; the remote end (bastion) reaches the final destination. Contrast this with -R (remote forward) for reverse tunnels, which is a common exam pairing.
- Admins manage servers over Telnet on port 23, and a packet capture shows their passwords in plaintext. What is the best fix?
Answer: Replace Telnet with SSH on port 22
SSH encrypts the entire remote session, so captured traffic no longer reveals passwords. Moving Telnet to another port only hides the service. The traffic is still plaintext and readable by anyone sniffing it.
- Which action would most directly prevent this attack while preserving authorized address assignment?
Answer: Enable DHCP snooping on access switches and trust only ports leading to authorized DHCP infrastructure.
When you encounter a rogue DHCP server question, ask yourself: where does the threat originate, and which control stops it at exactly that layer? Here, the attack is internal — a personal router plugged directly into a switch port is poisoning the local network with false gateway and DNS information. The perimeter firewall is irrelevant because the rogue server never touches the internet boundary.
DHCP snooping is the purpose-built Layer 2 defense for this scenario. When you enable it on access switches and mark only ports connected to authorized DHCP servers as "trusted," the switch silently drops DHCP offer and acknowledgment messages arriving on any untrusted port. The rogue router's responses never reach clients, while legitimate DHCP traffic flows normally. This directly targets the attack vector without disrupting authorized address assignment — making B the correct answer.
A is wrong on two levels: DHCP runs over UDP (ports 67 and 68), not TCP, and blocking those ports at the perimeter does nothing to stop a threat that never crosses the perimeter in the first place. This is a classic distractor that tests whether you know the protocol.
C is a non-sequitur. Requiring HTTPS on the default gateway is an application-layer encryption measure with zero relationship to how clients receive their IP configuration. DHCP runs before a browser ever makes a request.
D confuses the attack chain. A rogue DHCP server doesn't depend on external DNS to hand out false settings — it simply broadcasts fabricated responses locally. Blocking UDP 53 outbound punishes clients, not attackers.
Study tip: Memorize that DHCP snooping = internal rogue server defense, and always verify the protocol (UDP, not TCP) for DHCP before accepting any port-blocking answer.
- What is the best explanation for the inconsistent results?
Answer: An HTTP redirect requires the initial port 80 connection to succeed unless the browser independently upgrades to HTTPS.
When a browser receives only a hostname like example.com, it defaults to HTTP on port 80. The server's job is then to respond with a redirect (typically a 301 Moved Permanently) pointing the browser to the HTTPS version. Here's the catch: that redirect response requires the initial port 80 connection to complete. If the firewall silently drops port 80 traffic, the browser never receives the redirect — it just waits until the connection times out. Users who manually type https://example.com bypass this entirely because their browser goes straight to port 443, which the firewall permits. This is exactly what option C describes, making it the correct answer.
Option A is wrong because HTTPS never negotiates over port 80. TLS handshakes happen entirely on port 443 — port 80 is plaintext HTTP only, with no role in certificate validation.
Option B is wrong because DNS is protocol-agnostic. It resolves hostnames to IP addresses regardless of whether the browser intends to use HTTP or HTTPS. DNS has no awareness of which port or protocol a client will use.
Option D is wrong because standard HTTPS uses TCP port 443, not UDP. While newer protocols like HTTP/3 use QUIC over UDP, that is not the default behavior being described here, and UDP has nothing to do with redirect mechanics.
A good study habit for firewall and redirect questions: always trace the full connection flow step by step. Ask yourself which port is touched first, because blocking any step in the chain breaks the whole process — even if the final destination port is open.
- Which firewall change most directly addresses the failures without allowing clients to query arbitrary external DNS servers?
Answer: Permit TCP port 53 from clients only to the approved resolver, while retaining the existing UDP port 53 rule.
When you see a DNS firewall question, think about the DNS protocol itself: UDP port 53 handles most queries, but when a response is too large to fit in a single UDP datagram, the resolver sets the TC (truncated) flag and signals the client to retry over TCP port 53. DNSSEC adds large cryptographic signatures to responses, making truncated replies common. If TCP port 53 is blocked, that retry never completes — exactly the failure pattern described.
A is correct because allowing TCP port 53 exclusively to the approved resolver restores the TCP fallback mechanism while keeping tight control. Clients can't query arbitrary external servers because the rule is scoped only to the approved resolver's IP. This directly fixes the truncation problem without expanding the attack surface.
B is wrong because permitting inbound UDP from any Internet host is both unnecessary and dangerous. The truncation issue is about TCP fallback, not unsolicited UDP packets. This option would also allow any external DNS server to send UDP responses to clients, undermining the approved-resolver policy entirely.
C is wrong because DNSSEC validation has nothing to do with HTTPS or TCP port 443. DNSSEC operates entirely within the DNS protocol — signatures (RRSIGs, DSes) are delivered in DNS responses, not retrieved via a separate HTTPS channel. This is a plausible-sounding but fabricated mechanism.
D is wrong because the TC flag indicates response size overflow, not rate limiting. Rate limiting would manifest as dropped queries or SERVFAIL responses, not truncation flags. Increasing a UDP packet rate has no effect on packet size limits.
Remember: TC flag = response too big = TCP retry needed. When firewall rules block TCP 53, DNSSEC-heavy domains silently break.
- Which statement best explains why the SSH connection fails?
Answer: A destination port suggests an expected service, but inspection can identify that the traffic is SSH rather than HTTPS.
When a question involves firewalls and port-based filtering, shift your thinking away from ports and toward traffic inspection. Port numbers are just metadata — they tell the firewall what service is expected, not what's actually running.
Here's the core concept: modern application-aware (or "deep packet inspection") firewalls don't just check destination ports — they analyze the actual content of packets to identify the protocol in use. HTTPS traffic has a recognizable TLS handshake structure. SSH has its own distinct handshake (beginning with a banner like SSH-2.0-...). Even though both are arriving on TCP port 443, the firewall can fingerprint the difference and drop anything that doesn't look like valid HTTPS. That's exactly why C is correct — the port merely suggests an expected service, but the firewall's inspection layer identifies the true application protocol and terminates non-compliant traffic.
A is wrong because it invents a fictional requirement — SSH servers don't request HTTPS certificates from firewalls. Port 443 carries no inherent obligation to obtain any certificate from network devices. B is wrong because SSH operates entirely over TCP; it doesn't use UDP port 22 for any authentication phase. This distractor exploits confusion between TCP and UDP. D is completely backwards — TCP port 80 carries HTTP (plaintext), not encrypted data, and port 443 is not limited to redirects. This answer reverses well-known port assignments.
Your study tip: remember that ports are conventions, not enforced contracts. Any service can bind to any port, but an application-aware firewall can still detect the true protocol through payload inspection regardless of port number.
- A site's login page is served over plain HTTP on port 80. Which change best protects passwords as they travel to the server?
Answer: Serve the site over HTTPS using TLS
HTTPS uses TLS to encrypt traffic, so passwords cannot be read while in transit. Hashing stored passwords is good practice, but it only protects the database. The password still crosses the network as readable plaintext over HTTP.
- What is the most secure correct response to the proposal?
Answer: Use stateful filtering to permit packets matching the outbound session without broadly opening ephemeral ports.
When you see a question about firewall rules and return traffic, the core concept being tested is stateful vs. stateless packet filtering. Ask yourself: does the firewall track connection context, or does it blindly evaluate each packet in isolation?
In the scenario, the workstation initiates the TCP handshake outbound. A stateful firewall records this session — source IP, destination IP, source port 51842, destination port 443 — and automatically permits the server's reply because it matches the tracked session. This is exactly what C describes. Stateful inspection grants the minimum necessary access (only packets belonging to established sessions), without writing any permanent inbound allow rules at all. It's the most secure and architecturally correct solution.
A is factually wrong on two levels: servers don't pick a new destination port for responses — they reply to whatever source port the client used — and broadly opening all high-numbered inbound ports creates a massive attack surface, violating least-privilege principles.
B contains a fundamental misunderstanding of TCP. The server's reply retains port 443 as its source port, not its destination port. The destination of the reply is the client's ephemeral port (51842). Allowing only inbound destination port 443 would block the return traffic entirely.
D is a nonsensical distractor. DHCP and HTTPS are completely unrelated protocols serving different purposes. Replacing a web encryption protocol with a network address assignment protocol solves nothing and introduces new vulnerabilities.
For the exam, remember this rule of thumb: stateful firewalls eliminate the need to manually open return-traffic ports, because session tracking handles it automatically. Any answer proposing broad static port openings as a "solution" to return traffic is almost certainly wrong.
- Which control most directly provides the requested protection?
Answer: Validate DNSSEC signatures for signed zones so forged records lacking valid signatures are rejected.
When you see a question about DNS forgery attacks (like the classic Kaminsky attack), ask yourself: what would still protect the client even if the attacker successfully guesses both the transaction ID and source port? That framing immediately rules out anything that merely makes guessing harder — you need cryptographic verification that forgery cannot bypass.
That's exactly what DNSSEC provides. By digitally signing DNS resource records using asymmetric cryptography, DNSSEC allows a resolver to verify that a response came from the authoritative zone owner. A forged record, even one with a correctly guessed transaction ID and source port, will lack a valid cryptographic signature — and the resolver will reject it. Answer D is the correct choice because it's the only control that makes the content of the response verifiable, not just the delivery channel.
Answer A is a trap — fixing the source port to 53 actually reduces entropy and makes the attacker's job easier, not harder. It removes one of the two random values an attacker must guess. Answer B is nonsensical in practice; DNS and DHCP serve entirely different purposes, and redirecting DNS queries to port 67 would simply break name resolution without providing any authentication mechanism. Answer C contains a factual error — TCP DNS responses do carry the same transaction identifiers, and TCP actually adds protection through connection establishment, so restricting to UDP-only would weaken security, not strengthen it.
A useful study tip: whenever a question asks about detecting forgery even after an attacker overcomes guessing controls, think cryptographic authentication — that's the DNSSEC pattern. Randomness reduces risk; signatures eliminate it.
- Which conclusion best accounts for the dropped DNS response?
Answer: The firewall's timer-based UDP state expired, so the late reply no longer matched an active outbound flow.
Whenever you see a question about stateful firewalls and dropped packets, focus on how stateful inspection tracks connections — especially for connectionless protocols like UDP, which rely entirely on timers rather than handshake signals.
Stateful firewalls maintain a session table. For UDP, when an outbound packet leaves (here: source port 53000 → destination port 53), the firewall creates a temporary state entry and starts an idle timer. If no matching return traffic arrives before that timer expires, the entry is deleted. In this scenario, the firewall's UDP idle timeout is 30 seconds, but the DNS response arrived 35 seconds later — 5 seconds too late. With no active state entry remaining, the firewall has no record that this response belongs to a legitimate outbound request, so it drops the packet. That's exactly what B describes, making it the correct answer.
A is wrong because DNS does not automatically switch transports on delay — TCP is used for DNS only under specific conditions (e.g., responses exceeding 512 bytes or zone transfers), not based on response latency.
C is wrong because DNS clients use ephemeral (high-numbered) source ports, not port 53. Port 53 is the server's well-known destination port. Source port 53000 is perfectly valid.
D is wrong because stateful firewalls track return traffic based on flow state (IP, port, protocol tuples) — not on whether the application uses HTTPS encryption. HTTPS working fine is irrelevant to UDP DNS behavior.
For your exam, remember: UDP state = timer-only. If the response is late and the timer expired, the firewall treats it as unsolicited traffic and drops it — regardless of what the packet actually is.
