Security: Access Control

Autentification and autorisation

One of the final tasks of configuring your intranet server is access control. This entails determining your security needs, designing a security mechanism, and implementing your planned approach. Depending on your needs, this can be simple or complicated. Running an intranet site for 15 different clients is far more detailed than running one for your business alone.

This chapter walks you through the steps necessary for configuring your server's access control. The topics that are covered include the following:

  • Determining your security needs
  • Security mechanisms
  • Implementing your plan
  • Client configurations

In this chapter, you'll use a sample Web site, www.snookums.com. The administrator of that site, Spider, has just added a new domain, sweetie.com, to his list of served domains. I'll guide you through the process of setting up security and discuss what Spider did for his two domains.

Security and the Intranet

Web servers by nature are dumb. They do exactly what is requested of them: serving files stored on your system to any system that requests them. Before implementing your intranet server, you should consider the data that is being offered and to whom it should be served.

The default Web server installation provides virtually no security. Anything that you place into your server's document root directory is fair game for any Web surfer, both internal and external. Unprotected and misconfigured servers are open to cracking and the loss of important data.

CGI scripts also are a big security risk. If one of your scripts contains bugs, or was created to harm your system, you can run into trouble. Scripts should be carefully debugged and tested before being installed on your server.

Tip
For some excellent intranet and general Web security information, see the WWW Security FAQ
http://www-genome.wi.mit.edu/WWW/faqs/www-security-faq.html

Crackers Tread Where Administrators Fail to Secure

More and more movie companies are promoting their films on the Internet these days. It is a relatively inexpensive way of notifying the public of what is coming. Before MGM/UA released the motion picture Hackers, it put up a Web site promoting the film. The movie, which did not look appealing to real hackers, was a good target for mischief. Hackers were insulted by the connotations summoned up by the film

.

Note
There is a common misnomer when it comes to hackers
A hacker is someone who hacks code. Generally systems programmers, hackers feel that they can code just about anything. If they don't know how to do it, they will find out. Hackers are good..
Cracker, on the other hand, is the term that truly defines the mischievous and sometimes destructive person who is out to beat the system. Crackers are the kind who will try to break into systems, use stolen long-distance access codes and credit card numbers. Crackers are bad.

The Hackers site opens with an image of the movie poster that is displayed at theaters. The following URL displays what the site looked like before it was hacked: 

http://www.mgmua.com/hackers

A group of crackers downloaded the picture and HTML file and modified it to suit their whims. The resulting picture and Web page were left for new visitors to see at 

http://www.mgmua.com/hackers/inventory/hacked/index.html

The crackers were able to do this because the administrator at MGM/UA left the HTTP PUT method unsecured. Anyone with the inkling could overwrite any file that was there.

This break-in was not malicious. But while the site was unprotected, you can only imagine the things that could have been done-files deleted, accounts compromised, even the complete destruction of all data. This is why access control is so important to every Web administrator.

Living Large

It has been proven all too often that software programs contain bugs. This is not to say that all programs are buggy, but many popular programs on the market today have bugs. A majority of these bugs go unnoticed by the user and are fixed with the next release. Some bugs do affect users.

The general feeling in the security community is that the larger the program, the more likely it is to have bugs. Bugs can cause security holes. There is no greater example of this than the infamous sendmail debug bug that spawned the Internet Worm.

Note
There was a bug in sendmail, a UNIX mail handler, that allowed a savvy cracker to run programs on the host machine. This bug involved the use of debug mode. You could telnet to the SMTP port of any machine running sendmail, and if not disabled, debug mode would be active.
In 1988, a student named Robert Morris, Jr. exploited this and other UNIX daemon bugs, and released what is now known as the Internet Worm. The worm was thought, at first, to be a virus spreading wildly through the Internet. It was found to be a program that replicated itself and then used telnet to reach other systems and replicate itself again using the same debug mode bug in sendmail, among others
The Worm was a small program; however, it had several bugs. One of those bugs was the reason it crippled part of the Internet. If it had run properly, the Worm would not have spread as quickly.
For interesting Internet Worm information, check out the following URLs: http://www.ee.ryerson.ca:8080/~elf/hack/iworm.html
http://www.alw.nih.gov/Security/first-papers.html

A Web server is a very complex program consisting of many lines of code. It is therefore susceptible to security breaches because, by its nature, it contains bugs. The best defense against these bugs is a good offense.

Determining Your Security Needs

The first step in securing your site is to determine your security needs. These needs might range from none to top secret, but only you can decide the sensitivity of your data.

Access Control Schemes

There are three approaches to securing your intranet site. The first is the "anything goes" approach. This is a Web site with minimal restrictions. Perhaps it lives on the outside of your corporate firewall and you don't care if it lives or dies.

The second is the Draconian approach: all access to your site is cut off. You then enable bits and pieces until you attain the desired access level.

The third and final approach is somewhere in the middle. This is probably the most commonly used approach and the most difficult to keep secure. Because you are going to allow access to some parts of your site, but not all, this can cause conflicts in the configuration options. With proper planning and design, however, these conflicts can be eliminated and your site can be very secure.

Mapping Your Site

In order to better understand the layout of your site, you should first map out the entire site. Make a physical and a logical map using your favorite drawing or design program. Make a flow chart or diagram, whichever you prefer. The important thing is that you, as the administrator, completely understand the extent of your Web structure. This will not only help you see the big picture, but will also enable you to concentrate better on security design. Visual aids always help designers think things through more carefully.

