Start with 7 free days of training.

Gain instant access to our entire IT training library, free for your first week.
Train anytime on your desktop, tablet, or mobile devices.

Implementing Cisco IOS Network Security (IINS)

The exam associated with this course was retired December 1, 2015. However, this course still retains value as a training resource. For our most up-to-date training, see Keith Barker’s Cisco CCNA Security 210-260 IINS course....
The exam associated with this course was retired December 1, 2015. However, this course still retains value as a training resource. For our most up-to-date training, see Keith Barker’s Cisco CCNA Security 210-260 IINS course.

This CCNA security training course, produced by Cisco expert Keith Barker, helps prepare you for the 640-554 Cisco exam, and prepares you to address many of the real world vulnerabilities you come across today.

Keith dives into the Cisco Configuration Professional (CCP), the latest GUI (Graphical User Interface) software which will help you manage your Cisco routers. Not only does this training focus on switch security and router security, it also explains and demonstrates how to configure the ASA (Adaptive Security Appliance) firewall. Keith, author of the CCNA Security Cert guide, covers the material in a way that is thorough, fun and engaging.

Whether you're fairly new to the network security world, or you've been in it for a while and simply want to fill in the gaps and see how all the pieces can be integrated together to build a fortress of security using a defense in depth approach, this course is for you.

Keith Barker has been a CBT Nuggets trainer since 2012 and holds a variety of Cisco certifications, including Cisco CCIE Routing and Switching, Cisco CCIE Security, and Cisco CCDP.
 show less
1. Introduction to CCNA Security (7 min)
2. Network Foundation Protection (38 min)
3. Fortifying the Local Router (42 min)
4. AAA, RADIUS and TACACS+ (47 min)
5. Securing the Switched Data-plane (50 min)
6. Tools to Protect the Management-plane (43 min)
7. Controlling the IPv4 Data-plane with ACLs (34 min)
8. Protecting IPv6 Networks (53 min)
9. IOS Firewall Fundamentals (31 min)
10. Zone Based Firewall Implementation (25 min)
11. ASA Firewall (47 min)
12. Intrusion Prevention Systems (IPS) (45 min)
13. IOS-based IPS (48 min)
14. Cryptography Essentials (42 min)
15. IPsec Site to Site VPNs (53 min)
16. SSL VPNs (51 min)
17. Defense in Depth (24 min)
18. The Parka Principle (4 min)

Introduction to CCNA Security

Network Foundation Protection

Fortifying the Local Router


Securing the Switched Data-plane


Port security, BPDU guard and other Layer 2 tools to help you sleep better at night. In this Nugget, you and I get to take a look and some of the very common and easy attacks against Layer 2 and specifically how to mitigate or reduce the risk of those attacks.


This is the doozy. Grab yourself a glass of water, maybe a quick snack, and let's take a look at protecting Layer 2. To appreciate how clever these Layer 2 attacks are we want to make sure we understand the basics of how switching operates. So let's do a quick review together.


If we have these two PCs-- and let's also set some framework for this switch. We have trunks right here between the two switches. We have two of them for fault tolerance. We have patch cables here for the PCs to switch. And when this computer-- let's say his Mac address is AA.


And I realize that a MAC address is 12 digits long in texts, but I'm going to put AA for short and BB down here for short. When PC 1 sends its frame-- the very first frame-- into the switch, the switch does what? It memorizes it. It says, oh, based on your source Mac address, I know that port one has an address of AA and it's associated with a certain VLAN.


So let's say this port is assigned to VLAN 3. And down here we'll say the same thing, VLAN 3. So not only does it know that the Mac address lives on Port 1-- so this is our port, here's the Mac-- it also knows the VLAN that it's on. It's also on VLAN 3.


It's also going to keep that information inside its Mac address table-- the dynamic Mac address table. Now the memory space that's used to store the Mac address table-- the dynamic one-- is called content addressable memory. So if somebody says CAM, like the CAM table-- oh yeah, that's a CAM table overflow attack-- you're just taking a look at the memory table, where all those Mac addresses and where they live are stored.


Let's take this all the way down. Let's say that PC 1 sends a broadcast. A broadcast-- as you know-- would be sent into that switch. It would be sent to all the other ports that are also active and members of VLAN 3. And a trunk is also associated by default with VLAN 3.


So the frame as it goes down the trunk is tagged with an 802.1Q header that indicates, hey, this frame is a broadcast. Here's the source Mac address. AA. The destination is all F's or all ones in binary. And I'm going to tag it as being for VLAN 3. The receiving switch receives that frame and the .1Q encapsulated information.


It says, hey, thank you very much. VLAN 3 strips off the VLAN 3 tag, doesn't need that anymore. And then it forwards it to all-- because it's a broadcast-- to all other ports that are also assigned to VLAN 3. In this case, the circle blows their access ports.


Now, my question for you is this-- if we have that frame that went down here, in switch-- we'll call this Switch 2 and this is Switch 1. In Switch 2-- Mac address table and the CAM table-- where will Switch 2 think that the Mac address AA lives? Let's say also that this port is forwarding and here we have blocking, because spanning tree doesn't allow parallel pass.


So where will it say it came in? The answer is well, if the frame was sent over here, this Switch 2 would say, oh, Mac address AA lives off this port. That says 1, 3, 5, 7, 9. So let's say it's Port 9. It would also on the VLAN that it came in because of the 802.1Q tag.


VLAN 3. And that would also be stored in the CAM table. So if I have 10,000 devices on my switches, and they're all trying together, every single switch, if there's a broadcast frame that's been sent by every device at least once-- or unique assets going through the network-- all the switches have to memorize all those Mac addresses.


Now, that's OK, because switches have this CAM table memory. And they can memorize dynamically learned addresses. So let's take a moment. Let's bring in a live switch. Keeping this real. And here's Switch 1. Let's do a show Mac address table. And let's just look at the dynamically learned Mac addresses.


In this case, here are all the Mac addresses that have been learned by this switch. They're all in VLAN 1 at the moment, it looks like. We can fix that. Everyone has learned on VLAN 1. Here's the Mac addresses. And here's the pots they were learned on.


So fantastic. This is an example of the content addressable memory CAM table. And it says that we have five Mac addresses. And it's not infinite. We can't hold an infinite number of Mac addresses. But we can hold thousands and thousands of Mac addresses.


But it doesn't go on forever. So that's the basic portion or the basic method of how switching operates. We also want to make sure that we're comfortable with trunking. With trunking, when we send a frame down, we tag it with 802.1Q tags, saying, hey, this is for VLAN 3 or VLAN 2 or VLAN 5 or whatever it's for.


So the receiving switch can go ahead and propagate that. We don't forward all frames to all ports in the same VLAN, unless they are unknown-- we don't know where the Mac address lives-- or it's a broadcast. So if we know in our Mac address table that BB is right here, that frame from PC 1, if it was destined to BB, it would go here.


Down the trunk. Over the back plane of the switch, and out on this port, and we wouldn't bother all the other ports. So if we take a look at what we should be aware of w what attacks are out there. There's some attacks that are done accidentally against our networks, and there's some that are done on purpose.


I'm going to focus on those that are done on purpose. The first one is a rogue DHCP server function. On this network-- let's say this is VLAN 3 and VLAN 3 and we have trunks. And we're providing IP addresses via DHCP. Now, let's remember together how that works.


With DHCP you have a server that's sending out IP addresses, and a client would issue a discover, saying, I'm looking for a DHCP server who can give me an address. The server would answer with an offer. The client would say, wow, I'll take it with a request.


And the server would follow up with an acknowledgement. If an attacker wanted to compromise our network and do what's called a man-in-the-middle attack, he could simply become a DHCP server. Install some software-- it's readily available-- or have a distribution CD it boots off of.


It's all built in. And so when this PC here-- let's say we used .50 as an IP address. And let's say it's the 10.0.0 network. And this PC does the discover. So the discover goes out the network. If this rogue DHCP server answers and makes an offer, and this client takes it, then this client could be given a valid address.


Let's say that's .51. But, check it out, we can give him a gateway of .50. So anytime PCT wants to get off the local network, he would ARP for the IP address of .50, forward frames to .50, and that .50 could then as a courtesy forward those packets to the right default gateway.


But he's just pulled off a full blown man-in-the-middle attack for any traffic for this PC that's going off the local subnet. Easy to pull off. Easy to do. And we can spoof, of course, the DNS information as well. And we can have all kinds of fun with that host now we've compromised him.


So how do we protect against something like this? And the answer is really simple. It's a feature called a DHCP snooping on Cisco switch that supports it. With DHCP snooping, we do two things. We enable it. So you basically say, IP DHCP snooping to enable the feature.


And then you tell it I want to go ahead and do snooping for VLAN X. So that VLAN X may be VLAN 3, or VLAN 5, or VLAN 5 and 3. And here's what DHCP snooping does. It's going to tell the switch to pay attention to those DHCP messages that go across. And the switch-- so we have the Mac address table.


That's already done. But we are also going to create something called DHCP snooping table. And also sometimes called a DHCP snooping database or binding table. And it's going to keep track of no only the Layer 2 address for this house, which is already knew, it's also going to know the IP address that it got via DHCP.


And it's also going to assume that whoever is connected to this port-- or any other port in VLAN 3-- it's going to say we were doing it on both switches. They're going to assume that all those ports are not trusted. And that's the really key feature right out the gate.


Any port in VLAN you're applying this to is not trusted by DHCP snooping, which means those four packets-- discover, offer, request and acknowledge-- any of the packets that would be server packets, like the offer or the acknowledge, the switch is not going to let those come in on an untrusted port.


So if this user tries to do offer, or tries to do an acknowledge, or tries to do any DHCP server-related traffic, that port, right there by default with DHCP snooping is not going to let that frame in. So we've stopped it. Boom. Done. Now what do you do if you're a real DHCP server?


Well, if the real DHCP server's right here on this port, we would tell that port that is a trusted port, meaning, we trust this port because we want to allow the offers and acknowledgements to come in on that port. So let me show you how simple this is to configure.


It really is a lot of fun, pretty simple to do. Let's grab Switch 1 as an example. So in Switch 1 we're going to go into configuration mode. And in configuration mode going to say I want to do DHCP snooping for VLAN 3. And I want to turn on the feature of DHCP snooping.


And that's the part that people forget. You get to do those two commands. One for VLAN. One for globally enabling it. And then we want to go to the port where our actual DHCP server lives, and tell that port that it's a trusted port. That's it. And then we can verify the bindings that are in place.


Now, just so you know, I had beforehand-- like five minutes ago-- I loaded DHCP snooping. I turned it on for VLAN 3. I brought up a couple of DHCP clients, because I wanted to have something to show you in the actual database. This is what it's showing us that OK, we have these Mac addresses.


And these are the IP addresses. Here's the lease time. We learn to via DHCP snooping because you can also stack the configure it. They came in from VLAN 3 and they came in on interface. Interface G0/5 is where they came in from. So that's DHCP snooping.


