MQTT sızma testi, kendi broker'ınızdaki ve istemcilerinizdeki zayıflıkları başkası bulmadan önce bulmanın yapılandırılmış bir yoludur. Bu rehber, kapsam belirleme ve keşiften kimlik doğrulama, yetkilendirme, TLS ve kaynak limiti kontrollerine kadar tekrarlanabilir bir metodoloji sunuyor ve ekibe teslim edebileceğiniz bir sıkılaştırma kontrol listesiyle bitiyor. Buradaki her şey, sahibi olduğunuz veya test etmek için yazılı izniniz bulunan sistemler içindir.
Önce Çalışma Kuralları
Size ait olmayan bir broker'ı test etmek, "zaten açık" olup olmamasından bağımsız olarak çoğu yargı alanında yetkisiz erişimdir. Tek bir paket göndermeden önce:
- Ana bilgisayarları, portları, tarihleri ve izin verilen teknikleri belirten yazılı yetkiyi sistem sahibinden alın.
- Örneğin fiziksel ekipmanı harekete geçiren üretim cihazları, üçüncü taraf broker'lar ve herkese açık test broker'ları gibi kapsam dışı olanları tanımlayın.
- Bir hazırlık (staging) kopyasını tercih edin. Aynı yapılandırmaya sahip ancak canlı ekipman içermeyen bir broker, yazma erişimini risksiz test etmenizi sağlar.
- Durdurma koşullarında anlaşın. Bir test kararsızlığa neden olursa durun ve raporlayın.
Yönetilen bir serviste sağlayıcının kabul edilebilir kullanım politikası da geçerlidir. Sağlayıcının paylaşılan altyapısını değil, kendi tenant'ınızın yapılandırmasını ve istemci davranışını test edin; paylaşılan bir kümeye veya broker.connectmq.com gibi herkese açık bir broker'a karşı asla yük veya fuzzing kampanyaları çalıştırmayın. İstemci başına limitleri, onu herkes için kullanılabilir tutmak için vardır.
Bir Bakışta Metodoloji
| Aşama | Hedef | Tipik kanıt |
|---|---|---|
| 1. Kapsam belirleme | Neyi test etmeye yetkili olduğunuzu bilmek | İmzalı kapsam, varlık listesi |
| 2. Keşif | Listener'ları, sürümleri ve uç noktaları haritalamak | Port listesi, TLS ayrıntıları, broker banner'ı |
| 3. Kimlik doğrulama | Yalnızca geçerli kimliklerin bağlandığını doğrulamak | Anonim, yanlış ve tekrar kullanılan kimlik bilgisi denemelerinin sonuçları |
| 4. Yetkilendirme | Her kimliğin kendi topic'leriyle sınırlı olduğunu doğrulamak | Rol başına subscribe/publish matrisi |
| 5. Taşıma güvenliği | Şifrelemeyi ve sertifika doğrulamasını teyit etmek | TLS sürümleri, şifre takımı listesi, istemci doğrulama davranışı |
| 6. Dayanıklılık | Limitleri ve hatalı girdi işlemeyi kontrol etmek (staging) | Limit yanıtları, broker kararlılığı |
| 7. İstemci incelemesi | Cihaz ve uygulamalarda sır yönetimini kontrol etmek | Firmware ve yapılandırma bulguları |
| 8. Raporlama | Bulguları düzeltmelere dönüştürmek | Önceliklendirilmiş iyileştirme listesi |
Aşama 2: Broker'ınızın Keşfi
Bir istemcinin broker'a ulaşabileceği her yolu listeleyerek başlayın. Ekipler çoğu zaman 8883'ü dikkatle güvenceye alır ve bir WebSocket listener'ını veya eski bir düz listener'ı unutur.
# Kendi ana bilgisayarınızdaki MQTT ile ilgili portları listeleyin
nmap -Pn -p 1883,8883,8083,8084,9001 your-broker.example.com
# TLS uç noktasını inceleyin
openssl s_client -connect your-broker.example.com:8883 -servername your-broker.example.com </dev/null
Her listener için şunları kaydedin: protokol (TCP, TLS, WS, WSS), internetten erişilebilir olup olmadığı, sertifika konusu ve bitiş tarihi ve hangi MQTT sürümlerini kabul ettiği. Broker $SYS topic'lerini sunuyorsa, bunların sıradan bir kimliği doğrulanmış istemciye neleri açığa çıkardığını kontrol edin. Sürüm metinleri ve istemci sayıları bir saldırgan için faydalıdır ve cihazların nadiren ihtiyaç duyduğu bilgilerdir.
Aşama 3: Kimlik Doğrulama Testleri
Kimlik doğrulama testleri tek bir soruyu yanıtlar: bağlanmaması gereken biri bağlanabiliyor mu? Her testi, denemeyi günlüklerde kolayca bulunabilir kılan bir tanımlayıcıyla çalıştırın.
- Anonim bağlantı. Kullanıcı adı olmadan bağlanın. Beklenen: "not authorised" nedeniyle reddedilmek.
- Yanlış şifre. Beklenen: reddedilmek. Birkaç kez tekrarlayın ve tekrarlanan başarısızlıkların tespit edildiğini veya yavaşlatıldığını doğrulayın.
- Geçerli kimlik bilgileri, yanlış client ID. Broker'ınız client ID'leri kimlik bilgilerine bağlıyorsa, uyumsuzluk reddedilmelidir.
- Yinelenen client ID. Aynı ID ile iki kez bağlanın ve oturum devralmayı gözlemleyin. Cihazlarınızın bunu ele aldığından ve yalnızca bir client ID'ye sahip bir saldırganın oturumu devralamadığından emin olun.
- İptal edilmiş kimlik bilgileri. Bir test kimliğini iptal edin ve artık bağlanamadığını veya yeniden bağlanamadığını doğrulayın.
Küçük bir Python betiği bu kontrolleri tekrarlanabilir kılar:
import time
import paho.mqtt.client as mqtt
HOST, PORT = "your-broker.example.com", 8883
CASES = [
("anonymous", None, None, "pt-anon-01"),
("wrong-password", "YOUR_USERNAME", "not-the-password", "YOUR_CLIENT_ID"),
("valid", "YOUR_USERNAME", "YOUR_PASSWORD", "YOUR_CLIENT_ID"),
("valid-wrong-id", "YOUR_USERNAME", "YOUR_PASSWORD", "pt-other-id"),
]
def try_connect(name, user, pwd, cid):
result = {}
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=cid,
protocol=mqtt.MQTTv5)
client.tls_set() # sunucu sertifikasını sistem CA'larıyla doğrula
if user:
client.username_pw_set(user, pwd)
def on_connect(c, userdata, flags, reason_code, properties):
result["rc"] = str(reason_code)
c.disconnect()
client.on_connect = on_connect
try:
client.connect(HOST, PORT, keepalive=10)
client.loop_start()
time.sleep(5) # CONNACK'i bekle
client.loop_stop()
except Exception as exc:
result["rc"] = f"exception: {exc}"
print(f"{name:16} -> {result.get('rc', 'no response')}")
for case in CASES:
try_connect(*case)
Yalnızca valid durumu Success bildirmelidir. Diğer her şey açık bir reason code ile reddedilmelidir.
Aşama 4: Yetkilendirme Testleri
Kimlik doğrulama bir istemcinin kim olduğunu kanıtlar; yetkilendirme ise ne yapabileceğine karar verir. Rollere (sensör, ağ geçidi, pano, yönetici servisi) karşı topic kalıplarından oluşan bir matris oluşturun ve her hücreyi gerçek bir bağlantıyla test edin.
| Rol | site/+/telemetry yayını |
# aboneliği |
site/+/cmd yayını |
$SYS/# aboneliği |
|---|---|---|---|---|
| Sensör | İzinli (yalnızca kendi topic'i) | Reddedildi | Reddedildi | Reddedildi |
| Pano | Reddedildi | Reddedildi (yalnızca kapsamlı wildcard) | Reddedildi | Reddedildi |
| Kontrol servisi | Reddedildi | Reddedildi | İzinli | Reddedildi |
Retlerin nasıl göründüğüne dikkat edin. MQTT 5'te reddedilen bir abonelik 0x87 (not authorised) gibi bir SUBACK reason code döndürür, reddedilen bir QoS 1 yayını da reason code içeren bir PUBACK döndürür. MQTT 3.1.1'de reddedilen bir yayın genellikle sessizce düşürülür; bu yüzden mesajın hiç ulaşmadığını ikinci, ayrıcalıklı bir aboneyle doğrulamanız gerekir. Kendi barındırdığınız broker'larda bu kuralların nasıl ifade edileceğini MQTT ACL rehberi açıklar. Broker'ın topic başına kural sunmadığı durumlarda eşdeğer kontrol, her güven bölgesi için ayrı broker'lar veya tenant'lardır.
Aşama 5: Taşıma Güvenliği Testleri
TLS'in her iki tarafını da kontrol edin:
- Sunucu tarafı: yalnızca modern protokol sürümleri (TLS 1.2 ve 1.3), güvenilir bir CA'dan alınmış ve ana bilgisayar adıyla eşleşen bir sertifika ve internetten erişilebilen düz bir listener olmaması.
- İstemci tarafı: cihazlar yanlış bir sertifikayı reddetmelidir. Bir test cihazını kendinden imzalı veya eşleşmeyen sertifikaya sahip bir staging ana bilgisayarına yönlendirin ve bağlantının başarısız olduğunu doğrulayın. Yine de bağlanan bir istemci, aktif bir saldırgana karşı fiilen şifresizdir.
MQTT TLS yapılandırması yazısı doğru istemci ayarlarını ele alır; Wireshark ile MQTT trafiğini analiz etmek de payload'ların artık hatta görünmediğini kanıtlamanın iyi bir yoludur.
Aşama 6: Dayanıklılık ve Limitler (Yalnızca Staging)
Dayanıklılık testi, broker'ın ve istemcilerinizin aşırı veya hatalı girdiyle nasıl davrandığını kontrol eder. Bunu yalnızca kontrol ettiğiniz bir staging broker'da çalıştırın, asla paylaşılan veya üretim altyapısında değil.
- Aşırı büyük payload'lar: yapılandırılmış maksimumunuzdan büyük bir mesaj yayınlayın. Çökme değil, ret bekleyin.
- Hız limitleri: politikanızın izin verdiğinden daha hızlı yayın yapın ve broker'ın yavaşlattığını veya bağlantıyı kestiğini doğrulayın. ConnectMQ planlarında bir kotanın aşılması, istemcilerinizin zarif şekilde ele alması gereken MQTT 5 reason code 0x97 (quota exceeded) ile bildirilir.
- Bağlantı taşkınları: tek bir kaynaktan çok sayıda bağlantı açın ve limitlerin istemci veya IP başına uygulandığını kontrol edin.
- Protokol fuzzing'i: MQTT paketlerini değiştiren araçlar ayrıştırma hatalarını ortaya çıkarabilir. Bunları izole bir test broker'ında tutun ve çökmeleri broker üreticisine bildirin.
Bu limitlerin tasarımına dair bağlam için MQTT hız sınırlama ve DoS koruması yazısına bakın.
Aşama 7: İstemci ve Cihaz İncelemesi
Gerçek dünyadaki birçok bulgu broker'da değil cihazda yer alır:
- Firmware'e sabit kodlanmış veya bir depoya commit edilmiş kimlik bilgileri.
- Bir filodaki her cihaz için tek bir ortak şifre.
- Yapılandırma veya sır yayınlayan hata ayıklama topic'leri.
- Payload'ları doğrulama yapmadan çalıştıran komut topic'leri.
- "Çalışsın diye" devre dışı bırakılmış TLS doğrulaması.
Her cihazı, bir saldırgan tarafından potansiyel olarak sökülüp incelenmiş kabul edin. Her birinin tek başına iptal edilebilen benzersiz kimlik bilgileri olmalıdır.
Bulgularınızdan Sıkılaştırma Kontrol Listesi
Bulguları ekibin doğrulayabileceği sonuçlara dönüştürün:
- Her listener kimlik doğrulama gerektirir; anonim erişim yalnızca bilinçli ve belgelenmiş olduğu yerlerde vardır.
- İnternetten yalnızca geçerli sertifikalı TLS listener'larına erişilebilir.
- Her cihaz ve servisin benzersiz, iptal edilebilir kimlik bilgileri vardır.
- Her kimlik yalnızca ihtiyaç duyduğu topic'lere yayın yapabilir ve abone olabilir.
- İstemciler geçersiz sertifikaları reddeder.
- Mesaj boyutu, hız ve bağlantı limitleri yapılandırılmıştır ve istemciler retleri ele alır.
- Tekrarlanan başarısız girişler yavaşlatılır veya engellenir.
- Broker yazılımı bir takvime göre yamalanır.
- Retained ve hata ayıklama topic'leri hiçbir sır içermez.
- Büyük değişikliklerden sonra yeniden test planlanır.
Bir tam yönetilen MQTT servisi kullandığınızda bu listedeki birçok madde platform tarafından ele alınır. ConnectMQ'da özel broker'lar oluşturulmuş kimlik bilgileri gerektirir, client ID'ler bu kimlik bilgilerine bağlıdır, TLS bir Let's Encrypt sertifikası kullanır, tenant'lar izole edilir ve flood koruması ile tekrarlanan başarısız girişlerden sonra IP engelleme yerleşik olarak gelir. Böylece test çabanız istemci davranışına ve topic tasarımına odaklanabilir. İstemci tarafı maddeler için MQTT güvenliği en iyi uygulamaları yazısı iyi bir tamamlayıcıdır.
Kontrol Ettiğiniz Bir Broker'a Karşı Test Edin
Bu metodolojiyi uygulamanın en güvenli yolu, size ait bir broker üzerinde çalışmaktır. app.connectmq.com adresinde ücretsiz Serverless planında (kredi kartı gerekmez) özel bir ConnectMQ broker oluşturun, kimlik doğrulama ve TLS kontrollerini kendi kimlik bilgilerinize karşı çalıştırın ve yük ile fuzzing testlerini yerel bir staging broker'da tutun. Hızlı, hassas olmayan denemeler için ücretsiz herkese açık MQTT broker'ı limitleri dahilinde kullanmaya devam edebilirsiniz.
Sık Sorulan Sorular
Herkese açık bir MQTT broker'a sızma testi yapabilir miyim?
Operatörün açık izni olmadan hayır. Herkese açık test broker'ları paylaşılan servislerdir ve yük ya da fuzzing testleri onları herkes için yavaşlatır. Kendi broker'larınızı veya yerel bir staging kopyasını test edin.
MQTT güvenlik testinde yaygın olarak hangi araçlar kullanılır?
Listener keşfi için ağ tarayıcıları, TLS kontrolleri için openssl s_client, hızlı testler için mosquitto_pub ve mosquitto_sub, tekrarlanabilir kimlik doğrulama ve yetkilendirme matrisleri için de paho-mqtt gibi betik tabanlı istemciler.
MQTT kurulumumuzu ne sıklıkla yeniden test etmeliyiz?
Listener'larda, kimlik bilgilerinde, topic yapısında veya firmware'de yapılan her önemli değişiklikten sonra ve bunun dışında düzenli bir takvimle. Kimlik doğrulama ve yetkilendirme kontrollerini otomatikleştirmek sık yeniden testi ucuz hâle getirir.
En yaygın bulgu nedir?
Anonim bağlantı kabul eden listener'ların yanı sıra, cihazlarda paylaşılan veya sabit kodlanmış kimlik bilgileri ve istemcilerde devre dışı bırakılmış TLS doğrulaması sık görülen bulgulardır.
