NT Security Scares?

No need to panic
The sky is falling! The sky is falling! The sky is--oh, whoops, sorry. That was a raindrop. Well, it's almost the same, isn't it? You'll think so if you listen to the current gang of so-called NT security experts, each trying to out-do the other in proving that NT's security has more holes than a bowling ball factory.

If you're an NT administrator or a network security officer, no doubt higher-ups have asked you in baleful tones, "Are you sure it was a good idea to use NT? Hardly a day goes by without another security hole discovery!" If you're having a rough time answering that question, read on.

As more people use NT, they'll examine more and more of NT's nooks and crannies, leading to the discovery of more and more bugs. Some discoveries will be genuine security bugs, worthy of fear and reaction. But I haven't seen one yet. Bear in mind that although I'm no security expert, I have been running PC networks since 1985, so I've picked up a few lessons along the way. One article doesn't give me enough space to consider all aspects of NT security, but I can take up most of the big scares.

SCARE NUMBER ONE:  NTFSDOS
One of my fellow Windows NT Magazine contributing editors, Mark Russinovich, wrote a program, NTFSDOS.EXE, that occasioned the spilling of much ink (see "NTFSDOS Poses Little Security Risk," September 1996). Mark's very clever program lets you read NTFS volumes from DOS: You can go to an NT machine containing one or more NTFS volumes, boot DOS, and run NTFSDOS. You'll see the NTFS volumes, which now show up as regular drives. You can read the volumes, not write them.

Some people claim this program reveals a chink in NT's armor. They claim that previously they could format their server drives to NTFS and know that file and directory permissions would keep the casual user or hacker from coming up to the server, booting DOS, and having full access to the data on the drives.

I don't understand why this scenario is a problem. To use NTFSDOS, an intruder must have physical access to the server (that is, shove a bootable DOS floppy into the server's A drive). But is why would just anyone be able to walk in off the street and reboot a server? One of the first lessons I learned in PC networking was that unless you physically secure servers, you don't have security.

I'm amazed to see companies with swipe cards and security guards, offsite backups, and hot-start sites protecting their mainframes but doing nothing for the LAN servers. "So, where are your servers?" I once asked a client.

"In Scott's office," he replied.

"Does Scott's office have a lock on the door?" I wondered.

"Well, sure." came the answer. "But those servers keep it pretty warm, so I think he keeps the door open most of the time."

Walking into Scott's office, I saw that the servers were in max-height towers, and the towers were on the floor, where the vacuum cleaners could give them a little whack now and then. Several bookshelves piled high with backup tapes were mounted above the computers.

"So," I wondered aloud, "when the servers catch fire, the backups can go as well?" The clients looked sheepish and admitted they needed to move the backups somewhere else, but they just hadn't had the time.

