WHEN MY KIDS WERE YOUNGER, they slept with night lights on to protect them from the nameless, unspecified evil that was lurking beyond their vision. As they grew older, however, they learned that nothing was stalking them from the dark corners of their room, and now they can sleep in the dark. In contrast, as I grow older, I become increasingly aware of the nameless, unspecified evil that is stalking me from the dark corners of my network. In fact, if I could attach a night light to my network, it would glow brightly around the clock.
My fears are proportional to the size of the network: The bigger the network, the more dark corners I have to worry about. When I hook up a private network to the Internet, for instance, I see an endless maze of dark corners and shadowy alleys. Some people may say I'm just paranoid--that Windows NT has industrial-strength security (for an overview of NT security issues, see Keith Pleas, "Securing Windows NT," page 74) and that Microsoft would never release a product like the Internet Information Server (IIS--for a review of IIS, see Stephen Genusa, "Serving Up Internet Information," page 62, and Carl Calvello and Thad Schwebke, "Troubleshooting Internet Information Server 2.0," page 107) unless it was completely secure. My cynical view, however, is that no product connected to a network is 100% secure--it's just a matter of time before intruders find paths through the software or through your security implementation.
Personal paranoia aside, most discussions about security usually degenerate into a classic optimist/pessimist argument: The optimist sees the glass as half full and the network as mostly secure; the pessimist sees the glass as half empty and the network as partially insecure.
To shed some light on the issue of Internet security (and to justify my paranoia), I connected a system running Windows NT Server 4.0 beta 2 and IIS 2.0 to the Internet and asked a professional security analyst from Midwestern Commerce (MWC) to hack away at it. As you'll see, the results were both amazing and horrifying.
My Little Shop of Horrors
I built the NT system for this test by
configuring NT and IIS the way most people configure them. I installed NT Server
on one NT File System (NTFS) drive partition (for information about NTFS and its
security issues, see Sean Daily, "NTFS vs. FAT," page 95) on an Intel
dual Pentium system from Advanced Logic Research (ALR). During the NT Server
installation, I accepted the default settings for security and protocol. I then
installed IIS--with Web, FTP, and Gopher support enabled on the same
partition--and configured IIS for Internet access (for example, I enabled
anonymous FTP and Web access).
Finally, I went through the entire directory structure on the disk and made sure that only the Administrator had full read and write access to all files. I restricted other users to read-only access in system directories and read and write access in the designated Web, FTP, and Gopher directories.
I debated going back through the system configuration to plug some security holes I happened to be aware of, but ultimately, I decided not to. I wanted to see whether the security analyst would exploit the obvious holes and how Microsoft's out-of-the-box configuration fared against a full frontal assault. So I kept my paranoia under wraps and pushed my test server over the cliff and into the valley of darkness--in other words, I plugged the server into the Internet and told the security analyst where to find it.
I didn't need a medium to let me know when my system came under attack. Strange things began happening to my server system almost immediately. I experienced a series of mysterious system lock-ups. I also received ominous warning messages on the console, such as the one in Screen 1.
However, I didn't realize just how exposed my server was until a fateful conversation with the security analyst. He called to tell me he had accidentally corrupted my swap file. He needed me to reboot from NT Server to NT Workstation and then back to NT Server to correct the corrupt swap file so he could continue testing.
I said I couldn't recall whether I had installed NT Workstation on that system. He calmly told me that both NT Server and NT Workstation were, in fact, installed. He then proceeded to list the entire contents of the server system's hard disk. Obviously, he had penetrated far beyond the boundaries of ordinary Web access.
The Test Results
After several days of testing, the security
analyst sent me his observations and recommendations. The observation section of
his report listed the computer name, all the users defined for the system, the
groups assigned to those users, all the directories on the hard disk, the
permission levels assigned to those directories, and other details about my
server.
The recommendations section included the following instructions:
- Disable NetBIOS over TCP/IP.
- Disable the Guest account.
- Disable the Everyone group (but be careful how you do this!).
- Disable mapping for .bat and .cmd files, and don't use them as Common Gateway Interface (CGI) scripts.
- Avoid using the FTP server.
- Don't use the Web server as a file server.
- Remove unused (and dangerous) program files (that is, ftp.exe, rasdial.exe, and telnet.exe).
- Create separate partitions for NT system files, Hypertext Transfer Protocol (HTTP) documents, CGI scripts, template files, and FTP files.
One recommendation I expected to see but didn't is to remove or rename the Administrator account (for more information about this suggestion, see Mike Reilly "Find Holes in Your NT Security," page 87, and Bob Chronister, "Tricks and Traps," page 138, September 1996).
In Close-Up
Do you need to implement all these recommendations? In most cases, yes. But
before you run over to your server keyboard, let's look closely at each one.
Disable NetBIOS over TCP/IP. Running NetBIOS over TCP/IP on your corporate network and then connecting your network to the Internet is one of the most dangerous things you can do with a Microsoft-based network. When you run NetBIOS over TCP/IP, you open all your print, file, and application sharing services to any system that can run TCP/IP. Considering the Internet is a TCP/IP-based network, you're opening up your network to the world.
Unless you take adequate precautions, a hacker can fake a NetBIOS-over-TCP/IP session and try to penetrate any system on your network. Note that I'm not talking about penetrating just your Web server, I'm talking about penetrating any system that offers network services.
What can you do? The simplest, most obvious solution is to disable NetBIOS over TCP/IP with the Network applet on the Control Panel. You can then run your native Microsoft file, print, and application services with NetBIOS over either Internet Packet eXchange (IPX)/Sequenced Packet eXchange (SPX) or NetBEUI.
Because a hacker can't easily access IPX/SPX or NetBEUI services over the Internet, your corporate systems are better insulated from intrusion. Furthermore, because you can run TCP/IP on your corporate systems without running NetBIOS over TCP/IP, all your systems can still access the usual TCP/IP and Internet services.
Unfortunately, in many cases, you can't disable NetBIOS over TCP/IP. For example, you may have built your entire WAN using TCP/IP, or your CEO may have designated TCP/IP as a corporate standard. In these situations, to protect yourself from the dangers of running NetBIOS over TCP/IP, you can take one or both of the following actions:
1. Implement a firewall between your network and the Internet, and filter out traffic on the sockets UDP 137, UDP 138, and TCP 139. These sockets are for NetBIOS traffic; if you filter them out, NetBIOS traffic can't flow between your network and the Internet.
2. Implement a proxy server, such as Microsoft's Internet Access Server (IAS) and Intelligent Console Architecture. A proxy server hides your corporate systems' IP addresses from the Internet to protect them from a direct attack. (For more information about proxy servers, see Mark Edwards, "Microsoft's Internet Access Server," September 1996, and "Configuring Microsoft's Internet Access Server," page 153, and my article, "Think Thin and Win with Intelligent Console Architecture," page 128.)
Whatever you do, please don't take this recommendation lightly. If you run NetBIOS over TCP/IP without protection, you're putting your entire corporate network at risk.
Disable the Guest account. Like the Administrator account, the Guest account is a standard NT account and is often the target of attack. Even though the Guest account ordinarily has limited privileges, it can still hurt you. For example, if your Guest account has read access to your security database (the Security Accounts Manager) or your Registry files, a hacker can use FTP to download those files and pick them apart. Why open yourself to risk? Just disable the Guest account.
Disable the Everyone group. Of all the recommendations in the report, this is the most tricky to implement and can cause you real grief if you do it incorrectly. So be warned: Try this on a test machine before you do it on your production server!
The security analyst's report outlines the disabling process, beginning with this ominous note:
Group Everyone is a dark side of Windows NT. Get rid of group Everyone wherever possible. Take great care when doing this procedure; otherwise, you can easily make NT installation unstable.
The steps are as follows:
- Create a new group called Every User, for example.
- Include all existing users in this group.
- Use the User Manager program to grant group Every User the right to access this computer from the network; revoke group Everyone's right to access this computer from the network.
- In User Manager, substitute Everyone with Every User for all other rights.
- In File Manager's Security menu, replace group Everyone with group Every User. Be careful: Do not propagate the permissions through an entire file tree.
- Substitute Everyone permission with Every User on all disk shares.
- Some special network shares with group Everyone access cannot be deleted. The best known example is the Registry. Determining optimum permissions to all Registry keys in a real NT box is almost impossible. A practical recommendation is to remove group Everyone from the hkey_local_machine key and include Every User (read-only access) instead.
Note that IIS is particularly sensitive to the presence (or absence) of group Everyone--so again, try this procedure in a test environment before doing it on your live server.
Disable mapping for .bat and .cmd files (and don't use them as CGI scripts). Unfortunately, IIS has a history of problems regarding improper access to .bat and .cmd files through the Web server interface.
MWC, the company that performed the security probe into our test server, provides a complete explanation of this problem on its Web page at www.omna.com/msiis. This Web page also notes similar problems with the Netscape Web server.
The bottom line is don't use .bat or .cmd files to launch CGI scripts, and don't let users access .bat or .cmd files through your Web server (disable any mappings to these types of files). If you don't take these precautions, hackers can launch NT commands on your server.
Avoid the FTP server. FTP servers have always been a weak spot in Internet security, regardless of what platform and OS they run under. An FTP server lets hackers hack away at usernames and passwords at their leisure. Once hackers find the right username and password (e.g., the Administrator username and password), they can gain read and write access to the entire system.
You must seriously evaluate your need for an FTP server. If you really need one, establish separate partitions for its data area, and don't permit write access to the root FTP directory (force users to write into a lower-level anonymous directory or into individual user directories).
Don't use the Web server as a file server. Using a Web server as a file server creates a double-edged sword. First, if you store corporate data on your Web server, hackers can access or corrupt the data through the Internet. Second, if you let corporate users access Web server data, you risk having them corrupt (accidentally or otherwise) your Web pages.
I feel more strongly about this topic than the security analyst did. In fact, I recommend you put your Web servers in a domain separate from your corporate domains in a TCP/IP subnet separate from your corporate subnets. All access from your corporate network to your Web server will need to flow through a router or firewall.
Remove unused (and dangerous) program files. Remove unused files to keep hackers from gaining further access to your network if they find a hole in your server.
For example, if intruders can exploit the .cmd and .bat exposure, they can launch a client program on your server to access other corporate network resources. Because the clients are coming from one of your systems (your Web server), these clients may be able to bypass your external firewalls or proxy servers. A hacker, for instance, can launch an FTP session to attack any FTP servers on your corporate network.
Again, you can minimize such intrusions by putting your servers on separate networks--but why run any further risk? Simply delete client-oriented programs that you ordinarily install on your server, including ftp.exe, telnet.exe, and rasdial.exe.
Create separate partitions for your NT and Internet data. This suggestion is subtle but important. If you place each logical group of files or each independent directory structure on a separate partition (separate logical disk drives), you reduce the risk of contamination. For example, if you store your Web pages and your Web scripts in the same directory, hackers can break into your Web page area and easily contaminate your scripts.
An obvious response to this problem is to separate the files into different root-level directories. Unfortunately, after a hacker finds a security hole, moving around from one directory to another inside a partition is pretty easy--crossing partitions is much more difficult.
What types of Internet data do you need to keep separate from your NT data? Everything you can. Put your NT system files, HTTP documents, CGI scripts, template files, and FTP upload and download files on separate partitions.
Yes, carving up a drive into multiple partitions is a lot of work and multiple partitions are more difficult to configure and manage. And yes, this approach is not the most efficient way to use space on a disk drive. No one said implementing security would be fun or efficient.
Sweet Dreams?
After you implement all these recommendations, you
can turn off your night light and slip peacefully to sleep, right? Wrong.
Remember, no system connected to a network is 100% secure--and no one knows how
many new bugs and security monsters are waiting to be discovered.
But look at network security this way: If you implement these precautions, you should at least be able to sleep with a night light on. If you don't implement them, chances are that you'll wake up screaming--if you can sleep at all.
| Contact Info |
|
Midwestern Commerce * 614-263-0662 Web: www.omna.com/Yes/MWC Email: [email protected] |
