Network Security Devices practice questions

SSL Forward Proxy inspection

Why it fails: SSL Forward Proxy is designed for outbound traffic where internal clients browse the external internet. It intercepts outbound TLS connections by dynamically signing certificates with a local forward trust certificate, which does not address inbound connections to internal web servers.

SSH Proxy tunneling with asymmetric key exchange

Why it fails: SSH proxy tunneling is specifically built for secure shell remote management traffic and administrative file transfers. It does not handle inbound HTTPS web traffic inspection or TLS handshake termination for standard web applications.

Transparent proxy mode without certificate installation

Why it fails: Transparent proxy mode intercepts TCP traffic at Layer 3 or 4 without modifying IP addresses, but it cannot decrypt TLS traffic without access to the corresponding private keys or a trusted enterprise certificate authority infrastructure.

It alters the destination IP address of incoming packets to perform network address translation across subnets.

Why it fails: Layer 2 transparent firewalls do not perform routing or network address translation. They evaluate frames based on MAC addresses and upper-layer payloads while preserving original network layer headers, routing configurations, and IP addressing schemes.

It requires a complete redesign of the core routing table and gateway IP assignments across all internal subnets.

Why it fails: One of the primary benefits of transparent firewall deployment is that no network redesign or IP subnet renumbering is necessary. Routers and switches remain the default gateways for end hosts, preserving existing gateway assignments entirely.

It operates strictly at Layer 3 of the OSI model, requiring static routes for every connected subnet.

Why it fails: Operating at Layer 3 is a characteristic of routed mode firewalls, not transparent mode. Transparent firewalls function below the network layer, forwarding frames based on bridging tables rather than making routing decisions via network layer headers.

IPsec site-to-site virtual private network tunnel termination

Why it fails: IPsec VPN termination is handled by the crypto map command referencing VPN-MAP. The class map and policy map configuration sections handle Layer 3 and Layer 7 traffic classification and QoS enforcement, which are separate from crypto map operations.

Stateful packet inspection inspecting TCP connection state tables

Why it fails: Stateful packet inspection tracks connection states such as SYN, ESTABLISHED, and FIN to permit or deny return traffic. The configuration shown uses static class matching based on protocol and packet length rather than maintaining a dynamic connection state table.

Deep packet inspection utilizing signature databases to block malware payloads

Why it fails: Deep packet inspection requires advanced signature inspection engines to scan application payloads for malware strings. Matching HTTP protocol and packet length parameters is a structural classification method, not signature-based malware detection.

The number of static IP routing tables supported by the device operating system

Why it fails: Inline IPS devices typically operate as transparent bridges or layer 2 inspection tools rather than core routing devices. The size of the routing table is largely irrelevant to the packet-processing and inspection performance of an inline security sensor.

Network time protocol synchronization accuracy across global time zones

Why it fails: Network time synchronization is essential for accurate log correlation and forensic timeline analysis across multiple security devices. However, NTP accuracy does not directly impact the real-time packet processing throughput or latency performance of an inline IPS.

The total physical rack unit size and power supply voltage requirements in the data center

Why it fails: Physical rack units and power specifications dictate data center facility planning and rack layout, but they do not directly determine the packet inspection speed, latency impact, or data-plane throughput capacity of the security device.

Manually create an inbound allow rule for the high-numbered port.

Why it fails: Manually opening a high-numbered port creates a permanent security hole. If the firewall is stateful, this is unnecessary because the device is designed to track session states automatically. Static rules increase the risk of unauthorized access if the application port is ever hijacked by a malicious service.

Disable the firewall's stateful inspection engine for the database segment.

Why it fails: Disabling stateful inspection removes the primary security benefit of the firewall, forcing the administrator to manage every packet individually via access control lists. This approach is prone to configuration errors and makes it impossible for the firewall to distinguish between legitimate responses and unsolicited inbound malicious traffic.

Implement a transparent bridge mode to bypass stateful inspection.

Why it fails: Transparent mode allows the firewall to sit in the network path without changing IP headers, but it does not disable inspection logic. Bypassing inspection entirely would remove the security benefits of the device, rendering it incapable of tracking sessions or protecting the internal database from external threats.

