In-Depth
Private and Secure: The VPN Solution
If you want a better way to connect remote users, offices and servers securely,
consider the humble, easy-to-implement virtual private network. Here’s how to
make it work in Windows 2000.
Recently, we had a “snowstorm” (in Texas, that means the temperature dropped below
50 degrees), and many of our employees decided to work from home. The ability
to access all of our LAN resources with our laptop machines really helped productivity.
Similarly, you can use a VPN to allow your remote users and branch offices easily
and securely to connect to your LAN. Better yet, the cost savings may be dramatic,
and you can set up a basic VPN in just a few hours! In this article I share how
to do so in Windows 2000.
What Is a VPN?
A VPN, or virtual private network, allows you to transfer information
securely over a potentially insecure network. VPN connections generally
manage authentication between servers and clients and handle data
encryption for the connection. However, you can implement a VPN
in many different ways—using several types of protocols and standards.
But why would you want a VPN in the first place? Several years
ago this might have been a tougher sell. Dial-in solutions may have
met your users’ needs and leased lines let you connect your remote
offices. For example, you might have set up a bank of modems to
which your remote users could dial in from home or while on the
road. Of course, if you’ve used those solutions, you know about
their shortcomings:
- Difficult administration. Modem banks and leased network
links often come with a large amount of administration overhead.
For example, analog modem banks generally use proprietary technology.
- High costs. Leased lines are generally much more expensive
than Internet connections, and they can be difficult to implement
and administer. For dial-in solutions, serial port concentrators
and analog modem ports are also expensive. Also, CFOs rarely like
to see the amount of money spent on long-distance charges or 800-number
dial-ins.
- Limited support for technology. If your organization
only supports dial-up connections via analog modems, users with
faster connections (such as cable modems or xDSL solutions) will
be stuck in the slow lane when it comes to connecting to your
LAN. Just because it’s called a cable “modem” doesn’t mean it
can connect back to your analog modem bank!
- Inconvenience. In order to use dial-in solutions, users
have to configure their modems and operating systems to make remote
connections. For analog modems, each connection can take more
than 30 seconds (a time that many users find unacceptable). Plus,
there’s the possibility of reaching busy signals at peak times.
- Hardware failure. Oftentimes, individual analog modems
just plain blow up. This can be a nightmare if they’re heavily
used and/or depended upon.
These problems tend to be large and costly. However, new network
technologies often depend on better connectivity between your machines.
For example, Win2K’s Active Directory requires connectivity between
all of your domain controllers in order to work optimally. Although
you could connect all of your branch offices and remote locations
with dedicated leased lines (such as T1 connections), this can be
prohibitively costly and difficult to set up. There must be a better
way!
Fortunately, VPNs alleviate many of these obstacles. However, you’ll
still need to address other issues about using the Internet for
secure data communications, including security, reliability, scalability
and performance. Let’s look at how you might want to design and
deploy a VPN for your environment.
Making the Connection
The purpose of a VPN is to secure your network communications across
another network. There are two broad categories of VPN connections,
often referred to as “tunneling” mechanisms:
- Voluntary tunneling. Remote access users generally create
voluntary tunnels directly with a VPN server. This case is best
illustrated by a notebook computer user who already has an Internet
connection, say, via cable modem or dial-in to a local ISP. The
user simply “dials up” a VPN server via the Internet to create
a secure, encrypted connection. The VPN isn’t actually dialing,
but, indeed, this is how it appears to the user.
- Compulsory tunneling. You may want to implement the features
of a VPN transparently for your users. Compulsory tunnels are
often set up between two VPN servers that act as routers for all
network traffic. As with switching or routing, clients may not
even be aware that their data is traversing a secure, encrypted
connection. This type of tunnel is useful for connecting a central
office to remote offices, each with its own network. Compulsory
tunnels can also be created in an outsourced fashion by which
an ISP handles all data encryption between its Points of Presence
(POPs). Clients and servers simply “dial in” to this network as
they normally would, and the ISP handles the rest.
Figure 1 shows the voluntary and compulsory tunneling scenarios.
Both types of VPN connections can be used in various ways.
 |
