Yaygın MQTT Güvenlik Açıkları ve Önleme Yöntemleri

MQTT güvenlik açıkları birkaç tekrar eden sınıfa ayrılır: zayıf veya eksik kimlik doğrulama, yetkilendirme boşlukları, broker ve istemci kütüphanelerindeki ayrıştırma (parsing) hataları, bilgi sızıntıları ve kaynak tüketimi. Bu makale her sınıfı savunma tarafının bakış açısından ele alır, neden ortaya çıktığını açıklar ve işe yarayan önlemleri listeler. Sonunda broker'lar, cihazlar ve aradaki uygulamalar için bir zafiyet yönetimi kontrol listesine sahip olacaksınız.

MQTT Güvenlik Açıkları Nerede Bulunur?

MQTT protokolünün kendisi küçük ve iyi tanımlanmıştır. Gerçek dünyadaki sorunların çoğu üç yerden gelir:

Broker uygulamaları: Paketleri ayrıştıran, istemcilerin kimliğini doğrulayan ve mesajları yönlendiren sunucu yazılımı.
İstemci kütüphaneleri ve firmware: Cihazlarda ve uygulamalarda MQTT konuşan kod.
Dağıtımlar: Yapılandırma, kimlik bilgileri, ağ maruziyeti ve topic tasarımı.

Pratikte olayların çoğuna dağıtım hataları yol açar, ancak yamalanması gerekenler uygulama hatalarıdır. Her ikisi de bir planı hak eder.

Bir Bakışta Güvenlik Açığı Sınıfları

Sınıf	Tipik neden	Birincil önlem
Eksik kimlik doğrulama	Anonim erişimin açık bırakılması	Her listener'da kimlik bilgisi zorunlu tutun
Kimlik doğrulama atlatma	Auth eklentilerindeki hatalar veya mantıktaki uç durumlar	Hızla yama yapın, her yükseltmede auth'u test edin
Yetkilendirme boşlukları	Aşırı geniş izinler, wildcard kötüye kullanımı	Kimlik başına en az ayrıcalık, ayrı tenant'lar
Paket ayrıştırma hataları	Bozuk uzunluklar, özellikler veya UTF-8 dizeleri	Broker ve kütüphaneleri güncel tutun, staging'de fuzzing yapın
Bilgi ifşası	`$SYS` topic'leri, retained veriler, ayrıntılı hata mesajları	Meta veriyi sınırlayın, retained topic'leri temizleyin
Kaynak tüketimi	Bağlantı, boyut veya hız sınırı olmaması	Kotalar, paket boyutu sınırları, flood koruması
Şifresiz aktarım	Güvenilmeyen ağlar üzerinden 1883 portu	Sertifika doğrulamalı TLS
İstemci tarafı enjeksiyon	Payload'ların kodda veya komutlarda güvensiz kullanılması	Her payload'u doğrulayın ve şemaya göre kontrol edin
Kimlik bilgisi ifşası	Firmware'de sabit kodlanmış veya paylaşılan gizli bilgiler	Cihaz başına benzersiz, iptal edilebilir kimlik bilgileri

Kimlik Doğrulama Zayıflıkları

En basit güvenlik açığı hiç kimlik doğrulama olmamasıdır. Serbest bir geliştirme modunda bırakılan broker'lar her istemciyi kabul eder; bu da açıkta kalan MQTT broker'lar yazısında anlatılan sorunlara yol açar.

Daha ince sorunlar, kimlik doğrulama var olduğu halde boşluklar içerdiğinde ortaya çıkar. Geçmişte broker uygulamalarında, belirli seçenek kombinasyonlarının, eklenti davranışlarının veya bozuk paketlerin bir istemcinin bir kontrolü atlamasına izin verdiği hatalar görülmüştür. Dikkat edilmesi gereken desenler:

Bir arka uç (veritabanı, LDAP) erişilemez olduğunda açık kalan (fail open) kimlik doğrulama eklentileri.
Farklı ayarlara sahip listener'lar; unutulmuş tek bir listener anonim erişime izin verebilir.
Client ID tabanlı güven; bir client ID'yi bilmenin bir oturumu ele geçirmeye yettiği durumlar.
Oturum açma denemelerinde sınır olmaması; bu da parola tahminini uygulanabilir kılar.

Önlemler: Her listener'da kimlik doğrulamayı zorunlu tutun, bir auth arka ucu kapalıyken kapalı kalın (fail closed), client ID'leri kimlik bilgilerine bağlayın ve tekrarlanan başarısız denemeleri yavaşlatın veya engelleyin. ConnectMQ üzerinde client ID'ler verilen kimlik bilgilerine bağlıdır ve tekrarlanan başarısız oturum açma denemelerinden sonra IP'ler engellenir.

Yetkilendirme Boşlukları

Bağlandıktan sonra bir istemci yalnızca kendi topic'lerine erişebilmelidir. Yaygın boşluklar şunlardır:

Tüm cihazların tam erişimli tek bir hesabı paylaşması.
Sıradan cihazlar için # gibi wildcard subscription'lara izin verilmesi.
Kimliği doğrulanmış herhangi bir istemcinin yazabildiği komut topic'leri.
MQTT 3.1.1 için yazılmış ve shared subscription'lar ($share/group/topic) gibi MQTT 5 özelliklerini gözden kaçıran kurallar.

Önlemler: Topic'leri izinlerin hiyerarşiyi izleyebileceği şekilde tasarlayın, her cihaza benzersiz kimlik bilgileri verin ve izin matrisini her sürümün parçası olarak test edin. Kendi barındırdığınız broker'lar MQTT ACL rehberinde anlatılan ACL'leri kullanabilir. Broker'ın topic bazlı kural sunmadığı yerlerde, her güven alanı için ayrı tenant'lar veya broker'lar, paylaşılan kimlik bilgilerinin asla sağlayamayacağı kadar güçlü bir izolasyon sağlar.

Paket Ayrıştırma ve Bellek Güvenliği Hataları

MQTT paketleri değişken uzunluklu tamsayılar, uzunluk önekli dizeler, ikili veriler ve MQTT 5'te zengin bir özellikler kümesi içerir. Bu alanların her biri doğrulanmalıdır. Broker ve istemci uygulamalarındaki ayrıştırma hataları geçmişte çökmelere ve en kötü durumlarda bellek bozulmasına yol açmıştır.

Tipik kök nedenler:

Gerçek veriyle eşleşmeyen remaining-length değerleri.
Yinelenen veya beklenmeyen özellikler içeren özellik listeleri.
Topic adlarında geçersiz UTF-8 veya yasaklı karakterler.
Çok derin topic hiyerarşileri veya aşırı uzun dizeler.

Önlemler: Broker ve istemci kütüphanelerini desteklenen, yamalı sürümlerde tutun; dağıttığınız her MQTT bileşeni için güvenlik bültenlerine abone olun ve fuzzing'i yalnızca size ait izole staging broker'larına karşı çalıştırın. MQTT sızma testi metodolojisi bunun kapsamının nasıl güvenle belirleneceğini açıklar. Gömülü cihazlarda özel ayrıştırıcılar yerine bakımı yapılan kütüphaneleri tercih edin.

Bilgi İfşası

Bilgi sızıntıları nadiren çarpıcıdır ama saldırganlar için çoğu zaman faydalıdır:

Broker sürümünü, çalışma süresini ve istemci sayılarını açığa çıkaran $SYS topic'leri.
Bir proje bittikten çok sonra topic'lerde bırakılmış retained mesajlar.
Yapılandırma, IP adresleri veya token'lar publish eden debug ya da tanılama topic'leri.
Bir kullanıcı adının var olup olmadığını ele veren hata mesajları.
Konumları, müşterileri veya ekipmanı ayrıntılı biçimde tarif eden topic adları.

Önlemler: Meta veri topic'lerini kimlerin okuyabileceğini kısıtlayın, retained topic'leri gözden geçirip temizleyin, gizli bilgileri payload'lardan tamamen uzak tutun ve topic adlarının çok fazla şey açığa çıkaracağı yerlerde opak tanımlayıcılar kullanın.

Kaynak Tüketimi

Sınırlar olmadan tek bir istemci, broker performansı düşene kadar bağlantıları, belleği veya bant genişliğini tüketebilir. Flood'lar kötü niyetli olabileceği gibi yalnızca firmware hatalarının ve yeniden bağlanma fırtınalarının sonucu da olabilir.

Önlemler: İstemci başına mesaj hızı sınırları, maksimum paket boyutu, subscription ve bağlantı sayısına üst sınırlar ve istemci tarafında backoff. ConnectMQ, MQTT 5 reason code 0x97 ile plan bazlı kotalar ve flood koruması uygular. Ayrıntılar MQTT hız sınırlama ve DoS koruması yazısındadır.

İstemci Tarafı Güvenlik Açıkları

İstemciler, uzun güncelleme döngüleriyle çok sayıda cihazda çalıştıkları için çoğu zaman en zayıf halkadır.

Doğrulanmamış payload'lar: Bir payload'u shell komutuna, SQL sorgusuna veya eval fonksiyonuna aktaran bir subscriber, broker'ı bir saldırı kanalına dönüştürmüş olur.
Devre dışı bırakılmış TLS doğrulaması: Sertifika hatalarını aşmak için "insecure" modu açan istemcilerin trafiği araya girilerek ele geçirilebilir.
Sabit kodlanmış kimlik bilgileri: Firmware imajlarının içeriğini çıkarmak kolaydır. Cihazlarda MQTT kimlik bilgilerini güvenceye alma rehberi saklama seçeneklerini ele alır.
Güncelliğini yitirmiş kütüphaneler: Güncellenemeyen cihazlar bilinen hataları sonsuza dek taşır.

Güvenli bir subscriber her payload'u güvenilmeyen girdi olarak ele alır:

import json
import paho.mqtt.client as mqtt

ALLOWED_COMMANDS = {"set_interval": (5, 3600), "set_threshold": (0, 100)}

def on_message(client, userdata, msg):
    try:
        data = json.loads(msg.payload.decode("utf-8"))
        cmd, value = data["cmd"], float(data["value"])
    except (ValueError, KeyError, UnicodeDecodeError):
        print("rejected malformed payload on", msg.topic)
        return
    if cmd not in ALLOWED_COMMANDS:
        print("rejected unknown command", cmd)
        return
    low, high = ALLOWED_COMMANDS[cmd]
    if not low <= value <= high:
        print("rejected out-of-range value", value)
        return
    print(f"applying {cmd}={value}")  # burada kendi güvenli handler'ınızı çağırın

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="YOUR_CLIENT_ID")
client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD")
client.tls_set()
client.on_message = on_message
client.on_connect = lambda c, u, f, rc, p: c.subscribe("connectmq/site1/device42/cmd", qos=1)
client.connect("YOUR_BROKER_HOST", 8883)
client.loop_forever()

Desen basittir: sıkı ayrıştırın, komutları izin listesiyle sınırlayın, değerlerin aralığını kontrol edin ve payload içeriğini asla çalıştırmayın.

Yama Stratejisi: Kendi Barındırma ve Yönetilen Hizmet

Zafiyet yönetimi süregelen bir iştir. Kendi barındırdığınız bir broker için birinin bültenleri takip etmesi, yükseltmeleri test etmesi, bakım pencerelerini planlaması ve sonrasında yapılandırmanın hâlâ geçerli olduğunu doğrulaması gerekir. Güncellemelerin gerisinde kalan, internete açık broker'lar tam olarak saldırganların aradığı şeydir.

Tam yönetilen bir MQTT hizmeti, broker yamalamayı sağlayıcıya devreder. ConnectMQ ile broker yazılımı, TLS sertifikaları ve tenant izolasyonu gibi platform korumaları sizin için işletilir; cihaz firmware'i, istemci kütüphaneleri, kimlik bilgileri ve payload işleme ise sizin sorumluluğunuzda kalır. Bir MQTT broker'ın ne yaptığını anlamak bu sınırı net çizmenize yardımcı olur.

Zafiyet Yönetimi Kontrol Listesi

Kullanımdaki her broker, istemci kütüphanesi ve firmware sürümünün envanterini tutun.
Her bileşen için güvenlik bültenlerine abone olun.
İnternete açık her listener'da kimlik doğrulamayı ve TLS'i zorunlu tutun.
Her cihaza benzersiz, iptal edilebilir kimlik bilgileri ve en az ayrıcalıklı erişim verin.
Boyut, hız ve bağlantı sınırlarını yapılandırın; istemcilerde reason code'ları işleyin.
Subscriber'larda tüm payload'ları doğrulayın; payload içeriğini asla çalıştırmayın.
Gizli bilgileri payload'lardan çıkarın ve retained topic'leri temizleyin.
Cihazlar için güvenli bir firmware güncelleme yolu sağlayın.
Her yükseltmeden sonra kimlik doğrulama ve yetkilendirmeyi yeniden test edin.
Neyi kimin yamaladığını paylaşılan sorumluluk tablosunda belgeleyin.

ConnectMQ ile Saldırı Yüzeyinizi Küçültün

İşe broker yamalamayı yapılacaklar listenizden çıkararak başlayın. app.connectmq.com adresinde ücretsiz Serverless planla özel bir broker oluşturun (kredi kartı gerekmez), istemcilerinizi oluşturulan kimlik bilgileriyle TLS üzerinden bağlayın ve güvenlik çabanızı cihazlara ve uygulamalara odaklayın. İstemcileri sıkılaştırmak için bir sonraki adım MQTT güvenliği en iyi uygulamaları rehberidir.

Sık Sorulan Sorular

MQTT protokolünün kendisi güvensiz mi?

Hayır. MQTT kimlik doğrulamayı destekler ve TLS üzerinden çalışır, ancak ikisini de zorunlu kılmaz. Sorunların çoğu uygulamalardan ve bu kontrolleri atlayan dağıtımlardan kaynaklanır.

Pratikte en yaygın MQTT güvenlik açığı hangisidir?

İnternete açık broker'larda eksik veya zayıf kimlik doğrulama, çoğu zaman şifresiz 1883 portuyla birlikte, kamuya açık araştırmalarda en sık bildirilen sorundur.

MQTT istemci kütüphanelerini nasıl güvende tutarım?

Kütüphane sürümlerini sabitleyin, güvenlik bültenlerini takip edin ve normal sürümlerin parçası olarak güncelleyin. Cihazlarda, düzeltmelerin filoya gerçekten ulaşabilmesi için kablosuz (OTA) bir güncelleme yolu planlayın.

Yönetilen bir broker tüm MQTT güvenlik açıklarını ortadan kaldırır mı?

Broker yamalamayı ve platform sıkılaştırmasını iş yükünüzden çıkarır; ancak istemci kodu, firmware, kimlik bilgileri ve payload doğrulaması sizin sorumluluğunuzda kalır.

Yaygın MQTT Güvenlik Açıkları ve Bunları Azaltma Yolları