Hacking Exposed 5th Edition

Almost every firewall will give off a unique electronic "scent." That is, with a little port scanning, firewalking, and banner grabbing , attackers can effectively determine the type, version, and rules of almost every firewall on the network. Why is this identification important? Because once an attacker has mapped out your firewalls, he can begin to understand their weaknesses and attempt to exploit them.

Direct Scanning: The Noisy Technique

The easiest way to look for your firewalls is by port-scanning specific default ports (as you learned in Chapter 2). Some firewalls on the market will uniquely identify themselves using simple port scans you just need to know what to look for. For example, Check Point's FireWall-1 listens on TCP ports 256, 257, 258, and 259 (with Check Point NG listening on TCP ports 18210, 18211, 18186, 18190, 18191, and 18192 as well), and Microsoft's Proxy Server usually listens on TCP ports 1080 and 1745. With this knowledge, you'll find searching for these types of firewalls trivial with a port scanner such as ScanLine from Foundstone:

sl -pvh -t 23,80 68.4.190.1-254

Both the dimwitted and the bold attacker will perform broad scans of your network in this manner, searching for these firewalls and looking for any chink in your perimeter armor . But the more dangerous attackers will comb your perimeter as stealthily as possible. Attackers can employ numerous techniques to fall under your radar, including randomizing pings , target ports ( -z ), target addresses ( -z ), and source ports ( -g ), as well as performing distributed source scans (meaning an attacker can use multiple computers on the Internet, each taking a small portion of the scanning targets).

If you think your intrusion detection system (IDS) will detect these more dangerous attackers, think again. Most IDSs come configured by default to hear only the noisiest or most clumsy port scans. Unless you highly sensitize your IDS and fine-tune your detection signatures, most of these sophisticated attacks will go completely unnoticed. You can produce such randomized scans by using the Perl scripts supplied on this book's companion website (http://www.hackingexposed.com).

Direct Scanning Countermeasures

Firewall scanning countermeasures in many ways mirror those discussed in Chapter 2, the scanning chapter. You'll need to either block these types of scans at your border routers or use some sort of intrusion-detection tooleither freeware or commercial. Even then, however, single port scans will not be picked up by default in most IDSs, so you'll need to tweak the system's sensitivity before detection can be relied on.

Detection To accurately detect the port scans using randomization, you'll need to finetune each of your port-scanning detection signatures. Refer to your IDS vendor's documentation for the details.

If you are using FireWall-1 for UNIX, you can use Lance Spitzner's utility for FireWall-1 port scan detection (http://www.enteract.com/~lspitz/intrusion.html). As covered in Chapter 2, his alert.sh script will configure Check Point to detect and monitor port scans and run a user -defined alert when triggered.

If you are using Linux firewalling, better known as netfilter/iptables, you have a plethora of detection tools available that will help identify those noisy attackers. One such tool includes IPPL, which is a daemon that runs in the background and will alert you to set specific parameters for logging suspicions packets. IPPL can be found at http://pltplp.net/ippl.

Prevention To prevent firewall port scans from the Internet, you'll need to block these ports on routers in front of the firewalls. If these devices are managed by your ISP, you'll need to contact them to perform the blocking. If you manage these devices yourself, you can use the following Cisco ACLs to explicitly block the scans discussed earlier:

access-list 101 deny tcp any any eq 256 log ! Block Firewall-1 scans access-list 101 deny tcp any any eq 257 log ! Block Firewall-1 scans access-list 101 deny tcp any any eq 258 log ! Block Firewall-1 scans access-list 101 deny tcp any any eq 259 log ! Block Firewall-1 scans access-list 101 deny tcp any any eq 1080 log ! Block Socks scans access-list 101 deny tcp any any eq 1745 log ! Block Winsock scans

