Confronting Your Network Security Nightmares

WHEN MY KIDS WERE YOUNGER, they slept with night lights on toprotect them from the nameless, unspecified evil that was lurking beyond theirvision. As they grew older, however, they learned that nothing was stalking themfrom the dark corners of their room, and now they can sleep in the dark. Incontrast, as I grow older, I become increasingly aware of the nameless,unspecified evil that is stalking me from the dark corners of my network. Infact, if I could attach a night light to my network, it would glow brightlyaround the clock.

My fears are proportional to the size of the network: The bigger thenetwork, the more dark corners I have to worry about. When I hook up a privatenetwork to the Internet, for instance, I see an endless maze of dark corners andshadowy alleys. Some people may say I'm just paranoid--that Windows NT hasindustrial-strength security (for an overview of NT security issues, see KeithPleas, "Securing Windows NT," page 74) and that Microsoft would neverrelease a product like the Internet Information Server (IIS--for a review ofIIS, see Stephen Genusa, "Serving Up Internet Information," page 62,and Carl Calvello and Thad Schwebke, "Troubleshooting Internet InformationServer 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 amatter of time before intruders find paths through the software or through yoursecurity implementation.

Personal paranoia aside, most discussions about security usually degenerateinto a classic optimist/pessimist argument: The optimist sees the glass as halffull and the network as mostly secure; the pessimist sees the glass as halfempty and the network as partially insecure.

To shed some light on the issue of Internet security (and to justify myparanoia), I connected a system running Windows NT Server 4.0 beta 2 and IIS 2.0to the Internet and asked a professional security analyst from MidwesternCommerce (MWC) to hack away at it. As you'll see, the results were both amazingand horrifying.

My Little Shop of Horrors
I built the NT system for this test byconfiguring NT and IIS the way most people configure them. I installed NT Serveron one NT File System (NTFS) drive partition (for information about NTFS and itssecurity issues, see Sean Daily, "NTFS vs. FAT," page 95) on an Inteldual Pentium system from Advanced Logic Research (ALR). During the NT Serverinstallation, I accepted the default settings for security and protocol. I theninstalled IIS--with Web, FTP, and Gopher support enabled on the samepartition--and configured IIS for Internet access (for example, I enabledanonymous FTP and Web access).

Finally, I went through the entire directory structure on the disk and madesure that only the Administrator had full read and write access to all files. Irestricted other users to read-only access in system directories and read andwrite access in the designated Web, FTP, and Gopher directories.

I debated going back through the system configuration to plug some securityholes I happened to be aware of, but ultimately, I decided not to. I wanted tosee whether the security analyst would exploit the obvious holes and howMicrosoft'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 andinto the valley of darkness--in other words, I plugged the server into theInternet 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. Iexperienced a series of mysterious system lock-ups. I also received ominouswarning messages on the console, such as the one in Screen 1.

However, I didn't realize just how exposed my server was until a fatefulconversation with the security analyst. He called to tell me he had accidentallycorrupted my swap file. He needed me to reboot from NT Server to NT Workstationand then back to NT Server to correct the corrupt swap file so he could continuetesting.

I said I couldn't recall whether I had installed NT Workstation on thatsystem. 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'shard disk. Obviously, he had penetrated far beyond the boundaries of ordinaryWeb access.

The Test Results
After several days of testing, the securityanalyst sent me his observations and recommendations. The observation section ofhis report listed the computer name, all the users defined for the system, thegroups assigned to those users, all the directories on the hard disk, thepermission levels assigned to those directories, and other details about myserver.

The recommendations section included the following instructions:

One recommendation I expected to see but didn't is to remove or rename theAdministrator account (for more information about this suggestion, see MikeReilly "Find Holes in Your NT Security," page 87, and BobChronister, "Tricks and Traps," page 138, September 1996).

In Close-Up
Do you need to implement all these recommendations? In most cases, yes. Butbefore 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 yourcorporate network and then connecting your network to the Internet is one of themost dangerous things you can do with a Microsoft-based network. When you runNetBIOS over TCP/IP, you open all your print, file, and application sharingservices to any system that can run TCP/IP. Considering the Internet is aTCP/IP-based network, you're opening up your network to the world.

Unless you take adequate precautions, a hacker can fake aNetBIOS-over-TCP/IP session and try to penetrate any system on yournetwork. Note that I'm not talking about penetrating just your Web server, I'mtalking about penetrating any system that offers network services.

What can you do? The simplest, most obvious solution is to disable NetBIOSover TCP/IP with the Network applet on the Control Panel. You can then run yournative Microsoft file, print, and application services with NetBIOS over eitherInternet Packet eXchange (IPX)/Sequenced Packet eXchange (SPX) or NetBEUI.

