PLC’ye Dokunmadan Üretimi Etkilemek

PLC programını değiştirmek için gereken erişimi sıkılaştırdık. Mühendislik projesi korunuyor, program yüklemek sınırlandırılmış. Buna rağmen bir saldırgan üretim hücresinin içine ulaştığında, saha cihazlarının kendi işlevlerini kullanarak üretimi etkileyebilir mi?

Bu sorunun cevabını yalnız PLC’de ararsak önemli bir yolu atlayabiliriz. Kontrolörün programı kadar, konuştuğu cihazların iletişim ayarları ve kabul ettiği komutlar da prosesin çalışmasını belirler. Bunlardan biri yetkisiz değiştirilebiliyorsa, PLC kodu aynı kaldığı hâlde sistemin davranışı değişebilir.

Ağdan ulaşılabilen bir cihaz, gelen işlemin yetkisini nerede denetliyor?

Mühendislik yazılımındaki yetki, cihazda da denetleniyor mu?

Devreye alma, keşif, adresleme ve bakım işlevlerini genellikle üreticinin yazılımından kullanırız. Bu alışkanlık, ilgili işlemin ancak o yazılımla yapılabileceği izlenimini oluşturabilir. Oysa cihaz ağdaki isteği kendi protokol arayüzünde karşılar. Güvenlik değerlendirmesinde, yazılımın kullanıcıya sunduğu kısıtlamalar kadar bu arayüzün neyi kabul ettiğine bakmak gerekir.

Örneğin bir uygulamanın menüsünde belirli bir ayarı değiştirmek için yönetici hesabı gerekebilir. Bu, aynı ayarın başka bir ağ işlevi üzerinden de yönetici kimliğiyle korunduğunu tek başına göstermez. Her erişim yolunun kontrolünü ayrıca doğrulamalıyız.

Buradaki güven sınırı, cihaza ulaşabilmek ile cihazda işlem yapmaya yetkili olmak arasındadır. Protokole uygun bir istek, işletmenin onayladığı bir işlem anlamına gelmez. Hedef, isteği gönderenin kimliğini ve o işlem için iznini yeterince denetlemiyorsa, ağdaki konum beklediğimizden fazla yetki sağlayabilir.

Ağ erişimi hangi koşullarda etkili bir yetkiye dönüşür?

Bir cihazın ağda görünmesi, bütün ayarlarının değiştirilebildiği anlamına gelmez. Risk için birkaç koşulun birlikte oluşması gerekir: kaynak ilgili arayüze ulaşabilmeli, işlem desteklenmeli, cihaz mevcut çalışma durumunda isteği kabul etmeli ve yetkisiz kullanımı durduran cihaz veya ağ kontrolü bulunmamalı.

Kimlik doğrulama ve yetkilendirme farklı soruları cevaplar:

• Kimlik doğrulama — authentication: İsteği gönderen gerçekten iddia ettiği kaynak mı?
• Yetkilendirme — authorization: Bu kaynak, bu cihazda bu işlemi yapmaya yetkili mi?

Tanıdık bir MAC adresi kimlik doğrulaması değildir. Kimliği doğrulanmış bir istasyonun da her cihazda her işlemi yapmasına izin vermek zorunda değiliz. Üstelik yetkili istasyon ele geçirildiğinde, geçerli kimlik kullanılarak bakım kapsamı dışına çıkılabilir.

Şifreleme konuşmanın gizliliğini koruyabilir; kimin hangi işlemi yapabileceği sorusunu tek başına cevaplamaz. Kimlik doğrulama, işlem yetkisi ve mesaj bütünlüğü ayrıca değerlendirilmelidir. Bu ayrım, PROFINET’in güvenlik yaklaşımında da ayrı koruma amaçları olarak yer alır. PI, PROFINET güvenlik yaklaşımı

Somut bir örnek — PROFINET DCP

DCP, PROFINET cihazlarının keşfi, adlandırılması ve IP yapılandırması için kullanılır. Devreye alma sırasında gerekli olan bu işlev, hedef yazmayı kabul ediyorsa doğrudan cihazın iletişim ayarına müdahale edebilir.

Yerel Ethernet erişimi varsa, hedef cihaz ilgili DCP yazmasını kabul ediyorsa ve işlemi engelleyen cihaz/ağ kontrolü yoksa, cihaz adı veya IP yapılandırması değiştirilebilir. Siemens’in SCALANCE LPE9403 V4.0 kılavuzu, aynı yerel ağdaki bir kaynağın bu ayarları kimlik doğrulaması olmadan değiştirebilmesini açıkça anlatır. Aynı kılavuzda varsayılan yazma erişimi teslim/sıfırlama durumuna bağlıdır; diğer durumda varsayılan olarak yazılamaz. Bu, belgelenmiş bir ürün davranışıdır; bütün saha cihazlarının aynı ayarla çalıştığını varsayamayız. Siemens, DCP erişim hakları, §7.9.3

Siemens ProductCERT’in SSB-201698 bülteni de ilgili DCP yapılandırma ve sıfırlama işlevlerinin kötüye kullanılmasıyla hizmetin aksayabileceğini bildirir. Kapsamı PROFINET Security Class 1’e uymayan ürünler ve ilgili işlevleri destekleyen cihazlarla sınırlar. Siemens ProductCERT, SSB-201698

Aynı hücrede, PLC’ye uğramayan bir yol

Mühendislik istasyonunun ele geçirildiğini varsayalım. Turuncu yol istasyon → hücre anahtarı → hedef cihaz. İstasyon yerel Ethernet alanına erişiyor ve DCP gönderebilecek yetkiye sahip. Hedef ilgili yazmayı kabul ederse değişiklik doğrudan onun yapılandırmasında gerçekleşiyor.

Bu yol için PLC programını değiştirmek, PLC’yi ele geçirmek veya PLC’nin mühendislik arayüzünü kullanmak gerekmiyor. Üreticinin PLC programlama yazılımı da zorunlu değil; DCP konuşabilen bağımsız uygulamalar mevcut. Bağımsız DCP uygulamasının dokümantasyonu

DCP doğrudan Ethernet üzerinde çalışır, IP yönlendirmesinden geçmez. Şemadaki konuşma hücre sınırındaki güvenlik duvarına uğramadığı için yalnız dış bağlantıdaki IP kuralları bu yolu denetlemez. VLAN, port yalıtımı ve yerel Ethernet filtreleri erişimi değiştirebilir; aynı anahtara bağlı olmak tek başına yeterli değildir. Mor SPAN hattının gösterdiği yerel gözlem noktası da bu yüzden önemlidir: yalnız üst ağ bağlantısını izleyen sensör konuşmayı kaçırabilir.

PLC kodu aynı kalırken ne değişmiş olur?

PROFINET cihaz adı, kontrolörün beklediği cihazı bulmasının bir parçasıdır; IP ataması da bu ad üzerinden yürütülebilir. Projede dolum-io-01 beklenirken hedef başka bir ad bildirirse, aynı fiziksel cihaz yerinde olsa bile beklenen eşleşme bozulabilir. PI, adresleme ve bağlantı başlangıcı, §2.5–2.6

PLC’ye yeni kod yüklenmemiştir. Değişen şey, kontrolörün cihazla haberleşmesinin dayandığı yapılandırmadır. Etkinin mevcut bağlantıda mı, yeniden bağlantı kurulurken mi görüleceği cihaz davranışına bağlıdır. İletişim kaybının proseste yaratacağı sonuç da kontrolörün hata tepkisine, yedek değerlere ve işletme tasarımına bağlıdır. Ad değişti diye her hat anında durmaz.

Değiştirilmek istenen değer paketin neresinde?

Kaynak istasyon, hedefin anlayacağı bir DCP Set isteği oluşturabilir. Mevcut bir paketi araya girip değiştirmek şart değildir; yeni bir isteğin içine istenen yapılandırma değeri konabilir. Ethernet başlığındaki kaynak ve hedef MAC adresleri konuşmanın taraflarını, DCP bloğu ise hangi ayara ne yazılmasının istendiğini gösterir.

Karttaki 0x8892 PROFINET Ethernet türüdür; tek başına DCP’yi ayırmaz. FrameID: 0xfefd, DCP Get/Set yolunu; ServiceID: Set ve ServiceType: Request ise yapılandırma isteğini gösteriyor. Xid yanıtı eşleştirmeye yarar, kimlik veya yetki kanıtı değildir.

Asıl değişiklik talebi Device properties / Name of Station bloğundaki NameOfStation: dolum-io-02 değerinde. Projede beklenen dolum-io-01 bu isteğin içinde taşınmıyor; yeni ad gönderiliyor. BlockQualifier da kalıcı saklama istendiğini belirtiyor. Bu örnekte yeni ad 32–42 konumlarında; farklı blok dizilimi, VLAN etiketi veya kapsülleme konumları değiştirebilir.

Bu sentetik istek dosyadan tcpdump 4.99.4 ile okundu, DCP alanları TShark 4.2.2 ile çözümlendi. tcpdump bu sürümde Ethernet özetini gösteriyor; ayrıntılı alanlar TShark’tan geliyor. Wireshark, DCP alan referansı

Paketin anlamı “bu cihazın adını bu değere değiştir”dir. İsteğin oluşturulabilmesi, değişikliğin kabul edildiğini göstermez. Kritik kontrol hedefte: cihaz bu kaynağın yazmasına izin veriyor mu? Ardından yanıtın işlem sonucu ve cihazın bildirdiği ad kontrol edilir.

