Jak sprawdzić czy sterowniki są wystawione do sieci? Shodan i testowanie branży przemysłowej
Tagi:  pentestypentesting

Jak sprawdzić czy sterowniki są wystawione do sieci? Shodan i testowanie branży przemysłowej

Sprawdź, jak za pomocą Shodana wykrywać wystawione sterowniki przemysłowe i analizować bezpieczeństwo systemów. Poradnik testów sieciowych.

Shodan i sprawdzanie wystawionych sterowników na świat: czyli jak zgubić własne ICS w internecie

Materiał ma charakter edukacyjny. Wszystko, co tu pokazuję, testuj wyłącznie na własnym sprzęcie albo za pisemną zgodą właściciela, jak w Minecrafcie: we własnym świecie, nie na cudzym serwerze. W Polsce sam nieuprawniony dostęp do systemu jest karalny (art. 267 i następne k.k.), a prywatność nie istnieje, bo logi u dostawcy, fingerprint, NASK i CBZC prędzej czy później Cię znajdą. To nie jest porada prawna.


Ze wszystkiego, co Shodan widzi otwarte, najgorsza kategoria to systemy sterowania przemysłowego. Bo tu „otwarty port" nie oznacza wycieku tabelki z bazy. Oznacza sterownik, który zarządza prądem, wodą albo ciepłem, i który właśnie odpowiada na zaczepki całego internetu. To jest ten moment, w którym rekonesans przestaje być ćwiczeniem, a zaczyna być sprawą bezpieczeństwa.


Jedna rzecz na wstępie, ważniejsza niż zwykle: w przypadku ICS robimy wyłącznie pasywne rozpoznanie, czyli czytamy to, co Shodan już zebrał. Nie wysyłamy do tych urządzeń żadnych komend. Protokoły przemysłowe w bazowej formie często nie mają uwierzytelniania, więc „sprawdzenie" zapisu to nie test, tylko realna ingerencja w proces fizyczny. Od czytania banera nikomu nie zgaśnie światło. Od wysłania ramki Modbus już może.

Dlaczego ICS w ogóle wisi w internecie

Nikt nie projektuje sterownika z myślą „wystawmy go na świat". A jednak wiszą, i to z powtarzalnych, ludzkich powodów.


Najczęstszy to zdalny serwis. Ktoś potrzebował dostać się do HMI albo PLC z domu czy od integratora, więc wystawił dostęp „na chwilę, do diagnostyki", przez przekierowanie portu, RDP, VNC albo publiczny adres. Chwila się przedłużyła do kilku lat. Drugi powód to brak segmentacji: sieć IT i OT siedzą razem, płasko, bez firewalla między nimi, więc to, co miało być w odizolowanej strefie procesowej, jest o jeden routing od internetu.

Do tego dochodzi mentalność utrzymania ruchu. W świecie OT priorytetem jest dostępność, nie poufność. „Działa, to nie ruszaj" jest racjonalne, gdy zatrzymanie linii kosztuje fortunę, ale fatalne, gdy oznacza niezmienione domyślne hasło przez dekadę. No i legacy: sprzęt bez wsparcia, firmware, którego nie da się załatać, protokoły zaprojektowane w czasach, gdy „sieć" znaczyła kabel w zamkniętej hali. Całość spina jedno błędne założenie, że skoro nikt nie zna naszego adresu, to jesteśmy bezpieczni. Shodan istnieje właśnie po to, żeby to założenie obalić.

Protokoły, które zdradzają

Sterownik nie krzyczy „jestem elektrownią". Zdradza go protokół, którym mówi, a każdy ma swój domyślny port:

  • Modbus/TCP (502) to dziadek automatyki przemysłowej, wszechobecny i z natury bez uwierzytelniania
  • DNP3 (20000) to protokół smart grid, używany głównie w utilities, czyli elektroenergetyce i wodociągach
  • IEC 60870-5-104, w skrócie IEC-104 (2404) to standard telemechaniki sieci elektroenergetycznych, mocno europejski
  • IEC 61850 MMS, ICCP oraz Siemens S7 (102) to automatyka stacji i komunikacja między centrami sterowania
  • EtherNet/IP (44818), Niagara Fox (1911 i 4911), OPC UA (4840) to kolejne podejrzane, a BACnet (47808) to raczej automatyka budynkowa

