[Cheyenne] [ Home | Products | Anti-Virus | Firewalls | General Security | Hotline | Experts ] --------------------------------------------------------------------------- Internet Security Threats and Firewalls --------------------------------------------------------------------------- Preface With every passing day, we witness a huge increase in interest in Internet access, sometimes called the "information highway". The public is now aware of the Internet as a source of valuable information. We now have a glut of books on how to use the Internet. There is a surge in the number of new Internet users, new addresses, and sales of hardware and software to permit Internet access. We are also witnessing a general awakening to an understanding that there are security problems that might result when connecting to the Internet. While the public seems aware that such problems exist, very few people have any detailed knowledge of what the problems are. Many now think they should buy a firewall to prevent such problems. They think that firewalls are generic things, like fire extinguishers, that probably all are about equally effective, and that with a firewall installed, they will have dealt with the Internet security problems they have heard of. Users are headed for trouble if they continue to believe this. There are a wide variety of problems. Most firewalls don't stop a fraction of them. Firewalls differ so widely in what they can do that they hardly deserve to be grouped together under the same name. In this technical report, we will not tackle the entire problem of Internet security. Rather, we will focus on a manageable set of issues: * What are the some of the security problems that can arise with an Internet connection? * What are the kinds of technology available that might help with such problems? 40 Internet Security Threats to Your Network Your internal network is potentially vulnerable to a wide variety of attacks from the outside. Here are some examples, each of which you might ask your firewall to defend you against. Most of the attacks are described in more detail in Cheswick & Bellovin We use published descriptions of attacks and provide fairly little information about each, in an effort to minimize the "training" that this report might provide to attackers. Our intent is to show the wide array of mechanisms by which an attacker can get into your kitchen, living room, and bedroom. Here is a short list of just 40 vulnerabilities: 1. Attacks via password guessing. Guessable passwords (such as "service" as a password for an account named "field", or the default passwords provided at installation time) can defeat nearly any system, and are the most common means by which a system is penetrated. A proper firewall should establish the non-guessability of all passwords used by the system it is protecting. It should also provide additional authentication mechanisms, such as authenticating both machine (Ethernet address, for instance) and user. It should also limit the number of login attempts, to prevent unlimited guessing. 2. Brute force password guessing Password guessing attacks on the encrypted password file (/etc/passwd) will normally succeed when the attacker uses a hacking tool such as CRACK and the file has a sufficient number of names in it. Some of these attacks can extract as many as 25% of the passwords in the file, some of which will be useful in entering other systems. A good firewall protects the password file, and prevents its transmission or alteration. 3. Tapping terminal sessions Tapping terminal sessions is a technique in which the attacker merely monitors an active user, capturing their keystrokes and looking for a login to another system. Such attacks are possible with the default configuration of even "secure" versions of UNIX, such as OSF/1. 4. Keystroke capture of password via TSRKeystroke capture of password via TSR can be done with any number of hacker tools such as THIEF or GETIT or even Borland's SUPERKEY. With this attack, the hacker is likely to need to be able to later access the local drive to pick up the file containing the captured keystrokes. 5. A sequence number attack occurs when a hacker predicts the target's choice of starting points, places such an origin in the IP source address, and then engages any protocol that uses this address for authentication (such as the r commands in UNIX). A firewall might be expected to prevent such an attack by a more secure authentication of the source. 6. Spoofing UDPUDP packets is easy for an attacker if your applications use the User Datagram Protocol to transmit information. UDP does not use handshaking or sequence numbers, and sends all packets for a given port to the same process, regardless of source address or port number. A firewall might be expected to independently verify the source of a UDP packet before processing it, even if the source is internal to the organization. 7. Tearing down ICMP connectionsTearing down ICMP connections. The Internet Control Message Protocol (ICMP) is a mechanism that informs hosts of better routing, terminates connections when network problems arise and can report routing troubles. Older versions ignore the connection-specific information of an ICMP message, and may redirect all connections between a pair of hosts, replacing the original connection with a new one. Hacking tools to tear down connections using this technique are available to the underground. 8. Redirecting ICMP connections ICMP messages can be redirected, establishing routing between a new pair of hosts. Many routers will respond to such instructions, though they should be set to do no such thing! A proper firewall design would respond to these instructions only when its own trusted router provides the request. 9. Loose Source Route option attacksLoose Source Route option attacks require that the hacker initiates a TCP connection, specifying an explicit path to the destination. When it sees that this procedure is being used, the destination uses the inverse of the path if the source is trusted (source becomes destination), conforming to RFC 1122. This permits any attacker to impersonate a trusted machine. Independent authentication by a proper firewall can defeat this approach. 10. Bogus Routing Information Protocol attacks insert additional RIP packets into a network. If the attacker is closer to the target than the original source, traffic is diverted to the attacker. In some implementations of RIP, there is no authentication field and no dialog between pairs of hosts to establish authenticity. In such a case, it is possible for the attacker to provide the host with a host-specific route, making this attack more difficult to detect. 11. Zone transfer attack. The Domain Name System (DNS) is a distributed database that maps host name and IP addresses. TCP queries by backup servers can produce zone transfers, in which a full copy of a portion of the name space is produced, so that the backup server can do its job. In a zone transfer attack, hackers can make similar requests of DNS, obtaining a list of potential target hosts and IP addresses. 12. Inverse mapping tree attack In many systems, the DNS permits subtrees to be stored on other servers. Because DNS maintains pairs of trees one mapping host names to addresses, and the other mapping addresses to names an attacker can modify an inverse record to show the name of a trusted host, the address of the attacker. Then, by using rlogin, the attacker may be able to convince your machine that it is a trusted host. A firewall might be able to prevent such an inverse mapping tree attack if it protected the DNS or performed more thorough authentication by checking IP addresses. 13. DNS cache attacks. In all but the most recent versions of DNS, it is possible to pre-contaminate the cache of DNS responses, then initiate the call. When the target checks the cache of valid responses, it then finds a name match and permits the attack. A firewall must use both name-based and address-based authentication, if it is to be trusted. 14. DNS Resolver attacksDNS Resolver attacks exploit a weakness in DNS resolvers in which, to be more efficient, the resolver is willing to connect to destinations in which the match on domain names is incomplete. Thus a domain with a name in common with a name in a desired destination address might be able to intercept traffic intended for another destination. 15. SMTP overload attacks. The Simple Mail Transport Protocol (SMTP) provides a simple set of rules for transporting 7-bit messages. The protocol can be imitated easily, and because there is no authentication, messages can be entered manually by an attacker. Because an attacker can manually specify any source for the mail, it is possible for an attacker to overload the system with bogus messages, creating a denial of service attack. In such an attack, the mail system loses functionality, even if the host doesn't collapse under the weight of the bogus incoming messages. 16. Alias Expansion. SMTP permits aliases to be used when transmitting mail. But commands such as vrfy may translate mail aliases to login names, and expn expand mailing list aliases. A firewall should ensure that expansion of aliases to names is done inside the organization, to preserve the confidentiality of those who use the system. 17. sendmail attacks. sendmail is the most common means by which SMTP is implemented, and with thousands of lines of code, there are many bugs. Root is no place to run such a documentedly-dangerous program! sendmail need not run as root unless it is doing local delivery on gateway machines. Alternatives to sendmail are available, including potentially safer front-ends to it. 18. MIME header attacks. A mailer on a machine receiving mail that has been encoded with MIME (Multipurpose Internet Mail Extensions) might be expected to carry out the instructions in the header of the MIME message. Such instructions, if not carefully evaluated before execution, can overwrite .rhosts in the current directory and perform other forms of mischief. 19. Executables attached to mail. If the mail system can be entered by an attacker who can forge a message, then the attacker won't have difficulty attaching a program to the mail. The program can be designed to do anything the attacker wishes, and is likely to be successful with this Trojan if it appears to do something useful for the recipient. The Trojan, for instance, might seek to capture passwords as a TSR, or might merely contain a virus not detected by the recipient's virus scanner. Sometimes the Trojan is a "dropper" a program containing a virus. The program and virus are usually encrypted, to prevent a scanner from detecting the virus; when the program is run, the virus is released to infect files, or is placed in a sector, where it will execute with the next boot. Trojans and droppers do not require a deliberate attack, of course: they can be attached to E-mail by well-meaning senders who are unaware of the hidden contents of the program they send. 20. Attacks via corrupted telnet. telnet provides a user with terminal access. In an unsecure system, the telnet program can be compromised by an attacker to capture user name, password, or even the entire terminal session. Alternatively, if the attacker is not interested in what you are doing, but rather wishes to have the access offered by your account, the attacker's telnet replacement can simply keep the connection open after you think you've logged out. 21. Tapping the communications link. When any portion of a communications link is tapped, unencrypted passwords cannot be trusted. Often the easiest place to attack a communications link is a tap on its backbone. 22. NTP attacks. When an authentication service is time-sensitive, so that a different value for authentication is used at each different time, an attacker has an opportunity to capture what was used for authentication as well as the time of authentication, then attempt to instruct the host via the Network Time Protocol (NTP) to set the time back to the captured authentication string's valid time, then simply playback the captured authentication string. Such NTP attacks are not absolutely prevented by the latest versions of NTP. 23. finger attacks. The finger protocol provides information on users that is quite useful to attackers, including their name, electronic mail address, when the account was last used, where the user last connected from, idle periods, unread mail, etc. Attackers appreciate finger for its help in identifying relatively unused accounts and the match between names and mail addresses handy for password guessing. finger is a dangerous service, far less secure than whois. 24. Forging UNIX authentication fields in RPC headers. RPC (Sun's Remote Procedure Call) is a protocol that provides a designer with the means of creating a network service which can reach out and make subroutine calls to remote servers. Every RPC message has a header which can include authentication information. The information might be "null", for anonymous services, or might include "UNIX authentication" information, including the supposed numeric user id and group id of the caller and the name of the calling machine. All of the information in these fields can be readily forged by an attacker, and the RPC request can essentially ask for any service available on the host. 25. Portmapper denial of service attacks. Portmapper helps connect RPC clients and servers, and uses RPC for its work. One call supported by portmapper is to unregister a service. Because portmapper does not do much to authenticate such a request, portmapper denial of service attacks are straight-forward. 26. Portmapper reports to attackers via rpcinfo. Portmapper will also provide information on each service the server is running, including its protocol (e.g., UDP or TCP), its port number, and its version number. An attacker's work is easier after they obtain this information with rpcinfo. 27. Attacks using portmapper to hide source location. Use of RPC normally requires that a roundtrip of messages is required to determine the real port number of the client/source/attacker. To save this trip, portmapper permits the source to request that it transfer its request to the target server, carrying portmapper's own return address, rather than the actual source's. This ability makes legitimate local requests indistinguishable from those made by outside callers. While some versions of portmapper can do their own filtering, many cannot. 28. NIS attacks which obtain the password file, host address table, or public and private key databases. Network Information Services (NIS, formerly known as YP or Yellow Pages) is a service that distributes many important databases from a central server to its clients. Such databases include the password file, the host address table, and public and private key databases used for Secure RPC. This attack instructs NIS to transfer one or more of these key files to the attacker. 29. Attacks impersonating NIS backup servers NIS clients can be told to use a different NIS server, should it go down; the replacement server can be fraudulent, and supply false /etc/passwd file entries, false host addresses, etc. 30. RPC attacks on the NIS shadow password file. A shadow password file is a hidden copy of the password file which holds the actual, unencrypted passwords. An attacker is unlikely to be able to access this file directory, but can make repeated requests for RPC services using a variety of passwords. Applications check this file for the password, and report back to the attacker whether the password is valid. RPC does not log flurries of requests for passwords. 31. Attacks using NFS root file handles. To mount a volume for a client, a server running NFS (Network File System) the RPC mount daemon at the NFS server asks the client for name and requested file system, examines an administrator-supplied list, and if the client is on the list, sends the client the file handle for the root directory. The client maintains this file handle, and uses it in subsequent requests. If the client keeps the handle (e.g., records it for later use) the client has permanent access to that root. Root file handles can be shared, and once a user is given a root file handle, there is no mechanism for later taking it back. Considering the many problems that can occur in managing NFS, secure alternatives such as the Andrew File System (AFS) should be considered. AFS uses Kerberos for its authentication and provides a single scalable, global, location-independent file system. Files can reside anywhere in the network, with caching occurring transparently. 32. Attacks via tftp. The Trivial File Transport Protocol is a UDP-based file transfer mechanism which does not support authentication at all. If tftp is not restricted to just one or two directories, then attacks on the password file are simple. 33. Attacks using anonymous ftp. FTP (File Transfer Protocol) is a program and file distribution system that rivals e-mail for importance on the Internet. Anonymous ftp permits any caller to transfer files from a restricted area of the host without providing any further authorization. If ftp is set up so that a file or directory in the anonymous ftp area is writable or owned by the ftp login, then an attacker can use ftp to write a file named .rhosts to ftp's home directory, then use that file to authorize an rsh connection to the target machine as ftp. From there, the attacker proceeds to transfer files. 34. Anonymous ftp captures of /etc/passwd/etc/passwd. If you happen to leave the /etc/passwd file in an area reachable by anonymous ftp, assume a visitor will help themselves to a copy. 35. Undesirable files placed in the publicly writable anonymous ftp directory. If you have an area where anonymous ftp callers can place files, you should assume that this area will sooner or later hold copies of pirated, pornographic, slanderous, or virus-infected files. Such files may be placed their for your own amusement, for the "benefit" of those within your organization, or simply for others witting or unwitting to come and collect. 36. Denial of service by filling the publicly writable anonymous ftp. If a caller can place files on your system anonymously, it may be a matter of time before some caller places an expanding file there that fills the available space. Such a project will potentially disable any audit trail, slow other processes (or down the system), and, at a minimum, deny additional callers write-access to this directory. 37. Anonymous ftp attacks by replacement of commands within the ftp area. Any program such as ls which resides in the ftp area can be potentially replaced by an attacker, subsequently resulting in unexpected and undesired results. 38. Attacks with rlogin. rlogin permits login to a remote machine without a password if a few simple conditions are met: the caller must be listed in the destination's lists of trusted callers (such as /etc/hosts.equiv or $HOME/.rhosts), the caller must come through a privileged TCP port, and usually the caller's name must correspond to the caller's IP address. Both users and hackers like rlogin. Users like it because it does not require password entry, permits them to access other remote machines by simply adding them to the user's personal .rhosts file, and seems to work fine. Attackers like it because all they need to do is drop a file listing them as authorized in /etc/hosts.equiv, /usr/spool/uucppublic, /usr/ftp, etc. After they have gotten in with rlogin, they can capture lists of other trusting machines from /etc/hosts.equiv and other files, and from there explore many other machines. 39. Attack X11 servers. X11 is the most popular windowing system on the Internet. The system treats the user of it as a server, and permits applications to interact with it. An application is able to track keystrokes, capture screens, simulate keystrokes, etc. The main protection of most X11 servers is that they only permit certain machines to make requests of them. X11 servers are typically not notified of denied access requests, nor can they verify what process is using them. Attackers anywhere on the Internet can find and control all unprotected X11 servers. 40. Tunneling and encapsulation. If you run a firewall that only permits certain protocols, other protocols will be able to pass through if they are encapsulated within approved protocols, unless you examine the contents of each packet before it is permitted to pass through the firewall. Once a tunnel has been constructed between a "mole" inside your organization and a party outside your organization, bidirectional tunnel traffic will not be impaired by your firewall. --------------------------------------------------------------------------- Security Products for Internet Connections In the marketplace today, you'll find a host of Internet security products. Nearly all perform addressing, routing and filtering on data packets. They "read" the address information on packets and direct each to its intended destination. An increasing number of products are described as "firewalls", and offer to somehow protect your organization from the vague terrors of the Internet. While everyone is aware that such terrors exist, few can describe specifically what they are, much less how to defend against them. As a result, many who purchase firewalls aren't sure what they have gotten, what risks it has reduced, and what its remaining vulnerabilities are. Those shopping for firewalls don't know what to look for, or how to find out how the products differ. This report comes from a vendor of firewalls, and yet we have struggled to produce this report. It wasn't easy writing, and in this version, it is not particularly easy reading. --------------------------------------------------------------------------- Temporary vs. Permanent Internet Connections Your LANs may be connected to each other. One or more nodes may occasionally dial out and establish a temporary connection with the outside world via modem, perhaps connecting to CompuServe, or through CompuServe to the Internet. Generally, such temporary connections do not offer a means by which an outsider can enter your system. Although a user connected to the outside world can attack it, you cannot be attacked from the outside through such an outside connection. This report focuses on the types of permanent connections you may have, in which one or more of your systems is a permanent node on a larger network. Internet is the most widely known large network, and over the past 20 years it has become a very important part of communication for thousands of users. Today, the Internet includes networks in 100 countries, with probably one million computers (and 10 million users) around the world. The Internet has grown so large that estimates of the number of users who travel its highways can never again be made accurately. If you are tied to the Internet, that uncounted number of users is out there, and some of them may be thinking of coming to visit your system. The Internet is as vulnerable as it is valuable, and it is perhaps more likely to cause your internal network more harm than anyone realizes: the Internet first served (and continues to serve) the research community, which includes a heavy concentration of colleges and universities. Such sites obviously have a heavy concentration of students who, we increasingly learn, form the backbone of the attackers we must fight off. They have the skill to visit your internal network, they have time on their hands, and they are curious. Permanent nodes on networks such as Internet are a critical vulnerability, and hundreds of folks out there have the skill to get into your system through that node. Some of these potential callers are simply employees of your organization, working at other sites but authorized to make connections. Others are unauthorized. Your task is to somehow filter calls perfectly, so that authorized users can always get in, unauthorized users can never get in, and your onsite employees perceive no service loss nor increased difficulty in getting out. You can do this with firewalls, bridges, routers, and gateways. --------------------------------------------------------------------------- Bridges, Routers, Gateways, and Firewalls The terms bridge, router, gateway, and firewall are normally jumbled up enough so that no one can easily figure out what anyone else ever means. Sometimes a router is considered a gateway; sometimes the terms gateway and firewall are used interchangeably; and sometimes a router is called a firewall. * Despite the general confusion, bridges function at layer 2 of the ISO OSI seven-layer reference model, the data link layer, and within this layer, at the media access control (MAC) sublayer. * Routers function at layer 3 of the OSI model, the network layer. * Gateways function at layer 4 and above of the OSI model, the transport layer * Firewalls have no layer, but are rather a metaphor for any barrier that prevents unwanted intruders, so firewalls include bridges, routers, or gateways. Given our druthers, we would want to have a device that protected us from attacks at any OSI layer, we would call whatever we owned a firewall, and we would have it stop everything perfectly. The real issue is not what we call these things, but what protection you have, what you need, and what you can afford. Bridges are the most economical, most convenient, and least secure of the protections available; routers are intermediate; and gateways, or pairs of gateways, can be the least economical, least convenient, and most secure of the protections. --------------------------------------------------------------------------- Big Enough for a Firewall? If you run only a LAN or two and have no permanent connection to the outside world, then this report is not for you not now at least. Regardless, the next few pages are not any fun. Before talking about what to buy so that we can connect everything together, consider that many LANs may be doing just fine without being connected to anything else. The more local a LAN, the more secure it is. When only you and one other person are connected, you can trust a full 50 percent of the users on the system; add users, and your trust percentage drops. LANs that have no connections to the outside world have perfect firewalls. A user who cannot be physically connected to a LAN cannot threaten it. If your organization seems to be pushing to connect everyone, remember this doesn't mean you must interconnect everything. The folks in accounting can have their own LAN, shared only among them and then be connected to another LAN through a second NIC in each machine. They can use the wider area LAN for e-mail and the local LAN for accounting. This separation of hardware is the norm at atomic research facilities, and what's good for them may be good for you. Large organizations could consider firewalls when connecting internal networks. The internal firewall can limit the damage caused by eavesdropping or by flooding attacks, in which a system is intentionally overloaded until it fails, and also present barriers for anyone attempting to attack a targeted machine. Firewalls help isolate physical network failure as well, keeping most segments up. Firewalls contain two key components, gates and chokes. Gates freely pass data between two networks. Chokes block incoming packets not destined for the gate, or block outgoing packets not coming from the gate. That is, any packet that does not have the gate address in its origin or destination address gets blocked. Chokes can be set tighter than that, of course, to screen out packets of a certain type (for example, SMTP e-mail packets might be okay, but telnet packets might be rejected). The gate is typically a gateway computer; the choke is often an intelligent router. The router is located between the gate (or gateway) and the external network. It is possible to merge gate and choke functions into a single machine. A UNIX machine with two network interfaces can do the job, provided it is set up to not forward packets automatically from one interface to the other. Patching network driver source code is another reasonable, if complex, method. --------------------------------------------------------------------------- Bridges and Routers Bridges, routers, and hybrids called brouters, have emerged in the past few years as a means for connecting LANs within an organization, extending the distance limitations imposed by token ring and Ethernet cabling. By filtering out some users, these products improve the available bandwidth on a network segment. Similarities between Bridges and Routers Both bridges and routers can be used to link physically separate LANs. Other similarities include the following: * Both bridges and routers are programmable. Both can be set up to filter packets, so both can be used to divide large networks into smaller ones or to exclude certain unwanted guests. * Because bridges operate at such a low level, you can normally mix bridges from different vendors. You can also mix routers from various vendors, providing they use point-to-point protocol (PPP), an emerging router standard. Older routers typically used vendor-specific proprietary protocols, so if all routers were to be connected, they had to be purchased from one vendor. Differences between Bridges and Routers Some formal differences between bridges and routers include * As stated previously, bridges function at layer 2 of the OSI seven-layer model, the data link layer, and within this layer at the MAC sublayer. Routers function at layer 3 of the OSI model, the network level. Gateways function at layer 4 and above of the OSI model, the transport layer. * Bridges read the 48-bit destination address of every single packet on their connected networks, and then read an internal routing table (of perhaps 8,000 entries or so, each of which tells the bridge where an address and its devices reside on the network) and make a decision. Incoming packets with known addresses are sent to those addresses; incoming packets with any other addresses are simply forwarded. (All Ethernet devices and some token rings can be considered to be bridges. They build their own internal routing tables by looking at the source and destination addresses of packets going by. When a packet with a known address comes by, the device sends it to that address. If it finds no match with an address in the internal table, it permits the packet to continue through the network). * Routers are smarter than bridges, allowing logical links of separate networks. The intelligence in the router can be used to reroute traffic in case some network component fails. The intelligence also can be used to translate from one protocol to another, such as from IPX to TCP/IP or back. Sometimes this intelligence incorporates OSPF (open shortest path first), an emerging standard developed by the Internet Engineering Task Force (IETF) that permits the router to find, moment-by-moment, the lowest-cost routing of traffic from one point to another. Routers become more appropriate than bridges as your network grows in size or complexity. With routers, you can create a mesh topology -- a large, complex system offering several paths between any two points. Mesh topologies are more fault-tolerant than other topologies, but potentially more difficult to secure. * The greater intelligence of routers has some drawbacks, of course. By examining each packet before sending it on, packet processing with routers can be slower than packet processing with bridges. Intelligence also has its price: you pay more for routers than for bridges. * Routers are normally one-way filters, whereas many bridges don't filter at all, directing some messages and sending others on to some general out-basket for further processing. Bridges are transparent to users users never see bridges nor do they need to address them explicitly. Your workstation explicitly addresses routers, and routers transmit only packets that contain authorized destination addresses they route to. Because routers examine the protocol of each packet that they receive, they prevent broadcast traffic from passing between networks, providing a firewall for separating individual segments. In network environments where different segments running different protocols should be isolated, the router can enhance security by filtering based on protocol. Some bridges have security features. For example, SynOptics's bridge modules can define and filter packets based on Ethernet source address, destination address, or Ethernet packet type, such as DECnet, LAT (local area transport), and TCP/IP network-layer protocols. You also can base filters on a range of addresses, a specific packet type, or a range of packet types. Up to 16 user-defined filters may be specified in a SynOptics's bridge. Although bridges permit some security at the device level, routers permit much stronger security through their addressing capability. Not all bridges are alike. The bridges we have been describing are local bridges; they connect networks within a single physical location. And local routers connect networks within a single physical location. Remote bridges and remote routers join networks at different locations, making the link through serial connections when direct connections are not possible. Through remote bridges and routers, LANs around the world are linked to form a single network. Brouters To confuse things, some bridges can route at the network level of the OSI model, making them routing bridges or brouters. Bridges that offer such features often incorporate a source routing technology developed by IBM. Brouters may attempt to treat a packet in the same manner as routers treat a packet, by trying to send the packet along using the correct route; if the brouter cannot, it falls back into bridge mode, letting the packet wander on and find its own destination. Unlike full-fledged routers, however, brouters usually do not monitor the exact route to which a packet is directed, leaving this task to each node that has initiated the packet. Advantages of Bridges over Routers Bridges have some advantages over routers: * Bridges are transparent to link protocols (which use higher layers) and support any transport protocol, such as TCP/IP, XNS, DECnet, and SNA. Bridges can connect networks using a variety of media (shielded twisted pair, fiber optic, 10BaseT, and so on) and a variety of link protocols (Ethernet, token ring, and others). * Bridges are easy to install, easy to adapt as you reconfigure your network, inexpensive, and insensitive to issues of distance and speed. * Bridges offer little to impede traffic flow, permitting speeds greater than 19.2 kilobits per second. In contrast, routers generally slow traffic to 9600 bits per second or so. Advantages of Routers over Bridges Routers have some advantages over bridges as well: * Bridges can connect only similar systems, such as two NetWare systems running IPX and NETX or two LAN Manager systems running XNS and NetBIOS. You cannot use bridges to connect LANs that don't support the IEEE 802.1 standard defining network interfaces and methods for Internetworking and network management, including transparent bridging, a spanning tree algorithm, source routing bridging, and source routing transparent bridging. You cannot use bridges with WANs using X.25, frame relay, or switched multimegabit data service (SMDS). You cannot bridge token ring to Ethernet systems if your token ring application cannot adjust to the Ethernet maximum packet size of 1,500 bytes. Routers can connect any protocols (IPX, IP, AppleTalk, NetBIOS, OSI, and so forth) and any media (Ethernet, Token Ring, FDDI, LocalTalk, ARCnet, and so on). * Routers can support mesh topologies, offering greater fault tolerance than bridges, which support tree topologies. * Routers support more subnetworks, more stations, and heavier traffic loads than bridges. * Routers let packets through and direct their flow, but good routers can also offer packet filtering to block some kinds of access attempts. They can be programmed to allow e-mail through, for example, but to permit file transfers between a provided list of addresses only. * Because most routers use TCP/IP simple network management protocol (SNMP), they can be monitored, shut down, or configured under software control. * Routers with some advanced security options are now on the market. For example, Magnalink Communications/Telco Systems Inc. offers optional full DES encryption with no decrease in throughput and an overhead increase of only 3 percent in their route-3000 router. Because bridges are not particularly effective security devices, the remainder of this report focuses on routers, gateways, and firewalls. --------------------------------------------------------------------------- Routers Many companies now offer routers. Of the 48,200 units shipped in 1992, Cisco shipped the most units (38 percent), followed by Wellfleet (13 percent), 3Com (8 percent), ACC (8 percent), CrossComm (7 percent), Proteon (7 percent), and other firms (19 percent), such as Compatible Systems, SynOptics, Telco Systems/Magnalink Communications, Novell, and Retix. Cisco Systems offered the very first routers in 1986, and by 1988, Cisco was already earning $20 million a year in revenues. The router industry is hot. Cisco grew by 194 percent in 1992, and Wellfleet (founded in 1988) grew by 254 percent that year. The products in this hot market are expensive. In 1992, the 48,200 units shipped brought in an estimated $517 million, at an average price per router of $10,726. Routers vary widely in price, of course. The Risc-Router 3000E comes with a price tag of $2,995. Although early routers offered by Cisco focused on the problem of connecting internal UNIX networks to the Internet via TCP/IP, newer routers incorporate software to manage multiple protocols and to make router management and reconfiguration easier, and emphasize tying internal networks together as well. Bridges and routers were once stand-alone boxes; now, you often find them within concentrators and intelligent hubs, such as in SynOptics System 3000 intelligent hubs. Some modern routers are simply software: the NetWare MultiProtocol Router is software that runs on a standard 80386 or 80486 with NetWare Runtime, with your choice of network cards. Such software-only products can offer formidable security. The NetWare MultiProtocol Router, for example, uses standard NetWare security features, including encrypted passwords, and can make certain servers invisible to certain users or network segments. A number of routers are available. For example, the RISC-Router 3000E is a high-performance, dedicated Ethernet-to-Ethernet router, supporting AppleTalk, TCP/IP, and DECnet protocols. It includes two LocalTalk network ports that provide connectivity for Macs and LaserWriters or other peripherals that are not connected directly to its Ethernet network ports. Ether-Route is a high speed, dedicated LocalTalk-to-Ethernet gateway/router with two independent LocalTalk ports, providing support for AppleTalk network protocols. Ether-Route/TCP includes all the features of Ether-Route, along with support for TCP/IP and DECnet network protocols. All three products include management and security software that provides flexible configuration and network resource protection options. All three include Compatible Systems' Advanced Network Security Protocol which enables the routers to password-protect individual network devices that do not currently have password protection (such as lasers) or to provide additional password protection for AppleTalk Remote Access dial-ups or AppleShare compatible servers. Each product comes with versions for thick, thin, and/or 10BaseT twisted-pair Ethernet. From Compatible Systems. Security Inadequacies of Routers Routers have some drawbacks: * One drawback of routers is a problem that occurs when someone on the outside tries to access your network via telnet. If telnet is permitted, then your internal network is vulnerable to attacks via password guessing. If your router does not provide for telnet, then you need to establish some other means by which your authorized outside users can call in. * Another drawback of many routers is that they do not maintain a log of access attempts. Without such a log, it is difficult to know which attempts were unsuccessful and whether or not your internal network is under attack. Protecting internal networks is not necessarily the job for routers, brouters, or bridges. As convenient as a simple router can be, it is likely that each of the available products has some significant shortcomings that permit them to be bypassed by a competent outsider. To fight fire, you might need a specially prepared gateway machine, or even a firewall. --------------------------------------------------------------------------- Gateways Gateways are computers designed to manage a link between an internal network and one or more external networks. Though most gateways are designed to handle both inbound and outbound connections, some handle only outbound traffic. For example, Novell offers gateway software for a PC on a NetWare LAN called X.25 Gateway, which permits any LAN user to establish up to eight simultaneous connections to remote asynchronous hosts offering e-mail services or public information databases, such as SprintMail, MCI Mail, CompuServe, OAG, and Dow Jones News/Retrieval. Such products can also be used to connect LANs to local X.25 minicomputers and mainframes. Many organizations have a simple gateway machine, such as a Sun, for handling both inbound and outbound traffic. Although such a gateway can be intelligently configured to filter packet flow, the gateway can be compromised. In the following brief section, we outline some of the things you should consider in building a sturdier gateway. In the discussion of firewalls, you learn how you can build sophisticated firewalls from a pair of such gateways. Tips for Securing Gateways To configure a secure gateway, begin by eliminating many of the penetration opportunities known by attackers. Your own code is likely to be better than a vendor's simply because its specifications aren't published, and the best methods of attack won't become common knowledge in the underground. In the following tips, we assume you are building a gateway to the Internet and that you use UNIX in your gateway machine. * Turn off IP forwarding in the kernel of your gateway machine so that packets cannot pass through it in either direction. * Modify the kernel to limit TCP connections from the outside to a minimum of ports: smtp, uucp, named, and hostname. Do not permit protocols such as tftp, sunrpc, printer, rlogin, or rexec. * Eliminate sendmail, replacing it with upas. sendmail has too many known holes and is too complicated to be mastered to the extent that you can be sure you have patched all holes. * Be sure your gateway machine is not equivalent to anything. Remove /etc/hosts.equiv and /etc/hosts.Ipd. * Remove any programs that are not essential to operations: awk, cc, emacs, sed, and so forth. * Remove any daemons you don't need, including the finger server. * Use chmod to change all system directories to mode 711. Users (and attackers) won't be able to see what's in them, superusers will, and everyone but the attackers will still be happy. Then be sure you make chmod unavailable to any user on your system because it can be used to change file protections. * Remove anything of value from your gateway. The machine should serve only as a barrier, and you should assume that it is vulnerable to exploration, even if an unauthorized caller cannot get through it to your internal network. Don't leave any power tools here for hackers, such as compilers or utilities. * Ensure that the only way to reprogram this machine is from its own keyboard. Then ensure that the machine is always kept in a secure room. Your next task, having disabled some essential services, is to replace them with surrogates that are more difficult to defeat. * Add a gate service that internal users can call, providing the gate with the desired Internet address. The gate can connect to a socket of a remote Internet host, then copy bytes from the gate to the host. The mailer will rewrite headers to make all mail appear to come from the gateway machine (user@office.company.com will be sent as user@company.com). To handle incoming mail, the gateway needs to manage a list of aliases to redirect the incoming mail to the correct users and locations on your internal network. To manage its gate service, AT&T Bell Labs uses atelnet and ptelnet, two versions of programs that replace telnet. * ftpFTP should also be replaced because it will try to establish a connection between the host and your gateway, which your gateway has been configured to prohibit. AT&T has done this with aftp and pftp, two versions of programs that supply ftp services. * Do not put any user accounts on the gate machine, other than accounts for those requiring incoming connections, the root account, and essential system accounts. * Whenever you can, mount disks as read-only. Remember, only a few directories need read-write status. Such directories can be placed on a single partition, with all other partitions read-only. * Upgrade your system software to the latest version. Previous versions probably have been studied and successfully attacked; the latest versions are more likely to include patches for these problems. * Consider replacing passwords on the Internet. If your remote authorized callers use a password, it can be compromised and later used to impersonate the authorized caller. Such compromise may occur in a variety of ways (for example, unencrypted passwords can be captured by WAN analyzers). A number of replacements for passwords are available, such as the handheld card offered by Security Dynamics. * If your gateway can require an encrypted password, fine. But remember that one or more internal systems may also require passwords, and such passwords are unlikely to be encrypted as they travel through the Internet. Try to determine which machines require unencrypted passwords and find out if there is some way to encrypt these passwords as well. If you can't, change passwords often, monitor access attempts, permit only one login of a given username at a time, lock out selected users at a selected time, let users see their last login time and urge them to report any suspected compromises, and permit users to change their own passwords whenever they suspect the password has been compromised. * If you can afford it, consider using a router to direct traffic coming out of a single port on your gateway to the network, and consider sending all the incoming traffic from your gateway machine through a controller and on to a second gateway. This second machine can be given the task of redialing or splicing connections to other approved internal machines, connecting to an approved machine's smtp port or to a login destination. This second gateway can offer services such as uucp, mail, and perhaps some user jobs. But be sure that the services provided to your outside gateway machine are carefully restricted. * To avoid an attack in which the caller attempts to fill the gateway server in order to crash the system and prevent the logs from being updated, use separate file systems for the ftp directory (accessible to the public), the logs, and the spool directory. * Consider logging all connection and login attempts, writing this information in a secure way (to a write-only server, for example). If you keep a log, then read the log efficiently and daily, paying special attention to failed attempts. Your next task is an ongoing project: * Turn on full logging on your gateway. Turn on process and file quotas, if you have this option. Do security audits with some regularity, looking for signs of unwanted change or administrative errors. Make adjustments as soon as you spot the need for them. Read the chapter on UNIX in Network Security Secrets and refer to other sources for guidance, such as UNIX Programmer's Manual. * Read the Internet news about worms, attacks, holes, and patches, and patch your system from threats as soon as you discovery vulnerabilities. * Back up your gateway frequently so that you are prepared to do a full restoration if you detect an attack. * Check your gateway machine regularly for signs of tampering. One good means of doing this is to checksum critical files, and compare the checksums with results that are stored offline. Also, check for any new files that are not expected. * Even if you don't find any signs of entry over a period of time, don't grow to trust your gateway. Rather, assume that an attacker will visit tomorrow or that an attacker has already broken in, but has not been detected yet! Summary This was a difficult report, and you are to be commended! We began by comparing and contrasting the confusing, bruising world of bridges and routers. We moved on to a look at gateways, and we offered some guidance for securely configuring a gateway. If you are in the market for a firewall of some sort, we suggest you do the following: * Sift through the concerns raised in this report and make a features shopping list. * Sign up to be added to some mailing lists so that you can keep up on advisories of known holes in various products. * Go to a trade show, such as COMNET or INTEROP, and spend a few days in the exhibit area. Find every vendor that seems to have a product of interest, and let them add to your education. What features from your list do their products offer? At what price? What other features not on your list do they offer that you might like? What flaws can they find with their competitor's products? * When shopping, see if you can implement the features you want with software alone. If you can, you will find management and reconfiguration easier than if you must go with a hardware/software combination. And you'll likely pay less for software alone than if you must buy proprietary hardware. * Take good notes and share what you learn with others, who can share the responsibility for the decision. Let us know how things turn out. For Further Reading * "Improving the Security of Your UNIX System" by David A Curry, Technical Report ITSTD-721-FR-90-21, April 1990. Information and Telecommunication Sciences and Technology Division, SRI International, 333 Ravenswood Avenue, Menlo Park, CA 94025. Comprehensively lists a variety of potential things to check for in setting up your system. This is a must-read paper for any security-conscious system administrator. It has a variety of checklists beyond what COPS checks for and also recommends other literature. * "Coping with the Threat of Computer Security Incidents -- a Primer from Prevention Through Recovery," by Russell Brand, Internet document, June 1990. Available via anonymous ftp from cert.sei.cmu.edu. Has some hints similar to the preceding paper. Lists common accounts on VMS and CMS systems that are obvious holes, which have been used in the past by miscreants. It also contains hints on dealing with incidents as they occur, including tips on whom to contact in the event of trouble, how to handle the press, and so on. * Site Security HandbookSite Security Handbook, by Paul Holboork and Joyce Reynolds, RFC 1244, July 1991. Available via anonymous ftp from nic.ddn.mil. Developed by the security working group of the Internet Engineering Task Force (IETF), this book lists possible shortcomings on various systems and suggests policies that an organization should adopt. * "Security Problems in the TCP/IP Protocol Suite," Steven M. Bellovin, ACM Computer Communications Review, April 1989. This paper discusses problems in the TCP/IP protocol suite, including the potential for spoofing hosts, and more. Most of the problems discussed here are quite esoteric and are far beyond the capabilities of the average hacker. * The National Institute of Standards and Technology (NIST) has issued a few publications that discuss general management topics regarding computer security: * "Computer viruses and related threats," by John P. Wack and Lisa J. Carnahan, Technical Report Special Publication 500-166, NIST. * "Executive guide to the protection of information resources," NIST Special Publication 500-169. * "Management guide to the protection of information resources," NIST Special Publication 500-170. * "Computer user's guide to the protection of information resources," NIST Special Publication 500-171. * "Requirements for Internet hosts-communication layers," by Bob Braden, RFC 1122, October 1989. Available via anonymous ftp from nic.ddn.mil. "Requirements for Internet hosts-application and support," also by Bob Braden, RFC 1123, October 1989. Available via anonymous ftp from nic.ddn.mil. These two works define the standards for host configurations for all hosts on the Internet, and the Orange Book (Department of Defense Trusted Computer System Evaluation Criteria [TCSEC]), published in August 1983, is the classification of all hosts on the basis of their security. Available via anonymous ftp from ftp.oar.net. * Computer Security Basics, Deborah Russell and G.T. Gangemi, Sr. Practical UNIX Security, Simson Garfinkel and Gene Spafford. These are two new books published by O'Reilly & and Associates. prepared by David J. Stang, Ph.D. © 1996 Seven Locks Software, Inc. All rights reserved. Used by permission Quick Search: [Reseller Locator][Subscribe to E-NEWS][Evaluation Software][Product Information][Solution Center] [Registration] [Home][Search] [Sales Center] © Copyright 1995-1997 Computer Associates International, Inc. and or one of its subsidiaries. All Rights Reserved.