Zalecane zapytania LogParser do monitorowania IIS?

W miarę wzrostu przepełnienia stosu zaczynamy uważnie przyglądać się naszym dziennikom IIS w celu zidentyfikowania problematycznych klientów HTTP - takich jak nieuczciwe pająki internetowe , użytkownicy, którzy mają duży zestaw stron do odświeżania co sekundę, źle napisane jednorazowe skrobaki internetowe, podstępne użytkownicy, którzy próbują zwiększyć stronę, liczą zillion razy i tak dalej.

Wymyśliłem kilka zapytań LogParser, które pomagają nam zidentyfikować większość osobliwości i nieprawidłowości po wskazaniu pliku dziennika IIS.

Najlepsze wykorzystanie przepustowości według adresu 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

adres URL trafił do avgbyte
------------------------------------------------- - ---- ------- -------
/favicon.ico 16774 522 8756028
/content/img/search.png 15342 446 6842532

Najczęściej wyszukiwane według adresu 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

adresy URL trafień
------------------------------------------------- - ----
/content/img/sf/vote-arrow-down.png 14076
/content/img/sf/vote-arrow-up.png 14018

Najwyższa przepustowość i trafienia według 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

klient użytkownik-klient sumuje trafienia
------------- ------------------------------------- -------- --------- -----
66.249.68.47 Mozilla / 5.0 + (kompatybilny; + Googlebot / 2.1; 135131089 16640
194.90.190.41 omgilibot / 0.3 ++ omgili.com 133805857 6447

Najwyższa przepustowość według godziny według 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 klient użytkownik-klient sumuje liczbę trafień
- ------------- ----------------------------------- ------ -------- ----
9 194,90.190.41 omgilibot / 0.3 ++ omgili.com 30634860 ​​1549
10 194,90.190,41 omgilibot / 0,3 ++ omgili.com 29070370 1503

Największe trafienia według godziny według 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

Klient kliencki hr uderza totbytes
- ------------- ----------------------------------- ------ ---- --------
10 194,90.190,41 omgilibot / 0,3 ++ omgili.com 1503 29070370
12 66.249.68.47 Mozilla / 5.0 + (kompatybilny; + Googlebot / 2.1 1363 13186302

{Nazwa pliku} oczywiście byłaby ścieżką do pliku dziennika IIS, takiego jak

c:\working\sologs\u_ex090708.log

Przeprowadziłem wiele wyszukiwań w sieci w poszukiwaniu dobrych zapytań IIP LogParser i znalazłem niewiele cennego. Powyższe 5 punktów pomogło nam ogromnie w identyfikacji poważnych klientów. Ale zastanawiam się - czego nam brakuje?

Jakie są inne sposoby dzielenia i krojenia dzienników IIS (najlepiej za pomocą zapytań LogParser ) w celu ich wydobycia pod kątem anomalii statystycznych? Czy masz jakieś dobre zapytania IIS LogParser uruchamiane na twoich serwerach?

Dobrym wskaźnikiem dla działań hakerskich lub innych ataków jest liczba błędów na godzinę. Poniższy skrypt zwraca daty i godziny, w których zwrócono ponad 25 kodów błędów . Dostosuj wartość w zależności od natężenia ruchu w witrynie (i jakości aplikacji internetowej ;-)).

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

Wynik może być taki:

Data Godzina Status Błąd Liczba
---------- -------- ------ ------
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
...

Następne zapytanie wykrywa niezwykle wysoką liczbę trafień pod jednym adresem URL z jednego adresu IP . W tym przykładzie wybrałem 500, ale może być konieczna zmiana zapytania o przypadki skrajne (na przykład z wyłączeniem adresu IP 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

Data Adres URL Adres IP Odsłon
---------- ----------------------------------- ----- ---------- ----
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
...

Jedną rzeczą, którą możesz rozważyć, aby odfiltrować prawidłowy ruch (i rozszerzyć zakres), jest włączenie cs(Cookie)dzienników IIS, dodanie kodu, który ustawia małe ciasteczko przy użyciu javascript, i dodanie WHERE cs(Cookie)=''.

Z powodu małego fragmentu kodu każdy użytkownik powinien mieć plik cookie, chyba że ręcznie wyłączy pliki cookie (co może zrobić mały procent osób) lub jeśli ten użytkownik nie jest botem, który nie obsługuje Javascript (na przykład wget, httpclient itp. nie obsługują Javascript).

Podejrzewam, że jeśli użytkownik ma dużą aktywność, ale akceptuje pliki cookie i ma włączoną obsługę JavaScript, istnieje większe prawdopodobieństwo, że będzie uprawnionym użytkownikiem, natomiast jeśli znajdziesz użytkownika o dużej aktywności, ale bez obsługi plików cookie / JavaScript , częściej są botem.

Przepraszamy, nie mogę jeszcze komentować, więc jestem zmuszony odpowiedzieć.

Wystąpił drobny błąd w zapytaniu „Wykorzystanie największej przepustowości według adresu URL”. Podczas gdy przez większość czasu nie miałbyś nic przeciwko przyjmowaniu żądań strony i mnożeniu przez rozmiar pliku, w tym przypadku, ponieważ nie zwracasz uwagi na żadne parametry zapytania, natkniesz się na nieco -bardzo niedokładne liczby.

Aby uzyskać dokładniejszą wartość, po prostu wykonaj SUMĘ (sc-bytes) zamiast MUL (Hits, AvgBytes) jako ServedBytes .

Anders Lundström pisze serię artykułów na blogu dotyczących typowych zapytań LogParser.

Korzystałem z tych:

• LOGPARSER # 1: Wysłano 10 najlepszych obrazów według rozmiaru
• LOGPARSER # 5: Top 10 najwolniejszych stron ASPX
• LOGPARSER # 12: Rozwiązywanie problemów, kto powoduje 500 błędów?
• LOGPARSER # 23: Pobierz wersję systemu operacyjnego od użytkowników odwiedzających Twoją witrynę

Ten facet ma około tuzina przydatnych zapytań:

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

Możesz poszukać najdłuższych żądań (rdzeni i / lub zapytań) oraz tych o największej liczbie bajtów odebranych przez serwer. Spróbowałbym również takiego, który grupuje według odebranych bajtów i adresu IP, abyś mógł zobaczyć, czy określony format żądania jest prawdopodobnie powtarzany przez jeden adres 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

Liczę również trafienia dla grupy żądającej adresu IP przez godzinę i minutę dziennie lub grupuję żądający adres IP z minutą godziny, aby sprawdzić, czy są jakieś regularnie powtarzające się wizyty, które mogą być skryptami. Byłaby to niewielka modyfikacja skryptu trafień według godziny.

Na jakichkolwiek witryn bez programowania, szukając dzienników SQL słów kluczowych jest również dobrym pomysłem, rzeczy takie jak SELECT, UPDATE, DROP, DELETEoraz inne dziwactwa jak FROM sys.tables, Oring że razem i liczenia przez IP wydaje się przydać. W przypadku większości witryn, w tym tych, słowa rzadko pojawiałyby się w części zapytania identyfikatora URI, ale w tym przypadku mogą one występować w rdzeniu identyfikatora URI i częściach danych. Lubię odwracać adresy IP wszystkich trafień, aby zobaczyć, kto uruchamia gotowe skrypty. I mają tendencję, aby zobaczyć .ru, .br, .czi .cn. Nie mam zamiaru osądzać, ale mam tendencję do blokowania ich odtąd. W ich obronie, kraje te są na ogół głównie zaludnionych, choć do tej pory nie widzę dużo powiedzmy .in, .fr, .uslub .aurobi to samo.

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

PS Nie mogę zweryfikować, czy te zapytania faktycznie działałyby poprawnie. Edytuj je dowolnie, jeśli wymagają naprawy.

Wszystkie zostały znalezione tutaj (który jest doskonałym przewodnikiem do parsowania plików logów IIS, btw):

20 najnowszych plików na twojej stronie

logparser -i: FS "WYBIERZ TOP 20 Ścieżka, CreationTime z c: \ inetpub \ wwwroot *. * ZAMÓWIENIE 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 ostatnio zmodyfikowanych plików

logparser -i: FS "WYBIERZ TOP 20 Ścieżka, LastWriteTime z 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

Pliki, których wynikiem jest 200 kodów stanu (w przypadku usunięcia trojanów)

logparser "SELECT DISTINCT TO_LOWERCASE (cs-uri-stem) AS URL, Count ( ) AS HITS FROM ex np. 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

Pokaż dowolny adres IP, który trafił na tę samą stronę więcej niż 50 razy w ciągu jednego dnia

logparser "WYBIERZ ODLEGŁOŚĆ data, cs-uri-stem, c-ip, Count ( ) AS Hits Z np. log GROUP GROUP według daty, c-ip, cs-uri-stem POSIADAJĄC Trafienia> 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

Nie wiem, jak to zrobić za pomocą LogParser, ale szukanie ciągów żądań takich rzeczy jak „phpMyAdmin” (lub innych typowych błędów), które dostają 404, może być dobrym sposobem na identyfikację ataków skryptowych.