If you've ever used voice over IP or a voice over IP telephone
like this one then you've used the real time transport
protocol.
There is an encrypted version of that protocol
called the secure real-time transport protocol.
You'll sometimes see this referred to as secure RTP
or very simply SRTP.
The goal with RTP is to take conversations that normally
would not be encrypted across the network
and add encryption for security so that nobody can
listen in to your conversation.
The encryption used for SRTP is AES
this ensures that your communication with voice
over IP or video over IP will be secure.
But there's more to SRTP than simply encryption there
are additional security features,
such as authentication, integrity, and replay
protection.
This is accomplished by using H MAC SHA
1 which is a hash based message authentication code using
the hashing protocol SHA 1.
One of the challenges we have with legacy protocols
that we've used for so many years on the internet
is that they were never originally designed
with any security features.
A good example of this is the network time protocol
or NTP the original specifications for NTP
didn't include any security features.
And we've noticed recently that attackers have taken advantage
of this by using NTP and amplification attacks when
they're performing distributed denial of service attacks.
Thirty years after it was introduced
NTP has now started to have additional security features
added, this is added as part of the NTPsec protocol which
is the Secure Network Time Protocol.
This update has added a number of security features to NTP
and has cleaned up some of the old code
to remove some existing vulnerabilities.
As users are sending an increasing amount of email we
of course, need to be able to keep
the information within those emails confidential.
One way that you can do this is with SMIME
that stands for secure multipurpose internet mail
extensions.
This is a public private key encryption mechanism
that allows you to protect the information using
that encryption and to provide digital signatures
for integrity.
Since SMIME requires this public private key pair
there needs to be some type of public key infrastructure
or PKI in place in order to properly manage these keys.
Another common way to send and receive email is using POP 3
and using IMAP and there are some security extensions
to those protocols as well.
With POP 3 you can use a start TLS extension
to include SSL as part of that POP 3 communication
and with IMAP you can choose to use secure IMAP which
also uses SSL.
And if you're using a browser based
email such as Google Gmail or Yahoo Mail
then you should always be using an encrypted communication
and your browser should always be
using SSL to provide that confidentiality.
We often refer to this browser based encryption
as SSL that stands for Secure Sockets
Layer in the reality we're using a newer version of SSL
called TLS which is Transport Layer Security and these days
if somebody is using the older term Secure Sockets Layer
or SSL they are actually referring to TLC.
If we are sending encrypted data over that connection
it's using the HTTPS secure protocol that
stands for HTTP over TLS or HTTP over SSL
and sometimes you'll see it referred to as HTTP secure.
The most common form of HTTPS is going
to use a public key encryption method
and it's going to use that public and private key paired
in order to transfer symmetric key across the network
so that a session key can then be used symmetrically
during the communication.
This is the backbone for most of the encryption
that we're doing on the internet if you're
on the professormr.com website or the youtube.com website then
you are using HTTPS to be able to send
that information privately.
If you need to communicate between two locations
across the internet in a secure form,
then you'll probably need to use some type of encrypted tunnel.
One of the most common types is IPsec or internet protocol
security, this allows you to send information
across this layer 3 public internet but encrypt
the data so that all of that information
remains confidential.
IPsec also includes packet signing for integrity
and anti replay features.
One nice part of IPsec is that it is so standardized
and you can use different manufacturers equipment
on both ends of the tunnel and both of those manufacturers
will be able to communicate with each other using IPsec
because this is such a well-known and well-established
standard.
If you're implementing an IPsec tunnel
you'll be using two main protocols
the first is the authentication header or AH which provides
the integrity and the other is the encapsulation
security payload or ESP that provides the encryption.
If you're transferring files between devices
you'll also want to use a secure protocol for those.
Two of the most common are FTPS and SFTP.
FTPS is the file transfer protocol secure
and it's using SSL to encrypt the information that we're
sending using that FTP client.
Although the name is very similar,
FTPS is using a completely different mechanism
to communicate than SFTP.
SFTP is the SSH file transfer protocol
so where FTPS was using SSL to provide the encryption,
SFTP is using SSH to provide that encryption.
SFTP also includes some additional management
capabilities for example you can resume interrupted transfers,
you can get a listing of the directories that
are on a device, you can remove files and directories,
and manipulate the file system using the SFTP protocol.
Most enterprise networks will have
a central directory where information
is stored on the network.
This directory can be accessed using common protocols
one of those protocols is LDAP that stands for the Lightweight
Directory Access Protocol.
The standard for having a centralized directory
on the network comes from an X.500 standard
by the International Telecommunications Union.
This original standard was actually called DAP, D- A- P
and it ran on the OSI protocol stack.
When this was updated for TCP/IP networks
they created the LDAP version of this protocol.
If you're using Microsoft Active Directory Apple's
open directory or you're using open LDAP then
you're using a directory that can
be accessed using this standardized LDAP protocol.
There's a non-standard version of LDAP
that provides a level of security, this is LDAP secure
or LDAPS and very similar to other protocols
LDAPS uses SSL to be able to communicate securely
to an LDAP server.
A more common form of security is
SASL or the simple authentication and security
layer, which is a framework that many different application
protocols can use to be able to communicate securely.
LDAP uses SASL for this and it can communicate
using Kerberos, client certificates, and other methods
as well.
We spoke earlier of using SFTP to communicate with file
transfer protocol over SSH.
SSH stands for Secure Shell and it's commonly
used to provide a terminal screen that
is encrypting the information between the client
and the server.
As SSH effectively replaces the older telnet protocol which
was still providing a terminal screen like this
but there was no encryption mechanism within telnet
this made SSH a very popular upgrade
and it's very common now to use SSH
almost exclusively when doing any type of terminal
communication.
DNS or domain name system is another one of those legacy
protocols that was originally created
without any type of security features.
This allowed attackers to change the information that
was being sent to and from a DNS server
effectively allowing them to redirect traffic
to whatever server they'd like.
To avoid this we've added additional security
features to DNS this would be DNSSEC
this stands for the domain name system security extensions.
DNSSEC gives us a way to validate the information we're
getting from a DNS server so that we know that it really
did come from the DNS server that we were requesting it from
and that the information was not changed
as it went through the network.
We're able to do this using public key cryptography,
we can sign the information that we're adding to a DNS server
and then the recipient of that information
can verify that information is correct based
on those digital signatures.
If you're in charge of managing switches or routers
then you're performing a number of different communications
to those devices and you need to be sure
that, that communication is secure.
We've already discussed how connecting
to these devices with a terminal can
be protected by using SSH or Secure Shell if you're querying
your routers or switches for information
then you'll use the SNMP protocol
and if you want to make sure that's secure
then you use at least the version 3 of SNMP
the secure version is SNMPv3 that is the Simple Network
Management Protocol version 3.
This third version added encryption
so we can have confidentiality of the data.
We also have integrity and authentication capabilities
so that we know the data wasn't changed
as it went through the network and we can be assured
that we're communicating directly to that device
and receiving responses from that device
without anyone modifying that information in the middle
of the conversation.
Although it's commonly used as SSH
to modify the configuration of a switch a router
at the command line, it's also becoming common to do this
from a web browser.
So we'll want to use HTTPS rather than the insecure HTTP
to make sure that all of our browser communication
is running over an encrypted connection.
We rely on the Dynamic Host Configuration Protocol
or DHCP to automatically assign IP addresses
to the devices on our network.
But DHCP does not include any particular security
functionality within the original specification
and so there are opportunities for attackers
to be able to manipulate this information
or modify what people are seeing from a DHCP server.
In order to enhance the security of DHCP
we've added additional controls outside of the DHCP protocol.
For example, with active directory
you can avoid rogue DHCP servers by authorizing
what devices are able to act as DHCP devices on your network.
Many switches can also be configured
to monitor for DHCP communication
and only allowed DHCP to come from trusted
interfaces on that switch.
If a switch sees DHCP being sent from an untrusted interface
it can block that communication on Cisco's which is you'll
see this configuration referred to as DHCP snooping.
Another attack you might see with DHCP
is where the attacker will change their MAC address
and use up all of the available IP addresses that
are in a DHCP pool effectively causing starvation or limiting
the number of IP addresses that are
available to other devices on the network.
To prevent this from occurring we
can make other configurations to the switch that
will limit the number of MAC addresses
that can be seen from any particular interface.
If an interface is connected to a single workstation
we would only expect to see a single MAC address
from that interface.
If suddenly we see a large number of MAC
addresses being created that interface can automatically
disable itself and prevent a DHCP starvation attack.
There are a number of different devices on our network
that are constantly updating themselves automatically.
For example, antivirus and anti-malware software
will update their signatures we have intrusion prevention
systems that require updates to those signatures.
And we might even have firewalls that update a huge list of IP
addresses to be able to block known malicious locations.
One challenge we have with managing these updates
is that each one of these devices
is commonly using a different method
to be able to perform the update using different protocols
and communicating to different IP addresses.
It may require that we examine each one of these devices
individually to understand more about the protocols
that it uses during the update process
and that we can configure firewall rules and trust
relationships to only allow that device
to receive updates from specific well known and trusted servers.