Remote Access Part 1

Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *

Already have an account? Sign In »

4 hours 25 minutes
Video Transcription
hi and welcome to lessen 2 to 5 in this lesson, we're gonna talk about remote access. This is gonna be the last lesson we have on our perimeter layer controls. And after this, we'll get more into network layer controls
we talk about remote access. Were essentially just talking about how do we want to allow remote users access to internal resource is it could be because we have remote workforce that needs Teoh gain access to our corporate environment to do their work every day. It could be because we have, you know, traveling
workforce, whose from hotel to hotel and needs to get access. But either way, we're just talking about giving remote people access to that internal environment.
When we talk about that, one of the first things we need to discuss is what device do we want to allow to connect to our internal environment? Do we want to restrict access on Lee to control devices devices that we have full control over? Do we want to make it a little more convenient on let people access it from some personal devices?
We're gonna talk a little bit about revote, virtual private networks, or VP ends and what they are and how we can use them. Whenever we're giving people access to the remote, remote access to the environment,
we'll talk a little bit about multi factor authentication because passwords alone are not very secure. So talk a little bit about how we can add some additional factors to make it more difficult to break into the environment, which is especially important when we're talking about a remote access situation.
And then finally, we'll talk about mobile device management. If we do choose to give remote workforce access to our internal environment on mobile devices like smartphones, how can we manage that access?
Let's start with approved devices. One of the first things you have to discuss internally is what's gonna be the best balance between risk and reward in determining which devices you're going to allow to access your environment. We could go on the left side of the screen if we if we
Onley, allow people to access the environment remotely using a controlled computer. So you
come into the organization on day one year, issued a laptop. It's a company laptop that has all of the security controls in place. All of the monitoring in place and it's locked down. You can't make any changes to it. Well, that's much more secure than letting someone use their personal device. But the convenience is a lot less for in users. You know, if you've got
users who are traveling around,
maybe they have to now take two computers with them. They have to take one water on the network doing their job and then after work hours where they're still stuck in the hotel. They want to browse, however, do something else. They might have to take a whole separate device, their own personal device. So it's a convenience levels a little lower
on the flip side, if we allow people to use personal devices, I'm calling the control factor on this one medium. Because if we allow someone to use her personal device to connect to the internal network, there are things that we can do. We can make restrictions to say what you can only allow you can only connect to. The resource is
in this one controlled application on your personal device, so there's some control that we have there,
but at the end of the day, we don't own those devices, so we can't set all of the policies we can't force people toe run
all of the different software we needed to run. There's a whole lot of different things that are just outside of our control. But the convenience level is very high
because people can do their personal job, their personal work and their their work work on the same device. So there's no right or wrong answer here. Really, it's It's all about making a determination over what type of things people are going to access. How big is the risk and how much convenience do you want to give in users?
Every organization is gonna be a little bit different, and it's up to you to decide what's the best balance for your organization.
Let's have a little bit about VPNs or virtual private networks. When we talk about VPN, all of VPN is is a tunnel, if you will, it's ah, it's a way to transmit data, so if that's that's secure. So if we've got a
A device out there on the left hand side, it needs to go over the Internet. We got a remote worker needs to connect over the Internet to our corporate environment on the right.
Well, we all know there's a lot of bad stuff out there on the Internet, so all of VPN does. It establishes a a secure tunnel that then allows the traffic to pass through. Nothing from the outside can see inside this tunnel,
that's all. A VPN is a virtual private. Now it's an extension of your internal network out there in the wild somewhere,
there's a few different types of VPN is the sum of the VP and protocols will discuss. Here will be P p T. P, which is 0.2 point tunneling protocol L two tp, which is layer to tunneling protocol, an SS TP, which is secure socket tunneling protocol.
There are a couple of others, but these are the main three we're going to discuss here, and we'll tell you how each one of these works
and then you could make a determination which everyone is right for your environment
and start with P p. T. P. So point to point tunneling protocol, it's It's the original VP and protocol that was established back in the nineties. You know, there was a first determine that there was a need to actually encapsulate data over some sort of a secure transmission mechanism for this remote access type of situation.
It's not very secure. It's the least secure method of VPN now. It was fine when it was created, but it's very it's not very secure according to today standards. And we'll talk about why in a second.
One of the things about Pete P. P T. P that's unique is both sides use the same key, so VPN zehr just another mechanism of encryption. So we talked about encryption. Ah, few modules ago. Now we're talking about it in the form of a virtual private network,
but it's the same basic principles behind it. We talk about keys, keys, air used to encrypt and decrypt traffic.
In the case of P p. T. P, both sides have the same key.
So how does that work? So let's say we've got ah in point over there on the left. Let's say that's an external computer that needs toe communicate with some system. That's an internal system there on the right, but with P p. T. P. It's a tunneling protocol, so there's gonna be some sort of gateway mechanism that needs to be placed
between those two devices.
Um, the point point tunneling protocol actually terminates on gateway devices and not necessarily on the endpoints that are communicating with each other.
So the way that works is you would have some sort of a gateway device at the perimeter, and then you'd have another gateway device. Either in the form of software are a piece of hardware A to Custer at the inn users house or at the hotel with the end user.
Those two gateways have the same key configured in them. So when you think about a key, just think about it like a password looks just a long string of characters that has to be configured hard coated on both sides, and it has to be identical. And so what happens is when when a total needs to get established,
the Gateway's actually communicate with one another, and they say, Hey, I want to establish a tunnel.
The other one says, Okay, let's use our keys. They use their keys and in a tunnel is established. Once that tunnel is established, then the in point can transmit over that tunnel.
Now what's happening is the endpoint is actually transmitting to the gateway in just clear text. If it's if it's a clear text protocol, it's just regular raw traffic. And in the tunnel at the gateway is encapsulating that inside another inside a tunnel, if you will. It's getting tunnelled across to the other gateway
on the other side, that gateways de capsule, ating it or stripping the tunneling information off and then allowing the raw traffic to pass back to that
destination device.
In the case of L two TP, which is layer to tunneling protocol, it's gonna be a little bit more secure than pee pee tee pee because it doesn't use the same key on each side.
well, let me go back to this. Actually, I want to talk about why that's not secure. So if you think about people tp, it's convenient because you just have to have one key that you need to remember. But the gateway, the problem is the gateways on each side. That key's gonna live in two different places, so that's two places that that key could potentially be compromised in to physical places.
Oh, on top of that,
the administrators that configure those keys in the system. Human beings need to know what those keys are, so they have to configure those keys in the system. So now you've got the keys in two different places, and you've got human beings on both sides that know the keys. The more people that know the secrets, the more likely it is that secret gets compromised,
and all an attacker has to do is know what the key is. And they can decrypt anything going across that BP and tunnel
with L two tp, you're gonna have slower speeds because you're not using the same key on each side with P P T. P. The keys are already known. The tunnel could be negotiated, and that's the end of it. There's an extra step with L two TP because there's a key negotiation that takes place between the two gateways
before the tunnel is created. It's just an additional step before the actual tunnel gets created.
It's built on the ice I P SEC model that tunnels built on the I. P SEC model. There's a few different mechanisms for key negotiation and I p sec. We can use the public key encryption that PK I infrastructure like we talked about during the encryption session where each side has two keys. There's a public he in a private key and one public. He is used to unlock the private.
You know, the data that was are the private key is used to unlock data that was encrypted with the public key and vice versa.
It can use that model or I p second issues a list of keys and can negotiate between. But the thing that remember is there is a key negotiations step. It's not just hard coded, configured on each side with the same key.
So how does this look? L two tp we got same set up forgotten in user on the right, trying to connect to a system internally on the I'm sorry, in user on the left, trying to connect to a system internally on the right.
There are still gateways between the two because this is still a tunneling protocol and we're going toe. The gateways themselves are going to establish the tunnel.
So in this case, we have this two way communication between the two gateways and they negotiate which set of keys they're going to use once they negotiate that both sides have the keys. At that point, the tunnel can be created and again that negotiation could be in the form of the public key, the PK I infrastructure. It could be in the form of
a list of keys that each one has, and they just pick and choose which ones.
It could be in several different forms, but it's not predetermined. Which one is going to be used for each session or each tunnel?
Once the key negotiation happens, the tunnels establishing the communication works exactly like it does with tpp teepee, where the raw data is sent to the gateway. The gateway encapsulate. Sit inside, a tunnel goes across the other gateway de caps, elated and since they're all dated to the end point.
Up Next