IPv6’da Güvenli Komşu Keşfi (SEND) ve DAD Proxy

0
115
views
Günümüzde akıllı cihazların (cep telefonları, IP telefon, sayısal fotoğraf makineleri, buzdolabı, kamera,…) artması sonucunda 32 bitten oluşan IPv4 internet protokolünü (IP) yetersiz kalmaktadır. Bu yazıda komşu keşfinin güvenli hale getirilmesi için gereken Güvenli Komşu Keşfi yapısı ve bu protokole yönelik güvenlik açıklıkları ile DAD Proxy konusu açıklanarak, güvenli bir IPv6 altyapısı için neler yapılması gerektiği incelenmiştir.

Pentist: Sızma Testleri ve Bilgi Güvenliği Danışmanlık Hizmetleri

 

A) Güvenli Komşu Keşfi (SEND)

IPv6 ND protokolündeki zafiyetlere yönelik ataklara karşı önlem alabilmek için kimlik doğrulama, istemcinin sahip olduğu adresi kanıtlaması, mesajların bütünlüğünün sağlanması ve yönlendiricilerin yetkilendirilebilmesi gibi çeşitli önlemlerin alınması gerekmektedir. Bu noktada bu işlemleri gerçekleştiren bir mekanizma, Güvenli Komşu Keşfi (Secure Neighbor DiscoverySEND), RFC 3971’de tanımlanmıştır.

RFC 3971’de SEND için 4 yeni başlık yapısı tanımlanmaktadır;

  • CGA
  • RSA imza
  • Tek seferlik değer (Nonce)
  • Zaman damgası(Timestamp)

Bu seçeneklere ek olarak, RFC 3971’de SEND için 2 farklı mesaj tipi tanımlanmaktadır;

  • CPS (Certification Path Solicitation)
  • CPA (Certification Path Advertisement)

CPS ve CPA mesajları da kendi içerisinde TA ve Sertifika seçeneklerini kullanmaktadır.

 

A.1) SEND Mesajları

SEND ile gelen CPS ve CPA mesajları başlık yapıları RFC 3971′ e göre aşağıdaki gibi tanımlanmaktadır.

CPS başlık yapısı aşağıda gösterilmiştir.

Şekil 1: Sertifika Yolu İstek Mesajı(CPS) [4]

Bunun yanında CPA başlık yapısı da aşağıdaki şekilde gösterildiği gibidir.

Şekil 2: Sertifika Yolu Duyuru Mesajı (CPA) [4]

Tip, Kod, Rezerve alanlarının ile ilgili detaylı bilgi için kaynaklardaki Siberportal bağlantısı incelenebilir. ICMPv6 paketinde tip 148 mesajın bir CPS mesajı olduğunu, tip 149 mesajın bir CPA mesajı olduğunu ifade etmektedir. Bunun yanında mesajlarda yer alan diğer alanlar şu şekilde açıklanabilir;

  • Identifier (Tanımlayıcı): CPS ve CPA mesajlarının eşleşmesini sağlayan bir değerdir. Her iki seçenekte de aynı değere sahiptir.
  • Component (Bileşen): İstemcinin ilgilendiği sertifika yoluna bir dizin sağlamaktadır. Yani istemci “ben şu sertifika yolu ile ilgileniyorum” şeklinde bir mesaj yollamaktadır. İstemci güvendiği TA sunucusuna ait bilgileri içeren TA seçeneğini de ekleyebilir. Bu durumda istemci kendisinin sertifika yoluna güvenmesi için ilgili sertifika yolunun bu TA ile imzalanmış olması gerektiğini bildirir. Bu alan CPS mesajında da CPA mesajında da mevcuttur. CPA mesajında yer aldığında sertifika seçeneği ile gönderilen sertifikanın sertifika yolundaki dizinini göstermektedir. Yani hangi sertifika yolundaki sertifikanın gönderileceğini istemciye bildirir [5].
  • All Component (Bütün Bileşenler): Bu alan TA sunucu bilgisine kadar uzanan tüm sertifika yolundaki toplam sertifika sayısını göstermektedir. CPA mesajı bir veya birden fazla sertifika yolunu ve o sertifika yolundaki sertifikaları istemcilere göndermek için kullanılmaktadır. Sertifikaları göndermek için sertifika seçeneği CPA mesajına ek olarak gönderilir. [5]
  • Options (Seçenekler): CPS mesajına TA seçeneği, CPA mesajına ise TA seçeneği ve sertifika seçeneği gelebilmektedir. Bu seçeneklerden ilki TA seçeneğinin başlık yapısı RFC 3971’e göre aşağıda gösterilmiştir.

 

Şekil 3: TA (Trust Anchor) Seçeneği [4]

Başlık yapısı gösterilen TA seçeneği, sertifika yolu ile ilgili isim bilgilerini içermektedir. Başlık yapısındaki her bir alanın kısa açıklaması aşağıda gösterildiği gibidir.

  • Name Type (İsim Tipi): Bu alan Name(İsim) alanında yer alacak ismin türünü bildirmektedir. İki çeşit olabilir. Buraya 1 gelirse isim türünün DER ENCODED X.501 olduğunu 2 gelirse FQDN(Fully Qualified Domain Name) türünde olduğunu bildirmektedir [4].
  • Name (İsim): Bu alanda TA sunucusunu gösteren isim, İsim Tipi alanında belirtilen formatta yer alır. Örneğin İsim Tipi kısmı “2” olarak ayarlandıysa buraya TA sunucusunun FQDN isim karşılığı gelir. Buna örnek olarak “Trustanchor.example.com” vb. verilebilir [4].
  • Pad Length (Dolgu uzunluğu): Uzunluk alanında belirtilen başlık uzunluğunu tamamlayacak şekilde gelmesi gereken oktet sayısını belirtmektedir. Gönderici ve alıcı tarafından dikkate alınmayan sıfırlardan oluşur [4].

