Hello All!

I finished the IPX 3A Vol 1 lab today. It was a very good exercise and it was much more realistic than 2A ( which is very very hard ). I took about 6 hours to get it done.

Here are some of the interesting points that i learnt in today’s lab

• Yesterday i had some trouble configuring RSPAN on the INE rack rental. The INE rack rentals have 3550’s as the access switches and i couldn’t get RSPAN to work on them. But today it worked. I’m still trying to figure out why. However the only config that we need to remember  can be found here. -> http://is.gd/cUjbP
  • Also in SPAN/RSPAN configuration, pay keen attention to the keywords “ingress” , “untagged” if we have to permit return traffic in the SPAN/RSPANs destination interface. I’m a little confused about this so i’ve asked this question on OSL. Hopefully i’ll have an answer soon, and i’ll update this post.
• When doing IPX labs, there were many tasks which required dropping traffic if a special type of ping ( big size , bad source ,etc ) was detected. The IPX DSG showed that there are standard signatures to match these issues. But instead of sitting and searching for those, i configured my own signals. This just takes 2-3 mins and this way we atleast need not waste time searching for the signal. IMO, i don’t think it matters, because at the end of the day, the proctors are looking for the config to work.
• Also, a good tip which i want with you guys is REGEX matching. This is particularly useful in tasks where you have to drop packets with a certain payload ( maybe worm mitigation ,etc ). For this we will have to use/configure/create signatures belonging to “STRING” engine. Now here’s the tricky part. How do you verify if the regex that you have configured is correct or not. I use the ASA for this. The ASA has a neat command called #test regex <string to match> <REGEX> .  The really neat part is that, when i was going through the DSG  after the lab was over, tyson also uses the same technique to check if his regexes are ok, prior to implementing them on the IPS.
  • Ex : #test regex test [tT][eE][sS][tT]
• Ok here’s a little trick that i didn’t know , but i learned it from the labs. Suppose you have a task which says -> “Only B should telnet to A. If router C or D telnet to A, that traffic should be dropped by the IPS”. How do you go about configuring this? I kept on wondering about, how to permit the pings ONLY for A. Was there an IP address field in the signature configuration, where i could permit only router B to telnet to router A. Then i checked the DSG. The solution was awesome. Here are the steps :
  • First , in the signature that matches the telnet traffic going to Router A, configure it to drop ALL packets. Yes, you heard me right. Wait for the next step.
  • Now,  head over to Event Action Filters, enable them, and filter out the “drop packets” action for only traffic from Router B. So this way, we’ll be achieving what the task requires us to do. Isn’t this just cool!
• Here are 2 things i always try and keep in mind :
  • For BLOCKING , RATE-LIMITING -> The IPS uses it’s Management interface to send the block, rate-limit commands.
  • For TCP RESETS -> The IPS uses the promiscuous interface that it receives the traffic on. It sends back the tcp resets on that interface. Therefore, we must configure that span port to permit “ingress” traffic too, and place the tcp reset traffic in the same VLAN as the destination of the TCP resets.

Also, for the first time ever, i read through the whole 3A lab prior to configuring them. I know , instructors have been telling us to do this, but i was just too bored and i thought my way was correct. I used to just draw the diagram and start with TASK 1. I was SO wrong! I took the time to go through the whole lab, and make markings in my diagram about interesting stuff that i would encounter later in the lab. Ex : I know that i would have to configure blocking on say Router A and ASA1 etc. Also i know what all Virtual sensors operated and where they operated. This made my labbing much more efficient. I’ve been a totally dumbass for not using this technique in my earlier labs. I would highly highly recommend that you try it too.

Here’s what i do. I get a Blue/black pen , a Red pen and a pencil. I use the BLUE/BLACK pen to draw the network diagram. I then used the pencils to mark the IP addressing . Then i used the red-pen to indicate what all i’d have to configure on the diagram. This works for me. Do give it a try sometime.

Here’s what my diagram looked like, even before i started task1. I took 30 mins right at the beginning of the lab, but it was well worth it.

I’d love to hear from you, about the techniques that you guys use to lab more efficiently. Also, if you have any notes that you’ve taken during your labbing sessions, please pass them on so that all of us can be benefited from them.

Cheers and have a GREAT weekend!

TacACK