Network Address Translation (NAT) overloading

Why it fails: NAT overloading maps multiple private IP addresses to a single public IP address using distinct source ports to facilitate internet access. It alters packet headers and is used for routing, not for capturing or duplicating traffic for security analysis.

Virtual Router Redundancy Protocol (VRRP) failover

Why it fails: VRRP provides default gateway redundancy by electing a master router, so it addresses availability rather than traffic visibility. It is configured where hosts need a resilient next-hop address, whereas capturing raw packets requires port mirroring or a SPAN/TAP configuration on the switch.

Dynamic Host Configuration Protocol (DHCP) snooping

Why it fails: DHCP snooping filters rogue DHCP server offers by inspecting DHCP messages on untrusted ports; it does not copy frames to a monitoring destination. It is deployed to prevent DHCP spoofing and starvation attacks, not to mirror east-west traffic for packet capture.

It automatically injects TCP reset (RST) packets into the stream to terminate the active session.

Why it fails: Injecting TCP reset packets to terminate an active session is a capability of an inline Intrusion Prevention System (IPS) or a firewall with active TCP resetting enabled. A passive IDS lacks the inline interface placement required to alter live traffic streams.

It drops the malicious packets at the interface level to protect the internal workstation from further compromise.

Why it fails: Dropping malicious packets requires inline placement where the security device sits directly in the path of packet forwarding. A passive IDS receives only mirrored copies of traffic and cannot drop live packets passing through the core switch.

It dynamically updates the core switch routing table to quarantine the infected workstation into an isolated VLAN.

Why it fails: A passive IDS receives a copy of traffic and generates alerts; it holds no forwarding path to the switch and cannot alter VLAN membership or routing. Dynamic quarantine is performed by an IPS inline or by integration with network access control, so this option describes a capability the sensor lacks.

The traffic is permitted because the second rule matches the source subnet.

Why it fails: ACLs are processed sequentially. The first line of the configuration is a deny statement that matches all IP traffic directed at the specific host and port. Once a packet matches a deny rule, the router drops the packet immediately, preventing any evaluation of the later permit statement.

The traffic is permitted because permit rules take precedence over deny rules.

Why it fails: ACLs do not prioritize permit rules over deny rules; they prioritize the order of the rules as they appear in the configuration. The router follows the logic provided by the administrator, and because the deny rule is placed first, it overrides any subsequent permit commands for matching packets.

The router generates an error because the ACL rules are contradictory.

Why it fails: The router does not check for logic errors or shadowed rules when applying an ACL. It simply follows the list from top to bottom. While the rules are technically redundant and poorly ordered for the administrator's goal, the router will execute them exactly as configured without throwing errors.

Configure the IPS in tap mode with a fail-open bypass so it can inspect traffic without being in the forwarding path.

Why it fails: Tap mode copies traffic to the IPS but does not allow inline blocking; the IPS cannot drop malicious packets because it is not in the forwarding path. A fail-open bypass only helps availability if the IPS fails, but it does not satisfy the requirement to block exploits. This option would leave the network vulnerable to attacks that the IPS detects but cannot prevent.

Enable full packet capture on the IPS to record all traffic for forensic analysis, accepting the performance overhead.

Why it fails: Full packet capture is storage-intensive and can degrade throughput, which is unacceptable on a latency-sensitive 10 Gbps link. While forensic data is valuable, it is not the most critical factor when the priority is blocking exploits without disrupting patient monitoring. This option would likely introduce delays and potential packet loss, harming real-time clinical operations.

Deploy the IPS in promiscuous mode and rely on span ports to mirror traffic from the core switch.

Why it fails: Promiscuous mode with span ports is a passive monitoring deployment; the IPS can detect but not block attacks because it is not inline. This fails the requirement to block exploits. Additionally, span ports can drop packets under high load, reducing inspection accuracy. The scenario explicitly requires inline blocking, so this approach is unsuitable.

Access control lists (ACLs) applied to the inbound interface

Why it fails: ACLs are static rules that filter traffic based on IP addresses, ports, and protocols. They do not dynamically allow return traffic for outbound sessions. If an ACL is blocking return traffic, it would need an explicit rule to permit it, but that is not a scalable or secure solution for stateful firewalls. The problem is with session tracking, not ACL configuration.

