Cyber Security Academy · Lekcja

Źródła logów: systemowe, sieciowe i aplikacyjne

Poznają Państwo zawartość dzienników zdarzeń Windows, syslog, logów Apache/Nginx i logów zapory sieciowej.

Źródła logów: systemowe, sieciowe i aplikacyjne to bezpłatna lekcja Cyber Security Academy na CoddyKit. To lekcja 1 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej Cyber Security Academy, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs Cyber Security Academy zawiera 4 lekcji w sumie.

Dlaczego logi mają znaczenie

Logi są podstawowym źródłem dowodów podczas dochodzeń dotyczących bezpieczeństwa. Każde logowanie, połączenie sieciowe i działanie aplikacji pozostawia ślad. Bez logów ataki pozostają niewidoczne, a odtworzenie przebiegu zdarzeń metodami kryminalistycznymi jest niemożliwe.

Dzienniki zdarzeń systemu Windows

System Windows organizuje logi w kanały: Security, System, Application oraz niestandardowe kanały aplikacji. Dziennik Security zawiera zdarzenia uwierzytelniania, kontroli dostępu i audytu — jest najważniejszy dla analizy bezpieczeństwa.

# View Windows Event Logs
# Event Viewer (GUI): eventvwr.msc

# PowerShell
Get-EventLog -LogName Security -Newest 50
Get-WinEvent -LogName Security | Where-Object {$_.Id -eq 4625}

# Key Security Event IDs:
# 4624: Logon success
# 4625: Logon failure
# 4648: Explicit credentials
# 4672: Admin logon

Syslog i dziennik systemd w systemie Linux

Linux zapisuje logi w /var/log/ za pośrednictwem syslog (rsyslog/syslog-ng) oraz journald systemd. Najważniejsze pliki to: auth.log (uwierzytelnianie), syslog (informacje ogólne), kern.log (jądro) oraz logi właściwe dla poszczególnych aplikacji.

# View auth log
tail -f /var/log/auth.log

# Search for failed SSH logins
grep "Failed password" /var/log/auth.log

# Systemd journal
journalctl -u sshd -f
journalctl --since "1 hour ago"
journalctl -p err -b

Logi dostępu serwera WWW

Logi dostępu Apache/Nginx rejestrują każde żądanie HTTP: adres IP klienta, znacznik czasu, metodę, adres URL, kod stanu i user agent. Są niezwykle cenne przy wykrywaniu skanowania, prób wykorzystania luk oraz eksfiltracji danych.

# Apache format:
# IP - - [timestamp] "METHOD /path HTTP/1.1" status bytes "referer" "UA"
192.168.1.50 - - [01/Jan/2025:10:23:45 +0000] "GET /admin HTTP/1.1" 403 287

# Find 4xx errors (potential scanning)
grep " 40[0-9] " /var/log/apache2/access.log | awk '{print $1}' | sort | uniq -c | sort -rn

Logi zapory sieciowej i urządzeń sieciowych

Logi zapory rejestrują decyzje o zezwoleniu na ruch sieciowy lub jego zablokowaniu: źródłowy i docelowy adres IP, port, protokół oraz działanie. Są niezbędne do śledzenia ruchu bocznego i prób eksfiltracji danych.

# iptables logging rule
iptables -A INPUT -j LOG --log-prefix "IPTABLES-DENY: "

# View firewall logs
grep "IPTABLES-DENY" /var/log/syslog

# Palo Alto/Cisco ASA logs go to syslog
# Format: date, action, src, dst, port, bytes

Logi DNS

Zapytania DNS ujawniają, z jakimi hostami komunikują się urządzenia. Złośliwe oprogramowanie używa DNS do komunikacji C2 (sygnalizowania i tunelowania DNS) oraz eksfiltracji danych. Należy rejestrować wszystkie zapytania DNS, nie tylko te zakończone niepowodzeniem.

# Enable query logging in BIND
# named.conf:
logging {
    channel query_log {
        file "/var/log/named/queries.log";
        severity info;
        print-time yes;
    };
    category queries { query_log; };
};

# Detect tunneling: long subdomains
awk '{print length($0), $0}' queries.log | sort -rn | head -20

Logi DHCP

