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
behaviors.

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:NTBUGTRAQLISTSERV.NTBUGTRAQ.COM]On Behalf Of Nicholas Staff

> Description:
>
> 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.

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]