By Brien M. Posey
Your private network and the data that resides on it is one of your organization’s most valuable assets. As such, it makes sense to defend it against those in the outside world who would do it harm. Nearly every network is protected by a firewall these days. However, perimeter defense goes way beyond simply installing a firewall. There are many ways that outsiders can cross your network perimeter. I’ll show you some of the different techniques that hackers can use to penetrate your network’s perimeter. I’ll also explain what you can do to eliminate, or at least reduce, these potential vulnerabilities.

Firewalls
Of course, the first thing people tend to think of in network perimeter defense is a firewall. Many of the newer firewalls are preconfigured. Simply plug them in, enter some basic IP address information, and you’re good to go. But while an out-of-the box firewall configuration may provide a basic level of perimeter security, you can do much better with a custom configuration.

Disable unused ports
Although you’ve probably heard this a million times, the first thing you should do is to disable all TCP and UDP ports that aren’t absolutely necessary through your firewall —especially ports 135, 137, 139, and 445. An ideal arrangement would be to enable only TCP ports 80 and 443, but your own individual business needs may require you to open more ports. For example, it’s probably necessary for you to open ports 110 and 25, the ports associated with POP3 and SMTP, to have e-mail.

Once you’ve covered the basics of disabling any unused ports, I recommend going back through and disabling outbound traffic on all ports that aren’t absolutely necessary. It’s easy to think of a firewall as a device for keeping outside users out of your network. However, it’s just as important to keep certain types of traffic from leaving your network.

For example, suppose someone was able to plant a Trojan horse on your network. Now, imagine that the Trojan’s job was to launch a denial-of-service attack against a competitor. When the Trojan activated, you probably wouldn’t know anything about the attack until it was too late. However, it would be possible to trace the attack to your IP address, and you’d have some serious explaining to do. If, on the other hand, you had blocked all but a few key outbound ports, then the attack would probably never have happened because the outbound packets used in the attack would have been stopped by your firewall—assuming that the attack wasn’t using one of the key ports you left open.

Port scans
One way of identifying exactly how well your firewall is functioning is to do a port scan. A port scan is a technique by which an outside system systematically attempts to see if any TCP or UDP ports on your network are listening (open). There are many types of port scans, ranging from the very simple to the very complex. An easy and effective one is Steve Gibson’s ShieldsUp!! test.

Remote access servers
Once you’ve secured your firewall(s), turn your attention to your remote access servers. There are many techniques for securing remote access servers. Some of the most common techniques include requiring callbacks to preset numbers, recording caller ID information to log files, denying dial-up access to everyone except those who have a legitimate business need for it, and limiting the times and days when employees can dial in.

Rogue modems
In most organizations, the firewalls and remote access servers are the main perimeter access points. However, there are other perimeter holes that you might not have thought about. Any PC with a modem could potentially act as a remote access server. Ideally, you should know from your hardware inventory which PCs on your network have modems and how those modems are configured. At every network administration job I’ve ever had, I’ve discovered at least one unauthorized modem. Unauthorized modems represent a serious security risk. Basically, if you don’t know that a modem exists, you can’t control how it’s used.

There are a couple of ways of spotting rogue modems. One technique involves maintaining an automated hardware inventory. The inventory software can send you an e-mail message when hardware changes occur.

Another technique that works well is to maintain a list of every telephone number that the company owns. You can then configure a PC to call every single number (preferably late at night) to search for rogue modems. Bear in mind that I’ve also known of hackers using this technique to call every number in a company to look for modems.

In the early 1990s, I worked for a company where each phone number began with 580. The IT security team frequently encountered incidents in which someone would attempt to call all 10,000 numbers in the 580 exchange within a relatively short period of time. As you can see, it’s of the utmost importance for you to discover all of the modems on the network before a hacker does.

Wireless access points
Still another way that intruders can get past your perimeter is by going through a wireless access point (WAP). WAPs present a special challenge because an intruder can access your network through one without ever having to pass through a firewall or a remote access server. Fortunately, there are several things you can do to guard against wireless intrusions.

First, be sure to enable WEP encryption. There are several flavors of WEP available. Just about every wireless access point made in the last year supports 128-bit WEP encryption. Some of the newer devices support up to 152-bit WEP encryption. Therefore, use the highest level of WEP encryption you can. Remember that you must adhere to the lowest common denominator. For example, it does you no good to implement 152-bit encryption if your wireless client’s NIC cards support only 128-bit encryption.

Some other wireless defense techniques include defining which clients are allowed to use the access point. Not all access points support this, but many allow you to define clients by MAC address. If a client’s MAC address isn’t on the list of approved addresses, that client will be denied access.

A more controversial wireless defense technique is to disable DHCP for your wireless clients. By doing so, you can ensure that your access point won’t be handing out IP addresses to wireless hackers. Usually, an access point won’t distribute IP addresses unless the client requesting the address knows the WEP pass phrase.

