Jak czytać logi z firewalli i systemów IDS, żeby naprawdę wykrywać ataki w sieci

Po co w ogóle czytać logi z firewalla i IDS, zamiast tylko je zbierać

Logi jako najtańszy „rejestr wsteczny” ataków

Firewall i system IDS/IPS działający na brzegu sieci widzi praktycznie wszystko, co próbuje się do niej dostać lub z niej wyjść. Logi z tych urządzeń są więc w praktyce najtańszym i najpełniejszym „rejestrem wstecznym” zdarzeń bezpieczeństwa. Gdy incydent jest już po fakcie, właśnie z logów można odtworzyć:

• skąd zaczęły się próby ataku (adresy IP, kraje, ASN),
• kiedy dokładnie nastąpiły pierwsze symptomy,
• jakie systemy były celem (konkretne IP/porty/serwisy),
• czy atak się udał, czy został zatrzymany na brzegu.

Bez logów lub przy ich szczątkowej konfiguracji analiza incydentu zamienia się w zgadywanie. Organizacja traci czas na domysły, zamiast podejmować decyzje na podstawie faktów. Co gorsza, bez porządnych logów trudno później weryfikować skuteczność wprowadzonych zmian – nie widać, czy podobne próby ataku ustąpiły, czy tylko chwilowo ucichły.

W praktyce logi są jedynym rozsądnym finansowo sposobem na retrospekcję zdarzeń w małych i średnich firmach. Pełne rozwiązania EDR/XDR, zaawansowane systemy SIEM i zewnętrzny monitoring SOC są często poza budżetem. Dobrze ustawione logowanie na firewallu i IDS jest rozwiązaniem „z półki ekonomicznej”, a daje realną możliwość dochodzenia, co się stało w nocy o 3:00, gdy wszyscy spali.

Różnica między logami „dla compliance” a logami operacyjnymi

W wielu firmach logi są „gdzieś tam” zbierane, bo wymagają tego normy (np. ISO, wymogi audytu) lub polityka bezpieczeństwa. To często logi „dla compliance”: zapisują się na jakimś serwerze syslog, nikt ich nie czyta, rotacja jest przypadkowa, a przy incydencie okazuje się, że brakuje kluczowych informacji. Formalnie logi są, operacyjnie – jakby ich nie było.

Logi operacyjne to zupełnie inne podejście. Są zbierane w taki sposób, aby:

• dało się je szybko przeszukać po kluczach (IP, port, nazwa hosta, ID sesji),
• mieć co najmniej kilka–kilkanaście dni historii pełnych danych,
• zawierały minimalny zestaw pól pozwalający odtworzyć przebieg zdarzeń,
• wykrywać anomalie bez konieczności analizy każdego wpisu ręcznie.

Różnica nie polega na tym, że w jednym przypadku jest „więcej logów”. Chodzi o ich jakość i używalność. Lepiej mieć mniej logów, ale dobrze przemyślanych (np. każdy drop/deny + najważniejsze allow), niż gigabajty śmieci bez kontekstu. Celem nie jest „logowanie wszystkiego”, tylko logowanie takiego zestawu informacji, który realnie pomaga podejmować decyzje przy incydentach.

Czego można oczekiwać od firewalla/IDS, a kiedy potrzebne są dodatki

Firewall i IDS/IPS nie są magicznymi urządzeniami, które „same powstrzymają atak”. Mają swoje ograniczenia:

• Firewall blokuje lub przepuszcza ruch zgodnie z regułami. Widzi głównie nagłówki pakietów, czasem podstawowe informacje z warstwy aplikacji (w firewallach nowej generacji).
• IDS/IPS bazuje na sygnaturach lub prostych heurystykach. Wykryje znane wzorce ataków, payloady exploitów, charakterystyczne próby brute force, ale zwykle nie zrozumie kontekstu biznesowego (czy dany ruch jest dla Twojej sieci normalny).

Bez dodatkowych narzędzi firewall i IDS mogą wygenerować masę pojedynczych alertów – często prawdziwych, ale niepriorytetowych. Żeby zacząć skuteczniej wykrywać realne ataki, przydają się co najmniej:

• prosty serwer logów (syslog, Graylog, Wazuh), aby korelować zdarzenia z wielu urządzeń,
• tanie dashboardy (np. mały stack ELK/Opensearch) do wizualizacji „top źródeł” i „top sygnatur”,
• procedura reagowania: kto patrzy na logi, jak często, co jest traktowane jako priorytet.

Na start nie potrzeba pełnego SIEM za ciężkie pieniądze. Nawet prosty syslog z kilkoma sensownymi widokami może radykalnie zwiększyć użyteczność logów z firewalla i IDS. Kluczowe jest zrozumienie: urządzenia generują dane, ale to człowiek (lub lekki SIEM) decyduje, które wzorce są faktycznie niebezpieczne.

Jakie pytania logi potrafią rozstrzygnąć w kilka minut

Dobrze przygotowane logi z firewalla i IDS potrafią bardzo szybko odpowiedzieć na krytyczne pytania techniczne i biznesowe, na przykład:

• „Co się działo o 3:00 w nocy?” – czy był nietypowy wzrost ruchu, skan portów, seria alertów IDS, nagły zanik połączeń VPN.
• „Czy ten serwer łączył się z tym adresem IP?” – szybkie przeszukanie logów firewallowych po src/dst IP i porcie.
• „Czy próbowano włamywać się na nasze VPN/SSH/RDP?” – analiza liczby nieudanych połączeń, prób logowania, blokad IDS.
• „Czy użytkownik X naprawdę pracował zdalnie o tej godzinie?” – korelacja logów VPN (logowanie użytkownika) z logami firewall/IDS (aktywność z jego IP).

