<![CDATA[TurkTeam | Türk Siber Güvenlik Topluluğu - Donanım ve IoT Güvenliği]]> https://www.turkteam.org/ Sun, 25 Oct 2026 18:48:59 +0000 MyBB <![CDATA[Binwalk ile Firmware Analizine Giriş: Dosya Sistemi Çıkarma Labı]]> https://www.turkteam.org/konu-binwalk-ile-firmware-analizine-giris-dosya-sistemi-cikarma-labi.html Wed, 21 Oct 2026 11:34:59 +0300 KulTigin]]> https://www.turkteam.org/konu-binwalk-ile-firmware-analizine-giris-dosya-sistemi-cikarma-labi.html [Resim: attachment.php?aid=337]
Selam,

IoT cihazının güncelleme dosyasını indirip içine bakmak (kendi cihazınız / üreticinin yayımladığı imaj) firmware analizinin ilk adımıdır. Binwalk imza tarar, gömülü dosya sistemlerini ve sıkıştırılmış blokları bulur. Bu yazı etik lab girişi.

Kurulum
Kod:
# Dağıtım paketi veya pip/pipx (sürüme göre) pipx install binwalk binwalk --help | head

İlk bakış
Kod:
# Kendi indirdiğiniz router firmware'i binwalk firmware.bin # Otomatik çıkarma (dikkat: büyük çıktı) binwalk -e firmware.bin ls -la _firmware.bin.extracted/ | head
SquashFS / JFFS2 / gzip katmanları sık görülür. Çıktıda BusyBox, www kökü, varsayılan parola dosyaları aranır — sonra kendi cihazınızda varsayılanları değiştirirsiniz.

İyi alışkanlıklar
  • Hash'i kaydedin: sha256sum firmware.bin
  • Çıkarmayı VM içinde yapın; zararlı kullanıcı alanı binary çalıştırmayın
  • strings + grep ile "password", "private_key", URL avı
  • Bulgularınızı üreticiye sorumlu açıklama ile bildirin

Kod:
find _firmware.bin.extracted -type f | head -50 grep -R "admin" _firmware.bin.extracted/etc 2>/dev/null | head

Yasal uyarı
Başkasının cihaz firmware'ini izinsiz reverse engineering / dağıtım yasal sorun doğurabilir. Yalnızca sahip olduğunuz cihazlar ve lisansın izin verdiği kapsam. TCK 243-245.

Kaynaklar
Sonraki adımlar
Çıkarılan dosya sisteminde busybox suid, açık telnet, sabit kodlanmış sertifika arayın. Emülasyon (QEMU) ileri seviye; önce statik bulgularla üreticiye sorumlu bildirim yapın.



Uygulamada sık gördüğüm hatalar
Birçok ekip yamayı "planlandı" diye işaretleyip internete açık yüzeyde günlerce bekletiyor. İkinci sık hata: yalnızca CVE numarasına bakıp zincir etkisini görmemek. Üçüncü hata: yama sonrası log ve dosya bütünlüğüne bakmamak; oysa yama öncesi sömürü olmuş olabilir. Bu üç noktayı kendi kontrol listenize eklemenizi öneririm.

Ekip içi iletişim şablonu
Yönetime veya müşteriye yazarken teknik jargonu azaltın: hangi varlık etkilendi, internete açık mı, yama var mı, geçici azaltma ne, doğrulama nasıl yapılacak. Tek paragrafta risk + eylem + sahiplik yazmak, uzun CVE özetinden daha hızlı karar aldırır.

Lab not defteri
Bu konuyu kendi defterime şu başlıklarla işliyorum: tarih, kaynak URL, etkilenen ürün/sürüm, internete açık mı, yama komutu, geri alma planı, IOC listesi, kime haber verildi. Siz de benzer basit bir şablon tutarsanız bir ay sonra "ne yapmıştık?" sorusu cevapsız kalmaz.

İzleme ve doğrulama
Değişiklikten sonra en az bir negatif ve bir pozitif kontrol tanımlayın. Negatif: alarm boş yere düşmemeli. Pozitif: bilinen kötü örneği veya beklenen log satırını yakalamalı. İkisini de kaydedin; aksi halde "sanırım düzeldi" ile yetinirsiniz.

Sonuç
Özetle: kaynağı okuyun, kendi envanterinize bağlayın, yama veya azaltmayı uygulayın, sonra doğrulayın. TurkTeam'de yorumlarda kendi ortamınızdan (ürün adı ve sürüm yeter, hassas IP yazmayın) kısa deneyim paylaşırsanız herkes faydalanır.


Adım adım kontrol listesi (kopyala-yapıştır)
  1. Kaynak duyuruyu ve varsa üretici güvenlik sayfasını arşivleyin (PDF/HTML).
  2. Envanterde etkilenen ürün var mı diye CMDB / agent raporu / netscan ile bakın.
  3. İnternete açık mı, yoksa yalnızca iç ağda mı? Buna göre SLA seçin.
  4. Yama veya yapılandırma azaltmasını stagingde deneyin.
  5. Üretim penceresinde uygulayın; değişiklik kaydı açın.
  6. Servis sağlık kontrolü + log doğrulaması yapın.
  7. Gerekliyse IOC avı veya compromise assessment planlayın.
  8. Kapanış notunu yazın: sürüm, tarih, kim onayladı.

Sık sorulanlar
Sadece okumak yeter mi? Hayır. Okuduktan sonra envanter satırına bağlanmayan bilgi operasyonel değildir.
PoC çalıştırmalı mıyım? Yalnızca izole lab ve yazılı izinle. İnternette rastgele deneme hem etik dışı hem yasadışı olabilir.
WAF / EDR tek başına kurtarır mı? Katmanlı savunma işe yarar ama yamanın yerini tutmaz; özellikle kimlik doğrulamasız RCE sınıflarında.
Ne zaman yönetime çıkmalıyım? İnternete açık kritik yüzey, aktif sömürü istihbaratı veya veri sızıntısı şüphesi varsa gecikmeden.

Örnek komut defteri
Kod:
# Tarih damgası ve ortam notu date -Is hostnamectl 2>/dev/null | head -5 || true # Ağ dinleme özeti (lab) ss -lntp | head -30 # Son reboot / güncelleme ipucu (systemd) who -b 2>/dev/null || true
Bu komutlar tanı koymaz; değişiklik öncesi/sonrası basline almak için kullanın.

