Networking and Protocols practice questions

Abnormally high transaction ID variance within recursive DNS server query logs.

Why it fails: Randomizing transaction IDs is a defense mechanism against cache poisoning rather than an indicator of compromise. Low variance or predictable transaction IDs indicate vulnerable resolver implementations that allow spoofed responses to succeed.क्क

Disabling all outbound UDP traffic on ports other than 53 and 123 across gateways.

Why it fails: Blocking arbitrary UDP traffic does not stop cache poisoning, because valid DNS queries natively utilize UDP port 53. Restricting outbound ports fails to address the underlying vulnerability of unvalidated response records coming from authoritative servers.क्क

The server received a duplicate ACK for data it had already acknowledged and used RST to signal the error.

Why it fails: Duplicate ACKs are normal in TCP and are used to trigger fast retransmission, not connection resets. A receiver that gets duplicate data simply discards it and re-acknowledges; it does not send RST. The reset flag indicates a serious state mismatch, such as a segment for a nonexistent connection, not routine duplicate acknowledgment handling.

The client sent a SYN with an invalid checksum, so the server rejected the connection with RST.

Why it fails: A segment with an invalid checksum is silently discarded by the receiving TCP stack; it does not generate a reset. Moreover, the scenario states the handshake completed, which means the SYN was accepted and the connection was established. A checksum failure would have prevented the handshake from completing, so this explanation contradicts the observed sequence of events.

The server's firewall detected the request payload as malicious and injected a RST to tear down the session.

Why it fails: A firewall or IPS can inject RST packets to terminate connections, but that behavior is a deliberate configuration, not something inferred from the mere presence of a reset. The scenario describes a generic server response after a request, and the more fundamental TCP behavior is that a stack resets segments it cannot associate with a connection. Without evidence of an inline device, firewall injection is speculative and less likely.

TCP connection state tables showing persistent half-open sessions on port 53.

Why it fails: Standard DNS primarily operates over UDP port 53 for standard queries and responses, meaning TCP connection states are less indicative of core tunneling activity unless zone transfers occur, making this metric ineffective for spotting high-entropy payload distribution.क्क

Frequent receipt of ICMP Destination Unreachable messages indicating blocked UDP traffic.

Why it fails: ICMP Destination Unreachable messages indicate routing or firewall blocks rather than DNS tunneling payloads. While firewalls might block unauthorized ports, examining ICMP error messages fails to reveal the specific data-hiding characteristics inherent to malicious DNS queries.क्क

Elevated round-trip time latency on standard HTTP GET requests traversing proxy servers.

Why it fails: Elevated round-trip latency on HTTP GET requests describes web proxy performance, whereas DNS tunnelling hides data in query and response payloads, detectable through unusually long or high-entropy DNS labels and record-type abuse. Latency monitoring is tempting because tunnelling does add overhead, but it is the correct focus for proxy troubleshooting.

Implementing Port Security along with Static ARP entries on all critical endpoints.

Why it fails: Port Security limits MAC address learning per interface, but it fails to inspect ARP payloads or prevent malicious DHCP allocation. Static ARP entries do not scale in enterprise environments and cannot prevent dynamic ARP poisoning attacks launched by sophisticated malicious actors.क्क

Enabling BPDU Guard and Root Guard on all designated edge access ports.

Why it fails: BPDU Guard and Root Guard protect the Spanning Tree Protocol topology from unauthorized switches attempting to become the root bridge. These mechanisms do not validate IP-to-MAC bindings or inspect DHCP traffic, leaving the network vulnerable to ARP spoofing and rogue IP assignment.क्क

Configuring VLAN Access Control Lists alongside private VLAN isolated port modes.

Why it fails: Private VLANs and VACLs restrict inter-port communication within the same VLAN and filter traffic based on network layers. However, they lack the ability to inspect dynamic ARP packets or validate DHCP lease allocations against a trusted database to prevent spoofing.क्क

Enabling remote attackers to execute arbitrary shell commands via buffer overflows in the ICMP daemon.

Why it fails: ICMP messages do not execute remote shell code directly, as the protocol is designed for diagnostic messaging rather than application-layer processing. While parsing vulnerabilities can exist, the primary risk is information leakage rather than arbitrary code execution.क्क

Exposing internal private IP address ranges through embedded DNS zone transfer responses.

