External Intranet Access

Working from home is increasing in popularity for many companies. In the US, 25 million people spent at least some time working at home in 2001 (increased from 22 million in 1997), and of these, 80% used a computer for their work (see http://www.bls.gov/rofod/1460.pdf). For the employees, home working can allow them to spend less time traveling, and to work in more comfortable surroundings. For the employer, it can save money on office space, and may increase productivity. Intranet access from home can enable the home worker to solve problems more rapidly than if they did not have access. It can also help alleviate the feelings of isolation that can be caused by home working.

Another situation in which external intranet access might be required is when there is a consultant working at a client site for a period of time. The consultant is likely to benefit from access to their employer's intranet, although there may be problems of privacy and security to overcome if using a computer provided by the client, such as making sure the consultant is only given access when and where (and for as long as) needed.

If you are supporting any form of external intranet access, then you need to be aware of the bandwidth available to your external users. If the majority of them are using modems, then make sure that you're testing your intranet designs via a modem as well. We discussed methods for making the intranet faster, and appear faster, in Chapter 6 on Usability.

Using a Virtual Private Network (VPN)

A VPN is a secure network that uses the Internet for communication, but uses encryption to authenticate and secure each end. VPNs have grown in popularity because it is much cheaper to set up a VPN than a private network. We have already briefly mentioned VPNs in Chapter 10, Security and Personalization. An employee outside the office can use a VPN to access the company intranet securely, as well the rest of the internal business systems. In addition, different offices can be connected via VPN to share the same servers.

VPNs are a large topic, and in this chapter we will provide a brief overview and consider a few of the intranet-specific aspects of a VPN. Because of the potential that a VPN has for exposing your company to data loss and hacker attacks, it's vital to consider any move to a VPN very carefully and to consult a security expert on your exact setup.

VPNs are broadly divided into three types:

• The remote access VPN

• The intranet VPN

• The extranet VPN

The intranet VPN links together remote offices and partners, using secure tunnels across the Internet between specifically designated VPN gateways. The extranet VPN performs the same task for customers, suppliers, and other external communities. The remote access VPN allows access to a corporate network for employees that are away from the office - for example at home or on the road. The technologies used by all three are quite similar.

There are three major forms of VPN technology. These are IPSec (Internet Protocol Security), PPTP (the Point-to-Point Tunneling Protocol), and its successor L2TP (the Layer Two Tunneling Protocol). PPTP and its successor L2TP are primarily associated with Windows, whereas IPSec is more common on Unix systems (although it is now available on Windows 2000). Of the three, PPTP is the easiest to use, since the PPTP client is included with Windows since Windows 98SE, and PPTP is easy to set up on a Windows NT, 2000, or XP server. Encryption with PPTP is optional - and it must be turned on in order to provide a secure VPN. However, PPTP uses less secure encryption than the other two options, and has had several security-related bugs in the past. There's a good article on setting up a Windows VPN on the Microsoft web site at http://www.microsoft.com/technet/columns/profwin/pw0201.asp.

If employees are accessing the VPN from home, they may need to check the details of their ISP's (Internet Service Provider) contract. Some ISPs do not allow the use of the network connection for business purposes, such as VPN, without signing up for a special "Business" or "Professional" contract.

A good, but rather dated, reference for VPNs is Virtual Private Networks (Erwin, Scott and Wolfe, O'Reilly; ISBN: 1-56592-529-7).

Using SSL for Secure Remote Intranet Access

You may already be familiar with SSL (Secure Sockets Layer) - it's the technology used by web sites using the "HTTPS" protocol to make sure that communication with them is secure. In the way that it is used by most secure web sites, it verifies the identity of the server based on its server-side certificate (so your banking details are not sent to an untrusted server impersonating the bank's server), and it encrypts the communication between your web browser and the server.

It is possible to set up remote access to an intranet in the same way that you'd normally set up a secure web site - using a server-side certificate to provide encryption, and a username and password combination for each user. Alternatively, SSL can be used with a client-side certificate in addition to the server-side certificate. The client-side certificate is used to verify to the server that the client is trusted. It is more convenient and secure than a username and password, but it also makes it harder for a user to access the intranet from a different machine (although most of the time, this is an advantage). This also means that if anyone else gets access to the user's machine, they will be able to access the intranet. For particularly sensitive intranet data, and for computers such as laptops that are particularly vulnerable to theft, it may be worthwhile to require both a client-side certificate and a username and password.

Unlike a VPN, using SSL doesn't provide access to other computers on your intranet, but only to the intranet web pages itself.

SSL intranet access can be problematic if the intranet is running on a number of different servers - each must be set up for secure access. Using SSL to access the intranet also requires that SSL traffic to your intranet servers is allowed through the firewall - which may allow vulnerabilities in your web server to be exploited by attackers. If you are using SSL to allow remote intranet access, then consider positioning the intranet servers in a DMZ (de-militarized zone) that cannot access the rest of your internal systems.

Note

There is no need to pay a certificate authority (CA) such as Verisign to provide an SSL certificate for each intranet server and remote client. Most web servers that work with SSL will provide a certificate generation tool so you can make your own. The advantage of using a CA normally is that the CA's certificate will already be installed in users' browsers, so certificates signed by the CA will automatically be trusted. When you issue your own certificates, they will not automatically be trusted and instead each user must install your certificate in their browser themselves. However, since this is your company intranet, the users know they can trust you, so this is not an issue.

Dial-Up Access

An alternative to a VPN is having modems connected to a computer behind the organization firewall. Employees can connect to the internal computer from home using their own modems, over the phone line.

Dial-in setups are becoming less popular than VPNs. They are more expensive, both in terms of the initial setup and the ongoing maintenance costs. In addition, with the increasing penetration of broadband Internet access, a dial-up modem connection may be considerably slower than the employee's normal Internet access speeds. Users may not be able to effectively access high-bandwidth intranet content such as video, audio, or graphics even if there is intranet access, because of the bandwidth constraints.

The dial-in connection from a remote user to a company's intranet server usually takes place over low-speed and sometimes unreliable communication services. Users must frequently recover from line drops and other communications issues. The combination of connect-time charges and the opportunity cost of non-productive user time can be substantial for a large field organization.

For a small intranet, it is possible to use standard PC server hardware, with one or more modems installed, connected to dedicated phone lines. Users dial in to the server via their own modems, and the server provides connectivity to the intranet. Software is also required for this, of course. Windows comes with Remote Access Service built in, and Linux uses PPPD for the same task.

There's more information on the support within Windows for RAS at http://www.microsoft.com/technet/itsolutions/network/Default.asp. For Linux, see the PPP documentation at http://www.samba.org/ppp/documentation.html.

If there are many remote users, it becomes difficult to cope with the number of phone lines required. At this point, it's necessary to switch to using ISDN-PRI (Primary Rate Integrated Services Digital Network) lines. These allow the phone company to bundle 23 or 30 (23 in the US, 30 in the UK) connections down one line. This requires a RAS adapter in the server that has interfaces for ISDN-PRI connections.

It is also possible to buy dedicated RAS servers, running on proprietary hardware. This is generally a better option when there's a need to support more users - although the initial costs are higher, the servers are more integrated, use less power, and are more reliable than standard servers adapted to remote access, so support costs should be lower.

Providing Security for Remote Intranet Access

Providing security for remote intranet access is a question of assessing and minimizing risks. Allowing any sort of remote access, either over the Internet or via RAS, means that the intranet is not impenetrable by a determined and skilled attacker. However, you can reduce the vulnerabilities and ensure that security problems can be recovered from.

At the very least, a username and password should be required for intranet access. However, this only provides a minimum of security. Users will often choose poor passwords that are easily broken by automated password-guessing programs. If effective passwords are enforced (for example, with an automatic check to invalidate passwords that are too short, or dictionary words, or do not contain enough non-alphabetic characters) then users will write down the password or store it on their computer. Although this reduces the risk that a random attacker somewhere on the Internet can penetrate your systems, it increases the chance that an attacker with access to an employee's home computer can do so. If intranet security is of great importance to your business, then you should consider using a system that requires a password and a token, such as the RSA SecurID (http://www.rsasecurity.com/products/securid/), or even a biometric scanner that checks fingerprints or retinas. However, for most companies, simply using secure passwords is good enough, combined with limiting the damage that an authorized user can do.

If it is only possible to read the intranet remotely, without making any changes to it, then the potential for damage via remote access is low. The worst that can happen is that a competitor can gain access to confidential material. Although this is a risk, it's probably less likely that a competitor would illegally hack into a company intranet than it is that they would simply try to hire some of your company's current employees to obtain the same knowledge legally. However, if it is only possible to read and not to update the intranet remotely, then it becomes less useful when being used for legitimate purposes.

If it is possible to upload files to the intranet remotely then there is the danger of virus infection. By uploading a virus-infected file or a Trojan horse to the intranet that is downloaded and run by computers within the company, an attacker can potentially take control of computers within the organization, destroy files, and severely damage the company systems.

Viruses may also be uploaded to the intranet by accident. Although computers within the organization are likely to have a virus-checker, this is not necessarily true of employees' home , computers. Therefore, if you allow executable files or MS Office documents to be uploaded to the intranet from employees' home computers, make sure that you have some form of virus-checker in place to check uploaded files. Many content management systems will interface with a virus-checker. At the very least, it's easy to write a piece of server-side script that will automatically call a virus-checker when a file is uploaded. If the VPN allows access to network drives as well as allowing intranet uploads, then virus-checking will be needed on all networked machines - most virus-checkers can be set up to automatically scan everything written to the machine they are protecting, or some firewalls can be set to scan all data that passes through them for viruses. It's also a good company policy to provide employees with a virus-checker at home for free; it benefits the company and it benefits the employees.

If remote editing of intranet content is possible, then an attacker can deface the intranet. A more subtle attacker can edit critical data based upon which intranet users will make decisions, and possibly cause more damage. You can reduce these risks with backups and with logging. If the intranet is regularly backed up, then defacements can be quickly removed. If all changes to intranet content are logged by the username and IP address that carried them out, then it's possible to check what changes are being made, and find all of the changes that have been made by the attacker. However, this requires that the logs are checked, which can take a considerable amount of work for a large intranet. It's more likely that the logs will be stored, and then when unusual data is spotted on the intranet, any other changes made by the same attacker can be undone.

Of course, if there are security holes in the intranet web servers or other services running on the same machine, then it may still be possible for an attacker to crash the intranet or gain control of the intranet servers. Microsoft's Internet Information Server has historically been subject to more attacks than other web servers, but all web servers and operating systems need to be kept up-to-date with security patches.

"By placing the intranet server in your network DMZ, and not allowing the intranet server access to the rest of your network, you can reduce the risks of remote access"

By placing the intranet server in your network DMZ (De-militarized Zone), and not allowing the intranet server access to the rest of your network, you can reduce the risks of remote access. If the intranet server is compromised, then the attackers will still have no access to your internal systems, such as mission-critical database servers. The only damage that can be done is that the intranet web pages can be deleted or defaced. Although this is annoying, as long as there are regular backups of the server it need not be a serious problem.