İlgili TurkTeam bölümleri
Bu yazıyı okuduktan sonra aynı kategorideki komşu konulara ve Soru-Cevap bölümüne kendi lab çıktınızı (hassas veri olmadan) taşıyabilirsiniz. Kısa ekran görüntüsü veya komut çıktısı, uzun teoriden daha çok işe yarar.

Kapanış ve yasal çerçeve
TurkTeam white-hat bir topluluktur. Anlatılan teknikler eğitim, savunma ve izinli test içindir. Başkalarının sistemlerinde izinsiz tarama, sömürü, veri çalma veya "hack hizmeti" sunmak forum kurallarına ve TCK 243, 244, 245 maddelerine aykırıdır. Kendi laboratuvarınızı izolasyonla kurun; üretim verisi kullanmayın. Kaynaklardaki bağlantıları birincil referans kabul edin; bu yazı özet ve yol göstericidir, üretici duyurusunun yerini tutmaz.

Kişisel deneyim notu
Ben benzer konuları işlerken önce resmi duyuruyu iki kez okuyup sonra labda en küçük yeniden üretilebilir adımı arıyorum. Yeniden üretemiyorsam bile envanter ve yama doğrulamasını aynı gün bitirmeye çalışıyorum. Siz de "bugün tek iş" diye bir satır seçin: ya yamayı uygulayın ya da etkilenen varlık olmadığını kanıtlayın. İkisi de geçerli kapanıştır.

Okuma listesi
  • Üretici / araştırmacı birincil yazısı (kaynakçada)
  • CISA KEV veya CERT duyurusu varsa o
  • Kendi iç runbook'unuzun ilgili maddesi
Üçünden fazlasını aynı anda açmak yerine birini bitirip not alın; aksi halde tab kaybı başlar.

Kısa senaryo
Diyelim ki bu konuyu pazartesi sabah toplantısında anlatacaksınız: bir slaytta risk, bir slaytta etkilenen varlık sorusu, bir slaytta bugün yapılacak tek eylem. Üç slayttan fazlası dikkat dağıtır. Toplantı bitince eylem sahibinin adını ticket'a yazın.

.png   20-k05-binwalk.png (Dosya Boyutu: 110.19 KB / İndirme Sayısı: 11) ]]> [Resim: attachment.php?aid=337]
Selam,

IoT cihazının güncelleme dosyasını indirip içine bakmak (kendi cihazınız / üreticinin yayımladığı imaj) firmware analizinin ilk adımıdır. Binwalk imza tarar, gömülü dosya sistemlerini ve sıkıştırılmış blokları bulur. Bu yazı etik lab girişi.

Kurulum
Kod:
# Dağıtım paketi veya pip/pipx (sürüme göre) pipx install binwalk binwalk --help | head

İlk bakış
Kod:
# Kendi indirdiğiniz router firmware'i binwalk firmware.bin # Otomatik çıkarma (dikkat: büyük çıktı) binwalk -e firmware.bin ls -la _firmware.bin.extracted/ | head
SquashFS / JFFS2 / gzip katmanları sık görülür. Çıktıda BusyBox, www kökü, varsayılan parola dosyaları aranır — sonra kendi cihazınızda varsayılanları değiştirirsiniz.

İyi alışkanlıklar
  • Hash'i kaydedin: sha256sum firmware.bin
  • Çıkarmayı VM içinde yapın; zararlı kullanıcı alanı binary çalıştırmayın
  • strings + grep ile "password", "private_key", URL avı
  • Bulgularınızı üreticiye sorumlu açıklama ile bildirin

Kod:
find _firmware.bin.extracted -type f | head -50 grep -R "admin" _firmware.bin.extracted/etc 2>/dev/null | head

Yasal uyarı
Başkasının cihaz firmware'ini izinsiz reverse engineering / dağıtım yasal sorun doğurabilir. Yalnızca sahip olduğunuz cihazlar ve lisansın izin verdiği kapsam. TCK 243-245.

Kaynaklar
Sonraki adımlar
Çıkarılan dosya sisteminde busybox suid, açık telnet, sabit kodlanmış sertifika arayın. Emülasyon (QEMU) ileri seviye; önce statik bulgularla üreticiye sorumlu bildirim yapın.



Uygulamada sık gördüğüm hatalar
Birçok ekip yamayı "planlandı" diye işaretleyip internete açık yüzeyde günlerce bekletiyor. İkinci sık hata: yalnızca CVE numarasına bakıp zincir etkisini görmemek. Üçüncü hata: yama sonrası log ve dosya bütünlüğüne bakmamak; oysa yama öncesi sömürü olmuş olabilir. Bu üç noktayı kendi kontrol listenize eklemenizi öneririm.

Ekip içi iletişim şablonu
Yönetime veya müşteriye yazarken teknik jargonu azaltın: hangi varlık etkilendi, internete açık mı, yama var mı, geçici azaltma ne, doğrulama nasıl yapılacak. Tek paragrafta risk + eylem + sahiplik yazmak, uzun CVE özetinden daha hızlı karar aldırır.

Lab not defteri
Bu konuyu kendi defterime şu başlıklarla işliyorum: tarih, kaynak URL, etkilenen ürün/sürüm, internete açık mı, yama komutu, geri alma planı, IOC listesi, kime haber verildi. Siz de benzer basit bir şablon tutarsanız bir ay sonra "ne yapmıştık?" sorusu cevapsız kalmaz.

İzleme ve doğrulama
Değişiklikten sonra en az bir negatif ve bir pozitif kontrol tanımlayın. Negatif: alarm boş yere düşmemeli. Pozitif: bilinen kötü örneği veya beklenen log satırını yakalamalı. İkisini de kaydedin; aksi halde "sanırım düzeldi" ile yetinirsiniz.

Sonuç
Özetle: kaynağı okuyun, kendi envanterinize bağlayın, yama veya azaltmayı uygulayın, sonra doğrulayın. TurkTeam'de yorumlarda kendi ortamınızdan (ürün adı ve sürüm yeter, hassas IP yazmayın) kısa deneyim paylaşırsanız herkes faydalanır.


Adım adım kontrol listesi (kopyala-yapıştır)
  1. Kaynak duyuruyu ve varsa üretici güvenlik sayfasını arşivleyin (PDF/HTML).
  2. Envanterde etkilenen ürün var mı diye CMDB / agent raporu / netscan ile bakın.
  3. İnternete açık mı, yoksa yalnızca iç ağda mı? Buna göre SLA seçin.
  4. Yama veya yapılandırma azaltmasını stagingde deneyin.
  5. Üretim penceresinde uygulayın; değişiklik kaydı açın.
  6. Servis sağlık kontrolü + log doğrulaması yapın.
  7. Gerekliyse IOC avı veya compromise assessment planlayın.
  8. Kapanış notunu yazın: sürüm, tarih, kim onayladı.

