Security Technologies.

In this section of the course,

we're going to talk about security technologies.

As a network technician

it is your job to ensure our network is secure

with the help of your organization cyber security team.

Usually as a network technician,

you're going to be the one configuring the devices

and implementing the security upgrades

that are required to keep your network secure.

So in this section, we're going to focus on

how to prevent bad things from happening to your networks,

but using different security technologies,

like firewalls, intrusion detection and prevention systems,

remote access, virtual private networks,

IPsec, and of course,

network logging and monitoring for intrusions

to best protect your networks.

We're going to be talking about four different domains

in this section of the course.

Domain one: networking fundamentals.

Domain two: network implementations.

Domain three: network operations,

and domain four: network security.

We're going to be discussing six different objectives

across these four domains.

This includes objective 1.5,

which states that you must be able

to explain common ports and protocols,

their application and encrypted alternatives.

Objective 2.1,

which states that you must be able to compare

and contrast various devices,

their features and their appropriate placements

on the network.

Objective 3.1,

which states that given a scenario,

you must use the appropriate statistics

and sensors to ensure network availability.

And objective 4.1,

which states that you must explain common security concepts.

Also, we'll talk about objective 4.3,

which states that given a scenario,

you must apply network hardening techniques.

And objective 4.4 states that you must compare

and contrast remote access methods

and security implications.

Now let's start talking

all about the different types of security technologies

and how you can best protect your networks.

One of the most common network security devices out there

is a firewall.

Now, we've talked about firewalls briefly up to this point,

but in this video, we're really going to dive deeper

into firewalls to really understand the type of firewalls

that are out there and how they operate.

Now, when we look at firewalls, they use a set of rules

to define the types of traffic that's going to be permitted

or denied through that device.

They basically act as a barrier to our networks,

these can be either software-based or hardware-based,

and they could be virtual or physical devices.

They can also be on the host or they can be on the network,

depending on if they're a host-based firewall

or a network-based firewall.

It really depends on your implementation,

but they're all going to work in pretty much the same way.

The other thing that a firewall can do for you,

especially a physical one that's sitting

at the edge of your network,

is to perform your Network Address Translation or NAT,

or if you're using Port Address Translation, PAT,

it can do that for you, too.

Now, that way, you can use one public IP

and many private IPs.

The first type of firewall we're going to talk about

is called a packet-filtering firewall.

These packet-filtering firewalls are going to permit

or deny traffic based on a packets header.

So, they have to access that packet and they have to look

at the header and look for the source or destination IP

and the source or destination port.

It's then going to to look at each of those packets individually

and make decisions whether to permit them or deny them

based on its access control list inside the firewall.

So, here on the screen, I have an access control list,

and this access control list has 100 deny ip any.

Now, what does that mean?

It means that any IP that is going to be denied

if it meets these rules, 100 is the line number,

deny as the action, ip is the protocol,

and any is the action against which it's going to take.

So, in this case, we have

an interface Fa one slash zero ip group 100 in,

and what's that saying is we're going to apply this

to any incoming traffic.

Now, in the case of this one,

if we have traffic coming in from the Internet,

like an HTTP reply, then it's going to get blocked

because nothing is allowed in

because we have a deny any statement here,

even though the request was able to go out

because that's outbound, anything coming back in

is going to be blocked because we have an inbound deny rule.

That's the bad thing about packet-filtering firewalls,

they work just based on the rule sets,

and so, if I have allow any going out,

but I would deny any coming in,

nothing's really going to work for us.

Now, this is because they're all based off the ACL,

and they're only based on the port or IP addresses.

In this case, we blocked any port on any IP

that's trying to make its way into our networks,

that wouldn't make it for a very effective firewall

if we want to be able to enable

any kind of two-way communications.

Now, the second type of firewall we have

is what's called a stateful firewall,

and they're going to inspect your traffic as part of a session.

So, let's take the example here on the screen.

If I'm sitting at PC1 and I make

an SSH connection out to the server on the Internet,

that is session one.

Now, the server can then reply to me with that SSH traffic

and the firewall is going to let it in, why?

Because I opened the firewall by making the request.

When I put the request out, it now expects a reply

to come back and it's going to forward that to me.

But if a second SSH server tried to come back

and create its own session,

the firewall is going to deny it,

that's because this firewall can keep track of the fact

that I made the initial request

and I'm only going to get an answer to my request,

anything else is going to be blocked.

Now, you could see how this is a lot more beneficial

than a packet-filtering firewall,

because it's going to go ahead and not just let anything

in or out, but it's going to keep track

of what's been requested and only let those things in.

With a packet-filtering firewall, I would have had

to let everything in for SSH or everything out,

it's either all or nothing.

But in this case, we can keep track of these sessions

and get a much more specific granularity of what's going to

be going on here and what's going to be allowed and denied.

This is what people are using when they're doing

a phishing attack to explore your networks,

because they know that most people

are using session-based firewalls,

and so, if I can send you an email and you click that link,

what you just did was request a session,

and that firewall is going to then open up the port

and letting that out

and let the reply back into your network,

and that's why they're trying to do that.

That is the bad thing about a stateful firewall.

If you have users who are doing the wrong things,

the firewall is going to let them through

because they're making those requests,

and since they requested it,

it's going to let the bad stuff come back in.

Now, we can combine the ACLs

and the permit and deny statements

of a packet-filtering firewall

with a stateful firewall's capabilities,

and this can give us a really good security device,

and most modern firewalls will support both of those things

and that's how they're going to work.

The next type of firewall we have

is known as a next-generation or next-gen firewall,

these are also abbreviated as NGFW.

Unlike stateful and stateless packet-filtering firewalls

that operate at layer four and below,

these third-generation firewalls can conduct

what's known as deep packet inspection or DPI.

This allows them to do full on packet-filtering.

They're going to operate in layers five, six, and seven

of the OSI model, where they can get

really in-depth information and understand

what those packets contain

and whether it's bad for our networks or not.

Now, these can also be referred

to as a web application firewall,

if they're specific to a web server

or more generally, they're just called next-gen firewalls.

If they're for your entire network, they're going to be

a great use to you, because they're going to inspect

all of the web traffic coming in and out

and really understand

what is going in and out of your network.

Then, they can dig in and choose to whether

allow it or deny it based on specific rule sets

that you give it.

When we talk about ACS or access control list,

what exactly are they?

Well, an ACL is simply a set of rules

that are typically assigned to a router interface

or a firewall and it's going to permit or deny certain traffic

based on its IP address, its MAC address,

or its port depending on what device you're dealing with.

If you're dealing with a switch,

it's going to be based off your MAC addresses.

If you're dealing with a router,

it's usually based off your IP addresses.

If you're dealing with a firewall,

it's going to based off your IP or your port.

Now, the ACLs are going to do this based on your source IP,

your destination IP, your source port,

your destination port, your source MAC,

or your destination MAC.

Now, you can choose any or all of these

to be the criteria you want based on your rule set.

So, here's an example on the screen,

I have three different access control list entries.

I have the first one,

which is going to permit or deny the first column.

Now, the protocol you're using, whether it's TCP or UDP,

is our second thing.

And the next column we have is our source IP,

and this can signify any or a specific IP

that we want or a range of IPs.

Then, we have a destination IP, and again,

this can be any IP, a specific client,

or an entire range depending on what you want.

Then, we have our destination port,

and then, we have things like WWW for port 80,

SSH for port 22, Telnet that for port 23,

you're getting the idea here, right?

We're going to be able to decide

what we're going to allow and what we're going to deny.

So, in our case, we have this group

on serial interface one slash zero

that's going to be allowed on the inbound direction.

We're going to apply these rules

which are going to permit port 80 web traffic to come in.

It's also going to permit SSH or port 22 to come in, as well,

but it's going to deny port 23

or Telnet traffic from coming in.

Now, this is the way you can deal with ACLs.

For your Network+ exam, you should be able to read

an ACL just like I did here on the screen,

but you don't need to come up with it by yourself

for the exam and be able to create your own ACLs.

Next, we have firewall zones.

All firewall interfaces are classified as a certain zone.

You can set up rules based on these zones

so that all the inside rules apply to these interfaces

and all the outside rules apply

to those interfaces over there.

Now, we have three zones we'd talk about,

we have inside, outside, and DMZ.

Now, inside is going to be your intranet,

it's your local area network.

It's connecting to your corporate local area network,

and anytime you talk about things outside of that,

you're going to be talking about things like the Internet

or external to your network.

Then, we have this other zone and it's known as the DMZ

or demilitarized zone.

It's going to connect devices

that should have some restricted access

from the outside zone, like web servers and email servers,

but they still aren't necessarily trusted

by your internal network.

It's kind of this in-between land,

between the trusted inside and the untrusted outside,

and it's really part of your network,

but it is segmented off as this demilitarized zone.

Now, what does this really look like?

Well, here's an example where I have three PCs

and a switch, and they're going to be able to tie

into this firewall and allow traffic

to go between certain zones.

Then, we have the DMZ,

where my email and my web server up at the top.

Then, I have this outside Internet zone over here.

Now, if I have the untrusted Internet,

am I going to allow traffic to go to my internal network

or my inside network?

Well, no, because I don't trust it.

The only way I'm going to do that

is if somebody has requested it,

like using a stateful firewall.

So, in general, we're going to block everything

going from the Internet to my internal zone.

Now, from my internal zone to my DMZ, again,

I don't really fully trust that DMZ,

so we're going to treat it like the Internet

from our internal network.

Now, if we request information from the email

or the web server, we'll get return traffic,

so that's going to be good for us.

But in general, we're going to block a lot of traffic

between those two zones.

Then, let's talk about the DMZ to the outside.

Well, the DMZ should always be able to go out

so they can request whatever they want

from the outside or from the Internet,

and we do have to allow certain things to come into the DMZ,

things like port 25 for sending an email

or port 110 for POP3, or port 143 for IMAP.

Those email type services need to be able

to have inbound traffic from the Internet

because that's what an email service is designed to do,

to serve those emails.

The same thing is true for the web server,

We're going to need to allow port 80 and port 443

for unsecured and secure web browsing

if we're going to host a web server,

because if we're running a web server,

people outside our network need to get to those web servers.

