At Davidson County Community College (DCCC), the Computer Technology faculty made the decision to configure a dedicated web server to support the Cisco Networking Academy Online Curriculum. The Cisco curriculum is used as the foundation text for 4 required courses in the Networking Technology program, so the material is of the utmost importance. Up to this point, the Cisco-based classes have been connecting through the Internet to the Cisco Systems training servers in Arizona to access the online curriculum. The decision was made to acquire the curriculum files from Cisco and install them locally for both performance and bandwidth control purposes. The intention for this web site is that it be, at first, accessed only by classes within the campus intranet. However, if proper authorization can be obtained from Cisco, the Department hopes to make the curriculum accessible from the Internet via the campus Proxy server. Access control on the Proxy server will limit usage of the web site to enrolled students only. It is, therefore, imperative that the server be made as secure as possible.
There was no funding to purchase a new server for this purpose, so the staff decided to use an older server from the network lab that had previously been employed as a demo Remote Access Server. The server is a dual Pentium II 400mhz unit with a SCSI-RAID 0 array and 1024MB of memory. The server already had Windows 2000 and IIS 5.0 installed. Our goal was to remove all unnecessary services from the server and configure it as a secure dedicated web server.
As a first step toward implementing security we ran the Microsoft Baseline Security Analyzer against the server from a remote machine. MBSA provides a variety of valuable security-related information for Windows 2000/XP and NT4.0 machines. MBSA is very versatile in that it can be run locally or remotely against a single machine, multiple machines or against an entire domain or subnet range (see Image 1).
Image 1
Security Updates
Image 2 displays the first screen of results from the MBSA scan.
This section compares what critical security updates are currently applied to the scanned system as opposed to what updates are currently available from Microsoft. Internet access by the scanning workstation is required for this feature to work properly because a query is made by MBSA to the Microsoft Download Center for an XML file which contains a list of all the most current updates and update versions for Windows 2000 and other scanned applications. This scan is more exhaustive than that which is available from the standard Windows Update Service. The MBSA scan locates more recent releases of the same numbered update package which WUS would not flag. Our scan revealed some 37 missing updates, some of which are critical for our purposes and some, such as the Windows Media Player updates which are unnecessary since we intend to remove that application. Most MBSA tests also include detail screens with additional information on the results of the scan. The detail screen for the System Updates scan is seen in Image 2a.
Image 2
Image 2a
The second section of the MBSA scan, displayed in Image 3 includes some basic Windows administrative security checks.
Image 3
Restrict Anonymous Users
By default, anonymous Internet users connecting to a windows system can retrieve certain types of information from the system Local Security Authority (LSA), including user names and details, account policies, and share names. For higher security, the registry can be configured to prevent anonymous users from accessing this information. This test determines whether or not that feature has been implemented. MBSA scans which recommend configuration changes usually have "How to correct this" screens which give a step-by-step description of how to implement the change. The "how to" screen for this test is displayed in Image 3a.
Image 3a
Password Expiration
Checks the local user accounts to see if any of them have non-expiring passwords. Good security dictates that all passwords should expire and be changed on a rotating basis. The presence of non-expiring passwords is a security risk.
Local Account Passwords
This test performs a very rudimentary check on local system passwords (not AD passwords.) It reports whether:
In addition to these basic checks, truly effective password auditing at the local level and auditing of a Domain Controller’s Active Directory account database requires a third-party password auditing tool such as LophtCrack.
File System
This check determines what file systems (FAT16, FAT32, NTFS) are present on the scanned machine’s volumes or partitions. NTFS is the preferred file system for high security purposes and is recommended by MS for all workstations and servers.
Autologon
The Auto Logon scan determines whether or not the automatic logon using a specific user account has been enabled on the scanned machine. This is a serious security risk for a personal workstation and is totally unthinkable for a secure server.
Guest Account
This test determines whether or not the built-in Guest account has been enabled on the scanned server. The Guest account is identified as a potential security risk and is disabled by default in the Windows 2000 installation process. The Guest account can provide an open door for crackers to obtain first-level access to a system and then, through various techniques used by crackers to upgrade account rights , can become a major threat to system security. The Guest account should never be enabled on an Internet accessible server and, within an Intranet, should be used only when low value resources are stored on the system.
Administrator Group Membership
The Administrative Group Membership shows up as a security risk if more than two accounts are configured in the Local Administrators group of the scanned system. More than two are considered by MS to be a security risk.
Image 4
The third section of the MBSA report provides information about miscellaneous environmental factors and system services and utilities which effect system security.
Auditing
The Auditing scan determines whether auditing is enabled on the scanned server. This is a blanket scan which does not discriminate as to what resources or what type of auditing is going on, only that the auditing service is running. Microsoft recommends that on any Internet accessible server you audit, at the very least, for success or failure of logon attempts
Check for Unnecessary Services
The third section of the MBSA scan details what high risk services are installed on the scanned system, and whether they are running or disabled. The default services scanned for by MBSA are the HTTP, NNTP,FTP and SMTP services, but the system administrator can have MBSA scan for additional services which are of concern to him/her by including those additional services in the services.txt file resident in the MBSA home directory.
Shares
This scan documents all shared resources on the scanned system, including administrative shares. It displays both the share-level and NTFS permissions currently assigned to these shares. This test assists the administrator in removing unneeded shares from a system or assigning tighter permissions to better secure them.
Windows OS Version
Tells whether the system is running NT4.0, Windows 2000 or Windows XP.
Domain Controller
This check tells whether the scanned machine is a domain controller which can be a significant factor in determining the level of security required on the system. When doing entire network and subnet scans, it is often helpful to keep track of exactly which machines are filling the DC role and if that many are really needed to provide adequate authentication services.
MBSA also performs security scans on several major Microsoft applications, if installed: Internet Information Server 4.0/5.0, SQL Server, Outlook, Internet Explorer and the Microsoft Office suite. Since we are only interested in IIS for this project, this will be the only suite of features we discuss here.
Images 5 and 6 illustrate some of the IIS security checks available with MBSA:
Image 5
IIS Lockdown Tool
This test determines whether the IIS Lockdown Tool has been run against the scanned system. Part of the Microsoft Security Tool Kit, the Lockdown Tool provides a single interface to shut down or disable unnecessary IIS components to reduce the attack surface.
IIS Sample Applications
IIS sample applications in the iissamples and ishelp directories allow the sysadmin to test different types of index search methods, provide sample forms, and simulate different interactive environments. They can also be exploited as backdoors to the system and should be removed, if not needed. This scan tests for the presence of these directories.
IIS Parent Paths
If the ASPEnableParentPaths setting is enabled in the system registry of the scanned computer, Active Server Pages applications are able to use relative paths in moving from one directory to another. This provides a benefit to the cracker who is attempting to use .ASP scripts to modify the file system. They can move from one directory to the next without knowing the actual path name. A secure server should have this feature disabled.
IISADMPWD Virtual Directory
IIS, by default, allows users to change their passwords remotely through the web and notifies users that their passwords are about to expire. Files in this directory support this feature and should be deleted or locked down in a secure environment.
MSADC and Scripts Virtual Directories
By default IIS 5.0 installs with a Scripts virtual directory containing a series of sample scripts written using Microsoft's .ASP technology. Like the test.cgi and other sample .cgi scripts on Linux/Unix machines, they pose a significant security risk by allowing crackers to run arbitrary commands against the web server by appending them to the script command string. A secure server will delete or lock down these test scripts to reduce the attack surface of the system.
Image 6
IIS on Domain Controller
Determines whether IIS is running on a domain controller, a high-level vulnerability.
IIS Logging
This check determines whether IIS Logging is enabled and if the standard W3C Extended Log Format is being used. IIS logging is highly recommended for all web site scenarios, but especially for Internet accessible servers. IIS Logging goes well beyond standard MS Event Logging. IIS Logging keeps a detailed record of such events as who has visited your site, what IP and/or domain they connected from, what resources they viewed, what permissions and rights they used against those resources, etc.
Based upon the security analysis made by MBSA, we implemented the following security measures on the scanned server:
In order to address additional IIS 5.0 security concerns in the most efficient manner, we ran the IIS Lockdown Tool against this server. With IIS Lockdown we were able to implement the following security restraints:
After making the enhancements indicated by MBSA, we went through the Windows 2000 Server Baseline Security Checklist available on the Microsoft TechNet web site to see what other measures we could implement to tighten security through the OS. Using this document, we implemented the following measures:
After securing the OS and IIS, we copied the folders and files for the Cisco curriculum to the server and configured a virtual directory in IIS to link to the Cisco file structure. Our next step was to apply the proper NTFS and web access permissions to the web content. We used the CACLS command-line ACL utility to assign the Microsoft suggested NTFS permissions to each file type. The Microsoft White Paper IIS 5.0 Baseline Security Checklist, available on TechNet, outlines the recommended default ACLs by file type. CACLS works better for this purpose than the GUI interface because, like DOS, permission changes can be cascaded recursively through subfolders. The virtual directory was configured to allow read and script access which should work fine as the Cisco curriculum utilizes no server-side executable programs.
Finally we removed the Terminal Services Server, the Routing and Remote Access Server and the Remote Procedure Call Server left from the server's previous function. All of these services provide remote access and/or remote administration capabilities and present a tangible security risk.
At this point the server has been renamed CISCOWEB and configured with a private network IP address. An A record entry for it has been placed in the campus DNS server and it can currently be accessed from anywhere in the campus Intranet. We are confident that the server has been secured well enough to assume an Internet web server role in the near future.