Question Requêtes LogParser recommandées pour la surveillance IIS?


À mesure que le dépassement de capacité augmente, nous commençons à examiner de plus près nos journaux IIS pour identifier les clients HTTP problématiques, par exemple: spiders web voyous, les utilisateurs qui ont une grande page à actualiser chaque seconde, des scrapers web uniques mal écrits, les utilisateurs astucieux qui tentent d’incrémenter la page comptent un zillion de fois, et ainsi de suite.

Je suis venu avec quelques LogParser des requêtes qui nous aident à identifier la plupart des bizarreries et des anomalies signalées par un fichier journal IIS.

Utilisation maximale de la bande passante par 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 servi
------------------------------------------------- - ---- ------- -------
/favicon.ico 16774 522 8756028
/content/img/search.png 15342 446 6842532

Top hits par 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
url hits
------------------------------------------------- - ----
/content/img/sf/vote-arrow-down.png 14076
/content/img/sf/vote-arrow-up.png 14018

Bande passante maximale et hits par 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
agent utilisateur client totalise les 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

Bande passante maximale par heure par 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 client user-agent totalise les 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 par heure par 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
hr client utilisateur-agent hits 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

Le {nom du fichier} serait bien sûr un chemin d'accès à un fichier journal IIS, tel que

c:\working\sologs\u_ex090708.log

J'ai fait beaucoup de recherches sur le Web pour trouver de bonnes requêtes IIS LogParser et je n'ai trouvé que très peu de ressources. Ces 5, ci-dessus, nous ont énormément aidés à identifier les clients problématiques graves. Mais je me demande - qu'est-ce qui nous manque?

Quels autres moyens existe-t-il pour trancher et dés les journaux IIS (de préférence avec les requêtes LogParser) les exploiter pour des anomalies statistiques? Avez-vous de bonnes requêtes IIS LogParser que vous exécutez sur vos serveurs? 


86
2017-07-25 11:19


origine


Référencé par blog.stackoverflow.com/2009/07/podcast-63 - Brad Gilbert
Dans la requête relative à l'utilisation de la bande passante supérieure, il y a le mot clé DISTINCT. À quoi ça sert? - Jakub Šturc


Réponses:


Le nombre d'erreurs par heure est un bon indicateur des activités de piratage ou d'autres attaques. Le script suivant renvoie le dates et heures comportant plus de 25 codes d'erreur revenu. Ajustez la valeur en fonction du volume de trafic sur le site (et de la qualité de votre application 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

Le résultat pourrait ressembler à ceci:

Date Heure Statut Erreur Compte
---------- -------- ------ ------
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 requête suivante détecte un nombre inhabituellement élevé de hits sur une seule URL à partir d'une adresse IP. Dans cet exemple, j'ai choisi 500, mais vous devrez peut-être modifier la requête pour les cas d'extrémité (à l'exception de l'adresse IP de Google London, par exemple ;-).)

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
Date URL Adresse 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



nous faisons déjà la deuxième requête - notez le regroupement dans plusieurs des requêtes. Par IP et par agent d’utilisateur, c’est le meilleur des deux mondes, car si l’agent d’utilisateur est nul, il est identique à IP, et si ce n’est pas le cas, il s’agit de plus d’informations. - Jeff Atwood
Ok Jeff, l'ajout de l'agent utilisateur a du sens. Désolé, une combinaison de mauvaise mémoire à court terme et de trouble déficitaire de l'attention. :-) - splattne
remplacer le having avec un Limit n pourrait être un bon moyen de régler la première requête - BCS


Une chose que vous pourriez envisager pour filtrer le trafic légitime (et élargir votre portée) est de permettre à cs(Cookie) dans vos journaux IIS, ajoutez un peu de code qui définit un petit cookie à l'aide de javascript, puis ajoutez WHERE cs(Cookie)=''.

En raison de votre petite quantité de code, chaque utilisateur devrait avoir un cookie, sauf s'il le désactivait manuellement (ce qu'un pourcentage faible de personnes pourrait créer) ou si cet utilisateur est en réalité un bot qui ne prend pas en charge Javascript (par exemple, wget, httpclient). , etc. ne supporte pas Javascript).

Je soupçonne que si un utilisateur a un volume d'activité élevé, mais qu'il accepte les cookies et que javascript est activé, il est plus probable qu'il soit un utilisateur légitime, alors que si vous trouvez un utilisateur avec un volume d'activité élevé mais sans support des cookies / javascript , ils sont plus susceptibles d'être un bot.


