Cyberbezpieczeństwo OT to dziś zwykła praca utrzymania ruchu, a nie temat dla działu IT. Sterownik PLC w domyślnej konfiguracji odpowiada każdemu, kto go zapyta, i nie zapisuje, kto się z nim łączył. W tym wpisie pokazujemy, co widać na otwartym sterowniku Siemens S7, jak wygląda przejęcie wyjść skryptem Put/Get i jakie ustawienia w TIA Portal zamykają te drzwi.
Materiał powstał na bazie webinaru ControlByte z Ireneuszem Wyżykowskim z firmy Bezdram, która zajmuje się audytami sieci OT, segmentacją, monitoringiem i obsługą incydentów.
Dlaczego sterownik PLC jest realnym celem ataku
W sieci biurowej każdy serwer ma konta, logi i politykę haseł. W hali bywa inaczej. Sterownik stoi w szafie od dziesięciu lat, ma otwarty port 102 i nikt nigdy nie założył na nim użytkownika. Dlatego sieć OT bywa nazywana ziemią niczyją: formalnie należy do automatyki, a w praktyce nikt nie odpowiada za jej bezpieczeństwo. Cyberbezpieczeństwo OT zaczyna się więc od ustalenia, kto jest właścicielem tej warstwy.
Warto podkreślić jedną rzecz. Opisane dalej zachowania sterowników S7-300, S7-1200 i S7-1500 nie są luką. To domyślne ustawienia, które przez dwadzieścia lat nikomu nie przeszkadzały, bo sieć przemysłowa była odcięta od świata. Dziś ta sama sieć ma router z kartą SIM, zdalny dostęp integratora i system BMS od zewnętrznej firmy.
Trzy incydenty, jeden wspólny mianownik
- Sieć energetyczna na Ukrainie. Napastnicy mieli dostęp do systemu SCADA i ręcznie, jeden po drugim, wyłączali rozdzielnie. Setki tysięcy ludzi bez prądu w środku zimy.
- Oldsmar na Florydzie, 2021. Ktoś połączył się przez TeamViewer na stację operatorską i podniósł dawkę ługu sodowego w uzdatnianiu wody. Atak udaremnił operator, który zauważył, że kursor myszy sam się rusza.
- Atak z użyciem Tritona. Celem nie była produkcja, tylko przemysłowy system bezpieczeństwa, czyli warstwa chroniąca ludzi.
W każdym z tych przypadków zawinił niezabezpieczony dostęp zdalny, a nie złamane szyfrowanie. To dobra wiadomość, ponieważ akurat ten element da się naprawić własnymi siłami.
Jak wyglądał atak na elektrociepłownię
Na webinarze omówiliśmy incydent w polskiej elektrociepłowni, w wyniku którego około 50 tysięcy mieszkańców mogło zostać bez ciepła i wody. Przebieg był prosty i dlatego pouczający.
- Wejście. Napastnik wszedł przez router brzegowy z otwartym APN operatora.
- Pierwszy przyczółek. Podłączył się do sterownika Wago, który ma domyślnie aktywny serwer WWW. Na urządzeniu zostały fabryczne dane logowania.
- Rekonesans. Z tego miejsca przeskanował sieć w poszukiwaniu sterowników S7-300, S7-1200 i S7-1500 z otwartym portem 102.
- Przejęcie. Sterowniki nie miały ochrony dostępu, więc napastnik pobrał z nich programy, a następnie wgrał własny projekt z zahasłowanym dostępem.
Efekt był taki, że dział utrzymania ruchu nie mógł się już połączyć własnym projektem. Sterowniki trzeba było wyczyścić, a cały obiekt przeszedł w stan stop. Zwróć uwagę, że najsłabszym ogniwem nie był sterownik Siemensa, tylko zapomniane urządzenie obok niego.
Co widać na niezabezpieczonym sterowniku
Na stanowisku demonstracyjnym pokazaliśmy, jak zachowuje się S7-1200 bez konfiguracji zabezpieczeń. Odpytany sterownik sam podaje swoją tożsamość: typ CPU, numer seryjny i numer producenta. Dla osoby z zewnątrz to gotowa lista podatności do sprawdzenia.
Port 102 i S7 Communication
Natywny protokół S7 na porcie 102 nie pyta o tożsamość. CPU odpowiada każdemu, kto użyje właściwej składni. W wersji Legacy ruch leci otwartym tekstem, więc sonda na switchu zobaczy nawet hasło do CPU przesyłane w transmisji. Ani panel, ani programator nie wie, z kim naprawdę rozmawia.
Mechanizm Put/Get
Najbardziej obrazowa część webinaru. Kilkadziesiąt linii skryptu na zwykłym komputerze wystarczyło, żeby sterować wyjściami sterownika i zapalać je po kolei. Bez TIA Portal i bez dostępu do projektu. Funkcja get pozwala dodatkowo czytać markery i bloki danych, czyli najpierw rozpoznać, co w ogóle warto nadpisać.
Problem polega na tym, że Put/Get jest wykorzystywany w wielu działających aplikacjach. Zanim go wyłączysz, sprawdź, czy nie korzysta z niego istniejąca komunikacja.
Pozostałe otwarte usługi
- Serwer WWW w nowszych CPU potrafi odczytywać i zapisywać tagi. Dostęp warto ograniczyć do konkretnych użytkowników.
- Modbus TCP powstał w 1979 roku i z założenia nie ma uwierzytelniania ani szyfrowania. W konfiguracji bloku serwera łatwo przez nieuwagę udostępnić wyjścia do zapisu.
- PROFINET RT działa w drugiej warstwie, bez logowania i bez szyfrowania. Sieć polową trzeba więc izolować, a nie zabezpieczać hasłem.
Jak podnieść cyberbezpieczeństwo OT po stronie sterownika
Dobra wiadomość jest taka, że większość pracy nad cyberbezpieczeństwem OT wykonasz w TIA Portal, bez kupowania nowego sprzętu.
UMAC zamiast czterech poziomów dostępu
Wcześniej mieliśmy Access Levels, czyli cztery poziomy dostępu z przypisanymi hasłami. Od TIA Portal V19 dostępny jest UMAC, czyli User Management Access Control. Zamiast jednego hasła konfigurujesz użytkowników i role: osobno dla serwisu, administracji, technologa i dla użytkownika anonimowego. Każda rola dostaje własne uprawnienia inżynierskie i runtime.
Know-how protection i copy protection
Know-how protection hasłuje konkretne bloki w projekcie, więc przy uploadzie trzeba podać hasło. Copy protection wiąże bloki z numerem seryjnym karty pamięci lub sterownika. Dzięki temu skopiowana karta nie uruchomi programu na innej maszynie. Oba mechanizmy odpowiadają na pytanie, które w razie incydentu pada jako pierwsze: czy program w CPU to na pewno nasz program.
Secure PG/HMI i Syslog
Bezpieczna komunikacja PG/HMI szyfruje połączenie między TIA Portal, panelem i CPU oraz uwierzytelnia strony certyfikatami. Wymaga TIA Portal w wersji V17 lub nowszej oraz odpowiedniego firmware CPU, więc sprawdź wersję w dokumentacji swojego modelu.
Równie ważny jest Syslog. Sterowniki S7-1200 i S7-1500 z odpowiednim firmware prowadzą log systemowy zdarzeń bezpieczeństwa oraz zmian programu i firmware. Log możesz wysyłać na zewnętrzny serwer. Wtedy podmiana programu zostawia ślad poza samym sterownikiem i nikt nie musi zgadywać, czy to była akcja serwisowa, czy włamanie.
Kolejność prac
- Sprawdź, co komunikuje się z twoją maszyną.
- Zrób kopię zapasową i porównaj ją z aktualną konfiguracją CPU. Przyda się tu wersjonowanie projektu TIA Portal.
- Załóż konta i role, włącz ochronę dostępu.
- Dodaj know-how protection i powiązanie z kartą pamięci.
- Zamknij zbędne usługi i włącz bezpieczną komunikację, jeśli sprzęt na to pozwala.
Segmentacja i monitoring, czyli cyberbezpieczeństwo OT po stronie sieci
Zanim zaczniesz segmentować, musisz wiedzieć, co w sieci w ogóle jest. Automatycy często nie mają pojęcia o urządzeniach, które pojawiły się przez lata przy kolejnych modernizacjach.
Inwentaryzację rób pasywnie
Aktywny skan potrafi wyłożyć starszy sterownik i przestawić go w stop. Dlatego ruch nasłuchuje się pasywnie, na porcie SPAN lub TAP na switchu. Taki nasłuch nie wysyła żadnych pakietów, więc nic nie może pójść źle. Do analizy wystarczą darmowe narzędzia: Wireshark z dekoderami S7, Modbus i PROFINET albo Malcolm, czyli otwarty zestaw przygotowany pod ruch przemysłowy.
Pamiętaj o ograniczeniu. Sonda widzi sesje i metadane, czyli kto z kim rozmawia. Nie pokaże treści przesyłanych danych.
Gdzie postawić sondę
Model stref i kanałów z normy IEC 62443 dzieli zakład na warstwy: od sieci biurowej, przez przemysłową strefę DMZ i nadzór SCADA, aż po sterowanie. Jeśli nie możesz monitorować wszystkiego naraz, trzymaj się priorytetów:
- Kanały między strefami, zwłaszcza granica DMZ i nadzoru.
- Zdalny dostęp, czyli jump host integratora i każde łącze VPN.
- Najbardziej krytyczna linia produkcyjna.
Dwa ciche problemy
Pierwszy to pendrive przyniesiony do aktualizacji oprogramowania. Żaden firewall go nie zobaczy, bo nośnik omija sieć. Pomaga ochrona stacji końcowych i skanowanie nośników na wejściu do zakładu.
Drugi to systemy zarządzania budynkiem. Klimatyzacja czy HVAC bywa podpięta płasko do sieci zakładu przez integratora, który nie myślał o cyberbezpieczeństwie. Jeden z naszych kursantów opisywał właśnie atak na system HVAC w szpitalu. Dlatego żadne pojedyncze narzędzie nie załatwi sprawy: potrzebna jest ochrona stacji końcowych, nasłuch sieci i segmentacja naraz.
Pierwsza godzina od incydentu
Incydentem w OT jest nowe nierozpoznane urządzenie w strefie sterowania, połączenie spoza listy stacji inżynierskich, zmiana programu poza oknem serwisowym albo ruch na porcie 102, 502 czy 48898 w kierunku, w którym nie powinno go być.
- Pierwsze 10 minut. Potwierdź, że to incydent, a nie awaria lub nieuzgodniona akcja serwisowa.
- Kolejne 15 minut. Zabezpiecz dowody: logi, dane z sondy, aktualny program i konfigurację. Rób to ostrożnie, bo nieudana próba zrzutu potrafi zatrzeć ślady.
- Kolejne 20 minut. Powiadom kierownictwo.
- Na koniec. Zaplanuj przywrócenie sprawdzonej kopii, żeby skrócić przestój.
NIS2 i obowiązki zakładu
Jeśli twoja firma działa w sektorze objętym dyrektywą NIS2, ma obowiązek zarządzać ryzykiem cyberbezpieczeństwa także w sieci OT, a nie wyłącznie w IT, oraz zgłaszać incydenty w wyznaczonych terminach. Harmonogram wdrożenia w Polsce wygląda tak:
- 3 kwietnia 2026. Weszła w życie ustawa o krajowym systemie cyberbezpieczeństwa.
- 3 października 2026. Minął termin zgłoszenia się do wykazu podmiotów objętych NIS2.
- 3 kwietnia 2027. Systemy i procedury muszą być zgodne z ustawą.
- Koniec kwietnia 2028. Zaczynają się pierwsze audyty podmiotów kluczowych.
Terminy i zakres obowiązków zmieniają się wraz z kolejnymi aktami wykonawczymi, dlatego sprawdzaj je u źródła. Aktualne komunikaty publikuje CERT Polska, a ostrzeżenia dotyczące konkretnych sterowników i systemów przemysłowych znajdziesz w biuletynach CISA.
Jeśli chcesz przejść przez temat po kolei, od wymagań normy po konfigurację sprzętu, zajrzyj do kursu Cyberbezpieczeństwo przemysłowe zgodne z NIS2. Jeśli dopiero układasz sobie pracę z CPU i TIA Portal, sprawdź nasz kurs programowania PLC w języku LAD/FBD.
Checklista do wykonania w tym tygodniu
Cyberbezpieczeństwo OT nie zaczyna się od zakupu systemu. Zacznij od sześciu rzeczy, które sprawdzisz na istniejącej instalacji.
- Sprawdź, czy twoje CPU ma założonych użytkowników i role.
- Zweryfikuj, czy Put/Get jest naprawdę potrzebny w twojej aplikacji.
- Przejrzyj konfigurację bloku serwera Modbus pod kątem udostępnionych wyjść.
- Włącz Syslog i wyślij go na zewnętrzny serwer.
- Policz, ile urządzeń w twojej sieci ma fabryczne hasło.
- Ustal, kto i przez jakie łącze ma zdalny dostęp do linii.
Podobny sposób myślenia, czyli najpierw dane, potem wniosek, stosujemy też przy diagnostyce awarii z agentem AI.
Cyberbezpieczeństwo OT - najczęściej zadawane pytania
Czy wyłączenie Put/Get zepsuje moją aplikację?
Może, jeśli korzysta z niego istniejąca komunikacja z innym sterownikiem lub systemem nadrzędnym. Najpierw sprawdź pasywnym nasłuchem, co faktycznie łączy się z CPU, a dopiero potem zmieniaj ustawienia.
Czy otwarty port 102 to luka w sterownikach Siemensa?
Nie. To domyślne ustawienie, które przez lata nie stanowiło problemu, bo sieci przemysłowe były odseparowane. Dziś ten sam domyślny stan jest ryzykiem, więc trzeba go świadomie zmienić.
Skąd mam wiedzieć, kto łączył się z moim CPU?
Bez założonych użytkowników sterownik tego nie zapisuje. Po włączeniu kont i Syslogu zdarzenia bezpieczeństwa oraz zmiany programu trafiają do logu, który warto wysyłać na zewnętrzny serwer.
Od czego zacząć cyberbezpieczeństwo OT w małym zakładzie?
Od inwentaryzacji. Zrób pasywny nasłuch ruchu, wypisz urządzenia i połączenia, a następnie zmień fabryczne hasła i ogranicz zdalny dostęp. Segmentację planuj dopiero na podstawie tej listy.
