This chapter is from the book
This chapter is from the book
This chapter is from the book
Background Security
The term background makes it sound as if these are less important, when in fact some are just as, if not more, important than the built-in features offered within specific areas.
Certainly preventing IIS from ever being installed at a domain level through group policy is a good way of completely eliminating IIS as a threat.
Controlling IIS Through Group Policy
Windows Server 2000 included an extensive range of group policies that can be used and applied to the users and computers within domains, and can control everything from basic password and user parameters to the specific configuration of certain elements of the operating system.
Windows Server 2003 has quite considerably increased the number of elements and areas that can be configured through the policy system. You can still configure user account and auditing settings through the group policy system, which you can use to help control the authentication and access to your site.
Also introduced in the new version is the ability to prevent users from installing IIS, or applications that required IIS, on Windows Server 2003 machines. You can use this to control IIS installations at the departmental or location/branch office level. You can also use it to protect other servers within your network on which you don't want IIS enabled—for example, a file or database server.
Existing IIS Installations
Unfortunately, the policy doesn't stop or otherwise disable existing IIS installations, only new ones. However, if you set up the policy, apply it to the servers and then remove IIS; it will stop new installations from occurring.
The policy is within Computer Configuration, Administrative Templates, Windows Components, Internet Information Services, Prevent IIS installation. There are only three settings:
Enabled—Installation is prevented.
Disabled—Machines within the domain tree are specifically allowed to install IIS.
Not Configured—The usual propagation rules apply.
Command Line Tool Access
Previous versions of IIS allowed command-line tools to be executed by Web applications. Sometimes this was needed for the sake of convenience; other times, it was a requirement of the application. In IIS 6, it's impossible, even as an Administrator, to execute command-line tools. This not only eliminates the ability to run most of the command line administration tools, but also prevents some viruses and worms from running and propagating.
Timeouts and Limits
Some exploits in IIS have used the long timeouts and often large limits. For example, when running a denial of service attack, the excessively long timeouts make it easy to saturate the server with a relatively small number of clients.
Also, applications served by IIS could cause performance problems and security issues by overflowing the memory and CPU with requests if there were a problem with the application or supporting libraries in some way.
The new worker process model helps alleviate this slightly by building in protection in the form of renewable processes for servicing user requests. But the limits have also been lowered so that IIS is more likely to identify an issue with an application or system before it really does start to cause problems.
Updates and Patches
One reason that the Code Red and NIMDA worms spread quite quickly and voraciously was because of an unknown exploit in IIS. Microsoft was quick to react when the worms started to spread by releasing a patch within a few days that stopped the worms dead in their tracks. In fact, an earlier patch to the operating system had already addressed one of the known exploits.
Unfortunately, not everybody had applied the patch, and even when the new patch had been released, not everybody listened—either because they didn't care, didn't think the patch or the problem applied to them, or just assumed that because they had a firewall, the problem didn't matter. Of course, the worms used an exploit that bypassed firewalls because to the firewalls it looked like standard traffic.
The bottom line is that you should keep up-to-date with the various patches and fixes that Microsoft makes available. Microsoft has made a solemn pledge with the release of Windows Server 2003 to respond to potential security threats and exploits used in the past as quickly as possible.
In addition to the 'hotfixes' released when a problem occurs and the regular service packs, just as with Windows 2000, Microsoft will also be pumping out regular updates and fixes using the Windows Update Service—the automatic system built in Windows XP and made available through Windows 2000 with Service Pack 3.
You can configure the automatic updates through the System control panel. At an individual server level, you can control how and when these updates are applied by setting the various preferences here. You can see an example of the configuration in Figure 3.10.
If you are running an array of servers and want to control the patches and updates applied to them all without doing so individually, use the Software Update Server (SUS), which provides a local copy of the Windows update service and patches. The settings for the different systems can be applied through group policies so that you can automatically install patches on some servers, whereas others require your intervention.
SUS also caches the information, so you won't download the update multiple times and you get the opportunity to individually approve patches before they get published to the clients.
Wider SUS Use
SUS downloads all the updates for your chosen platforms that you can use to keep all your workstations and servers up-to-date. Caching the updates, even in a relatively small office, can prevent you from wasting your bandwidth.
)
Figure
3.10 Setting update intervals and automatic installation preferences.