Using CAR to mitigate SMURF attack

September 8, 2008 at 3:31 pm | Posted in QoS, Security | Leave a comment

Configuration (Modular QoS)

R4#

access-list 100 permit icmp any any echo-reply

class-map match-all SMURF_TRAFFIC
match access-group 100
!
!
policy-map SMURF_MITIGATION
class SMURF_TRAFFIC
police cir 64000 bc 8000 be 4000

interface Serial0/1
service-policy input SMURF_MITIGATION

interface Serial0/0.1 point-to-point
service-policy input SMURF_MITIGATION

Verification

R4#sh policy-map interface s0/1
Serial0/1

Service-policy input: SMURF_MITIGATION

Class-map: SMURF_TRAFFIC (match-all)
1860 packets, 2597440 bytes
30 second offered rate 61000 bps, drop rate 4000 bps
Match: access-group 100
police:
cir 64000 bps, bc 8000 bytes
conformed 1699 packets, 2355296 bytes; actions:
transmit
exceeded 161 packets, 242144 bytes; actions:
drop
conformed 54000 bps, exceed 4000 bps

Class-map: class-default (match-any)
72 packets, 6084 bytes
30 second offered rate 0 bps, drop rate 0 bps
Match: any

Configuration (Legacy QoS)

R4#
access-list 100 permit icmp any any echo-reply
interface Serial0/0.1 point-to-point
rate-limit input access-group 100 64000 8000 12000 conform-action transmit exceed-action drop
!
interface Serial0/1
rate-limit input access-group 100 64000 8000 12000 conform-action transmit exceed-action drop

Verification

R4#sh access-list 100
Extended IP access list 100
10 permit icmp any any echo-reply (278 matches)

R4#sh interface s0/1 rate-limit
Serial0/1
Input
matches: access-group 100
params:  64000 bps, 8000 limit, 12000 extended limit
conformed 130 packets, 195520 bytes; action: transmit
exceeded 12 packets, 18048 bytes; action: drop
last packet: 324ms ago, current burst: 3776 bytes
last cleared 00:01:10 ago, conformed 22000 bps, exceeded 2000 bps

Doc CD Navigation

There’s not a dedicated “configuration guide” or “command reference” specific for this.

Smurf attack is a general term describing one type of DoS attacks. The perpetrator launches many ICMP directed broadcast pings to many “proxy attacking networks” with spoof source address of the victim. The victim then is under a storm of return echo-reply traffic from “proxy attacking networks”.

To prevents the network from “attacking” other networks, or better said, taking part in a Smurf attack, we should disable directed broadcast, and drop packets with spoofed source IP (no ip unicast)

interface s0/1
 ip verify unicast reverse-path
interface e0/0
 no ip directed-broadcast

To minimize the effect of Smurf attack, just rate limit the Echo-Reply traffic (MQC and Legacy configuration at the top of this post).

For additional info, below is a security white paper

Strategies to Protect Against Distributed Denial of Service (DDoS) Attacks

General Smurf attack description can be found outside Cisco website, e.g. wikipedia

http://en.wikipedia.org/wiki/Smurf_attack

The Smurf attack is a way of generating a lot of computer network traffic to a victim host. That is, it is a type of denial-of-service attack. Specifically, it floods a target system via spoofed broadcast ping messages.

In such an attack, a perpetrator sends a large amount of ICMP echo requests (ping) traffic to IP broadcast addresses, all of it having a spoofed source address of the intended victim. If the routing device delivering traffic to those broadcast addresses delivers the IP broadcast to all hosts (for example via a layer 2 broadcast), most hosts on that IP network will take the ICMP echo request and reply to it with an echo reply, multiplying the traffic by the number of hosts responding. On a multi-access broadcast network, hundreds of machines might reply to each packet.[1]

In the late 1990s, many IP networks would participate in Smurf attacks (that is, they would respond to pings to broadcast addresses). Today, thanks largely to the ease with which administrators can make a network immune to this abuse, very few networks remain vulnerable to Smurf attacks.[2]

The fix is twofold:

  • Configure individual hosts and routers not to respond to ping requests to broadcast addresses,[1] and
  • Configure routers not to forward packets directed to broadcast addresses. Until 1999, standards required routers to forward such packets by default, but in that year, the standard was changed to require the default to be not to forward.[3]

Another proposed solution, to fix this as well as other problems, is network ingress filtering which rejects the attacking packets on the basis of the forged source address.[4

Advertisements

Leave a Comment »

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Create a free website or blog at WordPress.com.
Entries and comments feeds.

%d bloggers like this: