Archive for December, 2009

Day #20 – #23 – Slacking off!

Ah, the last week has been…”Sorta” productive. Meaning I did get the bootcamp done, but i didn’t make a structured effort towards documenting it. I didn’t take down notes and i didn’t lab as much as i wanted to. Hence, i won’t be able to post my notes / observations here.

I’m sorry for this ( I don’t know if i get any readers ! But it’s more an apology to myself  :)  ) and i assure you that the next time i go through the bootcamp , i’ll definitely document my effort a lot more precisely.

But , a new week dawns and i’m looking forward to all the new things i can learn this week. Again, many thanks all the “CCIE-gurus” who inspire me to share as much as i learn :)

Cheers,

TacACK

No Comments

Day #19 – Possibilites

Good morning!

It’s been a good couple of days and i’m really excited about the stuff i’m learning! . I’m looking to start the INE CCIE-sec bootcamp tomorrow and i’ll be posting about that. I won’t be posting all the notes i make ( ‘coz that wouldn’t make sense to anyone else ) , but i’ll be posting all the caveats and the workarounds that i learn.

Today, i had a bad start. Didn’t get good sleep + a bad dream + my room was really cold ( left the window open ). So my day started out all slow and i spent almost half the day gazing into the monitor and wondering what life was all about. After lunch, i came to my senses and i started reading around and made some notes about the stuff that i learnt . There are a few topics that i studied for the first time , as well as some topics that i revised.

Here’s the list

  • PRIVATE VLANs
    • This is a topic which i went through earlier, but i’d forgotten some of the details so i revised it again. HERE’s the link
    • A couple of things to remember here are :
      • Remember that all the members in different Private VLAN’s will all share the SAME IP subnet
      • For 2 communities to talk to each other, the things that must be done are
        • Hell, Put them all in the same community! Duh! :P ( Sorry i couldn’t help myself there! )
        • Configure an SVI on the switch to which the communities are connected to.
        • Why this is required is because , since the broadcast domains for the communities are separate, ARP requests which are broadcast messages, will not reach their intended destination in the other private VLAN.
          • As a workaround for this, we need to enable , “ip local-proxy arp” -> this command instructs the swx to answer to the ARP requests for clients in the same subnet as the requester. Ex : If 10.1.1.1 sends out an ARP query for a host 10.1.1.15 (present in another PVLAN ), without the “ip local-proxy-arp” command enabled, the swx will assume that since both the source and destination IP addresses of the ARP request are in the same subnet, 10.1.1.15 will reply to the ARP and that the swx doesn’t have to worry about it. Hence, with the local-proxy-arp enabled, the swx assumes that it HAS to reply to the ARP request.
          • For “ip local-proxy-arp” to work, “ip proxy-arp” has to be enabled under the interface. This should be enabled by default, if not, go ahead and enable it manually.
        • So an SVI is required on the switch because it has to answer the ARP queries .
    • There’s a small difference between the concept of private VLAN’s and “switchport protected ” a.k.a ” Private VLAN Edge ” . Here’s the difference.
      • A port configured as a community port  on a  swx has the following restrictions
        • It will not communicate with other ports on the same switch which belong to different PVLAN’s
        • However, if trunking is configured between switches, then if there’s a port on the second swx belonging to the same PVLAN, then they can communicate
        • If there are no other ports on the second switch belonging to the same PVLAN, then no communication takes place
      • Whereas, with the “PVLAN edge” feature, the following restricts are forced upon the switch ports
        • In a switch , 2 ports configured as “switchport protected” , will not communicate with each other
        • In a switch , ports configured as “switchport protected” can still communicate with other ports which are not configured as PVLAN Edges.
        • In a scenario where multiple switches are present, and there are protected ports on different switches, then a protected port on one switch, will be able to talk to all the ports of the other switch ( irrespective of whether that port is a normal or PVLAN edge port ).
  • SLA on the ASA
    • This was a new topic for me as i’d just read about it earlier , but i’d never configured it.
    • This concept is super-powerful and i just tested it out today.
    • The purpose of SLA is that , it monitors an IP address. It keeps checking it’s reachablity (once every configurable interval ) .
    • Along with SLA , we touch another command called “track” which is used to keep track of various SLA’s or various Interfaces that we are tracking.
      • ex : Suppose we are attaching “track #1″ to “sla #1″ , if the IP that sla #1 is monitoring goes down, then the track status goes to DOWN.
    • The advantage of having a track is that we can link the track status to a route. Doing this ensures that , when the track status goes DOWN, i.e when the IP reachibility is down, the IP route in the routing table, corresponding to that track ID , is removed!
    • The real world use of this might be a case where, the company’s EDGE firewall ( or router ) is connected to 2 ISP’s. One which is the primary and the other acting as the backup.
      • Suppose we have an SLA ( sla 1 ) monitoring the gateway of our primary ISP. We will also associate a track ID to it ( say track ID 123 )
      • In our routing table, we will have  a default route pointing to the Primary IPS’s gateway. Along with this attach the “track 123″ command to it at the end of the static route , so that the fate of this route, now depends if the gateway is reachable in the first place or not.
      • Next, create a backup default route with a higher metric pointing to the gateway of the backup ISP. ( this is our backup route, which is only used if the primary default route is removed from the routing table ).
      • If there is a problem in reaching the gateway of ISP 1, the following things happen
        • The SLA engine will try and verify it’s reachability for a duration of time (this can be configured)
        • If it’s still not reachable, it will drive Track 123 pointing to that SLA to “DOWN”
        • The default route in the routing table ( the one which the “track 123″ ) will now be removed.
        • The backup default route that we’d configured ( the one pointing the secondary ISP ) , will now become the default route.
    • This ensures that connectivity to the internet still remains, and that all this happens automatically.
    • You can find some data on this here : SLA-MONITOR and TRACK
  • I also did some configuration on redundant interface configuration on the ASA. This is pretty straightforward.