And the major part of this is that it's not trusting all the access ports by default. You have to specifically tell it which ones you trust. The other thing that this is going to come in handy for-- this information, this DHCP binding table-- is going to come in handy if we want to something called ARP inspection, which we're going to talk about in a few moments, as well.


So that's our first attack, which is rogue DHCP server. And the way you solve that is with a feature called IP DHCP snooping. This next attack is a lot of fun, too, and it is the option of destroying a DHCP server. Now, why would we want to do that? I remember a story about two hikers in the woods and they're hiking along this trail and a bear comes up and it looked mean.


And one of the hikers sat down, got his jogging shoes out of his backpack and started to put them on. And the other guy goes, you're crazy, you're not going outrun a bear. He goes, I don't have to outrun a bear. I just have to outrun you. So if there's a real DHCP server on the network, why not take this guy out of the picture, and then we go ahead and be our own rouge DHCP server and not have any competition.


How do we do that? Well, a DHCP server-- if this is the 10.0.0 network, there's only 254 addresses to go around. The default gateway probably has one already that's static. Maybe a couple other devices like printers are static. So we're really looking at having 250 addresses.


If the rouge device first can issue DHCP discover messages, spoofing his source and Mac addresses-- now when I say spoofing, I don't mean that he's lying about pretending to be somebody else, that's coming up in another attack, but maybe randomizing Layer 2 source Mac addresses.


So the DHCP server says, oh, there's a client. His Mac address is such and such. He's needs an IP address. Oh, there's another client. And basically this guy takes all 250 plus IP addresses-- that's called a DHCP starvation attack. DHCP has nothing left to offer, and then this guy can be his own rogue DHCP server.


That's one way of killing a DHCP server is take all of his existing IP addresses and use them. And the other challenge, or the other attack we could do is called a CAM table overflow attack. This is actually so easy to do it's scary. So they CAM table is where this switch remembers all of the Mac address it's learned dynamically.


Now that CAM table is not infinite, meaning it can't go on forever. We just don't have unlimited space forever and ever. Let me show you exactly what I mean by that. So let me bring in our good buddy, the switch. In fact, by the way this our topology.


We have Switch 1, Switch 2, Switch 3, and I literally have these trunks configured between them. We'll get to that in a moment with our spanning-tree attacks. So Here on switch 1, if we do a show. If we want to see the CAM table-- the content addressable memory-- is actually show mac.


So the media access control. I don't know if they thought about that when they came up with the acronyms, but that's how it works. So show mac address table, and let's do a count. And this is saying, that wow, we don't have very many Mac addresses. We've got five dynamically learned Mac addresses in VLAN 1.


We've got nothing from VLAN 2, and nothing from VLAN 3 at the moment. And the total Mac address space available is 3,039. The other switches in this network as well-- just to be aware of what's going to happen. If for some reason this switch learned 1,000 Mac addresses through broadcast or what have you, those would be forwarded onto our spending tree's going to be blocking one of them-- that these are going to be forwarded.


And if the switch knows 3,000 Mac addresses, this switch is also going to know 3,000 Mac addresses. If those devices are all out here, this switch will say, oh I learned them on this port. And this switch would say, I learned them on whatever ports they came in.


So that leads me to our next attack. It's called a CAM table overflow attack. What was the number on that? It was like 3,039. I think my switch had 3,039 Mac addresses that it could store. Anybody think that's enough for a 48-port switch? It's not going to need more than 3,000 Mac addresses.


Well, not normally. But here's what we're going to do. We're going to do this CAM table overflow attack, and I've got a device connected on port G0/7. It happens to be an attack tool. And it's distribution of Linux and it's called BackTrack. And BackTrack has hundreds of great penetration testing tools, and hacker tools and attack tools.


Again, you'd never want to use any of that if you were not on your own network. So we only want to use it for testing and verifying how our networks are secure, never anybody else's without authorization permission. So having said that, if you are interested more in BackTrack, we've got a whole other Nugget series coming up just on BackTrack itself.


So here, let's go ahead and use it to generate and launch a tool called macof. And this tool called macof is going to generate thousands and thousands of frames per minute, all using made up source Mac addresses. We're going to consume the Mac address table on this switch.


Now, why is that going to help? Well, once the CAM table is just flooded with Mac addresses and devices start to connect to the network, the switch doesn't have enough memory to remember where everyone lives. So Keith, how does that help the attacker?


That gives the attacker an ability to do an eavesdropping attack. So if we're simply flooding the CAM table and now PC 1 is talking to PC 2, what normally would be a private conversation. In this port. Down this trunk. Across the back plane to support.


Because the switch has forgotten where BB lives because of all the offending Mac addresses that are coming into the system, and there's just not enough room for all of them. Now the switch with an unknown destination of BB. It's going to flood that frame to all other ports.


So the PC here is now getting a copy of every single frame. And you can eavesdrop. It's a nasty one. So let's take a look at doing it. And then we'll take a look more importantly at how to solve it. So let's bring in the switch. Just to make sure he has a healthy start here, we'll do a show Mac address table, and we'll say dynamic.


Well, let's just do a count. That'll be easy. So here's the count. We have available space. 3,039 available. We have five dynamic Mac addresses that we're earned in VLAN 1. Nothing in 2. Nothing in 3. And if we put the key word dynamic at the tail end of that, we can actually see him.


All right, so great. He's learned those five Mac addresses on those various ports. So now what we're going to do is-- they're going to go ahead and simply load up. I have a port G0/7. I've got a device. I'm remote connected to it right here. And we're going to use this tool called macof.