| Figure 1. A comparison of compulsory
and voluntary VPN tunnels. Voluntary tunnels are created between
a client and a server, whereas compulsory tunnels are created
between two servers that act as secure routers. (Click image
to view larger version.) |
A Typical VPN Scenario
When considering the implementation of any technology, it’s important
to consider the real goals of a VPN solution. Let’s look at a simplified
example of some situations where a VPN might be useful.
Here’s a classic situation: You’re supporting a distributed company.
For the most part, your servers and most of your users are located
in a central office. However, you have several users working out
of remote offices. Some of these “offices” consist of only one sales
representative while others may have hundreds of employees. You
need to offer all of your users connectivity to the network, but
the cost of licensing leased lines for each of them is expensive.
In this case, a VPN could reduce costs and make the job quite easy.
A simple solution might involve four broad steps.
First, obtain Internet access for each of the remote offices. These
connections can range in speed from dial-ups (for locations that
support few users or that may require access to only corporate messaging
systems or an intranet) to much faster connections such as T1 lines
(operating at about 1.544 Mbps). Remote users can use any form of
Internet connectivity, including analog dial-up lines (everyone’s
favorite!), ISDN, xDSL and cable modems.
Second, set up a VPN server at your central office. This sets the
stage for others to join your party.
Third, for larger offices, implement a VPN server at the remote
office. Configure this machine to create a server-to-server VPN
connection between your main office and your branch office (in Win2K,
this could be a persistent connection or one created on demand).
The benefit is that your users don’t need to be aware that they’re
using a VPN connection. It’s all handled at the network level. This
is a good example of a compulsory tunnel. You may want to use a
persistent connection if you’re on an “all-you-can-eat” plan with
your ISP. Choose an on-demand connection if you’re on a “pay-as-you-go”
plan with your ISP and wish to save some money.
Fourth, for smaller offices and for traveling or remote users,
you might choose to have your users directly create a connection
with their local VPN server. Provided that they have Internet access,
they can create a VPN connection directly with the central corporate
VPN server or a VPN server closest to them.
When you’re finished with this configuration, you’ll have created
a voluntary tunneling situation. Figure 2 provides a high-level
overview of what such a network might look like. Now, let’s look
at how you implement the VPN.
 |