Tomorrow, i’m starting the INE Cod Bootcamp as i’ve already told you and i’ll be posting about it soon!

Cheers,

TacACK

No Comments

#Day 17,18 – ACS Study

Right!

I spent Saturday and today working on my least favourite topic : ACS! Now that i’m done with it..here are some of the things i’ve realized :

  • Cisco needs to definitely improve it’s documentation on the ACS. There’s very little stuff out there for ACS configuration scenarios
  • There are not many books to teach you how to configure the ACS for many tasks
  • All said and done, most of the configuration scenarios on the ACS are pretty *easy.

* – Easy if you know how the ACS works, impossibly hard if you don’t.

This was how i studied this topic ,

  • On Saturday ( Day # 17 ) , i spent time going through this book called ” Cisco Access Control Security: AAA Administration Services ” by Brandon Carroll.
    • It’s a great book for starters and i would DEFINITELY recommend it to anyone who’s trying to learn all about the ACS and it’s under-pinnings from scratch.
    • It’s got a great section on the technologies like TACACS+ , RADIUS , etc and it slowly evolves into more complex scenarios like RBAC , etc.
    • Since this was the first time i was learning the ACS, the last thing i wanted to do is to go too-deep , too-fast. So i skimmed through most of the topics, focussing on the fundamentals.
    • I spent about 6 hours on this and i can say that at the end of the 6 hours . i had a fair idea about how everything fits together.
    • I thought of making notes on the ACS, but i decided against it later as they would be really hard to do ( and time-consuming ).
  • On Monday ( Day # 18 ), i went through the ACS User guides.
    • This is found in the DocCD and was suggested by @davidhwest.
    • You could directly start reading this instead of the book, but i would suggest atleast reading the first few chapters of the book before you started this. ( Basically to understand TACACS+ , RADIUS better)
    • They provide configuration examples for many scenarios ( some of which are not covered in the AAA book ).
    • I would suggest going through this baby atleast once, ‘coz this is what we would have access to in the CCIE-sec lab.

On Sunday morning, i had a rack session scheduled and i practiced the “Identity Management” Vol 1 Workbook from INE. This would be my second go at this workbook , but now with my newly-found knowledge of the ACS, everything made a lot more sense :)

The activity for Tuesday would be to Read and understand NAC! For this i’ll be using 2 resources. Firstly, i’m thinking of reading through the NAC chapter in Yusuf Bhaiji’s book. Secondly, i’m going to go through the NAC sections present in the “ACS User guides”.

I’m feeling a bit lazy this morning, so i might just skip to the User guides for NAC! :P

Cheers,

TacACK.

No Comments

RFC #3330

Yesterday, on twitter , @packetu @infosecsamurai @rickmur and I had a discussion on RFC 3330 and how to memorize it. For those of you who are’nt familiar with RFC 3330 , it contains a list of addresses which are not be allowed into a network. (Ex : BOGON addresses , RFC 1918 addresses , etc ). The full RFC can be found here

Later, @packetu ( a dude i look upto! :) ) did a blogpost on how to memorize this . I personally found this very helpful and hopefully you’ll like it to.

