The Day before yesterday, i finished the IOS F/w Vol 1 lab. Those who were following me on Google wave would’ve seen me labbing live! Now onto some of the points that i noticed. As per an excellent suggestion that i received recently, i’ll be labelling the tasks in as per the INE workbook section number. This might help you when you have to lab-up these tasks. Thanks to the person who suggested this!

2.1 BASIC ACCESS LISTS

• When dealing with Cisco equipment,  think beyond the usual traceroute that happens in windows ( ICMP echo request with TTL values beingincrememnted, and ttl-exceeded replies)
• In cisco, the traceroute requests are sent as UDP messages to port numbers 33434 , 33464, and the replies include port-unreachable , time-exceeded. There are the ports that i need to permit
• OUTBOUnd -> UDP 33434 to 33464
• INBOUND -> time-exceeded, port-unreachable.
• Only then , trace-route will work.
• And when they say, permit all “terminal” access to a certain device on the other side of the IOS f/w, here are the traffic that you need to permit
  • telnet ( tcp 23 )
  • ssh ( tcp 22 )
  • http ( tcp 80 )
  • https ( tcp 443 ).
• I had only configured telnet and ssh ( FAIL! )
• When the task asks you to configure free email access to the inside users , where the email server is located on the outside, here are the list of protocols that needs to be allowed
  • SMTP ( tcp 25 )
  • POP3 ( tcp 110 )
  • IMAP ( tcp 143 )
• I had just configured SMTP. i totally forgot about the other 2 protocols.
• One note to all : After configuring these ACL’s. MAKE SURE YOU TEST THEM! They can be really simple to look at, but believe you me, the extra 10 mins spent in testing can save you precious, sweet points.

2.2 REFLEXIVE ACCESS-LISTS

• I suck at this.
• The first task is ok, no problems, i create an ACL oubound on the outside interface and i reflect the TCP, UDP and ICMP traffic
• I then apply an acl on the inbound direction on the outside interface and “evaluate” the traffic
• The next configuration item is to permit RIP .The task also tells me not to use “permit udp any any eq rip” on the inbound ACL on the outside interface.
• So , after thinking, i didn’t figure out the solution and i checked the solution in the INE workbook and here’s what i found
  • By default, router generated traffic ( like RIP updates ) aren’t subject to reflection as they get out of an interface.
  • To trick the router, we can divert the traffic to the loopback 0 interface , thus making them ingress. THat’s what we do in the previous task
  • We make use of route-maps for this purpose.
  • After creating the route-maps, they are applied to the local routing policy.

2.3 DYNAMIC ACCESS-LISTS

• This was pretty straight-forward
• The only thing to watch out for, is the “make sure the contrl-plane traffic doesn’t get affected”.
• This referes to the routing messages between R2 and R1, R3.
• To make sure they are permitted, we need to manually add a permit “udp any any eq rip” entry in the inbound access-list on the outside interface.

2.4 BASIC CBAC

• This task also asks me to maintain IP routing through the network, so i’m going to permit RIP on the firewall by default.
• Allow the firewall to ping any destination. I’m thinking we inspect the “router-traffic” on the CBAC lists to achieve this.
• It asks me to inspect FTP application traffic. Is it referring to active or passive? Do i assume ACTIVE? This is certainly an item which you might wanna ask the proctor for confirmation.
• Remember, the OLD CBAC used to allow the traffic from the outside to the inside, by creating temporary ACL’s on the outside interface.
• But now, the latest CBAC ( or new name SPI ) does an “ACL-BYPASS” and creates an entry in the session table.
• So, to check if inspection is working correctly, use the command ” sh ip inspect sessions”

2.5 CBAC PAM

• This was pretty basic except for one little issue that i wanted to share with you
• By default, there are some ports which belong to a particular protocol. Ex: FTP -> TCP 21 , HTTP -> TCP 80,etc.
• Now when the task asks you to configure FTP inspection on TCP port 80, we cannot directly add #ip port-map ftp port 80″
• This would give us an error as the port is already in use by HTTP. To workaround this , there are 2 solutions
  • Delete port 80 from HTTP, and then add it under FTP.
    • #no ip port-map http port 80
    • #ip port-map ftp port 80
    • The disadvantage of this method is that, from this point on, even the HTTP traffic which flows on port 80 will not be inspected by HTTP.
    • The next method’s the better solution
  • Create an “Exception” ACL
    • We can specify an exception “host” for whom the port-map works a little differently.
    • ex : Let’s say that we have make sure FTP also works on TCP 80 from our local router to router R1 ( 192.168.1.2 )
    • But to the rest of the network, HTTP inspection should work on traffic on port-80. This can be achieved by defining an ACL  which points to the “special” router to which the port 80 needs to be mapped to FTP and apply it using this command.
      • #access-list 99 permit host 192.168.1.2
      • #ip port-map ftp port 80 list 99
    • So, only for host 192.168.1.2 , the FTP inspection also works on port 99, but for the rest of the network, it’s good ‘ol HTTP! Cool isn’t it?!

2.6 CBAC TCP/UDP INTERCEPT

• I didn’t face any issues here, this was pretty straightforward.

2.7 CBAC PERFORMANCE OPTIMIZATION

• The commands are straight-forward, but i suggest reading throught the explanation in the workbook solutions once after finishing the task.
• Remember, there are 2 ways CBAC inspection performance can be improved:
  • Modifying the Hash-table ( session table ) size to match the approximate number of TCP connections that will be intercepted.
  • Switching off alerts/audit-trails and only turning it on when needed.

2.8 IOS URL FILTERING