Sık sorulanlar
Sadece okumak yeter mi? Hayır. Okuduktan sonra envanter satırına bağlanmayan bilgi operasyonel değildir.
PoC çalıştırmalı mıyım? Yalnızca izole lab ve yazılı izinle. İnternette rastgele deneme hem etik dışı hem yasadışı olabilir.
WAF / EDR tek başına kurtarır mı? Katmanlı savunma işe yarar ama yamanın yerini tutmaz; özellikle kimlik doğrulamasız RCE sınıflarında.
Ne zaman yönetime çıkmalıyım? İnternete açık kritik yüzey, aktif sömürü istihbaratı veya veri sızıntısı şüphesi varsa gecikmeden.

Örnek komut defteri
Kod:
# Tarih damgası ve ortam notu date -Is hostnamectl 2>/dev/null | head -5 || true # Ağ dinleme özeti (lab) ss -lntp | head -30 # Son reboot / güncelleme ipucu (systemd) who -b 2>/dev/null || true
Bu komutlar tanı koymaz; değişiklik öncesi/sonrası basline almak için kullanın.

İlgili TurkTeam bölümleri
Bu yazıyı okuduktan sonra aynı kategorideki komşu konulara ve Soru-Cevap bölümüne kendi lab çıktınızı (hassas veri olmadan) taşıyabilirsiniz. Kısa ekran görüntüsü veya komut çıktısı, uzun teoriden daha çok işe yarar.

Kapanış ve yasal çerçeve
TurkTeam white-hat bir topluluktur. Anlatılan teknikler eğitim, savunma ve izinli test içindir. Başkalarının sistemlerinde izinsiz tarama, sömürü, veri çalma veya "hack hizmeti" sunmak forum kurallarına ve TCK 243, 244, 245 maddelerine aykırıdır. Kendi laboratuvarınızı izolasyonla kurun; üretim verisi kullanmayın. Kaynaklardaki bağlantıları birincil referans kabul edin; bu yazı özet ve yol göstericidir, üretici duyurusunun yerini tutmaz.

Kişisel deneyim notu
Ben benzer konuları işlerken önce resmi duyuruyu iki kez okuyup sonra labda en küçük yeniden üretilebilir adımı arıyorum. Yeniden üretemiyorsam bile envanter ve yama doğrulamasını aynı gün bitirmeye çalışıyorum. Siz de "bugün tek iş" diye bir satır seçin: ya yamayı uygulayın ya da etkilenen varlık olmadığını kanıtlayın. İkisi de geçerli kapanıştır.

Okuma listesi
  • Üretici / araştırmacı birincil yazısı (kaynakçada)
  • CISA KEV veya CERT duyurusu varsa o
  • Kendi iç runbook'unuzun ilgili maddesi
Üçünden fazlasını aynı anda açmak yerine birini bitirip not alın; aksi halde tab kaybı başlar.

Kısa senaryo
Diyelim ki bu konuyu pazartesi sabah toplantısında anlatacaksınız: bir slaytta risk, bir slaytta etkilenen varlık sorusu, bir slaytta bugün yapılacak tek eylem. Üç slayttan fazlası dikkat dağıtır. Toplantı bitince eylem sahibinin adını ticket'a yazın.

.png   20-k05-binwalk.png (Dosya Boyutu: 110.19 KB / İndirme Sayısı: 11) ]]> <![CDATA[IoT Cihaz Sertleştirme: Varsayılan Parola, Firmware ve Segmentasyon]]> https://www.turkteam.org/konu-iot-cihaz-sertlestirme-varsayilan-parola-firmware-ve-segmentasyon.html Mon, 19 Oct 2026 02:23:43 +0300 Tonyukuk]]> https://www.turkteam.org/konu-iot-cihaz-sertlestirme-varsayilan-parola-firmware-ve-segmentasyon.html [Resim: attachment.php?aid=297]
Merhaba,

Evdeki ve ofisteki IoT cihazları (kamera, yazıcı, akıllı priz) çoğu zaman yıllarca güncellenmeden kalır. Bu yazıda varsayılan parola, firmware ve ağ segmentasyonu odaklı sertleştirme listemi paylaşıyorum.

1) Varsayılan kimlik bilgileri
İlk kurulumda admin/admin bırakmayın. Aynı modeli kullanan binlerce cihaz Shodan'da aynı parola ile duruyor. Parolayı parola yöneticisinde saklayın; her cihaz farklı olsun.

2) Firmware
  • Üreticinin resmi sayfasından güncelleyin; rastgele "firmware.bin" indirmeyin
  • Destek ömrü bitmiş cihazı internete açmayın; değiştirin veya tamamen izole edin
  • Otomatik güncelleme varsa açın; yoksa takvimle kontrol edin

[Resim: attachment.php?aid=298]

3) Segmentasyon
IoT'yi ana VLAN'dan ayırın. Misafir / IoT SSID + istemci izolasyonu. Kameranın televizyonunuza ihtiyacı olabilir; NAS ve bilgisayarınıza genelde yoktur. Firewall kuralı: IoT -> WAN sınırlı, IoT -> LAN deny (gerekli istisnalar hariç).

4) Servis yüzeyi
  • UPnP kapatın
  • Uzaktan erişim bulut özelliği kullanmayacaksanız kapatın
  • Gereksiz açık portları kapatın; port forward ile kamerayı dünyaya açmayın (VPN tercih)
  • TLS'siz yönetim arayüzünü WAN'a asla vermeyin

5) İzleme
Router'da IoT VLAN'ından beklenmeyen dış bağlantıları loglayın. Bir ampulün ani DNS tüneli gibi davranması "normal" değildir.

Hızlı kontrol listesi
  1. Parola değişti mi?
  2. Firmware güncel mi / destekleniyor mu?
  3. Ayrı SSID/VLAN?
  4. UPnP/WPS kapalı mı?
  5. Bulut paylaşımı bilinçli mi?

Kaynaklar
  • CISA IoT güvenlik önerileri
  • Üretici güvenlik bültenleri
  • NIST IR IoT cihaz güvenliği yayınları

Evde IoT VLAN'ı kurarken hangi router/firewall'u kullandınız? pfSense / OpenWrt deneyimleri yorumlara bekler.