Now if you need help with macof, you can do a /h. And that'll give you the details and options. And all I'm going to do is I'm going to specify the /i for which interface I want to use. And I'm going to say, go ahead and everything else you can just randomize.


And it's going to pump just a boatload of content in there right now. So this is just literally tens of thousands of frames that are being sent all with bogus source Mac addresses. We're doing a CAM table flood attack or overflow attack right now. If we go back to Switch 1-- I'm going to actually stop this, because it's done its work.


Let's go back to Switch 1 and hit the Up Arrow key a couple times. And now let's take a look at the count. It's got 3,000 dynamic-- and there must be some limit on this switch of what it's going to do, because it's toasted. It says it has space for 32 more.


But the other thing that's happening is this. This is also affecting the other switches, because a broadcast-- or traffic that makes it down the trunks-- also is going to fill up their CAM tables. Let's go take a look at those guys. Let's go to Switch 2, and let's do a show Mac address table count there.


Oh, there we go. So he's totally eaten up. He supported 5,086. He's got zero space left. Which is not nice. Now if we were eavesdropping, basically every frame that's being sent on this network is being sent to all other ports in that same VLAN. So if we're a member of VLAN 3--and I'll show you how to do that one in a second-- we can basically eavesdrop on all VLAN 3 traffic.


It's all been sent everywhere. So how do we protect against something like that? Well, first of all let's go and shut down that port. Go to 0/7. And say shut. And we'll do a no shut. And what that'll do for us is that will clean up all the Mac addresses off of that port.


Once a port goes down we lose link. Any Mac address that were learned are also gone as well. So our count's back up to 3,000 plus on this specific switch. Now how do we protect against exactly that? What we're going to do is we are going to configure something called port security.


And port security works like this. Port security says, dear Mr. Switch. I know you're doing a great job. You're doing the best you can with what you have. I agree with that. But what we want to do is we want to take this port. 1357. We want to take G0/7 right here, and we want to tell you to not to memorize Mac addresses.


What? What? Don't memorize Mac addresses? Above a certain limit. He goes, phew, OK, good deal. So what's the limit? We can set it to whatever we want. The default limit is one. Meaning you can have up to one source Mac address you're learned on this port.


And that's it. And then the switch says, well, what do I do if I get over one? What happens if I seize more than one source Mac address? And we say, well, the violation's going to be shut down the port. And that's the default violation if we turn on this feature called port security.


Fantastic. The switch says, great. I'd love to do it. Now, in our policy, we may not want that behavior. Maybe we want to say five Mac addresses at the most, because people might have virtual machines doing other kinds of stuff. They have voice VLANs that we have to work with as well.


And you could actually set the number of maximum Mac addresses per VLAN. And so if you're a voice VLAN you can deal with that as well. But the concept here is we specify the limit. We specify the violation. And there's three violations that can happen.


We could say, we want to restrict. We want to protect. Or we want to shut down. And the default is shut down. Meaning hey, you exceeded the maximum number, port's down. And somebody's going to have to come back in and bring it up. That someone would be you as an administrator, doing a shut and a no shut on that port to bring it back up.


Unless you set up some other feature, which we'll also take a look at. If you want to say protect. That simply says oh, once I reach five, don't let any additional source Mac address frames through. Great. I can do that. And restrict does the same thing as protect, however it says a log message, so you could be aware of it, which is a great thing.


Those are the options. Default is one Mac address. Default behavior is to shut down the port. And to turn it on, I'd like to walk you through that right now. So let's go over to the switch. Let me bring him over. There here he is. Nice and beautiful.


And we are going to go to interface G0/7. I just want to make sure I'm on the right port to start with. And let's go into configuration mode. And let's do this. I'm just going to walk you through step by step, as well. In interface configuration mode for the port that we want to set it up, it has to be an access port.


If you don't specify this port is an access port, the port security feature won't turn on. Then I'm supposed to find with the switch port security maximum five, meaning five maximum addresses. The default is shut down, if there's a violation. And I'm going to use it here again, just because I want you see the syntax for it.


But with a question mark, you could say I wanted to protect or restrict instead of shut down. If I didn't specify this command of violation shut down, that would be the default behavior. So this one people forget. We have to turn on the feature. We've tweaked it, and now we're turning it on with this switch port port security command.


And we're good now. Now to verify our work, which is really important, we do a show port security. And that's going to show us the current ports that have port security configured on them, the maximum number of Mac addresses allowed, their current violation state.


In this case zero. And the action if there's a violation that occurs, which would be to go ahead and shut down. We could also tell the switch, in this case, that we want to go ahead and automatically bring a port up, if it goes into air disable state because of port security violation.


This last piece. These last two lines, probably not uber-critical, but I would say that if I have a huge environment, I don't want to have to manually go and reset a port, if there's somebody who's has port security violations. If we give them a 30 second timeout or a five minute timeout which is quite possible we would then just basically say so he's doing it.


The port shuts down. They've got to go do something else for a while. They come back. And if we're logging it all, then we're going to look at our sys logs, hopefully, and say, we need to go fix or find out who's causing that. So these last two here.


Setting the error disable recovery is sanity for us. And the 30 seconds is how long before it'll check to bring it back into a normal state out of error disable. So let's do this. Let's go ahead and go to-- let me get out of configuration mode. And let's go ahead and attack now.


I'm going to launch the same attack. You'll notice also my icon. When there's content that comes to the screen, this little green check mark is going to change to a blue circle indicating there's new stuff on the screen. That'll be our visual clue that something has changed over there.


