MODULE 27
Internet Service Hardening
Hosts use a variety of applications that must communicate over the network with other hosts and applications on their own network or with Internet-based resources. Some of these applications are user-focused, such as client browsers, and some are applications that network services need in order to service client requests. Network communications between applications take place using protocols. Remember that protocols are simply rules for communications. When an application uses a protocol to communicate with another application, they work together and with other services, such as encryption and authentication services, to ensure that communications sessions between applications on different hosts are functional, that they transfer the data correctly and efficiently, and that they are secure.
As with other application and network components, such as transmission media and network devices, protocols can also have weaknesses and can be used in non-secure ways that pose risks to the organization’s systems and data. In this module, we’ll look at protocols and services that are common to most host machines and applications. We’ll also examine how you can use them securely on the network.
Internet and Application Service Protocols
We’ve discussed ports, protocols, and network-based services a great deal throughout this book; by now you should realize how important they are to the exam. Here we will examine each of these critical protocols and services, describing them and providing information on how they relate to the OSI model, as well as which TCP and UDP ports they use. This is important information, so you can expect to be tested on this heavily throughout the exam, regardless of the Security+ domain to which the question applies.
Using Secure Protocols and Services
Most of the application and network protocols we discuss in this module reside at the Application layer of the OSI model and TCP/IP protocol stack. They are used in conjunction with applications that reside on the host, which need to communicate over the network with the corresponding applications residing on a remote client host or machines. They also use lower level protocols and services to send message traffic over the network media. All of these protocols are altered in some way as they travel down and then up the OSI model or TCP/IP protocol stack. This is called encapsulation and de-encapsulation, and it occurs for every protocol that travels over the network. Each protocol also uses a corresponding Transport layer protocol, either TCP or UDP, to provide connection-based or connectionless services for their communications sessions. This also involves, necessarily, a corresponding TCP or UDP port number. Remember that protocols and port numbers are two of the elements used in filtering network traffic on network security devices. That’s why it’s important that you know the different protocols and their corresponding ports when securing network-based applications.
DNS
The Domain Name System, or DNS, is used to resolve Internet names to IP addresses. So, for example, when you type in www.google.com, DNS resolves the Internet name to the IP address that your computer and other networking devices along the way need to connect you to that particular site. DNS consists of clients (hosts that need to get name resolution services) and servers (used to provide name translation services).
Without going back into the Network+ level explanation of DNS, remember that DNS uses authoritative servers that host DNS zones, which are the domain namespaces of the organization and its subdomains and hosts. Authoritative servers for a DNS domain can be primary or secondary servers. Primary servers actually host the writable copy of the zone file and replicate it to the secondary servers. A zone file is a mapping of host names to IP addresses and is used to make the name-to-IP address translation.
Hosts make DNS queries to servers, and responses can come from authoritative servers or caching servers. Caching servers have made a query to other DNS servers and have retained the name resolution response in their own memory caches. Caching servers may not necessarily host DNS zones of their own; they may merely make requests on behalf of hosts and the responses they receive are cached for future requests. DNS as a protocol uses TCP port 53, as well as UDP port 53, and is an Application layer protocol. TCP is used for zone transfers between primary and secondary servers, while UDP is used for queries and responses between hosts and servers.
From a security perspective, you need to do several things to secure DNS. First, you should make sure that only specified secondary servers are able to receive zone transfers from authoritative servers, because a zone file can contain sensitive information about the organization. If the authoritative server is not securely configured, it will transfer the zone file to anyone, revealing information about the organization’s network infrastructure. This information could assist a hacker in formulating a network attack. Second, you should make sure that clients are able to contact a DNS server that is trusted by the organization, because one frequent hacker technique is to attempt to send clients to a rogue DNS server that could provide false name resolution information. This false information could cause the client to contact a malicious web site, instead of the web site they think they are connecting to. One common DNS-related attack is called pharming, which involves sending false name resolution responses to a client and sending them to a malicious site. Third, if the infrastructure allows it, you should authenticate DNS servers and clients to each other so that they can ensure that both the client and the server are trusted. This can be accomplished using the mutual authentication capabilities of digital certificates, as well as by using secure authentication methods, such as the 802.1X standard.
Yet another technique that network architects use to secure DNS is a split DNS architecture. In a split DNS, separate DNS servers are used for the internal and external namespaces of an organization. This allows internal clients to resolve internal host names using a separate DNS that is protected because of its placement on the interior of the network. If the client needs to resolve the name of an Internet host, it makes this request to the external DNS, usually located in the DMZ. Figure 27-1 serves as a reminder of how DNS works. Like many of the older TCP/IP protocols, DNS was not invented with any inherent security mechanisms built in. However, there are methods to secure DNS, such as tunneling DNS through secure protocols, using the DNS Security Extensions (DNSSEC), and locking down clients and servers using secure configurations.
Figure 27-1 DNS in action
SSL
Secure Sockets Layer (SSL) is a protocol that provides for both encryption and authentication services between hosts during data transmission. For encryption services, it encrypts the entire session between two hosts. Any traffic that is sent between the hosts during that session is encrypted and protected from unauthorized interception. For authentication, SSL can use digital certificates to authenticate a server to a client or both hosts to each other (called mutual authentication). The protocol has been widely used for years to secure sensitive data transferred during web sessions, such as in online e-commerce and financial transactions. SSL uses TCP port 443 and is considered an Application layer protocol. In addition to providing secure session services for web traffic, SSL can be used to protect other protocols that require secure sessions. FTP, another non-secure protocol, can often be used over an SSL session, as can other non-secure protocols. Figure 27-2 explains how hosts are authenticated and traffic is encrypted using a secure session key exchanged between the hosts during an SSL session.
Figure 27-2 An SSL session between two hosts
SSL has been vulnerable to an increasing number of attacks recently; the latest among them is the SSL version 3 attack, dubbed the “Poodle” attack (Padding Oracle On Downgraded Legacy Encryption), discovered in September 2014. This attack involved previous versions of SSL that allowed an attacker to force hosts to fall back to an unsecure version of SSL, so that the attacker can make malformed SSL requests to the client to break encrypted communications between the client and server. Because of the weaknesses in cryptographic algorithms used in various versions of SSL, different attacks over the years could be used to perform man-in-the-middle attacks on the protocol. That’s one reason why TLS was invented to replace SSL a while back, and its use has now been urgently accelerated in the past few months as of the time of this writing.
TLS
Transport Layer Security has been widely considered as an eventual replacement for SSL. It was slowly adopted, however, due to compatibility issues between legacy browsers and applications. Not all hosts or browsers and a lot of web applications fully supported TLS until recently. However, in the wake of several SSL exploits developed over the past few years, TLS has been implemented more and more. Currently, all modern operating systems, browsers, and web-based applications support TLS. TLS uses TCP port 443 for backward compatibility with SSL-based technologies.
HTTP and HTTPS
The Hypertext Transfer Protocol, or HTTP, is commonly used to access web resources on the Internet. This enables hosts to use HTTP requests to send and receive Hypertext Markup Language (HTML) documents as well as other Internet content from web applications. Unfortunately, HTTP is not a secure protocol by itself. All content sent over a HTTP request and response is unencrypted—that is, it is sent in plaintext, which can be easily intercepted and read by anyone, including malicious hackers. This is why sending sensitive data over ordinary HTTP can be very non-secure. One solution to this issue was developed by sending HTTP traffic over more secure protocols, such as SSL and TLS.
HTTPS is really not a separate protocol; it is merely sending normal HTTP traffic over an encrypted SSL or TLS connection. Sending unencrypted traffic through an encrypted SSL/TLS connection allows you to encrypt and protect the contents of that traffic. SSL and TLS can be used to send almost any protocol, though, providing security services for that traffic. HTTP uses TCP port 80, and HTTPS is sent using TCP port 443, the port used by SSL and TLS. Both HTTP and HTTPS reside at the Application layer in the OSI model.
Note that there is another secure version of HTTP out there as well, and it is called S-HTTP (for Secure-HTTP). It is not the same thing as HTTPS; they are very different protocols. S-HTTP encrypts only header information for the HTTP traffic and does not use SSL to do so. This is different from HTTPS, which does use SSL to encrypt not only header information, but the entire session and everything in it.
FTP
The File Transfer Protocol, or FTP, is used to upload and download files to an FTP site, which is a repository of files set up by an organization for its users or customers. FTP is inherently a non-secure protocol, simply because it does not encrypt any data sent or received. All traffic is unencrypted, so it is subject to interception by a malicious entity with the use of networks sniffers. FTP has no built-in security mechanisms; it does have a form of weak authentication that can be used, but again, even the authentication traffic is not encrypted or otherwise protected, so credentials are subject to sniffing as well. FTP is an Application layer protocol and uses two TCP ports to function, ports 20 and 21. These ports are for data and control commands, respectively.
FTPS
FTPS is a secure version of FTP that can be used over and SSL or TLS secure session connection. Using SSL or TLS enables users to perform FTP file transfers securely, using built-in encryption and authentication mechanisms (usually involving public and private keys). Unlike other applications that use SSL or TLS, FTPS uses TCP port 990. You should know that there is also another form of FTP, called SFTP, which is part of the Secure Shell suite of utilities. We’ll discuss it in detail after our discussion on SSH.
Telnet
Telnet is an older protocol used to remotely connect to and administer a network-based host, such as network devices. It was originally developed as a terminal emulation program, coming from the older days when administrators needed to use particular communications settings when remotely connecting to a mainframe and pretend to be a dumb terminal application, so the mainframe would understand it. It is inherently a non-secure protocol, since everything it sends over the network is unencrypted. It also uses weak authentication mechanisms. It has been largely replaced by SSH as a means to administer hosts remotely. Telnet is an Application layer protocol and uses TCP port 23 by default.
SSH
Secure Shell was developed to take the place of older, non-secure protocols that were used to administer hosts remotely, as well as to copy files back and forth between hosts across the network. These older protocols, including Telnet, were prone to sending data across the network in plaintext, where it could be easily intercepted and read. Any files transferred between hosts with these non-secure protocols, such as FTP, were also sent in the clear and could be intercepted and downloaded by any malicious user or attacker.
SSH is more than simply a protocol; it is a suite of utilities and applications that can be used to manage a system and transfer files remotely. In addition to the SSH program, other utilities in the suite include Secure Copy Protocol (SCP) and Secure FTP (SFTP). These utilities will be discussed a bit later in this module. SSH uses TCP port 22, as do all of the different utilities that use it. It resides at the Application layer of the TCP/IP protocol stack. SSH is included natively in UNIX and Linux distributions; although it’s not native to Windows operating systems, many third-party clients and servers are available for Windows so you can use SSH. Figure 27-3 shows an example of an SSH session.
Figure 27-3 An SSH session
SCP
The Secure Copy Protocol is one of the utilities in the SSH suite. SCP is used to copy files from one host to another during an SSH session. You can also initiate an SSH session using the SCP command. Because SCP is part of the SSH utility suite, it uses the same encryption and authentication methods, as well as TCP port 22 for its file copying operations. SCP, like all SSH utilities, requires that the SSH server and clients are set up on both hosts first, and that they are able to agree (through configuration files on both hosts) on mutual encryption and authentication schemes. SCP is a much more efficient and secure way of sending files back and forth between hosts using other unencrypted means (such as the regular Linux copy command, cp), which make sensitive files vulnerable to interception. Figure 27-4 illustrates an SCP session.
Figure 27-4 An SCP session
SFTP
Several security utilities are included the SSH protocol suite. One of these, SCP, is used to copy files back and forth during a particular SSH session with a single host. These file transfers are usually ad-hoc and are limited to that particular SSH session only. There are times when users require a more permanent secure file transfer solution beyond that of a single session. The organization could set up an FTP site for just such an instance, but you already know that FTP is not secure. For a more permanent, secure file transfer solution, SFTP is a good choice. SFTP (also known as SSH-FTP) uses SSH, so it protects data through encryption and authentication services. It functions similarly to normal FTP, but all data is encrypted, so it can’t be easily intercepted or read.
SFTP is not the same thing as regular FTP or FTPS, so don’t confuse them. SFTP does not use SSL at all. Additionally, there is yet another way you could use SSH: like other non-secure protocols, such as Telnet and HTTP, you could actually send regular non-secure FTP through an SSH tunnel. Note that when used in this manner, it is not the same thing as SFTP.
Confused yet? Table 27-1 will help clarify it for you by breaking down the different file copy and transfer protocols.
Table 27-1 Various Ways to Copy and Transfer Files Securely and Non-securely
POP3
The Post Office Protocol, or POP, is an e-mail client protocol used to receive e-mail through client applications. It is an older protocol but is still in wide use. Its current version, POP3, is being slowly replaced by a much more efficient client protocol, Internet Message Access Protocol (IMAP). Client applications that use POP3 access the user’s mailbox and download all of the e-mail in the inbox, and then delete the mail from the server. This can confuse some users, especially when they log in to their e-mail from different clients and find that their e-mail has “disappeared.” POP3 allows only one connection at a time to the user’s inbox.
POP3 uses TCP port 110, and although it is inherently non-secure by itself, a secure version of the protocol can use SSL or TLS to protect e-mail traffic between the client and the server. This ensures both authentication and encryption protection for e-mail. This version uses TCP port 995.
IMAP
IMAP is also a client e-mail protocol, although it is probably in more widespread use these days than POP3. The most current version of IMAP is version 4. IMAP4, which uses TCP port 143 by default, is used to connect to an organizational or web-based e-mail server and download client e-mail messages. It’s a bit different from POP3 in that you can have multiple connections to the server from different user clients, and e-mail isn’t automatically deleted from the server. Like POP3, IMAP is also an unsecure protocol, although it can also be used over secure session protocols such as SSL and TLS (called IMAPS). IMAPS uses TCP port 993 and, like IMAP4 and POP3, is an Application layer protocol.
SMTP
Simple Mail Transfer Protocol (SMTP) is the server-side e-mail protocol used to send e-mail messages from an organization’s e-mail server. SMTP is an Application layer protocol that uses TCP port 25. Like some of the older protocols we’ve discussed in this module, there are no built-in security mechanisms for SMTP. It provides no authentication between hosts or for users, and it relies on external authentication mechanisms such as LDAP-based directory systems for authentication. Besides being a non-secure protocol, SMTP is also vulnerable to various attacks. Particularly because there is no built-in authentication mechanism in the protocol, it is vulnerable to an SMTP relay attack. In this type of attack, a malicious person can actually connect to the SMTP server and send e-mail from it, spoofing the organization’s users and e-mail addresses. This attack can be prevented by configuring the SMTP server not to allow unauthenticated connections and by disallowing SMTP relay.
A secure version of SMTP is called SSMTP (Secure SMTP) or sometimes SMTPS (for SMTP-Secure), and it uses SSL and TLS to tunnel SMTP connections, effectively securing SMTP traffic using those secure protocols. Unlike other protocols sent through SSL and TLS, such as HTTP, for example, SMTP doesn’t use the standard TCP port 443. Instead, it uses its own unique port, TCP 465.
Module 27 Questions and Answers
Questions
1. Which of the following are methods used to secure DNS? (Choose three.)
A. Using a split DNS
B. Using DNS built-in encryption capability
C. Restricting zone transfers only to authorized, authenticated servers
D. Using DNSSEC
2. Which of the following ports does both SSL and TLS use?
A. UDP 443
B. TCP 465
C. TCP 443
D. TCP 22
3. Which of the following protocols uses SSL and TLS to secure their traffic?
A. SFTP
B. S-HTTP
D. SCP
4. Your manager wants you to implement a secure file transfer solution so that customers can log in and download files appropriate to your company’s products. The solution must offer secure authentication and encryption and must be available whenever they need it to be. Which of the following protocols should you use?
A. FTPS
B. FTP
C. SCP
D. HTTP
5. Which of the following remote administration protocols is inherently non-secure and exposes user credentials to sniffing and interception because they are transmitted in plaintext?
A. SSH
B. Telnet
C. HTTPS
D. FTP
6. All of the following characteristics describe Secure Shell (SSH), except:
A. Consists of a protocol and suite of utilities
B. Native to Linux distributions
C. Provides for encryption and authentication
D. Uses TCP port 23
7. Which of the following would be considered an appropriate utility to use when a user needs to send a few files securely to another host during a single SSH session?
A. SCP
B. SFTP
C. FTP
D. FTPS
8. Which of the following e-mail protocols uses TCP port 995 when tunneled through SSL or TLS?
A. SMTP
B. POP3
C. IMAP
D. SSMTP
9. Which of the following e-mail protocols allows multiple client connections to the user’s account and uses TCP port 993 in conjunction with a secure SSL/TLS connection?
A. SMTPS
B. SMTP
C. POP3
D. IMAP4
10. Which of the following best describes the SMTP protocol?
A. A non-secure client e-mail protocol that uses TCP port 995
B. A secure server-side e-mail protocol that uses TCP port 143
C. A secure client e-mail protocol that uses TCP port 110
D. A non-secure server protocol used to send e-mail traffic, which uses TCP port 25
Answers
1. A, C, D. All of these are valid methods of securing DNS except choice B, because DNS does not have any built-in encryption capabilities, as it is a non-secure protocol.
2. C. Both SSL and TLS use TCP port 443.
3. C. HTTPS uses SSL and TLS to secure its traffic.
4. A. In this scenario, FTPS is the best secure solution, since it uses the built-in capabilities of encryption and authentication of SSL or TLS.
5. B. Telnet is a remote administration protocol that is inherently non-secure and exposes user credentials to sniffing and interception because they are transmitted in plaintext.
6. D. SSH uses TCP port 22; Telnet uses TCP port 23.
7. A. SCP would be considered an appropriate utility for use when a user needs to send a few files securely to another host during a single SSH session.
8. B. POP3 uses TCP port 995 when tunneled through SSL or TLS.
9. D. IMAP4 allows multiple client connections to the user’s account and uses TCP port 993 in conjunction with a secure SSL/TLS connection.
10. D. SMTP is non-secure server protocol used to send e-mail traffic, which uses TCP port 25.