Pregunta ¿Consultas recomendadas de LogParser para el monitoreo de IIS?


A medida que crece el desbordamiento de pila, estamos comenzando a observar de cerca nuestros registros de IIS para identificar clientes HTTP con problemas, como arañas malintencionadasLos usuarios que tienen una gran cantidad de páginas para actualizar cada segundo, los raspadores web únicos mal escritos, los usuarios engañosos que intentan incrementar las páginas cuentan un millón de veces, y así sucesivamente.

He venido con algunos LogParser Las consultas que nos ayudan a identificar la mayoría de las rarezas y anomalías cuando se apunta a un archivo de registro de IIS.

Máximo uso de ancho de banda 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
golpes de url
------------------------------------------------- ----
/content/img/sf/vote-arrow-down.png 14076
/content/img/sf/vote-arrow-up.png 14018

Ancho de banda superior y aciertos 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
Totbytes cliente-agente de usuario 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 / Usuario-Agente

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
Totbytes de clientes de agente de usuario de hora
- ------------- ----------------------------------- ------ ---- --------
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 {nombre de archivo} por supuesto sería una ruta a un archivo de registro de IIS, como

c:\working\sologs\u_ex090708.log

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

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


86
2017-07-25 11:19


origen


Referenciado por blog.stackoverflow.com/2009/07/podcast-63 - Brad Gilbert
En la consulta de uso de ancho de banda superior hay una palabra clave DISTINCT. ¿Para que sirve? - Jakub Šturc


Respuestas:


Un buen indicador para actividades de hacking u otros ataques es el número de errores por hora. La siguiente secuencia de comandos devuelve el Fechas y horas que tenían más de 25 códigos de error. devuelto 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 ErrorCount
---------- -------- ------ ------
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 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 los casos perimetrales (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 Dirección IP Hits
---------- ----------------------------------- ----- ---------- ----
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
...

19
2017-07-25 11:47



En la segunda consulta, ya lo hacemos - note la agrupación en varias de las consultas. Por IP y User Agent, este es el mejor de los dos mundos, ya que si el User Agent es nulo, es lo mismo que IP, y si no, es más información. - Jeff Atwood
Bueno Jeff, agregar el agente de usuario tiene sentido. Lo sentimos, una combinación de mala memoria de corta duración y Trastorno por Déficit de Atención. :-) - splattne
Sustitución del having con un Limit n podría ser una buena manera de ajustar la primera consulta - BCS


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

Debido a su pequeño código, cada usuario debe tener una cookie a menos que deshabiliten manualmente las cookies (lo que puede hacer un pequeño porcentaje de personas) o a menos que ese usuario sea realmente un bot que no admita Javascript (por ejemplo, wget, httpclient , etc. no soporta 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 es compatible con cookies / javascript , es más probable que sean un bot.


6
2017-07-25 17:26





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 de acuerdo en tomar sus solicitudes de una página y multiplicar 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 un poco de -Números muy inexactos.

Para un valor más preciso, simplemente haga un SUMA (sc-bytes) en vez de MUL (Hits, AvgBytes) como ServedBytes.


6
2017-09-10 13:11





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

He estado usando estos:


6
2017-10-28 14:12





Este tipo tiene una docena de consultas útiles:

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


5
2017-08-09 15:07



Y ese chico (yo) es siempre Buscando más consultas para publicar. - James Skemp


Es posible que desee buscar sus solicitudes más largas (vástagos y / o consultas) y las que tienen más bytes recibidos por el servidor. También probaría uno que agrupa los bytes recibidos y la IP, de modo que pueda ver si un formato de solicitud particular es probable que se repita con 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 accesos para el grupo de solicitud de IP durante una hora y un minuto de un día, o agruparía la IP de solicitud con el minuto de la hora para encontrar si hay visitas periódicas que puedan ser scripts. Esto sería una pequeña modificación en el script de hits por hora.

En cualquier sitio no programado, buscar en sus registros las palabras clave de SQL también es una buena idea, por ejemplo: SELECT, UPDATE, DROP, DELETE y otras rarezas como FROM sys.tables, ORAR que juntos y contar por IP parecerían útiles. Para la mayoría de los sitios que incluyen estos, las palabras rara vez aparecerían en la parte de consulta de la URI, pero aquí podrían aparecer legítimamente en las partes de datos y datos de URI. Me gusta revertir las direcciones IP de cualquier éxito solo para ver quién ejecuta scripts premade. Tiendo a ver .ru, .br, .cz y .cn. No quiero juzgar, pero tiendo a bloquearlos de aquí en adelante. En su defensa, esos países generalmente están poblados en su mayoría, aunque hasta ahora no veo mucho que decir. .in, .fr, .us o .au haciendo 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. Por favor, edítelos libremente si necesitan reparación.


4
2017-07-30 17:06





Estos fueron encontrados aquí (que es una excelente guía para analizar los archivos de registro de IIS, por cierto):

20 nuevos archivos en tu sitio web

logparser -i: FS "SELECT TOP 20 Path, CreationTime from c: \ inetpub \ wwwroot *. * ORDER BY 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 "SELECT TOP 20 Path, LastWriteTime from c: \ inetpub \ wwwroot *. * ORDENADO 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 dado lugar a 200 códigos de estado (en caso de que se eliminaran los troyanos)

logparser "SELECT DISTINCT TO_LOWERCASE (cs-uri-stem) AS URL, Count () AS Hits FROM ex.log WHERE sc-status = 200 ORDENAR POR GRUPO POR URL ORDENAR POR URL "-rtp: -1

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

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

logparser "SELECT DISTINCT date, cs-uri-stem, c-ip, Count () AS Hits FROM ex.log GRUPO POR fecha, c-ip, cs-uri-stem HAVING Hits> 50 ORDER BY Hits Desc "-rtp: -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

3
2017-08-06 20:58



Los he mirado y no los he encontrado particularmente útiles. En su mayoría son "encontrar el compromiso" y ese no es realmente nuestro objetivo (no hemos sido comprometidos) - Jeff Atwood


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 guión.


0
2017-08-06 19:32



el objetivo no es encontrar ataques con scripts de ese tipo, sino clientes irresponsables / problemáticos relacionados con el ancho de banda y el tráfico. - Jeff Atwood
Yo diría que cualquier cliente que TRATA de lastimarme es un cliente problemático y preferiría que no utilicen mi ancho de banda. - BCS