After your Intranet has been in use a while you might realize that allowing customers to query the Intranet server directly can help to reduce support staff. Much of the information on the Intranet may be used for support services such as a database of common questions. By allowing external access many calls can be averted. It is also possible to setup remote offices with access to the corporate Intranet over the Internet.
Many times information that would be useful to an Intranet is already available on the Internet. Rather then duplicate this information it is possible to link in external sites with your Intranet.
In this chapter, we will discuss the following:
Many popular Internet sites started out as test sites used internally. These Intranets were such successes that the company decided to make the software available to any customers connected to the Internet.
This is very common and quite likely to happen more often as Intranets become more useful. Allowing Internet users to access part of your Intranet can be a formidable task, especially with security being a major concern, but the WWW is designed to be very flexible and can be used by both internal and external users without too many problems.
There are basically two different approaches to allowing Internet users to get to part of your Intranet: Using the Web server access controls and dedicating a separate machine to Internet access.
Because most Web servers allow you to specify who can access different directories, this is one of the easiest ways to allow some external access to the Intranet server. Using the access directive already supported by the server is simply a matter of changing the access file-usually access.cfg-and restarting the server. Some servers such as IIS allow you to change access permissions via a graphical user interface.
However, your permissions allow you to specify restrictions based on two criteria: IP address and username. IP address permissions allow the administrator to only allow certain machines to access the site or parts of the site. Using usernames and passwords to restrict access allows certain users to get to parts of the site. Using a combination of these two permissions allows fairly selective control.
The first way we will look at is to restrict which IP addresses or address ranges can connect to a directory. This works well if you know the IP addresses that should have access and you trust the security of the remote site. If someone gains access to the machine you are allowing, they can access your machine.
The easiest way to split the Web server is to have one directory tree that is public and one that is private. This is shown in figure 22.1.
Figure 22.1 : 123.123.123.123 can view the public directory but not the private one.
Using Apache or Netware Web Sever it is necessary to edit the access.cfg file, which is located in the configuration directory-usually /usr/local/etc/httpd/conf for Apache or in SYS:\WEB\CONFIG for Netware. It is also possible to use the override file-usually .htaccess-for Apache and acess.www for Netware, in the directory itself. You need to check the Limit directive for the different directories that the Web server uses. The private directory should have a Limit directive that looks like the following:
<Directory private> <Limit GET > order allow deny allow 123.123.123.0 deny from all </Limit> </Directory>
Line one defines what directory we are describing. If we were using the .htaccess file instead of the global file, this directive would not be necessary. The Limit defines what can be done to files in this directory, in this case GET. The order tells Apache to allow first and then deny. The allow 123.123.123.0 tells Apache that anyone coming from a machine on the 123.123.123 network can have access. The deny line refuses access to everyone else. The next two lines finish the directives.
For the public directory everyone should have access so the directives should look like the following:
<Directory public> <Limit GET > order allow deny allow all </Limit> </Directory>
This is similar to the directive used to deny except in this example we say allow all and don't have a deny line. We could limit access, say from a competitor or a harassing machine by adding a deny line with the IP addresses we want to refuse access to.
| NOTE |
More details on the Limit directive are available in Chapter 3 "Installing and Configuring HTTPD for UNIX." |
After changing the access.cfg file you must restart the server or send it a hangup (HUP) signal.
The Netscape server can be configured to block access by IP addresses as well. To do this you use the server manager program located in the admserv directory in the server root directory. If the admin server is not already running, then run start-admin to start the admin server program. Then point your Web browser to http://intranet.server.name:aport/.
Next perform the following:
Using wildcards also allows you to limit different type of files. For example, you might allow remote users to access all the files except .cgi files. If so, you would enter /private/*.cgi.
Using Microsoft IIS you can only allow or deny access to the entire server using IP restrictions. If you need to allow users to only part of your site, you will need to use user-based security, which is discussed in the next section.
There may be times when you need a finer granularity than restricting access by IP address. This might happen if you only want selected customers to have access to a particular part of your Intranet. This would allow, for example, a support contract-only area.
| TIP |
Since many people have Internet access at home it is possible to allow them to access the Intranet from home. This can allow a form of telecommuting over the Internet. Using passwords and usernames helps to make sure only valid users can connect over the Internet. |
HTTP allows for basic authentication only. This allows servers to require passwords but the passwords are sent in the clear. This allows anyone sitting on a network that the traffic passes through to use a network sniffer to see the username and password. If this is not enough security for your site, you will need to use some sort of encryption, such as SHTTP or SSL. SHTTP and SSL are covered in Chapter 1
Using usernames and passwords with Apache requires editing either the directory directive in the access.cfg file or the file .htaccess file in the directory you want to protect. The Limit directive needs to contain:
<Limit> require valid-user AuthName [Auth-domain] AuthType Basic AuthUserFile [user-file] AuthGroupFile [group-file] </Limit>
The require directive tells the server what users to allow access to. valid-user tells it to allow anyone with a valid account to be able to access it. You could also list which users can have access to this directory.
AuthName defines the security domain the password is good for. This is normally the same for the entire machine, but it is possible to have more then one security domain per server.
AuthType has to be Basic because that is all Apache uses. AuthUserFile and AuthGroupFile define what files contain the usernames and passwords.
The Limit directive is covered in more detail in Chapter 3"Installing and Configuring HTTPD for UNIX".
Netscape's server also allows username and password authentication. To enable it you will need to go into server manager (see previous section or Chapter 5for details) and select the "Restrict access to part of your server through authentication" link.
Netware Web server allows either file-based authentication, like Apache, or NDS-based (Netware Directory Services based) authentication. The most common way is to use file-based authentication if you are going to be sharing the server with external users.
To restrict directory access you must manually edit the per directory access control file, normally ACCESS.WWW. Before the Limit directive you must add three directives:
Inside the Limit directive you need to add a Require directive telling the server which users can have access to the directory. This can be a list of usernames or "valid_user." Using valid_user allows any user listed in the AuthUserFile to have access as long as he or she enters the correct password.
The encrypted file is created using the command pwgen. It takes as arguments the input file and the output file. The input file is a file containing usernames and clear text passwords. For example:
Rich:secret Tom:quiet Al:ring
After running pwgen and copying the encrypted file in ServerRoot, usually SYS:WEB, you should copy the unencrypted file to floppy disk and remove it from the system. This is added protection to keep the passwords from being accidentally discovered.
If you choose to use NDS passwords, you can use the webmgr.exe program to configure the access restrictions. To do this perform the following:
Microsoft IIS can also be used for username authentication. This can be done by performing the following:
This will force users to supply a username and password. This username must be a valid account for the machine running IIS or in an accessible NT domain.
| CAUTION |
Using Basic authentication sends the username and password in clear text. This will allow anyone on the network or on a network that the traffic passes through to see the username and password with a network sniffer. |
If your users are using Microsoft Internet Explorer for Windows 95, you can choose Windows NT Challenge/Response instead of Basic. This does not send unencrypted passwords in the clear.
It is also possible to run two separate WWW servers on one machine. This is useful to allow tighter restrictions on the private server while allowing looser restrictions on the public one.
You must first choose an alternate port for one of your servers to run on. Normally the externally accessible server runs at port 80 because this is the default. The internal server can run on any free port. Ports range from 1 to 65535.
| NOTE |
You can use any port between 1 and 65535 to run a Web server on. It is important to make sure the port is free before trying to use it. Ports less then 1024 are considered reserved. On UNIX machines this means you must have root permissions to run a server on these ports. |
Configure one server to run on one port and the other to run on a separate port. This will require two separate configuration directories and may require two licenses.
A better alternative to sharing an Intranet server with Internet users is to have a separate machine dedicated to the Internet. Because the WWW is distributed it is very easy to split the server into separate pieces and have links from the private Web server point to the public server. This adds a layer of protection in case the public Web server is compromised.
Running a separate machine allows looser controls to be placed on the internal server while still protecting sensitive data from intruders. It also provides a layer of protection because the external server doesn't need to have full network access.
When running with two servers it is desirable to separate them with a firewall or other protective measures. This helps to eliminate crackers getting access to the internal server using other means then the WWW software. Firewalls are covered in Chapter 23, "Intranet Security."
There are different ways to split the Web servers such as:
Having a separate server separated by a firewall and mirroring the required data is the most secure solution. It is also the most costly, both in hardware costs and maintenance costs. It is important to decide how much security is enough for your company.
It is common for users to want to access corporate information while they are on the road. Sales people and field support personnel frequently need access to sensitive company data while out of the office. This data though may need to be kept private and not released to the Internet community.
The following are several ways for people to get access to an Intranet:
Dial-in IP connections such as PPP or SLIP allow remote machines to connect over standard phone modems and act as if they were directly connected to the network. This allows them to use standard network tools such as Netscape Navigator, InterNotes, or Microsoft Internet Explorer.
PPP and SLIP access is distributed with Windows 95 and NT as well as with OS/2. It is available for Windows 3.x and above from many commercial sources as well as shareware. UNIX machines can download software to allow them to connect over modem lines as well. Some UNIX operating systems have PPP or SLIP already available. Check your documentation.
| NOTE |
PPP software for PCs is available from many commercial sources as well as a shareware package called Trumpet Winsock. Trumpet is very popular and can be downloaded from ftp://ftp.trumpet.com.au/ftp/pub/winsock. |
PPP and SLIP require either a dedicated communication server, or a server package running on a server machine. PPP/SLIP servers are available for UNIX machines. Windows 95 and Windows NT have PPP servers shipped with them. See the documentation on setting up PPP or SLIP links.
Dial-in IP connections should be protected using strong security. Basic security such as usernames and passwords is the minimum security you should have on dial-in connections. There are even more secure ways to protect your dial-in lines, such as the following:
Once a PPP or SLIP link is established, normal IP-based networking programs should work. Because most modems are under 28.8 Kbps-as opposed to the 4 Mbps or higher used in most LANS-performance will be much slower.
If employees are often calling in long distance, then the phone costs can add up very quickly. It is possible for remote users to connect to the Intranet over the Internet. Internet Service Providers, such as AT&T, Sprint, and Uunet have local numbers in most large cities. CompuServe and America Online also have local numbers in most cities.
Using the Internet opens many security problems but most of them can be limited by using a few server access lists, such as restricting to known IP addresses or forcing users to login using a username and password. To be even safer you should probably use a secure protocol such as SSL or S-HTTP.
| CAUTION |
When using the Basic authentication passwords are sent in the clear. This allows other network users to sniff the password and username if they are attached to the same network or a network that the traffic passes through. |
If your employees often connect from a certain customer site, or if your remote offices also have Internet connections, it might be possible to use Internet address restrictions to only allow certain addresses to connect.
| CAUTION |
IP Spoofing is fairly easy to do. It involves using another machine's IP address to send commands or requests to a third machine. Allowing access by IP address only is asking for trouble. |
There are several ways to enforce IP restrictions. We have covered how to do this on a per directory level using Apache, Netscape, and Netware. Using the same instructions you only need to restrict access to each directory in your Web server tree.
| NOTE |
There is also a UNIX package called TCP Wrappers that can be used to only allow access to certain IP addresses. It can also be used to start separate servers for internal and external users. TCP Wrappers are covered in Chapter 23, "Intranet Security." |
To allow IP restrictions in Microsoft IIS you need perform the following steps:
It is also possible to force users to login whenever they access the WWW server. This is done in the same manner as per directory.
Simply follow the directions to setup password authentication for a directory and apply it to all directories.
| NOTE |
It is also possible to apply these restrictions on just the Document Root directory but check your documentation to make sure the permissions will follow from there. |
This forces users to supply both a username and a password to access documents from the Intranet server.
| CAUTION |
Using Basic authentication passwords are sent in the clear. This allows anyone with access to a network segment that your traffic passes over to sniff your password and username. The only way to defeat this is to use encryption or one-time passwords. Using the Web server protections only protects against attacks to the Web server. If users can get access via other means, it is necessary to secure those as well. This is shown in figure 22.3 |
Figure 22.3 : Crackers may be able to get documents using other protocols than HTTP.
Allowing users to dial-in and have full network access makes it easy for them to get work done, but it is sometimes complicated to set up and use. There also is no real way to track what a remote user is doing using dial-in IP.
If someone breaks in, one of the most important tasks (after fixing anything he broke and closing the security hole that allowed him in) is to find out what the cracker did. Using dial-in accounts helps to keep track of what users are doing just in case their account is ever stolen.
Dial-in accounts are often much easier to set up than a PPP or SLIP server. Most UNIX machines allow a modem to be hooked up to a serial port for remote access. There are often few changes that need to be done except for telling the system to allow logins on the remote port.
This is generally done in one of the following ways:
Software is also available to allow a remote user to take over a PC. This software allows a remote user to enter commands just as if he were located at the keyboard. This can be used to allow remote users to connect to and use the Intranet. A dedicated PC, however, is required.
Microsoft Windows NT contains a package called RAS (Remote Access Server). This package allows remote logins to the NT server itself.
RAS allows the access to be restricted to the NT server only or to the entire network. Configuring RAS is fairly simple to do:
After RAS is setup you need to grant users permission. This is done by performing the following:
It is possible to use special encryption equipment to link remote offices over the Internet without having to worry about someone seeing your traffic.
These devices can be hardware devices such as routers or software devices that act as proxy servers to the remote network. These links are configured to automatically encrypt traffic to a specific network before sending the traffic over the Internet.
Unfortunately these devices normally require the same sort of equipment on both ends of the link. It is sometimes problematic exporting encryption outside of the United States.
One of the main reasons for having an Internet connection is to be able to access the many sources of information. Finding the information however can be very frustrating.
Some search engines will return hundreds of links on almost any search. While this is very good for finding arcane bits of knowledge, this is often times too overwhelming to be useful.
Some companies will either dedicate someone to be an Internet researcher, or more often, whoever is most familiar with finding information acts as a contact person. Either way, having a separate page on the Intranet for useful links can be very helpful.
There are many books available that can act as reference books on where to find information on the Net, but this information is often general reference only. Companies often need more specific information related to their specific product lines, such as a construction company having links to lumber yards or distributors. It is very useful to have links to the competition as well to keep abreast of what they are doing.
Finding all this information can require many hours of time. That's why having a global bookmark or hotlist available for users of the Intranet makes such sense.
There are many Internet sites that will be useful to your company. Some will be very specific to your company's needs and some will be generic. This section covers a few of these generic links and shows how to integrate external links into the Intranet.
As we learned earlier in this book, forms require an action item. In our examples we used local scripts, but it is possible to use remote scripts as well. The basic form is still the same:
<form method="POST" action="script">
The method is either GET or POST depending on how the script is expecting the data. The action is the script that receives the data. The action item can also be a remote form as long as you give it the complete URL of the form. This would allow a form to be local to your machine and send a request to a remote machine.
For example, to send a tracking request to the FedEx site you would have a fill out form that uses the FedEx script to actually query the site. This allows your users to only use bandwidth when sending the request and sending the answer.
| NOTE |
You should always check with the Webmaster at the remote site before using one of their scripts in your forms. They will probably be flattered that you find their site so useful, but some sites may not want you to link to them. |
CUSI stands for Configurable User Search Interface. It is used to build a page of search engines. It uses the remote script function to submit queries to different search engine depending on what you are looking for.
CUSI has search engines for software, RFCs, index sites, and general search engines. It is very customizable-as the name implies-and if maintained, is very useful as a building block for a company search page.
More information on CUSI is available from http://pubweb.nexor.co.uk/public/cusi.