Deep packet inspection (DPI) with application signatures

Why it fails: DPI examines packet payloads for application-layer threats but does not inherently manage session state for return traffic. While DPI can identify applications, it does not create dynamic allow rules for return packets. The issue described is about session tracking, not application identification. Enabling DPI would not resolve the dropped return traffic unless stateful inspection is also functioning.

Network address translation (NAT) with port forwarding

Why it fails: NAT with port forwarding is used to allow inbound connections to internal servers, not to manage return traffic for outbound sessions. While NAT can translate addresses, it does not create session state. The firewall's stateful engine should handle return traffic automatically if session tracking is enabled. Port forwarding would not address the described issue.

Deploy the appliance as a routed hop between the two VLANs with a static route on each side.

Why it fails: Inserting a routed hop changes the Layer 3 topology and requires gateway or route changes on the clinical and guest VLANs, violating the requirement to avoid IP addressing changes. A routed deployment also creates a single point of failure unless additional redundancy is configured, and it is not transparent to the existing network design.

Deploy a TAP aggregator that mirrors both VLANs to the appliance and enable fail-open on the NIC.

Why it fails: A network TAP copies traffic passively; it does not place the appliance in the forwarding path, so no prevention between the VLANs is possible. NIC-level fail-open only affects the appliance's own interface state and cannot restore a path that was never inline, leaving the clinical-to-guest traffic uninspected and unblocked.

Deploy a SPAN port on the core switch and attach the appliance in passive monitor-only mode.

Why it fails: A SPAN-based passive deployment copies frames to the monitoring interface but has no ability to block malicious traffic, so it cannot enforce policy between the clinical and guest VLANs. It also fails the availability requirement differently: while the network survives an appliance failure, the appliance provides no inline protection at all, which is not what the scenario asks for.

Configuring the WAF to operate only in detection mode with alerts sent to a SIEM.

Why it fails: Detection-only mode produces alerts but does not block malicious requests, which is insufficient for protecting a live banking portal where active prevention is expected. Alerting to a SIEM is valuable for visibility, yet it does not address either stated requirement: inspecting TLS 1.3 content or correlating behavior across many requests from one client.

Enabling promiscuous mode on the WAF's management interface.

Why it fails: Promiscuous mode lets an interface capture frames not addressed to it, which is useful for passive sniffing but irrelevant to a WAF that must actively proxy and inspect HTTP traffic. It does not decrypt TLS 1.3, does not correlate requests, and enabling it on a management interface could actually expose sensitive administrative traffic on the segment.

Disabling HTTP keep-alive so every request opens a fresh TCP connection.

Why it fails: Forcing a new TCP connection per request would degrade portal performance and does not improve attack detection; correlation across requests is a function of application-layer session tracking, not connection reuse. In fact, breaking keep-alive can obscure client identity and complicate the very session state the WAF needs to detect multi-request attacks.

The firewall is applying egress filtering that blocks the partner's return traffic after the first hour.

Why it fails: Egress filtering decisions are based on policy matching, not elapsed time, so a rule would either block the traffic from the start or not at all. A time-based cutoff points to session state management rather than static filtering, making this explanation inconsistent with the one-hour pattern users report.

The firewall is performing full packet reassembly and rejecting out-of-order TCP segments from the partner.

Why it fails: Reassembly and out-of-order handling affect individual packets within a flow, not the periodic teardown of a session that has been working normally. If out-of-order rejection were the cause, users would see erratic failures tied to specific retransmissions rather than a regular hourly drop, so this does not fit the symptom pattern.

The firewall's ALG for SSH is rewriting the sequence numbers and desynchronizing the endpoints.

Why it fails: Stateful firewalls generally do not run an application-layer gateway for SSH the way they might for FTP or SIP, so sequence rewriting is not a plausible cause here. Even where ALGs exist, they typically cause immediate connection failures, not clean disconnects after a consistent, long interval.

Enable fail-open bypass on the IPS so that traffic is forwarded without inspection when the inspection engine is overwhelmed.

