Web Security for NT Servers by Rik Farrow and Richard Power Windows NT has become a popular Web server, especially for intranets, for all the wrong reasons. NT has a reputation for being easier to manage than comparable UNIX servers, and this is true to a point. Other aspects of NT servers, such as domain authentication and file sharing, also have made NT an attractive choice. And sometimes, the wrong choice. It is possible to make an NT Web server more secure, but it involves disabling some of the very features which make NT so attractive. We will look at NT as both an intranet and an Internet Web server, and suggest ways to harden the server against attacks. Easy Pickings Web servers have a high-profile, whether internal or exposed to the world. And Web servers have often been the targets of successful attacks. U.S. Department of Justice, Central Intelligence Agency, Yahoo, and Fox have been some of the well-publicized attacks on public Web servers. Dan Farmer used an (as yet) unreleased version of his SATAN scanner to probe firewalls, and found that nearly two-thirds had serious security vulnerabilities (see resources sidebar). Another automated scan by the infamous Phiber Optic scored thousands of successful probes yielding encrypted UNIX passwords. Sometimes, the reason why a Web server was broken into is very simple. In one organization, an NT intranet server was moved outside the firewall and used as an Internet server with no configuration changes. And many Web administrators are still unaware of how Web servers become vulnerable to attacks. The UNIX community has both many years of experience and much expertise in hardening UNIX systems. That same level of experience is sorely lacking in the Microsoft world. Although Windows NT servers have yet to suffer the volume of successful attacks that UNIX servers have, the vulnerabilities are there. And there are some simple things you can do to prevent problems. Control Your Data Windows NT has a marvelous system that provides fine grained control over file and directory access. For example, you can permit a group to have access, while denying one member of that group access. You use access control lists (ACLs) as the first step in securing your NT Web server. Before we can discuss ACLs, we must back up a minute and explain which user has access to the Web server files. For purposes of discussion, we will be using Microsoft's own IIS server. Note that if you are using this server, you should have applied both Service Patch 3 and the hotfix for IIS. Without the patches, any user can read the source to your script files by appending a dot (or %2e) to the end of the filename. IIS provides three methods for authenticating accessto to your Web data; anonymous, clear text basic logon, and Windows NT Challenge-Response. Most Internet servers provide only anonymous access, which on IIS servers is mapped by default to the IUSR_machinename user account. Machinename will be replaced with the NetBIOS name of the NT server. Installation of IIS adds this account (which is also used by default by the FTP and Gopher services). The IUSR_machinename account must have the User Right to Logon locally. No other rights are necessary (or appropriate). You can create and use a different account, as long as you use the Internet Service Manager (ISM) to set up the username and password for this account. Choose a nice, random, password for this account, and enter the same password using the ISM. This account is not required to be in any groups. Files and directories within the document root, \InetPub\wwwroot\ by default, should have read and execute permission only for the IUSR_machinename account, and Full Control for the group (or user) which will be administering the Web server files. Often, this group will not be Administrators, but will be a special group created just for managing Web content. You can use Explorer to select the document root, Properties, Security Tab, Permissions button, to adjust the ACLs. Remove access to Everyone if you plan on having anonymous access only. Or change access for Everyone to Read (as opposed to Full Control, which is the default configuration on many NT systems). Clear text basic login is not recommended for authenticated access. Clear text authentication means that the user name and password are sent unecnrypted (clear text), which can be sniffed and easily captured--especially in intranets, although also over the Internet. NT offers a third choice, using challenge-response authentication. This is similar to NTLM, except that it happens via the the HTTP connection instead of over file sharing connections. The upsides to challenge-response are that it provides a safer way of transporting user names and passwords across the network, and it permits you to set up your Web server files and directories with permissions controlling which files the Web client can see. Challenge-response authentication will be attempted automatically if the anonymous user account does not have access permission to the requested resource. The downside of this is that every user who must be authenticated must have either an account on the Web server, or must be able to authenticate through the domain controller. In the case of domain users, you probably do not want outsiders to have accounts in your domains. Using NT challenge-response authentication can work well for intranet NT Web servers, as long as all the users who must have access to Web resources belong to the same domain as the Web server. Bastion Host The bastion host concept means that you have fortified your server by _removing_ unnecessary user accounts and services. On an NT Web server, it is best to limit the server to _only_ acting as a Web server. On any well-used Web server, this one task will consume more than enough system resources without trying to support other users and services. If your Web service is designed to work with a backend database, locate it elsewhere on the net. This is not only for performance purposes, but for security as well. Allow no network user accounts, and only local accounts for Web administration. On an intranet Web server, you might permit network accounts for Web admininstration, depending on the sensitivity of the information stored on the system. NT servers include many wonderful services--most of which are not need for server Web resources. You can disable these services, in particular, file and print serving for Internet exposed Web servers. The file sharing service is called, quite simply, Server. You might consider permitting access to file sharing on an intranet NT Web server, again depending on the sensitivity of the data made access through the share. A detailed paper on ways of attacking NT servers using the SMB/CIFS protocol is available at http://www.avian.org/. There are many other default services (see Table 1). One you will want to disable is Simple Services, a set of TCP/IP services such as Echo and Character Generator (chargen) used in debugging TCP/IP setup. Echo and chargen have been used together in denial of service attacks. Simply serving up files will not be enough for most Web servers. Web servers can received and process information from Web clients, typically collected via forms. One method for processing form data is by using the Common Gateway Interface, or CGI. CGI is the number one method of breaking into Web servers--not because CGI is itslef flawed, but because the scripts used to process user input often have subtle programming problems. CERT (see resource section) has put out four advisories relating to Web and CGI security in 1997 alone. The most common trouble with CGI scripts involves incorrect handling of user data. Crafty hackers send unexpected input, which can result in commands being executed at the hacker's whim. IIS and NT servers also support ISAPI (Internet Server Application Programming Interface), which so far has proven to be safer against these attacks. Another problem with CGI scripts (also called 'agents' on NT systems), is that they may use interpreters such as CMD.EXE or Perl. Never put these interpreters in scripts directories. An older version of the Netscape Communication server included Perl in a script directory, permitting anyone to execute the Perl commands of his or her choice on the Web server. Scripts (or agents) must be readable and executable by the Web user (IUSR_machinename). Firewalls Another line of defense is to put your Web server behind a firewall. For intranet servers, of course, this makes less sense (although some form of firewalling can still be useful). In the [insert month] column, we suggested placing an Internet Web server in its own subnet protected by your firewall. Even the simplest of firewalls, packet filters and stateful packet filters, can reduce your risk enormously by limiting access to the server. On an intranet NT server, you can use packet filtering to help protect your server. NT includes a simple form of packet filtering configured by selecting the Protocols Tab of the Network control panel applet. Double click on TCP/IP, and select the Advanced button at the bottom of the dialog. The IP Address panel includes a checkbox at the bottom for enabling security, and a button labeled Configure. Clicking on Configure gets you to a menu which lets you control which packets pass through the packet filter. Control here is primitive--you cannot, for example, permit or deny a range of ports, or even specify ports by name. In the IP protocols selection, you must know the protocol number as used in the IP header, and specified in RFC 1700. Still, you can do something with this. For example, Web servers by default listen at port 80. By permitting only packets addressed to port 80 through the TCP filter, you have denied (by default) all other TCP/IP application protocols. You might also want to support port 443, used by SSL. Now, only new connections to ports 80 and 443 will be passed by the packet filter. Outgoing connections will still work, but local use of an FTP client will not function completely, as FTP clients (the included NT client uses active mode) must be able to receive a connection _back_ from the FTP server to transfer data. The FTP client included in Web browser works in passive mode, and should not have this problem. Note, that this only protects you from TCP/IP-based attacks. NT also supports both NetBIOS and Netware protocols, although only Netware is actually routable (and can pose a threat of remote attacks). You want to disable other protocols by removing these protocols using the Bindings Tab of the Network applet. Web servers use only TCP/IP, so you won't disable your Web server by doing this. Note that domain authentication may be affected, however, if you are using it. But you will stop a lot else from happening. File sharing uses NetBIOS by default, although it will also use TCP/IP (ports 137-139). Domain authentication also uses NetBIOS or secure channels over TCP/IP (port 138 and 139). By permitting only TCP/IP to be bound to your network adaptors, you have disabled two important NT network applications. You have also blocked remote registry editing, which also uses secure channels. By now, you can see that making NT Web servers as safe as possible involves disabling many of the features which make NT an attractive platform. Knowing which services to disable, then managing a mangled NT server is not trivial, which is why NT may not be the ideal Web server for you. Consider using UNIX Web servers if you already have UNIX expertise (in some cases, UNIX outperforms NT Web servers by over 50%). And if you are working in a Microsoft shop, be cautious in setting up your Web servers. A little caution will be prevent many headaches later. Resources: Lincoln Stein's Web Security FAQ: http://www.genome.wi.mit.edu/WWW/faqs/ CERT Advisories: ftp://ftp.cert.org/pub/cert_advisories (in particular, see CA-97.07, CA-97.12, CA-97.24, and CA-97.25, all Web-related and within the last year) Dan Farmer's report on Web vulenrabilties in prominent public servers: http://www.trouble.org/survey/ Hobbit's paper on attacking NT/Win95 systems using SMB/CIFS: http://www.avian.org/ Examples of hacked Web pages: http://www.hacked.net/exp/com/yahoo/ http://www.news.com/News/Item/0,4,17931,00.html http://www.news.com/News/Item/0,4,17266,00.html [RIK NOTE THIS: ssm-1.0.4 uploaded to sunsite.unc.edu available on ftp.bizsystems.com/pub/secure ssm (Secure Shell Mirror) is a secure shell script written in Perl5 that mirrors the contents of a local host to a remote host. It is intended to provide a recursive transferr or 'put' of ] Table 1: Descriptions of NT Server Services Alerter -notifies selected users and computers of administrative alerts; requires the Messenger service ClipBook Server - supports ClipBook viewer; requires Network DDE (sharing of clipboard images remotely) Computer Browser - Maintains a list of network accessible computers, and provides this list to programs when requested (for example, Select Domain) DHCP client - Used to negotiate a TCP/IP address; should not be used by servers Directory Replicate - Replicates directory trees between computers EventLog - Records system, security and program events in logs FTP Publishing Service - Part of IIS, only start if you plan to use this; can be used (with authentication) for remote Web file management Messenger - Sends and receives messages sent by the Alerter or by administrators Net Logon - Performs authentication and keeps domain data sysnchronized on NT server; on NT workstation supports pass through authentication Network DDE - Network transport for Dynamic Date Exchange (DDE) Network DDE DSDM - Manages DDE transactions (DDE Share Database Manager) NT LM Security Provider - NTLM support for RPC services which do not use named pipes Remote Procedure Call (RPC) Locator - Manages the RPC name service database; servers register their availabilty and clients locate servers RPC Service - Provides endpoint mapper and other miscellaneous services Schedule - Enables the AT service (which can be used remotely) Server - Provides RPC support, as well as file, print and named pipe sharing Spooler - Provides print spooling service TCP/IP NetBIOS Helper - Works with transporting NetBIOS over TCP/IP UPS - Monitors uninterruptible power supplies Workstation - The client side of Server World Wide Web Publish Service - The IIS Web server