HTTP | Support Protocols

The Hyper Text Transfer Protocol (HTTP) is one of the most well known, and well used, protocols on the Internet. It is the protocol by which Web pages are transmitted from Web servers to clients, but it is also used by many other applications to send data between computers. For example, many peer-to-peer clients make use of the solid structure of HTTP to transfer data segments of shared files between peers. HTTP can be used to transmit both ASCII and binary data between computers.

HTTP is commonly used in the VoIP community as a way for administrators to remotely administer and configure devices. Many network management devices offer a Web-based administration panel by which the device can be altered and configured for a particular environment. Many such devices also require user authentication to be able to fully access the configuration data.

HTTP was first described in RFC 1945 at HTTP 1.0 by its founder, Tim Berners-Lee. Currently, RFC 2616 is used to describe the HTTP 1.1 protocol; however, various other RFCs describe additional extensions and uses for the HTTP protocol. These include HTTP Authentication (RFC 2617), Secure HTTP (RFC 2660), and CGI (RFC 3875).

HTTP Protocol

The function of HTTP and its protocol was designed to be very straightforward and usable by many applications. When a client wishes to request a file from an HTTP server, it simply creates a TCP session with the server and transmits a GET command with the name of the requested file and the HTTP protocol version (for example, GET /index.html HTTP/1.1). The HTTP server then responds back with the appropriate data. The response from the server will be either the data requested by the client, or an error message describing why it cannot send the data. All of the commands within the HTTP protocol are sent in regular ASCII text, with each line followed by a carriage return/line feed (CR/LF). In network logs, the CR/LF appear as hexadecimal 0x0D0A.

HTTP Client Request

For a client to retrieve data from an HTTP server, it must know the exact filename and location to construct an appropriate file request. For most purposes, this information is supplied in the form of a uniform resource locator (URL), which specifies a particular HTTP server, directory path, and file name (for example, www.digg.com/faq/index.php). When a client wishes to view this specific page, index.php, it must first make a connection to www.digg.com. This is performed by resolving the domain name to an IP through DNS, which results in the IP address of 64.191.203.30. The client then initiates a TCP connection to 64.191.203.30 and makes a request of GET /faq/index.php HTTP/1.1. This request also includes other information about the client, some of which may be required for HTTP 1.1, such as the host value. An example of a full HTTP GET request is shown next:

GET /download.html HTTP/1.1
Host: www.ethereal.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
Accept: \
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain; \
q=0.8,image/png,image/jpeg,image/gif;q=0.2,*/*;q=0.1
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859–1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://www.ethereal.com/development.html

HTTP Server Response

Upon receiving a GET request from a client, a server first ensures that the file requested does exist. If it does, the data is then sent back to the requesting client. If not, an error message is sent. Regardless of the action, a specific server response is sent back to the client that includes a status code. This status code informs the client of the response type. The most common is a 200 code, which informs the client that the file was found and will be sent. It is transmitted in the form of HTTP/1.1 200 OK, which specifies the HTTP protocol version, the status code, and a brief description of the code. Other common status codes include “404 Not Found,” which indicates that the requested file could not be located by the server, and “500 Internet Server Error” which indicates that there is a problem with the HTTP server. The following is an example of an HTTP response:

HTTP/1.1 200 OK
Date: Thu, 13 May 2004 10:17:12 GMT
Server: Apache
Last-Modified: Tue, 20 Apr 2004 13:17:00 GMT
Accept-Ranges: bytes
Content-Length: 18070
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: t ext/html; charset ++ ISO-8859–1

Security Implications for HTTP

Due to the simple design of HTTP, and the early state of the Internet when it was unveiled, security wasn’t a high priority in the protocol. All data sent through HTTP was sent as clear text, which allowed any person to be able to sniff the traffic flowing across the wire and parse out sensitive data, such as usernames, passwords, and network configuration data. This is particularly dangerous since many VoIP and network management devices use HTTP as a means to allow administrators to check the status of the device and to configure additional settings. A person with malicious intent on the same network segment as the device could pick out various usernames and passwords that may work on additional computers or devices.

HTTP also supports multiple forms of authentication, which is a means by which the HTTP server can verify a user’s identity. The two authentication forms currently used are basic and digest authentications. When a server supports authentication, it sends a 401 “Authentication Required” response to clients that request sensitive data. This response will also include a “realm” (a name associated with the Web site) that notifies the user what they are accessing. When a client receives such a response, it will provide a log-in window to the user to input a valid user name and password. These values will then be transmitted back to the requesting server for verification. Because of HTTP’s design, though, these credentials will have to be constantly transmitted to the server for every further data transmission. Each of these transactions will transmit the user name and password in the clear.

Another form of authentication supported by modern HTTP clients and servers is digest authentication, which is described in depth in RFC 2617. Digest authentication has an advantage over basic authentication in that it does not send a clear password over the network. Instead, an MD5 (Message Digest) value of the password is transmitted to the requesting server. The server then uses this digest value for password comparisons. However, digest authentication is not fully supported in many older Web browsers. It also does not fully protect a user’s credentials. The user name and other information about the user are still transmitted in the clear. And, even though the password is obfuscated, a skilled, malicious user can still capture the MD5 value and use it for future transactions with that particular server to use another person’s account.

Many devices have recently provided support for HTTPS to overcome the openness of the HTTP protocol. HTTPS is a modification of HTTP wherein all data between a client and server are encrypted using the Secure Sockets Layers (SSL). In order for HTTPS to function, both the server and the client must be able to support it, and it must be specifically chosen as the form of communication in the URL. For example, instead of http://www.foo.com, a secure connection would use https://www.foo.com.

TFTP | Support Protocols

The Trivial File Transfer Protocol (TFTP) is a simplified protocol used to transfer files from a server to a client. Unlike more evolved file protocols, such as FTP, TFTP was designed to work in pure simplicity, requiring less overhead and interaction. Its primary usage today is in computers and devices that do not have storage devices, commonly known as “thin client PCs.” Without offline storage, especially one that can be updated, it is difficult to maintain how such devices can operate. Instead of booting off of a hard drive or flash ROM, these devices use TFTP to request data from a central server to boot from. Or, such devices can boot from internal ROM memory and use TFTP to request configuration data to use during their operation. Also, devices can use TFTP to request firmware updates which they can then flash to their ROM chips to update the built-in software code. This is especially useful since customized sets of data can be stored for individual user devices within a corporate environment.

The role of TFTP in transferring data is well used throughout the computer industry. Virtually all modern computers support the ability to boot from the network. In this mode, the computer will attempt to locate a TFTP server on its network segment once it boots. In finding one, the client requests a bootable image from the server, usually in the form of a floppy disk image. Once it has received the data, the client will then proceed to boot from the image, as if it was an actual floppy disk or CD-ROM.

In the VoIP community, TFTP has a critical role in allowing VoIP devices and telephones to obtain configuration data from centralized servers. These devices are built with internal Flash ROM memory chips that contain simplified hardware architecture that does not allow for continual write access to memory. Instead, data is only written once to the device’s memory and read continuously by the internal operating system.

The TFTP protocol was first described in 1980 as IEN (Internet Experiment Note) 133. Its first formal RFC was RFC 783, which was later updated in RFC 1350. However, there are various RFCs that also describe individual actions and abilities that TFTP could be used for. These include Bootstrap loading (RFC 906) and TFTP multicasting (RFC 2090). The next few sections of the chapter detail a high-level overview of the TFTP architecture and several related security threats associated with the protocol.

TFTP Security Concerns

In order to better understand and be able to address the security concerns associated with TFTP properly, it is important to have at least a high-level understanding of how TFTP works. Unlike most other file transfer protocols, TFTP operates by transmitting UDP packets. While connection-less UDP packets are generally frowned upon for reliable data transmissions, they allow for a simpler implementation into the protocol, as well as faster transfer speeds. The abilities of the protocol are also very limited, allowing only for the ability to read and write data. The protocol does not have any mechanism displaying information about available files and directories on a server. The client must know the name of the file that they wish to download when connecting.

There are very strict regulations on how data is sent between computers, which allows for client applications to be written easier. Similar to the FTP protocol, TFTP allows for data to be sent as either ASCII or binary. This data is sent in individual UDP packets between the two devices. Of these packets, five types can be transmitted, each one identified by an operation code in the header of the data.

• Read Request (RRQ)
• Write Request (WRQ)
• Data
• Acknowledgement (ACK)
• Error

TFTP File Transfer Operation

When a client wishes to download a file from a TFTP server, it first sends a Read Request (RRQ) packet to the TFTP server. This packet identifies itself as an RRQ packet, and also specifies both the name of the file the client wishes to download and the data mode (binary or ASCII). Likewise, if the client wishes to upload a file to a TFTP server, it sends an identical Write Request (WRQ) packet, which also contains the file name and data mode. The sending computer then immediately starts sending data packets to the recipient computer. If the data is greater than 512 bytes in size, multiple packets will be sent. A packet that contains a data portion smaller than 512 bytes is seen as the last packet in the transfer. Following the receipt of each data packet, the receiving computer sends an acknowledgement (ACK) packet to the sender, notifying it that the transfer was successful. Figure 1 details this transfer of data between two computers.

 
Figure 1: TFTP Data Transferral

Security Implications for TFTP

Insomuch that TFTP was designed for simplicity and ease of use, any mechanisms normally used to secure data were not implemented into its protocol It was originally planned by engineers that usernames and passwords should not ever be required for TFTP access, but this has led to many security issues. This concern is also greater because all TFTP packets are sent in the clear across a network, with no data encryption. Given there is no authentication, and no encryption, TFTP is generally not recommended for the transfer of sensitive data. However, its role as a “bootstrap protocol” could allow usernames and passwords to be transferred in the clear across a network when these aren’t protected by higher-level mechanisms. Since TFTP is often used to download boot images from a remote server, and these images often contain sensitive data required to connect into various servers on the network, it is possible to retrieve stored account information from within these boot images. Any person who is capturing network traffic on the same network segment as the TFTP session could easily gather the transferred data and re-create the original file. If the file contains sensitive data, such as usernames and passwords, it would then be readily available to anyone capturing the traffic.

Warning

The TFTP protocol sends all data in clear text across the network. As it is commonly used to transfer configuration data to devices and clients, it is important to verify that there is no sensitive data contained within transferred data. Otherwise, anyone sniffing the wire could have access to various usernames and passwords used by such devices.

DNS | Support Protocols

The Domain Name System (DNS) is a static hierarchical name resolution architecture that relies on client/server communication for operation. DNS is a protocol that many use every day and may not know it. Whenever someone browses the Internet, DNS is used in the background to translate host names into IP addresses so that the proper network destinations can be found. DNS is equally important in VoIP networks for its ability to resolve destination endpoint addresses or allow gateway registration to call servers and gatekeepers by host name.

DNS was created so that no one would be required to memorize the IP addresses of every host on a private network or the Internet. Most people have a hard enough time remembering one or two passwords, let alone several billion IP addresses. With the development of DNS, the only requirement is knowledge of the target Web page name that you wish to go to. DNS resolves the target Web page name entered into one or more server IP addresses. It has also been designed to allow the reverse or “inverse” resolution of IP addresses to host names.

The DNS architecture was first discussed in detail in RFCs 881 through 883, and later updated in RFCs 1034 and 1035. Several of the newer RFCs include recommendations for how to secure the DNS architecture, including the addition of DNS security extensions (DNSSEC) beginning with RFC 4033. The next few sections detail a high-level overview of the DNS architecture and several security threats associated with DNS systems.

DNS Architecture

In order to better understand and be able to address the security concerns associated with DNS properly, it is important to have at least a high-level understanding of how DNS works. The hierarchy previously mentioned for DNS exists as a pyramid, with the highest level of the DNS architecture at the top. DNS is organized into myriad logical groupings called domains, which are further segmented into an endless number of subdomains. Figure 1 illustrates a sample hierarchy of the DNS system and is by no means exhaustive. The intent is to show the structure of the hierarchy.

Figure 1: Sample DNS Architecture

Located at the top of the DNS hierarchy are the root DNS servers. The root DNS servers are located in the root DNS zone, annotated by a single “.”, and are responsible for maintaining the location of the top-level domain servers (TLD). ATLD DNS server is one that is responsible for the management of one of the commonly associated address suffix identifiers, such as .com, .net, .edu, or .org. The TLD DNS servers are assigned or “dele-gated” the responsibility by the root DNS servers. They are known as the authoritative server for that TLD. Likewise, the TLD DNS servers delegate the management of one of their many subdomains. The subdomain DNS servers for .brad.com would be responsible for any resource records (RR) for that subdomain as well as the location of any related subdomains (.hr.brad.com). The resource records are the entries for the host systems. This process of delegation distributes the load of the DNS system across many different servers.

Fully Qualified Domain Name

Each host has its own pointer for DNS, known as a fully qualified domain name (FQDN). The FQDN is used to identify the path taken through the DNS architecture to find the requested host. Figure 2 illustrates what path is taken through the previously discussed DNS hierarchy from Figure 1 to reach host pc1.

Figure 2: Fully Qualified Domain Names

There are a couple of things to keep in mind about FQDNs. First of all, the explicit FQDN path from the top of the hierarchy (root) is read from right to left. Secondly, even though most FQDN illustrations do not include the final dot to represent the root domain, it is an implied part of the complete FQDN. Most applications, like IE, will not append a trailing “.” to the end of a requested Web resource. Followed from right to left, the host pc1 follows a path out of the root domain, through the TLD .com, to the .com subdomain .brad.com, and then finally into the .brad.com subdomain of .hr.brad.com.

FQDNs are entered into the DNS tables as one of several types of RRs:

• A An A record is an address record, denoting a standard host entry in the DNS table. The key here is that it is used to resolve an FQDN to an IP address.
• PTR PTR records are used by the inverse lookup zones in DNS. The PTR record resolves an IP address to an FQDN.
• SOA The SOA record identifies zone information such as the zone name and serial number.
• MX MX records identify mail servers for the zone.
• NS NS records are used for name servers for the zone.
• CNAME CNAME records act as alias records to allow for the translation of one host name into another.
• INFO Provides information about hosts listed in the DNS table.
• SRV SRV records identify SIP servers for the zone.

DNS Client Operation

In order to locate the IP address for a host, the client’s application will send a request to a resolver on the same client system. The resolver will then formulate and send out the DNS query. From a high level, the query will typically follow a path of trial and error known as a recursive lookup. Figure 3 illustrates what a recursive lookup from a host, pc2, would look like to find the IP address for host pc1.

Figure 3: Recursive Lookups Using DNS

1. The client’s resolver sends its DNS query which will be sent to the root domain.
2. The root domain server does not have the RR for the host pc1, so the response is sent to redirect the resolver on pc2 to the TLD DNS server for .com since it knows where .com. is.
3. The resolver, in turn, sends a query to the TLD DNS server for .com.
4. The TLD DNS server does not have the RR for the host pc1, so the response is sent to redirect the resolver on pc2 to the .brad.com. DNS server since it knows where .brad.com. is.
5. The resolver, in turn, sends a query to the DNS server for .brad.com.
6. The .brad.com. DNS server does not have the RR for the host pc1, so the response is sent to redirect the resolver on pc2 to the .hr.brad.com. DNS server since it knows where .hr.brad.com. is.
7. The resolver, in turn, sends a query to the DNS server for .hr.brad.com.
8. The authoritative DNS server for .hr.brad.com. has the RR for the host pc1 and sends back the information to pc2. pc2 now has the IP address information for pc1, and may use it accordingly.

Note

It is not required to have a separate DNS server for each subdomain. A single DNS server may be the authoritative server for many, or all, of the subdomains in a corporation, although there are usually backup DNS servers configured for each primary DNS server.

DNS Server Operation

The DNS server is responsible for cataloging all of the RRs that belong to any of the zones that it is the authoritative DNS server for. It is also responsible for keeping track of any of the DNS servers that it has delegated subdomain responsibility to. By keeping track of the subdomains, the DNS server is able to redirect client queries to the proper location in the event that the requested host RR does not reside on that server.

DNS servers may also be configured to maintain a cache of domain names, as well as their respective IP addresses, as they are requested by clients. This configuration allows a DNS server to retrieve an IP address only once and then store the value for any subsequent queries by the same client or any other client. These entries are cached for only a short period of time, equal to the Time To Live (ttl) value applied to the record. When a client requests a particular domain name resolution, the DNS server will first attempt to find the records in its local database. If this search fails, the DNS server will attempt to contact a root name server, if it’s been configured to do so, to request the value.

Another important function that the DNS servers provide is the replication of the DNS table, also known as a zone transfer. The zone transfer insures that all entries for a given zone will be available on all DNS servers in that zone. This is necessary so that DNS can provide a resilient operating architecture. Two types of zone transfers can be found between DNS servers: full and incremental. A full zone transfer is exactly as it sounds, a complete transfer of zone information between DNS servers. An incremental zone transfer, on the other hand, is one where only changed zone information is exchanged between DNS servers. Incremental zone transfers make more efficient use of bandwidth and network resources, but not all DNS server vendors support the newer implementation.

Zone transfers are based on several items, including serial numbers and refresh intervals. The secondary DNS server will request a zone transfer from the primary DNS server and there is a serial number embedded in the response. If the secondary server receives the response and the serial number is lower than or equal to the serial number of its current table version, the response will not be used to update the server’s table. However, if the serial number is higher, the DNS table will be updated to what is enclosed in the response.

The refresh interval is used to identify how often the secondary server should request a zone transfer from the primary server. It is used as a polling mechanism to help ensure that the secondary server remains up-to-date with the current DNS information. NOTIFY messages may also be used by the primary DNS server to tell the secondary DNS servers when changes have been made to the DNS table. When the secondary DNS server receives the NOTIFY, they can request a zone transfer to ensure table synchronization.

Security Implications for DNS

DNS is a core component of modern networking, and as such, is a rather attractive target for many attackers. When the DNS architecture was developed, security was not included as part of the design. There was nothing designed into the architecture for peer authentication, origin authentication, or data encryption. Some recent advancements in DNS have helped to alleviate some of the current security concerns, but they have not been able to remove them altogether.

The dangers of DNS are well publicized and well documented, owing to its long life on the Internet. More information on these security threats, how they are performed, and how to protect your DNS servers can be found at www.dnssec.net/dns-threats.php. There is also an RFC on DNS Threats, published as RFC 3833. Several types of attacks should be kept in mind regarding your DNS deployment, and some best practices can be employed to help lessen your exposure:

• DNS footprinting (using DNS zone data to learn host names, subdomains, and subnets)
• Denial of Service (DoS)
  1. SYN flooding of DNS server
  2. Transfer of blank DNS table

• DNS cache poisoning