Why it fails: Fail-open bypass would preserve availability but defeats the purpose of inline prevention: during overload, malicious packets would pass uninspected. The scenario asks to preserve inline prevention while reducing false drops, and bypass directly removes prevention exactly when it is most needed. It addresses the symptom (dropped legitimate traffic) by disabling the control, not by improving inspection capacity or tuning the engine.

Move the IPS to a passive TAP and rely on alerts to manually block offending sources at the firewall.

Why it fails: A passive TAP eliminates inline prevention entirely; the device can only alert, not block. Manual firewall blocking is slow and cannot stop a fast-moving exploit or worm. While this removes false drops caused by inline overload, it also removes the core requirement of inline prevention. The question asks how to preserve inline prevention, so removing it from the traffic path is not a valid adjustment.

Increase the IPS fail-closed timeout so that traffic is buffered longer during inspection spikes.

Why it fails: Extending a timeout does not increase inspection throughput and can worsen latency and packet loss. If the engine is already saturated, longer buffering will overflow or delay sessions, causing application timeouts and more perceived drops. The root cause is inspection load, not timeout duration. This option misdiagnoses the bottleneck and would likely degrade performance further rather than reduce legitimate traffic drops.

Deploy the WAF as a host-based agent on each web server with a static rule set based on the OWASP Core Rule Set.

Why it fails: A host-based agent with a static rule set relies on predefined signatures, not behavioral learning. The OWASP Core Rule Set is valuable but requires tuning and does not automatically learn each application's normal traffic. Host-based deployment also consumes server resources and may not see traffic before it reaches the application. This approach does not satisfy the requirement to learn normal behavior and block deviations without writing new signatures.

Deploy the WAF in monitor-only mode with signature-based rules and alert on known attack patterns.

Why it fails: Monitor-only mode does not block traffic, so it cannot meet the requirement to block deviations. Signature-based rules also require manual updates and do not learn normal application behavior. While monitoring is useful during tuning, the scenario explicitly asks for a configuration that blocks deviations after learning normal behavior. This option provides visibility but not enforcement or behavioral learning, so it fails the stated goal.

Deploy the WAF in transparent bridge mode with a positive security model that only allows explicitly defined methods, parameters, and content types.

Why it fails: A positive security model can be very strong, but it requires explicit definition of all allowed behavior and does not learn deviations automatically. It can cause extensive false positives when the application changes, and it typically needs manual maintenance. The requirement is to learn normal behavior and block deviations without writing signatures, which is closer to anomaly-based or behavioral learning than to a strict positive model.

A web application firewall placed in front of the SCADA historian's HTTP interface.

Why it fails: A WAF protects HTTP-based applications and has no visibility into Modbus/TCP function codes or register semantics, so it cannot enforce the required allowlist. Deploying one may be useful for the historian's web console, but it does nothing for the proprietary control traffic the scenario is concerned about.

An email and web gateway performing TLS interception on the OT VLAN.

Why it fails: A secure web gateway targets user browsing and mail flows, not industrial control protocols, and TLS interception is irrelevant to Modbus/TCP, which is typically unencrypted. Placing such a device on the OT VLAN would add latency and complexity without providing any function-code enforcement.

A stateless packet filter permitting only TCP port 502 between the engineering workstation and the PLC.

Why it fails: Port 502 is the transport for all Modbus/TCP traffic, so permitting it allows every function code, including write and diagnostic operations the team wants to block. A stateless filter also cannot see inside the payload, meaning it cannot distinguish an approved read from a dangerous write on the same port.

It relies solely on signature updates pushed to endpoint agents installed on each workstation.

Why it fails: Endpoint agents are a different control architecture; a UTM is a network device that inspects traffic in the path rather than depending on software installed on each host. The scenario describes protecting traffic at the network edge, which endpoint-only signatures would not accomplish for devices that lack agents, such as guest laptops.

It functions only as a stateful firewall and requires separate appliances for each additional security service.

Why it fails: That describes a conventional firewall, not a UTM. The defining characteristic of unified threat management is the consolidation of several services into one platform, so stating that separate appliances are required directly contradicts the purpose of the device the owner purchased.

It offloads all inspection to a cloud service, requiring no local processing of network traffic.

