One of the elements that binds the Internet together is a set of Unix-based programs--protocols, really--that let you access files and locate and use resources at remote sites. These services--FTP, DNS (Domain Name System), and X11 (the dominant windowing protocol for the Unix community)--are just now being augmented by the more automated operations of WWW (World Wide Web) browsers, such as NCSA (National Center for Supercomputing Applications) Mosaic and Netscape, but they pose serious security problems. Any organization considering implementing a firewall must be aware of how to make these services available yet secure.
FTP
After E-mail, FTP is probably the most-
used service on the Internet today, letting millions of users download files and enabling organizations to make easily available a variety of documents, software, and graphics images.
But using FTP presents various security headaches. For starters, FTP isn't a single program; it's a protocol that's been implemented numerous times, and some of those implementations and FTP daemons are buggy. Another problem is that an FTP daemon normally runs with root privileges and doesn't relinquish this status. This means that if an intruder manages to get into your system by exploiting a hole in your FTP implementation, he or she can get straight to the heart of your system with maximum privileges. It was a known security hole in sendmail, another privileged program, that enabled Robert Morris's Internet worm of 1988 to propagate so widely.
So how do you get a secure FTP connection through a firewall? One way is to pass FTP requests to a proxy server--a restricted, cut-down version of FTP that's known to be
secure and that won't permit anything you don't want. A second approach is to modify the FTP software so that it will talk to only a restricted range of ports, for which firewall filtering or screening rules are in place.
Yet another approach is to use the pasv option, if it's available, to indicate that the remote FTP server should permit the client to initiate connections. This will work, however, only when the remote FTP server supports that operation. Finally, it is possible to build client versions of FTP that are linked against a SOCKS library (a generic proxy implementation).
DNS
DNS is vital to the correct operation of your internal mail and other functions--it's the telephone book that lets you know who's who and where in your network. But its structured database contains important and often sensitive information about your system that you don't want to make available to the outside world. Many organizations don't want to make their host names public.
For s
ome of you, establishing an Internet connection may require that you reconfigure the internal networks and domains. However, there are work-arounds. One security system developer suggests an approach that works by redirecting DNS clients so that they talk to a DNS server that is on a different machine. First, on the outer side of your firewall host, you set up a DNS server that the outside world can talk to. To them, this is what your domains look like, although, in fact, they are seeing a restricted set of names (and aliases) that tells them only what you want them to know. We'll call this the public server.
Next, you set up another DNS server on an internal machine. This server is in fact the real thing, and it contains information about your hosts. You make sure that this server forwards any queries it can't resolve to the public server.
Finally, you set up your DNS clients--including any clients on the machine that hosts the public server--and use the internal server. This is the key.
In practice, an internal client makes a request and gets an answer from the internal server or--asking about an external host--the Internet but relayed through the public DNS server. External requests, however, are handled completely by the public server with its restricted information (see the figure "
Public and Private DNS Servers
").
While this technique can work well, it may not be the final answer. Hiding names in the DNS doesn't stop host names from "leaking" out in mail headers, signature files, or news articles. But this can be an effective way for an organization to quickly set up a restricted DNS gateway without having to conduct any significant internal reorganization or reconfiguration.
X11
X11, the predominant windowing protocol for Unix, assumes that the user's terminal is a server. While this philosophy enables many benefits, it also puts the system at risk. Applications connected to an X11 server have the power to seriously compromise s
ecurity.
Spoofing--making your computer masquerade as a different machine or originating IP address, one that the receiving system trusts--is a problem that still hasn't gone away. In January, CERT (Computer Emergency Response Team) reported a new rash of IP spoofing incidents in which security software was stolen from the University of California's San Diego Supercomputer Center. According to CERT, some routers can be programmed to defeat such attacks, but others cannot.
Even though these are not X11-specific, they illustrate the dangers of spoofing. Remote systems that can gain or spoof access to a workstation's X11 display can monitor keystrokes that a user enters, download screen dumps that contain sensitive data, generate commands that appear to originate at the keyboard, and so on. Because of these problems, most firewalls block all X11 traffic unless they have a specially written application proxy to handle it.
illustration_link (38 Kbytes)
Establishing dual DNS (Domain Name System) servers allows the internal network to keep its true domain names private. In the diagram, when an internal user makes a DNS request, it goes to the private DNS server, which returns the proper name. If the private server doesn't know that name, it passes it along to the public server, which then returns it to the user. All external DNS requests go to the public server alone, and it answers these requests directly.
Safe Network Services: FTP, DNS, and X11
