Network Security and Defense Questions

Implicit deny is the default, unwritten last rule of any properly-designed access control list (ACL) or firewall rulebase: any traffic that does not explicitly match one of the allow rules above it is dropped, even though no rule literally says "deny" for that traffic.

Example ACL

1. permit tcp any host 10.0.0.5 eq 443
2. permit tcp any host 10.0.0.5 eq 80
3. (implicit deny: everything else, dropped)

A connection attempt to 10.0.0.5 on port 22 (SSH) matches neither rule 1 nor rule 2, so it falls through to the implicit deny at the end and is dropped, even though the configuration contains no line mentioning port 22 or the word deny at all.

Why explicit deny is sometimes added anyway

Many devices do not log the implicit deny by default, so it is often invisible. An explicit final rule, such as deny all traffic and log it, gives visibility into what is being blocked and why, useful for both troubleshooting and spotting reconnaissance or attack traffic. It also documents intent clearly for anyone auditing the rulebase later, since a reviewer should not have to already know the device's default behavior to understand the policy. On platforms that allow inserting rules at arbitrary positions, a deliberate explicit deny at the end also guards against a future rule being appended after it that the original author assumed would never be reached.

Worked example: an overly broad allow rule

An engineer intends to allow SSH management access only from the small operations subnet 10.0.1.0/24, 256 addresses, but mistypes the rule as permit tcp 10.0.0.0/16 host 10.0.0.5 eq 22. A /16 covers 65,536 addresses, roughly 256 times more than intended, silently granting SSH access to the entire internal /16 range instead of just the operations subnet. Because this is an explicit allow rule that legitimately matches, the implicit deny at the end never even gets evaluated for that traffic. Implicit deny only protects against what falls through the cracks, it does nothing to catch an overly broad rule that matches exactly as written. This is why every explicit allow rule needs its own review for correct scope, not just trust that "there is an implicit deny at the bottom" as a safety net for mistakes made higher up.

Trade-offs and pitfalls

Implicit deny is the correct least-privilege default, but it can also silently break legitimate new traffic that nobody remembered to write a rule for. Good change management pairs implicit deny with an explicit deny-and-log line and active monitoring of what is hitting it, so a silent drop does not also become a silently undiagnosed outage during troubleshooting.

The Address Resolution Protocol (ARP) has no built-in authentication, so ARP spoofing, also called ARP poisoning, works by an attacker sending forged ARP replies that map a legitimate address, commonly the default gateway, to the attacker's own MAC address. Victim hosts then send their traffic to the attacker instead, giving the attacker a local man-in-the-middle position.

Detection and mitigation techniques

1. Dynamic ARP Inspection (DAI) on managed switches: validates every ARP packet against a trusted IP-to-MAC binding table, usually built from DHCP (Dynamic Host Configuration Protocol) snooping, and drops and logs any reply that does not match. Limitation: requires switches that support DAI and DHCP snooping enabled correctly on every access port, offers no help for a host that is statically addressed unless a manual binding is added, and does nothing for an attacker positioned upstream of the enforcement point.
2. Static ARP entries for critical hosts, for example hardcoding the gateway's IP-to-MAC mapping on servers that must never be intercepted. Limitation: this does not scale, since every mapping is manual and per-host, and it only protects the specific entries pinned, not general LAN traffic.
3. Passive ARP monitoring, watching for a MAC address suddenly claiming an IP it has never used, or one IP mapping to multiple MACs, and alerting on the change. Limitation: this is detection after the fact, not prevention, so an attacker still gets a window before anyone responds.

Verifying an attack is occurring

Pull the ARP table from several hosts, and from the switch's own binding table, and compare the MAC address recorded for the gateway's IP across all of them. An inconsistency, most hosts showing the real gateway MAC while one shows a different MAC, points at a targeted poisoning rather than a network-wide problem. A packet capture on the suspect segment showing repeated, unsolicited (gratuitous) ARP replies for the gateway's IP address, especially from a MAC not in the asset inventory, confirms it directly.

Worked example

Gateway is 10.0.0.1, real MAC 00:11:22:33:44:55. An attacker broadcasts a gratuitous ARP reply claiming "10.0.0.1 is at AA:AA:AA:AA:AA:AA." The victim's ARP cache updates to the attacker's MAC for 10.0.0.1. An analyst runs the ARP table command on the victim and on a known-clean host in the same segment side by side: the clean host shows 10.0.0.1 mapped to the real MAC, the victim shows it mapped to the attacker's MAC, confirming the poisoning on that specific host.

Trade-offs and pitfalls

Dynamic ARP Inspection is the strongest single control here, but it is an investment in switch capability and configuration discipline across every access port, one unmanaged or misconfigured port re-opens the whole LAN to the same attack. Static entries and passive monitoring are cheap stopgaps for a handful of critical hosts, not a solution for the whole network.

Direct answer

The OSI model splits networking into seven conceptual layers; the TCP/IP suite is the four-layer model the real internet runs on, and it condenses OSI's bottom two layers into one "network access" layer and OSI's top three into one "application" layer. Each layer is where a specific class of attack and a specific class of control naturally live, because that is the layer that actually has the information needed to detect or block that class of problem.

Structured elaboration

Worked example

Trace a single attack end to end through this table: an attacker plugs a laptop into an unused conference-room jack. If the physical-layer control (802.1X, disabled unused ports) is missing, the attacker gets link immediately. If it is present but the data-link control is missing, the attacker can still ARP-spoof the gateway and intercept traffic even though they were correctly admitted at layer 1 for some other legitimate reason (a guest VLAN, say). This is why the table is a defense-in-depth chain, not a menu you pick one item from: a gap at any single layer can undo the protection at every layer above it.

