You might ask; " why would some want to do this? "
Well simple, we might not want our network servers and resources tied-up with delivering icmp traffic.
As general rule, that I try to follow is to limit icmp traffic to no more than 1-to-10% of my bandwidth both in/out bound. What this means for a 100 meg link; we would limit icmp traffic to just 1-to-10mbps peak.
Take google for example, there ipv4 dns servers which are probably ping every second by god only knows who. They have deployed icmp ( echo-reply ) rate controls because of this.
e.g
sh-3.2$ ping -c 1 -s 200 8.8.4.4
PING 8.8.4.4 (8.8.4.4): 200 data bytes
72 bytes from 8.8.4.4: icmp_seq=0 ttl=47 time=33.467 ms
wrong total length 92 instead of 228
--- 8.8.4.4 ping statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 33.467/33.467/33.467/0.000 ms
sh-3.2$
So my 200byte echo-request, only returned backed 72 bytes. They have to do this or if not, they would see even more icmp traffic outbound, and this would conflict with the whole object of the delivery of the DNS response or other business critical services.
btw the ipv6 name-server implement the same concept;
e.g
#
# ping6 -c 1 -s 333 2001:4860:4860::8888
PING6(381=40+8+333 bytes) 2607:f2f8:a250::2 --> 2001:4860:4860::8888
72 bytes from 2001:4860:4860::8888, icmp_seq=0 hlim=55 time=32.986 ms
--- 2001:4860:4860::8888 ping6 statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 32.986/32.986/32.986/0.000 ms
#
# ping6 -c 1 -s 333 2001:4860:4860::8844
PING6(381=40+8+333 bytes) 2607:f2f8:a250::2 --> 2001:4860:4860::8844
72 bytes from 2001:4860:4860::8844, icmp_seq=0 hlim=55 time=32.561 ms
--- 2001:4860:4860::8844 ping6 statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 32.561/32.561/32.561/0.000 ms
#
Okay one of the most simplest means to rate limit icmp & that's easy to deploy for cisco ;
e.g
config t
int ten 1/1
no ip unreachables
!
! ( or globally we do )
!
ip icmp rate-limit unreachable 300
ip icmp rate-limit unreachable DF 300
!
end
But that only covers the processing of type 3 unreachable. ICMP is used for other purposes outside of unreachables. But what about our icmp echo-request and the resulting echo-replies?
( control-plane & protection of traffic directed at the device )
Will requires control-plane policing, which tails-drop traffic after we reach the set threshold. A simple policer on a edge-router could be crafted in this fashion;
e.g
ip access-list extended LOC_TRAFFIC
deny tcp any any eq bgp
deny tcp any any eq 22
deny tcp any eq bgp any
deny udp any any eq 161
permit ip any any
!
class-map match-all LOC_TRAFFIC
match access-group name LOC_TRAFFIC
!
!
policy-map CPP-policer
class LOC_TRAFFIC
police cir 128000 bc 8000 be 8000 conform-action transmit exceed-action drop violate-action drop
!
class class-default
police cir 128000 bc 8000 be 8000 conform-action transmit exceed-action drop violate-action drop
and applied for control-plane ;
config t
control-plane
service-policy in CPP-policer
end
So basically we exempt our critical services such as BGP, SNMP , etc,.... And then rate limit all other traffic inbound to 128kbps. I could just place this policing under my class-default to even better controls as another option.
You can used the following commands for validation of control-plane-policing & status ;
Keep mind this will not prevent some one from flooding you with a pure volumetric-flood, but it would prevent the control-plane from having to handle & the processing of the traffic identified within the class-maps.
We could tighten the ropes a little, by identifying some specific hosts or networks that we can trust and drop the ANY src.
eg
ip access-list extended LOC_TRAFFIC
remark allow our BGP peers
deny tcp any any eq bgp
deny tcp any eq bgp any
#
deny tcp 10.0.0.0 0.0.255.255 any eq 22
# here's my management station
deny udp 172.16.18.1 0.0.0.0 any range 161-162
# here's my tftp services ( we don't want to happen file transfer upgrades)
deny udp 172.16.18.1 0.0.0.0 any eq 69
# now we rate this rest of the world
permit ip any any
!
Control plane policing, keeps our systems freed and protected from excessive traffic. We don't want the control-plane busy with handling misc or warrant traffic. If some one for examples, tries to DoS the control-plane, we want the router to be happy and continuing to deliver the forwarding traffic over the data-plane.
It's also a good strategy to police icmp & traffic from local hosts within the LAN. This is crucial if a infected hosts starts to act up and attempts to flood another external destination.
class-map match-all icmp
match protocol icmp <-------HERE
class-map match-any bigfiles
description " alist of big mime-types files"
match protocol http mime "iso9660-image"
match protocol http mime "application/x-gtar"
match protocol http mime "application/x-tar"
match protocol http mime "application/x-7z-compressed"
match protocol http mime "application/zip"
match protocol http mime "application/x-rar-compressed"
match protocol http mime "application/application/x-bzip"
match protocol http mime "application/application/x-bzip2"
class-map match-all udp-traffic
match not protocol rtp
match not protocol skype
match access-group name udp-traffic-acl
class-map match-all port0
match access-group name port0
class-map match-any youtube
match protocol http host "youtube.com"
class-map match-all bittorent
match protocol bittorrent
!
!
policy-map rate-in
class icmp
police 384000 conform-action transmit exceed-action drop
class bittorent
drop
class port0
drop
And applied to your interfaces facing your LAN subnets;
config t
int gi 1/1
service-policy input rate-in
end
Almost all cisco devices has a means to filtering and rate-limit icmp traffic for ipv4 and ipv6. You should deploy some type of filtering or keep in mind the ability for execution of rate-limits.
Ken Felix
Freelance Network/Security Engineer
kfelix -a-t socpuppets-d-o-t- com
No comments:
Post a Comment