I tu uwaga, która oddziela kogoś, kto rozumie temat, od kogoś, kto przepisał listę portów: port 102 dzielą naraz Siemens S7, IEC 61850 i ICCP, a wiele protokołów chodzi na kilku portach. Dlatego klasyfikacja po samym numerze portu jest zawodna. Shodan nie zgaduje po porcie, tylko parsuje baner, więc to w banerze, nie w numerze, siedzi prawdziwa identyfikacja urządzenia.

Jak to wygląda w Shodanie

Pasywne rozpoznanie zaczynasz od portu protokołu, zawężonego do interesującego obszaru:

port:502 country:PL
port:2404 country:PL
port:20000

Dla sterowników Shodan często wyciąga z banera konkretne dane: identyfikator urządzenia Modbus, informacje o module przy S7, vendora, model, czasem wersję firmware. To znaczy, że już z samego rekordu wiesz, z czym masz do czynienia, bez wysyłania czegokolwiek. Shodan utrzymuje też dedykowane narzędzia do ekspozycji ICS, więc skalę problemu możesz oglądać zbiorczo, a nie rekord po rekordzie.

I na tym discovery się kończy. Czytasz baner, analizujesz ekspozycję, raportujesz. Nie nawiązujesz sesji protokołem przemysłowym, nie wysyłasz odczytów ani zapisów. Powtarzam to celowo, bo to jedyna granica, której w ICS naprawdę nie wolno przekroczyć ani z ciekawości, ani „żeby potwierdzić".

Najczęstsze błędy na produkcji

Jak już patrzysz na cudzą (albo własną) ekspozycję, te grzechy powtarzają się do znudzenia:

  • HMI albo panel SCADA wystawiony przez RDP (3389) lub VNC (5900) wprost na internet, regularnie z domyślnym albo słabym hasłem
  • port inżynierski sterownika (502, 102, 44818) widoczny publicznie, bo „tak było wygodniej serwisować"
  • zero VPN i zero jump hosta, dostęp do OT prosto z sieci publicznej
  • niezmienione domyślne poświadczenia producenta
  • webowy panel sterownika (na przykład Niagara) z fabrycznym loginem
  • płaska sieć, w której z firmowego Wi-Fi widać strefę procesową

Każdy z tych punktów z osobna jest błędem. Razem to instrukcja, jak oddać komuś kontrolę nad procesem fizycznym.

Jak nie trafić do tego nagłówka

Obrona nie jest egzotyczna, jest tylko rzadko wdrażana. Żaden element OT nie powinien mieć publicznego adresu, kropka. Zdalny dostęp wyłącznie przez VPN i jump host, nigdy goły port. Segmentacja IT od OT z prawdziwym firewallem pomiędzy, najlepiej w duchu modelu Purdue. Zmiana domyślnych haseł i wyłączenie nieużywanych usług. A na koniec monitoring własnej ekspozycji: ustaw alert Shodana na swoje zakresy (pokazywałam to w części o CLI i API), żeby dowiedzieć się o wystawionym sterowniku od narzędzia, a nie z wiadomości.


Dirty fact: to nie są hipotezy z prezentacji. Stuxnet uderzył w sterowniki Siemens S7. Industroyer, znany też jako CrashOverride, posłużył się dokładnie protokołami energetyki, w tym IEC-104 i IEC 61850, i stoi za realnym wyłączeniem prądu w Kijowie w 2016 roku. Triton celował w systemy bezpieczeństwa instalacji przemysłowej. Każdy z tych ataków zaczynał się od dostępu do tego, co miało być nieosiągalne.


