İlker Ünver

Yerli SIEM/OT İzleme Neden Önemli: Ambargo ve Bağımlılık Açısından

Mon, 28 Sep 2026 16:01:02 GMT

Bir güvenlik operasyonunun temelinde izleme yatar: logları toplamak, ilişkilendirmek, anomaliyi yakalamak. Bunu yapan araca genelde SIEM (Güvenlik Bilgi ve Olay Yönetimi) denir; OT tarafında ise buna özel izleme platformları vardır. Bu araçlar bir kurumun “gözü ve kulağı”dır.

Peki bu göz ve kulak dışa bağımlıysa ne olur? Bu yazı, kritik altyapı ve savunma sanayi bağlamında yerli SIEM/OT izleme kabiliyetinin neden yalnızca teknik değil, aynı zamanda stratejik bir mesele olduğunu ele alıyor. Amacım tek bir “doğru cevap” dayatmak değil; hem bağımlılık riskini hem de yerli geliştirmenin gerçek zorluklarını dürüstçe koymak.

Dış bağımlılığın katmanları

Yabancı bir güvenlik/izleme platformuna bağımlılık, birkaç ayrı riski aynı anda taşır:

Erişim riski (ambargo/lisans). Bir aracın kullanımı, üreticinin ülkesinin ihracat politikalarına bağlı olabilir. Politik bir kararla lisans yenilenmeyebilir ya da erişim kesilebilir — hem de tam ihtiyaç duyulan anda.
Güncelleme ve tehdit istihbaratı bağımlılığı. Modern izleme araçları sürekli güncellenen tehdit istihbaratıyla çalışır. Bu akış dışarıdaysa, hem kesilebilir hem de yabancı önceliklere göre şekillenir; yerel tehditler geç ya da hiç kapsanmayabilir.
Veri egemenliği. İzleme aracı, kritik altyapının en hassas verisini görür. Bu verinin yurt dışındaki sistemlere akması başlı başına bir risktir.
Denetlenebilirlik. Kapalı kaynaklı bir araca “güvenmek” zorundasındır; içinde ne olduğunu bağımsız denetleyemezsin.
Kriz anında destek belirsizliği. Gerçek bir kriz anında, dışa bağımlı desteğin devrede olacağının garantisi yoktur.

Adli bilişimden somut bir örnek

Bu tartışma soyut değil. Adli bilişim alanında Cellebrite ve MSAB gibi araçlar dünya standardıdır ve olağanüstü yeteneklidir — ama erişimleri, üretici ülkelerin politikalarına tabidir. Bir kurumun en kritik incelemesini yapabilme yeteneği, başka bir ülkenin ihracat kararına bağlı hâle gelebilir. Bu, yeteneğin kalitesiyle ilgili bir eleştiri değil; bağımlılığın doğasıyla ilgili bir gerçek. Aynı mantık OT izleme ve SIEM için de geçerlidir.

Yerli kabiliyetin sağladıkları

Yerli bir izleme/adli bilişim kabiliyeti, bu riskleri şu yönlerden azaltır:

Süreklilik — ambargodan bağımsız, kesintisiz erişim.
Veri egemenliği — hassas veri yurt içinde kalır.
Denetlenebilirlik ve uyarlanabilirlik — kaynağa hâkim olmak, hem güveni hem esnekliği artırır.
Yerel uyum — Türkçe/yerel protokoller, mevzuat (ör. kişisel veri, adli süreçler) ve yerel tehdit önceliklerine göre şekillenme.
Teknoloji ve istihdam birikimi — kabiliyeti içeride tutmak, uzun vadeli stratejik bir yatırımdır.

Dürüst olalım: yerli geliştirmenin zorlukları

Yerli kabiliyet savunusu, gerçekleri görmezden gelmemeli. Olgun yabancı araçların arkasında yıllarca AR-GE, büyük ekipler ve geniş tehdit istihbaratı ağları var. Yerli bir alternatif geliştirmek:

Zaman ve kaynak ister — olgunluk bir gecede gelmez.
Yetkin insan gücü ister — OT, gömülü ve adli bilişimi birleştiren nadir bir uzmanlık gerektirir.
Ekosistem ister — tek bir araç değil, onu besleyen istihbarat, eğitim ve destek yapısı.
“Yeniden icat” tuzağı taşır — her şeyi sıfırdan yazmak yerine, açık kaynak temeller üzerine inşa etmek çoğu zaman daha akıllıcadır.

Yani soru “yerli mi, yabancı mı?” ikilemi değil; hangi kritik kabiliyetlerin egemen olması gerektiği ve bunun nasıl, hangi temeller üzerine inşa edileceği sorusudur.

Pratik bir yol: açık kaynak temelli, yerli uyarlı

Gerçekçi bir yaklaşım, olgun açık kaynak temelleri (ağ izleme, log toplama, adli analiz çatıları) yerel ihtiyaçlara göre uyarlayıp üzerine yerli değer katmaktır: Türkçe raporlama, yerel mevzuata uygun delil çıktıları, yerel protokol desteği, yerel tehdit istihbaratı entegrasyonu. Bu, hem “her şeyi sıfırdan yazma” yükünü hafifletir hem de egemenlik kazandırır. Bu yaklaşım, gömülü/OT geçmişiyle adli bilişimi birleştiren uzmanlar için doğal bir çalışma alanı — çünkü bu araçların en zor kısmı (gömülü cihaz analizi, kimliksiz protokol trafiğinin yorumlanması) tam da bu kesişimde yatıyor.

Adli bilişim açısı

Bu yazı, serinin bir tür kapanışı: gömülü güvenlik, OT protokolleri, firmware analizi ve OT loglaması üzerine anlattığım her şey, aslında bu stratejik resmin parçaları. Bir OT ağında delili nerede arayacağını bilmek (bkz. SCADA/PLC loglama yazısı), kimliksiz protokol trafiğini yorumlamak (bkz. Modbus, CAN yazıları), gömülü cihazdan delil çıkarmak (bkz. IoT/OT forensics yazıları) — bu becerilerin yerli olarak var olması, yerli izleme ve adli bilişim kabiliyetinin ta kendisidir. Teknik beceri ile stratejik egemenlik, burada aynı madalyonun iki yüzü.

Kapanış

Yerli SIEM ve OT izleme meselesi, “yabancı kötü, yerli iyi” gibi basit bir sloganla özetlenemez. Yabancı araçlar çoğu zaman teknik olarak üstündür; mesele onların yeteneği değil, kritik anda erişimin başkasının kararına bağlı olmasıdır. Kritik altyapı ve savunma sanayi için bazı kabiliyetlerin egemen olması, teknik bir tercih değil stratejik bir zorunluluk. Ve bu kabiliyeti inşa etmenin en gerçekçi yolu, açık temeller üzerine yerel uzmanlık ve yerel ihtiyaçları örmekten geçiyor — tam da bu serinin anlattığı becerilerin buluştuğu yerden.

Bu içerik eğitim ve strateji tartışması amaçlıdır; belirli bir ürün ya da politika önerisi değil, konunun farklı yönlerini ortaya koyan bir değerlendirmedir.

Türkiye’nin Kritik Altyapı Güvenliği: Enerji, Ulaşım, Üretim

Fri, 25 Sep 2026 16:01:02 GMT

Siber güvenlik denince akla genelde veri sızıntıları, fidye yazılımları, çalınan kredi kartları gelir. Ama bir ülkenin gerçekten savunmasız olduğu yer, çoğu zaman ekranların değil, fiziksel süreçlerin olduğu yerdir: elektrik şebekesi, doğalgaz iletimi, demiryolu sinyalizasyonu, su arıtma, fabrika otomasyonu. Bunların hepsi OT (Operasyonel Teknoloji) sistemleriyle çalışır ve bir sorun burada olduğunda sonuç dijital değil, fiziksel olur — karanlıkta kalan şehirler, duran trenler, kesilen su.

Bu yazı, Türkiye bağlamında kritik altyapı güvenliğinin neden stratejik bir öncelik olduğunu, ortak zorlukları ve bu alanda yerli kabiliyetin önemini ele alıyor.

Kritik altyapı nedir, neden kritik?

Kritik altyapı, kesintisi toplumu ve ekonomiyi doğrudan sarsan sistemlerdir. Türkiye için başlıca sektörler:

Enerji — elektrik üretim/iletim/dağıtım, doğalgaz, santraller. SCADA sistemleriyle yönetilir.
Ulaşım — demiryolu, metro, havalimanı sinyalizasyonu, trafik yönetimi.
Üretim / Sanayi — fabrikalar, otomasyon ve özellikle savunma sanayi üretim hatları.
Su ve atık su — arıtma tesisleri, dağıtım, barajlar; çoğu uzaktan izlenir.
Telekom ve finans — ağ omurgası, ödeme sistemleri.
Sağlık — hastane sistemleri, tıbbi cihazlar.

Bu sektörlerin ortak noktası: hepsi giderek daha fazla dijitalleşirken, altlarındaki OT sistemleri çoğu zaman on yıllar öncesinin teknolojisiyle çalışıyor.

Ortak zorluk: eski sistem, artan bağlanabilirlik

Kritik altyapının siber güvenlik açığı üç faktörün kesişiminden doğar:

Eski OT sistemleri. 15–20 yıllık PLC’ler, desteklenmeyen işletim sistemleri, güvenlik düşünülmeden tasarlanmış protokoller (bkz. serinin Modbus yazısı). Bunları güncellemek ya da değiştirmek çoğu zaman mümkün ya da ekonomik değil.
Artan bağlanabilirlik. Verimlilik ve uzaktan yönetim için bu eski sistemler artık ağlara, hatta internete bağlanıyor. Kapalı tasarlanmış bir sistemi açık bir dünyaya bağlamak, saldırı yüzeyini büyütüyor.
Tedarik zinciri ve dış bağımlılık. Donanım, yazılım ve izleme araçlarının önemli kısmı dış kaynaklı. Bu, hem teknik hem stratejik bir bağımlılık yaratıyor.

Bu üçünün kesişimi, giderek büyüyen bir ulusal saldırı yüzeyi anlamına geliyor.

Neden stratejik bir mesele?

Kritik altyapıya yönelik siber tehditler artık teorik değil. Dünya genelinde enerji şebekelerine, su tesislerine ve üretim sistemlerine yönelik olaylar yaşandı. Bu tür sistemlerin ortak dersi şu: bir OT olayı, bir veri sızıntısından farklı olarak fiziksel ve ulusal güvenlik boyutu taşır.

Türkiye’nin konumu bunu daha da önemli kılıyor: büyüyen bir enerji altyapısı, gelişen bir savunma sanayi, ve giderek dijitalleşen bir üretim ekonomisi. Bu varlıkları korumak, klasik IT güvenliğinin ötesinde, OT’ye özgü kabiliyet gerektiriyor.

Yerli kabiliyetin önemi

Kritik altyapı güvenliğinde dışa bağımlılık iki katmanlı bir risktir: hem teknik (denetlenemeyen kapalı sistemler) hem stratejik (ambargo ya da politik kararla erişimin kesilmesi). Bu yüzden yerli OT izleme, adli bilişim ve güvenlik kabiliyeti geliştirmek — TÜBİTAK BİLGEM, savunma sanayi kurumları ve özel sektörün ortak gündemi — giderek stratejik bir gereklilik hâline geliyor. Bu konuyu serinin son yazısında (yerli SIEM/OT izleme) ayrıca ele alıyorum.

Savunma tarafı: nereden başlanır

Envanter ve görünürlük — neyin bağlı olduğunu bilmeden korunamaz; OT varlık envanteri çıkar.
Segmentasyon — IT/OT ayrımı ve Purdue modeli (bkz. ilgili yazı).
Pasif izleme — süreci bozmadan anomali tespiti.
Olay müdahale planı — OT’ye özgü, “önce süreci koru” mantığıyla.
Yerli kabiliyet yatırımı — uzun vadeli stratejik bağımsızlık.

Adli bilişim açısı

Bir kritik altyapı olayında adli bilişim, hem “ne oldu”yu anlamak hem de gelecekteki savunmayı şekillendirmek için hayatidir. Ama OT ortamında bu iş, klasik adli bilişimden farklı beceriler ister: canlı ve seçici delil toplama, pasif ağ kaydı, gömülü cihaz analizi (bkz. serinin IoT/OT forensics yazıları). Bu becerileri yerli olarak geliştirmek, kritik altyapı güvenliğinin ayrılmaz bir parçası — çünkü bir enerji santralinin adli incelemesini dışarıya bağımlı yapmak, başlı başına bir risktir.

Kapanış

