Jak wykrywać i blokować nietypowy ruch w sieci z użyciem darmowego IDS na Raspberry Pi

Cel: prosty „radar” bezpieczeństwa w sieci domowej lub biurowej

Domowe i małe firmowe sieci coraz częściej przypominają mini–data center: router operatora, kilka laptopów, NAS, kamery IP, drukarki, smart TV, urządzenia IoT. Każde z nich jest potencjalnym wektorem ataku, a jednocześnie mało kto patrzy, jaki ruch faktycznie przechodzi przez sieć.

Raspberry Pi z darmowym IDS potrafi zamienić tę „czarną skrzynkę” w przejrzysty obraz: kto z kim rozmawia, jakie protokoły są używane, czy w sieci nie działa malware lub botnet. Do tego przy odrobinie konfiguracji można nie tylko wykrywać nietypowy ruch w sieci, ale też go blokować – automatycznie reagując na zagrożenia.

Cały sens takiego projektu sprowadza się do dwóch rzeczy: świadomości (widzisz, co dzieje się w sieci) oraz kontroli (potrafisz odciąć lub ograniczyć niechciany ruch bez wydawania fortuny na sprzęt klasy enterprise).

Po co w ogóle IDS w małej sieci i co realnie daje

Antywirus, firewall, IDS/IPS – kto za co odpowiada

Bezpieczeństwo sieci to nie jeden program, tylko warstwowy zestaw narzędzi. Każde ma inne zadanie i dopiero razem zaczynają sensownie działać.

Antywirus działa głównie na końcówce – komputerze, serwerze, telefonie. Analizuje pliki, procesy, czasem ruch sieciowy na tym jednym urządzeniu. Dobrze radzi sobie z klasycznym malware, ale nie widzi pełnego obrazu sieci i nie monitoruje tego, co robią inne urządzenia.

Firewall (np. na routerze) filtruje ruch według adresów IP, portów, protokołów. Pozwala zablokować „kierunki” komunikacji, ale nie widzi logiki ataku. Dla zapory ruch HTTP do portu 80 może wyglądać identycznie, niezależnie czy jest to zwykła wizyta na stronie, czy próba wykorzystania luki SQL Injection.

IDS (Intrusion Detection System) analizuje ruch sieciowy pod kątem śladów ataków, exploitów, skanów, anomalii. Działa jak radar: niekoniecznie blokuje (choć może), ale wykrywa i alarmuje o zdarzeniach podejrzanych. IPS (Intrusion Prevention System) to krok dalej – system nie tylko wykrywa, ale automatycznie blokuje ruch zgodny z określonymi regułami.

Raspberry Pi jako sensor sieciowy z darmowym IDS dokładnie wypełnia lukę między prostym firewallem routera a antywirusami na poszczególnych urządzeniach. Zyskujesz wgląd w cały ruch, który przechodzi przez twoją sieć, a nie tylko w to, co dzieje się na jednym komputerze.

Typowe zagrożenia w domu i małej firmie

W sieciach domowych i małych biurach zagrożenia są inne niż w dużych korporacjach, ale równie realne. Przykładowe kategorie, które darmowy IDS na Raspberry Pi potrafi wychwycić:

• Botnety IoT – kamery IP, rejestratory, tanie routery, żarówki Wi‑Fi z domyślnymi hasłami stają się częścią sieci botnetu (np. Mirai). IDS wykryje nietypowe połączenia do serwerów C&C, masowe próby logowania, nietypowe porty.
• Skanowanie portów z internetu – boty szukają wystawionych usług (RDP, SSH, FTP). IDS pokazuje skany, próby logowania, brute force – nawet jeśli firewall większość ruchu blokuje.
• Malware i exploit kit z maili i stron WWW – po kliknięciu w złośliwy załącznik komputer łączy się do podejrzanych domen, próbuje pobrać dodatkowe komponenty lub komunikować się z serwerem C&C. IDS ma sygnatury na takie zachowania.
• Nietypowe użycie protokołów – np. tunelowanie ruchu przez DNS (DNS tunneling), brak szyfrowania tam, gdzie powinno być (np. logowanie do panelu admina po HTTP), dziwne protokoły używane przez aplikacje w sieci lokalnej.
• Brutalne błędy konfiguracyjne – otwarty port SMB na świat, wystawiony panel administracyjny routera, serwer RDP bez VPN. IDS wychwyci niepokojące próby logowania i skanowania takich usług.

Już samo zmapowanie, jakie protokoły i dokąd idą z twojej sieci, często otwiera oczy. IDS nie zastąpi zdrowego rozsądku, ale daje dane, które pozwalają podejmować świadome decyzje.

Jaka realna wartość z IDS w praktyce

Największą wartością IDS w małej sieci nie jest nawet „blokowanie ataków”, a możliwość wczesnego wykrycia, że coś jest nie tak. Kilka typowych korzyści:

• Wczesna detekcja infekcji – jeżeli jedno z urządzeń zacznie nagle łączyć się z serwerami w egzotycznych krajach, IDS to zauważy. Zanim komputer zacznie szyfrować dane lub wysyłać gigabajty na zewnątrz.
• Kontrola nad tym, co „gada” w sieci – IDS pokazuje, jakie aplikacje i urządzenia najczęściej wychodzą w internet, z jakimi domenami się łączą, jakie protokoły wykorzystują.
• Diagnoza problemów z przepustowością – duża liczba połączeń, masowe skany, flood pakietów mogą obciążać łącze. Na dashboardzie ruchu zobaczysz, co generuje nagłe piki.
• Lepsze decyzje konfiguracyjne – mając dane z IDS łatwiej wyłączyć zbędne funkcje w urządzeniach IoT, zablokować ruch do konkretnych krajów lub domen na firewallu, wdrożyć segmentację sieci.

