Archive for December, 2009

Day #31 – RADIUS+TACACS+POSTER+

I was going through some notes today and i found this that i’d made. It’s just a small document containing some key aspects of RADIUS , TACACS+ . I refer to this whenever i’m in doubt of some basic details regarding the protocols. So , why not share it here! :)

You can find it HERE.

I hope you find this helpful!

Cheers and Merry christmas! :)

TacACK

1 Comment

M.I.A

Hello folks!

It’s been quite some time since i published here. There are multiple reasons for that : )

  1. For the last couple of days, i’ve been revising the Vol 1 INE labs ( hopefully for the last time) . So nothing very interesting to post about
  2. Plus there were a couple of holidays in between when i did nothing ( Guilt creeping in! )

I won’t be blogging for the next week too , ’coz i’m going on a VACATION =D ! I don’t know if it’s well deserved, but hey, it’s still going to be awesome! But, to reduce the guilt involved in blowing away one solid week , i’m going to be reading as much stuff as possible from the DocCD.

One good place to start would be this ->  http://www.internetworkexpert.com/resources/iewb-sc-vol1-further-reading.htm . This is a compilation of  links to the DocCD . I like this a lot since it’s arranged section-wise and it covers most of the stuff that i’d want to read about. Plus, i save time in actually searching for it.

Which brings me to my second point, whenever you find a document on the DocCD, make sure you memorize/take-a-picture/get-a-tattoo done of where it’s located . This is super-important for the sake of the lab!

Most importantly, MERRY CHRISTMAS and super happy 2010 to one and all! :) I hope this year ushers in happiness , health and a ccie # to you and your family :)

Cheers ,

TacACK

No Comments

Day #26, #27

How are you all doing! :)

I’m actually rushing out now and before i left i wanted to give you all an update on what i did for the last two days ( i.e Friday and Saturday )

I finally FINALLY am done with NAC! It’s a topic if i’ve been trying to understand for quite some time now. But now that i’m done with it, it’s much easier than it looks! So if you’re trying to figure out how to tackle this monster, my advice to you would be to just start from the basics ( Yusuf Bhaiji’s Network security techologies and Solutions ) and work your way up to the ACS user guides.

Today i’ll be doing some NAC labs from the INE vol1 workbooks. I’ll post about how that goes.

Cheers,

TacACK

<Personal blog ahead>

I’m slacking off a lot. I waste a lot of time .. which i think is because i’ve not committed to an exam date as of now. So my agenda for the next 2-3 days is to fix a date and BOOK the exam, so that i’ll stay focussed.  :)

3 Comments

Day #25 – Boy! Was i wrong! :)

It’s been a day of revelations :) . One major lesson i learnt was that there’s a HUUUGE difference between knowing the technology and labbing it! Boy, oh boy!

Before i list my activites for the day, i want to point you to an interesting and VERY helpful document -> Cisco Guide to Harden Cisco IOS Devices . It’s very useful and it covers many of the topics under the CCIE-sec v3 blueprint for this particular section. So i would suggest reading through it once ( or maybe even twice :) )

