My June article, "Point-to-Point Tunneling Protocol," showed you how to build a Virtual Private Network (VPN) using Microsoft's Point-to-Point Tunneling Protocol (PPTP). By following the configuration outlined in that article, you can set up a Remote Access Service (RAS)/PPTP server on your network, and give your clients secure, encrypted access to your internal network via the Internet.
Now that you have implemented a PPTP solution, have you increased your network's security accordingly? If you haven't had a chance to re-evaluate your security policy, or if you are interested in making your network more secure, this article will give you some basic tips on how to protect your network from intrusions.
Reach Out and Touch Someone
As I mentioned in the June article, you can dial up your PPTP connection by using either an IP address or a fully qualified domain name in the phone number field of the Dial-Up Networking (DUN) dialog box. Fully qualified domain names simplify navigating and finding things on the Internet. This capability is great when you're surfing Web sites and other public systems. However, making things easier to find is not a desirable feature for your private network.
Let's say, that you've just built a RAS/PPTP server for your users that has a public Internet address of 172.16.1.1 (this address is an example, and is not a valid public Internet address). To simplify configuring connections for your users, you create the fully qualified domain name PPTP.yourcompany.com and put this address into the Domain Name System (DNS) on the Internet, pointing to address 172.16.1.1.
DNS is the "phone book" of the Internet. By providing a name resolution service for anyone on the Internet, DNS lets you enter user-friendly names instead of IP numbers to connect to sites. For example, when you ask your browser to connect to http://www.winntmag.com, your PC--if it doesn't already know which IP address to use--sends a query to the DNS server defined in its TCP/IP configuration. The DNS server receives the query, "Hi, what number do I use to contact www.winntmag.com?" The server replies, "The IP number is 220.127.116.11."
As a result, DNS is more of a convenience than a necessity, and the Internet can technically function without it. All the computer needs to navigate the Internet is the correct IP address to establish a connection with. You can observe this connection by accessing Windows NT Magazine's home page by entering the IP address instead of its name. Point your browser to http://18.104.22.168, and watch the page load. Although this method works, no one wants to remember the IP addresses of all the Web sites they need, so DNS acts as a helpful human-oriented navigation tool.
Too Much of a Good Thing
Helpful, however, is not a good thing when your network has public access points. After all, you wouldn't request listings of your standard dial-up lines in your local white pages. Nevertheless,
creating a descriptive DNS entry for your PPTP server amounts to the same type of thing. As a matter of fact, creating a descriptive entry is even worse, because this information is usually easier to find than phone book listings.
Suppose that I'm an unscrupulous hacker who wants to get into your network. Using publicly available records on the Internet and a correctly configured DNS server, I can find all the systems in your network that have associated DNS entries and their IP addresses. If I stumble across an entry called PPTP.yourcompany.com, this address gives me a significant clue as to what is waiting at that address, how to connect with that system, and what to expect once I've connected. Fortunately, most DNS servers will not surrender this information unless you configure them to do so.
After successfully negotiating a connection to your PPTP server, my final step is to find a username and password combination that lets me access your network. Having good internal security policies in place can help you deter this attack; the best security is not letting unauthorized users get to a point where they can attempt a logon validation. After all, you wouldn't let a complete stranger walk into your building, sit down at a PC, and start attempting logons, would you?
Conceal the Obvious
So how can you protect yourself from such attacks? Don't make a DNS entry for your PPTP server. Without a DNS entry, a hacker will have difficulty determining whether a certain IP address belongs to a server, workstation, printer, or some other device.
If you absolutely must create a DNS entry for the server, consider using an obscure name such as EARTH.yourcompany.com, or something that doesn't provide any clues as to the function of the device assigned to this address. To create confusion, people name their servers after planets, Santa's reindeer, the Seven Dwarfs, Star Trek characters, and so on. The more ambiguous the server name, the better.
For the public to access your Web site, you want to keep systems such as your Web server at www.yourcompany.com and your FTP server at ftp.yourcompany.com. However, anything that you don't want the general public to access needs to have an obscure name or no name (DNS entry) at all.
Configure the PPTP server to accept only PPTP packets: Select the Enable PPTP Filtering check box in the Advanced IP Addressing dialog box, as shown in Screen 1. If you select this option, your system will not respond to any ping or tracert packets, which makes that IP address look unused. A common routine for determining which systems are on a network is to do a net scan of a block of IP addresses and see which systems respond. If your PPTP server doesn't respond, a less-skilled hacker will breeze right past your system, leaving it untouched.
The flip side of the coin is that you won't be able to ping the PPTP server as a matter of routine troubleshooting techniques. You will need to implement other methods of remotely troubleshooting that system (such as a standard dial-in port) so that you can check the server from inside your network.
Consider a firewall for your network if you are connecting it to the Internet. When you really want to get creative, you can buy two firewalls and build a Demilitarized Zone (DMZ, Figure 1) such a zone of systems protected between two separate firewalls, is shown in Screen 1. Although this option is more expensive than a single firewall, it is the most secure. Your public servers, such as your Web and FTP servers, sit between the two firewalls, open to the public but controlled by the first firewall. If an intruder breaches the security on the first firewall, the second firewall takes over. Security is usually tighter on the second firewall than on the first.
Another method to protect your network is to use private network addresses for most of your internal network. The Internet Assigned Numbers Authority (IANA) has reserved several address ranges for corporations to use for their internal networks. These ranges (10.0.0.0 to 10.255.255.255, 172.16.0.0 to 172.31.255.255, and 192.168.0.0 to 192.168.255.255) are blocked at every router on the Internet, so no direct connections can exist between external systems and stations on your internal network. This method is great for protection, but it can be a hindrance for your users because the converse is also true--users can't connect to Web sites and FTP sites.
If you have a large network with an IP subnet infrastructure, changing to private IP addresses is no small task. However, if your organization isn't using TCP/IP yet, think about using private IP addresses for some or all of your internal network.
You will need to set up a proxy server or Network Address Translator (NAT) to handle all your Internet communications, such as Web browsing and FTP sessions. Microsoft's Proxy Server, an extension to Internet Information Server (IIS) is an excellent choice because it integrates directly into the NT security system to let you control outbound access based on username or group membership. Some leading firewall packages will also perform proxy services.
Any systems that need to reside in both the public and private world will need to have two network cards for communications. For example, an Exchange server running Internet Mail Server (Simple Mail Transfer Protocol--SMTP service) needs to communicate with the Internet as a whole on one network card, and with your internal network on the other card.
As a precaution, make sure that IP routing is disabled by selecting Control Panel, Networks and clicking on the Protocols tab. Open the properties for TCP/IP, and select the Routing tab. Verify that the check box for IP forwarding is not selected. For more information on private IP addresses, refer to InterNIC RFC 1597 at http://www.internic.net/rfc/rfc1597.txt.
Lock the Front Gate, but Don't Stop There
All of these methods will protect you on the outside. But, as I heard one firewall expert explain, strong external security with lax internal security will make your network "crunchy on the outside with a soft chewy center on the inside." A lack of internal security is equivalent to locking the front door of your house and leaving all the inside doors wide open. You assume that after someone has entered the front door, the visitor is trusted to roam the house freely. Obviously that's not a very safe assumption in networking.
As someone who is responsible for a network, you are probably very security conscious. However, in some organizations, I've seen security policies stretched or tossed aside in the name of ease-of-use for end users. Connecting your network to the Internet can be a good political opportunity to step up your security a few more notches.
Some of NT's basic security policies are necessary in your network. These policies include requiring password changes every 30 days to 45 days, enabling account lockouts, and demanding minimum password lengths. Additionally, increasing auditing to include failed logon attempts and security policy changes will help troubleshoot problems, but logging an event after it happens is a reactive step, not a proactive one. Clearly, you don't want to have to log any events if at all possible.
Next, secure your Guest account by disabling it. Unless you need this account, you have no reason for it to be active. Also, secure your Administrator account, but if your system is still prone to a RedButton attack (for more information about RedButton, see Mark Minasi, "NT Security Scares?," July 1997), an outsider (with no access whatsoever) will still be able to determine your Administrator account name, even if you have renamed it. You can block access to ports 137, 138, and 139 on any machines exposed to the Internet to help prevent this attack, and apply Service Pack 3 (SP3), which lets you restrict anonymous user access.
Also, look at some of your service process accounts such as a replication user or a Microsoft Mail or Exchange service account. Although these accounts need a higher level of security in your system, they do not need Administrator rights.
You will probably want to obscure these account names. People use some common names for these accounts based on what they have read in NT books or Microsoft training classes. Do yourself a favor, be creative when naming your accounts. And by all means, do not let the password be the same as the username (don't laugh, I've seen this mistake at some very large organizations).
Take Security Seriously
Even if you follow all the steps I've listed, see the " Security Checklist," and have a myriad of firewalls protecting your network, you'll never achieve 100 percent security as long as you're connected to the Internet. If legitimate users can access the network from the outside, illegitimate users can get in--this fact is the nature of remote access. Your organization probably dealt with this issue (or should have) when you added dial-in lines to your network. For information about token-based security authentication systems, see Ben Rothke, "Token-Based Security Add-ons," June 1997.
With the recent security issues that NT has faced, unauthorized access into your network is something you don't want to take lightly. Be aware that some programs can pose a significant security risk for you and your network. As long as you keep a good internal and external security policy, monitor your event logs and firewall logs, and obscure system names, you will protect yourself from all but the most hardened of attackers.