Firewall vs IDS vs IPS vs WAF: What They Inspect, Block or Alert, and What They Protect
All four defend against attacks that travel over the network, but they differ in what they inspect and what they do when they find something. A firewall lets through only the traffic its rules allow, based on IP addresses, port numbers and similar fields. An IDS (intrusion detection system) inspects traffic down to its contents, finds what looks like an attack and alerts administrators, but does not stop the traffic. An IPS (intrusion prevention system) sits in the traffic path and blocks the attacks it finds on the spot. A WAF (web application firewall) inspects the contents of HTTP requests and blocks attacks on web applications such as SQL injection. None of them covers everything on its own, so they are used together.
| Aspect | Firewall | IDS | IPS | WAF |
|---|---|---|---|---|
| What it mainly inspects | Source and destination IP addresses, port numbers and connection state (network and transport layers); some products also identify applications | Packet headers through contents (network layer up to the application layer) | Like an IDS, packet headers through contents | The contents of HTTP and HTTPS requests and responses (application layer) |
| Placement relative to the traffic path | In the path (inline) | Usually outside the path, receiving a copy of the traffic from a switch mirror port or similar | In the path (inline) | In the path, in front of the web server, as a reverse proxy or a cloud service |
| Action on detection | Blocks traffic its rules do not allow | Raises an alert and logs it; the traffic itself is not stopped | Blocks the traffic or drops the connection | Blocks requests judged to be attacks; a detect-and-log-only mode is also common |
| Detection method | Allow and deny rules (addresses, ports, connection state) | Matching against known attack patterns (signatures) and anomaly detection that looks for deviations from normal traffic | Like an IDS, signatures and anomaly detection | Rules for attack patterns such as SQL injection and cross-site scripting, and rules defining which input is allowed |
| What it mainly protects | The network's entry and exit points, keeping disallowed traffic out | Monitoring of networks and servers, noticing signs of attack or intrusion | Servers and endpoints on the network, against known attacks | Web applications, against attacks that exploit application vulnerabilities |
| Impact of false positives | A rule mistake stops legitimate traffic | Many false alarms bury real alerts and burden operators, but business traffic is not stopped | A false positive directly blocks legitimate traffic, so careful tuning is needed | Legitimate input, such as text containing symbols, judged as an attack makes users' operations fail |
| Example placement | At the boundary between the internal network and the internet, between network segments, and on each server or endpoint | On the network segment to be monitored (network-based) or on a server (host-based) | At the internet boundary, for example just inside the firewall | In front of a public web server |
| Limitations | Cannot stop attacks that pass through allowed ports, such as those exploiting web application flaws; has no function to encrypt traffic | Only detects and cannot stop; cannot inspect TLS-encrypted traffic unless placed where it can be decrypted | Unknown attacks without signatures depend on anomaly detection and are easily missed; cannot see encrypted contents; its capacity can become a traffic bottleneck | Does not protect non-web traffic; does not fix the application's vulnerabilities themselves |
Figures are typical orders of magnitude and vary by process generation and product.