Dodatkowy bonus: przy problemach typu „internet muli” czy „drukarka znika z sieci” IDS nadzorujący ruch w LAN pomaga zobaczyć, czy problemem jest nadmiar połączeń, zalew ARP, czy może konkretny host generuje nadmierne obciążenie.

Przykład: „gadatliwy” smart TV z podejrzanymi połączeniami

Wyobraźmy sobie prostą sytuację: w sieci pojawia się nowy smart TV. Normalnie łączy się z serwerami producenta, Netflixem, YouTube i kilkoma CDN-ami. Po tygodniu IDS zaczyna generować powtarzalne alerty: telewizor komunikuje się co kilka minut z serwerem w nietypowym kraju, który widnieje na listach reputacyjnych jako potencjalnie niebezpieczny.

Bez IDS nie miałbyś pojęcia, że coś takiego się dzieje. Dzięki darmowemu IDS na Raspberry Pi:

• widzisz dokładnie, z jakim adresem IP i domeną łączy się TV,
• porównujesz to z logami routera i ewentualnie z listami reputacyjnymi,
• blokujesz te połączenia na firewallu (np. na routerze lub Pi),
• ewentualnie przenosisz telewizor do osobnego VLANu „IoT”, aby odizolować go od reszty sieci.

Tego typu konkretne przypadki szybko pokazują, dlaczego IDS działa jak praktyczny radar, a nie tylko ciekawostka dla adminów.

Raspberry Pi jako tani radar bezpieczeństwa w sieci

Dobry router z wbudowanym IDS/IPS, abonamentem na reguły i sensowną wydajnością kosztuje kilkukrotnie więcej niż pełny zestaw z Raspberry Pi, kartą SD/SSD i dodatkowymi akcesoriami. A Raspberry Pi może wykonywać jeszcze inne zadania: VPN, serwer monitoringu, mały serwer logów.

Stawiając darmowy IDS na Raspberry Pi, zyskujesz elastyczny, tani i rozwojowy element infrastruktury bezpieczeństwa, który można stopniowo rozbudowywać – od samego podglądu, przez automatyczne blokowanie nietypowego ruchu sieciowego, aż po pełnoprawny tryb IPS inline.

Podstawy: jak działa IDS i czym różni się od IPS

Modele detekcji: sygnatury, anomalie i hybryda

Darmowe IDS takie jak Suricata, Snort czy Zeek opierają się na kilku modelach detekcji. Rozumiejąc je, łatwiej świadomie dobierać reguły i ograniczać liczbę fałszywych alarmów.

Detekcja sygnaturowa działa jak antywirus. Każdy znany atak, exploit czy typowy fragment złośliwego payloadu ma swoją sygnaturę – wzorzec pasujący do fragmentu ruchu sieciowego (np. ciągu znaków, sekwencji pakietów). Taki model jest bardzo skuteczny na znane zagrożenia, ale nie zadziała na zupełnie nowe ataki – dopóki ktoś nie zdefiniuje odpowiedniej reguły.

Detekcja anomalii opiera się na modelu „normalnego” ruchu w sieci i wykrywaniu odchyleń – nietypowych hostów, portów, ilości połączeń, wielkości pakietów. To podejście jest silne na ataki zero-day i nowe techniki, ale często generuje fałszywe pozytywy, szczególnie w dynamicznych, mało uporządkowanych sieciach domowych.

Model hybrydowy łączy oba podejścia: część ruchu jest porównywana do znanych sygnatur, a dodatkowo monitorowane są wskaźniki typu „ilość połączeń z danego hosta”, „liczba błędnych logowań”, „nietypowe protokoły na nietypowych portach”. Suricata czy Zeek potrafią zbierać metadane (flows) i na ich podstawie budować obraz „normalności”.

Dla domowego i małego biura najlepszy na początek jest zestaw sprawdzonych reguł sygnaturowych plus lekkie elementy anomalii, zamiast budowania własnych, skomplikowanych modeli behaviorystycznych.

Pasywny IDS a aktywny IPS na przykładach

Pasywny IDS słucha ruchu, analizuje go i generuje alerty, ale nie ingeruje w przesyłanie pakietów. Przykład: Suricata skonfigurowana na porcie mirrorującym na przełączniku – widzi wszystko, ale pakiety nie przechodzą przez nią fizycznie. Jeśli IDS zauważy atak SQL Injection na twoją stronę WWW, zapisze alert i ewentualnie wyśle powiadomienie, ale nie zablokuje ataku samodzielnie.

IPS pracuje inline – ruch przechodzi przez ten system, tak jak przez router czy firewall. Jeśli reguła mówi „blokuj tego typu ruch”, IPS po prostu nie przepuszcza pakietów dalej. Przykład: Raspberry Pi wpięte między router a przełącznik, działające jako bridge z Suricatą w trybie IPS – każde połączenie przechodzi przez Pi, a reguły mogą od razu odrzucić złośliwe pakiety.

Konsekwencje:

• IDS jest bezpieczniejszy na start – jeśli coś źle ustawisz, co najwyżej będziesz mieć spam w logach, ale nie utniesz sobie internetu.
• IPS daje większą kontrolę i automatyczne blokowanie, ale wymaga bardzo solidnych reguł i większego zaufania do wydajności i stabilności Raspberry Pi.
• Na początku rozsądne jest połączenie: pasywne IDS + skrypty reagujące na niektóre alerty (np. dynamiczna modyfikacja firewall na routerze lub Pi).

Gdzie podłączyć IDS w małej sieci

Kluczowe pytanie brzmi: gdzie wpiąć sensor, żeby widział to, co cię interesuje. W praktyce są trzy główne miejsca:

• Za routerem, przed resztą sieci LAN – IDS obserwuje ruch między internetem a twoją siecią wewnętrzną. To dobre miejsce, jeśli głównie interesuje cię wykrywanie ataków z zewnątrz, komunikacji złośliwego oprogramowania na zewnątrz, botnetów, skanów.
• Przed lub za kluczowymi serwerami – np. NAS, serwer firmowy, ważna maszyna z księgowością. IDS monitoruje ruch do/z tych hostów, wykrywając próby włamań, nieautoryzowany dostęp, nietypowe protokoły.
• W wydzielonym segmencie IoT lub gości – IDS patrzy na komunikację „niskozaufanych” urządzeń, typu kamery, żarówki, telewizory, urządzenia odwiedzających. To dobre miejsce do łapania botnetów i dziwnych zabawek typu „smart-cokolwiek”.

W małych sieciach, gdzie router operatora ma jedno wyjście LAN, często najlepszym kompromisem jest wpięcie Raspberry Pi „za routerem” i obserwacja ruchu wychodzącego/ przychodzącego do internetu oraz kluczowych hostów.

Ograniczenia: czego IDS nie zobaczy

Żaden IDS, nawet najbardziej zaawansowany, nie jest magicznym okiem widzącym wszystko. Projektując jak wykrywać i blokować nietypowy ruch w sieci z użyciem darmowego IDS na Raspberry Pi, trzeba uwzględnić ograniczenia:

• Szyfrowanie – ruch HTTPS, VPN, SSH jest zaszyfrowany; IDS widzi tylko metadane (adresy IP, porty, SNI w TLS, rozmiar, czas). Nie podejrzy zawartości formularza logowania na stronie banku, ale może zauważyć, że komputer nagle łączy się do dziwnego serwera TLS.
• Ruch poza punktem nasłuchu – jeśli Pi jest wpięte za routerem, nie zobaczy ruchu Wi‑Fi między dwoma urządzeniami na tym samym AP, o ile nie przechodzi przez mirrorowany port lub bridge.
• Brak reguły – brak detekcji – jeśli nikt nie napisał reguły na dany atak, IDS tego ataku sygnaturowo nie wykryje. Stąd ważna jest aktualizacja reguł i rozsądne korzystanie z list reputacyjnych.
• Wydajność Raspberry Pi – jeśli ruch jest bardzo duży, a Pi za słabe lub źle skonfigurowane, może gubić pakiety. Wtedy część ataków może przemknąć niezauważona.

W praktyce przy sensownej konfiguracji IDS staje się bardzo użytecznym źródłem wiedzy, ale nie powinien być jedynym narzędziem – raczej częścią większej układanki (firewall, kopie zapasowe, zdrowe nawyki użytkowników).

Pasywne IDS + lekkie reagowanie – dobry start

Od alertu do akcji: prosty łańcuch reakcji

Pasywny IDS sam niczego nie blokuje, ale w małej sieci łatwo zamienić wybrane alerty w realne działania. Chodzi o prosty łańcuch: alert → decyzja → automatyczna akcja.

Przykładowy schemat może wyglądać tak:

• Suricata zapisuje alert o podejrzanym ruchu do pliku JSON lub wysyła go do Sysloga,
• lekki skrypt (np. w Pythonie lub Bashu) nasłuchuje nowych alertów,
• jeśli alert spełnia warunek (np. powtarzające się skany z jednego IP), skrypt dodaje regułę blokującą na firewallu,
• Pi wysyła krótką wiadomość (e‑mail, Telegram, Slack) z informacją, co zostało zablokowane i dlaczego.

Nie musi to być od razu super‑automatyzacja. Można zacząć od prostych reakcji „półautomatycznych”: skrypt generuje gotową regułę iptables/nftables lub komendę dla routera, którą wklejasz ręcznie. Z czasem, gdy zaufasz regułom, tę samą logikę przełączasz na tryb w pełni automatyczny.

Wiele problemów – skaner portów z jednego IP, setki błędnych logowań SSH, dziwny ruch DNS – da się opanować kilkoma linijkami skryptu. Zaczynasz od pasywnego monitoringu, ale krok po kroku budujesz własny mini‑SOC w wersji light.

Wybór darmowego IDS i ocena, czy Raspberry Pi da radę

Popularne darmowe IDS: Suricata, Snort, Zeek

Na rynku open source królują trzy silniki, które sprawdzają się zarówno w małych sieciach, jak i w dużych firmach. Każdy z nich ma trochę inny charakter.

Suricata to obecnie bardzo popularny silnik IDS/IPS/NSM. Obsługuje:

• detekcję sygnaturową na bazie reguł podobnych do Snorta,
• analizę protokołów (HTTP, DNS, TLS, SMB itd.),
• pracę w trybie pasywnym i IPS inline,
• eksport metadanych (flows) i logów w formatach JSON, EVE, PCAP.

Jest dobrze wspierana, ma szeroką bazę reguł (m.in. Emerging Threats), radzi sobie sensownie na małym sprzęcie i jest dobrym wyborem na Raspberry Pi.