The biggest problem with security is that we know what we're supposed to do, but we forget to do it or we're just too busy. (And I'm no exception, as I detailed in "Recovering from a Network Disaster," March 1997.)

Advice: Think Nike: Just do it. Control access to the servers. Whatever you do on the mainframes--disaster recovery plans, offsite backups, hot-start sites, the works--do it on the LANs

SCARE NUMBER TWO:  The Internet
Many companies want to attach their corporate networks to the Internet but are worried about the consequences. To hear people at such companies talk, you'd think that at this very moment, 50 guys in Stuttgart are waiting for you to put your company on the Net so that they can magically destroy your network by remote control.

Cliff Stoll's excellent book, The Cuckoo's Egg, and Robert Morris Jr.'s 1989 Internet worm highlighted problems in UNIX and VAX Internet security. The problems stemmed from users' lack of concern about security in the early days of the ARPAnet/Internet.

In the NT world, things are different. Let's suppose you put an NT file server on an Internet-connected computer. What can the bad guys do? To access your files, they must log on as recognized users of that server. To do so, they need to know four things: a valid user account name, the password for that account, the name of the server's domain, and either the name of a domain controller in the domain or the IP address of a Windows Internet Name Service (WINS) server in the domain.

Let's suppose you have a C-class network, acme.com at 200.200.200.x, where x can range from 1 to 254. Using NBTSTAT (a command to get NetBIOS information over TCP/IP) and a bit of patience, our theoretical hackers can figure out which machines are domain controllers and the name of your NT domain. (See "Knowing the Angles of NetBIOS Suffixes," February 1997, and Tom Sheldon, "NT Security Tips," December 1996, for specifics on using NBTSTAT to dump network information.) Suppose the hackers find that you have a domain named ACMENET with a domain controller at 200.200.200.15. They've won half the battle, two of the four things that they need to crack your network. Next, they need the name of an administrator account. They can get the name of an administrator account in a few ways, but the easiest is probably the RedButton program that's available on the Internet (http://www.ntsecurity.com/RedButton/index.htm). Another way to get the name of an administrator account is with NBTSTAT. When you dump a machine's NetBIOS name table with NBTSTAT, you often find the name of the person logged on to the server. You often see two names with the suffix <03>. One is the computer's name, and the other is the user's name. To keep this information from displaying, stop the Messenger service on that server.

So the bad guys now have a domain name, the name of a domain controller or two, and the name of the built-in Administrator account; now they need a password. Potential intruders possessing the name of the built-in Administrator account is particularly scary because that account doesn't lock out, like other accounts. You can set your system's account policies so an account becomes locked out if someone tries to log on to that account and fails after a given number of tries. For example, you can set up accounts so that five failed logon attempts in a row keep anyone from logging on to that account until the administrator unlocks it. The built-in Administrator account is unfortunately an exception to that rule; when hackers have the name of your built-in Administrator account, they can try to log on to that account as many times as they like. Would-be intruders can randomly try passwords for the built-in Administrator account until they hit the right one. So don't make the random search easier by allowing a simple password.

You can make the built-in Administrator account safer in another way. The NT resource kit includes a program, PASSPROP.EXE, that modifies the built-in administrative account so that you can lock it out like other accounts.

The key to securing the built-in Administrator account, then, is through a good password. This advice is old, but don't use obvious passwords, and don't use English words or names all by themselves: For example, if you like the password "Hale-Bopp," append some other character, as in "Hale-Bopp7," to make it harder to guess. If you figure each failed logon attempt takes (conservatively) 10 seconds, someone beating on your system unnoticed for a year would have an opportunity to try about 3,000,000 passwords. How worrisome is that? Well, you can have up to 14 characters in an NT password. If you restrict yourself to just lowercase letters, you have 64 quintillion possibilities (64,509,974,703,300,000,000), 26 raised to the 14th power. If you use 26 lowercase, 26 uppercase, and 10 numerics, you get 12,401,769,434,660,000,000,000,000 possibilities--I think that's septillions, but I won't swear to it.

You can use basic rules for developing passwords for most accounts, and go to extremes on the built-in Administrator account. Set the account's password to some randomly generated 14-character password. The password won't be inconvenient for logging in because you don't want to use the built-in Administrator account anyway. You can also protect yourself from someone logging on if you filter out UDP ports 135 through 139 and TCP port 139. With these ports filtered out, you can't log on to an NT server's file-and-print sharing services (unless you're doing Point-to-Point Tunneling Protocol--PPTP). And of course, all this advice goes out the window if you enable the Guest account--don't do it, ever.

Now you know how to secure your files from attack via NT's NetBIOS-based file sharing protocols. But someone can theoretically read or perhaps change files on your server another way--older Internet protocols. I honestly can't detail how someone can crack an NT system with one of these protocols, but I can relate the protocols that most Internet security types talk about: Telnet, Remote Shell (RSH), and FTP. I'm told that running Telnet, RSH, or FTP servers on any machine that contains sensitive data is a bad idea, so I don't. Other people have hinted that HTTP (the protocol underlying Web servers) is also insecure, so I suppose the same advice goes for Web servers. More specifically, if a hacker can upload a dangerous Common Gateway Interface (CGI) program to your Web server and then execute it, that criminal can do some damage to your server. How someone can upload unwanted data to a Web site is not clear to me--there's that sky falling again--but if that feat is possible, you can still protect yourself from the ill-intentioned CGI program. Set the file and directory permissions on your files to keep the intruder from doing damage. People coming in on your server log on as the user IUSR_servername, which Internet Information Server (IIS) automatically creates. If you use file and directory permissions to give that user account No Access to some file, no CGI program (or HTTP hole) in the world will let a criminal damage or even look at one of your files.

Advice: First, never enable the Guest account on any NT machine, ever. And if you're really worried, filter out UDP ports 135 through 139 and TCP port 139 with your firewall or your router. Our Cisco 2501, for example, can filter UDP ports, making a firewall unnecessary. (That is, unnecessary to me. Again, remember I'm not a security expert. Your mileage may vary and all that.) Also, don't put anything sensitive on a computer running an FTP server. Next, use file and directory permissions on all the files on an IIS server to ensure that hackers can't exploit security holes in HTTP; if you really want to be careful, run IIS on a computer that doesn't run anything else. Finally, use a long, randomly-generated password for the built-in Administrator account, or use PASSPROP to lock out the built-in Administrator account. (Again, PASSPROP is part of the NT Server resource kit, a separate Microsoft product.) For more information on Internet security, see John Enck, "Confronting Your Network Security Nightmares," October 1996.