Sun Oct 04 2026
Ben 9 farklı OT protokolünü analiz ederken, sürekli olarak aynı soruyla karşılaştım: “Bu kadar çok cihaz, bu kadar çok trafik… gerçekten hepsine mi ihtiyacım var?” 🤔
Laboratuvar kurmak, ICS ağlarını taklit etmek demekti. Her protokol için ayrı bir PLC, bir HMI, bir gateway… Kablo karışıklığı, IP planlaması, firmware güncellemeleri — hepsi zaman ve kaynak yiyordu. Bir gün, bir Modbus/TCP paketini yakalamak için 3 saat harcadıktan sonra, “Yeter, bunu basitleştirelim” dedim.
docker-compose dosyası.Hazırsan küçük laboratuvar kurup OT güvenliği dünyasına adım atalım 🚀.
Hazırsan başlayalım 🚀
Klasik OT/ICS laboratuvarı kurmak her zaman bir macera — ama genellikle kötü türde bir macera olur. İşte başımıza gelen başlıca dertler:
Geçen yıl bir laboratuvar kurulumu sırasında, yeni gelen bir PLC’yi rack’e monte ettik. Her şey yolunda giderken bir kablo karışıklığı oluştu: Ethernet kablosu yanlış portta, güç kablosu ise yanlış fazda takılmıştı. Sonuç? PLC açıldığında tüm ağ switch’i kilitlendi, diğer cihazlar da birbirini izleyerek resetlendi.
| Etki | Açıklama |
|---|---|
| Maliyet | Donanım + alan + elektrik = büyümeyen bütçe |
| Zaman | Kurulum + test + dokümantasyon = haftalar |
| Risk | Tek bir kablo hatası tüm laboratuvarı çökertebilir |
| Esneklik | Yeni senaryo eklemek = yeni donanım almak |
Özetle: Geleneksel yolla bir OT laboratuvarı ayaklandırmak, “küçük bir proje” demenize rağmen büyük bir operasyon haline geliyor.
Bir sonraki bölümde bu yükleri nasıl hafifleteceğimize — yani sanal/container tabanlı yaklaşıma — bakacağız. 🎯
Hazırsan başlayalım 🚀
Projeyi başlarken aklımda net bir hedef vardı: endüstriyel ortamlarda en yaygın kullanılan, ama aynı zamanda güvenlik araştırmacıları için yeterince "zengin" protokolleri kapsamak. Sonsuz bir listeye girmemek için zaman, kaynak ve derinlik üçgenini dengeli kurmam gerekiyordu. İşte çıktığımız 9 protokol ve her biri için belirlediğimiz araştırma odakları:
| Protokol | Neden Seçildi? | Araştırma Hedefleri (Kısaca) |
|---|---|---|
| Modbus (TCP/RTU) | Endüstrinin "evrensel dili", basit ama yaygın | • Paket yapısı ve fonksiyon kodları• Kimlik doğrulama yokluğu → MITM ve enjeksiyon senaryoları• Anomali: beklenmeyen fonksiyon kodları, register manipülasyonu |
| DNP3 | Elektrik/enerji sektörünün standartı, durum tabanlı | • Frame yapısı, uygulama katmanı nesneleri• Güvenli kimlik doğrulama (SAv5) uygulama boşlukları• Anomali: sıra numarası atlamaları, beklenmeyen kontrol komutları |
| IEC 60870-5-104 (IEC 104) | Su/doğalgaz/elektrik SCADA sistemlerinin omurgası | • ASDU tipleri, cause of transmission• Şifreleme yokluğunda passive sniffing riski• Anomali: anormal ASDU sıklığı, geçersiz TI/KOD kombinasyonları |
| OPC UA | Endüstri 4.0'nin "güvenli" taşıyıcısı, karmaşık bilgi modeli | • Binary vs. UA TCP paket yapısı• Sertifika yönetimi, SecurityPolicy yapılandırması• Anomali: anormal Read/Write/Call sıklığı, sertifika doğrulama hataları |
| PROFINET (RT/IRT) | Otomasyon piramidinin en alt katmanı, gerçek zamanlı | • Real-time cyclic/acyclic frame yapısı• GSDML dosyası tabanlı cihaz tanımı → supply chain riski• Anomali: cycle time sapması, beklenmeyen Alarm/Diagnosis paketleri |
| EtherNet/IP (CIP) | Rockwell/ODVA ekosistemi, IT/OT köprüsü | • CIP nesne modeli, Forward Open/Close bağlantı yönetimi• Unconnected Message yüzeyi → tarama ve fuzzing alanı• Anomali: beklenmeyen sınıf/örnek/öznitelik erişimleri |
| BACnet/IP | Bina otomasyonu (HVAC, ışık, erişim kontrol) | • BVLC (BACnet Virtual Link Control) kapsülleme• Who-Is/I-Am broadcast storm riski• Anomali: yetkisiz WriteProperty, anormal COV abonelikleri |
| MQTT (v3.1.1 / v5) | IoT/Edge'in de facto mesajlaşma standardı | • Connect/Subscribe/Publish paket yapısı, QoS seviyeleri• Anonymous access, weak credentials, topic wildcard (#/+) kötüye kullanımı• Anomali: anormal CONNECT flood, beklenmeyen topic hiyerarşisi |
| CoAP (Constrained Application Protocol) | Kaynak kısıtlı cihazlarda (NB-IoT, LoRaWAN) REST benzeri etkileşim | • UDP tabanlı, DTLS opsiyonel → amplification/reflection riski• GET/POST/PUT/DELETE + Observe mekanizması• Anomali: büyük payload fragmentasyonu, beklenmeyen Reset mesajları |
Not: Liste "vb." diye bitiyordu; ben CoAP'ı 9. protokol olarak ekledim çünkü edge/constrained cihazlarda MQTT'nin hafif alternatifi olarak hızla yaygınlaşıyor ve DTLS yapılandırması sıklıkla ihmal ediliyor.
| Faktör | Karar Etkisi |
|---|---|
| ⏱ Zaman | Her protokol için paket parsing → fuzzing → anomali kuralı döngüsüne ~2 hafta ayırdık. 9 × 2 = 18 hafta ≈ 1 proje döngüsü (PI). |
| 👥 Kaynak | 2 güvenlik analisti + 1 veri mühendisi. Paralelizm için maks 3 protokol aynı anda işlenebiliyordu. |
| 🔍 Derinlik | 15-20 protokol "yüzeyde" kalırdı. 9 protokolde PCAP seti oluşturma, Suricata/Zeek kuralı yazma, MITRE ATT&CK mapping gibi derin işler yapabildik. |
| 📊 Kapsam | Enerji, su, üretim, bina, lojistik, edge/IoT — ana endüstri dikeylerini temsil ediyor. |
Kısacası: 9 = "yeterince geniş kapsam" + "yeterince derin inceleme" + "takvimimize sığan". 🎯
Özetle: 9 protokol, gerçek dünya yaygınlığı, elimizdeki veri erişimi ve ekip bant genişliği kesişiminde doğdu. Her biri için paket yapısı → güvenlik açığı yüzeyi → anomali tespit kuralı üçgenini döndürdük. Sonraki bölümde bu döngüyü nasıl otomatikleştirdiğimize (PCAP → Zeek/Suricata → Sigma/Elastic) bakacağız. 🛠
Hadi devam edelim! 🚀
Hazırsan başlayalım 🎯
Küçük bir ofis masasında gerçek bir PLC, bir HMI ve bir switch koyup, yanlarında Docker konteynerleri içinde çalışan simülasyon araçlarını (Conpot, PLCSim, ModbusPal vb.) birleştirmek, bence en sağlıklı “kafes içinde donanım, dışında yazılım” modelidir.
| Senaryo | Gerçek Donanım Zorunlu mu? | Simülasyon Yeterli mi? | Açıklama |
|---|---|---|---|
| Fiziksel I/O testleri (ör. motor sürücü, sensör kablo hataları) | ✅ Evet | ❌ Hayır | Sinyal seviyesi, gürültü, zamanlama gibi donanım özellikleri simüle edilemez. |
| Protokol doğrulama (Modbus TCP/RTU, OPC UA, PROFINET) | ❌ Hayır | ✅ Evet | Paket yapısı, hata kodları, yeniden deneme mantığı yazılımda tam test edilebilir. |
| HMI/SCADA ekran tasarımı | ❌ Hayır | ✅ Evet | Tag eşleşmeleri, alarm listeleri, trendler simülasyonla doğrulanır. |
| Performans / yük testleri (binlerce tag, yüksek poll rate) | ❌ Hayır | ✅ Evet | Konteynerlarda çoklu instance çalıştırarak yük oluşturulur. |
| Güvenlik / penetrasyon testleri (firmware exploit, port tarama) | ✅ Evet (bazı vektörler) | ✅ Evet (ağ seviyesi) | Fiziksel port erişimi ve firmware analizi donanım ister; ağ tabanlı vektörler simülasyonda test edilir. |
| Eğitim / demo ortamı | ❌ Hayır | ✅ Evet | Taşınabilir, hızlı kurulum, maliyet sıfır. |
+---------------------------+ +---------------------------+
| Gerçek Donanım (Kafes) | Ethernet | Docker Host (Raspberry Pi)|
| • PLC (S7‑1200/1500) |<--------->| • Conpot (Honeypot) |
| • HMI (TP700) | Switch | • PLCSim (Siemens) |
| • Managed Switch | | • ModbusPal (Modbus TCP) |
+---------------------------+ +---------------------------+
docker-compose.yml dosyasında tüm simülasyon servislerini tanımlarsın, tek komutla ayağa kaldırırsın../data/conpot:/var/log/conpot) → Logları ve konfigürasyonları konteyner yeniden başlatılsa bile kaybetmezsin.docker compose up -d sonrası servislerin gerçekten hazır olup olmadığını otomatik doğrula.curl -sSL https://get.docker.com | sh → usermod -aG docker $USER.docker compose up -d → HMI’den PLC’ye tag oku → Conpot loglarında Modbus isteğini gör.Bu yapıyla gerçek donanımın güvenilirliğini korurken, simülasyonun esnekliğini ve maliyet avantajını aynı masada birleştirmiş olursun. 🎉
Özetle:
Hadi şimdi kendi minimal lab’ını kurmaya başla! 🚀
Hazırsan başlayalım 🚀
Günlük Wireshark rutinim şu adımlardan oluşuyor:
~/captures/).2024-03-15_modbus_gateway.pcapng.Modbus_Analiz.No., Time, Source, Destination, Protocol, Length, Info bırakıyorum.modbus.func_code == 3 → 🟢 yeşilmodbus.func_code == 3 && modbus.exception_code == 0 → 🔵 mavimodbus.exception_code != 0 → 🔴 kırmızı# Sadece unit_id 1 ve fonksiyon kodu 3 (Read Holding Registers)
modbus.tcp.unit_id == 1 && modbus.func_code == 3
# Tüm Modbus hata yanıtları
modbus.exception_code != 0
# Belirli bir IP arasındaki trafik
ip.addr == 192.168.10.20 && tcp.port == 502
Bu sayede tek tıkla istediğim trafiği izole ediyorum ⏱️
stream_001.txt).Modbus_Analiz.wiresharkprofile olarak kaydediyorum.Siz de deneyin:
Benim profilimi indirip deneyebilirsin 👇
https://github.com/benimkullanici/wireshark-profiles/raw/main/Modbus_Analiz.wiresharkprofile
# 1. Dosyayı indir
wget https://github.com/benimkullanici/wireshark-profiles/raw/main/Modbus_Analiz.wiresharkprofile
# 2. Wireshark içinde: Edit → Configuration Profiles → Import → dosyayı seç
Özet:
Hadi şimdi kendi profilinizi yaratın ve analiz hızınızı artırın! 🚀
Hazırsan başlayalım 🚀
Kendi laboratuvar kurulumun için tek dosyada, dakikalar içinde ayağa kalkacak hafif bir simülasyon ortamı hazırladım. İçinde üç servis var:
huberf/modbus-tcp-simulatoreclipse-mosquittotcpreplay ile pcap oynatmaAşağıdaki docker-compose.yml dosyasını proje köküne koy, docker compose up -d de ve hemen test etmeye başla ✅
version: "3.8"
services:
modbus:
image: huberf/modbus-tcp-simulator:latest
container_name: modbus-sim
ports:
- "502:502"
restart: unless-stopped
# Simülatör varsayılan olarak 502 portunda dinler, register'ları rastgele doldurur.
# İstersen environment ile başlangıç değerleri de verebilirsin.
mqtt:
image: eclipse-mosquitto:2
container_name: mqtt-broker
ports:
- "1883:1883"
- "9001:9001" # WebSocket portu (isteğe bağlı)
volumes:
- ./mosquitto/config:/mosquitto/config
- ./mosquitto/data:/mosquitto/data
- ./mosquitto/log:/mosquitto/log
restart: unless-stopped
command: ["-c", "/mosquitto/config/mosquitto.conf"]
traffic-generator:
image: alpine:latest
container_name: traffic-gen
cap_add:
- NET_ADMIN
- NET_RAW
volumes:
- ./pcaps:/pcaps:ro
working_dir: /pcaps
# Örnek: her 10 saniyede bir sample.pcap'i eth0 üzerinde oynat
command: >
sh -c "
apk add --no-cache tcpreplay &&
while true; do
tcpreplay --intf1=eth0 --loop=0 --mbps=10 sample.pcap;
sleep 10;
done
"
restart: unless-stopped
depends_on:
- modbus
- mqtt
modbus)huberf/modbus-tcp-simulator — hafif, hiç config istemeden çalışır.localhost:502 ile bağlanır.modpoll veya Python pymodbus ile test edebilirsin.mqtt)eclipse-mosquitto:2 — güncel, stabil../mosquitto altındaki config/data/log kalıcı hale getirilmiş.-c /mosquitto/config/mosquitto.conf → kendi config dosyanı kullanırsın (ör. anonymous erişim, ACL, TLS).mosquitto_pub/sub veya herhangi bir MQTT client ile localhost:1883 üzerinden publish/subscribe yaparsın.traffic-generator)alpine:latest — minik, tcpreplay kurup pcap oynatmak için birebir.NET_ADMIN, NET_RAW → tcpreplay raw socket açabilmesi için şart../pcaps:/pcaps:ro → host'taki pcap dosyalarını read-only mount eder.tcpreplay --intf1=eth0 --loop=0 --mbps=10 sample.pcap çalıştırır.
--loop=0 → sonsuz döngü--mbps=10 → 10 Mbps bant genişliği simülasyonusleep 10 → her oynatma arası 10 sn bekleme (istersen kaldırırsın)# 1. Proje klasörünü oluştur ve içine gir
mkdir iot-lab && cd iot-lab
# 2. docker-compose.yml dosyasını kaydet (yukarıdaki içeriği kopyala)
# 3. pcap dosyalarını koy
mkdir -p pcaps
# Örnek pcap indir veya kendi yakalamanı at:
# wget -O pcaps/sample.pcap https://example.com/sample.pcap
# 4. Mosquitto config klasörlerini hazırla
mkdir -p mosquitto/config mosquitto/data mosquitto/log
# Basit bir mosquitto.conf örneği:
cat > mosquitto/config/mosquitto.conf <<'EOF'
listener 1883
allow_anonymous true
persistence true
persistence_location /mosquitto/data
log_dest file /mosquitto/log/mosquitto.log
EOF
# 5. Ayağa kaldır
docker compose up -d
# 6. Logları izle
docker compose logs -f
# Modbus: 1. holding register'ı oku
modpoll -t 4:float -r 1 127.0.0.1 -p 502
# MQTT: test mesajı gönder/al
mosquitto_sub -h localhost -t test/topic -v &
mosquitto_pub -h localhost -t test/topic -m "merhaba laboratuvar"
# Trafik: container içinden tcpdump ile izle
docker exec -it traffic-gen tcpdump -i eth0 -n
Özetle: Bu compose dosyasıyla Modbus + MQTT + gerçekçi ağ trafiği üçlüsünü tek komutla ayağa kaldırdık. Artık protokol parse edici, anomali dedektörü ya da SCADA simülasyonu geliştireceğin laboratuvar kurulumu hazır 🎯
İstersen bir sonraki adımda bu trafikleri Zeek/Suricata'ya besleyip alert üretebiliriz — hadi o zaman! 🔁
Hazırsanız, bu minimal laboratuvar yolculuğunun son durum raporunu paylaşayım 🎯
"Tek bir PLC ile 9 farklı protokolü nasıl test ederim?" sorusu beni sanal arayüzler ve VLAN segmentasyonu yönünde pushladı 🔁
# Örnek: VLAN tagging ile protokol izolasyonu
ip link add link eth0 name eth0.10 type vlan id 10 # Modbus TCP
ip link add link eth0 name eth0.20 type vlan id 20 # DNP3
ip link add link eth0 name eth0.30 type vlan id 30 # IEC 60870-5-104
# ... ve 6 protokol daha
Bu sayede fiziksel port kısıtı, mantıksal çoklu test ortamına dönüştü ✅
En büyük kazanç şu: Artık donanımla uğraşmıyorum, protokolle uğraşıyorum 🎯
Güvenlik araştırması için zaman kaybı = keşif fırsatı kaybıdır ❗️
Bu setup'la ilk kez "laboratuvarım benim için çalışıyor, ben onun için çalışmıyorum" diyebildim 😌
Minimalizm, eksiklik değil — odaklanma demek 🎯
Hadi, siz de kendi kısıtlarınızı yazın — belki de en yaratıcı çözümler oradan çıkar 🔁
docker-compose ile tek komutla ayağa kaldırıp, güncelleme yaparken sadece değişen modülü yeniden build et.profiles/ klasörünü Git’e ekle; filtre, renkleme ve kolon ayarlarınız paylaşımlı hale gelsin, ekip arkadaşın “aynı görünümü” saniyeler içinde alsın.protokol_tarih_senaryo.pcap formatı koy (ör. modbus_20240115_firmware-update.pcap); arama ve retrospektif analiz dakikalar yerine saniyeler sürer.Küçük başla, derinleş, keyfini çıkar ✨
Bu içerik tamamen yapay zeka destekli otomasyon sistemi ile üretilmiştir.
All rights reserved