| Figure 2.
A typical VPN scenario using VPN servers and clients. (Click
image to view larger version.) |
Protocols and Standards
If you’ve given some thought to transferring your sensitive company
data over the Internet, it’s likely that you already know two of
the requirements for VPNs: authentication and data security (encryption).
Here’s where it starts getting confusing. Unlike the situation of
just a few years ago, you can choose from several VPN protocols.
The good news is that these protocols are standards. The bad news
is that you have to understand the strengths and weaknesses of each.
- Point-to-Point Tunneling Protocol. Microsoft and other
industry partners originally introduced PPTP with the release
of Windows NT 4.0 (think way back to August 1996). It currently
has widespread support on all current versions of Windows as well
as some third-party solutions.
- Layer 2 Forwarding. Cisco’s answer to the VPN problem
was its hardware-based L2F protocol. L2F was designed to allow
Cisco routers to form secure connections over the Internet or
other IP-based networks.
- Layer 2 Tunneling Protocol. Developed as the best parts
of both PPTP and L2F, L2TP allows for strong security, protocol
independence and for flexible authentication mechanisms.
- Internet Protocol Security. The next version of TCP/IP,
IPv6, will support a mechanism for securely transferring data.
The IPSec standard defines methods for communicating between servers
and clients, but it lacks standard support for authentication
mechanisms. Furthermore, IPSec can be difficult to configure for
simple client-side access and is currently used mainly for server-to-server
connections. However, look for IPSec to become increasingly common
as the standards continue to mature. [Read Roberta Bragg’s
two-part “Security Advisor” series on IPSec in the March and April
issues.—Ed.]
But wait, there’s more! You can use a combination of L2TP and IPSec
to get the best of both worlds (authentication support and strong
security, respectively). And some VPN servers (such as Win2K) support
the use of multiple VPN protocols at the same time. For example,
some clients can connect using PPTP, while others connect using
IPSec. A complete, in-depth analysis of these protocols is outside
the scope of this article (this magazine would get pretty heavy
if we started discussing packet structure). However, Table 1 provides
an overview of the various features of each protocol.
If you need compatibility with various Windows-based clients, PPTP
is a good basic choice. It’s important to remember that if you create
a “compulsory tunneling” VPN, client and server support may be a
non-issue. That is, since the VPN servers act as routers and handle
encryption and authentication for all data, the clients on your
network need not even know this is happening (read: no reconfiguring
desktop machines on your internal network!). Windows servers can
support up to 256 logical VPN connections. NT Workstation and Win2K
Professional only allow a single inbound VPN connection at a time.
As shown in Table 1, you now have several choices when determining
what protocols to support in your environment.
| Table 1. Comparing features
of VPN protocols. |
| Protocol
|
IETF
RFC # (see www.ietf.org) |
Windows
server-side support |
Windows
client-side support |
Pros |
Cons |
| PPTP |
2637 |
NT 4.0, Win2K |
Windows 9x/ME/NT 4.0/2000 |
Most compatible; quick to set up;
easy to implement and administer |
Not the most secure |
| L2F |
N/A |
None - hardware solution |
N/A (encryption is handled at the
network level, transparent to clients) |
Can be set up without client reconfiguration
|
Hardware-only solution; supports IP
traffic only |
| L2TP |
2661 |
Win2K |
Win2K |
Protocol-independent; includes authentication
mechanisms |
Supported only on Win2K clients |
| IPSec |
2401 - 2409 |
Win2K |
Win2K |
Provides strongest security; part
of IPv6 specification; potential cross-platform support |
Most difficult to set up; lack of
complete interoperability between vendors |
| L2TP/ IPSec |
See RFCs for L2TP and IPSec |
Win2K |
Win2K |
Provides strong security (IPSec) plus
authentication mechanisms (L2TP) |
Difficult to set up |
In general, I’d recommend starting with PPTP (if you need to support
non-Win2K clients) or L2TP (if you’re a pure Win2K shop). Both protocols
are quick and easy to set up using wizards, and client configuration
is simple. If your environment needs more security (at the expense
of ease of administration), look into an L2TP/IPSec solution. You’ll
get stronger security for data transfers plus L2TP’s authentication
mechanisms. Beware that setting up IPSec can be challenging—so be
sure to do your homework and make sure it’s worth the effort for
your business.
Implementing Your VPN
OK, so we’ve looked at some of the choices you need to make when
planning for a VPN and examined a few possible connection scenarios.
The next step, of course, would be to implement the solution. In
the remainder of the article, I provide a quick overview for setting
up a simple PPTP-based VPN using Win2K Server and Professional machines.
The overall process is quick and easy. (I often set up clients and
servers in my presentations in less than 10 minutes.)
Set Up the Server
Obviously, you must begin with a machine that meets the minimum
system requirements for Win2K Server. In addition, your machine
must have two physical network connections: one with a network connection
to your LAN and another with a connection to the Internet. The VPN
server will be responsible for routing between the two “networks.”
To start configuring a Win2K VPN server, you’ll need to access
the Routing and Remote Access (RRAS) admin tool. The RRAS admin
tool is used to set up and configure advanced networking features
on your server. If it hasn’t already been configured, you can easily
set up your server to allow VPN connections by right-clicking on
your server name and selecting “Configure and enable routing and
remote access.” You’ll see the handy wizard shown in Figure 3.
 |
| Figure 3. The wizard you use to set up
routing and remote access is available by right-clicking on
your server name in the Routing and Remote Access Administrative
Tool. |
The wizard will walk you through the steps you’ll need to complete
in order to configure your server. Note that if the RRAS server
has already been configured, you’ll no longer be able to use the
convenient wizard interface. Instead, you’ll need to access the
property sheets for the various configuration options.
When you configure your VPN server, there are several decisions
to make. First, you need to choose which protocols you plan to support.
The list will include any protocols currently enabled on the server,
but there’s a good chance you’ll want to use TCP/IP. If you tell
the wizard that not all of the protocols you plan to support are
installed, it kindly tells you to install them and then come back
when you’re really ready. Next, you’ll have to choose an adapter
for your Internet connection. (Remember, it must have separate LAN
and Internet network interfaces.) Generally, the decision will be
easy. The VPN service should be configured to use the server’s Internet
connection. For example, if you have one network adapter that connects
to your LAN and another that connects to a T1 router (which, in
turn, connects to your ISP), you’ll want to configure the VPN server
to listen on the network interface that’s connected to the T1.
With the basic settings out of the way, it’s time to look at configuration
options for the client. The main choice is to determine how clients
will receive their IP addresses. You have two methods. First, you
can use the Dynamic Host Configuration Protocol (DHCP) to assign
IP address information. In this case, you can use a DHCP server
that has already been configured on the network, or you can set
up the local server to act as a DHCP server. One important consideration
is that you must make sure that remote clients will have access
to the DHCP server. That is, if your VPN server is sitting on a
different subnet from the DHCP server, you may need to configure
a DHCP Relay Agent or reconfigure your routers to allow BOOTP broadcasts.
If you need help in making the necessary choices, be sure to refer
to the resources in “Additional Information.”
The simpler (though more-difficult-to-administer) solution is to
create a static set of IP addresses. The VPN server will simply
choose addresses from this pool and assign them to clients. Once
you make this decision, all that’s left to do is click on Finish
to configure the VPN server.
Once the basic options for a VPN server have been configured, you’ll
see several changes to the Routing and Remote Access administrator
tool. First, you’ll be able to expand the local server and see configuration
options. For the purpose of VPNs, the most relevant is the presence
of new “Ports” (see Figure 4).
 |
| Figure 4. Viewing logical ports configured
for the VPN service in the Routing and Remote Access administrative
tool. |
The Ports container holds one item for each logical port you have
configured on this server. By default, the wizard creates multiple
“WAN Miniports” (for both PPTP and L2TP connections). Additionally,
you’ll see any other ports (such as modems or the ever-popular direct
cable connection) that you might have configured on this machine.
To monitor a port, you simply right-click on one and choose the
“Status” option. This provides you with details about the usage
statistics of a connection. Remember that the total number of logical
ports you have configured will be the maximum number of simultaneous
connections your server will allow.
Other areas of interest in the RRAS admin tool include the following:
- Routing Interfaces. This section will provide one item
for every available network interface on the machine. If you’ve
enabled routing for any of these interfaces, you can view details
about the configuration by right-clicking on one of the items
and choosing Properties. The details of configuring routing are
beyond the scope of this article, so if you need help, be sure
to check out the RRAS help file.
- Remote Access Clients. This section shows you all of
the people that are currently connected to your remote access
server (including VPN connections). From here, you can easily
identify who’s connected, how long they’ve been connected and
how much data they’ve transferred. You can also drop stuck connections
from here.
- IP Routing. If you’re configuring static or dynamic routing,
this is the place for you to configure the RRAS service and to
create your route assignments. Note that you can also configure
the DHCP Relay Agent here. Again, the details of routing are beyond
the scope of this article.
- Remote Access Policies. This useful icon lets you configure
various security options for remote users. For example, by default,
there’s a master switch for whether or not you allow users to
connect to this remote access server. The specific options will
vary based on whether or not the VPN server is the member of an
Active Directory domain.
- Remote Access Logging. This is a very useful option for
tracking the action that your VPN server is seeing. By viewing
the properties of the log file settings, you can specify exactly
what types of actions are logged and where the log file is stored.
This is handy when you’re troubleshooting connectivity or trying
to get a better handle on the usage of your VPN servers.
Finally, you can right-click on the name of your local server and
select Properties to view the main configuration information about
this machine. Figure 5 shows the General tab from which you can
configure the “master switch” for VPNs.
 |