And let's run macof again. Shouldn't take very long. There we go. It's done. that port. I'm going to stop macof because he's not having any success anymore. So here's our port security violation. And it says, a log level two message. Security violation occurred.


Caused by Mac address. It states what that Mac address is. It just happened to be the sixth one in. And it specifies that the interface is currently in error disable state. To check that we do a show interface status error disable. And that's the easiest way to do it.


Oh, look at that. I just missed it. So I put in this command. Show interface status error disable. And it just recovered it. I waited a little bit too long. Let's send the attack again. It's OK. So the attack's running. Attack stops. And now we can go ahead and run that command again.


It'll show us. Port G0/7 error disable due to port security violation. And also if we do a show port security-- want to catch that in time-- we have the violation count right now as one on that port, meaning it's currently locked down. And in a few seconds here it'll automatically bring it back up because of the error disable recovery that I said, check after 30 seconds.


So in a production environment, again, it's just not practical to have port security violations have to manually be brought up every time by an administrator. But where should this be set up? All of your access ports. So if we have thousands of clients, we might want to have thousands of access ports.


Use port security on them. Maybe give five as the limit for how many Mac addresses. Maybe set up the automatic error disable recovery, so you don't have to go back and see them. But that's going to protect your network. That's going to protect your network against CAM table overflow attacks.


And you do it with port security. All right, so that's our next attack in our list. So let's make a list of what we've taken a look at. Rogue DHCP servers. DHCP snooping. We then had the CAM table overflow attack, which we're going to fix with port security.


And the next one on our list is something called VLAN hopping. Let's take a look at what that is right now. Our next attack is called VLAN hopping, or jumping, meaning you're jumping between VLANs. We used to set up security based on VLANs, and that's still not a bad idea.


So, for example, it goes like this. We'd have for example VLAN 2 here. And in a different color, maybe VLAN 3 here. So we keep people in separate Layer 2 broadcast domains and then we'd have separate Layer 3 subnets for each of those VLANs. And then we would route between them.


And we'd use the security policies on the router to route between them. If this PC, however, wanted to get access to this computer and be directly there and avoid any type of access. Control this on a router. How could he do it? The answer is, if he lived on VLAN 3, he could then simply configure an IP address appropriate for that subnet and logically be on the same subnet.


But Keith, he can't control that. The switch controls the VLANs. We know this. That is true, unless the client has software that can negotiate a trunk. And if the client can negotiate a trunk with the switchboard what VLANs are allowed on a trunk by default?


And the answer is all of them. So if we can trick the switch into making this port a trunk, and then in software we make a logical interface that works with that 802.1Q tag for VLAN 3, we can communicate with anybody on VLAN 3. It's called VLAN hopping.


There's another weird twist to that, where if the native VLAN happens to be something and something else that can double tag it, I have yet to see that be a successful attack as a realistic threat. However, we're going to solve both of them with two basic things.


Number one, we're not going to use VLAN 1 for anything. Ever. It's not going to be your native VLAN on your trunks. You're not going to use it for customer VLANs. So you're going to never use VLAN 1 anywhere. You'll take all of your switch ports, brand new switch and assign them all to VLAN 999-- or some other VLAN where it goes nowhere.


You're going to shut down all of your ports by default on a switch. To arrange command, shut them all down. Then when you bring clients up, you'll specifically assign those port as access ports. You'll specifically assign those ports to be in the correct VLAN.


Or you might be using 802.1X to dynamically authenticate a user and assign the VLAN based on a AAA configuration. But we're not going to allow dynamic negotiation. And I'll tell you what, in most networks I go into, if I look at their switches, there allowing dynamic negotiation.


Where a hacker can simply tell this port, tell a switch, hey, you know what, I'd love to do dynamic trucking protocol. DTP. And I would love to be a trunk. And poof, the link is now a trunk, and now the hacker has direct access to any VLAN carried by that trunk, which would by default would be all VLANs.


So that's another real attack. Let's take a look at possibly how we could pull that one off. I'm going to bring over-- I have-- this is BackTrack. And BackTrack is a fantastic tool. I really enjoy using it. Again, we're not attacking anyone else's networks.


We are not going to do this on your production network. This is in my test lab. Attacking and breaking into other people's networks is serious stuff. We definitely do not want to participate in that, unless they're paying us to do it. And we have written authorization.


And our legal department is involved in making sure that all the I's are dotted and T's are crossed before we do. So what I'm going to do here is we're going to bring up-- now this machine happens to be on Port 5. So Switch 1, I'm on Port 5 with this BackTrack.


And let's run a little utility called Yersinia. I think that's how it's spelled. All right. So Yersinia is a really great tool. It's compiled for lots of different platforms. And I am having problems with it on this machine. So I don't always do this.


But let's use a different flavor of Yersinia. Let's go to the GUI interface. /T will bring up the GUI, and that will work as well. This is BackTrack version 5, release three. Here's the GUI graphical interface for this tool, and if you take a look right here on the left hand side it's showing us all the frames the same.


It says, Keith, I see some FTP. It says it sees some ISL. I don't know how that could be, but it's possible. It says, I see DTP, what that means is dynamic trucking protocol is set up. If we take a look at the switch. Let's take a look at the switch and see what he says about all this.


To show run for interface G0/5. Right here. That looks OK. Switchport access VLAN 3. See the problem is we didn't say, switchport mode access. If we did that that would help us in limiting the dynamic trunking that was going on. But we also didn't do a switchport no negotiate, which we also should do to turn off totally the ability to trunk on this port, dynamically set it up.


