Cyber Security Quiz: Ports And Common Protocols
10 questions · exam conditions
0:00
Ports And Common ProtocolsQuestion 1 of 10

A public website is configured to redirect every HTTP request to HTTPS. Administrators allow inbound TCP port 443 through the firewall but deny inbound TCP port 80. Users who enter the full HTTPS URL succeed, while many users who enter only the hostname report a timeout.

What is the best explanation for the inconsistent results?

HTTPS initially negotiates over port 80 and then changes to port 443 after the server certificate is validated.
DNS returns different addresses depending on whether a browser intends to use HTTP or HTTPS for the request.
An HTTP redirect requires the initial port 80 connection to succeed unless the browser independently upgrades to HTTPS.
The firewall must permit UDP port 443 because browsers use UDP for all HTTPS connections before redirecting.
← Back to quizzes

Cyber Security Quiz

Cyber Security Quiz: Ports And Common Protocols

Practice Ports And Common Protocols in Cyber Security with focused quiz questions that help you check what you know, review explanations, and build confidence with test-style prompts.

What this quiz covers

This quiz focuses on Ports And Common Protocols, giving you a quick way to practice the rules, question types, and explanations that matter most for Cyber Security.

How to use this quiz

Try each quiz question before looking at the correct answer. Use the explanations to review missed ideas, then come back to similar questions until the pattern feels familiar.

All questions

Question 1

A public website is configured to redirect every HTTP request to HTTPS. Administrators allow inbound TCP port 443 through the firewall but deny inbound TCP port 80. Users who enter the full HTTPS URL succeed, while many users who enter only the hostname report a timeout.

What is the best explanation for the inconsistent results?

  1. HTTPS initially negotiates over port 80 and then changes to port 443 after the server certificate is validated.
  2. DNS returns different addresses depending on whether a browser intends to use HTTP or HTTPS for the request.
  3. An HTTP redirect requires the initial port 80 connection to succeed unless the browser independently upgrades to HTTPS. (correct answer)
  4. The firewall must permit UDP port 443 because browsers use UDP for all HTTPS connections before redirecting.
Explanation: 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.

Question 2

A company publishes an administrative web interface as https://gateway.example:8443. Its edge device translates external TCP port 8443 to TCP port 443 on an internal management server. An external scanner reports that port 443 on the edge device is closed.

Which conclusion is best supported by this information?

  1. The management interface is unreachable because HTTPS can function only when the externally visible destination port is 443.
  2. The interface is reachable only with UDP because port translation cannot change destination ports for TCP connections.
  3. The interface must be using SSH because any encrypted service on a nonstandard port is interpreted as TCP port 22.
  4. The interface may remain reachable through external port 8443, which the edge device maps to internal port 443. (correct answer)
Explanation: 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.

Question 3

To pass through a restrictive egress firewall, an administrator configures an SSH server to listen on TCP port 443. The firewall permits outbound port 443, but its application-aware policy allows only valid HTTPS and terminates the connection after inspecting the first packets.

Which statement best explains why the SSH connection fails?

  1. Port 443 guarantees TLS encryption, so the SSH server must first request an HTTPS certificate from the firewall.
  2. SSH requires UDP port 22 for authentication even when its main data channel listens on TCP port 443.
  3. A destination port suggests an expected service, but inspection can identify that the traffic is SSH rather than HTTPS. (correct answer)
  4. TCP port 443 can carry only HTTP redirects, while encrypted application data must use TCP port 80.
Explanation: 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.

Question 4

A stateful firewall records an outbound DNS query from UDP source port 53000 to destination port 53. The DNS response arrives 35 seconds later and is dropped. The firewall's UDP idle timeout is 30 seconds. TCP-based HTTPS sessions through the same firewall continue to work.

Which conclusion best accounts for the dropped DNS response?

  1. The firewall expected the DNS server to reply from TCP port 53 because all delayed DNS responses switch transports automatically.
  2. The firewall's timer-based UDP state expired, so the late reply no longer matched an active outbound flow. (correct answer)
  3. The client selected an invalid source port because DNS clients must always use UDP source port 53.
  4. The DNS response was rejected because stateful firewalls permit return traffic only for protocols that use HTTPS encryption.
Explanation: 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.

Question 5

Endpoints are permitted to send DNS requests only to an internal recursive resolver. The resolver alone may send UDP or TCP port 53 traffic to the Internet. Malware on an endpoint repeatedly requests long, unique subdomains beneath a domain controlled by an attacker.

