Network Defense by Rik Farrow The classic defense posture might save your job! I was scanning a Web site recently, and discovered that not only was it an NT system, but it was configured pretty much like any other NT server. I have discoverd similar problems on UNIX-based Web servers (which far outnumber the NT-based servers on the Web). Every service that appears when a system is scanned provides an opportunity for an attacker. If there are no services available, the prospects for an attacker are slim, essentially reduced to denial of service. But, in the case of the system just scanned, it was ripe for pillage. Many of the consultants that I know report finding the same problems. Asked to do a "penetration test" of a Web site, they often find that the system has not been hardened at all. In just a few minutes, they have enough information to stop the test, and send a report back to the client telling them of the failure of the target to resist attacks. This column describes steps you can take to harden an NT Web server. Rocket Science Hardening a server is not rocket science, but it is not that simple either. The place to start is by scanning any servers that you consider at risk. Certainly, any servers that appear outside of your firewall, or any servers on any network directly connected to the Internet and not protected by a firewall are at risk. You can use commercial tools, such as ISS in port scanning mode, but I recommend that you try the more hacker-oriented tools, such as strobe or nmap. If the system you want to harden is an NT system, you have a difficult time ahead of you. NT is very chatty on the network, and Microsoft's method for integrating NetBIOS into TCP/IP has made it more difficult to know what services you can safely disable--that is, without seriously damaging the usefullness of your server. Default, out of the box file permissions (ACLs), also need to be tightened. Let's imagine that you have an NT server running IIS, and it is sitting right where I would like you to have it--on its own subnet, protected by a firewall (Figure 1). The only services visible from the Internet are HTTP and SHTTP (TCP ports 80 and 433). You manage this system from your internal network, which is reached through a different network interface on the firewall. The firewall only permits your management connection from your internal network to the partially exposed Web server. While this sounds pretty good, there still may be problems here. For example, how is the Web server being managed? If you are using SMB for file sharing, you have opened up the most useful vulnerability for breaking into an NT system. Even though the firewall should prevent access to TCP ports 135 and 139, and UDP port 138 (used by SMB and remote procedure calls, RPC), are you certain that the firewall will continue to be correctly configured? Also, if there are other systems sharing the same subnet as the Web server, they could potentially be used to break into the Web server using SMB. You can disable most of the service on an NT server and still keep IIS running. Table 1 lists services that should be disabled to harden an exposed NT system. These services should be disabled, and stopped unless you plan on rebooting your NT server. You will largely cripple the NT server for normal use--but this server is not intended for normal use, but as an server exposed to any person anywhere in the world. And it will work fine as a Web server, just don't expect it to perform domain authentication. The server should be configured as standalone (it could also be a domain controller, but why bother). Even a server defended by a firewall should have all unnecessary services disabled. Use the Service Manager, in the Control Panel, to disable these services. Remotely Available If you can't use file sharing to manage the Web server, what can you do? Microsoft products provide you with several methods for remotely managing IIS, such as Internet Service Manager (ISM), FrontPage, and the Web administration feature in the Option Kit. There is also FTP. All of these present some problems. First, if you have disabled the services I suggested, ISM will no longer work remotely. And ISM is more designed for starting or stopping IIS, so doesn't help with mananging content anyway. You use FrontPage to design and manage Web content, but can have configuration problems as well. Visit the Rhino9 Web site, and check out WarDoc, and long explanation of penetration testing of NT servers, with a section on how to use FrontPage. At the end of February, postings appeared on the Bugtraq full-disclosure mailing list about an exploit that uses the Option Kit to guess passwords on an NT Web server with the kit installed. The default installation is incorrect, and can be changed. But, to use this feature, you will need NTLM authentication (which you can do by managing local accounts on the NT server). The problem with FTP is that the protocol sends passwords as plaintext across the network link. Tools for sniffing passwords focuse on collecting plaintext passwords, so this is not accessible. If the environment is really hostile, Microsoft challenge-response is not that safe either, as their are tools for collecting the challenge- response sequences, and for cracking passwords based on the captured sequences. One secure technique is known as the "sneaker net". You hand carry a Zip drive with updates to be installed on the Web server, insert the drive, and login at the console. You have opened no network vulnerabilities with this low-tech technique, and have very fine-grained control of what goes on, if you limit you has accounts on the server. Let's suppose that you cannot use the ideal setup I suggest in Figure 1. Instead, your NT Web server is being hosted by your Internet Service Provider (ISP). You now do not have physical access to your system, or physical control over it either. Having physical access to any computer system makes it easy to compromise (by rebooting it using a floppy disk containing DOS or Linux, in the case of NT). You can guard against this physical access by removing the floppy drive, or more simply, removing the floppy drive from the list of boot devices, and then password protecting the systems CMOS to prevent this from being changed. I have discovered sites using PC Anywhere to remotely manage NT Web servers. PC Anywhere is not designed as a security tool, but as a convenience tool. If you are concerned about security, do not connect a modem that accepts incoming calls to any sensitive system. Modems are the classic method for breakin, and modem scanners, such as war dialers (or commercial products such as Phone Sweep) are designed to discover modems. A much better technique for remote administration is to use a VPN product. By having an encrypted tunnel between the hosted Web server and your internal management system you can safely administer to and update the Web server. You can even use FTP through the encrypted tunnel, and not worry about passwords being sniffed. Even if your Web server is behind your own firewall, a VPN is still a good solution. A possible solution is to use Microsoft's PPTP for the VPN tunnel. PPTP in its original form had some serious security problems--a sniffed PPTP connection could be used both for cracking passwords, and for decrypting the encrypted communication if the password is cracked (see the Counterpane resource). Microsoft has announced patches (see Microsoft Security bulletin 98-12). These patches fix most of the problems described in the Schneier-Midge paper, but still leave PPTP servers open to denial of service attacks, slower but still possible password cracking, and will only work when 128 bit encryption is used. Batten Down the Hatches You will also want to tighten the deafult security expressed by ACLs and ownership of files and directories. The Security Configuration Manager that is part of Service Pack 4 can help here, as well as the suggestions found at the Trusted Systems Web site. At the very least, remove Full Control access for the Everyone group on critical directories and files (those containing commands, DLLs, parts of the NT system, etc., as well as files and directories within IIS hierachiy itself). You might find these suggestions a bit extreme. But Web servers are common targets for attacks, and are often attacked successfully. The 1999 CSI/FBI Computer Crime and Security reported that 20% of respondents had intrusions or incidents involving their Web servers (and an astonishing 33% didn't know if they had had a Web-related incident). If you follow these guidelines, your NT system will be more difficult to manage, but also much more difficult to break-into. Resources: The Rhino9 site has a paper (WarDoc) about penetration testing of NT systems using off-the-shelf NT and the Resource Kit. They also offer some of their own tools: http://rhino.techotronic.com/, under textware. Bruce Schneier and Dr. Mudge collaborated on a paper published last Summer on weaknesses in PPTP: http://www.counterpane.com/ Microsoft responded with a set of patches and upgrades which address some of the problems listed in the Schneier-Mudge paper: http://www.microsoft.com/security/bulletins/ms98-012.htm "Windows NT Security Guidelines" that Trusted Systems produced for the National Security Agency, and source for Super CACLS scripts for adjusting permissions: http://www.TrustedSystems.com/fm_Signup.htm Press release about the 1999 CSI/FBI Computer Crime report, and how to get a copy of it: http://www.gocsi.com/prelea990301.htm Table 1: Recommendations for Disabling Services for Hardening an exposed NT Web server (R means Required by IIS or NT, D means disable, and O stands for Optional) Service Name Status Description Alerter D Notifies selected users and computers of administrative alerts; requires the Messenger service ClipBook Server D Supports ClipBook viewer; requires Network DDE (sharing of clipboard images remotely) Computer Browser D Maintains a list of network accessible computers, and provides this list to programs when requested (for example, Select Domain) DHCP client D Used to negotiate a TCP/IP address; should not be used by servers Directory Replicator D Replicates directory trees between computers EventLog R Records system, security and program events in logs FTP Publishing O Part of IIS, only start if you plan to use this; can be used (with strong authentication) for remote Web file management Messenger D Sends and receives messages sent by the Alerter or by administrators NetLogon D Performs authentication and keeps domain data synchronized on DC; on NT workstation supports authentication Network DDE D Network transport for Dynamic Date Exchange (DDE) Network DDE DSDM D Manages DDE transactions (DDE Share Database Manager) Network Monitor D Monitor network traffic, the SMS version can see all packets on the local network segment, and can be used remotely NTLM Security Provider R NTLM support for RPC services which do not use named pipes, required for local logon Plug and Play D Can be disabled after hardware configuration RAS D Only enable if system is used as a router or for modem dialup RPC Locator D Manages the RPC name service database; servers register their availabilty and clients locate servers RPC Service R Provides endpoint mapper and other miscellaneous services; required and more secure when other services are disabled Schedule D Enables the AT service (which can be used remotely) and runs as System Server D Used for SMB. and provides RPC support, as well as print and named pipe sharing Simple Services D Chargen, echo, discard, and daytime; unnecessary and possibly harmful (Denial of service and probes) SNMP D SNMP agent, useful in probes SNMP trap O SNMP traps, a client Spooler D Provides print spooling service TCP/IP NetBIOS D Works with transporting NetBIOS over TCP/IP Helper UPS O Monitors uninterruptible power supplies Workstation O The client side of Server, harmless World Wide Web R The IIS Web server Publishing Service [end]