So having done that we have these DTPs coming in. We could also verify that with Wireshark. We've used Wireshark in lots of my classes. So let's go and capture on this interface. And we can just look at the traffic. There's spanning tree. There's some CDP.


Oh my goodness. And if we wait-- oh there we go. There's some DTP right there. Dynamic trunk protocol. Fantastic. So this guy's willing to negotiate. Check it out. And the type. And the domain. Fantastic. OK. So we knew that was running from the actual-- I'm going to stop and not save that.


We knew that was running from this tool right here. So look how he used this to launch his attack. This is showing us under DTP that its access at the moment-- it's an access port configured for VLAN 3, but it's automatically willing to negotiate. Check this out.


If you go to show interface G0/5 switchboard that's going to give us the switch port related information regarding that port. And if you scroll down just a little bit, let's see what this says. So the administration mode is dynamic auto negotiate. Great.


It's willing to be a trunk. And if somebody else on the other side agrees to it, it'll go for it. So basically negotiation trucking is definitely on. Currently it's operating as an access mode, which is fine. VLAN 3. But we can change that. So in fact, let me leave this here.


Let's do terminal monitor. Then we remotely connect it to this box. And we'll come back to that in a moment. Let's launch an attack. Let's go ahead and say, launch attack. And I want to trucking please. OK. Done. If you'll notice that's all it took. All it took was two people who wanted to dance and now we are trunking.


So it balanced the port. And if we do a show interface trunk, we now have a G0/5 as a trunk port It's not forwarding yet, because spending tree wants to make sure it's safe. Oh, it's safe. Come on down. And for spending tree, there's like a 15 second listening and learning before it goes forwarding.


So depending on what flavor of spanning tree we're using-- there we go. So great. I now have a trunk port coming to this PC, which happens to be BackTrack, not a good plan. So now with BackTrack I can create logical sub-interface that does tagging on any VLAN I want.


VLAN 1. In the case of VLAN 1-- if that's our native VLAN-- we don't have to tag there at all. We can tag from VLAN 2. Tag from VLAN 3. Use the appropriate IP addresses. We could do Wireshark and listen to all the traffic that's coursing on all those and is being sent to us.


And if there's not enough traffic being sent to us, we just do Mac office. Flood the CAM table so all the traffic is being forwarded out all the ports. On all the devices. And we'd see all the traffic for all three VLANs. The native. The VLAN 1, VLAN 2, and VLAN 3.


OK. So how do we protect against something like this? To protect against something like this, we would want to make sure we tell the switch that we are not willing to negotiate. But we also want to tell the switch that the port is an access port. Those two things will absolutely stop DTP from happening and it won't allow the attacker to negotiate a trunk with us.


So let's configure it. So we're here on switch one. Let me make sure we're on the right device. Go into configuration mode. Interface G0/5. We'll simply say switch port mode access. That's should stop the DTP from increasing. And that will tell at us that it's in VLAN 3, which it already was.


And then we'll say switchboard, no negotiation. Gate is over, as far as negotiating a trunk with his attacker. A lot of people don't do that. A lot of companies don't have that as a default template that they're going to apply for their access ports, but it definitely should be there.


So if we do that command again to show interface G0/5 switch port, you'll notice that the actual truck negotiation here is off. So it's not willing to do it. And also if we look over here at this tool, we won't-- oh, check it out, it's even telling us.


Saying, yup, it's an access port and the ability to negotiate is no longer happening. And its DTP count will not increase. So the switch is no longer willing to be a trunk with us. So how do we secure VLAN hopping? Number one. Don't use VLAN 1 anywhere.


So you know how to do that. Simply assign all the ports on a brand new switch to some bogus VLAN that goes nowhere. And then on your trunks where you do have trunks, go ahead and specify the native VLAN as something other than one. Use it just for your native VLAN.


And then simply use the switchboard no negotiate to turn off the ability to negotiate a trunk. DTP is turned off. And also set the port as an access port. Kind of like double duty. But it's better to be over cautious then to allow customers to trunk directly to your switch, as we did here.


So let's take a look at yet another attack that would harm the data plane at Layer 2. And that deals with spanning tree. So let's say this user here is curious so he goes out and buys a mid-range switch to support spanning tree. He goes into his office.


He disconnects the computer. Takes that beautiful blue cable and plugs it into a switch, which has the auto undock set up so it automatically can talk to the other switch. No problem. A lot of switches have that auto-sensing feature, so we really didn't even have to get a crossover cable.


And now he's got a switch talking with the rest of our network. What can he do? Well, if the port here is misconfigured and allows spanning tree messages to just be sent and received, this switch could become the root of our spanning tree. Now is that the end of the world?


Maybe not. Because we had just a connection from here to here to here. Not a big deal. However, CDP-- unfortunately-- is allowed to run on a lot of ports. So this hacker-- is a person-- could listen in and say, oh, I'm on Switch 1. Port 1. And then he could go ahead maybe walk around the office.


Or maybe it's a weekend, no one's around. And he's goes out and he's listening and he plugs in to all the different offices. And he finds another connection that's on Switch 2. Port 1. Right here. As so what he does, he takes that cable and he also plugs that into a switch.


What we have right now is a situation where if he becomes the root of spanning tree, these two links will both be in blocking state, and we're going to have this guy be the root. And all the traffic from hosts on Switch 1 that need to go to hosts on Switch 2 are now going through a man-in-the-middle of the rogue switch.


Now besides performance being really bad, that's really bad security risk. And if his switch is fairly fast, the users might not even recognize that it's happening. So how do you protect against a rogue switch? And the answer why a person can do this is because of the defaults that exist with spanning tree and with port configuration that we need to change.