Kritik altyapı güvenliği, bir ülkenin en sessiz ama en önemli savunma hattıdır. Türkiye için enerji, ulaşım ve üretim sistemlerinin korunması, eski OT teknolojisi ile artan bağlanabilirliğin kesişiminde giderek zorlaşıyor. Bu zorluğun cevabı yalnızca teknik değil aynı zamanda stratejik: OT güvenliği, izleme ve adli bilişimde yerli kabiliyet geliştirmek. Görünmez altyapıyı korumak, artık görünür bir öncelik olmalı.

Bu içerik eğitim ve farkındalık amaçlıdır.

Bir SCADA/PLC Ağında Ne Loglanır, Olay Sonrası Ne Kalır

Wed, 23 Sep 2026 16:01:03 GMT

Klasik bir adli bilişim incelemesinde loglar bolca akar: olay günlükleri, kayıt defteri, uygulama izleri. OT dünyasına geçtiğinde ise bu bolluk yerini bir kıtlığa bırakır. Bir PLC’ye “geçen hafta ne oldu?” diye sorduğunda çoğu zaman cevap alamazsın — çünkü o PLC kalıcı bir günlük tutmuyordur.

Bu yazı, bir SCADA/PLC ağının hangi katmanında ne loglandığını, bir olay sonrasında geriye ne kaldığını ve adli açıdan delili nerede aramak gerektiğini katman katman inceliyor.

Seviye 1 — PLC/RTU: en zayıf halka

Kontrol katmanındaki PLC ve RTU’lar, adli açıdan en fakir kaynaklardır. Nedenleri:

Kalıcı log genelde yok. Kaynak kısıtlı bu cihazlar, sürekli bir günlük yazmak için ne belleğe ne de yazma döngüsü bütçesine sahiptir.
Durum uçucudur. Register değerleri, çalışan mantık ve bağlantı durumu bellekte durur; güç kesilince kaybolur.
Sınırlı olay tamponu. Bazı modeller küçük bir olay tamponu tutar ama bu hızla döner (yeni olay eskisini siler).

Sonuç: bir PLC size ne olduğunu doğrudan söyleyemez. Delil kaçıcıdır ve çoğu zaman canlı toplama gerektirir (bkz. serinin “log yok” yazısı).

Seviye 2 — SCADA/HMI: operatörün penceresi

Denetim katmanı daha zengindir. SCADA ve HMI sistemleri, yapılandırmaya bağlı olarak şunları loglayabilir:

Operatör eylemleri — kim, ne zaman, hangi komutu verdi.
Alarmlar — hangi eşik ne zaman aşıldı.
Set-point değişiklikleri — bir sürecin hedef değeri ne zaman, kime göre değişti.

Bu loglar bir olayı anlamak için çok değerlidir, çünkü insan-süreç etkileşimini gösterir. Ama kritik uyarı: bu loglama varsayılan olarak yeterli yapılandırılmamış olabilir. Denetim penceresinin ne kadar geriye gittiği ve neyi kaydettiği, kurulum zamanı verilen kararlara bağlıdır.

Seviye 3 — Historian: altın kaynak

OT dünyasının en değerli adli kaynağı çoğu zaman historian’dır. Historian, proses verisini zaman serisi olarak uzun süreli saklayan bir veritabanıdır — sıcaklıklar, basınçlar, akışlar, durumlar, saniye saniye kaydedilir.

Adli açıdan historian bir hazinedir: bir olayın öncesindeki ve sırasındaki proses davranışını yeniden kurabilirsin. Bir anomali — beklenmedik bir basınç düşüşü, olağan dışı bir komut deseni — historian’ın zaman serisinde görünür hâle gelir. Bu yüzden bir OT incelemesinde ilk bakılan yerlerden biridir.

Ağ ve DMZ: kimliksiz protokoller için tek delil

En kritik katmanlardan biri ağ tarafıdır. Neden? Çünkü OT protokollerinin çoğu (Modbus, DNP3, CAN) kimlik doğrulaması yapmaz ve cihaz tarafında iz bırakmaz (bkz. serinin Modbus yazısı). Bu durumda “kim, ne zaman, hangi komutu gönderdi” sorusunun tek cevabı ağ trafiğidir.

Bu yüzden OT ağlarında:

DMZ güvenlik duvarı logları — seviyeler arası geçişleri gösterir.
Pasif pcap kaydı — süreci hiç bozmadan tüm trafiği kaydeder; kimliksiz protokoller için en güvenilir delildir.

Pasif ağ kaydı, OT adli bilişiminin en önemli yatırımıdır — cihazlar susarken ağ konuşur.

Savunma tarafı: olaydan önce loglamayı hazırla

Adli açıdan en büyük hata, olaydan sonra “keşke loglasaydık” demektir. Öncelikler:

SCADA/HMI loglamasını doğru yapılandır — operatör eylemleri ve alarmlar kaydedilmeli.
Historian’ı koru — kritik proses verisinin bütünlüğünü ve saklama süresini güvence altına al.
Pasif ağ kaydı kur — kritik segmentlerde sürekli pcap.
Merkezî toplama — logları güvenli, değiştirilemez bir yerde topla (OT-uyumlu bir izleme/SIEM).
Zaman senkronizasyonu — tüm katmanlarda ortak, güvenilir zaman kaynağı; timeline bununla anlam kazanır.

Adli bilişim açısı

OT loglamasının katmanlı doğası, adli stratejiyi belirler: aşağı katmanlar (PLC) delil bakımından fakir, yukarı katmanlar (historian, ağ) zengindir. Bu yüzden bir OT incelemesinde delil aramayı yukarı katmanlara ve ağa kurmak gerekir. Ayrıca kimliksiz protokoller nedeniyle pasif ağ kaydı, OT/IoT forensics’in temel taşıdır — serinin CAN timeline ve Modbus yazılarında bunun somut örneklerini işledim. Bu katmanlı düşünme biçimi, klasik disk adli bilişiminden gelen birinin OT’de yeniden öğrenmesi gereken bir haritadır.

Kapanış

Bir SCADA/PLC ağında delil eşit dağılmaz: PLC susar, SCADA yapılandırmaya göre konuşur, historian ve ağ ise çok şey saklar. Bir OT olayında elde ne kaldığını belirleyen şey, olaydan önce loglamayı ne kadar iyi hazırladığındır. “Aşağıya inip PLC’ye sormak” yerine “yukarıya çıkıp historian ve ağa bakmak” — OT adli bilişiminin altın kuralı.

Bu içerik eğitim amaçlıdır.

Purdue Modeli: Endüstriyel Ağı Katmanlara Bölmek

Mon, 21 Sep 2026 16:01:02 GMT

Bir önceki yazıda IT ve OT güvenliğinin neden farklı öncelikler taşıdığını konuştuk. Peki bu farkı sahada nasıl uygulamaya dökeriz? Cevabın büyük kısmı mimaride — endüstriyel ağı nasıl kurduğunda. Ve OT dünyasının bu konudaki ortak dili Purdue modelidir.

Purdue modeli (Purdue Enterprise Reference Architecture’dan gelir), bir endüstriyel kontrol sistemini işlevsel seviyelere böler. Amaç basit ama güçlü: fiziksel sürecin en kritik olduğu katmanları, en az güvenilir olan kurumsal ve internet katmanlarından ayırmak. Bu yazı modeli katman katman açıklıyor.

Seviyeler: fiziksel süreçten kurumsala

Model aşağıdan yukarıya doğru güven ve kritiklik azalır:

Seviye 0 — Fiziksel süreç. Sensörler, aktüatörler, motorlar, valfler. Gerçek dünyaya dokunan katman. Bir hata burada fiziksel sonuç doğurur.
Seviye 1 — Kontrol. PLC’ler, RTU’lar, DCS’ler. Seviye 0’ı okuyup komut veren “beyinler”.
Seviye 2 — Denetim. SCADA ve HMI sistemleri. Operatörün süreci izleyip yönettiği katman.
Seviye 3 — Operasyon yönetimi. MES (üretim yürütme), veri tarihçesi (historian), üretim optimizasyonu. OT’nin en üst katmanı.
Seviye 4 — İş lojistiği. Üretim planlama, IT sistemleri. Artık kurumsal dünyaya geçiş.
Seviye 5 — Kurumsal ağ. ERP, e-posta, internet. En az güvenilir, en açık katman.

Kritik nokta: DMZ (Seviye 3.5)

Modelin kalbi, Seviye 3 (OT) ile Seviye 4 (IT) arasındaki sınırdır. Buraya genelde bir DMZ (silahtan arındırılmış bölge) yerleştirilir — bir tampon katman. IT ve OT’nin doğrudan konuşmasına izin verilmez; tüm trafik bu DMZ üzerinden, sıkı kurallarla geçer.

Neden bu kadar önemli? Çünkü çoğu ciddi OT olayı, bir saldırganın IT tarafından (ör. bir oltalama e-postasıyla) girip OT’ye doğru ilerlemesiyle olur. Sağlam bir IT/OT sınırı, bu yanal hareketi durduran ana settir. DMZ olmadan, kurumsal ağdaki bir ihlal doğrudan üretim hattına ulaşabilir.

Modelin gücü ve sınırları

Gücü: Purdue, “neyin nereye bağlanabileceği” konusunda ortak, anlaşılır bir dil sunar. Bir denetimde ya da tasarımda “bu cihaz Seviye 1’de, doğrudan Seviye 4’e bağlanmamalı” demek, herkesin anladığı bir cümledir. Segmentasyonu somutlaştırır.

Sınırları: Model 1990’ların katı, hiyerarşik fabrikası için tasarlandı. Bugünün dünyasında sınırlar bulanıklaşıyor: IIoT cihazları doğrudan buluta bağlanıyor, uzaktan bakım katmanları atlıyor, kablosuz bağlantılar hiyerarşiyi deliyor. Purdue hâlâ değerli bir zihinsel çerçeve ama artık tek başına yeterli değil; sıfır güven (zero trust) yaklaşımlarıyla tamamlanıyor.

Savunma tarafı: modeli uygulamak

Katmanları gerçekten ayır — güvenlik duvarları ve VLAN’larla seviyeler arası trafiği kısıtla.
DMZ’yi kur — IT/OT arasında doğrudan bağlantıya asla izin verme.
Seviye atlamayı yakala — bir Seviye 1 cihazının internete konuşması bir alarmdır.
Uzaktan erişimi kontrol et — bakım bağlantıları modelin en zayıf noktasıdır; sıkı yönet.
Modeli güncel tut — IIoT ve bulut bağlantılarını haritaya dahil et, görmezden gelme.

Adli bilişim açısı

Bir OT olayında Purdue modeli, incelemenin haritasıdır. “Saldırgan hangi seviyeye kadar indi?” sorusu, olayın ciddiyetini belirler. Seviye 4’te kalmış bir ihlal ile Seviye 1’e (PLC’lere) ulaşmış bir ihlal tamamen farklı sonuçlar taşır. Adli açıdan, seviyeler arası trafiği kaydeden noktalar (DMZ güvenlik duvarı logları, historian kayıtları, SCADA logları) delilin toplandığı yerlerdir. Modbus gibi kimliksiz protokoller Seviye 1–2’de delil bırakmadığından (bkz. serinin Modbus yazısı), sınır noktalarındaki kayıtlar kritik önem taşır.

Kapanış

Purdue modeli, OT güvenliğinin harita ve pusulasıdır. Endüstriyel ağı seviyelere bölerek, en kritik olanı en açık olandan ayırır ve IT/OT sınırını somutlaştırır. Modern bağlanabilirlik onu esnetse de, temel fikir hâlâ geçerli: fiziksel sürece dokunan katmanı, internete dokunan katmandan olabildiğince uzak tut. Bir OT ağını anlamak ya da savunmak istiyorsan, önce onu Purdue seviyelerinde okumayı öğren.

Bu içerik eğitim amaçlıdır.

IT Güvenliği ile OT Güvenliği Neden Aynı Şey Değil: Availability vs Confidentiality

Fri, 18 Sep 2026 16:01:02 GMT

Siber güvenlik eğitimi neredeyse tümüyle IT dünyası üzerine kuruludur: veri sızıntısı, kimlik hırsızlığı, fidye yazılımı, ağ savunması. Bu dünyada temel içgüdü nettir — veriyi koru. Bir şüphe anında sistemi izole et, kapat, trafiği kes; önemli olan gizli kalması gereken bilginin sızmamasıdır.

Sonra OT (Operasyonel Teknoloji) sahasına çıkarsın — bir fabrika, bir enerji santrali, bir su tesisi — ve bu içgüdünün seni yanlış yola götürdüğünü fark edersin. Çünkü OT’de öncelikler tersine dönmüştür. Bu yazı, IT ve OT güvenliğinin neden farklı meslekler olduğunu, o ünlü CIA üçlüsünün nasıl baş aşağı döndüğü üzerinden anlatıyor.

CIA üçlüsü ve IT’nin önceliği

Güvenliğin klasik üçlüsü: Confidentiality (gizlilik), Integrity (bütünlük), Availability (erişilebilirlik). IT dünyasında öncelik sırası genelde tam bu sıradadır: C → I → A.

