Hints and tips for the CCIE Security from the guy who actually writes the tests!

Hi again guys,

Well as you may have saw in my previous blog entry, I am at networkers Brisbane and in my techtutorial for CCIE Security my tutor was Yusuf Bhaiji who actually writes the CCIE Security coursework, here are some hints and tips I picked up:

• There is no more Windows CA Server! Unlike the previous exams where a Windows CA server was setup ready to use, in the new exam you must setup your own Crypto PKI server on the router itself, easy enough but something to keep in mind
• This is a common question so its nice to get an answer, for those of you who like using the ASDM and SDM you will be unhappy to know that these are NOT enabled and CANNOT be enabled for the exam, the files are actually deleted off the flash drives of the routers and the ASA's. So NO GUI's for the routers or ASA's
• In saying that however you ARE allowed to use the GUI for IPS
• IOS IPS version 5 is used
• Don't underestimate the implicit and explicit troubleshooting questions that you will get
• Don't underestimate the core knowledge questions, they are going to be difficult! Look for a book coming out in December from Yusuf featuring up to 300 sample core knowledge questions.
  
• You must know virtualization on the IPS devices and multiple contexts on the ASA's as these will feature HEAVILY in the exam
• You must understand all the different types of VPN including the new GETVPN, Dynamic VTI and VTI (I have done a blog post on VTI already and one is coming up for Dynamic VTI)
• You will be asked to implement at LEAST three different types of VPN's so know them backwards
• You need to know about IPSEC redundancy (another topic about that will be posted soon.)
• In the new version of IPS 6.1 all high risk attacks are denied by default, some questions will try and use this to trip you up deliberately! So watch out for this.
• Control-Plane and Management plane policing are heavily heavily focused on as these are new topics in this blueprint, you can always expect topics that are new to the blueprint to be tested heavily.
• You will have 0 initial config done on the ACS Server
• You can expect questions like "Someone has attempted to configure an IPSEC tunnel between router X and ASA Y, But it is not working" and you will need to troubleshoot and resolve (Explicit troubleshooting)
• You can expect questions like"the following traffic was captured during an attack earlier today" followed by a screenshot of a packet capture and you must identify the attack and use appropriate methods to mitigate the attack from occurring in the future within the constraints confined in the question (for example, something like "Due to your ISP's routing policy you must not use reverse-path forwarding to protect against this attack")

I hope this helps some of you out there!

Networkers Brisbane, A non-tech perspective.

Hi Guys,

• Smallest
• Small
• Normal
• Large
• Largest

Reporting to you from sunny Brisbane here, staying at the Rydges hotel (which I cannot recommend enough, its literally right next to the convention center and has pretty decently priced accommodation and Internet access.)

Can I just first say: Brisbane is very pretty, and the convention center is well organised and massive for Australia. I hope I get chance to check out the awesome museum too which has a dinosaur themed section (see below for the cool mock ups outside the front of the museum)

Cool hey?

So about networkers, from the minute you step in the whole effort and the money Cisco must spend to put the event together is obvious. The first thing they give you is a special badge with a scannable device on it, this scannable code is your ticket to all events, you simply scan the badge to register for events or to print your schedule. Everything went silky smooth:


Once you get your badge its time to collect your merchandise! Considering how stingy Cisco normally are with merchandise, the items you get are impressive:

• A very nice Cisco carry bag with padding and all
• A Shirt
• USB Key (2 gig) with all the Cisco content from the ALL the technical breakout sessions.
• Water bottle, cap etc

For those who know Cisco, all this merchandise is quite generous for them!

So on my first day, the Monday which is an optional day I had my techtutorial, I chose CCIE Security as I want another one to go with my CCIE Routing and Switching.

The tutor we had was none of than... Yusuf Bhaiji,
The author of the Cisco press book Network Security Technologies and Solutions and also the lead for the actual CCIE Security exams itself! Can you think of anyone more qualified to talk about the exam topics?

He gave us a great handout and did an amazing job of covering the material that will appear in as much detail as one day would allow (that is to say, not much detail but good bits of hints and tips.)