Snort to klasyk – przez lata standard de facto w IDS. Oparty na regułach, bardzo rozbudowany, ale w praktyce nieco bardziej „enterprise” i mniej wygodny na lekkich platformach domowych, szczególnie jeśli nie planujesz głębokiej integracji z komercyjnymi subskrypcjami reguł.

Zeek (dawniej Bro) jest bardziej systemem monitoringu sieci i analizy zdarzeń niż klasycznym silnikiem sygnaturowym. Tworzy szczegółowe logi protokołów, pozwala pisać własne skrypty analityczne. Rewelacyjny do głębokiej analizy, ale na start bywa zbyt ciężki koncepcyjnie dla domowego użycia i wymaga trochę więcej nauki.

Dla Raspberry Pi w roli „radaru bezpieczeństwa” rozsądny wybór to Suricata jako główny silnik, a Zeek można dołożyć później, jeśli zechcesz iść bardziej w stronę analizy zachowań.

Które Raspberry Pi ma sens pod IDS?

Teoretycznie da się odpalić IDS nawet na starym Raspberry Pi 2, ale w praktyce szybko skończy się to gubieniem pakietów i frustracją. Przy wyborze modelu dobrze spojrzeć na kilka kryteriów.

Najważniejsze elementy:

• CPU i RAM – więcej rdzeni i pamięci to więcej reguł i mniejsze ryzyko dropów,
• karta sieciowa – najlepiej wbudowany gigabit (Pi 4/5), a nie tylko 100 Mbps,
• magazyn danych – szybka karta microSD lub mały SSD ograniczy „zamulenie” przy logowaniu ruchu.

Praktyczne warianty:

• Raspberry Pi 3 – wystarczające do lekkiego IDS dla łącza do ~100 Mbps, z ograniczoną liczbą reguł i raczej w trybie pasywnym. Dobry na pierwsze testy.
• Raspberry Pi 4 – solidna baza dla domowego i małego biura. Gigabit Ethernet, więcej RAM (4–8 GB), spokojnie obsłuży bogatsze zestawy reguł i większy ruch.
• Raspberry Pi 5 – najmocniejsza opcja, jeśli planujesz intensywny ruch, DPI, więcej usług na jednym Pi (VPN, logi, IDS/IPS).

W praktyce Raspberry Pi 4 z 4 GB RAM to „złoty środek”: niedrogie, a wystarczająco wydajne, by obsłużyć Suricatę, kilka tysięcy reguł i sensowną ilość logów bez duszenia się przy każdym skoku ruchu.

Szacowanie wydajności: ile ruchu ogarnie Pi?

Wydajność zależy od wielu czynników: liczby reguł, typu ruchu, poziomu logowania, a nawet sposobu kompilacji Suricaty. Na start pomaga kilka prostych wskazówek.

Przy domowym łączu rzędu 300–600 Mbps i kilku/kilkunastu klientach:

• Raspberry Pi 4 da sobie radę z pasywnym IDS z standardowym zestawem reguł ET Open,
• w trybie IPS inline sensownie jest celować w ~100–300 Mbps, zależnie od obciążenia i optymalizacji,
• redukcja zbędnych reguł (np. dotyczących protokołów, których nie używasz) mocno pomaga.

Dobrym nawykiem jest stopniowe zwiększanie „ambicji”: zaczynasz od podsłuchu z podstawowym logowaniem, potem stopniowo dodajesz reguły, pełniejsze logi i ewentualnie tryb IPS – obserwując obciążenie CPU, ilość gubionych pakietów i opóźnienia.

Na co jeszcze zwrócić uwagę przy wyborze rozwiązania

Poza samym silnikiem IDS liczy się ekosystem. Chodzi o to, żebyś nie spędzał godzin na walce z formatami logów i ręcznym parsowaniem JSON‑a, tylko szybko zobaczył „kto, dokąd, kiedy i dlaczego”.

• Wsparcie dla EVE JSON – Suricata generuje logi EVE, które łatwo wciągnąć do narzędzi takich jak Kibana, Grafana, Loki czy nawet prosty Elastic/Opensearch.
• Gotowe dashboardy – wiele projektów (np. SELKS, Security Onion – choć to cięższe dystrybucje) pokazuje, jak wyglądają praktyczne panele; możesz zainspirować się ich układem nawet na lekkim Pi.
• Automatyczna aktualizacja reguł – skrypty aktualizujące ET Open, reguły społecznościowe, a czasem także listy reputacyjne IP i domen.

Jeśli celem jest praktyczny radar, a nie zabawa w kolejne komendy, wybór Suricaty z EVE JSON i prostym narzędziem do wizualizacji (nawet lokalnym) to bardzo rozsądny skrót.

Projekt architektury: jak wpiąć Raspberry Pi IDS w realną sieć

Tryb pasywny: mirrorowanie portu i TAP

Pasywny tryb to najbezpieczniejszy start. IDS ogląda ruch, ale go nie dotyka. Do tego potrzebujesz miejsca, w którym sklonujesz pakiety z „głównej ścieżki” sieci na port Raspberry Pi.

Dwa najprostsze warianty:

• Port mirror na przełączniku – jeśli masz zarządzalny switch, ustawiasz mirror/port‑span z portu, na którym jest router (lub inny istotny segment) na port, do którego podłączone jest Pi.
• Sprzętowy TAP – małe urządzenie wkładane między router a switch, które kopiuje ruch na dodatkowy port monitorujący. Do tego portu wpinasz Pi.

