This page discusses two aspects of Web server security:
Pointers to more information on security are provided on a separate page.
If your Web server is accessible only from your company's private internal network -- that is, if it isn't connected to the Internet -- then the Web server poses no greater threat than any other computer on the internal network. But if you want people outside your company to be able to reach your server, you must connect to the Internet; such a connection has inherent security risks. Once your internal network is connected to the Internet, anyone with Internet access can potentially connect to any system on your private network. Since not everyone is trustworthy, computer and network security systems are recommended to restrict access.
The safest way to connect a Web server to the Internet is to completely isolate the server from the internal private network (that is, to allow no connection between the Web server and the private network). In this kind of configuration, you can transfer Web content from the private net to the Web server only by "sneaker-net": a floppy or a DAT tape, or some other form of removable media, physically carried from one system to another. This approach, while very secure, is probably the wrong way to run a Web server or connect to the Internet. The ability to access the private net from the Internet and to access the Internet from the private network is just too valuable.
Therefore, if you want a highly secure connection to the Internet, you probably need a firewall.
A common approach to Internet security is to construct a firewall between the internal network and the Internet. Firewalls are systems that control the flow of traffic between the Internet and internal networks and systems. A firewall can consist of a router, a computer system, or a combination of the two.
There are a variety of possible approaches to firewall design. Historically, there's been disagreement over the best approach: one camp suggested that adequate security could be achieved by using only the packet filtering mechanism available in most routers, while others maintained that sites that were serious about security had to use an application level firewall -- on a computer, not a router -- and authentication as well as packet filtering. Today, packet filtering is considered an optional but useful piece of a firewall rather than a complete firewall solution.
The packet-filtering part of a firewall involves using a screening router as the connection between your internal network and the Internet. An elaborate table specifies which packets should be passed on to the other side of the router and which should be thrown away ("dropped"). This approach is convenient because it's an extension to what the router already does: routing IP packets from one side to the other. Most of the large router manufacturers, such as Cisco and Bay Networks, offer packet filtering on their routers.
Each line of the routing table contains a destination IP address, a source IP address, and an IP port number. Each line also indicates whether packets that match the given description are to be allowed through to the other side of the router, or dropped. Every IP packet contains information about where it comes from and where it's going; each time a packet arrives at the router, the router checks the packet's address information against the routing table.
However, the individual packets give no indication what sort of transaction they're part of -- such as whether they're part of a piece of mail, part of a telnet session, or part of a file being transferred via FTP or HTTP. This lack of information makes it difficult to tell from looking at the routing table exactly what effect a given entry will have on users using applications.
And it's easy to make mistakes in setting up the routing table. Most people don't think in terms of IP addresses and port numbers. Some packet filters provide a graphical user interface to help with table administration, but the conceptual difficulties remain. Add an entry to allow access to your private network from some favored remote site on the Internet, and if you're not very careful you can end up inadvertently allowing wide-open access to your site. Therefore, setting up your own packet filtering is not recommended unless you're a very experienced system administrator.
Not only are packet filters difficult to do right and easy to get wrong, they also just don't handle some high-level application services very well -- services such as FTP, X Windows, and DNS.
Some system administrators dislike packet filters because of their inadequate logging facilities. Packet filters only log the raw packet data going into and out of the router. It would be far more useful to be able to see information about (for instance) whether a hacker has attacked an application like telnet or ftp. Packet-level logging is much harder to interpret than application-level logging.
Finally, screening routers look only at packets; they can't use proxies, and they don't do authentication. Thus, it's possible to "spoof" IP packets, making a router believe that the packets come from somewhere other than where they're really from.
For all these reasons, if you want real security you need more than just a router.
Another way to build a firewall is to put a computer system between the Internet and the private network. Such a system is sometimes referred to as a bastion host, a dual-homed host, a dual-homed gateway, or an application proxy system. Many companies concerned about security use both a bastion host and a packet-filtering router. (A router is needed to connect to the rest of the world anyway, so using it for packet filtering makes sense, as long as it's backed up by a bastion host.)
The idea behind a proxy-server-based firewall is to break the IP connection between the Internet and the internal network. Such a firewall system has two separate network connections (and two IP addresses, one internal and one external). A proxy server (also known as an application proxy) such as sockd takes in packets received by both connections and decides whether to send them on to the other side of the firewall. There is no connection between the two network connections inside the operating system kernel; all packets go through the proxy server. Among other security features, proxy servers prevent the IP spoofing problem that can breach security in a screening-router-only firewall.
A proxy server is just a miniature version of an already existing network service that you want to allow to send data through your firewall. For example, a user on the private network who wants to use telnet to connect to a computer on the Internet would first connect to the application proxy running on the bastion host. This proxy makes decisions about whether the application is allowed to transmit packets to the Internet or not based on a wide variety of parameters specified by the system administrator, such as target system, time of day, user name, and so on -- parameters that a packet filter doesn't have access to. If the requirements are met, then the proxy passes the packets to the other network interface on the bastion host, which sends them to the Internet. Proxy servers therefore provide much finer control than packet filters over which packets can be transmitted across the firewall.
There are two common approaches to setting up proxy servers: a SOCKS proxy server, and the TIS(TM) Internet Firewall Toolkit (or possibly Gauntlet(TM)) software.
Once you've got a proxy server system set up, you have to configure Netscape Navigator to get it to work properly with the selected proxy server software.
In the SOCKS system, a single proxy server (sockd) runs on the firewall host. Any application running on an internal host that needs to reach the Internet must be specially modified ("SOCKSified") to be SOCKS-aware. (Netscape Navigator has already been made SOCKS-aware.)
In a small homogeneous environment with only a few applications that need to reach outside the firewall, this is a workable solution. Unfortunately, in a large heterogeneous environment, the SOCKS approach requires a separate SOCKS-aware version of each application for each operating system. Thus, you might need to have separate SOCKS-aware versions of ftp, telnet, finger, an IRC client, and Netscape Navigator for each of several different brands of UNIX, not to mention any PCs that might be part of your internal network. This approach is a system administrator's nightmare in such a network.
You can obtain the sockd proxy server by anonymous ftp from various sites; download the SOCKS FAQ for information about SOCKS and how to get it. (Note that you can only use this link if you're already connected to the Internet.)
(Silicon Graphics® makes no warranty or representation regarding SOCKS software.)
The TIS Internet Firewall Toolkit provides a separate proxy server on the firewall host for each application, rather than a single proxy server for all applications. The applications themselves don't need to be modified; the users of internal hosts can use the same software they would use without a firewall. Each proxy server is fairly small and relatively easy to understand, though not necessarily easy to compile.
TIS provides source code for its Internet Firewall Toolkit for free; if you're an experienced administrator, you can go ahead and get this software from TIS. TIS also provides a commercial pre-compiled version of the Toolkit, known as Gauntlet(TM), with full customer support. Unfortunately there's no Makefile for the free version of the Toolkit for Silicon Graphics systems as yet, so setting up the Toolkit on your firewall may be difficult unless you purchase Gauntlet.
The Toolkit doesn't rely on any router security, though you can use a packet-filtering router with it if you wish. The Toolkit also includes tools to authorize, monitor, secure, and log network traffic, for authentication purposes.
(Silicon Graphics is not affiliated with TIS and makes no warranty or representation regarding any TIS product.)
Another side to security is transaction security (as opposed network security). Conducting commerce over the Internet requires answering the problems of authentication, privacy, and reliability.
The authentication problem is solved using cryptography. A message is put into code ("encrypted") so that only a person with the proper key can translate it back into readable form ("decrypt" it) and read it. There are two types of cryptography, symmetric and asymmetric.
Symmetric cryptography is also known as private key cryptography. Using this method of encryption, the key used to decrypt a message is the same as the one used to encrypt the message. The Data Encryption Standard (DES) is a widely used private key cryptographic system. The problem with such systems is that it's difficult for the message originator to distribute the key. Physically handing the key to a message recipient usually isn't feasible, but is often the safest alternative.
The asymmetric cryptographic system is also commonly known as public-key cryptography. Using this method, a message originator uses a private key to encrypt a message. Anyone who has the sender's public key, which is widely distributed, can decrypt the message. The receiver knows that the message really did originate from the sender because the public key only decrypts messages that were encrypted by the private key held by the sender. Thus, private key encryption solves the authentication problem because a recipient can be assured that a message is really from the person it says it's from.
Public-key systems can also solve the privacy problem. Someone sending a message can use the recipient's known public key to encode the message. Since the private key is the only way to decrypt a message encoded with the public key, the sender is assured that nobody but the intended recipient can read the message.
Finally, public-key systems solve the problem of reliability because a message sender can include information inside the encrypted message that allows the recipient to determine whether or not the message has been tampered with. Therefore, public-key cryptography allows messages that are authenticated, private, and reliable.
The best currently available public-key cryptography system is the algorithm invented by Rivest, Shamir, and Adleman, an algorithm known by the creators' combined initials: RSA. The security of this algorithm relies on a couple of mathematical properties of prime numbers: specifically, the fact that it's easy and fast to multiply primes together, but exceedingly difficult to factor the product of two large primes.
RSA is also the name of the company founded by the RSA inventors, a company which provides cryptographic solutions to industry. Netscape Communications, for instance, uses RSA public-key cryptography in the Netsite Commerce Server to provide authentication, privacy, and message integrity.
The way the Netsite Commerce Server uses public key cryptography is through the Secure Sockets Layer (SSL). Invented by Netscape, SSL is a new layer in the TCP/IP stack that fits between the TCP/IP data transport layer and the TCP/IP applications layer. SSL allows Netsite's Commerce Server to encrypt an entire application session such that no information is ever transmitted without first being encrypted. Therefore, transactions for applications such as ftp, telnet, and Usenet newsreaders, as well as HTTP transactions, can be conducted securely.
Given that SSL is already embedded in the Netscape browser, used by over 70% of Web surfers today, Netscape's proposed SSL will most likely be adopted as a new Web standard. The other well known Web security proposal, also based on public-key cryptography, is Secure HTTP (SHTTP), proposed by Enterprise Integration Technologies (EIT) and Terisa Systems. Unlike SSL, SHTTP only provides security for HTTP, or Web transactions. With the recent investment of Netscape in Terisa Systems, most industry observers believe that these two security standards will merge.