Why it fails: While some modern platforms offer cloud-assisted reputation lookups, a UTM performs its core inspection locally as traffic passes through it. Claiming that no local processing occurs mischaracterizes how the device works and would not deliver the inline antivirus, filtering, and intrusion prevention the owner expects from a single appliance.

Enable private VLANs on the switch so that guest ports can communicate only with the router port.

Why it fails: Private VLANs can isolate ports within a VLAN and force traffic through a promiscuous port, which is useful for some segmentation designs. However, if guest and internal users remain in the same primary VLAN, the isolation rules may not cleanly separate them from internal file servers, and configuration complexity is high. The more direct and commonly supported approach is separate VLANs plus a router ACL, which unambiguously blocks guest-to-internal traffic.

Configure port security on all switch ports to limit the number of MAC addresses, and enable DHCP snooping on the guest VLAN.

Why it fails: Port security and DHCP snooping protect against MAC flooding and rogue DHCP servers, but they do not prevent a guest host from sending IP traffic to an internal file server on the same Layer 2 network. These are Layer 2 hardening features, not inter-segment access controls. The requirement is to stop guest users from reaching internal servers, which needs logical separation and a routed policy enforcement point, neither of which this option provides.

Place guest users on the same VLAN as internal users but assign them static IP addresses in a different subnet range.

Why it fails: Using different IP subnets on the same VLAN does not create a security boundary; hosts on the same Layer 2 segment can still communicate directly via ARP and MAC addressing, bypassing any router ACL. Without VLAN separation, the router is not in the path for local traffic, so an ACL cannot enforce segmentation. This approach gives a false sense of separation and does not prevent guest users from reaching internal file servers.

A stateless packet-filtering router that evaluates each packet independently against ACLs.

Why it fails: Stateless packet filtering does not maintain connection state, so it cannot perform stateful connection tracking. It evaluates each packet in isolation against ACLs and often requires rules for both directions of a flow. The description explicitly includes stateful connection tracking and NAT, which go beyond stateless filtering. Therefore, a stateless packet-filtering router does not match the described capabilities.

A next-generation firewall that performs full application-layer inspection and user identity mapping.

Why it fails: A next-generation firewall does stateful tracking and NAT, but it also performs deep application inspection, application identification, and often user identity mapping. The scenario explicitly states that deep application inspection is not provided, so an NGFW exceeds the described capabilities. Although an NGFW could be placed in that position, the description points to a simpler stateful firewall rather than a full application-aware platform.

A web proxy that terminates HTTP and HTTPS connections and enforces content policies.

Why it fails: A web proxy operates at the application layer, terminates client connections, and enforces content or URL policies. It does not typically provide general-purpose stateful connection tracking for all protocols or network address translation for arbitrary traffic. The description mentions NAT and stateful connection tracking without application inspection, which is not the role of a web proxy. Therefore, this device type does not match the scenario.

The IPS is configured to drop all traffic that it cannot inspect, including encrypted sessions it cannot decrypt.

Why it fails: Dropping all uninspectable traffic, including encrypted sessions, would cause severe availability problems and block legitimate business communication. The goal is to minimize single-point-of-failure risk and still block malicious traffic, not to enforce a fail-closed policy on all uninspected flows. Such a configuration would likely create outages and is not a recommended design characteristic for an inline IPS on a critical link. It confuses strict enforcement with availability preservation.

The IPS is managed out-of-band on a separate management VLAN with restricted access.

Why it fails: Out-of-band management on a restricted VLAN is a good security practice, but it does not address the single-point-of-failure or line-rate requirements for inline traffic. It improves management security and availability of the management plane, yet it does not ensure data-plane continuity or inspection capacity. Because the question asks for design characteristics that minimize single-point-of-failure risk while still blocking traffic, this option is not one of the two required characteristics.

The IPS is deployed in passive mode with a span port so that it can alert without affecting traffic flow.

Why it fails: Passive mode with a span port avoids becoming a single point of failure, but it also cannot block malicious traffic inline. The scenario requires both minimizing single-point-of-failure risk and still blocking malicious traffic. Passive deployment removes the inline enforcement capability, so it does not satisfy the blocking requirement. It may be useful for monitoring, but it is not a valid inline IPS design characteristic for this requirement.