Na Raspberry Pi konfigurujesz interfejs sieciowy w trybie tylko‑nasłuch (bez IP lub z IP w innym VLANie) i uruchamiasz Suricatę na tym interfejsie. Internet dalej działa tak jak wcześniej; Pi jest „obserwatorem z boku”.

W domowych warunkach często wystarcza tani, mały switch z obsługą mirrorowania. Pozwala to jednym ruchem objąć monitoringiem cały ruch idący z/na router, czyli praktycznie wszystkie połączenia z internetem.

Tryb IPS inline: Raspberry Pi jako bridge

Jeśli chcesz, żeby IDS mógł aktywnie blokować ruch, Pi musi stanąć „na drodze” pakietów. W małej sieci najprościej zrobić z niego bridge między routerem a resztą LAN.

Klasyczny scenariusz:

• router operatora ma jedno wyjście LAN,
• do tego wyjścia podpinasz port eth0 Raspberry Pi,
• do portu eth1 (np. dodatkowa karta USB‑Ethernet) podpinasz switch lub resztę sieci,
• na Pi konfigurujesz bridge łączący oba interfejsy i uruchamiasz Suricatę w trybie IPS na tym bridge.

Dzięki temu cały ruch z/na internet przechodzi przez Pi. Suricata może nie tylko generować alerty, ale także na podstawie reguł decydować, co przepuszczać, a co błyskawicznie odrzucać. Kluczowe jest stabilne zasilanie, sensowna obudowa z chłodzeniem i sprawdzona karta sieciowa USB, żeby uniknąć „wąskich gardeł”.

Dla wielu osób najlepsza droga to: najpierw mirror i tryb pasywny, dopiero po kilku tygodniach, gdy konfiguracja się „ułoży”, przełączenie na bridge i IPS inline.

Segmentacja: osobne VLANy dla IoT i gości

Raspberry Pi może pomóc opanować bałagan w sieci, ale jeszcze większą siłę zyskasz, gdy połączysz IDS z segmentacją. Nawet prosty podział na:

• VLAN „Core” – komputery, NAS, drukarki,
• VLAN „IoT” – kamery, telewizory, czujniki,
• VLAN „Guests” – urządzenia gości,

pozwala lepiej panować nad tym, kto z kim może rozmawiać w sieci. IDS może wtedy patrzeć osobno na ruch IoT (szukanie botnetów), osobno na VLAN gościnny (np. masowe skanowanie portów) i osobno na ruch „core”.

W praktyce oznacza to:

• router lub switch zarządzalny konfigurujesz z VLANami,
• trunk z VLANami idzie do przełącznika,
• Raspberry Pi widzi poszczególne VLANy (np. poprzez mirror lub bridge trunku) i Suricata ma osobne reguły/priorytety dla różnych segmentów.

Nawet jeśli nie wdrożysz od razu pełnej segmentacji, zaplanowanie jej pod kątem IDS ułatwi późniejsze kroki – unikniesz sytuacji, w której wszystko miesza się w jednym „worku”, a logi ciężko zinterpretować.

Integracja z istniejącym routerem operatora

Wiele osób korzysta z routera dostarczonego przez operatora, który często ma ograniczone możliwości konfiguracji. Nie dyskwalifikuje to IDS, ale wymusza kilka kompromisów.

Praktyczne podejścia:

• Tryb bridge na routerze operatora – jeśli dostępny, przełączasz router w bridge, a własny router (z IDS/IPS lub z Pi) przejmuje całą logikę DHCP/NAT/Firewall. To najlepszy wariant.
• Raspberry Pi za routerem, w trybie monitoringu – jeśli nie masz wpływu na konfigurację routera operatora, wstawiasz Pi za nim, jako sensor na mirrorowanym porcie switcha. IDS widzi ruch do/z internetu, ale niekoniecznie cały ruch wewnętrzny.
• Pi jako dodatkowy firewall/VPN – ruch krytyczny (np. z laptopa służbowego) kierujesz przez Pi (VPN, proxy, tunel), gdzie działa IPS, a reszta sieci funkcjonuje „normalnie” za routerem operatora.

Nie zawsze uda się od razu przebudować całą sieć, ale nawet częściowe objęcie ruchu monitoringiem jest ogromnym krokiem naprzód. Z czasem łatwiej przekonać się do głębszych zmian, kiedy widzisz realne korzyści w logach.

Przygotowanie Raspberry Pi: system, sieć i twarda podstawa bezpieczeństwa

Wybór systemu: Raspberry Pi OS czy coś innego?

Do IDS na Pi nie jest potrzebna żadna egzotyczna dystrybucja. W wielu przypadkach najprościej postawić na Raspberry Pi OS (Lite) – wersję bez środowiska graficznego.

Zalety takiego podejścia:

• lekkość – mniej procesów, mniej aktualizacji, więcej zasobów dla Suricaty,
• znane repozytoria i pakiety,
• dobra dokumentacja i mnóstwo poradników.

Alternatywy typu Ubuntu Server dla Pi także działają dobrze – szczególnie jeśli lubisz ten ekosystem i planujesz integrację z innymi serwerami Ubuntu. Kluczowe, żeby system był stabilny, aktualny i bez zbędnych „wodotrysków”.

Podstawowa twarda konfiguracja systemu

IDS ma chronić sieć, więc sam nie może być łatwym celem. Minimalna, ale solidna higiena systemu robi olbrzymią różnicę.

