Seven practical recommendations for securing Internet-connected Windows NT systems.
Jon Udell
In my August 1995 column, I mentioned that Satan, the Internet security scanner, had probed a Windows NT server on The BYTE Site and found no vulnerabilities. But as I pointed out then, no scanner can find holes that it doesn't know how to look for. Satan tests for well-known weaknesses in Unix installations, but it was clueless when it came to finding security holes in my Internet-connected NT system.
In this case, I'd purposely left a NetBIOS share wide open. Anyone who was running Windows 95 and knew a little about Windows networking over TCP/IP could have typed NET USE Q: \\SERVERNAME\SHARENAME and gained full access -- across the Internet -- to the server's boot partition.
Does that make NT less secure than Unix? Today the answer is yes, but not because NT is inherently less securable than Unix. Administrators of Unix systems have learned over decades how to configure Unix to survive in the hostile environment of the open Internet. As NT increasingly finds itself operating in that same hostile environment, its administrators have to master the same techniques. Here, then, are some ways to make an NT site less vulnerable.
1. Use NTFS, Not FAT
NT File System (NTFS) volumes can apply access-control lists (ACLs) to files and directories; these controls work in conjunction with permissions on shared directories. A file allocation table (FAT) volume supports only the latter, share-level form of security. For safety's sake, it's always the best thing to layer multiple defenses whenever they're available, so you should always use NTFS on Internet-connected Windows NT machines.
If NTFS ACLs give a network user full access to a partition but share-level permiss
ions grant only read access, then the effective access is read only. Windows NT takes the intersection of NTFS ACLs and share permissions.
Should you even allow shares to exist on a public machine? Ideally not, but in practice you need some way to move files to and from your server. NTFS-level security can help make that practice less dangerous. If you create new shares, though, be sure to alter the default permissions assigned by NT. If you forget, group "Everyone" will have full control of all that's visible through the share.
This behavior is one of the reasons why NT gets a bad rap in the security community. It tends to default to a friendly configuration rather than to a paranoid one. That philosophy may be appropriate for a LAN workgroup, but it's disastrous for an Internet server.
What if you're already running FAT? On x86 (but not RISC) NT systems, you can upgrade a boot volume to NTFS -- in place -- using the CONVERT utility. It's scary, but when I tested CONVERT on a development server
to verify that it works, all went well.
2. Rename the Administrative Account
To foil brute-force password-guessing attacks, you should use NT's User Manager to set an account-lockout policy. For example, the policy might specify that NT will lock out an account after five failed log-on attempts. Unfortunately, the most dangerous account -- the administrator's -- is exempt from this policy. Even if you transfer administrative rights to your own account and use only that account for NT administration, the built-in administrative account remains available (because it can't be deleted or disabled) and vulnerable to brute-force password attacks (because it can't be locked out).
Many NT experts recommend that you rename the administrative account something obscure (e.g., 789Az0qPPaGzwer79) rather than the default name Administrator. That way, a password-guesser must first guess the account's name.
The renaming function is not available from User Manager's User Properties dialog box,
an omission that confused not only me but also a Microsoft product manager I interviewed. To rename the administrative account, select the User->Rename menu choice in User Manager.
While you're at it, disable the Guest account and remove or restrict all other user accounts. A machine dedicated to providing public Internet services does not need, and should not have, user accounts other than those required for its administration.
Finally, if you're running NT 4.0, you can use a utility provided in the Resource Kit to activate lockout for the built-in administrator's account. It's effective only for over-the-network log-ons; if it's triggered by an attack, you can still log on locally to reset the lockout.
3. Turn On Auditing
How do you know if you've been attacked or broken into? NT's event-auditing system can help, but only if it's enabled -- and by default it is not. In User Manager, the Policies->Audit menu choice leads to a screen that controls auditable events.
The trick here is to collect enough information, but not too much. You can audit both the success and failure of various operations. Failures occur less often than successes, and they're usually more interesting from a security perspective, so I always capture all these events (
see the screen
). I also capture successes for infrequent operations -- such as Security Policy Changes and Restart -- that might reflect unauthorized activity.
NT permits you to track other successful operations -- File Access, Use of User Rights, and Process Tracking -- but you'll need massive storage to capture this data, and incredible diligence to analyze it.
However you decide to audit your system, it's crucial to review the event logs to understand what records NT writes under normal conditions. That baseline will help you spot changes that spell trouble.
Experts also recommend that you guard the audit logs, because hackers typically try to cover their tracks after a break-in. You could schedule
a periodic backup of the log files, but if the backups remain on-line, then they, too, are vulnerable. A better solution would be to echo the audited events to a printer, or even e-mail them to yourself, to create an irrevocable audit trail. How? NT Perl comes with a (slightly buggy) module that you can use to read the event log. (See
http://www.byte.com/art/download/evt.pl
for a sample program that lists recent event-log entries.)
4. Disable NetBIOS-over-TCP/IP
An Internet-connected NT box will, by default, support Windows networking over two transport protocols: NetBEUI and TCP/IP. What's Windows networking? All the operations that require syntax of the form \\NAME. These operations include directory and printer sharing, NetDDE, and remote administration. Connecting to a
drive or editing a registry across the Internet requires only a mapping, in the local LMHOSTS file, between the remote machine's NetBIOS name and its IP address. For instance, you can use Win 95 versions of Event Viewer and User Manager (these come with the NT Resource Kit) to manage NT servers across the Internet. This setup is very convenient for administrators -- and also for hackers.
The good news is that NT enables precise control over your use of NetBIOS-over-TCP/IP (NBT). You can go to the Bindings dialog box in the Networks control panel and disable any or all of the following bindings between NetBIOS-based services and TCP/IP (
see the screen
).
On several machines, I've disabled all three. On one machine, though, I've allowed the
Workstation->TCP/IP
binding to remain, because its job requires it to connect locally to a Linux server that shares directories using Samba.
Because NT networking services run promiscuously over multiple transports, my machines ca
n still talk to each other using Server, Workstation, and other services. But these conversations occur only on the NetBEUI channel, which does not go across the Internet.
The bad news? Hackers can't try to remote-mount drives or remote-edit registries -- but neither can I.
5. Block Nonessential Inbound TCP/IP Ports
Suppose an attacker did break in somehow and gain administrative control. He or she might then find a way to reenable the NBT bindings you'd so carefully disabled. So, it's a good idea to enlist your router as another line of defense.
I'm assuming here that your NT server is highly exposed -- outside your firewall if you have one -- and that its mission is to offer public services, such as Web and FTP. If that's the case, only two inbound paths need to exist from the router to the server: HTTP on port 80, and FTP on port 21. The router can, and probably should, block all other inbound traffic.
You may or may not have the access and/or the authority to adjust yo
ur router's packet-filtering rules. If you can do so, you might be tempted to create a back door for yourself. You could, for example, reject all non-Web and non-FTP inbound traffic, except NBT traffic on ports 137, 138, and 139 coming from the IP address that you use for remote administration.
In theory, only you could then remotely operate the server. In practice, a hacker who discovered the connection between you and that IP address could also try to exploit the inbound path.
How might someone learn the IP address of your home system and exploit it? An acquaintance outlined his MO as follows: 1) research the target server's administrator, 2) create a phony Web page tailored to the administrator's interests, 3) send an e-mail invitation to visit that page, 4) capture the IP address of the home system, and 5) infiltrate that system using JavaScript or ActiveX.
A back door that depends on the anonymity of an IP address is frighteningly vulnerable to a patient, systematic attack. That's why securit
y experts recommend that you disallow all nonessential inbound paths. Bob Lord, Netscape's chief security consultant, wryly laments this evil necessity: "Rather than telnet in at 3 a.m. from my den while sipping a hot cup of coffee, I have to drive to work and sit in the cold room...but I'm not bitter."
6. Revoke the "Access from Network" Privilege
There's another line of defense available in NT. By default, NT grants to group Everyone the right to Access from Network. You can revoke this right -- thus blocking all Windows networking services -- yet still support Web service. An NT Web server, for example, runs either as SYSTEM or as a local user; in either case, there's no notion of a remote user in the NT sense.
The FTP server that comes with NT will fail in this situation, because it requires users to perform network-style log-ons. But other FTP servers, including the one in Microsoft's Internet Information Server (IIS), perform local log-ons and so are unaffected by revocation
of the Access from Network right.
Unfortunately, unlike the NBT method, this technique cannot select which protocols to allow or deny. So, if you run Web and FTP service with Access from Network revoked, you'll block file-sharing not only across the Internet but also locally over NetBEUI. Here's a compromise solution: Grant only your personal administrative account the Access from Network right.
7. Don't Blithely Divulge Information
"On the Internet, nobody knows you're running Windows NT," say NT partisans. Unfortunately, the curious can easily find out. For example, the built-in FTP service announces connections thusly:
ftp> open ftp.myhost.com
Connected to ftp.myhost.com
220 ftp Windows NT FTP Server
(Version 3.51).
Legitimate users have absolutely no need for such information. Hackers, however, gladly use it to disqualify fruitless modes of attack and zero in on effective, OS-specific ones. The IIS FTP service has an equally distinctive signatur
e:
Connected to ftp.myhost.com.
220 ftp Microsoft FTP Service
(Version 2.0).
In either case, it's a snap to find out that you've connected to an NT box and to discover which version of NT it's running. Contrast this with my Unix hosts, which announce the following:
Connected to ftp.myhost.com.
220 ftp FTP server Version
wu-2.4(2)
It's not obvious whether you've connected to my Linux server or to my BSD/OS server. Even this approach isn't perfect, because there are attacks specific to the wu FTP server. The point: Don't give away any information that you don't have to give away. Although you can customize a greeting message in NT's built-in FTP server and the IIS FTP service, I'm not aware of a straightforward way to suppress or alter the connection banner. If you've figured that out, please let me know.
Give NT Paranoia
Most of the defenses I've outlined here are simple, but they all require some effort. Out of the box, NT config
ures itself for a trusting environment. When you locate an NT server on the Internet, the governing principle must be paranoia, not trust.
It's not hard to do the kinds of things I've outlined here. What
is
hard is to discover these methods in the first place and then apply them rigorously. But isn't that just what computers do well?
I'd like to make a simple choice -- trust or paranoia -- when installing or configuring NT. If I choose paranoia, the NT installer should omit all unnecessary network services, protocols, and bindings; revoke all network-based rights and permissions; and audit itself aggressively. On an upgrade, features not consistent with the paranoid mode should be removed so that attackers cannot reenable them. The burden should be on me to selectively install and enable essential capabilities.
A basic tenet of computer security states that whatever is not explicitly allowed should be denied. NT gets this principle mostly backward today, but it shouldn't be hard to implem
ent a "paranoid toggle." Such an option would make public deployment of NT a whole lot less risky. How about it, Microsoft?
Editor's Note:
Thanks to the security consultants who helped with this article: Steve Turcich (independent) and Andy Baron (Midwest Commerce Systems, Inc.,
http://www.omna.com/
). See also
http://www.somarsoft.com/
.
TOOLWATCH
SafeSuite
Web-security scanner...............$ 495
Firewall scanner...................$1495
Intranet scanner...................$1495
Internet Security Systems
Internet: http://www.iss.net/
A powerful Internet security scanner that does much of what Satan
does, plus it probes for NT-specific vulnerabilities.
BOOKNOTE
World Wide Web Journal
volume 1, issue 4, edited by Rohit Khare
Publisher: O'Reilly and Associates
Internet: http://www.ora.com/
Price: $24.95
A collection of technical papers from members of the World Wide Web
Consortium and other prime movers of the Web. This issue of the
quarterly journal focuses on HTTP/1.1, state management, and PICS.
photo_link (62 Kbytes)
screen_link (29 Kbytes)
By default, NT audits nothing. Be sure to audit all failed operations, as well as low-frequency successes.
screen_link (32 Kbytes)
Disconnecting NetBIOS, Server, and Workstation from the TCP/IP stack guards against many NBT-based over-the-Internet attacks.
Jon Udell is BYTE's executive editor for new media. You can reach him by sending e-mail to
jon_u@dev5.byte.com
.
NT Security