W IT otwarty port to incydent. W energetyce to ryzyko, że ktoś zgasi światło całemu miastu. Dlatego mapę ekspozycji rób sumiennie, raportuj szybko, a palca od sterownika trzymaj z daleka. A na wschodniej flance, gdzie akurat mieszkamy, to nie jest rozważanie akademickie, tylko bieżący stan zagrożenia.

Marketing Manager
Autor artykułu
Marketing Manager
Oceń blog:
Czas czytania: 8 min
Data: 22.06.2026

Terminarz

prev

next

Lista najbliższych webinariów

24.11.2026
09:00 Autoryzowane szkolenie dotyczące konfiguracji i administracji rozwiązaniami WatchGuard
Autoryzowane szkolenie dotyczące konfiguracji i administracji rozwiązaniami WatchGuard
22.09.2026
10:00 Szkolenie: cyberbezpieczeństwo dla pracowników biurowych
Szkolenie: cyberbezpieczeństwo dla pracowników biurowych
23.06.2026
10:00 [ON-DEMAND] OXARI ITSM w praktyce – Service Desk, CMDB i automatyzacja procesów IT w jednej platformie PREMIERA 17.06.2026
[ON-DEMAND] OXARI ITSM w praktyce – Service Desk, CMDB i automatyzacja procesów IT w jednej platformie PREMIERA 17.06.2026
29.06.2026
10:00 PODCAST Włam się w Temat - Scroll, hejt, uzależnienie - dlaczego dzieci potrzebują cyfrowej ochrony? Gość: Mikołaj Sołtysik PREMIERA 29.06.2026
PODCAST Włam się w Temat - Scroll, hejt, uzależnienie - dlaczego dzieci potrzebują cyfrowej ochrony? Gość: Mikołaj Sołtysik PREMIERA 29.06.2026
newsletter
Chcesz wiedzieć więcej? Zapisz się na Newsletter i otrzymuj najnowsze informacje

Zobacz inne wpisy

Wiedza i świadomość na temat aktualnych cyberzagrożeń to podstawa dobrej taktyki bezpieczeństwa. Chcesz być na bieżąco z wydarzeniami ze świata cybersecurity? A może szukasz wskazówek jak zapewnić wyższy poziom cyberbezpieczeństwa w swojej firmie? Chcesz poznać topowe rozwiązania? Dobrze trafiłeś.

zobacz wszystkie wpisy
Wprowadzenie do Shodana, jak zacząć i jak działa Shodan? Monitorowanie i Reagowanie na Incydenty
Shodan po polsku - jak zacząć używać Shodana? Security Operation Center (SOC)
Stealer logs: kiedy jeden zainfekowany laptop kończy się ransomware Monitorowanie i Reagowanie na Incydenty
Testy Socjotechniczne: Symulacje Phishingu

Testy Socjotechniczne: Symulacje Phishingu

Sprawdź w kontrolowanych i bezpiecznych warunkach czy Twoi pracownicy są odporni na phishing i inne metody socjotechniczne. Obejmują one phishing e-mailowy, vishing (ataki telefoniczne) czy smishing (SMS), skupiając się na ludzkim czynniku w cyberbezpieczeństwie.

Wycena indywidualna
Zobacz więcej
Testy Penetracyjne Sieci

Testy Penetracyjne Sieci

Zapoznaj się z ofertą testy penetracyjnych sieci. Zabezpiecz infrastrukturę krytyczną przed atakami. Poznaj zagrożenia, podatności i luki. Na koniec otrzymasz szczegółowy raport z rekomendacjami.

Wycena indywidualna
Zobacz więcej
Testy Penetracyjne Aplikacji

Testy Penetracyjne Aplikacji

Testy penetracyjne aplikacji webowych to skuteczny sposób na ochronę stron internetowych, sklepów online i portali przed cyberatakami. Symulują ataki hakerskie, wykrywając luki w zabezpieczeniach, takie jak SQL Injection czy XSS, zanim wykorzystają je przestępcy.

Wycena indywidualna
Zobacz więcej