RE: Logging mechanism in IIS (was RE: code red---- on system that is already (and has been) patched)

• Previous message: Antoine Borg: "User rights on Terminal Services"
• Maybe in reply to: Geoff Craig: "RE: Logging mechanism in IIS (was RE: code red---- on system that is already (and has been) patched)"
• Next in thread: Geoff Craig: "RE: Logging mechanism in IIS (was RE: code red---- on system that is already (and has been) patched)"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

From: David Vincent <david.vincent@mightyoaks.com>
To: 'Geoff Craig' <GCraig@quilogy.com>, focus-ms@securityfocus.com
Date: Thu, 6 Mar 2003 08:43:45 -0800 

hi.

i searched google with no results, filesearching.com with no results, and
found nothing on the microsoft site - not even in the DLL Help Database
(http://support.microsoft.com/servicedesks/fileversion/). where might i be
able to get a copy of this dll?

-d

-----Original Message-----
From: Geoff Craig [mailto:GCraig@quilogy.com]
Sent: March 5, 2003 9:33 AM
To: focus-ms@securityfocus.com
Subject: RE: Logging mechanism in IIS (was RE: code red---- on system
that is already (and has been) patched)

I do not know if this is distributed beyond the Microsoft Course on IIS
5 but Microsoft does have an ISAPI filter called URLLog.dll. What it
does is log HTTP requests both before AND after they are processed. It
is true that IIS will NOT log any request that it cannot process. This
is a distinct disadvantage for those who want to know what is getting
dropped by inetinfo.exe. Since the dll is an ISAPI filter it is
executed before the request is handed to inetinfo.exe. I did a Google
search to find the dll but I did not receive any results. The only
place I have even seen it mentioned is in the IIS 5 courseware which I
have taught frequently.

Geoff Craig
Quilogy - The Art & Science of Business

-----Original Message-----
From: Ken Schaefer [mailto:ken@adOpenStatic.com]
Sent: Tuesday, March 04, 2003 7:41 PM
To: focus-ms@securityfocus.com
Subject: Re: Logging mechanism in IIS (was RE: code red---- on system
that is already (and has been) patched)

I concur with Keith (but I could be wrong...)

In the case of buffer overflow attacks (/not/ Sadmind etc that used
Unicode
traversal to get to cmd.exe) a successful attack should result in
nothing in
the IIS logs.

Attacks like Sadmind which use traversal will be logged either way. 404
if
cmd.exe can't be found and 200 if cmd.exe can be found (subject,
possibly,
to the qualification wrt to sites that have custom 404 pages which
someone
else mentioned).

Cheers
Ken

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From: "Turner, Keith (Contractor)" <Keith.Turner@tea.army.mil>
Subject: Logging mechanism in IIS (was RE: code red---- on system that
is
already (and has been) patched)

:
: I believe this to be true, someone please correct me if it is not.
: Logging is one of the last steps IIS takes while processing a request.
: Logging is not a separate process. If your server is attacked
successfully,
: some other code starts executing and therefore, IIS never gets a
chance to
: log that entry into the logfiles.
:
: Keith
:
:
: -----Original Message-----
: From: Levinson, Karl [mailto:LevinsonK@STARS-SMI.com]
: Sent: Monday, March 03, 2003 4:18 PM
: To: 'Sandy Ryan'; focus-ms@securityfocus.com
: Subject: RE: code red---- on system that is already (and has been)
: patched
:
:
: My understanding is that code 200 is exactly what you get in response
to
: Code Red's GET /DEFAULT.IDA request, if you have installed the
relevant
: security patch but have not yet removed the relevant script mappings
from
: IIS. More information:
:
: http://securityadmin.info/faq.htm#iislogs2
: http://securityadmin.info/faq.htm#iislogs
:
: Note that usually a HTTP code 200 is a disturbing code to see in the
context
: of a worm, as it normally represents the successful execution of the
attack
: command. In this case, however, the code 200 is inconclusive and does
not
: in itself prove the success or failure of the attack. [Similarly, an
HTTP
: 502 doesn't always prove that a particular attack failed.]
:
: On the other hand, successful attacks from Nimda, Code Red, Sadmind,
etc.
: will all show code 200's in the logs.
:
: As your customer might already know, just installing patches does not
by
: itself make your server secure. Your customer would want to consider
also
: setting the correct settings, deleting the correct files, setting the
: appropriate file permissions, disabling services, etc. Installing
patches
: may protect you from many of today's exploits, but not the exploits
: discovered tomorrow. The Baseline Security guidelines for Windows and
IIS
: from www.microsoft.com/technet/security are one place to start, and/or
the
: instructions at http://securityadmin.info/faq.htm#harden
:
: HTH
:
: - karl
:
:
: -----Original Message-----
: From: Sandy Ryan [mailto:sryan@seewolf.com]
: Sent: Monday, March 03, 2003 11:47 AM
: To: focus-ms@securityfocus.com
: Subject: [despammed] code red---- on system that is already (and has
: been) patched
:
:
: well - I doubt that the log is right - because I think the 200 implies
: that its not infected - by when my customer sees his report - and path
: taken through the site he sees worm.com
:
: here's the log (simplified to get through the moderator)
: GET /default.ida
:
:
NN----NN%u9090%u6858%ucbd3%u7801...%u9090%u9090%u8190%u00c3%u0003%u8b00%
: u531b%u53ff%u0078%u0000%u00=a 200 0 206 4039 266 HTTP/1.0 [you know
the
: url]- - -

• Previous message: Antoine Borg: "User rights on Terminal Services"
• Maybe in reply to: Geoff Craig: "RE: Logging mechanism in IIS (was RE: code red---- on system that is already (and has been) patched)"
• Next in thread: Geoff Craig: "RE: Logging mechanism in IIS (was RE: code red---- on system that is already (and has been) patched)"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]