Sockets and Services from a Security Point of View

  • Article
Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

By Matthew Strebe ,Charles Perkins

Chapter 4 from Firewalls, 24 seven, published by Sybex, Inc.

In Chapter 3 you saw the first four layers of the OSI stack—those layers which transfer data, irrespective of what that data is, from one computer to another over the Internet. This chapter focuses on the security implications of the types of data exchanged between computers using those lower-level protocols. We'll talk about common protocols, such as HTTP and FTP, hidden or problematic ones such as RPC and Finger, as well as obscure ones like BootP and SNMP.

A network intruder will look for security weaknesses at every point in your network architecture. If you have adequately locked down the Physical, Data Link, Network, and Transport Layers of your network, the wily hacker will simply move up to those protocols and services your network does expose to the Internet. These application-specific protocols are actually much easier to exploit, so many hackers start there and drop down to the network or transport level when they need to circumvent a protocol's security mechanisms.

In this chapter we'll go over each of the most commonly used Internet services, briefly examining each for their weaknesses and abuse potential. First, however, we'll discuss sockets and services in general, identifying typical service vulnerabilities so you can identify potential problems when you need to install services on your own network.

On This Page

Exploiting Socket-Based Services
Internet Names
The Protocols
Case Study: Leaving the Barn Door Open

Exploiting Socket-Based Services

Which services are safe to allow through your firewall, which are not safe, and which ones do you do need to keep an eye on? When a new service becomes popular, or when you want to give your network clients a new Internet-based tool, what do you look for when you evaluate the service?

Later in this chapter we will examine the most common protocols that use IP as a transport and are passed through firewalls. For those protocols, and for any others you may want to support in your network, you should ask the following questions:

  • How complex is the service?

  • How might the service be abused?

  • What information does the service dispense?

  • How much of a dialog does the service allow?

  • How programmable or configurable is the service?

  • What other services does the service rely on?

  • What sort of authentication does the service use?

How Complex Is the Service?

Complex services are easier to exploit than simple services. The Echo service, for example, simply transmits back to the client whatever the client sends to it. The Echo service is useful for debugging and for network connectivity testing, but it is difficult to see how the Echo service could be exploited to gain control of the computer running the service. Since the Echo service accepts data from the client, however, it must be programmed to correctly handle being fed too much data at once.

The mail service, on the other hand, is a large, complex piece of software that accepts data (mail) from and returns data to the client, as well as reads and stores data and configuration information on the computer's hard drive. Many mail services (POP and IMAP, for example) require authentication before the client can use the service. SMTP, on the other hand, allows any connecting user to send mail as though it came from any user—even a non-existent one. If the authentication mechanism can be subverted, the passwords hacked, or the service tricked into sending out private data (such as your password file), the hacker can use the service to get enough information to break into your computer through other means, such as FTP or Telnet.

Buffer Overruns and Denial-of-Service Floods

Buffer overruns are a potential weakness of all services that receive data from the client. Optimistic programmers expect network clients to play by the rules and only send as much data as would be appropriate for the protocol. For example, the destination address portion of an SMTP message should be somewhere between four and two hundred characters. But what if the client sends several megabytes instead?

A correctly written implementation of the protocol will simply discard the excess data and return an error. An incorrectly written implementation, which does not check how much data is being received, may overwrite its own program code and either crash or (if the sender of the data sent it maliciously) begin executing the excess data as a program.

Early versions of Sendmail had exactly this kind of security hole, and the infamous Internet Worm used this weakness to gain control of target computers and to bring the whole Internet to its knees.

A related attack for computers that store data (such as mail), is to keep sending data until the storage space on the server runs out. This is a denial-of-service attack that, although it does not give the hacker control of the computer, renders the computer unusable to its intended clients.

How Might the Service Be Abused?

Some services might be simple and innocuous in themselves, but can be turned to unexpected and detrimental uses. Chargen, for example, is a simple UNIX service that sends out ASCII characters over and over. Chargen is a useful network programming and testing tool because there are certain classes of networking problems that become evident when you can look at a stream of data spanning a whole range of binary representations. A communications channel that clears (or sets) the top two bits of every data word, for example, becomes obvious because the pattern of characters from Chargen will change as well.

An unscrupulous hacker, however, might exploit this protocol by forging a SYN packet (connection request) that redirects the output of Chargen to another computer and port. This way the hacker can flood the target computer with data that doesn't even originate from his own computer!

What Information Does the Service Dispense?