Bir banka düşün. En kötü senaryo müşteri verisinin çalınmasıdır (gizlilik ihlali). Sistemin birkaç saat kapalı kalması can sıkıcıdır ama veri sızıntısının yanında ikincil kalır. Bu yüzden IT güvenlikçisinin refleksi: şüphe varsa durdur ve koru. Sistemi kapatmak meşru, hatta çoğu zaman doğru bir savunmadır.

OT’de öncelik neden tersine döner

Şimdi bir elektrik santralini ya da bir su arıtma tesisini düşün. Burada en kritik şey sürecin kesintisiz ve güvenli devam etmesidir. Öncelik sırası: A → I → C.

Availability (erişilebilirlik) en üstte. Bir türbini, bir pompayı, bir üretim hattını durdurmak yalnızca para kaybı değil; bazen fiziksel tehlike, çevresel felaket ya da insan hayatı riski demektir. OT’de “şüphe varsa kapat” felaket olabilir.
Integrity (bütünlük) ikinci. Bir sensör verisinin ya da bir kontrol komutunun değiştirilmesi, fiziksel dünyada yanlış kararlara yol açar — yanlış basınç, yanlış sıcaklık, yanlış hız.
Confidentiality (gizlilik) en altta. Bir PLC’nin register değerinin gizli kalması, bir sürecin durmasından çok daha az kritiktir.

Buna genelde “emniyet (safety)” boyutu da eklenir: OT’de güvenlik yalnızca veriyi değil, insanları ve fiziksel dünyayı korumaktır.

Bu farkın pratik sonuçları

Öncelik tersine dönünce, IT’de doğru olan pek çok şey OT’de yanlış olur:

Yama yönetimi: IT’de “hemen yama geç.” OT’de bir yama süreci durdurabilir; yama pencereleri aylar sürebilir, bazı sistemler hiç yamalanamaz.
Antivirüs/EDR: IT’de standart. OT’de bir tarama, gerçek zamanlı bir kontrolcüyü yavaşlatıp süreci bozabilir.
Ağ izolasyonu: IT’de “şüpheli cihazı kes.” OT’de bir cihazı kesmek bir prosesi durdurabilir.
Cihaz ömrü: IT’de 3–5 yıl. OT’de 15–20 yıl; hâlâ Windows XP ya da desteklenmeyen sistemler sahada.
Belirlenmişlik: OT’de milisaniyelik zamanlama kritik; güvenlik önlemi gecikme yaratamaz.

Bu yüzden OT güvenliği “IT güvenliğini fabrikaya taşımak” değildir; kendi kurallarıyla ayrı bir disiplindir.

Savunma tarafı: OT’ye özgü yaklaşım

Pasif izleme öncelikli — aktif tarama yerine ağı dinleyerek gözle; süreci bozma.
Segmentasyon — IT ve OT’yi ayır, katmanla (bkz. serinin Purdue modeli yazısı).
Kesintisizliği koru — savunma önlemleri sürecin availability’sini tehdit etmemeli.
Emniyet sistemlerini ayrı tut — güvenlik (safety) katmanı bağımsız olmalı.
Değişimi dikkatle planla — her müdahale bir bakım penceresi ve risk analizi gerektirir.

Adli bilişim açısı

Öncelik farkı adli bilişime doğrudan yansır. IT olayında refleks “sistemi imajla, sonra analiz et”tir. OT olayında sistemi durdurmak çoğu zaman mümkün değildir; canlı, seçici delil toplama ve pasif ağ kaydı öne çıkar (bkz. serinin IoT/OT forensics ve “log yok” yazıları). Bir OT olay müdahalesinde “önce kapat” değil, “önce süreci koru, sonra delili topla” mantığı geçerlidir. Bu, klasik DFIR eğitiminin doğrudan aktarılamayacağı, gömülü/OT bilgisi gerektiren bir alandır.

Kapanış

IT ve OT güvenliği aynı kelimeleri kullanır ama farklı diller konuşur. Aradaki temel fark, o CIA üçlüsünün baş aşağı dönmesinde saklı: IT veriyi korur, OT süreci ve insanı korur. Bu farkı içselleştirmeyen bir güvenlikçi, en iyi niyetle bir prosesi durdurup gerçek zarar verebilir. OT güvenliğine geçmek, yeni araçlar öğrenmekten önce önceliklerini yeniden sıralamayı gerektirir.

Bu içerik eğitim amaçlıdır.

🦅 gokdogan

Wed, 16 Sep 2026 23:23:45 GMT

Statik PE Malware Triyaj Motoru

OTA Güncelleme Zincirini Kırmak: İmza Doğrulaması Nerede Zayıf

Wed, 16 Sep 2026 16:01:03 GMT

Modern gömülü cihazlar sahaya çıktıktan sonra da güncellenir: yeni özellik, hata düzeltmesi, güvenlik yaması hepsi OTA (Over-The-Air) güncellemelerle gelir. Bu, güvenlik açısından hayati bir yetenektir — bir zafiyeti sahadaki milyonlarca cihazda uzaktan kapatabilmek büyük bir güç.

Ama aynı güç ters yönde de çalışır. Eğer bir saldırgan güncelleme kanalını kandırıp cihaza kendi yazılımını yükletebiliyorsa, bu tek bir zafiyetin ötesinde — cihaz üzerinde kalıcı ve tam kontrol demektir. Bu yazı, OTA zincirinin nerelerde zayıfladığını savunma perspektifinden inceliyor. (Burada hiçbir operasyonel istismar adımı yok; amaç zafiyet sınıflarını tanıyıp doğru savunmayı kurmak.)

Sağlam bir OTA zinciri neye benzer?

İdeal akış şöyledir: üretici firmware’i kriptografik olarak imzalar, dağıtım sunucusuna koyar, cihaz indirir ve — en kritik adım — kurmadan önce imzayı doğrular. İmza geçerliyse ve sürüm ileriyse kurar; değilse reddeder. Güvenlik, tam olarak cihazın bu doğrulamayı doğru yapmasına bağlıdır.

Zincirin halkaları: imzalama (üretici) → dağıtım (CDN) → doğrulama (cihaz) → kurulum. Zayıflıklar neredeyse her zaman doğrulama halkasında yoğunlaşır.

Zayıf halka 1 — İmza hiç doğrulanmıyor

En sık ve en vahim durum: cihaz imzayı hiç doğrulamaz, yalnızca taşıma güvenliğine (HTTPS) güvenir. Mantık şudur: “Bağlantı şifreli, o hâlde gelen dosya güvenli.” Ama HTTPS yalnızca yolu korur, dosyanın kaynağını değil. Sertifika doğrulaması zayıfsa ya da saldırgan dağıtım sunucusuna erişebiliyorsa, cihaz sahte bir firmware’i sorgusuz kabul eder. Taşıma güvenliği, imza doğrulamasının yerini tutmaz.

Zayıf halka 2 — İmza değil, sadece checksum

Bazı cihazlar bir “doğrulama” yapar ama bu kriptografik bir imza değil, basit bir CRC/checksum’dır. Checksum yalnızca dosyanın bozulmadan geldiğini gösterir — kaynağını değil. Bir saldırgan istediği firmware’i üretip doğru checksum’ı kolayca hesaplayabilir. Bütünlük ile özgünlük (authenticity) farklıdır; OTA’da gereken ikincisidir.

Zayıf halka 3 — Rollback (geri alma) engellenmiyor

Cihaz imzayı düzgün doğrulasa bile, eski ama geçerli imzalı bir sürümü kabul ediyorsa sorun var. Saldırgan, bilinen bir zafiyeti olan eski (ama meşru imzalı) bir sürüme cihazı düşürebilir. Buna rollback saldırısı denir. Çözüm, cihazın sürüm numarasını takip edip geriye gitmeyi reddetmesidir (anti-rollback sayaçları).

Zayıf halka 4 — Anahtar yönetimi

Tüm imza şeması, imzalama anahtarının gizliliğine dayanır. Eğer bu anahtar zayıfsa, sızmışsa ya da (kötü bir tasarımla) firmware’in içine gömülüyse ve tüm cihazlarda ortaksa — bkz. serinin sır avı yazısı — imza koruması pratikte çöker. Saldırgan anahtarı ele geçirdiğinde kendi firmware’ini meşru gibi imzalayabilir.

Savunma tarafı: sağlam OTA

Kriptografik imza zorunlu — her güncelleme kurulmadan önce imzası doğrulanmalı, checksum yeterli değil.
Doğrulama cihazda, güven kökünde — imza, secure boot güven köküne bağlı bir anahtarla doğrulanmalı (bkz. secure boot yazısı).
Anti-rollback — sürüm sayacı ile eski sürüme düşürme engellenmeli.
Güvenli anahtar yönetimi — imzalama anahtarı çevrimdışı ve korunaklı; cihaza asla gömülmez.
Taşıma + özgünlük birlikte — HTTPS kullan ama ona güvenme; imza ayrı bir katmandır.
Atomik ve kurtarılabilir kurulum — bozuk/kesintili güncellemede cihaz güvenli bir duruma dönebilmeli.

Adli bilişim açısı

OTA, bir olay incelemesinde çift yönlü ilgi çeker. Bir yandan, kötü niyetli bir firmware güncellemesi bir saldırının kalıcılık (persistence) mekanizması olabilir; incelemede firmware sürüm geçmişi, imza kayıtları ve güncelleme logları kritik delillerdir. Öte yandan, cihazdaki firmware’in beklenen sürüm ve imzayla eşleşip eşleşmediğini doğrulamak, cihazın kurcalanıp kurcalanmadığını gösterir. EV şarj ünitelerinden OT geçitlerine kadar, OTA güvenliği hem savunmanın hem adli analizin buluştuğu noktadır (bkz. serinin EV şarj tehdit modelleme yazısı).

Kapanış

OTA, gömülü güvenliğin en yüksek kaldıraçlı noktası: doğru kurulduğunda sahadaki tüm cihazları koruyabilir, yanlış kurulduğunda hepsini aynı anda riske atar. Zincirin gücü en zayıf halkasına eşittir ve o halka neredeyse her zaman doğrulamadır. “İndirdim ve kurdum” ile “indirdim, imzasını doğruladım, sürümünü kontrol ettim ve kurdum” arasındaki fark; bir cihazın güvenli mi yoksa uzaktan ele geçirilebilir mi olduğunu belirler.

Bu içerik tamamen savunma ve zafiyet farkındalığı amaçlıdır; operasyonel bir saldırı rehberi değildir.

Firmware’de Gömülü Sır Avı: Sabit Kodlanmış Anahtarlar, Parolalar, Sertifikalar

Mon, 14 Sep 2026 16:01:02 GMT

Önceki yazılarda bir firmware imajını nasıl çıkaracağını ve binwalk ile içini nasıl açacağını konuştuk. Şimdi elimizde ayıklanmış bir root dosya sistemi var ve asıl av başlıyor: sabit kodlanmış sırlar.

Sabit kodlanmış sırlar, gömülü güvenlikte hem en yaygın hem de en yüksek etkili zafiyettir. Neden yaygın? Çünkü kolaydır — geliştirici bir parolayı ya da anahtarı koda gömer, “sonra düzeltirim” der, düzeltmez. Neden yüksek etkili? Çünkü bir cihazda bulunan sır, çoğu zaman tüm filoda aynıdır; birini kırmak hepsini açar.

Nerede ar* — hedef dosyalar

Çıkarılmış dosya sisteminde ilk bakılacak yerler bellidir:

/etc/shadow, /etc/passwd — kullanıcılar ve parola hash’leri
/etc/ssl/, *.pem, *.key — özel anahtarlar ve sertifikalar
/etc/config*, *.ini, *.conf — yapılandırma dosyalarındaki düz parolalar
/www/, *.js — web arayüzü kaynak kodundaki gömülü token’lar
wpa_supplicant.conf — WiFi PSK’leri
Uygulama binary’leri — strings içinde gömülü sırlar

Teknik 1 — strings + grep

En basit ve şaşırtıcı derecede etkili yöntem: metin arama.

# İkili dosyalardaki okunabilir metinleri çıkar ve tara
strings -n 8 /bin/app | grep -iE "pass|key|secret|token|api"
# Tüm dosya sisteminde metinsel arama
grep -rniE "password|api[_-]?key|secret|BEGIN .* PRIVATE KEY" .

Çoğu zaman ilk beş dakikada bir düz parola ya da anahtar başlığı çıkar. Bu, sabit kodlanmış sırların ne kadar yaygın olduğunun kanıtıdır.

Teknik 2 — entropi taraması

Anahtarlar ve şifreli veri yüksek entropiye sahiptir. Bir dosyada olağan dışı yüksek entropili bir blok, bir anahtar adayı olabilir. binwalk’ın entropi modu ya da özel araçlar bu blokları işaretler. Yüksek entropi tek başına kanıt değildir ama “buraya bak” der.