That's why the DMZ is considered

the semi-trusted zone, because people

from outside our networking reach in and touch the DMZ.

We wouldn't want them to reach and touch

our internal network, but we can get to those DMZ servers.

Now, we can really lock it down

and put a lot of protections in place, but we still have

to have some kind of open access to it because otherwise,

the email server and the web server

don't give us any functionality, right?

And so, that's the idea here with a DMZ,

it's a semi-trusted zone

between the inside and the outside network.

Now, the last type of device I want to mention here

is called a UTM or a unified threat management system.

Now, these have been getting a lot of popularity

in recent years, and this is a device

that's going to combine your firewall, your router,

your intrusion detection and intrusion prevention systems,

antimalware solutions you have, and other security devices,

all into a single device that's placed on your network.

This is generally considered a border device,

and it really is a next-generation next-generation firewall.

Now, there's an agent that's running your internal clients

and they can be queried by the UTM

before allowing any connection to the network.

They can also serve with a NAC or a network authentication

and network authorization function prior to allowing

any new devices onto your network, as well.

Now, these unified threat managers can be purchased

as a physical device to be installed in your networks

or there can be a virtualized device,

and there's even cloud solutions out there with UTMs, too.

If you're using a cloud solution, you'll just route

all your traffic to this cloud service provider

and they'll do all the security for you,

and then, they route your traffic out to the Internet,

because of this, UTMs are really expanding in popularity,

and you're going to see them more and more in networks

because they have this always on, always updated signatures

with the latest threat information

and the latest threat intelligence

that provides you additional security for your networks,

more so than a firewall alone could do for you.

In this demonstration, we're going to explore

a basic small office/home office network firewall.

In this example, I'm going to use a typical

router/switch access point combination device

manufactured by Netgear and marketed

as a wireless network N300 model.

Now, this is probably very similar

to what most of you are using in your small office

or home office environments.

Your interface and settings on your firewall

are going to look a little different than mine,

but it's still going to give you the same general idea

of what kind of options there are

and how you can configure one of these firewalls

at your network boundary.

On the screen, you can see the basic web-based access

for this wireless router/wireless access point

combination device.

On mine, I'm going to go to Security,

which is where the firewall is located

and it's under Blocked Services on this particular router.

Usually, most of these small office/home office routers

are going to have a very weak type firewall

and they hide it by calling it something else

instead of calling it a firewall,

so, it'll be called blocked sites, blocked services,

blocked ports, something of that nature.

In this case, it's blocked services

and I can do it based on a schedule,

so, I only want it to be certain times of the day or always.

Let's say I want to block something like Telnet.

I'm going to always block it, I'm going to add a block,

and the block I want to use is going to be a Service,

and go down to Telnet.

It automatically knows that Telnet is port 23,

so, it's going to block port 23 for me.

It's called Telnet because this is a predefined one

and then, I can block it for all IP addresses in this network

or only certain IP addresses or a certain range.

Maybe I want to block it for everything for Telnet.

That's fine, we can go ahead and add that to our list.

If we want to add something else,

let's say I have another rule.

In this case, I want to block port 666

because maybe there's a game

I don't want my kids playing on that,

so, I'll block it as port 666.

I'm going to make it TCP, UDP, or both,

I'm going to say both in this case,

and I'm just going to call it Game.

And then, I can block it for an IP range.

Maybe I don't want it be accessed by my kids

which all have their devices

in the 10.0.0.2 and the 10.0.0.10 range.

If I do that, I can go ahead and hit Add.

And, again, that adds another rule to the firewall

where we are blocking port 666 over that range of IPs.

You can see how this works as you

add or delete different rules.

Then, I can go through and I can do another one.

Let's say I want to block the

FTP server,

so, I will just go through here and say user defined

port 20 through port 21

because that is the connection port

and the data ports for FTP.

And then, we'll give it a name of FTP

and we can do it for all IP addresses in this range,

so nobody can access FTP servers.

That's the idea of how this firewall works.

In this case, it's blocking the outbound connections

because it's preventing us from sending things

out to the Internet.

If we want to block things from coming in from the Internet,

we're going to have to do that in a different firewall

on this particular device

because this one only has the outbound defined here.

It's going to have what things

as it's going out to the Internet.

Now, if I want to do this on inbound stuff,

I would have to go and find that

in this particular router.

That's usually going to be something like port forwarding

or port triggering or something like a static route.

In this case, I can port forward or port trigger

and say hey, if something's trying to come in

on port 21, FTP, it can go and be routed to my server,

which is at the .50, for instance.

So now, anything that comes in that's trying to get to

this router on port 21 is going to be forwarded

over to that IP address of .50.

That's how you allow things in to your network

based on this particular firewall.

How do you block things with the firewall?

Well, in this particular router,

everything is blocked by default

because it's doing an implicit deny,

so, anytime I add a rule, like FTP here,

that's doing an explicit allow.

Anything you don't allow is going to be blocked by default

on the inbound, based on this particular router.

In this video, I'm going to show you how to configure

the Windows firewall and the Mac firewall,

so whichever system you're using, you'll know how to do it.

Let's start with the Windows firewall.

We're going to use the Windows Defender Firewall

with Advanced Security.

To load this up, simply go down to your Windows key

or your start menu, scroll all the way down

to where you see Windows Administrative Tools,

and then, scroll down again, once you click on that,

and you will find the Windows Defender Firewall

with Advanced Security.

Once you click on that, it will open.

From here, you can create all of the policies you want,

setting up inbound rules, outbound rules,

monitoring it, et cetera.

Once you have it set just the way you like,

you can actually export that policy

so you'll have it as a back-up

any time you need to go back to it.

Right now, you can see my domain profile

shows Windows Defender Firewall is off.

My private profile shows that it's on,

and my public profile shows that it's on.

What this means is that in my private network

and my public network,

I do have the Windows firewall turned on.

In the private network I don't allow

any inbound connections that don't match my rules,

but I will allow outbound that don't match my rules.

In my public network, I have it set the exact same way.

Now, if I want to change that,

I can go into my inbound rules or my outbound rules,

and decide how I want that to be done.

Let's take a look at some of these rules.

For example, we have this one here, which is SSH,

which is Secure Shell.

All of my profiles allow it, it's enabled for all of them,

it will do an allow action,

and it's going to allow any program to be run

from any address locally to any address remotely

over port 22.

That may be what you want to do,

or it may be something you want to block.

Let's go ahead and look at some other ones.

Down here, we have App Installer.

For App Installer, it's allowing it to go

any local address to any remote address,

any protocol, and any port.

This type of an any/any rule

allows it to have a lot of ability,

and so, this is going to allow a lot of things through

that we might not want.

Now, let's say you have a program

that you want to add to this.

Maybe you have a new web server on this

and you're going to run it on port 80.

You can hit new, you can then select a program,

a port, a pre-defined, or a custom.

In this case if it's a web server,

we would want to do it based on port 80.

Then, we'll click on next.

Do we want it for TCP traffic or UDP traffic?

If it's a web server, again, it's TCP.

If it's something else that might use UDP,

you could set that up.

And then, what ports is that going to work for?

For all of your local ports, or specific ports?

Well, if it's a web server, it again should be port 80,

and for secure, port 443.

Then, we can go next, we can allow that connection,

we can allow the connection if it's secure,

meaning it has to use something like

a VPN tunnel with IPSec, or we can block the connection

and not allow any web traffic in.

In our case, we want to allow the connection.

Then, we click on next, and you can see

which of those three networks it's going to apply to.

I'm going to allow all three of them

to have it applied to it, and then I'll give it a rule.

Jason's Web Server.

And that's it, now you can see that Jason's Web Server

is now going to allow traffic from any program

from any local address and any remote address

over protocol TCP, and on port 80 and 443.

Now, conversely, if I want to block things from getting in,

we would do the exact same thing,

except we would set it up as a block or a deny.

For example, I don't want to allow anybody

to do Telnet into my network, because Telnet is unsecure.

So, I would set up a new rule,

and from there, I can block anything on port 23,

which is TCP traffic on port 23,

and then, I'll hit Next, I'll block that connection,

and I'll block it for all three of those networks,

and I'm going to say Blocking Telnet.

And that's it.

You could see how easy it is to set up these rules.

If somebody says I want to block TCP on port 23

or I want to block Telnet, then you should be able to say

I want to block it from this area,

and let it go to that area.

Now, one more area of the Windows firewall

that I want to show you is down here in Monitoring.

Down in Monitoring, you can see which profile is active

as I showed you before,

but you also have access to the log file,

and if you click on that,

you'll be able to see what's currently there.

What is being logged, right now is it logging drop packets

and successful connections?

Right now, it's not, but we can change that if we wanted to.

Now, we can also view our active rules.

This again brings us back to what those inbound rules are

and seeing which ones are actually active on this profile.

So, you'll notice, anything that's all or public

is being shown here.

Anything that was just private or domain is not

because they're not active for this particular connection.

Next, we're going to configure a firewall on a Mac machine.

To do that, simply go to the apple in the upper left corner

and go to System Preferences.

From here, you're going to click Security and Privacy

and then, you're going to click on the Firewall tab.

You can notice that my firewall is on,

but I can't click any of the firewall options right now.

That's because you have to unlock it by clicking the lock

and adding your username and password for the Admin account.

Once you do that, you can turn off your firewall,

or you can turn on your firewall,

and you can configure the options.

In here, you can block all incoming connections,

you can see what applications

have been allowed through the firewall.

In my case, Skype and Google Drive are allowed

to have connections into my computer.

And then, you can automatically allow built-in software,

meaning Apple software, to receive incoming connections,

things like iTunes and iMessage,

and you can automatically allow downloaded

signed software to receive incoming connections,

meaning this is software that you trust.

And finally, we have Stealth Mode.

What Stealth Mode does is it makes your firewall

not respond and not acknowledge any attempts

from somebody to ping your network.

So, if somebody is doing a ping sweep of your network,

my computer is simply not even going to answer,

so you won't know if it's up, down, or even there.

So, how do we add an application to this list

to allow incoming connections?

Well, Mac makes it fairly easy.

You click on the plus sign, you find the application,

for example, my Chess application, and then hit Add.

When you do that, it by default

is going to allow incoming connections.

