Jak zabezpieczyć publiczny broker Mosquitto MQTT: konfiguracja ACL i certyfikatu Let’s Encrypt

Wystawienie brokera Mosquitto na publicznym adresie IP to jeden z najczęstszych momentów krytycznych w projektach Internetu Rzeczy. Wystarczy uruchomić domyślną instalację na wirtualnym serwerze w chmurze i otworzyć standardowy port, aby w ciągu kilkunastu minut w logach systemowych pojawiły się pierwsze wpisy generowane przez automatyczne skanery sieciowe. Przeszukiwanie przestrzeni adresowej IPv4 w poszukiwaniu otwartych instancji protokołu MQTT odbywa się w sposób ciągły. Jeśli broker nie wymaga uwierzytelnienia, a transmisja danych odbywa się jawnym tekstem, infrastruktura staje się natychmiast podatna na przejęcie telemetrii, wstrzykiwanie fałszywych komend sterujących oraz ataki typu odmowa usługi. ^[2]

Zabezpieczenie brokera MQTT działającego w publicznym internecie nie sprowadza się jednak wyłącznie do włączenia szyfrowania. Wymaga ono precyzyjnego zdefiniowania granic zaufania, wdrożenia weryfikacji tożsamości urządzeń oraz rygorystycznego ograniczenia praw dostępu do poszczególnych tematów (topics). Zastosowanie bezpłatnych certyfikatów Let’s Encrypt w połączeniu z listami kontroli dostępu (ACL) w Mosquitto stanowi skuteczny, sprawdzony standard, ale niesie ze sobą specyficzne wyzwania operacyjne, zwłaszcza na styku z mikrokontrolerami i środowiskami wbudowanymi. ^[4]

Publiczny broker Mosquitto: kiedy ma sens, a kiedy lepiej go nie wystawiać

Decyzja o wystawieniu instancji Mosquitto bezpośrednio do sieci publicznej powinna wynikać z twardych uwarunkowań architektonicznych, a nie z dążenia do ułatwienia sobie pracy na etapie prototypowania. W środowiskach IoT panuje tendencja do przedwczesnego udostępniania usług na zewnątrz tylko po to, aby ominąć konfigurację tuneli lub lokalnych tras routingu. Tymczasem każdy otwarty port publiczny staje się trwałym elementem powierzchni ataku.

Publiczny dostęp nie oznacza anonimowego dostępu

W dyskusjach o architekturze sieciowej pojęcia „publiczny broker” i „otwarty broker” bywają błędnie utożsamiane. Broker publiczny to usługa nasłuchująca na publicznym interfejsie sieciowym (z publicznym adresem IP lub domeną), osiągalna z dowolnego węzła w internecie. Usługa otwarta (lub anonimowa) to taka, która akceptuje połączenia od dowolnego klienta bez weryfikacji poświadczeń i zezwala na subskrypcję lub publikację w pełnym drzewie tematów.

Wdrożenie bezpiecznego publicznego brokera zakłada bezwzględne odrzucenie anonimowości. Urządzenie łączące się przez internet musi przejść dwuetapową weryfikację: najpierw potwierdzić tożsamość serwera za pomocą certyfikatu x509 i bezpiecznie zestawić szyfrowany kanał TLS, a następnie uwierzytelnić się unikalnym loginem i hasłem. Ostatnim etapem jest kontrola autoryzacji realizowana przez mechanizm ACL, który ściśle określa, jakie operacje dany węzeł może wykonać.

Praktyka pokazuje, że publiczny adres IP rozwiązuje fundamentalne problemy z łącznością w projektach rozproszonych geograficznie. Kiedy urządzenia łączą się za pośrednictwem sieci komórkowych (LTE-M, NB-IoT), znajdują się za podwójnym lub potrójnym firewallem operatora (Carrier-Grade NAT). W takiej konfiguracji broker nie ma możliwości zainicjowania bezpośredniego połączenia do urządzenia. To mikrokontroler musi wyjść na zewnątrz i utrzymać długożyjące połączenie TCP. Jeśli cała infrastruktura telemetryczna opiera się na setkach stacji pogodowych czy instalacji fotowoltaicznych rozrzuconych po całym kraju, centralny punkt zborny osiągalny publicznie staje się koniecznością techniczną.

Scenariusze uzasadniające wystawienie brokera do internetu

