Windows Foundation
Threats from the Trenches
You're no security expert, but you should keep an eye on your perimeter network. Implementing intrusion detection and antivirus measures can help.
- By Bill Heldman
- 08/01/2002
Last month's article talked about formulating the beginnings of a quality
perimeter network: NAT-ting, a firewall and Web-filtering software. This
month we take your perimeter network to the next level and discuss important
topics such as intrusion detection, your DMZ and antivirus software for
the perimeter.
Intrusion Detection
So far, you're doing fine. You've got a reserved network address
implemented. Your router is NAT-ting and you've set up a firewall server.
You've also installed a Web filtering server so that you can keep users
from hitting the bad sites.
One day you're startled to find that users cannot get out onto the Internet,
nor can they receive Internet e-mail documents. All servers and routers
seem to be working, but the Internet just is not accessible. What could
be happening?
Could be a Denial of Service (DoS) attack or similar intrusion attempt.
The DoS attack can be a real pain for administrators because it's so simple
that an elementary hacker could set one off (and they do frequently).
All you do is simply send thousands of PINGs to a known IP address. The
server gets so busy answering the PINGs that it cannot do anything else,
bringing the server to its knees.
This is only one kind of intrusion attempt—there are hundreds of
others. To stop this kind of thing, you need intrusion detection software.
Microsoft ISA Server comes with a tiny little bit of intrusion detection
software called Real Secure (www.realsecure.com)
written by Internet Security Systems, Inc., but it only filters for a
handful of the more well-known intrusions (such as the UDP bomb, DoS and
others). It's possible for you to set up a complete intrusion detection
server to watch for such intrusion attacks by either purchasing the full-blown
Real Secure client for your ISA server or opting to set up a standalone
intrusion detection server. Figure 1 shows such a setup.
|
Figure 1. A private network with an intrusion
detection server. |
We've got the perimeter network built and if it's well-managed (i.e.
you've gotten the training you need to be able to configure and manage
the software and you're given the time to properly set things up) your
internal network is, for the most part, safe.
Anti-virus Management
But you shouldn't mop your brow just yet. You have a little bit
more internal work to do. Your servers and workstations should all be:
- Equipped with a good quality anti-virus software package.
- Routinely updating the virus signature file so they know about the
latest and greatest viruses.
- Updating their scan engine versions as new ones come out.
- Actively scanning for, detecting and eradicating viruses.
It's easy to set up a perimeter network; it's much more difficult to
make sure that you're actively managing the anti-virus software on your
users' computers and your servers. I've had junior admins ask me if all
servers should be equipped with antivirus software. I tell them that as
a general rule of thumb, if human beings touch the server in any way,
then yes, you need to install server antivirus software. Otherwise, in
the interest of cost savings only, I think you're fine to not go ahead
and install the software.
Is anti-virus management considered a part of the perimeter? Well, indirectly
it actually is, because hackers can easily send viruses through e-mail
attachments, which in turn are easily able to enter your network and get
onto user's workstations. And we're all aware of the work that hackers
do to try to exploit Microsoft's other software offerings, finding vulnerabilities
in the code that would allow them in the door. So by proactively scanning
your e-mail servers (along with other servers and workstations), you're
assisting your perimeter in doing its job.
Good
Medicine |
The two big leaders in the anti-virus software niche
are Norton and McAfee, but there are others. Trend Micro
and F-Prot are among the others who offer fine quality
anti-virus packages. All of the companies offer some
sort of automated delivery method for you to assess
the antivirus software health of your network, as well
as push updates to computers.
I've noticed over the years that Norton and McAfee
tend to one-up one another. One year McAfee's offerings,
while fairly strong, aren't backed up by the support
I'd expect. So I'd switch to Norton. The next year Norton
gets a little weak and McAfee jumps ahead of the pack.
Anti-virus software seems to be one of the few places
in the software industry where heavy competitive forces
are at play, thus producing better quality products
for end users.
There are at least two elements you must keep track
of when you're considering antivirus software: the software
engine itself and the signature files that the software
uses to detect viruses. From time to time the scan engine
will be updated by the company and you'll have to figure
out a way to update your user's computers. You have
to go through this process because at some point the
virus signature file will be so far ahead in version
number that it won't be able to be used by the older
software.
The signature file, called the "DAT" file by some software
vendors, is, at a minimum, a weekly offering put out
by the software manufacturer. Most of today's anti-virus
software can automatically download the latest signature
file, or you can point all users to a server where you
keep the latest and greatest signature file downloads.
The trick to good quality anti-virus management is
to make sure that all workstations and servers are updated
to the latest and greatest scan engines and signature
files on a routine basis (always testing first before
implementing in production, of course).
[For a review of anti-virus solutions, see "Stop
Viruses at the Gate," by Roberta Bragg and
David Tschanz, in the December 2001 issue of MCP Magazine.—Editor]
|
|
|
Finally, there are your Internet servers—those rascals that are
sitting out there ahead of the perimeter network, just waiting to be attacked
by some ne'er-do-well. This area is called the DMZ, a term borrowed from
the warfare term demilitarized zone (don't ask me why it got the name
DMZ; Microsoft tried very hard to call it a "screened subnet", but the
term just doesn't have that satisfying ring, like DMZ, and never caught
on).
|
Figure 2. A private network behind a perimeter
net with the DMZ out front. |
Figure 2 shows the DMZ sitting out ahead of your perimeter. The DMZ is
connected to another port on the router, but this doesn't necessarily
have to be the way the DMZ is set up. DMZ servers typically have a different
TCP/IP subnet than their nice, warm, safe internal cousins—a network address
that cannot be reserved, unless the DMZ servers are behind a NAT device.
A
Must-Take Exam for MCSEs |
Exam 70-221, Designing a Windows 2000 Network
Infrastructure, deals quite a bit with the DMZ and how
you can use Windows 2000 servers to help you out with
the problem of protecting your DMZ servers, including
acting as a NAT for the DMZ and providing one-way read-only
DNS addressing. You can also set up VPN connections between
your external DMZ servers and internal servers so that
all data traversing from outside to inside and back is
encapsulated and protected.
Of all of the Windows 2000 server tests, I think that
70-221 is one of the most valuable because it really
drives home how you can leverage the powers of Windows
2000 servers that you might not have considered had
you not read about them. The 70-221 test should be a
must for administrators that really want to understand
their networks.
|
|
|
So, how to you protect a DMZ? Well, first of all your Web servers should
be designed in such a way that they don't contain sensitive information
(such as resumes, credit card information, internal usernames and IP addresses,
etc.) and they should be clustered so that if one is attacked, the site
can stay up. Name-server services, in the form of DNS, can be set up in
such a way that even if it is hacked, the only things the hacker will
get are the addresses and names of the DMZ computers.
But even more important, most companies put a firewall and router ahead
of their DMZ (see Figure 3). This forward firewall is less hardened off
than the rear firewall, meaning that it might not prohibit things that
the rear firewall will. For example, your rear firewall probably won't
allow any incoming HTTP port 80 at all, whereas the forward firewall will
have to allow the port to be open.
In figure 3, we've purchased a second router and hooked it to our DMZ.
The forwarding addresses in our ISP's router are set for different router
addresses, depending on the protocol (SMTP 25 goes to the internal network's
router, HTTP 80 goes to the DMZ's). The two company routers are hooked
to one another so that VPN traffic can be set up. This is a complicated
setup; there are more simple ones, but you can see that we're making every
effort to isolate the DMZ from our internal network traffic.
|
Figure 3. A well-protected DMZ. |
Some companies simply host all Web pages on their ISP servers and reduce
the possibility of being internally hacked by a large degree. However,
that solution could be cost-prohibitive for some companies.
The idea behind the perimeter network and DMZ is to prevent external
users from getting into the private network by utilizing unauthorized
protocols or methods. You also want to keep internal users from getting
to Internet sites they're not supposed to go to. By thoroughly understanding
the components involved in your perimeter network and DMZ, then carefully
implementing them and testing them and finally managing them well on a
daily basis, you'll go a long way toward a much more secure group of users.