Now, if I don't want that anymore, I can simply click on it

and subtract it, and it won't answer up.

As you can see, you don't have the level of fidelity

that you have on a Windows machine here in a Mac machine.

To get that level of fidelity, you'd have to use

the command line firewall tools that are provided,

such as PF or IPFW.

Intrusion detection and intrusion protection systems.

Now, in this lesson, we're going to talk

about IDSs and IPSs.

We've mentioned them briefly before

but now, we're going to dig into them.

Now, when we talk about IDS or intrusion detection system,

or IPS, an intrusion prevention system,

these can recognize network attacks.

And in the case of intrusion prevention system,

they can actually respond appropriately.

It's going to analyze all the incoming data

for any attacks it knows about using

different detection mechanisms

like a signature or behavioral-based model.

And we'll talk about more of those

as we go through this video, too.

Now, one of the most common ones is known as Snort.

S-N-O-R-T, which you can see here on the screen.

Snort is a software-based intrusion detection

and intrusion prevention system.

It is open source and it is widely used in the industry.

Now, when you're dealing

with intrusion detection system,

this is considered a passive device.

It's going to operate in parallel to your network,

and you can see it here in the diagram

hanging off just below the switch in this diagram.

Now, it's going to monitor all the traffic

going across the network and it's going to log in.

And it's going to alert any time it sees something

that it thinks is bad.

So, if it thinks it sees something bad,

like there might be an attack going on,

it might see something like a port scan

or denial of service attack,

or anything else that matches

its database to signatures,

then, it's going to alert the system administrator.

But because it's a detection system,

it's not going to respond.

All it's going to do is log in.

It might capture some packet data on it,

if you configured it to do that

and then, it's going to send the alert

to the administrator who's going to go ahead

and investigate it further.

Now, on the other hand, if you have it configured

as an intrusion prevention system,

this is considered an active device.

And so, it has to operate in-line.

Notice how it's now placed here

between the firewall and the switch,

so all the traffic from the attacker

and from the Internet

has to go through this device as it goes

through the router and the firewall into your network.

This way, by using this intrusion prevention system,

it can actually have all the data going through it

and it can stop and block any data

that it thinks is bad.

Now, again, this is going to be based off

of the signatures you have programmed.

It's going to monitor all the traffic,

send all the alerts, do all the logging,

do the packet capture,

all of the stuff like an IDS would.

But because it's a prevention system,

it can also drop or block offending traffic.

Therefore, it can actually stop an attack in progress.

Now, if you're worried about a denial of service attack,

an IPS is one of the best ways

to prevent this from happening.

Now, why would we use an IDS versus an IPS?

Cause it sounds like an IPS is awesome.

Well, one of the problems is that IPSs

and IDSs are not always tuned properly.

And so, if you have a false positive,

you can actually drop legitimate traffic

if you're using an IPS.

So, that's one of the reasons

why a lot of organizations operate

these detection systems in detection mode

and not prevention mode.

Speaking of detection, how can we detect different things?

Well, there are really three main methods.

We have signature-based detection,

policy-based detection, and anomaly-based detection.

When you're dealing with signature-based detection,

this is where a signature contains

a string of bytes that acts as a unique

fingerprint or some sort of a pattern

that's going to be triggering that detection.

Think of it like a signature

from malware or your hand signature.

I can look at it and say,

"Ah, I know this is John Smith's signature,

I've seen it before."

That's essentially what we're doing here

with the data flowing through the network.

Now, these signatures have to be created by yourself

or you can download them from a central repository.

Now, if you find a signature that matches something

that isn't threatening, but you have your device

in prevention mode, guess what?

That's going to cause issues for you

because it's going to block it.

And this again is why people tend

to lean towards an IDS instead of an IPS.

Next, we have policy-based detection.

And this is going to rely on a specific

declaration of a security policy.

You may say something like,

"No Telnet allowed."

and if we see anybody trying to talk on Port 23,

we know that's a policy issue

and we're going to flag it in the logs

and we're going to alert on it.

That's the idea of policy-based detection.

Now, the third one we have is an anomaly-based detection.

And this is either going to be done

through a statistical or non-statistical anomaly.

Now, if it's using a statistical anomaly,

it's going to watch for traffic patterns

and build a baseline up and then anytime it sees

something that thinks is outside the normal,

it's going to flag it.

Again, if you're using an IPS,

this can be very, very dangerous.

Because something that is completely normal

and routine that's just a little bit outside

the normal baseline could be flagged

and cause issues for your end users.

Now, when you use a non-statistical anomaly,

this is based on a pattern or baseline

that the administrator is going to define.

So, I might go in and configure and say,

"Hey, anytime I see more than some amount of downloads,

it's over a gigabyte per user per day,

I want you to flag that

because that might be something that's not right."

These are the kind of things

that we're going to set by the administrator

and they would then be a non-statistical anomaly.

In addition to having an intrusion detection system

and intrusion prevention system,

we could also have either host-based

or network-based IDSs and IPSs.

And this is another way we distinguish these systems.

When we're dealing with the network-based one,

we're talking about a network device

that's going to protect the entire network.

The diagrams I showed you earlier

were example of a network-based IDS and IPS,

were either hung off the switch

or it was between the switch and the firewall.

Now, if I wanted to have it as a software

installed on the host

like your Windows or your Mac machine,

this would be a piece of software

we install and it can serve

as an IDS or an IPS, as well.

Those are considered host-based

because it's sitting on a host or a server.

This would be your clients,

your servers, your phones, your tablets.

Now, these network and host-based systems

can be used together to give you even more protection.

For example, you might have a network

intrusion prevention system that's going to be used

in-line to protect you

from a denial of service attack.

But then, you might also have a host-based

intrusion prevention system on your Windows server

that can prevent people from installing

and running software that you don't authorize.

This is going to help protect you

from malware attacks and other things like that.

Now, what is all these look like

when you put it together?

Well, it looks kind of like this.

Notice here, I have two switches

hanging off that router.

I have my administrative and my management network.

And I also have my users who are sitting

there off to the left.

Now, in my user domain,

I have an intrusion detection system

that is network-based

and it's hanging off that switch.

Then, I have an intrusion prevention system

sitting between the firewall and the router

to protect myself from denial of service attacks.

Then, I might have a DMZ,

and I might need another IPS there

that's going to be set between the switch

and the firewall and that's going to protect

my web servers and my email servers.

In addition to all that network-based defenses,

I can actually install software

on PC1, PC2, and PC3 that acts

as a host IDS or a host IPS.

Now, all of that is going to be connected

back up to the management PC up in the top,

which is going to take and correlate

all of these logs and alerts

and that way, I can investigate them as I see them.

You could see how all of this starts

working together giving us layers of security

and a lot more additional security.

Remote access, in this lesson,

we're going to discuss a lot of the different types

of remote access options

that you may be supporting as a network technician

or network administrator.

These different methods will allow a client

to access a server or a network device

remotely over your network.

Now, as an administrator,

you're going to be using some of these methods

to reach into the command line interface of your routers,

your switches, and your firewalls as well.

In order for you to be able to modify their settings

and configurations as part of your job functions.

Now, there are many ways to access this data remotely,

and you can also control these devices remotely as well.

Many of these, we may have already covered before

in different videos in the course,

but in this lesson, I want to provide you

with a quick recap or summary.

So you have them all covered in one place.

And that way, you can use it as a great review

before you take the exam.

So in this lesson, we're going to discuss Telnet,

SSH, RDP, RDG, VPN, VNC,

VDI, in band versus out-of-band management

and some authentication and authorization considerations.

Now, the first thing we need to talk about

with remote access technology is Telnet.

Now Telnet operates on port 23 and Telnet

is used to send text-based commands to remote devices.

And it's considered a very old networking protocol.

Everything you do in Telnet is going to be text-based

and here, you can see that I'm connecting over Telnet

to rainmaker.weather.underground.com.

By doing this, I can then look up

the daily weather for my area.

Now, one of the biggest drawbacks to using Telnet

is that it sends everything over the network

in plain text or un-encrypted formats.

Now, in this case, I really don't care

that I'm sending things in plain text

because the only information I have to send

to the server is the three digit airport code

for the city that I want to check the weather within.

But if I'm going to send something private,

like my social security number or my password

or my credit card number, then I would never,

ever want to use Telnet for that.

Remember, Telnet should never,

never not ever be used for anything

when you're connecting to one of your secure devices,

anything like a router or a switch or a firewall,

because when you're configuring them,

everything will be sent in plain text,

including your commands, your username, your passwords,

your access control lists, and all of that stuff.

Instead, we always want to use an encrypted

text-based remote access technology,

something like Secure Shell.

This brings us to our second remote access technology,

which is Secure Shell.

Now Secure Shell or SSH is going to operate over port 22.

Secure Shell is also known as SSH,

and it works just like Telnet,

but it's going to encrypt everything that's being sent

received between the client and the server, the router,

or the switch that you're communicating with.

Therefore, you're going to have much better security

when you're using SSH

than when you're using Telnet.

Remember, anytime you need to connect

to a networking device to configure it

in the command line interface,

you should always be doing this over SSH,

using Secure Shell.

This will ensure you have an encrypted connection

to that device.

The third remote access technology we need to discuss

is known as RDP or the desktop protocol.

Now the remote desktop protocol

operates over port 3389

and it's a proprietary protocol developed by Microsoft,

which provides users with a graphical interface

to connect to another computer over a network connection.

While RDP is not really useful

if you're trying to talk to a router,

a switch or a firewall, it is really useful

when you're trying to remotely access

and control a windows server or client machine.

For example, if your SIEM or network management system

operates on a windows machine,

you can RDP into it as a way to connect to it

over your local area network.

RDP is going to provide you with a graphical user interface

known as a gui or GUI.

This allows you to access a server and desktop

and control it using your mouse and keyboard.

Now, when you're remotely connected this machine,

it's going to act just as if you were sitting in front of it,

but you can do it from across the network

or across the world.

For example here,

you can see there are three devices

and they're all connecting to a windows seven machine.

You have a Macintosh laptop,

you have an iPad or an Android tablet,

and you have a cell phone.

And all of these are able to reach in

and do the communication using RDP,

just as if I had a mouse and keyboard

