Smurf Attacks and Countermeasures

Smurf attacks use a combination of IP Address Spoofing and ICMP flooding to overwhelmingly saturate a target network with traffic to such an extent that all normal traffic is effectively “drowned out” thereby causing a Denial of Service (DoS) attack. Smurf attacks consist of three separate elements; the source site, the bounce site and the target site.

·         First of all an attacker will select a bounce site. This is usually a very large network.

·         The attacker then modifies a PING packet to contain the address of the target site as the PING packet’s source address.

·         Next the attacker sends the spoofed PING packet to the broadcast address of the target site.

·         This will result in the bounce site broadcasting the spoofed packet to all devices configured to receive messages from that broadcast address, which by default will be all devices on that Local Area Network (LAN) or subnet segment if the network has been configured into a number of smaller subnets for administrative purposes.

·         All devices on the bounce site network receiving this misinformation will not know that it is misinformation and so they will automatically respond to the request with a reply to the site which is the intended target of the smurf attack.

·         This results in the target site being overwhelmed by a huge number of erroneous replies that it neither requested nor knows about.

·         The outcome of the oversaturation is that the target is unable to process the requests often due to a buffer overflow and hence it will hang or reboot.

In many cases such is the overwhelming effect of this type of attack that it will cause the target to appear to simply grind to a halt in attempting to process the flood of incoming reply PINGs from the bounce site.

Another consequence can be that the target machine’s CPU processing queue, internal counters, out of sequence processing units and cache simply cannot cope with the flood and the CPU will register processing queue errors which can cause the CPU to continually flush its processing pipeline and buffers continuously with the result that the CPU will suddenly appear to be running at 100% up until such time as it overheats and becomes an unusable blob of silicone.

Fortunately; modern CPUs have thermal regulatory mechanisms that usually prevent total obliteration of the CPU due to this type of processing strain and loop running but many older systems and those with thermal throttling turned off will often die.

Smurf Attack Countermeasures

Countering a smurf attack is not as hard as one might expect. A correctly configured “stateful” firewall device will know that the massive influx of ICMP Ping replies was never requested by any devices internal to it and if configured to do so it will simply drop these packets. This will protect devices internal to the firewall.

Also configuring your firewall to deny external ICMP traffic access to your internal network will work just as effectively. Once again this may make remote administration and connectivity testing a little more difficult than would otherwise be the case but this is a small price to pay for a respectable degree of immunity to this type of attack.

However; if the attacker is able to send enough spoofed ICMP PING packet reply requests and the exploited “bounce” site is large enough, the number of ICMP replies the “bounce” network is triggered to send your way may be large enough to overwhelm your modem/router/firewall device(s). The effects of this inundation of arriving PING replies may be such that all of the firewall device’s resources become consumed in dealing with the smurf attack flood.

As a result it may be unable to service legitimate network requests and so a denial of service will be experienced by all internal network devices requesting external access (Internet access or a branch office network access) as will all external requests for access to internal network resources; such as your publically accessible website.

Failover Redundancy

This is one reason why having a redundant failover backup device(s) and extra “live” IP Addresses are such good ideas. While the redundant failover system may allow your internal network to have external access capabilities it is much harder to provision for similar redundancy for external requests for internal resources access.

ISP Involvement

One thing you can do is to get your ISP to block all ICMP traffic at their end. This should get you back up and running but be warned it will take a little time unless you have entered into an agreement that specifically states the actions to be taken by both yourself and your ISP in the event of your being attacked by a smurf Denial of Service (DoS) attack.

This falls into the category of preventative countermeasures since you have processes and procedures already in place just waiting for a trigger event before they are swung into action. Your ISP will be able to drop the unsolicited PING replies while rerouting legitimate traffic to your “spare”/alternate IP Address.

Attacker Identification

The ultimate objective is to identify the network that is being used as the “bounce” site and to stop their inadvertent broadcasting of the spoofed ICMP PING reply requests. It is also be possible to identify the source of the spoofed ICMP PING reply request broadcasts (the attacker) by back tracking the path the requests came in via.

This is one reason why the more sophisticated attacker has moved on and uses other variations on the smurf attack theme such as Distributed Denial of Service (DDoS) and Distributed Reflected Denial of Service attacks using botnets to create a massive wave of incoming traffic to overwhelm the target (victim). I will discuss them and the appropriate countermeasures in another article.