Archive for March, 2010
3 Topics done
Posted by TacAck in Uncategorized on March 29th, 2010
Hello All,
I’m starting with all tasks that i’ve rated 7. So i did Filtering, Failover and Tranparent IOS and ASA firewalls. I’ve updated the schedule with the links to the notes that i made
This will ensure that they are easily availble when we wanna check them out later. I’m yet to update the blueprint according to the latest expanded blueprint announced by cisco. I will do that in time
( Too bored )
Cheers and happy studying. Please let me know as to how your studies are going and what you’d like to see here?
TacACK
Awesome announcement from Cisco!
Posted by TacAck in Uncategorized on March 28th, 2010
Hey guys and girls!
I was just about to post a new article on some of the notes that i had made recently. As you all know i recently posted up the CCIE-blueprint as a checklist and i’ve started ticking things off , as i finish them ! Well, here’s the good news..
Cisco, did EXACTLY the same thing and their new( and expanded ) CCIE-v3 blueprint rocks my face! HERE’s the link to it ( Registered customers only ). If you want it in a PDF format, you can find it HERE.
This is really awesome, as i no longer have to keep guessing about the topics that might be included under a particular section. It’s always a good feeling when you hear it from *THE MAN* himself, rather than providers
I will be updating the CCIE-sec blueprint later today to match this new and improved list.
Cheers!
TacACK
Brand new schedule + New plans!
Posted by TacAck in CCIE-Security on March 25th, 2010
Hey guys/girls!
It’s been quite some time since i posted and there are several reasons for that. Well , primarily , my day-job (coding) is keeping me really busy and i’m unable to spend quality time on studies. Secondly, i was just plain confused.
But now,i’ve a solid plan. All thanks to Ryan Scheutt ( twitter : @routsec , Blog : www.routsec.com ). Although we’re in completely different continents, we interact on a regular basis on GOOGLE WAVE and we’ve had many useful debugging sessions/discussions. So what we’ve decided is for both of us to follow a similar schedule and to try and complete as much as possible before we attempt in August of this year.
So yesterday, Ryan implemented a table on www.routsec.com listing the various DocCD topics and how he rated them on difficulty. I had this idea in mind for sometime now, but after seeing Ryan’s blogpost, i decided to do one too , just to know where i stand.
You can find my schedule on the Page named -> “CCIE-sec Blueprint”, which you can locate on the list of pages , right next to the “About” page. I’m yet to mark the exact number of hours that’ll be required for each topic. I will mark these soon.
Again, please don’t forget to check out Ryan’s schedule .
I’m really excited about all the stuff that i’m going to be learning. I promise to blog “everyday” and upload some tutorials whenever i find something super cool.
Cheers,
TacACK
Confusion and then Clarity
Posted by TacAck in CCIE-Security on March 17th, 2010
Hello all,
Sorry i was offline for the last couple of days. I’d a couple of days off from work and unfortunately my internet connection at home decided to quit on me. So i spent 4 days ( It’s HARD! ) without the internet and i’ve grown to appreciate the internet even more now
Since i woke up this morning , i’ve been super confused about where my CCIE-sec studies is heading. I went through the INE vol 1 labs a couple of times, but i must say, i’m not fully confident about my abilities in tackling all the technologies on the blueprint. This makes me wanna focus on the technologies and nail them. On the other hand, i want to start Vol 2 labs , because they’re definitely the next step in the learning/labbing process which i want to try. After a lot of thinking and after talking to Ryan Schuett ( www. routsec.com ) , i’ve finally reached a couple of conclusions.
I’m going to be scheduling my first lab attempt on the 1st week of AUGUST,2010.
I know it’s a long way from when i’d planned to take the lab, but i guess preparedness for the lab is crucial and i must not compromise on knowledge and trying to understand every little detail of the technologies.
So what i’m going to be doing from tomorrow is , i’m going to take each and every section of the blueprint and i’m going to try and tear it apart ( as much as possible ). Instead of focusing on 1 section at a time, i’m going to be trying to do all 7 sections everyday ( 1 task each ). That way, i’ll be in touch with all the topics and it’ll be harder for me to forget them.
I’m getting late and i’m heading home. I’ll post a detailed schedule ASAP.
Cheers,
TacACK
T-18 | Bootcamp Final Day Review
Posted by TacAck in 90 Day countdown on March 10th, 2010
I’m going to miss Marvin
Here are the notes for the final day of the bootcamp .
L2 SECURITY
- Violation modes of port-security
- Shutdown
- send port to err-disable
- Protect
- Violators cannot send traffic in , no alert is raised
- Restrict
- Violators cannot send traffic in
- Generates SNMP/ Syslog
- HSRP uses 2 MAC addresses ( NOTE )
- During configuration, check if some traffic might inadvertantly trigger this port-security feature.
- Shutdown
- 2 ways to recover a port from err-disable
- err-disable recovery configured
- shut/no-shut
- We can also configure a static ” Null route” a MAC address
- When we block multicast, then some unicast/broadcast traffic also gets blocked in Storm-control ( read more on this )
- “switchport protected” -> Mini PVLAN like configuration
- When configuring VLAN Maps, ensure that ARP traffic is allowed ( most of the time, this is needed )
- PVLAN requires Transparent ( VTP ) mode configuration on the switch
ATTACK MITIGATION
- VLAN HOPPING ATTACK
- 2 variations
- Hosts runs DTP to form a trunk with the adjacent switch
- Host sends frames double tagged with 802.1q
- Mitigation
- Ensure that all host-facing ports are statically assigned as access ports (switchport mode access )
- Don’t ever use VLAN 1 as the default VLAN
- 2 variations
- CAM TABLE ATTACKS
- port-security -> Mitigation
- Shutting down the port is the best option
- DHCP STARVATION ATTACKS
- Tons of DHCP requests exhaust the DHCP pool.
- Victim hosts are starved of a DHCP lease.
- Could be a DOS/ MITM attack
- Mitigation
- DHCP Snooping
- Ensure that all switches running a the particular VLAN have DHCP snooping turned on ( talk to the proctor )
- ROGUE DHCP SERVER ATTACK
- Mitigation : DHCP Snooping ( trust )
- Can also use Port ACLs/VACLs
- We can also use the “ip dhcp snooping Limit” command to limit the flood.
- Mitigation : DHCP Snooping ( trust )
- ARP SPOOFING
- Gratuitous ARP -> Send ARP replies regularly without valid requests ( to refresh the ARP caches of the devices )
- This can be a good playground to lauch MITM attacks
- Mitigation
- DHCP snooping with DAI
- or ARP acls with DAI ( for static IP addressing )
- If switches don’t support snooping or ARP inspection
- IP ARP uses ethertype 0×806
- IP uses Ethertype 0×800
- This can be used to block the ARP traffic
- Bad configuration of this can cause problems later ( reload, reboot ,etc ) . So remember, it won’t immediately show up due to ARP caching on the devices
- MAC SPOOFING
- Mitigation
- IP Source guard
- Consults the DHCP Snooping table
- We can also use port-security
- IP Source guard
- Mitigation
- IP SPOOFING
- Mitigation
- RFC 1918/2827/3330 BOGON ingress filtering
- uRPF
- RFC 2827 is bidirectional
- Traffic leaving should have the internal address
- Traffic entering from the outside, should not have the internal address
- uRPF takes into consideration all equal cost paths(urpf accepts both the paths as the reverse path ) into consideration when determining the interface upon which a packet should be received on . It even understands EIGRP unequal cost load-balancing.
- Mitigation
- SMURF/FRAGGLE ATTACK
- Mitigation -> no ip directed broadcast
- uRPF also does the job
- via CAR/MQC
- via Blackholing ( either source/destination based )
- Mitigation -> no ip directed broadcast
STANDARD BLACKHOLE FILTERING
- Problem is legit traffic to the destination also gets blocked
- Matches only by destination
- Ensure that the “no ip unreachables” is configured on the Edge -routers
SOURCE-BASED BLACKHOLE FILTERING
- There is a uRPF statement on the EDGE router
- The trigger will be a route for the “source IP”s next hop ( instead of the destination IP , like the previous configuration )
- If we do not add a “deny” route-map after the first route-map, any other static routes will get redistributed into the BGP.
SYN FLOODING
- Mitigation
- TCP Intercept
- IOS CBAC/ ZBF
- PIX/ASA MPF connection limits
- SYN policing with CAR/MQC
Network scanning can be blocked by using ASA Threat detections, IPS/IDS , etc
- To drop ip options you can use the global config command : “ip options drop”, or we can drop using ACL’s ” access-list 101 deny ip any any option.”
I’m now officially done with the bootcamp. I would recommend this to everyone , when they are almost done with their Vol 1 labs. There was a big section in Day 5 about Strategies and tips to be followed during the lab and that was very insightful and i thoroughly enjoyed it
To be honest, i don’t know what exactly i wanna do for the next couple of days/ weeks. I’m stuck between Vol 2 labs (or) Go through the CCIE-sec blueprint and configure each and every item in detail and also make a list of the Doc-CD references for each.
I’ll definitely have an answer soon
.
I’m really lucky to have found an awesome support community online who continue to inspire/motivate/support me. Paul Stewart , Brian Almond and Ryan Schuett are some people i look up to someday i want to know as much as these dudes
Cheers,
TacACK
