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
• August 01, 2002

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.

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.

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.