CPA mesajına gelebilecek bir diğer seçenek olan sertifika seçeneği başlık yapısı RFC 3971’e göre aşağıda gösterilmiştir.

Şekil 4: Sertifika Seçeneği [4]

Sertifika seçeneği CPA mesajı ile bilgisayarlara gönderilen sertifikaları içeren başlıktır. Bir sertifika yolu göstermek için tek bir sertifikaya sahiptir. [5]. Sertifika seçeneği başlık yapısında gösterilen alanların açıklamaları özet olarak aşağıdaki gibi ifade edilebilir.

  • Cert Type (Sertifika Tipi): Bu alanda sertifika alanında ne tür bir sertifika olduğunu göstermektedir. Şu an için tek bir yasal sertifika türü olan X.509.v3 sertifikasını göstermek için bu alana “1” değeri gelmektedir [4].
  • Certificate (Sertifika): Sertifika tipi alanı “1” olarak ayarlandığında bu alan bir X.509v3 sertifikası içermektedir [4].

SEND yapısında kullanılan CPS ve CPA mesajları ve bunların seçenekleri kullanılarak sahte yönlendirici ve sahte RS/RA ataklarına karşı önlem alınabilmektedir. Bu önlem temelde RA mesajı gönderen yönlendiricilerin sertifikalarının güvenilir olup olmadığının teyit edilmesi ve paketin ona göre kabul edilip edilmemesini ifade etmektedir. Bu yönteme Yetkilendirme Delegasyon Keşfi (Authorization Delagation DiscoveryADD) denilmektedir. Şekil 5’te ADD süreci gösterilmiştir ve şu şekilde özetlenebilir.

  • İstemciler yalnızca güvenilir bir sertifika otoritesi tarafından imzalanan sertifikalara güvenmektedirler.
  • Bir yönlendirici istemcilere RA mesajı yolladığında istemci yönlendiricinin sertifikasının kendi güvendiği sertifika otoritesi tarafından imzalanıp imzalanmadığına bakar
  • Bir yönlendirici RA mesajı yaydığında, bilgisayar “Ben şu TA sunucusuna güveniyorum, sen kimsin, sertifika yolunu gönder” şeklinde CPS mesajı yollar
  • Yönlendirici CPA mesajı ile sertifika zincirini ve sertifika yolunu gönderir
  • Bilgisayar bu sertifika zincirini adım adım kontrol eder, zincirin herhangi bir noktasında imza hatası varsa RA mesajını düşürür, sertifika zincirinde herhangi bir hata yoksa RA mesajını kabul eder.
  • Eğer sertifika yolundaki sertifikalar geçerli x.509 imzasına sahipse istemci bu yönlendiriciyi güvenilir kabul eder ve bu yönlendiriciden gelen paketlere güvenir. Güvenilir bir sertifika otoritesi tarafından imzalanmamış paketlere ise güvenmeyecek ve böylelikle yönlendiriciler üzerinden gelebilecek olan saldırılara karşı önlem alınabilecektir.

Bunun yanında ADD sürecinde DOS ataklarına maruz kalınmaması için sertifika yolu bilgisayarlarda depolanmadan evvel doğrulanmalı. Çünkü doğrulanmadan depolanırsa DOS ataklarına açık hale gelir. Bir saldırgan bir bilgisayara doğrulayamayacağı sertifikalar göndererek o bilgisayarın hafızasının dolmasına sebebiyet verebilir [4].

Şekil 5: ADD Süreci

 

A.2) SEND Seçenekleri

ND protokolünü güvenli hale getirmek için SEND ile birlikte 4 farklı seçenek tanımlanmıştır. Bu seçenekler aşağıda incelenmiştir.

A.2.1) CGA (Cryptographically Generated Address) Seçeneği

CGA, adres hırsızlığının yani bir saldırganın bir istemcinin adresini taklit etmesinin önüne geçmek için kullanılan tahmin edilip kırılması zor bir algoritmaya göre üretilip istemcinin özel anahtarı ile imzalandıktan sonra hedefe yollanan paketlerde kullanılan kriptografik IPv6 adreslerini ifade etmektedir. Bu adresler ve istemcinin özel anahtarı ile paketin hedef adrese bozulmadan gitmesi sağlanmaktadır. Bir diğer ifadeyle CGA, istemcinin özel anahtarı ile beraber mesajların bütünlük kontrolünde kullanılmaktadır. CGA seçeneği ise CGA parametrelerinin alıcı tarafa taşınması için kullanılmaktadır. Alıcı taraf bu parametreleri kullanarak üretilen adresin doğru üretilip üretilmediğini, yani kendisine gelen adresin gerçek bir adresten gelip gelmediğini kontrol edecektir. Başlık yapısı aşağıda gösterilmektedir.

Şekil 6: CGA Seçeneği [4]

