Requêtes LogParser recommandées pour IIS surveillance?
Au fur et à mesure que Stack Overflow se développe, nous commençons à examiner de près nos journaux IIS pour identifier les clients HTTP problématiques - des choses comme araignées Web escrocs , les utilisateurs qui ont un grand page mise à jour toutes les secondes, grattoirs Web mal rédigés, utilisateurs rusés qui tentent d'augmenter le nombre de pages un million de fois, etc.
J'ai trouvé quelques LogParser requêtes qui nous aident à identifier la plupart des bizarreries et des anomalies lorsqu'elles sont pointées vers 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 serve ------------------------------------ ------------- ----- ------- ------- /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 frappe -------------------------------------- ----------- ----- /content/img/sf/vote-arrow-down.png 14076 /content/img/sf/vote- arrow-up.png 14018
Bande passante et hits supérieurs 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
totaux de l'agent utilisateur client atteint ------------- --------------------- ------------------------ --------- ----- 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 utilisateur-utilisateur 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 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 l'agent utilisateur du client atteint le nombre de octets - ------------- ------------------ ----------------------- ---- -------- 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 de fichier} serait bien sûr un chemin vers un fichier journal IIS, tel que
c:\working\sologs\u_ex090708.log
J'ai fait beaucoup de recherches sur le Web pour de bonnes IIS requêtes LogParser et trouvé peu de choses précieuses. Ces 5, ci-dessus, nous ont énormément aidés à identifier les clients à problèmes graves. Mais je me demande - quels sont nous manque?
Quelles sont les autres façons de découper et de découper les journaux IIS (de préférence avec les requêtes LogParser ) pour les exploiter afin de détecter des anomalies statistiques? Avez-vous de bonnes IIS requêtes LogParser que vous exécutez sur vos serveurs?
Un bon indicateur des activités de piratage ou d'autres attaques est le nombre d'erreurs par heure. Le script suivant retourne le dates et heures contenant plus de 25 codes d'erreur retourné. Ajustez la valeur en fonction du 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 État ErreurCompte ---------- -------- ------ ------ 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 Edge (à l'exclusion 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 IPAddress 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 ...
Anders Lundström a écrit une série d'articles de blog concernant les requêtes LogParser courantes.
Je les utilise:
Désolé, je ne peux pas encore commenter, donc je suis obligé de répondre.
Il y a un bug mineur avec la requête `` Utilisation de la bande passante supérieure par URL ''. Alors que la plupart du temps, vous seriez d'accord pour prendre vos demandes de page et multiplier par la taille du fichier, dans ce cas, puisque vous ne faites attention à aucun paramètre de requête, vous allez en rencontrer légèrement -des chiffres très inexacts.
Pour une valeur plus précise, faites juste un SUM (sc-bytes) au lieu de MUL (Hits, AvgBytes) as ServedBytes.
Une chose que vous pourriez envisager pour filtrer le trafic légitime (et élargir votre portée) est d'activer cs(Cookie) dans vos journaux IIS, ajoutez un peu de code qui définit un petit cookie en utilisant javascript, et ajoutez WHERE cs(Cookie)=''.
En raison de votre petit morceau de code, chaque utilisateur doit avoir un cookie, sauf s'il a désactivé manuellement les cookies (ce qu'un petit pourcentage de personnes pourraient faire) ou à moins que cet utilisateur ne soit en fait un bot qui ne prend pas en charge Javascript (par exemple, wget, httpclient , etc. ne prennent pas en charge 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 susceptible d'être un utilisateur légitime, alors que si vous trouvez un utilisateur avec un volume d'activité élevé mais pas de support cookie/javascript , ils sont plus susceptibles d'être un bot.
Ce gars a environ une douzaine de requêtes utiles:
Vous voudrez peut-être rechercher vos demandes les plus longues (tiges et/ou requêtes) et celles contenant le plus d'octets reçues par le serveur. J'essaierais également celui qui regroupe les octets reçus et l'IP, afin que vous puissiez voir si un format de demande particulier est probablement répété par une 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 compterais également les hits pour le groupe d'IP demandant pendant une heure et une minute d'une journée, ou grouper l'IP demandant avec la minute de l'heure pour trouver s'il y a des visites régulièrement récurrentes qui peuvent être des scripts. Ce serait une petite modification du script hits by hour.
Sur tous les sites hors programmation, la recherche dans vos journaux de mots clés SQL est également une bonne idée, des choses comme SELECT, UPDATE, DROP, DELETE et autres bizarreries comme FROM sys.tables, ORing cela ensemble et compter par IP semblerait pratique. Pour la plupart des sites, y compris ceux-ci, les mots apparaissent rarement, voire jamais, dans la partie requête de l'URI, mais ici, ils peuvent légitimement apparaître dans la partie racine et les parties de données de l'URI. J'aime inverser les adresses IP de tous les hits juste pour voir qui exécute des scripts premade. J'ai tendance à voir .ru, .br, .cz et .cn. Je ne veux pas juger, mais j'ai tendance à les bloquer désormais. Pour leur défense, ces pays sont généralement majoritairement peuplés, même si jusqu'à présent je ne vois pas grand-chose à dire .in, .fr, .us ou .au faire de même.
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écuteraient correctement. Veuillez les modifier librement s'ils ont besoin d'être réparés.
Ils ont tous été trouvés ici (qui est un excellent guide pour analyser vos IIS logfiles, btw):
20 fichiers les plus récents sur votre site 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 derniers fichiers modifiés
logparser -i: FS "SELECT TOP 20 Path, LastWriteTime from 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) 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
Afficher toute adresse IP qui a frappé la même page plus de 50 fois en une seule journée
logparser "SELECT DISTINCT date, cs-uri-stem, c-ip, Count () AS Hits FROM ex. log GROUP BY date, c-ip, cs-uri-stem HAVING Hits> 50 ORDRE PAR 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
Je ne sais pas comment le faire avec LogParser, mais la recherche de chaînes de demandes pour des choses comme "phpMyAdmin" (ou d'autres fonctionnalités courantes) qui reçoivent 404 peut être un bon moyen d'identifier les attaques par script.