Installing and Securing IIS Servers (Part 1)
Easy to use, easy to hack. Indeed, the ease of installation can further tempt users to overlook careful planning, adequate fundamental security measures or patching holes when they emerge. Such a default installation is massively vulnerable and it is no wonder that attackers are finding IIS to be "the easiest pickings" of all Web servers. Something must be going on if one considers the outburst of CodeRed infection. If so, what can be done to prevent the problem? The most important aspect of any security countermeasure is, knowing what to look for and where to look for it.
The Internet Information Services is a suite of tools and services for creating, managing, and securing Web sites that is included with Windows NT operating systems (also Windows 2000, XP and .NET). The IIS services are tightly integrated with the operating system and therefore all IIS versions are Windows-dependent, namely:
- IIS 5 - is associated with Windows 2000 (all versions)
- IIS 5.1 - is associated with Windows XP Professional
- IIS 6 - is associated with Windows .NET Server
- IIS versions 3 and 4 are designed for Windows NT 4.0, (technical support for this is expected to be terminated by the end of 2002).
The IIS Versions designed for workstations (that is IIS5 in Windows 2000 Professional and IIS5.1 in Windows XP Professional) have limited functionality as compared with their server versions (IIS5 on Windows 2000 Server and IIS6 on Windows .NET Server). This limited functionality relates, for example, to a maximum of 10 concurrently handled HTTP requests, the possibility of running a single Web site only, lack of host IP-based access control list, no Connection Limit extension. Therefore, IIS workstations are not suitable for serving up fully functional web sites - this limitation continually triggers the irritating "403 Too many users" message, despite the fact that the logs show that there are fewer than 10.
(Fig.1 Whether our site is reaching its maximum popularity or our server is experiencing difficulties to handle requests?)
Since Windows .NET Server (together with IIS6) is at the moment undergoing finishing touches and unavailable for purchase as yet, we will focus below on Windows 2000 Server IIS Version 5. This is because this version is currently the most suitable to be a powerful server for a new generation of Web applications. Moreover, given the availability of downloadable patches being of vital importance for web server security, we will deal further with the English Version of Windows 2000 Server.
Getting installed with IIS
All IIS services are installed in the same manner as any other Windows component - through the Control Panel: select "Add/Remove Programs", then click on "Add/Remove Windows Components". The screen will appear that allows you to install new Windows components - this requires caution, because an operating system connected to the Internet is particularly vulnerable to attacks. Therefore DO NOT install IIS together with services that are of key importance for LAN functionality or security. Locate the Internet Information Services (IIS) entry and then click on the Details button to select the necessary IIS pieces of functionality. They are:
- Common Files - that is, the main files and services included with IIS,
- Documentation - files of the Default Web Site, files containing IIS error messages and the basic HTML documentation (C:\WINNT\Help\iisHelp directory),
- Internet Information Services Snap-In - an application for managing IIS from the Microsoft Management Console (MMC),
- World Wide Web Server - which provides Hyper Text Transfer Protocol (HTTP) services compiled in a user-friendly manner.
Other IIS components that may deserve further attention are as follows:
- File Transfer Protocol (FTP) Server - included in the system provides support for an FTP account. Remember however, that the FTP service lets you force anonymous logons because it does not use encryption for authentication. You should also be very restrained when considering other options that require logons (web site update, sharing files).
- NNTP Service - to host newsgroups. It can be utilized, for example, for client-to-server and employee communications, but it is not recommended to use the USENET features (that is the commonly available newsgroup hierarchy) because of their limitations.
- SMTP Service - the email server. Being an SMPT server, it provides only mail delivery functionality. It is not intended to aid in receipt of emails, but with its Collaboration Data Objects (CDO) component it is able to forward messages from WWW sites. Remember, however, to ensure that your spam-borne mailing service will be appropriately secured to avoid this nuisance i.e. preventing your server from being used to relay spam! 
There are also components that when installed, may be risky from the security point of view and are therefore not recommended, please consider:
- FrontPage 2000 Server Extensions - this is a special communication protocol that supports authoring and administering Microsoft FrontPage webs,
- Internet Service Manager (HTML) - is designed to configure and monitor IIS using WWW pages,
- Visual InterDev RAD Remote Deployment Support -this is a sub-component that assists in the development of web applications via Visual InterDev.
While installing IIS remember, that any subsequently added service will imply the need for proper configuration and maintenance of its security environment otherwise problems may occur and worse, persist. On poorly secured and/or configured servers everything may happen quickly: unauthorized third party relaying, illegal contents, mail viruses and hacking attempts, potentially involving "ritual" problems, with possible legal risks for you, as the owner of the server. Depending on the scale of your web site, installation of the previously mentioned IIS components, SMPT and anonymous FTP may be enough.
(Fig. 2 Installing IIS)
The general approach involves closing down the connections to the Internet while installing web services - once installed, IIS can potentially expose your server to unfriendly forces. Of course, a complete firewall solution or a NAT device may be enough to deny incoming traffic as appropriate. In fact, further sections of this article will be devoted to some security countermeasures allowing a safe installation of IIS components while still allowing Internet connectivity and access to your WWW pages.
The first step in securing your server is to download the most updated Service Pack (currently Service Pack 3 ) and current IIS patches (MS02-062 is the recent patch concurrent with this article ). The system administrator, should also download other patches as required for Windows 2000  (at least consider seriously their implementation) and Internet Information Services 5.0 
(Fig. 3 Windows 2000 Patches & Updates).
In addition, don't forget to register so that you will automatically receive Microsoft security bulletins . This is of fundamental importance because procurement and installation of any update patches is a must from time to time in order to keep the server operating securely (hackers and viruses like to find out where "lousy software" is!). Don't forget to confirm your subscription by replying to the email with the instructions included.
In the next step, setting up the computer is important enough to not be ignored . The simplest way is to get HiSecWeb.exe file from the Microsoft Web site , unpack it to the C:\WINNT\Security\Templates and follow the instructions given in . Open it in mmc.exe (using the "Security Configuration and Analysis" application to be downloaded from the Console > Add/Remove Snap-In menu) and run (being prompted to import hisecweb.inf, select "Analyze Computer Now" from Action menu, and then "Configure Computer Now." Remember that HiSecWeb is designed for dedicated Web servers and it disables all services that are not associated with web access services. The HiSecWeb package does not alter the permissions within the file structure on the system partition , while the WWW files are to be installed on a non-system partition, the hardening of which will be discussed later.
Once all necessary patches and updates have been applied and the system settings chosen, you must disable access to the default Web site that has been installed concurrently with the IIS documentation. To do this, run "Internet Services Manager" (within administrative tools, that is Programs > Administrative Tools). This program is an MMC application that was been previously installed under the name "Internet Information Services Snap-In". Once started, choose a name for the server, right mouse click on "Default Web Site", and then select "Properties" from the popup menu.
In order to disable the default web site, assign it to the localhost address (that is 127.0.0.1) - in the "IP Address" box (the "Web Site" tab) delete "(All Unassigned)" and insert 127.0.0.1, and then click "OK"
(Fig. 4 assigning the default web site to the localhost address).
This will cause the default web site to only be accessed from the web browser running on the server, not from the network. It is better to leave the default web site disabled rather than remove it, as it may come in handy later. Right mouse-click on the Default Web Site and select "Stop" in popup menu (instead using the right mouse button, you may use "Action" menu). Naturally, if you plan not to use the default web site anymore, for example to check location of IIS installed files or to read IIS documentation, you can remove it (from popup menu). So far, no other changes to the IIS configuration are necessary, but you can review all tab settings. As you can simply check, directories (and even individual files) can have their own settings within the IIS configuration.
In the next step related to the IIS hardening, you should set master properties for the WWW services. Contrary to the default web site configuration, the IIS configuration is a hierarchical one, that is, any changes to the IIS configuration associated with the WWW Service Master Properties (W3SVC for short) can be inherited through the hierarchy of the embedded system components (sites, applications, directories and files). When you configure properties at the level of the IIS server, certain security-related settings will become the default settings for all web sites (the existing ones and those which are to be created). Before attempting to change settings, ensure that you make a backup copy of the metabase (i.e. the IIS configuration). To do this, in the "Internet Services Manager" application, right mouse- click the server (not the web site!) and click on "Backup/Restore Configuration". The backup IIS copy management window will appear. Click on "Create backup " , and insert the backup copy name (for example "Manufacturer's Configuration") and click OK. The backup copy has been stored to the file in the C:\WINNT\system32\inetsrv\MetaBack directory.
(Fig. 5 the first IIS configuration backup copy).
After making the backup copy, close the "Configuration Backup / Restore" and configure the W3SVC services. Right mouse click on the computer name and select "Properties". Under "Master Properties", click "Edit " next to the "WWW Service" tab. The window similar to the web site configuration will appear - it has its "Service" tab. Pay attention, that certain components are disabled (because they are consistent with individual web sites only). On the "Web Site" tab, select the "Enable Logging" check box and then select the format (I recommend that you select "W3C Extended Log File Format"). Pressing the "Properties" button can modify both the file rollover period (preferably leave "Daily") and the location of the log directory. Because a typical server can have logs measuring dozens of MB daily, it is a good idea to choose a directory on a dedicated disk, for example E:\LogFiles (remember to establish an appropriate directory on the selected partition). You may also enable local time logging (I don't recommend this), and select the scope of the logged information. My advice is to select all boxes excluding "Process accounting" on the "Extended Properties" tab. These options are useful at troubleshooting, detecting intrusions, examining traffic etc. The "Process Accounting" boxes allow one to analyze the server load resulting from individual HTTP requests, but I do not recommend that one use them during a normal operation of the server.
(Fig. 6 Details of WWW Server logins).
After enabling the logging feature (in the master properties of the W3SVC), change the Home Directory settings. In the "WWW Service Master Properties" window, select the "Home Directory" tab and then click on "Configuration ". The "Application Configuration" window will appear, it allows you to set up dynamic WWW pages that are files with specific extensions. Whenever they are called from the Web, they will be passed through the W3SVC service for execution by ISAPI applications, that is additional programs (more specifically - DLLs) installed on the WWW server. These programs are, for example, C:\WINNT\System32\inetsrv\asp.dll, ism.dll, httpodbc.dll, ssinc.dll and C:\WINNT\System32\msw3prt.dll, idq.dll and webhits.dll (within the same directory). You must remove all said programs, leaving only those using asp.dll (and also ssinc.dll if it is considered useful) - all others were used in the past for breaking into the IIS servers and infecting them with viruses (for example CodeRed that uses a known buffer overflow vulnerability contained in the idq.dll). Of course, given all these patches and updates installed previously, it is quite impossible to feel unsecure even with the entire set of ISAPI programs enabled. However, an experienced system administrator would know the old German saying, "once lost, confidence does not easily return" - particularly when the ism.dll application had "lost confidence" with its record-breaking negative events. One is advised to only leave enabled for use the asp.dll and possibly ssinc.dll - since they both also had security-related problems, but of considerably less importance and which were far more difficult to be exploited by hackers.
Files with .inc extensions will not be compiled, executed, or served with the default installation of IIS. In order to have ASP pages served, you will need to give all include files a .ASP extension and add these extensions to the Web Service Extensions list. Otherwise whenever any request is made for an .inc suffixed page, its code will be revealed for public viewing instead of executing it (even with errors, it is far better than publicizing dynamic pages code). Of course, the same procedure should be followed for any other extension scripts. Those who save ASP customization in the .txt files deserve to be given special attention from the system administrator.
In order to setup the extension service via ISAPI applications, click on the "Add" button and then fill in the boxes:
- Executable: C:\WINNT\System32\inetsrv\asp.dll
- Extension: .inc
- Limit to: POST, GET, and HEAD
It is a good idea to provide each extension (those default included) with the "Check that file exists" option enabled - this setting implies that if the requested file doesn't exist, the usual error processing occurs ("404 Not Found") instead of producing the ISAPI application error.
(Fig. 7 Adding ISAPI scripting environment).
The ISAPI msw3prt.dll functionality is dependent both on the IIS and "Web-based printing" setup in the group policy (defined on a local computer and the relevant GPO). It also depends on Print Spooler functionality - which was disabled while launching hisecweb.inf. When you intend to upgrade a Service Pack (sooner or later), the installer activates the Print Spooler service if it's not already running. However, if you have disabled the start-up type for this service, the service will fail to start. This is a strange but consistent requirement associated with the installation of all existing Windows 2000 upgrade packages.
The next important applications to be set up are listed in the tabs of the "Application Configuration" window. On the "App Options" tab, clear the "Enable parent paths" setting to ensure that the FileSystemObject started by an ASP application is limited to that application's defined directory. Another possible service to disable is the "Enable session state" to avoid overloading the server's memory at any ASP request. (Encourage the Webmaster to accept this change). On a cluster of Web servers (where many Web servers share the responsibility for responding to user requests), a Web page will not always function properly. This is because a single user session cannot be created on one server and then read and modified on another. With the advent of IIS 6 and its user session synchronizing support, this limitation will not longer be maintained.
On the "Process Options" tab you can either modify or disable the ASP file cache size - I would discourage you from enabling "Cache all requested ASP files" as the usage of server RAM for ASP session variables could become quite significant.
Lastly, on the "App Debugging" tab, ensure that the debugging options are unchecked and change "Send detailed ASP error messages to client" to "Send text error message to client". This will prevent potential attackers from compromising your website and then provide a simple text for error of WWW services with a possible email address included for reporting problems. With all applications set up as desired, click OK.
If at anytime during these steps you see the "Inheritance Overrides" properties box, this means that certain W3SVC components (web site etc.) have their own settings that are different from the master properties being applied. As you may remember, settings are inheritable, therefore you must decide whether to delete or maintain invariant certain settings as replicated ones. As the default web site is of concern, I suggest not to change anything, whilst for your own web sites use the documentation you are maintaining as guidance. Just click the OK button - do not touch the list! - The master properties will be modified but those previously set will remain unchanged.
(Fig. 8 Changing Master Properties; the Default Web Site settings remain unchanged)
After defining the default application settings, go to change the default WWW site settings. Select the "Directory Security" tab in the "WWW Service Master Properties" window, click on the upper button marked "Edit". The "Authentication Methods" window will appear with their enabled "Anonymous access" and "Integrated Windows authentication" options. It is advisable to uncheck the latter option in respect to commonly accessible WWW pages - it may allow "brute force" attacks from the Internet, targeted at unscrambling server (or related network) user passwords in transit. Unfortunately, this option is to be recurrently disabled, since it is activated by default whenever any new domain is opened. Also remember to uncheck the authentication options after installing SMTP and/or FTP services - this issue will be discussed later. After pressing OK, and then "Apply" you will again see the "Inheritance Overrides" window - do not enable any component belonging to the default web site (for example the .in. file localstart.asp file) and click OK again. The "Edit" button underneath allows defining of appropriate IP and domain restrictions - you might use it for a server that by default is designed for access by a selected group of users only (for example Intranet users or your company partners connected via ISDN). Remember that IP restrictions do not ensure high security level - today's IP protocol does not provide fully secure authentication of the connection source. If you want to have your server accessible from trusted sites only, take advantage of a Virtual Private Network (VPN) solution. On the "Documents" tab you can define default documents. If a domain or directory contains a file with its filename not listed here, the user will see the "403 Forbidden" error message (or the content of the entire directory if the "Directory browsing" has been enabled in the Home Directory option). It is good practice to consult the Webmaster about filenames to be placed on the list - for example, it may be required to add a name index.html.
Generally speaking, your IIS server is now fully set up. However don't forget to look at other tabs to ensure that the "Home Directory" tab has unchecked the "Read", "Write" or "Directory browsing" options, that the "Execute Permissions" (related to dynamic pages) are set to "None", and that "Log visits" is ON. As for the "Home Directory" settings, they will be re-visited after a new WWW site has been established.
Creating Web pages
When creating web pages, it is important to be aware of a problem when starting the work: you should provide a separate partition for WWW pages. Create separate partitions for your NT and Internet data. This suggestion is subtle but important. If you place each logical group of files or each independent directory structure on a separate partition (separate logical disk drives); you reduce the risk of contamination. For example, if you store your Web pages and your Web scripts in the same directory, hackers can break into your Web page area and easily contaminate your scripts.
This can be the same partition you use to store logs - pay attention not to store operating system programs on it (preferably no other programs if possible). Why this requirement? Unfortunately, IIS has a history of problems regarding improper access to programs outside the directory of WWW pages; and still there are many strange entries like "/scripts/../../winnt/system32/cmd.exe+/c+dir+\" found in server logs worldwide. Bugs in ".."path handling that were allowed to pass from the site directory to the operating system directories and run the programs residing under these directories were responsible for this. These bugs could be exploited to launch attacks from the sites hosted on the operating system partition. All other situations where relevant partition-related security recommendations were observed i.e. that used separate partitions for the operating system and WWW pages and with the "Default Web Site" disabled were immune to attacks despite the same IIS holes, because a potential attacker could not redirect his request between various disks. Due to a hard time learning slowly from our own mistakes - this costly experience can be avoided by following the said recommendation, (in addition to disabling the default web site, removing unnecessary ISAPI services and setting restrictive file access policies) that is one of the key IIS related security issues. It is an obvious choice, and is included as one of the options when you set up each IIS directory. Any directory you want to protect must be on a NTFS partition - for example E:\WebFiles and subdirectories of individual domains, for example E:\WebFiles\W3SVC2. Make sure you set out appropriate file access permissions: right click on the disk with your domain content and select the "Security" tab. Be aware, that IIS is particularly sensitive to the presence (or absence) of group "Everyone". Remove this hacker invitation from your server, then click "Add " and enable access for Administrators, SYSTEM and Authenticated Users. Then, still on the "Security" tab associated with Administrators and SYSTEM activate maximum permissions with "Full Control", whilst for Authenticated Users, uncheck all, leaving only "List Folder Contents". Confirm your disk security settings by pressing OK. Then mouse select the WebFiles directory, again open the "Properties" window with right mouse click and on the "Security" tab give the Authenticated Users permissions under "Read & Execute" (and also "Read" by default). It is suggested that such an entire set of file access permissions, simplified but conceptually sufficient, is as follows:
- For Administrators: Full Control,
- For Authenticated Users: List Folder Contents,
- For SYSTEM: Full Control,
- For Authenticated Users: Read & Execute.
Now, with such an "over-hardened" dedicated partition you have a certain margin for loosening restrictions on any other directory, that from time to time may share the disk with WWW sites content. If the log directory is placed on the same partition, you should add the users appropriate read access:
- The log directory - Users: Read
After setting the directory for all sites, you should set a subdirectory for your new site. Let's name it W3SVC2 - because it is a directory designed for the second site (W3SVC services). The same naming convention is used by the IIS service to name subdirectories containing the web site logs - of course, you may not use it if you don't wish to, but this solution can facilitate log interpreting when more web sites exist. The next thing to do is associated with the well-known "Internet Services Manager" program: run it and halt the default web site selecting the "Stop" option in the popup menu - if this has not been carried out before. Upon completion of these preparatory activities, create a new IIS web site. Right mouse click on the server name and from the popup menu, select New, and then select "Web Site" from the respective submenu. The "Web Site Creation Wizard" window will appear. Click "Next >" on the Welcome screen, then place a short description of your site (it may resemble the WWW address)
(Fig. 9 A short description of your site).
On the next screen, specify the IP address of your website (among those configured at the server - alternatively, you can use any of those available). Then the TCP port (it is recommended to use the 80 port only - using non-standard ports does not enhance security but rather makes more difficult to use web services) and, if you wish, the Web address of your site. This last box is to be filled in if you wish to have multiple sites running on a single IP address, differentiated only by their DNS names.
(Fig. 10 [...] Your Web site address).
Once again click "Next >" and locate your "elaborated" Home Directory - in this example E:\WebFiles\W3SVC2
(Fig. 11 [...] location of files).
Leave the "Allow anonymous access to this Web site" enabled and go to the last web site configuration screen to complete settings for the new web site. Here, leave the "Read" and "Run scripts" boxes enabled as they are. The first is designed to allow reading of static web site files- that is HTML, graphics, style spreadsheets, presentations, that is the files that are sent to Web users with no additional server operation required. Dynamic web pages (that is the scripts activated by ISAPI applications already set up under "Application Configuration") use the settings established in "Run scripts" - if using ASP pages is required, make sure that this box remains checked. Answering the question "Do I really need the "Execute" enabled? Is your next step. This option allows running of programs via the IIS server interface (including EXE files and DLLs, also called ISAPI applications) located in the web site - it is very likely to be exploited by enemies, because these powerful programs, if buggy, may be exploited by a hacker. Another threat but even more concerning is associated with the "Write" setting - all publicly available web sites should not be write-accessible and in this example this requirement has been fulfilled by appropriate file access restrictions settings. Enabling the Browse functionality will provide users with access to your web site as to a common FTP server. You can also enable it, if both names and contents of your files can be publicized (for example, if it is required to have an anonymous file server accessed via HTTP). Of course, you can apply such a setting for a chosen site subdirectory not to worsen aesthetic quality of your Home Page.
(Fig. 12 [...])
Finally, go to set up permissions for Internet users. After clicking on the "Next >" button, press "Finish" on the final screen - you will see the web site launched in the IIS server environment. Right click on it and select Properties tab followed by the "Home Directory" tab. The same tab is available at the settings of any web site subdirectory, so you will be able to individually set up access permissions in respect to specific directories depending on their content. The following options are seen while creating the web site:
- "Script source access" allows access to dynamic pages source code via HTTP; it is better not to use this option.
- "Read" allows reading of web site files. If the web site or a subdirectory contain solely dynamic page scripts, you may disable this option;
- "Write" allows writing of files via HTTP. If your server is accessible on the Web, uncheck this option;
- "Directory browsing" enables a user to navigate through your WWW server directory structure (names of all files). It can be activated from a subdirectory performing the role of an anonymous file server. If you decide to enable this option, you will be likely to need to uncheck the "Enable Default Document" option on the "Documents" tab;
- Options "Log visits" and "Index this resource" - the first one should always be enabled, the second one not, unless the file indexing service has been installed on your server;
- "Execute Permissions"- when enabled, it is an equivalent to the "Run scripts" and "Execute" options together, being visible on the final screen while creating web sites. "None" corresponds to non-selecting any of the said options. "Scripts only," means the same as "Run scripts" enabled, whilst "Scripts and Executables" - corresponds to both options enabled. For directories containing static files only, (for example a directory with graphics or a file server) select "None", whilst for typical directories with ASP pages set "Scripts only"; May I suggest that you do not use the third alternative if possible
- "Application Protection" box - you can select a process that will be responsible for running ASP sites - preferably Medium or High to be checked. Do not enable "Low (IIS Process)", because you will be at heavy risk of possible running dynamic WWW under SYSTEM user privileges! Setting to "Medium" will place your ASP in a "pooled application" process. Selecting "High" will allow you to run an ASP "on its own" thereby enhancing security by separating web sites. Additionally;
- "Configuration" button allows one to modify ASP settings. If you have selected a high level of application separation (option "High" as described above), you will have access to an additional tab named "Process Options" in the "Application Configuration". This window has been already described when describing the server global configuration procedures. "Remove" (or "Create") - you can use it to create/delete ASP applications on the web site or its subdirectories. My advice is to not delete the application belonging to the web site!
- "Unload" button allows one to momentarily reduce server burden from ASP pages by removing ASP application from the memory
- The final setup component is associated with the location of web site files (it is provided in the upper portion of the window) - you can change the location of the Home Page directory or activate redirecting to another web site. Do not use the "A share located on another computer" option - this may imply a heavy overhead to the file server service and "unexplainable" lowering of your server performance.    
The above settings are documented in the IIS popup help facility (use Shift-F1 while previewing setup windows) and also in the Microsoft Knowledge Base  . Moreover, the TechNet Whitepaper available at the Microsoft Web site may be helpful  .
Having completed the preview of the Home Page settings, go to enhance security parameters on the "Directory Security" tab - click on the upper button marked "Edit", then in the "Authentication Methods" window only leave enabled the "Anonymous access" option. You will need to remove the "Integrated Windows authentication" option that is unfortunately activated by default (you don't want to risk successful brute force attacks, do you?)
(Fig. 13 the final patch).
The same applies for other IIS server services - if you have installed the FTP service, enable the anonymous FTP user. In the "Internet Services Manager" application, click on "Default FTP Site" and select Properties from the popup menu. In the "Default FTP Site Properties" go to the "Security Accounts" tab and check the "Allow only anonymous connections" option. In this manner you will cause the FTP to be prevented from hacking away at usernames and passwords. If you have installed the SMTP service, also ensure that you disable this opportunity - click on "Default SMTP Virtual Server", and select Properties from the popup menu. In the "Default SMTP Virtual Server Properties" select the "Access" tab and click on "Authentication". You will see the user authentication access mode window - delete all options except for the highest one ("Anonymous access"). Of course, you can set up your services so that they will be accessible to trusted users of your network (offering them extra services, for example, accessing confidential files), but this is associated with some additional operations to enhance security of passwords involved.
What about the web sites?
If you want to see your new site in the web browser, you have to add some files to it, at least a notepad-created default.html. You may manually copy the files from a CD-R, e-mail or a diskette, sent you by the Webmaster. This is an often-used solution allowing for documentation of the changes effected on the Web site. It is however possible that you would have to allow the Webmaster to save the files directly to the web site. Firstly you have to create an account for him. If the WWW server belongs to a Windows NT or an Active Directory domain, you may use a domain account. You should take note of the fact that the Ethernet card receiving HTTP tasks from the Internet must not be connected to the internal network - they have to be separate network interfaces. Then, you modify the authorizations in the file system, attributing the Webmaster the right of writing and modifying the files of the chosen web site (in our case of the E:/WebFiles/W3SVC2 directory). If you have a local area network and a WWW server belonging to the domain, you may define the access as a simple network share on the directory that contains the Web site's files (E:/Webfiles). Otherwise, you may define a new virtual FTP site (choose New -> FTP Site in the IIS server's popup menu). Your FTP 'site' has to be accessible from a trusted network only! To achieve this objective you should use the other Ethernet card installed in the server or the firmware VPN (or an IPsec tunnel) - it is important that the card's IP is not at all accessible from the Internet. While setting up a virtual FTP server you should choose this IP address. E:/WebFiles will be the home directory of the FTP 'site'. You should authorize the Webmaster to write in the directory, too, with the use of the 'Write' option on the last screen of the FTP site creation process. Additionally, the FTP server's setup should block any access coming from IP addresses not belonging to the VPN and/or the local area network. This is an extra means of security, which could save you from some consequences of the mistakes made in the process of connecting the server to the network. A more important way of securing yourself is a trusted network interface, accessible from the local area and/or VPN network, but inaccessible from the Internet. Its trust should not be based on the computer's configuration but on the topology and means of security of the network it is connected to. This is however a topic for another article. And now you can finally connect your new WWW server to the Internet!
If you would like us to email you when Bronek Kozicki releases another article on WindowSecurity.com, subscribe to our 'Real-Time Article Update' by clicking here. Please note that we do NOT sell or rent the email addresses belonging to our subscribers; we respect your privacy!
Bronek Kozicki has worked as a Network Administrator for the last eight years. Five years were devoted to Windows NT-based systems. He deals with administering SQL Server databases, applications, network security issues and efficiency of Internet Servers. He writes server solutions (chiefly extensions of the IIS services - the SMTP and the W3SVC) in the C++ language. Besides programming, he is concerned with teaching advanced C++ uses such as: methodology, idioms, programming styles and the modern features of the language. He was a member of WinSecurity Magazine's editorial board where he was chief editor of the Microsoft Knowledge Base pages. At the moment he works as a Network Administrator in Getin SP S.A., a company providing Internet services. He spends his free time with his wife, going for walks or to the cinema, or reading books, preferably science fiction. He is the world champion in preparing hot chocolate with froth or cappuccino.