Bu başlık yapısında gösterilen bölümleri açıklamak gerekirse;

  • Tip: “11” değeri, başlığın bir CGA tanımladığını gösterir.
  • Uzunluk: CGA başlık yapısının toplam uzunluğunu gösterir.
  • Dolgu Uzunluğu (Pad Length): Dolgu kısmının uzunluğunu gösterir.
  • CGA Parametreleri: Genel anahtar, Niteleyici(Modifier), Alt ağ öneki, CC(Collision Counts/Çarpışma sayısı) değerleri olup, CGA üretilmesi ve doğrulanmasında kullanılan parametreleri ifade etmektedir [4].
  • Dolgu (Padding): Başlık yapısını tamamlamak için konulan sıfırlardan oluşan kısımdır. Alıcı tarafından ihmal edilmektedir.

 

A.2.2) RSA İmza Seçeneği

SEND’de göndericinin kimliğinin doğruluğunun ispatı için RSA imza seçeneği kullanılmaktadır. Her cihaz kendi RSA genel/özel anahtar çiftlerini üretir. Genel anahtar CGA üretiminde, özel anahtar ise ND mesajlarının imzalanmasında kullanılmaktadır. Özel anahtar ile imzalama işlemi saldırganların iki cihaz arasına girip NP mesajlarının aldatılmasını engellemektedir. RSA imza seçeneğinde, gönderilecek olan her ND mesajının RSA imzası taşınmaktadır [1]. Aşağıda bir RSA imza seçeneğinin yapısı gösterilmiştir.

Şekil 7: RSA İmza Seçeneği [4]

Bu seçenekte gösterilen Digital Signature(Dijital imza) alanında göndericinin dijital imzası yer almaktadır. Key Hash(Anahtar Hash değeri) değeri ise imza oluşturulurken kullanılan genel anahtarın sha-1 hash değerinin soldan 128 bitlik kısmını içermektedir[5]. RFC 3971’e göre özel anahtar ile imzalanan alanlar şu şekilde ifade edilebilir [4]:

  • CGA Message Type Tag(CGA Mesajı Tip Etiketi)
  • ICMPv6 başlığında Tip, Kod ve Sağlama alanları
  • ICMPv6 başlığında Sağlama alanından sonraki ND seçeneklerine kadar olan kısım (Hedef ve Kaynak Katman 2 adresi gibi)
  • IPv6 başlığında kaynak ve varış yeri IPv6 adresi

CGA, Tek Seferlik Değer, Zaman Damgası seçeneği de dahil RSA seçeneğinden önceki bütün ND seçenekleriBurada CGA Mesaj Tip Etiketi değeri aynı anahtarı kullanan başka protokol mesajları ile bir çakışma yaşanmaması için kullanılan, IANA tarafından tahsis edilen 128 bitlik bir değerdir [6]. Bu imza alanlarını aşağıdaki şekilde daha detaylı olarak görebiliriz.

Şekil 8: CGA parametreleri ve RSA imza Alanları

 

A.2.3) Tek Seferlik Değer(Nonce) Seçeneği

Nonce seçeneği duyuru ve talep mesaj çiftlerinin sırasını belirlemede kullanılan rastgele bir değerdir [7]. Bir NA mesajının, bir NS mesajına çok yeni bir cevap olduğunu göstermek için kullanılır. Bir NS mesajında yer alan Nonce değerinin aynısı bu NS mesajına giden NA mesajında da yer alır. Böylelikle NS ve NA mesajlarının eşleşmesi sağlanır.

Şekil 9: Nonce Seçeneği [4]

Burada gösterilen Nonce alanı en az 6 byte uzunluğunda rasgele bir değer içermektedir. Mesajların arasına giren birisi Nonce değerini çok kısa sürede tutturması güç olduğu için potansiyel yeniden yayınlama ataklarına karşı koruma sağlamaktadır.

 

A.2.4) Zaman Damgası Seçeneği(Timestramp)

Zaman damgası seçeneğinin amacı, istenmeyen duyuruların ve yönlendirmelerin tekrar yayınlanmadığından emin olmaktır [4]. Kısacası istenmeyen duyuru ve yönlendirme çoklu gönderme adresleri ile gelen yeniden yayınlama ataklarına karşı koruma sağlar. Mesajı gönderen cihaz tarafından bilinen gün saatini içerir. Bu anlamda SEND’e yönelik yeniden yönlendirme ataklarına karşı koruma sağlamaktadır. Aşağıda yapısı gösterilen Zaman Damgası Seçeneğinde, Zaman Damgası alanının ilk 48 biti, 1 Ocak 1970 00:00 UTC zaman diliminden beri geçmiş zamanı saniye cinsinden göstermektedir. Geri kalan bitler ise bir saniyenin (1/64K) kesirli haliyle tutulmasını sağlamaktadır [5].

Şekil 10: Timestamp Option [4]

 

A.3) SEND Süreci

A.3.1) CGA Üretimi

CGA üretim sürecini aşağıdaki şekil ile özetlenmektedir. Üretim sırasında kullanılan Rasgele değer bilgisayar tarafından üretilir. RSA anahtarları ise bilgisayara ürettirilebilir veya başka bir ortamda üretilip bilgisayara yüklenebilir.

Şekil 11: CGA Üretim Algoritması

 

