I was going through my my previous posts and i realized that i’d never written about the IOS F/w Lab.

So today, i’ve scheduled a rack session which will start at 16:30 IST.As usual, I’ll be live blogging the lab on google wave.

Feel free to join the wave where we can discuss any issues/problems/solutions real-time!

If you can’t join me there, i’ll be posting an overview on the configuration i’m going to be doing today , later on this site.

My wave id is ” ybnmts at googlewave dot com”. See you there. Buzz me once you get there and then i’ll you onto the waves.

Cheers,

TacACK

From now on, i’m increasing the pace at which i’m labbing. I’ve booked INE racks for 3 days a week ( Mon, Wed , Fri ) from 4:30 PM to 10:00 PM.

I figured i need to increase the amount of time i spend labbing , to better sharpen my labbing / debugging skills.

So here’s the stuff that i’m going to do now

• Block www.google.com on my PC. I know this sounds crazy, but there’s a valid reason . Everytime i want some help on a particular topic, i’m really tempted to google it and click on the best link. However this approach will not help me during my lab. So i’m going to block www.google.com and i’m going to completely rely upon the DocCD for reference.
• Spend the alternate days ( Tue, Thu , Sat ) studying technologies. I am hoping to get some good study done during these days.
• Regarding the sections on the CCIE-sec lab
  • Advanced Mitigation and Control-plane security are two fields which i definitely wanna nail. In fact, after doing these a couple of times, i feel that most of the configs here are right from the DocCD with a little change here and there. I’d be really unhappy if i lost points in these 2 sections.
  • Similarly, i’m going to be focussing on the IPS section and i don’t want to lose any points in that section.
  • Since 3 are taken care of ( atleast theoretically  ), there are 4 more sections remaining : VPN , IOS FW , ASA , ID MGMT.
  • I’m absolutely sure that there might be tasks in ID MGMT or VPN in which i’d screw up. So i need to spend a little more time every week on those two sections.

For now, i’m just doing technology labs ( i.e Vol 1 Labs ). I don’t feel ready to do the Vol 2 labs yet. But hopefully, i should be in a state to start them by the end of the coming week.

Ryan and I were planning to do a Mock Vol 2 lab on a weekend, just for kicks . Well, not entirely for kicks . We were hoping to get an idea about how the vol 2 lab is. The “evil” 8 hr labs scare me! Honest to GOD! So i wanna alleviate this fear by starting the Vol 2 labs ASAP. I’ll definitely keep you posted on any developments regarding that.

For my detailed schedule for the next week, please visit my google Calendar page HERE.

Finally, i wanted to thank all of you for visiting my site everyday. This medium allows me to clear my mind and plan my studies more effectively. I also end up studying more ‘coz of the site And, i hope this helps you in some little way.

Thank you all and good luck with your CERTS too! See you tomorrow!

Cheers,

TacACK

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!

Hello!

Yesterday, as the title suggests, i re-visited the Control Plane security Vol 1 Labs. I’d worked this lab earlier and had posted an article about it. Please refer to that article for lotsa technical stuff that i found in the lab. Here i’ll be making a quick listing of the other interesting stuff that i encountered yesterday when doing the labs

• There was a task which focused on Control-plane protection. The task asked for the HTTP traffic headed to the host-subinterface to be rate-limited.
  • So i tried this configuration to match the traffic
    • #class-map HTTP_RATE
      • #match protocol http
    • #policy-map HTTP_RATE
      • #class HTTP_RATE
        • #police……<bla>
  • But when i applied this on the host subinterface using the “service-policy” command, it gave me an error saying that an unknown type of traffic was being classified under the class-map , and therefore the policy-map couldn’t be applied to the Host-subif.
  • To counter this, i tried another method to configure the same thing. i.e to match HTTP packets. I create an ACL, and called it under the class-map.
    • #access-list 101 permit tcp any any eq www
    • #class-map HTTP_RATE
      • #match access-group 101
  • This worked just fine! Although this behaviour was wierd, i tried it many times. Everytime i tried it, i got the same error messages for the 1st configuration method.
  • This maybe just a point to note. In-case you get similar errors in the lab, don’t panic; Try other ways of matching the traffic.
• BGP TTL Security
  • This is such an awesome concept! I discovered this yesterday thanks to Ryan and the DocCD.
  • I was on google wave ( Live-blogging my lab ), when Ryan wrote a small summary of what TTL-security achieves and how this applies to situations where eBGP peers are multiple hops from each other.
  • Here’s what Ryan wrote :

  BGP Generic TTL Security Mechanism.

  Internal BGP (iBGP) – these are neighbors connected within the same AS. By default, these neighbors can be reached over as many hops as it takes (well, I guess 255).

  External BGP (eBGP). By default, you can only reach a neighbor being 1 hop away. Anymore hops and you would have to use the following command (most common)

  #neighbor x.x.x.x ebgp-multihop (0-255).

  This command will connect to a neighbor up to the specified number of hops away.

  For example, if we used neighbor x.x.x.x ebgp-multihop 10, the the neighbor can be 2 hops away or 9, anything lower that 10.

  Another command exists to disable this TTL check as well.

  #neighbor x.x.x.x disable-connected-check

  This won’t even check the number of hops an external neighbor is and will allow them to connect without issue.

  Now the TTL security Security Mechanism is used when you want to connect to a neighbor that must be a certain number of hops away.

  So for example, we know we have a neighbor that is 3 hops away and we are sourcing our peerings off of a loopback address to the loopback of our BGP neighbor, then we would be 5 hops away. We could use TTL security to tell the BGP process that the neighbor must be 5 hops away, no more and no less.

  • I also found a great DocCD link for this task . You can find it HERE.
  • Point to NOTE : If the eBGP peering doesn’t adhere to the TTL-security hop count configured, then the eBGP goes into “ECN Disabled” state. If the hop-count between the peers is lesser than the count configured, then it gets into the “ESTABLISHED” state.
• I found THIS to be a great resource for many “routing-protocol” related configurations.
• SELECTIVE PACKET DISCHARGE ( or we call it SPD with love )
  • I’ve blogged about this feature when i did the same lab earlier, but there are some additional details which i noticed here!
  • WARNING : When i labbed this, these commands were’nt under the context-sensitive help. i.e We had to remember the commands verbatim and type them out. KEEP THIS IN MIND!
  • HERE’s the DocCD link for this.
  • Crazy fact to remember : IGP takes precendence over BGP(external) here. Apparently, internal routes are more important than external-routes
• SNMP trap v/s SNMP Inform
  • I didn’t know the difference till yesterday. Thanks to THIS document
• Remember, to apply limiting on PMTUD  packets, check for icmp packets with the DF bit to “1″ .

Well, thats about it for the lab. Tomorrow i’m going to be doing Advanced Mitigation labs! Join me on Google WAVE at 10:30 PM IST.

Another thing to look out for is that, most of the configuration tasks can’t actually be tested in the lab, so i would suggest paying importance to the “show” commands and learning to decipher what they mean. That could make the difference between an almost complete configuration and an award winning configuration. This is something which i am learning

Cheers and have a great day!

TacACK