In Remote Web Administration, Part 1, we stated that colocating your Web server on an Internet Service Provider's (ISP's) network is the most cost-effective method to improve Web site performance. Part 1 explored configuring and monitoring a Windows NT Web server. In Part 2, we discuss how to access the Web server remotely for administration and how to secure the server from attacks.
Remote Access
To administer your Web server, you must be able to access it remotely. You can access a remote Web server in two ways: remote node and remote control. Both methods are important for remote management. Remote node access lets the management station access the remote Web server as if the server is on the same network as the management station, whereas remote control provides local access to the remote Web server's hardware.
Remote node/RAS. With remote node access, the remote server acts as the Remote Access Service (RAS) server, and the management station acts as a RAS client. The RAS client connects to the RAS server through an asynchronous, X.25, or ISDN connection (out-of-band connection) or through the Internet with a Point-to-Point Tunneling Protocol (PPTP) connection (in-band connection).
Out-of-band connections are essential to effective remote management. In most cases, a 28.8Kbps modem is adequate for an out-of-band connection. Although for best performance you will want to use NetBEUI as the primary connection protocol for out-of-band management, in some cases TCP/IP is important as well. For example, if you establish your Simple Network Management Protocol (SNMP) connection through RAS, you must enable TCP/IP to establish a Windows sockets-based connection for SNMP. Your ISP must provide IP addresses for the RAS server or a server address for dynamic IP address allocation.
RAS provides all the Server Message Block (SMB) connections and Windows socket connections you need for remote Web administration. NetBEUI provides access to files and folders, and provides network browser services to access computer and share names. For security purposes, NT disables network browser services over TCP/IP on all network and dial-up adapters in the Web server.
For remote access redundancy, you will want to use PPTP to establish your RAS connection to the Web server. First, connect to the Internet, and then use PPTP to connect to the server. Because you connect to the Web server over the Internet, you don't need any asynchronous, X.25, or ISDN hardware.
PPTP encapsulates NetBEUI or IPX/SPX packets in IP packets. If you configure security properly, the encapsulated packets contain encrypted data that the RAS server authenticates and de-encrypts before providing access. However, keep in mind that encapsulation overhead and Internet congestion make using PPTP over the Internet cumbersome at speeds less than 128Kbps.
Remote control. After you establish a RAS connection, you can use third-party tools to control the Web server's monitor, keyboard, and mouse. This remote control capability is a crucial augmentation to RAS. While RAS provides network access to the Web server, remote control provides local access to the server's hardware. Remote control lets you install and run applications on the remote Web server. For example, if your backup software is on the remote Web server, remote control lets you view the backup management console. You can also install backup software updates directly on the remote Web server via a remote control session.
For many remote control packages, RAS is not the only way to connect to the server. For example, Computer Associates' ControlIT (formerly Remotely Possible) connects to the server using the Internet or a modem connected to the server; RAS is not involved in either type of connection (for more information, go to http://www.cai.com/). This approach provides redundancy if the RAS server fails. (For reviews of seven other remote control software packages, see the December 1998 issue of Windows NT Magazine.)
Bandwidth considerations. Remote access performance is crucial to a successful management strategy. Pure remote node access to server resources does not perform well over slow bandwidth connections, and adding PPTP over the Internet to RAS only exacerbates the problem. Products such as ControlIT can optimize slow bandwidth connections.
To take advantage of redundant connection methodologies, you must have at least 56Kbps access. ISDN is ideal for establishing a 56kbps or 128kps connection for remote management if a dedicated connection at higher speeds is not available.
Initially, we remotely accessed our Web server through a 3Com ISDN terminal adapter. However, performance was unacceptable and idle remote connections did not disconnect even when we configured these connections to drop if idle. Because we pay our ISDN fees by connect time, we were paying for the idle connections. We switched to a CiscoPro ISDN router to solve our remote access problems. The router drops idle connections more effectively than idle time settings in RAS, and the performance, even over one 56Kbps B channel, is excellent.
The ISP that hosts our Web server doesn't support remote ISDN or asynchronous connections to the Internet, so our ISDN router connects to another ISP that supports these connections. For Internet-based remote management, the ISDN router uses ControlIT for remote control and file transfers. RAS connects to the Web server out-of-band using 33.6Kbps modems and NetBEUI. We can use PPTP for Internet-based in-band connections using our modems, but performance is slow, even at 33.6Kbps. Table 1 lists remote-administration tasks and the tools we use to perform them.
Security
Security is a major concern when managing Web servers connected to the Internet. Regardless of your company's size or the sensitivity of your data, you must always follow certain security guidelines. Above all, be diligent about monitoring your system and reviewing logs for indications of attacks.
IIS and NT security. Depending on how you configure your Web server, Internet users can connect to it anonymously (public access) or through a secure connection (private access). Private access requires user authentication--either NT LAN Manager (NTLM) or basic authentication. Support for secure access using NTLM authentication is browser-dependent, so using both NTLM and basic authentication is important for browser compatibility.
Most private, custom authentication schemes use either an Internet Server API (ISAPI) filter or scripts and a mechanism such as HTTP Cookies or Active Server Pages (ASP) sessions. Fortunately, Internet Information Server (IIS) supports public, private, and mixed access. For example, our Atlas Online University (http://www.atlasu.com) training system supports mixed access. The Web server maps HTTP requests through the custom ISAPI filter, whereas other Internet services use NT accounts.
Before you configure user access to your Web server, you must have a secure NT installation. The Web server's boot partition is the volume containing the operating system (OS) files. The boot partition must contain only OS files and must be separate from other volumes containing data you publish to the Internet. To secure the OS files, you need to format the boot partition for NTFS. For additional security, install NT into a directory with a nonstandard name. Nonstandard directory names make determining the location of OS files harder for hackers.
Installation of NT and IIS creates several user accounts that you must reconfigure for secure Internet access. You must rename some of these accounts and disable others. If you don't take the following measures, hackers will be one step closer to breaking into your Web server. By default, NT Server disables the guest account and NT Workstation enables it, so you must verify that the guest account is disabled. You can't delete this built-in account, but you can rename it for additional security. You must also rename the built-in administrator account. Make the new username and password long, and add nonalphanumeric characters to both. Passwords can't be more than 14 characters long, but they are case sensitive, so use a combination of upper- and lowercase characters. Next, create a dummy account named Administrator, and make sure this dummy account has no rights to the server. A dummy Administrator account will keep hackers tied up trying to crack a worthless account.
IIS creates a user account, IUSR_computername, which is the proxy account for anonymous access to all Internet services configured in Internet Service Manager (ISM). If hackers guess your server's computer name, they will know the name of this NT account. If you allow anonymous access, rename this account and change it in ISM. If you run multiple services in ISM, you can create anonymous accounts for each service, but you must match the account username with the anonymous account name in ISM. If you don't provide public access to your site, you need to disable or delete the anonymous account.
If you use NT accounts for private access, set the Minimum Password Length to At Least 6 Characters. To thwart password attacks, set the Account lockout value to 5 and the Lockout Duration to 60 minutes. These settings limit the number of failed password attempts that NT allows and provide time to spot failed logons in the Event Viewer Security log. Screen 1 shows the Account Policy dialog box and typical account restrictions.
If a hacker succeeds in breaking into the system, NTFS security and the User Rights policy limits the damage the hacker can cause. Assign permissions using groups for NTFS and the User Rights policy rather than assigning individual user account rights. Additionally, never use FAT if you need to protect your file system from attacks.
By default, NT grants full control for the directory structure to the special group Everyone. You can't delete or rename the Everyone group, but you can remove the group from full control access to the file system. From the root of every partition, except the boot partition, assign control of the directory structure to the Administrators local group and then remove the Everyone group. After you make this security adjustment, assign NTFS permissions to the appropriate groups for Internet access to your Web server. For example, we provide read access to the directories that the Web user accesses in the Atlas Online University classroom. Additionally, other Internet service directory structures, such as the newsgroup directories, receive rights based on the user's group membership.
You must also adjust User Rights policies for security. Web user accounts require the Logon Locally User Right to access the Web server. Remember to assign the Internet user accounts to a group, and then assign the Logon Locally User Right to the group. Remove all groups, excluding the Administrators local group, from all other User Rights assignments. Because NT background service accounts depend on a proper User Rights policy, be cautious about removing service accounts from their assignments.
Most of the damage a malicious user can cause to your file system must occur through an NT logon. When only native NT services are running, a logon through the NetBIOS interface layer provides access to the file system. All NT protocols contain this NetBIOS interface. Fortunately, access to Web server services uses Windows sockets rather then NetBIOS.
NT protocol security. Although NetBEUI contains the NetBIOS interface, the interface exists as a distinct layer above IPX/SPX and TCP/IP. The NT Server service, TCP/IP, and Windows sockets are necessary for Internet access. The NetBIOS interface layer presents a serious security hole if you leave it enabled. Screen 2 shows the Windows Internet Naming Service (WINS) Client (TCP/IP) disabled over the Server service on the LAN Adapter (HP 10/100TX PCI LAN Adapter), which is the same as disabling the NetBIOS interface for the Server service over TCP/IP. If you are not using NetBIOS from the Web server to communicate with other NT Web servers, you can also disable the TCP/IP NetBIOS layer/WINS Client (TCP/IP) for the NT Workstation service. In addition, don't install protocols that you won't use. RAS is important for out-of-band management, so don't disable the NetBIOS interface layer from the RAS service. For RAS access to NT administrative tools, enable NetBEUI for dial-in RAS services on your server.
The TCP/IP protocol suite uses various port numbers to provide Internet services. These port numbers and their functions are contained in Request for Comments (RFC) 1700, located at http://ds.internic.net/std/std2.txt. You can also review port assignments and their functions in appendix B of the Windows NT Server Networking Guide (Microsoft Windows NT Server Resource Kit). You should permit only ports over TCP and User Datagram Protocol (UDP) that Web services require. For added security, change the port assignments for well-known ports in the ISM or the Registry. If you change port assignments, inform your Internet users which ports to use for service connections and adjust the information in the TCP/IP Security dialog box, as Screen 3 shows.
ISM security. Now that you have securely configured protocols, user permissions, and policies, you must adjust the ISM to further enforce Web security. Disable directory browsing so Internet users can't browse your Web server's directories and files. Directory browsing might not be a problem if your Web directories contain only native HTML. However, if these directories store script files containing environment variables, users can download your scripts to their computer.
Another important security issue in ISM is basic authentication, which allows clear-text password authentication to the Web server. Allowing clear-text passwords might be necessary for cross-browser compatibility. However, if you allow clear-text passwords, anyone able to operate a protocol analyzer on the network local to your server can discover usernames and passwords. The Secure Sockets Layer (SSL) protocol addresses this problem, but you must apply SSL sparingly because it affects server performance. Also, IIS 3.0 has a bug that exposes usernames and passwords. For more information, review Microsoft Support Online article Q163485 at http://support.microsoft.com/support/kb/articles/q163/4/85.asp.
Custom security methods provide additional security. Our Atlas Online University system uses a SQL Server database to store user accounts, passwords, and URLs. The system uses a custom ISAPI filter to authenticate users to the database, check permissions, and map the username and password to NT accounts. This approach lets the NT account and password be different from what is sent over the Internet, and lets us manage our users through a SQL Server database. You must have proficiency in C++ or Visual Basic (VB), HTTP, IIS, and multithreaded programming to build an ISAPI filter. If you have the resources to purchase or create an ISAPI filter for private access, it is worth the expense.
If you run other Internet services in addition to HTTP, investigate any security considerations unique to these services. For example, Microsoft FTP Server authenticates only clear-text usernames and passwords, so you must use limited or anonymous access accounts. NTFS security ensures that the FTP directory structure is secure. If you let all Internet users browse your FTP server, then you must use Allow Only Anonymous access. The FTP Server service maps the anonymous account to an anonymous NT account. SQL Server services for Web access also require special attention. If possible, don't allow SQL Server administrative access over TCP/IP. One method for providing this security is to build a protocol barrier between a separate SQL Server system and the Web server. On the SQL Server system run only IPX/SPX or NetBEUI. Bind one of these protocols to a LAN adapter in your Web server not running TCP/IP. When the Web server receives a SQL Server access request, the server communicates with SQL Server through a protocol other than TCP/IP. If you must use TCP/IP on the server running SQL Server, use difficult usernames and passwords and use only standard SQL Server security accounts.
Web Encryption
A common augmentation to standard Internet security is encryption. Unfortunately, government restrictions have complicated the use of encryption. If you receive credit card numbers or other sensitive information over the Internet, use an encryption protocol such as SSL. The US government restricts the export of strong encryption using private keys of more than 40 bits and public keys of more than 512 bits. If your Web server is in the US, give users the ability to use strong encryption, if their client software supports it. If you are in the US, you can apply strong encryption to the Web server by requesting the Strong Encryption (128-bit) version of NT 4.0 Service Pack 3 (SP3).
To use SSL on your server, request a digital certificate from a certification authority such as VeriSign. In IIS 4.0, Certificate Server lets you create and manage your digital certificate without an external certifying authority. The digital certificate also provides authentication support so that users can verify that you are who you say you are. You can also create client certificates that let you verify that clients are who they say they are.
Avoiding Hackers
While rarely damaging to your Web server, Denial of Service (DoS) attacks are frustrating for anyone trying to access your server. For an explanation of the most common attacks, read the sidebar, "Common Internet Hacker Attacks."
If you're running an early version of IIS, make sure to apply NT 4.0 SP3. SP3 updates IIS from version 2.0 to version 3.0. If you're not running SP3, you must install it before using any of the fixes the sidebar describes. No one has fully tested these fixes, so use them at your own risk. Each fix has documentation that you need to read carefully before applying the fix. Several other documented fixes exist for security holes in IIS and NT 4.0. You need to evaluate these configuration changes before applying them. You will find post-SP3 fixes at ftp://ftp.microsoft.com/bussys/winnt/winnt-public/fixes/usa/nt40/hotfixes-postsp3.
Web server colocation provides excellent performance and minimizes the cost of Internet access fees. Colocation, however, requires careful planning. Redundant Web server access, continuous monitoring, remote administration, and attention to server security are key components to a successful colocation strategy.