sitting right in front of that workstation.

RDP is going to allow you to connect to these devices

from across your network or across the world,

depending on how you have it configured.

Now the remote desktop protocol itself

is not considered to be a secure protocol.

Instead, you need to secure that connection

by using something else to tunnel it over.

For example, you can use a remote desktop gateway or RDG

to create a secure connection

between you and that gateway

and then tunnel into the RDP session.

Or you can use a VPN, like a virtual private network.

Now our fourth remote access technology we need to discuss

is the RDG or the remote desktop gateway.

Now a remote desktop gateway is a window server

that's going to have the role of creating a secure connection

using either SSL or TLS protocols to a server via RDP.

So if you're using an RDG to secure RDP client,

this will allow you to create

those secure server connections.

This way, you wouldn't have to run a VPN

to create an encrypted tunnel,

because RDG is already going to create

that encrypted tunnel using SSL or TLS protocols.

A remote desktop gateway provides several security features

for you in terms of securing RDP connections.

This includes things like creating encrypted tunnels,

like a VPN would, controlling access to network resources

based on permissions and group roles,

maintaining and enforcing authorization policies

and monitoring the status of the gateway

and any RDP connections passing through that gateway.

If you're running a windows server 2008 or newer,

you definitely should be using this RDG

or remote desktop gateway

to better protect your RDP connections.

Now the fifth remote access technology we need to talk about

is VPNs or virtual private networks.

A VPN is used to establish a secure connection

between a client and a server

over an untrusted public network like the internet.

If you're going to use RDP over the internet,

you first need to make sure you create

a VPN connection to create a secure tunnel,

and then run that RDP session over that VPN connection.

We're going talk more about VPNs and their own lesson,

including the three different types of VPNs

and how to establish and maintain

these secure connections over an untrusted network

like the internet.

The sixth remote access technology we need to discuss

is VNC or virtual network computing.

VNC operates over port 5900.

It was originally designed for thin client architectures

and things like virtual desktop infrastructure or VDI.

VNC operates a lot like RDP, but unlike RDP,

which only operates on Windows clients and servers,

VNC is truly cross-platform and it can be used

on Linux OSX or windows, clients and servers.

Our seventh remote access technology

to discuss is virtual desktop infrastructure or VDI,

which I just mentioned that we use

that with VNC a lot of times.

Now virtual desktop infrastructure

is used to host a desktop environment

on a centralized server.

VDI is a form of desktop virtualization

and allows a specific desktop image

to be run within a virtual machine

and delivered to an end user over a network.

In Cloud computing, we call this

desktop as a service or DAS.

Now when you're using VDI, you can access it

through a virtual desktop either by using a web browser

on a regular desktop or laptop,

or you can use a specialized thin client device

that uses a PXE network boot image

to load up a specialized client

that can connect to that centralized server

and provide access to the virtual desktop.

Our eighth remote access technology or concept

that we need to talk about is known as in-band

versus out-of-band management.

Now, inbound management refers to managing devices

through the use of Telnet or SSH protocols over the network.

For example, if you're going to be using

a workstation on your local area network

to configure your land routers,

you can connect to those using SSH

by simply connecting to the gateway over port 22,

this would be considered an in-band management

because you're using the same network

that you're configuring.

Now out of band management on the other hand,

is used when you have an alternate path

or alternate management network

to connect to the different network devices

for configuring them.

This is considered a best practice in security.

For example, in the last large scale enterprise network

I worked on, we had a production network

with the users we're connected to,

and everyone's workstations were there

to be able to do their work on a daily basis

and they can access our servers and the internet.

From this network, you couldn't connect to the routers

and switches in order to configure them though.

Instead, we had a separate network

called a management network,

which was an out-of-band network.

This was a more secure network

and it was limited in its functions.

If I need to configure the routers or switches,

I would connect to the out-of-band network.

And then I could talk to those routers

and switches and configure them.

Another out-of-band management connection

would be if you had a laptop and you directly connected

to the switch or router

using a serial connection or a console port.

Now this direct connection is going to be establishment

you need to configure the router or switch.

And when you're done doing that configuration,

you'd unplug it and disconnect it.

This is a truly out-of-band solution.

Now the goal with using an out-of-band solution

is to prevent a regular users machine

from being able to connect to the management interfaces

of your devices.

This way, if a user's computer is taken over by an attacker,

they would then be unable to cause large-scale havoc

across your network.

Now, by using an out-of-band network,

you can provide separation of data

between your production networks

and your management networks,

which gives you additional layers of security.

Now out of networks do require additional configuration

and equipment to implement though.

if you want to be able to have a management network

and a user network, you're going to need two sets of routers

and two sets of switches.

And all of that starts to get very expensive over time.

Now it is considered a best practice,

especially in large scale networks,

where you can't physically walk to every single switch

or router that you want to reconfigure.

So in those cases, you definitely need

to have a management network.

Finally, we need to discuss some authentication

and authorization considerations

when dealing with these remote access technologies.

When we're talking about authentication,

we're referring to how a system will confirm

that a user is who they say they are.

Essentially, how are we going to validate their identity?

Now, when we're talking about authorization,

we're referring to how a system will give the user

the proper permissions

to access a particular resource on the network.

Now there are lots of different ways

to do remote access authentication,

including PAP, CHAP, MS-CHAP and EAP,

pap or PAP is the password authentication protocol.

And it's a really old protocol that was never built

with security in mind.

In fact, when PAP is used,

it's going to send the username and passwords

for authentication in the clear, just like Telnet does.

This makes PAP an insecure choice for any modern network

and you simply should never use it

in today's modern networks.

You see, pap worked by having the clients

send the username and password

in the clear over the network,

then the server would send an authentication acknowledgement

if the credentials matched what they expected to receive,

or they would get an authentication NEC

or a non acknowledgement if the credentials were incorrect.

So why am I even mentioning PAP

if we never use it these days?

Well, because after PAP came CHAP,

which was an evolution to PAP,

and it helps to understand PAP

before you start talking about CHAP.

Now, CHAP is considered the challenge,

handshake authentication protocol, CHAP.

And it's an improvement over PAP that attempted to solve

this problem with sending our credentials

over the network in plain text.

With CHAP, the server sends the client

a string of random texts called a challenge.

This random text is then encrypted by the client

using their password.

And then they send that encrypted message

back to the server.

The server will then unencrypt

the text received from the client

using the stored password on that server.

And if those things match,

that means that that client really did have the password.

And so it's a match and they would be authenticated.

Now by using this method,

the passwords never actually send across the network.

Only this encrypted text.

This allows us to positively identify the user

using authentication while maintaining security.

Now CHAP and MS CHAP were used for many, many years.

And both of these though have been overtaken

by a newer protocol known as EAP,

the extensible authentication protocol.

Now the extensible authentication protocol

or EAP allows for more secure authentication methods

to be used instead of just using a username and password.

With EAP, we can use a username and password,

or we can use things like smart cards,

Kerberos and digital certificates.

In modern remote access implementations,

you should be using EAP TLS for your authentication

in conjunction with a RADIUS or TACACS+ server.

Virtual private networks or VPNs.

In this lesson,

we're going to dive deeper into VPNs

known as virtual private networks.

And we're going to cover all the things you need to know

about a VPN for your exam.

First, what is a VPN?

Well, a VPN is a virtual private network,

and it's going to be used to extend a private network

across a public network

and enable users to send and receive data

across that shared or public network

as if their computing devices were directly connected

to the private network.

Now with a VPN,

your users can work in a remote office or work from home

and they can telecommute

simply by logging into their laptop and establishing

a secure VPN tunnel to the organization's network,

regardless of where it sits in the world.

To do this,

they're going to connect to a VPN device

sitting at the headquarters data center,

and then they're going to establish a secure tunnel

using a VPN protocol in order to allow a secure connection

for that corporate user over an untrusted or public network,

something like the internet.

Now, this allows them to then reach

into the corporate network

and be connected to the internet

as if they were sitting right at their desk in their office.

VPNs can be configured as a site to site VPN,

a client to site VPN,

or a clientless VPN.

With a site to site VPN,

we can connect two offices together.

With a client to site VPN,

we're more concerned with connecting a single remote user

back to a corporate network as I described earlier

with the user who needed to telecommute.

When we talk about a clientless VPN,

these are usually going to be used with web browsing.

All right. Let's dive a little bit deeper

and talk about a site to site VPN.

Now, a site to site VPN is used to interconnect to sites

and provide an inexpensive alternative

to dedicated lease lines.

For example,

let's pretend I have a branch office in California

and my headquarters is in Washington DC.

Now, if I want to be able to connect

my remote regional office in California,

to my headquarters office in Washington DC,

I could buy a dedicated lease line

from a telecommunications provider

and they would give me a direct connection

that covers over 3000 miles in distance

between these two sites.

Even if I got a low speed T1 connection,

this would be very expensive.

Now, on the other hand,

I could use a site to site VPN and I can save

a lot of money.

Instead of using that dedicated lease line,

I could simply create a VPN tunnel from the regional office

back to the headquarters over the public internet,

using the internet connectivity

that's already in that office.

This solution might cost me 50 or $100 per month

for a standard cable modem or a fiber modem service

from the local ISP.

Once that VPN tunnel is established,

it's going to take all the traffic

from the regional office in California

and run it back to the headquarters in Washington DC,

over the internet within this secure tunnel.

And then, once it gets to Washington DC,

it's going to be decrypted and put back

inside of my corporate network.

Now, when a California user

wants to go to Google.com, for instance,

that data is going to go from California to Washington DC,

out the Washington DC's office internet connection

to visit that website,

get the information,

send it back

to the Washington DC's office internet connection,

and then back through the VPN to that California user,

where they'll be able to view the website they requested.

By using this site to site VPN,

all the traffic that goes back and forth

between California and Washington,

is going to be encrypted and secure.

So no one can see the internal network traffic

that's going

through this external public internet connection.

Now, when we deal with a client to site VPN

on the other hand,

we're going to be seeing data from a single host,

like a laptop or cell phone or smartphone or tablet,

and connecting it back to our headquarters office.

This is going to be done instead of going

from router to router,

we're going from client to router.

This allows a remote user to be able to connect

back to the head office.