However, using static IP addresses for legitimate wireless clients offers one more way that you can make a hacker’s job just a little more difficult. It also makes it a bit easier for you to spot an intruder since an intruder would have to take a guess as to what IP address to use, and would likely have to use an address that’s different from the static addresses you’ve assigned.

Before wireless networking became so popular, a close friend was running a wireless network in his office. Since he ran a small business with fewer than 10 employees, he didn’t see the need for WEP encryption. However, over time, he began noticing that his bandwidth wasn’t what it should be. After doing some investigating, my friend discovered that the company across the hall had installed wireless NICs into all of its machines and as sponging off my friend’s Internet connection. The lesson here is that even if you aren’t worried about someone stealing your data or hacking your network, it’s still a good idea to implement WEP encryption to prevent outsiders from stealing your bandwidth. Whatever their motivation, you don’t want outsiders on your network.

Extranets
Extranets represent yet another hole in your network’s perimeter. An extranet is a Web site that is designed to allow users from outside the company to connect to resources on your private network. An example of an extranet would be an Internet banking system. Your account information exists within a database on the bank’s private network, but it’s made available to you over the Web after you enter the necessary credentials.

There are a couple of things you can do to make extranets more secure. First, if possible, configure IIS to use only NTLM security for the extranet Web site. Remember, though, that you can only use NTLM security with Windows clients. If you have other clients, such as Linux or Macintosh clients, you must use either basic or anonymous authentication. Basic authentication transmits the logon credentials in clear text, while anonymous authentication doesn’t require the end user to enter any logon credentials at all.

In the case of an extranet, I recommend using basic authentication, assuming that NTLM isn’t an option. Anonymous authentication would be acceptable if all of the extranet data is accessible to the world. For example, a car dealership might have a Web site that shows the current vehicle inventory. Since no one can do anything but view the inventory and there’s no reason to block anyone from doing so, there’s no reason to use anything beyond anonymous authentication.

For those whose only choice is basic authentication, there remains the problem of authentication information being transmitted in clear text form. One thing that you can do to significantly enhance security is to enable SSL just before the user transmits the logon credentials.

Once you’ve secured the authentication process, you’ll need to secure the server itself. Remember that, in an IIS environment, extranet users are users in the same sense as local users and domain users. Even anonymous users still authenticate into the server via the IUSR_servername account. The point is that when outside users access your extranet, you must make sure that they can’t access anything else.

Part of that is done through the Internet Services Manager. However, a frequently overlooked step is to set up NTFS-level security. You should set explicit denies on extranet users for any files or folders that they don’t need to access. Likewise, you should assign extranet users the lowest set of possible permissions for resources that they do need to access.

Setting up an explicit deny for extranet users may seem like overkill at first. After all, you haven’t directly assigned these users rights to anything outside the Web site. However, extranet users are usually included in the Domain Users group. There are several places where Windows depends on the Domain Users group having rights to something, so you don’t want to remove the group. Instead, it’s much easier to create an Extranet Users group and explicitly deny the group access to the various resources.

Other perimeter holes
One last technique for securing your perimeter is to make sure that you aren’t giving anything away. Avoiding the use of wireless DHCP services is one example of this, since you want to avoid giving a hacker an IP address, DHCP server number, and so on. However, the idea of not giving anything away goes way beyond mere IP configuration information.

One of the first things you should do is scrutinize your company’s Web site for anything that a hacker could use to launch an attack. This includes information that could be used for social engineering purposes and information that could aid an actual break-in. For example, it’s not uncommon for Web sites to provide an e-mail address to which users can send messages. You should make sure that none of the e-mail addresses on your Web site belong to accounts with administrative permissions. If you list administrative mailboxes on your Web site, you’ve just given the world the name of an administrator’s account. Sure, you’re not publicizing the fact that the account has administrative privileges, but if hackers really wanted to break into your network, they might start by trying to exploit known account names.

If you use a software-based firewall, such as Microsoft’s ISA Server, then you need to go through the server with a fine-tooth comb looking for weaknesses. It may sound dumb, but I can’t count the number of times that I’ve seen an ISA Server configured to be a domain controller. This is especially common in small companies. Support staffers often find themselves in need of another domain controller. They see the ISA Server as not really doing anything, so why not make it a domain controller?

Remember that the ISA Server is the point that everyone in the world passes through to get to your network from the Internet. Do you really want this server to contain sensitive domain information? The same goes for Web servers and mail servers. Often such servers exist in DMZs that allow them to be accessed through the Web. Don’t make the mistake of making a publicly accessible server a domain controller. Such servers should be isolated from the rest of your network as much as possible.

Safe and sound
Securing your network needn’t be rocket science. It may sound complicated, but if you keep track of the basics, you can go a long way toward ensuring that your network and the data it contains remain safe. Make a checklist of your network’s security to make sure you’ve covered all the bases. Sometimes it’s the little things you overlook that can leave your network open to attack.