7.3 Dial-In Security Access

   

There are two types of dial-up security that a network administrator has to worry about: dial-in VPNs and users who access IP VPNs through a dial-up ISP. There are different security concerns for each of the dial-in models. For dial-in VPNs, the primary focus is securing the corporate environment, while the security precautions for dial-up IP VPN users focus on securing the remote environment.

7.3.1 Dial-In VPNs

Dial-in VPNs are generally created in one of two ways. Either a network administrator sets up a modem banks with an RAS server, or a user attaches a modem to his or her computer and installs remote access software.

The first type of remote access is fine, and can be an easy way for employees to gain remote access to the network. The second method of remote access should be, to put it mildly, actively discouraged.

Aside from the aforementioned expense associated with dial-in VPNs, the other problem with them is that they have been around, in one form or another, for many years . Remember the movie WarGames ? WarGames took place 20 years ago, and there were already tools available to gain unauthorized access to remote machines via modem. Tools have gotten a lot better since then, and are constantly being improved.

There are two types of attacks used against modem pools: war dialers and demon dialers. A war dialer is a program that dials a string of numbers looking for modem tone. Once modem tone has been detected , a demon dialer will then try username and password combinations in order to gain access.

A properly secured modem bank, with sensible security precautions and a strong password policy, is very resistant to war and demon dialing attacks. That's not what attackers want. They are looking for a single stand-alone modem attached to a device that does not have a password, or has a password that is easy to guess.

Many question the need for a strong modem security policy. Modem access is obsolete, and it is unlikely that anyone will attach a modem to a workstation and leave it connected for an attacker. Remember, unlikely does not mean that it cannot and does not happen often. A prime example where modems are still commonly used is in terminal servers. It is not uncommon for network administrators to set up out-of- band access to routing equipment. If there is a major catastrophe on the edge routers or core switches that takes out the entire network, the administrators need a way to access the equipment ” especially if they are at home when it happens. A terminal server with a modem attached is an excellent solution to this problem.

The problem is that terminal servers are often insecure , requiring only a simple password, or even no password to access them. Many terminal servers provide no logging information as well. If an attacker is able to gain access to it, there is often no record of where the call originated, or what commands were issued while the attacker was connected.

This does not mean that a terminal server should not be used as a back door into network routing equipment. Instead, it is important that the same policy that is applied to the primary corporate modem bank should apply to all other modems that are installed on the network. However, the number of modems installed, outside of the primary modem bank, should be limited, and each one should be monitored for potential security breaches.

Modems that are not in use, for instance many laptops come standard with modems, should not be connected to phone lines, and should be removed whenever possible.

7.3.1.1 Dial-In VPN Security

As with anything else on the network, a security policy should be in place for modem services. As previously mentioned, the primary rule in any modem security policy should be no unauthorized modems.

Ideally, all forms of modem access should be forced to authenticate against a RADIUS server, but sometimes that is not possible. If RADIUS authentication is not available for a specific application, consider instituting a minimal rule set for any modem on the network. The rule set should consist of a set of minimally accepted logging standards. It should at least log the incoming phone number and log activities that involve remote access to another device. The modem software should require a password in order to access it and that password should be subject to the same rules as all network passwords.

The modem software should have a lock out feature, so that if an account enters the wrong password more than three times, the account is locked until an administrator reactivates it. Either the modem software, or the device to which it is attached, should allow a network administrator to set policy restricting areas of the network that are allowed to be accessed over a remote connection.

It is important to review the network to ensure there are no unauthorized modems installed. Again, it is becoming less likely that an employee will install a modem for the purpose of remote access, but it still can happen, and when it does network administrators should be aware of it, and remove the unauthorized device.

7.3.2 RADIUS Security

Many of the same security rules that apply to a single modem installation also apply to a modem bank. Fortunately, the RADIUS software that is available today can make it easier to enforce these policies, and give an administrator much more control.

There are many different implementations of RADIUS available on the market such as Steel-Belted Radius, RadiusNT, and GNU Radius. In addition to available software, many RAS devices include their own version of RADIUS. The version of RADIUS is not as important as the security precautions that are taken to secure it.

Starting with the basics, the RADIUS server should be a single use server, with no other services running. Only a limited number of users should have access to the server, and there should not be any unnecessary accounts ”this means deleting low-level accounts, such as guest on Windows servers, and the games account on Unix servers.

Whatever version of RADIUS the server is running, the software process should not be owned by the administrator account on the server. RADIUS listens to Port 1812 for UDP connections. Most likely the software will need to be started by the administrative user in order to bind itself to the port, but after that the owner should be changed to a nonprivileged account used just for RADIUS.

