The Latest In Denial Of Service Attacks: “Smurfing”

Description and Information to Minimize Effects

Craig A. Huegen <chuegen@cisco.com>

Cisco Systems, Inc.

NANOG 11 Interprovider Operations BOF

Description of “Smurfing”

Newest DoS attack

Network-based, fills access pipes

Uses ICMP echo/reply packets with broadcast networks to multiply traffic

Requires the ability to send spoofed packets

Abuses “bounce-sites” to attack victims

Traffic multiplied by a factor of 50 to 200

Multiplied Bandwidth

Perpetrator has T1 bandwidth available (typically a cracked account), and uses half of it (768 Kbps) to send spoofed packets, half to bounce site 1, half to bounce site 2

Bounce site 1 has a switched co-location network of 80 hosts and T3 connection to net

Bounce site 2 has a switched co-location network of 100 hosts and T3 connection to net

(384 Kbps * 80 hosts) = 30 Mbps outbound traffic for bounce site 1

(384 Kbps * 100 hosts) = 37.5 Mbps outbound traffic for bounce site 2

Victim is pounded with 67.5 Mbps (!) from half a T1!

Profiles of Participants

Typical Perpetrators

Cracked superuser account on well-connected enterprise network

Superuser account on university residence hall network (Ethernet)

Typical PPP dial-up account (for smaller targets)

Typical Bounce Sites

Large co-location subnets

Large switched enterprise subnets

Typically scanned for large numbers of responding hosts

Typical Victims

IRC Users, Operators, and Servers

Providers who eliminate troublesome users’ accounts

Prevention Techniques

How to prevent your network from being the source of the attack:

Apply filters to each customer network

Ingress:

Allow only those packets with source addresses within the customer’s assigned netblocks

Apply filters to your upstreams

Egress:

Allow only those packets with source addresses within your netblocks to protect others

Ingress:

Deny those packets with source addresses within your netblocks to protect yourself

This also prevents other forms of attacks as well

Prevention Techniques

How to prevent being a “bounce site”:

Turn off directed broadcasts to subnets with 5 hosts or more

Cisco: Interface command “no ip directed-broadcast”

Proteon: IP protocol configuration “disable directed-broadcast”

Bay Networks: Set a false static ARP address for bcast address

Use access control lists (if necessary) to prevent ICMP echo requests from entering your network

Probably not an elegant solution; makes troubleshooting difficult

Encourage vendors to turn off replies for ICMP echos to broadcast addresses

Host Requirements RFC-1122 Section 3.2.2.6 states “An ICMP Echo Request destined to an IP broadcast or IP multicast address MAY be silently discarded.”

Patches are available for free UNIX-ish operating systems.

Prevention Techniques

If you do become a bounce site:

Trace the traffic streams to the edge of your network, and work with your upstream or peer in order to track the stream further

MCI’s DoSTracker tool

Manual tracing/logging tips

Prevention Techniques

How to suppress an attack if you’re the victim:

Implement ACL’s at network edges to block ICMP echo responses to your high-visibility hosts, such as IRC servers

Again, will impair troubleshooting -- “ping” breaks

Will still allow your access pipes to fill

Work with upstream providers to determine the help they can provide to you

Blocking ICMP echoes for high-visibility hosts from coming through your access pipes

Tracing attacks

Prevention Techniques

Technical help tips for Cisco routers:

BugID CSCdj35407 - “fast drop” ACL code

This bug fix optimizes the way that packets denied by an ACL are dropped within IOS, reducing CPU utilization for large amounts of denied traffic.

First major release of integration is 11.1(14)CA

Not available in 11.2 yet, but coming

BugID CSCdj35856 - ACL logging throttles

This bug fix places a throttle in IOS which will allow a user to specify the rate at which logging will take place of packets which match a condition in an ACL where “log” or “log-input” is specified.

First maintenance release of integration is 11.1(14.1)CA

Not available in 11.2 yet, but coming

References

White paper on “smurf” attacks:

http://www.quadrunner.com/~chuegen/smurf.txt

Ingress filtering:

ftp://ds.internic.net/internet-drafts/draft-ferguson-ingress-filtering-03.txt

MCI’s DoSTracker tool:

http://www.security.mci.net/dostracker/

Other DoS attacks:

“Defining Strategies to Protect Against TCP SYN Denial of Service Attacks”

http://www.cisco.com/warp/public/707/4.html

“Defining Strategies to Protect Against UDP Diagnostic Port Denial of Service Attacks”

http://www.cisco.com/warp/public/707/3.html

Author

