Các truy vấn LogParser được đề xuất để theo dõi IIS?


86

Khi Stack Overflow phát triển, chúng tôi bắt đầu xem xét kỹ các bản ghi IIS của chúng tôi để xác định các máy khách HTTP có vấn đề - những thứ như trình thu thập dữ liệu web lừa đảo , những người dùng có một trang lớn được thiết lập để làm mới mỗi giây, các công cụ xóa web một lần được viết kém người dùng cố gắng tăng trang đếm hàng triệu lần, v.v.

Tôi đã đưa ra một vài truy vấn LogParser giúp chúng tôi xác định hầu hết các điểm kỳ lạ và bất thường khi chỉ vào tệp nhật ký IIS.

Sử dụng băng thông hàng đầu theo 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 lượt truy cập avgbyte được phục vụ
------------------------------------------------- - ---- ------- -------
/favicon.ico 16774 522 8756028
/content/img/search.png 15342 446 6842532

Lượt truy cập hàng đầu theo 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
lượt truy cập url
------------------------------------------------- - ----
/content/img/sf/vote-arrow-down.png 14076
/content/img/sf/vote-arrow-up.png 14018

Băng thông hàng đầu và lượt truy cập của IP / Tác nhân người dùng

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
lượt truy cập totbyte của tác nhân người dùng
------------- ------------------------------------- -------- --------- -----
66.249,68,47 Mozilla / 5.0 + (tương thích; + Googlebot / 2.1; 135131089 16640
194.90.190.41 omgilibot / 0.3 ++ omgili.com 133805857 6447

Băng thông hàng đầu theo giờ theo IP / Tác nhân người dùng

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 lượt truy cập totbyte tác nhân người dùng khách hàng
- ------------- ----------------------------------- ------ -------- ----
9 194.90.190.41 omgilibot / 0.3 ++ omgili.com 30634860 ​​1549
10 194.90.190.41 omgilibot / 0.3 ++ omgili.com 29070370 1503

Lượt truy cập hàng đầu theo giờ theo IP / Tác nhân người dùng

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 tác nhân người dùng khách truy cập totbyte
- ------------- ----------------------------------- ------ ---- --------
10 194.90.190.41 omgilibot / 0.3 ++ omgili.com 1503 29070370
12 66.249.68.47 Mozilla / 5.0 + (tương thích; + Googlebot / 2.1 1363 13186302

Tất nhiên {tên tệp} sẽ là đường dẫn đến tệp logfile IIS, chẳng hạn như

c:\working\sologs\u_ex090708.log

Tôi đã thực hiện rất nhiều tìm kiếm trên web cho các truy vấn IIS LogParser tốt và tìm thấy rất ít. 5, ở trên, đã giúp chúng tôi rất nhiều trong việc xác định các khách hàng có vấn đề nghiêm trọng. Nhưng tôi đang tự hỏi - chúng ta đang thiếu gì?

Có những cách nào khác để cắt và xé các bản ghi IIS (tốt nhất là với các truy vấn LogParser ) để khai thác chúng cho các bất thường thống kê? Bạn có bất kỳ truy vấn IIS LogParser tốt nào bạn chạy trên máy chủ của mình không?



Trong truy vấn sử dụng băng thông hàng đầu có từ khóa DISTINCT. Nó tốt cho cái gì?
Jakub Šturc

Câu trả lời:


19

Một chỉ báo tốt cho các hoạt động hack hoặc các cuộc tấn công khác là số lỗi mỗi giờ. Kịch bản sau đây trả về ngày và giờ có hơn 25 mã lỗi được trả về. Điều chỉnh giá trị tùy thuộc vào lượng lưu lượng truy cập trên trang web (và chất lượng ứng dụng web của bạn ;-)).

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

Kết quả có thể giống như thế này:

Ngày giờ Trạng thái ErrorCount
---------- -------- ------ ------
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
...

Truy vấn tiếp theo phát hiện số lần truy cập cao bất thường trên một URL từ một địa chỉ IP . Trong ví dụ này tôi đã chọn 500, nhưng bạn có thể phải thay đổi truy vấn cho các trường hợp cạnh (chẳng hạn như địa chỉ IP của Google London chẳng hạn ;-).)

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
Ngày URL IPAddress Lượt truy cập
---------- ----------------------------------- ----- ---------- ----
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
...

truy vấn thứ hai, chúng tôi đã thực hiện - lưu ý việc nhóm trong một số truy vấn. Theo IP và Tác nhân người dùng, đây là điều tốt nhất của cả hai thế giới, vì nếu Tác nhân người dùng là null, thì nó giống như IP và nếu không, đó là thông tin thêm.
Jeff Atwood

Được rồi Jeff, thêm tác nhân người dùng có ý nghĩa. Xin lỗi, sự kết hợp của bộ nhớ thời gian ngắn xấu và Rối loạn thiếu tập trung. :-)
splattne

thay thế havingbằng một Limit ncách tốt có thể điều chỉnh truy vấn đầu tiên
BCS

6

Một điều bạn có thể xem xét để lọc lưu lượng truy cập hợp pháp (và mở rộng phạm vi của bạn) là bật cs(Cookie)trong nhật ký IIS của bạn, thêm một chút mã đặt cookie nhỏ bằng javascript và thêm WHERE cs(Cookie)=''.

Do một chút mã của bạn, mọi người dùng nên có một cookie trừ khi họ vô hiệu hóa cookie theo cách thủ công (điều mà một tỷ lệ nhỏ mọi người có thể làm) hoặc trừ khi người dùng đó thực sự là một bot không hỗ trợ Javascript (ví dụ: wget, httpclient , v.v. không hỗ trợ Javascript).

