გამოიკვლიეთ Windows‑ის, IIS‑ისა და ვებსერვერის ჟურნალები

აირჩიეთ სწორი ჟურნალი Event Viewer‑ში

Event Viewer‑ში Windows Logs შეიცავს Application, Security, Setup, System და Forwarded Events ჟურნალებს; Application and Services Logs შეიცავს პროდუქტებისა და სერვისების არხებს. მომხმარებლის შეტყობინებით ან მონიტორინგის სიგნალით დაავიწროეთ დროის ფანჯარა, შემდეგ გაფილტრეთ პროვაიდერით, Event ID‑ითა და დონით. ფაილზე პირდაპირი წვდომა ჩვეულებრივ საჭირო არ არის; Event Viewer‑ის ფილტრები და ექსპორტი უფრო უსაფრთხო, გამეორებად გამოძიებას უწყობს ხელს.

1. 01

   დაავიწროეთ დროის ფანჯარა

   აირჩიეთ ფანჯარა მოვლენამდე და მის შემდეგ; მიუთითეთ სისტემური საათი და დროის სარტყელი.

2. 02

   აირჩიეთ ჟურნალი და დონე

   System მოიცავს დრაივერებსა და სერვისებს, Application — პროგრამულ შეცდომებს, Security კი — აუდიტის მოვლენებს.

3. 03

   შეადარეთ დაკავშირებული ჩანაწერები

   რამდენიმე წყარო შეადარეთ დროის, პროვაიდერის, მომხმარებლის ან კორელაციის ID‑ის მიხედვით.

წაიკითხეთ შეცდომები PowerShell‑ით

Get-WinEvent გამოკითხავს Windows Event Log‑სა და ETW‑ჟურნალებს. FilterHashtable ჟურნალის წაკითხვისას იყენებს დროის, არხისა და დონის პირობებს, რაც დიდი ჟურნალის მთლიანად მიღებისა და შემდეგ გაფილტვრის სჯობს. ეს მაგალითი System‑ჟურნალიდან კითხულობს ბოლო 24 საათის Error‑დონის მოვლენების შეზღუდულ ნაკრებს. ზოგ არხს დამატებითი უფლებები სჭირდება.

      $since = (Get-Date).AddHours(-24)
Get-WinEvent -FilterHashtable @{ LogName = 'System'; Level = 2; StartTime = $since } -MaxEvents 100 | Select-Object TimeCreated, Id, ProviderName, LevelDisplayName, Message
    

Security‑მოვლენები კონტექსტში წაიკითხეთ

Security‑ჟურნალში 4624 წარმატებულ შესვლას აღნიშნავს, 4625 კი — წარუმატებელ მცდელობას. მხოლოდ Event ID კომპრომეტირების მტკიცებულება არ არის: შეადარეთ ანგარიში, შესვლის ტიპი, წყაროს მისამართი, ჰოსტი, დრო და ამ ანგარიშისთვის მოსალოდნელი ქცევა. მოვლენის წარმოქმნა აუდიტის პოლიტიკაზეა დამოკიდებული; მაგალითად, ობიექტის უფლების ცვლილების 4670‑ად აღრიცხვას შეიძლება შესაბამისი აუდიტი და ობიექტის SACL დასჭირდეს. მოვლენა 4688 პროცესის შექმნას აღრიცხავს, მაგრამ მისი ბრძანების სტრიქონის ველი ცალკე აუდიტის პოლიტიკით ირთვება. თითოეული Event ID შეამოწმეთ Microsoft‑ის მიმდინარე დოკუმენტაციასა და Windows‑ის თქვენს ვერსიასთან მიმართებით.

დააკონფიგურირეთ IIS W3C აღრიცხვა

IIS 7 და მომდევნო ვერსიები ნაგულისხმევად W3C‑ფორმატს იყენებს; აღსარიცხი ველები სერვერის ან საიტის დონეზე ირჩევა. #Fields ხაზი ამ ფაილში ველების მიმდევრობას აღრიცხავს. დიაგნოსტიკისთვის ხშირად სასარგებლოა თარიღი/დრო, კლიენტის IP, მეთოდი, URI‑ის ძირითადი ნაწილი, HTTP‑სტატუსი, ქვესტატუსი და time-taken. UriQuery, მომმართველი გვერდი, მომხმარებლის აგენტი და მორგებული ველები შეიძლება მგრძნობიარე მნიშვნელობებს შეიცავდეს, ამიტომ მხოლოდ საჭიროებისას ჩართეთ. IIS Manager‑ში საიტის Logging‑პარამეტრებში შეამოწმეთ ფორმატი, დირექტორია და ველები; ჩვეულებრივი ნაგულისხმევი დირექტორიაა %SystemDrive%\inetpub\logs\LogFiles.

შეადარეთ ვებსერვერის ჟურნალები

Apache‑ში, NGINX‑სა და IIS‑ში წვდომის ჟურნალების ფორმატები და ველების სახელები განსხვავდება, ამიტომ პარსერის კონფიგურაციამდე რეალური ნიმუშის ხაზები და სათაურები შეამოწმეთ. მეთოდი, URI, სტატუსი, პასუხის ზომა, მომხმარებლის აგენტი და დრო ტრაფიკის ნიმუშებისა და სერვერის შეცდომების ახსნას ეხმარება. მცოცავი რობოტების ანალიზისას მხოლოდ მომხმარებლის აგენტის ტექსტს ნუ ენდობით; მას კლიენტი აწვდის და მისი მიბაძვა შესაძლებელია. ჟურნალი აჩვენებს სერვერის მიერ ნანახ მოთხოვნებს და არა მომხმარებლის სრულ გზას ან განზრახვას.

მართეთ როტაცია და შენახვა

IIS‑ს შეუძლია ახალი ფაილის დაწყება დროის პერიოდით ან კონფიგურირებული ზომის ზღვრით; ეს თავისთავად შენახვის ვადას არ ადგენს. Windows Event Log‑ის მაქსიმალური ზომა და სავსე ჟურნალის ქცევა ცალკე კონფიგურირდება. Linux logrotate‑ს შეუძლია ფაილების როტაცია, არქივირება და შეკუმშვა დროით ან ზომით; შეამოწმეთ, აგრძელებს თუ არა აპლიკაცია სახელშეცვლილ ფაილში წერას. თითოეული გარემოსთვის განსაზღვრეთ საარქივო ასლები, წვდომის უფლებები, წაშლის დრო და დისკის გამოყენების გაფრთხილებები. ორგანიზაციის პასუხისმგებელმა სპეციალისტმა უნდა განსაზღვროს, შეესაბამება თუ არა შენახვის წესი მოქმედ სამართლებრივ ან დარგობრივ მოთხოვნებს.