Lesson 13: Implementing Secure Network Applications Flashcards
HyperText Transfer Protocol (HTTP)
HTTP enables clients (typically web browsers) to request resources from an HTTP server. A client connects to the HTTP server using an appropriate TCP port (the default is port
80) and submits a request for a resource, using a uniform resource locator (URL). The server acknowledges the request and responds with the data (or an error message).
The response and request formats are defined in an HTTP header. The HTTP payload is usually used to serve HTML web pages, which are plain text files with coded tags (HyperText Markup Language) describing how the page should be formatted. A web browser can interpret the tags and display the text and other resources associated with the page, such as binary picture or sound files linked to the HTML page.
HTTP also features a forms mechanism (POST) whereby a user can submit data from the client to the server. HTTP is a stateless protocol; this means that the server preserves no information about the client during a session. However, the basic functionality of HTTP servers is often extended by support for scripting and programmable features (web applications). Servers can also set text file cookies to preserve session information. Technologies such as Java, ASP, and integration with databases increase flexibility and interactivity but also significantly increase security risks.
As with other early TCP/IP application protocols, HTTP communications are not secured. The popularity of the web has made it and related technologies (such as browsers and plug-ins) a popular target for different attacks.
Web servers should be deployed using configuration templates where possible. Some basic hardening procedures include the following:
• Most web servers must allow access to guests (that is, unauthenticated users). The guest account must be secured so that it cannot be used to modify any data on the server (it should be granted read-only or browse permissions only). The guest account on IIS is called IUSR_ServerName; an account named httpd or apache is typically configured for guest access to Apache®. The guest account should have no permissions outside the directory set up for browsing.
Note: Guests may require execute permissions on scripts and applications that you want them to be able to run, and these may be stored in a directory outside the root of the website.
- When a web server is leased, a secure means of uploading files and configuration changes needs to be used (SSH, for example). Most hosting packages include a GUI management application such as cPanel. Remember that ordinary FTP connections are not secure (critically, authentication information is transmitted in plaintext).
- When a web server is connected to a private network, the location of the server should be carefully considered so as not to expose the private network to attack from the public one through the web server. This is typically achieved by placing a firewall between the web server and the local network, creating a Demilitarized Zone (DMZ).
- Use separate accounts to administer servers in the DMZ, and ensure that the accounts do not share credentials with any other accounts on the LAN.
- Web servers are typically installed with sample pages (and even scripts) along with help documentation. These samples sometimes contain vulnerabilities and should be removed from a production server.
- Logging provides valuable information regarding the use of the website, alerts of any unusual or suspicious behavior, and audit changes made to pages and settings.
Secure Sockets Layer (SSL)
developed by Netscape in the 1990s to address the problems with the lack of security in HTTP. SSL proved very popular with the industry. Transport Layer Security (TLS) was developed from SSL and ratified as a standard by IETF. SSL/TLS works as a layer between the application and transport layers of the TCP/IP stack. It is usually used to encrypt TCP connections. It is typically used with the HTTP application (referred to as HTTPS or HTTP Over SSL or HTTP Secure) but can also be used to secure other TCP application protocols, such as Telnet, FTP, NNTP, SMTP, or LDAP.
To implement HTTPS, a server is assigned a digital certificate signed by some trusted certificate authority (CA). The certificate proves the identity of the server (assuming that the client trusts the Certificate Authority). The server uses the digital certificate and the SSL/TLS protocol to encrypt communications between it and the client. This means that the communications cannot be read or changed by a third party.
The initial connection is governed by the SSL/TLS Handshake sub-protocol:
- The client makes a connection request (CLIENT_HELLO) listing the highest protocol version, cipher suites, and compression algorithm(s) supported. It also sends the date and time plus a random number (ClientRandom), which is used to generate the secret key. The client may also specify a session ID, allowing resumption of an existing session without re-generating keys (which is processor intensive).
Observing the TLS handshake in a Wireshark packet capture—The CLIENT HELLO packet sends the cipher suites supported (amongst other data). (Screenshot used with permission from Wireshark.)
Note: In this context, SSL 3.1 is used to mean TLS. Most implementations do not actually support any compression technologies.
- The server responds with SERVER_HELLO, selecting the highest protocol version and strongest cipher suite supported by both, and its own randomly generated number (ServerRandom), along with any session information.
- If client and server support compatible versions and ciphers, the server sends its X.509 certificate to the client (CERTIFICATE command) followed by the SERVER_DONE command.
Note: A server can optionally request a certificate from the client, providing mutual authentication. More commonly, the client is untrusted.
- The client checks the server’s certificate and if verified, responds with CERTIFICATE_VERIFY. It then performs key exchange or key agreement to select the secret session key for use with the confidentiality cipher, such as AES. This process can be completed using either RSA or Diffie-Hellman. If using RSA, the client generates a pre-master secret, encrypts it using the server’s public key, and sends it to the server.
- The server and client then follow the same steps to derive a shared master secret from the pre-master secret and the ClientRandom and ServerRandom values.
- Client and server then exchange the CHANGE_CIPHER_SPEC command, to indicate that subsequent communications will be encrypted, and the FINISHED command, which contains a digest of the command exchange that is used to verify that the handshake process has not been tampered with.
- Once the session is established, client and server exchange encrypted data in SSL/TLS records, which are placed into transport layer packets for delivery.
SSL/TLS supports most of the major symmetric and asymmetric ciphers.
- Asymmetric ciphers (key exchange and authentication)—RSA, DSA/DSS, and Diffie-Hellmann.
- Symmetric ciphers (confidentiality)—RC4, RC2, DES, 3DES, IDEA, AES.
- Hashed Message Authentication Code (HMAC) function—MD5 or SHA.
- A cipher suite is written in the following form:
ECDHE-RSA-AES128-GCM-SHA256
This means that the server can use Elliptic Curve Diffie-Hellman Ephemeral mode (and supports Perfect Forward Secrecy) for session key agreement, RSA for authentication, 128-bit AES-GCM (Galois Counter Mode) for symmetric encryption confidentiality, and 256-bit SHA for HMAC functions. Suites the server prefers are listed earlier in its supported cipher list.
Transport Layer Security
While the name SSL is still widely used, the Transport Layer Security versions are the only ones that are safe to use. SSL and TLS versions are not interoperable; that is, a client supporting only SSL 3.0 could not connect to a server supporting only TLS 1.0. A server can provide support for legacy clients, but obviously this is less secure. For example, a TLS 1.2 server could be configured to allow clients to downgrade to TLS 1.1 or 1.0 or even SSL 3.0 if they do not support TLS 1.2.
Note: A downgrade attack is where a Man-in-the-Middle tries to force the use of a weak cipher suite and SSL/TLS version.
SSL 2.0 and 3.0 are both deprecated, and SSL 1.0 was never used commercially. TLS 1.2 is widely supported now, and older versions should only be deployed when subject to risk assessments. The most notable changes between TLS 1.0, 1.1, and 1.2 are improvements to the cipher suite negotiation process (the means by which server and client agree to use the strongest ciphers available to both) and protection against known attacks. TLS 1.2 also adds support for the strong SHA-256 cipher.
TLS version 1.3 was approved in 2018. One of the main features of TLS 1.3 is the removal of the ability to perform downgrade attacks by preventing the use of unsecure features and algorithms from previous versions. There are also changes to the handshake protocol to reduce the number of messages and, therefore, speed up connection establishment. TLS 1.3 cipher suites only include the mechanisms used for confidentiality and integrity (AES with SHA, for instance). Key exchange/agreement and authentication algorithms are specified separately. This should make selecting the algorithms simpler and less prone to configuration errors as there isn’t a list of 30 or more cryptically named suites to choose from and it allows the actual cipher negotiation process to be streamlined.
SSL/TLS accelerator
Public key encryption calculations are relatively intensive in terms of CPU and memory resources. An SSL/TLS accelerator is a hardware device with a specialist chipset—Application Specific Integrated Circuit (ASIC)—dedicated to performing these calculations. They are usually implemented as plug-in cards for server equipment or load balancing appliances and therefore can be placed anywhere in the network where SSL/TLS offloading is desired.
SSL decryptor, inspector, or interceptor
An SSL decryptor, inspector, or interceptor is a type of proxy used to examine encrypted traffic before it enters or leaves the network. This ensures that traffic complies with data policies and that encryption is not being misused, either as a data exfiltration mechanism or to operate a Command & Control (C2) Remote Access Trojan. An SSL decryptor would be positioned at the network edge and implemented as a transparent bridge. This makes it almost impossible for an adversary to evade the device, unless there is a separate backdoor network channel. The drawback is that the decryptor appliance will be a single point of failure, unless a load balancing and failover system is implemented.
Some typical functions of SSL decryptors include:
- Block connections that use weak cipher suites or implementations.
- Block connections that cannot be inspected (for instance, they do not use a standard enterprise certificate).
- Do not inspect authorized traffic that is subject to privacy or compliance regulations.
- Integrate with IDS, DLP, and SIEM to apply security policies and provide effective monitoring and reporting.
Employees may require access to all kinds of subscription services. Some examples include:
- Market and financial intelligence and information.
- Security threat intelligence and information.
- Reference and training materials in various formats (ebook and video, for instance).
- Software applications and cloud services paid for by subscription rather than permanent licenses.
Most of this sort of content will be delivered by a secure web site or cloud application. It may be necessary to provision authentication mechanisms for enterprise Single-Sign On (SSO) access to the services.
Another use of subscriptions is a web feed, where updated articles or news items are pushed to the client or browser. Web feeds are based on either the Really Simple Syndication (RSS) or Atom formats, both of which use eXtensible Markup Language (XML) to mark up each document supplied by the feed. It is possible that such feeds may be vulnerable to XML injection style attacks, allowing an attacker to show malicious links or even interact with the file system (https://mikeknoop.com/lxml-xxe-exploit).
Note: Subscription services may also describe the outsourcing of network and security components and procedures. There may also be subscription use of enterprise cloud applications, which may be mediated by an access broker.
file transfer
There are many means of transferring files across networks. A network operating system can host shared folders and files, enabling them to be copied or accessed over the local network or via remote access (over a VPN, for instance). Email and IM applications allow file transfer using attachments to messages. HTTP supports file download (and uploads via various scripting mechanisms). The TCP/IP FTP protocol and various peer-to-peer file sharing products can be used to transfer files more quickly and efficiently, however.
File Transfer Protocol (FTP)
A File Transfer Protocol (FTP) server is typically configured with several public directories, hosting files, and user accounts. Each user account can be configured with different permissions over files and directories. Most HTTP servers also function as FTP servers, and FTP services, accounts, and directories may be installed and enabled by default when you install a web server. FTP is more efficient compared to file attachments or HTTP file transfer, but has no security mechanisms. All authentication and data transfer are communicated as plain text, meaning that credentials can easily be picked out of any intercepted FTP traffic.
Note: Do not re-use secure passwords (such as Windows authentication passwords) for FTP applications. Any password used for FTP should be regarded as unsecure.
FTP clients usually have GUIs to help the user, though FTP can be performed over a command line as well. Most web browsers can function as basic FTP clients.
Note: You should check that users do not install unauthorized servers on their PCs (a rogue server). For example, a version of IIS that includes HTTP, FTP, and SMTP servers is shipped with client versions of Windows, though it is not installed by default.
Trivial File Transfer Protocol (TFTP)
a connectionless protocol (utilizing UDP port
69) that also provides file transfer services. It does not provide the guaranteed delivery offered by FTP and is therefore only suitable for transferring small files. Also, it only supports reading (GET) and writing (PUT) files, not directory browsing, file deletion, or any of the other features of FTP. An example of the usage for TFTP might be a switch or router automatically downloading configuration files.
SSH FTP (SFTP)
addresses the privacy and integrity issues of FTP by encrypting the authentication and data transfer between client and server. In SFTP, a secure link is created between the client and server using Secure Shell (SSH) over TCP port 22. Ordinary FTP commands and data transfer can then be sent over the secure link without risk of eavesdropping or Man-in-the-Middle attacks. This solution requires an SSH server that supports SFTP and SFTP client software.
Another means of securing FTP is to use the connection security protocol SSL/TLS. As with SMTP, there are two means of doing this:
- Explicit TLS (FTPES)—use the AUTH TLS command to upgrade an unsecure connection established over port 21 to a secure one. This protects authentication credentials. The data connection for the actual file transfers can also be encrypted (using the PROT command).
- Implicit TLS (FTPS)—negotiate an SSL/TLS tunnel before the exchange of any FTP commands. This mode uses the secure port 990 for the control connection.
FTPS is tricky to configure when there are firewalls between the client and server. Consequently, FTPES is usually the preferred method.
Simple Mail Transfer Protocol (SMTP)
The Simple Mail Transfer Protocol (SMTP) specifies how mail is delivered from one system to another. It is a relatively straightforward protocol that makes the connection from the sender’s server to that of the recipient and then transfers the message. The SMTP server of the sender discovers the IP address of the recipient SMTP server using the domain name part of the email address. The SMTP server for the domain is registered in DNS using a Mail Exchanger (MX) record.
SMTP communications can (and should) be secured using the SSL/TLS version of the protocol (SMTPS). This works much like HTTPS with a certificate on the SMTP server and a negotiation between client and server about which cipher suites to use. There are two ways for SMTP to use TLS:
- STARTTLS—this is a command that upgrades an existing unsecure connection to use TLS. This is also referred to as explicit TLS or opportunistic TLS. Note that despite the name, the connection can be configured to use legacy SSL versions if required.
- SMTPS—this establishes the secure connection before any SMTP commands (HELO, for instance) are exchanged. This is also referred to as implicit TLS.
The STARTTLS method is generally more widely implemented than SMTPS. Typical SMTP configurations use the following ports and secure services:
- Port 25—used for message relay (between SMTP servers or Message Transfer Agents [MTA]). If security is required and supported by both servers, the STARTTLS command can be used to set up the secure connection.
- Port 587—used by mail clients (Message Submission Agents [MSA]) to submit messages for delivery by an SMTP server. Servers configured to support port 587 should use STARTTLS and require authentication before message submission.
- Port 465—some providers and mail clients use this port for message submission over implicit TLS (SMTPS), though this usage is now deprecated by standards documentation.
Post Office Protocol v3 (POP3)
SMTP is only used to deliver mail to hosts that are permanently available. Mail users require the convenience of receiving and reading their mail when they choose. The Post Office Protocol v3 (POP3) is a mailbox protocol designed to allow mail to be stored on a server and downloaded to the recipient’s email client at his or her convenience.
A POP3 client application, such as Microsoft Outlook® or Mozilla Thunderbird®, establishes a TCP connection to the POP3 server over port 110. The user is authenticated (by username and password) and the contents of his or her mailbox are downloaded for processing on the local PC. POP3S is the secured version of the protocol, operating over TCP port 995 by default.
Internet Message Access Protocol v4 (IMAP4)
POP3 has limitations, which are addressed by the Internet Message Access Protocol v4 (IMAP4). POP3 is primarily designed for dial-up access; the client contacts the server to download its messages then disconnects. IMAP supports permanent connections to a server and connecting multiple clients to the same mailbox simultaneously. It also allows a client to manage the mailbox on the server (to organize messages in folders and control when they are deleted, for instance) and to create multiple mailboxes. Clients connect to IMAP over TCP port 143. They authenticate themselves then retrieve messages from the designated folders. As with other email protocols, the connection can be secured by establishing an SSL/TLS tunnel. The default port for IMAPS is TCP port 993.
Note: POP and IMAP also support the STARTTLS command, but this is not often used in practice, with implicit TLS over the default secure ports much more widely implemented.
Secure/Multipurpose Internet Mail Extensions (S/MIME)
Connection security goes a long way toward preventing the compromise of email accounts and the spoofing of email, but there is still a need for message authentication and confidentiality in many scenarios. One means of doing this with PKI is called Secure/Multipurpose Internet Mail Extensions (S/MIME).
To use S/MIME, the user is issued a digital certificate containing his or her public key, signed by a CA to establish its validity. The public key is a pair with a private key kept secret by the user. To establish the exchange of secure emails, both users must be using S/MIME and exchange certificates:
- Alice sends Bob her digital certificate, containing her public key and validated digital ID (distinguished subject name and email address). She signs this message using her private key.
- Bob uses the public key in the certificate to decode her signature and the signature of the CA (or chain of CAs) validating her digital certificate and digital ID and decides that he can trust Alice and her email address.
- He responds with his digital certificate and public key and Alice, following the same process, decides to trust Bob.
• Both Alice and Bob now have one another’s certificates in their trusted certificate stores.
- When Alice wants to send Bob a confidential message, she makes a hash of the message and signs the hash using her private key. She then encrypts the message, hash, and her public key using Bob’s public key and sends a message to Bob with this data as an S/MIME attachment.
5.
Bob receives the message and decrypts the attachment using his private key. He validates the signature and the integrity of the message by decrypting it with Alice’s public key and comparing her hash value with one he makes himself.
One complication in this scenario is that it assumes Alice and Bob are using the same private and public key pair, both to sign messages and to allow recipients to encrypt messages. This is not recommended for communication requiring very high levels of security. A key pair used for encryption/decryption should normally be backed up or kept in escrow because if it is lost, the data encrypted with it will also be lost. However, if the same key pair had been used for signing messages, obtaining the backup or escrow key would allow someone to impersonate the user (breaking the principle of non-repudiation). Using separate private key pairs is referred to as a dual key pair. The following key usage OIDs must be specified in each certificate:
- Signing—digital signature or non-repudiation OID.
- Encryption—key agreement or data encipherment OID.
Not all email clients support the use of dual key pairs.
Spam
unsolicited email. Dealing with spam wastes resources (computer and human). Most new email application software has spam filtering built-in. This is an appropriate solution for home users, but on enterprise networks, if spam has already reached the user’s mailbox, then it has already wasted bandwidth and taken up space on the server. Consequently, most companies deploy a gateway server with spam filtering technology. This can either be installed in-house or leased from a provider.
A secure configuration for email is to install an email relay server in a demilitarized zone (DMZ).
The mail relay can be installed with software to monitor and filter email traffic, checking for spam and infected file attachments.
Apart from message-based filtering and using blacklists (to block mail servers or domains known to send spam), there are many other methods for trying to reduce spam. As with filters, though, these can generate numerous false positives (that is, block legitimate traffic). Some examples include:
- Whitelist—if an organization only deals with a limited number of correspondents, they can set up a whitelist of permitted domains or use some sort of authentication between the mail servers.
- SMTP standards checking—rejecting email that is not strictly RFC-compliant can block some spam, but may also block legitimate traffic.
- rDNS (reverse DNS lookup)—rejecting mail from servers where the IP address does not match the domain in the message header or is a dynamically assigned address.
- Tarpitting—introducing a delayed response to the SMTP session. This makes the spammer’s server less efficient; in many cases, the spamming software will simply give up.
- Recipient filtering—blocking mail that is not addressed to a valid recipient email address.