So what we would do to change it is we would implement something called be BPDU-- the bridge protocol data unit-- guard. Sort of like the National Guard, but for spanning tree. And here's how it works. If we turn be BPDU guard on-- and we can turn it on globally, where it affects any port that's configured as an access port, or we could do it per interface.


It's up to you. But let's say, for example, we turn off just that interface. BPDU guard says, hey, listen, Mr. Switchboard, if you see it a BPDU inbound on that port, it's over. Shut the port down. It's bad news. It should never be a switch out there.


It's an end user. If there's BPDUs coming in, we have a misconfiguration, or we have an attacker, or somebody's just curious. Shut the port down. And that's what BPDU guard does. BPDU guard says if I see BPDUs, I shut the port down. There's a couple other features also like BPDU filter.


I want you to be aware of that. BPDU filter doesn't shut the ports down, but it simply doesn't allow BPDUs to flow. And there's also something called root guard, which if you're connected to other legitimate switches, but you just don't want the spanning tree topology to change, you can go on a switch and say that certain ports should never be the root port in your spanning tree, although it's OK to receive BPDUs.


BPDU guard get me configured. I'm comfortable in a couple of different ways. I love it when we have choices. We can do it in interface configuration mode, where we say, dear Mr. Interface, you are using BPDU guard. And it's very clear there. Or we could do it in global config, where it takes any access ports that are currently access ports and they're leveraging port fast, it will automatically apply the global BPDU guard to those ports as well.


To err on the side of caution what we're going to do is we're going to set port fast, that's the spanning tree. I don't have to wait the whole 30-second rule. We're going to PortFast globally. And we're going to do be BPDU guard globally. So you can see how to do both of them.


That's a G for global. And then we'll do a bolt on the interface. Just so you can see the mix and match. So once we secure the port, we'll secure it globally. We'll make sure BPDU guard's enabled. I'll show the commands that verify that it's working.


And then we'll test it to make sure that BPDU guard is doing its job and guarding the access port from being able to send in BPDUs. That's the whole goal of it. So let's bring in our switch. So here is Switch 1, which is a right there. And let's go ahead and bring it in and let's configure it.


So in configuration mode, I'm going to turn on PortFast globally by default, and then we'll turn on BPDU guard by default. So any PortFast enabled interface will get the benefit of BPDU guard through access ports. Also I'm going to turn on BPDU guard on the interface.


On G0/5. Also turn on PortFast there. And I also am going to send you that error disable recovery feature we did previously with port security violations. We're going to do it here for be BPDU guard violations as well. So that after 30 seconds-- the interval's still the same that we said earlier.


After 30 seconds, if there is a violation, it'll come back and bring up the port. So the command for that-- I went a little bit fast there-- is right here. So it's the error disable recovery cause BPDU guard. So here's our status. This is a show spending tree summary.


It's showing us for VLANs 1 through 3 that we have BPDU guard default is enabled. Fantastic. And it's also showing us that we've got PortFast by default. That's fantastic. And that's what we're focused on right now. So that's all I wanted to verify. Now, let's test it.


How do we make sure that this is working correctly. Obviously, our switch ports they talk to each other or the trunks we want BPDUs to flow there. But I have that BackTrack machine still connected on Port 5. Let's go talk to him. So we'll leave this here for a moment.


I mean end out of that. Let's bring in over BackTrack on Port 5 on Switch 1. Here he is. OK. The same tool we use earlier-- Yersinia-- will work great. And we could wait until we see some port. Look at that. Spanning tree is pouring in. And we are no longer getting DTP because we turned off negotiation, but we are getting spanning tree.


So if we wanted to launch an attack, and we wanted to go spanning tree and say, I want to claim to be the root, that ought to generate a BPDU. So we'll say OK, and let her go. All righty. So that's happened. We moved it out of the way so we can see our switch.


So our switch is saying, oh, bummer, we have on port G0/5, we have a BPDU guard violation. If we do a show interface status error disable, it'll show us they G0/5 is error disabled. The reason is for BPDU guard. And because I sent that error recovery interval for BPDU guard issues in 30 seconds, if we're patient, it should bring that port back up.


And maybe 30 seconds is too short. Maybe we ought to penalize somebody for five minutes. So you could increase the 30 seconds to 300 seconds or whatever you want to specify before it would try to bring it back up. There we go. So it looks like it's trying to bring the port up.


And look at that. It brought the interface up. I wonder if I have that tool in the background still trying to be root. If that's the case, we're going for a block again. So I'm going to exit out of that tool, so we're not going to try to send BPDUs, because if somebody really is just sending in-- let me refresh this.


See if we got caught or not. Yeah, we got nailed. I just turned it off, just now. If somebody's sending BPDUs in. After it comes back BPDU shows up, boom, it's going to be locked down again after 30 seconds based on our config. If interface is brought up, BPDU shows up, it's brought down.


It's a bouncing ball over and over and over again. So let's take a look at what we focused on in this Nugget on securing the data plane. We identified first of all how basic switching works and how basic trunking operates. And how that can be leveraged.


How could somebody leverage it. Well, if someone puts in a rogue DHCP server, we've got people now going to the wrong Layer 2 address to start off. How you protect against a rogue DHCP server is DHCP snooping. Anybody who is not an authorized port or a trusted from a DHCP snooping prospective their traffic doesn't get to look like server traffic.


So they try to send server traffic. The switch is going to stop that right ingress right at the port that they're send it in on. Next, we were trying to do a CAM table overflow attack. So CAM table overflow attack to exceed how many Mac addresses can be remembered.