• Zmiana domyślnego hasła – banalne, ale wciąż powszechnie zaniedbywane.
• Utworzenie osobnego użytkownika administracyjnego i wyłączenie logowania jako „pi” (jeśli używasz Raspberry Pi OS),
• Aktualizacja systemu – regularne apt update && apt upgrade lub skonfigurowanie automatycznych aktualizacji bezpieczeństwa,
• SSH – logowanie wyłącznie kluczem (bez haseł), zmiana portu, ewentualnie ograniczenie dostępu z konkretnych adresów IP.

Bezpieczeństwo sieciowe Raspberry Pi

Sam system to jedno, ale Pi stoi w środku Twojej sieci i widzi praktycznie wszystko. Trzeba go traktować jak host o podwyższonym zaufaniu, który mimo to ma możliwie mało „furtek” na zewnątrz.

• Minimalne usługi – usuń lub wyłącz wszystko, czego nie używasz: serwer WWW, Bluetooth, Avahi/zeroconf, drukowanie sieciowe. Im mniej demonów, tym mniejsza powierzchnia ataku.
• Firewall na Pi – prosty zestaw reguł nftables lub ufw, który wpuszcza tylko SSH z określonych adresów i (jeśli trzeba) porty do panelu WWW. NIC więcej nie musi być otwarte.
• Brak usług „w świat” – nie wystawiaj Pi bezpośrednio do internetu (port forwarding, DMZ). Dostęp zdalny ogarnij VPN‑em lub chociaż tunelem SSH.
• Monitoring samego Pi – lekkie narzędzia typu logwatch czy proste skrypty raportujące zajętość dysku i obciążenie CPU/mailowo są bezcenne, gdy logi nagle zaczną rosnąć.

Im bardziej Pi jest „nudne” z punktu widzenia atakującego, tym lepiej. Zrób z niego specjalistę od podsłuchu, a nie serwer do wszystkiego.

Konfiguracja sieci: adresacja, DNS i synchronizacja czasu

IDS żyje z detali. Jeśli czas się rozjeżdża, DNS robi dziwne sztuczki, a adresy IP skaczą jak szalone, analiza logów szybko zamienia się w zgadywankę.

• Stały adres IP dla Pi – ustaw rezerwację DHCP na routerze lub statyczne IP na interfejsie zarządzającym. Potem zawsze wiesz, że np. 192.168.1.10 to Twój sensor.
• Porządny NTP – konfiguracja systemd-timesyncd albo klasycznego NTP z zaufanymi serwerami. Dobrze, jeśli Pi, router i inne kluczowe hosty korzystają z tego samego źródła czasu.
• DNS z logowaniem – jeśli w sieci używasz Pi‑hole, Unbound lub innego lokalnego DNS, będzie świetnym uzupełnieniem logów z IDS. Nazwa domeny + reguła Suricaty to już konkretna historia.
• Rozdzielenie interfejsów – przy IPS/bridge trzymaj osobny interfejs (lub VLAN) tylko na zarządzanie. Ruch produkcyjny przelatuje przez bridge, a Ty łączysz się do Pi innym „bocznym” kanałem.

Dobra, spójna konfiguracja sieci wokół Pi sprawia, że logi mają sens, a nie tylko zawierają „jakieś IP, gdzieś, kiedyś”.

Ochrona przed awarią i odzyskiwanie po błędach

W pewnym momencie coś zepsujesz – to normalne. Najważniejsze, żeby sieć i dane przeszły to w miarę bezboleśnie.

• Backup karty SD – po wstępnej konfiguracji zrób obraz karty (np. dd albo narzędzia typu Raspberry Pi Imager z funkcją klonowania). Gdy coś „wybuchnie”, wkładasz kopię i wstajesz w kilka minut.
• Konfiguracja jako kod – pliki /etc/suricata/, /etc/nftables.conf, skrypty cron – trzymaj w repo (Git na Pi lub prywatny serwer). Łatwo porównasz zmiany i cofniesz się do działającej wersji.
• Plan awaryjny dla IPS – jeśli Pi stoi w roli bridge, miej przygotowany prosty kabel „na skróty”: router → switch bez pośrednictwa Pi. W razie awarii wyciągasz dwa wtyki, wkładasz jeden kabel i masz sieć bez IDS, ale za to działającą.

Nawet podstawowy plan awaryjny sprawia, że odważniej testujesz nowe reguły i funkcje, bo nie boisz się, że „uśmiercisz” całą sieć.

Instalacja i wstępna konfiguracja darmowego IDS (Suricata)

Instalacja Suricaty na Raspberry Pi OS

Najwygodniej zacząć od pakietów z repozytoriów, szczególnie na etapie nauki. Kilka komend wystarczy, żeby Pi zaczęło patrzeć na pakiety.

sudo apt update
sudo apt install suricata jq

Po instalacji sprawdź wersję:

suricata --build-info | grep -E "Suricata|PCAP|NFQUEUE|AF_PACKET"

Dla trybu pasywnego wystarczy wsparcie dla PCAP/AF_PACKET, do IPS inline przyda się NFQUEUE lub tryb IPS w AF_PACKET w bridge’u.

Podstawowa struktura konfiguracji Suricaty

Suricata trzyma główną konfigurację zwykle w /etc/suricata/suricata.yaml. Warto poznać kilka kluczowych bloków, bez których łatwo się zgubić.