Şekilde anlatılmaya çalışılan CGA üretim aşaması RFC 3972’ye göre adım adım aşağıdaki gibi gerçekleşmektedir [6] :

  1. İşletim sistemi tarafından bir SEC değeri seçilir. SEC değeri (0-7) arasında olabilecek şekilde tasarlanmış olup işletim sistemleri tarafından tanınmaktadır.
  2. Gönderici tarafta işletim sistemi tarafından 128 bitlik bir rasgele bir sayı üretilir. Rasgele sayının yanında RSA genel/özel anahtar çifti de üretilmeli veya işletim sistemine bir yerden sağlanmalıdır. Genel anahtar CGA üretiminde, özel anahtar ise CGA’nın kullanılmadan önce imzalanmasını sağlamaktadır.
  3. 128 bit rasgele sayı değeri, 72 bit sıfır (64 bit önek alanı, ardından 8 bit CC alanı yerine) ve bilgisayarın RSA Genel Anahtarı(DER-Encoded) yan yana koyularak ortaya çıkan değerin SHA1 algoritmasına göre Hash değeri alınır. Bu hash, HASH2 olarak adlandırılır.
  4. Ortaya çıkan HASH2 değerinin yalnızca soldaki 112 biti alınır. Bu değerin son 16*SEC kadar bit sayısı sıfır ile karşılaştırılır. Sıfıra eşitse diğer aşamaya geçilir. Eşit değilse rasgele sayı değeri bir arttırılarak işlem tekrar edilir. Bu işlem 16*SEC kadar bitin sıfır olmasına kadar devam eder. Dolayısı ile bu süre. CGA üretiminde en çok zaman gerektiren işlem yoğunluğunun fazla olduğu süreçtir. Bu süreçteki iyileştirmeler CGA üretim süresini kısaltacaktır.
  5. CC değeri sıfıra ayarlanır.
  6. Bir sonraki adımda en son kullanılan rasgele sayı, 64 bit önek, 8 bit CC ve bilgisayarın RSA genel anahtarı(DER-Encoded), ve uzantı alanları varsa o da yan yana konularak, yani CGA parametleri yan yana konularak bu değerin SHA1’e göre hash değeri alınır ve çıkan sonuç HASH1’dir.
  7. Elde edilen Hash1 değerinin soldaki 64 biti alınır ve önekin yanına arabirim tanıtıcısı olarak konulur. Arabirim tanıtıcısı ilk üç biti SEC değerleri ile değiştirilir. Çünkü SEC değerinin karşı tarafa gönderilmesi gerekmektedir. Bunun yanında U ve G bitleri ilgili değerlerine set edilir. Arabirim tanıtıcısının ilk byte değerinin son iki biti sırasıyla U ve G bit olarak bilinmektedir. U biti küresel/yerel(universal/local) biti olmakla beraber ayarlandığında adresin yerel olarak yönetildiği anlamına gelmektedir. G bit grup biti olarak bilinmektedir ve ayarlandığında ilgili adresin bir grup adresi veya çoklu gönderim adresi tipinde olduğunu da bildirmektedir [5].
  8. Bu şekilde bilgisayarın CGA’sı hesaplanmış olur.
  9. Ardından üretilen CGA’nın ağda kullanılıp kullanılmadığının kontrolü için DAD süreci başlar. DAD süreci sonunda eğer çakışma meydana gelirse CC değeri 1 arttırılarak HASH1 ve arabirim tanıtıcısı yeniden hesaplanır ve tekrar DAD süreci çalışır. CC değeri en fazla 2’ye kadar çıkabilir. 3 kereden daha fazla çakışma meydana gelmesi demek CGA üretimi yapan cihaza, ortamda bir saldırı olma ihtimalini düşündürecek ve üretimi durdurup kaynak tüketiminin önüne geçecektir.

CGA üretimi sırasında HASH2 değerinin hesaplanmasının sebebi kaba kuvvet saldırılara karşı CGA’yı güçlendirmektedir. Önek zaten içerdeki bir saldırgan tarafından tahmin edilebileceği veya bilineceği için aslında CGA’nın kaba kuvvet saldırılarına karşı dayanığı 264 kabul edilebilir. Çünkü IPv6 ID kısmı 64 bittir. Bu 64 bitin ilk üç biti SEC değerini ifade etmek için kullanılmaktadır. SEC değeri buraya yazılıp karşı tarafta doğrulama için kullanılır. Dolayısı ile SEC değeri bilinmektedir. Bunun yanında U ve G bitleri de bilindiği için CGA bu dayanıklılığı 259’a düşmektedir. Yani bir CGA 259 adet tahmin içeren bir kaba kuvvet saldırısı ile bulunabilmektedir. İşte burada önceden belirlenen ve işletim sistemlerinde yer alan SEC değerleri ve HASH2 algoritması bu dayanıklılığı arttırmaktadır. Örneğin SEC=1 olduğunda dayanıklılık 216 kadar artıp 275 olacaktır. SEC değerinin her bir artışında CGA kaba kuvvetleri karşısında 216 kadar daha güçlenecektir.

SEC değerinin her artışı HASH2’nin üretimini zorlaştırmaktadır. Çünkü HASH2’nin 16xSEC değeri kadar soldan ilk bitleri sıfır olarak üretilmek zorundadır. SEC değerinin artışları güvenliği arttırsa da, HASH2 üretimini zorlaştırdığı için CGA üretim süresini uzatmaktadır. Yani “HASH2 üretimi, CGA üretiminde işlem kapasitesinin en yoğun olduğu kısımdır” denebilir. A. AlSa’deh ve C. Meinel’ın [8],[9], [10]’ dan aktardığına göre SEC değeri ile CGA üretim sürelerinin karşılaştırmasını gösteren şekil aşağıdadır.