Wystawienie brokera na świat jest uzasadnione przede wszystkim w systemach o wysokiej dynamice węzłów oraz w aplikacjach mobilnych. Można wyróżnić kilka sytuacji, w których próby ukrycia brokera za prywatnymi sieciami przynoszą więcej problemów operacyjnych niż korzyści:

• Floty pojazdów i systemy śledzenia zasobów (asset tracking): Moduły GPS/GSM przemieszczają się pomiędzy stacjami bazowymi różnych operatorów, regularnie tracą i odzyskują zasięg, a ich adresy IP wewnątrz sieci komórkowej zmieniają się nieprzewidywalnie. Utrzymywanie w takich warunkach stałych tuneli VPN na poziomie systemu operacyjnego bywa zbyt obciążające dla prostych modemów.
• Rozproszona telemetria przemysłowa i środowiskowa: Stacje pomiarowe instalowane w odległych lokalizacjach, gdzie jedynym medium transmisyjnym jest pasmo komórkowe, a urządzenia dysponują ograniczonym budżetem energetycznym (zasilanie bateryjne lub panele PV). Zestawianie pełnego tunelu IPsec lub WireGuard wymaga stałej wymiany pakietów kontrolnych, co uniemożliwia przejście mikrokontrolera w stan głębokiego uśpienia (deep sleep).
• Integracja z zewnętrznymi platformami chmurowymi (SaaS/PaaS): Kiedy dane z Mosquitto muszą być pobierane przez narzędzia analityczne działające w chmurze zewnętrznego dostawcy, brak publicznego punktu styku wymusza stosowanie skomplikowanych połączeń Site-to-Site VPN, co podnosi koszty i złożoność administracyjną.
• Urządzenia konsumenckie działające poza kontrolą administratora: Urządzenia smart home sprzedawane użytkownikom końcowym, którzy instalują je we własnych sieciach domowych za ruterami z dynamicznym IP, bez możliwości przekierowywania portów.

Sytuacje, w których publiczny broker jest błędem architektonicznym

Istnieje szeroka grupa wdrożeń, w których wystawienie brokera Mosquitto na świat zewnętrzny jest kardynalnym błędem sztuki. Dotyczy to w szczególności systemów automatyki budynkowej działających w obrębie jednej nieruchomości. Domowy czujnik temperatury, inteligentny przekaźnik czy miernik energii elektrycznej zainstalowany w rozdzielnicy nie mają żadnego uzasadnienia technicznego, by wymieniać komunikaty przez serwer ulokowany w zewnętrznym centrum danych, jeśli centrala zarządzająca (np. Home Assistant) znajduje się w tej samej sieci lokalnej. ^[3]

Równie niebezpieczne jest publikowanie brokera w sieciach przemysłowych (OT), gdzie sterowniki PLC realizują krytyczne zadania wykonawcze. Wystawienie magistrali sterującej na bezpośrednie oddziaływanie ruchu internetowego otwiera furtkę do sabotażu procesu technologicznego w przypadku jakiejkolwiek luki w implementacji stosu sieciowego brokera lub błędu ludzkiego w konfiguracji haseł. Jeśli pracownicy techniczni potrzebują zdalnego wglądu w parametry instalacji, znacznie bezpieczniejszym podejściem jest zastosowanie dedykowanej bramy dostępowej VPN lub architektury opartej na sieciach nakładkowych (ang. mesh overlay networks, takich jak Tailscale czy Netmaker).

Decyzja przed konfiguracją: model zagrożeń, architektura i minimalny zakres ekspozycji

Zanim na serwerze zostanie wygenerowany jakikolwiek plik konfiguracyjny, należy precyzyjnie zdefiniować wektory ataków, na które narażony będzie broker. Publiczne środowisko sieciowe charakteryzuje się ciągłym szumem: skanery badają otwarte porty, botnety sprawdzają domyślne dane logowania, a wyspecjalizowane narzędzia testują podatności na błędy przepełnienia bufora w oprogramowaniu sieciowym.

Pytania, które trzeba rozstrzygnąć przed otwarciem portu

Bezpieczeństwo systemu zależy od najsłabszego ogniwa. W przypadku architektury MQTT wąskim gardłem bardzo często nie jest sam serwer, lecz ograniczenia sprzętowe podłączonych do niego klientów. Przed przejściem do wdrożenia TLS i reguł autoryzacji należy udzielić jednoznacznych odpowiedzi na następujące pytania:

1. Czy wszystkie planowane urządzenia posiadają wystarczającą moc obliczeniową i pamięć RAM do obsługi kryptografii asymetrycznej? Podstawowe mikrokontrolery z rodziny AVR (np. starsze Arduino) nie są w stanie obsłużyć współczesnych szyfrów TLS 1.3 ani przetworzyć łańcucha certyfikatów RSA o długości klucza 2048/4096 bitów. W ich przypadku próba nawiązania sesji TLS skończy się wyczerpaniem pamięci operacyjnej lub restartem układu przez mechanizm watchdog. Nawet układy takie jak ESP8266 wymagają precyzyjnej alokacji pamięci na bufor SSL, podczas gdy nowocześniejsze platformy (ESP32, układy ARM Cortex-M4/M33 ze sprzętową akceleracją kryptografii) radzą sobie z tym zadaniem bez problemu.
2. W jaki sposób urządzenia weryfikują aktualny czas? Certyfikaty x509 wystawiane przez Let’s Encrypt mają ściśle określony czas ważności (90 dni). Jeśli mikrokontroler nie posiada podtrzymywanego bateryjnie zegara czasu rzeczywistego (RTC) i nie zsynchronizuje czasu przez protokół NTP przed nawiązaniem połączenia MQTT, uzna certyfikat za jeszcze nieważny lub przeterminowany, co uniemożliwi komunikację.
3. Czy architektura uwzględnia mechanizm bezpiecznej, zdalnej aktualizacji oprogramowania układowego (OTA)? Jeśli certyfikat główny urzędu certyfikacji (Root CA) ulegnie zmianie lub dojdzie do wycieku poświadczeń, konieczna jest możliwość szybkiej modyfikacji parametrów urządzeń w terenie. Brak mechanizmu OTA przy publicznym brokerze oznacza ryzyko trwałego odcięcia urządzeń od systemu.
4. Jaki jest charakter przesyłanych danych? Należy rozróżnić komunikację jednokierunkową o niskim priorytecie (okresowy odczyt wilgotności gleby) od komunikacji dwukierunkowej sterującej

   elementami wykonawczymi (np. elektrozaworami czy przekaźnikami zasilania). Przejęcie kanału telemetrycznego oznacza wyciek metadanych, jednak wstrzyknięcie fałszywych komend w kanale sterującym niesie bezpośrednie ryzyko uszkodzenia instalacji lub zakłócenia ciągłości procesów technologicznych.

Powszechnym uproszczeniem przy projektowaniu takiej architektury jest traktowanie szyfrowania TLS jako kompletnego rozwiązania kwestii bezpieczeństwa. Zaszyfrowanie sesji na porcie 8883 rozwiązuje jedynie problem podsłuchu danych w tranzycie i chroni przed atakami typu man-in-the-middle. Z perspektywy brokera ruch pochodzący od skompromitowanego węzła z poprawnie zestawioną sesją kryptograficzną jest wciąż w pełni zaufany, o ile system nie wymusza twardych reguł kontroli dostępu.

Minimalizacja ryzyka wymaga przyjęcia zasady separacji ról na poziomie sieciowym. Publicznie dostępny powinien być wyłącznie dedykowany listener TLS (standardowo port 8883 lub 443 w przypadku restrykcyjnych firewalli korporacyjnych), podczas gdy nieszyfrowany port 1883 musi pozostać całkowicie zablokowany na interfejsach zewnętrznych i przypisany wyłącznie do pętli zwrotnej (127.0.0.1) na potrzeby lokalnych integracji. Każda próba ułatwienia sobie pracy poprzez tymczasowe otwarcie surowego portu na świat kończy się

przechwyceniem wrażliwych poświadczeń przez automatyczne skanery sieciowe w ciągu zaledwie kilkunastu minut.

Fundament bezpiecznej instalacji Mosquitto: system, sieć i osobne listenery

Bezpieczeństwo brokera MQTT zależy w równym stopniu od konfiguracji samej usługi, co od higieny systemu operacyjnego, na którym została uruchomiona. Powszechną praktyką w środowiskach deweloperskich jest uruchamianie Mosquitto z domyślnym plikiem konfiguracyjnym, co od wersji 2.0 kończy się odrzucaniem połączeń spoza interfejsu localhost. Zamiast otwierać broker globalną dyrektywą listener 1883 0.0.0.0, należy precyzyjnie podzielić punkty wejścia zależnie od przeznaczenia ruchu.

