Threats to your information systems are everywhere. If you don't know about the threats, just spend a few days at a security conference to learn about hacking, cracking, spoofing, and sniffing--the activities of underground pranksters, hardened criminals, industrial spies, and international terrorists who want to break into your systems for profit and pleasure.
At the recent NetSec '96 conference in San Francisco, Len D'Alotto of GTE Laboratories told a story that I'll paraphrase: Two friends are walking across the African plains. They see a lion heading their way. One friend stops to put on a pair of running shoes. The other says, "You can't outrun a lion!" The first says, "No, but all I need to do is outrun you." Similarly, the best way to discourage intruders is to tighten security at your site so they leave you alone and pursue easier prey. Then again, the challenge of breaking your security may be too much for a confident hacker to resist.
How do intruders break into your Windows NT system? The Administrator account is the first target, for two good reasons: It has unlimited privileges, and you need the passprop.exe utility that comes with the Windows NT 4.0 Resource Kit if you want to lock out network access to the Administrator account. If intruders can't break in through the Administrator account, they will enter through authorized means and then find holes in some service and get more privileges to your system. For example, attackers look for holes in a service that runs under the System account. Unfortunately, you never know what new holes hackers will find and exploit. But, you can prevent many attacks on your system by protecting your Administrator account, limiting services, and understanding weak spots in NT's file- and printer-sharing services.
Administrator Account Break-ins
A typical attack comes from someone who knows the Administrator account name and attempts to log on to that account. You did change the Administrator account name to something obscure, right? Your best protection is to change the name of the Administrator account to include a long string of alphanumeric characters and no discernible words.
As additional protection, through the Account Policy option in User Manager, set lockouts on all other accounts. Assume an inside user is attacking an NT server. To avoid lockout, internal attackers will collect user account names and occasionally attempt logons over extended periods.
Despite such measures, the Administrator account is a hacker's best target. How can hackers learn the Administrator's name if you rename it? A hacker can collect account names in the hopes of uncovering the Administrator. For example, one way to collect names is to run the nbtstat command to get statistics about NetBIOS over TCP/IP. Assume you are an internal hacker and type the nbtstat command as shown here, replacing <ipaddress> with the IP address of any computer that the Administrator is logged on to (an internal hacker can easily observe which computer the Administrator logs on to and figure out a few logical steps to discover its IP address).
NBTSTAT -A <ipaddress>
Screen 1 shows the result--a list of account names a hacker can use to guess the Administrator's account. On my internal network, I renamed the Administrator account to TOPGUN, and you can see this name in the list. The command will not show an Administrator logged on to the primary domain controller (PDC)--a good reason to have your Administrator log on only at the server console of such machines. However, if the Administrator is working at some workstation on the network and an internal hacker happens to notice, the hacker might just run the nbtstat command using the IP address or computer name of that workstation to view the Administrator's renamed account.
nbtstat also accepts NetBIOS names such as those you see in Network Neighborhood (type NBTSTAT-a<name>). Granted, this technique won't always work, but it shows that the Administrator name is generally available to someone who knows where to look. If intruders discover the account name, they can attempt to crack the account. If the account has weak passwords, intruders can break in eventually.
Try this. Go to a Windows workstation on your network and log on as Administrator, but assume you don't know the password. Type in the wrong one. When that fails, try another password. Keep trying as long as you like. Now consider how easy it is to write a program that repeats those keystrokes and tries passwords from one of the password dictionaries available on the Internet.
Meanwhile, the Event Log on your server is filling with failed logon attempt messages, if you took the security precaution of enabling Failure for the auditing feature Logon and Logoff. To set this option, open User Manager and choose Audit from the Policies menu. Now you just need to look in Event Viewer every so often to see whether someone is trying to break in. If you want the server to notify you of repeated attempts to break in, you can set alarms.
If the inability to lock out the Administrator account worries you, you can just have the system shut down in the event of a continuous attack. If your system does shut down, perhaps your attackers have achieved their goal: a denial-of-service attack that prevents legitimate users from accessing your system. Nevertheless, you're better safe than sorry.
To set up shutdown instructions, open Event Viewer and choose Log Settings from the Log menu. Then reduce Maximum Log Size so the log fills quickly. You must set the option Do Not Overwrite Events, and you need to set an option in the Registry. You can find this procedure at Microsoft's Knowledge Base Web site (www.microsoft.com/kb) by searching for document number Q140058. When the log fills, you get a warning and the server shuts down.
Another intruder attack can come from an NT user who targets the administrative share accounts on your servers. Administrative shares are default accounts that you cannot permanently remove. The system creates these accounts for the NT root directory and for the root of each disk partition. The shares have a dollar-sign suffix (c$, d$, winnt$) and are usually not visible to users. However, a malicious user on your network can open the Run dialog and type something like \\<server
name>C$, which brings up the dialog in Screen 2. Now the user can type the Administrator's account name in the Connect As field and enter a guessed password in the Password field to keep guessing as long as necessary.
These examples give you an idea of what your system is up against. Fortunately, you can easily stop these attacks by preventing all Administrator logons from the network. But what about remote logon?
Disable Remote Server Administration
Think about this: Why let an Administrator log on to a server from a remote location? That capability compromises security too easily. What if someone installs a camera to videotape the logon? It has happened. Is the logon computer trusted? What if someone installs a Trojan horse program to capture passwords?
To prevent all potential break-ins from the network into any Administrator account, require all server administration to take place at the server console. Revoke network logon privileges for the Administrators group. Open User Manager, click User Rights on the Policies menu, and remove the Administrators group and the Everyone group from the Access this computer from the network right.
Removing Everyone means you must add back the users and groups who need network access. For example, create a new group called Network Users, and grant it the Access this computer from the network right. Then add appropriate members to the group, but don't add administrative accounts.
Now that you've tightened the security of your servers and increased the difficulty of breaking into them, upper management might be concerned about what to do if you are suddenly unavailable. You can create a backdoor, fail-safe password. Pick three trusted people in the company, and give each one a piece of a three-part password. If the password is StudebakerHawk, the first person gets Stude, the second has baker, and the third has Hawk. If you're absent, this scheme provides accountability: These three people must get together to enter the password and provide access to the server with administrative privileges. (By the way, StudebakerHawk is a poor password choice because it contains recognizable words and no numeric characters.)
Create a Decoy
After you rename your Administrator account, create a new decoy account called Administrator. If hackers target your system, they will try to break into the fake Administrator account.
If you track failed logon attempts in the auditing system, you'll see illicit activities. If the hackers are internal users, you'll know which workstation they are using. But don't be quick to accuse the person at that workstation. Someone else can access it to attempt break-ins. Also, be aware that you can't legally monitor a person's activity unless you post notices that all activities may be monitored. Put this notice in employee contracts.
Limit Services
An anonymous user in a chat room asked, "Would you pay $5000 for a completely bug-free version of Microsoft Word?" Good question. As large teams of programmers rush products to competitive markets, bugs and holes are inevitable. When putting a program through test loops, programmers bypass certain functions, such as security checks, to accelerate the tests. But what if programmers leave in the bypass mechanism by mistake and the program goes to production? Or what if the designers didn't fully understand the security requirements? In NT, this scenario is particularly dangerous because applications can run as services and you can access services over the network.
Unfortunately, hackers know how to find and exploit such holes. Sometimes such discoveries become widely known. Sometimes the hacker guards discoveries like trade secrets to prevent vendors from plugging the holes.
When connecting to untrusted networks such as the Internet, your best strategy is to run as few services as possible and to run them under an account with as few privileges as possible. To configure a service, create an account for the service to log on to with only the rights and privileges that the service needs. Some services can run only under the System account. The software vendor can tell you which areas of the system the account needs to access.
After creating the account, open Services in the Control Panel, select the service you want to configure, and click Startup. Add the new account to the field This Account in the Service dialog pictured in Screen 3, and type the appropriate password. Now if hackers infiltrate the program, they will have only the privileges you assigned to the special account. In this example, the Directory Replicator service logs on under the RepAdmin account, which has fewer privileges than the System account.
Secure Services
The NT file- and printer-sharing system is the Server Message Block (SMB) protocol. NT implements SMB as the Server and Workstation service (and indirectly as the NetBIOS service). SMB has some security problems that internal users or Internet users can exploit if you're connected to the Internet. Session hijacking can occur, where a "man in the middle" manages to masquerade as the real client and takes over the session. SMB's sharing features can cause security violations if someone uses them inappropriately. SMB also exposes the Ad-
ministrator account to attack by hackers who try to log on to administrative shares, as discussed earlier.
SMB servers connected to the Internet can provide an interesting file-sharing solution. For more information, check out the Winserve Web server at www.
winserve.com. Follow the instructions there for configuring your system to connect with an SMB site over the Internet, then try connecting to Winserve's experimental Windows 95 shared directory. Open the Run dialog and type \\win
server95\guest. However, be aware that an SMB file-sharing system connected to the Internet is relatively easy for hackers to exploit. If you use an NT system as an Internet-connected Web server, your best bet is to turn off SMB file sharing.
I was curious about security on Internet-connected SMB servers, so I tried connecting to the administrative share at Microsoft's SMB share site, which is called \\ftp. I opened the Run dialog and typed \\ftp\C$. Sure enough, a logon dialog popped up similar to Screen 2. I suppose I could have tried cracking the password, but the site is probably tough to crack. If you set up such a system, make sure you take the steps described earlier to protect your administrative accounts from hackers.
This scenario shows the potential for people on the Internet to break into your site if you use SMB file sharing. Be careful connecting any internal system to the Internet or to another untrusted network. If you share folders, disable the Guest account and require logon with strong passwords. Then check the permissions for the folders, especially if the Everyone group has access to those folders. Consider removing the Everyone group's access to folders and reassigning access to specific groups.
SMB makes your shared folders available to Internet users. This access is not necessarily bad if you've adequately protected the folders and the computer is a standalone system. However, if one of your network clients connects to the Internet with sharing enabled, the client creates a potential backdoor into your TCP/IP network. Savvy administrators ban internal modems and provide Internet access only through a firewall-
protected network connection.
Consider SMB Alternatives
Microsoft and several other vendors recognized the security limitations with SMB and developed an enhanced SMB: Common Internet File System (CIFS). CIFS provides user authentication, file locking, data sharing, and file-level security; Microsoft will soon release an NT version. Other alternatives to SMB include NetWare Core Protocol (NCP) for NetWare environments and Network File System (NFS) for UNIX environments, although numerous security problems exist with these file systems.
To avoid SMB's insecurities, consider an alternative file-sharing system, such as TCP/IP-based Internet and intranet services. Many organizations have already replaced their traditional inhouse file-sharing systems with Web servers. This transition is easy because users are already familiar with Web browsers. Web servers let you view information in a graphical format, click buttons to access hyperlinked documents, and download documents. You can also run programs and query databases from Web browsers. In addition, new encryption and certification options in Web browsers such as Microsoft's Internet Explorer (IE) let you implement secure client-server transactions that hide data transmissions and authenticate certified users.
The next major release of Win95 and NT will implement a user interface that looks and operates like a Web browser. With it, you can work with files anywhere--on local systems or the Internet. Security will also improve. For example, when you access Microsoft Web servers with IE, the following security options are available.
- Microsoft challenge/response authentication to securely log on users to user accounts
- Secure Sockets Layer (SSL) to encrypt transmissions between client and server
- Digital certificates (available as an add-on in late 1996) to authenticate people (for information about certificates, connect with www.verisign.com)
- IP address filtering, and in the Microsoft Internet Information Server (IIS), port filtering to block services (except for Web services on port 80)
That's a lot of security. But what kind of file services does a Web server such as IIS offer? Screen 4 shows a basic example, with a directory listing as seen from a Web browser. The file list is hyperlinked, so you can click a file to open it. You can also right-click a file to display the context menu pictured in Screen 4 and then copy files to your workstation.
Web servers provide spiffy graphics and hyperlinks and also provide a file service that is similar to but easier to use than an FTP server. You can use a Web server for simple file distribution, and future enhancements by Microsoft will let you use it as a full-fledged network file system that operates on your internal network or over the Internet with a high level of security. To secure the server, remove SMB bindings, disable unnecessary services, enable authentication and SSL encryption, and optionally use certificates. But these are topics for another article. *
| RELATED ARTICLES |
|
Jon Honeyball,
"The Road to Cairo Goes Through Nashville," June 1996 Lawrence E. Hughes, "Digital Envelopes and Signatures," September 1996 Michael D. Reilly, "Find Holes in Your NT Security," October 1996 Philip Carden and Charles Kelly, "Firewalls: Securing NT Networks from Internet Intruders," November 1996 Jonathan J. Chau, "Internet Explorer 3.0," November 1996 Mike Otey, VB Solutions, page 143 |