Some services may be simple, terse, and still dangerous to your network security. Finger, for example, was designed to help Unix users contact each other. A Finger request will tell you whether or not there is an account for an individual on a computer, what that account name is, when the user last logged on, additional contact information for the user, and whatever else that user would like to tell the world.

That information is certainly useful if you need to know a co-worker's email address or phone extension. It is also incredibly useful for a hacker who wants to verify the existence of an account, find a dormant one, and get clues to the identity and personality of an account holder. You won't find many computers on the modern Internet that support the Finger protocol. The Whois service is another one that you might not want to run on your network due to the amount of information it can give to a network intruder.

Services such as Whois and Finger are excellent time-saving tools for use within an organization, but you should never allow access to these services from beyond your internal network or your Intranet.

How Much of a Dialog Does the Service Allow?

A simple service with a regular interface is easier to secure than a complex service that uses an extensive dialogue with the client to provide its functionality. HTTP, for example (disregarding CGI, server applets, and Active Server Pages for the moment), is easy to secure because all the client can do is ask for a resource, and the server does not maintain data about the state of the connection between client requests (i.e. the protocol is stateless).

A stateful protocol is more difficult to secure, especially if the protocol requires client authentication at the beginning of the session and allows for many requests, replies and state changes after authentication. A stateful protocol must be tested for security holes for every state the client may place the server in. It is possible, for example, to hijack a Telnet session after an authorized client has established the connection and provided correct credentials.

Also, the more dialog a service allows, the more dangerous the service is when compromised. If a hacker arranges the Finger service to run at the wrong permissions level (such as root or Administrator), the hacker would still just get account and contact information from it. An FTP session at the supervisor level, however, could send the hacker any file in the computer. A root Telnet session would allow the intruder to do anything at all, including running programs, shutting down or starting services, replacing operating system code, as well as creating and deleting accounts.

Service Separation

FTP sites, Web sites, and Telnet hosts perform vital functions in today's Internet-connected networks. They create an Internet presence and facilitate communication within the organization as well as with outside customers and the rest of the world. You can't just decide not to run these services, but you can be careful about how you do it.

Because computers running these services are more vulnerable to being compromised, these services should not be run on computers that also host other internal services (i.e. the file server or a database server). Ideally, each Internet service would be run on its own server, but some services work well together (FTP is often used to update Web server content, for example).

How Programmable or Configurable is the Service?

The more configurable a service, the easier it is to get the configuration wrong. The more programmable the service, the more likely bugs are to pop up, creating loopholes for network intruders to jump through. So, Exchange Server (which has more configuration options than you can shake a stick at) and Internet Information Server (or any other Web server that allows you to run arbitrary scripts to generate Web pages) are more likely to contain a security weakness than simpler services such as the POP service that comes with the NT 4 resource kit.

What Sort of Authentication Does the Service Use?

Any service that requires authentication from the client is a potential security risk for two reasons: the authentication protocol may be weak, and users tend to use the same account names and passwords across multiple services.

POP is one example of weak authentication. The username and password is sent from the client to the server unencrypted, and the password is sent complete and unsalted. In POP, the server asks for the username and password, and the client just sends them. Compare this to MAPI (used by Microsoft Exchange), which uses a challenge-and-response protocol. With MAPI, the server requests the username and password, but also sends a value for the client to salt (pre-pend to) the password before the client hashes (scrambles) the password. The username and hashed password are then sent to the server. The server can compare the hash to a known hashed password to determine if the client should have access to the service. No eavesdropping computer can determine what the password is from the hash, and the same hash cannot be used more than once because the server changes the hash every time.

Anther common problem with authentication is insufficiently long passwords. LAN Manager style passwords, which are used in Windows for Workgroups and Windows 95, are weak because case sensitivity is ignored in the hash, and because the hash is comprised of two sections using the same seed that may be cracked in parallel. In addition, older Microsoft networking clients send the same password hashed with both the LAN Manager protocol and the Windows NT challenge and response protocol, seriously compromising the Windows NT hash.

The purpose of a strong password hash is to keep the hacker from intercepting the passwords as they travel from the client to the server. If the hacker can't intercept the password, he may just try to guess it. This is another area in which many protocols fail. A properly implemented protocol will detect an unusual number (three or greater) of failed password attempts and not allow any more logon attempts to that username or from that client. A weak protocol will allow as many attempts as the hacker can perform, and a clever hacker can write a program to perform hundreds of attempts per second, determining the true password by brute force. Windows NT by default will lock out any account but the Administrator account when there are too many failed password attempts.

