Kiedy wszystko grało, a nagle nic: realny problem na pokładzie
Wyjście z mariny idzie gładko, autopilot trzyma kurs, na ploterze widać ruch AIS. Po godzinie żeglugi ekran zaczyna się przycinać, autopilot „pływa” o kilka stopni, a aplikacja pogodowa na tablecie nie pobiera danych. W porcie działało szybkie Wi‑Fi mariny, na morzu router przełączył się na kartę 4G. Brzmi jak typowa usterka? Częściej niż myślisz to problem cyberbezpieczeństwa na jachcie: przeciążona, źle odseparowana sieć pokładowa, stare firmware i otwarte usługi wprowadziły chaos w kluczowych systemach. Jeden błąd konfiguracyjny – np. pozostawione domyślne hasło w bramce NMEA‑Wi‑Fi – potrafi sparaliżować rejs.
Mit: jacht jest „za małym celem” dla atakujących. Rzeczywistość: automatyczne skanery w sieciach marin i w Internecie wyszukują podatne urządzenia bez względu na banderę i wielkość jednostki.
Mit: na morzu jesteśmy odłączeni. Rzeczywistość: telefony załogi, router 4G/5G, satcom, zdalne monitoringi i chmury producentów łączą łódź z siecią non stop – także w pobliżu brzegu i na kotwicowisku.
Dlaczego dochodzi do incydentów – techniczne i ludzkie przyczyny
Jedna, płaska sieć dla wszystkiego
Wiele jachtów używa jednego SSID i jednego zakresu IP dla: ploterów, autopilota, kamer, komputerów, telefonów gości i telewizora. Bez segmentacji sieci (oddzielnych podsieci/VLAN) każdy element widzi każdy. Zainfekowany telefon natychmiast „widzi” bramkę NMEA 2000 czy rejestrator kamer i może je przeciążyć lub przejąć.
Stare firmware i urządzenia po EOL
Plotery, bramki NMEA, inwertery/ładowarki, modemy IoT i kamery często działają na oprogramowaniu sprzed lat. Producent już ich nie wspiera (end‑of‑life), więc znane luki nie będą łane. Aktualizacje bywały odkładane, bo „przecież działa”, a w sezonie nikt nie ryzykuje. To prosta droga do kompromitacji.
Domyślne hasła i zdalny dostęp
„admin/admin”, włączony UPnP na routerze, przekierowanie portów do bramki NMEA czy kamer – to gotowa ścieżka z Internetu na mostek. Do tego panele administracyjne dostępne z tego samego SSID co dla załogi i gości. Atakujący nie musi się wysilać.
„Evil twin” i Wi‑Fi w marinie
Popularna technika to podszywanie się pod sieć mariny (drugi, silniejszy punkt dostępowy o takim samym SSID). Załoga łączy się, a atakujący przechwytuje ruch i próbuje logowań do urządzeń pokładowych. Następnego dnia kłopoty wracają już na morzu – bo ustawienia zostały zmienione.
Ekspozycja bramek NMEA i usług autodiscovery
Bramki NMEA‑Wi‑Fi często wystawiają serwery TCP/UDP (np. 10110/2000) i usługi mDNS/SSDP. W płaskiej sieci dochodzi do „zalewania” ramek, plotery się dławią, a interfejsy odmawiają posłuszeństwa. Jeśli router z UPnP wypchnie te porty do Internetu – jacht pojawi się w wynikach wyszukiwarek IoT.
Zasilanie i zakłócenia to też cyber
Wahania napięcia przy rozruchu silnika, słabe masy, brak filtrów EMI – to korupcja danych na kartach SD z mapami, zawieszające się modemy i błądzący autopilot. Bez stabilnej energii nie ma bezpiecznych aktualizacji ani spójnych logów.
Co na jachcie jest krytyczne – mapa ryzyka systemów pokładowych
Nawigacja, autopilot, sensory po NMEA
Ploter, autopilot, przetworniki (wielo, wiatromierz, log) i GPS to serce bezpieczeństwa. Ryzyka: wstrzykiwanie fałszywych danych (spoofing GNSS/NMEA), denial of service na magistrali i po Wi‑Fi, przejęcie panelu Web bramki i zmiana konfiguracji. Skutek: błędne kursy, spadek świadomości sytuacyjnej, nadmierne zaufanie do autopilota.
Łączność i routery: wąskie gardło bezpieczeństwa
Router 4G/5G, punkt dostępowy Wi‑Fi i ewentualny terminal satelitarny to brama na świat. Ryzyka: włączone UPnP, przekierowania portów do urządzeń pokładowych, słabe hasła do Wi‑Fi, panel administracyjny dostępny z sieci gościnnej, a także „chmury” producenta z domyślnymi ustawieniami prywatności. Skutek: otwarte drzwi do całej elektroniki lub stabilne zdalne „dłubanie” w ustawieniach przez kogoś obcego.
Mit: wystarczy mocne hasło do Wi‑Fi. Rzeczywistość: hasło nie zatrzyma ruchu między segmentami sieci ani nie wyłączy automatycznych przekierowań portów – potrzebna jest architektura i reguły zapory.
Energia: inwertery, ładowarki i BMS online
Nowoczesne inwertery/ładowarki i systemy baterii LiFePO4 mają Ethernet/Wi‑Fi, Modbus/TCP lub aplikacje chmurowe. Ryzyka: zmiana profili ładowania, odcięcia przy złej konfiguracji, „brick” po przerwaniu aktualizacji przy spadku napięcia. To cyber‑fizyczne skutki – realne awarie energetyki pokładowej zdalnie.
Mit: urządzenia „od prądu” nie mają znaczenia dla cyber. Rzeczywistość: błąd w ich sieciowym interfejsie potrafi zatrzymać nawigację, jeśli zgaśnie ploter i bramka NMEA po wspólnym zasilaniu.
Monitoring, kamery i trackery
Kamery IP z RTSP, trackery GSM, czujniki zalania/dymu z P2P w chmurze – wygodne, ale często archaiczne pod względem bezpieczeństwa. Ryzyka: przesył obrazu bez szyfrowania, stałe „wycie” metadanych do zewnętrznych serwerów, przejęcie panelu WWW z domyślnymi hasłami. Skutek: podgląd pokładu lub pivot do bardziej krytycznych systemów.
BYOD i aplikacje na urządzeniach załogi
Tablety z mapami, telefony z aplikacjami NMEA, zegarki z Wi‑Fi – najczęstszy wektor wejścia. Ryzyka: złośliwe aplikacje, profile VPN z przekierowaniem całego ruchu, udostępnianie hotspotu łączącego podsieci. Wystarczy jeden nieaktualny tablet z dostępem do panelu bramki, by zmienić kurs całej wyprawy – dosłownie.
Architektura odporna na fale: prosta segmentacja na jachcie
Najbezpieczniej jest oddzielić ruch krytyczny od reszty. Nie trzeba od razu stawiać serwerowni – sprawdzi się prosty podział na trzy strefy z podstawowymi regułami zapory.
- Strefa NAV/OT (ploter, autopilot, bramki NMEA, GPS): brak Internetu „na stałe”, tylko wyjścia kontrolowane (np. NTP, pogoda przez proxy) i brak ruchu przychodzącego z innych stref.
- Strefa SERWIS (kamery, monitoring, inwerter/BMS, drukarka sieciowa): dostęp ograniczony z jednego urządzenia administracyjnego lub przez VPN; brak trasy do NAV.
- Strefa CREW/GUEST (telefony, tablety, TV): Internet tak, komunikacja wewnątrz sieci wyłączona (AP/client isolation), zero widoczności urządzeń NAV i SERWIS.
Do tego osobny, nieemitowany SSID „ADMIN” z silnym hasłem i tylko dla paneli WWW/SSH (dostęp okresowo włączany). Jedno urządzenie – laptop skippera – jako klucz administracyjny.
Krótka ścieżka: 60 minut audytu w marinie
Gdy czas goni, zrób te rzeczy po kolei. To daje natychmiastowe zyski bezpieczeństwa i stabilności:
- Router: wyłącz UPnP i WPS, ustaw unikalne hasło admina, wyłącz zarządzanie z WAN, włącz izolację klientów w sieci gościnnej.
- Wi‑Fi: rozdziel SSID na NAV (ukryty), SERWIS i GUEST; zmień hasła na losowe, długie; jeśli sprzęt pozwala – włącz VLAN.
- Bramki NMEA i plotery: zmień domyślne porty i hasła do panelu, wyłącz mDNS/SSDP, ustaw unicast zamiast multicastu/broadcastu gdzie się da.
- Kamery/tracker: wyłącz dostęp z chmury P2P, ustaw lokalny dostęp z VPN; RTSP tylko po sieci SERWIS lub przez proxy.
- Aktualizacje: zrób kopie konfiguracji (pliki z ploterów, routera, bramek), zasilanie na kablu brzegowym i pełne akumulatory; aktualizuj po jednym urządzeniu, testuj.
- Telefony/tablety: usuń nieużywane aplikacje, wyłącz automatyczne łączenie z otwartymi sieciami, rozłącz „udostępnianie Internetu”.
Konfiguracja routera, która działa na wodzie
Nie każdy router do jachtu jest równy. Szukaj modelu z VLAN, klientem VPN i sensowną zaporą. Minimum konfiguracji:
- WPA2‑PSK lub WPA3 dla SSID, długie hasła; GUEST z izolacją klientów i brakiem trasy do innych sieci.
- Firewall: blokuj ruch między VLAN‑ami; zezwól z NAV tylko na NTP i aktualizacje pogody przez adresy/proxy, a nie „pełny Internet”.
- Zero port‑forwardów do urządzeń pokładowych; zdalny dostęp wyłącznie przez tunel VPN (WireGuard/OpenVPN) zestawiany z jachtu „na zewnątrz”.
- DNS: własne lub DoT/DoH, stałe serwery; wyłącz przekaźniki z mariny.
- Failover 4G/5G ↔ satcom z histerezą, by uniknąć częstych przełączeń (które „wybijają” sesje i aplikacje).
Bezpieczne aktualizacje i urządzenia po EOL
Najwięcej awarii zdarza się nie przez same łatki, tylko przez brak procedury.
- Okno serwisowe w porcie, shore power, pełne baterie; jeśli to możliwe – mały UPS DC dla routera/plotera.
- Backup: konfiguracje i mapy na dwie karty/pendrive’y; punkt przywracania, jeśli sprzęt to wspiera.
- Pobieraj pliki firmware z zaufanych źródeł i trzymaj offline; wyłącz na czas aktualizacji inne, głośne usługi sieciowe.
- EOL: jeśli producent nie łata – odetnij urządzenie do osobnej strefy lub wymień. Lepiej prosta, wspierana bramka niż „flagowiec” bez łatek.
Zdalny dostęp bez otwierania pokładu
Bezpieczna telemetria i serwis da się zrobić bez dziur w zaporze.
- VPN tylko jako klient z jachtu do Twojego serwera (VPS w zaufanej chmurze lub biurze). Brak otwartych portów na routerze w marinie.
- Konta imienne, klucze zamiast haseł, 2FA na panel do zarządzania serwerem VPN.
- Dzienniki połączeń i prosty alert e‑mail/SMS przy logowaniu spoza znanych lokalizacji.
Ograniczenie hałasu NMEA i stabilność autopilota
Jeśli ploter „pływa” i gubi dane, zwykle winny jest nadmiar ruchu i autodiscovery.
- Wyłącz broadcast/multicast, gdy aplikacja wspiera unicast; przypisz konkretne IP odbiorców strumieni NMEA.
- Ogranicz częstotliwość wysyłania ramek (np. wind/depth) do realnych potrzeb; nie dubluj tej samej telemetrii z kilku źródeł.
- Panel WWW bramki: inny port niż domyślny, hasło z menedżera haseł, dostęp tylko z VLAN ADMIN.
Reakcja awaryjna na wodzie: co zrobić, gdy „coś” przejmuje kurs
Nie ma czasu na forach – trzeba odzyskać sterowność i świadomość sytuacyjną.
- Odłącz Wi‑Fi bramki NMEA (fizyczny przełącznik/wyłącz zasilanie modułu), przejdź na ręczne sterowanie i nawigację z redundancji (drugi GPS, tablet offline, papier).
- Zrestartuj router i ploter w tej kolejności; po restarcie sprawdź, czy GUEST nadal jest odseparowany.
- Na ploterze sprawdź źródło danych pozycji i kursu. Wybierz lokalny GPS (wbudowany/na USB), wyłącz na chwilę strumienie NMEA z sieci.
- Jeśli autopilot „wariuje”: odłącz wejście NMEA do pilota (fizyczna wtyczka/bezpiecznik linii danych) i prowadź ręcznie, dopóki nie ustalisz winnego urządzenia.
- W routerze tymczasowo zablokuj całe połączenia przychodzące oraz dostęp SSID GUEST; przywracaj stopniowo i obserwuj, co wywołuje problem.
- Po opanowaniu sytuacji zachowaj logi (router, bramki, ploter) na nośniku; krótka notatka czasu i objawów później ułatwi diagnozę.
Polityka załogi i gości: zasady BYOD, które nie psują rejsu
Najczęściej zawodzi dyscyplina urządzeń osobistych. Krótkie zasady ustne na odprawie działają lepiej niż długie PDF‑y, ale muszą być konkretne.
- Jedno Wi‑Fi dla gości (GUEST) bez widoczności urządzeń; brak haseł do sieci NAV i SERWIS poza skipperem/technikiem.
- Zakaz hotspotów z telefonów – mieszają segmentację i otwierają boczne drogi do paneli WWW. Prosty sygnał: „hotspoty OFF od wyjścia do powrotu do mariny”.
- Aplikacje mapowe na tabletach: tryb offline, bez autoprzesiadek przez losowe Wi‑Fi portowe; automatyczne aktualizacje wyłączone na morzu.
- Jeśli ktoś musi administrować (zespół techniczny) – konto imienne, dostęp tylko przez VPN i krótkie okna czasowe.
Mit: „im więcej aplikacji żeglarskich, tym lepiej”. Rzeczywistość: trzy apki walczące o ten sam strumień NMEA to chaos i lagi; wybierz jedną główną i jedną zapasową offline.
Pułapki portowe: sieci mariny i cudze kable
Najwięcej incydentów zdarza się… na kei. Portowe Wi‑Fi z captive portalem „przestawia” DNS, a niektóre pedestale oferują Ethernet o nieznanej izolacji.
- Internet z mariny zawsze wpuszczaj tylko do WAN Twojego routera. Nigdy bezpośrednio do przełącznika z urządzeniami NAV/SERWIS.
- Wyłącz „Auto‑join” dla SSID mariny na urządzeniach administracyjnych. Jeden skok na obce DNS‑y i panele WWW potrafią otworzyć sesje bez certyfikatu.
- Filtruj ruch wychodzący z NAV do białej listy adresów (NTP, pogoda). W marinie pojawia się mnóstwo multicastów, które zalewają bramki.
Przykład z praktyki: kamera P2P po podpięciu do LAN mariny utrzymywała stały tunel do chmury – ściągała przepustowość i generowała setki połączeń dziennie. Po przeniesieniu do strefy SERWIS i zablokowaniu ruchu do chmury – cisza i stabilny ploter.
Wybór sprzętu i dostawców: kryteria „secure‑by‑design”
Specyfikacje marketingowe nie mówią o tym, jak długo urządzenie będzie bezpieczne. Pytaj wprost i szukaj tych cech:
- Polityka aktualizacji z okresem wsparcia (min. 3–5 lat) i publiczny changelog. Brak deklaracji = problem za dwa sezony.
- Dostęp lokalny bez chmury, możliwość wyłączenia P2P, konta imienne i role. Jedno „admin/admin” to zaproszenie na pokład.
- Obsługa VLAN, klient VPN, logi z exportem (syslog/USB). Bez logów diagnoza w porcie trwa dłużej niż tankowanie w sztormie.
- Odporność EMC i sensowne zasilanie: separacja galwaniczna, PoE na kamery, bezpieczniki na liniach danych NMEA2000.
- Otwarte protokoły (NMEA, Modbus) – tak, ale z kontrolą: możliwość ograniczenia ról/zakresów i wyłączenia autodiscovery.
Mit: „urządzenia premium są z definicji bezpieczne”. Rzeczywistość: zdarzają się drogie plotery z panelem HTTP bez szyfrowania. Wybór rób po testach i lekturze forów technicznych, nie katalogu.
Tryb „offline‑first” na długie przeloty
Internet bywa kapryśny, a autopoprawki w złym momencie szkodzą bardziej niż brak danych. Na ocean czy długie przejścia przygotuj profil pracy bez stałego łącza:
- Mapy i pogoda pobrane wcześniej, aktualizacje automatyczne wyłączone, NTP z GPS.
- Router z regułą: NAV bez ruchu do Internetu, wyjątek tylko dla zaplanowanego okna pogodowego przez proxy.
- Plan B zasilania: oddzielny obwód dla ploter/bramka i mały UPS DC. Gwałtowny zanik napięcia to najczęstszy „brick” po update.
Rejestrowanie i dowody po incydencie: minimum operacyjne
Bez śladów trudno udowodnić, co naprawdę się stało. Nie trzeba SIEM‑a – wystarczy prosty zestaw na jacht:
- Włącz logi na routerze i bramkach, rotacja na pamięć USB/kartę; synchronizacja czasu z GPS.
- Znacznik zdarzenia: krótka notatka w dzienniku z czasem i objawami. Potem łatwiej korelować z logami.
- Po incydencie nie resetuj od razu do fabryki. Najpierw zrób zrzut konfiguracji i kopię logów, dopiero potem sprzątanie.
Najczęstsze błędy wdrożeniowe, których lepiej unikać
- Łączenie wszystkiego w jeden switch „bo działa szybciej”. Działa – do pierwszego burzyku ramek lub pętli.
- Port‑forward do kamer lub bramek „na chwilę”. Te „chwile” zostają w Internecie na długo – boty skanują non stop.
- Aktualizacje „po trochu” bez kopii i z wyłączonym zasilaniem brzegowym. Jeden zanik i masz cegłę zamiast bramki.
- Hasła zapisane na naklejce przy panelu. W marinie to otwarte zaproszenie.
Decyzja na ten sezon: krótki plan wdrożenia
Jeśli trzeba wybierać, zrób to w tej kolejności:
- Segmentacja sieci i izolacja GUEST, wyłączenie UPnP/WPS, brak port‑forwardów.
- Stabilne zasilanie dla krytycznych urządzeń + kopie konfiguracji.
- Procedura aktualizacji i tryb offline‑first na dłuższe odcinki.
- Regulamin BYOD dla załogi i dostęp serwisowy wyłącznie przez VPN.
- Wymiana urządzeń EOL lub odcięcie ich do strefy SERWIS bez drogi do NAV.
Jedna dobrze wdrożona zmiana robi więcej niż pięć półśrodków. Zacznij od architektury i prądu, reszta przestaje wtedy „falować”.
Bezpieczeństwo systemów energii: BMS, inwertery i ładowanie z kei
Gdy prąd faluje, elektronika zaczyna „dziwnie się zachowywać”, a zdalne przełączniki potrafią wyłączyć krytyczne obwody w najmniej wygodnym momencie. Źródłem kłopotów bywa integracja BMS/inwerterów z siecią pokładową bez kontroli dostępu.
- Oddziel strefę ENERGIA (POWER) od NAV i GUEST. Inwerter, ładowarki, BMS i monitor akumulatorów w osobnym VLAN/portach przełącznika – dostęp wyłącznie z konta ADMIN.
- Tryb tylko-do-odczytu dla paneli WWW i aplikacji. Sterowanie (on/off, progi, profile) dostępne jedynie przez VPN i konta imienne.
- Wyłącz chmury P2P producentów, jeśli jest lokalny dostęp. Zostaw telemetrykę do Twojego serwera (VPN), a nie do publicznego brokera.
- Modbus/RS‑485/CAN tylko z białą listą: pozwól wybrane adresy i funkcje (odczyt), zablokuj zapisy spoza segmentu SERWIS.
- Izolacja galwaniczna na liniach danych i dedykowane bezpieczniki na NMEA2000/RS‑485. Jedna pętla masy i zrobisz „reboot” ładowarce przy każdym skoku napięcia.
- Alarmy napięcia/prądu przez e‑mail/SMS z Twojego serwera VPN, nie z aplikacji w chmurze – mniej fałszywych powiadomień w marinie.
Mit: „panel producenta w chmurze jest najwygodniejszy”. Rzeczywistość: wygodny, dopóki captive portal mariny nie utnie sesji – wtedy aplikacja nie steruje niczym, a lokalny panel by zadziałał.
Krótki przykład: po podpięciu do słupa zasilającego ładowarka zaczęła losowo przełączać profil. Winny – włączony zdalny „Assist” z chmury. Po przejściu na dostęp lokalny przez VPN i blokadzie zapisów Modbus – koniec nocnych niespodzianek.
Test odcięcia sieci: czy jacht działa bez Internetu
Zanim wyjdziesz, sprawdź, co się stanie, gdy WAN zgaśnie. Ten 10‑minutowy test ujawnia zależności, które w sztormie kosztują nerwy.
- Odłącz WAN na routerze. Sprawdź: ploter widzi GPS lokalny, autopilot dostaje kurs, a mapy i AIS lokalny działają bez chmury.
- Otwórz panele WWW urządzeń z VLAN ADMIN – powinny być osiągalne bez Internetu i z ważnym certyfikatem lokalnym (lub przez VPN).
- Sprawdź, czy bramka NMEA nie „wisi” przy braku NTP. Jeśli tak – ustaw NTP z GPS lub zegar lokalny w routerze.
- Przejdź aplikacje mobilne w tryb offline. Te, które bez sieci gubią uprawnienia do GPS/kompasu – skreśl z listy „główne”.
Mit: „w trybie samolotowym nie działa GPS”. Rzeczywistość: na wielu urządzeniach GPS działa po ręcznym włączeniu lokalizacji – sieci wyłączone, pozycja zostaje.
Wniosek operacyjny: jeśli coś nie działa offline w porcie, na fali będzie gorzej. Zamień to na rozwiązanie z kontrolą lokalną.
Standard dla floty: powtarzalność zamiast niespodzianek
Przy rotacji załóg liczy się przewidywalność. Mniej „kreatywnych” konfiguracji, więcej obrazów wzorcowych i krótkich procedur.
- Golden image dla routera i bramek: wersja firmware zablokowana (pinning), szablon VLAN/SSID, gotowe reguły zapory, lista dozwolonych hostów.
- Repozytorium konfiguracji per jacht (chmura prywatna/ git w biurze) + kopia na szyfrowanym pendrive w sejfie portowym.
- MDM na tablety załogi: profil kiosk (nawigacja + pogoda), auto‑join OFF, aktualizacje tylko w oknie serwisowym, zdalne czyszczenie po rejsie.
- Unikalne SSID i hasła per jacht; GUEST izolowany, harmonogram włączania (noc: off). WPA3, a jeśli kompatybilność wymusza WPA2 – z krótką rotacją haseł.
- Check‑out w sobotę: eksport logów, zrzut konfiguracji, szybki skan portów urządzeń krytycznych i reset haseł GUEST.
Czego unikać: łatanie „po bohatersku” w dniu wydania czarteru, mieszania modeli routerów w jednej flocie i jednorazowych wyjątków „na szybko”, które nikt nie dokumentuje.
Aplikacje mobilne na mostku: minimum uprawnień, maksimum przewidywalności
Telefony i tablety to nowy wektor awarii – nie tylko ataków. Zbyt agresywne oszczędzanie energii i auto‑przełączanie Wi‑Fi potrafią „dławić” dane NMEA.
- Wyłącz auto‑join i przełączanie na „lepsze” Wi‑Fi. Tablet nawigacyjny łączy się tylko z SSID NAV.
- Uprawnienia „lokalizacja tylko podczas użycia” dla aplikacji zapasowych; aplikacja główna może mieć stały dostęp – inaczej traci fix przy wygaszonym ekranie.
- Oszczędzanie baterii – wyjątek dla nawigacji i AIS; w przeciwnym razie system ubije proces w tle przy zwrocie.
- Bluetooth: parowanie tylko znanych sensorów, widoczność urządzenia OFF. Atak to nie film – to aplikacja fitness skanująca mostek.
- Zakaz sideloadu i „modowanych” apk. Jedna zła biblioteka reklamowa i masz ruch do 20 domen w tle.
Mit: „im więcej aplikacji tym lepsza redundancja”. Rzeczywistość: trzy apki śledzące ten sam strumień NMEA to ryzyko kolizji i opóźnień; lepiej jedna główna, jedna offline w zapasie.
Szybki audyt po montażu: 15 minut prawdy
Po każdej zmianie instalacji zrób krótki przegląd. Nie szukaj piękna – szukaj otwartych drzwi i pętli.
- Sprawdź, czy żaden panel WWW nie jest dostępny z GUEST. Jeśli tak – reguła zapory i przeniesienie do VLAN ADMIN.
- Przeskanuj lokalnie otwarte porty urządzeń krytycznych (ploter, bramka, kamera). Nie potrzebne – wyłącz usługę.
- Autodiscovery OFF tam, gdzie można; unicast z przypisanym IP zamiast broadcastów.
- Weryfikacja haseł i kont: brak „admin/admin”, konta imienne dla serwisu, 2FA tam, gdzie wspierane.
