security \si-'kyur- t-e-\ n: the quality or state of being secure
You might think that there is little reason to be concerned about security in an intranet. After all, by definition an intranet is internal to your organization; outsiders can't access it. There are strong arguments for the position that an intranet should be completely open to its users, with little or no security. You might not have considered your intranet in any other light.
On the other hand, implementing some simple, built-in security measures in your intranet can allow you to provide resources you might not have considered possible in such a context. For example, you can give access to some Web pages to some people without making them available to your entire customer base, with several kinds of authentication. In this chapter, you'll learn how simple security measures can be used to widen the scope of your intranet.
To help you get oriented to the material to be presented, the following is a list of chapter objectives. You might want to refer to this list as you work your way through the chapter. In this chapter, you'll
Intranet security is, then, a multifaceted issue, with both opportunities
and dangers, especially if your network is part of the Internet.
I'll walk through the major ones, with detailed information on
using built-in intranet security features, in this chapter.
| Warning |
Except in the sections of this chapter that are specifically devoted to Internet security issues, it's assumed that your intranet is not accessible from outside your organization. If you are on the Internet, the intranet security measures discussed in this chapter may not be sufficient to secure your system. If you want to make the services and resources of your intranet accessible from the outside, you'll need to take significant additional steps to prevent abuse and unauthorized access. Some of these steps are described at the end of this chapter in the section titled "Your Intranet and the Internet." |
Many people view computer and network security in a negative light, thinking of it only in terms of restricting access to services. One major view of network security is "that which is not expressly permitted is denied." Although this view is a good way of thinking about how to connect your organization to the Internet, you can, and possibly should, view intranet security from a more positive angle. Properly set up, intranet security can be an enabler, enriching your intranet with services and resources you would not otherwise be able to provide. Such an overall security policy might be described as "that which is not expressly denied is permitted."
This does not mean that you should throw caution to the wind and make everything available to your users on your intranet. There are many things to consider when placing sensitive business data out on your intranet. It may fall into the wrong hands, or worse, be used against your business.
This chapter takes the latter approach, presenting intranet security in terms of its opportunities for adding value to your intranet. For example, some of your users might have information they would like to make available, provided access to it can be limited to a specified group-for example, confidential management or financial information. Without the ability to ensure that only those who have the right to see such information will have access, the custodians of such data will not be willing to put it on your intranet. Providing security increases your organization's ability to use the important collaborative aspects of an intranet.
For example, your company's accounting department wants to publish a weekly list of the top ten delinquent clients and the amounts they owe. They've hired a young stud programmer who has created a link to the company database that updates this information automatically. While this information is useful to upper management, and perhaps the sales staff, it shouldn't be viewed by other departments. The fact that a client is delinquent in payment can cause your employees to think less of those clients and perhaps cop a bad attitude toward them.
The more defensive approach, preventing abuse of your intranet, is also given play, however. Organizations' needs for security in an intranet can vary widely. Businesses in which con-fidentiality and discretion are the norm in handling proprietary information and corporate intellectual property have different needs than a college or university, for example. Academic institutions generally tilt toward making the free exchange of ideas a primary interest. At the same time, though, the curiosity (to use a polite word) of undergraduates requires strong needs for security. Keeping prying sophomores out of university administration computing resources is a high priority; for example, students have been known to try to access grade records (their own or those of others) for various reasons. Even simple adolescent high jinks take on new dimensions on a computer network.
Before going into a great deal of detail about how you can use security to enhance your intranet, take a high-level look at what security features are available to you. These break down into three main categories. First, you can take steps on your Web server to set up security. Second, you can take steps with the other TCP/IP network services you've set up on your intranet to enhance their security. Third, you can secure customers' Web browsers themselves to limit what they can do with them.
There is a wide range of very flexible security features you can implement on your Web server. Here's a summary:
You can combine these features in a number of ways, such as requiring a password and limiting access to a group of users who must access your Web server from a specific group of computer systems. You'll see a good deal of detail about Web server security setup in this chapter.
In addition to the access controls you can set up on your Web servers, you can implement security in some of the other network services that may be offered on your intranet. Here are some of the steps you can take:
This chapter, doesn't provide any additional information about these services. You'll want to refer to the documentation for these network packages to learn about how to handle access control and other security features in them.
Some Web browsers can be set up in kiosk mode, which limits the features of the package that users can access. Available primarily in ncSA Windows Mosaic and Mosaic-based browsers, kiosk mode runs the browser with a limited set of features. Users cannot save, print, or view the HTML source of Web pages, and hotlist/bookmark editing is not allowed. The user cannot even exit from the browser and restart it in normal mode without exiting from Windows altogether. Even the overall Mosaic window cannot be minimized or maximized, and the normal pull-down control menu for Windows is missing. This can be quite effective in a controlled environment. However, end users tend to find their way out of paper bags quite often. Don't count on kiosk mode being your super security implementation.
Figure 5.1 shows ncSA Mosaic for Windows in kiosk mode, and, for your comparison, Figure 5.2 shows the same page in standard Mosaic. As you can see, many of the normal toolbar buttons are missing, as is the Options menu. The remaining pull-down menus are also limited in the available features. Kiosk mode is primarily for use in library or trade-show environments, where users need to be limited in what they can do, but you might find a use for it in your intranet if you need to limit what some customers can do with the package. The Netscape Navigator browser does not have a kiosk mode.
Figure 5.1 : ncSA Mosaic for Windows in kiosk mode.
Figure 5.2 : ncSA Mosaic for Windows in normal mode.
| Tip |
Resourceful users will quickly figure out they can manually edit their pc's autoexec.bat file or Web browser's .ini file to override kiosk mode, undoing the limitations you've placed on them. If you're concerned about such things, you'll need to place user startup and Windows and browser setup files on a file server to which users have read permission only. You'll also need to limit access to the Mosaic startup command itself, or else users would simply use the Windows Program Manager's Run command to start another Mosaic session. As a result, kiosk mode might not be worth your trouble except in limited situations, such as at a trade show. |
It's your responsibility to determine the level of security you need on your intranet, and, of course, to implement it. Putting most of the security measures mentioned into place, as you'll learn in the following sections, is not difficult. Your primary concern will be explaining to customers how intranet security works, not so much as a limiting factor but as an opportunity for increased use and collaboration using your intranet. Assuring decision-makers that they can make information available on your intranet in a secure fashion can go a long way toward making your intranet a success. At the same time, it's important to make sure both information providers and their customers understand a number of critical aspects of intranet security, so they don't inadvertently defeat the purpose of it.
There are network security commonplaces, unrelated to intranet
security specifically, that need your attention. All the security
precautions in the world can't protect your intranet from overall
poor security practices. Users making poor choices on passwords
always leads the list of computer and network security risks.
You can limit access to a sensitive Web resource based on the
TCP/IP network address of the boss's pc, but if the boss walks
away and leaves his pc unattended without an active screenlock,
anyone who walks into the empty office can access the protected
resources.
| Caution |
Password security is only as good as the passwords that are chosen. Be sure to impose some sort of password setting and changing policy. This will save you time in the end. Unique passwords that are a garble of letters and numbers are the best, but the hardest to remember. Encourage your users to be creative in their password selection. Sometimes a user uses his own name as his password, or his significant other's or pet's name; password-guessing is simple for anyone who knows him. Some people write their passwords down and tape them to their keyboards or monitors. These bad habits need to be avoided to completely secure your intranet. |
In other words, the same good security practices that should be followed in any networked computing environment should also be made to apply in your intranet. Not doing so negates all the possible security steps you can take and reduces the value of your intranet. Even in the absence of malice, the failure to maintain any security on your intranet will inevitably result in an intranet with little real utility and value to its customers.
It's useful to break the overall subject of World Wide Web server security down into three pieces and discuss them separately. I'll do so in this section, covering user/password authentication, network address access limitations, and transaction encryption. Bear in mind throughout the discussion of these separate pieces that you can combine them in various ways to create flexible and fine-grained access control. In fact, combining two, or even all three, of these methods provides the best overall security.
Before I turn to the individual methods, I'll cover some high-level information about Web server security setup.
Whichever individual security mechanisms you implement on your Web server, the first thing you need to know is that you can implement them at either or both of two levels. First, you can specify high-level access control in a Global Access Configuration File (GACF), specifying overall access rules for your server. In the ncSA httpd server and those which are derived from it, such as the Windows httpd and Apache servers, the GACF is called access.conf. The CERN/W3 server doesn't have a separate GACF; rather, all access control information is in the main server configuration file, httpd.conf. The Netscape servers have a graphical interface (actually, Netscape Navigator itself) for overall server administration, including setting up access control. If you feel more comfortable editing configuration files, the Netscape server does allow them, calling them Dynamic Configuration Files. Although you can do both global and local configuration using the graphical tool, you can also manually create a top-level Netscape Dynamic Configuration File, which can then be hand-edited to function as a GACF.
Second, you can set up per-directory access control using local ACFs (LACFs) for each directory or subdirectory tree. Usually named .htaccess or .www_acl (note the leading periods in the filenames), LACFs lay out access control for an individual directory and its subdirectories, although subdirectories can also have their own LACFs. The CERN/W3 server can even extend protection to the individual file level using LACFs. In the Netscape server, lower-level Dynamic Configuration Files serve as LACFs. You can change the names of LACFs in both the ncSA and Netscape servers, but you're stuck with .www_acl in CERN/W3.
With a few important exceptions, you can do everything with an
LACF you can do with a GACF. Although you can control access to
every directory in your Web server document tree from the GACF,
you'll probably not want to do so, especially if your needs for
access control are complex. It's easy to make mistakes in a lengthy
configuration file like the GACF, and you'll get unexpected, unintended
results when you do. These might be hard to track down and might
not even show up without extensive testing. Overall, it's better
to use your GACF to establish a high-level security policy and
then set up lower-level, simpler controls using LACFs.
| Note |
The CERN/W3 server's LACF files have a completely different format than its GACF. Most of the examples in this chapter apply only to the format of the GACF. |
What's the GACF for, then? Most Webmasters use the GACF to establish a general access policy for their Web server. For example, if your Web server is accessible to the Internet at large and you're not using a firewall system (see the "Firewalls" section later in this chapter) to limit access to your network from the outside, you may want to establish a policy in your GACF that only computers with TCP/IP network addresses that are inside your network can access your Web server's document tree. Similarly, you can use the GACF to segregate public and private areas on your Web server according to some criteria, and require usernames and passwords for access to the private areas.
After you've established your overall policies, you can implement LACFs to fine-tune your setup. In doing so, you can selectively apply different access controls to the directory or directories controlled by the LACF.
Earlier, exceptions to the statement that you can do everything with an LACF you can do with a GACF were mentioned. Here is a quick, incomplete list; you'll want to consult detailed server documentation for comprehensive explanations of these and others. The first one applies to all httpd servers, and the last three refer only to UNIX servers.
With respect to symbolic links, confidential files on the system that are completely outside of your Web server tree could be compromised by a naive or malicious user. For example, if a user created a symbolic link in her home directory pointing to the UNIX /etc/passwd file, which contains usernames and encrypted passwords, outside users could obtain a copy of that file using their Web browser and then run a password-cracker on it offline. Of course, a malicious user can grab /etc/passwd himself and run the cracker directly, or e-mail the file to someone else for the same reason, but that's no reason to make it easy to do so via your intranet. (The UNIX System V /etc/shadow file is not readable by non-root users, nor is the IBM AIX /etc/security/passwd file.) See the section titled "The Common Gateway Interface (CGI) and Intranet Security" later in this chapter for discussion of CGI-BIN and server-side include security issues.
These generalities out of the way, let's turn our attention to the three major elements of Web server security.
The first major element of Web server security is username/password authentication. All the sample Web servers discussed in this book provide this basic kind of security. I kick off this discussion by looking at what the Web browser user sees when he encounters a Web page that requires username/password authentication for access. Figure 5.3 (part of ncSA's excellent access control tutorial, at http://hoohoo.ncsa.uiuc.edu/docs/tutorials/) shows a Prompt dialog box asking for a username. Once the username is entered, a new dialog box asks for a password, as shown in Figure 5.4.
Figure 5.3 : The user is prompted to enter a username on a protected Web page.
As you can infer from Figures 5.3 and 5.4, there are three aspects of username/password authentication: the username, the password that applies to that username, and what is permitted to that user when a correct username and password are supplied. Usernames and passwords are meaningless unless you specify a directory, directory tree, or filename to which your username/password access restrictions apply.
Figure 5.4 : The user is also prompted for a password on a protected Web page.
To make this more understandable, look at an example. Suppose your httpd server's DocumentRoot directory contains three main subdirectories, named public, management, and personnel. Using your GACF, you can specify that access to the management and personnel subdirectory trees requires username/password authentication, while public is left wide open for anyone to access without being prompted for a username and password. You can also set up LACFs within the protected subdirectories to further limit access to particularly sensitive documents by using usernames/passwords.
Of the servers covered in this book, setting up username/password authentication is simplest in the Netscape servers. The Netscape servers actually use the Netscape browser itself as a graphical interface for administering the server, providing a set of private Web pages and configuration scripts to do so. Using the Server Manager page, you can easily enter new users and their passwords into what Netscape calls the user database. (Your empty user database must first be created before you can add any users and passwords to it.) Figure 5.5 shows the User Database Management screen. Notice there's an administrative password that must be given, as well as the username and password for the user being added to the database. After you've entered this information, click Make These Changes.
Figure 5.5 : The Netscape Communications Server Add-User form.
After you've set up one or more users, you can continue to use the Server Manager to apply access control rules to users. You can associate groups of users together for purposes of authentication, and define access control rules that apply to groups as well as to individuals. With group access controls, users must still provide their own usernames and passwords, but access to a specified area of the server file tree (Netscape calls this a realm) can be controlled by requiring that a user be a member of a group for access. Even if a user provides the correct username and password, he may be denied access based on group access control rules if he is not a member of that realm's group.
The CERN/W3 httpd server uses a UNIX-like password file (but with only three colon-separated fields) containing usernames, encrypted passwords, and users' real names. The password file is controlled using the htadm program that comes with the httpd server software. This program enables you to create and delete user accounts, as well as change and verify existing passwords. Although you can provide all the information htadm needs on the command line, it's easier to let the program prompt you for it. For example, to add a new username and password:
# path/to/htadm /path/to/passwordfile
You must specify the name of the password file on the command line, but htadm will prompt you for the function you want to perform and the actual username, password, and user's real name, as appropriate. (You can use multiple words in the realname field to include a full name and other information.) If you're in a hurry or have a long list of users to add or delete, you can take advantage of specifying all the htadm command-line arguments at once, like in these examples:
# htadm -adduser passwordfile joeuser joespassword Joe User
# htadm -deluser passwordfile baduser
The first example creates the user joeuser with the password joespassword, and the second deletes the user baduser. This enables you to do mass account deletion using shell looping and to take username, password, and real name input from a file. You'll need something like the expect package to do automated, mass account creation. There are also -passwd and -check command-line arguments to htadm, which enable you to change and verify passwords, respectively.
As with the Netscape server, the CERN/W3 httpd server also enables you to associate individual users with groups. You can set up group authentication rules in LACFs that control access to portions of your Web server document tree. CERN/W3 uses a group file, the format of which is based on the standard UNIX /etc/group format, but it has an added feature for defining access control rules and for recursive inclusion of groups into metagroups. A simple group file, which I'll use for examples in this chapter, might be something like this:
management: tom, mary, joan
personnel: anne, joe, jerry
staff: management, personnel
public: All, Anybody
Here, four groups are defined. The first two each contain a list of several individual usernames, but the last two are groups of groups. (Two special groups, All, meaning all authenticated users and Anybody meaning anyone, authenticated or not, are predefined by the CERN/W3 httpd server software, and refer to anyone who might access the server; see the server documentation for details on the distinction between All and Anybody.)
After setting up your password and group files, you can add access control protection to your server. As noted, high-level rules go in httpd.conf, the GACF. Access control rules in httpd.conf use the Protect directive and associated protection rulesets. Here's a simple Protect directive, based on the group file shown above. It implements the example division of your Web server's document tree into public, management, and personnel subtrees:
Protect /personnel/* Personnel
This example indicates that all subdirectories and files in the personnel subtrees of your Web server DocumentRoot are subject to the rules in the protection ruleset named Personnel. (You can name protection rulesets with any name you want, but it makes sense to use meaningful names.) According to this Protect directive, the ruleset itself also appears in the GACF, under the label Personnel, and might look like this:
Protection Personnel {
AuthType Basic
Passwordfile /usr/local/etc/httpd/passwd
GroupFile /usr/local/etc/httpd/group
GetMask personnel
}
| Note |
The Protect directive can specify the protection ruleset be read from a file, rather than from another part of the GACF. In this case, the directive would look like this: |
This simple example applies username/password authentication access control to all files and subdirectories in the personnel directory, using the following criteria, all of which must be met before access is granted:
Going back to the sample group file, you can see that only users Anne, Joe, and Jerry will be granted access to files in this directory tree. Even if Tom provides his correct password, he will not be given access.
This has been a very cursory look at user authentication in the CERN/W3 httpd server. Protect directives and protection rulesets can be quite detailed, including other features not described here. In addition, you can set up both a default protection ruleset and progressively more limited protection rulesets according to your own criteria, adding access control all the way down to the individual file level. For details, see the documentation which comes with the CERN/W3 httpd server software (on the Developing Intranet Applications with Java CD-ROM). Or check out the World Wide Web Consortium's online CERN/W3 httpd documentation at http://www.w3.org/pub/WWW/Daemon/User/Admin.html.
The ncSA httpd server, along with those derived from it (WinHttpd for Windows and the Apache package for UNIX systems), provide similar username/password authentication mechanisms. Except where there are differences among these packages, I'll discuss them as a group.
Although these packages use authentication methods that are similar to the methods used in the CERN/W3 httpd package, there are differences. Let's first focus on the similarities. Most importantly, the ncSA packages support both GACFs and LACFs, enabling you to set high-level policy at the server level and then fine-tune it at the directory and subdirectory levels. In addition, both individual user and group authentication are provided for. Finally, some configuration commands, such as AllowOverride, affecting critical items listed earlier might only appear in a GACF. You can also disallow the use of server-side includes and the following of symbolic links, for example, as described earlier.
The GACF in the ncSA packages is the file named access.conf (access.cnf in WinHttpd) and is located in the conf subdirectory of your Web server's file tree. On UNIX systems, the server is usually installed in /usr/local/etc/httpd, and on Windows systems, the server is in c:\httpd. In both cases, there exists a conf subdirectory in the top-level httpd directory. However, the layout and syntax of the access.conf file is significantly different from the GACF in the CERN/W3 httpd server.
The ncSA file is divided into sections, one for each directory to be controlled. Each directory section in access.conf looks something like this:
<Directory /absolute/directory/path>
[ Various configuration commands ]
</Directory>
Like HTML markup, each Directory (the literal word Directory must appear) section is marked off by the access.conf tags <Directory> and </Directory>, surrounded with angle brackets. Case is not significant in the word Directory, although it might be in the actual directory name.
The directory path here is an absolute pathname and is not relative to either the Web server's ServerRoot or DocumentRoot directories. If you use /usr/local/etc/htdocs/, for example, you must specify it in full and not just simply use /htdocs. Within each Directory section of the file, you specify one or more options, or configuration commands, which will be applied by the server to the specified directory. There are a number of different options, but we're concerned here with username/password authentication.
Of course, before you can apply a username/password access control, you need to have established users and passwords on your server. Usernames and encrypted passwords are stored in a special httpd password file. ncSA provides a utility program, htpasswd, for creating this file; you'll find it in the support subdirectory of your ncSA httpd server file tree, and you might need to compile it. The syntax of the htpasswd command is substantially simpler than that of the CERN/W3 htadm command, as are its capabilities. To add a user to your password file or change his password, use this syntax:
# htpasswd /path/to/passwordfile username
If you don't already have a password file, you need to modify this command a bit:
# htpasswd -c /path/to/passwordfile username
The -c argument creates a new password file, so you use it only once. If you use it again, you'll erase your current password file. You can name your password file anything you like.
You can't remove a user from your password file with the htpasswd command. Instead, you'll have to hand-edit the password file with a text editor and delete the user's entry. The format of the file is quite simple, with just two fields in each record, separated by a colon:
tkevans:TyWhfX9/zYd7Y
The first field is the username. The second field is the encrypted password. Permissions on the password file must be set so as to be readable by the system user under whose userid the httpd server runs (usually, the no-privileges user nobody), so passwords are not stored in clear text.
Besides the httpd password file, the ncSA servers also respect a group file in which you can define groups of users. Groups can be treated like individual users with respect to access control, so the group file can add capabilities and save data-entry time. For the most part, syntax of the ncSA httpd group file is exactly the same as that shown earlier in this chapter for the CERN/W3 group file.
There is one significant difference in what the two group files may contain, however. As noted above, the CERN/W33 group file can include group entries which consist of other groups. The ncSA group file can include only individual users as members of groups. Thus, the recursive staff group, consisting of all the members of the personnel and management groups, is not possible in ncSA. To create such a group, you would need to re-enter each user's name in the group entry for staff.
Now that you've set up your password and group files, you're ready to add username/password authentication in your GACF or LACFs. Take a look at an example:
# Anybody in the personnel group can get to the top level
# of the personnel filetree
<Directory /usr/local/web-docs/personnel>
AuthType Basic
AuthName Personnel Only
AuthUserFile /usr/local/etc/httpd/userpw
AuthGroupFile /usr/local/etc/httpd/ourgroup
<Limit GET>
Require group personnel
</Limit>
</Directory>
Here, in the GACF file, you've limited access to the top level of the personnel tree of the Web server. Only members of the predefined group personnel (defined in the ourgroup file) are allowed to GET (access) files in the directory tree, and they must provide a valid username and password, verifiable against the encrypted password in the userpw file.
Most of the lines in the example are clear, but a couple need a little more explanation. AuthName is just an arbitrary label for your rule; you should put something there that'll make sense when you read the rule a year from now, and you can use a phrase here. The <Limit GET> subsection of the file is the critical section, in which you actually specify who has access. You can also include comments in the file, as indicated by the first two lines, where the # symbol is used.
As I've noted, you can use LACFs to refine the access rules in your GACF. Here's an example of an ncSA httpd LACF: a file named .htacces in the personnel/executive subdirectory. See if you can translate its meaning:
AuthType Basic
AuthName Anne Only
AuthUserFile /usr/local/etc/httpd/userpw
AuthGroupFile /usr/local/etc/httpd/ourgroup
<Limit GET>
Require user anne
</Limit>
You're right; this rule limits access to the executive subdirectory to a single user: anne. The heart of this rule is the matter between the <Limit> and </Limit> tags near the end of the file. Other users, including the other members of the personnel group, are denied access, even if they give a correct password for themselves. A dialog box will demand Anne's username and password. Notice that this LACF file, which controls access to a single directory (personnel/executive), does not require the opening and closing <Directory> and </Directory> tags required in the server's GACF because there are no subdirectories in this directory.
Unless the access rules change (that is, new LACFs are encountered) as a user moves around on your intranet Web pages (as with the personnel/executive subdirectory in the previous example), he will be prompted only once in his browser session for a username and password. As long as he continues his browser session, he can access all of the files and directories available to him under the most recent access rule-without being prompted again for his password. This is for the sake of convenience; customers shouldn't have to repeatedly provide their usernames and passwords at each step of the way when the access rule hasn't changed.
However, this situation has important ramifications if you follow it logically. Suppose Anne, having authenticated herself to access the executive subdirectory, leaves her Netscape or Mosaic session running, as most of us do. Her privileged access remains open to all the files protected by that one-time, possibly days-old, authentication. If she leaves her workstation, pc, or terminal unattended when she goes to lunch or goes home for the day, without any sort of active screen or office door lock, anyone can sit down and browse the files and directories that are supposed to be limited to Anne's eyes only. This is a potential security breach, and one that the Webmaster can do little about. This is really no different from a user who leaves his workstation unattended without logging off. Although you can try to educate your customers about such everyday security matters, even though they have very little to do with your intranet, you'll agree a security breach like this can be potentially harmful to all your work.
User passwords are transmitted over your network by most Web browsers in a relatively insecure fashion. It is not terribly difficult for a user with a network snooper running to pick out the httpd network packets containing user passwords. Although the passwords are not transmitted in clear text, the encoding/encryption method is a very old and widely used one. Every UNIX system, for example, has a program (uudecode) that can decode the encrypted password in a captured httpd packet. If you believe this may be a problem on your intranet, you'll want to consider the secure Web servers and browsers that encrypt user-transmitted data, as discussed in the section titled "Secure/Encrypted Transactions," later in this chapter.
All the Web servers discussed in this chapter provide an additional authentication method, using the TCP/IP hostname or numerical network address of customer workstations or pcs as access criteria. As you'll learn in later chapters, in the context of CGI-BIN programming, every Web browser request for a document or other intranet resource contains the numerical IP address of the requesting computer. Servers look up hostnames using these addresses and the Domain Name Service (DNS). You can set up rules in your GACFs and LACFs based on either of these, making a considerable amount of fine-tuning possible.
Because the format of the ncSA access.conf file is still fresh in your mind from the last section, look at this one first in the context of hostname/network address authentication. You'll place your rules for this sort of authentication within the <Limit> and </Limit> tags of the server's GACFs or LACFs <Directory> sections. Do this with several new access control directives, including
Here's a simple example limiting access to the personnel subtrees of your Web server. (The opening and closing <Directory> tags have been left off so as to cut right to the chase.) For purposes of this example, I'll assume your company's TCP/IP network domain is subdivided along operational lines and that there is a personnel subdomain in which all of the computers have IP addresses beginning with 123.45.67.
<Limit GET>
order deny,allow
deny from all
allow from personnel.mycompany.com
allow from 123.45.67
</Limit>
In plain English, this example rule says, "access is denied to all hostnames and IP addresses except those in the subdomain personnel.mycompany.com and those in the numerical IP address family 123.45.67." Notice that both the subdomain name and IP address family are wildcards that might match many computers; you can also use individual hostnames or addresses for even finer-grained control.
As you can see, I've used each of the three directives listed. You might wonder why I used both allow and deny statements. The World Wide Web was built with openness in mind, not security. The server therefore assumes, without instructions to the contrary, all directories are accessible to all hostnames/addresses. (This is the same as the username/password authentication about which you learned earlier. In the absence of a username/password requirement, all directories and files are accessible to all users.) Without a deny directive, the rule might just as well not exist. The server assumes, in the absence of a deny directive, all hostnames/addresses are allowed access. Why have any rule at all, then, if all are allowed access? In other words, it makes no sense to have rules with allow directives that don't have deny directives.
Because you must have both deny and allow directives in order to have meaningful access rules, the order in which the rules are evaluated is important. One way to evaluate your implementation is to follow the actual order in which the directives appear in the file, but it's easy to make mistakes with this approach. Instead, ncSA httpd uses the order directive so you can explicitly instruct that your directives be processed in the order you want. The example uses order deny,access, indicating all incoming requests are to be tested against the deny directives first and then tested against the allow directives. In the example, you set up a general deny rule and then make exceptions to it. The order directive can also be turned around, with allow rules processed first. Using this sequence, you can make your server generally available and then add selective denials. For example:
<Limit GET>
order allow,deny
allow from all
deny from .mycompetitor.com
</Limit>
Here, you're granting access to your server to everyone except your competitor. For more information about hostname/IP address authentication, see the ncSA httpd server documentation on the Developing Intranet Applications with Java CD-ROM, or the authentication tutorial at ncSA's Web site, http://hoohoo.ncsa.uiuc.edu/docs/tutorials/.
You can also impose hostname/IP address access control with the CERN/W3 httpd server. Although you can accomplish the same ends as with the ncSA server, the method of doing so is different, and the access control file formats are different. As you'll recall from the earlier username/password authentication, the CERN/W3 httpd server uses protection rulesets in the GACF or LACF. I'll modify the earlier example in which you limited access to the personnel portion of your Web server by group name to illustrate hostname/IP address authentication. For purposes of this example, I'll assume that your company's TCP/IP network domain is subdivided along operational lines and that there is a personnel subdomain, all of the computers in which have IP addresses beginning with 123.45.67.
Protection Personnel {
AuthType Basic
Passwordfile /usr/local/etc/httpd/passwd
GroupFile /usr/local/etc/httpd/group
GetMask @*.personnel.mycompany.com,@123.45.67.*
}
As you can see, the only thing changed about this ruleset is the GetMask line. In the earlier example, I used GetMask to limit access based on membership in a defined group of usernames, personnel. Here, I've done access control limitation in two ways. First, I specified an sub-domain name (personnel.mycompany.com). Second, the rule contains a numerical IP address family. In both cases, I've used a special wildcard syntax; note the use of both the @ symbol and the asterisk (*). You can think of the string @*.personnel.mycompany.com as meaning any user at any computer in the personnel subdomain. Similarly, @123.45.67.* refers to any user at any computer with an IP address beginning with 123.45.67.
Actually it was not needed. You might be wondering why, since all computers in the personnel subdomain have IP addresses in the 123.45.67 family, I've included both rules. I did this for a couple of reasons. The first is to show that you can use either symbolic host/domain/subdomain names or numerical IP addresses.
The second reason is a more technical one. In some cases, your httpd server won't be able to resolve the hostname of a computer making a request for a document from the numerical IP address it receives in the browser request. The reasons for this inability vary, but they usually involve out-of-date or inaccurate DNS information. In growing networks, newly networked computers might not get added to the database promptly. Errors in DNS configuration, such as misspelled hostnames, can also result in unresolvable hostnames. To be safe, placing both symbolic host/domain name and numerical IP address information in your GetMask is a good idea; there's nothing like having the boss's brand-new PowerMac being denied access to your intranet's Web server on his very first try because its DNS entry hasn't been made by the network operations staff yet.
As with most aspects of Netscape Communications Server administration, you can set up hostname/IP address access control using a graphical interface. Start up the Administration Manager and select Restrict Access From Certain Addresses. This opens a document with extensive instructions for setting up access restrictions. You'll find fill-in boxes in this document for hostname/IP address restrictions. Figures 5.6, 5.7, and 5.8 show the essential parts of this form. You have all the same choices here for restricting access that you saw in the ncSA and CERN/W3 httpd servers.
Figure 5.6 : Netscape Communications Server Host restriction (Part 1).
Figure 5.7 : Netscape Communications Server Host restriction (Part 2)
The first step is to select what Netscape calls a resource to which you'll apply hostname/IP address restriction. For this purpose, a resource can be the entire Web server tree, a particular part of it, or one or more individual files. Clickable buttons (as shown at the top of Figure 5.6) enable you to select the resource you want. In this example, your resource would be the /usr/local/web-docs/personnel subdirectory of your httpd server tree. After you've selected your resource, scroll down the form to the headline What To Protect. (See Figure 5.7.) Here, you'll find two important choices.
You can simply accept the default of protecting everything in the selected resource. Or you can specify a wildcard filename pattern to match the files you want to protect. Notice the hypertext link labeled wildcard pattern, which takes you to a detailed document describing how wildcard pattern-matching works in the Netscape servers. (Essentially, it's standard UNIX shell filename expansion, but has some additional features.)
For the purposes of the example, you need not enter anything, because you're going to accept the default restriction to all files and directories in the personnel resource. However, you could have entered the wildcard pattern for the files to which you wanted to apply your hostname/IP address restrictions in the boxed and labeled Pattern of files to protect. The Addresses to allow section, which starts in Figure 5.7 and ends in Figure 5.8, tells you how to enter hostnames and IP addresses.
Figure 5.8 : Netscape Communications Server Host restriction (Part 3)
As with filenames, you can enter either specific individual hostnames or IP addresses, or wildcard patterns that match multiple hosts. The Hostnames to allow and IP addresses to allow boxes are shown in Figure 5.8 with the personnel example filled in.
The bottom of Figure 5.8 shows how you can set up a custom message to users who try to access restricted resources, giving them a reason for the denial of their request. You need not use this, but it can be friendlier than the generic Not Found message most httpd servers return. Here, I've set things up so the contents of the file /usr/local/web-docs/private.txt will be returned. This file could explain politely, for example, that access to personnel resources on the Web server is limited to the Personnel Department. After you finish the form, scroll all the way to the bottom (not shown in Figure 5.8) and click Make These Changes to apply your restrictions.
All of the Web server software described in this chapter trustingly accepts the word of a requesting computer when it sends its IP address. Verification of this information is not possible. It's relatively easy for a user to change the hostname/IP address of a UNIX system, and laughably easy to change that of a pc or Mac. A curious, mischievous, or malicious person can reconfigure his computer to impersonate someone else's simply by changing the IP address of his own. Although this is an overall network security issue, not specifically one for your intranet, it's important you know about it because it can affect the security of your access controlled documents. Security-minded network administrators can use special hardware and software to prevent this sort of IP spoofing, but for your intranet, you'll probably want to combine hostname/IP address authentication with username/password authentication, as outlined in the following section.
Now that you understand how username/password and hostname/IP address authentication work separately, consider how you can combine the two to beef up your access control. Begin with the Netscape Communications Server.
Netscape's scanty $40 documentation for the Communications Server doesn't address this subject directly, but you can infer from it how to implement combined username/password and hostname/IP address authentication. As you learned earlier, the Netscape server uses one or more user databases to store usernames and passwords, and you can apply access control limits based on both individual usernames and on group membership. Also, the Netscape server can restrict access by hostname/IP address, as described in the previous section. Although the Netscape Communications Server manual and its essentially identical online help describe these two methods as an either/or choice, it would appear that applying both kinds of access control to a single resource would result in both methods being applied. In other words, you can
Because the documentation doesn't say what happens in such a situation, including whether there is an order of precedence in the testing of the access control rules, you should very carefully check how things work when you set up intersecting access control rules of this sort.
For example, it isn't clear which rule would be applied first. If the username/password authentication rule goes first, the user will be prompted for a username and password. The hostname/IP address rule would then deny access to even authenticated users. Applying the hostname/IP address rule first, however, will correct this problem.
Fortunately for those who want to have their access control rules perform exactly as they want them to, Netscape provides another means of access control, using Dynamic Configuration Files (DCFs). You can think of Netscape's DCFs as what I've called LACFs in this chapter-access control files that apply to a single directory or subdirectory on your Web server. Normally named .nsconfig (note the leading period in the filename), DCFs are organized into discrete sections with HTML-like markup. Each section is marked off by the tags <Files> and </Files>, in between which are access control and other rules that apply to the files specified. You can do many things with Netscape DCFs; here's an example that replicates the combined username/password and hostname/IP address access control to the personnel section of the example Web server:
<Files *>
RequireAuth dbm=webusers userpat="anne|joe|jerry" userlist="anne,joe,jerry"
RestrictAccess method=HTTP method-type=allow ip=123.45.67.* dns=*.personnel.mycompany.com
</Files>
This DCF, which goes in the top level of the /usr/local/web-docs/personnel
directory, applies to all files and subdirectories in that directory
tree. It requires username/password authentication, limiting access
to users anne, joe,
and jerry listed in the Netscape
user database named webusers.
It further limits access by both numerical IP address and symbolic
hostname, both using wildcards. Notice that it's not necessary
to specify both allow and
deny rules; Netscape's server
takes a more conservative approach to access restrictions than
do ncSA and CERN/W3.
| Tip |
Netscape DCFs in lower-level directories take precedence over the rules in a DCF in a higher-level directory. Thus, by creating a .nsconfig file in the personnel/executive subdirectory, you can limit access to files in that directory to the user anne, as you did earlier in this chapter. Such a DCF might look like this: |
You can enable Netscape DCFs using fill-in forms similar to those shown earlier for setting up hostname/IP address access control. For example, you can enable a DCF for a given server resource, and the graphical interface will create a skeleton .nsconfig file. However, you'll need to use a text editor to add your own detailed access control and other directives.
Combining username/password and hostname/IP address authentication in the ncSA httpd servers is fairly simple. You'll extend the rules in the <Limit> sections of either the GACF or LACF. Here's the now-familiar personnel example, modified to combine the two access control methods:
AuthType Basic
AuthName Personnel Only
AuthUserFile /usr/local/etc/httpd/userpw
AuthGroupFile /usr/local/etc/httpd/ourgroup
<Limit GET>
order deny,allow
deny from all
allow from personnel.mycompany.com
allow from 123.45.67
Require group personnel
</Limit>
As you can see, all you needed to do was to pull in both of the two sample methods shown in the earlier ncSA examples. Notice that order counts in the <Limit> section. Here, the hostname/IP address access control rules are applied first (using the deny and then allow sequence). After those rules are satisfied, the user is prompted for a password as the username/password authentication is applied. Based on this example, it's easy to modify this rule for an LACF in the personnel/executive subdirectory, simply by replacing Require group personnel with Require user anne.
The CERN/W3 Server is similarly capable of combining username/password and hostname/IP address authentication. Here, you'll modify the GetMask directive in your GACF. Again, here is the modified personnel example, this time limiting access using both methods:
Protection Personnel {
AuthType Basic
Passwordfile /usr/local/etc/httpd/passwd
GroupFile /usr/local/etc/httpd/group
GetMask @*.personnel.mycompany.com, @123.45.67.*,
personnel
}
As with the ncSA example, this one applies hostname/IP address access control first (since it appears on the GetMask line first) and then username/password authentication. Both rules must be satisfied before access is permitted. To further restrict access, you'll need to develop LACFs for individual directories and subdirectories. As noted earlier, the CERN/W3 LACF file's format is completely different from that of the server's GACF. Here's one (note the file must be named .www_acl) that can be placed in the personnel/executive directory to limit access to the subdirectory to user anne, and only from a specific hostname/IP address:
* : GET : [email protected],
[email protected]
This simple file has just one rule. (The rule is usually a single line, with colon-separated records, but it can be wrapped, as shown above, after a comma.) No one other than the user anne (who must give a password under the rule in the previous example) can access any files in the personnel/executive directory. Moreover, anne must be accessing the files from her normal pc to be granted access, even if she gives the correct password. For more information on CERN/W3 LACFs, check out the online documentation at http://www.w3.org/pub/WWW/Daemon/User/Admin.html.
You can further enhance security on your intranet by encrypting Web transactions. When you use an encryption facility, information submitted by customers using Web fill-in forms-including usernames, passwords, and other confidential information-can be transmitted securely to and from the Web server.
There are a wide range of proposed or partially implemented encryption solutions for the Web, but most are not ready for prime time. Of the several proposed methods, only two have emerged in anything like full-blown form. Let's look at the Secure HTTP (S-HTTP) and Secure Socket Layer (SSL) protocols in this chapter. Unfortunately, the two protocols are not compatible with each other. Worse, Web browsers and servers that support one method don't support the other, so you can reliably use one or the other only if you carefully match your Web server and customers' browsers.
S-HTTP was developed by Enterprise Integration Technologies and RSA Data Security, and the public S-HTTP standards are now managed by CommerceNet, a nonprofit consortium conducting the first large-scale market trial of technologies and business processes to support electronic commerce over the Internet. (For general information on CommerceNet, see http://www.commerce.net/.) S-HTTP is a modified version of the current httpd protocol. It supports
EIT has developed modified versions of the ncSA httpd server and ncSA Mosaic (for UNIX and Microsoft Windows), which both support S-HTTP transactions. Although the licensing terms allow for ncSA to fold EIT's work into its free httpd server and Mosaic browsers, there's been no public indication of ncSA's plans to do so. Meanwhile, the CommerceNet secure ncSA httpd server and Mosaic browser are available only to members of CommerceNet. You'll find information about both packages, including full-text user manuals, at the CommerceNet home page http://www.commerce.net/.
S-HTTP seems to have been engulfed in the 1995 Netscape tidal wave. Unwilling to wait for widely accepted httpd security standards to evolve (as it was with HTML as well), Netscape Communications Corporation developed its own SSL encryption mechanism. SSL occupies a spot on the ISO seven-layer network reference below that of the httpd protocol, which operates at the application layer. Rather than developing a completely new protocol to replace httpd, SSL sits between httpd and the underlying TCP/IP network protocols and can intervene to create secure transactions. Netscape makes the technical details of SSL publicly available. In addition, C-language source code for a reference implementation of SSL is freely available for noncommercial use.
The Netscape Navigator Web browser has built-in SSL support, as
does the Netscape Commerce Server; the Netscape Communications
Server does not support SSL. Given Netscape's share of the Web
browser market, it's hard to see how S-HTTP has much of a chance
at becoming widely available. With the exception of ncSA Mosaic,
most other Web browsers have-or have promised-SSL support. Some
of them are Spry's newer product, Internet in a Box, Mosaic in
a Box for Windows 95, and Release 2 of Microsoft's Internet Explorer
for Windows 95 and the Macintosh. By the time you read this book,
all of these packages might have completed their SSL implementations.
| Note |
Even though a browser might support secure transactions using SSL or S-HTTP, no transactions are actually secure except those between the browser and a compatible Web server. Thus, using Netscape, for example, won't provide any security unless you're also using the Netscape Commerce Server. It's also important to note that simply using a proxy service (that is, passing Web services through network firewalls) does not imply secure transactions unless both the proxy server and the destination server do. |
As noted in the preceding section, the Netscape Commerce Server supports the company's SSL security mechanism. Other packages that support SSL include the Secure WebServer package from Open Market, Inc., (http://www.openmarket.com/), which also supports S-HTTP, and IBM's Internet Connection Secure Server, which runs under IBM's UNIX, AIX Version 4, and OS/2 Warp. (Evaluation copies of Secure WebServer for several UNIX systems are available at the Open Market Web site.)
Both Secure WebServer and Internet Connection Secure Server are based on Terisa Systems, Inc.'s SecureWeb Client and Server Toolkit. This package provides source code for developers building secure Web servers and browsers. The Terisa Toolkit supports both SSL and S-HTTP. For more information about the package, visit Terisa's Web site at http://www.terisa.com/. Open Market's promotional announcements about Secure WebServer state that the package supports secure transactions through Internet firewalls, but no details on just how this works are provided.
CGI is the mechanism that stands behind all the wonderful, interactive fill-in forms you'll want to put on your intranet. Your customers might demand these kinds of intranet resources. CGI-BIN scripting is susceptible to security problems, so do your scripting carefully to avoid such problems.
You can minimize much of your risk of security breaches in CGI-BIN scripting by focusing on one particular area: Include in your scripts explicit code for dealing with unexpected user input. The reason for this is simple: You should never trust any information a user enters in a fill-in form. Just because, for instance, a fill-in form asks for a user's name or e-mail address, there is no guarantee that the user filling in the form won't put in incorrect information. Customers make typographical errors, but probing crackers, even those inside your organization, might intentionally enter unexpected data in an attempt to break the script. Such efforts can include UNIX shell meta-characters and other shell constructs (such as the asterisk, the pipe, the back tick, the dollar sign, and the semicolon) in an effort to get the script to somehow give the user shell access. Others intentionally try to overflow fixed program text buffers to see if the program can be coaxed into overwriting the program's stack. To be secure, your CGI-BIN scripts have to anticipate and deal safely with unexpected input.
Other problems inherent with CGI-BIN scripts include
Paul Phillips maintains a short but powerful list of CGI-BIN security resources on the Web. Check out http://www.cerf.net/~paulp/cgi-security, where you'll find a number of documents spelling out these and other risks of CGI-BIN scripting. For an extensive list of general CGI-related resources, go to Yahoo!'s CGI page, at http://www.yahoo.com/Computers_and_Internet/Internet/World_Wide_Web/CGI_Common_Gateway_Interface/index.html.
Is your intranet accessible from the Internet? If so, all of the security problems of the Internet are now your intranet's problems, too. Throughout this book, an implicit assumption has been made that your intranet is private to your organization. You can, however, connect safely to the Internet and still protect your intranet. You can even use the Internet as a means of letting remote sites in your company access your intranet.
First, look at some Internet security basics.
It's a fact of Internet life that there are people out there who want to break into other people's networks via the Internet. Reasons vary from innocent curiosity to malicious cracking to business and international espionage. At the same time, the value of the Internet to organizations and businesses is so great that vendors are rushing to fill the need for Internet security with Internet firewalls. An Internet firewall is a device that sits between your internal network and the outside Internet. Its purpose is to limit access into and out of your network based on your organization's access policy.
A firewall can be anything from a set of filtering rules set up on the router between you and the Internet to an elaborate application gateway consisting of one or more specially configured computers that control access. Firewalls permit desired services coming from the outside, such as Internet e-mail, to pass. In addition, most firewalls now allow access to the World Wide Web from inside the protected networks. The idea is to allow some services to pass but to deny others. For example, you might be able to use the Telnet utility to log into systems on the Internet, but users on remote systems cannot use it to log into your local system because of the firewall.
Here are a couple of good general Web resources about Internet firewalls:
If your company is also connected to the Internet, you'll want to know how to make sure your intranet isn't generally accessible to the outside world. You learned earlier in this chapter about denying access to your Web server using hostname and IP address authentication, but the fact that IP addresses can be easily spoofed makes it essential that you not rely on this mechanism as your only protection. You'll still want to rely on an Internet firewall to protect your intranet, as well as all your other network assets. Moreover, unless your corporate network is not connected to the outside world at all, you'll want to ensure the security of your other intranet services, including not only your Web servers, but also your FTP, Gopher, Usenet news, WAIS, and other TCP/IP network services.
More and more companies with widely distributed offices, manufacturing sites, and other facilities are turning to use the Internet to replace private corporate networks connecting the sites. Such a situation involves multiple connections to the Internet by the company, with the use of the Internet itself as the backbone network for the company. Although such an approach is fraught with security risks, many organizations are using it for non-sensitive information exchange within the company. Using a properly configured firewall, companies can provide access to services inside one site's network to users at another site. Still, however, the data that flows across the Internet backbones between the corporate sites is usually unencrypted, plain text data that Internet snoopers can easily read. Standard firewalls don't help with this situation.
A number of firewall companies have recently developed Virtual Private Network (VPN) capabilities. Essentially, VPN is an extension of standard firewall capabilities to permit authenticated, encrypted communications between sites over the Internet. That is, using a VPN, users at a remote site can access sensitive data at another site in a secure fashion over the Internet. All the data that flows on the public Internet backbones is encrypted before it leaves the local network and then decrypted when it arrives at the other end of the connection.
The VPN is similar to a wide area network, or WAN, in that you are connecting one or more smaller networks together. WANs, however, typically utilize dedicated phone lines to communicate with each other. Many T1 and T3 lines are used for this purpose daily all over the world. This WAN setup can be quite secure because the information flow is over private telephone networks, not a giant chaotic network like the Internet.
WANs are not as prone to outages as VPNs are. That is because the VPN is at the mercy of a) your Internet service provider, and possibly b) your Internet service provider's Internet service provider. If either of these two sites go down, you're in the dark. That's a bad thing when you need to get at your corporate database in Chicago for a meeting that started five minutes ago.
What VPNs do give you is secure communications over a relatively cheap medium. Instead of paying hundreds or possibly thousands of dollars per network drop site, plus the cost of WAN equipment (which can get expensive), you simply pay for an Internet connection. These can be had for as little as $125.00 per month. Granted you won't get much bandwidth for that price, but it's a start. If you are considering extending your corporate network, consider VPNs too.
The most mature VPN product comes from Raptor Systems (http://www.raptor.com/), part of the company's Eagle family of products, and others are available from Checkpoint (http://www.checkpoint.com/) and Telecommerce (http://www.telecommerce.com/).
Figure 5.9 shows a schematic drawing of a VPN, reprinted with the permission of Raptor Systems, Inc. The cloud represents the Internet, and the firewall system, local network, and remote site are shown as workstations. The broad line connecting the workstation at the remote site to the local workstation illustrates the VPN. Such products make it possible for you to extend the availability of your intranet to remote company sites without having to set up a private network.
Figure 5.9 : Virtual Private Network.
This chapter has dealt with implementing security on your intranet. Although an intranet is, by definition, internal to an organization, security is important not so much because it prevents things, but because it enables them. Judicious use of built-in security features of Web servers and other intranet resources can add value to your intranet by making new things possible. In this chapter, you have
In the next section, you will examine the various methods available to Java for connecting to databases.