Jeśli na takie pytania nie da się odpowiedzieć w kilka minut, system logów wymaga uporządkowania. Czas reakcji przy incydencie ma konkretne przełożenie na koszty: im szybciej ustalisz, co się stało, tym mniej godzin zespołu poświęcasz na chaotyczne dochodzenie i tym mniejsze straty operacyjne.

Jakie logi generuje firewall i IDS – szybki, praktyczny przegląd

Podstawowe kategorie logów firewalla

Większość firewalli, niezależnie od producenta, generuje kilka głównych kategorii logów. Znając je, łatwiej zdecydować, co logować w szczegółach, a co tylko minimalnie:

• Ruch (traffic) – decyzje typu accept/allow, deny/drop, często z nazwą reguły i interfejsem. To główne źródło informacji o tym, co faktycznie przechodzi (lub próbuje przejść) przez firewall.
• NAT – mapowania adresów prywatnych na publiczne (SNAT, DNAT). Bez logów NAT trudno później ustalić, który host w sieci wewnętrznej stał za danym adresem publicznym w chwili incydentu.
• VPN – logowanie połączeń zdalnych: kto się loguje, z jakiego IP, kiedy startuje i kończy sesja, czy wystąpiły błędy uwierzytelniania.
• System/konfiguracja – zmiany konfiguracji, restarty, błędy, aktualizacje, logowania do panelu administracyjnego. Przydatne do ustalenia, czy w krytycznym momencie nie trwają zmiany na firewallu.

Na start najważniejsza jest kategoria traffic i logowanie wszystkich deny/drop z sensownym poziomem szczegółowości. W dalszej kolejności – logi VPN i istotne zdarzenia systemowe. Logowanie każdego allow może być kosztowne, ale dla wybranych, krytycznych reguł (np. dostępy do serwerów produkcyjnych) warto włączyć pełne logowanie, nawet kosztem większej ilości danych.

Typy zdarzeń w IDS/IPS i poziomy powagi

Systemy IDS/IPS (np. Snort, Suricata, systemy wbudowane w firewalle NGFW) generują alerty o różnym poziomie ważności. W uproszczeniu można je podzielić na:

• alert – zdarzenie wymagające uwagi, potencjalny lub realny atak, np. próba wykorzystania znanej podatności lub brute force na usługę logowania,
• notice – coś podejrzanego lub nietypowego, ale niekoniecznie atak (np. nietypowy nagłówek HTTP),
• info – informacja o zdarzeniu, które może być przydatne do korelacji, ale samo w sobie nie jest zagrożeniem,
• error – błąd systemu IDS/IPS, problem z regułą, brak zasobów.

Dodatkowo większość systemów przypisuje sygnaturom poziom powagi (severity), np. od 1 do 5 (gdzie 1 to najniższa istotność, a 5 – krytyczne). Przykładowo:

• poziom 4–5 – próby exploitów, ataki na znane podatności, malware,
• poziom 3 – skany portów, bardziej agresywne rozpoznanie,
• poziom 1–2 – drobne anomalie, nietypowe flagi w TCP, rzadkie protokoły.

Do codziennej pracy przy ograniczonym czasie opłaca się skoncentrować na:

• sygnaturach o najwyższej powadze (severity wysoki),
• sygnaturach powiązanych z usługami wystawionymi na świat (WWW, VPN, SSH, RDP),
• nagle rosnącej liczbie alertów o niższej istotności z jednego źródła (oznaka rekonesansu lub próby obejścia detekcji).

Przykładowe wpisy z popularnych systemów i znaczenie pól

Przykładowy wpis logu z iptables (Linux):

[ 1234.567890] IPTABLES-FW: IN=eth0 OUT= MAC=xx:xx SRC=203.0.113.5 DST=192.168.1.10 LEN=60 TOS=0x00 PREC=0x00 TTL=51 ID=54321 DF PROTO=TCP SPT=44567 DPT=22 WINDOW=14600 RES=0x00 SYN URGP=0

Najważniejsze elementy:

• IN/OUT – interfejs wejściowy/wyjściowy,
• SRC/DST – adres źródłowy i docelowy,
• PROTO – protokół (TCP/UDP/ICMP),
• SPT/DPT – port źródłowy i docelowy,
• SYN – flagi TCP, tu pakiet inicjujący połączenie na SSH (port 22).

Przykładowy wpis z pfSense (oparty o pf):

Feb 10 12:34:56 firewall filterlog: 1,1676038496,,1000000103,em0,match,block,in,4,0x0,,64,12345,0,DF,6,tcp,60,203.0.113.5,192.168.1.10,44567,22,0,S,123456789,0,,mss;sackOK;TS;nop;wscale

Kluczowe pola:

• action – block/match (tu block),
• direction – in/out (ruch przychodzący),
• src/dst IP i port,
• interfejs – em0 (zwykle WAN).

Przykładowy alert z Snort/Suricata:

02/10-12:35:10.123456 [**] [1:2010935:3] ET SCAN Potential SSH Scan [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 203.0.113.5:44567 -> 192.168.1.10:22

Istotne elementy:

• nazwa sygnatury – „ET SCAN Potential SSH Scan”,
• Classification – opis kategorii zdarzenia,
• Priority – poziom ważności,
• kierunek i parametry ruchu – z/do, porty, protokół.

Każdy system inaczej formatuje logi, ale zawsze da się w nich odnaleźć te same fundamentalne informacje: kto do kogo, czym, kiedy i z jakim skutkiem się łączył.

Minimalny zestaw typów logów potrzebny do sensownej analizy

Aby analiza logów z firewalla i IDS miała realny sens, przy ograniczonym budżecie warto włączyć co najmniej:

• logi drop/deny – wszystkie nieudane próby połączeń z zewnątrz do sieci oraz z sieci na zewnątrz, jeśli dotyczą nietypowych portów lub krajów,
• logi allow dla krytycznych reguł – np. dostęp do serwerów produkcyjnych, VPN, serwerów zarządzających,
• logi IDS/IPS z poziomem powagi powyżej progu X – np. Priority ≥ 2,
• logi VPN – udane i nieudane logowania, rozłączenia, próby zablokowane,
• logi systemowe – błędy, restarty, zmiany konfiguracji.

Całkowite logowanie wszystkich „allow” w dużej sieci może być kosztowne dyskowo i obliczeniowo. Rozsądna strategia „na start” to podejście selektywne: pełne logi tam, gdzie incydent może być najbardziej kosztowny (serwery krytyczne, VPN), a na reszcie ograniczenie do blokad oraz ruchu nietypowego.

Podstawy czytania pojedynczego wpisu logu – znaczenie pól

Znaczenie dat i stref czasowych

Daty w logach wydają się banalne, dopóki nie trzeba skorelować zdarzeń z trzech różnych systemów i kalendarzem użytkownika. Tam, gdzie jest incydent, drobne rozjazdy o kilka minut potrafią kompletnie zamazać obraz.

Podstawowe problemy ze znacznikiem czasu:

• różne strefy czasowe – część urządzeń zapisuje UTC, część lokalny czas z DST,
• brak synchronizacji NTP – firewall „spóźnia się” o 5 minut, IDS „wyprzedza” o 2 minuty,
• różne formaty – syslog z nazwą miesiąca, urządzenie z timestampem UNIX, appliance z własnym formatem.

Najprostsza, tania strategia:

• ustawić wszędzie NTP z tym samym źródłem (np. serwer czasu w LAN),
• spiąć wszystkie logi na UTC i dopiero w narzędziu do przeglądania prezentować w lokalnej strefie,
• zrobić jedną krótką notatkę w procedurze IR: „Wszystkie czasy w raportach w UTC, jeśli inaczej – dopisek wprost”.

Bez wspólnego czasu korelacja „logi VPN + logi firewalla + logi IDS” zamienia się w zgadywanie. Przy incydencie minutę lub dwie jeszcze da się przeżyć, ale przy różnicach rzędu 15–30 minut ustalenie sekwencji zdarzeń staje się kosztownym śledztwem.

Adresy IP, porty i kierunek ruchu

Większość praktycznych wniosków z logów opiera się na trzech elementach: kto do kogo (adresy IP), po czym (protokoły i porty) i w którą stronę (kierunek).

Przy czytaniu pojedynczego wpisu dobrze od razu sobie odpowiedzieć na kilka pytań:

• czy źródło (SRC) jest „u mnie” czy „na zewnątrz” – host w LAN, VPN, DMZ, czy Internet,
• czy cel (DST) to coś krytycznego – serwer produkcyjny, panel administracyjny, kontroler domeny,
• czy port docelowy zgadza się z usługą (80/443 – WWW, 22 – SSH, 3389 – RDP itd.),
• czy kiedykolwiek powinno istnieć takie połączenie w normalnym scenariuszu biznesowym.

Jeśli format logu na to pozwala, przydatne są też uproszczone pola:

• direction – in/out (z internetu do nas, od nas do internetu),
• interface – WAN/LAN/VPN/DMZ,
• action – allow/accept vs deny/drop/reject.

Przykładowe szybkie wnioski:

• „SRC=publiczne_IP, DST=serwer_RDP, DPT=3389, action=deny” – ktoś strzela w RDP, firewall blokuje; warto sprawdzić skalę, ale pojedynczy wpis to jeszcze nie incydent,
• „SRC=host_w_LAN, DST=egzotyczny_publiczny_IP, DPT=4444, action=allow” – nietypowy outbound do dziwnego portu; w połączeniu z innymi logami może wskazywać malware.

Flagi TCP i liczba pakietów/połączeń

W wielu logach ruchu TCP pojawiają się flagi typu SYN, ACK, FIN, RST. Nie trzeba być sieciowcem, żeby wyciągnąć z nich podstawowe wnioski:

• SYN na DPT=X – ktoś próbuje otworzyć połączenie na dany port,
• dużo SYN bez dalszego ruchu – skanowanie lub próba SYN flood,
• RST – zrywanie połączenia; lawina RST może wskazywać na problemy lub próby „uciekania” przed detekcją.

Niektóre firewalle logują również liczbę bajtów lub pakietów (np. w podsumowaniu sesji). Przydaje się to do szybkich decyzji:

• 1–2 pakiety, mało bajtów – raczej próba połączenia niż sesja aplikacyjna,
• dziesiątki tysięcy bajtów – faktyczna wymiana danych (np. pobranie pliku, dłuższa sesja RDP).

Reguła, polityka i decyzja (allow/deny)

Każdy wpis z firewalla oprócz IP i portów powinien mieć informacje, która reguła zadziałała i jaką decyzję podjęto. To jest złoto przy analizie:

• jeśli w logu masz nazwę reguły (np. „VPN-remote-access-allow”), wiesz od razu kontekst biznesowy,
• jeśli masz tylko ID w stylu „1000000103”, musisz co chwilę zaglądać do konfiguracji – koszt czasowy rośnie.

Przy tworzeniu reguł opłaca się nadawać im sensowne nazwy z punktu widzenia analizy logów, np.:

• WAN_to_DMZ_HTTP_prod_web zamiast rule_17,
• VPN_users_to_AD_RDP zamiast rdp_allow.

Potem w logu od razu widzisz: „to dostęp z VPN użytkownika do kontrolera domeny, a nie jakiś przypadkowy outbound na 3389”. Różnica w czasie analizy jest ogromna.

Pola specyficzne dla IDS: sygnatura, kategoria, severity

W logach IDS każde zdarzenie ma zwykle kilka kluczowych atrybutów:

• SID / ID sygnatury – unikalny numer reguły (np. 1:2010935:3),
• nazwa sygnatury – krótki opis ataku lub zachowania,
• classification – rodzaj zdarzenia (np. Attempted Admin Privilege Gain),
• priority/severity – istotność alertu.

Do efektywnej pracy opłaca się mieć prosty, lokalny mapping: które klasyfikacje i poziomy severity traktujesz jako rzeczywiste „podejrzenie incydentu”, a które jako szum. Przykład minimalistyczny:

• severity 1–2 – loguj, ale nie wysyłaj powiadomień,
• severity 3 – grupuj w raportach dziennych/tygodniowych,
• severity 4–5 – powiadomienia natychmiast lub quasi-natychmiast (np. e-mail, Slack).

Zamiast reagować na każdą pojedynczą sygnaturę, łatwiej ogarnąć 10–15 „grup zagrożeń”, z których każda obejmuje kilka–kilkadziesiąt reguł. Do takiego modelu wystarczy prosty arkusz lub narzędzie do tagowania alertów w lekkim SIEM-ie.

Jak odróżnić normalny ruch od podejrzanego – myślenie w kategoriach wzorców

Co to znaczy „normalny ruch” w Twojej sieci

Nie istnieje uniwersalna definicja „normalnego ruchu”. Inny profil ma biuro z ERP-em w chmurze, inny firma deweloperska z mnóstwem zdalnych repozytoriów. Bez przybliżonego obrazu „normalności” większość logów wygląda jak losowy szum.

Minimum, które opłaca się zdefiniować na początku:

• typowy ruch wychodzący – np. HTTP/HTTPS do internetu, DNS do własnych resolverów, poczta do chmurowego dostawcy,
• typowy ruch przychodzący – np. HTTPS na publiczny serwer WWW, VPN z internetu, ewentualnie kilka portów do systemów B2B,
• krytyczne połączenia wewnętrzne – hosty, które normalnie łączą się z bazami, AD, serwerami aplikacyjnymi.

Na starcie wystarczy prosty diagram lub tabela, bez żadnych zaawansowanych narzędzi. Taki „szkic normalności” robi różnicę przy interpretowaniu logów: od razu widać, że np. stacja księgowej nie powinna robić ruchu SMTP bezpośrednio do internetu, bo poczta idzie przez serwery firmowe.

Wzorce połączeń zamiast pojedynczych wpisów

Logów nie czyta się efektywnie po jednym wierszu. Realne informacje kryją się w wzorcu – powtarzalności adresów, portów, decyzji firewalla i alertów IDS.

Przy analizie dobrze szukać prostych schematów:

• dużo podobnych wpisów z jednego IP źródłowego – potencjalne skanowanie lub brute force,
• nagły wysyp ruchu na port, który zwykle jest spokojny – np. skok ruchu na 3389 lub 389 z internetu,
• nagle pojawiające się nowe kraje / AS – jeśli ruch do tej pory był głównie z regionu, a nagle pojawia się egzotyczny hosting.

Nawet zwykłe narzędzie do filtrowania logów (grep, zgrep, prosty front syslogowy) pozwala zobaczyć takie wzorce, jeśli zadasz dobre pytanie typu:

• „pokaż wszystkie próby dostępu do mojego VPN w ostatnich 24h, posortowane po IP źródłowym”,
• „pokaż wszystkie allow na RDP z zewnętrznych adresów w ciągu tygodnia”.

Prosta „checklista zdrowego rozsądku” dla podejrzanego ruchu

Zamiast wymyślać skomplikowane modele, można zastosować prostą listę kontrolną. Dany wpis / grupa wpisów jest podejrzana, jeśli spełnia co najmniej jeden warunek:

• trafienie w port lub usługę administracyjną (SSH, RDP, panel WWW, bazy) z internetu lub z nietypowego segmentu,
• ruch z/do egzotycznych lokalizacji (hosting, kraje, z którymi realnie nie robicie biznesu),
• nietypowe godziny – duża aktywność VPN lub RDP w środku nocy, jeśli firma nie pracuje zmianowo,
• ruch wychodzący z hostów, które zwykle nie gadają z internetem (np. kontroler domeny, serwery baz danych),
• protokół lub port nieużywany w normalnej działalności (np. Telnet, SMB przez internet, tunelowanie DNS),
• nagły skok liczby alertów IDS powiązanych z tym samym IP lub hostem.

Taka lista nie wymaga drogich narzędzi. Wystarczy, że w prostym systemie logów możesz policzyć liczbę wpisów spełniających dane kryterium i posortować po IP, porcie lub czasie.

Jak szybko wykluczać „szum sieciowy”

W logach znajdzie się masa ruchu, który jest niechciany, ale nie stanowi realnego problemu – losowe skany portów, boty sprawdzające WWW, nieudane próby połączeń na domyślne porty. Jeśli masz reagować na każdy skan, zespół spali się w dwa tygodnie.

Praktyczne kryteria, by coś zakwalifikować jako „szum”:

• pojedyncze próby na losowe porty z wielu IP – typowy background noise internetu,
• skany, które blokuje edge firewall, a za nim nie ma wrażliwych usług,
• stare sygnatury IDS o niskiej powadze, które pojawiają się masowo i nie przekładają się na udane exploity.

Takie wzorce najlepiej „odszumić” regułami w narzędziu do zbierania logów: oznaczyć jako low priority, przenieść do osobnego widoku lub agregować do jednego zapisu „1000 podobnych zdarzeń”. Klucz, żeby nie kasować ich całkowicie – raz na jakiś czas warto sprawdzić, czy za starym „szumem” nie kryje się nowe zachowanie.

Praktyka: typowe ślady ataków w logach firewalla i IDS

Skanowanie portów i rozpoznanie (recon)

Skanowanie portów to klasyka – zanim ktoś spróbuje wykorzystać podatność, musi wiedzieć, co słucha i gdzie. W logach firewalla wygląda to zwykle jako:

• krótki okres (sekundy/minuty), w którym jedno źródło (lub kilka z tej samej podsieci/AS) próbuje wielu portów na Twoim zewnętrznym IP,
• duża liczba deny/drop na kolejnych portach, często w rosnącej lub malejącej sekwencji,
• czasem przejście z pełnego skanu na szczegółowe próby pod znanymi portami (22, 80, 443, 3389 itp.).

IDS doda do tego alerty typu „Potential Scan”, „TCP Portscan”, „SSH Scan”. Najprostszy sposób, by to złapać:

• filtrowanie logów po src IP i zliczanie liczby unikalnych DPT w krótkim oknie czasowym,
• ustawienie w IDS alertów na „więcej niż X różnych portów z jednego IP w Y sekund”.

Reakcja zależy od zasobów. W mniejszych zespołach zwykle wystarczy:

• blokada źródłowego IP / podsieci, jeśli atak jest uporczywy,

Brute force i próby logowania do usług zdalnych

Po skanowaniu często przychodzą próby odgadnięcia haseł. W logach firewalla widać wtedy:

• wiele połączeń z jednego lub kilku adresów źródłowych na jeden port (RDP 3389, SSH 22, VPN),
• często stała częstotliwość – np. kilka–kilkanaście prób na minutę, przez dłuższy czas,
• sekwencje allow na poziomie firewalla, a dopiero w logach systemu docelowego (AD, Linux, VPN gateway) – nieudane logowania.

IDS dorzuci sygnatury typu „SSH Brute Force”, „Multiple Login Failures”, „Suspicious RDP Activity”. Dla mniejszego zespołu opłaca się patrzeć na brute force przede wszystkim przez pryzmat skutku:

• jeśli nie ma ani jednego udanego logowania z podejrzanego IP lub kraju – wystarczy blokada IP/podsieci i ewentualnie automatyczne dodawanie do listy odrzucanych,
• jeśli pojawiają się udane logowania po serii nieudanych prób – to już podejrzenie przejęcia konta, temat dla kogoś z uprawnieniami do AD lub VPN.

Najprostszy, tani mechanizm to sklejka: logi firewalla + logi uwierzytelniania. Nawet bez SIEM-a można:

• wyeksportować z VPN/AD listę nieudanych logowań z ostatnich 24h,
• zgrupować po IP i użytkowniku (prosty skrypt lub arkusz kalkulacyjny),
• zestawić to z logami firewalla – czy ruch szedł z tego samego kraju/AS, co wcześniejsze skany.

Nawet tak „analogowe” podejście pozwala wyłapać realne przypadki, przy minimalnym nakładzie pracy i bez wchodzenia w duże platformy.

Eksploatacja podatności i próby RCE

Gdy ktoś znajdzie podatną usługę, kolejne wpisy logów zaczynają wyglądać inaczej. Zamiast losowych portów pojawia się skupienie na jednym hoście i porcie (np. zewnętrzne HTTPS do serwera WWW) i specyficzne ścieżki URL lub nagłówki.

W logach IDS często widać:

• sygnatury związane z konkretnym frameworkiem lub aplikacją (WordPress, Drupal, Exchange, Log4j),
• „Attempted Administrator Privilege Gain”, „Web Application Attack”,
• nagłe pojawienie się kilku różnych sygnatur z tej samej kategorii dla jednego IP i hosta docelowego.

Firewall widzi tu zwykle tylko „allow” na HTTP/HTTPS. Cała treść kryje się w IDS i logach serwera WWW. Przy ograniczonych zasobach sensowne jest skupienie się na:

• zdarzeniach z kategorii web-attack / rce / code-execution przeciwko usługom biznesowo krytycznym (np. panel klienta, system pocztowy),
• wzorcach typu: jedno IP próbuje wiele różnych URL-i i payloadów w krótkim czasie (różne exploity na tego samego hosta),
• powiązaniu: po udanym ataku często następuje nietypowy ruch wychodzący z zaatakowanego hosta.

Minimalistyczne podejście „efekt vs wysiłek”:

• filtrowanie alertów IDS po kategoriach „web-attack” i severity >= 3 dla serwerów z listy krytycznych,
• dla każdego takiego alertu – szybkie sprawdzenie, czy z tego hosta nie pojawił się zaraz potem nowy, stały ruch wychodzący (np. na porty 4444, 8080, egzotyczne kraje),
• jeśli tak – ręczna analiza hosta (logi aplikacji, AV/EDR, snapshot maszyny wirtualnej).

Ruch C2 i komunikacja po przejęciu hosta

Zaawansowane malware po udanym wejściu musi „porozmawiać” z infrastrukturą atakującego. W czystych logach firewalla trudno to odróżnić od normalnego HTTPS, ale są pewne sygnały:

• pojedynczy host w sieci zaczyna łączyć się okresowo do niewielu zewnętrznych IP, często w hostingach typu VPS,
• używa niestandardowych portów (np. 8080, 8443, 9001) lub protokołów, które wcześniej nie były widziane z tego hosta,
• ruch wychodzący o stałych porach lub z równą częstotliwością – „beaconing”.

IDS może pokazać sygnatury typu „Possible CnC Activity”, „Suspicious TLS”, ale w tańszych rozwiązaniach ich jakość bywa różna. Dla małego zespołu bardziej opłacalne jest użycie prostych heurystyk na logach firewalla:

• znalezienie hostów, które mają stały ruch do jednego IP w internecie, niebędącego popularną usługą (nie Google, nie Microsoft, nie CDN),
• wylistowanie nietypowych portów TCP/UDP w ruchu wychodzącym i zobaczenie, z których hostów wychodzą,
• oznaczanie jako „podejrzane” ruchu z serwerów, które nie powinny w ogóle inicjować połączeń na zewnątrz (AD, bazy, drukarki).

Narzędziowo wystarczy eksport logów do CSV i kilka filtrów. Jeden z prostych trików: osobna tabela „egzotyczne dest IP” – adresy, do których łączy się tylko jeden host w całej organizacji. Taki zbiór jest zwykle mały i da się go przejrzeć ręcznie w rozsądnym czasie.

Lateral movement i nietypowy ruch wewnętrzny

Gdy atakujący wejdzie do sieci, zaczyna się rozglądać – skanuje wewnętrzne zakresy, próbuje RDP/SMB do serwerów, czasem odpala mini-skanery wbudowane w malware. Jeśli masz logujący ruch między segmentami, widać to całkiem wyraźnie.

Charakterystyczne sygnały w logach firewalla między VLAN-ami / strefami:

• host z jednej stacji roboczej zaczyna odpytywać wiele adresów w innym segmencie na szeregu portów (135, 139, 445, 3389, 5985 itp.),
• próby dostępu z segmentu użytkowników do serwerów, do których normalnie brak potrzeby dostępu (np. serwery baz, kontrolery domeny),
• nagłe pojawienie się RDP/SMB z nietypowego segmentu (np. z sieci gościnnej do serwerów produkcyjnych).

IDS dodaje do tego alerty typu „SMB Brute Force”, „Pass-the-Hash”, „Lateral Movement Detected”, choć te bardziej zaawansowane pojawiają się raczej w droższych produktach. Tańszy, ale skuteczny wariant:

• na poziomie firewalla – logowanie deny dla ruchu między segmentami na porty administracyjne i serwerowe,
• proste reguły: „pokaż wszystkie próby łączenia się z kontrolerami domeny z segmentów innych niż X/Y”,
• zliczanie prób RDP i SMB z pojedynczych stacji do wielu serwerów – to nie jest typowy wzorzec pracy zwykłego użytkownika.

Nietypowe transfery danych i możliwe exfiltracje

Z perspektywy logów firewalla exfiltracja wygląda często jak normalny ruch „w internet”. Kluczowe są jednak wolumen i kontekst. Przy ograniczonych zasobach nie ma sensu wdrażać ciężkiego DLP, ale można wyciągnąć parę prostych sygnałów:

• hosty, które w krótkim czasie wysyłają znacznie więcej danych niż zwykle (np. nagły skok kilkukrotny),
• duże transfery do nieznanych dotychczas dest IP lub krajów,
• tunelowanie – np. nietypowo duży wolumen DNS z jednego hosta albo spore ilości HTTP POST do mało znanego serwera.

Jeśli firewall wspiera podstawowe statystyki wolumenu per IP, można raz dziennie wyciągać listę „top talkerów” i sprawdzać ją pod kątem niespodzianek. W małych środowiskach taka lista bywa krótsza, niż się wydaje – kilka serwerów i pojedyncze stacje typu „power user”. Każde nowe IP w topce zasługuje na krótkie spojrzenie: co to jest i z kim rozmawia.

Łączenie logów firewalla i IDS w prosty „łańcuch zdarzeń”

Realny atak to rzadko pojedynczy wpis. Bardziej przypomina historyjkę z kilku kroków. Nawet bez SIEM-a da się ją ułożyć ręcznie, jeśli zastosujesz prosty schemat:

1. wejście – skany z zewnątrz, próby logowania, web-attack na serwer zewnętrzny,
2. utrwalenie – udane logowanie, podejrzany ruch z jednego hosta, zmiana wzorca ruchu,
3. rozpoznanie wewnętrzne – skany między segmentami, próby SMB/RDP,
4. exfiltracja / C2 – stały ruch wychodzący do egzotycznych IP, duże transfery.

Przy analizie konkretnego hosta albo incydentu opłaca się dosłownie rozpisać sobie na kartce: „co firewall widzi przed atakiem, w trakcie, po?”. Taki „timeline z biedronki” porządkuje głowę i pomaga zdecydować, czy mamy tylko głośny, ale nieskuteczny skan, czy realne wejście do środka.

Praca z masą logów: jak nie utonąć w danych przy małym zespole

Ustalanie priorytetów: które logi są naprawdę krytyczne

Przy ograniczonym czasie trzeba zaakceptować, że nie przejrzysz wszystkiego. Zamiast próbować czytać cały strumień, lepiej podzielić logi na trzy koszyki:

• krytyczne – logi z firewalla i IDS dotyczące:
  • serwerów z danymi wrażliwymi,
  • dostępów z internetu (VPN, portale),
  • ruchu między segmentami wewnętrznymi.
• ważne, ale niepilne – reszta ruchu wychodzącego użytkowników do internetu (HTTP/HTTPS, DNS),
• szum / tło – losowe skany z internetu, masowe stare sygnatury IDS o niskiej wadze.

Priorytety warto odzwierciedlić w samej konfiguracji zbierania logów: osobne strumienie, osobne indeksy lub osobne pliki. Wtedy da się np. codziennie przejrzeć tylko „krytyczne” i tygodniowo „ważne”. „Szum” wystarczy raz na jakiś czas zagregować statystycznie.

Minimalne „dashboardy” zamiast zaawansowanego SIEM-a

Nie każde środowisko ma budżet na pełny SIEM. Do sensownego monitoringu firewalla i IDS spokojnie wystarczą:

• syslog + prosty stack (np. Elasticsearch/Opensearch + Kibana, Graylog, Loki + Grafana), albo
• lekki, darmowy/lub tani produkt z gotowym widokiem typu „top alerts”, „top talkers”.

Najważniejsze to stworzyć kilka praktycznych widoków, a nie kilkanaście ładnych, na które nikt nie patrzy. Przykładowe „dashboardy na start”:

• VPN i zdalny dostęp – próby logowania, nieudane vs udane, top IP, kraje pochodzenia,
• Ruch do serwerów krytycznych – źródła, porty, ilość deny/allow, trend dzienny,
• Alerty IDS severity 4–5 – posortowane po liczbie wystąpień i hostach docelowych,
• Nietypowy ruch wychodzący – top dest IP, nietypowe porty, hosty-„outliery”.

Jeśli dashboard nie pomaga podjąć decyzji „ignoruję / patrzę głębiej / eskaluję”, to zwyczajnie jest zbędny. Dobrze zaprojektowany, prosty widok pozwala w 5–10 minut wyłapać rzeczy, które wymagają reakcji.

Prosty harmonogram przeglądu logów

Zamiast „kiedykolwiek się uda”, lepiej mieć krótki, realistyczny plan. Przykładowo przy dwuosobowym zespole:

• codziennie (15–20 minut):
  • przegląd alertów IDS severity 4–5,
  • sprawdzenie logów z VPN i dostępu zdalnego,
  • szybki rzut oka na „top talkers” ruchu wychodzącego.
• raz w tygodniu (30–60 minut):
  • analiza trendów: liczba alertów IDS per kategoria,
  • przegląd nowych dest IP i AS w ruchu z serwerów krytycznych,
  • czyszczenie / doprecyzowanie filtrów „szumu”.
• raz w miesiącu:
  • weryfikacja, czy reguły firewalla i profile IDS odpowiadają aktualnej infrastrukturze (nowe systemy, wycofane usługi),
  • krótkie ćwiczenie: prześledzenie losowo wybranego „incydentu” od początku do końca (trening czytania logów).

Taki kalendarz można dopasować do własnych realiów, ale klucz to konsekwencja i ograniczanie zakresu do tego, co naprawdę da się zrobić.

Automatyczne „podświetlanie” ważnych wzorców

Najczęściej zadawane pytania (FAQ)

Po co czytać logi z firewalla i IDS, skoro i tak wszystko się loguje?

Samo „gdzieś tam” zbieranie logów najczęściej kończy się tym, że przy incydencie brakuje kluczowych informacji albo nikt nie potrafi ich szybko znaleźć. Czytanie i sensowne porządkowanie logów pozwala w kilka minut odpowiedzieć na pytania: skąd szedł atak, kiedy się zaczął, jaki serwer był celem i czy atak się udał, czy zatrzymał się na brzegu.

Dla mniejszych firm logi z firewalla i IDS są de facto najtańszym „rejestrem wstecznym” zdarzeń bezpieczeństwa. Zamiast inwestować od razu w drogi SIEM czy zewnętrzny SOC, można rozsądnie skonfigurować logowanie i mieć realną możliwość odtworzenia tego, co się działo np. o 3:00 w nocy, bez kosztownego dochodzenia „na ślepo”.

Jakie logi z firewalla są naprawdę ważne do wykrywania ataków?

Na start kluczowa jest kategoria traffic, czyli decyzje allow/accept i deny/drop wraz z adresem źródłowym, docelowym, portem i nazwą reguły. Absolutnym minimum jest pełne logowanie wszystkich deny/drop, bo to właśnie tam widać większość prób skanów i wstępnego rozpoznania. Dla krytycznych reguł (np. dostęp do serwerów produkcyjnych) warto dodatkowo logować także ruch allow.

W drugiej kolejności dochodzą logi NAT (żeby móc odtworzyć, który host stał za danym adresem publicznym), VPN (z kim, skąd i kiedy zestawiono sesję) oraz ważne zdarzenia systemowe: zmiany konfiguracji, logowania administratorów, restarty. Resztę można na początku ograniczyć, żeby nie produkować gigabajtów mało przydatnych wpisów.

Czym się różnią logi „dla compliance” od logów operacyjnych?

Logi „dla compliance” często są zbierane tylko po to, żeby zaliczyć audyt: lądują na jakimś serwerze syslog, nikt ich nie przeszukuje, rotacja jest przypadkowa, a przy incydencie okazuje się, że brakuje np. źródłowych IP albo nazw reguł. Formalnie logi są, ale praktycznie niewiele da się z nich wyczytać.

Logi operacyjne są zaprojektowane pod użycie w boju. Da się je szybko filtrować po IP/porcie/hoście, mają co najmniej kilka–kilkanaście dni pełnej historii i zawierają minimalny zestaw pól potrzebny do odtworzenia zdarzenia. Lepiej mieć mniejszą, ale sensownie zaprojektowaną paczkę logów niż „wszystko”, w czym nie da się nic znaleźć bez godzin żmudnego klikania.

Jakie narzędzia do logów z firewalla i IDS wystarczą na start w małej firmie?

W większości małych i średnich firm wystarczy prosty serwer logów (syslog, Graylog, Wazuh) i kilka podstawowych dashboardów. To pozwala skorelować zdarzenia z wielu urządzeń i szybko sprawdzić np. „top źródła ruchu odrzuconego” albo „top sygnatur IDS w ostatnich 24h”.

Nie trzeba od razu kupować pełnego SIEM. Tani lub darmowy stack typu ELK/Opensearch na jednym serwerze + rozsądna konfiguracja logowania na firewallu/IDS dają ogromny skok jakości w porównaniu z sytuacją, w której logi „gdzieś są”, ale nikt ich nie widzi ani nie ma prostych widoków do analizy.

Jak rozpoznać w logach, czy atak się powiódł, czy został zablokowany?

W logach z firewalla pierwszą wskazówką jest akcja na ruchu: deny/drop zwykle oznacza, że próbę zablokowano, a allow/accept – że ruch przeszedł. Trzeba to jednak zestawić z kierunkiem ruchu (wejście/wyjście), portem i adresem docelowym. Jeśli widać serię pozwolonych połączeń do wrażliwej usługi (np. RDP) z jednego, dotąd nieznanego IP, to sygnał ostrzegawczy.

Z kolei w logach IDS/IPS warto patrzeć na sygnatury o wysokiej powadze (severity 4–5: exploit, malware) oraz to, czy występują seriami wobec tego samego hosta. Jeśli równolegle w logach firewalla widać allow na ten ruch, trzeba założyć, że atak mógł przejść dalej i zweryfikować logi z serwera docelowego lub EDR, jeśli jest.

Jak szybko sprawdzić w logach, co się działo o konkretnej godzinie (np. 3:00 w nocy)?

Najprostszy sposób to filtrowanie logów po przedziale czasowym i kilku podstawowych polach. Na dashboardzie lub w narzędziu do przeszukiwania ustawiasz okno np. 02:50–03:10 i patrzysz na:

• nagłe skoki liczby odrzuconych połączeń (deny/drop) z jednego lub kilku IP,
• nowe lub rzadko widziane adresy źródłowe, zwłaszcza spoza typowych krajów dla Twojej działalności,
• serię alertów IDS, szczególnie o wyższym severity, skierowaną w te same hosty/porty,
• logi VPN: kto się logował, czy były nieudane próby logowania lub zrywanie sesji.

Jeśli podstawowe pytania („kto, skąd, dokąd, ile razy”) zajmują więcej niż kilka minut, to znak, że trzeba poprawić zarówno sposób logowania, jak i widoki w narzędziu do analizy – inaczej każda nocna awaria zamieni się w wielogodzinne dochodzenie.

Na które alerty IDS/IPS zwracać uwagę, gdy nie ma czasu na analizę wszystkiego?

Przy ograniczonych zasobach najlepiej skupić się na trzech grupach: sygnaturach o najwyższej powadze (severity 4–5), alertach dotyczących usług wystawionych na świat (WWW, VPN, SSH, RDP) oraz nagłym skokach liczby „drobniejszych” alertów z jednego źródła (oznaka agresywnego skanowania lub automatu testującego wiele podatności po kolei).

Dobry kompromis to przygotowanie krótkiej listy „alertów pierwszego poziomu” – kilku–kilkunastu sygnatur, które zawsze wymagają spojrzenia człowieka, oraz prostej procedury: kto na nie patrzy, jak często, jaka jest minimalna reakcja (np. czasowy blok IP, sprawdzenie logów serwera). Dzięki temu nie trzeba siedzieć cały dzień w IDS, a jednocześnie realne ataki nie przelatują bokiem.

Co warto zapamiętać

• Logi z firewalla i IDS to najtańszy i najbardziej kompletny „rejestr wsteczny” ataków – bez nich analiza incydentu zamienia się w zgadywanie, a nie w oparcie decyzji na faktach.
• Różnica między logami „dla compliance” a logami operacyjnymi polega na używalności: logi muszą dać się szybko przeszukać, mieć sensowny okres retencji i zawierać minimalny zestaw pól potrzebnych do odtworzenia zdarzeń.
• Lepiej logować mniej, ale mądrze (kluczowe decyzje allow/deny, NAT, VPN), niż generować gigabajty szumu bez kontekstu, których nikt nie jest w stanie realnie analizować.
• Firewall i IDS nie „same bronią sieci” – generują masę pojedynczych alertów; dopiero człowiek lub lekki system korelacji nadaje im priorytety i wyciąga z nich realny obraz ataku.
• Prosty serwer logów (syslog, Graylog, Wazuh) z podstawowymi dashboardami (np. mały ELK/Opensearch) daje ogromny skok jakości za ułamek kosztu pełnego SIEM czy SOC.
• Dobrze ustawione logi pozwalają w kilka minut odpowiedzieć na kluczowe pytania typu: „co się działo o 3:00?”, „czy ten serwer łączył się z tym IP?”, „czy były próby włamania na VPN/SSH/RDP?”, co przekłada się bezpośrednio na mniejsze koszty incydentów.
• Minimalny „proces nad logami” jest obowiązkowy: ktoś musi regularnie patrzeć w dashboardy, wiedzieć, co jest priorytetem i mieć prostą procedurę reakcji, inaczej nawet najlepsze logi będą tylko tanią przechowalnią danych.