Teknik 3 — regex ve özel araçlar

Bilinen sır formatlarını (AWS anahtarları, private key başlıkları, JWT, sabit token desenleri) arayan araçlar işi otomatikleştirir:

trufflehog, gitleaks — sır tarama araçları, firmware dosya sistemine de uygulanabilir
semgrep — kod içi sabit kodlanmış sır desenleri için

Bu tür bir taramayı otomatikleştiren, Türkçe/yerel formatları da tanıyan küçük bir açık kaynak araç, hem savunma hem de portföy açısından değerli bir katkı olabilir — regex + entropi tabanlı basit bir “firmware sır tarayıcı” ilerleyen proje yazılarında ele alacağım bir fikir.

Sık bulunan sırlar ve neden tehlikeli

Sabit root parolası: cihaza tam erişim, üstelik tüm filoda ortak.
Özel TLS anahtarı: ortadaki adam saldırılarını mümkün kılar; şifreli trafik artık güvenli değildir.
API / bulut token’ı: cihazın bağlı olduğu bulut hesabına erişim.
WiFi PSK: ağa erişim.
Ortak imzalama anahtarı: en kötüsü — saldırganın kendi firmware’ini imzalayıp OTA ile yüklemesine kapı açar (bkz. serinin OTA yazısı).
Backdoor hesap: bazen üreticinin “servis” hesabı, sahada bir arka kapıya dönüşür.

Savunma tarafı

Sırları koda gömme — en temel kural. Sırlar cihaz başına üretilmeli, koda değil.
Güvenli element / TPM — anahtarları donanımda, okunamaz biçimde sakla.
Cihaz başına benzersiz kimlik — bir cihazın sızması diğerlerini açmamalı.
Otomatik sır taraması — CI/CD hattına gömülü, her firmware yayını öncesi tara.
Parola hash’leme ve rotasyon — düz parola asla, güçlü hash her zaman.

Adli bilişim açısı

Sır avı, hem saldırı yüzeyi analizinin hem de adli incelemenin parçasıdır. Bir olay incelemesinde, bir cihazda bulunan sabit kodlanmış sır, saldırganın cihaza nasıl eriştiğini açıklayabilir. Ayrıca bir cihazın firmware’inde beklenmedik bir sır ya da hesap bulmak, cihazın kurcalandığının (ör. eklenmiş bir backdoor) işareti olabilir. Firmware analizinden çıkan bu bulgular, olay zincirinin kritik halkalarıdır.

Kapanış

Sabit kodlanmış sırlar, gömülü güvenliğin en dürüst aynasıdır: bir cihazın firmware’ini açıp içindeki parolaları ve anahtarları görmek, o cihazı yapan ekibin güvenlik olgunluğunu doğrudan gösterir. İyi haber, bu zafiyetin çözümü nettir — sırları koddan çıkar, cihaz başına üret, donanımda sakla. Kötü haber, hâlâ ne kadar yaygın olduğu. Ve tam da bu yaygınlık, sır avını gömülü analizin en verimli beceresi yapıyor.

Bu içerik eğitim amaçlıdır; yalnızca sahibi olduğun ya da yasal izinli firmware üzerinde çalış. Bulunan gerçek sırları asla ifşa etme.

UART/JTAG Debug Portları: Üretimde Unutulan Arka Kapılar

Fri, 11 Sep 2026 16:01:02 GMT

Bir gömülü cihazı ilk kez eline alan bir güvenlik araştırmacısının ya da adli bilişimcinin ilk baktığı yer nedir? Devre kartındaki test noktaları ve debug portları. Çünkü bu portlar, geliştirme sırasında cihazın en derinine — kök kabuğa, belleğe, firmware’e — erişim için tasarlanmıştır. Ve üretici bunları kapatmayı unuttuysa, aynı erişim herkese açıktır.

Bu yazı, UART ve JTAG portlarının neden bu kadar kritik olduğunu, açık bırakıldıklarında ne anlama geldiklerini ve üretimde nasıl kapatılmaları gerektiğini anlatıyor.

UART: en yumuşak giriş

UART (seri konsol), gömülü cihazlarda geliştiricinin penceresidir. Genelde kartta dört pad olarak durur: GND, TX, RX, VCC. Bir USB-UART adaptörüyle bağlandığında:

# Tipik bağlantı — genelde 115200 baud
sudo screen /dev/ttyUSB0 115200

Açık bir UART konsolu şunları verebilir: boot logları (sürüm, yapılandırma, hata), U-Boot komut istemi ve — en tehlikelisi — doğrudan bir kök kabuğu. Eğer konsol parola sormuyorsa, kartı eline alan herkes root erişimine sahiptir. Boot logları tek başına bile zafiyet keşfi için altın değerindedir.

JTAG/SWD: en derin erişim

JTAG (ve ARM tarafındaki SWD), çip seviyesinde debug için tasarlanmıştır. Bir debug probe’u ile bağlandığında belleği doğrudan okuyup yazabilir, işlemciyi durdurup adım adım çalıştırabilir, firmware’i çıkarabilirsin. Bu, UART’tan çok daha derin bir erişimdir — pratikte cihazın beynine doğrudan kablo takmak gibidir.

Bir JTAG portu açık bırakılmışsa saldırgan flash’ı okuyabilir, firmware’i çıkarabilir ve bazı durumlarda güven zincirini atlatmayı deneyebilir. Bu yüzden JTAG, üretimde en öncelikli kapatılması gereken arayüzdür.

Neden “unutuluyor”?

Bu portlar kötü niyetle açık bırakılmaz; genelde bir süreç eksikliğidir:

Üretim aceleyle biter, güvenlik sertleştirmesi (hardening) atlanır.
Test için gerekli oldukları için son ana kadar açık tutulur, sonra unutulur.
Görünmezler: kartta küçük pad’ler olarak durur, işlevsellik testinden geçer, kimse fark etmez.
Maliyet kaygısı: fuse yakmak, portları kalıcı kapatmak ek bir üretim adımıdır.

Sonuç: sahaya çıkan milyonlarca cihazda debug erişimi açık kalır.

Savunma tarafı: üretimde ne yapılmalı

Debug portlarını kalıcı olarak kapat — mümkünse fuse yakarak, geri dönüşsüz biçimde.
Okuma korumasını (RDP) aktive et — JTAG/SWD üzerinden flash okumayı engelle.
Seri konsolu koru — üretimde ya tamamen kapat ya da güçlü kimlik doğrulamayla kilitle.
Test pad’lerini kilitle — üretim sonrası test noktalarını devre dışı bırak.
Tehdit modeline ekle — fiziksel erişimi bir saldırı yüzeyi olarak kabul et (bkz. serinin tehdit modelleme yazısı).

Buradaki denge önemli: debug portları meşru bir ihtiyaçtır (saha teşhisi, garanti onarımı). Amaç onları yok etmek değil, kimlik doğrulama ve okuma koruması arkasına almak.

Adli bilişim açısı

İlginç olan şu: savunmacının kapatmak istediği bu portlar, adli bilişimcinin en değerli araçlarıdır. Bir cihazdan yasal olarak delil toplarken UART ve JTAG, çoğu zaman firmware’e ve belleğe ulaşmanın tek yoludur (bkz. serinin flash dump ve firmware çıkarma yazıları). Yani aynı kapı, bir tarafta zafiyet, diğer tarafta delil toplama aracıdır. Bu ikili doğa, gömülü güvenlik ile adli bilişimin ne kadar iç içe olduğunu gösterir — ve ikisini birlikte anlayan uzman, her iki tarafı da görebilir.

Kapanış

UART ve JTAG portları, gömülü cihazların en dürüst zafiyetidir: kötü niyetten değil, ihmalden doğarlar. Bir saldırgan için ilk uğrak, bir adli bilişimci için değerli bir araç, bir üretici için ise kapatılması gereken bir görev. Devre kartındaki o küçük pad’ler, gömülü güvenliğin fiziksel ve dijital dünyayı nasıl birleştirdiğinin en somut örneği.

Bu içerik eğitim amaçlıdır; yalnızca sahibi olduğun ya da yetkili olduğun donanımda çalış.

Secure Boot Gerçekte Neyi Koruyor, Neyi Korumuyor

Wed, 09 Sep 2026 16:01:02 GMT

Gömülü güvenlik tartışmalarında Secure Boot neredeyse sihirli bir kelime gibi kullanılıyor. Bir cihazın Secure Boot’u varsa “güvenli” kabul ediliyor. Oysa Secure Boot çok özel bir problemi çözer — cihazın doğru yazılımla açıldığını garanti eder — ve bunun dışındaki hiçbir güvenlik problemine dokunmaz.

Bu yazı, Secure Boot’un tam olarak ne yaptığını, hangi güçlü garantiyi sunduğunu, ve hangi yaygın yanlış anlamaların yanlış bir güven duygusu yarattığını netleştiriyor.

Secure Boot ne yapar: güven zinciri

Secure Boot’un özü bir güven zinciridir (chain of trust). Fikir şu: cihazın açılışındaki her aşama, bir sonrakini çalıştırmadan önce onun imzasını doğrular.

En altta, donanıma gömülü, değiştirilemez bir güven kökü (root of trust) vardır — genelde çip üreticisinin anahtarı.
Bu kök, bootloader’ın imzasını doğrular. İmza geçerliyse çalıştırır.
Bootloader, kernel’in imzasını doğrular.
Kernel, uygulama/OS katmanını doğrular.

Her halka bir öncekine güvenerek zinciri uzatır. Sonuç: eğer zincirin herhangi bir halkası kurcalanmışsa (imza tutmuyorsa), cihaz açılmayı reddeder. Bu, saldırganın cihaza kalıcı, imzasız bir yazılım yüklemesini engelleyen çok güçlü bir garantidir.

Secure Boot neyi KORUMAZ

İşte yanlış güvenin kaynağı. Secure Boot şunların hiçbirini çözmez:

Çalışma zamanı zafiyetleri. Secure Boot yalnızca açılışta imza doğrular. İmzalı ama içinde buffer overflow ya da uzaktan kod çalıştırma (RCE) zafiyeti olan bir yazılım, sorunsuz açılır ve sonra istismar edilebilir. İmza “bu bizim yazılımımız” der, “bu yazılım güvenli” demez.

Veri gizliliği. Secure Boot bir bütünlük mekanizmasıdır, şifreleme değil. Flash’taki verini okumaya karşı korumaz. Gizlilik için ayrıca flash şifreleme gerekir.

Fiziksel ve yan kanal saldırıları. Voltaj/glitch saldırıları, yan kanal analizi gibi donanım seviyesi teknikler, bazı durumlarda güven zincirini atlatabilir. Secure Boot bunların çoğuna karşı tek başına yeterli değildir.

Kötü anahtar yönetimi. Zincirin tamamı anahtarların gizliliğine dayanır. İmzalama anahtarı sızarsa ya da tüm cihazlarda ortak bir anahtar kullanılıyorsa, Secure Boot’un koruması pratikte çöker.

Flash okuma (ayrı bir mekanizma). Debug portundan flash okumayı engelleyen şey Secure Boot değil, okuma koruması (RDP) gibi ayrı bir özelliktir. İkisi karıştırılır.

Doğru zihinsel model

Secure Boot’u şöyle düşün: bir binanın kapısına takılmış, “içeri yalnızca kimliği doğrulanmış kişiler girer” diyen bir turnike. Bu, dışarıdan sahte birinin girmesini engeller — ama içeri giren gerçek kişinin kötü niyetli olmasını, ya da içeride bir pencerenin açık olmasını engellemez. Secure Boot kimlik ve bütünlük sağlar; davranış ve gizlilik için başka katmanlar gerekir.

Savunma tarafı: Secure Boot’u tamamlayan katmanlar

Flash şifreleme — gizlilik için, Secure Boot’un yanında.
Okuma koruması (RDP/fuse) — debug portundan flash okumayı engellemek için.
Güvenli kod geliştirme — çalışma zamanı zafiyetlerini azaltmak için.
Sağlam anahtar yönetimi — cihaz başına benzersiz anahtarlar, güvenli saklama.
Fiziksel güvenlik önlemleri — glitch ve yan kanal savunmaları.

Secure Boot bu katmanların bir parçasıdır, tamamı değil.

Adli bilişim açısı

Secure Boot ve flash şifrelemenin varlığı, bir adli incelemenin sınırını doğrudan belirler. Şifreli ve imzalı bir cihazda ham flash dökümü (bkz. serinin flash dump yazısı) işe yaramayabilir; anahtar çipin içindeyse içerik okunamaz. Bu yüzden bir cihazı incelemeden önce güven zincirinin ve şifrelemenin durumunu anlamak, hangi delil toplama stratejisinin mümkün olduğunu belirler. Savunmayı güçlendiren şey, incelemeyi zorlaştıran şeydir — ve iyi bir uzman ikisini de anlar.

