Well this post really isnt about stopping the smurf attack. The post covers rate limiting the type of traffic that is used in a smurf attack (ICMP Echo and Echo Reply).

Basically you want to avoid 3 things in this type of attack:

• Being the Victim
• Being the Reflector
• Being the Source

Using the Committed Access Rate (CAR) feature in Cisco IOS will allow you to limit the effect of a smurf DoS attack by defining acceptable levels of traffic allowed for ICMP.

First create the ACL identifying the ICMP traffic you want to limit. In this case you want to avoid your hosts being targeted by limiting echo replies and also being used as a reflecting by limiting echo requests.

access-list 190 permit icmp any any echo
access-list 190 permit icmp any any echo-reply

Its important to not that if you are being targeted only your ISP can effectively limit the traffic going to your site. Limiting on your device will indeed give you the opportunity to stop the traffic from entering your network. I have seen several TCP Syn DoS attacks bring a poorly configured router based firewall to its knees, to the grave and back to its knees again after a reboot.

Assign rate limiting to the internet facing interface:

int fa0
rate-limit input access-group 190 8000 1500 2000 conform-action transmit exceed-action drop
rate-limit output access-group 190 8000 1500 2000 conform-action transmit exceed-action drop

I configured both inbound and outbound. This will allow me to limit ICMP echo and echo reply in both scenarios of being a target and a reflector. The bit per second value that I used is quite low (8000). I did this in order to test and verify I could exceed the burst rate and get some drops.
…click here to read more

EZVPN isnt actually that bad. Im just having a hard time figuring out what makes it so easy. I guess the implementation requirements that would drive you to use EZVPN would better define EZVPN as easier than say a good ole lan to lan or remote access vpn config if that makes sense .

Here is the quick and dirty config. Left out XAUTH because I thought it was lame that you have to log into the router to provide credentials before completing the tunnel. You can also configure web control to allow a user to provide credentials through a web browser which is much easier but doesn’t seem to be a option on 12.2.

ROUTER A — The EZVPN SERVER

aaa new-model
aaa authentication login default none
aaa authorization network grouplist local
cry isakmp policy 1
group 2
authentication pre-share
hash md5
!
cry isakmp client configuration group cisco
key cisco
!
crypto ipsec transform-set DMVPN-SET esp-3des esp-md5-hmac
cry dynamic-map DYNEZVPN 1
set transform-set DMVPN-SET
reverse-route
cry map vpnmap isakmp author list grouplist
cry map vpnmap client configur address respon
crypto map vpnmap 1 ipsec-isakmp dyn DYNEZVPN
int f0/0
cry map vpnmap

ROUTER B — The EZVPN Client

cry ipsec client ezvpn RTR2VPN
connect auto
group cisco key cisco
mode network-extension
peer 192.168.56.2
!
int f0/0
crypto ipsec client ezvpn RTR2VPN inside
int f0/1
crypto ipsec client ezvpn RTR2VPN

The key item here is to make sure you have the interfaces marked correctly. If you notice in the above code I had to define one interface as “inside” for ezvpn. I also am not using any nat in this example. If you configure nat, nat bypass would need to be in place. Surprisingly enough the ezvpn tunnel came up without a snag.

Router#sh cry ipsec sa | i inter|encap|decap
interface: FastEthernet0/0
#pkts encaps: 19, #pkts encrypt: 19, #pkts digest 19
#pkts decaps: 19, #pkts decrypt: 19, #pkts verify 19
Router#ping 192.168.55.2 source l0
!
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.55.2, timeout is 2 seconds:
Packet sent with a source address of 192.168.4.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 80/92/108 ms
Router#sh cry ipsec sa | i inter|encap|decap
interface: FastEthernet0/0
#pkts encaps: 24, #pkts encrypt: 24, #pkts digest 24
#pkts decaps: 24, #pkts decrypt: 24, #pkts verify 24
Router#

Was doing a little configuration with NBAR and class setting. I decided to try and block the basic image types I could think of off the top of my head (jpg, bmp, gif, png). So I started my config like so:

rtr1(config)# class-map match-any Drop-Images
rtr1(config-cmap)# match protocol http url "*.jpg"
rtr1(config-cmap)# match protocol http url "*.gif"
rtr1(config-cmap)# match protocol http url "*.bmp"
rtr1(config-cmap)# match protocol http url "*.png"
rtr1(config-cmap)# match protocol http url "*.jpeg"
rtr1(config-cmap)# exit
rtr1(config)#

The match protocol http url allows me to match strings in the URL. Now the next step is to apply the class-map to a policy-map so this can be a applied to a interface.

rtr1(config)# policy-map URL-FILTER
rtr1(config-pmap)# class Drop-Images
rtr1(config-pmap)# set dscp 1

The “set dscp 1″ sets the dscp value to 1 for any packet that matches any of the criteria defined in the class-map Drop-Images. How is this relevant? Well my goal was to drop and packet that was requesting a image I defined in the URL. So what I need to do next is create an outbound acl on the routers internet facing interface and drop any packet with the dscp value equal to 1.

ip access-list extended acl_outbound
deny ip any any dscp 1
permit ip any any
int fa0
access-group acl_outbound out
…click here to read more