Separacja interfejsów i izolacja portów

Prawidłowo skonfigurowany broker produkcyjny korzysta z co najmniej dwóch odrębnych listenerów. Pierwszy z nich obsługuje wyłącznie ruch wewnętrzny (np. lokalne usługi bazodanowe, backend aplikacji lub exportery metryk Prometheus), nasłuchując na pętli zwrotnej bez narzutu obliczeniowego związanego z TLS. Drugi dedykowany jest urządzeniom zewnętrznym i wymusza pełne szyfrowanie oraz autoryzację.

Minimalny, bezpieczny szkielet pliku /etc/mosquitto/mosquitto.conf powinien zawierać następujący podział ról:

# Globalne zasady bezpieczeństwa
per_listener_settings true

# Listener 1: Tylko lokalny dostęp nieszyfrowany (loopback)
listener 1883 127.0.0.1
allow_anonymous false
password_file /etc/mosquitto/local_passwd

# Listener 2: Publiczny punkt wejścia dla urządzeń zewnętrznych
listener 8883 0.0.0.0
allow_anonymous false
password_file /etc/mosquitto/external_passwd
acl_file /etc/mosquitto/external_acl

Kluczowym parametrem w powyższym listingu jest per_listener_settings true. Domyślnie Mosquitto stosuje reguły uwierzytelniania i autoryzacji globalnie. Włączenie tej flagi pozwala na całkowitą separację baz poświadczeń oraz list ACL pomiędzy interfejsem lokalnym a publicznym. Dzięki temu skompromitowanie konta używanego przez urządzenie brzegowe na zewnątrz nie daje automatycznie uprawnień do topiców administracyjnych obsługiwanych przez interfejs lokalny.

Reguły zapory sieciowej na poziomie hosta

Konfiguracja samej usługi nie zwalnia administratora z wymuszenia reguł na poziomie jądra systemu za pomocą zapory sieciowej (np. ufw lub surowego nftables). Zasada minimalnej ekspozycji oznacza, że port 1883 nie powinien mieć prawa odebrać żadnego pakietu z interfejsu publicznego, nawet jeśli Mosquitto omyłkowo zostanie przestawione na nasłuch globalny.

# Domyślna polityka blokowania ruchu przychodzącego
ufw default deny incoming
ufw default allow outgoing

# Zezwolenie na ruch administracyjny oraz szyfrowany MQTT
ufw allow 22/tcp
ufw allow 8883/tcp

# Zezwolenie na ruch HTTP na potrzeby walidacji Let's Encrypt
ufw allow 80/tcp

# Aktywacja reguł
ufw enable

Port 80 TCP jest w tym scenariuszu niezbędny wyłącznie do przeprowadzenia walidacji domeny w procesie odnawiania certyfikatów przez protokół ACME. Nie ma potrzeby uruchamiania na nim pełnego serwera WWW – mechanizm Let’s Encrypt może wykorzystać tryb tymczasowy (standalone), który podnosi miniserwer HTTP tylko na czas weryfikacji tożsamości węzła.

TLS z Let’s Encrypt: szyfrowanie połączenia bez fałszywego poczucia bezpieczeństwa

Wdrożenie powszechnie zaufanego certyfikatu Let’s Encrypt eliminuje konieczność ręcznego wgrywania certyfikatu własnego urzędu (ang. Self-Signed CA) na każde urządzenie klienckie. Standardowy łańcuch zaufania Let’s Encrypt (oparty na certyfikacie głównym ISRG Root X1) znajduje się w magazynach certyfikatów większości systemów wbudowanych, co ułatwia masowe wdrażanie urządzeń w terenie.

Jeśli chcesz pogłębić ten wątek, sprawdź też: Jak wdrożyć Private 5G w porcie morskim?.

Kiedy Let’s Encrypt ma sens, a kiedy rodzi problemy operacyjne

Wybór publicznego urzędu certyfikacji dla protokołu MQTT ma swoje jasne granice techniczne, które należy rozważyć przed automatyzacją wdrożenia:

• Warto wdrożyć Let’s Encrypt, gdy: urządzenia klienckie to komputery jednopłytkowe (Raspberry Pi), telefony, aplikacje przeglądarkowe przez WebSockets lub mikrokontrolery z regularnie aktualizowanym magazynem zaufanych certyfikatów CA w pamięci flash.
• Uważaj na Let’s Encrypt, gdy: infrastruktura opiera się na mikrokontrolerach z zaszytym „na sztywno” certyfikatem pośrednim lub gdy urządzenia mają rygorystyczne limity transferu danych komórkowych. 90-dniowy cykl rotacji certyfikatu w Let’s Encrypt wymusza ponowne pobieranie pełnego łańcucha przy renegocjacji sesji, co w przypadku taryf NB-IoT/LTE-M może zauważalnie zwiększyć koszty transmisji.
• Alternatywa dla mikrokontrolerów: Jeśli urządzenia są w 100% pod Twoją kontrolą i nie integrujesz się z aplikacjami firm trzecich, własne prywatne CA o 5- lub 10-letnim okresie ważności często okazuje się rozwiązaniem bezpieczniejszym operacyjnie, chroniąc przed przestojami wywołanymi rotacją kluczy publicznych urzędów.

Pobranie i montaż certyfikatu w Mosquitto

Aby wygenerować certyfikat dla brokera o przypisanej domenie (np. mqtt.twojadomena.pl), najprościej posłużyć się narzędziem certbot w trybie autonomicznym:

certbot certonly --standalone -d mqtt.twojadomena.pl

Pliki wygenerowane przez Let’s Encrypt trafiają do katalogu /etc/letsencrypt/live/mqtt.twojadomena.pl/, gdzie domyślnie dostęp do nich ma wyłącznie użytkownik root. Demon Mosquitto działa z uprawnieniami nieuprzywilejowanego użytkownika systemowego mosquitto, przez co nie może bezpośrednio odczytać klucza prywatnego (privkey.pem). Próba uruchomienia usługi w takiej konfiguracji zakończy się błędem uprawnień. ^[1]

Prawidłowe rozwiązanie polega na automatycznym kopiowaniu certyfikatu i klucza do wyznaczonego folderu Mosquitto przy użyciu skryptu powdrożeniowego Certbota (tzw. deploy hook). Należy utworzyć plik /etc/letsencrypt/renewal-hooks/deploy/mosquitto.sh o zawartości:

#!/bin/sh
set -e

DOMAIN="mqtt.twojadomena.pl"
TARGET_DIR="/etc/mosquitto/certs"

mkdir -p "$TARGET_DIR"
cp "/etc/letsencrypt/live/$DOMAIN/fullchain.pem" "$TARGET_DIR/fullchain.pem"
cp "/etc/letsencrypt/live/$DOMAIN/privkey.pem" "$TARGET_DIR/privkey.pem"

