Is the Internet a Safe Place to Live?

If you've explored the Internet recently, you may have noticed that many Internet servers are Windows NT Servers. And although you can't see them, many Windows NT Workstations also connect to the Internet as client systems. Embedded support for the Transmission Control Protocol/Internet Protocol (TCP/IP) network architecture allows NT systems to be easily integrated into large networks including the Internet. But what risks do you run when you attach an NT Workstation or an NT Server to a TCP/IP network? Are TCP/IP networks inherently risky? And if they are, do those security weaknesses affect NT systems on the Internet? You bet they do.

The very fact that NT Workstations and Servers are operating over the Internet puts them at risk. Just because NT has excellent internal security doesn't make it bulletproof on the Internet--just as a world-class boxer might not last three minutes in a back-alley street fight.

A Matter of Perspective
If you're concerned about the security of a system operating over the Internet, the first thing to look at is how that system interacts with the network. Is it a client, a server, or both?

Client systems, which merely explore the network looking for information, run the least risk because hackers can't penetrate them while they're connected. This doesn't mean, however, that client systems provide a worry-free environment. After all, hackers can monitor unencrypted traffic going into and out of client systems and discover details like passwords used to access "secure" applications. Hackers can attach viruses to files that will be downloaded using File Transfer Protocol (FTP) client software. And Internet-based hackers can make life miserable with harassment techniques such as "mail bombing" (i.e., sending you so much mail that it overloads your mail server).

What hackers can't do, however, is reach into a client system and pull out important or confidential information tucked away on a hard disk. Nor can they enter a client system and plant viruses, deposit digital bombs, or otherwise modify it to suit their purposes. They can't do these things because there is no point of entry. Clients initiate connections; they don't accept them.

To run the risk of direct intrusion, a system must function as a server. For our purposes, let's define a server as any system offering background TCP/IP services over an IP-based connection (i.e., a Serial-Line Internet Protocol (SLIP) dial connection, a Point-to-Point Protocol (PPP) dial connection, or a permanent LAN connection). This definition includes, for example, an NT Workstation running FTP Server software. It includes proprietary computer systems, such as Digital's VAX, IBM's AS/400, and Hewlett-Packard's HP3000, which offer limited background services. And it includes full-blown UNIX systems, the traditional backbone of the Internet. In fact, by this definition, virtually any system attached to the Internet or operating on a TCP/IP network has the potential to be a server.

However, all servers are not equally vulnerable. Their degree of vulnerability depends on the services they offer. To appreciate this potential exposure, let's open the lid of the TCP/IP network architecture and look at its embedded socket structure.

Plug 'n' Play?
Sockets provide the means for system-to-system communications; they are a fundamental part of the TCP/IP architecture. In a nutshell, sockets provide a series of "pipelines" between systems to accommodate all types of communications. In fact, all communications between systems in a TCP/IP environment depend on them. Sockets exist at several levels: IP, TCP, and User Datagram Protocol (UDP). All sockets, however, have two things in common:

* An IP address, which identifies the target server system involved in the connection

* A port number, which defines a particular service (or program) within the target server

The purpose of the IP address is fairly straightforward. When a client initiates a socket connection to a server, the client includes the server's IP address in the request.

The purpose of the port component of a socket, however, is a little more involved. In general, each type of protocol--IP, TCP, or UDP--has 65,536 ports available for use. Services (or programs) are associated with those ports within a server. Many ports have over time acquired pre-assigned definitions (for some examples, see Figure 1). Other ports are reserved for vendor-specific purposes; still others are available for application assignments.

In addition, you can use a "portmapper" program to manage ports. Programs attach to the portmapper (on IP port 111) which makes an actual port assignment based on the service requested. This method is most commonly employed by integration solutions that use the UNIX Remote Procedure Call (RPC) strategy. Such solutions include the Network File System (NFS), the Distributed Computing Environment (DCE), and others.

The IP address, protocol type, and port assignment come into play when a client initiates a connection with a server: It must identify the proper IP address, the protocol (IP, TCP, or UDP) to use, and the specific port assignment for the target service. If any one of these variables is incorrect, the client/server connection will not be made.

The Language of the Net
In all fairness, there is nothing intrinsically wrong with the way TCP/IP assigns and manages sockets. What makes sockets scary is the way in which clients and servers communicate over them. The same features that make TCP/IP protocols easy to understand and easy to implement also undermine the security of their networks.

It's important to note that this conversation is not pseudocode; it shows how the SMTP protocol really works. The client actually transmits the keyword HELO, and the server does, indeed, reply 250. In fact, the entire SMTP protocol consists of English-like commands and numerical responses. (The exact phrases that follow each keyword may vary slightly from one machine to the next, but they all follow the same general format.)

Many application-level TCP/IP protocols operate using English-like commands. For example, the Hypertext Telnet Protocol (HTTP) used on the Web employs commands such as GET, SEARCH, and LINK. Similarly, FTP uses basic directives such as DIR, GET, and PUT. Even those protocols that don't use English-like commands rely on simple, byte-oriented command sequences and responses.

Basing these protocols on high-level commands and responses makes them extremely easy to learn, easy to program, and easy to debug. Unfortunately, although this approach may be great for programmers and protocol developers, it presents two significant problems for network managers:

* The protocols are open to view. Anyone with a LAN or WAN monitor can see everyone's dirty laundry, so to speak. Although you can argue that anyone with a network monitor can see everything on the network anyway, with TCP/IP you don't have to work very hard--all of the information is laid out in front of you. You don't even have to decode bit-level flags like you do with IBM's Systems Network Architecture (SNA), Digital's DECnet, or Novell's Internet Packet eXchange (IPX).

* Both people and sleuth programs can easily attach to ports and masquerade as protocols. This means you can use Telnet to connect to a specific socket and start manually emulating a protocol! For example, a hacker can use Telnet to get into an SMTP socket, type HELO, wait for the response, type MAIL, and so on. You'd be surprised--and horrified--to learn what you can accomplish when you disguise yourself as a protocol.

To minimize your exposure to these dangers, one step would be to disable all nonessential services and their related ports as well as any unnecessary protocols, for example, UDP. (In NT systems, these definitions are stored in the Protocol and Services files.)

   Previous  [1]  2  Next