| Figure 5. Viewing the General properties
of a RRAS server using the RRAS administrative tool. |
If, for example, you want to disable all VPN-based access to this
server temporarily without losing your configuration, simply uncheck
the “Remote access server” box. As you can see, the RRAS admin is
“command central” for managing your VPN, and it will become your
best friend when you need to monitor and troubleshoot VPN issues.
Increase Server Security
Invariably, when discussing VPNs and tunneling over the Internet,
the most common concerns I hear involve security. Fortunately, you
have several additional options for increasing the security of your
VPN solution. The list of features includes:
- Active Directory-based security. VPNs may be relatively new
technology, but the same basic rules regarding user accounts and
security still apply. Your best bet in a Win2K environment is
to take advantage of the features of AD for ensuring only authorized
users can get to your network. So, don’t forget about good password
policies and account policies—there’s little administrative cost,
and you’ll get a lot of additional security.
- Remote Authentication Dial-In User Services support.
RADIUS allows multiple remote access servers (such as a VPN server)
to communicate information about connected users. It’s important
because it lets you manage your remote access user accounts centrally
and allows for centralized logging of remote access connection
information. Consider investing in RADIUS-based solutions when
you’re supporting a large number of remote users (hundreds of
concurrent connections), when you have multiple remote access
servers and when centralized management is worthwhile.
- Authentication mechanisms. In addition to standard password-based
security, you can take advantage of biometric devices, smart-cards,
and two-factor authentication token cards (such as the SecurID
system from RSA Security Corp.). Also, Win2K can take advantage
of the Extensible Authentication Protocol (EAP), which means it
can tap into other third-party authentication schemes. If you
want to avoid password-based security (and all of the potential
hassles associated with it), consider looking into biometric solutions
(such as fingerprint scanners) and token authentication schemes.
Know, however, that you’ll probably need to absorb some short-term
expenses.
- Group Policy settings. You can use Group Policy settings
(in AD environments) or Local Security Policy settings to restrict
access to your VPN servers. By default, the security settings
are quite liberal—basically, they don’t put very strong restrictions
on user accounts, passwords and auditing. You’ll probably want
to make several configuration changes from the defaults to enforce
stronger passwords. You’ll also want to audit, at the very least,
successful and failed logons and logoffs. It doesn’t take a lot
of effort, and you’ll be able to sleep better at night knowing
that common causes of network intrusion have been reduced.
- Integration with AD. You can administer settings for
remote users from the comfort and security of your AD administration
tools. Furthermore, you can configure AD Sites and Services to
use your VPN connections. Just treat your VPN connection like
you would any other dial-up or standard network connection. If
you plan to change the settings from their defaults, it’s a good
idea to keep in mind the speeds of your underlying Internet connections.
- Network design. A VPN server can be configured to exist
inside, outside or as part of your firewall solution. The most
common solution is to place the VPN server outside the firewall.
For the utmost security, you’ll probably want to ensure that your
VPN server isn’t running any additional services. For example,
you would probably want to disable IIS on that machine. Then,
if the VPN server is compromised, you won’t risk losing any data
stored on that machine.
- Network-level security. Windows-based servers support
packet-filtering of TCP/IP connections. This can be useful for
preventing certain types of traffic from entering your network.
For example, on the public interface of your VPN server, you might
choose to restrict all traffic except data transferred through
the VPN connections. That way, you can avoid common methods of
denial-of-service attacks and prevent issues related to known
vulnerabilities of Web, FTP, mail, telnet and other services.
It’s important to remember that technology is only part of the
solution. Make sure users are educated in the value of strong
passwords and good security practices.
Set Up The Clients
The process used to set up Windows 95/98/Me, NT 4.0 and Win2K clients
is fairly straightforward. However, the exact steps you need to
follow differ somewhat based on which operating system you’re dealing
with. Fortunately, Microsoft has made it easy to set up VPN clients.
Most users could go through the necessary steps in less than 15
minutes or so. Here’s the two-step process to connect clients to
servers:
- Establish Internet access. This may be through a LAN,
broadband or dial-up connection. The point is that the user must
have access to the Internet—it doesn’t matter how.
- Connect to the VPN server. The second step involves “dialing”
another connection to the VPN server. Instead of using a phone
number, however, the connection will use an IP address (or DNS
name, if it’s available) for the server. In Win2K Professional,
you simply set up a standard dial-up connection. Right-click on
the My Network Places icon and choose Properties. Then select,
“Make New Connection.” This will begin the Network Connection
wizard (see Figure 6).
 |