Also, all your routers should have a cleanup rule (if they don't deny packets by default), which will have the same effect as specifying the preceding explicit deny operations. A typical "deny all" rule looks something like this:

access-list 101 deny ip any any log ! Deny and log any packet that got through our ACLs above

As with any countermeasure, be sure to refer to your specific documentation and installation requirements before applying any recommendations.

Route Tracing

A more quiet and subtle way of finding firewalls on a network is to use traceroute. You can use UNIX's traceroute or Windows' tracert.exe tools to find each hop along the path to the target and to do some deduction . Linux's traceroute has the -I option, which performs traceroutes by sending ICMP packets, as opposed to its default UDP packet technique:

[sm]$ traceroute -I 192.168.51.100 traceroute to 192.168.51.101 (192.168.51.100), 30 hops max, 40 byte packets 1 attack-gw (192.168.50.21) 5.801 ms 5.105 ms 5.445 ms 2 gw1.smallisp.net (192.168.51.1) 3 gw2.smallisp.net (192.168.52.2) .... 13 hssi.bigisp.net (10.55.201.2) 14 serial1.bigisp.net (10.55.202.1) 15 192.168.51.101 (192.168.51.100)

In the preceding output, chances are good that the system (10.55.202.1) just before the target (192.168.51.100) is the firewall, but we don't know for sure yet. We'll need to do a little more digging.

The preceding example is great if the routers between you and your target servers respond to ICMP time to live (TTL) expired packets. But some routers and firewalls are set up not to return these TTL expired packets (from both ICMP and UDP packets). In this case, the deduction is less scientific. All you can do is run traceroute, see which hop responds last, and deduce that this is either a full-blown firewall or at least the first router in the path that begins to block TTL expired packets. For example, here ICMP is being blocked to its destination, and there's no response from routers beyond client-gw.smallisp.net:

1 stoneface (192.168.10.33) 12.640 ms 8.367 ms 2 gw1.localisp.net (172.31.10.1) 214.582 ms 197.992 ms 3 gw2.localisp.net (172.31.10.2) 206.627 ms 38.931 ms 4 ds1.localisp.net (172.31.12.254) 47.167 ms 52.640 ms ... 14 ATM6.LAX2.BIGISP.NET (10.50.2.1) 250.030 ms 391.716 ms 15 ATM7.SDG.BIGISP.NET (10.50.2.5) 234.668 ms 384.525 ms 16 client-gw.smallisp.net (10.50.3.250) 244.065 ms !X * * 17 * * * 18 * * *

Route Tracing Countermeasure

The fix for traceroute information leakage is to restrict as many firewalls and routers from responding to ICMP TTL expired packets as possible. This is not always under your control because many of your routers are probably controlled by your ISP, but attempts should be made to motivate your ISP into action.

Detection To detect standard traceroutes on your border, you'll need to monitor for ICMP and UDP packets with a TTL value of 1.

Prevention To prevent traceroutes from being run over your border, you can configure your routers not to respond with TTL EXPIRED messages when they receive a packet with the TTL value of 0 or 1. The following ACL will work with Cisco routers:

access-list 101 deny ip any any 11 0 ! ttl-exceeded

Ideally, you'll want to block all unnecessary UDP traffic at your border routers altogether.

Banner Grabbing

Scanning for firewall ports is helpful in locating firewalls, but most firewalls do not listen on default ports like Check Point and Microsoft, so detection has to be deduced . You learned in Chapter 3 how to discover running application names and versions by connecting to the services found open and reading their banners. Firewall detection can be made in much the same way. Many popular firewalls will announce their presence by your simply connecting to them (of course, you will first have to find an open port to connect to by port scanning; refer to Chapter 2). For example, many proxy firewalls will announce their function as a firewall, and some will advertise their type and version. For instance, when we connect to a machine believed to be a firewall with netcat on port 21 (FTP), we see some interesting information:

C:\> nc -v -n 192.168.51.129 21 (UNKNOWN) [192.168.51.129] 21 (?) open 220 Secure Gateway FTP server ready.

The "Secure Gateway FTP server ready" banner is the telltale sign of an old Eagle Raptor box. Connecting further to port 23 (telnet) confirms the firewall brand name "Eagle," as shown here:

C:\> nc -v -n 192.168.51.129 23 (UNKNOWN) [192.168.51.129] 23 (?) open Eagle Secure Gateway. Hostname:

Finally, if you're still not convinced that our target host is a firewall, you can netcat to port 25 (SMTP), and it will tell you it is

C:\> nc -v -n 192.168.51.129 25 (UNKNOWN) [192.168.51.129] 25 (?) open 421 fw3.example.com Sorry, the firewall does not provide mail service to you.

As you can see in the preceding examples, banner information can provide attackers with valuable information in identifying your firewalls. Using this information, they can exploit well-known vulnerabilities or common misconfigurations.

Banner-Grabbing Countermeasure

The fix for this information leakage vulnerability is either to eliminate the open port on your firewall (this should not be allowed generally ) or to limit the banner information given out. If you must leave the ports open on the external interface of your firewall, you can usually change the banner to read a legal warning reminding the offender that all attempts to connect will be logged. The specifics of changing default banners will depend largely on your specific firewall, so you'll need to check with your firewall vendor.

Prevention To prevent an attacker from gaining too much information about your firewalls from the banners they advertise, you can often alter the banner configuration files. Specific recommendations will depend on your firewall vendor.

Advanced Firewall Discovery

If port scanning for firewalls directly, tracing the path, and banner grabbing haven't proved successful, attackers will take firewall enumeration to the next level. Firewalls and their ACL rules can be deduced by probing targets and noticing the paths taken (or not taken) to get there.

Simple Deduction with nmap

nmap is a great tool for discovering firewall information, and we use it constantly. When nmap scans a host, it doesn't just tell you which ports are open or closed, it tells you which ports are being blocked. The amount (or lack) of information received from a port scan can tell a lot about the configuration of the firewall.

A filtered port in nmap signifies one of three things:

• No SYN/ACK packet was received.

• No RST/ACK packet was received.

• An ICMP type 3 message (Destination Unreachable) with code 13 (Communication Administratively Prohibited - [RFC 1812]) was received.

nmap will pull all three of these conditions together and report it as a "filtered" port. For example, when scanning http://www.example.com, we receive two ICMP packets telling us that its firewall blocks ports 23 and 111 from our particular system:

Starting nmap V. 2.08 by Fyodor (fyodor@dhp.com, www.insecure.org/nmap/) Initiating TCP connect() scan against (192.168.51.100) Adding TCP port 53 (state Open). Adding TCP port 111 (state Firewalled). Adding TCP port 80 (state Open). Adding TCP port 23 (state Firewalled). Interesting ports on (192.168.51.100): Port State Protocol Service 23 filtered tcp telnet 53 open tcp domain 80 open tcp http 111 filtered tcp sunrpc

The "Firewalled" state in the verbose preceding output results from receiving an ICMP type 3, code 13 (Admin Prohibited Filter) packet, as seen in the tcpdump output:

23:14:01.229743 10.55.2.1 > 172.29.11.207: icmp: host 172.32.12.4 Unreachable admin prohibited filter 23:14:01.979743 10.55.2.1 > 172.29.11.207: icmp: host 172.32.12.4 Unreachable admin prohibited filter

How does nmap associate these packets with the original ones, especially when they are only a few in a sea of packets whizzing by on the network? The ICMP packet sent back to the scanning machine houses all the data necessary to understand what's happening. The port being blocked is the 1-byte portion in the ICMP header at byte 0x41 (1 byte), and the filtering firewall sending the message is in the IP portion of the packet at byte 0x1b (4 bytes).

Finally, an nmap "unfiltered" port appears only when you scan a number of ports and receive an RST/ACK packet back. In the "unfiltered" state, either our scan is getting through the firewall and the target system is telling us that it's not listening on that port, or the firewall is responding for the target and spoofing its IP address with the RST/ACK flag set. For example, our scan of a local system gives us two unfiltered ports when it receives two RST/ACK packets from the same host. This event can also occur with some firewalls, such as Check Point (with the REJECT rule) when it responds for the target by sending back an RST/ACK packet and spoofing the target's source IP address:

[root]# nmap -sS -p1-300 172.18.20.55 Starting nmap V. 2.08 by Fyodor (fyodor@dhp.com, www.insecure.org/nmap/) Interesting ports on (172.18.20.55): (Not showing ports in state: filtered) Port State Protocol Service 7 unfiltered tcp echo 53 unfiltered tcp domain 256 open tcp rap 257 open tcp set 258 open tcp yak-chat Nmap run completed -1 IP address (1 host up) scanned in 15 seconds

The associated tcpdump packet trace shows the RST/ACK packets received:

21:26:22.742482 172.18.20.55.258 > 172.29.11.207.39667: S 415920470:1415920470(0) ack 3963453111 win 9112 <mss 536> (DF) (ttl 254, id 50438) 21:26:23.282482 172.18.20.55.53 > 172.29.11.207.39667: R 0:0(0) ack 3963453111 win 0 (DF) (ttl 44, id 50439) 21:26:24.362482 172.18.20.55.257 > 172.29.11.207.39667: S 1416174328:1416174328(0) ack 3963453111 win 9112 <mss 536> (DF) (ttl 254, id 50440) 21:26:26.282482 172.18.20.55.7 > 172.29.11.207.39667: R 0:0(0) ack 3963453111 win 0 (DF) (ttl 44, id 50441)

Simple Deduction with nmap Countermeasures

There are two types of simple deduction nmap countermeasures, both of which are discussed below.

Detection The detection mechanisms for nmap scans are the same as those detailed in Chapter 2. We recommend customizing those detection mechanisms to extract just the scans that enumerate your firewalls.

Prevention To prevent attackers from enumerating router and firewall ACLs through the "ICMP Admin Prohibited Filter" technique, you can disable your router's ability to respond with the ICMP type 13 packet. On Cisco you can do this by blocking the device from responding to IP unreachable messages, like so:

no ip unreachables

Port Identification

Some firewalls have a unique footprint that is displayed as a series of numbers that are distinguishable from other firewalls. For example, Check Point will display a series of numbers when you connect to its SNMP management port, TCP 257. Although the mere presence of ports 256-259 on a system is usually a sufficient indicator for the presence of Check Point's FireWall-1, the following test will confirm it:

[root]# nc -v -n 192.168.51.1 257 (UNKNOWN) [192.168.51.1] 257 (?) open 30000003 [root]# nc -v -n 172.29.11.191 257 (UNKNOWN) [172.29.11.191] 257 (?) open 31000000

Port Identification Countermeasures

You can prevent connections to TCP port 257 (or any other Check Point port) by blocking them at your upstream routers. A simple Cisco ACL like the following can explicitly deny an attacker's attempt:

access-list 101 deny tcp any any eq 257 log ! Block Firewall-1 scans