Cihazın adı değil, yapılandırması sıfırlanırsa?

PLC programı aynı kalırken, saha cihazının haberleşmek için ihtiyaç duyduğu ayarlar silinirse ne olur? Ad değişikliğinde bozulan eşleşme, bir sıfırlamada yeniden devreye alma ihtiyacına dönüşebilir. Kesintinin süresi ve üretimdeki karşılığı, silinen verilere ve sistemin bunları nasıl geri yüklediğine bağlıdır.

DCP’nin kapsamı ad ve IP atamakla bitmiyor. Siemens ProductCERT, ilgili cihazlarda çalışma sırasında Reset-to-Factory işleminin kötüye kullanılabileceğini de belirtiyor. Yerel Ethernet erişimi varsa, cihaz ilgili sıfırlamayı mevcut durumunda kabul ediyorsa ve yetkisiz işlemi engelleyen kontrol yoksa, bu da PLC’ye uğramadan saha cihazını etkileyen bir yol olabilir. Siemens ProductCERT, SSB-201698

Sıfırlamanın kapsamı da tek değil. ABB’nin DCP reset tanımları şu ayrımı gösteriyor:

Bu tanımlar her cihazın bütün modları desteklediği anlamına gelmiyor; ürün, firmware ve etkin güvenlik profili belirleyici. Mühendislik verilerini sıfırlayabilmek de DCP ile istediğimiz PLC programını yükleyebilmek demek değil. Buradaki senaryoda hedef saha cihazı; PLC programına dokunulmuyor. ABB, DCP reset modları

Bu cihazda hangi kayıtlı veriler ağdan sıfırlanabiliyor ve cihaz bunlar olmadan nasıl çalışıyor?

Aynı soru başka bir protokolde de karşımıza çıkar mı?

Modbus üzerinden bir sürücüyle iletişimi düşünelim. Protokolde cihaz verilerine yazma işlevleri vardır; Modbus Organization’ın açıklaması da sürücü komutlarını bu yolla örnekler. Yazılabilir bir değer gerçekten cihazın davranışına bağlıysa, kontrol kaynağı buna göre seçilmişse ve yetkisiz yazmayı durduran kontrol yoksa, doğrudan cihazla iletişim ayrı bir etki yolu olabilir. Burada neyin yazılabildiğini ve geçerli olup olmayacağını cihazın veri eşlemesi, çalışma modu ve erişim ayarları belirler. Modbus Organization, protokolün kullanım örnekleri

DCP’deki yerel Ethernet erişimi ile Modbus TCP’nin IP üzerinden erişimi aynı değildir; ağda denetlenecek yollar değişir. Ortak soru, hedefin kabul ettiği işlemi kimin yapmaya yetkili olduğudur.

Üstelik Modbus/TCP Security, karşılıklı sertifika doğrulaması ve ürünün uyguladığı rol temelli işlem yetkisini tanımlar. Bu nedenle protokol adından tek başına “yetkisiz yazılabilir” sonucu çıkaramayız. Protokolün güvenlik profili, varsa security class’ı, ürün, firmware ve etkin konfigürasyon birlikte incelenmelidir. Modbus/TCP Security, §6 ve §8.4

Hücreyi bu gözle nasıl değerlendirelim?

Hücreyi incelerken cihazın kabul ettiği işlemi, ona ulaşan kaynağı ve işlemin üretimdeki karşılığını birlikte değerlendirelim:

• Hedef ve işlev: Cihazda hangi keşif, devreye alma, yapılandırma veya operasyon işlevleri erişilebilir? Hangileri yalnız okuyor, hangileri durum değiştiriyor?
• Kimlik ve yetki: Her arayüz kaynağı nasıl doğruluyor, hangi işlemi kime açıyor? Salt okunur mod, rol veya kaynak kısıtlaması gerçekten ilgili yolu kapsıyor mu?
• Yaşam döngüsü: Devreye alma, cihaz değişimi veya sıfırlama sonrasında yazma erişimi değişiyor mu? Bakım tamamlandığında kontroller yeniden doğrulanıyor mu?
• Gözlem ve sonuç: İstek bakım kapsamıyla uyumlu mu, hedef kabul etmiş mi, sonraki cihaz durumu değişmiş mi? Üretim etkisi ayrıca kontrolör ve proses kayıtlarıyla doğrulanıyor mu?

Meşru bakım trafiğini de hesaba katmalıyız. Örneğin PROFINET kontrolörü tanımlı topoloji üzerinden otomatik ad atayabilir. Bir yapılandırma yazması görmek tek başına saldırı kanıtı değildir; kaynak, hedef, işlem, yeni değer ve bakım kapsamını birlikte okumak gerekir. PI, otomatik ad atama