Craig Huegen

<chuegen@cisco.com>

-or-

<chuegen@quadrunner.com>



	Description and Information to Minimize Effects

	Craig A. Huegen <chuegen@cisco.com>
	Cisco Systems, Inc.

	NANOG 11 Interprovider Operations BOF


	Newest DoS attack
		Network-based, fills access pipes
		Uses ICMP echo/reply packets with broadcast networks to multiply traffic
		Requires the ability to send spoofed packets
	Abuses “bounce-sites” to attack victims
		Traffic multiplied by a factor of 50 to 200


	Perpetrator has T1 bandwidth available (typically a cracked account), and uses half of it (768 Kbps) to send spoofed packets, half to bounce site 1, half to bounce site 2
	Bounce site 1 has a switched co-location network of 80 hosts and T3 connection to net
	Bounce site 2 has a switched co-location network of 100 hosts and T3 connection to net
	(384 Kbps * 80 hosts) = 30 Mbps outbound traffic for bounce site 1
	(384 Kbps * 100 hosts) = 37.5 Mbps outbound traffic for bounce site 2
	Victim is pounded with 67.5 Mbps (!) from half a T1!


	Typical Perpetrators
		Cracked superuser account on well-connected enterprise network
		Superuser account on university residence hall network (Ethernet)
		Typical PPP dial-up account (for smaller targets)
	Typical Bounce Sites
		Large co-location subnets
		Large switched enterprise subnets
		Typically scanned for large numbers of responding hosts
	Typical Victims
		IRC Users, Operators, and Servers
		Providers who eliminate troublesome users’ accounts


How to prevent your network from being the source of the attack:
	Apply filters to each customer network
		Ingress:
			Allow only those packets with source addresses within the customer’s assigned netblocks
	Apply filters to your upstreams
		Egress:
			Allow only those packets with source addresses within your netblocks to protect others
		Ingress:
			Deny those packets with source addresses within your netblocks to protect yourself
This also prevents other forms of attacks as well




How to prevent being a “bounce site”:
	Turn off directed broadcasts to subnets with 5 hosts or more
		Cisco: Interface command “no ip directed-broadcast”
		Proteon: IP protocol configuration “disable directed-broadcast”
		Bay Networks: Set a false static ARP address for bcast address
	Use access control lists (if necessary) to prevent ICMP echo requests from entering your network
		Probably not an elegant solution; makes troubleshooting difficult
	Encourage vendors to turn off replies for ICMP echos to broadcast addresses
		Host Requirements RFC-1122 Section 3.2.2.6 states “An ICMP Echo Request destined to an IP broadcast or IP multicast address MAY be silently discarded.”
		Patches are available for free UNIX-ish operating systems.


If you do become a bounce site:
	Trace the traffic streams to the edge of your network, and work with your upstream or peer in order to track the stream further
		MCI’s DoSTracker tool
		Manual tracing/logging tips


How to suppress an attack if you’re the victim:
	Implement ACL’s at network edges to block ICMP echo responses to your high-visibility hosts, such as IRC servers
		Again, will impair troubleshooting -- “ping” breaks
		Will still allow your access pipes to fill
	Work with upstream providers to determine the help they can provide to you
		Blocking ICMP echoes for high-visibility hosts from coming through your access pipes
		Tracing attacks


Technical help tips for Cisco routers:
	BugID CSCdj35407 - “fast drop” ACL code
		This bug fix optimizes the way that packets denied by an ACL are dropped within IOS, reducing CPU utilization for large amounts of denied traffic.
		First major release of integration is 11.1(14)CA
		Not available in 11.2 yet, but coming
	BugID CSCdj35856 - ACL logging throttles
		This bug fix places a throttle in IOS which will allow a user to specify the rate at which logging will take place of packets which match a condition in an ACL where “log” or “log-input” is specified.
		First maintenance release of integration is 11.1(14.1)CA
		Not available in 11.2 yet, but coming



White paper on “smurf” attacks:
	http://www.quadrunner.com/~chuegen/smurf.txt
Ingress filtering:
	ftp://ds.internic.net/internet-drafts/draft-ferguson-ingress-filtering-03.txt
MCI’s DoSTracker tool:
	http://www.security.mci.net/dostracker/
Other DoS attacks:
	“Defining Strategies to Protect Against TCP SYN Denial of Service Attacks”
		http://www.cisco.com/warp/public/707/4.html
	“Defining Strategies to Protect Against UDP Diagnostic Port Denial of Service Attacks”
		http://www.cisco.com/warp/public/707/3.html