20. 14.19 Securing DHCP
We love DHCP because it allows a new device to be added to the network, and we can automatically assign IP address information to that device. We could say, Here is your IP address, here is your subnet mask, here is your default gateway, here is the IP address of a DNS server. And there are many, many other options that we could assign as well. However, this could be a security issue. What if somebody installed their own DHCP server on the network and it started responding to those DHCP requests? And as part of the response from this rogue DHCP server, they’re pointing users to their DNS server. So when somebody tries to go to Facebook. com as an example, they can be redirected to a server that the attacker has set up that looks like a Facebook login page. But really it’s fake.
It’s just capturing credentials that people are typing in. That’s the kind of thing we want to avoid, and we can protect ourselves against something like that using a feature called D Eight CP snooping. First, let’s review the operation of D eight CP. And when I’m teaching DHCP, I usually refer to the old Nickelodeon show Dora the Explorer, because Dora is the way that I remember the four steps of DHCP. This client, it just came on the network. It wants to get IP address information. So the D in Dora is a Discover broadcast. We’re sending out a broadcast saying, hey, are there any D eight CP servers out there? And that’s going to go everywhere in the network, including the corporate DHCP server, who’s going to respond with the Oindora and offer, saying, yes, here’s my IP address, I’m a DHCP server.
And the client says, great, I would like to request IP address information from you. And it responds with the Aundora, the Acknowledgment, saying, Here you go, here is your IP address information. So again, do a Discover broadcast, and then the server or servers receiving that broadcast respond with the O, endora an offer, and the client is going to request information from whoever the first DHCP server was to respond. And then that DHCP server, through an Acknowledgment message, is going to say, here is your IP address information. But what we want to prevent is a rogue DHCP server from being added to the network, where a malicious user might have some of their own creative IP address information. They want to send our client to influence us to go to them as the default gateway or to go to them for DNS resolution. Here’s what could happen again.
We’ll pretend the DHCP client just got connected to the switch, and it sends out the Discover broadcast saying, are there any DHCP servers out there? And it goes to both servers. But let’s imagine the rogue DHCP server sends its offer message back first. It came in before the corporate DHCP server. So who is the client going to believe? It’s going to believe the rogue DHCP server, and it’s going to request IP address information from that rogue server. How do we protect ourselves against this? Well, if your switch supports it, we might have a feature called DHCP snooping. And that’s what it’s called on Cisco Catalyst switches. You may see a variety of names for that on different vendor switches.
But with DHCP snooping, we can say which ports are trusted and which ports are untrusted. And by trusted, we mean we will allow a DHCP offer message to come in this port. And if you’re untrusted, we will block any DHCP offer message coming into this port. And what we’ll normally do when setting this up is we will turn on DHCP snooping for all of our ports and we’ll make them untrusted ports. Then we’ll just go surgically insert a trusted setting for those individual ports, or maybe a single port that connects to our legitimate DHCP server resources. So let’s say that once again, the DHCP client is going to send out its Discover broadcast. It still goes to both servers. But now when the rogue server sends back its offer message, when it hits that untrusted port, it’s going to be dropped. It’s not going to be allowed to get back to the client. And therefore, the client is going to only believe the trusted corporate DHCP server.
And this is not just a good practice for security reasons. It’s a good practice in general. I’ll give you a true story. One time I was working with a company that was handling the Internet connection for a big tech convention. And there was a convention floor where a lot of vendors were going to come in, set up their booze, and demonstrate their products to people attending the convention. And again, I was working with a company that was providing Internet access to all of those vendors on that floor. So I’m there the night before. We’re getting everything set up. Our DHCP server is there. It’s handing out correct IP address information. We’ve got a rocking signal going out to the Internet. Everything was beautiful. However, I get there the next morning, there is chaos because we had many, many vendors that could not get out to the Internet.
And I thought, wow, this worked perfectly last night. What’s going on? And as I started visiting some of the different vendor booths and doing troubleshooting, I realized they had some very interesting IP addresses. IP addresses for subnets that we were not handing out. Where were they getting all this information? Well, as it turned out, when the vendors brought their equipment in that morning and connected to our network, they didn’t do this intentionally or maliciously, but some of the devices they connected, some of the servers they brought from their own office, they were DHCP servers. And they started responding with inappropriate IP address information for clients on that show floor. That was a pretty big disaster. So I had to just run around. I broke a sweat.
I was hard coding IP addresses into PCs all over the floor. It was a bad morning. But I could have prevented all that had I known about this feature, DTP Snooping. Because if I had known about this feature, I could have trusted the port connecting to our server and not trusted ports going out to any other device. So even though those vendors may have brought in their DHCP servers, that would have worked fine because we would not have accepted offer messages from them. And that’s a look at how we can secure dynamic Host configuration protocol DHCP using a feature called DHCP Snooping.
21. 14.20 IoT Security Concerns
Internet of things, or IoT devices let us do so many cool things in our home. For example, in my home, I’ve got a smart fridge, and if somebody leaves the door open too long, it tells me on my smart TV, we’ve got video cameras, we’ve got thermostats light bulbs come on and go off at certain times. I love IoT devices, but there are some serious security concerns with IoT devices. And the challenge is, many of these IoT devices were not designed with security in mind. That was not a primary design parameter. In fact, there are lots of video cameras around the internet right now that you can connect to without providing any credentials at all. That’s kind of frightening. And even if a manufacturer does include security with their device, it might be weak security, because a weaker encryption algorithm would take up less processing power on that device as compared to a stronger encryption algorithm.
And many users leave the default passwords on the device at the defaults. You don’t want your wireless router exposed to the internet with a username password combination of admin, admin that could be fairly easily found by someone scanning the internet. And we know that network security is a game of leapfrog. The manufacturer will come out with a release, and a vulnerability will later be found, and an exploit will be written to take advantage of that vulnerability. Then the manufacturer comes out with a patch, and another vulnerability is going to be found. It’s just a continual leapfrog cycle. And to better protect ourselves, we want to apply frequent patches and updates. But that might not happen automatically with IoT devices. Or even if automatic updates are applied, it might not be very often, and we could have a vulnerable piece of IoT gear exposed for quite some time.
Here’s a classic example. It happened in October 2016. It was called the Mariah malware cyber attack. And here’s what happened. There was a group of malicious hackers that scanned the internet for devices using default passwords, and they found a bunch of devices that they could infect. Primarily those were video cameras and home wireless routers. And once they were infected, those devices in people’s homes around the world, thousands of devices, they became a botnet of IoT devices. And the attackers could then talk to their command and control server, which would send out instructions to that botnet to attack a target, a victim. And in this case, one of the main victims was a major DNS provider that people would go to to resolve a DNS name like Twitter. com to a corresponding IP address. And a lot of sites were unreachable at certain locations around the world for quite some time.
In fact, twitter was offline for many people that day. So what can we do to better protect ourselves against the weaknesses of IoT? Well, for one thing, we can change our passwords from the default password to a strong password, and we should also probably place IoT devices on their own VLAN. If you have a wired device, you can plug it into an Ethernet switch that has that port configured to be in a separate VLAN than your production VLAN. It can still get out to the Internet, but it cannot get to the rest of your network. Or for your wireless IoT devices, you can set up another guest network that has a different address space than the rest of your wireless network. You want your IoT devices to go out to the Internet, but you may not want them to get to the rest of your network. And while IoT security is going to be an ongoing concern, at least here are a couple of steps we can take to better protect ourselves.
22. 14.21 Cloud Security
We’ve got lots of options when it comes to cloud providers. We could go with Amazon’s AWS, Microsoft Azure, we could go with Google Cloud and lots of other cloud providers as well. And an advantage of using a cloud provider is that we can have our compute resources living in the cloud. We don’t have to buy the gear and upgrade it and patch it. That’s the responsibility of the cloud provider. But the challenge is, how do we securely connect to that cloud provider? In this video, let’s take a look at a few options. Maybe we’re a single user working from home, maybe we’re mobile, or maybe we’re just sitting at our desk in the corporate office.
But one way we could securely access that cloud is via a browser connection. We could set up a TLS tunnel. That’s how browsers typically do security. And we would have an encrypted path to send traffic between ourselves and the cloud provider. But instead of making everybody fire up a TLS session and use a browser, if we had a building with multiple users, perhaps we could set up a VPN that would go between that building and the cloud provider going through the Internet. And in each of those cases, if somebody were to intercept our traffic, they would not be able to read it because it’s encrypted. If we want an even higher level of security, we may go with some sort of a private wayne connection, something very fast like Metro, Ethernet. Maybe we’re using a high speed NPLs cloud. But we could connect into our own dedicated servers colocated at the cloud provider site. So these are a few different ways that we could securely connect between a user or a building of users and the cloud provider. We can add an extra layer of security with what is called a CASB. A CASB is a cloud access security broker.
And CASB is software that’s going to sit between the users and the resources in the cloud. That software might be running at our local site, or that software might be running in the cloud and it’s going to monitor the traffic flowing between a user and the cloud. And it’s going to enforce any security policies that are in place. And as it’s monitoring that traffic, if it notices any malicious activity, it can jump generate an alert about that activity. And that’s a look at how to better secure our communication with our cloud provider.
23. 14.22 IT Risk Management
In our enterprise networks. We don’t want to be reactive when it comes to security. We want to be proactive. We want to come up with a collection of security policies and procedures and technologies that we put in place in advance. That way we’re going to be better prepared to handle some sort of a security issue that comes up in the future. That’s what It Risk management is all about. But this is not a one time thing. We don’t just set it and forget it. This is continually repeating process and in a design we could be very comprehensive.
We could throw a lot of money at the problem and we could have this very robust yet very expensive security solution. So we need to balance the needs of the organization, the sensitivity of the data with our budget. That’s what we’re doing with It risk management. And there are different models that describe It risk management. Here’s a five step model. And step number one is to identify attack targets. Here is where we determine locations in which we might be attacked. For example, perhaps we have a data center on site. So we might want to set up physical security for that data center. Or we might have data living in the cloud. In the second step, we rank our data here. We’re rating how sensitive, how valuable, or how private the information is.
For example, if we have personally identifiable information such as Social Security numbers, that type of data might warrant us spending more to secure as compared to a database containing pricing for our company’s products. Step number three is to determine risk levels. Here we can define a risk level for our data with the formula risk level equals the probability of being breached multiplied by the financial impact of that breach. If it does occur, for example, we might have that database of product pricing stored in a location that has a relatively high probability of being breached. However, the financial impact of that data, if it is breached, that’s very little.
So overall we’ve got a relatively low risk level. That’s as compared to a database of confidential employee information maybe stored in a location that has a moderate level, let’s say a 50% probability of being breached. That could represent a very high risk level. Step number four is to set risk tolerances. Here we’re combining the risk levels that we’ve calculated along with the resources that we have available. Financial resources, human resources, and we need to determine how much risk are we willing to tolerate. We need to decide what are we going to do, if anything, to protect specific data sets. We might decide not to spend any more protecting our product pricing database, but we might decide that the risk level for our employee database, we might say that’s currently not acceptable. And in response to that decision, we might put in an IPS and intrusion prevention system sensor. And finally, in step five, we want to monitor this. We’re going to be continually updating security measures based on newly discovered vulnerabilities and threats. And vulnerabilities and threats. Those are a couple of terms that CompTIA wants you to know for this exam. Let’s take a look at a few of those terms.
First up, let’s talk about threats and vulnerabilities. A vulnerability is a weakness within a system, but an exploit. Or we could call that a threat. That’s a method that somebody has developed to take advantage of that weakness. Next up is posture assessment. This involves limiting who can access our network. We’re going to say it’s not enough for a user just to provide correct credentials. They give a correct username and a password. That does not necessarily mean that they can get access to the network because the client that they’re using it might be vulnerable. So before we let them on the network, we could do a posture assessment to check things like the version of their antivirus software. We want to make sure it’s up to date. We might want to check the service pack on their Microsoft Windows operating system to make sure it’s a current version.
We want to make sure that different security patches have been applied. Next up is penetration testing. This involves hiring someone. They could be internal to our company. They could be external, but they’re going to be looking for vulnerabilities in our network before those vulnerabilities get discovered by an attacker. That way we’re able to identify and fix those issues before we’re attacked. And finally, let’s think about process and vendor assessment. You might want to take a hard look at your processes, looking for any weaknesses. You should also work with any vendors that you rely on and make sure that their systems and their procedures, they don’t have weaknesses that could put you at risk. And that’s a look at it. Risk management.