And that's why we call it a client to site.

Now, in addition to site to site and client to site VPNs,

we also have to decide whether or not,

we're going to use a full tunnel

or a split tunnel VPN configuration.

Both full tunnel and split tunnel VPNs

can be used with either a site to site

or client to site model.

Now, a full tunnel VPN is usually used by default

in most organizations.

And it's what I described earlier.

With a full tunnel VPN,

we're going to route and encrypt all the traffic requests

through the VPN connection, back to the headquarters,

regardless of where the destination

of that service is located.

This is considered more secure,

but when we're connected using a full tunnel,

the clients are considered

to be fully part of the headquarters network

when they're connected.

This means if you're trying to access a local area resource

like a wireless printer in your home office,

you're not going to be able to do that

because that wireless printer in your home office,

is not connected to the headquarters network,

like your laptop is, over that client to site VPN.

Conversely though,

you can still print to the printers

in the headquarters office,

even if you're connected using a full tunnel VPN,

because you could be sitting in a hotel room

halfway around the world,

but logically, you're still sitting in your office

at the corporate headquarters.

Now, a split tunnel VPN on the other hand

is going to divide your traffic and network requests

and then route them to the appropriate connection

or network.

With a split tunnel VPN,

we're going to route and encrypt the traffic

bound for the headquarters over the VPN,

and we're going to send all the other traffic

out the regular internet.

So, let's pretend that I'm using a client to site VPN

on my laptop with a split tunnel configuration

from my home office.

The VPN here is going to decide which traffic

goes back over the VPN

and gets sent over to the headquarters

and what traffic goes over the internet.

So, if I'm trying to access a file server

or a Microsoft exchange mail server,

that's back on the headquarters network,

those packets will get encrypted

and write it over the VPN to the headquarters.

But, if I need to attend a Zoom conference

or access Office 365 or traffic outbound for the internet,

I'm simply going to bypass that encrypted VPN connection

and go directly out my internet connection

to those public websites.

Now, this is why we call it a split tunnel

because we have an encrypted VPN tunnel

for traffic that needs to go to the headquarters

and another un-encrypted tunnel

that takes a direct path out to the internet from your ISP.

The challenge when using a split tunnel,

is that they can be less secure

because there is a possibility

that an attacker could connect to your device

over that un-encrypted internet tunnel,

and then they could pivot through your laptop

and send out over the VPN back to the headquarters network.

For this reason,

if you're connecting the VPN over an untrusted network,

like Wi-Fi at a hotel or a coffee shop,

you should never use a split tunnel.

And instead, you should be using a full tunnel.

Now, a split tunnel does give you better performance

because it's going to route all your internet based traffic

directly to those servers

and bypass the entire company headquarters network.

So, as you see,

it becomes a trade off between security and performance.

If you want more security,

use a full tunnel VPN.

If you want better performance, use a split tunnel VPN.

So, at this point we've talked about two main types of VPNs,

a site to site VPN and a client to site VPN.

But, there is one more type of VPN that we need to discuss.

And it's known as a clientless VPN.

Now, a clientless VPN is used

to create a secure remote access VPN tunnel

using a web browser without requiring any software

or hardware clients to be used.

In fact, using this type of VPN,

is something you do every day

without even knowing it.

A clientless VPN is used by your web browser

when it makes a secure connection to an e-commerce

or other secure website using HTTPS.

This can be done using an SSL or TLS tunnel

by using those protocols.

Now, SSL or the Secure Socket Layer,

is going to provide cryptography and reliability

using the upper layers of the OSI model,

specifically, layers five, six and seven.

In recent years,

SSL has become a bit outdated and less secure.

So, most clientless VPNs are now using TLS,

which is Transport Layer Security,

to provide secure web browsing over HTTPS.

So, when you logged into this website to watch this video,

you had to enter your username and password,

and you saw that little green padlock

in the upper left corner of the address bar.

That's how you knew you had a secure connection using HTTPS.

That means you're using either SSL or TLS

to create that secure clientless VPN tunnel

from your web browser in your computer to my servers,

so you can pull these videos.

Now, SSL and TLS,

both use TCP to establish their secure connections

between a client and a server.

But, this can slow down your connection

because TCP has a lot more overhead

than a UDP connection does.

So, if you want,

you can instead opt to use DTLS

or the Datagram Transport Layer Security,

which is essentially a UDP based version

of the TLS protocol.

This provides the same level of security as TLS,

but it does operate a bit faster

because there's less overhead inside the UDP protocol.

Now, DTLS is an excellent choice to use

when you're wanting to do things like video streaming

and things like Voice over IP

over secure and encrypted tunnels.

This provides the end-user with security over UDP

and prevents eavesdropping, tampering and message forgery

inside that clientless VPN connection.

Now, there are a few older VPN protocols

you need to be aware of as well.

This includes things like L2TP, L2F and PPTP.

L2TP is the Layer 2 Tunneling Protocol.

L2TP was a very early VPN.

It was invented all the way back in the 80s and 90s.

Unfortunately,

L2TP lacks security features like encryption by default.

So, if you're going to use L2TP,

you have to combine it with another protocol

to provide encryption for your VPN tunnel

when you're using L2TP.

Even though it's an older protocol,

it's still used by a lot of modern networks

by combining it with that extra encryption layer

for protection.

L2F or Layer 2 Forwarding is a VPN protocol

that was originally developed by Cisco

to provide a tunneling protocol

for the point to point protocol or PPP.

Unfortunately, it also lacks the native security

and encryption features

just like the Layer 2 Tunneling Protocol.

For this reason,

LTF has lost most of its popularity,

and it's not used in most modern networks.

PPTP or the Point-to-Point Tunneling Protocol

is an older version of the VPN protocol as well.

And it was used for dial up networks.

PPTP also lacks the native security features,

but Microsoft Windows has added security features

to their implementation of PPTP.

Therefore, if you're using a VPN through Windows with PPTP,

you can still consider this to be pretty secure.

All these VPN types can still be used today.

It's just a matter of how secure

you need your implementation to be,

and if you need to add an additional layer of encryption,

provide a more secure tunnel.

But in most modern VPNs,

you're going to see overwhelmingly that IPsec

or IP Security is being used.

Now, IPsec is used in virtual private networks

to provide authentication and encryption of packets

to create a secure encrypted communication path

between two computers

over an internet protocol based network.

We're going to talk more about IPsec in a separate lesson,

because there's a lot to cover in terms of IPsec

and how it operates.

For now, remember there are three main types of VPNs,

site to site, client to site,

and clientless.

Also, remember there are two methods of communication

using a VPN.

You can use full tunnel or split tunnel.

Finally, remember there are several VPN protocols

you can use to establish those VPNs.

You can use the L2TP,

L2F,

PPTP

and IPsec.

IPSec or IP Security.

In this lesson, we're going to talk all about IPSec.

Now, IPSec is a secure network protocol suite

that provides authentication and encryption of data packets

to create a secure encrypted communication path

between two computers over internet protocol network.

IPSec is the most popular protocol in use today

for the creation operation of VPNs

or virtual private networks.

IPSec provides confidentiality, integrity,

authentication, and anti-replay

when using a VPN connection

for both site-to-site and client-to-site VPNs.

IPSec provides confidentiality by using data encryption.

It's also going to provide integrity

by ensuring that data was not modified in transit

by checking that it's hashed before transmission

and upon receipt, match.

Authentication is going to be provided

by having each party verify

that they are who they claim to be.

And IPSec is also going to provide you

with anti-replay by checking the sequence numbers

on all the packets prior to transmission.

This prevents the transmission of duplicate packets,

and it prevents an attacker from being able to capture

and resend packets later as part of an attack.

Before we go too deep into IPSec,

let's take a big picture view of how IPSec works.

There are five main steps in the process

of establishing and using a secure VPN tunnel

when you're using IPSec.

First, there is a request to start a key exchange.

Second, IKE Phase one is going to authenticate the parties

and establish a secure channel for negotiation.

Third, IKE Phase two is going to negotiate

the security association parameters

and fully establish the secure tunnel.

Fourth, we're going to have data transfer,

and this is going to allow data transfer

between the two parties over the secure tunnel to occur

using the IPSec parameters and keys

stored from the security associations

that were negotiated back in step three.

Fifth, IPSec tunnel termination is going to occur.

And this happens when the security associations

are terminated through either mutual agreement

and deletion or due to timing out of the tunnel

due to one party becoming non-responsive.

All right, those are our five main steps,

but it's important for us to fully understand

how all of this works in our networks

so that we can better troubleshoot these IPSec tunnels

if we ever have a problem with their not working properly.

Now, the first step is pretty self-explanatory here.

We need to request to start a key exchange.

This can be done by your devices automatically

if you're using a site-to-site VPN,

or it can be initiated by a software client

on your laptop, if you're going to be using

a client-to-site method.

Either way, the request to initiate a VPN connection

is going to occur, and then we can move to our second step,

the IKE Phase one.

Now, during IKE Phase one,

the IPSec peers have their identities authenticated

and encrypted for protection.

Then there's going to be a negotiation that occurs

to create a matching IKE SA

or internet key exchange security association

between the two IPSec peers

to protect the key exchange that's about to occur.

Next, the IPSec peers are going to perform

an authenticated Diffie-Hellman key exchange

so that both IPSec peers

will have a copy of the same shared secret key,

and that way they can use that to establish

and secure an IKE Phase two tunnel.

The internet key exchange or IKE Phase one

can use one of two modes to conduct this process.

We can use either main mode or aggressive mode.

Now, when we're using main mode,

it's going to conduct three 2-way exchanges

between the peers.

This goes from the initiator to the receiver.

Now, the first exchange between the IPSec peers

is to agree upon which algorithms and hashes

are going to be used to secure the IKE communications

throughout this process.

The second exchange that they're going to do

is going to be between the peers,

using a Diffie-Hellman key exchange

to generate the shared secret key material

that's going to be used to create

these shared secret keys

that we can then send to the other party

by sending assigned random number,

and that way the two parties

can prove their identities.

Then we're going to have a third exchange

between the IPSec peers.

And this occurs where each side can verify

the identity of the other side

by looking at encrypted form

of the other peer's IP address.

Now, by the time these three exchanges are finished,