Tôi nghi ngờ rằng nếu người dùng có khối lượng hoạt động lớn, nhưng họ chấp nhận cookie và bật javascript, thì nhiều khả năng họ là người dùng hợp pháp, trong khi đó nếu bạn tìm thấy người dùng có khối lượng hoạt động lớn nhưng không hỗ trợ cookie / javascript , họ có nhiều khả năng là một bot.


6

Xin lỗi, chưa thể bình luận nên tôi buộc phải trả lời.

Có một lỗi nhỏ với truy vấn 'Sử dụng băng thông hàng đầu theo URL'. Mặc dù hầu hết thời gian bạn sẽ ổn khi nhận yêu cầu của mình cho một trang và nhân với kích thước tệp, trong trường hợp này, vì bạn không chú ý đến bất kỳ tham số truy vấn nào, bạn sẽ gặp phải một chút -rất số không chính xác.

Để có giá trị chính xác hơn, chỉ cần thực hiện SUM (sc-byte) thay vì MUL (Số lần truy cập, mức trung bình) là ServedBytes .




4

Bạn có thể muốn tìm kiếm các yêu cầu dài nhất của bạn (thân và / hoặc truy vấn) và những yêu cầu có nhiều byte nhất mà máy chủ nhận được. Tôi cũng sẽ thử một nhóm theo các byte nhận được và IP, để bạn có thể xem liệu một định dạng yêu cầu cụ thể có khả năng lặp lại bởi một IP hay không.

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

Tôi cũng sẽ đếm số lần truy cập cho nhóm yêu cầu IP trong một giờ và phút mỗi ngày hoặc nhóm IP yêu cầu với số phút để tìm xem có bất kỳ lượt truy cập định kỳ nào có thể là tập lệnh không. Đây sẽ là một sửa đổi nhỏ trên các lượt truy cập theo kịch bản giờ.

Trên bất kỳ các trang web không lập trình, tìm kiếm các bản ghi của bạn cho các từ khóa SQL cũng là một ý tưởng tốt, những thứ như SELECT, UPDATE, DROP, DELETEvà kỳ dị khác như FROM sys.tables, ORing đó với nhau và đếm bằng IP có vẻ tiện dụng. Đối với hầu hết các trang web bao gồm những trang này, các từ hiếm khi xuất hiện trong phần truy vấn của URI, nhưng ở đây chúng có thể xuất hiện hợp pháp trong phần gốc và dữ liệu của URI. Tôi thích đảo ngược IP của bất kỳ lần truy cập nào chỉ để xem ai đang chạy các tập lệnh tiền đề. Tôi có xu hướng thấy .ru, .br, .cz.cn. Tôi không có ý phán xét, nhưng tôi có xu hướng chặn chúng từ đó. Trong lời bào chữa của họ, những nước này thường chủ yếu là dân cư, mặc dù tôi vậy, đến nay tôi không thấy nhiều tiếng nói .in, .fr, .ushoặc .aulàm như vậy.

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 Tôi không thể xác minh rằng những truy vấn này sẽ thực sự chạy chính xác. Vui lòng chỉnh sửa chúng một cách tự do nếu họ cần sửa chữa.


3

Tất cả đều được tìm thấy ở đây (đây là một hướng dẫn tuyệt vời để phân tích cú pháp logfiles IIS của bạn, btw):

20 tập tin mới nhất trên trang web của bạn

logparser -i: FS "CHỌN 20 đường dẫn hàng đầu, CreationTime từ c: \ inetpub \ wwwroot *. * ĐẶT HÀNG THEO 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 tập tin được sửa đổi gần đây nhất

logparser -i: FS "CHỌN 20 đường dẫn hàng đầu, LastWriteTime từ c: \ inetpub \ wwwroot *. * ĐẶT HÀNG THEO 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

Các tệp đã dẫn đến 200 mã trạng thái (trong trường hợp trojan đã bị xóa)

logparser "CHỌN DISTINCT TO_LOWERCASE (cs-uri-thân) AS URL, Count ( ) AS Lượt truy cập TỪ ex .log WHERE sc-status = 200 NHÓM THEO URL ĐẶT HÀNG THEO URL" -rtp: -1

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

Hiển thị bất kỳ địa chỉ IP nào đạt được cùng một trang hơn 50 lần trong một ngày

logparser "CHỌN NGÀY DISTINCT, cs-uri-thân, c-ip, Count ( ) AS Lượt TỪ ex .log NHÓM THEO NGÀY, c-ip, cs-uri-thân HAVING Lượt truy cập> 50 ĐẶT HÀNG THEO Lượt truy cập 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

Tôi đã xem xét chúng và không thấy chúng đặc biệt hữu ích. Họ chủ yếu là "tìm sự thỏa hiệp" và đó không thực sự là mục tiêu của chúng tôi (chúng tôi chưa bị xâm phạm)
Jeff Atwood

0

Tôi không biết làm thế nào để làm điều đó với LogParser nhưng tìm kiếm chuỗi yêu cầu cho những thứ như "phpMyAdmin" (hoặc các công cụ thông thường khác) có được 404 có thể là một cách tốt để xác định các cuộc tấn công theo kịch bản.


mục tiêu không phải là tìm kiếm các cuộc tấn công theo kịch bản loại đó, nhưng các khách hàng vô trách nhiệm / có vấn đề liên quan đến băng thông và lưu lượng truy cập.
Jeff Atwood

2
Tôi muốn nói rằng bất kỳ khách hàng nào đang cố gắng làm tổn thương tôi là một khách hàng có vấn đề và tôi không muốn họ sử dụng băng thông của mình.
BCS
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.