Kapanış

Secure Boot, gömülü güvenliğin temel taşlarından biri — ama tek taşı değil. Gücü, cihazın doğru yazılımla açıldığını garanti etmesinde; sınırı ise “güvenli açılış” ile “güvenli çalışma”nın farklı şeyler olmasında. “Secure Boot var” demek, “güvenli” demek değildir; olsa olsa “güvenliğin bir katmanı var” demektir. Farkı bilmek, gömülü güvenliği ciddiye almanın ilk adımı.

Bu içerik eğitim amaçlıdır.

CAN Bus Trafiğini pcap’e Alıp Timeline Çıkarmak

Mon, 07 Sep 2026 16:01:03 GMT

CAN bus (Controller Area Network), 1980’lerde otomotiv için tasarlanmış ama bugün araçlardan endüstriyel makinelere, tıbbi cihazlardan enerji sistemlerine kadar her yerde karşımıza çıkan bir alan veriyoludur. Bir araçtaki motor kontrol ünitesi, fren sistemi, gösterge paneli — hepsi bu tek hat üzerinden konuşur.

Güvenlik ve adli açıdan CAN’ın en önemli özelliği, Modbus gibi, kimlik doğrulaması olmamasıdır: hatta yayılan her çerçeveyi, hattaki her düğüm okur ve kaynağını doğrulayamaz. Bu, hem bir zafiyet hem de bir analiz fırsatıdır. Bu yazıda CAN trafiğini yakalayıp adli açıdan kullanışlı bir zaman çizelgesine nasıl dönüştüreceğini anlatıyorum.

CAN çerçevesi 30 saniyede

Bir CAN çerçevesinin özü basittir: bir arbitration ID (mesajın kimliği ve önceliği) ve en fazla 8 baytlık veri. ID kaynağı değil, mesaj tipini/önceliğini belirtir. Örneğin 0x18F bir fren komutu, 0x244 bir hız verisi olabilir — bu eşleme araca/sisteme özeldir ve çoğu zaman tersine mühendislik gerektirir.

Kimlik doğrulaması olmadığı için, hatta erişen herkes herhangi bir ID ile çerçeve gönderebilir. Bu yüzden CAN üzerinde “kim gönderdi” sorusunun tek cevabı çoğu zaman trafiğin kendisidir.

Adım 1–2: Trafiği yakalamak

Linux’ta CAN, SocketCAN altyapısıyla birinci sınıf bir ağ arayüzü gibi ele alınır. Bir USB-CAN adaptörü ile arayüzü ayağa kaldırıp trafiği dinlersin:

# CAN arayüzünü ayağa kaldır (500 kbit/s örnek)
sudo ip link set can0 type can bitrate 500000
sudo ip link set up can0

# Trafiği canlı izle
candump can0
# Zaman damgalı olarak dosyaya kaydet
candump -l can0        # candump-*.log dosyası üretir

Bu aşamada elinde zaman damgalı bir ham kayıt olur. Adli açıdan zaman damgası kritik — çünkü timeline’ın omurgası budur.

Adım 3: pcap’e dönüştürmek

Ham candump logu iş görür, ama trafiği standart bir adli/ağ formatı olan pcap’e almak analizi güçlendirir: Wireshark’ta açabilir, filtreleyebilir, diğer delillerle aynı araç setinde birleştirebilirsin.

# candump'ı doğrudan pcap uyumlu yakalamak için
# (can-utils + Wireshark CAN desteği ile)
candump -L can0 > trafik.log
# Wireshark, SocketCAN yakalamalarını doğrudan açabilir

Wireshark’ta CAN çerçevelerini ID’ye, zamana veya veri içeriğine göre filtreleyebilir, belirli bir olayın etrafındaki trafiği izole edebilirsin. pcap, delil zinciri açısından da avantajlıdır çünkü yaygın, doğrulanabilir bir formattır.

Adım 4: Timeline ve anomali

Asıl değer, ham çerçeveleri olay sıralamasına çevirmekte. ID’leri anlamlarına eşledikten sonra, zaman çizelgesi okunabilir hâle gelir:

t0.000  ID 0x18F  frenleme komutu
t0.012  ID 0x244  hız verisi
t0.031  ID 0x18F  beklenmedik tekrar  → anomali
t0.045  ID 0x3C1  kapı durumu

Anomaliler burada ortaya çıkar: normalde belirli bir aralıkta gelen bir mesajın aniden ve düzensiz tekrarlanması, hiç görülmemiş bir ID’nin belirmesi, ya da bir komutun beklenen bağlamın dışında gönderilmesi. Bir saldırı ya da arıza, çoğu zaman bu zamansal desende bir kırılma olarak görünür.

Savunma tarafı

Segmentasyon ve gateway: kritik CAN segmentlerini daha az güvenilir olanlardan ayır.
Anomali tespiti (IDS): mesaj frekansını ve ID setini öğrenip sapmaları yakala.
Mesaj kimlik doğrulama (CAN-FD üzerinde): yeni sistemlerde kriptografik bütünlük ekle.
Fiziksel erişim kontrolü: OBD portu ve teşhis arayüzleri birer giriş noktasıdır.

Adli bilişim açısı

CAN timeline çıkarma, “IoT/OT forensics” pratiğinin ders kitabı örneğidir: cihaz kimlik bırakmaz, delil ağ trafiğindedir, ve iş zaman damgalı bir kaydı olaya dönüştürmeye dayanır. Bu yaklaşım doğrudan kendi araç fikrimle de örtüşüyor — CAN/Modbus trafiğini pcap’ten alıp otomatik timeline üreten bir araç, hem savunma hem adli analiz için değerli bir açık kaynak katkısı olabilir. Bu tür bir aracın mimarisini ilerleyen proje yazılarında ele alacağım.

Kapanış

CAN bus, kimlik doğrulaması olmayan ama her şeyi konuşan bir hattır — bu da onu hem savunmasız hem de analiz için şeffaf kılar. Trafiği zaman damgalı yakalamak, pcap’e almak ve olay sıralamasına dökmek; bir aracın ya da bir OT sisteminin “kara kutusunu” okumanın en güçlü yollarından biri.

Bu içerik eğitim amaçlıdır; yalnızca sahibi olduğun ya da test yetkin olan sistemlerde uygula.

Gömülü Cihazda “Log Yok” Durumunda Delil: Bellek, NVRAM ve Yan Kanallar

Fri, 04 Sep 2026 16:01:02 GMT

Bir Windows makinesini incelerken en büyük müttefikimiz loglardır: olay günlükleri, kayıt defteri, uygulama izleri. Gömülü dünyaya geçtiğinde ise sık sık şu duvarla çarpışırsın: cihaz hiç log tutmuyor. Kaynak kısıtlı bir mikrodenetleyici, kalıcı bir günlük dosyası için ne yer ne de yazma döngüsü ayırır.

Peki o zaman “ne oldu” sorusunu nasıl cevaplayacağız? Bu yazı, log olmayan gömülü cihazlarda delilin nerede saklandığını ve onu kaybetmeden nasıl toplayacağını anlatıyor.

Anahtar kavram: uçuculuk sırası

Adli bilişimin altın kurallarından biri, delili kaybolma hızına göre toplamaktır (order of volatility). Gömülü cihazlarda bu kural klasik bilgisayarlardan çok daha kritiktir, çünkü en değerli delil çoğu zaman en uçucu yerdedir. Sıralama, en hızlı kaybolan en üstte olacak şekilde:

CPU kayıtçıları ve önbellek — anlıktır, pratikte yakalanması çok zor
RAM (çalışan durum) — çalışan süreçler, açılmış şifreli veri, geçici anahtarlar
Ağ durumu — aktif bağlantılar, oturumlar
NVRAM / EEPROM / config — cihaza özel kalıcı ayarlar
Flash / kalıcı depolama — en yavaş kaybolan, en son toplanan

Fişi çekmek, bu piramidin üst katmanlarını anında yok eder. Bu yüzden gömülü adli bilişimde “önce kapat” refleksi çoğu zaman yanlıştır.

RAM: en değerli ama en kaçıcı delil

Çalışan bellekte şaşırtıcı derecede zengin bilgi bulunur: o an çalışan süreçler, açılmış (decrypt edilmiş) yapılandırma, geçici oturum anahtarları, ağ üzerinden gelen son komutlar. Flash şifreliyse bile, çalışan sistemde bu veri açık hâlde RAM’de olabilir.

Gömülü cihazda RAM dökümü almak klasik bilgisayardan zordur — standart bir araç yoktur. Yollar cihaza göre değişir: bir debug portu (JTAG/SWD) üzerinden bellek okuma, cihazın kendi sağladığı bir teşhis arayüzü, ya da bootloader üzerinden erişim. Her yöntem sistemi bir miktar değiştirir; bunu kabul edip ne yaptığını tutanaklamak gerekir.

NVRAM ve config: sessiz tanıklar

RAM’in aksine NVRAM/EEPROM kalıcıdır ve genelde cihazın “durumunu” tutar: ayarlar, sayaçlar, son bağlantı bilgileri, bazen kimlik bilgileri. Bir cihaz açıkça log tutmasa da, NVRAM’deki değerler dolaylı bir tarih anlatabilir — bir sayacın değeri, bir bayrağın durumu, son yapılandırma zamanı. Bu değerleri okumak ve yorumlamak, “log yok” duvarını aşmanın en pratik yollarından biridir.

Yan kanallar: dolaylı delil

Doğrudan delil yoksa, dolaylı izlere bakılır:

Boot logları: cihaz her açılışta UART’a bir açılış çıktısı verebilir — sürüm, hata, yapılandırma bilgisi.
Zaman damgaları: dosya sistemi ya da NVRAM’deki değişim zamanları bir olayı konumlandırabilir.
Fiziksel/donanımsal izler: kurcalama izi, değişmiş bir jumper, eklenmiş bir cihaz.
Ağ tarafı: cihaz log tutmasa da, ağdaki pasif pcap kaydı onun ne konuştuğunu gösterir.

Bu son madde kritik: gömülü cihaz sana konuşmayabilir, ama ağ konuşur. Bu yüzden IoT/OT ortamlarında pasif ağ kaydı, log olmayan cihazlar için çoğu zaman en güvenilir delil kaynağıdır.

Pratik toplama yaklaşımı

Cihaza dokunmadan önce ağ trafiğini yakalamaya başla (pcap).
Mümkünse cihazı çalışır bırak; uçucu belleği önce topla.
Debug portu ya da teşhis arayüzünden RAM ve NVRAM’i oku.
En son kalıcı depolamayı imajla.
Her adımı, aracı ve zamanı tutanakla; toplanan her şeyin hash’ini al.

Adli bilişim açısı

“Log yok” durumu, gömülü adli bilişimi klasik disk adli bilişiminden ayıran tam da o zorluktur — ve gömülü/donanım bilgisi olanın fark yarattığı yerdir. Delilin nerede, hangi sırayla ve hangi araçla toplanacağını bilmek, bu alanda uzmanlığın özüdür. Klasik adli bilişim eğitimi sana bir Windows olay günlüğünü okumayı öğretir; bir NVRAM’i okumayı ya da fişi çekmeden RAM dökümü almayı öğretmez. İşte bu boşluk, bir fırsat.

Kapanış

Gömülü bir cihaz sana bir günlük dosyası sunmayabilir, ama tümüyle sessiz de değildir — yeter ki doğru yere, doğru sırayla bakasın. RAM’in kaçıcı zenginliği, NVRAM’in sessiz kayıtları ve ağın konuşkanlığı; “log yok” duvarını aşmanın üç anahtarı. Gömülü adli bilişimde delil kaybolmadan önce onu nerede arayacağını bilmek, işin kendisidir.

Bu içerik eğitim amaçlıdır.

Firmware Analizi 101: binwalk ile Bir İmajın İçini Açmak

Wed, 02 Sep 2026 16:01:02 GMT

Firmware analizinde en heyecan verici an, ham bir .bin dosyasının içindekini ilk kez görmektir. Önceki yazılarda o imajı nasıl çıkaracağını (kart okuyucu, UART, chip-off, flash dump) konuştuk. Şimdi elimizde imaj var ve soru şu: içinde ne var?

Bu yazı, gömülü analizin giriş aracı olan binwalk üzerinden bir firmware imajının nasıl katman katman açıldığını, nelere dikkat edileceğini ve ilk bulguların nerede aranacağını anlatıyor.

Bir firmware imajı neye benzer?

Tipik bir Linux tabanlı gömülü firmware imajı katmanlı bir yapıdır:

Bootloader (ör. U-Boot) — cihazı başlatan ilk kod
Kernel — genelde sıkıştırılmış bir Linux çekirdeği
Root dosya sistemi — SquashFS, JFFS2, UBIFS gibi gömülü formatlarda
NVRAM / config — cihaza özel ayarlar, bazen kimlik bilgileri