• af-packet / pcap – sekcja odpowiedzialna za nasłuchiwanie na interfejsach. Tu ustawiasz np. interface: eth1 oraz tryb IPS/pasywny.
• vars – zmienne sieciowe, m.in. HOME_NET, EXTERNAL_NET. Poprawne ustawienie to podstawa sensownych alertów.
• outputs – definicje logów: EVE JSON, syslog, pliki z HTTP, DNS itp. Tu włączysz/wyłączysz poszczególne strumienie.
• rule-files – lista plików z regułami, które Suricata ma wczytać przy starcie.

Dobrze jest zrobić kopię oryginalnego pliku suricata.yaml, a potem wprowadzać zmiany stopniowo, po kilka na raz.

Konfiguracja interfejsu w trybie pasywnym

Na start najbardziej naturalny jest podsłuch na jednym interfejsie, który widzi ruch z mirrorowanego portu lub TAP‑a.

1. Sprawdź nazwy interfejsów:

   ip link show
   

2. Załóżmy, że interfejs do podsłuchu to eth1. W suricata.yaml znajdź sekcję af-packet i ustaw:

   af-packet:
     - interface: eth1
       cluster-id: 99
       cluster-type: cluster_flow
       defrag: yes
       use-mmap: yes
   

3. Upewnij się, że Suricata będzie używać właśnie tego modułu (a nie np. pcap) jako głównego źródła ruchu.

Przy pracy pasywnej interfejs monitorujący może w ogóle nie mieć adresu IP – dzięki temu nawet jeśli coś się pomyli w firewallu, ruch nie wejdzie do Pi tą ścieżką.

Ustawienie HOME_NET i EXTERNAL_NET

Reguły bazują na podziale „nasze” vs „świat”. Dobrze określony HOME_NET sprawia, że nie toniesz w nieprzydatnych alertach.

vars:
  address-groups:
    HOME_NET: "[192.168.0.0/16,10.0.0.0/8]"
    EXTERNAL_NET: "!$HOME_NET"

Jeśli masz kilka podsieci lub VLANów, dodaj je w tej liście. Później, kiedy zaczniesz stosować różne polityki do różnych segmentów, ten podział zaoszczędzi mnóstwo czasu.

Włączenie i dostosowanie logów EVE JSON

EVE to główne „okno” na to, co Suricata widzi w sieci. Dzięki niemu zbudujesz proste dashboardy i skrypty alarmujące.

outputs:
  - eve-log:
      enabled: yes
      filetype: regular
      filename: /var/log/suricata/eve.json
      types:
        - alert
        - dns
        - http
        - tls
        - ssh
        - flow

Na początek wystarczy kilka typów. Gdy ogarniesz podstawy, można dołożyć np. stats czy fileinfo. Jeśli logi rosną zbyt szybko, zacznij od alert i flow; resztę dołóż później.

Źródła darmowych reguł: ET Open i społecznościowe

Bez reguł IDS jest tylko szybkim snifferem. Nawet podstawowy zestaw darmowych reguł potrafi wyłapać zaskakująco dużo śmieci latających po domowym łączu.

• Emerging Threats Open (ET Open) – darmowy, regularnie aktualizowany zestaw reguł. Pokrywa masę typowych ataków, malware i dziwnego ruchu.
• Reguły Suricata‑community – skromniejsze, ale niezłe jako uzupełnienie.

Przykładowy, prosty sposób pobierania ET Open:

cd /etc/suricata/rules
sudo wget https://rules.emergingthreats.net/open/suricata-6.0/emerging.rules.tar.gz
sudo tar xzf emerging.rules.tar.gz
sudo rm emerging.rules.tar.gz

Następnie w suricata.yaml upewnij się, że pliki są uwzględnione w sekcji rule-files, np.:

rule-files:
  - suricata.rules
  - emerging-all.rules

Dla wygody warto przygotować prosty skrypt aktualizujący reguły raz na tydzień i odpalać go z crona.

Oszczędne podejście do reguł na Raspberry Pi

Pełen komplet reguł to łatwy sposób na zaduszenie słabszego sprzętu. Pi poradzi sobie sensownie, jeśli dasz mu przemyślany zestaw, zamiast „wszystko, co się da”.

• Wyłącz całe pliki z regułami dotyczące protokołów, których nie ma w Twojej sieci (np. SCADA, NetBIOS, jeśli używasz wyłącznie nowoczesnego SMB, egzotyczne protokoły przemysłowe).
• Rozważ uruchomienie osobnego pliku local.rules, gdzie trzymasz najważniejsze i ręcznie wybrane reguły specyficzne dla sieci domowej.
• Stopniowo włączaj kolejne kategorie zamiast wszystkiego naraz – obserwuj obciążenie CPU i ilość alertów.

Celem jest sensor, który reaguje szybko, a nie taki, który robi wszystko „na papierze”, ale gubi połowę pakietów przy byle speedteście.

Pierwszy start Suricaty i test działania

Po wprowadzeniu podstawowych zmian warto odpalić Suricatę w trybie „na konsolę”, żeby zobaczyć, czy nie sypie błędami.

sudo systemctl stop suricata
sudo suricata -c /etc/suricata/suricata.yaml -i eth1 -D

Albo jeszcze prościej, do szybkiego testu bez demona:

sudo suricata -c /etc/suricata/suricata.yaml -i eth1

W innym terminalu sprawdź logi:

tail -f /var/log/suricata/eve.json

Otwórz kilka stron WWW, odpal aplikacje na telefonie – jeśli w EVE zaczynają pojawiać się flow, HTTP i DNS, wszystko jest na dobrej drodze.

