Along with all the security precautions we have looked at so far, there is one more worth adding to the list. Our final task is to help prevent Smurf attacks. Named after the original program that would launch this attack, Smurf uses a combination of IP spoofing and ICMP replies in order to saturate a host with traffic, causing a denial of service.
The attack goes like this: Woolly Attacker sends a spoofed ping packet (echo request) to the broadcast address of a network with a large number of hosts and a high-bandwidth Internet connection. This is known as the bounce site. The spoofed ping packet has a source address of the system Woolly wishes to attack.
The premise of the attack is that when a router receives a packet sent to an IP broadcast address (such as 206.121.73.255), it recognizes this as a network broadcast and will map the address to an Ethernet broadcast address of FF:FF:FF: FF:FF:FF. So when your router receives this packet from the Internet, it will broadcast it to all hosts on the local segment.
I’m sure you can see what happens next. All the hosts on that segment respond with an echo reply to the spoofed IP address. If this is a large Ethernet segment, there may be 500 or more hosts responding to each echo request they receive.
Since most systems try to handle ICMP traffic as quickly as possible, the target system whose address Woolly Attacker spoofed quickly becomes saturated with echo replies. This can easily prevent the system from being able to handle any other traffic, thus causing a denial of service.
This not only affects the target system, but your organization’s Internet link, as well. If the bounce site has a T3 link (45Mbps) but the target system’s organization is hooked up to a leased line (56Kbps), all communication to and from your organization will grind to a halt.
So how can you prevent this type of attack? You can take steps at the source site, bounce site, and target site to help limit the effects of a Smurf attack.
Blocking Smurf at the Source
Smurf relies on the attacker’s ability to transmit an echo request with a spoofed source address. You can stop this attack at its source by using the standard access list described earlier in this chapter. This will insure that all traffic originating from your network does in fact have a proper source address—stopping the attack at its source.
Blocking Smurf at the Bounce Site
In order to block Smurf at the bounce site, you have two options. The first is to simply block all inbound echo requests. This will prevent these packets from ever reaching your network.
If blocking all inbound echo requests is not an option, then you need to stop your routers from mapping traffic destined for the network broadcast address to the LAN broadcast address. By preventing this mapping, your systems will no longer receive these echo requests.
To prevent a Cisco router from mapping network broadcasts to LAN broadcasts, enter configuration mode for the LAN interface and enter the command
no ip directed-broadcast
Warning This must be performed on every LAN interface on every router. This command will not be effective if it is performed only on your perimeter router.
Blocking Smurf at the Target Site
Unless your ISP is willing to help you out, there is little you can do to prevent the effects of Smurf on your WAN link. While you can block this traffic at the network perimeter, this is too late to prevent the attack from eating up all of your WAN bandwidth.
You can, however, minimize the effects of Smurf by at least blocking it at the perimeter. By using reflexive access lists or some other firewalling device that can maintain state, you can prevent these packets from entering. Since your state table would be aware that the attack session did not originate on the local network (it would not have a table entry showing the original echo request), this attack would be handled like any other spoof attack and promptly dropped.
Additional Security Precautions
Along with all the security precautions we have looked at so far, there is one more worth adding to the list. Our final task is to help prevent Smurf attacks. Named after the original program that would launch this attack, Smurf uses a combination of IP spoofing and ICMP replies in order to saturate a host with traffic, causing a denial of service.
The attack goes like this: Woolly Attacker sends a spoofed ping packet (echo request) to the broadcast address of a network with a large number of hosts and a high-bandwidth Internet connection. This is known as the bounce site. The spoofed ping packet has a source address of the system Woolly wishes to attack.
The premise of the attack is that when a router receives a packet sent to an IP broadcast address (such as 206.121.73.255), it recognizes this as a network broadcast and will map the address to an Ethernet broadcast address of FF:FF:FF: FF:FF:FF. So when your router receives this packet from the Internet, it will broadcast it to all hosts on the local segment.
I’m sure you can see what happens next. All the hosts on that segment respond with an echo reply to the spoofed IP address. If this is a large Ethernet segment, there may be 500 or more hosts responding to each echo request they receive.
Since most systems try to handle ICMP traffic as quickly as possible, the target system whose address Woolly Attacker spoofed quickly becomes saturated with echo replies. This can easily prevent the system from being able to handle any other traffic, thus causing a denial of service.
So how can you prevent this type of attack? You can take steps at the source site, bounce site, and target site to help limit the effects of a Smurf attack.
Blocking Smurf at the Source
Smurf relies on the attacker’s ability to transmit an echo request with a spoofed source address. You can stop this attack at its source by using the standard access list described earlier in this chapter. This will insure that all traffic originating from your network does in fact have a proper source address—stopping the attack at its source.
Blocking Smurf at the Bounce Site
In order to block Smurf at the bounce site, you have two options. The first is to simply block all inbound echo requests. This will prevent these packets from ever reaching your network.
If blocking all inbound echo requests is not an option, then you need to stop your routers from mapping traffic destined for the network broadcast address to the LAN broadcast address. By preventing this mapping, your systems will no longer receive these echo requests.
To prevent a Cisco router from mapping network broadcasts to LAN broadcasts, enter configuration mode for the LAN interface and enter the command
no ip directed-broadcast
Warning This must be performed on every LAN interface on every router. This command will not be effective if it is performed only on your perimeter router.
Blocking Smurf at the Target Site
Unless your ISP is willing to help you out, there is little you can do to prevent the effects of Smurf on your WAN link. While you can block this traffic at the network perimeter, this is too late to prevent the attack from eating up all of your WAN bandwidth.
You can, however, minimize the effects of Smurf by at least blocking it at the perimeter. By using reflexive access lists or some other firewalling device that can maintain state, you can prevent these packets from entering. Since your state table would be aware that the attack session did not originate on the local network (it would not have a table entry showing the original echo request), this attack would be handled like any other spoof attack and promptly dropped.
Chapter 7: Check Point’s FireWall-1
Choosing which firewall to cover in this chapter was difficult. There are many firewall products on the market, with a wide range of features. I chose FireWall-1 because it is by far the most popular firewall on the market today. It has enjoyed a larger deployment than any other firewall solution, barring the Cisco router that we covered in Chapter 6.
FireWall-1 Overview
FireWall-1 supports a wide range of features, but uses three primary components to create and enforce security policies:
GUI management interface Management Server FireWall Module
GUI Management Interface
A GUI client is used to define a network (or enterprise) Security Policy (along with Address Translation and Bandwidth policies), which in turn is defined by using network objects (hosts, gateways, etc.) and security rules. The GUI includes the Log Viewer and System Status Viewer.
FireWall-1 creates an INSPECT script from the policies (Security, Address Translation, and/or Bandwidth) that are defined at the GUI. INSPECT is an object-oriented, high-level scripting language that is proprietary to Check Point. The INSPECT script is then compiled to create the Inspection Code, which is then loaded into the various