It is easier to remember one password than a half-dozen, so many computer users use exactly the same password for all of their computer accounts. This means that if a network intruder penetrates one computer and captures the password list for that computer, one or more passwords and usernames from that computer are very likely to also work in another computer that is otherwise secure. Your password-protected service gives the hacker a double resource—if the hacker can find a password that works on that service, she'll try it elsewhere, and if she can find a password elsewhere, she'll try it on that service as well.

One Key Fits All

For convenience's sake, some services use the operating system username and password instead of recording a separate username and password pair for the service. While this feature makes life easier for the user, it also makes life easier for the hacker. When the hacker has obtained access to the service, it means that he has also obtained access to the underlying operating system. Internet Information Server for Windows NT (for password-protected Web pages) works this way, as do the POP and SMTP services that come on the NT 4 resource kit. Surprisingly, Microsoft's Exchange Server maintains a separate set of usernames and passwords for access to its services.

Internet Names

One of the most important higher-level services in the Internet Protocol Suite is the Domain Name Service. The lower-level Internet protocols all use IP addresses to identify source and destination computers, but people have a hard time remembering numbers. So, the architects of the Internet developed a service that will translate human-friendly Internet addresses like https://www.microsoft.com and https://www.linux.org into their corresponding computer-friendly IP addresses.

Dot Com and All That

In the beginning, people just kept a list of the human-friendly Internet addresses and their corresponding IP addresses (the host file is a remnant of this), but as the Internet grew these files got unwieldy, and a more flexible method was needed. The Internet architects came up with a new scheme that allowed an organization (or a person) to request an Internet address from a central authority and then expand on that name using their own authority. Thus was born the Internet Domain Name Registration system.

Human-readable Internet addresses, like IP addresses, contain dots. But Internet addresses can have as few as one dot or many more than four (although it is a rare address that will have more than a half-dozen). The dots function as separators, and the last portion of the address is called the top-level domain. Common top-level domains include .com, .org, .net, .mil, .gov, .edu, and two-character country codes such as .uk, .us, .cz, .au, and .oz.

When you request a domain name such as memetech.com, tribalgame.net, or robinsoncrusoefamily.org, you are staking out space on the Internet in a similar manner to when you obtain a range of IP addresses. It is up to you to further subdivide the name space. When you request the name, you provide the top-level service with the IP address of two servers that will handle name requests from your name space. When a computer wants to contact www.tribalgame.net, for example, it is up to the domain name servers that you specify to perform the translation from www.tribalgame.net to the actual IP address. Your servers can put any computer name you want below tribalgame.net, including this.is.a.very.long.domain.name.tribalgame.net.

A large organization or a service may further subdivide the name space. BigCorp, for example, might have separate domain name servers for each of its divisions in Asia, Europe, the US, and Africa. In this scenario, one domain name server would handle requests such as www.asia.bigcorp.com and a different one would handle requests such as www.us.bigcorp.com, allowing each division to configure their networks independently but maintain overall BigCorp control of the bigcorp.com domain.

DNS Queries

When you type https://www.microsoft.com into your Web browser, your computer needs to know what IP address corresponds to that Internet address. Microsoft's DNS (Domain Name System) server is the computer that contains that information. How does that information get from the Microsoft DNS server into your computer?

Your computer has the IP addresses of one or two DNS servers that it can ask about domain names (and unless you work in Redmond, neither one is likely to be the Microsoft DNS server that has the resolution you need). Your DNS servers most likely contain only Internet address to IP address mappings for your local network, and for a few frequently accessed external locations. When your local DNS server cannot satisfy a DNS mapping request, it will either redirect your computer to another DNS server query that DNS server itself and pass the results back to your computer.

If the mapping query is for an address in a domain foreign to the DNS server, the DNS server redirects the query up the chain of servers toward (or to) a root server (such as the server for the .com, .edu, or .gov domains). A server that has recorded and delegated name service for a domain will redirect the query down to the DNS server that has responsibility for the domain. See Figure 4.1 for an example.

Cc723704.socket01(en-us,TechNet.10).gif

Figure 4.1: The DNS system distributes control of Internet domain names.

DNS Messages

Your computer makes a DNS request by sending a UDP packet in the DNS message format to port 53 of the DNS server. DNS uses UDP rather than TCP because it has one short message that will fit in a UDP packet to send to the server, and the connection establishment overhead of TCP is not necessary for DNS. The message has a fixed 12-byte header and four variable-length fields as shown in Figure 4.2.

Cc723704.socket02(en-us,TechNet.10).gif

