¿Consultas recomendadas de LogParser para la supervisión de IIS?

A medida que crece el desbordamiento de pila, comenzamos a mirar de cerca nuestros registros de IIS para identificar clientes HTTP problemáticos, como arañas web no autorizadas , usuarios que tienen una página grande configurada para actualizar cada segundo, raspadores web mal escritos, trucos Los usuarios que intentan incrementar la página cuentan un billón de veces, y así sucesivamente.

Se me ocurrieron algunas consultas de LogParser que nos ayudan a identificar la mayoría de las rarezas y anomalías cuando se apunta a un archivo de registro de IIS.

Uso de ancho de banda superior por URL

SELECT top 50 DISTINCT 
SUBSTR(TO_LOWERCASE(cs-uri-stem), 0, 55) AS Url, 
Count(*) AS Hits, 
AVG(sc-bytes) AS AvgBytes, 
SUM(sc-bytes) as ServedBytes 
FROM {filename} 
GROUP BY Url 
HAVING Hits >= 20 
ORDER BY ServedBytes DESC

url hits avgbyte servido
------------------------------------------------- - ---- ------- -------
/favicon.ico 16774 522 8756028
/content/img/search.png 15342 446 6842532

Top hits por URL

SELECT TOP 100 
cs-uri-stem as Url, 
COUNT(cs-uri-stem) AS Hits 
FROM {filename} 
GROUP BY cs-uri-stem 
ORDER BY COUNT(cs-uri-stem) DESC

hits url
------------------------------------------------- - ----
/content/img/sf/vote-arrow-down.png 14076
/content/img/sf/vote-arrow-up.png 14018

Ancho de banda superior y hits por IP / User-Agent

SELECT TOP 30
c-ip as Client, 
SUBSTR(cs(User-Agent), 0, 70) as Agent, 
Sum(sc-bytes) AS TotalBytes, 
Count(*) as Hits 
FROM {filename} 
group by c-ip, cs(User-Agent) 
ORDER BY TotalBytes desc

cliente usuario-agente totbytes hits
------------- ------------------------------------- -------- --------- -----
66.249.68.47 Mozilla / 5.0 + (compatible; + Googlebot / 2.1; 135131089 16640
194.90.190.41 omgilibot / 0.3 ++ omgili.com 133805857 6447

Ancho de banda superior por hora por IP / User-Agent

SELECT TOP 30
TO_STRING(time, 'h') as Hour, 
c-ip as Client, 
SUBSTR(cs(User-Agent), 0, 70) as Agent, 
Sum(sc-bytes) AS TotalBytes, 
count(*) as Hits 
FROM {filename} 
group by c-ip, cs(User-Agent), hour 
ORDER BY sum(sc-bytes) desc

hr cliente usuario-agente totbytes hits
- ------------- ----------------------------------- ------ -------- ----
9 194.90.190.41 omgilibot / 0.3 ++ omgili.com 30634860 ​​1549
10 194.90.190.41 omgilibot / 0.3 ++ omgili.com 29070370 1503

Top hits por hora por IP / User-Agent

SELECT TOP 30
TO_STRING(time, 'h') as Hour, 
c-ip as Client, 
SUBSTR(cs(User-Agent), 0, 70) as Agent, 
count(*) as Hits, 
Sum(sc-bytes) AS TotalBytes 
FROM {filename} 
group by c-ip, cs(User-Agent), hour 
ORDER BY Hits desc

El agente de usuario del cliente hr alcanza totbytes
- ------------- ----------------------------------- ------ ---- --------
10 194.90.190.41 omgilibot / 0.3 ++ omgili.com 1503 29070370
12 66.249.68.47 Mozilla / 5.0 + (compatible; + Googlebot / 2.1 1363 13186302

El {filename}, por supuesto, sería una ruta a un archivo de registro IIS, como

c:\working\sologs\u_ex090708.log

Hice muchas búsquedas web para buenas consultas de IIS LogParser y encontré muy poco. Estos 5, arriba, nos han ayudado enormemente a identificar clientes con problemas serios. Pero me pregunto: ¿qué nos estamos perdiendo?

¿Qué otras formas hay de cortar y cortar los registros de IIS (preferiblemente con consultas de LogParser ) para extraerlos en busca de anomalías estadísticas? ¿Tiene alguna buena consulta de IIS LogParser que ejecute en sus servidores?

Un buen indicador para piratear actividades u otros ataques es la cantidad de errores por hora. El siguiente script devuelve las fechas y horas que tuvieron más de 25 códigos de error devueltos. Ajuste el valor según la cantidad de tráfico en el sitio (y la calidad de su aplicación web ;-)).

SELECT date as Date, QUANTIZE(time, 3600) AS Hour, 
       sc-status as Status, count(*) AS ErrorCount
FROM   {filename} 
WHERE  sc-status >= 400 
GROUP BY date, hour, sc-status 
HAVING ErrorCount > 25
ORDER BY ErrorCount DESC

El resultado podría ser algo como esto:

Fecha Hora Estado Error Cuenta
---------- -------- ------ ------
2009-07-24 18:00:00 404 187
2009-07-17 13:00:00 500 99
2009-07-21 21:00:00 404 80
2009-07-03 04:00:00 404 45
...

La siguiente consulta detecta un número inusualmente alto de visitas en una sola URL desde una dirección IP . En este ejemplo, elegí 500, pero es posible que tenga que cambiar la consulta para casos extremos (excluyendo la dirección IP de Google London, por ejemplo ;-).)