Bu katmanlar tek bir ikili dosyada arka arkaya durur. binwalk’ın işi, bu bloğu tarayıp “burada bir SquashFS başlıyor, şurada bir LZMA sıkıştırma var” diyerek haritayı çıkarmaktır.

binwalk nasıl çalışır?

binwalk iki temel şey yapar: imza taraması ve entropi analizi.

İmza taraması, dosya içinde bilinen “sihirli bayt” desenlerini arar — her dosya formatının kendine has bir başlangıç imzası vardır. Entropi analizi ise verinin rastgeleliğini ölçer; yüksek entropi (~1.0’a yakın) sıkıştırma ya da şifreleme işareti, düşük entropi ise düz veri/kod işaretidir.

# 1) Haritayı çıkar: içeride hangi formatlar var?
binwalk firmware.bin
# 2) Entropiye bak: şifreli/sıkıştırılmış bölgeler nerede?
binwalk -E firmware.bin
# 3) Çıkarılabilenleri ayıkla (dikkatli - çok dosya üretebilir)
binwalk -e firmware.bin

İlk komutun çıktısı genelde şuna benzer bir harita verir: ofset, tespit edilen tür ve açıklama. Bu haritadan bootloader’ın, kernel’in ve dosya sisteminin nerede başladığını okuyabilirsin.

Root dosya sistemine ulaşmak

Asıl hazine genelde root dosya sistemindedir. binwalk -e ile çıkardıysa, açılan klasörde tanıdık bir Linux dizin yapısı görürsün. Bakılacak yerler:

/etc/ — servis yapılandırmaları, başlangıç betikleri, sabit ayarlar
/etc/passwd, /etc/shadow — kullanıcılar, parola hash’leri
/etc/ssl/, anahtar dosyaları — sertifikalar, özel anahtarlar
/bin/, /sbin/, uygulama binary’leri — tersine mühendislik hedefleri
/www/ ya da web arayüzü dosyaları — çoğu zaman zafiyet yuvası

Sabit kodlanmış sırların (parolalar, API anahtarları, sertifikalar) avlanmasını serinin ayrı bir yazısında derinlemesine ele alıyorum.

Entropi tuzağı: şifreli firmware

Bazen binwalk -E çıktısında imaj boyunca sabit, yüksek bir entropi görürsün. Bu genelde iki şeyden birini gösterir: ya tüm imaj sıkıştırılmış, ya da şifreli. Şifreliyse binwalk katmanları ayrıştıramaz; farklı bir yola geçmek gerekir (anahtarı bulmak, çalışan bellekten açılmış hâlini yakalamak, ya da secure boot zincirini analiz etmek). Bu, modern cihazlarda giderek daha sık karşılaşılan bir durum ve savunma açısından iyi bir işaret.

Adli bütünlük ve tekrarlanabilirlik

Analizi her zaman imajın kopyası üzerinde yap; orijinali ve hash’ini sakla.
Kullandığın binwalk sürümünü ve komutları not al — tekrarlanabilirlik adli açıdan önemlidir.
binwalk -e bazen çok sayıda parçalı dosya üretir; çıkardığın şeyi anlayarak ilerle, körü körüne değil.

Adli bilişim açısı

binwalk bir başlangıç aracıdır; asıl adli değer, çıkardığın katmanları anlamlandırmakta. Firmware analizi bir cihazın “ne yaptığını” ve “hangi zafiyeti taşıdığını” ortaya koyar; bir olay incelemesinde ise cihazın kurcalanıp kurcalanmadığını (ör. beklenmedik bir binary, değiştirilmiş bir config) gösterir. Ham dökümden anlamlı delile giden yol tam da buradan, imajın içini açmaktan geçer.

Kapanış

binwalk, firmware analizinin “merhaba dünya”sıdır — basit ama her ciddi gömülü incelemenin başladığı yer. Bir imajı katmanlarına ayırmak, root dosya sistemine ulaşmak ve orada ne olduğunu okumak; gömülü güvenliğin ve adli bilişimin kesiştiği en pratik beceridir. Sıradaki adım, o dosya sisteminde gizlenen sırları avlamak.

Bu içerik eğitim amaçlıdır; yalnızca sahibi olduğun ya da yasal izinli firmware üzerinde çalış.

Bir Mikrodenetleyiciden Flash Bellek Dökümü Almak: UART, SWD, Chip-off Yöntemleri

Mon, 31 Aug 2026 16:01:01 GMT

Bir önceki yazıda Raspberry Pi gibi Linux tabanlı bir cihazdan imaj almayı konuştuk — orada işler görece kolaydı, çünkü çıkarılabilir bir SD kart ya da dosya sistemi vardı. Ama gömülü dünyanın büyük kısmı mikrodenetleyicilerden (MCU) oluşur: STM32, ESP32, PIC gibi, firmware’i doğrudan yonga içi flash belleğinde tutan çipler. Buradan döküm almak farklı bir oyun.

Bu yazıda bir MCU’dan flash dökümü almanın üç ana yolunu, ne zaman hangisini seçeceğini ve adli açıdan nelere dikkat edeceğini anlatıyorum.

Altın kural: en az müdahaleden başla

Adli bilişimde her fiziksel müdahale bir risktir. Bu yüzden yöntem sırası şudur: önce hiç dokunmadan (yazılımsal), sonra debug portundan, en son fiziksel sökme. Aşağıdaki üç yöntem tam da bu sırayla gidiyor.

Yöntem A — UART bootloader (en yumuşak)

Birçok MCU, fabrika çıkışında bir ROM bootloader ile gelir. Belirli pinler doğru seviyeye çekildiğinde (ör. STM32’de BOOT0), çip bu bootloader’a girer ve UART üzerinden bellek okuma/yazma komutlarını kabul eder. Bu, çoğu zaman en temiz ve en az müdahaleci yoldur.

# STM32 örneği — stm32flash aracıyla flash okuma
stm32flash -r firmware_dump.bin /dev/ttyUSB0
sha256sum firmware_dump.bin

Avantajı: fiziksel sökme yok, üretici destekli bir arayüz. Dezavantajı: bazı cihazlarda bu bootloader devre dışı bırakılmış ya da parola korumalı olabilir.

Yöntem B — SWD / JTAG debug portu

MCU’ların çoğunda geliştirme için bir debug arayüzü vardır: ARM tarafında SWD (Serial Wire Debug) ya da klasik JTAG. Bir debug probe’u (ST-Link, J-Link gibi) ile bu porta bağlanıp belleği doğrudan okuyabilirsin.

# OpenOCD ile flash okuma (örnek)
openocd -f interface/stlink.cfg -f target/stm32f4x.cfg \
  -c "init; reset halt; dump_image dump.bin 0x08000000 0x100000; exit"

Avantajı: hızlı ve tam erişim. Dezavantajı: üreticiler bu portu okuma koruması (RDP — Readout Protection) ile kilitleyebilir. Kilit aktifse debug portu belleği okumayı reddeder; bu da bizi bir sonraki (ve en zor) yönteme iter.

Yöntem C — Chip-off (son çare)

Diğer yollar kapalıysa — bootloader devre dışı, debug portu kilitli — geriye fiziksel yol kalır: çipi anakarttan söküp özel bir okuyucuya takmak. Bu, sıcak hava istasyonu, hassas lehim işi ve okuyucu donanımı gerektiren, geri dönüşü olmayan bir işlemdir.

Chip-off adli açıdan en son başvurulan yöntemdir çünkü:

Geri dönüşsüzdür; cihaz genelde bir daha çalışmaz.
Yüksek beceri ve doğru ekipman ister; hata veriyi yok edebilir.
Şifreli flash’ta ham döküm işe yaramayabilir (anahtar çipin içindeyse).

Şifreleme ve okuma koruması gerçeği

Modern MCU’lar giderek daha fazla flash şifreleme ve secure boot ile geliyor. Bu durumda ham dökümü alsan bile içerik şifreli olabilir. Bu, savunma açısından iyi haber; adli açıdan ise incelemenin sınırını belirleyen kritik bir faktör. Secure boot’un gerçekte neyi koruyup neyi korumadığını serinin ayrı bir yazısında ele alıyorum.

Adli bütünlük notları

Hangi yöntemi kullanırsan kullan, dökümü aldıktan sonra hash al ve sakla.
Her adımı, kullandığın aracı ve pin bağlantılarını tutanakla — özellikle fiziksel müdahalede.
Mümkünse aynı modelden bir referans cihazla yöntemi önce doğrula, sonra delil cihaza uygula.

Adli bilişim açısı

Flash dökümü, gömülü adli bilişimin en somut becerisidir. Elde ettiğin ham dökümü sonra binwalk ile açar, dosya sistemini ayıklar, sabit kodlanmış sırları ararsın — bunları serinin “firmware analizi 101” ve “gömülü sır avı” yazılarında işliyorum. Ama her şey doğru dökümü, doğru yöntemle, bütünlüğü bozmadan almakla başlar.

Kapanış

Bir MCU’dan döküm almak, uygun aracı seçmekten çok doğru sırayı izlemekle ilgilidir: önce UART, sonra debug portu, en son chip-off. Her adım daha fazla erişim ama daha fazla risk demek. İyi bir gömülü adli bilişimci, mümkün olan en yumuşak yöntemle en fazla delili toplayabilendir.

Bu içerik eğitim amaçlıdır; yalnızca sahibi olduğun donanımda uygula.

IoT/OT Forensics Nedir, Klasik Disk Adli Bilişiminden Nerede Ayrılıyor

Fri, 28 Aug 2026 16:01:02 GMT

Adli bilişimi klasik disk analizi üzerinden öğreniriz: cihazı kapat, diski çıkar, yaz-korumalı bir imaj al, tanıdık dosya sistemini tanıdık araçlarla incele. Bu yöntem on yıllarca oturmuş, olgunlaşmış ve mahkemelerde kanıtlanmış bir disiplindir.

Sonra bir gün karşına bir akıllı sayaç, bir router, bir sanayi geçidi ya da bir şarj ünitesi çıkar — ve elindeki playbook’un yarısı işe yaramaz. IoT/OT forensics tam da bu boşlukta doğuyor. Bu yazı, ikisi arasındaki farkı ve neden yeni bir zihniyet gerektirdiğini anlatıyor.

Klasik disk adli bilişiminin konforu

Standart bir bilgisayar incelemesinde işler öngörülebilir:

Cihaz kapatılabilir — kapatmak delili yok etmez, çünkü veri kalıcı diskte durur.
Depolama çıkarılabilir ve yaz-korumalı bir bağlayıcıyla imajlanabilir.
Dosya sistemi standarttır (NTFS, ext4, APFS) ve araçlar bunu anlar.
Sistem zengin log ve artefakt üretir (kayıt defteri, olay günlükleri, tarayıcı geçmişi).
Olgun araçlar vardır: AXIOM, Autopsy, X-Ways.
Süreç tekrarlanabilir ve doğrulanabilirdir.

Bu konfor, adli bilişimin mahkeme önünde güçlü olmasının temelidir.

IoT/OT dünyasında bu konforun çöküşü

Gömülü ve endüstriyel cihazlarda neredeyse her varsayım tersine döner:

Kapatmak delili yok edebilir. Kritik veri çoğu zaman uçucu bellekte (RAM, NVRAM) durur; fişi çekmek onu siler. OT tarafında ise cihazı durdurmak fiziksel bir sürecin kesintiye uğraması demek olabilir.
Depolama erişilemezdir. Flash bellek çoğu zaman anakarta lehimlidir; çıkarılabilir bir disk yoktur.
Dosya sistemi tuhaftır. Özel, sıkıştırılmış ya da hiç dosya sistemi olmayan ham bellek düzenleriyle karşılaşırsın.
Log azdır ya da hiç yoktur. Birçok gömülü cihaz kalıcı log tutmaz.
Standart araç yoktur. Çoğu zaman elle parse etmek, protokolü tersine çevirmek gerekir.
Fiziksel müdahale gerekebilir. JTAG, UART, hatta chip-off.

Sonuç: aynı meslek değil. Disk adli bilişimi “kapat, imajla, analiz et” derken, IoT/OT forensics “canlı topla, seçici davran, ağdan doğrula” der.

Yeni zihniyetin üç direği

1. Uçuculuk önceliği. Delil kaybolmadan önce toplanmalı. Sıra (order of volatility) gömülü dünyada çok daha kritiktir: önce RAM/NVRAM, sonra ağ durumu, en son kalıcı depolama.

2. Seçici ve canlı toplama. Çoğu zaman “kapat ve imajla” mümkün değildir. Cihaz çalışırken, sistemi mümkün olduğunca az değiştirerek seçici delil toplamak gerekir — ve her müdahalenin sistemi değiştirdiğini kabul etmek gerekir.