Kamera özelinde
Varsayılan RTSP parolasını değiştirin, mümkünse VPN ardında izleyin, bulut paylaşımını bilinçli açın. "Zayıf cihaz" varsayımıyla hareket edin: ele geçince LAN tarayıcı olur. Bu yüzden segmentasyon şart.

Envanter
Evdeki her IoT'nin MAC, IP, firmware sürümü, son güncelleme tarihini basit bir tabloya yazın. Router DHCP static lease ile isim verin; "unknown device" alarmı anlamlı hâle gelir.


Doğrulama senaryosu
Bu konuyla ilgili ek bir kontrol: değişikliği yaptıktan sonra en az bir negatif test ve bir pozitif test tanımlayın. Negatif test 'alarm boşyere düşmemeli', pozitif test 'bilinen kötü örneği yakalamalı' der. İkisini de kaydedin.

Lab disiplini
Ortamlar arasında (lab, staging, production) aynı yapılandırmayı kör kopyalamayın. Adresler, sertifikalar ve kimlikler farklıdır. Şablon kullanın, değerleri envanterden doldurun.

Runbook'a taşımak
İlgili log ve kanıtları olaydan sonra en az kurum politikasının öngördüğü süre kadar saklayın. Disk dolunca en eski güvenlik logunu silmek klasik hatadır; ayrı retention politikası tanımlayın.

Ölçüm ve alarm sağlığı
Yanlış pozitifleri susturmak ile körleşmek arasındaki çizgi incedir. Suppress kuralına gerekçe ve gözden geçirme tarihi yazın. Süresi dolunca yeniden değerlendirin.

Kapsam ve izin hatırlatması
Bu adımları change ticket olmadan production'da uygulamayın. Küçük görünen bir audit ayarı bile uygulama uyumluluğunu bozabilir. Önce staging, sonra kontrollü yayılım.

Yedekleme ve geri dönüş
Yılda en az iki kez masabaşı tatbikatı yapın: 'bu kontrol kırılırsa kim fark eder?' sorusunu sorunsuz cevaplayabilmelisiniz. Tatbikat notlarını wiki'ye ekleyin.

Log saklama süresi
Araç çıktısını ekran görüntüsü olarak bırakmak yerine makinece okunur formatta (JSON/CSV) arşivleyin. İki yıl sonraki denetimde arama kolaylaşır.

Yanlış pozitif yönetimi
Yetki ayrımı: bu kontrolü yapılandıran kişi ile alarmı triaj eden kişi mümkünse farklı olsun. Küçük ekiplerde olmasa bile en azından farklı hesap kullanın.

Değişiklik yönetimi ile ilişki
Sürüüm yükseltmelerinden sonra regresyon testi yapın. 'Aynı config' yeni sürümde farklı varsayılanlara bağlanmış olabilir. Release note'daki breaking change bölümünü okuyun.

Eğitim tatbikatı
Dış bağımlılık (feed, imza seti, konteyner imajı) için bütünlük doğrulaması yapın. İmzasız feed ile gelen kural seti tedarik zinciri riskidir.

Doğrulama senaryosu
Bu konuyla ilgili ek bir kontrol: değişikliği yaptıktan sonra en az bir negatif test ve bir pozitif test tanımlayın. Negatif test 'alarm boşyere düşmemeli', pozitif test 'bilinen kötü örneği yakalamalı' der. İkisini de kaydedin.

Lab disiplini
Ortamlar arasında (lab, staging, production) aynı yapılandırmayı kör kopyalamayın. Adresler, sertifikalar ve kimlikler farklıdır. Şablon kullanın, değerleri envanterden doldurun.

Runbook'a taşımak
İlgili log ve kanıtları olaydan sonra en az kurum politikasının öngördüğü süre kadar saklayın. Disk dolunca en eski güvenlik logunu silmek klasik hatadır; ayrı retention politikası tanımlayın.

Ölçüm ve alarm sağlığı
Yanlış pozitifleri susturmak ile körleşmek arasındaki çizgi incedir. Suppress kuralına gerekçe ve gözden geçirme tarihi yazın. Süresi dolunca yeniden değerlendirin.

Kapsam ve izin hatırlatması
Bu adımları change ticket olmadan production'da uygulamayın. Küçük görünen bir audit ayarı bile uygulama uyumluluğunu bozabilir. Önce staging, sonra kontrollü yayılım.

Yedekleme ve geri dönüş
Yılda en az iki kez masabaşı tatbikatı yapın: 'bu kontrol kırılırsa kim fark eder?' sorusunu sorunsuz cevaplayabilmelisiniz. Tatbikat notlarını wiki'ye ekleyin.

Log saklama süresi
Araç çıktısını ekran görüntüsü olarak bırakmak yerine makinece okunur formatta (JSON/CSV) arşivleyin. İki yıl sonraki denetimde arama kolaylaşır.

Yanlış pozitif yönetimi
Yetki ayrımı: bu kontrolü yapılandıran kişi ile alarmı triaj eden kişi mümkünse farklı olsun. Küçük ekiplerde olmasa bile en azından farklı hesap kullanın.

Değişiklik yönetimi ile ilişki
Sürüüm yükseltmelerinden sonra regresyon testi yapın. 'Aynı config' yeni sürümde farklı varsayılanlara bağlanmış olabilir. Release note'daki breaking change bölümünü okuyun.

Eğitim tatbikatı
Dış bağımlılık (feed, imza seti, konteyner imajı) için bütünlük doğrulaması yapın. İmzasız feed ile gelen kural seti tedarik zinciri riskidir.

Uygulama notu
Bu rehberdeki komutları olduğu gibi kopyalamadan önce yolları, arayüz adlarını ve IP adreslerini kendi ortamınıza göre değiştirin. Dağıtım farkları (Debian/Ubuntu/RHEL/Windows sunucu) çıktı biçimini değiştirebilir; man sayfası ve resmi dokümantasyon birincil kaynaktır. Bir adım beklediğiniz sonucu vermezse önce yetki (sudo/Administrator), sonra sürüm, en son da yapılandırma dosyası sırasıyla bakın. Değişiklikleri geri almak için snapshot veya yapılandırma yönetimi (Ansible/Git) kullanın; 'elle bir dokundum' geçmişi denetimde kaybolur. Alarm ve log örneklerini ekip kanalında paylaşırken kişisel veri ve iç IP şemasını maskeleyin.
Yasal uyarı: Bu içerik eğitim amaçlıdır. Anlatılanları yalnızca kendi sistemlerinizde veya yazılı izin aldığınız sistemlerde uygulayın. Yetkisiz erişim ve sistemlere müdahale 5237 sayılı TCK'nın 243, 244 ve 245. maddeleri kapsamında suçtur.

