D-Link DFL-2500 - Manual (Page 230)

• Protecting mobile and home computers
• Restricting access through the VPN to needed services only, since mobile computers are
vulnerable
• Creating DMZs for services that need to be shared with other companies through VPNs
• Adapting VPN access policies for different groups of users
• Creating key distribution policies
A common misconception is that VPN-connections are equivalents to the internal network from a
security standpoint and that they can be connected directly to it with no further precautions. It is
important to remember that although the VPN-connection itself may be secure, the total level of
security is only as high as the security of the tunnel endpoints.
It is becoming increasingly common for users on the move to connect directly to their company's
network via VPN from their laptops. However, the laptop itself is often not protected. In other
words, an intruder can gain access to the protected network through an unprotected laptop and
already-opened VPN connections.
A VPN connection should never be regarded as an integral part of a protected network. The VPN
firewall should instead be located in a special DMZ or outside a firewall dedicated to this task. By
doing this, you can restrict which services can be accessed via VPN and modem and ensure that
these services are well protected against intruders. In instances where the firewall features an
integrated VPN feature, it is usually possible to dictate the types of communication permitted. The
NetDefendOS VPN module features such a facility.
9.1.4. Key Distribution
Key distribution schemes are best planned in advance. Issues that need to be addressed include:
• How will keys be distributed? Email is not good. Phone conversations might be secure enough.
• How many different keys should be used? One key per user? One per group of users? One per
LAN-to-LAN connection? One key for all users and one key for all LAN-to-LAN connections?
It is probably better using more keys than is necessary today since it will be easier to adjust
access per user (group) in the future.
• Should the keys be changed? If so, how often? In cases where keys are shared by multiple users,
you may want to consider overlapping schemes, so that the old keys work for a short period of
time when new keys have been issued.
• What happens when an employee in possession of a key leaves the company? If several users are
using the same key, it should be changed.
• In cases where the key is not directly programmed into a network unit, such as a VPN firewall,
how should the key be stored? On a floppy? As a pass phrase to memorize? On a smart card? If
it is a physical token, how should it be handled?
9.1.4. Key Distribution Chapter 9. VPN
230