We can go ahead and simply limit the number of Mac addresses with port security. And that's a two-for-one. So that mitigates a CAM table overflow attack. It also mitigates a DHCP server exhaustion. Because if they try to send six or 1,000, or how many source Mac addresses that are all different trying to get different IP addresses from the DHCP server, ports security's going to say, well, one's the default maximum and you're done.


And that person won't be able to get additional frames into the network. The next one we took a look at was VLAN hopping. How can this user get on VLAN 2 or 3 or 5 or 7. The answer is they can trick the switching into negotiating a truck with them. So how you fix that?


Just say no. So we turn off the trucking. We turn off the willingness to do negotiation with the switch port no negotiate. We also assign it as an access port. Switch port mode access. And we specify the VLAN we want them to be. And also we're not going to use VLAN 1 anywhere.


Anywhere. Don't use it for your native VLAN. Don't use it for you customer networks. Go ahead and don't use it at all. Is there a situation where you might have to use VLAN 1? The answer is yes. In a heterogeneous environment, maybe you've some Hewlett Packard gear.


You've got some Cisco gear. And you've got some Juniper gear. And you're doing multiple spanning tree, and to get it all to work you have to use VLAN 1 in certain cases. That would be a good reason why you should. But if you've got nothing like that-- no heterogeneous switches need to talk to each other-- you can stick with not using VLAN 1 ever.


And be happy, happy, happy. All right, next. We take a look at the concept of somebody lying about being a switch. So you have somebody who has a rogue switch right here. And they're now the root of spanning tree. And to do that they would have had to send in BPDUs.


So to fix that we go ahead and do BPDU guard. And we can turn that on on a port, which should be on all of your access ports. Or you could turn it on globally. So any access port that has port fast enabled will also have the BPDU guard feature, so any inbound BPDUs on those access ports will immediately trigger the port to go down.


I want to share with you one other attack that's really important and really easy to pull of, too. Let's say somebody plugs into the network and they're a PC and they send a gratuitous ARP. So let's say your router's right here. So there's the router, and let's say his IP addresses is .1 on this network.


And his Mac addresses is CC. I know it's 12 digits, but just for now it's CC. If somebody sends a gratuitous ARP into the network-- the gratuity is where you don't have to do it, but you just did it to be nice. Well, a gratuitous ARP is where nobody asked for an ARP reply, but you've created one.


And this attacker could say something like-- let's say his Mac addresses is DD. He says a gratuitous ARP and it says, oh, my IP addresses is .1 and my Layer 2 address is DD. If we can poison the ARP cache, which that would do on these devices, where they believe that the .1-- their default gateway-- is at the Layer 2 address DD.


They will forward their frames for the default gateway to this device, who then is a man-in-the-middle attack and he can forward them to the correct Layer 2 address of the real router, and the users might not even know. If we can do it fast enough. If there's tons of traffic and he can't keep up, there might be some lags and delays.


But that's a really amazing man-in-the-middle attack. It's called a Layer 2 man-in-the-middle attack. And it's quite possible, and there's lots of easy tool to pull that off. So how do you protect against that? The way you protect against it is you first use DHCP snooping so that your switches know all the Layer 3 addresses and the Layer 2 addresses associated with each port.


Once they have the database from DHCP snooping, we then use another feature called DAI. It stands for dynamic ARP inspection. And every time any type of ARP traffic goes into the switch, they look at it. The Switch looks at it and says, hey, that's-- for this attack, he tries to send in a bogus Mac addresses as far as saying that's part of his ARP information.


The switch is going to say that's not your Mac address. And the switch can kill it right there, using dynamic ARP inspection to stop a man-in-the-middle attack. So if you and I we're going to be focused here on the key elements that I want you to take away from our Nugget together, I would say make sure you understand port security and how that operates to limit the number of Mac addresses.


And I'd also say to be very aware of the concept of BPDU guard. The other best practices, as far as don't allow the trunking. Don't use VLAN 1. Shut down ports that are not in use. Assign all initial ports to an unused VLAN. Those are all good, good best practices, but these would be the two that I would say you should focus on the most as you enter the world of CCNA security.


I absolutely have had a great time sharing some of my toys with you with BackTrack and others. I hope this information has been informative for you. And I'd like to thank you for viewing.

Tools to Protect the Management-plane

Controlling the IPv4 Data-plane with ACLs

Protecting IPv6 Networks

IOS Firewall Fundamentals

Zone Based Firewall Implementation

ASA Firewall

Intrusion Prevention Systems (IPS)

IOS-based IPS

Cryptography Essentials

IPsec Site to Site VPNs


Defense in Depth

The Parka Principle

Please help us improve by sharing your feedback on training courses and videos. For customer service questions, please contact our support team. The views expressed in comments reflect those of the author and not of CBT Nuggets. We reserve the right to remove comments that do not adhere to our community standards.

comments powered by Disqus
Intermediate 11 hrs 18 videos


Training Features

Practice Exams
These practice tests help you review your knowledge and prepare you for exams.

Virtual Lab
Use a virtual environment to reinforce what you are learning and get hands-on experience.

Offline Training
Our iOS and Android mobile apps offer the ability to download videos and train anytime, anywhere offline.

Accountability Coaching
Develop and maintain a study plan with one-to-one assistance from coaches.

Supplemental Files
Files/materials that supplement the video training.

Speed Control
Play videos at a faster or slower pace.

Included in this course
Pick up where you left off watching a video.

Included in this course
Jot down information to refer back to at a later time.

Closed Captions
Follow what the trainers are saying with ease.
Keith Barker
Nugget trainer since 2012