Hostname-Address Authentication - Online Article

All the Web servers discussed in this article 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 articles, 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.

Hostname/Address Authentication in the ncSA Servers

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

     
  • Order, which specifies  the order in which the other directives in the file are to be  evaluated.
  •  
  • Allow, which permits  access based on a hostname or IP address.
  •  
  • Deny, which denies access  based on a hostname or IP address.

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.

Hostname/Address Authentication in the CERN/W3 Server

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.

Hostname/Address Authentication in the Netscape Server

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.

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. 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.

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.

As with filenames, you can enter either specific individual hostnames  or IP addresses, or wildcard patterns that match multiple hosts.

An Important Warning About Hostname/IP Address Authentication

All of the Web server software described in this article 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.

Combined Authentication

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.

Combined Authentication in the Netscape 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

     
  • Define a set of users, such as the sample personnel group I've  used, in the Netscape user database.
  •  
  • Apply username/password authentication,  such as to the personnel resource, limiting access to the members of the personnel group in the user database.
  •  
  • Apply hostname/IP address restrictions,  such as to the same personnel resource, limiting access to those computers in the personnel subdomain (or even to the individual computers of the members  of the personnel group).

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 article-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 article. Such a DCF might look like this: <Files *>  RequireAuth dbm=webusers userpat=anne userlist=anne  RestrictAccess method=HTTP method-type=allow ip=123.45.67.89 dns=annspc.personnel.mycompany.com  </Files>

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.

Combined Authentication in the ncSA Servers

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.

Combined Authentication in the CERN/W3 Server

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  :  anne@annspc.personell.mycompany.com,  ann@123.45.67.89

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.

About the Author:

No further information.




Comments

No comment yet. Be the first to post a comment.