Figure 15.1 is the logical map that Spider (our fictitious Web administrator) made for www.snookums.com.

Figure 15.1: The www.snookums.com site map.

Snookums, Inc. sells many different products, and the company wants to showcase its product line and take orders online. To do this, it has set up a five-page catalog with some additional company information. The pages are as follows:

  • home.html: The home page. Links are provided to all of the top-level pages.
  • catalog.html: This is the catalog main page. From here you can go to any catalog page or any other top-level page.
  • info.html: This is the company information page. From here you can get to any top-level page.
  • order.html: This is the order page. This page provides a form to place orders for widgets. The form calls a CGI script that handles the order.
  • mailingList.html: This page allows a visitor to join a mailing list for new information from Snookums, Inc.

Spider's map shows lines with arrows. These represent the pages you can access from any given page. Spider now has a better understanding of the layout of his site. Armed with this information, he is ready to begin securing the site.

Special Access Considerations

After you have mapped your site, you should think about any special access that you need to allow. Think of these as the whos and the whats.

The whos are the remote hosts to which you will grant access. Most Web sites have no restrictions on who can access their site. However, some visitors can become abusive or destructive and measures might need to be taken. If you want to block access for any hosts, make a note of those sites.

Tip
You might want to block access to your site from Web crawlers, spiders, and worms. These robots scan the Web for information and catalog their findings. They then allow their users to search the database that was constructed with this information. It is possible to block out these Web insects. For more information, check out the following URL
http://info.webcrawler.com/mak/projects/robots/robots.html:

The whats are the pages at your site. They are what you are serving. You need to determine which hosts can view what data. Again, most Web sites grant the same access to all remote hosts. If you have any special considerations, now is the time to think of them. Some examples are

  • Employee access: Perhaps you have an intranet page set up that is only for employees of your company to view from home.
  • Special clients: You might have a extra special client that gets its own page on the intranet.
  • Robots: You might want to block robots from getting to some pages on your site. This is not an issue for a totally isolated intranet.
  • Users and passwords: You can configure any page to require a user name and password. You can even configure your entire site to require these.

In any event, you should make a note of the items that you want to provide special access.

File Permissions

One of the last things you'll need to check is the permissions for your files. Your files should never be world-writeable-this would allow anyone to overwrite them.

Battening Down the Hatches

If you are running your intranet server on a UNIX system, there are several precautions you should take. These precautions will limit the potential security holes that might exist. They are simple to implement and can be undone quickly in a pinch.

Designated Intranet Server

If at all possible, make your intranet server only an intranet server. Try not to use it for purposes other than an intranet. Combining an intranet server with a mail server or with a Usenet news server is just asking for trouble. These other servers can have security holes that will give a wily cracker access to your machine and its data. Also, if your Web server is compromised, you'll lose the services provided by that machine (like news or mail).

Exorcisms

Physically remove all daemons from your system that are not used or wanted. If these programs are on your server, the potential for abuse is there. For example, if you are not running a mail server on your system, remove all of the mail servers. Likewise, if FTP is not provided, remove the FTP daemon. When you have deleted the unwanted rascals, be sure to modify your inetd.conf file so the daemons are never called.

Sweep and Clean

Physically remove all unused language interpreters, command shells, and compilers. If these programs are not used, they don't belong on your system. If someone was able to compromise your system, the tools could help the invader build a more permanent home.

User Accounts

Keep user accounts on your intranet machine to a minimum. Only grant access to the machine on an as-needed basis. The fewer login accounts and passwords that exist on your server, the better. Any user who has an account on the intranet should use a good password. Good passwords contain a mixture of numbers and upper- and lowercase characters. These types of passwords are nearly impossible to crack.

Passwords and Authentication

It is possible to configure your server to serve documents only to users that it can authenticate. These configurations allow flexibility in the way they are set up. They also allow you to restrict access to certain parts of your site on a user-by-user basis.

Both the CERN and NCSA servers provide a method of user authentication. Both involve a user file and a password file. These files are created with either a text editor or a supplied program. These programs can be called from CGI scripts, allowing you to register people online.

Figure 15.2 shows how the Netscape browser accepts a user-supplied user name and password.

Figure 15.2: Netscape Navigator's User/Password dialog box.

Figure 15.3 shows the same window filled in. Notice that the password is not displayed.

Figure 15.3: Supplying a user name and password.

These user and password files are in no way connected with the system's own password file. Those intranet server password and user files are maintained by the administrator and are not connected. Conversely, one does not need an account on an intranet server to be granted access through password authentication.

Figure 15.4 shows successful entry to the protected page.

Figure 15.4: Success!.

Figure 15.5 shows the message that is displayed when the user is not granted access.

Figure 15.5: Failure!.

CERN Authentication

The CERN server can be configured for password authentication in many different ways. The Protect directive allows you to define the protection setup file for an URL or set of URLs. You can also configure the server to run as different users for different documents.

The most flexible method is to combine the use of the Protect directive with an Access Control Listing, or ACL, file. This file lives in the directory where your files live. It provides more detailed access rules for those files. This file is called .www_acl. If you use this method, no further modifications are required once your Protect directive is placed in your configuration file. All of the changes now go in the .www_acl file.

Tip
If you use the Protect or the Protection directives in your configuration file, the directives must be placed before any Pass or Fail directives. These directives use the URLs that are requested of your server, not the physical file locations on your hard drive.

Protect

The Protect directive enables you to specify an URL or set of URLs that are protected by an ACL file. The format of this directive is as follows: 

Protect