SELECT DISTINCT date AS Date, cs-uri-stem AS URL,
      c-ip AS IPAddress, Count(*) AS Hits
FROM  {filename}
GROUP BY date, c-ip, cs-uri-stem
HAVING Hits > 500
ORDER BY Hits Desc

Fecha URL IP Dirección Accesos
---------- ----------------------------------- ----- ---------- ----
2009-07-24 /Login.aspx 111.222.111.222 1889
2009-07-12 /AccountUpdate.aspx 11.22.33.44 973
2009-07-19 /Login.aspx 123.231.132.123 821
2009-07-21 /Admin.aspx 44.55.66.77 571
...

Una cosa que podría considerar para filtrar el tráfico legítimo (y ampliar su alcance) es habilitar cs(Cookie)en sus registros IIS, agregar un poco de código que establezca una pequeña cookie usando javascript y agregar WHERE cs(Cookie)=''.

Debido a su pequeño fragmento de código, cada usuario debe tener una cookie a menos que deshabilite manualmente las cookies (lo que podría hacer un pequeño porcentaje de personas) o que ese usuario sea en realidad un bot que no sea compatible con Javascript (por ejemplo, wget, httpclient , etc. no son compatibles con Javascript).

Sospecho que si un usuario tiene un gran volumen de actividad, pero acepta cookies y tiene habilitado javascript, es más probable que sea un usuario legítimo, mientras que si encuentra un usuario con un gran volumen de actividad pero no admite cookies / javascript , es más probable que sean un bot.

Lo siento, no puedo comentar aún, así que me veo obligado a responder.

Hay un error menor con la consulta 'Uso de ancho de banda superior por URL'. Si bien la mayoría de las veces estaría bien tomando sus solicitudes de una página y multiplicándolas por el tamaño del archivo, en este caso, dado que no está prestando atención a ningún parámetro de consulta, se encontrará con algunos -muy inexactos números.

Para un valor más exacto, simplemente haga una SUMA (sc-bytes) en lugar de la MUL (Hits, AvgBytes) como ServedBytes .

Anders Lundström ha estado escribiendo una serie de artículos de blog sobre consultas comunes de LogParser.

He estado usando estos:

• LOGPARSER # 1: 10 imágenes principales por tamaño enviado
• LOGPARSER # 5: Las 10 páginas ASPX más lentas
• LOGPARSER # 12: Solucionar problemas de quién está causando sus 500 errores?
• LOGPARSER # 23: Obtenga la versión del sistema operativo de los usuarios que acceden a su sitio

Este tipo tiene alrededor de una docena de consultas útiles:

http://logparserplus.com/Examples/Queries.aspx

Es posible que desee buscar sus solicitudes más largas (tallos y / o consultas) y las que reciben más bytes del servidor. También probaría uno que agrupe por los bytes recibidos y la IP, para que pueda ver si un formato de solicitud en particular es probable que sea repetido por una IP.

SELECT TOP 30
cs-uri-stem,
cs-uri-query,
c-ip as Client, 
SUBSTR(cs(User-Agent), 0, 70) as Agent, 
cs-bytes,
c-ip,
FROM {filename} 
WHERE cs-uri-stem != '/search'
ORDER BY LEN(cs-uri-query) desc

SELECT TOP 30
COUNT(*) AS Hits
cs-uri-stem,
cs-uri-query,
c-ip as Client, 
SUBSTR(cs(User-Agent), 0, 70) as Agent, 
cs-bytes,
c-ip,
FROM {filename} 
GROUP BY c-ip, cs(User-Agent), cs-bytes 
ORDER BY Hits desc