Trade-offs and pitfalls

• The TCP/IP model does not actually have separate session and presentation layers; treating them as OSI does is a teaching convenience, and real protocols (TLS, for example) blur session and presentation concerns together.
• A control that is technically correct for its layer can still be misapplied: a WAF (application layer) cannot compensate for an open, unauthenticated switch port (physical/data-link layer), so layer-appropriate controls have to be deployed together, not as substitutes for one another.
• Some technologies genuinely span layers (IPsec can operate in a way that affects both network-layer routing and what looks like transport-layer session state), so treating this table as a strict, non-overlapping partition is itself a simplification worth naming out loud in an interview.

Several widely-deployed legacy protocols transmit everything, including credentials, in plaintext, and each has a secure, encrypted successor that should replace it. The right approach to migration is a short-term compensating control paired with a tracked long-term replacement, not an instant rip-and-replace that a legacy environment often cannot support on day one.

The pairs

Migration strategy per pair

• Telnet to SSH: short-term, restrict Telnet to an isolated management network with strict access control and close monitoring if some legacy device firmware cannot be upgraded immediately; long-term, disable the Telnet daemon entirely and enforce SSH-only management.
• FTP to SFTP/SCP: short-term, confine any remaining FTP service to internal-only networks and never expose it to the internet; long-term, migrate transfer scripts and workflows to SFTP and decommission the FTP service.
• HTTP to HTTPS: short-term, add an HTTP-to-HTTPS redirect and obtain a valid TLS certificate; long-term, enforce HTTPS-only with HTTP Strict Transport Security (HSTS) so browsers refuse to fall back to plaintext even if an attacker tries to intercept the initial redirect.

Worked example

An analyst runs a network scan and finds 40 internal hosts still answering on port 23 (Telnet) and 12 legacy file servers on port 21 (FTP), while the customer-facing website already redirects HTTP to HTTPS. Short-term mitigation applied immediately: a firewall rule restricts ports 23 and 21 to the management subnet only, cutting exposure to the general LAN and internet to zero without waiting for a change window. Long-term: a tracked migration ticket per host group targets a move to SSH and SFTP with a decommission date, and any device whose firmware genuinely cannot be updated in time gets its own documented compensating control (isolation plus logging) rather than being quietly left exposed.

Trade-offs and pitfalls

Some embedded or legacy hardware genuinely cannot support SSH or TLS, so isolation is a legitimate interim step, not an excuse to defer the migration indefinitely. And enabling HTTPS without also enforcing a redirect and HSTS still leaves the plaintext path reachable, which defeats much of the purpose of migrating in the first place.

Direct answer

Slow HTTP attacks like Slowloris don't send much data or many requests; they open many connections and trickle bytes in just fast enough to avoid a read timeout, so each connection ties up a worker thread or, for HTTP/2, a stream slot, indefinitely. The fix is to bound how long any single connection or stream may take to make progress, rather than trying to spot "attack traffic" by volume, since the entire point of this attack class is to look like an unusually slow but otherwise ordinary client.

Structured elaboration

Indicators. On the network side: many concurrent connections from a modest number of source addresses sitting in an open, no-data or partial-request state, each with data arriving in tiny increments spaced seconds apart, and connection durations far beyond the P99 for legitimate clients on that endpoint. On the application side: the worker or thread pool (or, for HTTP/2, the per-connection concurrent-stream count) approaching its configured maximum while overall request throughput and CPU usage stay low; a growing number of requests stuck "receiving headers" or "receiving body" without completing; and for HTTP/2 slowstreams specifically, many streams drip-fed on a small number of connections rather than many separate slow connections.

Three mitigations, and their side effects:

1. A strict request-completion timeout, independent of how much data has arrived so far (headers for HTTP/1.1, forward progress on open streams for HTTP/2). Side effect: a real client on a very slow or high-latency connection can be disconnected mid-request if the timeout is set too tight, so it needs to come from your own traffic's actual P99/P99.9 completion time, not a round number picked out of habit.
2. Per-source connection and stream limits at the reverse proxy or load balancer. Side effect: legitimate users behind a shared address, a large office network or carrier-grade network address translation (NAT), can be throttled as collateral damage since many real users can share one visible source address.
3. An edge reverse proxy or web application firewall (WAF) built to hold many slow connections cheaply (an event-driven design) in front of the origin, so the application server's own limited worker pool is never directly exposed to raw client connections. Side effect: adds a network hop, and if the edge layer isn't itself tuned correctly it can become the resource-exhaustion target one layer further out; it also requires trusting that layer to enforce the same protections correctly.

Worked example

A server configured with a 200-worker thread pool and no request-completion timeout can be fully occupied by just 200 Slowloris connections, each sending one header line every 10 seconds, an aggregate rate well under one request per second per connection, which is exactly why volume-based detection misses it. Adding a 10-second header-completion timeout means each connection gets killed and its slot freed roughly every 10 seconds, so the attacker now has to continuously reopen all 200 connections just to sustain the same denial, a far more visible and costly pattern (200 connections opened and immediately timing out, every 10 seconds) that gives the monitoring system something concrete to alert on.

Trade-offs and pitfalls

These three layers are complementary, not alternatives: the timeout catches the slow-drip pattern itself, per-source limits blunt any single origin's blast radius, and the edge proxy absorbs raw connection volume before it ever reaches the origin's worker pool. The common pitfall is tuning any one of these against a single observed attacker's behavior instead of against your own legitimate traffic's real distribution, which is how real users end up blocked.