Why it fails: ICMP Timestamp carries no DNS payload and cannot trigger zone transfers; that risk belongs to misconfigured DNS servers permitting AXFR from untrusted hosts. The confusion is tempting because both are reconnaissance vectors, but the actual timestamp exposure is host clock and uptime disclosure, not internal addressing.

Facilitating high-bandwidth distributed denial-of-service reflection attacks using small spoofed packets.

Why it fails: ICMP Timestamp is a low-volume, non-amplifying query; it cannot generate the traffic multiplication that reflection DDoS requires, unlike ICMP Echo with large payloads or DNS. The DDoS framing is tempting because ICMP is abused in floods, but timestamp replies are roughly equal in size to requests.

Deploying a traditional static packet-filtering firewall with inbound rule sets.

Why it fails: Static packet filters match only addresses, ports and protocols, and the inbound rule sets described do not inspect or restrict outbound sessions at all. Such firewalls are tempting for simple perimeter filtering, and would suit environments needing basic inbound access control rather than egress inspection.

Configuring port security on all access layer switch ports to limit MAC addresses.

Why it fails: Port security operates strictly at Layer 2 to limit device connections and MAC address learning per port. It has no visibility into Layer 4 ports or Layer 7 protocols leaving the network across the WAN perimeter.क्क

Implementing WPA3 Enterprise wireless security across all corporate access points.

Why it fails: WPA3 Enterprise secures wireless link-layer authentication between clients and access points; it exerts no control over outbound traffic leaving a server on the wired network. It is tempting as a recognised enterprise security standard, and would suit protecting Wi-Fi confidentiality and access, not perimeter egress filtering.

The workstation is performing a standard DNS resolution process.

Why it fails: DNS resolution typically occurs over UDP port 53 or occasionally TCP port 53 for zone transfers. The described behavior involves SYN packets targeting random high-range ports rather than a specific recursive resolver. This pattern lacks the signature of standard client-server DNS communication protocols.

The system is initiating a legitimate peer-to-peer file transfer.

Why it fails: Peer-to-peer protocols establish full TCP connections to exchange data. The absence of SYN-ACK responses followed by ACK packets indicates that no data transmission is intended. Legitimate P2P applications would successfully handshake with remote nodes rather than simply leaving connections in a half-open state.

The network interface is experiencing a broadcast storm.

Why it fails: Broadcast storms involve excessive traffic directed to the broadcast address, consuming bandwidth and CPU across the local segment. SYN packets targeting random external IP addresses are unicast in nature and represent directed traffic, not the flooding characteristics associated with layer 2 broadcast storms.

Telnet

Why it fails: Telnet transmits data, including authentication credentials, in cleartext. Because it lacks any form of encryption or integrity checking, it is inherently insecure for sensitive communication. Modern security standards mandate the replacement of Telnet with encrypted alternatives like SSH to prevent unauthorized data interception and credential harvesting.

HTTP

Why it fails: HTTP is an unencrypted protocol used primarily for web traffic. It provides no confidentiality or integrity mechanisms for the data being transferred. Without the addition of TLS, HTTP traffic is susceptible to man-in-the-middle attacks where attackers can easily view or modify the contents of the requests.

SNMPv1

Why it fails: SNMPv1 relies on community strings passed in cleartext for authentication. It offers no encryption capabilities, making it unsuitable for protecting sensitive data. The protocol was designed for network management efficiency rather than security, and its use is highly discouraged in environments requiring confidentiality and data integrity.

UDP provides guaranteed delivery of packets.

Why it fails: UDP does not provide any mechanism for verifying that a packet reached its destination. There are no sequence numbers or acknowledgments, meaning packets can be lost, duplicated, or arrive out of order without the application layer being notified or corrective actions being taken by the protocol.

UDP uses flow control to manage data transmission rates.

Why it fails: Flow control is a feature specific to TCP, utilizing sliding windows to ensure the sender does not overwhelm the receiver. UDP lacks flow control mechanisms entirely, which means a sender can transmit data as fast as the network interface allows, potentially causing significant packet loss at the destination.

UDP is the primary protocol for HTTP web traffic.

Why it fails: HTTP and HTTPS utilize TCP to ensure the reliable delivery of web content. Because web pages rely on the complete and accurate receipt of HTML, CSS, and image files, the reliable, connection-oriented nature of TCP is necessary. UDP would result in corrupted or missing webpage elements.

