|
|
by John Jung
Because Web sites are usually very high-profile, they tend to attract a lot of attention. For many organizations, this attention is exactly what they want. The downside to all that exposure is the possibility of people using the Web site to break in to the company. Typically, the more high-profile the company sponsoring the Web site is, the more attempted break-ins there are. Consequently, Webmasters now have to address issues that were typically the domain of network administrators. Obviously, the Webmaster isn't going to replace the network administrator; however, they do share some tasks. This chapter explains what issues are involved in maintaining Web server security.
Probably the most obvious security issue that a Webmaster has to deal with is traffic from the Internet. Because the Internet is likely to generate more network traffic for the site than internal users do, how to handle traffic from the Internet is a very big concern. One of the most important aspects of Web server security is controlling who has direct access to the Web server. Another security issue is making sure that the content of the Web site is inoffensive and follows the company line. Another security issue concerns CGI scripts, which are used in some Web pages.
Traditionally, Web servers are run off of UNIX computers. UNIX, in addition to being extremely powerful, is a true multiuser and multitasking operating system. Also, by nature UNIX is generally a network-dependent environment. Consequently, UNIX servers are one of the most popular targets for unauthorized remote logins. UNIX-based Webmasters have their work cut out for them. Among the more obvious tasks that they should do with the Web server is to ensure that users have secure passwords. One way to ensure the security of passwords is to force users to periodically change them.
Before making your Web site publicly accessible, make sure you've changed a number of system passwords. Aside from the obvious root account, there are some other predefined accounts that you should fix. Among them are bin, nobody, guest, daemon, and sys. Depending on the flavor of UNIX you're using, there might be more, or fewer, predefined accounts. Because these accounts are predefined, they also come with predefined passwords. Not only does your operating system vendor know these passwords, but so do hackers. As a good safety measure, change all the passwords on all predefined accounts.
As a final measure, look at your system from a hacker's point of view. A number of publicly available packages help you to hack into your system. Obviously, you're not trying to do anything malicious, but these packages attempt to find holes in your security. Get some, or all, of these packages and try them out on your system. If a package finds any holes, fix them yourself, or get your system or network administrator to fix them. Additionally, check to see whether your OS vendor has released any operating system patches. If it has, download them and apply them.
Tiger, by Texas A&M University, is one collection of programs. It has no official home page, but you can get a copy of it by pointing your Web browser to ftp://net.tamu.edu/pub/security/TAMU/tiger-2.2.3.tar.gz. An older hacking package known as COPS, by Dan Farmer, has an unofficial home page at http://misbss20.larc.nasa.gov/security/4.0/cops.html. However, you can't download it directly from that site, as it's intended only for NASA personnel. You can, however, get COPS from ftp://info.cert.org/pub/cops/1.04/cops_104.tar.Z. Finally, there's the highly regarded SATAN (Security Administrator's Tool for Analyzing Networks). You can find out more about it by using the URL http://www.fish.com/satan/. You can get a copy of its source code from ftp://ftp.win.tue.nl/pub/security/satan-1.1.1.tar.Z.
| Caution |
UNIX hacking programs are intended for use by system and network administrators. They will slow down the system they are running on and can take up to several hours in generating a report. They are not intended for general end-user use. |
Non-UNIX operating systems are, most of the time, far more secure than UNIX. This difference isn't because the software for UNIX is inferior; it's just that the personal computers aren't designed the same as UNIX is. Specifically, Windows 95 and the Macintosh aren't designed to be as multiuser as UNIX is. Consequently, where most UNIX boxes come enabled with a number of Internet services, the personal operating systems don't. In fact, personal operating systems often require you to install server software.
There is, of course, a middle-ground operating system, Windows NT. This environment is as multiuser and multitasking as UNIX, but is more approachable. This quality is primarily due to Windows NT's built-in user interface. However, it, like the personal operating systems, doesn't have built-in services. It too needs server software to be installed before remote access security issues can become an issue. Additionally, the majority of Windows NT programs require the graphical user interface. This requirement makes it so that only the command line-based programs are accessible to a hacker.
Another Internet security issue that concerns Webmasters is the content of the Web site. You, the Webmaster, have to make sure that all the Web pages on your site meet company standards. For example, sensitive company information should not be made available on the public Web server.
You should also watch out for sources of possible lawsuits on your Web page. Make sure there aren't any copyrighted images on your Web site. All images from comic strips, movies, or magazines must be authorized. Also, get rid of any content that may be offensive to users of the site, such as nude pictures or offensive language. Aside from possible lawsuits, such elements may turn off people from your Web site.
Some may feel that talking about Web content has little to do with security. Unfortunately, there are real-life events where hackers have modified content. One such incident happened in August of 1996, when hackers broke into a computer at the Department of Justice. They heavily modified the main Web page, adding profanity, swastikas, and other completely unrelated content. A similar incident happened about a month later to the CIA's Web page, except the modifications were less severe. Although these incidents might have been politically motivated, they could still happen to companies. In fact, high-profile, well-known companies are often the target of unsucessful hacking attempts.
A final aspect of Internet security is to make sure that certain pages are password-protected, if necessary. Especially in large organizations, sometimes it's not a good idea to reveal all information. Suppose you work at a large service-oriented business with different groups for different customers. Further, suppose an information area is created for a particular customer and maintained by a particular group. The area allows the specialized group and its customer to interact with each other in privacy. Obviously, this information area should be protected so that only certain users can access it.
CGI scripts are another security concern for most Webmasters. Typically, the Web server software is running as a privileged user. This kind of user often has certain privileges that are beyond the scope of normal users. CGI scripts run with the user and group permissions of the Web server, which means that CGI scripts should be heavily regulated. After all, a malicious CGI script could be written to exploit the Web server's special privileges. In some cases, it would be possible for such a script to delete all or some of the files on your Web server. Either each CGI script should be analyzed and dissected, or each one should go through rigorous testing. Some Web sites completely disable save access to areas where other CGI scripts are stored.
In addition to dealing with Internet-related security, a Webmaster has to deal with intranet-related security. Just because the intranet is not available to everybody doesn't mean that security should be relaxed. All of the Internet-related problems also exist on an intranet. Most of the solutions just have to be applied in a different fashion. For example, you still have to look out for the content of the Web site by watching out for possible lawsuit issues, such as copyrighted images, but you also have to focus on keeping groups divided. For example, you may not want the sales department to be able to access everything in the development Web pages.
Also, you should watch out for possibly malicious CGI scripts. Although such scripts might not be malicious by design, badly written scripts can cause plenty of problems. As a result, you don't want to give carte blanche to intranet-based scripts. In addition to minimizing the problem of poorly written CGI programs, restricting access to the cgi-bin directory can prevent other problems. Suppose a disgruntled employee wrote a malicious script just for vengeance that wreaked havoc on your intranet. Far better to not allow this to happen than to deal with the consequences if it does happen.
Probably one of the easiest security issues for traditional Webmasters is how to control access. As Webmaster, you want to be able to ensure that Web authors can modify their own Web pages. You wouldn't want somebody to be able to modify someone else's pages. On personal computer operating systems, this type of segregation can be very difficult.
Fortunately, most traditional Web servers are run off of UNIX systems. Consequently, you can use UNIX's built-in user and group permissions. Basically, you can keep users away from each other's files by planning ahead and creating as many groups as possible. Be sure to restrict each user you add by giving him group access only to the files that he needs. Similarly, you should also make sure that all Web pages have appropriate permissions. In particular, avoid giving everybody write access to all Web pages.
So far, I've focused on controlling access permissions of files on the Web server. I've assumed that the people who log on to the system are there because they're supposed to be. But Web server security has another level beyond file protection. The entire system also needs to be protected from unauthorized access. There are a number of approaches that network administrators and Webmasters can take to protect their systems. One common way is to put up something known as a firewall.
Simply put, a firewall separates an internal network from the Internet. It screens and filters all connections coming from the Internet to the internal network and vice versa. This filtering is done through a single, concentrated security checkpoint. All network activity between the Internet and the internal network must go through the firewall. A firewall acts as an electronic gate, allowing in only authorized users. You can manage a number of aspects of this gate as well as keep logs and statistics of activity. Some firewalls even require you to log onto the firewall itself before passing through the gate.
| Tip |
Using FTP, you can get information on firewalls from mailing list archives at the following URL: ftp://ftp.greatcircle.com/ub/firewalls A firewall toolkit and papers are available at the following URL: ftp://ftp.tis.com/ub/firewalls |
Believe it or not, there are some inherently insecure services and systems on your internal network. As mentioned in the "Remote Access" section of this chapter, new UNIX machines have a number of predefined passwords. Although it might make sense to change all these passwords for a single machine, this concept becomes unworkable with a large network. It would be a tremendous undertaking for a company with over 2,000 UNIX systems to change all its predefined passwords.
A firewall protects such machines and services that might not be secure. As a result, your internal network is exposed to far fewer risks and dangers. Because the firewall filters out unwanted protocols, there are fewer holes in your network security. This brings peace of mind not only to your network administrators, but also to each individual system administrator.
For example, a firewall could prohibit certain vulnerable services, such as NFS, from entering or leaving your internal network, so you prevent the services by being exploited by outsiders. A firewall also allows your personnel to use the services with less risk of exploitation. Services such as NIS and NFS, which are particularly useful for an internal network, can be used without exposing the network to outside threats. These two services in particular make systems management easier for all administrators.
The problem with firewalls, though, is that they limit access to and from the Internet. In some configurations, you may decide to use a proxy server (see the "Proxy Service" section of this chapter) to filter inbound and outbound access. Although not necessary, proxies can be very useful.
A firewall can provide a fine level of access control to internal network machines. For instance, some servers can be made reachable from outside networks. Similarly, other systems can be effectively sealed off from unwanted access. Depending on the level of risk you are willing to accept for your Web site, watch out for outside access to internal network servers. Only under special situations, such as mail servers or RAS services, should you not be too overly concerned. When setting up access control systems, keep the following rule in mind: never provide access to servers or services unless it is required. A good rule of thumb in access control is to keep the available servers and services to a minimum. Following this rule will limit the number of possible break-in points on your system.
A firewall can be less expensive for an organization than security measures on individual machines. Because the firewall is a central filtering point, you can put security software on the firewall system itself. This solution is preferable to distributing such packages to each and every machine on your internal network. In particular, one-time-password systems and other add-on authentication software can be located at the firewall rather than on each system that needs to be accessed from the Internet. As a result, instead of configuring the 2,000 machines on your internal network, you only configure one: the firewall.
Other solutions to your Web site security could involve modifications at each server system. In some cases, such solutions might be preferable to using a firewall. However, firewalls tend to be far simpler to implement because only the firewall machine needs to run specialized software. However, if you have a package-filtering firewall or require your users to log onto the firewall, you'll need more hardware. In all likelihood, you'll need either a router that filters the packages or a dedicated machine.
| Caution |
Don't neglect internal security just because you have a firewall. If a hacker breaks in, your network will be exposed unless you have some internal security policies in place. |
Privacy should be of great concern for every Web site because all information might be useful to a hacker. Regardless of whether the information appears dangerous, there might be subtle clues that a hacker can pick up on. By using a firewall, Web sites can block access from services such as finger and Domain Name Service (DNS). Typically, people use finger to get information about individual users, such as whether they've read mail and their last login time. However, finger can also be used to retrieve information about the entire system. It can be used to tell how often a system is used and whether users are currently logged on. This information, though by itself harmless, allows hackers to decide whether that system can be attacked. And getting the information in this way doesn't attract the attention of system and network administrators and monitoring software.
Another approach to keeping your internal network private is to maintain separate DNS servers. You could have an internal DNS server that contains all the host names and IP addresses of your internal network. Another external DNS server could be set up to contain only the host names and IP addresses of certain machines. Only those machines that are important to other Internet servers would be on the external DNS. Some Web administrators feel that this setup hides material that otherwise would be useful to hackers.
Firewalls can be configured to log accesses to and from the Internet. This log provides important information about network usage and where possible weak points are in your network. You should have a log of your Web site usage statistics and evidence of probing for a number of reasons. The first reason is to know whether the firewall is withstanding probes and attacks. This information allows you to determine whether the controls on the firewall are adequate. Another reason to track Web server usage statistics is to provide input to network requirements studies and risk-analysis activities.
| Tip |
A firewall with appropriate alarms that sound when suspicious activity occurs can also provide details on whether the firewall and network are being probed or attacked. |
Although a firewall might seem like an adequate form of protection, it isn't the only one. Another form of protection for your network, as well as your Web site, is a proxy server. Unlike a firewall, proxies enable you to work with services that might jeopardize your network, but it keeps them from being a threat.
A proxy is a program that takes the data of another program and interprets and filters it. A proxy filters information based on the application and service supported by the proxy. This is different from a firewall, which merely filters out data based on what port number it's coming from. Proxy services allow through only those services for which there is a proxy. If an application gateway only contains proxies for FTP and telnet, only FTP and telnet are allowed into the internal network. All other services are completely blocked, even if they pass through the firewall. This degree of security is important. A proxy makes sure that only trustworthy services are allowed through the firewall and prevents untrustworthy services from being implemented on the firewall without your knowledge.
| Note |
If you have used TIA (The Internet Adapter), slirp, or TERM, you probably are familiar with the concept of redirecting a connection. Using these programs, you can redirect a port. Proxy servers work in a similar way by opening a socket on the server and allowing the connection to pass through. |
In terms of Web servers, a proxy is a special HTTP server that typically is run on the machine running the firewall. A proxy basically does the following:
Usually, all of the clients in an internal network use the same proxy. This setup enables the proxy to efficiently cache documents that are requested by several clients.
| Note |
The fact that a proxy service is not transparent to the user means that either the user or the client will have to be made aware of the proxy. Either the user is instructed on how to manage the client in order to access certain services, or the client, such as a Web client, is made proxy-aware. |
Because proxies are created on an application-by-application basis, they know about the data being sent. Whereas firewalls blindly accept or deny data based on a particular port, proxies can interpret the data. This provides for much more detailed logging information, such as IP addresses, date and time, and other useful information. Another characteristic of proxying is its capability to filter client transactions at the application protocol level. It can control access to services for individual methods, servers, domains, and so on.
Technically speaking, proxy servers act as two separate programs, a client and a server. When a client requests data through the proxy, the proxy intercepts the request. So in this regard, the proxy is the client's server for any such application activity. The proxy then makes the request for information from the specified host. In this regard, the proxy is acting as a client. Finally, the proxy sends the data it received from the server back to the original client. Once again, the proxy is acting as a server to the user client.
| Note |
A complete Web proxy server must speak all of the Web protocols, especially HTTP, FTP, Gopher, and NNTP. |
With most data that's transferred from a Web client, everything is transmitted in the open. If the Web browser is sending data, it merely sends the exact piece of data, so that if the Web client were told to send the word test, the word test would be sent. This sort of approach is fine for everyday use and almost all situations with the Web. Unfortunately, it's not perfect, nor preferred, for a number of situations. In particular, if you're sending confidential information, such as a credit card number, this situation is unacceptable. Even though the chances that your credit card number will be seen are remote, the possibility does exist.
To allow data transmissions in which no information is blatantly obvious, the data must be hidden in some form. Although there are many proposed methods of hiding information, the most popular one is to encrypt the transmitted information. What this means is that when a Web browser sends the word test, the word doesn't look like test while it's on the Internet. Only the destination Web server knows how to decode the encrypted data. After the information is decoded, the Web server can process the information accordingly.
The most popular form of Web data encryption is known as the Secure Sockets Layer (SSL). Although not yet fully accepted, its widespread support makes it likely that it will be fully accepted soon. What SSL does is take the information that's going to be sent over the Internet and encrypts it by using some sophisticated forms of public key cryptography. As a general rule, SSL is very secure. Although it's not completely inpenetrable, it's extremely hard to break.
| Note |
You can find out more about Web security by pointing your browser to http://www.genome.wi.mit.edu/WWW/faqs/www-security-faq.html |
| Note |
As a point of reference, Pretty Good Privacy (PGP) uses a technology similar to SSL. It took a concerted effort of many users and workstations over eight months to break a PGP-encoded message. |
Most Web sites can work fine without having to encrypt their data. Companies that sell goods over the Internet, however, should look into using some form of encryption. Currently, the only Web servers that can use SSL are those by Netscape and Microsoft. Be aware that implementing SSL, as per Netscape's proposal, is a rather daunting task. As of this writing, there are no available public SSL-capable Web servers.
After all the content for your Web site is created, you'll want to be able to access it. Regardless of whether you're behind a firewall, server access raises several issues. One fact to consider is whether your Web server is an Internet server or an intranet server. Intranet servers are far easier to implement because there is little threat of an unauthorized break-in. Although such a threat still exists, you have better control over it. You probably don't need to worry about firewalls and proxies with an intranet Web server. The only security concerns you deal with relate to user and group permissions.
Internet Web servers are a different matter. For many small-to-medium sized companies, the Webmaster is probably also the systems administrator. Consequently, when you start up a Web site, you have to look at all security concerns. If your site already has a firewall or proxy server, you will have to make sure that the Web server can talk through them. If your organization doesn't have any form of protection, you should look into implementing at least some form of protection.
In large companies, being a Webmaster is a bit easier because you don't have total responsibility for the entire system. Chances are good that some sort of security mechanism is already in place. All you, the Webmaster, have to do is get your Web server to work with it. If your company has a firewall, you'll need to talk to your network administrator. He may need to get justification for opening up a hole in the firewall. If a proxy server is in place, the network and systems administrators may have more work to do. They may need to set up a Web server proxy service for your Web site. Whatever the case, though, you, the Webmaster, won't have that much to do. All you have to do is make sure that the Web server software is made aware of proxies.
Web server security is a very important part of being a Webmaster. It includes security for the Web server itself as well as its content. To maintain content security, you can use UNIX's built-in set of tools. In keeping with the theme of maintaining content security, you can restrict access to other Web pages by carefully planning out user and group permissions. User accounts enable you to create a corporate-wide Web page, as well as let individual users create their own home pages.
Another aspect of Web server security is to prevent unauthorized people from accessing your system. Two methods of doing this are firewalls and proxy servers. Most Web servers will have no problems talking through a firewall. However, some configuration will be needed to make them proxy-aware.
