If you’re going to communicate on a network, you should ensure the use of secure protocols. In this video, you’ll learn how to secure phone conversations, email, file transfers, directory services, and more.
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.