Because a hacker can't easily access IPX/SPX or NetBEUI services over theInternet, your corporate systems are better insulated from intrusion.Furthermore, because you can run TCP/IP on your corporate systems withoutrunning NetBIOS over TCP/IP, all your systems can still access the usual TCP/IPand Internet services.

Unfortunately, in many cases, you can't disable NetBIOS over TCP/IP. Forexample, you may have built your entire WAN using TCP/IP, or your CEO may havedesignated TCP/IP as a corporate standard. In these situations, to protectyourself from the dangers of running NetBIOS over TCP/IP, you can take one orboth of the following actions:

1. Implement a firewall between your network and the Internet, and filterout traffic on the sockets UDP 137, UDP 138, and TCP 139. These sockets are forNetBIOS traffic; if you filter them out, NetBIOS traffic can't flow between yournetwork 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 corporatesystems' IP addresses from the Internet to protect them from a direct attack.(For more information about proxy servers, see Mark Edwards, "Microsoft'sInternet Access Server," September 1996, and "Configuring Microsoft'sInternet Access Server," page 153, and my article, "Think Thin and Winwith Intelligent Console Architecture," page 128.)

Whatever you do, please don't take this recommendation lightly. Ifyou run NetBIOS over TCP/IP without protection, you're putting your entirecorporate network at risk.

Disable the Guest account. Like the Administrator account, theGuest account is a standard NT account and is often the target of attack. Eventhough the Guest account ordinarily has limited privileges, it can still hurtyou. For example, if your Guest account has read access to your securitydatabase (the Security Accounts Manager) or your Registry files, a hacker canuse 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 thereport, this is the most tricky to implement and can cause you real grief if youdo it incorrectly. So be warned: Try this on a test machine before you do iton your production server!

The security analyst's report outlines the disabling process, beginningwith this ominous note:

Group Everyone is a dark side of Windows NT. Get rid of group Everyonewherever possible. Take great care when doing this procedure; otherwise, you caneasily make NT installation unstable.

The steps are as follows:

Note that IIS is particularly sensitive to the presence (or absence) ofgroup Everyone--so again, try this procedure in a test environment before doingit on your live server.

Disable mapping for .bat and .cmd files (and don't use them asCGI scripts). Unfortunately, IIS has a history of problems regardingimproper 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 atwww.omna.com/msiis. This Web page also notes similar problems with the NetscapeWeb server.

The bottom line is don't use .bat or .cmd files to launch CGI scripts, anddon't let users access .bat or .cmd files through your Web server (disable anymappings to these types of files). If you don't take these precautions, hackerscan launch NT commands on your server.

Avoid the FTP server. FTP servers have always been a weak spot inInternet security, regardless of what platform and OS they run under. An FTPserver lets hackers hack away at usernames and passwords at their leisure. Oncehackers find the right username and password (e.g., the Administrator usernameand 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 needone, establish separate partitions for its data area, and don't permit writeaccess to the root FTP directory (force users to write into a lower-levelanonymous directory or into individual user directories).

Don't use the Web server as a file server. Using a Web server as afile server creates a double-edged sword. First, if you store corporate data onyour 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 themcorrupt (accidentally or otherwise) your Web pages.

I feel more strongly about this topic than the security analyst did. Infact, I recommend you put your Web servers in a domain separate from yourcorporate domains in a TCP/IP subnet separate from your corporate subnets. Allaccess from your corporate network to your Web server will need to flow througha router or firewall.

Remove unused (and dangerous) program files. Remove unused files tokeep hackers from gaining further access to your network if they find a hole inyour server.

For example, if intruders can exploit the .cmd and .bat exposure, they canlaunch a client program on your server to access other corporate networkresources. Because the clients are coming from one of your systems (your Webserver), these clients may be able to bypass your external firewalls or proxyservers. A hacker, for instance, can launch an FTP session to attack any FTPservers on your corporate network.

Again, you can minimize such intrusions by putting your servers on separatenetworks--but why run any further risk? Simply delete client-oriented programsthat you ordinarily install on your server, including ftp.exe, telnet.exe, andrasdial.exe.

Create separate partitions for your NT and Internet data. Thissuggestion is subtle but important. If you place each logical group of files oreach independent directory structure on a separate partition (separate logicaldisk drives), you reduce the risk of contamination. For example, if you storeyour Web pages and your Web scripts in the same directory, hackers can breakinto your Web page area and easily contaminate your scripts.

An obvious response to this problem is to separate the files into differentroot-level directories. Unfortunately, after a hacker finds a security hole,moving around from one directory to another inside a partition is prettyeasy--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 andmultiple partitions are more difficult to configure and manage. And yes, thisapproach is not the most efficient way to use space on a disk drive. No one saidimplementing security would be fun or efficient.

Sweet Dreams?
After you implement all these recommendations, youcan 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 howmany 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'timplement them, chances are that you'll wake up screaming--if you can sleep atall.