PLC programının korunması önemli bir kontrol. Üretimin geri kalanındaki güveni ise saha cihazlarının kendi arayüzlerinde aramalıyız: hücrenin içinden hangi cihaza ulaşılabiliyor ve o cihaz, ulaşan kaynağa hangi değişiklikleri yaptırıyor?

Teknik not — DCP örneğinin ayrıntıları

Enerjiyi kesip vermek adı geri getirir mi?

Adın nasıl yazıldığına bağlı. HMS’nin PROFINET cihazlarında geçici atanan ad güç çevriminde kaybolurken, kalıcı atanan ad bellekte kalır. Yeniden başlatmak, kalıcı yazılmış bir adı eski hâline döndürmez. HMS, geçici ve kalıcı cihaz adı

Yukarıdaki Set örneğinde BlockQualifier, yeni adın kalıcı saklanmasını istiyor. Cihaz bu yazmayı uygulamışsa, enerjiyi kesip vermek yeterli olmayabilir. Cihazın şu an bildirdiği adı projede beklenen adla karşılaştırmak gerekir. Paketteki kalıcılık seçimi, tek başına cihazın ne sakladığını kanıtlamaz.

Sıfırlama sonrasında yazma erişimi

DCP reset tanımlarında ResetAndRestoreData, yüklü yazılımı fabrika imajına döndürmeyi de kapsar. Bu modun cihazda bulunması ve kabul koşulları ayrıca doğrulanmalı; tanımın varlığı, her üründe firmware değiştirilebildiğinin kanıtı değildir. Ad yazmasındaki kalıcı/geçici saklama yorumunu da reset bloğuna taşımayız; burada alanın anlamı sıfırlama kapsamıdır. ABB, DCP reset modları

Fabrika ayarlarına döndüğümüzde DCP erişim ayarı da değişebilir. Örneğin SINEC OS v3.0’da, teslimde veya sıfırlama sonrasında cihaz setup modundayken DCP okuma-yazma erişimi açıktır. İlk yönetici girişinde yeni parola atanması ya da yapılandırma dosyasının yüklenmesiyle salt okunur hâle gelir. Bu davranış o ürün ve sürüme ait; kendi cihazımızda hangi ayarın geri geldiğine bakmalıyız. Siemens, SINEC OS v3.0, §12.2.2.1

Salt okunur moda geçmeden, yeni cihazın adını kimin atayacağını da netleştirmek gerekir. Kontrolörün otomatik ad ataması da bir yazma işlemidir; erişimi kapatmak bu bakım adımını etkileyebilir.

Ad ve IP dışında başka hangi DCP işlevleri var?

Siemens’in bülteni, destekleyen ürünlerde DHCP yapılandırmasını da değiştirilebilen ayarlar arasında sayıyor. Hilscher’in dokümanındaki Set Signal ise cihazın tanımlama LED’ini etkinleştiriyor; cihazı panoda bulmaya yarayan bu işlev, proses ayarı yazmakla aynı şey değil. Keşif yanıtında bir alanın görünmesi de o alanın yazılabildiğini göstermez. Siemens ProductCERT, Hilscher, DCP Set Signal, §3.2.7

Yanıt geldi; cihazın adı değişti mi?

Önce yanıtın hangi isteğe ait olduğunu buluruz. Kaynak/hedef MAC adresleri, servis, Xid ve zaman birlikte okunur; ardından yanıtın ilgili seçenek/alt seçenek için verdiği sonuca bakılır.

Response Success başlığına bakıp adın değiştiğini söylemek acele olur. Şekildeki ilk yanıtta başlık böyle olmasına rağmen Control/Response bloğundaki BlockError, In operation, SET not possible diyor: cihaz ilgili yazmayı reddetmiş. İkinci yanıtta blok sonucu Ok; burada ilgili işlem için olumlu yanıt var. Wireshark, DCP ayrıştırıcısı

Blok Ok diyorsa sıradaki kontrol cihazın bildirdiği addır. Projede dolum-io-01 beklenirken cihaz dolum-io-02 bildiriyorsa, yapılandırmanın projeden saptığını görürüz. Bunun iletişime ve prosese etkisini ise kontrolörün teşhisleri ve proses kayıtlarıyla takip ederiz.

Wireshark’ta pn_dcp filtresiyle bu konuşmalar ayrılabilir. Alanları okurken şu ayrım işimizi kolaylaştırır:

Yanıt görünmüyorsa “cihaz reddetti” diyemeyiz. Aynalama yalnız bir yönü kapsıyor olabilir, paket kaybolmuş olabilir veya cihaz yazma isteğine yanıt vermiyor olabilir. Bu durumda cihazdaki ayarı başka bir gözlemle doğrulamadan sonucu kapatmak erken olur. Wireshark, DCP alan referansı