Enabling private VLAN edge isolation between access ports

Why it fails: Private VLAN edge, also called port isolation, prevents hosts on the same switch from communicating directly with one another by forcing traffic through an uplink. It can limit lateral movement, but it does not validate ARP contents, and in many designs the attacker and victim would still share a path to the gateway. It also disrupts legitimate peer-to-peer traffic, making it a poor fit for the stated requirement.

Deploying 802.1X port-based network access control on access ports

Why it fails: 802.1X authenticates devices before granting them access to the switch port, which stops unauthorized devices from connecting at all. However, once a legitimate device is authenticated and its port is authorized, it can still send forged ARP replies to other hosts. Because the attack in this scenario comes from an already-connected host, 802.1X alone does not prevent the spoofed ARP reply from being accepted.

Enabling Spanning Tree Protocol on all access switches

Why it fails: Spanning Tree Protocol prevents Layer 2 loops by blocking redundant paths between switches, but it does not validate ARP replies or bind IP addresses to MAC addresses. An attacker on the same access port can still send a forged ARP reply that the workstation accepts, because the switch simply forwards the frame. STP addresses topology loops, not ARP spoofing, so it would not stop this attack.

Create an EtherChannel bundle between the sensor and the switch, and enable trunking on the link.

Why it fails: An EtherChannel trunk aggregates bandwidth and carries multiple VLANs, but it does not copy traffic from other ports. The sensor would only see frames the switch chooses to forward out that link, which excludes the unicast conversation between the two hosts. Aggregation and trunking change capacity and tagging, not visibility, so this does not meet the monitoring requirement.

Configure a SPAN session on the switch, designating the sensor port as the source and the monitored host ports as the destination.

Why it fails: This reverses the roles of source and destination. In a SPAN configuration, the monitored traffic originates from the source ports or VLAN, and the copy is delivered to the destination port where the analysis device resides. Making the sensor the source would cause the switch to mirror whatever the sensor transmits to the hosts, which is the opposite of the required monitoring design.

Enable promiscuous mode on the sensor NIC and connect it to an access port in the same VLAN as the two hosts.

Why it fails: Promiscuous mode lets a NIC accept frames not addressed to its MAC, but on a switch each access port only receives unicast frames destined to the devices behind it plus broadcasts. The sensor would not see the unicast conversation between the two other hosts. Promiscuous mode alone cannot overcome the switch's forwarding table behavior; port mirroring or a tap is required.

The server's TCP initial sequence number, which is randomized to prevent session hijacking.

Why it fails: Randomized initial sequence numbers make off-path TCP injection harder by preventing an attacker from guessing the next expected sequence value. That is a transport-layer integrity measure, not an identity check. It says nothing about who operates the server, does not involve certificates or keys, and would not satisfy the analyst's goal of confirming the server's authenticated identity before data transfer.

The HTTP Host header, which tells the server which virtual host the client intends to reach.

Why it fails: The Host header is an application-layer field used for virtual host routing; it is supplied by the client and is trivially spoofable. It does not authenticate the server and, in TLS, is normally encrypted inside the tunnel. An attacker could present any certificate while the Host header still names the legitimate site, so this header cannot verify server identity in the scenario described.

The TCP SYN, SYN-ACK, ACK sequence confirms the server's identity before data transfer.

Why it fails: The three-way handshake only establishes a reliable transport connection and synchronizes sequence numbers; it carries no cryptographic proof of the server's identity. Any host that answers on port 443 would complete the handshake. In this scenario the analyst needs proof tied to a certificate and key, which the handshake cannot supply, so relying on the SYN/SYN-ACK/ACK exchange would misidentify the security control actually protecting the session.

UDP ports 53 and 54, because the address server acts as a directory service.

Why it fails: Port 53 is associated with DNS, not address assignment. While DHCP can inform a client of DNS servers, the assignment exchange itself does not run on port 53 or 54. Confusing the directory-service function of DNS with DHCP's address leasing role leads to the wrong ports. The observed broadcast offer and acknowledgment pattern is characteristic of DHCP, not of any DNS query or zone transfer.

ICMP type 4 and type 5 messages, because routers advertise addresses to local hosts.

Why it fails: ICMP types 4 and 5 relate to source quench and redirect messages, not address assignment. ICMP Router Discovery historically used types 9 and 10, and even that did not assign addresses with leases. The described four-message exchange with a broadcast request and unicast offer is DHCP's DORA sequence, so ICMP message types cannot account for the observed traffic or the port numbers involved.