.png   100-n26-d6e0b3.png (Dosya Boyutu: 68.07 KB / İndirme Sayısı: 14)

.png   n26-inner.png (Dosya Boyutu: 16.82 KB / İndirme Sayısı: 15) ]]> [Resim: attachment.php?aid=297]
Merhaba,

Evdeki ve ofisteki IoT cihazları (kamera, yazıcı, akıllı priz) çoğu zaman yıllarca güncellenmeden kalır. Bu yazıda varsayılan parola, firmware ve ağ segmentasyonu odaklı sertleştirme listemi paylaşıyorum.

1) Varsayılan kimlik bilgileri
İlk kurulumda admin/admin bırakmayın. Aynı modeli kullanan binlerce cihaz Shodan'da aynı parola ile duruyor. Parolayı parola yöneticisinde saklayın; her cihaz farklı olsun.

2) Firmware
  • Üreticinin resmi sayfasından güncelleyin; rastgele "firmware.bin" indirmeyin
  • Destek ömrü bitmiş cihazı internete açmayın; değiştirin veya tamamen izole edin
  • Otomatik güncelleme varsa açın; yoksa takvimle kontrol edin

[Resim: attachment.php?aid=298]

3) Segmentasyon
IoT'yi ana VLAN'dan ayırın. Misafir / IoT SSID + istemci izolasyonu. Kameranın televizyonunuza ihtiyacı olabilir; NAS ve bilgisayarınıza genelde yoktur. Firewall kuralı: IoT -> WAN sınırlı, IoT -> LAN deny (gerekli istisnalar hariç).

4) Servis yüzeyi
  • UPnP kapatın
  • Uzaktan erişim bulut özelliği kullanmayacaksanız kapatın
  • Gereksiz açık portları kapatın; port forward ile kamerayı dünyaya açmayın (VPN tercih)
  • TLS'siz yönetim arayüzünü WAN'a asla vermeyin

5) İzleme
Router'da IoT VLAN'ından beklenmeyen dış bağlantıları loglayın. Bir ampulün ani DNS tüneli gibi davranması "normal" değildir.

Hızlı kontrol listesi
  1. Parola değişti mi?
  2. Firmware güncel mi / destekleniyor mu?
  3. Ayrı SSID/VLAN?
  4. UPnP/WPS kapalı mı?
  5. Bulut paylaşımı bilinçli mi?

Kaynaklar
  • CISA IoT güvenlik önerileri
  • Üretici güvenlik bültenleri
  • NIST IR IoT cihaz güvenliği yayınları

Evde IoT VLAN'ı kurarken hangi router/firewall'u kullandınız? pfSense / OpenWrt deneyimleri yorumlara bekler.

Kamera özelinde
Varsayılan RTSP parolasını değiştirin, mümkünse VPN ardında izleyin, bulut paylaşımını bilinçli açın. "Zayıf cihaz" varsayımıyla hareket edin: ele geçince LAN tarayıcı olur. Bu yüzden segmentasyon şart.

Envanter
Evdeki her IoT'nin MAC, IP, firmware sürümü, son güncelleme tarihini basit bir tabloya yazın. Router DHCP static lease ile isim verin; "unknown device" alarmı anlamlı hâle gelir.


Doğrulama senaryosu
Bu konuyla ilgili ek bir kontrol: değişikliği yaptıktan sonra en az bir negatif test ve bir pozitif test tanımlayın. Negatif test 'alarm boşyere düşmemeli', pozitif test 'bilinen kötü örneği yakalamalı' der. İkisini de kaydedin.

Lab disiplini
Ortamlar arasında (lab, staging, production) aynı yapılandırmayı kör kopyalamayın. Adresler, sertifikalar ve kimlikler farklıdır. Şablon kullanın, değerleri envanterden doldurun.

Runbook'a taşımak
İlgili log ve kanıtları olaydan sonra en az kurum politikasının öngördüğü süre kadar saklayın. Disk dolunca en eski güvenlik logunu silmek klasik hatadır; ayrı retention politikası tanımlayın.

Ölçüm ve alarm sağlığı
Yanlış pozitifleri susturmak ile körleşmek arasındaki çizgi incedir. Suppress kuralına gerekçe ve gözden geçirme tarihi yazın. Süresi dolunca yeniden değerlendirin.

Kapsam ve izin hatırlatması
Bu adımları change ticket olmadan production'da uygulamayın. Küçük görünen bir audit ayarı bile uygulama uyumluluğunu bozabilir. Önce staging, sonra kontrollü yayılım.

Yedekleme ve geri dönüş
Yılda en az iki kez masabaşı tatbikatı yapın: 'bu kontrol kırılırsa kim fark eder?' sorusunu sorunsuz cevaplayabilmelisiniz. Tatbikat notlarını wiki'ye ekleyin.

Log saklama süresi
Araç çıktısını ekran görüntüsü olarak bırakmak yerine makinece okunur formatta (JSON/CSV) arşivleyin. İki yıl sonraki denetimde arama kolaylaşır.

Yanlış pozitif yönetimi
Yetki ayrımı: bu kontrolü yapılandıran kişi ile alarmı triaj eden kişi mümkünse farklı olsun. Küçük ekiplerde olmasa bile en azından farklı hesap kullanın.

Değişiklik yönetimi ile ilişki
Sürüüm yükseltmelerinden sonra regresyon testi yapın. 'Aynı config' yeni sürümde farklı varsayılanlara bağlanmış olabilir. Release note'daki breaking change bölümünü okuyun.

Eğitim tatbikatı
Dış bağımlılık (feed, imza seti, konteyner imajı) için bütünlük doğrulaması yapın. İmzasız feed ile gelen kural seti tedarik zinciri riskidir.

Doğrulama senaryosu
Bu konuyla ilgili ek bir kontrol: değişikliği yaptıktan sonra en az bir negatif test ve bir pozitif test tanımlayın. Negatif test 'alarm boşyere düşmemeli', pozitif test 'bilinen kötü örneği yakalamalı' der. İkisini de kaydedin.

Lab disiplini
Ortamlar arasında (lab, staging, production) aynı yapılandırmayı kör kopyalamayın. Adresler, sertifikalar ve kimlikler farklıdır. Şablon kullanın, değerleri envanterden doldurun.

Runbook'a taşımak
İlgili log ve kanıtları olaydan sonra en az kurum politikasının öngördüğü süre kadar saklayın. Disk dolunca en eski güvenlik logunu silmek klasik hatadır; ayrı retention politikası tanımlayın.