| Figure 6. Using the Network Connection
wizard to create a VPN connection. |
Choose the option to “Connect to a private network through the
Internet.” You’ll be prompted for the IP address or DNS name of
the remote VPN server. You’ll also have the option of first connecting
to the Internet via another network connection before creating the
VPN connection. This is especially useful if your clients will be
using dial-up Internet connections since it allows single-click
access to your VPN. When the connection has been created, you should
be able to “dial” it like any other. Note that this new form of
connectivity doesn’t come for free — there’s also a potential security
risk. For details, see “Mitigating Security Risks.”
Test the VPN
OK, so far you’ve set up the VPN clients and servers. Now, it’s
time to test the solution to make sure it works properly. Fortunately,
this should be pretty easy to do. The first step would be to try
to connect to your server from a client machine located across the
Internet (that is, not on your LAN). If the connection doesn’t succeed
at first, you need to determine whether the problem comes from the
client side or the server side. The easiest way to determine this
might be to test the creation of a VPN connection on your LAN. Connect
both the client and server to the same subnet and see if they can
connect to each other that way. If they can, then the problem might
be related to a connectivity issue (such as a firewall that’s in
the way, which I’ll discuss shortly).
If you’re unable to create a VPN connection between your machines
when they’re connected to the same LAN, then it’s time to verify
the configuration. If the client can connect to the VPN server,
but can’t access some (or all) network resources, then check to
see if they have the appropriate network configuration (this is
most easily done by running IPCONFIG from the command line). If
the network configuration looks good, put on your standard TCP/IP
troubleshooting hat. First, find out if the issues are related to
name resolution. That is, does connecting via IP addresses work
while connecting by machine- or DNS-name fail? If so, make sure
your DNS (and WINS, if you support it) configuration is working
properly. Remember that clients can resolve some names via broadcasts,
even without the proper name resolution set up on a LAN. But when
working over a VPN connection, your organization’s routers may not
allow broadcasts to be transferred between subnets. Also, be sure
to verify that your users have appropriate permissions to log on
to the VPN server and access specific network resources.
Still stuck? Read on for more information on troubleshooting...
Tips, Tricks, Troubleshooting and Gotchas
Remember, your VPN server must be accessible to users from the Internet.
It’s often advisable to create a public DNS entry for your VPN server
so users can connect to a server such as “vpn.mycompany.com.” Some
may see this as a potential security problem, but remember that
you’re creating a DNS entry for an IP address that’s already publicly
available (that is, in general, “security through obscurity” isn’t
a good practice). Here’s a common issue: You’ve set up your VPN
client and server properly, but they’re still unable to connect
with each other. Or, more commonly, you can create a VPN connection
on your LAN, but clients from outside the network can’t connect.
The issue may have to do with network-level security. Technically,
you can configure a VPN server to be inside, outside or part of
your firewall. There are several different considerations that might
make you choose one idea over the other. Regardless, your firewall
must allow the passage of VPN information between clients and servers.
Table 2 provides a brief summary of the types of traffic you’ll
need to permit for use with each type of VPN protocol.
Table 2. Firewall configuration requirements for
VPN protocols.
|
| Protocol |
Communication methods |
Notes |
| PPTP |
TCP Port 1723;
IP Protocol 47 |
Both types of traffic must be allowed
for a successful connection. |
| L2TP |
UDP Port 1701 |
The port number can be reconfigured.
|
| L2TP/IPSec |
UDP Port 500;
IP Protocol 50 |
Port numbers and assignments can
vary among different implementations. The exact details related
to configuring your firewall will vary depending on your firewall
implementation. |
Remember that even basic routers can provide some functionality
of firewalls (such as port- and packet-filtering). However, the
basics are pretty much the same. The bottom line is that your VPN
clients and servers must be able to communicate using the appropriate
IP ports and protocols, or you won’t be able to create the connection.
| Additional
Information |
|
Mitigating Risks
Although, in general, network connectivity for remote and
traveling users is a good thing, it comes with risks. Remember
that when you create a connection to your LAN resources using
a VPN, you’re opening up a whole new avenue onto your network.
That is, if someone were to compromise the security of your
VPN client, he or she might be able to use that information
to access your company’s network. A simple setting like a
cached password or a machine that has been left logged-on
can provide potential hackers with the opportunity they need.
Fortunately, several solutions are available. Personal firewalls
are an important feature that can greatly reduce the chances
of network-based attacks against your home-based and remote
users. It’s so important, in fact, that Microsoft is building
this technology into its upcoming Windows XP products.
For current clients, solutions such as Zone Labs’ ZoneAlarm
(www.zonealarm.com)
might do the trick. Another potential solution might be to
use a device that performs Network Address Translation (NAT)
functionality, such as products from Linksys (www.linksys.com).
Not only do these devices allow you to share a single Internet
connection with multiple machines, but they also provide a
reasonable level of security by reducing the exposure of your
internal network to the Internet.
As well, it’s important to find and understand your vulnerabilities.
A good way is to use the ShieldsUp! Web-based test (which
can be performed from www.grc.com)
to check potential vulnerabilities of your VPN clients by
scanning for open and responding ports and looking for shared
resources.
Finally, no security plan is complete without laying down
(and enforcing) the rules. Be sure your users understand the
importance of strong passwords. And, don’t trust that they’re
creating them—use password-cracking tools to enforce the quality
of passwords. Also, be sure your users understand the potential
risks of sharing passwords (or even sharing machines, such
as laptops, which may contain cached passwords). All of these
measures are vital to keeping your network virtually private!
More Resources
|
Virtually Private, at Last
If you’ve been able to hang with me so far, there’s a good chance
that you know pretty much everything you need to get started implementing
a VPN. Once you’ve done it a few times, you’ll be able to configure
a VPN client and server in less than 10 minutes. It’s likely that
you’ll need to monitor and enhance security and performance based
on the needs of your organization. However, pitching VPNs to your
management should be a quick and easy sell (think quick ROI, low
TCO) as well as a great benefit for system administrators and users
alike. May your sensitive information always remain private and
secure!