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.

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.

Alt text here
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).

Private Network behind the perimeter
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.

A well-protected DMZ
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.

Featured