While a firewall product might itself have vulnerabilities, most firewall scans are conducted to identify which traffic types the firewall allows, and to test the effectiveness of its rules. The primary purpose of a firewall is to block unauthorized packets from reaching listening services. Dedicated (appliance) firewalls control traffic flowing between the "trusted" and "untrusted" network. Software-based personal firewalls protect the host from unwanted connections. Firewalls use rule sets to determine if traffic is permitted or not. Most rules are based on:
- Destination or source port
- Destination or source IP address
- Protocol type
- Payload
Specially crafted packets might slip through because they sufficiently match a permit rule. Or, the packet might not be blocked because it doesn't sufficiently match a deny rule. In addition, not all firewalls are capable of payload inspection. You might be able to push malicious code through a firewall over a permitted port. For example, if TCP 80 is allowed, you could hide a payload in HTTP, or simply set the destination port of any malicious TCP packet to 80. If the firewall is only looking at ports and not payload, it will permit the packet.
Sometimes you may just want to validate that there is a device at an IP address. Firewalls by design filter (block) traffic unless the port is open. This also means that if the host has no open ports, it will not respond to ICMP. Nor will it send any kind of response (including a TCP RST) to a TCP SYN. But a firewall might have a misconfiguration or design flaw that allows a specially crafted packet through, thus eliciting a response from the host. The type of packet you need to use will be dependent on the firewall product, though you can start with some well-known vulnerabilities. For example, the XMAS scan, in which the FIN, URG, and PSH flags are all raised in the same TCP segment, works against firewalls that follow a strict interpretation of RFC 793 (the original TCP specification). While this has been updated in most implementations, this vulnerability still exists in the wild.
There are two basic approaches to scanning a firewall for vulnerabilities:
- If the firewall is installed on the host, if it is a separate device in transparent mode, or if it provides NAT translation between the private and public network: Port-scan the public address of the host or firewall to see which ports are open or are being published. If you are probing for vulnerabilities, use specially crafted packets.
- If the firewall stands between two routable networks (does not provide NAT translation between two separate subnets), and you know or guess the IP address of the hidden host: Use firewalking against the firewall's public interface. This technique uses a specialized combination of traceroute and port scanning to discover the details of the internal network. It can map additional routers and firewalls, IP addresses, and permitted ports.
Note: A firewall in transparent mode acts like a switch rather than a router. Although it filters traffic, nodes on both sides of it are in the same subnet.
Note: For information about firewalking, see the article "Firewalk: Can Attackers See Through Your Firewall?" at www.giac.org/paper/gsec/312/firewalk-attackers-firewall/100588