TCP ports 67 and 68, because address assignment requires a reliable connection.

Why it fails: DHCP does not use TCP. The exchange relies on broadcast, which TCP cannot perform because TCP requires an established connection between known endpoints before data flows. A client with no address cannot form such a connection, so a reliable transport is impossible here. Naming TCP ports 67 and 68 confuses the well-known DHCP port numbers with the transport protocol, which is the error this distractor is designed to catch.

VLANs assigned by physical switch port with inter-VLAN routing disabled.

Why it fails: VLANs provide Layer 2 isolation and can limit broadcast domains, but they are tied to physical port or subnet boundaries and do not scale to per-workload identity policy. Disabling inter-VLAN routing blocks all inter-VLAN traffic, which is too coarse and does not enforce identity-based rules. It also fails in virtualized environments where workloads move between hosts, so it does not satisfy the design goal.

A perimeter firewall with rules based on source and destination IP addresses.

Why it fails: A perimeter firewall governs north-south traffic entering and leaving the data center, not lateral movement between internal workloads. IP-based rules also fail when workloads are dynamic, because addresses change and can be spoofed. It does not enforce policy based on workload identity and leaves east-west traffic largely unrestricted, so it does not meet the stated requirement.

802.1X port-based network access control on all switch ports.

Why it fails: 802.1X authenticates devices or users before granting access to a switch port, which is valuable for network admission control. However, it controls initial access, not ongoing east-west traffic between workloads already on the network. Once a device is authenticated, 802.1X does not enforce per-workload policy or prevent lateral movement between servers, so it does not meet the stated design goal.

The internal server uses a smaller TCP receive window than the client advertises during the handshake.

Why it fails: The TCP receive window governs flow control, not path MTU. A smaller window limits how much unacknowledged data can be in flight, which can reduce throughput but does not cause large packets to be dropped while small ones succeed. Window size negotiation is a performance tuning matter and cannot explain the fragmentation-related drop pattern observed in the capture.

The client's DNS resolver returns a stale record pointing to a decommissioned server address.

Why it fails: A stale DNS record would cause connection failures to a specific host regardless of packet size, not a pattern where small packets pass and large ones drop. The capture shows the tunnel is up and some traffic succeeds, so name resolution is functioning. DNS caching issues do not produce fragmentation-related, size-dependent drops on an established path.

The client and server negotiated a weak cipher suite during the VPN handshake.

Why it fails: Cipher suite strength affects confidentiality and integrity, not packet size handling. A weak cipher would not selectively drop large packets, and modern suites have negligible effect on MTU. The symptom of small packets succeeding while large packets fail is a size-dependent forwarding problem, so cryptographic negotiation parameters are irrelevant to the described fault.

netstat -an

Why it fails: netstat -an lists local sockets and their states; it shows whether the workstation has open connections but says nothing about DNS resolution. The user can already reach the application by IP, so socket state is not the failing component. Running netstat would not confirm whether the hostname resolves, making it a poor first diagnostic choice for this specific symptom.

ipconfig /all

Why it fails: ipconfig /all displays adapter configuration, including the configured DNS server addresses, but it does not perform a lookup. It can confirm that a DNS server is configured, yet it cannot tell the technician whether that server resolves the internal name. Since the scenario already states the DNS server address is reachable, this command adds little diagnostic value compared with an actual query.

tracert app.internal.example.com

Why it fails: tracert traces the Layer 3 path to a destination and requires the destination to be resolvable to an IP first. If name resolution is the problem, this command fails before it can produce useful path information, or it resolves the name using the same broken resolver. It does not isolate DNS from routing, so it is not the best first step here.

VLAN hopping, where the attacker injects double-tagged frames to reach a different VLAN.

Why it fails: VLAN hopping involves manipulating 802.1Q tags, such as double tagging or switch spoofing, to cross VLAN boundaries. It does not inherently cause a switch port to learn many distinct MAC addresses. While both are Layer 2 attacks, the signature described, a flood of source MACs on one port, points elsewhere. Confusing the two techniques would send the analyst toward the wrong mitigation, such as pruning VLANs rather than port protection.

ARP spoofing, where the attacker sends forged ARP replies to associate their MAC with a victim's IP address.