Right! Today i did the Control plane and management plane security Vol 1 INE lab and i feel really good about the challenges that i faced and the stuff that i learnt in the process. Here’s the stuff i learnt.

  • If the task asks you to limit all the “non-ip” traffic to some bandwidth, then create a policy-map with “class-default” traffic and specify the limit and apply it under the “CEF exception” subinterface, because that’s where all the non-IP traffic goes to.
  • On a subinterface , we can configure a service policy , one of each type. i.e one general , one of type port-filter, one of type queue-threshold ,etc
  • DON’t FORGET TO CONFIGURE THE BURST SIZE In the police rate command. What happened is that there was a task where i had to police the number of Non-IP traffic traversing the router to a rate of 100 pps. So what i did was i entered this command under the policy-map configuration – “#police rate 100 pps conform-action transmit exceed-action drop” and i assumed that the other parameters like burst rate, interval, etc would be assigned some non-zero default values.
    • After configuring this , i noticed that the reachability between the routers who were on either sides of the policing router was down. They could’nt ping each other. After some investingation, i noticed that the ARP requests for the next hop’s MAC were getting eaten by the “police-rate” command.
    • It also said that the packet rate allowed was : 100, and the burst size was : 0 . This was a big surprise to me. The burst rate did not get a default value based on the police rate value ( like the “police” command ) .
    • So i went into the config once again, and i set the burst rate to 10 . As soon as i did this, the network was up and running again.
    • What i wanted to enforce here is that, though it’s common to assume that some fields get default values, it’s VERY VERY important knowing exactly what values will be assigned to them in order to avoid such configuration errors.
  • Selective packet discard ( SPD )
    • This is an awesome feature that i found in the workbook.
    • This is a queue-management technique for input interface queuing
    • Every interface has an input FIFO queue ( Hold queue )
    • There are 3 total queues on the input interface 
      • SPD extended headroom -> Priority queuing, Highest priority among all the queues, L2 keepalives and IGP packets go in here
      • SPD headroom -> Priority queuing, lower priority, if the packets don’t have space in the extended headroom it goes in here. BGP packets go here.
      • Hold queue ( the output FIFO queue ) -> Lowest priority, FIFO method to process the packets which arrive here. All IP packets go here by default
    • By implemnting the 2 additional queues, what SPD achieves is, it can prioritize traffic which is coming into the interface and avoids a scenario where, some important traffic arriving on an interface gets dropped, because the Hold queue is full of low-priority traffic.
    • SPD basically treats malformed packets(packets that need the router to generate ICMP responses ). All these packets head to the Hold queue.
    • SPD has 2 modes of operation
      • normal
        • it places the malformed packests in the hold queue. If the queue size increases above the maximum threshold, the packets are dropped in a random fashion.
      • aggressive
        • the malformed packets are dropped as soon as the hold queue grows above the minium threshold. Instead of random drop, it does an unconditional drop here.
  • Use “hold-queue” command in the interface config to set the size of the hold-queue
  • when the task asks you to only allow telnet traffic without using ACL’s , all we need to do is “transport input telnet” on the vty lines, that should do the trick
  • if you want the IOS to not start a telnet session for every random (unknown ) command entered in the exec mode , use ” transport preferrred none ” on the line where you want to enable it.. Otherwise be default, if we enter some random stuff in the exec mode, the IOS will try and telnet to that name.
    • #line vty 0 4
    • #transport input preferred none
  • Rotary groups
    • Rotary groups are an interesting concept. They are used to allow a protocol to run on another port , other than it’s standard port. Ex : We can configure telnet to run on port 2001.
    • Simple config to make telnet run on aux port 2001 is as follows
      • (config)#ip telnet port 2000 rotary 1
      • What this does is, it tells the IOS that, telnet is now assigned to rotary group “1″, and the the starting port address is async port 2000.
      • That means that telnet will now run also on port “2000 + rotary group number” = 2000 +1 = 2001.
  • When we need to enable traps for every interface’s up/down status
    • #snmp-server enable traps snmp linkdown linkup
  • If we want to exclude an interface from this
    • #interface fa0/0
    • #no snmp trap link-status
  • SNMP v3
    • replaces the old community-based authentication system.
    • communication privacy using encryption.
    • the new concepts
      • user
      • group
        • defines what access rights a set of users have
        • the policy is defined by associating a r,w or notify view with the group.
        • if a group is defined without a read view, all objects are availbale to read ( implicit permit )
        • but, if a write or notify view is not defined, no write access is granted, no objects can send notifications to  members of the group.
      • security level
        • authentication and/or encryption
        • 3 levels
          • noAuthnoPriv – keyword “noauth
          • AuthnoPriv – “auth
          • AuthPriv – “priv”
    • SNMP v1 and v2 can only support noAuthnoPriv, in case the SNMPv3 uses noAuthnoPriv, then the username serves as the community string.
    • password,encryption-key are set on a “per-user” basis.
    • SNMPv3 does not send passwords in clear-text , but instead uses MD5 or SHA1 hash based authentication.
    • for encryption : Des, 3DES/AES keys are supported.
    • NOTE : SNMP v3 users do not appear in the running config for security reasons.
  • NOTE : “snmp-server ifindex persist ” makes sure the interface index stays after reconnect..read properly.

It’s been an intense and very interesting day. I wish i could learn so much everyday :)

Cheers,

TacACK

1 Comment

Day #24 – The final frontier.

Let me clarify! :) I call this the final frontier , not because of i’m almost done with the CCIE-sec studies, but because i only have 1 section left in the ccie-sec v3.0 blueprint. That section being “Control and Management Plane security”.

Here are the topics that must be covered :

Implement Control Plane and Management Plane Security

A. Implement routing plane security features (protocol authentication, route filtering)
B. Configure Control Plane Policing
C. Configure CP protection and management protection
D. Configure broadcast control and switchport security
E. Configure additional CPU protection mechanisms (options drop, logging interval)
F. Disable unnecessary services
G. Control device access (Telnet, HTTP, SSH, Privilege levels)
H. Configure SNMP, Syslog, AAA, NTP
I. Configure service authentication (FTP, Telnet, HTTP, other)
J. Configure RADIUS and TACACS+ security protocols
K. Configure device management and security

1. IOS Login Enhancements
2. IP Source Tracker
3. Role Based CLI
4. IOS Resilient Configuration
5. Buffer Overflow Detection and correction
6. Additional CPU protection mechanisms (options drop, logging interval)

So as usual i planned to make a structured approach towards this : Starting from the basics and heading towards advanced configs. So this lead me into the DocCD where i spent time searching for the right documentation to go through . I found 2 configuration guides, one for Control plane security and the other for Management plane. The control plane guide is very well written and it’s easily understandable. However the management plane configuration guide is “SUPER” big and it’s not feasible to read and remember everything.

So what i did today was i went through the configuration guide for control plane security and made notes. This was very helpful and i now feel confident that i can tackle the tasks i might encounter in the Vol 1 labs for this section. You can find the notes HERE!

Tomorrow i’m going to figure out a way to read through the management plane configuration guide efficiently  and i’ll definitely share the experience/notes with you all! :)

Hope you find the notes useful. Please feel free to point out any mistakes/comments that you might find/have in the comments section. I’m really lucky to have a medium through which i can interact with people and learn so much!

Thanks you readers! :)

Cheers,

TacACK

No Comments