both peers have received matching IKE security associations

or IKE SAs.

These can now be used for ISAKMP exchanges

between the IPSec peers

moving forward throughout the rest of the process.

These security associations are going to contain

the authentication methods used by the peers,

the encryption and hash algorithms used,

the Diffie-Hellman groups used,

the expiration of the IKE SA,

and the shared secret values for the encryption algorithms.

Basically these IKE SAs have everything

that both peers need in order to make and maintain

their IPSec tunnels.

Now, the second mode you can use

is known as aggressive mode,

and this has fewer exchanges than the main mode.

So instead of having three,

we're going to have less.

This results in fewer packets

and a faster initial connection

than using main mode.

Now, in aggressive mode, almost everything needed

for the proposed security associations

is going to be sent by the initiator at first.

This includes the Diffie-Hellman public key,

the signed random number, and an identity packet.

Then it's going to be received

and the receiver is going to send everything back at once.

So the initiator only needs to confirm the exchange

to finish the association.

This is why it's considered more aggressive

because one side is saying,

"Here's all the things I want to use,"

and the second side can say,

"Okay, I'll go along with that."

Now, this is concerned less secure than main mode,

but again, it's a lot faster than using main mode

'cause we don't have to go through these three passes

and three exchanges.

Now, once you have the IKE security associations

and they've been received

by either using main mode or aggressive mode,

we can move into step three of our process.

This is the IKE Phase two portion

of our tunnel establishment.

Now the purpose of IKE Phase two is to negotiate

IPSec security associations

to set up the IPSec tunnel.

IKE Phase two is used to negotiate

the IPSec security association parameters

that are protected by the existing IKE SA

that we created in phase one.

This allows us to establish IPSec security associations

to periodically renegotiate security associations we need,

to maintain that security, and to perform

additional Diffie-Hellman key exchanges

if we need to.

During IKE Phase two,

we can accomplish this by using quick mode.

Now, quick mode can only occur after IKE

has already been estabished

in that secure tunnel during Phase one,

using either main or aggressive modes.

Using quick mode,

we can negotiate a shared IPSec policy,

and we can also drive shared secret key materials

using the IPSec security algorithms.

And then we can use that to establish

our IPSec SAs.

Now as discussed in phase one,

each essay has a limited lifespan

and it will then expire.

Now with quick mode,

we can negotiate a replacement SA

before the expiration occurs.

And this lets us maintain that VPN tunnel

for longer periods of time

without worrying that the attacker

could crack our security associations

and enter that tunnel.

Now, the fourth step of this process

is to conduct our data transfer

with those newly established encrypted IPSec tunnels.

This is done by using IPSec SAs

that were created in IKE Phase two.

Now, these packets are going to be encrypted by the sender,

and they're going to be decrypted by the receiver,

and this makes sure everything is kept

confidential and secure.

Now, our fifth and final step of this process

is to terminate the tunnel.

This occurs whenever the IPSec SAs

are deleted by mutual agreement by both peers,

or if the SAs reach their lifetime expiration

and simply time out without being replaced.

When this happens, we need to go and create

a new phase one and phase two key exchange

if we want to re-establish that tunnel

and conduct more data transfers.

Now, you may or may not understand

the basics of asymmetric cryptography yet,

so let me take a quick detour

and explain how this whole key exchange thing works.

You may have noticed I kept saying the words

Diffie-Hellman.

I kept talking about a Diffie-Hellman exchange.

Well, Diffie and Hellman are basically names

of two computer scientists who came up

with this really brilliant way

for two systems that don't know each other

to be able to exchange a secret key and trust each other.

This process is known as the Diffie-Hellman key exchange

named after them.

So at IKE Phase one, there's an initial tunnel

created between the two peers.

And they're going to begin to exchange some information

to create those IKE SAs or security associations,

and then authenticate each other.

Now, in a Diffie-Hellman key exchange,

the two clients, in this case PC1 and PC2,

are going to create their own private key.

And I'm labeling this PRI for private.

From that key, they can use a mathematical algorithm

to calculate a corresponding public key,

and then they can hand that public key

to the other PC to create a key exchange.

Now, PC2 has a private key called PC2 PRI,

and they have a public key for PC1 called PC1 PUB.

PC1 has its private key, PC1 PRI,

and a public key for PC2 called PC2 PUB.

Now at this point,

each side is going to calculate a shared secret

using the Diffie-Hellman protocol.

By using their private key

and the other person's public key

in this mathematical algorithm,

they get a Diffie-Hellman shared key,

which is going to be the same on both sides.

And now they both have the same shared secret.

They can now create a tunnel with it.

At this point, they both agreed to the encryption

and the integrity methods,

and they're going to establish the IKE Phase two tunnel

using that Diffie-Hellman key.

At this point, they are going to use

the IPSec tunnel created,

and that becomes known as a phase two key

that's going to create this IPSec tunnel

and secure it.

Once they have this phase two key in use,

they now have encryption and integrity intact

for this tunnel and it becomes a tunnel

inside of a tunnel.

And now we have a secure method

to communicate between the two peers.

Now, I know that was a lot,

so let me break it down again into just five steps

and show you what it looks like in the real world.

First, I have PC1.

And they want to send traffic to PC2.

When they do this, router one is going to create

an initiation of an IPSec tunnel.

Second, we're going to see router one and router two,

and they start negotiating the security associations

to form the IPSec IKE Phase one tunnel.

This is also known as our ISAKMP tunnel.

Now, in step three,

the IKE Phase two is going to create this tunnel

inside of the tunnel when it's negotiated and set up.

Now, once that tunnel is established,

we can begin to conduct data transfer in step four,

and the information starts flowing

between PC1 and PC2 securely.

When they're all done with that,

we reach step five, and the tunnel is going to be torn down,

and the IPSec security associations

are going to be deleted.

Now, if you wanted to be able to create another VPN,

you can do that by starting this whole process over

from the beginning and going through those five steps again.

All right, at this point,

we've covered the tunnel establishments

a few different times in a few different ways,

so hopefully it's beginning to make some sense.

The reason I cover this so many times

in so many different ways is this is an area

that a lot of people struggle with.

Now, to allow the data transfer to happen,

there are two methods that we can use.

These are known as transport mode

or tunneling mode.

Now, transport mode is going to use

the packet's original IP header,

and it's used for client-to-site VPNs.

This approach works really well

if you have problems increasing your packet size

because you may end up hitting

a maximum transmission unit size

or MTU inside your network.

Remember, by default, the MTU

or maximum transmission unit size

is set at 1500 bytes in most networks.

If you go over 1500 bytes,

the packet will become fragmented

and this can cause issues with your VPN's functionality.

If you're using a client-to-site VPN,

I highly recommend you use transport mode

as your IPSec method,

because it doesn't add additional padding

to your packet and doesn't increase its size.

Now, on the other hand,

if you're setting up a site-to-site VPN,

like having a regional office

connecting back to a main office,

then I would use tunneling mode.

Now, tunneling mode is used to encapsulate

the entire packet and put another header on top of it.

This is going to increase the size of that packet

and it could go over your MTU.

Now, think about it this way.

Let's say you had an envelope

and you put it inside another envelope

and then wrote an address on it.

You readdressed it and then you shipped it to somebody else.

This new header is going to have a new source

and destination of the VPN terminating devices

at the different site that it wants to go to.

When it gets to the other site,

the VPN concentrator is going to remove

that outer envelope

or that header inside of a network packet,

decrypt the content,

and then route it across their private local area network,

just as if it was coming

from an internally connected client.

When using tunneling mode

you're encapsulating the entire packet

into a new packet.

So this is going to increase

the size of your overall packet.

And it could go above that MTU default size

of 1500 bytes.

If you're going to be using a site-to-site VPN,

you may need to allow jumbo frames,

which is any frame above the MTU size of 1500 bytes.

This way it'll be properly supported.

Normally the best way to configure your devices

would be to drop your maximum MTU size

on your inner router

to something like 1400 bytes,

and then connect it to the VPN.

This way there's enough room to add the extra encapsulation

and the new packet header before transmitting it out

over the public internet inside your VPN tunnel.

If you control the entire network,

you could actually raise your MTU size up

to a maximum of 9,000 bytes if you wanted to,

but this should only be done on your own local area networks

because 9,000 byte packets will have trouble

traversing the internet.

Now remember, transport mode

is normally going to be used for client-to-site VPNs

and tunneling mode is normally going to be used

for site-to-site VPNs.

The final thing we need to discuss in this lesson

is the concept of an authentication header or AH

and an encapsulating security payload or ESP

within your IPSec protocol.

Now, the AH or authentication header

is used to provide connectionless data integrity

and data origin authentication for IP datagrams,

and it provides protection against replay attacks.

Be aware though,

that the authentication header does not provide

any kind of confidentiality of the data itself.

Instead, the authentication header

contains a cryptographic hash of the data,

and this acts as identification information

to provide the integrity between the sender

and the receiver of each packet being transmitted.

Now, the encapsulating security payload

or ESP is used to provide authentication,

integrity, replay protection,

and confidentiality of the data.

By using ESP within IPSec,

you can rewrite the payload of the packet

inside of an encrypted format.

Now, with ESP, we're only protecting

the confidentiality of the payload

contained within the packet,

not the headers themselves.

So if you're using transport mode,

such as in a client-to-site VPN,

you can use the authentication header

to provide integrity for your TCP header.

And then you can add the ESP,

encapsulating security payload,

to encrypt the TCP header and the data in the payload.

But this does not encrypt the end-to-end header,

so people outside your organization

can see where the data's coming from

and where it's going to.

If you're using the tunneling mode,

such as in a site-to-site VPN,

you can instead use both the authentication header

and the encapsulating security payload

to provide integrity and encryption of that payload,

including the end-to-end header.

In this case, a new IP header is going to be added

to the front of the packet to cover the hops

to the other end of the secure connection.

This means that nobody on the internet

can see the source or destination of the traffic

within the organization's internal networks

on either side of this VPN connection.

The Simple Network Management Protocol or SNMP.

In this lesson we're going to discuss

the Simple Network Management Protocol.

SNMP is an internet protocol

for collecting and organizing information

about managed devices on IP networks,

and for modifying that information

to change the devices behavior.

When we talk about managed devices

we're referring to any device that can communicate

with an SNMP manager

known as the management information base or MIB.

Now this includes things like routers and switches

and firewalls and printers and servers

and even your end user client devices.

SNMP can be used to send and receive data

from these managed devices

back to a centralized network management station.

When you're configuring your SNMP architecture,

you have to have a manager and then you have agents.

Now the SNMP manager could be any machine on your network

that's running the SNMP protocol

to collect and process information

from the devices on your LAN or WAN.

Normally though, you're going to set this up on a server,

especially in a large enterprise environment.

Now, the agents are different network devices,

they're sending information about themselves

over the network, back to that manager.

Usually an agent is just running a background service

to collect the data and send it back to the manager

at regular intervals, or when they're requested to do so

by that manager.

Now the SNMP manager is essentially a master node,

and it's going to be able to send and receive these messages

to those agents using three different message types.

These are set, get, and trap messages.

Now the set and get messages are pretty straightforward.

The set request is a manager to an agent request,

and it's going to change the value of a variable

or a list of variables.

When this request is received by the agent,

it's going to update its variables to the latest status,

and then provide a response to the manager

with a list of all the new values for that variable.

A get request is a manager to agent requests to retrieve

the value of a variable or a list of variables.

Using a get request, one or more variable values

can be requested from the agent by the manager.

Now, a trap message is a little bit different though,

because these are going to be sent asynchronously,

as notifications from the agent to the manager.

In the case of trap messages, the agent is going to send

the information without first being requested

from the manager.

This allows the agents to notify the management station

of a significant events that are occurring

in near real time.

In general, traps are going to be used to provide events

or alarm notifications to the manager from the agent.

Since trap messages are unsolicited information

being sent from the manage devices

back to your network manager, you might be wondering

what kind of information is contained

within an SNMP trap message?

Well, this can include lots of things.

Things like uptime, configuration changes,

unexpected downtime of a particular network link,

or other essential information on your network,

that's used in the monitoring and detection of unforeseen

events and network outages.

Now there are two different methods used to encode the data

inside your SNMP trap messages.

These can be sent as granular traps or verbose traps.

With a granular trap, each SNMP trap message

is sent with a unique object identifier or OID.

This number allows the SNMP manager to distinguish each

message as a unique message being received.

Now, an OID is a unique object identifier,

which identifies a variable that can be read

or set via SNMP.

As these individual OIDs are received,

they're going to be consolidated and stored inside

a translation file known as the MIB

or management information base.

The MIB is used to describe the structure of the management

data of a device subsystem using a hierarchal namespace

containing object identifier that OID,

as well as other information.

Since the MIB contains all the details about the OID,

this now allows the SNMP trap messages to send

just the changes for particular OID and not the entire list

of data known about every variable or measure

on a specific device or system.

This is bandwidth on the network for us because SNMP traps

don't send redundant information over the network.

Instead they seek to conserve network resources for us.

Now, if we're using verbose traps,

the SNMP traps may be configured to contain

all the information about a given alert or event

as a payload.

Since more data is being sent to the manager

from the device, it's going to take up more resources

on that server, for it to be able to analyze the data

contained within each trap.

This takes more resources, and it's going to use up more

bandwidth as it goes over our network.

Now data in these SNMP traps are going to be sent and stored

in a key value pair configuration.

This is known as variable binding.

For example, I might have a list of variable bindings

for particular router, things like site name, PR-Branch,

criticality, high, severity, low,

alarm description, high temperature,

and other pertinent information for a given alarm or event

basically, that's going to be reported

through one of these trap messages.

Now, when you're implementing SNMP in your network,

you need to keep in mind that there are three different

versions of SNMP, and they're not all created equal.

SNMPv1 version 2 and version 3

have different varying levels of security.

Now, as you can probably guess,

SNMPv3 is the newest and it was built as an improved version

over version 1 and version 2 making it the most secure.

When you're dealing with SNMPv1 and version 2,

these versions use a community string to give them access

to the devices as their security mechanism.

Now, these community string act as a shared secret key,

but in SNMPv1 and version 2,

it was set and stored in plain text,

making it really insecure.

Now these default community strings are either

public read-only, or private read-write,

and the devices are considered a huge security risk when

they're using these default community strings

in SNMPv1 and v2 because they're vulnerable to attack.

So in SNMPv3, there was some added security

to overcome this issue.

To mitigate the vulnerability with the community strings,

SNMPv3 provides three security enhancements,

which added integrity, authentication,

and confidentiality to the SNMP protocol.

So how does SNMP solve all these problems?

Well, for integrity, they started hashing the messages

before they were being transmitted,

to make sure nobody could alter the data

as it was being sent from the routers or switches

to the management node.

For authentication, they started validating

the source of the messages, that way you knew

where they came from.

For confidentiality, they added encryption

and they started using DES or the Data Encryption Standard

with a 56 bit encryption key to provide

confidentiality and privacy.

Now, if you know anything about encryption you know

that DES is considered a weak algorithm.

And so over time it's been replaced by 3DES

and now AES, the Advanced Encryption Standard

in newer devices that rely on SNMPv3.

But you can only use those newer algorithms,

if you have a firmware on your device

that supports those newer algorithms.

If not, you're still going to have to rely on DES.

Now another benefit of SNMPv3 is that it groups

our SNMP components into different entities

to increase security.

Each group can then be given different authorizations

and access privileges, such as read, write,

or read-write access.

By allowing us to create groups of smaller

and smaller sizes, we can better protect our networks

and the SNMP traps that are being sent across them.

Network logging.

In this lesson, we're going to discuss how we conduct

network logging inside of our networks.

Now all of our network devices are going to generate logs

based on the information, events, warnings, alerts,

and other critical data that they generate.

If you have a very small network,

it's pretty easy for you to log into a network device

and review the logs individually or manually.

But, if you're like me and you start working on large

enterprise networks, this is impossible.

For example,

one of the networks I previously worked on

had thousands of network switches and hundreds of routers.

There is no way I could possibly log into each and every one

of them and review those log files individually,

each and every day.

So instead we use something known as Syslog.

Syslog is a protocol that's used to send these logs

to a centralized server.

This becomes the easiest way for us to gather all the logs

across all our routers and switches

and bring them back to a central point

where we can analyze and review them.

All of our routers, our switches, our servers,

and all of our other devices can be configured

to send their own logs back to the centralized server,

to make our jobs easier and more efficient;

if we use syslog.

These centralized servers are known as syslog servers.

Or you can have a SIM,

which is a Security Information Management System.

Or a SEM, a Security Event Management System.

Or the new combination of the two known, as a SIEM,

a Security Information and Event Management System.

These days, most people have moved to a SIEM

because it combines the functionality

of all these other types of logging

and analysis systems into one device.

By sending all of your logs to the centralized server,

it allows you, as an administrator or analyst,

to normalize and correlate the events

in order to see trends over time.

For example, if I see someone's conducting

a ping sweep of my firewall,

that's really not that big of a deal.

But, if I see that as coming within a few minutes of that

sweep, and I see from the same IP address,

somebody trying to connect to my servers or my clients,

that may be a concern that can be flagged for investigation.

Because maybe, they were preparing the environment

by seeing what ports were open.

And now they're launching an attack.

When you configure your syslog server,

your SIM, your SEM, or your SIEM,

there are two primary components you have to have.

You have to have a client and you have to have a server.

Now, a client is just the device

that's going to send the log information

to the syslog server.

This can be a router, a switch, a firewall,

a web server, or any other type of device.

Then you have a server and this is going to receive

and store all those logs from all the different clients.

Each client can be configured to send logs to the server

based on different severity levels

of the information they contain.

Now, when it does this, it's going to send the data

over port 514, using UDP,

the User Datagram Protocol.

Now syslog has eight different severity levels.

The severity levels start at zero

and they count upward to seven.

So zero is going to be the most severe

and seven is going to be the least severe

or the most benign.

Now level zero is going to be used for emergencies,

and it's going to be considered the most severe condition

because the system has now become unstable.

With level one, we're going to have an alert condition.

And this means there's a condition

that should be corrected immediately.

Level two is used for a critical condition.

And it means there's a failure

in the system's primary application.

And it requires somebody immediate attention.

With level three, we have an error condition.

And it means that something is happening to the system

that's preventing it from functioning properly.

Now, for example,

your file system storage may have reached it's limits

and now the system can't write the data.

And so it's generating a write error

when it tries to save that log information.

And that could generate an error condition.

Now level four is going to be used for warning conditions,

and it can indicate that an error is going to occur

if action isn't taken soon.

For example, let's say your file system

only has two gigabytes of space remaining.

So you need to free up more space

before you start to get write errors.

This can send an alert.

This would be known as a warning condition

because you're running out of this space.

Now level five is used for notice conditions.

And that means these are events that are unusual,

but they're not exactly error conditions.

Level six is for information conditions.

And this is going to be a normal operational message

that requires no action.

For example, you might see in your logs

that an application has started or paused

or ended successfully.

These are all informational logs.

Level seven is going to be used for debugging conditions.

And it's just information that's useful to developers

as they're debugging their networks and their applications.

Now, as a network or system administrator,

it's your responsibility to determine

what levels should be logged

and how long do you want to keep those logs inside

your syslog server or your SIEM?

Now, while we would love to keep everything forever.

For most of us, that's just not practical

because we'll eventually run out of hard disk space.

So, some administrators will limit what they log.

And they decide to only log things

from level zero to level five.

And they'll ignore the informational or debugging logs.

This all depends on your organization and the policies

you're going to set forth inside your business.

All right,

we've talked a lot about logs so far in syslog.

But we haven't really looked at one yet.

So let's pull up a log and take a look inside.

Here's an example from a syslog server.

Here, we have the date, the time, the location,

and then we have the log level.

And you could see things like alerts, emergency,

error, warning, notice, informational,

and things like that.

Then, you have the machine or the host name

and the IP in the next column.

So, you know, what machine did the reporting

of this error or information or warning.

Then you have the actual text of the log message itself.

This will say things like, "this is a test message",

or "this is an error. And here's the error I had".

By having this information and understanding

what it is, as an analyst or administrator,

you can start going back and figuring out what caused