Figure 4.2: A single DNS message may contain multiple address resolution queries or responses in the Question RR and Answer RR fields of the DNS UDP packet.

The DNS message fields are as follows:

  • Identification—This is set by the client so that it can identify the DNS server response.

    Flags—This field classifies the message as follows (See Figure 4.2):

    • QR—0 for query or 1 for response.

    • Opcode—0 for standard query, 1for Inverse query, or 2 for Server Status Request.

    • AA—Authoritative Answer (True/False).

    • TC—Truncated (True/False).

    • RD—Recursion Desired (True/False).

    • RA—Recursion Available (True/False).

    • Zero—These three bits are zero.

    • Rcode—0 for No Error, or 3 for Name Error.

  • Number of Questions—1 or more for query, 0 for reply

  • Number of Answer RRs—0 for query, 1 or more for reply

  • Number of Authority RRs—0 for query, 1 or more for reply

  • Number of Additional RRs—0 for query, 1 or more for reply

  • Questions—Each question is composed of a string containing the Internet address being queried, a query type, and a query class (which is 1 for Internet addresses). Common types are as follows:

    1

    A

    The IP Address

    2

    NS

    The Name Server for the domain

    5

    CNAME

    The Canonical Name (if a computer responds to more than one name, this is the main one)

    12

    PTR

    The Pointer Record (looks up the name corresponding to an IP address)

    13

    HINFO

    Host Information (computer details)

    15

    MX

    The Mail Exchange Record (which host handles mail for this Internet Address)

    252

    AXFR

    The Request for Zone Transfer

    255

    ANY

    The Request for all records

    Answers, Authority, and Additional Information—all share the same Resource Record format, as follows:

    • Domain Name—This is the Internet address that information was requested for.

    • Type—This is the same as the Type field in the query.

    • Class—This is usually set for 1 for Internet addresses.

    • Time-To-Live—The number of seconds that the data may be cached by the client (typically two days).

    • Resource Data Length—The amount of space taken by the resource data.

    • Resource Data—The four-byte IP address for a type 1 (a record) response.

So when you type https://www.microsoft.com into your Web browser, your computer fires off a UDP packet to your DNS server asking where Microsoft is. The DNS server either sends back a UDP packet containing that information, or it redirects your computer to another DNS server that might have it instead. Eventually, your computer gets back an Answer record containing the IP address, and the Web browser can then use it to open a TCP socket to Microsoft's Web server.

in-addr.arpa

Sometimes you already have the IP address to a computer, and you want to know what the Internet address for that computer is. Web server administrators, for example, often need to know which domains most of their traffic is coming from. More importantly, if you suspect that a hacker is breaking into your system, you need to be able to translate the IP address into a domain so that you can contact the administrator of the network that the hacker is coming from. How do you look up an IP address?

Note: The different kinds of Internet addresses can be confusing to people who are just learning how the Internet protocols work. Just remember—IP addresses are for computers and are made up of four numbers separated by dots. Internet addresses (also called Internet names) on the other hand are meant to make sense to humans, and have the familiar endings such as .com, .edu, .mil, .net, or .org.

When you are allocated a block of IP addresses and you request a domain name to go with it, you are also given control of a portion of the DNS name space corresponding to the IP addresses you have control over. The top level domain name for this portion of DNS is not .com or .org, but rather .in-addr.arpa, which (like the rest of the DNS system, and unlike IP addresses) gets more specific as values are added to the left of it.

If you want to look up the address 128.110.121.144, you would request the CNAME record for 144.121.110.128.in-addr.arpa, and you would receive back the actual Internet address for that computer if there is one registered for it. This is why your own DNS server must be configured for that weird numerical in-addr.arpa domain in it as well as the domain you requested.

Reverse Lookup

Many services will not allow a network client to connect to it if the client does not have an Internet name as well as an IP address configured for it. While a computer without an Internet name is not proof positive of hacking, it is indicative of a domain with lax administration. If the protocols you support allow it, and your network can handle the overhead of looking up every IP connection attempt, lock out these nameless computers.

Coordinating Name Servers (and Subverting Them)

When you obtain a domain name (or more than one), you are required to provide the IP addresses of at least two DNS servers that will handle DNS requests for your domain(s). Why two? So that if one fails, the other can take over its responsibilities. One is designated the primary DNS server and has several secondary servers to backup its data.

Primary and secondary DNS servers are typically configured to stay in sync through the exchange of zone transfer messages. The primary can preemptively send the zone transfer message, or the secondary can request that the primary send one. Zone transfers can be incremental or complete.