Şekil 12: Farklı Sec değerleri için CGA üretim Süreleri [2]

CGA üretim süresinin kısaltılması için Ahmad AlSa’deh ve Christoph Meinel şu önerilerde bulunmuşlardır [2];

  • CGA’yı daha hızlı üretebilmek için kriptografik hızlandırıcı kartlar kullanmak
  • Günümüz bilgisayarları ve uygulamaları için pratik olmadığından dolayı SEC değerinin 1’den büyük kullanılmaması
  • Sıfırdan büyük bir SEC değeri için belli bir süre sonra CGA üretiminin duracağının bir garantisi olmadığı için zaman bazlı CGA kullanılması önerilmektedir. Yani belli bir süre CGA üretilemezse üretiminin durması ve ardından farklı parametrelerle yeniden başlaması
  • CGA üretiminin paralelleştirilmiş CGA algoritması ile yapılması
  • Bilgisayar kaynaklarına uygun SEC değerlerinin seçilmesi
  • Güvenlik seviye arttırıcı katsayının 16’dan 8 ‘e düşürülmesi [11]

Bunların yanında S.Jiang ve S.Xia CGA yönetiminin DHCPv6 sunucu kullanılarak yapılmasını önerdi. Burada İstemci DHCPv6’ya kendisi için CGA üretmesi için bir istekte bulunur. DHCPv6’nın ürettiği CGA istemci tarafından kullanılır [12].

CGA, mobil cihazlarda da kullanılacaktır. Mobil cihazların kaynakları daha kısıtlı olduğundan üretim performansa daha fazla önem arz etmektedir. Kaldı ki mobil cihazların farklı ağlara bağlanma sıklığı normal cihazlara göre çok daha fazladır. Farklı ağlara bağlanan mobil cihazların önek değeri sürekli değiştiği için üretim aşaması yenilenmektedir. Bu da daha kısıtlı kaynaklara sahip mobil cihazlarda kaynak ve şarj tüketimine sebep olmaktadır. Bunun önüne geçmek için mobil cihazlarda işlem gücü gerektiren HASH2 hesaplanması kısmının yeni bir alt ağa girildiğinde hesaplanmaması, yeni alt ağlar ve önekler için sadece HASH1 ile arabirim tanıtıcısı üretilmesi düşünülmüştür. Buradaki tek endişe ise genel anahtara göre cihazın izlenip izlenemeyeceği ihtimalidir. Fakat genel anahtar ile bir mobil cihazın izlenebilmesi kolay değildir ve bu zaten çerezler ve IP adresleri vasıtasıyla yapılabilmektedir [2].

Bütün bunların yanında CGA süresinin üretim süresi işletim sisteminin genel/özel anahtar çiftini üretmek için seçeceği anahtar uzunluğuna göre de değişebilecektir. Örneğin RSA-1024 anahtar çifti ile üretilen CGA ile RSA-512 ile üretilen CGA’nın üretim süreleri aynı olmayacaktır. Bununla ilgili Pentium 4 ve 2593 Mhz CPU ya sahip bir cihaz üzerinde yapılan bir çalışma da farklı uzunlukta ki RSA üretim süresi gösterilmiştir.

Şekil 13: Farklı Anahtar uzunluklarına göre Anahtar üretim süresi [1]

Bütün bu performans geliştirmeleri göz önünde bulundurularak CGA üretim algoritması daha az kaynak tüketilmesi ve daha hızlı üretim için işletim sistemlerine en uygun şekilde düzenlenmelidir.

 

A.3.2) CGA İmzası

Bir cihaz bir mesajı imzalamak istediğinde RSA kullanarak üretmiş olduğu özel anahtar, CGA ve bu CGA ile ilişkili CGA data yapısı ve 128 bitlik “Tip Etiket” değerine ihtiyaç duymaktadır. 128 bitlik tip etiket değeri ve imzalanacak mesaj birleştirilir. Etiket değeri sola mesaj sağa yazılır. Oluşan bu yeni bileşke yapı ile özel anahtar girdi kabul edilerek RSASSA-PKCS1-v1_5 imzalama algoritması ve SHA-1 hash kullanılarak imza üretilir [6].
Mesaj imzalandıktan sonra; mesajın kendisi, imzası, CGA ve CGA data yapısı alıcı tarafa gönderilir. Alıcı tarafta imza doğrulanmadan evvel ilk önce CGA doğrulama algoritması gerçekleşir. İmzayı doğrulamak için mesajın imzası, kendisi, CGA ve CGA data yapısı, 128-bitlik tip etiket değeri birleştirilir. Bu yeni oluşan bileşke, mesajın imzası ile genel anahtar girdi kabul edilerek SHA-1 algoritması ile birlikte RSASSA-PKCS1-v1_5 imza algoritması çalışır ve imza doğrulanır [6].

 

A.3.3) CGA Doğrulanması

