Vraag Aanbevolen LogParser-query's voor IIS-bewaking?


Naarmate Stack Overflow groeit, beginnen we onze IIS-logboeken nauwkeurig te bekijken om probleem HTTP-clients te identificeren, zoals dingen rogue web spiders, gebruikers die een grote paginaset hebben om elke seconde te vernieuwen, slecht geschreven eenmalige webschrapers, lastige gebruikers die een paginatelling van een miljoen keer proberen te verhogen, enzovoort.

Ik heb er een paar bedacht LOGPARSER queries die ons helpen de meeste eigenaardigheden en afwijkingen te identificeren bij het verwijzen naar een IIS-logbestand.

Gebruik van de hoogste bandbreedte per 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 geserveerd
------------------------------------------------- - ---- ------- -------
/favicon.ico 16774 522 8756028
/content/img/search.png 15342 446 6842532

Top hits op 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

Hoogste bandbreedte en hits door 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
client user-agent totbytes-hits
------------- ------------------------------------- -------- --------- -----
66.249.68.47 Mozilla / 5.0 + (compatibel; + Googlebot / 2.1; 135131089 16640
194.90.190.41 omgilibot / 0.3 ++ omgili.com 133805857 6447

Hoogste bandbreedte per uur door 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-agent 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 per uur door 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 user-agent slaat totbytes
- ------------- ----------------------------------- ------ ---- --------
10 194.90.190.41 omgilibot / 0.3 ++ omgili.com 1503 29070370
12 66.249.68.47 Mozilla / 5.0 + (compatibel; + Googlebot / 2.1 1363 13186302

De {filename} is natuurlijk een pad naar een IIS-logbestand, zoals

c:\working\sologs\u_ex090708.log

Ik deed veel zoekopdrachten op het web naar goede IIS LogParser-zoekopdrachten en vond er heel weinig van. Deze 5 hierboven hebben ons enorm geholpen bij het identificeren van serieuze probleemcliënten. Maar ik vraag me af - wat missen we?

Welke andere manieren zijn er om de IIS-logs te snijden en in te delen (bij voorkeur met LogParser-query's) om ze te ontginnen voor statistische anomalieën? Heeft u goede IIS LogParser-query's die u op uw servers uitvoert? 


86
2017-07-25 11:19


oorsprong


Gerefereerd door blog.stackoverflow.com/2009/07/podcast-63 - Brad Gilbert
In de zoekopdracht voor de hoogste bandbreedtegebruik is er een DISTINCT-sleutelwoord. Waar is het goed voor? - Jakub Šturc


antwoorden:


Een goede indicator voor hacking-activiteiten of andere aanvallen is het aantal fouten per uur. Het volgende script retourneert de datums en uren met meer dan 25 foutcodes teruggekeerd. Pas de waarde aan afhankelijk van de hoeveelheid verkeer op de site (en de kwaliteit van uw webtoepassing ;-)).

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

Het resultaat kan zoiets als dit:

Date Hour Status ErrorCount
---------- -------- ------ ------
2009-07-24 18:00:00 404 187
17-07-2007 13:00:00 500 99
2009-07-21 21:00:00 404 80
2009-07-03 04:00:00 404 45
...

De volgende query detecteert een ongewoon hoog aantal hits op één URL vanaf één IP-adres. In dit voorbeeld heb ik 500 gekozen, maar het kan zijn dat u de zoekopdracht voor randgevallen (met uitzondering van het IP-adres van bijvoorbeeld Google London ;-).)

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
Datum URL IPadres 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



de tweede vraag doen we al - let op de groepering in verschillende van de vragen. Door IP en User Agent is dit het beste van beide werelden, want als de User Agent null is, is het hetzelfde als IP, en zo niet, dan is dat meer info. - Jeff Atwood
Oké, Jeff, het toevoegen van de user-agent is logisch. Sorry, een combinatie van slecht kortstondig geheugen en Attention Deficit Disorder. :-) - splattne
ter vervanging van de having met een Limit n kan een goede manier zijn om de eerste zoekopdracht af te stemmen - BCS


Een ding dat u zou kunnen overwegen om legitiem verkeer uit te filteren (en uw bereik te verbreden) is om in te schakelen cs(Cookie) voeg in uw IIS-logboeken een stukje code toe dat een klein cookie met javascript instelt en voeg toe WHERE cs(Cookie)=''.

Vanwege je klein beetje code, zou elke gebruiker een cookie moeten hebben tenzij deze cookies handmatig zou uitschakelen (wat een klein percentage van de mensen zou kunnen doen) of tenzij die gebruiker eigenlijk een bot is die geen Javascript ondersteunt (bijvoorbeeld, wget, httpclient , enz. ondersteunen geen Javascript).