Why can data exfiltration still occur despite the endpoint DNS restriction?

  1. The internal resolver can relay attacker-controlled query names outward while performing recursion, even though the endpoint cannot query externally. (correct answer)
  2. The endpoint can establish SSH sessions through the resolver because every DNS query automatically opens TCP port 22.
  3. The endpoint can convert the query into DHCP broadcasts, which Internet routers forward to the attacker's authoritative server.
  4. The resolver decrypts HTTPS traffic on port 443 and places the recovered content into ordinary DNS cache entries.
Explanation: 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.

Question 6

An organization permits outbound DNS queries to its approved resolver over UDP port 53 but blocks TCP port 53. Most name lookups succeed. However, lookups for several DNSSEC-enabled domains fail after the resolver returns a response with the truncated flag set.

Which firewall change most directly addresses the failures without allowing clients to query arbitrary external DNS servers?

  1. Permit TCP port 53 from clients only to the approved resolver, while retaining the existing UDP port 53 rule. (correct answer)
  2. Permit inbound UDP port 53 from any Internet host, because truncated responses require unsolicited UDP packets.
  3. Permit TCP port 443 to the approved resolver, because DNSSEC validation normally retrieves signatures through HTTPS.
  4. Increase the maximum UDP packet rate, because the truncated flag indicates that the resolver is being rate-limited.
Explanation: 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.

Question 7

A workstation may make outbound TCP connections only to port 22 on a hardened bastion host. An administrator runs ssh -L 8443:intranet.example:443 bastion.example and then opens https://localhost:8443 in a browser.

Which description most accurately identifies the resulting network traffic?

  1. The workstation sends HTTPS directly to the intranet server on port 8443, bypassing the bastion after SSH authentication.
  2. The workstation carries local port 8443 traffic inside SSH on port 22, and the bastion connects to intranet port 443. (correct answer)
  3. The workstation converts HTTPS into DNS over port 53, and the bastion reconstructs the original TCP connection.
  4. The workstation opens an inbound SSH service on port 8443, allowing the intranet server to initiate the connection.
Explanation: 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.

Question 8

A workstation initiates an HTTPS connection using TCP source port 51842 and destination port 443. The web server replies from TCP source port 443 to destination port 51842. A security analyst proposes allowing all unsolicited inbound traffic to high-numbered destination ports so web responses will work.

What is the most secure correct response to the proposal?

  1. Allow every inbound high-numbered port, because servers dynamically select a new client destination port for each individual HTTPS response they send.
  2. Allow inbound TCP port 443 only, because server replies always retain port 443 as their destination port when responding to HTTPS clients.
  3. Use stateful filtering to permit packets matching the outbound session without broadly opening ephemeral ports. (correct answer)
  4. Replace HTTPS with UDP-based DHCP, because DHCP responses are self-contained broadcasts that do not require tracked return traffic through the firewall.
Explanation: 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.

Question 9

Employees on one office floor intermittently receive an incorrect default gateway and DNS server. The security team discovers that a personal wireless router connected to an access port is responding to DHCP requests. The perimeter firewall already blocks inbound DHCP traffic from the Internet.

Which action would most directly prevent this attack while preserving authorized address assignment?

  1. Block TCP ports 67 and 68 at the perimeter, because DHCP servers establish TCP sessions with each client.
  2. Enable DHCP snooping on access switches and trust only ports leading to authorized DHCP infrastructure. (correct answer)
  3. Require HTTPS on the default gateway, because encrypted web traffic prevents false DHCP configuration.
  4. Block outbound UDP port 53 from clients, because rogue DHCP servers depend on external DNS responses.
Explanation: 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.

Question 10

An off-path attacker sends forged UDP DNS responses to a client, guessing the transaction identifier and the client's UDP source port. The organization wants a control that allows the client or resolver to detect forged DNS records even if the attacker eventually guesses both values.

Which control most directly provides the requested protection?

  1. Fix the client source port at UDP port 53 so legitimate DNS responses always return to a predictable socket.
  2. Redirect DNS queries to DHCP port 67 so only an authorized address server can answer them.
  3. Allow DNS only over UDP because TCP responses do not include identifiers that can be checked.
  4. Validate DNSSEC signatures for signed zones so forged records lacking valid signatures are rejected. (correct answer)
Explanation: 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.