9. 14.8 Common Defense Strategies
What are some best practices to help protect our network against attacks? That’s what we’re going to discuss in this video. As a first best practice, let’s change default credentials on our equipment. If you have a wireless access point with a username of admin and a password of admin, you probably want to change those. Any equipment that you can go online and see default passwords for, probably you need to change that. And that includes things like your SNMP management systems. For years, networking equipment using SNMP came with a read only community string of public and a read write community string of private and it was a very well known set of credentials used by different vendors. So let’s change those default credentials.
And when you’re setting up a password, avoid a common password such as characters from Star Wars or your spouse’s name or your birth date. You want to come up with something that is typically a mixture of upper and lowercase characters, special characters, numbers, and it should be of a fairly long length. And you want to make sure that your hardware has upgraded firmware a lot of your network devices such as wireless access points, they will commonly have firmware updates available and you can download those updates and that might improve performance and it’s probably going to improve security as well. And it’s not just the underlying hardware that needs these firmware updates. For the software you should perform regular patches and updates.
And if you do file transferring and you want to make sure that the file does not get altered or corrupted in transit, you can do file hashing. You could use a hashing algorithm like MD Five or Shaw One, and by providing the party that’s doing the downloading with both the file and the hash digest, when they get the file, they can run a hash algorithm themselves on that file. And if the hash digest that they calculate matches the one that was initially provided, then they have some assurance that that file has not been modified or corrupted. We want to disable any unnecessary services running on our equipment. If we don’t need web services running on a particular networking appliance, we might want to turn that off. And when we’re connecting to devices, we want to use, if at all possible, secure protocols. As a couple of examples, we should use secure shell as opposed to telnet.
We should use Https as opposed to Http. And one way of doing encryption is to use shared secret keys. If that’s what you’re doing, then you want to periodically and I would schedule this, change out those keys, generate new keys so that they don’t get compromised. Maybe an employee left the company and maybe they know what that key was. You want to have different keys, you should also disable any unused ports, and by that I mean a couple of different things. I’m talking about logical IP ports. For example, TCP port 23 for telnet TCP port 80 for http you might want to disable those service ports, as we’ve already discussed. But you may also want to disable physical ports on your ethernet switch that are not in use.
This can help prevent somebody from going into a wiring closet and connecting their laptop and gaining access to your network and possibly launching a man in the middle attack. Another best practice is to keep the signature databases on your IDs and IPS sensors. Let’s keep those signature databases updated so they can better do their job of trying to match incoming traffic against that signature database. You might want to also go through a collection of best practices for doing device hardening. This would include some things we’ve already talked about, such as disabling unnecessary services, maybe preventing access from the Internet if nobody from the Internet should be accessing this device, as just a couple of examples, another best practice is to change the native VLAN on a one Q trunk.
There is one VLAN that is not tagged, and we call that the native VLAN and oftentimes it defaults to VLAN one. Unfortunately, all of the switch ports that have not been configured, they probably also default to VLAN one. That means that somebody could plug into an unused port and suddenly they’re on a VLAN that’s going across a trunk. You may not want that. So it’s a best practice to change the native VLAN on a one Q going between your ethernet switches to something other than the default. And for the different users in your network, you want to define what privileges they have. If they’re at the help desk, maybe you want to give them read only permissions to a variety of systems, but not read write privileges. And somebody that focuses on router administration, maybe they have read write permission to the routers, but maybe they don’t to your ethernet switches.
Other ways that we can help mitigate network threats include monitoring the integrity of your files. And an example of that we mentioned a few moments ago where we were calculating hash digested values for a file to make sure it was not modified or corrupted in transit. And when you’re adding users to your network, you need to clearly understand what do they need to access and what do they not need to access. Define different roles and this role can be a definition of they can have read permissions to this, they can have read write permissions to this other thing, and they cannot even read this other entity on the network. Define your roles and assign appropriate users to the appropriate role. And one mechanism many companies use to help protect themselves against an outside attacker is to set up what’s called a honeypot. And this might be a Linux server, for example, that has not been hardened. It is going to be fairly easy to break into.
It has plenty of vulnerabilities and the attacker could export those vulnerabilities and they could get into the server, but the Honeypot was put there on purpose to lure the attacker in. It’s almost like the Winnie the Pooh cartoon where Winnie the Pooh gets stuck in the tree going after the Honey, because once you’ve lured them in, you can monitor what they’re doing. You can understand what tools they’re using to try to get into your network. And also you’ve distracted them from your valuable resources by luring them into this unsecured resource. So they’re basically wasting their time because you don’t have any actual valuable data on this Honeypot. Now, a Honeypot is an individual system that’s going to attract the attacker. However, you could have a more robust distractor, and that would be a Honey Net, an entire network containing nothing valuable, just something to lure the attacker in.
They compromise a router, they compromise the switch, they compromise the server. It’s not going to damage your organization because it’s isolated. You’re just luring them in there and you can monitor what they’re doing while they waste their time on your Honey Pot or Honey Net. But we don’t want to rely on watching attackers to figure out where our vulnerabilities are. You may want to hire a Pen tester that’s short for penetration testing. That’s where you may hire an outside third party to see if they can get into your network and identify vulnerabilities, see what they can get to, and then they can come back and report to you. Here’s what I was able to access. That means a knowledgeable attacker could also access this, and they might give you a recommendation as to how to protect yourself against that vulnerability. Something else we can do is to segment our network into different security zones.
When I worked at university, we had something like we see here on screen. We had different security zones. We had the outside connecting to the Internet, we had the inside connecting to the faculty and staff within the university. But we also had lots of residence halls on campus, students that were living on campus. They had rooms. We put those rooms in a separate security zone, and we typically call that zone a DMZ or a demilitarized zone that would prevent the students from getting into the faculty staff resources while still protecting the students from the Internet and allowing the students to get out to the Internet or in a corporation much like what we see here on screen. We may have servers that we want to be accessible from the Internet.
Maybe we have a Web server, an email server. We want people to come in from the Internet and get to those servers. So we might put them in a DMZ zone. But by being in that zone, if somebody does compromise the email server as an example, they’re not going to be able to use that as a hopping off point to go attack our inside resources, like that accounting server. And the buzzword you hear a lot in the industry these days is defense in depth. What we’re talking about when we say defense in depth is we don’t just have a single security solution. You don’t say that I have a firewall, therefore my network is secure. No defense in depth means we have overlapping layers of security.
The metaphor I often give my students is this think of yourself on a cold winter’s night in your bed and you’ve got a blanket over you up, but your foot sticking out, so you put another blanket over that foot, and maybe your elbow is sticking out over here because the blanket is too narrow. You put another blanket there, you have these overlapping blankets to completely cover you and keep you warm. Same thing with security. We want to have overlapping blankets of security. Maybe we have physical security. We might have some sort of a card reader to allow somebody to swipe into a room. Maybe we’ve got a security guard. Maybe we require strong passwords on our network. Maybe we use different types of encryption and hashing. We want overlapping layers of security, like firewalls and intrusion prevention system sensors. That’s what’s going to give us the best security, not having a single security solution. Another term we hear a lot is zero trust.
Now, what this implies is when somebody attaches to the network, they do not get assigned a default set of permissions. For example, if somebody plugs into a switch port, that’s part of the accounting VLAN. We don’t want them to necessarily have permissions to access the accounting servers and printers and other accounting resources or be able to probe the network to see what devices live in that VLAN. No, initially we trust them. Zero. There’s a zero trust policy that says you don’t get any permissions until you authenticate yourself. Then that user is given an appropriate set of permissions. And finally, there’s the concept of least privilege. Going back to our accounting department example, let’s say that we were setting up permissions for users in the accounting department.
We may not want to give every accounting user the same privilege level. Let’s give them the least amount of privilege that will still allow them to do their job. Maybe not everybody needs to get to this particular accounting server. Or maybe somebody should not see this shared file. After all, if somebody has access to too many resources, that might ruin our system of checks and balances. So the goal is give a user a set of permissions that allows them to do their job, but no more. And that is a look at some different ways of mitigating network threats.
10. 14.9 Switch Port Defense
One type of attack that someone might launch against an Ethernet switch is a Mac flooding attack. We know that a switch port is going to look at frames coming in and it’s going to record the source Mac address of those frames in its Mac address table. But what an attacker might do is send a series of frames into that switch port, each with a different Mac address. They could simply write a program that’s going to, as an example, increment the Mac address by one each time they send in a frame on some operating systems with just one command, you can change the Mac address to whatever you want. But after this happens, for maybe a couple of minutes, maybe just a few seconds, we could send potentially thousands of frames into that switch, each with a different Mac address.
And the Mac address table on that switch has a capacity, and it varies switch model to switch model. But let’s say it was about 4000 Mac address entries. Well, within a fairly short period of time, that attacker could send in more than 4000 frames, each with a different Mac address. Now, how is that a security issue? Well, the issue is if somebody new attaches to this switch port, then the switch has no room in its Mac address table to learn the Mac address of that newly attached device. Which means if somebody is sending data to that device, the switch is not going to know off of which port that device is connected. So, in a desperate attempt to make sure that the frame going to that newly attached device gets to that device, that switch is going to flood the frame. And flooding is when we make a copy of an incoming frame and we send it out all of our switch ports within a VLAN anyway, other than the port on which that frame was received. And one of those ports is connected to our attacker, who might be running some packet capture software where they’re going to be able to see traffic and capture traffic going to that newly attached device. This is a way to force a switch to not behave much like a switch and send the attacker copies of traffic going to a newly attached device.
The good news is many Ethernet switches support a feature called port security. Or it might be called something different, depending on the manufacturer. But in general, port security allows you to set a maximum for the number of Mac addresses that can be learned on a specific port. That way, if an attacker sends more than maybe ten Mac addresses into a port, the switch is going to say, nope, that’s my capacity. I’m not going to allow any additional Mac addresses to be learned off of this port. And that’s a way that we can help protect an Ethernet switch against a Mac flooding attack.
11. 14.10 Access Control Lists
Let’s think about how we can permit or deny traffic coming into a router interface or exiting a router interface. That’s what we can do with an access control list or an ACL. Or you might hear that pronounced as an ACL and it can be used to permit or deny traffic coming into a router interface that will be inbound traffic or going out of a router interface that will be outbound traffic. And this list is a listing of access control entries, aces or ACS. And these ACS are processed top down. That’s critical to understand when you’re looking at an ACL. For example, let’s say I wanted to permit one host out of an entire subnet, so I would want to give the statement saying I want to permit that host before I gave the statement saying I wanted to deny the subnet.
If I said I wanted to deny the subnet first, then that would deny the host. And we would never even get to the line that says, oh, exception, I want to allow the host. So we’re going to be processing things top down. And if something is not matched at all, it’s going to be denied implicitly. There is an implicit deny any statement at the bottom of our ACL. So if we don’t explicitly match it, it’s going to be implicitly denied. And this can vary by router model, but on Cisco routers we can choose between a standard or an extended ACL. A standard ACL allows us to specify a source IP address and that’s about it. We cannot specify the destination, we cannot specify a particular protocol, just all IP traffic coming from this source. And that source could be a specific host or it might be a subnet.
And as we’ve already mentioned, we want to put more specific access control entries near the top of our list. And if we’re using a standard ACL, we want to place that near the destination because we’re only matching the source IP address. If we put that too close to the source, we’re going to be blocking it from getting to other places in the network that we wanted to get to. However, that’s not the case with an extended ACL. An extended ACL gives us a lot more flexibility than a standard ACL. It allows us to specify the source, the destination, as well as specific protocol information. I could say I want to permit TCP traffic on port 23, that would be telnet traffic going from this source to this destination. And because we’re being more specific about the traffic, it’s better to put those ACLs, the extended ACLs, closer to the source.
And the reason is we’re not going to be dropping a packet accidentally too early if we place it near the source because we know where it’s going, we know what protocol it’s using, and by denying any traffic early on, that’s going to prevent it from going across the network and consuming bandwidth. And we’re going to eventually drop it anyway. Now let’s drop it early. And again, this could vary by router model, but I want to show you a couple of configuration examples. Here on Cisco routers, we can say that we want to create a standard ACL, and our goal specifically is we want to prevent traffic from PC One in this topology from getting to the 192, 168, 100:24 network that’s the subnet on which both servers reside. Now think about what we’re asking here. We want to deny PC One, so that suggests that we want to allow PC Two. And if I just say I want to deny PC One, and I don’t explicitly say I want to allow PC two, remember that deny any statement. Yeah, it’s going to block PC Two as well. So take a look at our syntax. We’re creating an access control list, and this is a numbered list. It’s identified with a number of two. Another option is to create a named list. You can do that in Cisco iOS. But here we have an access list numbered two, and that’s in the range of numbers used for standard ACLs. And we’re saying we want to permit the host, and this is the source of ten one, one, two, that’s PC Two. And even though I could just let the implicit deny any take care of preventing traffic from PC One, just to show you how we can specify an entire subnet, notice the second ace in this access control list, number two.
I’m saying Access Hyphen list two deny, and I’m specifying the subnet on which both PCs reside. Ten, one, 10. And we’ve got a 24 bit subnet mask. But notice this is a wildcard mask we’re using here. A wildcard mask is like the inverse of a subnet mask. Every time we have a 255 in the subnet mask, we’re going to have a zero in the wildcard mask. So this is sort of an inverse of the subnet mask. And again, we call it a wildcard mask. But I’m denying all PCs on that subnet. But because we’re processing things top down, I’ve already permitted PC two, and then I’m going into Router R one’s gigabit zero one interface, and I’m applying this access control list in the inbound direction. Let’s take a look at an extended ACL here. Our goal is to allow PC One to connect to server one using TFTP, and PC Two should be able to connect to server two using FTP.
And that implies that all other traffic should be denied. So let’s take a look here. We’ve got access. Hyphenlist 10 one. That’s one of the numbers in the range for an extended ACL on Cisco routers. And first, let’s allow PC One to get to server one using TFTP, and TFTP is going to use UDP port 69. So I say, I want to permit and then I give the protocol suite name UDP. And I say, I want to permit the host of ten one one that’s PC. One going to a destination something we could not specify with a standard ACL, but we’re going to a destination host of 192 168. One two. That’s server one. And then we say EQ 69. We’ve already said this is going to be a UDP protocol. And now we’re qualifying that and saying specifically it’s UDP port 69.
And we’re following that up with another access control entry. This time we’re permitting TCP. And instead of giving a port number, I’m saying EQ FTP because many times we can specify the protocol name as opposed to the port number. And I’m permitting the host of ten one dot one one dot 1102, that’s PC two to get to host 192 168 one three, that server two. Then, just as we did in the previous example, we go into the gig one interface on R one, and we apply that access control list in the inbound direction. Oh, by the way, if I wanted to apply it in the outbound direction, I could do that. I could simply go into interface gig zero, slash two and say IP access hyphen group 10 one out, and that would apply the list as we were exiting R one, going towards the servers. And that’s a look at access control lists.