Ölçüm ve alarm sağlığı
Yanlış pozitifleri susturmak ile körleşmek arasındaki çizgi incedir. Suppress kuralına gerekçe ve gözden geçirme tarihi yazın. Süresi dolunca yeniden değerlendirin.

Kapsam ve izin hatırlatması
Bu adımları change ticket olmadan production'da uygulamayın. Küçük görünen bir audit ayarı bile uygulama uyumluluğunu bozabilir. Önce staging, sonra kontrollü yayılım.

Yedekleme ve geri dönüş
Yılda en az iki kez masabaşı tatbikatı yapın: 'bu kontrol kırılırsa kim fark eder?' sorusunu sorunsuz cevaplayabilmelisiniz. Tatbikat notlarını wiki'ye ekleyin.

Log saklama süresi
Araç çıktısını ekran görüntüsü olarak bırakmak yerine makinece okunur formatta (JSON/CSV) arşivleyin. İki yıl sonraki denetimde arama kolaylaşır.

Yanlış pozitif yönetimi
Yetki ayrımı: bu kontrolü yapılandıran kişi ile alarmı triaj eden kişi mümkünse farklı olsun. Küçük ekiplerde olmasa bile en azından farklı hesap kullanın.

Değişiklik yönetimi ile ilişki
Sürüüm yükseltmelerinden sonra regresyon testi yapın. 'Aynı config' yeni sürümde farklı varsayılanlara bağlanmış olabilir. Release note'daki breaking change bölümünü okuyun.

Eğitim tatbikatı
Dış bağımlılık (feed, imza seti, konteyner imajı) için bütünlük doğrulaması yapın. İmzasız feed ile gelen kural seti tedarik zinciri riskidir.

Uygulama notu
Bu rehberdeki komutları olduğu gibi kopyalamadan önce yolları, arayüz adlarını ve IP adreslerini kendi ortamınıza göre değiştirin. Dağıtım farkları (Debian/Ubuntu/RHEL/Windows sunucu) çıktı biçimini değiştirebilir; man sayfası ve resmi dokümantasyon birincil kaynaktır. Bir adım beklediğiniz sonucu vermezse önce yetki (sudo/Administrator), sonra sürüm, en son da yapılandırma dosyası sırasıyla bakın. Değişiklikleri geri almak için snapshot veya yapılandırma yönetimi (Ansible/Git) kullanın; 'elle bir dokundum' geçmişi denetimde kaybolur. Alarm ve log örneklerini ekip kanalında paylaşırken kişisel veri ve iç IP şemasını maskeleyin.
Yasal uyarı: Bu içerik eğitim amaçlıdır. Anlatılanları yalnızca kendi sistemlerinizde veya yazılı izin aldığınız sistemlerde uygulayın. Yetkisiz erişim ve sistemlere müdahale 5237 sayılı TCK'nın 243, 244 ve 245. maddeleri kapsamında suçtur.

.png   100-n26-d6e0b3.png (Dosya Boyutu: 68.07 KB / İndirme Sayısı: 14)

.png   n26-inner.png (Dosya Boyutu: 16.82 KB / İndirme Sayısı: 15) ]]> <![CDATA[Fransa'da 700 Süpermarketin Soğutma Sistemi Hacklendi: Danfoss ve Copeland Saldırısı]]> https://www.turkteam.org/konu-fransa-da-700-supermarketin-sogutma-sistemi-hacklendi-danfoss-ve-copeland-saldirisi.html Fri, 16 Oct 2026 11:11:02 +0300 Tonyukuk]]> https://www.turkteam.org/konu-fransa-da-700-supermarketin-sogutma-sistemi-hacklendi-danfoss-ve-copeland-saldirisi.html [Resim: attachment.php?aid=5]
Fransa'da Süpermarket Soğutma Sistemlerine Siber Saldırı: IoT ve OT Güvenliği İçin Ağır Bir Ders

Merhaba arkadaşlar,

Bu hafta siber güvenlik dünyasının en çok konuşulan olaylarından biri bir veri sızıntısı ya da fidye yazılımı değil, buzdolapları oldu. Fransa'da yüzlerce süpermarketin soğutma kontrol sistemleri uzaktan ele geçirildi; reyonlardaki gıdalar bozuldu, bazı mağazalarda yangın çıktı. Olay, internete açık bırakılan endüstriyel kontrol cihazlarının ne kadar gerçek ve fiziksel bir risk olduğunu bir kez daha gösterdi.

Konuda Anlatılacaklar
  1. Ne oldu? Olayın zaman çizelgesi
  2. Hangi cihazlar etkilendi?
  3. Saldırının fiziksel etkileri ve rakamlar
  4. Neden bu kadar kolay oldu? İnternete açık OT cihazları
  5. CERT-FR önerileri ve kendi cihazlarınızı nasıl kontrol edersiniz
  6. Kaynakça

1) Ne Oldu?
Fransa'nın ulusal siber güvenlik ajansı ANSSI bünyesindeki CERT-FR, 12 Ekim 2026'da Danfoss'un AK-SM ve AK-SC serisi soğutma kontrolcülerini etkileyen çok sayıda ele geçirme vakası için uyarı yayımladı. Bir gün sonra uyarı güncellenerek Copeland XWEB ve Dixell XWEB sistemleri de kapsama alındı. Copeland önce bulguları doğrulamaktan kaçınsa da daha sonra bir zafiyet olduğunu kabul ederek etkilenen müşterilerle çalıştığını açıkladı.

Saldırganların cihazlara nasıl eriştiği henüz net değil. CERT-FR uyarısı olayları belirli bir zafiyete bağlamıyor. Bu yaz Claroty, Danfoss AK-SM 800A'da açıklar ve Copeland XWEB Pro kontrolcüsünde 23 zafiyet yayımlamıştı (Copeland bunları bir firmware güncellemesiyle kapattı); ancak ne Danfoss ne de Fransız yetkililer saldırıyı bu açıklarla ilişkilendirdi.

2) Hangi Cihazlar Etkilendi?
Danfoss'a göre etkilenen cihazların çoğu destek süresi dolmuş eski modeller:
  • AK-SM 800: Desteği Mayıs 2021'de sona erdi.
  • AK-SC 355: 2016'da üretimden kaldırıldı.
  • Ayrıca güncel olmayan firmware çalıştıran bazı AK-SM 800A cihazları.
  • Copeland/Dixell XWEB ailesi (CERT-FR güncellemesiyle eklendi).

