IIS Insider - March 2003
By Brett Hill
Consolidating Multiple Log Files Into Single File
Q: We're using IIS 6 and have about 200 web sites. Each web site writes a log file every day which results in 200 log files daily which equates to about 73,000 files annually. We are expecting to double the number of sites, but don't want to manage that many individual log files. What we would like to do is to write each web site to a single log file and provide tools to do reporting on each web site's activity. Of course, there is ODBC logging but scalability is a concern for us with ODBC and we don't want to have network or database problems interfere with web site logging.
A: Lucky you! IIS 6 has a feature called Central Binary Logging that allows all logs to be written to a single file. The file is in a binary format so you can't parse it like an ASCII text file, as you can with other IIS log file formats. However, the Log Parser Tool mentioned in January's column does read this format as a native file format and can parse the file according to queries you provide. You can also find the log file format documented on the IIS 6 Resource Kit (when released).
Central Binary Logging cannot be enabled in the Internet Information Service console. Instead you have to turn it on with the Metabase entry W3SVC/CentralBinaryLoggingEnabled as follows:
adsutil.vbs SET W3SVC/CentralBinaryLoggingEnabled
You will then need to restart IIS 6 with
net stop w3svc followed by
net start w3svc. Afterwards, you'll find your log files in \system32\logfiles\w3svc as a .ibl (internet binary log) file. The name of the file will be rayymmdd.ibl where ra stands for raw followed by the date and the .ibl file extension. Note that once you have configured Centralized Binary Logging, other log file settings are ignored except for the file rollover settings for how frequently a new log file is created.
What are Null Sessions?
Q: I am in the process of deploying my company's web site on IIS 5 and have been reading up on securing IIS. I keep reading a lot about "null sessions" vulnerabilities. What are null sessions, and why do they present a vulnerability to IIS?
A: There is a great deal to say about null sessions but I'll make a bold effort to distill this to a few key concepts that covers a lot of territory. A null session occurs when a computer connects to another computer and no authentication is required. This is also called an anonymous connection which should in no way be confused with anonymous authentication in IIS. Anonymous authentication in IIS refers to allowing a user to have access to web resources (via IIS) without providing credentials. Even though the user is automatically assigned to the IUSR_<servername> user account without having to provide credentials, they are using the server as regular user in the security context of the IUSR_<servername> account.
Anonymous connections, however, are a different matter altogether. Anonymous connections provide a means for Microsoft operating systems to query the resources available on another system. For example, obtaining a list of computers for network neighborhood, users and groups available on a system, folders that have been shared for network use, or a list of netbios services can all be obtained using an anonymous connection.
Even though anonymous connections were designed to be used computer to computer or service to service, an attacker will try to exploit this capability to find out all the information that, by default, is freely available for the asking such as what hostname, domain names, shares, usernames and other details you'd really rather not have an attacker know. Armed with this information, attackers have a much easier task of identifying potential soft spots on a server or network.
There are several effective techniques for controlling access to anonymous connections. The first is to disallow access to ports 139 and 445 at your firewall. This will prevent attacks using anonymous connections. You will also want to consider the setting for the local policy Additional Restrictions for anonymous connections to either Do not allow enumeration of SAM accounts and shares or No access without explicit permissions'. When set to No access without explicit permissions you are in effect turning off anonymous connections. On an IIS server that is connected to an untrusted network, I would strongly advise this setting which will work best on all Windows 2000, Windows XP, and Windows Server 2003 networks.
A more aggressive technique is to disable File and Print Sharing for Microsoft Networks for the network card. You can do this with no ill effects in terms of IIS unless you need to host network shares on your IIS server. By a network share, I mean the kind you get when you right click on a folder and select the Sharing tab, rather than a virtual directory in IIS. Note that you can still connect to UNC pathnames on other server's File and Print Sharing disabled, but often your server will need File and Print Sharing enabled in order to be backed up over the network or managed remotely using the MMC.
Finally, consider using IPSEC for port filter on the IIS server. If your firewall is exploited, you don't want your IIS server to simply offer up the jewels. IPSEC is built into Windows 2000 and Windows Server 2003 and is frequently used for creating VPN's from one server to another. However, it also has the ability to do port filtering, which in the case of an IIS server, can be very useful. Using the built-in IPSec capabilities of Windows 2000 and Windows Server 2003, you can deny all ports except those you specifically allow on an IP-address-by-IP-address basis. If your server is port scanned for available ports, only those ports you specifically permit will be found.
Using these techniques in combination, you will very effectively protect your server from exploits based on null connections. Of course, this is only a part of the task of hardening a server. None of this will help if you have poorly implemented passwords or weak permissions. For a good overall look at security on Windows 2000 server, see the Security Operations Guide and Microsoft Solution for Securing Windows 2000 Server.
Configuring the IIS Admin Service
Q: I've configured the IIS Admin Service to run a batch file (a recovery process) if IIS5.0 goes down. Basically, this batch file will restart the IIS service and send an email automatically to our mailbox. The script has been tested and it works successfully. However, if I do a trial run by Stopping/Restarting the IIS, the batch file is not executed. Is there anything that I missed?
A: For those who may not be familiar with this feature, the IIS Admin Service in the services console is pre-configured to run IISRESET.EXE (which stops and starts all internet services associated with inetinfo) when it fails. In fact you can configure any service in Windows XP, Windows 2000, or Windows Server 2003 to recover from a failure and take a designated action on the first, second, and subsequent failures.
If your browser does not support inline frames, click here to view on a separate page.
I often recommend administrators do just what you are suggesting, which is to configure the IIS Admin Service to run a batch or script process that performs a logging event and/or notifies an administrator, and then invoke IISRESET.
The question now becomes - What circumstances causes the events configured under first, second, and subsequent failures to trigger? They are only triggered in the event of an unexpected failure such as inetinfo halting due to an error in a web application. They are not triggered when services are shutdown in an orderly fashion such as running IISReset or
Net Stop commands. Consequently, you cannot test your settings in this way. Also note that if an application is running out of process in dllhost.exe and fails in such a way as the application is no longer responding, inetinfo is likely to be running (which will be so if the server is delivering static pages) so the reset action is not triggered.
Submit your questions to the IIS Insider. Selected questions along with the answers will be posted in a future IIS Insider column.
For a list of previous months questions and answers on IIS Insider columns, click here.
We at Microsoft Corporation hope that the information in this work is valuable to you. Your use of the information contained in this work, however, is at your sole risk. All information in this work is provided "as is," without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Microsoft Corporation. Microsoft Corporation shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages.