Pertanyaan LogParser yang disarankan untuk pemantauan IIS?

86

Ketika Stack Overflow tumbuh, kami mulai melihat dengan cermat pada log IIS kami untuk mengidentifikasi masalah klien HTTP - hal-hal seperti laba-laba web jahat , pengguna yang memiliki halaman besar yang diatur untuk menyegarkan setiap detik, pencakar web sekali pakai yang ditulis dengan buruk, rumit pengguna yang mencoba menambah halaman menghitung miliaran kali, dan sebagainya.

Saya telah datang dengan beberapa pertanyaan LogParser yang membantu kami mengidentifikasi sebagian besar keanehan dan kelainan ketika diarahkan ke file log IIS.

Penggunaan bandwidth teratas dengan 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 disajikan
------------------------------------------------- - ---- ------- -------
/favicon.ico 16774 522 8756028
/content/img/search.png 15342 446 6842532

Hit teratas dengan 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

hit url
------------------------------------------------- - ----
/content/img/sf/vote-arrow-down.png 14076
/content/img/sf/vote-arrow-up.png 14018

Bandwidth dan klik top oleh 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

klien, agen, jumlah pengguna, hit
------------- ------------------------------------- -------- --------- -----
66.249.68.47 Mozilla / 5.0 + (kompatibel; + Googlebot / 2.1; 135131089 16640
194.90.190.41 omgilibot / 0.3 ++ omgili.com 133805857 6447

Bandwidth teratas per jam oleh 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

jam klien-agen pengguna hit
- ------------- ----------------------------------- ------ -------- ----
9 194.90.190.41 omgilibot / 0.3 ++ omgili.com 30634860 ​​1549
10 194.90.190.41 omgilibot / 0.3 ++ omgili.com 29070370 1503

Hit teratas per jam oleh 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

jam agen pengguna klien mencapai totbytes
- ------------- ----------------------------------- ------ ---- --------
10 194.90.190.41 omgilibot / 0.3 ++ omgili.com 1503 29070370
12 66.249.68.47 Mozilla / 5.0 + (kompatibel; + Googlebot / 2.1 1363 13186302

{Nama file} tentu saja akan menjadi jalur ke file log IIS, seperti

c:\working\sologs\u_ex090708.log

Saya melakukan banyak pencarian web untuk pertanyaan-pertanyaan IIS LogParser yang bagus dan menemukan sedikit yang berharga. Kelima, di atas, telah sangat membantu kami dalam mengidentifikasi klien-klien bermasalah yang serius. Tapi saya bertanya-tanya - apa yang kita lewatkan?

Apa cara lain yang ada untuk mengiris dan memotong log IIS (lebih disukai dengan pertanyaan LogParser ) untuk menambang mereka untuk anomali statistik? Apakah Anda memiliki pertanyaan IIS LogParser yang Anda jalankan di server Anda?

iis  logparser 
— Jeff Atwood
sumber
5
— Brad Gilbert
Di kueri penggunaan bandwidth teratas ada kata kunci DISTINCT. Apa gunanya?
— Jakub Šturc

Jawaban:

19

Indikator yang baik untuk aktivitas peretasan atau serangan lainnya adalah jumlah kesalahan per jam. Skrip berikut mengembalikan tanggal dan jam yang mengembalikan lebih dari 25 kode kesalahan . Sesuaikan nilainya tergantung pada jumlah lalu lintas di situs (dan kualitas aplikasi web Anda ;-)).

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

Hasilnya bisa seperti ini:

Tanggal Jam Status Kesalahan
---------- -------- ------ ------
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
...

Kueri berikutnya mendeteksi jumlah klik yang luar biasa tinggi pada satu URL dari satu alamat IP . Dalam contoh ini saya memilih 500, tetapi Anda mungkin harus mengubah kueri untuk kasus tepi (tidak termasuk alamat IP Google London misalnya ;-).)

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

URL Tanggal 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
...
— percikan
sumber
permintaan kedua, sudah kami lakukan - perhatikan pengelompokan di beberapa pertanyaan. Dengan IP dan User Agent, ini adalah yang terbaik dari kedua dunia, karena jika User Agent adalah nol, itu sama dengan IP, dan jika tidak, itu info lebih lanjut.
— Jeff Atwood
Oke Jeff, menambahkan agen-pengguna masuk akal. Maaf, kombinasi memori pendek yang buruk dan Attention Deficit Disorder. :-)
— splattne
mengganti havingdengan Limit nmungkin membuat cara yang baik untuk menyetel kueri pertama
— BCS
6

Satu hal yang dapat Anda pertimbangkan untuk menyaring lalu lintas yang sah (dan memperluas cakupan Anda) adalah mengaktifkan cs(Cookie)di log IIS Anda, menambahkan sedikit kode yang menetapkan cookie kecil menggunakan javascript, dan menambahkan WHERE cs(Cookie)=''.

Karena sedikit kode Anda, setiap pengguna harus memiliki cookie kecuali mereka menonaktifkan cookie secara manual (yang mungkin dilakukan sebagian kecil orang) atau kecuali pengguna itu sebenarnya adalah bot yang tidak mendukung Javascript (misalnya, wget, httpclient , dll. tidak mendukung Javascript).

Saya menduga bahwa jika pengguna memiliki aktivitas volume tinggi, tetapi mereka menerima cookie dan mengaktifkan javascript, mereka lebih cenderung menjadi pengguna yang sah, sedangkan jika Anda menemukan pengguna dengan volume aktivitas tinggi tetapi tidak ada dukungan cookie / javascript , mereka lebih cenderung menjadi bot.

— Adam Brand
sumber
6

Maaf, belum bisa berkomentar jadi saya terpaksa menjawab.

Ada bug kecil dengan permintaan 'Penggunaan bandwidth teratas menurut URL'. Sementara sebagian besar waktu Anda akan baik-baik saja mengambil permintaan Anda untuk halaman dan mengalikan dengan ukuran file, dalam hal ini, karena Anda tidak memperhatikan parameter kueri, Anda akan mengalami beberapa ke Nomor -sangat tidak akurat.

Untuk nilai yang lebih akurat, lakukan saja SUM (sc-bytes) alih-alih MUL (Hits, AvgBytes) sebagai ServedBytes .

— James Skemp
sumber
4

Anda mungkin ingin mencari permintaan terpanjang Anda (batang dan / atau pertanyaan), dan permintaan dengan sebagian besar byte yang diterima oleh server. Saya juga akan mencoba yang mengelompokkan berdasarkan byte yang diterima dan IP, sehingga Anda dapat melihat apakah format permintaan tertentu yang kemungkinan diulang dengan satu 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

Saya juga menghitung hit untuk grup yang meminta IP selama satu jam dan menit dalam sehari, atau mengelompokkan IP yang meminta dengan menit dari jam untuk menemukan apakah ada kunjungan berulang yang secara teratur dapat berupa skrip. Ini akan menjadi modifikasi kecil pada hits oleh skrip jam.

Pada situs-situs non-pemrograman, mencari log untuk kata kunci SQL juga merupakan ide yang baik, hal-hal seperti SELECT, UPDATE, DROP, DELETEdan keanehan lainnya seperti FROM sys.tables, ORing yang bersama-sama dan menghitung dengan IP akan tampak berguna. Untuk sebagian besar situs termasuk ini, kata-kata akan jarang jika pernah muncul di bagian permintaan URI, tetapi di sini mereka mungkin muncul secara sah di batang URI dan bagian data. Saya suka membalikkan IP dari hit apa saja hanya untuk melihat siapa yang menjalankan skrip premade. Saya cenderung melihat .ru, .br, .czdan .cn. Saya tidak bermaksud menghakimi, tetapi saya agak cenderung memblokir mereka untuk selanjutnya. Dalam pertahanan mereka, negara-negara umumnya sebagian besar dihuni, meskipun saya sejauh ini saya tidak melihat banyak katakanlah .in, .fr, .usatau .aumelakukan hal yang sama.

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 Saya tidak dapat memverifikasi bahwa pertanyaan ini benar-benar akan berjalan dengan benar. Harap edit secara bebas jika perlu diperbaiki.

— dlamblin
sumber
3

Ini semua ditemukan di sini (yang merupakan panduan yang sangat baik untuk mem-parsing file IIS Anda, btw):

20 file terbaru di situs web Anda

logparser -i: FS "SELECT TOP 20 Path, CreationTime dari 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 file yang paling baru dimodifikasi

logparser -i: FS "SELECT TOP 20 Path, LastWriteTime dari c: \ inetpub \ wwwroot *. * PESANAN OLEH 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

File yang menghasilkan 200 kode status (seandainya trojan dihapus)

logparser "SELECT DISTINCT TO_LOWERCASE (cs-uri-stem) AS URL, Hitung ( ) AS Hits DARI ex .log WHERE sc-status = 200 KELOMPOK DENGAN PESAN URL DENGAN PESAN DENGAN URL" -rtp: -1

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

Tampilkan alamat IP apa pun yang mengenai halaman yang sama lebih dari 50 kali dalam satu hari

logparser "SELECT DISTINCT date, cs-uri-stem, c-ip, Hitung ( ) SEBAGAI Hits DARI ex .log GROUP DENGAN tanggal, 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
— GregD
sumber
Saya telah melihat itu dan tidak menemukan mereka sangat membantu. Mereka sebagian besar "menemukan kompromi" dan itu bukan tujuan kami (kami belum pernah dikompromikan)
— Jeff Atwood
0

Saya tidak tahu bagaimana cara melakukannya dengan LogParser tetapi mencari serangkaian permintaan untuk hal-hal seperti "phpMyAdmin" (atau vunerablities umum lainnya) yang mendapatkan 404s mungkin cara yang baik untuk mengidentifikasi serangan skrip.

— BCS
sumber
tujuannya bukan untuk menemukan serangan skrip jenis itu, tetapi klien yang tidak bertanggung jawab / masalah yang terkait dengan bandwidth dan lalu lintas.
— Jeff Atwood
2
Saya akan mengatakan klien mana pun yang mencoba menyakiti saya adalah klien bermasalah dan saya lebih suka tidak menggunakan bandwidth saya.
— BCS
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.