I’m going to try and pick up the pace with new scenarios. Hopefully, this one won’t be too difficult and will work like I think it should. 
Today’s scenario involves securing a trunk between two switches…
A user PC A is located on Switch A with the interface configuration shown in the diagram below. A different user PC X is located on Switch B, and that interface configuration is also shown. Switches A and B are connected by a trunk link on their GigabitEthernet1/0/49 interfaces. The same configuration commands that are shown below the link have been applied to both switches. Assume that neither switch A nor B has been configured for IP routing.
See if you can answer the following questions:
1. Given the interface configurations, is it possible for user PC A to send traffic from VLAN 100 onto VLAN 200, so that it reaches PC X? If so, what configuration command(s) make it possible?
2. What configuration commands should you enter into switches A and B to secure the trunk link and prevent any VLAN hopping? (Hint: There may be more than one way to secure the trunk link.)
Enjoy,
Dave H
June 15, 2010 at 4:37 pm
2) set the natvie vlan to some other vlan not in use and then remove the native vlan from the trunk with vlan allowed command. and you could tag the native vlan with vlan dot1q tag native command.
I’ll think about the first one tomorrow, it seems too easy and i dont want to say anything…
have a good night everyone…
June 15, 2010 at 7:55 pm
Same as above really, because the native vlan on the switch is the same as the access vlan you can play with tags and get the packets to hope acrosss.
change native vlan on link to an unused vlan, and then prune it of both ends of the link. in effect disable the native vlan across the trunk.
now all packets will have to be tagged be the switch before the cross.
June 16, 2010 at 9:33 am
Yeap, I would say prune native VLAN(also change this one to an unused one) at boths ends of the link and change VLAN access on switch B interface pointing PC X.
June 16, 2010 at 10:23 am
1) switch A will proccess a (PC A )packet that is pulled of the ingress queue as L3…
it will search the FIB table for the next hop L2 and/or L3 address. Without making some routing descisions there is no way for PC A to send traffic to PC X.
Are there SVI interfaces defined on either switch? If the SVI interfaces are defined the traffic would be able to move from PC A to PC X.
June 16, 2010 at 11:42 am
Why would it be processed at layer 3? it is coming in to a access port (IE layer 2)
packets are only tagged as they cross the trunk. tags are striped off at the access ports.
so packets received at switch A from PC-A will be left untagged (native vlan is not tagged remember. However if the user on PC-A was to pre tag the frame with a vlan 200 tag. Switch A would ignore this and send it over the link with the tag in place. on reaching Switch B it would then be read and forward on as VLAN 200.
Of course the return journey will not work. Traffic from PC-X will be tagged across the link as by switch B with a VLAN 200 tag. a user on PC-x trying the same trick would get there tag striped out and over written.
so PC-A can send traffic on to vlan 200, but it is not able to set up a two way session with any device on vlan 200.
June 16, 2010 at 11:55 am
When hosts in one VLAN need to communicate with hosts in another VLAN, the traffic must be routed between them.It’s called inter-VLAN routing.
SVI ( Switch virtual interfaces )are used on multilayer switches to route traffic between vlan’s.
June 16, 2010 at 12:02 pm
yes but this question is not asking about that.
its asking if it is possible for a use on PC-a to send packets on to vlan 200.
is also says to assume there is not ip routing configured.
This to me is asking if it is possible to carry out a layer 2 vlan attack. the second part of the question seems to confirm this as it asks how to stop vlan hopping (A layer 2 attack method)
June 16, 2010 at 12:26 pm
i should read the question first..and not watch the world cup while answering…
1) yes, PC A can send traffic to PC X. switchport trunk native vlan 100 command makes it possible.
June 16, 2010 at 4:17 pm
Ok guys:
Why is it that I cannot get this to work in my lab?
Unless both PC’s are on the same VLAN’s, I cannot get connectivity. I will post my lab results pretty soon for you guys.
I’d appreciate knowing where I went wrong.
Thanks!
June 16, 2010 at 4:21 pm
Ok my lab is up. Open for any comments! Thanks!
http://www.brandontek.com/?p=381
June 16, 2010 at 5:09 pm
you need softare on pc A that can tag the packets with dot1q tags. it is only one way. pc-a ccan send packets to vlan 200. but not return. so a ping would fail.
June 16, 2010 at 5:56 pm
Aaron,
That is very interesting. I’m actually using Cisco routers as my “PC hosts”, what I can do is debug ICMP packets to see if “PC B” is actually getting the packets….
Thank you!
June 16, 2010 at 4:20 pm
[...] http://dhucaby.wordpress.com/2010/06/15/scenario-2-securing-a-trunk/ [...]
June 16, 2010 at 6:26 pm
In more detail this is how I believe this attack works.
First, Access ports strip the VLAN information of any frame it receives or sends out.. You don’t want to send tagged frames to a pc or device. and if you receive a frame you want to strip the tag and replace it with what the port is configured for.
Second as I mentions and we all know native vlan traffic is not taged across trunks.
so here’s how it works
On PC A i get a bit of software that can tag frames as they leave the PC. I set this up to double tag each frame. The first tag (nearest the start of the frame) is the native vlan tag ie vlan 100, the second tag straight after I would label as vlan 200.
Switch A now receives this frame and does what is should it removed the VLAN tag.. but only the first one!! the VLAN 200 tag is still there. when it then gets sent across the trunk Switch A does not retag it with a new vlan, as it correctly thinks it is on the native vlan (vlan 100 as the access port is configured). When it reaches switch B however this checks the vlan tag and seeing it is vlan 200 deal with it as such.
if you tried the same double tagging from PC-x, you get a different result, in this case you could still double tag an put the inner most tag as vlan 100. but in this case as the frame was recived again the outer most tag is removed. but then when it is placed on the trunk it is retagged as vlan 200 (as the access port it was received on is configured). because this is not the native vlan. so although your vlan 100 tag would still be present, there is now a vlan 200 tag in front. and this is the tag switch A would se first as it recived the frame across the trunk and the one it would act on.
you could try setting up QinQ tagging if the switch supports it and see if you can get this to work. (QinQ) is quite cool actual and I use it at work for separating out traffic.
June 16, 2010 at 6:34 pm
(Dave please remove this if you think it is not suitable)
if you really want to test this out
http://www.yersinia.net/attacks.htm is a tool that installed on linux can doubble tag packets as well as some other Layer 2 attacks. Of course it should only be used in labs and with the consent of the networks owner..
IT might be fun to play with in a lab, then again it may contain malware or anything else!! I have played with it briefly once long ago in my lab.
As I said Dave if you are unhappy with links to this kind of software please delete this comment, I know its a bit of a grey area, but tools like this can be good when learning to test your knowledge.
July 4, 2010 at 10:54 pm
Hey,
Thanks for posting the double-tag tool link! I’m fine with posting things like this, as long as these are tools we can learn from in our labs.
Dave H
June 16, 2010 at 6:44 pm
Just testing,
Formally known as Aaron
June 16, 2010 at 9:03 pm
Ahhh, now I finally know who you are….
You devil you!!!
=)
June 25, 2010 at 8:39 am
Dave,
Great stuff and great books. Could you post this or just have a spot where we could download these as PDF’s? Sure beats cut and paste.
Mike
July 4, 2010 at 10:50 pm
Hi Mike,
Thanks for your kind words and for suggesting PDF versions of the scenarios. I’ve started posting a PDF link beginning with Scenario 3, and will circle back to add it to previous scenarios. I have lots of scenarios in the queue; just have to find time to write them up and post them. My “day” job has become the day+night job for the last several weeks…
Best regards,
Dave H
July 1, 2010 at 6:36 pm
Hi Dave,
As you may know the updated version of the Boson CCNP test package is out now, and they have seen fit to ask a practice question about CGMP. Which leads me to ask, how much should we know about multicast in general? I’ve done some reading on it in the past, and have done the odd lab on it, but had the impression it was not part of the new exams. Is this a topic that it would pay us to discuss a bit?
regards
John
July 1, 2010 at 7:41 pm
wow…
should i wait before taking this exam?
I’ve scheduled my exam for next week but i might cancel it and wait a year or so until Cisco figures out what is that they are doing….C’MOOON CISCO…get it together already….
I also heard people complaining about the exam engine failing on them, being slow, buggy and some were not able to save their configurations…
P.S. My CCNP quest might be a waste of time… it seems.
July 4, 2010 at 10:48 pm
Hi John,
Thanks for bringing this up. IP Multicast topics like CGMP and IGMP snooping used to be in the BCMSN exam, but Cisco decided to remove all mention of multicast a couple of exam revisions back. I haven’t seen one thing to suggest that multicast is back in the new SWITCH exam at all.
Best regards,
Dave H
July 4, 2010 at 7:38 am
Hi David
after spending a couple of hours to try to do double tagging without an extra software I had to give up.I thought that in your questions you implied that it was possible to do with added configurations.
I thought that dot1q tunnelling could be an option but did not work,also I thought that the 2 access interfaces had to remain so not turned into trunking.
I would be grateful if you could tell us if there was a solution within the limit of the IOS to do vlan hopping,of course it would be very surprising.
Thanks in advance
July 4, 2010 at 10:32 pm
Howdy,
My apologies for not making it more clear that the VLAN hopping would be done by a malicious user on the network. VLAN hopping is a well known attack, but to pull it off, I think you do need to procure some hacker-type software. Within IOS, we can only take measures to prevent the possibility of a VLAN hopping attack.
Best regards,
Dave H
August 19, 2010 at 5:51 pm
Hi Dave,
Thanks for all your work here. A good follow-up to your switch book.
Can i ask you On P.89 of the new switch book, it states vtp transparent mode v2 forwards regardless of domain name. My experiments dispute this: see
https://learningnetwork.cisco.com/thread/19943
I was hoping you might have an answer for me.
October 11, 2010 at 3:01 pm
I agree with the previous statement. The question threw me off because I was assuming default behavior, not a malicious attack. I was like… there’s no way that could happen. Then I saw question two.
December 19, 2010 at 3:47 pm
Regarding question 1.
there are several options, but I think the most interesting one is on switch B on the trunk interface to add
switchport access vlan 200