DNS servers make juicy targets for hackers because the hacker can use a compromised name server to redirect unwitting clients to her own computer. As a result, impersonation and man-in-the-middle attacks are easy to perform. If your DNS servers aren't particular about where zone transfer packets come from, the hacker can feed false information to the secondary server and then perform a denial-of-service attack on the primary (perhaps through a ping-of-death or smurf attack). The hacker is then in charge of your network name space, not you.

Note: With a very small network you can disable zone transfers and simply update the tables of your internal DNS servers by hand. For larger networks this becomes impractical, and you must have either firewall software that discriminates between regular DNS queries and zone transfers, or you must have DNS proxy software that will allow only safe domain name requests.

The Protocols

DNS is one service you must allow through your firewall in one manner or another because without it your network clients won't be able to find anything. There are many more services you may want to support on your network, or that you may elect to block depending on the needs of your network users. Each has its strengths and vulnerabilities, which we'll examine using the criteria established at the start of this chapter. The protocols we'll discuss are:

  • BootP/DHCP (67 and 68 UDP)

  • Chargen (19 UDP and TCP)

  • Daytime (13 UDP)

  • Discard (9 UDP and TCP)

  • DNS (53 UDP)

  • Echo (7 UDP)

  • Finger (79 TCP)

  • FTP (20 and 21 TCP)

  • Gopher (70 TCP)

  • HTTP (80 TCP)

  • IMAP (143 TCP)

  • LDAP (389 TCP and UDP)

  • NetBIOS (137, 138, and 139 TCP)

  • NFS (2049 TCP and UDP)

  • NTP (123 UDP)

  • POP3 (110 TCP)

  • Quote (17 UDP)

  • RPC(sun) (111 UDP)

  • RSH (514 TCP)

  • SMTP (25 TCP)

  • SNMP (161 UDP)

  • Telnet (23 TCP)

  • TFTP (69 UDP)

BootP/DHCP (67 and 68 UDP)