CGA, RFC 3972′ e göre mesajı alan bilgisayar tarafından aşağıdaki adımlar izlenerek doğrulanmaktadır [6]:

  1. CC değerinin 0,1 veya 2 olup olmadığı kontrol edilir.
  2. CGA’nın önekinin, CGA parametreleri ile gelen önek ile aynı olup olmadığı kontrol edilir.
  3. CGA parametrelerini kullanarak HASH1 hesaplanır. Çıkan hash değerinin soldaki 64 hanesi CGA adresinin arabirim tanıtıcısı kısmı ile karşılaştırır. Bu karşılaştırma sırasında SEC bitleri, U ve G bitleri ihmal edilir.
  4. Arabirim tanıtıcısının ilk 3 biti yani SEC değeri alınır. Sec değerine göre CGA yapısında bulunan niteleyici, 9 byte sıfır ve genel anahtar yan yana koyularak SHA1 algoritmasına sokulur ve HASH2 hesaplanır.HASH2’nin 16*SEC kadar bitinin sıfır olup olmadığı karşılaştırılır. Bütün bu işlemler hatasız olarak tamamlanırsa doğrulama başarıyla sonuçlanır. Doğrulama işleminin herhangi bir adımında hata alınırsa doğrulama işlemi durur ve başarısız olur. Aşağıda CGA doğrulama algoritmasını özetleyen şekil gösterilmiştir.
Şekil 14: CGA Doğrulama Algoritması

 

SEND üretim, imzalanma ve doğrulanma aşaması yukarıda belirtildiği gibi tasarlanmıştır. Bunların yanında her işletim sistemi ve SEND yapısını kendi ihtiyaç ve altyapılarına uyacak şekilde yeniden tasarlama yoluna gidebilirler. Örneğin Windows kendi işletim sistemine özgü WinSEND veya çeşitli Linux sürümleri DoComo SEND, Easy SEND gibi SEND tasarımları kullanmaya başlamışlardır.

 

A.4) SEND Güvenlik Problemleri

CGA’ların SEND yapısında kullanılmasının birçok saldırı metodunu engellediği söylenebilse de, CGA kendi içerisinde bir takım güvenlik problemleri barındırmaktadır. Bu güvenlik problemlerini şu şekilde özetleyebiliriz;

  • SEND mesajları özel anahtar ile imzaladığı için bir cihazın IP adresinin bir saldırgan tarafından çalınmasını engellemektedir. Yani bir saldırgan ortamda kullanılan bir IP adresini kendi üzerine alamaz. Çünkü o IP adresini kullanan istemcinin özel anahtarına sahip olması gerekmektedir. CGA bu türlü bir adres hırsızlığının önüne geçse de bir istemcinin kimliğini doğrulamakta yetersizdir. CGA’ da kullanılan anahtarların güvenilirliği doğrulanmadığı için bir saldırgan RSA genel/özel anahtar çifti üretip özel anahtarı ile imzalayıp iletişimi başlatabilir. Bunun önüne geçebilmek için anahtarların bir sertifika otoritesi tarafından doğrulanması gerekmektedir [3].
  • Bilindiği gibi CGA parametreleri alıcı tarafa açık olarak gitmektedir. Saldırgan araya girip bu açık giden parametreleri değiştirirse mesajı alan taraf bu parametreler ile CGA’yı doğruladığı için doğrulama işlemini gerçekleştiremez. Dolayısı ile saldırgan iki cihaz arasındaki iletişime bu parametreleri değiştirerek engel olabilir [2].
  • Bütün bunların yanında CGA kullanımında gizlilik konusunda da bir takım güvenlik problemleri doğabilir. Örneğin bir cihaz bir CGA ürettiği zaman uzun bir süre onu kullanmaya devam edecektir. Dolayısı ile cihaz ile kullandığı CGA arasında gizlilik tabanlı ataklar oluşturulabilir. Bunun üstesinden gelmek için ise üreticiler tasarımlarında CGA’ ya bir geçerlilik zamanı atamalıdır. Bu süre sonunda CGA’ nın yeniden üretilmesini sağlayacak şekilde CGA üretim algoritması genişletilmelidir [3]. Burada dikkat edilmesi gereken husus ise hukuksal gerekliliklerin yerine getirilmesi için her yeni CGA adresinin hangi cihaz ve kişi tarafından kullanıldığının kaydının tutulmasıdır. Burada her cihaz için kullanılan CGA sürekli yenileneceği için bir kayıt mekanizmasının çalışması gerekmektedir. Tavsiye olunan çözüm ise ortamda DHCP benzeri IP, MAC, kişi ve zaman eşleştirilmiş bilgilerini tutan bir veritabanı bulundurulması ve CGA üretim aşamasında, DAD sürecinden hemen sonra yeni CGA’nın bu veritabanına istemci tarafından otomatik yazdırılmasını sağlayacak bir genişlemeye gidilmesidir. Burada istemci yeni CGA’ sını kullanmaya başlamadan hemen evvel “Bu CGA adresini artık ben kullanıyorum” diye veritabanına mesaj yollamalı, veri tabanı bu mesaj içeriğini diğer bilgilerle eşleştirerek tutmalıdır. Bunun için yeni bir SEND mesajı veya seçeneği ve bunlara ait tip ve kod alanını içeren başlık yapılarının tanımlanması gerekmektedir.
  • Saldırgan bir CGA’ nın DAD sürecine DOS atak yapabilir. Kurban yeni bir CGA üretip DAD sürecini başlattığında ağa NS DAD mesajları yollar. Saldırgan bu mesajlar içerisinden kurbanın IP adresini, CGA parametrelerini ve imzasını alıp kopyalar ve DAD NA için beklenen süre içerisinde kurbana geri dönerse kurban kendisine gelen parametre ve imzaların doğru olduğunu görüp ürettiği CGA’nın kullanıldığını düşünür. Saldırgan aynı işlemi iki kere daha tekrarlarsa kurban artık CGA üretimini durdurur ve hata verir. Burada saldırgan sadece DOS atağı yapabilmekte bunun dışında herhangi bir zarar oluşturamamaktadır. Fakat yine de bu saldırının engellenebilmesi için DAD NS mesajı gönderen istemcinin kendisine gelen DAD NA mesajını CC değerini arttırmadan evvel doğrulayabilmesi gerekmektedir [3].
  • Saldırgan DAD sürecine CGA olmayan bir IP adresi ve NA mesajı ile “Sorgulanan adrese sahibim” mesajı yollayabilir. CC değeri 2’ye ulaştığında ise CGA üretim aşaması başarısızlığa uğrar. Dolayısı ile CGA algoritması CC değeri arttırmadan evvel gelen DAD NA mesajını doğrulayacak şekilde geliştirilmelidir. Bu durumda ağdaki bütün cihazların CGA’yı desteklemesi ve CGA olmayan IP adreslerinden gelen DAD NA mesajlarının düşürülmesi gerekmektedir [2].
  • CGA üretimi için SHA-1 algoritması kullanılsa da SHA-1’e yönelik çarpışma saldırıları mevcuttur. Fakat bu saldırının gerçekleşmesi en az sec değerinin sağladığı güvenlik seviyesi kadar değerin incelenmesini gerektirmektedir. Ayrıca SHA-1 nispeten eski bir güvenlik algoritması olduğundan dolayı yavaş yavaş sistemlerden desteği çekilmektedir. Örneğin Microsoft SHA-1 imzalı TLS sertifikalarına desteğini kaldırdı. Dolayısı ile CGA üretiminde ileriki yıllarda SHA-1 yerine başka bir şey kullanılması konusunda değişikliğe gidilebilir.

 

