Yesterday i re-worked the Attack Mitigation lab. I could remember some of the stuff that i learnt when i configured this lab for the first time a couple of weeks back. But, thanks to my memory, i forgot lotsa stuff

Here are some of the aspects of the lab that i wanted to share with you!

• There was a task where we had to use NBAR to block HTTP requests going for certain file-types. First thing we do is to classify the class-map using the REGEX strings.
  • Suppose our task asks us to block files with a “.exe” extension. This can be achieved using 2 Regex’s. Either “*.exe” or *\.exe
  • The second aspect that i found interesting was, it doesn’t matter what direction we apply the service-policy on the interface. NBAR is direction independant. It performs the same way when applied in either direction.
• I came across a couple of tasks where non-ip traffic had to be blocked/permitted.
  • One of the ways of doing this was through matching the traffic by their ethertype values.
  • So , i was searching for a location in the DocCD where i can find this. Thanks to twitter , someone pointed this out to me
  • In the DocCD , Click in the left pane on Products, then in the middle pane on Routers, then in the right pane on Cisco 3200 Series Rugged Integrated Services Routers, then when at the new page click on Configure –> Configuration Examples, then Cisco 3200 Series Wireless MIC Software Configuration Guide, then on the new page click on Protocol Filters which is 5th from the bottom.
  • IMO this is definitely a location to remember, ‘coz this would help us fetch easy points in tasks where all we have to do is match the ethertype value.
• DHCP Snooping
  • There’s a feature i found very interesting here
  • The DHCP client will set the “giaddr” field to 0 when it sends the DHCP messages. There is no data in the Option -82 fields in the DHCP packet.
  • This packet will be accepted by the DHCP server without any issues.
  • Now, when a switch performing DHCP snooping is inserted between the Client and the server, the switch will add DHCP information option ( Option 82 ) to all the received packets.
  • Seeing this, the server get’s confused , ‘coz the server is supposed to receive packets with either
    • NO giaddr , NO Option 82
    • YES giaddr, YES Option 82
  • Seeing that this doesn’t have the giaddr set, but has only option 82, the server that something’s wrong and drops the Client’s DHCP packet.
  • This can be avoided by entering the following command on the DHCP server ( we’re assuming that the IOS DHCP server is being used )
  • #ip dhcp relay information trusted-all (global configuration ) or #ip dhcp relay information trusted (interface-level command )
  • Also don’t forget to configure the switch interface connected to the DHCP server as “Trusted”
• DAI ( Dynamic Arp Inspection)
  • One thing to always remember is that, suppose when the switch configured to run DAI , receives an ARP packet on an ARP-untrusted port, it checks 2 locations before it permits/denies it.
    • If there is an ARP ACL configured, then this is checked first.
    • If the IP/MAC entry doesn’t exist in the ARP ACL, it checks the DHCP snooping database.
  • It’s important to remember this order, because you might be required to configure tasks where the ARP ACL over-rides the DHCP binding values, etc.
• SOURCE GUARD
  • Source guard as we all know, makes sure that we receive packets with Legit. IP on the configured interface. If any packet from any other IP address is received, then the packet is blocked.
  • This prevents IP spoofing attacks
  • The configuration is pretty simple.
  • Now, there’s also an option where we can check the MAC-ADDRESS of the incoming packets too, to see if they are being spoofed or not.
  • For this to work, we need to do 2 things
    • Turn on port-security on the switch and on the port
    • Specify the keyword “port-security” after the “ip verify source” command
• Rate-limiting
  • This is not my strong point and i’m making a video on this as we speak. I’ll release that as soon as it’s done. Hopefully it’ll help you understand the concept of CIR, Burst, excess burst a little better
  • One thing to keep in mind : When configuring, please take time to have a good look at the units which are to be used during configuration .
  • Example : In the “rate-limit” command, the CIR is to be specified in Bits/second, but the normal and excess burst have to be configured in “Bytes/second!” I don’t know why they configured it this way, so please stay frosty on this feature.
• URPF
  • Know the difference between “Loose” and “strict” uRPF and the configuration difference.
  • There was a task which required me to log the packets that failed uRPF check. I searched for the log keyword in the ” ip verify unicast source..” command , but i didn’t find it.
  • After racking my nearly empty brain for sometime, i figured that we could specify an ACL to log the packets it denies and call the ACL in the uRPF command.
  • How this works is as follows:
    • Suppose we enter this command
      • #int fa 0/0
        • #ip verify unicast  source reachable-via rx 102
    • What this says is, suppose there are packets which are arriving on the f a 0/0 interface, and they fail the uRPF check, the “FATE” of the packets is allowed to be decided by the ACL “102″.
    • If the acl says deny all traffic, then the packet is dropped. If the ACL says “permit”, the packet is passed , despite the fact that it failed the uRPF check.
    • This feature can now be used to log the packets which are being denied by uRPF. We can do this by using the “log” keyword in the ACL’s.
• POLICY-BASED-ROUTING
  • This was somewhere i screwed up
  • I didn’t know that you could deny traffic by using route-maps.
  • I interpret route-maps as a way of screwing with the already configured routing for  a packet.
  • So when a packet enters an interface with a route-map configured, if the packet matches the conditions present in the route-map, then the route-map’s ACTION , overrides the default routing action for the packet.
  • To drop the packet, we configure the route-map to route the packet to Null 0 (Black hole! )
• SWITCHPORT PROTECTED
  • This is a “mini” PVLAN feature.
  • By typing this on an interface, achieve the following functions:
  • • it can’t communicate with other protected ports on the switch
    • it can communicate with other non-protected ports on the switch
    • it can communicate with other protected ports on other switches

I hope you’re as excited about learning new stuff , like i am!

Cheers,

TacACK

P.S : Keep an eye on www.routsec.com . Ryan’s coming up with some kick-ass configuration challenges as well as articles for you! See you there!