Firewalls, intrusion detection and prevention, and choosing the network control

Objective 4.1 asks you to apply controls to a real situation. This lesson takes the controls that sit on the network path: firewalls and what they understand, rate limiting for traffic that obeys every rule but still overwhelms, intrusion detection and prevention on the wire, on the host and over the air, and the reasoning that picks one control when several would technically work.

Why this matters

Questions about network controls rarely ask what a firewall is. They give you a requirement and four real security devices, three of which solve a different problem. What usually decides it is which layer the control understands and whether it must block or only tell you. A device that sees only addresses and ports cannot judge a URL. A device that understands HTTP cannot protect a protocol it has never heard of. An inline blocker that misfires causes an outage.

The lesson

Rule-based firewalls, layer 4 versus layer 7, UTM and the web application firewall

A rule-based firewall matches traffic against an ordered list of rules. A rule has a source, a destination, a service (protocol and port) and an action. Newer devices can also match on application, user identity and time of day. Three principles carry most exam questions:

• Default deny. The rule base ends in "deny everything else", and wanted traffic is allowed explicitly.
• Order matters. Rules are checked top to bottom and the first match wins. A broad allow placed above a narrow deny silently cancels the deny. "The rule is there but not working" usually means the rule is in the wrong place.
• Be specific. Allow this source to this destination on this port, not one subnet to another on any port.

Outbound rules are the neglected half: free outbound traffic is exactly what command-and-control and exfiltration rely on. Rule hygiene matters too. Every rule needs an owner and a reason, temporary rules need an expiry date, and regular reviews remove the rules for systems that no longer exist.

How much a firewall understands is the next distinction:

• A layer 4 firewall decides on addresses, ports and protocol. A stateful one also tracks connections, so it knows a returning packet belongs to a session someone inside started. It is fast, and it cannot tell one HTTPS conversation from another.
• A layer 7 firewall understands the application protocol itself, so it can identify an application on any port and act on its content. Next-generation firewalls combine stateful filtering with this awareness.

Two named devices round this out:

• Unified threat management (UTM) puts firewall, intrusion prevention, antivirus, content filtering and spam filtering in one appliance. It suits smaller organisations that want simplicity and lower cost. The price is that the box becomes a single point of failure, and each function is usually weaker than a dedicated product.
• A web application firewall (WAF) sits in front of web applications and inspects HTTP and HTTPS in depth, blocking injection, path traversal and similar abuse. It is narrow and deep, so it is excellent for web applications and irrelevant to anything else. It is also the standard virtual patch: a WAF rule can block a known web flaw while the code fix is still being written.

The separator to remember: a general firewall protects the network and understands many applications a little. A WAF protects a web application and understands one protocol thoroughly. SQL injection or cross-site scripting against a web app points to the WAF.

Rate limiting, and the flood of requests a rule cannot see

Some attacks consist entirely of traffic every rule allows. A login page must accept login attempts, and an API must accept API calls. Credential stuffing, password guessing, scraping and application-layer floods all send perfectly well-formed requests. They are only malicious because there are so many of them.

Rate limiting caps how many requests a client may make in a time window. The client can be identified by source address, user account, session or API key. Requests over the limit are delayed, challenged or rejected. Web services commonly answer with HTTP status 429, Too Many Requests. Firewalls can apply the same idea lower down, capping new connections or half-open handshakes from one source.

Where it helps most:

• login and password-reset endpoints, where it turns fast automated guessing into a slow trickle (account lockout and MFA cover the rest);
• APIs, where it stops one client from scraping the data or exhausting capacity;
• expensive operations, such as search or report generation, which a modest number of requests can turn into a denial of service.

Know its limits. A distributed attack spreads requests across thousands of addresses so a per-address limit never trips; limiting per account helps. Many real users can share one address behind a corporate gateway, so a tight per-address limit blocks customers. And a flood big enough to fill the internet link does its damage before your firewall counts anything, so it needs upstream filtering by the provider or a DDoS protection service.

Network and host IDS/IPS, signatures versus anomalies, and where each belongs