B) DAD Proxy

SEND, NDP yapısını daha güvenli hale getirse de kendi içerisinde birtakım güvenlik ve gizlilik açıklıkları içermektedir. Belirtilen bu tür güvenlik sorunların üstesinden gelebilmek için farklı bir çözüm yolu olan DAD Proxy geliştirilmiştir. Farklı üreticilerin ağ anahtarlarına entegre edilen bu çözüm ile ağ katmanında NDP’ye yönelik saldırılara karşı önlem alınabilmektedir.

Şekil 15: DAD Proxy [13]

Bu çözümün çalışması için istemcilerin bağlı olduğu ağ anahtarının Katman 3 paketlerini de açıp inceleyebilecek kapasitede olması gerekmektedir. Sistem aşağıda belirtildiği şekilde çalışmaktadır [14];

  • İstemcilerin bağlı olduğu ağ anahtarları kendi içerisinde istemcilerin port, IPv6 ve Mac bilgilerini tutmaktadırlar.
  • Bir istemci bir NS DAD isteğinde bulunduğu zaman bağlı olduğu anahtar gelen NS mesajı içerisinde Hedef adres seçeneğinde yer alan istemcinin sorgulamak istediği IPv6 adresi ile kendi tablosundaki adresleri karşılaştırır. Eğer sorgulanan adres kendi tablosunda varsa bir NA mesajı ile adresin kendinde olduğunu bildirir. Eğer kendisinde yoksa kendi tablosuna kaydeder, NS paketini düşürür ve cevap vermez.
  • Kısacası IPv6 DAD Proxy özelliği bir adres kullanımdayken ağ anahtarlarının o adres adına cevap vermesini sağlar. Anahtarlar istemciler için birer vekil konumundadırlar

DAD Proxy kaynak adres aldatmasını engellemek için SAVI (RFC: 6959 Source Address Validation Improvement) mekanizması gibi özelliklerle beraber kullanılırsa kaynak adres aldatmasına yönelik NDP saldırılarının önüne geçer [15]. Bunun yanında 802.1x ve port-security gibi önlemlerde ağ katmanında güvenliği arttırmaktadır. IPv6 DAD proxy özelliğini kullanabilmek için ağdaki tüm anahtarlar Katman 3 özelliklerini desteklemeli ve bu özellikleri destekleyecek modlarda çalıştırılmalıdır. Bu da fazladan kaynak tüketimine ve maliyet açısından daha yüksek rakamların ortaya çıkmasına sebebiyet verebilir.

DAD Proxy, şu an için SEND ile beraber çalışmamaktadır. Çünkü vekil görevi görecek olan Katman 2 anahtarlar CGA ile ilişkili özel anahtara sahip olmadığı için vekil ND mesajlarını imzalayamamaktadırlar [15].

Ayrıca DAD Proxy için bütün anahtarların Katman 3 paketlerini açabilmesi ve kendi içerisinde bir eşleşme tablosu tutması gerekmektedir. Pratikte eşleşme tablolarının ağdaki sadece tek bir Katman 3 destekleyen cihazda tutulacağı ve ağda diğer güvenlik önlemlerin alınmadığı varsayılıp düşünülürse vekil anahtar ve istemci arasına girilebileceği düşünülmelidir. Bu eksikliği giderilmesi vekil anahtar cihazının özel anahtar içermesi ve CGA’ yı destekleyip mesajları imzalaması gerekmektedir. Bunun için şu an RFC6496’da deneysel aşamada olan SEND için güvenli vekil desteği tanımlanmıştır. SEND için güvenli vekil desteği çalışmasında “proxy imza seçeneği” adında yeni bir seçenek tasarlanıp denenmektedir [16].

