Network Perimeter Protection practice questions

access-list OUTBOUND extended permit tcp any any eq 80 and access-group OUTBOUND in interface outside

Why it fails: Applying an inbound rule to the outside interface would block outbound traffic initiated from the inside.

static (inside,outside) tcp interface 80 192.168.1.10 80 netmask 255.255.255.255

Why it fails: A static NAT mapping exposes an internal server inbound, which is not required for outbound browsing.

object network WEB_PORTS; range 80 443; nat (inside,outside) dynamic interface

Why it fails: NAT translates IP addresses, not ports in this manner for outbound dynamic session inspection.

suricata -T

Why it fails: The -T flag tests the configuration file for syntax errors.

suricata --daemon

Why it fails: The daemon flag runs Suricata in the background.

Wireshark

Why it fails: Wireshark captures and analyses packets passively; it never binds ports or responds to connections, so it cannot emulate SSH, Telnet or FTP. It is tempting because it reveals login attempts, but it requires traffic to already exist and provides no honeypot service.

Metasploit

Why it fails: Metasploit is an exploitation framework for launching attacks against targets, not for emulating vulnerable services and logging inbound attempts. It is tempting because it handles SSH and FTP exploits, but it generates traffic rather than capturing attacker logins as a honeypot would.

Nmap

Why it fails: Nmap is a port scanner and service fingerprinter used for reconnaissance against hosts; it does not listen on ports or emulate SSH, Telnet or FTP. It is tempting because it identifies those services, but it produces scan results rather than logging brute-force attempts.

pattern:"AAAA";

Why it fails: Snort rules do not use a keyword named 'pattern'; the correct keyword is 'content'.

search:"AAAA";

Why it fails: The 'search' option is invalid; 'content' must be used to define strings or byte patterns to match.

payload_match:"\x41\x41\x41\x41";

Why it fails: 'payload_match' is not a valid rule option in the Snort rule language.

TCP Selective Acknowledgments (SACK)

Why it fails: SACK helps efficiently recover from lost packets without retransmitting the entire window, unrelated to SYN flood mitigation.

TCP Window Scaling

Why it fails: TCP window scaling is designed to improve throughput over high-bandwidth, high-latency links, not mitigate SYN floods.

Reverse Path Forwarding (RPF) strict mode

Why it fails: RPF checks packet source IPs against routing tables to prevent IP spoofing, not SYN floods.

ufw enable 192.168.100.0/24

Why it fails: The enable subcommand activates the firewall and takes no subnet argument, so this syntax is rejected outright. It is tempting because enable is genuinely used to turn UFW on, which would be correct when the requirement is simply to start the firewall rather than permit SSH from 192.168.100.0/24.

ufw deny ssh

Why it fails: This adds an explicit deny rule for port 22, blocking the very SSH access the administrator must permit from 192.168.100.0/24. It is tempting because deny ssh is a valid UFW command, and would be the correct choice when the requirement is to block SSH rather than allow it from a subnet.

ufw route allow 22

Why it fails: Route rules govern forwarded traffic traversing the host, not packets destined for the host itself, so inbound SSH to this machine is unaffected. It is tempting because route allow does accept port syntax, and would be right when configuring a gateway or container host that forwards traffic between interfaces.

iptables -A INPUT -m limit --limit 5/min -j LOG

Why it fails: The limit match rate-limits and the LOG target records packets; neither accepts established or related connections, and processing continues to later rules. It is tempting because LOG rules are commonly placed early for auditing, and would be correct if the goal were throttled logging of matching traffic rather than automatic acceptance.

iptables -A FORWARD -p tcp --dport 80 -j REJECT

Why it fails: This targets the FORWARD chain for port 80 and rejects, so it never inspects INPUT traffic and permits nothing. It is tempting because chain and target syntax look plausible, and would be correct if the requirement were to block web traffic transiting the host between networks.

iptables -A INPUT -m state --state NEW -j DROP