3. Ağdan doğrulama. Cihazın kendisi az kanıt bırakıyorsa, delil ağa kayar. OT/IoT ortamlarında pasif ağ kaydı (pcap) çoğu zaman en güvenilir delil kaynağıdır — çünkü kimlik doğrulaması olmayan protokoller cihaz tarafında iz bırakmaz.

Pratikte ne değişiyor?

Konu	Disk forensics	IoT/OT forensics
Cihaza müdahale	Kapat	Canlı bırak (genelde)
Depolama	Çıkar, imajla	Lehimli, JTAG/chip-off
En değerli delil	Kalıcı disk	Uçucu bellek + ağ
Araçlar	Olgun, hazır	Elle, uyarlama
Log	Bol	Az ya da yok

Bu farklar rastgele değil; gömülü cihazların kaynak kısıtlı, gerçek zamanlı ve kapalı olarak tasarlanmasından doğuyor.

Adli bilişim açısı: fırsat nerede?

Bu alan Türkiye’de neredeyse boş. Klasik mobil ve disk adli bilişimi yapan çok, ama IoT/OT tarafına gömülü/donanım bilgisiyle girebilen az. Gömülü sistem geçmişi olan bir DFIR uzmanı burada gerçek bir fark yaratır — çünkü UART’ı bağlayacak, boot logunu okuyacak, ham belleği parse edecek beceri klasik adli bilişim eğitiminde yoktur. Serinin sonraki yazılarında (flash dump, CAN timeline, “log yok” durumunda delil) bu becerileri tek tek ele alıyorum.

Kapanış

IoT/OT forensics, adli bilişimin bildiğin kurallarını çöpe atmaz — ama hangi kuralın hangi bağlamda geçerli olduğunu yeniden düşünmeni ister. Konforlu “kapat ve imajla” dünyasından, canlı ve seçici bir delil toplama disiplinine geçiş. Ve tam da bu geçiş, gömülü geçmişi olanlar için bir uzmanlık fırsatı.

Bu içerik eğitim amaçlıdır.

Raspberry Pi Tabanlı Bir Cihazda Firmware’i Nasıl Çıkarır ve İncelersin

Wed, 26 Aug 2026 16:01:03 GMT

Gömülü güvenlik ile adli bilişimin en net kesiştiği yer firmware analizidir. Bir IoT cihazının, bir şarj ünitesinin ya da bir OT geçidinin ne yaptığını gerçekten anlamak istiyorsan, önce içindeki yazılımı ele geçirmen gerekir. Raspberry Pi tabanlı cihazlar bu iş için mükemmel bir öğrenme zemini: yaygın, ucuz, iyi belgelenmiş ve depolaması genelde erişilebilir.

Bu yazıda bir Pi’den (ya da benzeri bir Linux gömülü cihazından) firmware imajını adli bütünlüğü koruyarak çıkarmanın üç yolunu ve incelemenin ilk adımlarını anlatıyorum.

Önce kural: bütünlük her şeyden önce gelir

Herhangi bir teknik adıma geçmeden önce tek bir prensip: orijinali değiştirme. Adli açıdan geçerli bir inceleme için:

Mümkünse yaz-korumalı (write-blocker) bir yol kullan.
İmajı aldıktan hemen sonra hash al (SHA-256).
Analizi kopyada yap, orijinali sakla; işlem sonrası hash’in değişmediğini doğrula.
Her adımı zaman damgasıyla tutanakla.

Bu disiplin, bulgularının bir gün mahkemede ya da bir raporda savunulabilir olmasını sağlar.

Yol A — Kart okuyucu ile bit-birebir imaj (en temiz)

Pi’lerin çoğu SD karttan boot eder. En temiz yöntem kartı çıkarıp bir okuyucuyla iş istasyonuna bağlamak ve bit-birebir imaj almaktır:

# Kartın hangi aygıt olduğunu belirle (ör. /dev/sdb) — dikkatli seç!
sudo dd if=/dev/sdb of=cihaz_imaj.dd bs=4M status=progress conv=noerror,sync

# İmajın ve kaynağın hash'ini al
sha256sum cihaz_imaj.dd

eMMC lehimliyse okuyucu adaptörü ya da cihazın sağladığı bir USB boot modu gerekebilir. İmajı aldıktan sonra bölümleri incele:

fdisk -l cihaz_imaj.dd
# genelde bir FAT boot bölümü + bir ext4 kök dosya sistemi görürsün

Yol B — UART konsol ile canlı erişim

Depolamaya fiziksel erişemiyorsan ya da çalışan sistemi görmek istiyorsan, UART (seri konsol) çok değerlidir. Pi’nin GPIO pinlerindeki TX/RX/GND’yi bir USB-UART adaptörüne bağlarsın:

# Adaptör bağlıyken (genelde 115200 baud)
sudo screen /dev/ttyUSB0 115200

UART’tan boot loglarını, U-Boot komut istemini ve çoğu zaman doğrudan bir kök kabuğunu görebilirsin. Boot logları tek başına altın değerindedir: çekirdek sürümü, dosya sistemi düzeni, açılışta çalışan servisler ve hata mesajları buradan okunur. Adli açıdan UART “canlı” bir kaynak olduğu için, ne yaptığını kaydet ve sistemin durumunu değiştirdiğinin farkında ol.

Yol C — Chip-off (son çare)

Cihaz boot etmiyorsa, depolama şifreli değilse ve başka yol kalmadıysa, bellek yongasını fiziksel olarak sökme (chip-off) devreye girer. Bu, geri dönüşü olmayan, lehim ve özel okuyucu gerektiren, riskli bir yöntemdir. Adli bilişimde ancak diğer tüm yollar tükendiğinde başvurulur. Serinin “mikrodenetleyiciden flash dump” yazısında bu konuya daha derin gireceğim.

İmaj elde: ilk inceleme

Elinde imaj olduğunda ilk refleks binwalk:

binwalk cihaz_imaj.dd          # gömülü dosya sistemlerini, sıkıştırmayı tarar
binwalk -e cihaz_imaj.dd       # çıkarılabilenleri ayıklar (dikkatli kullan)

Kök dosya sistemini bağladıktan (mount) sonra bakılacak yerler:

/etc/ — yapılandırma, servisler, sabit kodlanmış ayarlar
/etc/shadow, anahtar/sertifika dosyaları — sabit kodlanmış sırlar (serinin ayrı yazısı)
/var/log/ — varsa loglar
Uygulama binary’leri — tersine mühendislik için

Adli bilişim açısı

Firmware çıkarma, “IoT/OT forensics” pratiğinin temel taşıdır. Klasik disk adli bilişiminden farkı şu: gömülü cihazda çoğu zaman düzgün bir dosya sistemi, kalıcı log ya da standart bir imaj alma yolu bulamazsın. Bu yüzden yöntem seçimi (A/B/C) doğrudan delilin niteliğini belirler. Bir sonraki yazıda tam da bu farkı — IoT/OT forensics’in disk adli bilişiminden nerede ayrıldığını — ele alıyorum.

Kapanış

Firmware çıkarmak, gömülü güvenliğin kapısını açan ilk anahtardır. Önemli olan hangi aracı kullandığın değil, bütünlüğü koruyarak ve ne yaptığını bilerek çalışman. Kart okuyucudan başla, UART’ı yanında tut, chip-off’u son çare olarak sakla — ve her zaman hash al.

Bu içerik eğitim amaçlıdır; yalnızca sahibi olduğun ya da incelemeye yetkili olduğun cihazlarda uygula.

EV Şarj İstasyonu Bir Saldırganın Gözünden: Fiziksel Port, MQTT Broker, Backend Güveni

Mon, 24 Aug 2026 16:01:02 GMT

Güvenlik mühendisliğinin en yararlı zihinsel egzersizlerinden biri tehdit modellemedir: sistemi savunanın değil, saldıranın gözünden okumak. Bu, “nasıl saldırılır” öğrenmek için değil, savunmayı nereye koyacağını bilmek içindir. Bu yazıda bir elektrikli araç şarj istasyonunu tam da bu gözle, katman katman bir güven haritası olarak inceliyoruz.

Not: burada hiçbir operasyonel saldırı reçetesi yok. Amaç, her katmanın hangi varsayımlara güvendiğini görüp savunmayı doğru yere yerleştirmek.

Katman 1 — Fiziksel ve servis arayüzü

Şarj istasyonu sokakta, çoğu zaman gözetimsiz bir kutudur. Bir saldırganın ilk sorusu şudur: “Bu kutuya fiziksel olarak ne kadar yaklaşabilirim?” Kabin kilidi, açık USB/UART portları, çıkarılabilir depolama ve şifresiz servis menüleri bu katmanın zayıf noktalarıdır. Fiziksel erişim genelde firmware’e ve gömülü kimlik bilgilerine açılan kapıdır.

Güven varsayımı: “Kimse kabini açamaz.” Gerçek: açabilir.

Katman 2 — RFID ve ödeme

Kullanıcı kimliği çoğu istasyonda bir RFID kartıyla doğrulanır. Zayıf kart teknolojileri klonlanabilir; bu da yetkisiz şarj ve başkasının hesabına işlem anlamına gelir. Ödeme akışı ayrı bir güven sınırıdır ve PCI-DSS benzeri gereklilikler burada devreye girer.

Güven varsayımı: “Kart sahibi = yetkili kullanıcı.” Gerçek: kart klonlanabilir.

Katman 3 — Yerel ağ ve MQTT broker

İstasyonun iç bileşenleri (ölçüm, HMI, güç modülü) çoğu zaman yerel bir mesajlaşma katmanıyla — sıkça MQTT ile — haberleşir. Broker kimlik doğrulama olmadan yapılandırılmışsa, yerel ağa erişen biri tüm telemetriyi okuyabilir ve komut topic’lerine yazabilir. Bu konuyu serinin ayrı bir yazısında derinlemesine işliyorum.

Güven varsayımı: “Yerel ağ güvenli.” Gerçek: bir kez içeri girildiğinde her şey açık.

Katman 4 — Backend / OCPP güveni

İstasyon, kendisini yöneten merkezî sisteme (CSMS) OCPP ile bağlanır. Eğer bu bağlantı şifresiz ya da doğrulamasızsa, saldırgan sahte bir backend gibi davranıp uzaktan komut gönderebilir: durdur, sıfırla, yapılandırma değiştir. Tehlike ölçekte büyür — tek bir sahte backend yüzlerce istasyonu aynı anda etkileyebilir. OCPP güvenlik modelini serinin ilk yazısında ayrıntılı inceledim.

Güven varsayımı: “Bağlanan backend gerçek backend’dir.” Gerçek: kanıtlanmadıkça değil.

Katman 5 — OTA güncelleme kanalı

En kritik katman firmware güncellemesidir. İmza doğrulaması zayıf ya da yoksa, saldırgan istasyona kendi yazılımını yükleyebilir — ki bu, cihaz üzerinde kalıcı ve tam kontrol demektir. OTA güvenliğini serinin ayrı bir yazısında tek başına ele alıyorum.

Güven varsayımı: “Gelen güncelleme üreticidendir.” Gerçek: imza doğrulanmıyorsa değil.

Savunmayı katman katman kurmak

Tehdit haritasının değeri, savunmayı doğru yere koymamızı sağlamasıdır:

Fiziksel: sağlam kabin, servis portu kimlik doğrulama, güvenli boot, şifreli depolama
Ödeme: güçlü RFID/ödeme teknolojisi, sunucu tarafı doğrulama
Yerel ağ: MQTT için TLS + kimlik doğrulama + ACL
Backend: mTLS, sertifika sabitleme, komut yetkilendirme
OTA: imzalı firmware, güvenli güncelleme zinciri

Her katman ayrı bir güven sınırıdır; birinin çökmesi diğerini otomatik açmamalıdır. Buna derinlemesine savunma denir.

Adli bilişim açısı

Bir şarj istasyonu olayında, hangi katmanın çöktüğünü anlamak delil toplama stratejisini belirler. Fiziksel ihlal → firmware imajı ve boot logları; MQTT ihlali → yerel ağ pcap’i; backend ihlali → OCPP mesaj logları; OTA ihlali → firmware sürüm ve imza kayıtları. Gömülü/OT cihazlarında delil çoğu zaman uçucudur, bu yüzden hangi katmanda arayacağını bilmek yarı iş demektir.

Kapanış

Bir sistemi savunmak için önce onu saldırganın gördüğü gibi görmek gerekir — bir hizmet olarak değil, bir dizi güven sınırı olarak. Şarj istasyonu örneği bunu somutlaştırıyor: beş katman, beş varsayım, beş savunma noktası. Tehdit modelleme tam da bu haritayı çıkarma disiplinidir.

Bu içerik tamamen savunma ve tehdit modelleme amaçlıdır; operasyonel bir saldırı rehberi değildir.

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