También contaría los resultados para el grupo de IP solicitante durante una hora y minuto del día, o agrupe la IP solicitante con el minuto de la hora para determinar si hay visitas periódicas que pueden ser guiones. Esta sería una pequeña modificación en el script de hits por hora.

En cualquier sitio sin experiencia en programación, buscando sus registros para palabras clave de SQL es también una buena idea, cosas como SELECT, UPDATE, DROP, DELETEy otras rarezas como FROM sys.tables, ORing que juntos y contando con IP parecerían práctico. Para la mayoría de los sitios que incluyen estos, las palabras rara vez aparecerían en la parte de consulta del URI, pero aquí podrían aparecer legítimamente en el tronco y las partes de datos del URI. Me gusta invertir las direcciones IP de cualquier hit solo para ver quién ejecuta scripts prefabricados. Tiendo a ver .ru, .br, .czy .cn. No me refiero a juzgar, pero tiendo a bloquearlos de ahora en adelante. En su defensa, esos países están generalmente en su mayoría pobladas, aunque hasta el momento no veo mucho de, por ejemplo .in, .fr, .uso .auhaciendo lo mismo.

SELECT TOP 30
c-ip as Client, 
SUBSTR(cs(User-Agent), 0, 70) as Agent, 
cs-uri-stem,
LOWER(cs-uri-query) AS q,
count(*) as Hits,
SUM(sc-bytes) AS BytesSent,
SUM(cs-bytes) AS BytesRecv
FROM {filename} 
WHERE q like '%select%' OR q like '%sys.tables%' OR etc... 
GROUP BY c-ip, cs(User-Agent) 
ORDER BY Hits desc

PD: No puedo verificar que estas consultas realmente se ejecuten correctamente. Edítelos libremente si necesitan reparaciones.

Todos estos se encontraron aquí (que es una excelente guía para analizar sus archivos de registro IIS, por cierto):

20 archivos más nuevos en tu sitio web

logparser -i: FS "SELECCIONE la ruta TOP 20, CreationTime de c: \ inetpub \ wwwroot *. * ORDENAR POR CreationTime DESC" -rtp: -1

Path                                                        CreationTime
----------------------------------------------------------- ------------------
c:\inetpub\wwwroot\Default.asp                              6/22/2003 6:00:01
c:\inetpub\wwwroot\About.asp                                6/22/2003 6:00:00
c:\inetpub\wwwroot\global.asa                               6/22/2003 6:00:00
c:\inetpub\wwwroot\Products.asp                             6/22/2003 6:00:00

20 archivos modificados más recientemente

logparser -i: FS "SELECCIONE la ruta TOP 20, LastWriteTime de c: \ inetpub \ wwwroot *. * ORDENAR POR LastWriteTime DESC" -rtp: -1

Path                                                        LastWriteTime
----------------------------------------------------------- ------------------
c:\inetpub\wwwroot\Default.asp                              6/22/2003 14:00:01
c:\inetpub\wwwroot\About.asp                                6/22/2003 14:00:00
c:\inetpub\wwwroot\global.asa                               6/22/2003 6:00:00
c:\inetpub\wwwroot\Products.asp                             6/22/2003 6:00:00

Archivos que han resultado en 200 códigos de estado (en caso de que se hayan eliminado troyanos)

logparser "SELECCIONE DISTINCT TO_LOWERCASE (cs-uri-stem) AS URL, Count ( ) AS Hits FROM ex .log WHERE sc-status = 200 GROUP BY URL ORDER BY URL" -rtp: -1

URL                                      Hits
---------------------------------------- -----
/About.asp                               122
/Default.asp                             9823
/downloads/setup.exe                     701
/files.zip                               1
/Products.asp                            8341
/robots.txt                              2830

Mostrar cualquier dirección IP que llegue a la misma página más de 50 veces en un solo día

logparser "SELECCIONE DISTINCT fecha, cs-uri-tallo, c-ip, Count ( ) AS Golpea DE ex .log GROUP BY fecha, c-ip, cs-uri-tallo TIENE Hits> 50 ORDEN POR Hits Desc" -1

date       cs-uri-stem                         c-ip            Hits
---------- ----------------------------------- --------------- ----
2003-05-19 /Products.asp                       203.195.18.24   281
2003-06-22 /Products.asp                       210.230.200.54  98
2003-06-05 /Products.asp                       203.195.18.24   91
2003-05-07 /Default.asp                        198.132.116.174 74

No sé cómo hacerlo con LogParser, pero buscar cadenas de solicitudes de cosas como "phpMyAdmin" (u otras vunerablities comunes) que obtienen 404s podría ser una buena manera de identificar ataques con script.