Why it fails: This matches only NEW state packets and DROPs them, which would block new inbound connections rather than allow established or related ones. It is tempting because the state match is the right extension, and would be correct if the requirement were to reject unsolicited new inbound sessions.

External Firewall acts as a transparent bridge; Internal Firewall performs NAT for all internet-bound traffic.

Why it fails: A transparent bridge on the external firewall provides no IP-layer filtering at the untrusted boundary, and NAT on the internal firewall obscures internal addressing while failing to enforce DMZ segmentation. NAT belongs on the external firewall, which should filter inbound internet traffic.

External Firewall routes internal traffic; Internal Firewall acts as a honeypot gateway.

Why it fails: Assigning the internal firewall a honeypot role inverts the architecture: the external firewall should face untrusted networks and the internal firewall should protect the trusted core. Honeypots are decoy systems placed in the DMZ, not perimeter enforcement devices.

External Firewall permits all traffic to DMZ; Internal Firewall blocks all traffic from DMZ to internal network.

Why it fails: Permitting all traffic from the internet into the DMZ removes the external firewall's filtering role, and blocking all DMZ-to-internal traffic also blocks legitimate service flows. Best practise has the external firewall filter inbound traffic and the internal firewall permit only required DMZ-to-internal connections.

log icmp any any -> any any (msg:"ICMP Ping Detected"; itype:8; sid:1000003;)

Why it fails: The header inspects ICMP with an echo-request type check, so HTTP payloads are never examined for the traversal string. It is tempting because ICMP signatures are a standard Snort use case, and this rule would be correct when detecting ping sweeps or echo requests against monitored hosts.

drop udp external any -> $HOME_NET 53 (content:"passwd"; sid:1000002;)

Why it fails: The header matches UDP port 53 DNS traffic, so the TCP HTTP request carrying the traversal string is never inspected. It is tempting because DNS tunnelling and exfiltration rules are common, and this structure would be correct when detecting suspicious queries to external resolvers.

pass ip any any -> any any (content:"GET /index.html"; sid:1000004;)

Why it fails: The pass action tells Snort to ignore the matching traffic rather than alert on it, and the content matches /index.html, not the traversal string. It is tempting because pass rules exist to suppress noise from trusted flows, which is correct when filtering benign traffic out of alert output.

Layer 2 Bridging

Why it fails: Layer 2 bridging forwards frames between interfaces by MAC address and never decrypts TLS, so DPI signatures still cannot read the payload. It is tempting because bridging is a firewall interface mode, but it would be correct only when transparent inline placement is required without IP re-addressing.

Port Forwarding

Why it fails: Port forwarding rewrites destination addresses and ports for inbound connections; it never decrypts TLS, so DPI signatures still cannot read the payload. It is tempting because it manipulates traffic flows, but that is NAT functionality, whereas SSL/TLS decryption with a trusted certificate is required to inspect encrypted sessions.

Static NAT

Why it fails: Static NAT only maps one IP address to another permanently; it performs no decryption, so TLS payloads remain opaque to DPI signatures. It is tempting because NAT is configured on the same firewall, but its purpose is address translation for inbound access, not cipher inspection.

Intrusion Prevention System

Why it fails: An IPS inspects traffic inline and blocks or alerts on detected signatures, but it neither emulates vulnerable services nor attracts attackers. It is tempting because IPS also gathers threat telemetry, making it correct when the requirement is real-time prevention of exploits against live production hosts rather than decoy engagement.

Stateful Inspection Firewall

Why it fails: A stateful inspection firewall tracks connection state to permit or deny packets by policy, but it presents no vulnerable services to entice attackers. It is tempting because firewalls log denied connection attempts, making them the right choice when the requirement is enforcing segmentation and filtering traffic at network boundaries.

Proxy Server

Why it fails: A proxy server brokers and filters application requests between clients and servers; it hosts no deliberately vulnerable services and cannot lure or observe attackers. It is tempting because proxies do provide traffic logging and content inspection, making them the right choice when the requirement is outbound request control rather than deception.

