RE: [logs] Commercial Tool for in-depth IIS Logging

rgerhards@private

> > > We have created a tool that is directly integrated into IIS (ISAPI
> > > filter). It emits log data via syslog when IIS reaches 
> certain points of
> > > its internal processing (e.g. begin and end of http request).
> >
> > Why do you output to syslog? Such a debugging application typically
> > outputs to a logfile - no?
> >
> the IIS "logging improver" isn't primarily designed for 
> debugging.  it's
> designed for intrusion detection and system monitoring.  the 
> situation we
> specifically had in mind is the one in which an IIS attack 
> (for instance,
> the printer ISAPI buffer overflow used by code red) is 
> launched through a
> web connection.  the IIS server starts the connection and then gets
> hacked, and never makes it to the point in its workflow at 
> which it writes
> its log into the access log file.

Looks like I tried to hard to avoid sales pitch ;-) ... got most of the
actual uses cases out of the description... Thanks, Tina, for providing
it.

> if rainer's done what i assume he's done (ie. what we talked 
> about last
> year) (where the hell did that year go?), this application enables the
> ability to write a logfile entry at various points of the IIS 
> workflow to
> improve an administrator's ability to monitor the server at critical
> points.

Yes, this is exactly what it does. In a very corase overview, IIS works
as follows (for each http request):

1. decode request
2. call script processor (asp, .net, perl, php.. you name it)
3. send reply
4. log to w3log

please note that logging comes last - if there is a worm like CodeRed,
that stage will never be reached. Instead, IIS will loop somewhere in 2.
So you do not at all see these requests in w3logs. IISLogger can emit a
begin http transaction before 1. and an end http transaction after 4
(and also log at several other points). 

IMPORTANT: The workflow outlined above is a rough sketch. The real thing
can be found in the paper (link below).

> 
> of course, this would be very useful for a programmer too, but alas
> programmers have never been my main audience.  me and my ol' sys admin
> bias...
> 
> Rainer, did that article we were working on ever get posted anywhere?

Actually, we decided to split them (if you remember the dark ages of the
beginning of this year):

http://www.monitorware.com/Common/en/SecurityReference/Monitoring-IIS-Lo
gs.pdf
is the fully edited, fully correct version - but mostly without the
workflow.

http://www.monitorware.com/Common/en/Articles/IIS-Workflow.asp
Is the paper on IIS Workflow. It is NOT fully edited (I guess Tina and I
both have it on the todo list...). Also, it is not 100% correct. But all
the key facts are fine, so it is good to understand the whole thing. IIS
6 changed quite some things, but the basic picture remains.

Rainer
_______________________________________________
LogAnalysis mailing list
LogAnalysis@private
http://lists.shmoo.com/mailman/listinfo/loganalysis