I will follow this blog post up with all the hints he gave but for now let me just say some of them will be quite useful to those preparing for the exam! He also mentioned his new book is out in a months time which is an updated version of his CCIE Security practice labs (so second edition of that same title.) If I had my copy of his book I would have got him to sign it. Sad I know, but my rock stars are different from your rock stars (for an interesting take on that check out this video:
http://www.youtube.com/watch?v=jqLPHrCQr2I )


Well that's it for the non-technical side of my blog kids, I will post the hints and tips from Yusuf next, but so far apart from missing my girlfriend back home in Perth I am enjoying it here in Brisbane.

IPSEC with VTI: The best damn way to do it.

Back when I was finally sick of working for ISP's and wanted to make the switch to enterprise, I had the normal "I am ISP background working in enterprise" worries (more of these and tips for those making the switch in a future article) but one particular technology had always stumped me.

IPSEC

Few other technologies require you to configure so many damn things to get them going! The steps you had to remember, ISAKMP policies, transform sets, crypto maps, interesting traffic ACL's, nat-traversal, the list could just go on and on and the debugging was just horrific!

Luckily I got my head around IPSEC to the point where of all the topics on the CCIE security IPSEC is the one I feel most confident with.

BUT my dear reader, I want you to be able to _AVOID_ the problems with IPSEC completely! Let me show you: VTI Tunnels


Virtual Tunnel Interface is a Cisco technology that basically allows you to have IPSEC tunnels, I am not talking about the pseudo IPSEC tunnels that are encapsulated inside GRE or GRE tunnels encapsulated inside IPSEC.

What we have with VTI is a pure Virtual tunnel, no GRE MTU issues to worry about and no real drawbacks that I have been able to see so far (if you know of any drawbacks id love to hear from you please comment in the section below.)

So, without any further rantings lets get onto some configuration:


First of all, you must configure your ISAKMP policies as normal (Hey, I didn't say it got rid of ALL the steps :p)

crypto isakmp policy 100
encr 1des
authentication pre-share
group 1
!

Obviously you need to make sure this matches on both your routers!

Go ahead and configure the transform sets:


crypto ipsec transform-set STRONGSET esp-3des esp-md5-hmac

Now here is a new step you probably have not seen before (except those of you who have configured GRE tunnels with IPSEC protection.. you know who you are!)


crypto ipsec profile VTI
set transform-set STRONGSET
!



Okay, so we have our transform set, our crypto isakmp policy and something that you may not have run across yet called a "profile."

Lets configure our tunnel, you perform this just like you would a normal GRE tunnel but with a few important differences:

interface Tunnel0
ip address 192.168.10.2 255.255.255.0
tunnel source 203.56.14.17
tunnel destination 61.88.88.88
tunnel mode ipsec ipv4
tunnel protection ipsec profile VTI


The two lines that should look different to you are "tunnel mode ipsec ipv4"
and "tunnel protection ipsec profile VTI"

These enable the VTI tunnel for IPSEC (obviously) and define the transform set to use,

We just have one more step now, earlier when I configured my ISAKMP policy I missed out a crucial stage that some of you may have picked up on (Hint: What authentication method am I using?)

Thats right, Pre-share, which means i need a pre-shared KEY! Now the reason i missed out on this was because a question i had when i first looked at this was what should i specify as the peer address? Well the answer is easy, you specify the peer address as the actual destination of the tunnel, so in our example our peer key looks like this:

crypto isakmp key CcI3R4ntsIs4Gr43tBl0g address 61.88.88.88




Assuming you have obviously mirrored the configuration on the other side guess what... that's it!! No Crypto-maps to worry about, interesting ACL's to define, no-nat statements to write, the next step is to bring up the tunnel by pinging the other end of the tunnel (so in our case 192.168.10.1) which should bring up the tunnel, you can verify using your regular crypto commands (show crypto isakmp sa and show crypto ipsec sa respectively.)

You can now route traffic over this interface just like a regular tunnel, you can even use a dynamic routing protocol!

Enjoy!

An Important lesson on QOS

Today I had a strange QOS problem to solve. This article mentions the problem and hopefully gives you guys a few pointers on QOS design.

So essentially the job involved me going to a company to teach a young CCNA about QOS, luckily he had some idea of QOS already and was a very quick learner. I took him through the basics of DSCP, COS, and the various tools available to you for QOS (shaping, policing, priority, bandwidth and WRED)

So far so good right?

Like I explained to the customer though, the biggest problem with QOS has nothing to do with the syntax or the configuration. The biggest issue is DESIGN and TROUBLESHOOTING. A few people apply QOS policies to there Internet-facing interfaces on OUTPUT and then think to themselves "Jee QOS does not seem to work" when it fails to achieve anything. The problem however lies in there design.

Without going into too much detail, it is CRITICAL to remember that the QOS "tools" priority and bandwidth do not do ANYTHING unless an interface is congested, so the very first thing you must do when designing your QOS is consider the size of the interface.

For example, lets say you have an Ethernet connection that connects to your ISP (pretty common these days.) Your actual speed the ISP provides you is 2 megabits per second, but your Ethernet interface is 100 Megabits. It is important to remember when using a QOS policy on an interface that the QOS policy only works if traffic is in the software buffer, and if your actual interface SPEED is 100 meg but your ISP speed is 2 meg, then the software buffer will never be used! Because as far as your router is concerned, there is PLENTY of bandwidth available. To get around this problem you must use a hierarchical policy map. An important note here: the bandwidth command under the interface is NOT used to control the bandwidth of the interface from a QOS perspective or to speed limit the traffic on that interface.

This configuration is simply used as a metric for internal routing protocols such as OSPF to help them calculate the cost of a link so for example, if a link is 100 meg and you want to make it less desirable, you could use the bandwidth command to say it is a 1 meg link in OSPF calculations. This would not limit the speed of the interface.

A hierarchical policy map is how you solve this issue, see below a configuration example:


policy-map parent_policy
class class-default
shape average 2048000
service-policy child_policy
!

We then apply this policy to our interface, and our child_policy is where we put our actual QOS policy, the one that prioritizes VOIP traffic, rate-limits HTTP or whatever else we desire to do.

What this does is limit the speed of the traffic to 2 megabits per second, so that a software buffer is created for this traffic. Once the traffic is inside the software at this point we can manipulate it with our QOS policy and our policy will actually have some effect!

But wait! There is more. The second important factor to consider is WHERE to apply your QOS policy, as you may know you can only use the priority and bandwidth commands on OUTPUT and NOT on input since no software buffer can possibly exist for traffic ENTERING your interface (how can you queue traffic thats not actually going out your router?)

Therefore, when writing your QOS policy, consider in what direction the traffic is most likely to experience congestion, so for example:

internet----> Dialer1 on router <--- Router ---> fa0/0

The thinking may be to prioritize FTP over HTTP for example that you would place your policy-map on the dialer interface, but if you think about it, traffic going OUT the dialer interface is only going to be acknowledgments! So chances are you wont experience congestion on your UPLOADS and hence your QOS policy is not going to accomplish what you set out to do. Since you can't apply it on the input because you want to use priority and bandwidth, the best choice is the fa0/0 interface. By placing it here you will be controlling the traffic as it leaves the router towards your network, so you can prioritize and shape as you see fit. I guarantee this works because I do it at home.

To complete the config, here is the full details guys:

policy-map parent_policy
class class-default
shape average 2048000
service-policy child_policy
!

class-map ftp
match protocol ftp
!
policy-map child_policy
class ftp
bandwidth percent 75
!
class class-default
fair-queue
!
!

interface fa0/0
service-policy output parent_policy
!

So in this example what I am doing is guaranteeing FTP 75 percent of the 2 megabits of bandwidth during times of congestion. All other traffic is in the class default class and the fair-queue command ensures that each queue is given equal amounts of bandwidth if there is congestion on the link.


Super quickly, to check if it is working correctly you would issue

#Show policy-map interface fa0/0 (but more on the output of this tomorrow.)


Coming tomorrow: Advanced QOS Design (what to do when we add IPSEC to the picture) and troubleshooting your QOS effectively.

Call Recording: The good, the bad, the ugly

Ahh Call-recording, its a feature many customers ask me about so I thought I would briefly speak about it here.

Just before we go on any further, I think I ought to mention the legal requirements surrounding call recording. First we shall look at a legal definition of call recording:

"Recording a call

Recording is the physical act of making a recording; monitoring is the listening to a call when being made or later."

Now lets look at the legal requirements for making a call recording:

“Every reasonable effort is made to inform parties that recording or monitoring is taking place.”

So in other words, you MUST inform the calling party that they may be recorded and/or are being recorded.

The Data Protection Act of 1998 also specifies that you must treat these recordings like any other form of private data stored electronically.

So now we have that out of the way and you understand your legal requirements, what kind of call-recording can we offer?

First of all, Later versions of Cisco Unity Express, Most versions of Cisco Unity Connection and Cisco Unity come with a feature called "Live Record." This rather handy feature allows a user to "conference" in the live-record pilot number, a beep will then sound indicating that the live-record feature has started, and the resulting .wav file will be placed in the users voicemail box after the call is complete.

SPAN is another method of configuring recording but is much more difficult to do, the idea behind this is to catch the RTP stream using port-mirroring. This requires more than just call-manager software however to execute and recording cannot be performed "on-demand" by the end user.

The final option is the use of third party software, to be totally honest I have not completely looked into this option as yet but I had a very interesting email from a company called Red Box who develop a voice-recording app. I will be investigating over the week and will let you know my findings.

Cheers
Pete
CCIE #18371

Ironports can perform man-in-the-middle for SSL.

Ironport WebProxys are capable of intercepting SSL to ensure they are not being used to tunnel other protocols. It used to be that you could run your SSH daemon on port 443, and even if you where behind a proxy you could potentially tunnel your traffic via SSH so you can get out and do whatever it is you want to do (BitTorrent, MSN, etc. etc.)

The reason for this was fairly simple: Since the connection was a secure connection, the proxy could not see the traffic encapsulated inside the port and thus was unable to determine if it was legitimate traffic or not. Luckily however the Cisco Ironport has a method around this, by inserting itself in any SSL path, so the actual SSL stream looks like this:

Client <--- Secure SSL with IronPorts Public Cert ---> Iron Port <---- Iron Port secure connection with SSL website ---> Secure Website.

The main drawback from this approach is that the certificate presented to the client will be untrusted, because it is signed by the Ironport application. This is easily resolved by either trusting the ironports self-signed certificate as a root-CA (Meaning any certificates the ironport subsequently signs are trusted) or by having the ironport request a Root-CA certificate from your own organizations root-CA and then rolling out the trust relationship via group policy.

Another awesome Ironport feature and a great way to stop people doing the dodgy on your network.

Ironports can perform man-in-the-middle for SSL.

Ironport WebProxys are capable of intercepting SSL to ensure they are not being used to tunnel other protocols. It used to be that you could run your SSH daemon on port 443, and even if you where behind a proxy you could potentially tunnel your traffic via SSH so you can get out and do whatever it is you want to do (BitTorrent, MSN, etc. etc.)

The reason for this was fairly simple: Since the connection was a secure connection, the proxy could not see the traffic encapsulated inside the port and thus was unable to determine if it was legitimate traffic or not. Luckily however the Cisco Ironport has a method around this, by inserting itself in any SSL path, so the actual SSL stream looks like this:

Client <--- Secure SSL with IronPorts Public Cert ---> Iron Port <---- Iron Port secure connection with SSL website ---> Secure Website.

The main drawback from this approach is that the certificate presented to the client will be untrusted, because it is signed by the Ironport application. This is easily resolved by either trusting the ironports self-signed certificate as a root-CA (Meaning any certificates the ironport subsequently signs are trusted) or by having the ironport request a Root-CA certificate from your own organizations root-CA and then rolling out the trust relationship via group policy.

Another awesome Ironport feature and a great way to stop people doing the dodgy on your network.

Waiting to Exhale (Via Networkers.)

Well, the wait for networkers is well underway, luckily for me the week of networkers is quite litreally the day after my birhtday party! Should make for a very rapid cleanup before I fly off to brisbane.

I am really looking forward to the video surviellance/Physical security side of things. This is a product you really don't hear much about but is another great ISR module you can install in your router:

http://www.cisco.com/en/US/prod/collateral/vpndevc/ps6918/ps9145/ps9152/at_a_glance_c45-468316.pdf

Interesting new features for IPS 7.0

I ran across this article on network world and thought I would share it. SenderBase is basically what your paying for when you buy an Ironport so it's good to see Cisco intergrating it into other products.

It's a great idea, lets say for example the 139.0.1.0 network is infected with Code Orange (or some other new worm,) as this network launches attacks on other networks equipped with Cisco IPS's the reputation of the network will suffer and future IPS devices will flag it as dangerous based on the network it's coming from alone!

Personally I am just patiently waiting for the Ironport to come out as a module for the ISR routers and/or ASA devices, can't wait!

Cheers
Pete
CCIE #18371 and all round nice guy