Şu ana kadar yazılan bütün önlemler özetlenirse, güvenli bir yapı oluşturulması için bir ağda aşağıdaki gereklilikler sağlanmalıdır.

  • ND Vekil Anahtarı kullanılmalı
  • CGA kullanılmalı
  • SEND altyapısında kullanılan bütün sertifikalar bir sertifika otoritesine doğrulatılmalı
  • Bunların yanında ağ katmanında EAP-TLS gibi 802.1x metotları kullanılarak ağdaki herhangi bir cihaz ve kullanıcının kimliği doğrulanmalıdır.

 

 

Kaynaklar:

https://www.siberportal.org/green-team/constructing-network-environment/ipv6-da-komsu-kesfi-protokolu-ndp-ve-atak-vektorleri/
[1] A.Boudguia, T.Cheneau ve M.Laurent., “Usage and performance of cryptographically generated addresses,” Eylül 2008, https://hal.archives-ouvertes.fr/hal-01373433, s.8-51
[2] A. AlSa’deh ve C. Meinel, “Secure Neighbor Discovery: Review, Challenges, Perspectives, and Recommendations”, IEEE Security & Privacy, 7 Şubat 2012, s.26-34
[3] A. AlSa’deh, H. Rafinee ve C. Meinel, “Secure Neigbor Discovery: A Crytocraphic Solition for Securing IPv6 Local Link Operations”, Theory and Practice of Cryptography Solutions for Secure Information Systems, ed. A.Elçi vd., IGI Global, 2013,s.183-190)
[4] J.Arkko vd.,”Secure Neighbor Discovery (SEND),” RFC 3971, Mart 2005, https://tools.ietf.org/html/rfc3971, s.15-40.
[5] Fall K.R. ve Stevens W.Richard, TCP IP Illustrated, Person Education, 2.b., ABD, 2012, s.45-418
[6] T.Aura,” Cryptographically Generated Addresses (CGA),” RFC 3972, Mart 2005, https://tools.ietf.org/html/rfc3972, s.7-15.
[7] AlSa’deh A, Meinel C; “Secure Neighbor Discovery”, 2012, Aktaran: Akın G., Uysal M.B. ve Sarı T., Secure Neighbor Discovery Protokolü, Akademik Bilişim Konferansı Bildirileri, Akdeniz Üniversitesi, Antalya,2013, s.3
[8] J.W. Bos, O. Özen, ve J.-P. Hubaux, “Analysis and Optimization of Cryptographically Generated Addresses,” LNCS 5735, Springer, 2009, pp. 17–32., Aktaran: AlSa’deh A., Secure Neighbor Discovery: Review, Challenges, Perspectives, and Recommendations, IEEE Security & Privacy, 7 Şubat 2012, s.31
[9] A. AlSa’deh, H. Rafee, ve C. Meinel, “Stopping Time Condition for Practical IPv6 Cryptographically Generated Addresses,” Proc. 26th IEEE Int’l Conf. Information Networking (ICOIN 12), IEEE, 2012, pp. 257–262, Aktaran: AlSa’deh A., Secure Neighbor Discovery: Review, Challenges, Perspectives, and Recommendations, IEEE Security & Privacy, 7 Şubat 2012, s.31
[10] S. Jiang, “Analysis of Possible DHCPv6 and CGA Interactions,” draf, 12 Mar. 2012; htp://tools.ietf.org/html/draf-ietf-csi-dhcpv6-cga-ps-09, Aktaran: AlSa’deh A., Secure Neighbor Discovery: Review, Challenges, Perspectives, and Recommendations, IEEE Security & Privacy, 7 Şubat 2012, s.31
[11] AlSa’deh ve C. Meinel, “Secure Neighbor Discovery: Review, Challenges, Perspectives, and Recommendations”, IEEE Security & Privacy, 7 Şubat 2012, s.26-34, Aktaran: A. AlSa’deh, H. Rafee, ve C. Meinel, Stopping Time Condition for Practical IPv6 Cryptographically Generated Addresses, 26.Int’l Conf. Information Networking (ICOIN 12), IEEE, 2012, s. 257–262.
[12] Jiang S. Ve Xia S., “Configuring Cryptographically Generated Addresses (CGA) Using DHCPv6″, IETF, , http://tools.ietf.org/html/draft-ietf-dhc-cga-config-dhcpv6-02, 11 Nisan 2012.
[13] Cisco,IPv6 First-Hop Security Configuration Guide, https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipv6_fhsec/configuration/xe-3e/ip6f-xe-3e-book/ip6f-xe-3e-book_chapter_0101.html, (Erişim tarihi:20 Haziran 2017).
[14] Costa F. vd.,”Duplicate Address Detection”, https://tools.ietf.org/html/rfc6957, RFC 6957, Haziran 2013, s.7-9.
[15] Costa F. vd.,”Duplicate Address Detection draft-costa-6mn-dad-proxy-01″, IETF internet-draft,https://tools.ietf.org/html/draft-costa-6man-dad-proxy-01#page-11, 20 Eylül 2010, s.10-11.
[16] Krishnan S. vd., “Secure Proxy ND Support for Secure Neighbor Discovery (SEND)”, RFC 6496, Şubat 2012, s.5.

 

 

 

 

 

Pentist: Sızma Testleri ve Bilgi Güvenliği Danışmanlık Hizmetleri

CEVAP VER

Yorumunuzu giriniz
İsminizi giriniz

This site uses Akismet to reduce spam. Learn how your comment data is processed.