Internal LAN

Why it fails: An internal LAN sits behind the firewall, so publishing the server there exposes the corporate network if it is compromised. It is tempting because the server must reach internal systems, and an internal LAN would be correct for a service used only by employees.

Management VLAN

Why it fails: A management VLAN carries administrative traffic for switches and hypervisors; it does not expose services to the internet. It is tempting because it is a segregated segment, and it would be correct for isolating device management access from user data traffic.

Virtual Private Network (VPN) pool

Why it fails: A VPN pool supplies addresses to remote clients tunnelling inwards; it cannot host inbound public web requests. It is tempting because VPNs provide isolation, and a VPN pool would be correct for granting remote staff access to internal resources.

Spanning Tree Root Guard

Why it fails: Root Guard prevents a switch port from becoming the Spanning Tree root, protecting Layer 2 topology on switched networks. It is the right choice when stopping a rogue switch from hijacking the STP root, but it has no role in throttling or filtering traffic aimed at a router's control plane.

Port Security

Why it fails: Port Security restricts which MAC addresses may appear on a switch access port, so it cannot rate-limit traffic destined to a router's own CPU. It is the correct choice for stopping MAC flooding or rogue devices at Layer 2 access edges, not for control-plane policing on a perimeter router.

Dynamic ARP Inspection (DAI)

Why it fails: Dynamic ARP Inspection validates ARP packets against the DHCP snooping binding table, blocking ARP spoofing on a Layer 2 segment. It is correct for mitigating man-in-the-middle ARP attacks on access switches, but it does not police or rate-limit traffic reaching the router's control plane.

The firewall drops all incoming SYN packets immediately.

Why it fails: SYN cookies work by encoding connection state in the SYN-ACK sequence number so the firewall need not allocate state for half-open connections; they do not drop SYNs, which would block all legitimate TCP handshakes too. Dropping every inbound SYN is a blunt access-control rule, appropriate only when a specific source is known to be malicious.

The firewall resets the TCP window size to zero for all external connections.

Why it fails: Zeroing the TCP window size stalls data transfer on established sessions and does nothing to validate half-open SYN requests. Window manipulation belongs to flow-control or session-throttling features, not to SYN flood mitigation, which relies on stateless cookie validation.

The firewall proxies the TCP handshake by establishing a full connection before forwarding traffic to the server.

Why it fails: SYN cookies avoid allocating state until the handshake completes; the firewall does not proxy or complete the connection itself. Full proxy handshake termination describes a SYN proxy or full-proxy firewall, which is the correct mechanism when the device must shield servers by completing TCP on their behalf.

Unmanaged Layer 2 Switch

Why it fails: An unmanaged Layer 2 switch forwards frames using MAC addresses and has no concept of IP headers or connection state, so it cannot inspect Layers 3 and 4. It is the right fit for flat, small networks needing basic frame forwarding without configuration.

Patch Panel

Why it fails: A patch panel is passive cabling termination hardware; it neither reads packet headers nor makes forwarding decisions at any layer. It is correctly chosen for organising and cross-connecting structured cabling in racks and wiring closets.

Hub

Why it fails: A hub merely repeats electrical signals across all ports at Layer 1, holding no header or connection-state awareness, so it cannot inspect anything. It is tempting because hubs do forward traffic dynamically in the sense of regenerating signals to every segment, which suits tiny legacy networks needing cheap physical connectivity, not stateful Layer 3/4 filtering.

HTTP

Why it fails: HTTP serves web content in cleartext and provides no command-line session; HTTPS would encrypt browser-based device management, but neither offers the interactive CLI the scenario demands. HTTP suits hosting a device's web configuration pages, not replacing Telnet's terminal access.

SNMPv1

Why it fails: SNMPv1 is a management protocol for polling device metrics and traps, not an interactive command-line session, and its community-string authentication is cleartext. It would suit monitoring interface counters and uptime across a device estate, but it cannot deliver the encrypted CLI access the scenario requires.

