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.)
Beyond the Language Barrier
Even after you trim down your port and protocol usage, you still run the risk of hackers attacking the ports you keep available and gaining access to your server. Even worse, if local systems share an Internet connection with a server, a hacker can also penetrate those local systems.
To address this level of security risk, you should establish a series of firewalls between the Internet and your other systems. A firewall creates a protective barrier between your Internet connection and your application systems. The first firewall should be within the server attached to the Internet--it's the one you build by limiting the services and ports.
You should also consider building another firewall between your Internet server and your other LAN-based systems by placing the Internet server on its own LAN segment. Then you would use a gateway to limit the traffic flow between that segment and your main segments. This firewall prevents an intruder from peering into your LAN and scanning your corporate traffic as it passes. (For more information on firewall placement, see the sidebar "Up Against the Wall".)
The Client/Server Conundrum
Another area of concern is the amount of trust TCP/IP puts in IP addresses. Imagine that you're on a TCP/IP client system and that you want to make a connection to a server system. If you start with a server name, you need to translate it into an IP address by looking it up in a local host table or by going out on the network and asking a Name Server to translate it for you. Once you have the IP address, you can use it to determine if the server system is on your local network or if you have to go through a gateway to reach it.
If you need to go through a gateway--as you do with most Internet accesses--the gateway must have routing tables established that allow it to route traffic to that server system, either directly or through other gateways (see "The Internet Roadmap" on page 15). If the server you want is on your own LAN, you need to find the assigned hardware address of the server's LAN adapter corresponding to the Internet address. To resolve an Internet address, a system uses the Address Resolution Protocol (ARP) to broadcast a message containing that address to all systems on the LAN. The system that "owns" the address responds with its adapter's address. To communicate directly with that system, your system must include that adapter's address in all its messages. Without the adapter's address, the only way you can reach that system is to broadcast messages that all systems on the LAN receive.
Server/Client (server-blue, client-green 220 gateway2.heaven.com Sendmail ready HELO mail.msen.com 250 gateway2.heaven.com Hello mail.msen.com MAIL From:[email protected] 250 [email protected]... Sender ok RCPT To:[email protected] 250 [email protected]... Recipient ok DATA 354 Enter mail, end with "." alone Dear Jim: How are things in lizard land? -- John 250 Mail accepted QUIT 221 gateway2.heaven.com delivering mail
As you can see, connecting to a server is a fairly involved process. It's not impossible to defeat the process--for example, you can "hack" your way into routing tables in gateways, and you can intercept ARP requests on a LAN--but that's not the point. The point is, when a client initiates communications with a server, there is a formal procedure it follows so that the message arrives at its proper destination.
On the flip side, the server doesn't need to look up the IP address associated with a client request because it's contained in the incoming message. Also, the server doesn't need to look up the return gateway and hardware address because they're also contained in the message. Basically, everything the server needs to respond to a client is in the client's message. And that's the root of a problem called IP spoofing, where one system pretends to be another one.
IP spoofing works because most servers on the Internet--actually, most TCP/IP servers in general--don't even attempt to verify whether or not a client is telling the truth about its IP address. They don't know if they are dealing with a genuine connection or a hacker spoofing an IP address. They don't know, and they don't care.
Origin Unknown
Technically, it's easy to assume the IP address of a client system, certainly much easier than trying to assume that of a server. The extent of the damage a hacker can cause by spoofing such an address depends on your gateways and firewalls. The biggest risks you run are when you have:
* Internet access to local servers as well as local-client access to the Internet
* IP addresses determining accessibility
However, just because your gateway or firewall performs one of these functions doesn't mean you're at risk; as you'll see, the devil--and the danger--is in the detail.
When you use a gateway or firewall to allow local systems access to the Internet as well as to control access from Internet systems, IP spoofing can fool that device into accepting an external system as local. If a hacker uses an IP address that is part of your local domain, your gateway may assume that the hacker's system is a local, trusted system and allow it to pass through to your local network. Now the hacker has a chance of breaking into one of your local servers--even one that isn't supposed to be accessible from the Internet. For an example of how this can happen, see Figure 2.
A gateway or firewall that allows special access privileges to a system based on its IP address can also cause you problems. For example, your company may use the same Internet gateway for remote representatives that it uses for local staff; however, the gateway routes the remote users to your local network based on their IP addresses. A hacker using one of those addresses can penetrate deeply into your LAN. Similarly, some gateways and firewalls use special IP addresses for remote maintenance or administration. A hacker gaining entry at one of those points may be able to reconfigure your gateway or firewall or completely take it over.
In both cases, it's possible for a hacker to wander around your local network, probing your business servers, looking for weak spots in your security setup. And since you probably set up your local security assuming that intruders could not penetrate your gateway or firewall, the information on your local network may not be all that secure.
What Can You Do?
The dangers associated with sockets and IP addresses are real. But there are ways in which you can minimize your risk. The following are some suggestions that can help you reduce your exposure to intrusion.
1. Think twice about putting sensitive information on any server that you connect to the Internet. Don't put any information on it that you are afraid to lose, have altered, or have prying eyes see. If your application demands that you put sensitive information there, make sure that it's properly encrypted, both in storage and in transmission.
2. Consider encrypting all of your proprietary or private traffic, including email. If you're developing new commercial applications, build encryption into your client and server components. If you need to layer encryption on top of an existing application (like email or FTP), look for a stand-alone NT encryption package.
3. Make sure you can reload your server from a pristine vault copy of a backup tape, not just a daily or weekly backup. Most hackers make their alterations and plant their traps long before they actually do any damage, so you can't necessarily reload from a couple days or weeks ago. You need to make a point of saving "clean" backup copies of your server's contents.
4. Restrict the use of ports, services, and protocols on your server. Don't run FTP server software on your NT Server or NT Workstation unless you absolutely must. And don't use your accounting system as a mail-relay host. Be conservative! Don't open doors that don't need to be opened.
5. Never, ever, make security decisions based on IP addresses. They can be faked. Your applications or gateways should not grant special privileges to a system based on its IP address. If you really want to be secure, look at authenticity services, such as those provided by Kerberos (which gets its name from the mythical, three-headed guard dog). This type of security uses a series of key-phrase exchanges between client and server systems--a method far superior to one-time passwords or address-based checks.
6. Make sure that your firewall can distinguish between Internet traffic and local network traffic. In particular, make sure that it doesn't apply the routing tables it uses for local traffic to Internet traffic. Your goal is to prevent a fake IP address from being accepted as a local address. And while you're at it, make sure your firewall doesn't provide special handling for specific IP addresses.
The Tip of the Iceberg
Don't underestimate either your system's risk or the sophistication of today's hackers. Sadly enough, this discussion covers just the tip of the iceberg. The Internet is a powerful, worldwide network that is home to any number of highly technical hackers who get their kicks out of penetrating corporate defenses.
Hopefully, the security of your server will never be tested under fire. Statistically, the odds are low--but that's small solace in the aftermath of an attack. As the Boy Scouts say: Be prepared.