One of the limitations of RADIUS is that only the password is encrypted, not the entire packet. On a local network, with proper security precautions in place, this should not be too much of a disadvantage , but it is something to be aware of and monitor.

One of the big debates associated with using RADIUS, or any other remote authentication protocol, is whether or not the RADIUS server should authenticate against the existing network passwords, or if passwords should be created. Using the existing password file is easier from a management standpoint because there are fewer password files to maintain, and fewer username/password combinations for an attacker to guess. Users also prefer a single login to the RADIUS server and network. The downside is that if an attacker does manage to authenticate against the RADIUS server he or she now has full access to the network.

Unfortunately, this problem is compounded by the fact that many remote access tools allow users to save their username and password in the login box. An attacker who manages to get an employee's laptop will have full access to the network. As much of a pain as it may seem, it is generally better to separate the RADIUS username and password from the network authentication username and password combination. It should also be a policy that the two passwords be different.

7.3.3 Dial-Up ISP Security

A remote access VPN creates a whole new set of problems for security administrators, and extends the reach of the security policy. Users accessing the network through a dial-up ISP are the first part of that extension.

Remote users connecting to the network through a dial-up ISP add an element of uncertainty into the network security arena. Network administrators no longer have control over the entire network, and are less able to secure data. There are additional security considerations that need to be taken into account.

First and foremost among these unknowns is the dial-up ISP that remote users are using. Unlike local phone service, the federal government does not heavily regulate dial-up Internet access. The quality of service provided by dial-up ISPs varies greatly from one service to another, and the quality of security varies from ISP to ISP. If possible it is a good idea to select a national ISP, with a solid security reputation, especially if the organization will be contracting with them for many dial-up accounts. A representative from the ISP should be able to answer questions about the steps taken to secure the dial-up network and the data passing across it.

Many large ISPs also provide dial-up services. Providers such as AT&T, Sprint, WorldCom, and Level 3 all have dial-up service as well as high-speed connectivity. If the corporate provider has a dial-up backbone that meets the needs of an organization, signing up through them is usually a good idea ”especially because they tend to have a very large dial footprint. While not as safe as a direct connection, knowing that dial-up users will be connecting to the same network as the corporate backbone provides some reassurance that the VPN data will be secure.

In addition to concerns about the security of the dial-up backbone, VPN administrators have to be concerned about the security of the systems connecting to the network. Dial-up ISP users are actually, relatively speaking, more secure than cable or DSL users, but there are precautions that need to be taken.

Many remote VPN users will connect using their company-assigned laptops. This is actually preferred in some ways; it means that the security precautions in place within the organization's network will continue to be in place while the user is dialed into the network. One thing that needs to be communicated very clearly to remote VPN users is that the computer in use still belongs to the organization, and should not be used for any personal activities. It is possible for a remote user to introduce a virus or worm, through the VPN, into the network. Limiting the outside activities the laptop is used for should help keep that from happening.

Some users already have their own computers at home, and would rather use those to access the network remotely. There is nothing inherently wrong with this, but these users should follow the same security precautions that are in place on the corporate network. If, as will be discussed in Chapter 14, there are minimum operating system standards in place in the corporate network, those minimum standards should be applied to remote systems as well.

Generally, this means that a home user should not be connecting to the network using a Windows 98 or Windows XP machine, for example. Home users connecting through dial-up ISPs should also be running an approved antivirus software program and should have the same security patches on their home system that are in place on the network.

A software-based personal firewall would also be useful for dial-up users to have. It may not need to be a requirement, but a program such as BlackICE Defender or ZoneAlarm from Zone Labs should provide ample protection for a dial-up user.

Finally, if possible the machine being used to connect to the corporate network should be a single use machine, or at least a machine used by one person. More households have multiple computers in the house, and with prices for fairly powerful home computers in the $700 price range, it is not an unreasonable request. A machine used by one person, who knows that the machine will be connecting into the corporate network, will be less likely to have viruses and worms that can be spread through the corporate network.

These steps will help bring remote machines into compliance with the security standards of the organization that, combined with the encryption discussed in later in this chapter, should make remote dial-up users as secure as the rest of the network, regardless of where they are connecting from.

   


The Practice of Network Security. Deployment Strategies for Production Environments
The Practice of Network Security: Deployment Strategies for Production Environments
ISBN: 0130462233
EAN: 2147483647
Year: 2002
Pages: 131
Authors: Allan Liska

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net