MQTT Güvenliği: Broker’ı Açık Bırakınca Ne Oluyor (ve Pratikte Hep Açık Kalıyor)

MQTT, IoT ve gömülü sistemlerde neredeyse standart hâline gelmiş hafif bir mesajlaşma protokolüdür. Sensörler veri publish eder, aktüatörler komut topic’lerine subscribe olur, ortada bir broker bu trafiği yönetir. Basit, verimli ve düşük kaynak tüketen bir yapı — tam da gömülü dünyanın istediği şey.

Sorun, bu basitliğin çoğu zaman güvenliğin atlanmasına dönüşmesi. Sahada ve internet taramalarında sürekli karşılaşılan tablo şu: kimlik doğrulaması kapalı, TLS yok, port 1883 internete açık. Bu yazı, o açık broker’ın gerçekte ne anlama geldiğini anlatıyor.

MQTT nasıl çalışır (kısa özet)

Üç rol var: publisher, subscriber ve broker. Mesajlar topic adı verilen hiyerarşik yollara gönderilir, ör. bina/kat3/sicaklik. Abone olurken wildcard kullanılabilir: + tek seviye, # ise altındaki her şey demektir. # topic’ine abone olmak, broker’daki tüm mesajları dinlemek anlamına gelir.

Ek olarak “retained message” özelliği, bir topic’in son değerini broker’da saklar; yeni abone bağlandığında bu değeri hemen alır. Bu iki özellik — wildcard ve retained — güvenli olmayan bir broker’da ciddi risk taşır.

Açık broker’ın anatomisi

Kimlik doğrulaması olmayan bir broker’da bir saldırganın yapabilecekleri:

# ile her şeyi dinlemek: tüm telemetri, cihaz durumları, bazen kimlik bilgileri açığa çıkar. Bu hem mahremiyet ihlali hem de mükemmel bir keşif (reconnaissance) kaynağıdır.
Komut topic’lerine yazmak: eğer aktüatörler cmd/* gibi topic’leri dinliyorsa, saldırgan doğrudan cihazlara komut gönderebilir — bir valfı açmak, bir cihazı yeniden başlatmak gibi.
Retained mesajla kalıcı sahte durum: retained bir mesaj göndererek, gelecekteki tüm abonelere sahte bir değeri kalıcı olarak dayatabilir.

Buradaki asıl mesele, MQTT’nin “kötü” olması değil — protokol TLS ve kimlik doğrulamayı destekler. Mesele bunların varsayılan olarak kapalı gelmesi ve hızlı prototiplerin üretime öylece taşınması.

Neden “hep açık kalıyor”?

Prototip → üretim kayması: geliştirme sırasında kolaylık için auth kapatılır, sonra unutulur.
Belge körlüğü: birçok “hızlı başlangıç” rehberi güvenliği hiç anmaz.
Kaynak kaygısı: TLS’in gömülü cihazda maliyetli olacağı varsayımı (çoğu zaman abartılıdır).
Görünmezlik: broker sessizce çalışır; bir sorun olana dek kimse bakmaz.

Savunma tarafı

MQTT’yi güvenli kılmak aslında zor değil:

TLS kullan (port 8883) — trafiği şifrele, broker’ı doğrula.
İstemci kimlik doğrulama — kullanıcı adı/parola en azından, tercihen istemci sertifikası.
Topic bazlı ACL — her istemcinin yalnızca ihtiyacı olan topic’lere erişmesine izin ver; # aboneliğini kısıtla.
Broker’ı internete açma — 1883’ü asla doğrudan dışarı verme; VPN ya da özel ağ arkasında tut.
İzleme — beklenmedik abonelikleri ve komut trafiğini logla.

Adli bilişim açısı

Bir MQTT olayında delil çoğunlukla broker loglarında ve ağ trafiğinde yatar. Broker düzgün loglama yapıyorsa hangi istemcinin hangi topic’e ne zaman bağlandığı görülebilir. Kimlik doğrulama yoksa kaynağı belirlemek zorlaşır ve iş yine pcap kaydına düşer. Bu yüzden IoT/OT ortamlarında pasif ağ kaydı hem savunma hem adli açıdan kritik bir yatırımdır — cihazlar size kim olduklarını çoğu zaman söylemez.

Kapanış

MQTT, IoT’nin sinir sistemidir; açık bir broker ise o sinir sistemine takılmış bir dinleme cihazı gibidir. İyi haber: güvenli hâle getirmek birkaç yapılandırma adımından ibaret. Kötü haber: bu adımlar o kadar sık atlanıyor ki, internette hâlâ binlerce açık broker taranabiliyor. Farkı yaratan, “çalışıyor” ile “güvenli çalışıyor” arasındaki o küçük ama kritik mesafe.

Bu içerik eğitim ve savunma amaçlıdır; yalnızca sahibi olduğun sistemlerde test et.