all groups > iis security > march 2008 >
You're in the

iis security

group:

source of Failure Audits is Default Web Site


source of Failure Audits is Default Web Site G
3/14/2008 2:26:39 PM
iis security:
I've inherited an apparently unmaintained environment. I notice that about
half of my Security events on my domain controller SVR2 are:
Event Type: Failure Audit
Event Source: Security
Event Category: Account Logon
Event ID: 680
Date: 3/14/2008
Time: 1:44:25 PM
User: NT AUTHORITY\SYSTEM
Computer: TMG-SVR2
Description:
Logon attempt by: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
Logon account: Administrator
Source Workstation: SVR1
Error Code: 0xC000006A

I start checking SVR1, a W2K box, and eventually find that stopping the
Default Web Site in IIS Admin stops these errors. We have the usual IISHelp,
IISAdmin, IISSamples, and an MSADC. There's a PerlEx web site that I gather
is ActiveState. And there are five websites from a vendor-provided Altiris
offering. Directory Security varies among Anonymous access with Username
IUSR_SVR1 and "Allow IIS to control password" checked, Basic Authentication
with no Domain Name set, and Integrated Windows authentication. I suspect
there is a problem with the IUSR_SVR1 Internet Guest Account, which I do as
a local user on SVR1 as a member of Guests, with Password never expires and
User cannot change password.

At this point, I'm not sure what to do with this. What are good solutions at
ths point?
________
Greg Stigers, MCSA
remember to vote for the answers you like


Re: source of Failure Audits is Default Web Site David Wang
3/14/2008 9:46:46 PM
[quoted text, click to view]


How can a problem with user name IUSR_SVR1 become an event for
Administrator?

Perhaps someone is attempting to hack the Administrator account using
the fact that Authentication is enabled on the web server so that they
can attempt login as anyone, including Administrator.


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
Re: source of Failure Audits is Default Web Site G
3/18/2008 10:33:26 AM
Well, I'm posting because I don't understand what's wrong. If someone is
trying to crack the Admin account, whatever they are doing depends on having
the Default Web Site up and running on this member server, because stopping
that website stops these errors. I am guessing that the IUSR_SVR1 account
somehow tries to use NT AUTHORITY\SYSTEM, causing the Logon attempt by
MICROSOFT_AUTHENTICATION_PACKAGE_V1_0, whose Logon account is Administrator.
But maybe I'm misreading the Event Log.

Bottom line, I just want these websites to work, without filling the Event
Log on the DC.
________
Greg Stigers, MCSA
remember to vote for the answers you like

Re: source of Failure Audits is Default Web Site David Wang
3/19/2008 1:03:18 AM
[quoted text, click to view]


Well, it makes sense that if someone is trying to crack tho Admin
account, they need *some* website which accepts authentication to be
running (so that IIS tries to logon for authentication using username/
password provided by the hacker). Thus, stopping the website stops the
entire logon process and hence the events.

FYI: Your guess is pretty much non-factual in all aspects. Let's look
at what are true.

Since you cannot stop hackers from trying to attack, and you have no
way for the web server to select who to allow authenticate (you don't
know the user until after authentication), there is nothing you can
configure in IIS to stop this.

Actually, I suspect that you have Administrator hardcoded in IIS
somewhere as the Anonymous user for a specific vdir and that password
has changed -- so everytime someone tries to anonymously browse that
vdir in the website, it causes IIS to attempt (and fail) to logon as
the Anonymous user (which is configured to be the Administrator) and
generate the event.

How Windows deals with this is to lockout a user account after so many
failed login attempts -- hence the events stop generating afte
reaching the lockout limit.

FYI: you have to accept that event logs will get filled with lots of
things and that you have to filter to find the right information. It
is literally impossible to avoid the event you mention because you'd
have to stop people from making incorrect logons, and that's obviously
never going to happen because you cannot control those people at all.
And since you're telling Windows "log those auth logon failures" and
there is no way to determine if someone accidentally or intentionally
enters the wrong credentials, there is no way to achieve your bottom
line unless you turn off authentication everywhere.


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
AddThis Social Bookmark Button