the incident and what really occurred.

Now for the exam, what do you need to know about syslog?

Well, you need to understand the eight different levels.

You may get a question that says,

"what is level number three in syslog?"

And you need to say, "that's an error message".

Alright, let's go ahead

and talk a little bit more about logs.

Remember, a syslog server is all just a big collection of

all the different logs from all the different servers

and clients and network devices we have.

Now, when it comes to network device logs,

we can review these inside the syslog server,

as well as by looking at our traffic logs

and our audit logs.

Now, when it comes to network traffic logs,

these are going to contain information about traffic flows

within your network.

For example, if you collect network traffic logs

from your router or your firewall,

you're going to see a list of every connection

that's been made to and from your network.

For example,

you could see the source IP, the source port,

the destination IP, the destination port,

as well as the Mac address of the client,

the time it took to occur, the length of the packet,

and even it's time to live.

Then you can analyze these traffic flows

to determine if this is normal traffic for you

and something you'd expect to see in your baseline.

Or, is this something that's abnormal

and needs to be investigated further?

For example, if you know that in a given day,

you're used to seeing about a gigabyte of data

leaving your network over port 443,

but today you saw 10 gigabytes of data

was leaving your network.

That is something you need to worry about.

So you might take a look at that and see,

have you been hacked?

Is somebody stealing all your data?

Now does it mean that's happening?

Well, not necessarily.

But we do know it's abnormal, because we expect to see

somewhere around one. And right now we're seeing around 10.

So we need an investigate that closer

and dive into those network traffic logs

to see what's happening.

Let's say for example, that happened in my company.

I would want to investigate that.

Now, most likely what I'll

find is that my video editor was uploading all of our videos

to cloud-based servers because 10 gigabytes of data

is only about an hour or two, a video for our courses.

Now she might edit all week and then on Friday,

upload all that data.

And that's why we're seeing that big spike on Friday.

Similarly, if you see traffic that you're not expecting,

like somebody saying data over some port that you're not

using, like port 21 for FTP,

but you don't have an FTP server.

This could be something that's abnormal

and suspicious as well.

The key to understanding your network traffic logs

is understanding what normal looks like.

And so you have to understand what normal is

in your baseline.

So you can then determine what is abnormal

and what needs to be looked at

much more closely as you do investigations.

Also, when you're looking at your traffic logs,

this can help you during your troubleshooting efforts.

For example,

you might see that you're trying to send data

to a particular IP address.

But it's stopping at a particular router or firewall

within your network.

By investigating this and the traffic logs,

you can determine why this blockage is occurring.

Now the second type of network device log

we need to talk about is an audit log.

Now, an audit log or audit trail is a record

of all the events and changes

that have happened on that device.

Every IT device keeps a log based on the events

and an audit log is typically going to contain

a sequence of events for a particular activity.

In a network device, this would be something

like a configuration change that you made to that system.

So let's say, for example,

you came into work and you found that somebody changed

the configuration on your border gateway router.

Now, you could log in and see who made that change

and exactly what changes were made

by reviewing that audit log for the device.

For your convenience, these audit logs

can be sent over syslog to that centralized server

for review and analysis as well.

Now, when it comes to servers and clients,

we're usually going to be using windows machines

in enterprise networks.

For windows, there are three main types of logs

you can also collect.

These are application logs, security logs, and system logs.

To view these logs, you can open your event viewer

on a windows system and access the different

types of logs.

The first one is an application log.

In windows this contains information

about the software running on your client or server.

Now, there are three severity levels

in a windows application log.

We have informational, warning, or error.

For example, if you have Microsoft word

and it crashes on you, you can go check

the application log and figure out why it keeps crashing.

Our second one we have is a security log.

The security log contains information about

the security of your client or server.

This is going to have things like successful

and failed login attempts,

and other pertinent security information.

This will also show you if an audit success or audit failure

occurred for those logs.

Now, the third one we have is a system log.

The system log contains all the information

about the operating system itself.

There are three severity codes here;

just like the application log.

We're still going to have informational, warning, and error.

In this example, there are four errors

and the rest were informational items.

The errors are notated by that red exclamation mark.

Whereas, if you see the warning,

it's going to be a yellow triangle.

And information is a white circle

with a blue I inside of it.

SIEM in this lesson,

we're going to discuss a security technology known as a SIEM,

or security information and event management system.

Now a SIEM is a security solution that provides real time

or near real-time analysis of security alerts

that are generated by network hardware and applications.

In our networks, we have a lot of different devices,

including not just our network infrastructure,

but also all our client devices that we host on the network

as well, to maintain a strong security posture,

it is critical to understand the status

of each of these devices by reviewing their logs,

informational alerts and events.

But if we had to log into each of these machines

individually to collect and analyze all that data,

it would take us forever.

Luckily, we have a solution known as a SIEM,

that helps us overcome this challenge.

A SIEM is able to gather logs and data

from all sorts of different systems

and combine them into a single combined data store.

This allows our cybersecurity analysts,

system administers and network administrators

to review the logs and find abnormalities

or things that are not operating within our baselines.

When it comes to reviewing these logs,

it shouldn't be done only after an incident

or after breaches occurred.

Instead conducting law reviews should be something

that's done regularly and routinely

as part of your network administration

and system management functions.

To effectively conduct a log review and analysis though,

you really do need to utilize a SIEM.

A seam is used to help us correlate the events

between different systems across the network.

Something that we couldn't do ourselves easily

if we're looking at logs from each individual machine.

Now by using a SIEM, we can combine

five essential functions that provides us

with a more comprehensive view of our enterprise network.

This is done by performing log collection,

normalization, correlation, aggregation and reporting.

Now, first we have log collection.

Log collection of all of our event records

from sources throughout the network is going to happen

usually using something like Syslog.

This will provide us with important forensic tools

and help us address

compliance reporting requirements as well.

Second, we have normalization.

Normalization is going to map log messages

from different systems into a common data model.

This will enable us to be able to connect

and analyze related events,

even if they're initially logged

in different source formats.

Third, we have correlation.

Correlation is going to link the logs and events

from different systems or applications

into a single data feed,

which speeds up our detection of threats,

as well as decreases the time for us

to be able to respond to those threats.

Fourth, we have aggregation.

Aggregation is going to reduce the volume of event data

by consolidating duplicate events

and taking those records and merging them

into a single record.

Fifth, we have reporting.

Reporting is going to be used to present

the correlated, aggregated event data

in a real-time monitoring dashboard

if you're an analyst, and if you're in management,

you're going to get some form of a longterm summary

or report at the end, and that's also part of reporting.

All right, let's consider a simple example.

You're looking through the logs and you see

that somebody has logged in over VPN from Asia.

When you look up the user ID, you see it's John Smith,

all right, that seems normal.

Maybe he's in Asia because he's on a business trip.

Now, while there may be nothing wrong with this,

a few minutes later,

you're looking at your SIEM and you see

that the access control system says

that John Smith's ID was just used

to log into the server room inside your building.

All right, now we have an issue

because if your server room is sitting in America

and John Smith is supposedly accessing us

from a VPN in Asia, something is wrong,

'cause he can't be both in the server room

and on a business trip in Asia at the same time.

So one of these things has to be wrong.

Now, either of these two events

by themselves would be totally fine

and not suspicious at all.

But by seeing them correlated together

at the same time or nearly the same time,

this tells us that there's something wrong here.

And we need to flag that as suspicious

and investigate it further.

Now, as we look into the situation,

we can determine where this person really is.

We can just walk down to the server room and say,

is John here?

And so he says, no, he's on a business trip in Asia.

Now we need to go check the security footage

and see who is logging in with John's credentials

here in the server room.

A SIEM allows us to do this type of correlation

very quickly and very easily,

and be able to deconflict these things.

A security information event management system

or SIEM can be implemented in many different ways.

A SIEM can exist as a piece of software

running on a server, a hardware appliance,

or even as an outsource managed service.

In order to effectively deploy a SIEM,

you have to consider a lot of different things.

First, you need to be able to log

all the relevant events and filter out anything

that's considered to be irrelevant data.

Second, you need to make sure you establish

and document the scope of the events.

Exactly what is it that you're going to log?

What's going to be considered inside or outside of your scope?

Third, you need to develop use cases to define a threat.

This will help you to find exactly what you do

and do not consider a threat and what you may

want to take action on or postpone for later.

Forth, you need to plan incident responses

for given scenarios or events.

If you know that when you see this type of thing occur,

then you need to take those types of actions.

That's what I'm talking about here.

You need to have these pre-planned responses

for any given threat that you might face.

Fifth, we want to establish a ticketing process

so we can track all these different events that we flag.

This way, as we go into the SIEM,

we can see something that looks unusual,

like my example of somebody logging in from Asia

and at the local office at the same time.

And then we can flag it and have it tracked

through the process to completion,

to make sure nobody forgets about it.

Sixth, we want to make sure we schedule regular threat hunting

by working with our cyber security analysts

and using our SIEM.

By doing this, we want to make sure

we're not missing any important events

that may have escaped the automated alerts

that we create inside the system.

By going through and doing threat hunting,

our cyber security analysts will be able to catch bad guys

doing bad things that may have escaped

our automated alerts and seventh,

our final consideration is how are we going to provide

auditors and analysts an evidence trail?

by using a seam, we have this great centralized repository

with lots of different data.

And so it becomes a great place for an auditor

or analyst to look through as they're doing their analysis

as part of a compliance-based inspection, as you can see,

there are a lot of great benefits and considerations

that we have when we start using a SIEM.

It's important for us

to always properly configure our network devices,

to make sure they're feeding their data into our SIEM

within the scope of our events.

Remember, a SIEM is going to take data

using the Syslog protocol.

This means we're going to be using UDP port 514,

or TCP port 1468, as that is being brought into the SIEM,

it's going to be classified

based on a log level from zero to seven.

Zero is our most important or most critical,

and seven is our least important or most informational,

just like we had with our regular devices using CIS log.

For the exam, it's important to understand

the purpose of a SIEM and that a SIEM relies

on the Syslog protocol to collect the data

from all these different network devices

and client devices on our enterprise network.

And then we're going to use that to normalize,

correlate and aggregate that logging data

into a single repository for further analysis.