Proste filtrowanie i podgląd logów EVE

Surowe EVE JSON to ściana tekstu. Nawet bez pełnego SIEM‑a można zrobić podstawowe filtrowanie lokalnie, na Pi.

• Podgląd samych alertów:

  jq 'select(.event_type=="alert") | {timestamp,src_ip,dest_ip,alert}' 
    /var/log/suricata/eve.json
  

• Sprawdzenie, jakie domeny są najczęściej odwiedzane:

  jq -r 'select(.event_type=="dns") | .dns.rrname' 
    /var/log/suricata/eve.json | sort | uniq -c | sort -nr | head
  

• Wyłuskanie ruchu HTTP z konkretnego hosta:

  jq 'select(.event_type=="http" and .src_ip=="192.168.1.50")' 
    /var/log/suricata/eve.json
  

Nawet kilka takich prostych komend pozwala szybko złapać, który sprzęt w sieci „bryka” najbardziej i gdzie wysyła ruch.

Automatyczna rotacja logów i kontrola miejsca

IDS generuje logi cały czas, a karty SD nie lubią przepełnienia. Trzeba pilnować ich rozmiaru od pierwszego dnia.

• logrotate – pakiet zwykle jest już w systemie. Dodaj plik konfiguracyjny np. /etc/logrotate.d/suricata:

  /var/log/suricata/*.log /var/log/suricata/*.json {
      daily
      rotate 7
      compress
      missingok
      notifempty
      postrotate
          systemctl reload suricata >/dev/null 2>&1 || true
      endscript
  }
  

• Przeniesienie logów – przy większym ruchu sensownie jest trzymać logi na osobnym nośniku (np. dysk USB) i tylko krótką buforową historię na karcie SD.

Dzięki rotacji Pi nie „udławi się” logami po kilku dniach bardziej intensywnego ruchu czy testów.

Włączenie trybu IPS w konfiguracji Suricaty

Gdy pasywny tryb zacznie Cię nudzić, można przejść do blokowania. Na Raspberry Pi zazwyczaj najprościej użyć trybu IPS z AF_PACKET w połączeniu bridge.

W suricata.yaml w sekcji af-packet dodaj parametry:

Najważniejsze wnioski

• Raspberry Pi z darmowym IDS zamienia domową lub małą firmową sieć w „radar bezpieczeństwa”, który pokazuje pełny obraz ruchu – kto z kim się łączy, jakimi protokołami i czy nie dzieje się nic podejrzanego.
• IDS/IPS wypełnia lukę między antywirusem a firewallem: antywirus widzi tylko końcówkę, firewall tylko porty i IP, a IDS analizuje faktyczną treść i logikę ruchu, wyłapując skany, exploity i anomalie.
• Nawet w małej sieci realne są zagrożenia takie jak botnety IoT, skanowanie portów z internetu, malware komunikujące się z serwerami C&C, tunelowanie przez DNS czy katastrofalne błędy konfiguracyjne – IDS potrafi je wykryć na wczesnym etapie.
• Największą przewagą IDS jest szybkie wychwycenie „czegoś dziwnego” w sieci: nagłe połączenia do egzotycznych serwerów, gwałtowny wzrost liczby sesji czy nietypowe protokoły od razu sygnalizują potencjalny problem.
• Dane z IDS pomagają podejmować lepsze decyzje: wyłączać zbędne funkcje w IoT, blokować wybrane kraje lub domeny na firewallu, planować segmentację sieci i usuwać niebezpiecznie wystawione usługi.
• IDS jest też świetnym narzędziem diagnostycznym – przy problemach typu „internet muli” czy „drukarka znika z sieci” łatwo sprawdzić, czy winny jest zalew ARP, flood pakietów, czy jeden „rozgadany” host.

Bibliografia

• NIST Special Publication 800-94: Guide to Intrusion Detection and Prevention Systems (IDPS). National Institute of Standards and Technology (2007) – Definicje IDS/IPS, modele detekcji, rola w architekturze bezpieczeństwa
• NIST Special Publication 800-41 Revision 1: Guidelines on Firewalls and Firewall Policy. National Institute of Standards and Technology (2009) – Zadania firewalli, różnice względem IDS/IPS, dobre praktyki konfiguracji
• Suricata User Guide. Open Information Security Foundation – Opis działania Suricata IDS/IPS, tryby pracy, reguły i logowanie ruchu
• Snort 3 Manual. Cisco Systems – Dokumentacja Snort IDS/IPS, modele detekcji sygnaturowej i konfigurowanie reguł
• Zeek Documentation. Zeek Project – Opis monitoringu sieci, analizy protokołów i wykrywania anomalii w ruchu
• Raspberry Pi Documentation: Raspberry Pi Hardware and Configuration. Raspberry Pi Foundation – Parametry sprzętowe Raspberry Pi, zastosowania sieciowe i konfiguracja interfejsów
• ENISA Threat Landscape for the Internet of Things. European Union Agency for Cybersecurity – Przegląd zagrożeń IoT, scenariusze ataków i rekomendacje dla małych sieci
• OWASP Testing Guide v4. OWASP Foundation (2014) – Opis ataków web, m.in. SQL Injection, oraz ich śladów w ruchu sieciowym
• SANS Reading Room: Intrusion Detection FAQ and Best Practices. SANS Institute – Praktyczne wskazówki wdrożenia IDS, interpretacja alertów i typowe błędy