Ik vermoed dat als een gebruiker een hoog activiteitenvolume heeft, maar zij cookies accepteren en javascript hebben ingeschakeld, ze waarschijnlijk een legitieme gebruiker zijn, terwijl als u een gebruiker vindt met een hoog activiteitenvolume maar geen cookie / javascript-ondersteuning , ze zijn meer kans om een ​​bot te zijn.


6
2017-07-25 17:26





Sorry, ik kan nog geen commentaar geven, dus ik moet antwoorden.

Er is een klein probleem met de zoekopdracht 'Top bandbreedte gebruik door URL'. Hoewel u meestal de meeste tijd neemt om uw paginaverzoeken in te vullen en te vermenigvuldigen met de bestandsgrootte, omdat u in dit geval geen aandacht besteedt aan queryparameters, zult u enigszins tegenkomen -zeer onnauwkeurige cijfers.

Voor een meer accurate waarde, doe gewoon a SUM (sc-bytes) in plaats van de MUL (Hits, AvgBytes) als ServedBytes.


6
2017-09-10 13:11





Anders Lundström heeft een reeks blogartikelen geschreven over veelvoorkomende LogParser-query's.

Ik heb deze gebruikt:


6
2017-10-28 14:12





Deze gast heeft ongeveer een dozijn nuttige vragen:

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


5
2017-08-09 15:07



En die gast (ik) is altijd op zoek naar meer vragen om te plaatsen. - James Skemp


U wilt mogelijk uw langste verzoeken (stengels en / of query's) en die met de meeste bytes die door de server zijn ontvangen, zoeken. Ik zou er ook een proberen die groepen op basis van de bytes ontvangt en de IP, zodat u kunt zien of een bepaalde aanvraagindeling waarschijnlijk wordt herhaald met één 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

Ik tel ook de hits voor de groep van verzoekende IP voor een uur en minuut van een dag, of groepeer de verzoekende IP met de minuut van het uur om te zien of er regelmatig terugkerende bezoeken zijn die scripts kunnen zijn. Dit zou een kleine wijziging zijn in het hits by hour script.

Op alle niet-programmeringsites is het zoeken naar uw logs voor SQL-sleutelwoorden ook een goed idee, zoals SELECT, UPDATE, DROP, DELETE en andere eigenaardigheden zoals FROM sys.tables, ORING dat samen en tellen door IP lijkt handig. Voor de meeste sites, inclusief deze, verschijnen de woorden zelden of nooit in het querygedeelte van de URI, maar hier kunnen ze legitiem in de URI-stam en gegevensonderdelen voorkomen. Ik vind het leuk om de IP's van hits om te draaien, om erachter te komen wie er premadescripts gebruikt. Ik heb de neiging om het te zien .ru, .br, .cz en .cn. Ik wil niet oordelen, maar ik ben geneigd ze voortaan te blokkeren. In hun verdediging zijn die landen over het algemeen meestal bevolkt, hoewel ik tot nu toe niet veel zegswijze zie .in, .fr, .us of .au hetzelfde doen.

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

Postscriptum Ik kan niet verifiëren dat deze query's correct worden uitgevoerd. Bewerk ze alstublieft vrijelijk als ze moeten worden hersteld.


4
2017-07-30 17:06





Deze zijn allemaal gevonden hier (wat een uitstekende gids is voor het parseren van uw IIS-logbestanden, tussen haakjes):

20 nieuwste bestanden op uw website

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 meest recent gewijzigde bestanden

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

Bestanden die hebben geresulteerd in 200 statuscodes (in het geval trojans zijn verwijderd)

logparser "SELECT DISTINCT TO_LOWERCASE (cs-uri-stem) ALS URL, Tel () AS Hits FROM ex.log WHERE sc-status = 200 GROEP OP URL BESTELLING OP URL "-rtp: -1

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

Toon elk IP-adres dat dezelfde pagina meer dan 50 keer op dezelfde dag raakt

logparser "SELECT DISTINCT date, cs-uri-stem, c-ip, Count () AS Hits FROM ex.log GROUP BY-datum, c-ip, cs-uri-stem HAVING Hits> 50 BESTELLING 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



Ik heb daarnaar gekeken en vond ze niet bijzonder nuttig. Ze zijn meestal "vind het compromis" en dat is niet echt ons doel (we zijn niet in de problemen geraakt) - Jeff Atwood


Ik weet niet hoe ik het moet doen met LogParser, maar op zoek naar strings van verzoeken voor zaken als "phpMyAdmin" (of andere veel voorkomende vunerablities) die 404s kunnen een goede manier zijn om gescripte aanvallen te identificeren.


0
2017-08-06 19:32



het doel is niet om gescripte aanvallen van dat type te vinden, maar onverantwoordelijke / probleemcliënten gerelateerd aan bandbreedte en verkeer. - Jeff Atwood
Ik zou zeggen dat elke client die probeert mij pijn te doen een probleemclient is en ik liever niet heb dat ze mijn bandbreedte gebruiken. - BCS