3) Fiziksel Etkiler ve Rakamlar
  • Fransa Maliye Bakanı Roland Lescure'ün milletvekillerine verdiği bilgiye göre ülkedeki yaklaşık 10.000 süpermarketten yaklaşık 700'ü etkilendi (ilk raporlar 300-350 diyordu).
  • Carrefour, Coopérative U, E.Leclerc, Intermarché ve Monoprix etkilendiğini doğruladı. Intermarché'de yaklaşık 150, Carrefour'da 80 mağaza etkilendi.
  • Intermarché'de soğutma üniteleri altı saat boyunca 50 santigrat derecede çalıştı ve tüm gıdalar imha edildi.
  • Le Monde'a göre saldırganlar buz çözme (defrost) döngülerini bir saatten sekiz saate kadar uzatarak alarmların geç çalmasını sağladı.
  • Paris savcılığı siber suçlar birimi soruşturma başlattı; savcılık gıda kaybının yanı sıra yangınlar da yaşandığını açıkladı. Alsace'taki iki süpermarketin toplam kaybı 270.000 avro.
  • Ne bir sorumluluk üstlenme ne de fidye talebi var; Reuters'ın kaynağına göre bu durum müfettişleri şaşırtmış durumda.
  • Sekoia araştırmacısı Félix Aimé'ye göre İspanya, Portekiz, Polonya, Almanya ve Belçika'daki mağazalar da etkilendi.

4) Neden Bu Kadar Kolay Oldu?
Sorunun özü çok tanıdık: Yönetim arayüzleri doğrudan internete açık bırakılmış endüstriyel cihazlar. Censys'in ölçümlerine göre 11 Ekim'de internete açık yaklaşık 3.000 Danfoss StoreView kontrol paneli vardı ve bunların 1.800'den fazlası Fransa'daydı. 14 Ekim'e gelindiğinde Fransa'daki sayı 537'ye düştü. Censys'in dikkat çektiği nokta şu: Yamalı ve yamasız sürümler aynı hızda kayboldu; yani operatörler cihazları güncellemek yerine internetten kopararak çözüm buldu.

Bu olay IoT/OT güvenliğinin klasik üç hatasını bir arada gösteriyor:
  1. Destek süresi dolmuş, artık yama almayan cihazların sahada çalışmaya devam etmesi
  2. Uzaktan bakım kolaylığı için yönetim panellerinin doğrudan internete açılması
  3. Cihazların sorumluluğunun tedarikçi ile işletme arasında belirsiz kalması (Les Mousquetaires, sistemlerin Danfoss tarafından yönetildiğini söyledi)

5) CERT-FR Önerileri ve Kendi Kontrolünüz
CERT-FR'nin önerileri net:
  • Etkilenen kontrolcüleri internetten kaldırın; uzaktan erişimi yalnızca güvenli bir VPN veya korumalı ağ üzerinden verin.
  • IP adresine göre filtreleme yalnızca geçici acil durum önlemi olarak kabul edilebilir.
  • Ele geçirilmiş destek süresi dolmuş cihazlarda fabrika ayarlarına dönmek yeterli değil; cihaz açık kalmaya devam ederse tekrar ele geçirilir.

Kendi kurumunuzun dış IP bloğunda, yetkiniz dahilinde, bilinen OT/IoT yönetim portlarının açık olup olmadığını kontrol etmek için basit bir Nmap taraması kullanabilirsiniz:
Kod:
# Sadece kendi/yetkili olduğunuz IP aralığında çalıştırın nmap -Pn -sV -p 80,443,8080,8443,502,47808,1911,4911 --open 203.0.113.0/28 -oN ot_dis_yuzey.txt
Yukarıdaki 203.0.113.0/28 belgeleme amaçlı örnek bir bloktur; kendi kurumunuzun bloğuyla değiştirin. 502 (Modbus), 47808 (BACnet), 1911/4911 (Niagara Fox) gibi portlar internete açık görünüyorsa bu durum doğrudan acil durum maddesidir.

Ek kontrol listesi:
  • Bina otomasyonu, soğutma, HVAC ve enerji izleme cihazlarının envanterini çıkarın; her biri için firmware sürümü ve destek bitiş tarihi kaydedin.
  • OT cihazlarını kurumsal ağdan ve internetten ayrı bir VLAN/bölgede tutun.
  • Tedarikçi uzaktan erişimini kalıcı açık port yerine zaman sınırlı, kayıt altına alınan VPN oturumlarıyla verin.
  • Kritik süreçlerde (sıcaklık eşikleri, defrost süreleri) yapılan yapılandırma değişikliklerine alarm kuralı yazın.

Kaynakça
Görsel: TurkTeam özgün kapak görseli.

Alıntı:Yasal Uyarı: Bu konudaki tarama örnekleri yalnızca sahibi olduğunuz veya yazılı izin aldığınız sistemlerde kullanılmalıdır. İzinsiz tarama ve sistemlere erişim, 5237 sayılı TCK'nın 243-245. maddeleri kapsamında suç teşkil eder.


.jpg   tonyukuk-03-supermarket.jpg (Dosya Boyutu: 120.92 KB / İndirme Sayısı: 7) ]]> [Resim: attachment.php?aid=5]
Fransa'da Süpermarket Soğutma Sistemlerine Siber Saldırı: IoT ve OT Güvenliği İçin Ağır Bir Ders

Merhaba arkadaşlar,

Bu hafta siber güvenlik dünyasının en çok konuşulan olaylarından biri bir veri sızıntısı ya da fidye yazılımı değil, buzdolapları oldu. Fransa'da yüzlerce süpermarketin soğutma kontrol sistemleri uzaktan ele geçirildi; reyonlardaki gıdalar bozuldu, bazı mağazalarda yangın çıktı. Olay, internete açık bırakılan endüstriyel kontrol cihazlarının ne kadar gerçek ve fiziksel bir risk olduğunu bir kez daha gösterdi.

Konuda Anlatılacaklar
  1. Ne oldu? Olayın zaman çizelgesi
  2. Hangi cihazlar etkilendi?
  3. Saldırının fiziksel etkileri ve rakamlar
  4. Neden bu kadar kolay oldu? İnternete açık OT cihazları
  5. CERT-FR önerileri ve kendi cihazlarınızı nasıl kontrol edersiniz
  6. Kaynakça

