Infrastructure security: Remote access DMZ
An excerpt from Chapter 7: Infrastructure security from "How to Cheat at Managing Information Security," by Mark Osborne.
In this excerpt from Chapter 7: Infrastructure Security from How to Cheat at Managing Information Security, author Mark Osborne examines how remote access DMZs can mitigate risks of unsecured remote access endpoints and provides remote access design options network administrators can use to enhance the security of the network's infrastructure .
Many organizations have a legacy dial-in remote access server. This server will need access to a radius-based authentication server (see Figure 7.3). More modern remote access will be enabled by either an SSL or IPsec VPN server, using the ubiquitous Internet. It is good practice to "DMZ" both of these to allow better access control. I'll come right out and say it: Many VPN servers provide lame firewall service and aren't certified to EAL4. Rant over.
Threat Analysis
The threats and countermeasures look something like the list in Table 7.2.
Table 7.2 Threat Analysis of Remote DMZ
| Activity | Threat | Countermeasure |
|---|---|---|
| Public network connectivity | Hacking/unauthorized access through insecure, nonmandated protocols | Firewall |
| Hacking/brute-force attack providing entry via authorized protocols by repeated trial of user ID and password | Strong authentication | |
| Getting access to confidential information | Encryption | |
| Man-in-the-middle attack | Encryption plus strong authentication | |
| Mail inward | Viruses and worms | Optional mail virus scanning |
Remote Access Design Options
Personally, these days I usually run encryption over the PSTN. The local operators in some parts of the world aren't very secure and run it through IP over the Internet, so it makes sense. To achieve this goal, a direct connection into the VPN concentrator from the access server is required.Typically, a port on the same virtual LAN (VLAN) or a new VLAN and an extra network interface card (NIC) in the concentrator will do it.
For strong authentication, I am particularly fond of the one-time password generators, so you should consider deploying:
- Cryptocard
- RSA SecuriD
- Vasco token -- Digipass
These can be used with the PSTN, SSL VPN, or IPsec VPN. They should speak "radius" as a native tongue so they require no further integration.
As a one-time evangelist of PKI, I should recommend digital certificates, but I'm not, simply because they are too difficult to manage for a typical medium-sized organization. (Please note that I'm not suggesting that risk/threat is a function of size only; capital expenditure and head count to maintain large infrastructure often are. Many investment banks are "medium-sized" but need and use Rolls Royce countermeasures.) @24566
If you are dying to use an integrated firewall appliance, this is your chance. As mentioned before, many of them have virus capability, and extra virus scanning of your remote access connection is a useful addition. Many of them can also speak SSL-VPN and IPsec-VPN, so you can end up with all the functionality in one box. That has to be good for the flexible enterprise. But please make sure that virus scanning occurs on the decrypted VPN stream. Use the dummy virus EICAR to check.
Lastly, and as mentioned earlier in this chapter, it would be good to have IDS included. As an old fossil, I would not jump at the chance to integrate IDS into an appliance. An IDS is a detective control, and therefore I like it to have complete separation (in other words, segregation of duties).
Want more from Chapter 7: Infrastructure Security? Download the full chapter.
Reprinted with permission. Copyright Syngress Publishing © 2006.