• One thing i didnt know here was how to capture traffic .. i assumed that no access-list was required for URL filtering. But it turns out that we need to specify an access-list specifying the traffic that needs to be “URL-FILTERED”.
  • #access-list 1 deny any
  • #ip inspect name HTTP_FILTER http java-list 1 urlfilter
• The rest of this configuration is pretty simple.

2.9 IOS AUTHENTICATION PROXY

• This involves some ACS configuration, So let’s head over into our beloved ACS! <3
• Ok, this works fine! I tried it with TACACS+ , but it seems to working well with RADIUS
• Now , there were some Issues i faced with TACACS+. I thought auth-proxy could be done using TACACS+ as well, but i tried hard to configure it and it didn’t work.
• So i switched to Radius and i used AV pairs “auth-proxy:priv-lvl=15, auth-proxy;proxy-acl#1=permit icmp any any” , etc to permit the ACL’s to be download on successful authentication.
• However when i tried achieving the same using LOCAL authentication/authorization, it failed! < INSERT DRAMATIC MUSIC! >
• Everything looked fine on the surface untill Ryan “The MAN” Schuett  ( www.routsec.com ) and i started debugging the issue.
• Here’s what we found, this is SUPER AWESOME!
  • When you create a username in the IOS using the “username xxx password yyy” command, i thought the username get’s a privilege level of 15.
  • WRONG!
  • The username initially get’s a privilege level of “1″ . That’s right,  a measly “1″ . So when we log in using a username of “xxx” we are in the user exec mode. I confirmed this by doing a “show priv” command.
  • Upon entering the “enable” command, we are immediately into priv-exec with a priv-level of 15.
  • So here’s the hidden detail, the username needs to have enough privilege, for the IOS to insert the ACL’s after successful authentication to the Auth-proxy device.
  • This was achieved in the earlier RADIUS based configuration by using the AV pair of “auth-proxy:priv-lvl=15″.
  • On the router, for local authentication/authorization,  we can get it to start working by adding the “privilege” keyword to the username and specifying a priv-level of 15
  • #username gotcha privilege 15 password i_told_you_so
• Thanks to Ryan for pointing this out to me. Ryan, thanks bro!

2.10 FLEXIBLE PACKET MATCHING

• FPM is pretty straightforward.
• I’ve written about matching the VLAN ID in the BPDU’s in an earlier post. Do refer that.
• Also, if you’re new to FPM, check THIS out. It’s an article by Petr Lapukhov, who is hands-down, the best tutorial writer to have ever walked the earth.

2.11 ZONE BASED FIREWALL

• Always remember to draw the zones on a piece of paper and form the mappings there.
• I’ll post a short article on how i do this. You need’nt follow it , but i’m guessing it might be of use to some Atleast , if you have a bad memory like i do!
• We match the traffic that we like using ACL’s under the type inspect class-map, apply it to a type inspect policy-map and now apply that under the zone-pair.
• Also note that, policing under the zone-pair is not allowed when one of the zone-pair member is a self-zone.
• Traffic to and from a particular zone and the self-zone(router generated trafffic) is permitted by default, even if you don’t create a zone-pair and apply a policy-map to it. But when we do that, the trafic which is permitted by the policy-map gets passed on, but the rest of the traffic is blocked.
• This prevents routing updates from getting exchanged, so what @infosecsamurai suggested was, to permit routing protocols between the self-zone and the otherzones who are part of zone-pairs ( ie. ( SELF , ZONE A) -> zone-pair A ), you must permit the routing protocol on both the directions. ZONE A to SELF , SELF to ZONE A. We cannot apply an “inspect” action on the routing protocol traffic,it has to only be pass. Therefore we have to explicitly create matching entries on zone-pairs which are in the opposite direction to one another.

2.14 CLASSIC IOS TRANSPARENT FIREWALL

• I was initially scared of configuring a router to operate in bridge mode . This was the first time i ever did that configuration and i think it’s pretty easy once you get the hang of it and once you start figuring out how it works!
• Always remember that IOS F/w operaetes after the input ACL, but before the output acl. So if we wanna block any traffic on an interface on which inspection is enabled, we can place an input ACL there.This ACL will block traffic prior to being inspected by the CBAC.
• The Ethertype of IPv6 is 0×86dd. To block IPv6 we use this ethertype value in the ACL :  #access-list 203 deny 0×86dd.
• But ensure that you permit the rest of the traffic, otherwise everything will get blocked. “access-list 203 permit 0×0 0xFFFF” ( address and mask )
• To apply this ACL on an interface , we have to enter the command “#bridge-group 1 input-type-list 203″. This is because , ACL 203 is not an ip acl, and the regular “ip access-group” command will not work.

2.15 ZFW-BASED IOS TRANSPARENT FIREWALL

• It’s exactly like 2.14 when it comes to configuring the interfaces as part of a bridge-group and enable bridge routing, and bridge irb mode.
• The zone-based configuration , is unchanged. Its the same regardless whether it’s operating on L3 interfaces or L2 interfaces. As long as they have ip routing enabled, it’s happy and it works just fine!
• Remember, TEST , TEST and TEST!

2.16 IOS IP VIRTUAL REASSEMBLY

• Not much to discuss here, just note the difference between max-reassemblies(The maximum number of simultenous BIG packets that we wanna reassemble) and max-fragments(The maximum number of fragments of EACH BIG packet that the IOS needs to track ).

2.17 IOS ACL SELECTIVE IP OPTION DROP

• Simple commands, simple job

That’s the end of a long blog post Today i’m going to be doing the VPN Vol 1 Lab. Join me on the wave. My wave id is “ybnmts at googlewave dot com”

Thanks everyone for your help and please have fun while you study I certainly am!

Cheers,

TacACK

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!