chown -R mosquitto:mosquitto "$TARGET_DIR"
chmod 700 "$TARGET_DIR"
chmod 600 "$TARGET_DIR"/*

# Bezprzerwowe przeładowanie certyfikatów w Mosquitto
systemctl reload mosquitto

Po nadaniu uprawnień do wykonania (chmod +x /etc/letsencrypt/renewal-hooks/deploy/mosquitto.sh), skrypt wykona się automatycznie przy każdym udanym odnowieniu certyfikatu przez Certbot, eliminując ryzyko wygaśnięcia szyfrowania.

Następnie konfigurujemy sekcję TLS dla publicznego listenera w mosquitto.conf:

# Parametry TLS dla publicznego portu 8883
listener 8883 0.0.0.0
certfile /etc/mosquitto/certs/fullchain.pem
keyfile /etc/mosquitto/certs/privkey.pem

# Wymuszenie bezpiecznych protokołów (blokada SSLv3, TLS 1.0, TLS 1.1)
tls_version tlsv1.2

# Bezpieczne zestawy szyfrów eliminujące podatności starszych implementacji
ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384

Uwierzytelnianie i ACL: jak ograniczyć klientom dostęp do właściwych topiców

Zaszyfrowany kanał komunikacyjny bez rygorystycznej kontroli dostępu stanowi otwarte zaproszenie do sabotażu danych. Domyślne zachowanie protokołu MQTT pozwala dowolnemu zalogowanemu użytkownikowi na subskrypcję tematu wieloznacznego (ang. wildcard) #, co umożliwia podsłuchanie całego strumienia zdarzeń w systemie, a także na wstrzykiwanie danych do cudzych kolejek.

Generowanie bezpiecznych poświadczeń

Mosquitto odrzuca zapis haseł otwartym tekstem. Do zarządzania kontami służy dedykowane narzędzie mosquitto_passwd, które haszuje hasła algorytmem PBKDF2 (lub SHA-512 w zależności od wersji biblioteki). Każde urządzenie w terenie musi posiadać unikalną parę login/hasło; stosowanie jednego „uniwersalnego” konta dla całej floty urządzeń uniemożliwia revocację uprawnień w przypadku kradzieży sprzętu bez konieczności rekonfiguracji pozostałych jednostek.

# Tworzenie nowej bazy haseł i dodanie pierwszego urządzenia
mosquitto_passwd -c /etc/mosquitto/external_passwd sensor_node_01

# Dodawanie kolejnych urządzeń do istniejącej bazy
mosquitto_passwd /etc/mosquitto/external_passwd sensor_node_02
mosquitto_passwd /etc/mosquitto/external_passwd backend_collector

Konstrukcja precyzyjnych reguł ACL

Listy kontroli dostępu (ACL) powinny być budowane według modelu zerowego zaufania (deny all by default). Jeśli reguła nie przyznaje wprost prawa do odczytu (read) lub zapisu (write), operacja jest blokowana przez broker. Dobrą praktyką architektoniczną jest izolacja przestrzeni nazw topiców według szablonu: firma/kategoria/identyfikator_urządzenia/kierunek.

Przykładowa implementacja pliku /etc/mosquitto/external_acl realizująca zasadę najmniejszych uprawnień:

# Globalna blokada - brak domyślnego dostępu do jakichkolwiek topiców
# Każdy użytkownik musi być zdefiniowany poniżej

# Węzeł pomiarowy 01: może publikować wyłącznie swoją telemetrię
# i subskrybować wyłącznie dedykowane komendy
user sensor_node_01
topic write telemetry/sensors/sensor_node_01/state
topic read telemetry/sensors/sensor_node_01/commands

# Węzeł pomiarowy 02: odizolowany od węzła 01
user sensor_node_02
topic write telemetry/sensors/sensor_node_02/state
topic read telemetry/sensors/sensor_node_02/commands

# Serwis backendowy: odbiera dane od wszystkich czujników i wysyła rozkazy
user backend_collector
topic read telemetry/sensors/+/state
topic write telemetry/sensors/+/commands

W dużych flotach urządzeń ręczne wpisywanie dziesiątek użytkowników staje się nieefektywne. W takich scenariuszach Mosquitto wspiera dynamiczne szablony oparte na zmiennych %u (nazwa użytkownika) oraz %c (Client ID przekazany podczas handshake MQTT):

# Wzorzec uniwersalny dla urządzeń polowych:
# Urządzenie może pisać i czytać wyłącznie we własnym poddrzewie odpowiadającym jego loginowi
pattern write devices/%u/data
pattern read devices/%u/control

Stosując powyższy wzorzec, dodanie nowego urządzenia do infrastruktury wymaga jedynie wygenerowania dla niego hasła w mosquitto_passwd. Broker automatycznie ograniczy jego uprawnienia do poddrzewa odpowiadającego wprowadzonej nazwie użytkownika, bez konieczności modyfikacji i przeładowywania pliku ACL.

Bezpieczna konfiguracja publicznego brokera nie sprowadza się do pojedynczego parametru, lecz do wzajemnie uzupełniających się warstw: zapory sieciowej odcinającej niepowołane porty, szyfrowania TLS walidującego tożsamość serwera, bazy poświadczeń uniemożliwiającej podszywanie się pod inne węzły oraz reguł ACL, które ograniczają promień ewentualnych szkód, jeśli którekolwiek z urządzeń w terenie wpadnie w niepowołane ręce.

Kryteria weryfikacji konfiguracji: test szczelności przed otwarciem portów

Zanim na brzegu sieci zostanie przepuszczony jakikolwiek ruch z zewnątrz, należy bezwzględnie zweryfikować zachowanie brokera z poziomu odizolowanej maszyny. Pomyślna autoryzacja zaufanego węzła to zaledwie połowa testu – kluczowe jest upewnienie się, że broker aktywnie odrzuca próby nieautoryzowanego dostępu.

Do rzetelnej weryfikacji wystarczą standardowe narzędzia klienckie mosquitto_sub i mosquitto_pub:

# 1. Test braku dostępu anonimowego (oczekiwany wynik: Connection Refused / Not Authorized)
mosquitto_sub -h mqtt.twojadomena.pl -p 8883 
  --cafile /etc/ssl/certs/ca-certificates.crt 
  -t "telemetry/#"

# 2. Test wymuszenia TLS (próba połączenia nieszyfrowanego na port 8883 musi natychmiast zerwać sesję)
mosquitto_sub -h mqtt.twojadomena.pl -p 8883 
  -u "sensor_node_01" -P "T4jneH4slo123!" 
  -t "telemetry/#"

# 3. Test naruszenia reguł ACL (węzeł 01 próbuje pisać do kolejki węzła 02 - broker musi zignorować lub zablokować pakiet)
mosquitto_pub -h mqtt.twojadomena.pl -p 8883 
  --cafile /etc/ssl/certs/ca-certificates.crt 
  -u "sensor_node_01" -P "T4jneH4slo123!" 
  -t "telemetry/sensors/sensor_node_02/state" 
  -m '{"attack": true}'

Jeśli trzecie polecenie zakończy się publikacją wiadomości na brokerze, oznacza to błąd parsowania pliku ACL lub obecność domyślnej reguły zezwalającej na szeroki dostęp. W poprawnie zabezpieczonej instalacji wpis w dzienniku zdarzeń (/var/log/mosquitto/mosquitto.log) powinien odnotować odmowę publikacji (kod błędu ACL denied).

Rekomendacja architektoniczna: ostateczna decyzja o wdrożeniu

Wystawienie brokera Mosquitto na publiczny adres IP zawsze stanowi kompromis pomiędzy wygodą integracji rozproszonych urządzeń a powierzchnią ataku wystawioną na zautomatyzowane skanery sieciowe. Przed skierowaniem rekordu DNS na interfejs publiczny należy przeprowadzić bilans operacyjny:

• Wdrażaj publiczny broker Mosquitto z TLS i ACL, gdy:
  • Zarządzasz rozproszoną geograficznie flotą urządzeń mobilnych lub telemetrią pracującą w sieciach komórkowych bez stałych adresów IP (gdzie implementacja klienta VPN drastycznie drenuje baterię lub przekracza budżet pamięci RAM mikrokontrolera).
  • Architektura wymaga integracji z chmurowymi serwisami webhookowymi lub zewnętrznymi platformami analitycznymi, które wymagają bezpośredniego dostępu do ustandaryzowanego brokera po porcie 8883.
  • Posiadasz zautomatyzowany mechanizm monitorowania certyfikatów, procesu odnawiania Let’s Encrypt oraz centralny system zarządzania poświadczeniami umożliwiający natychmiastowe unieważnienie skompromitowanego tokenu sprzętowego.
• Zrezygnuj z publicznego wystawiania brokera, gdy:
  • Wszystkie węzły komunikujące się po MQTT znajdują się w ramach jednej sieci lokalnej, kampusu lub łączą się wyłącznie ze stacjonarnym serwerem w siedzibie firmy. W takim scenariuszu bezpieczniejszym podejściem jest zamknięcie brokera za zaporem sieciowym i dostęp wyłącznie przez dedykowane tunele WireGuard lub sieci nakładkowe (overlay network).
  • Infrastruktura opiera się na starszych urządzeniach bez możliwości sprzętowej akceleracji kryptografii (np. 8-bitowe mikrokontrolery), co uniemożliwia egzekwowanie TLS 1.2+. Zezwolenie na ruch otwartym tekstem przez internet to krytyczna luka w bezpieczeństwie.
  • Nie masz możliwości wdrożenia procedury automatycznej rotacji kluczy i certyfikatów (brak wsparcia dla aktualizacji oprogramowania układowego w trybie OTA).

Publiczny broker Mosquitto zabezpieczony certyfikatem Let’s Encrypt, rygorystycznymi listami ACL oraz izolacją portu nieszyfrowanego stanowi w pełni produkcyjne i skalowalne rozwiązanie dla projektów IoT. Kluczem do utrzymania jego odporności nie jest jednak jednorazowa konfiguracja, lecz traktowanie każdego urządzenia polowego jako węzła potencjalnie wrogiego, którego uprawnienia muszą kończyć się dokładnie na granicy jego własnego poddrzewa topiców.

Źródła

• [1] Eclipse Mosquitto – Using Let’s Encrypt certificates with mosquitto
• [2] Eclipse Mosquitto – mosquitto.conf man page
• [3] Eclipse Mosquitto – ACL file Plugin
• [4] Eclipse Mosquitto – Authentication methods