Step 6: Check Wireless-to-Wired Gateway Egress Filtering Rules

A security consultant or security solutions beta tester needs to find out if the deployed secure wireless gateway provides a sufficient level of protection against wireless side attackers and properly obscures the wired LAN. Although detailed firewall testing is beyond a chapter devoted to the basics of (W)LAN security auditing, we can give a few recommendations here:

• Check how the gateway handles packet fragmentation using nmap or hping2.

• Check how the gateway handles overlapping packets employing Ghost Port Scanner or some form of an old teardrop DoS attack.

• Check if strict or loose source route packets leak through the gateway using lsrscan or manually (netcat, telnet).

• Check if ACK (-sA) and Window (-sW) nmap scans bring any useful data.

• Set port 20 as a source of TCP and 53 - UDP portscan (-g switch in nmap) and see if it makes any difference.

• Play with the port scan source IP and MAC addresses (Ghost Port Scanner is good for this; randsrc can be used for randomizing source IP addresses).

• Give Mike Schiffman's Firewalk a try:

  
  

  
  arhontus:~# firewalk
  
  Firewalk 5.0 [gateway ACL scanner]
  
  Usage : firewalk [options] target_gateway metric
  
                       [-d 0 - 65535] destination port to use (ramping phase)
  
                       [-h] program help
  
                       [-i device] interface
  
                        [-n] do not resolve IP addresses into hostnames
  
                       [-p TCP | UDP] firewalk protocol
  
                       [-r] strict RFC adherence
  
                       [-S x - y, z] port range to scan
  
                       [-s 0 - 65535] source port
  
                       [-T 1 - 1000] packet read timeout in ms
  
                       [-t 1 - 25] IP time to live
  
                       [-v] program version
  
                       [-x 1 - 8] expire vector
  
  

  
  

• Check out broken CRC scans with the Malloc() FWScrape tool. This is a good all-around firewall testing tool that can save a lot of time:

  
  

  
  arhontus:~# ./mfwscrape
  
  
  
  Malloc() FWScrape v0.0.3a
  
  Written by: Dr.Tek of Malloc() Security
  
  
  
  Usage: ./mfwscrape -A firewall_address [Options]
  
  
  
  Firewall Testing Options:
  
  
  
          -f0:     TCP Traffic test.
  
          -f1:     TCP Broken CRC test.
  
          -f2:     UDP Traffic test.
  
          -f3:     ICMP Traffic test.
  
          -f4:     ICMP Broken CRC test.
  
          -f5:     TCP ACK probe test.
  
          -f6:     TCP FIN probe test.
  
          -f7:     TCP NULL test.
  
          -f8:     TCP XMAS test.
  
  
  
  Other Testing Options:
  
  
  
          -a:  Perform all Test.
  
          -t:  Open TCP service (Required for TCP test).
  
          -c:  Closed TCP service [OPTIONAL] (Default: 8331)
  
          -u:  Closed UDP service [OPTIONAL] (Default: 21093)
  
          -s:  Force Source Address.
  
  

  
  

To run a proper gateway test, you need a sniffing host on the other side of the firewall to analyze the leaking traffic. Many firewall testing tools are built as client/server utilities, with the client being a custom packet generator and server-sniffing daemon with leaking traffic decoding functions. Examples of such tools in the UNIX world are Ftester and Spoofaudit for spoofed IP filter testing. Convince your corporate management or client company to let you run a proper gateway filtering test by explaining that if you can find a leak in the gateway, so can the crackers. High-end wireless gateways are expensive, but are they really as good as the vendors claim? Is the money paid wasted because of incorrectly written rules? There is only one way to find out.