You can find that article HERE.

His blog is one that i would recommend to anyone who’s studying for their CCIE-sec. He’s very knowledgeable and more importantly he takes the time out to address any queries or problems that you might have. ( Lotsa CCIE’s, CCIE candidates  don’t do this ).He’s got absolutely no attitude and i respect him a lot . He’s helped me a lot in understanding certain concepts better and i’m sure that you’ll find his blog helpful.

Thanks Paul!

Cheers,

TacACK

No Comments

Day #16 – Rest and Yoga :)

Today’s all about chilling out and zoning out! :)

Agenda for today :

  • Leave work early and meet up with Neetha
  • Fumble through Google Maps and find my way to this awesome Arabic restaurant
  • Fill myself with Humus and Shawarma rolls
  • Go home, do some meditation and calm the mind.

This is all in preparation for the big day tomorrow! Yes, you guessed it!  24 SOLID hours dedicated to the monster : ACS! I’ll post about it soon!

Right, now that i’ve got that out of the way, it’s time to take a step back and do a high level review of the 15 days i’ve spent and my goals for the next 75.

Since i’ve spent 1/6 th of the number of days remaining before my attempt , here’s looking back at some of the stuff i did

  • I did some technology labs ( VPN , ASA , Attack mitigation , etc ) . I learn a lot from these and i’m definitely going to allocate time to re-do all these labs again.
  • It sounds kinda wierd , but all my life i’ve not been setting high goals for myself. I guess , it’s always been the fear of not being able to live upto them / a feeling that i’m not capable of achieving what others can. So this time i’ve set clear goals which i want to accomplish :
    • Find atleast 2 ways to solve every task . For some tasks, this might not be possible , but for others there might be more than 2 ways.
    • Reduce the “silly” errors that i do . ex : I don’t read the tasks properly,etc.
    • Try and reduce the time taken to solve a problem
    • I must force myself not to do 2 things
      • Google the problem :D I am going to force myself to use only the DocCD :)
      • Look at the solutions. If a task takes more than the allocated time, i must force myself to skip the task and head to others, but to never look at the solutions
  • I did Beta testing for INE vol 1 labs. That was also a great experience and it was very humbling to interact with Keith Barker. Overall , i learned  a lot!

My plan for the next 1/4 ( Day 16 – Day 30 ) is as follows

  • Re-work all the technology labs.
  • Master the ACS . Yes, i’m sick of being bogged down by this piece of software. I am going to rip this apart and burn the parts ( Idea stolen from Twilight :D )
  • Try and read as much of the DocCD as possible ( free time activity ) . I got this idea from watching @packetu ( Paul Stewart ) go throught the DocCD. Thanks Paul! :)

My plan for the Day 31 – Day 45 :

  • Start the Vol 2 labs ( The full scale 8 hours labs ) . I can’t tell you how excited i am to start this!
  • Go through the Bootcamp. I’ve purchased the INE CoD V3.0 CCIE SEC bootcamp.
  • Finish all the Vol 2 labs.

Day 46 - 60 :

  • Re-work the Vol 2 labs
  • Re-work the Vol 1 labs
  • Focus on efficiency : Fast , accurate

At the end of 70 days, i want to take up the  written exam and if i clear that, take up the lab soon after.

A part of me keeps telling me not to plan too much and to take everyday as it comes ( that’s the old,procrastinating part of me ), and the other part’s patting me on my back for committing to a schedule. Let’s see how this goes :) I’d love to hear what you thought about my schedule . Plus your additions to this, anything that i need to additional to this! Please feel free to shoot me an e-mail or comment here :)

Cheers,

Vybhav

No Comments