6
2017-07-25 17:26





Désolé, je ne peux pas encore commenter, je suis donc obligé de répondre.

Il y a un bug mineur avec la requête 'Utilisation de la bande passante maximale par URL'. Bien que la plupart du temps, vous puissiez prendre vos demandes de page et les multiplier par la taille du fichier, dans ce cas, étant donné que vous ne prêtez pas attention aux paramètres de requête, vous rencontrerez des problèmes légèrement plus complexes. -très nombres inexacts.

Pour une valeur plus précise, il suffit de faire un SOMME (en octets) à la place du MUL (hits, AvgBytes) comme ServedBytes.


6
2017-09-10 13:11





Anders Lundström a écrit une série d'articles de blog sur les requêtes courantes de LogParser.

J'ai utilisé ceux-ci:


6
2017-10-28 14:12





Ce mec a environ une douzaine de requêtes utiles:

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


5
2017-08-09 15:07



Et ce mec (moi) est toujours chercher plus de requêtes à poster. - James Skemp


Vous voudrez peut-être rechercher vos requêtes les plus longues (stems et / ou requêtes) et celles contenant le plus d'octets reçus par le serveur. Je voudrais également essayer celui qui regroupe les octets reçus et l'adresse IP, afin que vous puissiez voir si un format de demande particulier est probablement répété par une adresse 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

Je compte également les occurrences pour le groupe d'adresses IP demandées pendant une heure et une minute de la journée ou pour le groupe avec la minute qui précède afin de déterminer s'il existe des visites récurrentes qui peuvent être des scripts. Ce serait une petite modification sur le script hits par heure.

Sur tous les sites de non-programmation, il est également judicieux de rechercher dans vos journaux les mots-clés SQL. SELECT, UPDATE, DROP, DELETE et d'autres bizarreries comme FROM sys.tables, Ranger cela ensemble et compter par IP semblerait bien pratique. Pour la plupart des sites incluant ces sites, les mots apparaîtront rarement, voire jamais, dans la partie requête de l'URI, mais ici, ils pourraient apparaître légitimement dans le radical d'URI et les parties données. J'aime inverser les adresses IP des hits pour voir qui exécute des scripts prédéfinis. J'ai tendance à voir .ru, .br, .cz et .cn. Je ne veux pas en juger, mais j'ai tendance à les bloquer désormais. Pour leur défense, ces pays sont généralement majoritairement peuplés, bien que je n’aie pas encore beaucoup à dire. .in, .fr, .us ou .au faire la même chose.

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

P.S. Je ne peux pas vérifier que ces requêtes s'exécutent correctement. Veuillez les éditer librement s'ils ont besoin d'être réparés.


4
2017-07-30 17:06





Ils ont tous été trouvés ici (qui est un excellent guide pour analyser vos fichiers de log IIS, btw):

20 derniers fichiers sur votre site web

logparser -i: FS "chemin TOP 20 sélectionné, heure de création depuis 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

Les 20 derniers fichiers modifiés

logparser -i: FS "chemin TOP 20 choisi, LastWriteTime de c: \ inetpub \ wwwroot *. * ORDER BY 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

Fichiers ayant généré 200 codes d’état (au cas où des chevaux de Troie auraient été supprimés)

logparser "SELECT DISTINCT TO_LOWERCASE (cs-uri-stem) en tant qu'URL, compte () AS hits de 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

Afficher n'importe quelle adresse IP qui a frappé la même page plus de 50 fois en un jour

logparser "SELECT DISTINCT date, cs-uri-stem, c-ip, Count () AS hits de ex.log GROUPE Par date, c-ip, cs-uri-stem AYANT Hits> 50 ORDER BY Hits Description "-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



J'ai regardé ceux-ci et je ne les ai pas trouvés particulièrement utiles. Ils sont principalement "trouver le compromis" et ce n'est pas vraiment notre objectif (nous n'avons pas été compromis) - Jeff Atwood


Je ne sais pas comment faire avec LogParser, mais rechercher des chaînes de requêtes pour des choses telles que "phpMyAdmin" (ou d'autres vulnérabilités courantes) qui obtiennent des 404 pourrait être un bon moyen d'identifier les attaques par script.


0
2017-08-06 19:32



le but n'est pas de trouver des attaques scriptées de ce type, mais des clients irresponsables / problématiques liés à la bande passante et au trafic. - Jeff Atwood
Je dirais que tout client qui essaie de me faire mal est un client à problème et que je préfère ne pas les utiliser avec ma bande passante. - BCS