All right, let's take a look at module seven, which also deals with network
security controls, but this time of the technical variety.
All right, we're going to start it off
with an overview of network security protocols.
All right, so in this segment we're going
to look at Radio US pop three, DNS SEC, SRTP SMB V three.
We got a dedicated slide for each one.
So we're going to start off with the basic function.
A little bit later on.
We'll see these revisited in their
discussions called conglomerations with AAA servers, VPNs and so forth.
So let's lay down some framework or some groundwork for network security protocols.
Now, before we go much further, we need to
discuss the concept of clear text versus encrypted or encapsulated.
Most everything you can name protocol wise is by default clear text.
In nature, clear text is
easily parsed by any sort of packet capturing utility, as long as you can gain
access to network traffic and record it locally.
So anything of a clear text variety used
to go under the protection of security through obscurity.
People don't know the protocol, how it's parsed.
That's definitely not the case these days.
In the early days of the Internet, it was a somewhat closed network.
Nobody knew how TCP IP worked, so there
was a certain degree of inherent security there.
Nowadays, everybody uses the Internet on multiple devices at any point during their
day, and the standards are widely publicized and well known, and with very
little effort, you can easily intercept traffic and decode it locally, even if
it's not intended for your system as far as the addressee goes.
So we need to take measures to protect
what's otherwise clear text communication through encapsulation and encryption.
So with the remote authentication dial in user service concept or Radius.
This deals with it's called AAA Server,
which means authentication authorization and accounting.
It has a counterpart of a proprietary
nature called tacax, which we'll talk about here shortly.
But the Radius is a server that
authenticates at the request of clients who may authenticate for another client.
So in a nutshell, you have something like
a wireless access point that Bob is authenticating to.
802 WETX authentication would forward that authentication request to a Radius server.
So Bob would be the connecting client.
The wireless access point would be the client in the Radius client server
relationship, and the server Radius server would be the server.
So that gets a little confusing since you
typically want to think of the client as the requesting client.
But this guy would forward the
authentication request to a Radius server that would then allow or disallow
connection based on authenticator information.
So authentication, authorization and
accounting are three functions performed by Radius server, which is a standard.
Radius does have a successor called
Diameter, which really never seems to have caught on, which gave you in geometry.
Diameter is twice a radius.
It actually gave you
much more than that as far as extensibility goes, there was these things
called associated value pairs in the protocol field that gave you lots of
extensibility but never really seemed to catch on much.
So if you hear Diameter, it's supposed to be the successor to Radius.
Radius is still around enforce, and you see it all over the place.
For VPN dial up, wireless access, it does provide you with, again, the
authentication authorization data and then also accounting.
So there's actually two ports that Radius
uses for the authentication and the accounting services.
So the steps in Radius again are to
initiate a connection server, sees a request, sends back the response, which
either allows or disallows the connection request in the accounting steps.
It's a parallel function, the authentication piece.
Are they allowed in or not?
The accounting is then going to keep track of who authenticates.
So, similar operation.
We don't really need to dig too much into the contents or the details of the packets
at this stage, but they are two separate operations on the radio server.
Then you got the Cisco proprietary flavor
of AAA server, which is called Tacax Xtacx or Tacax Plus.
All right, radius is a UDP based protocol 1812 by default.
Tacax uses TCP, which inherently we like TCP better than UDP because it establishes
A through A handshake, does sequencing acknowledgement, whereas UDP is a little
bit more likely as spoofing attacks and that sort of thing.
But Tacax Plus also encrypts the entire communication between the client and the
server, including the user's passwords, which protects it from Snipping attacks.
Radius only encrypts the authentication
information, so the accounting authorization is transmitted in the clear.
It's also client server model, and again, it is Cisco proprietary.
So it also allows for separation of duties, which you may run into a
discussion in another resource of Tacax versus Radius.
That separation of duties allows you to
divide those services across multiple hosts.
Kerberos.
Yes, Kerberos.
A three headed dog guarding the gates to the underworld in Greek mythology.
Or a project developed at MIT as part of
the Athena project for a stronger method of authenticating systems.
The power with Kerberos or the strength in
Kerbros is that your password never really crosses the network, just things encrypted
with your password which are also unknowns.
So you can get really into detail about how the Kerberos exchange takes place.
But I'm going to summarize the whole thing in basic overview and steps.
The Kerberos authentication protocol.
The user sends his or her credentials to an authentication server.
All right, so you know what?
I'm going to go full whiteboard here for
just a second and do Eric's diagram of how Kerberos works.
All right. Key distribution center or Kdc
authentication server and ticket granting server.
Two services performed by the Kdc
authenticating Kerberized client puts their username and password
into a login field that's held in memory by the Kerberos
client, and the authentication request is sent to the Kdc authentication server.
With the requesting client's identity or user's identity.
All right. The password never leaves the box.
That's really important.
The kerberos server.
Let's actually make the hits guy more personable.
Kerberos server is happy to comply and sends back what's called a ticket granting
ticket, which is encrypted with my password.
All right, so there's actually more detail to this.
I'm going to keep it kind of brief, but
there's a symmetric key that should be unique for every session.
The Tgt typically has a lifetime of eight to 10 hours, and that Tgt
and its session key is decrypted correctly using my stored password and memory.
Then I prove my knowledge of the password.
So this guy is nice and encrypted so prying eyes can't read it.
But when I can replay this to the ticket granting server and request a session
ticket with another server or resource like File Serve one,
it contains a symmetric key for that session, which is encrypted both with my
password and the trust account password for the authenticating server.
So that session ticket or service ticket is a unique session key.
Sorry, it's a little bit warped that I
replay back with the symmetric key to the authenticating server.
It decrypts its copy of the symmetric key.
We both prove knowledge of our passwords.
Now it gets way more involved in that.
But this is in contrast to a challenge
handshake authentication, which can definitely be attacked.
So if an attacker evil Lego guy, or if the attacker wanted
to eavesdrop on this communication, they don't have much to go on.
The best you can do is try to decrypt the Tgt.
Intelligibly but in a challenge handshake
response a challenge handshake, that's a horrible server.
There involves a challenge string and a response.
So I send my username, I get a challenge, I send back the challenge response.
But this challenge is then mathematically manipulated using my password hash
and mathematically combined to create the challenge response.
An attacker could eavesdrop on this,
collect the challenge and the challenge response, and then brute force using the
challenge string until they match the challenge response.
So I've got a definitive I've got criteria that definitively tells me whether or not
I guess correctly in the symmetric key scenario in Kerberos, I don't know what
the symmetric key is, so I have no idea if I decrypt it.
Intelligibly in this case, all I have to do is match the challenge response trial
and error with the hash value period so I can capture it.
It takes more time and effort than a basic hash crack.
I can definitely attack it.
So Kerberos is way more secure than
challenge handshake in the fact that the password itself never crossed the network.
All right. Secure Email Services by default.
Smtp.
The protocol is clear text.
So we should probably use Smtp secure,
which almost always means using SSL or TLS.
Post Office protocol used to receive email.
Pop three runs over port 110.
Pop three secure uses.
SSL, again, typically runs over port 995.
Now this can definitely change.
It can be 465 for Smtp.
It's really up to the provider, Secure Imap.
Imap normally runs over port 143.
Imap, Secure can run over port 993.
All three of these are just using Ssltls.
Actually, I'm going to kind of cut to the chase here.
Typically we encrypt what are otherwise
clear text communications using
SSL or TLS, ssh or Ipsec.
Most of our data protection is done using one of those three options, and VPNs and
things like that will incorporate these protocols.
There's also things like Secure, real time
transport and a couple of less notable, less widely used.
But anything that addresses the clear text nature of the communication will consider
to be secure because it provides encryption, plain and simple.
So almost always using SSL TLS, which is pretty darn good considering Netscape came
up with SSL back in like the we're still using it today.
It's definitely withstood the test of time.
SSL and TLS are two different evolutions
of the same basic concept and we will definitely get to that.
Pretty Good Privacy.
A guy named Phil Zimmerman wrote a software package called Pretty Good
Privacy that gave us pretty good privacy, right?
It's an application layer protocol which
provides cryptographic privacy and authentication for network communication.
It can encrypt and decrypt email communications as well as authenticate
messages with digital signatures and encrypts stored files.
All right, so the digital signature, we've talked about that a bit already.
That's a hash or integrity check of a file encrypted with the signer's Private key.
Right.
The receiver decrypts that encrypted hash with the signer's public key.
If it decrypts correctly, the message is said to be authentic and intact.
So you have a random key that's used to encrypt the user's.
Public key for encryption is used to encrypt the symmetric key.
The receiver uses their private key.
Okay, we're getting ready to talk more about asymmetric encryption, so I am going
to just do a basic overview of asymmetric and how that works.
All right, first off, symmetric key
encryption, the same key is used to encrypt and decrypt.
All right?
So there are some drawbacks to that lack of non repudiation.
If you compromise the key, both sides of the communication are compromised.
It also does way better than asymmetric for bulk encryption.
And most everything we encrypt, transport, security or bulk data is using symmetric.
But the problem with symmetric is the key distribution.
And we're going to talk more about this in
cryptography, but we've got lots of slides that might mention this before then.
So let's understand how asymmetric and symmetric work.
In asymmetric, you have an encryption key
pair that's created they're mathematically related.
You have a public key and a private key.
My public key I give out to the public.
I don't care.
My private key I hold on to.
I am the only entity on the planet that has a copy of that private key.
So when something is encrypted with the
public key, I'm the only person that can decrypt it.
If something is encrypted with my private
key, I'm the only person that could have encrypted it.
So we don't typically use the private key for confidentiality because anybody on the
planet that has the public key could decrypt what's possibly sensitive data.
So when you're talking confidentiality,
the public key encrypts, the private key decrypts.
When you're talking about integrity and
non repudiation, then I encrypt something nonsensitive, like a message digest of a
file, which ensures authenticity and gives me non repudiation.
So since I'm the only person that could have signed it, then it gives you a higher
level of confidence that I actually was a signer.
So when you talk about integrity, non
repudiation, authenticity, the private key encrypts.
So if I'm sending you a file, that file is
actually encrypted with a symmetric key for the bulk encryption.
But then the symmetric key is encrypted with you, the receiver's public key, so
that you can receive the encrypted symmetric key.
You can decrypt it, and you're the only
one that can do that since you're the only one that has the private key.
So this will bang around in your head a
bit, and you'll think you get it, and then you don't.
And you think you get it, and then eventually it sticks.
So two different objectives authenticity or confidentiality.
Confidentiality. The public key encrypts.
The private key decrypts authenticity.
The private key signs the public key
verifies, which is actually an encryption process.
All right, so with bulk email,
bulk data sent through Sltls, they use digital envelopes as well.
We'll use asymmetric to protect the symmetric key.
All right, secure multipurpose Internet mail extensions.
So PGP can be used to encrypt email.
PGP used to old school use proprietary certificates.
Proprietary were again designed by Phil Zimmerman and they used a web of trust or
a mesh trust in secure multipurpose Internet mail extensions.
It uses X 509 standard certificates and a certificate hierarchy.
We'll definitely talk more about that, but SMIME is another way to encrypt email.
Also encrypting the mail with the symmetric key and encrypting the symmetric
key or doing the signatures with the certificates.
Certificates really quickly without getting into the whole discussion.
Certificates original purpose was to bind a public key to the owner's identity.
So when I hand you my certificate, that certificate has my public key and it's
signed by a certifying authority you've chosen to trust, so you know it's valid.
So when I flash that to you, you're like, well, this public key must actually belong
to Eric because this came from Verisign or Thought or whoever.
So for the verification process or the encryption process, we require certificate
exchange, which really means just exchanging public keys.
Hold up that thought.
We've got more to talk about in certificates.
All right, so again, here's how the whole thing works.
You've got the signing of the message digital signature we just talked about, or
the encryption using Des or AES, and then the encryption of the secret key.
So two things.
We might encrypt an email, the symmetric key for confidentiality, or the integrity
checker message digest for authenticity, receiving end decrypts.
All right. DNS SEC.
DNS itself is clear text, and that puts a smile on the attacker's face.
So my standard little doodle for clear text is eyeballs.
Sometimes I do it without even thinking about it.
So whenever you see that pop up on the slide, we're talking about a clear text
protocol, which most of this stuff is by default.
DNS is UDP based.
It's used to resolve FQDNs and host names to IP addresses.
It's subject to various types of impersonation and poisoning attacks.
We've already talked about that.
And the authenticity of the DNS response sometimes comes into question.
So to remedy that, we've got DNS SEC.
DNS SEC is signed DNS responses, which requires what?
Configuration? Right?
Configuration and certificate validation.
So it's used for securing certain types of information provided by DNS.
It works by digitally signing the records
for DNS with the help of public key cryptography.
Just like any other signature, it
guarantees authenticity, integrity, or potentially, the absence of a domain name
or type does not guarantee confidentiality.
Keep in mind that a digital signature does nothing for confidentiality by itself.
It merely gives us an integrity check.
So it's still clear text.
So I'll just put a checkbox next to my eyeballs here.
Anything that's digitally signed is not necessarily encrypted.
All right?
It does not provide protection against denial of service attacks either.
The working of DNS SEC.
Again, it's on the concept of asymmetric keys, a public key and a private key.
It adds a digital signature to each piece of the domain names.
DNS information.
Again, it's assigned response, the receiver verifies.
It ensures that it hasn't been forged by a non valid DNS server.
DNS poisoning in some way, shape, or form.
And DNS poison is actually pretty easy to perform.
All right, SHTP.
There's SHTP and then there's Https.
All right, we almost never see SHTP.
SHTP is security at the application layer,
so it is actually encrypted as the payload.
It's an alternative for Https, although you never really see it around SSL.
TLS works really, really well.
So almost never do you see implications of
Shttp, but the idea there is encryption at the application layer, secure data
transmission individual messages, while SSL establishes a secure connection
between two entities, thus ensuring security of the entire communication.
All right?
Now, Https hypertext Transfer Protocol secure typically runs over port 443.
It is an incorrect statement to say that SSL uses port 443.
That's kind of one of my pet peeves.
Like https uses 443 SSL, or TLS doesn't use port abstraction.
The protocols that use SSL do.
So https uses 443 LDAP SDAP secure uses 636 pop.
Secure uses port 995 465 for Smtp, secure, et cetera, et cetera.
So it's the protocol that dictates what port is being used.
Now that I've split hairs, I'm going to jump off my soapbox here.
The connection is encrypted using
Transport layer security TLS or SSL protocol.
It's used for confidential online transactions.
Also protects against man in the middle attacks.
Kind of come back for ceh and we'll show you some SSL hijacking attacks.
All right, I'm going to do a quick
whiteboard diagram here on how an SSL session works because
we're going to be talking about it a bit before we actually see the slide for it.
And sometimes I like my drawings better.
I hope you do too.
All right, here's my web server,
and I want to connect to a web server using Https, all right?
So I'm going to send a request for an
Https connection and the server responds with its certificate.
That certificate has the subject Identifier, which matches the server.
It's got a validity date,
start and expiration date, and it has the associated public key.
That server also has the private key on a chain around its neck.
That's a chain, by the way, around its
neck, and it never gives it out to anybody, hands out the public key in the
form of a certificate to anybody and everybody.
We don't care. That's the whole idea of a public key.
So I verify the certificate.
If everything lines up, I come up with a
symmetric key for the session, for the transport security.
That's supposed to be a tunnel, by the
way, and I encrypt it with the web server's public key.
I send it to the web server, the web
server decrypts the symmetric key with their private key,
and now we've securely negotiated a key for the tunnel.
All right, so the idea here is it protects against man of middle tax and any
intermediary device it's encrypted host to host.
So that's how the setup works.
But I can also spoof a certificate to
request a client and set up what's called an SSL bridge.
And there's also SSL stripping, which
allows us to redirect to a non SSL version of the site.
We've already talked about that.
So that's the basics of how SSL works.
So any protocol that uses SSL establishes
that connection using the certificate, validates the server.
If everything looks in order, we'll accept
the certificate and encrypt the session key with the server certificates.
Public key.
Transport layer Security is the evolution of successor two SSL.
TLS ensures secure communication link, just like SSL did the layers of TLS.
You have the Record protocol, which establishes the connection security, and
the Handshake protocol, which ensures the server and client authentication.
All right, so again, same idea as SSL.
SSL developed by Netscape way back in the
day for managing the security of a message transmission on the Internet.
It uses RSA encryption to encrypt data transferred over SSL connections.
And I just give you the eric Chalkboard version of this and how that works.
I like my drawing a little bit better than that.
I'm sure this is more complete with the
detail, but I think mine illustrates the concept more clearly.
All right. Secure real time transport protocol.
SRTP advanced version of real time Transport protocol.
So you're talking about VoIP Real Time Transport Protocol or Rtp by
default is not encrypted, which means VoIP is Clear Text, which again, that puts a
smile on our attacker's face, which means I can collect it and actually encode VoIP
messages in MP3 s and play them back from a player.
Wireshark or cane.
Both do that and a variety of other utilities.
Secure real time transfer protocol. Secures it.
So with VoIP, you have Rtp, SRTP, and then
you also will hear session initiation protocol mentioned in discussions with
Wood Media transmissions between connected devices.
All right.
Lightweight directory access protocol over SSL.
LDAP typically runs over port three, D nine.
LDAP is for communicating with X 500
compliant databases, which means active directory domain controllers.
Most likely 389 is Clear Text,
which remember, that is not a good idea from a security perspective.
So we can use 636 or LDAP s to establish a
secure connection, again using SSL or TLS Ipsec.
All right, Ipsec is layer three encryption.
There's tunnel mode, there's transport mode, there's integrity, there's
confidentiality authentication header or ESP.
There's some terminology that you're going
to want to be familiar with the Internet Key Exchange.
Isocamp security associations.
So we'll address this in about three
slides, but Ipsec is actually built into IP version six.
Well, if you do, it's been ported over to
IP version four, added to it since, like, Windows 2000 came out.
So it's not a new technology by any stretch.
It is widely used to implement VPNs for
Moote user access, dial up connections to private networks.
It's also used for internal security.
And it doesn't use port numbers. It doesn't get that high.
It's layer three.
So if somebody asks you what port number
Ipsec runs on, it's a trick question, unless they're
talking about the Internet Key Exchange, which establishes the connection.
So this is protocol IDs, not port numbers.
Ah and ESP.
But the Ipsec Key exchange.
The Internet Key Exchange actually runs on UDP port 500.
Let's keep that in mind. Okay.
Ike, Isocamp, Oakley and Diffie.
Hellman.
All right, this gets a little confusing.
You'll hear all three terms used kind of interchangeably.
The Internet Key Exchange is a facilitator
for authentication and connection negotiation.
Isocamp is a key management protocol.
Ike is kind of another term for Isocamp.
Isocamp uses the Oakley Protocol, which uses Diffie hillman for the key agreement.
There you go. Demystified.
So you'll hear all these terms used in the syndicate.
They're all part of the same process.
So a lot of times hands go up.
That's a frequently asked question class. Which one is it?
Diffiellum and Oakley.
They're all part of the same process.
The Ipsec driver actually does the encryption.
The policy agent determines when the encryption needs to take place.
So you'll set that up through group policy or local security policy on a Windows
system that says, hey, those servers get Ipsec, and here's how it should go.
And you can differentiate what gets encrypted and what doesn't.
The benefits of Ipsec gives you pure authentication, data origin,
authentication data integrity, data confidentiality, and replay protection.
All right? And the way it does that is through a
negotiation of, first off, a transport mode or a tunnel mode.
A transport mode means that the entire
packet is not put inside the payload of another packet.
Tunnel mode, the entire packet is encapsulated in another packet.
So it protects the inner IP header
from being captured or identified, typically on an untrusted network.
So tunnel mode typically means VPN.
Internet transport mode is typically more internal.
All right? Then you got ah or ESP.
Ah and ESP are actually illustrated in the next slide.
So let's switch to that.
Authentication header provides data authentication.
It does an integrity check and a signature encapsulating security payload does an
integrity check and a signature and encryption.
So it gives you confidentiality, this
gives you authentication and non repudiation.
Again, you'll typically set that up in a
Windows system through your local security policy or group policy.
Secure File Transfer Protocol or Sftp is
used to securely send what's otherwise clear text FTP.
So again, almost everything is clear.
Text secure file transfer protocol runs on port TCP 22, which is an extension of Ssh.
You can also run FTP over SSL ftps or FTP secure.
SNMP version three.
SNMP version three is a much needed upgrade to SNMP version two and SNP
version one that are horribly insecure by today's standards.
Some of the problems with SNMP version one
are clear text, community strings, no access control list, lack of
encryption, and that's makings for a really insecure management network.
But SNMP version one is still pretty widely used.
SNMP version three provides encryption
authentication and remote configuration and also access control list on your
management information basis, which gives you granularity of access control so much
more secure user based security model versus a community string standard, which
is basically a common password that everybody uses for reader write access.
All right, Secure Shell is the fix for telnet and our login runs on port 22.
You have three flavors of Secure Shell authentication.
Simple authentication performed on the basis of a user's password.
Key based authentication allows for key pairs.
All right, so you've got RSA keys, public
and private key, then host based authentication.
If it's enabled on a trusted host, they
can log into the target machine using the same username enables feature.
The set user ID bitlist we set.
So typically it's one of these two.
You also have host based authentication as an option.
Ssh, everything is encrypted just like SSL or TLS, and it's a bad bad idea to use
telnet as remote authentication or administration protocol.
Oauth authorization protocol that allows a
user to grant limited access to the resources from one site to another site.
So this is single sign on Federated
identity type of stuff does not transfer user credentials between applications.
Instead, it uses authorization tokens to
verify your identity between the client and server.
So if you're logging into one site and
able to access the resources of another, you might be using Oauth for that.
OpenID Connect is built on the Oauth 2.0 protocol.
It provides authentication login, profiling information and user identity.
It creates a secure ID token using JavaScript object notation contain in
information like name, phone number and address.
All.