Fri, 21 Aug 2026 16:01:01 GMT

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.

Modbus Neden Hâlâ Kimliksiz Konuşuyor: OT Protokollerinde “Güvenlik Sonradan Eklendi” Problemi

Wed, 19 Aug 2026 16:01:02 GMT

Bilişim güvenliğiyle uğraşan biri Modbus’a ilk baktığında genelde aynı tepkiyi verir: “Kimlik doğrulama nerede?” Cevap kısa: yok. Ve bu bir hata değil, bir dönemin tasarım tercihi. Modbus 1979’da, kapalı bir fabrika ağında iki cihazın konuşması için tasarlandı. O ağda “düşman” kavramı yoktu; fiziksel güvenlik yeterliydi. Sorun, o protokolün 40 yıl sonra internete bağlı OT ağlarında hâlâ birebir aynı mantıkla çalışıyor olması.

Bu yazı, OT güvenliğinin en temel gerçeğini tek bir protokol üzerinden anlatıyor: güvenlik sonradan eklenemeyecek kadar derine gömüldüğünde ne oluyor.

Modbus nasıl çalışır (ve neyi hiç yapmaz)

Modbus basit bir master–slave (istemci–sunucu) protokolüdür. Master bir istek gönderir, slave cevap verir. İstekte üç temel bilgi vardır: hedef cihazın Unit ID’si, ne yapılacağını söyleyen fonksiyon kodu ve adres/veri. Örneğin Read Holding Registers (FC 03) veri okur, Write Single Register (FC 06) tek bir register’a yazar.

Protokolün yapmadıkları ise şunlar:

Kimlik doğrulama yok: master’ın gerçekten yetkili olup olmadığını kimse doğrulamaz.
Şifreleme yok: tüm trafik açık; dinleyen herkes okur.
Bütünlük kontrolü yok: mesajın yolda değiştirilip değiştirilmediği anlaşılmaz (RTU’daki CRC yalnızca hat gürültüsüne karşıdır, saldırıya karşı değil).
Oturum yönetimi yok: her istek bağımsızdır; “kim, ne zaman, kaç kez” bilgisi tutulmaz.

Sonuç net: ağa erişebilen herkes, yetkili bir master gibi davranıp bir PLC’ye komut yazabilir. Bir vanayı açtırabilir, bir motorun devrini değiştirebilir, bir alarmı susturabilir.

“Ama ağ kapalı” savunmasının çöküşü

OT tarafında en sık duyduğum cümle: “Bizim ağ zaten internete kapalı.” Pratikte bu neredeyse hiç tam doğru değildir. Bakım için uzaktan erişim, mühendislik istasyonundan gelen köprüler, yanlış yapılandırılmış bir güvenlik duvarı, USB ile taşınan bir dosya — hava boşluğu (air gap) çoğu zaman efsanedir. Ve Modbus’ta tek bir ayağın ağa girmesi yeter, çünkü protokolün kendisi hiçbir ikinci savunma hattı sunmuyor.

İnternete açık Modbus cihazlarını tarayan servislerde binlerce açık 502 portu görünür. Bunların çoğu su, enerji ve bina otomasyonu sistemleridir.

Neden düzeltmek bu kadar zor?

IT tarafında bir protokolü güncellemek görece kolaydır; OT tarafında değil. Sebepler:

Ömür: bir PLC 15–20 yıl sahada kalır. 2008’de kurulan sistem hâlâ çalışıyor.
Kesinti maliyeti: üretim hattını durdurup firmware güncellemek milyonluk kayıp demek olabilir.
Belirlenmişlik (determinism): OT’de milisaniyelik zamanlama kritik. Şifreleme eklemek gecikme yaratır, bu da süreci bozabilir.
Sertifikasyon: emniyet kritik sistemlerde her değişiklik yeniden sertifikasyon gerektirebilir.

İşte bu yüzden güvenlik “sonradan eklenemiyor” — çünkü değişimin maliyeti, riskin kendisinden yüksek görünüyor.

Savunma tarafı: gerçekçi katmanlar

Protokolü değiştiremiyorsak, etrafını sarıyoruz:

Ağ segmentasyonu: OT ağını IT’den ayır, Purdue modeline göre katmanla (serinin ayrı bir yazısında).
Modbus/TCP Security: TLS destekli sürüm mümkünse devreye alınmalı — ama eski cihazlarda çoğu zaman mümkün değil.
Tek yönlü diyot (data diode): kritik segmentten yalnızca dışarı veri akışına izin ver.
Derin paket denetimi: OT-farkında güvenlik duvarları ile hangi fonksiyon kodunun kime izinli olduğunu filtrele.
Pasif izleme: OT ağını dinleyip beklenmedik Write komutlarını yakala.

Adli bilişim açısı

Bir OT olayında “hangi komut, hangi kaynaktan, ne zaman geldi” sorusu delil demektir. Modbus’ta kimlik doğrulama olmadığı için, kaynağı belirlemenin tek yolu genelde ağ trafiğinin pcap kaydıdır. Bu yüzden OT ağlarında pasif kayıt (network tap + pcap) adli açıdan altın değerindedir — cihazın kendisi size kim olduğunu söylemeyecektir. CAN bus tarafında benzer bir “trafikten timeline çıkarma” konusunu serinin ayrı bir yazısında işliyorum.

Kapanış

Modbus’ın hikâyesi tek bir protokolün değil, tüm OT dünyasının hikâyesi: kapalı bir dünya için tasarlanmış sistemlerin açık bir dünyaya taşınması. Çözüm protokolü suçlamak değil, onu hangi varsayımlarla tasarlandığını bilerek doğru katmanlarla sarmak. Ve bir olay olduğunda, bu protokollerin bize kanıt bırakmadığını baştan kabul edip izlemeyi ağ katmanına taşımak.

Bu içerik eğitim ve savunma amaçlıdır.

OCPP 2.0.1'in Güvenlik Modeli: EV Şarj Altyapısında Saldırı Yüzeyi

Mon, 17 Aug 2026 16:01:02 GMT

Türkiye’de elektrikli araç şarj altyapısı son birkaç yılda katlanarak büyüdü. Cadde başındaki her AC/DC şarj ünitesinin arkasında, çoğu zaman görünmeyen bir protokol çalışıyor: OCPP (Open Charge Point Protocol). Şarj istasyonu ile onu yöneten merkezî sistem (CSMS) arasındaki tüm konuşma bu protokol üzerinden geçiyor — kimin ne zaman ne kadar şarj aldığı, faturalandırma, uzaktan başlat/durdur, firmware güncellemesi.

OCPP’nin ilk sürümleri güvenliği neredeyse hiç düşünmeden tasarlandı. 2.0.1 ile birlikte tabloya güvenlik profilleri, TLS ve sertifika yönetimi girdi. Ama sahada gördüğüm gerçek şu: standardın “yapabilirsin” dediği güvenlik önlemleri, uygulamada çoğu zaman “yapılmamış” durumda. Bu yazıda protokolü bir saldırganın gözünden, üç katmanlı bir saldırı yüzeyi olarak inceliyoruz.

OCPP mimarisini 30 saniyede oturtalım

Zincir üç halkadan oluşuyor: elektrikli araç → şarj istasyonu (Charge Point) → CSMS (backend). Araç ile istasyon arasındaki konuşma ISO 15118 / güç hattı iletişimi tarafında; istasyon ile backend arasındaki konuşma ise OCPP tarafında yürüyor. OCPP 2.0.1, taşıma katmanı olarak WebSocket (ws / wss) kullanır ve mesajlar JSON formatındadır.

Kritik nokta: şarj istasyonu genelde bir gömülü Linux ya da RTOS cihazıdır. Yani karşımızda hem bir ağ istemcisi, hem bir gömülü cihaz, hem de para akışına dokunan bir uç nokta var. Üçünün kesişimi de saldırı yüzeyini büyütüyor.

1. Katman — Fiziksel ve yerel arayüz

Şarj istasyonu, kilitli bir kabinin içinde bile olsa “fiziksel olarak erişilemez” değildir. Sahada en sık karşılaşılan zayıflıklar:

Açıkta bırakılmış debug/servis portları (UART, JTAG) ve şifresiz servis menüleri
Firmware’i doğrudan barındıran, çıkarılabilir SD kart veya eMMC
Servis moduna geçince kullanıcı adı/parola sormayan bakım arayüzleri

Bu katman ele geçirildiğinde saldırgan yalnızca tek bir istasyonu değil, o istasyona gömülü CSMS bağlantı bilgilerini, sertifikaları ve anahtarları da elde eder. Bir istasyondan çıkarılan kimlik bilgisi, tüm filoya sızmanın kapısı olabilir.

2. Katman — OCPP taşıma katmanı

OCPP 2.0.1 üç güvenlik profili tanımlar: yalnızca temel kimlik doğrulama, TLS + temel kimlik doğrulama, ve TLS + istemci sertifikası (mTLS). Standart en güçlü profili önerir ama zorunlu kılmaz. Pratikte gördüklerim:

Bağlantının hâlâ şifresiz ws:// üzerinden kurulması
TLS kullanılsa bile istemci tarafında sertifika doğrulamasının atlanması (self-signed kabul etme)
Sabit kodlanmış ya da tüm filoda ortak paylaşılan kimlik bilgileri

Şifresiz veya doğrulamasız bir bağlantı, klasik bir ortadaki adam (MITM) senaryosuna kapı açar. Saldırgan araya girip mesajları okuyabilir, faturalandırma verisini manipüle edebilir veya sahte komutlar enjekte edebilir.

3. Katman — Backend güveni ve komut kötüye kullanımı

OCPP çift yönlü bir protokoldür: CSMS istasyona komut gönderebilir. RequestStartTransaction, RequestStopTransaction, Reset, UpdateFirmware, SetVariables gibi mesajlar bunlardan bazıları. Eğer saldırgan sahte bir CSMS gibi davranabiliyor ya da gerçek CSMS’e komut enjekte edebiliyorsa:

İstasyonu uzaktan durdurup hizmet dışı bırakabilir (DoS)
Zararlı firmware yükleme akışını tetikleyebilir
Yapılandırma değişkenlerini değiştirerek istasyonu güvenlik profili düşük bir moda çekebilir

Buradaki asıl risk tek bir istasyon değil, ölçektir. Merkezî sisteme güvenerek çalışan yüzlerce istasyon, backend güveni kırıldığında aynı anda etkilenebilir.

Savunma tarafı: ne yapılmalı

Bir güvenlik analizi, çözüm önermeden yarım kalır. Öncelik sırasıyla:

mTLS’i zorunlu kıl — istemci sertifikası olmadan bağlantı kabul etme.
Sertifika sabitleme (pinning) ve düzgün bir PKI/sertifika rotasyonu kur.
Güvenli boot ve şifreli depolama ile yerel arayüzden anahtar sızmasını engelle.
Komut yetkilendirmesi: her OCPP komutunun kaynağını ve yetkisini doğrula.
Backend tarafında anomali tespiti: aynı istasyondan olağan dışı komut/işlem paternlerini izle.

Adli bilişim açısı

Bir şarj istasyonu olayında iş “saldırı oldu mu” sorusundan “ne oldu, ne zaman, hangi izle” sorusuna geçtiğinde adli bilişim devreye girer. OCPP tarafında işlem logları, mesaj zaman damgaları ve firmware güncelleme kayıtları birer delildir. Gömülü cihaz tarafında ise uçucu bellek, NVRAM ve yapılandırma bölümü incelenmesi gereken artefaktlardır. OT/gömülü sistemlerde klasik disk imajı almak çoğu zaman mümkün olmadığından, canlı analiz ve seçici delil toplama öne çıkar — bu konuya serinin ayrı bir yazısında gireceğim.

Kapanış

OCPP 2.0.1 aslında ihtiyacımız olan güvenlik araçlarının çoğunu içeriyor. Sorun protokolde değil, uygulama ve konfigürasyonda. “Standart destekliyor” ile “sahada açık” arasındaki fark, tam da savunma yapan mühendisin doldurması gereken boşluk. Bu boşluğu görmek için de protokolü hem gömülü hem ağ hem de operasyonel açıdan aynı anda okumak gerekiyor.

Bir sonraki yazıda benzer bir “güvenlik sonradan eklendi” hikâyesini bu kez OT dünyasının en yaygın protokolü Modbus üzerinden anlatacağım.

Bu içerik eğitim ve savunma amaçlıdır. Anlatılan zafiyetler gerçek sistemlere yönelik bir saldırı reçetesi değil, savunma ve adli analiz için farkındalık amacıyla ele alınmıştır.

4624'ten DCSync’e: bir lateral movement avcısı inşa etmek

Wed, 12 Aug 2026 15:22:49 GMT

crabwalk: MITRE ATT&CK’e maplenen, ground-truth corpus’a karşı doğrulanmış açık kaynak bir DFIR aracı