BootP was developed as a simple mechanism for allowing simple network terminals to load their operating system from a server over the LAN. Over time it has expanded to provide for centralized control of many aspects of a computer's identity and behavior on the network, including allocating IP addresses, configuring gateway, DNS, and router settings, dispensing NetBIOS names, as well as downloading operating system files. The following bulleted items summarize this protocol's security profile (we'll provide a similar bulleted list for each protocol we discuss).

  • Complexity—BootP is simple, DHCP is a little more complex.

  • Abuse Potential—Medium. The greatest danger from BootP and DHCP is from a network intruder impersonating a DHCP server on your network and thereby misconfiguring the DHCP clients. If you do not allow DHCP to pass your firewall you should be able to use DHCP internally without problems.

  • Information Sensitivity—Medium. The DHCP server responds with machine information about your network, but not user account information, when queried.

  • Dialog—Minimal.

  • Programmability and Configurability—Medium.

Chargen (19 UDP and TCP)

Chargen continuously sends out the printable ASCII characters. It is useful for testing network applications. Any service that could be stopped or swamped by a stream of ASCII characters is broken anyway and shouldn't be let past your firewall. It is extremely unlikely that a network intruder could use Chargen to break into your system.

  • Complexity—Simple.

  • Abuse Potential—Chargen can be redirected to flood other unsuspecting computers.

  • Information Sensitivity—none.

  • Dialog—none.

  • Programmability and Configurability—none.

Daytime (13 UDP)

This service sends the date and time at the server to the client. It would take a very clever hacker to find a security weakness in this protocol.

  • Complexity—Simple.

  • Abuse Potential—Minimal.

  • Information Sensitivity—None.

  • Dialog—Minimal.

  • Programmability and Configurability—None.

Discard (9 UDP and TCP)

This protocol throws away any data sent to it. It is useful for developing network tools.

  • Complexity—Simple.

  • Abuse Potential—Minimal.

  • Information Sensitivity—None.

  • Dialog—Minimal.

  • Programmability and Configurability—None.

DNS (53 UDP)

While this protocol is a prime target for network intruders, you can't disable it without disabling all your network clients as well. You should protect your DNS servers (as described in the previous section, "Dot COM and All That") by blocking zone transfer packets or by using a DNS proxy service.

  • Complexity—Complex.

  • Abuse Potential—High.

  • Information Sensitivity—Minimal.

  • Dialog—Minimal.

  • Programmability and Configurability—High.

Echo (7 UDP)

Echo repeats to the connected client whatever the connected client sends to it. It is useful for testing network applications. It is extremely unlikely that a network intruder could use Echo to break into your systemas long as Echo properly manages its input buffers.

  • Complexity—Simple.

  • Abuse Potential—Minimal.

  • Information Sensitivity—None.

  • Dialog—Minimal.

  • Programmability and Configurability—None.

Finger (79 TCP)

The Finger service was designed to help network users communicate by providing system information, such as the last time a user checked their e-mail, and real-world data, such as the user's office hours, telephone number, or current projects. Unfortunately, this data is as good as gold to hackers looking for potential account names and passwords. Also, some hackers will even go so far as to call an office pretending to be the help desk staff and trick users into giving up their account names and passwords over the phone.

  • Complexity—Simple.

  • Abuse Potential—Average.

  • Information Sensitivity—High.

  • Dialog—Minimal.

  • Programmability and Configurability—Average.

FTP (20 and 21 TCP)

FTP is a useful command-line protocol for transferring files over the Internet. FTP is often used to remotely update Web content on HTTP servers. For this reason it may be necessary to allow FTP traffic through your firewall.

The FTP protocol's development predates the development of firewalls and is therefore a little more difficult to pass through a firewall than newer protocols such as HTTP. When a client opens a connection with the service (using port 20, the command channel) the server opens a second connection to the client (using port 21, the data channel). If the firewall is using IP translation to hide the client computers behind a single public IP address, the data channel connection attempt will fail unless special measures are taken in the firewall to identify and pass through the incoming data channel.

You should be exceedingly careful in configuring FTP security because FTP establishes a dialog with the client in which the client can browse files on the FTP server and download them, and because FTP authentication is made using operating system usernames and passwords. Even if someone accesses the FTP server as the "anonymous user," the user can gain access to critical operating system files if you have set up file and directory security incorrectly (especially if you have established symbolic links that allow the anonymous user out of the typical safety sandbox).

When you set up an FTP server for access that is external to your network, do not use the same account names and passwords on the FTP server as are used for LAN log on.

  • Complexity—Complex.

  • Abuse Potential—High.

  • Information Sensitivity—Medium.

  • Dialog—Complex.

  • Programmability and Configurability—High.

Gopher (70 TCP)

The Web was not the first widespread hypertext system on the Internet—Gopher actually predates the Web by a year or two. Gopher, like the Web, displays pages of information and has links you can select that lead to other pages. Gopher is text-based, however, while HTTP supports graphics, sound, etc.

Gopher's simplicity makes it a safer service to support than HTTP, but you still need to make sure that the directories served by Gopher don't contain sensitive data.

  • Complexity—Simple.

  • Abuse Potential—Minimal.

  • Information Sensitivity—Low.

  • Dialog—Minimal.

  • Programmability and Configurability—Low.

HTTP (80 TCP)

The Web uses the HTTP protocol to transfer text, video, sound, and even programs over the Internet. Initially, Web servers were very simple (merely sending out to a client whatever page the client requested), but the exploding World Wide Web demands more and more features from Web servers. Now a Web server is a complex piece of software, with many configuration options, a complicated dialog, and infinite programmability.

The hacker exploitation of HTTP can go both ways—a hacker may try to exploit your Web site using HTTP, and a hacker Web site may contain dangerous Web page components such as malicious ActiveX controls or Java applets.

ActiveX controls are an Internet Explorer feature. An ActiveX control, once downloaded and run on a client computer on your network, can do absolutely anything any other program on that computer can do. You should require that on your network only those ActiveX controls that have been digitally signed by organizations you trust will be downloaded. You can use the Internet Explorer Administration Kit to lock down this Internet Explorer setting. If you can get away with it, disable ActiveX controls entirely.

Java is a little safer. Make sure that all of the computers in your network are configured not to allow Java applets access to hardware resources unless they are digitally signed by organizations you trust.

On the server side, be extremely careful with remote Web administration software. Most of the Web site hacking done by Internet vandals has been accomplished by exploiting security holes in remote Web site management tools.

Scrutinize server-side applets and CGI scripts. Do not make script directories browsable. Do not allow arbitrary scripts to be uploaded. Do not allow scripts to be executed from directories that contain other Web data.

If you can, maintain Web page usernames and passwords separately from operating system usernames and passwords. Log Web access, and look for unusual patterns (excessive 404 errors, etc.).

  • Complexity—Complex.

  • Abuse Potential—High.

  • Information Sensitivity—Medium.

  • Dialog—High.

  • Programmability and Configurability—High.

IMAP (143 TCP)

This is the protocol used by network clients to retrieve mail from servers configured to retain e-mail on the server rather than transferring it to the client. The protocol itself, while more complex than POP or SMTP, is more secure (passwords aren't sent in the clear, at least).

  • Complexity—Simple.

  • Abuse Potential—Minimal.

  • Information Sensitivity—Medium.

  • Dialog—Low.

  • Programmability and Configurability—Low.

LDAP (389 TCP and UDP)

The Lightweight Directory Access Protocol is a flexible and distributed way of maintaining contact information (including usernames and passwords) over the Internet. Several Internet services use LDAP to maintain user information rather than relying on the operating system user accounts. This is more secure because it separates operating system functionality from service functionality, and a hacker who gets a service password will not necessarily be able to log on to the server with it. If you want to maintain contact information on your network to facilitate communication with people in your organization you should consider using LDAP instead of Finger and Whois.

  • Complexity—Complex.

  • Abuse Potential—Minimal.

  • Information Sensitivity—Medium.

  • Dialog—Medium.

  • Programmability and Configurability—Medium.

NetBIOS (137, 138, and 139 TCP)

NetBIOS is the protocol used by Microsoft Windows networking to connect LAN clients to file and print servers. NetBIOS will run over IPX, NetBEUI, and TCP.

You should definitely not allow NetBIOS traffic to pass your firewall in either direction. NetBIOS is easily hacked and many exploits exist on hacker Web sites. If you want to link your LANs over the Internet, you should use an encrypted IP tunnel to convey the NetBIOS IP packets through the Internet.

  • Complexity—Complex.

  • Abuse Potential—High.

  • Information Sensitivity—High.

  • Dialog—High.

  • Programmability and Configurability—Low.

NFS (2049 TCP and UDP)

NFS is the UNIX equivalent of NetBIOS—it gives LAN clients access to file server storage. If you need to allow remote clients access to NFS resources, establish an encrypted tunnel to do it, don't just open up the NFS ports.

  • Complexity—Complex.

  • Abuse Potential—High.

  • Information Sensitivity—High.

  • Dialog—High.

  • Programmability and Configurability—Medium.

POP3 (110 TCP)

The Post Office Protocol allows clients to check their e-mail over the LAN or over the Internet. POP is easy to configure and use, but the protocol is a little too simple—it doesn't encrypt usernames or passwords. Avoid allowing access to internal mail accounts from outside the firewall using POP—and if you do, do not allow POP account names and passwords to be the same as LAN usernames and passwords.

  • Complexity—Simple.

  • Abuse Potential—Medium.

  • Information Sensitivity—Medium.

  • Dialog—Minimal.

  • Programmability and Configurability—Low.

Quote (17 UDP)

This protocol merely sends to any connecting client a random selection from a file full of quotes. Quote provides little leverage for abuse.

  • Complexity—Simple.

  • Abuse Potential—Minimal.

  • Information Sensitivity—None.

  • Dialog—Minimal.

  • Programmability and Configurability—None.

RPC (111 UDP)

Remote Procedure Call is a protocol that allows two computers to coordinate in executing software. A program on one computer can use RPC to transfer the execution of a subroutine to another computer, and have the result returned via RPC to the first.

RPC is a fragile service, and most operating systems cannot handle arbitrary data being sent to an RPC port. RPC is best used in trusted LAN environments, and you should not let RPC traffic through your firewall.

  • Complexity—Medium.

  • Abuse Potential—High.

  • Information Sensitivity—High.

  • Dialog—High.

  • Programmability and Configurability—High.

RSH (514 TCP)

The Remote Shell protocol makes up for deficiencies in Telnet. There are always dangers when you allow remote command line access to computers through your firewall, but if you are going to do so, use RSH rather than Telnet. RSH at least protects the passwords as they are exchanged between the client and the server.

  • Complexity—Medium.

  • Abuse Potential—High.

  • Information Sensitivity—High.

  • Dialog—High.

  • Programmability and Configurability—Low.

SMTP (25 TCP)

Most of the mail exchanged over the Internet is done using the Simple Mail Transport Protocol. All the protocol does is accept mail in a simple dialog (without checking the authority or even the identity of the sender).

Although the protocol is simple, the software that processes the mail (once it's received) is often not so simple. Many SMTP packages have complex configuration options and forwarding rules, and, if incorrectly configured, can adversely affect network performance or crash the mail server when large amounts of mail are being processed. Also, the lack of sender authorization leaves SMTP open to spam attacks and e-mail flooding.

Unfortunately, if you want to receive Internet mail you need to support SMTP. You should choose mail server software that is as bullet proof as possible and use care when configuring it, paying attention to details like available hard disk space, network bandwidth, and so on. Install a server-based virus scanner to sanitize e-mail attachments as well.

  • Complexity—Complex.

  • Abuse Potential—Medium.

  • Information Sensitivity—Medium.

  • Dialog—Minimal.

  • Programmability and Configurability—High.

SNMP (161 UDP)

The Simple Network Management Protocol is a useful tool for remotely managing network devices such as routers, servers, hubs, clients, and terminal servers. You can use it to enable and disable ports, measure bandwidth, reboot devices, and gather statistics. However, it should be used to manage your network only, not to allow hackers to watch every aspect of the data flow on your network. Block SNMP traffic at your firewall.

  • Complexity—Medium.

  • Abuse Potential—High.

  • Information Sensitivity—High.

  • Dialog—Minimal.

  • Programmability and Configurability—Medium.

Telnet (23 TCP)

Telnet is extremely simple—it's just a connection opened to a command line interpreter. Whatever you type is sent to the interpreter on the server, and the interpreter's response is returned to you. The data traffic is not encrypted, and when you log on, the username and password are readable by any computer on any intermediate LAN.

Do not allow Telnet access to computers inside your firewall. If you require command-line access use a more secure protocol such as RSH.

  • Complexity—Simple.

  • Abuse Potential—High.

  • Information Sensitivity—High.

  • Dialog—Minimal.

  • Programmability and Configurability—None.

TFTP (69 UDP)

TFTP is used with BootP and DHCP to allow diskless workstations to load their operating system and other configuration over the LAN. TFTP does not have the two-channel problem that FTP has (and therefore interoperates well with a firewall), but there is little reason to allow TFTP through a firewall when you already have FTP and HTTP for file distribution. Also, hackers have developed tools for using unprotected TFTP servers as pirated software dumping grounds, so only allow TFTP through your firewall if you have a good reason to.

  • Complexity—Simple.

  • Abuse Potential—High.

  • Information Sensitivity—Medium.

  • Dialog—Minimal.

  • Programmability and Configurability—Low.

Case Study: Leaving the Barn Door Open

One of the benefits of being a consultant who actually fixes things and makes life easier for the client company is that when an employee leaves for greener pastures he or she often will take you with them to fix problems in those new, greener pastures. One day, a former employee of a customer of mine called up and asked if I could evaluate the security of his new employer's network. I said that of course I could—and that for this excellent customer I would perform an initial, over-the-Internet evaluation for free. I agreed that I would present the over-the-Internet results to the customer and, at that point, discuss the cost of a full security evaluation of their network, including hardware, software, internal, and external practices.

I then gathered a few widely available Internet tools and began my remote evaluation. The first thing I discovered was that their Web server computer (accessible through their firewall) had ports 137 through 139 open. Not only did this identify the computer as a Windows NT machine, it showed that the NetBIOS service was accessible over the Internet, protected only by Microsoft LAN authentication. A quick check showed that the administrative account was still Administrator, and I crafted a small program to repeatedly try passwords (distilled from common password lists I generated or grabbed from Internet Web sites). I then got to work looking for other ways into the system.

I didn't get very far, though, because an hour and a half later the password testing program came up with the Administrator password and allowed me in. The password was short and simple and all lowercase. I immediately phoned our contact, let him know that he did indeed have at least two problems, and set up a time to come in and do an exhaustive evaluation.

About the Authors

Matthew Strebe, MCSE, is the author of NT Server 2 24seven and co-author of NT 4 Network Security (both from Network Press) and owner of Netropolis, a network-integration firm specializing in high-speed networking, security, and Windows NT. Strebe's colorful career includes hacking his high school and a stint in the U.S. Navy where he installed the Navy's first fiber-optic LAN aboard a ship.

Charles Perkins, MCSE, is co-author of NT 4 Network Security and six Network Press MCSE Study Guides. Formerly director of Computing Services for the University of Utah College of Law, he is now a consultant specializing in Windows NT and security.

Copyright © 2000 Sybex, Inc.

We at Microsoft Corporation hope that the information in this work is valuable to you. Your use of the information contained in this work, however, is at your sole risk. All information in this work is provided "as -is", without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Microsoft Corporation. Microsoft Corporation shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages. All prices for products mentioned in this document are subject to change without notice. International rights = English only.

International rights = English only.

Link
Click to order