TFTP

Why it fails: TFTP transfers files over UDP with no authentication or encryption, so it cannot carry an interactive encrypted CLI session. It is the right tool for pushing configuration or firmware images to a device during provisioning, not for the secure remote command-line administration described here.

IEEE 802.1X

Why it fails: IEEE 802.1X performs port-based network access control via EAP authentication; it does not insert VLAN tags into frames on trunk links. It is tempting because 802.1X is correct when the requirement is authenticating supplicants before granting switch port access, not segmenting traffic.

IEEE 802.3ad

Why it fails: IEEE 802.3ad defines link aggregation, bundling multiple physical links into one logical channel; it carries no VLAN tag information. It is tempting because 802.3ad is correct when the requirement is increasing bandwidth and redundancy between switches rather than isolating departments.

IEEE 802.11i

Why it fails: IEEE 802.11i specifies security mechanisms for wireless LANs, such as WPA2, and operates on Wi-Fi links rather than Ethernet trunk encapsulation. It is tempting because 802.11i is correct when securing wireless client traffic, not tagging frames across wired switch trunks.

Zone Protection Profile attached to the external zone

Why it fails: Zone Protection Profiles defend against flood, reconnaissance and packet-based attacks at the ingress zone level, not signature-based malware or exploit inspection within an allowed session. It is tempting because both are security profiles, and it would be correct when the requirement is volumetric attack protection for an entire zone.

NAT Policy translation destination field

Why it fails: NAT policy handles address and port translation only; it has no field for attaching Security Profiles, so no threat inspection occurs there. It is tempting because NAT is configured alongside security rules for the same traffic flow, and would be correct when the requirement is translating source or destination addresses.

Network Interfaces configuration tab

Why it fails: Interface configuration covers addressing, zones and management settings; Security Profiles are attached to security rules, not interfaces, so no malware or vulnerability inspection is applied. It is tempting because interfaces define traffic entry points, and would be correct when the requirement is assigning an interface to a zone or setting its IP address.

Change the firewall default gateway to the backup ISP.

Why it fails: Rerouting traffic to the backup ISP leaves the IPS inline, so it keeps dropping the legitimate transactions and the false positives persist. Changing the default gateway is a resilience action for ISP or link failure, not for tuning signature-based inspection of a custom protocol.

Disable the entire IPS inspection engine globally.

Why it fails: Disabling the inspection engine globally removes all signature and protocol inspection, eliminating perimeter visibility entirely. Global disablement is appropriate only for troubleshooting a suspected engine fault, not for suppressing false positives on one custom protocol.

Bypass the IPS by moving it from inline mode to out-of-band monitoring mode.

Why it fails: Out-of-band mode stops the IPS blocking traffic, but it also removes the inline prevention point, so the perimeter loses enforcement rather than retaining visibility with control. Out-of-band monitoring suits detection-only deployments where blocking is deliberately not required.

To actively block and drop malicious packets inline.

Why it fails: A span or mirror port receives copies of traffic, so a promiscuous-mode NIDS only observes and alerts; it cannot drop packets inline. Blocking requires an inline IPS or firewall. Detection is the correct role when monitoring mirrored traffic without disrupting the forwarding path.

To act as the default gateway for the DMZ network.

Why it fails: A NIDS passively copies mirrored traffic to inspect for malicious patterns; it forwards nothing, so it cannot route packets as a gateway. The role is tempting because span ports sit at network boundaries where a Layer 3 device would normally reside, but gateway duties belong to a router or firewall.

To perform Network Address Translation for internal hosts.

Why it fails: Network Address Translation rewrites packet headers and requires an inline forwarding device; a promiscuous NIDS only receives mirrored copies and never sits in the traffic path. The confusion arises because perimeter devices often perform NAT, but that is a firewall or router function, not passive monitoring.