(A User Provides Guidance) Re: Microsoft IIS Web Server Can Be Effectively Shutdown By Certain Internal-Network Attacks When The Underlying OS Supports User Account Lockouts
SecurityTracker Alert ID: 1001502|
SecurityTracker URL: http://securitytracker.com/id/1001502
(Links to External Site)
Date: May 9 2001
Denial of service via network|
Due to the intended design of Microsoft NT and Windows 2000 and due to the default account used by the IIS web server for anonymous web access, it is reported that the IIS server can be effectively shut down by a remote user on the internal network.|
A user provides some guidance on related issues. Please read the Source Message for details.
For details on the original vulnerability report, please see the Message History.
A remote user with access to the underlying server via Microsoft networking protocols can cause the IUSR_COMPUTERNAME account to become locked out, thereby prohibiting any anonymous web surfing to the IIS web server until the lockout period expires.|
No solution was available at the time of this entry. The vendor reportedly responded that this is the intended design.|
Vendor URL: www.microsoft.com/technet/security/ (Links to External Site)
|Underlying OS: Windows (NT), Windows (2000)|
This archive entry is a follow-up to the message listed below.|
Source Message Contents
Subject: Re: IIS DOS Attack|
Account lockout always exposes you to some degree of denial of service
potential. I've had a couple of people ask how to maintain account lockout
on the domain users, but not encounter this situation. The key here is to
remember that account lockout properties depend on the account domain - so
if the IIS server is running as a local account, don't set the local system
for account lockout. You can then set the domain for lockout if you like.
Additionally, one work-around for a typical web server where NetBIOS/SMB
services aren't available to an attacker is to make sure that no web
directories allow NTLM authentication. This prevents both lockouts and
password guessing attacks.
Finally, if it is an internal server, you go check your audit logs, find the
system that the attacks came from, and go fire the jerk who is screwing up
your servers. Even though one cannot discount insider attacks, particularly
on very large networks, there are non-technological solutions to certain
As a last point, IPSec can be a very handy tool that will help with Win2k
systems - you could set ports 135-139,445 TCP/UDP to require IPSec, and base
that IPSec on a certificate you distribute only to people authorized to
administer the web server.
> -----Original Message-----
> From: Windows NTBugtraq Mailing List
> [mailto:NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM]On Behalf Of Nicholas Staff
> The IUSR_COMPUTERNAME account is governed by account lockout policies
> and can be locked out. This is the default account used by IIS for
> anonymous web access and when it is locked out anonymous access is
> denied. Any IIS server with a lockout policy that can be
> made to prompt
> for authentication is vulnerable. Additionally nearly every
> Internal/Corporate web site running on IIS can be shut down by any
> employee on their network.