1) Ne Oldu?
Fransa'nın ulusal siber güvenlik ajansı ANSSI bünyesindeki CERT-FR, 12 Ekim 2026'da Danfoss'un AK-SM ve AK-SC serisi soğutma kontrolcülerini etkileyen çok sayıda ele geçirme vakası için uyarı yayımladı. Bir gün sonra uyarı güncellenerek Copeland XWEB ve Dixell XWEB sistemleri de kapsama alındı. Copeland önce bulguları doğrulamaktan kaçınsa da daha sonra bir zafiyet olduğunu kabul ederek etkilenen müşterilerle çalıştığını açıkladı.

Saldırganların cihazlara nasıl eriştiği henüz net değil. CERT-FR uyarısı olayları belirli bir zafiyete bağlamıyor. Bu yaz Claroty, Danfoss AK-SM 800A'da açıklar ve Copeland XWEB Pro kontrolcüsünde 23 zafiyet yayımlamıştı (Copeland bunları bir firmware güncellemesiyle kapattı); ancak ne Danfoss ne de Fransız yetkililer saldırıyı bu açıklarla ilişkilendirdi.

2) Hangi Cihazlar Etkilendi?
Danfoss'a göre etkilenen cihazların çoğu destek süresi dolmuş eski modeller:
  • AK-SM 800: Desteği Mayıs 2021'de sona erdi.
  • AK-SC 355: 2016'da üretimden kaldırıldı.
  • Ayrıca güncel olmayan firmware çalıştıran bazı AK-SM 800A cihazları.
  • Copeland/Dixell XWEB ailesi (CERT-FR güncellemesiyle eklendi).

3) Fiziksel Etkiler ve Rakamlar
  • Fransa Maliye Bakanı Roland Lescure'ün milletvekillerine verdiği bilgiye göre ülkedeki yaklaşık 10.000 süpermarketten yaklaşık 700'ü etkilendi (ilk raporlar 300-350 diyordu).
  • Carrefour, Coopérative U, E.Leclerc, Intermarché ve Monoprix etkilendiğini doğruladı. Intermarché'de yaklaşık 150, Carrefour'da 80 mağaza etkilendi.
  • Intermarché'de soğutma üniteleri altı saat boyunca 50 santigrat derecede çalıştı ve tüm gıdalar imha edildi.
  • Le Monde'a göre saldırganlar buz çözme (defrost) döngülerini bir saatten sekiz saate kadar uzatarak alarmların geç çalmasını sağladı.
  • Paris savcılığı siber suçlar birimi soruşturma başlattı; savcılık gıda kaybının yanı sıra yangınlar da yaşandığını açıkladı. Alsace'taki iki süpermarketin toplam kaybı 270.000 avro.
  • Ne bir sorumluluk üstlenme ne de fidye talebi var; Reuters'ın kaynağına göre bu durum müfettişleri şaşırtmış durumda.
  • Sekoia araştırmacısı Félix Aimé'ye göre İspanya, Portekiz, Polonya, Almanya ve Belçika'daki mağazalar da etkilendi.

4) Neden Bu Kadar Kolay Oldu?
Sorunun özü çok tanıdık: Yönetim arayüzleri doğrudan internete açık bırakılmış endüstriyel cihazlar. Censys'in ölçümlerine göre 11 Ekim'de internete açık yaklaşık 3.000 Danfoss StoreView kontrol paneli vardı ve bunların 1.800'den fazlası Fransa'daydı. 14 Ekim'e gelindiğinde Fransa'daki sayı 537'ye düştü. Censys'in dikkat çektiği nokta şu: Yamalı ve yamasız sürümler aynı hızda kayboldu; yani operatörler cihazları güncellemek yerine internetten kopararak çözüm buldu.

Bu olay IoT/OT güvenliğinin klasik üç hatasını bir arada gösteriyor:
  1. Destek süresi dolmuş, artık yama almayan cihazların sahada çalışmaya devam etmesi
  2. Uzaktan bakım kolaylığı için yönetim panellerinin doğrudan internete açılması
  3. Cihazların sorumluluğunun tedarikçi ile işletme arasında belirsiz kalması (Les Mousquetaires, sistemlerin Danfoss tarafından yönetildiğini söyledi)

5) CERT-FR Önerileri ve Kendi Kontrolünüz
CERT-FR'nin önerileri net:
  • Etkilenen kontrolcüleri internetten kaldırın; uzaktan erişimi yalnızca güvenli bir VPN veya korumalı ağ üzerinden verin.
  • IP adresine göre filtreleme yalnızca geçici acil durum önlemi olarak kabul edilebilir.
  • Ele geçirilmiş destek süresi dolmuş cihazlarda fabrika ayarlarına dönmek yeterli değil; cihaz açık kalmaya devam ederse tekrar ele geçirilir.

Kendi kurumunuzun dış IP bloğunda, yetkiniz dahilinde, bilinen OT/IoT yönetim portlarının açık olup olmadığını kontrol etmek için basit bir Nmap taraması kullanabilirsiniz:
Kod:
# Sadece kendi/yetkili olduğunuz IP aralığında çalıştırın nmap -Pn -sV -p 80,443,8080,8443,502,47808,1911,4911 --open 203.0.113.0/28 -oN ot_dis_yuzey.txt
Yukarıdaki 203.0.113.0/28 belgeleme amaçlı örnek bir bloktur; kendi kurumunuzun bloğuyla değiştirin. 502 (Modbus), 47808 (BACnet), 1911/4911 (Niagara Fox) gibi portlar internete açık görünüyorsa bu durum doğrudan acil durum maddesidir.

Ek kontrol listesi:
  • Bina otomasyonu, soğutma, HVAC ve enerji izleme cihazlarının envanterini çıkarın; her biri için firmware sürümü ve destek bitiş tarihi kaydedin.
  • OT cihazlarını kurumsal ağdan ve internetten ayrı bir VLAN/bölgede tutun.
  • Tedarikçi uzaktan erişimini kalıcı açık port yerine zaman sınırlı, kayıt altına alınan VPN oturumlarıyla verin.
  • Kritik süreçlerde (sıcaklık eşikleri, defrost süreleri) yapılan yapılandırma değişikliklerine alarm kuralı yazın.

Kaynakça
Görsel: TurkTeam özgün kapak görseli.

Alıntı:Yasal Uyarı: Bu konudaki tarama örnekleri yalnızca sahibi olduğunuz veya yazılı izin aldığınız sistemlerde kullanılmalıdır. İzinsiz tarama ve sistemlere erişim, 5237 sayılı TCK'nın 243-245. maddeleri kapsamında suç teşkil eder.


.jpg   tonyukuk-03-supermarket.jpg (Dosya Boyutu: 120.92 KB / İndirme Sayısı: 7) ]]>