D-Link DFL-260 Product Manual - Page 379
Key Distribution, 9.1.5. The TLS Alternative for VPN, Endpoint Security, Placement in a DMZ
UPC - 790069296802
View all D-Link DFL-260 manuals
Add to My Manuals
Save this manual to your list of manuals |
Page 379 highlights
9.1.4. Key Distribution Chapter 9. VPN • 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. Endpoint Security 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. Placement in a DMZ 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, the administrator can restrict which services can be accessed via the VPN 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 and NetDefendOS VPN has this feature. 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 a good solution. 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 they are changed, 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.5. The TLS Alternative for VPN If secure access by clients to web servers using HTTP is the scenario under consideration, then using a NetDefend Firewall for TLS termination can offer an alternative "lightweight" VPN approach that is quickly and easily implemented. This topic is described further in Section 6.2.10, 379