Why it fails: ARP spoofing poisons hosts' ARP caches so traffic is sent to the attacker's MAC. It typically involves a small number of MAC-to-IP mappings, not a flood of distinct source MAC addresses on a single port. The switch log signature differs: ARP spoofing produces many ARP replies but few unique source MACs, whereas the scenario shows an abnormal volume of learned addresses.

STP root bridge takeover, where the attacker sends superior BPDUs to become the root of the spanning tree.

Why it fails: An STP root bridge takeover involves sending crafted Bridge Protocol Data Units with a lower bridge ID to win the root election and reposition the topology so traffic traverses the attacker. It does not cause a port to learn a large number of MAC addresses. The described CAM table growth is unrelated to spanning-tree topology manipulation and would not be detected through MAC learning logs.

Publish the internal application through a reverse proxy that uses basic authentication over HTTPS.

Why it fails: Basic authentication transmits reusable credentials with each request, and although HTTPS protects them in transit, the credentials remain vulnerable to phishing and replay if captured elsewhere. There is no second factor and no strong server identity validation described. This does not adequately protect against credential theft or MITM, so it fails the security requirements of the scenario.

Deploy an IPsec VPN that requires a client certificate issued to each device.

Why it fails: Requiring a client certificate provides strong mutual authentication, but it directly violates the constraint that no client certificate be installed on personal devices. Provisioning and managing certificates on unmanaged devices is also operationally impractical. Although secure, this approach does not meet the stated requirement, so it cannot be the correct design.

Deploy an IPsec VPN with pre-shared keys distributed to each employee's device.

Why it fails: Pre-shared keys are shared secrets that are difficult to distribute securely and do not scale; if one device is compromised, the key must be changed for everyone. They also do not provide strong per-user authentication or resistance to phishing. The scenario requires protection against credential theft and MITM without client certificates, and pre-shared keys introduce operational and security weaknesses that fail that requirement.

A DNS amplification attack, where spoofed queries generate large responses aimed at a victim.

Why it fails: DNS amplification spoofs the source address of queries so that large responses are directed at a third-party victim, multiplying bandwidth. It originates from many reflectors and targets one victim, not from a single internal host maintaining an ongoing dialogue with one domain. The scenario involves bidirectional encoded exchanges from a compromised internal host, which is tunneling rather than reflection-based amplification.

DNS cache poisoning, where forged responses insert malicious records into a resolver's cache.

Why it fails: Cache poisoning injects false records so subsequent lookups return attacker-controlled addresses, usually with a small number of forged responses targeting a specific victim record. It does not involve a sustained high volume of unique encoded subdomains from one host. The described pattern is continuous bidirectional data exchange, characteristic of tunneling, whereas poisoning is a discrete redirection attack affecting other clients' resolutions.

A zone transfer abuse, where the attacker pulls the entire DNS zone from an authoritative server.

Why it fails: Zone transfers use AXFR or IXFR over TCP and copy a full zone from an authoritative server, typically producing one large synchronous response rather than a sustained stream of many small queries. The scenario shows continuous query-response pairs with encoded labels, which is bidirectional tunneling. Zone transfer abuse is a reconnaissance and data-exposure issue, not a covert command-and-control channel, so this classification is incorrect.

VLAN hopping

Why it fails: VLAN hopping allows an attacker to send traffic to a different VLAN by exploiting switch trunking or double-tagging. It does not involve ARP replies or gateway MAC address manipulation. The evidence here is ARP-based deception, not VLAN segmentation bypass. Therefore, VLAN hopping is unrelated to the observed unsolicited ARP replies and MAC mismatch.

DHCP starvation

Why it fails: DHCP starvation exhausts the DHCP server's address pool by flooding it with requests using spoofed MAC addresses, preventing legitimate clients from obtaining IP configurations. It does not involve unsolicited ARP replies or gateway MAC mismatches. The observed traffic is specifically ARP-related and targets the gateway mapping, so DHCP starvation is not the correct classification.

MAC flooding

Why it fails: MAC flooding overwhelms a switch's CAM table with numerous fake source MAC addresses, causing the switch to fail open and broadcast traffic. While it can lead to traffic interception, it does not generate unsolicited ARP replies with incorrect IP-to-MAC mappings. The scenario explicitly describes ARP replies claiming the gateway IP maps to an unknown MAC, which is not a characteristic of MAC flooding.