Logi DHCP odwzorowują adresy IP na adresy MAC i nazwy hostów w określonym momencie — są niezbędne do ustalenia, które fizyczne urządzenie posiadało dany adres IP podczas incydentu.

# DHCP log location (Linux):
/var/log/dhcpd.log
/var/lib/dhcpd/dhcpd.leases

# Windows DHCP Server:
# C:\Windows\System32\dhcp\DhcpSrvLog-*.log

# Correlate: IP address → MAC → hostname → user

Logi aplikacji i baz danych

Logi aplikacji ujawniają ataki na logikę biznesową: próby wstrzyknięcia SQL w logach zapytań do bazy danych, próby obejścia uwierzytelniania w logach aplikacji oraz eskalację uprawnień w tabelach audytowych. W środowiskach testowych zawsze należy włączać rejestrowanie zapytań do DB.

# MySQL query log
# my.cnf:
general_log = 1
general_log_file = /var/log/mysql/query.log

# PostgreSQL
# postgresql.conf:
log_statement = 'all'
log_min_duration_statement = 0

# View slow queries
grep "Query" /var/log/mysql/query.log | grep -v "SELECT 1"

Logi VPN i uwierzytelniania

Logi VPN pokazują, którzy użytkownicy, skąd i kiedy się łączyli. Anomalie, takie jak impossible travel (logowanie z Nowego Jorku i Londynu w ciągu godziny), dostęp poza godzinami pracy oraz nowe kraje, wskazują na przejęte dane uwierzytelniające.

Retencja i integralność logów

Logi należy przechowywać wystarczająco długo, aby umożliwić prowadzenie dochodzeń (co najmniej 90 dni, a w przypadku wymogów zgodności — 1 rok). Należy natychmiast przesyłać logi do scentralizowanego systemu odpornego na manipulacje — napastnicy mogą usuwać logi lokalne.

Normalizacja i analiza składniowa

Logi występują w dziesiątkach formatów. Normalizacja przekształca je do wspólnego schematu (adres IP, znacznik czasu, typ zdarzenia, użytkownik), umożliwiając korelację danych z różnych źródeł w systemie SIEM.

Szybkie sprawdzenie

Jaki identyfikator zdarzenia systemu Windows wskazuje na nieudaną próbę logowania?

Podsumowanie: źródła logów

Skuteczne monitorowanie bezpieczeństwa wymaga logów z każdej warstwy: zdarzeń uwierzytelniania systemu operacyjnego, zapory sieciowej i DNS, dostępu do serwera WWW, aplikacji i bazy danych oraz VPN. Należy natychmiast przesyłać logi centralnie — napastnicy usuwają logi lokalne. Formaty należy normalizować, aby umożliwić korelację danych z różnych źródeł, a logi przechowywać przez co najmniej 90 dni na potrzeby dochodzeń.

Często zadawane pytania

Czy lekcja „Źródła logów: systemowe, sieciowe i aplikacyjne” jest bezpłatna?

Tak — pełny tekst „Źródła logów: systemowe, sieciowe i aplikacyjne” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu Cyber Security Academy, przejdź na CoddyKit PRO. Kurs Cyber Security Academy zawiera 4 lekcji w sumie.

Co nauczysz się w „Źródła logów: systemowe, sieciowe i aplikacyjne”?

Poznają Państwo zawartość dzienników zdarzeń Windows, syslog, logów Apache/Nginx i logów zapory sieciowej. Ćwiczysz Cyber Security Academy z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.

Czy potrzebuję doświadczenia, aby zacząć Cyber Security Academy?

Nie wymagamy żadnego doświadczenia. Cyber Security Academy w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 1 z 4.

Ile czasu zajmuje lekcja „Źródła logów: systemowe, sieciowe i aplikacyjne”?

Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.

Czy mogę pisać i uruchamiać kod w tej lekcji Cyber Security Academy?

Tak. Każda lekcja Cyber Security Academy zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.

Wszystkie lekcje w tym kursie

Źródła logów: systemowe, sieciowe i aplikacyjne
Architektura SIEM i pobieranie logów
Pisanie reguł detekcji i korelacja
Triaging alertów i przebieg pracy SOC

← Powrót do Cyber Security Academy