|
|
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:
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.
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 |
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.
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 |
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.
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.
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.
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:
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.
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
In any event, you should make a note of the items that you want to provide special access.
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.
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.
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).
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.
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.
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.
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.5 shows the message that is displayed when the user is not granted access.
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. |
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 <template> <setup_file> [<uid.gid>]<template> is the URL template defining the URL or set of URLs that you wish to protect.
<setup_file> is the full path and file name of the actual file that contains the protection rules.
<uid.gid> is an optional parameter. When you first configured the CERN server, you specified the user and group that the server should run as. In the examples, I chose www and www for the user and group, respectively. The <uid.gid> parameter lets you specify the user and group to run as for an URL or set of URLs. This is a very nice feature.
Here are some sample Protect statements:
You also can configure a default setup file for your Protect statements. The DefProt directive allows you to provide the file's name when it is omitted from any Protect statement.
For example:
DefProt /Private/* conf/private.setup Protect /Private/Snookums/* conf/snookums.setup Protect /Private/Spider/* Protect /Private/Sweetie/*
The DefProt defines the default setup file as conf/private.setup. This file is the setup file for all files under the /Private tree.
The first Protect statement defines conf/snookums.setup as the setup file for the /Private/Snookums tree. The file is specified and, therefore, the default is ignored.
The second and third Protect statements, however, have no setup file specified. This is where the DefProt statement kicks in. These two statements will have the conf/private.setup file used as their protection setup files.
Specifying the DefProt and Protect directives for your URLs is only half the job. The other half is creating the protection setup files. These files define the authentication scheme, password and group files, and the password server's ID.
These items are specified through directives. Here is a sample protection setup file:
AuthType Basic ServerId SnookumsSetup PasswordFile /usr/local/etc/httpd/admin/passwd GroupFile /usr/local/etc/httpd/admin/group
As you can see, there are four basic directives:
The following are additional directives that can be used for embedded protection:
The password file is created with a utility program called htadm. This program is bundled with the server when you download it. The htadm program has the following options and parameters:
| Caution |
htadm should never be used to add users to your system password file. The format of the files is different. The results could be bad. |
You can configure your server to serve files only to people who belong to a certain group. These groups are maintained in the file called a group file. If used, this file-like the password file-can exist in any directory you wish. The format is similar to that of the password file:
<group name>:<member1> <member2> ... <membern>
<group name> is what you want to call the group. The <member#> is the user name or mask that you wish to be part of the group. This user name is from the Protect password file, not the system passwd file. You can specify multiple members per group.
The following is a list of the entities that can be members of groups:
The best way to understand the group file syntax is to see one. This is the sample group file used in the CERN documentation for the server:
authors: john, james trusted: authors, jim cern_people: @128.141.*.* hackers: marca@141.142.*.*, sanders@153.39.*.*,(luotonen, timbl, Âhallam)@128.141.*.*, cailliau@(128.141.201.162, 128.141.248.119) cern_hackers: hackers@128.141.*.*
You can specify a group of users at an IP address by surrounding
them with parentheses. Also, note that the last group, cern_hackers,
is made up of the group hackers,
further restricted by an IP address. These files can become quite
complex.
| Tip |
As corny as it might sound, remember to check and test your work thoroughly after any change in the group or password files. These configurations can get pretty hairy. A single misplaced asterisk could open up your site to anyone. |
There are two predefined groups:
It is possible to specify even more protection than the Protect statement provides. This is done with the .www_acl file. This file specifies the files, methods, and users allowed access inside a directory. The format of the file is as follows:
<filespec>: <method1,method2,etc.>: <user1,user2,group1,etc.>
Here is a sample .www_acl file:
secret*.html: GET,POST: trusted_people *.html: GET,POST: snookcust
The first line allows the GET and POST methods for all files that match secret*.html to the users in the group trusted_people.
The second line allows the GET
and POST methods for all
files that end in .html to
the users in group snookcust.
| Caution |
This file processes all lines in the file. Translation does not stop when a match occurs. This behavior is exactly like the Map directive. Be careful how you set up your. www_acl files. In the preceding example, all HTML files would be available to anyone in the snookcust group, even if they were not in the trusted_people group. |
Instead of using protection setup files, you can embed your protection setup into your configuration file. This is done with the Protection directive. The format is as follows:
Protection <protname|template> ( directives… }
Any of the directives listed earlier in the Protection Setup Files section can be used in this protection block. This enables you to keep all of your configuration in one place. The <protname> is a name that you give to the protection block. You then can use the name in a normal Protect statement instead of the setup file. For example:
Protection SpiderWeb { UserId spider GroupId www AuthType Basic ServerId SnookumsSetup PasswordFile /usr/local/etc/httpd/admin/passwd GroupFile /usr/local/etc/httpd/admin/passwd GetMask @(170.137.254.*) } Protect /Private/Snookums/* SpiderWeb
Note that the name of the protection block is SpiderWeb. This name is used instead of the protection setup file name in the Protect statement at the end of the block. It is possible to combine the two lines into one, as well. If you do not wish to use the protection name in any other Protect statements, simply place the URL template where the protection name would go. Here's an example:
Protection /Private/Snookums/* { UserId spider GroupId www AuthType Basic ServerId SnookumsSetup PasswordFile /usr/local/etc/httpd/admin/passwd GroupFile /usr/local/etc/httpd/admin/passwd GetMask @(170.137.254.*) }
| Caution |
The CERN documentation warns that the server is not very robust in parsing the Protection directive. The developers ask that you make sure to place a space between the URL template and the curly brace. They also ask that the ending curly brace be alone on a line. |
This configuration might seem a bit difficult at first. However, working through a few examples could help you better understand the nature of CERN protection.
The following is an example of protecting an entire directory tree for a particular IP address. This can be used to prevent a certain set of hosts from accessing part of your site. The example will allow only hosts from snookums.com and sweetie.com into the directory tree /Private/Secret. Note that there is no password or group file involved in this type of setup. It is a simple restriction based on an IP address. Therefore, the user will never be prompted for a user name or password.
Protection IPRESTRICT { UserID www GroupID www AuthType Basic GetMask @(*.snookums.com,*.sweetie.com) } Protect /Private/Secret/* IPRESTRICT
The second example builds on the first. In addition to IP address protection, you're going to add user protection. Only certain users at snookums.com or sweetie.com are allowed access to the /Private/Secret tree.
Protection USERRESTRICT { UserID wwwadmin GroupID www AuthType Basic ServerID AdminPassword PasswordFile /usr/local/etc/httpd/admin/passwd GroupFile /usr/local/etc/httpd/admin/group GetMask admins@(*.snookums.com,*.sweetie.com) } Protect /Private/Secret/* USERRESTRICT
The final example shows how to use the .www_acl files to restrict access to individual files. I'll build on the last two examples for this one. So far, you have restricted access to the /Private/Secret directory tree to only administrative users from snookums.com or sweetie.com. You can do the same thing using the ACL files. To do this, simply move a portion of the GetMask from the main configuration down to the directory of the files.
For your example, the configuration file would look like the following:
Protection USERRESTRICT { UserID wwwadmin GroupID www AuthType Basic ServerID AdminPassword PasswordFile /usr/local/etc/httpd/admin/passwd GroupFile /usr/local/etc/httpd/admin/group GetMask @(*.snookums.com,*.sweetie.com) } Protect /Private/Secret/* USERRESTRICT You then place the following into your .www_acl file: *.html : GET: admins
The NCSA server can be configured for password authentication on a directory basis only. To do this, you must create a hidden file called .htaccess in the directory where the files are that need to be secured. You can also create a global access file called access.conf. and place it in your configuration directory.
The .htaccess file can be configured many different ways. These directives are as follows:
The following .htaccess file is from the Web page shown in Figure 15.4. It is from the NCSA Web site. This page allows access only to the user fido with a password of bones.
AuthUserFile /X11/mosaic/public/auth-tutorial/examples/by-password/.htpasswd AuthGroupFile /dev/null AuthName ExampleByPassword AuthType Basic <Limit GET> require user fido </Limit>
From the configuration file, you can see that the password file is stored in
/X11/mosaic/public/auth-tutorial/examples/by-password/.htpasswd
You can also see that there is no group file, and the page requires user fido.
Here is the file from the preceding configuration:
/X11/mosaic/public/auth-tutorial/examples/by-password/.htpasswd
It is similar to the UNIX password file, but contains less information:
fido:h5HhgnhegqFIw
You have the option to place the entirety of this file in the global access file. To do this, you use the Directory directive. This is a blocking or sectioning directive. The format is as follows:
<Directory dirname> directives </Directory>
To move the preceding example to the access.conf file, simply add the following to it:
<Directory /usr/local/etc/httpd/htdocs/private> AuthUserFile /X11/mosaic/public/auth-tutorial/examples/by-password/.htpasswd AuthGroupFile /dev/null AuthName ExampleByPassword AuthType Basic <Limit GET> require user fido </Limit> </Directory>
The Limit directive is by far the trickiest one of the bunch. It is similar to the VirtualHost directive in format. This directive format encloses other directives into a block of configuration code. The format uses begin and end tags. These tags look like this:
<Limit method> directives </Limit>
You might notice the similarity to HTML code. It uses similar tags.
The following directives are allowed to be used inside a Limit block:
The Options directive controls the server features that can be done in your directory. These features are as follows:
| Caution |
If you do not specify an Options directive in your configuration file, the server defaults to All. This might not be what you want. Be sure to check your configuration carefully. |
The password file can be created with a utility program called htpasswd. This program is bundled with the server when you download it. The syntax of the htpasswd program is as follows:
htpasswd [-c] <file> <user>
<file> is the path and name of the password file to work with. <user> is the user to create the password for. The -c option will create the file if it does not exist.
When run, this program asks you to enter the password for the user specified. You must enter it a second time to verify. The record is then written to the file specified. This new file can then be used for user authentication.
You can configure your server to serve files only to people that belong to a certain group. These groups are maintained in the file .htgroup. If used, this file-like the password file-can exist in any directory you wish. The format is similar to that of the password file:
<group name>:<member1> <member2> ... <membern>
<group name> is what you want to call the group. The <member#> is the user name that should be part of the group. This user name is from the .htpasswd file, not the system /etc/passwd file. You can specify multiple members per group.
Here is a sample .htgroup file:
snookcust: ren stimpy sven
In the group snookcust, there are three users: ren, stimpy, and sven.
Here is a sample .htaccess file using groups:
AuthUserFile /usr/local/etc/httpd/passwords/.htpasswd AuthGroupFile / usr/local/etc/httpd/passwords/.htgroup AuthName Password AuthType Basic <Limit GET> require group snookcust </Limit>
This requires the user to be in the group snookcust. Therefore, only the users ren, stimpy, and sven are allowed access.
If you are running an intranet site that enables users to have their own home pages, you need to configure your server to allow this. Both the CERN and NCSA servers have the UserDir directive. This directive enables the server to jump to a user's home directory when only the user's name is specified with a preceding tilde (~). On a UNIX system, you can reference any user's home directory by placing a tilde in front of that user's name. For example, to list the files in the home directory of the user teddy, the command would be
munster@honey:~$ ls -l ~teddy
Your intranet server can be configured to do the same thing. When a request comes in for the home page of the user teddy, it will usually look like the following:
http://www.snookums.com/~teddy/home.html
The UserDir directive enables the server to look for user files in a special subdirectory in its home directory tree.
The format of the UserDir directive is as follows:
UserDir <directory>
<directory> is the directory under the user's home directory tree to search for documents. It is similar to automatically specifying a sub-DocumentRoot for each user.
On the CERN server, you must specify the UserDir directive to enable this feature.
The NCSA server, on the other hand, enables this feature and by default points to the directory public_html. To disable this feature on the NCSA server, you must use the following command:
UserDir DISABLED
Here are some examples:
| Tip |
To enable the entire users' home directory, use a single slash (/). This will resolve to the users' root directory. This can be dangerous, however, if user file permissions are not set properly. |
Be sure to inform your users to take the same precautions that you use to secure your files in the server's root directory tree: make the files readable and writeable only by themselves.
Your users might request that they be allowed to create their own CGI scripts. Besides the management headache that this causes, you probably don't want users writing programs that run on your server. Any script the user creates could potentially run as the root user and wreak major havoc on your system.
Only you know the capabilities of your users, but, generally, most systems have a mix ranging from gurus to newbies. Although you might not be worried about your gurus writing CGI code, your newbies will probably be the ones that ask for it. Unfortunately, these little snippets of code need to be as secure as your intranet server itself.
There are two ways to allow users access to your CGI scripts.
Both methods are simple. The first is to restrict script directory
access to a certain group of people (that is, admin
users). Then, simply add users to that group so they can then
create and test their own scripts.
| Tip |
If you were to allow CGI scripts in any directory, it would be very difficult to detect changes in all of them. For some excellent CGI security information, check out the CGI security FAQ at the following URL: http://www.cerf.net/~paulp/cgi-security/ |
The second method is to enable scripts in that user's directory.
To configure your server to enable CGI scripts in directories other than the main /cgi-bin directory, you need to add more configuration directives. This differs slightly between the CERN and NCSA servers.
The Exec directive is used to map URLs to scripts. When you place executable scripts on your server, the server needs to know where the scripts are and the fact that they are executable. The format is as follows:
Exec <template> <result>
This directive differs in its use of wildcards. The Exec directive must include wildcards in both the template and the result. This is because many scripts take arguments that are passed along at the end of the URL. If no wildcard was used, the arguments would not be passed on properly.
Here is an example of the Exec directive:
Exec /cgi-bin/* /usr/local/etc/httpd/cgi-bin/*
This will inform your server that any URL beginning with /cgi-bin is an executable script that it can be found in this directory:
/usr/local/etc/httpd/cgi-bin/
Simply use this directive for each place that you want to allow scripts to execute.
The ScriptAlias directive specifies a directory where executable scripts live on your server. Multiple ScriptAlias directives can be used in the srm.conf file. The format of the ScriptAlias directive is as follows:
ScriptAlias <template> <path>
When used, the ScriptAlias directive effectively remaps the location of template to path.
Here is an example of the ScriptAlias directive:
ScriptAlias /cgi-bin /usr/local/etc/httpd/cgi-bin
All requests for documents that begin with /cgi-bin will be rerouted through /usr/local/etc/httpd/cgi-bin and the output of the script will be returned to the requesting client.
Simply use this directive for each place that you want to allow
scripts to execute.
| Tip |
If you want to allow CGI script execution here and there, use the Options ExecCGI directive in the ACF for that directory. You need to make scripts automatically execute, however. To do this, you will need to add a new MIME type to your global configuration or to your local directory ACF. This should look like the following: This will make all files ending in .cgi scripts. You also can add .sh and .pl as in the following: This will allow for the automatic execution of PERL and shell scripts as well. |
Server-side includes, or SSIs, are a way to include other programs or HTML files into a document before it is served to the client. This allows for customization of the file on-the-fly. Types of information that you can provide include the following:
Allowing SSIs can be costly to your server's performance. It slows your server down to parse through a second HTML file while sending the original. To reduce this performance cost, you should only allow SSIs with files of a certain extension. This will cause the server to only parse the included file, not both files. If you don't care about the performance, this restriction is not needed.
To enable SSIs, you first need to add a MIME type to your global configuration or local directory configuration file. This will inform the server of the extension that you wish to use for all SSIs. The server internally uses the magic MIME type of text/x-server-parsed-html to identify these types of documents. You must bind an extension to this MIME type. Use the AddType directive to do so:
AddType text/x-server-parsed-html .shtml
This specifies that files ending in .shtml will be the only candidates for inclusion.
Alternatively, if you don't care about server performance, use this AddType directive instead:
AddType text/x-server-parsed-html .html
By default, all users have access to SSIs. You might want to restrict access to a few people or only allow SSIs from certain directories.
If you do not want to allow access to server-side includes, you must modify the Options for the global access file, access.conf. By default, all options are enabled for all directories. You must make an entry in your global access file or your directory's .htaccess file. See the earlier section regarding the format.
After reading this chapter, you should have a better understanding of the methods available to you for securing your intranet site. These include restrictions based on user, IP address, and domain name. You also should have some ideas about what you want to allow users to do. You now might or might not want to let them have access to CGI scripts or server-side includes. Hopefully, I've offered enough insight for you to make these decisions.