Both detect malicious activity. The difference is what they may do about it.

• An IDS detects and alerts. It works on a copy of the traffic from a tap or mirror port, so it cannot break the network and cannot block.
• An IPS detects and blocks. It must sit inline, so it can break the network. A false positive becomes an outage, not just a wasted alert. Decide in advance whether it should fail open to keep traffic flowing or fail closed to keep traffic blocked when it fails.

So IPS rules go in detection mode first, and switch to blocking only once they prove clean.

Where they run:

• NIDS/NIPS watch network traffic at a chokepoint. Put an IPS inline at a boundary. Put a sensor inside the perimeter to see what actually got through. Remember the gap: a sensor at the gateway never sees east-west traffic between two hosts on the same segment.
• HIDS/HIPS run on the host. They see activity regardless of encryption: file integrity changes, suspicious processes, registry and log events. HIPS blocks that behaviour. In current products this is usually part of EDR (see lesson 32).

How they decide:

• Signature-based detection matches known patterns. It is precise, has few false positives, and is blind to anything new.
• Anomaly-based (behavioural) detection compares activity with a learned baseline of normal. It can catch the previously unseen, needs a learning period and raises more false positives.

The exam's discriminator: signatures catch the known; anomalies catch the unknown and cost false positives. If a scenario says zero-day or never seen before, the answer is anomaly-based or behavioural detection.

Wireless intrusion prevention, and the access point nobody approved

A wireless network has no walls, so it needs its own sensors. A wireless intrusion prevention system (WIPS) listens to the radio environment through dedicated sensors or the access points themselves, and compares what it hears with the authorised access points and their expected behaviour.

What it looks for:

• Rogue access points. These are unauthorised devices plugged into the wired network, often by an employee who wanted better coverage. A rogue AP creates an unmanaged door straight past the perimeter.
• Evil twins. These broadcast your network's name to lure clients into connecting to the wrong access point.
• Deauthentication floods and other management-frame abuse used to knock clients off the network.
• Misconfigured authorised APs and ad hoc networks.

A WIPS can locate a device by signal strength and often find the switch port a rogue is plugged into, so the port can be shut. Some products can also disrupt clients connecting to a rogue. Interfering with networks you do not own, such as a visitor's personal hotspot, can break communications law, so containment is limited to devices proven to be on your own network.

Pair WIPS with controls that make a rogue useless: 802.1X on wired ports, so a device plugged into the wall gets nothing without authenticating, and the protected management frames WPA3 requires, which blunt deauthentication.

Choosing between two controls that both technically work

These selection questions have a method. Four questions settle most of them:

1. What layer is the threat at? Addresses and ports point to a firewall. HTTP content points to a WAF. Too many valid requests points to rate limiting. Behaviour on a host points to HIPS or EDR. Radio points to WIPS.
2. Must it block, or only tell you? Blocking means inline, with the outage risk that comes with it. If the scenario stresses that business traffic must not be interrupted, choose detection first.
3. Can it see what it needs to? Encrypted traffic, east-west traffic and devices that cannot run an agent each rule out whole categories of control.
4. Will the organisation actually run it? A strong control that needs constant care, and that nobody has time for, is not a control.

A worked example: "A shop's login page is hit with thousands of username and password pairs from many addresses. The requests are well-formed, and customers must not be locked out." A port rule sees only HTTPS on 443, and a signature IPS sees valid logins. The answer is rate limiting on the login endpoint, keyed on the account as well as the address, alongside MFA. You get there by elimination, not recall.

Prefer defence in depth too: no single device sees everything.

What to take into the exam

• Default deny, first match wins, be specific; outbound is the neglected half.
• Layer 4 sees ports; layer 7 sees content. A WAF guards one web app deeply and is the virtual patch. A UTM trades depth for simplicity.
• Rate limiting stops floods of valid requests; distributed sources defeat per-address limits.
• An IPS is inline, so start it in detection mode. Signatures catch the known; anomalies catch the unknown, with more false positives.
• WIPS finds rogue APs and evil twins; 802.1X on wired ports makes a rogue useless.