Şifreli e-posta neden yaygınlaşmıyor?

encrypted-emailSayısal iletişimde e-posta önemli servislerden birisi. Şifreleme kullanılmadan yapılan e-posta trafiği, olası kritik verinin açık ve erişilebilir olarak İnternet ortamından geçmesi anlamına geliyor.

Günümüzde e-posta şifreleme yöntemleri karmaşık yapıya sahip ve tek taraflı e-posta şifreleme yöntemi bulunmuyor. Sayısal kimlik tabanlı şifreleme (IBE – Identity Based Encryption) günümüzde ideale en yakın çözümlerden. IBE’de şifreleme, e-postayı yazan ve okuyan taraflara en yakın seviyede başlatılır ve bitirilir. Yasal düzenlemeler ile nitelikli sayısal kimliklere, veri bütünlüğünü kanıtlama, kimlik doğrulama ve inkar edilemezlik özellikleri kazandırılmıştır.

E-posta şifreleme yöntemlerinin tamamı PKI (public key infrastructure) altyapısına dayanmaktadır. Tam bir PKI uygulaması, dijital sertifikaların dağıtılması ve yönetilmesini gerektirir. PKI masraflı ve bilgi birikimi gerektiren bir uygulamadır. PKI altyapısı kullanılarak yapılan e-posta şifrelemede açık anahtarların (public key) güvenli şekilde dağıtılması yapının problemlerindendir. Şifreli e-posta gönderilmek istendiğinde, karşı tarafın açık anahtarının güvenli şekilde önceden temin edilmiş olması gerekliliği, yapının en zayıf noktasıdır. Sayısal kimlik tabanlı e-posta şifreleme bu nedenlerden dolayı yaygınlaşamamaktadır.

Uygulanabilirliği yüksek ve son kullanıcı bilinci gerektirmeyen şifreleme alternatifi, e-posta sunucuları arasında TLS kullanılmasına dayanır. Fakat RFC 2487e göre, İnternet’e açık sunucular sadece TLS bağlantıları kabul edilecek şekilde ayarlanmamalıdır.

DNSSEC’in kullanım alanlarından birisi de güvenli açık anahtar dağıtımı olacak. DNSSEC ile ilgili yazım ilginizi çekebilir, http://ozcan.com/blog/dnssec-nedir/ .

Hamdi ÖZCAN – ozcan.com

6 Kasım 2014

Posted In: açık anahtar altyapısı, dnssec, e-mail, eposta, IBE, ID-based encryption, kripto, lkd, pki, RFC 2487, sayısal kimlik tabanlı şifreleme, şifreleme, teknik, TLS, tr

Şifreli e-posta neden yaygınlaşmıyor?

encrypted-emailSayısal iletişimde e-posta önemli servislerden birisi. Şifreleme kullanılmadan yapılan e-posta trafiği, olası kritik verinin açık ve erişilebilir olarak İnternet ortamından geçmesi anlamına geliyor.

Günümüzde e-posta şifreleme yöntemleri karmaşık yapıya sahip ve tek taraflı e-posta şifreleme yöntemi bulunmuyor. Sayısal kimlik tabanlı şifreleme (IBE – Identity Based Encryption) günümüzde ideale en yakın çözümlerden. IBE’de şifreleme, e-postayı yazan ve okuyan taraflara en yakın seviyede başlatılır ve bitirilir. Yasal düzenlemeler ile nitelikli sayısal kimliklere, veri bütünlüğünü kanıtlama, kimlik doğrulama ve inkar edilemezlik özellikleri kazandırılmıştır.

E-posta şifreleme yöntemlerinin tamamı PKI (public key infrastructure) altyapısına dayanmaktadır. Tam bir PKI uygulaması, dijital sertifikaların dağıtılması ve yönetilmesini gerektirir. PKI masraflı ve bilgi birikimi gerektiren bir uygulamadır. PKI altyapısı kullanılarak yapılan e-posta şifrelemede açık anahtarların (public key) güvenli şekilde dağıtılması yapının problemlerindendir. Şifreli e-posta gönderilmek istendiğinde, karşı tarafın açık anahtarının güvenli şekilde önceden temin edilmiş olması gerekliliği, yapının en zayıf noktasıdır. Sayısal kimlik tabanlı e-posta şifreleme bu nedenlerden dolayı yaygınlaşamamaktadır.

Uygulanabilirliği yüksek ve son kullanıcı bilinci gerektirmeyen şifreleme alternatifi, e-posta sunucuları arasında TLS kullanılmasına dayanır. Fakat RFC 2487e göre, İnternet’e açık sunucular sadece TLS bağlantıları kabul edilecek şekilde ayarlanmamalıdır.

DNSSEC’in kullanım alanlarından birisi de güvenli açık anahtar dağıtımı olacak. DNSSEC ile ilgili yazım ilginizi çekebilir, /blog/dnssec-nedir/ .

Hamdi ÖZCAN – ozcan.com

6 Kasım 2014

Posted In: açık anahtar altyapısı, dnssec, e-mail, eposta, IBE, ID-based encryption, kripto, lkd, pki, RFC 2487, sayısal kimlik tabanlı şifreleme, şifreleme, teknik, TLS, tr

DNSSEC Nedir?

DNSSECDNSSEC sayısal verinin dijital imza ile doğrulanmasına dayanan, bilişim güvenliğini tamamlayan teknolojilerdendir. DNS sisteminin güvenlik eksiklerini tamamlamak için geliştirilmiştir. DNSSEC doğrulamasının yapılabilmesi için kök alandan son alan adına kadar tüm basamakların DNSSEC uyumlu olması gerekmektedir. Kökün imzalanmış olması, güven zincirinin ön şartıdır (.tr henüz DNSSEC uyumlu değil). DNSSEC mekanizmasında trafik kriptolanmaz, ziyaret edilen alan adının işaret ettiği IP adreslerinin doğruluğu kanıtlanır.

DNSSEC son kullanıcının kullandığı alan adının doğru web sayfasına veya servislere karşılık gelen IP adresine ait olduğunu güvence altına alır. Bu Internet’in tüm güvenlik problemlerini çözmez fakat kritik bir bölümün güvenliğini kontrol altına alır. SSL (https) gibi diğer teknolojilerle birlikte kullanıldığında güvenliği iyileştirilmiş bir platform sağlar.

DNSSEC yapısı, KSK “Key Signing Key” (uzun süreli anahtar) ve ZSK “Zone Signing Key” (kısa süreli anahtar) olmak üzere iki anahtar çiftinden oluşur. Yeterli süre ve veri toplanarak kriptografik anahtarlar çözümlenebilir. DNSSEC‘de asimetrik veya açık anahtar kriptografisi kullanılmaktadır ve saldırganlar kaba kuvvet saldırısı ile anahtarları imzalayan anahtar çiftinin gizli yarısını ele geçirilebilir. DNSSEC bu tür saldırılara karşı sistemi güçlendirmek için rutin DNS kayıtlarını imzalarken ZSK anahtar çiftini, imzaları doğrularken KSK anahtar çiftini kullanır. ZSK düzenli olarak değiştirilerek saldırılara karşı sistem güçlendirilir. KSK anahtar çifti daha uzun aralıklarla yenilenir (güncel uygulamada yıldar bir). KSK ZSK‘yı, ZSK DNS kayıtlarını imzalar. KSK sadece alan adındaki DNS kayıtlarını doğrulamak için gereklidir. KSK‘nın bir örneği DS “Delegation Signer” kaydı biçiminde bir üst alan adına kaydedilir. Üst alan adı, alt alandan gelen DS kayıtlarını kendi ZSK‘sı ile imzalar.

DNSSEC açık anahtar altyapısı (Certificate Authority) ICANN bünyesinde barındırıyor. Fakat KSK‘ları imzalayan kök sertifikalar gönüllü katılımcılar tarafından yönetiliyor. Küresel kabul için kök anahtarların yönetiminin kimde olduğu önemli bir nokta. ICANN katılımcıların kimler olacağına müdahale etmiyormuş ve ticari kararların bu seçimi etkilememesi gerektiğine inanmaktaymış.

PKI altyapısını kullanan sistemlerde yaşanan güvenli anahtar değiş tokuşu problemine, DNSSEC çözüm sağlayabilecek yetenekte. Yakın gelecekte kriptolu e-posta gönderimi gibi konularda standart haline geleceğini düşünüyorum. Bu konuda “Şifreli e-posta neden yaygınlaşmıyor?” yazım ilginizi çekebilir.

ozcan.com NS suncularını, bu yazıyı yazdığım tarihte DNSSEC uyumlu hale getirdim. BURAYA tıklayarak, kontrol aracını deneyebilirsiniz (hatalı sonuç verebiliyor, sayfayı yenilemek gerekebilir birkaç kez).

Hamdi ÖZCAN – ozcan.com

14 Mayıs 2014

Posted In: dnssec, güvenlik, icann, ksk, lkd, pki, security, teknik, tr, zsk

DNSSEC Nedir?

DNSSECDNSSEC sayısal verinin dijital imza ile doğrulanmasına dayanan, bilişim güvenliğini tamamlayan teknolojilerdendir. DNS sisteminin güvenlik eksiklerini tamamlamak için geliştirilmiştir. DNSSEC doğrulamasının yapılabilmesi için kök alandan son alan adına kadar tüm basamakların DNSSEC uyumlu olması gerekmektedir. Kökün imzalanmış olması, güven zincirinin ön şartıdır (.tr henüz DNSSEC uyumlu değil). DNSSEC mekanizmasında trafik kriptolanmaz, ziyaret edilen alan adının işaret ettiği IP adreslerinin doğruluğu kanıtlanır.

DNSSEC son kullanıcının kullandığı alan adının doğru web sayfasına veya servislere karşılık gelen IP adresine ait olduğunu güvence altına alır. Bu Internet’in tüm güvenlik problemlerini çözmez fakat kritik bir bölümün güvenliğini kontrol altına alır. SSL (https) gibi diğer teknolojilerle birlikte kullanıldığında güvenliği iyileştirilmiş bir platform sağlar.

DNSSEC yapısı, KSK “Key Signing Key” (uzun süreli anahtar) ve ZSK “Zone Signing Key” (kısa süreli anahtar) olmak üzere iki anahtar çiftinden oluşur. Yeterli miktarda veri toplanarak kriptografik anahtarlar çözümlenebilir, bu yüzden DNS kayıtları otomatik olarak belirli aralıklarla yeniden imzalanır. DNSSEC‘de asimetrik veya açık anahtar kriptografisi kullanılmaktadır ve saldırganlar kaba kuvvet saldırısı ile anahtarları imzalayan anahtar çiftinin gizli yarısını ele geçirilebilir. DNSSEC bu tür saldırılara karşı sistemi güçlendirmek için rutin DNS kayıtlarını imzalarken ZSK anahtar çiftini, imzaları doğrularken KSK anahtar çiftini kullanır. ZSK düzenli olarak değiştirilerek saldırılara karşı sistem güçlendirilir. KSK anahtar çifti daha uzun aralıklarla yenilenir (güncel uygulamada yıldar bir). KSK ZSK‘yı, ZSK DNS kayıtlarını imzalar. KSK sadece alan adındaki DNS kayıtlarını doğrulamak için gereklidir. KSK‘nın bir örneği DS “Delegation Signer” kaydı biçiminde bir üst alan adına kaydedilir. Üst alan adı, alt alandan gelen DS kayıtlarını kendi ZSK‘sı ile imzalar.

DNSSEC açık anahtar altyapısı (Certificate Authority) ICANN bünyesinde barındırıyor. Fakat KSK‘ları imzalayan kök sertifikalar gönüllü katılımcılar tarafından yönetiliyor. Küresel kabul için kök anahtarların yönetiminin kimde olduğu önemli bir nokta. ICANN katılımcıların kimler olacağına müdahale etmiyormuş ve ticari kararların bu seçimi etkilememesi gerektiğine inanmaktaymış.

PKI altyapısını kullanan sistemlerde yaşanan güvenli anahtar değiş tokuşu problemine, DNSSEC çözüm sağlayabilecek yetenekte. Yakın gelecekte kriptolu e-posta gönderimi gibi konularda standart haline geleceğini düşünüyorum. Bu konuda “Şifreli e-posta neden yaygınlaşmıyor?” yazım ilginizi çekebilir.

ozcan.com NS suncularını, bu yazıyı yazdığım tarihte DNSSEC uyumlu hale getirdim. BURAYA tıklayarak, kontrol aracını deneyebilirsiniz (hatalı sonuç verebiliyor, sayfayı yenilemek gerekebilir birkaç kez).

Hamdi ÖZCAN – ozcan.com

14 Mayıs 2014

Posted In: dnssec, güvenlik, icann, ksk, lkd, pki, security, teknik, tr, zsk

BIND, IPv6 ve DNSSEC

Bir onceki yazida DNSSEC’e giris yapmis ve PowerDNS’i arkada MySQL kullanacak sekilde yapilandirdiktan sonra sundugumuz DNS alanina DNSSEC destegi kazandirmistik. Bu yazida ayni islemin BIND ile nasil yapilabilecegine bakacagiz. Diger yazidan farkli olarak bu yazida temel kayitlarin aciklamalari yerine kayitlarin imzalanmasi, alan transferi (axfr) gibi diger alanlara da deginecegiz. Bu seferki ornegimiz .net TLD’sine sahip olacagindan farkli bir guvenlik zincirine kayit eklememiz gerekmeyecek. (DLV)

Problem su ki kendi DNS alanimizi kendimiz sunsak dahi DS kaydini alan adimizi kaydettigimiz yere vermemiz gerekiyor ki bizi icinde barindiran alana bu kayit iletilebilsin. Boyle olunca da yine destek veren ve destek vermeyen alan adi kaydedicilerden bahsetmek gerekiyor. Ben normalde Hover[1] kullaniyorum fakat ne yazik ki Hover henuz DS kaydi eklenmesine izin vermiyor. Bu isleme olanak taniyan alan adi kaydedicilerin ICANN tarafindan tutulan bir listesine suradan[2] ulasilabilir. Gozuken o ki kala kala yine SOPA destekcisi GoDaddy’ye kaliyoruz.

dnssecenabled.net adresi icin, Ubuntu 12.04 ve CentOS 6.4 uzerinde BIND ile IPv6 ve DNSSEC destegi veren 2 ana isim sunucu (authoritative nameserver) kuracagiz. Bu DNS sunuculardan biri ana (master Ubuntu) digeri ise ikincil(slave CentOS epel ve remi tanimli) olarak gorev yapacak ve ikincil isim sunucu ana isim sunucudan kayitlari alacak. DigitalOcean’da olusturdugum bu sunucular IPv6’e sahip degiller o yuzden HE’nin (Hurricane Electric) tunnelbroker.net hizmetini kullanip IPv6 adreslerini IPv4 uzerinden tunelleyerek ise baslayacagiz.

Tunnelbroker’da hesap actiktan sonra “Create regular tunnel” diyoruz ve IPv4 adresimizi ve kullanmak istedigimiz tunel sunucuyu secip “Create tunnel” tusuna bastigimizda tunnelbroker bizim icin gereke ayarlari
ekrana basiyor. Gelen pencerede “Example Configuration” altinda kullandiginiz isletim sistemini secerseniz hangi dosyada ne degisiklikleri yapmaniz gerektigini size gosterecektir. Ornegin Ubuntu sunucu icin /etc/network/interfaces dosyasina asagidaki satirlari eklememi soyluyor.

auto he-ipv6  
iface he-ipv6 inet6 v4tunnel  
        address 2001:470:1f04:9cb::2
        netmask 64
        endpoint 72.52.104.74
        local 198.199.111.195
        ttl 255
        gateway 2001:470:1f04:9cb::1

CentOS seceneklerde bulunmadigindan onu su sekilde elle ekliyorum. Tabii bu ve yukaridaki degerleri kendinize gore degistirmeyi unutmayin.

ip tunnel add he-ipv6 mode sit remote 216.66.84.46 local 198.211.120.12 ttl 255  
ip link set he-ipv6 up  
ip addr add 2001:470:1f14:efa::2/64 dev he-ipv6  
ip route add ::/0 dev he-ipv6  
ip -f inet6 addr  

Ardindan /etc/sysconfig/network dosyasini acip su uc satiri ekliyoruz.

NETWORKING_IPV6=yes  
IPV6_DEFAULTDEV=he-ipv6  
IPV6_DEFAULTGW=2001:470:1f14:efa::1  

Son adimda ise /etc/sysconfig/network-scripts/ifcfg-he diye bir dosya olusturup icine su degerleri yazdiktan sonra network servisini yeniden baslatiyoruz.

DEVICE=he-ipv6  
TYPE=sit  
BOOTPROTO=none  
ONBOOT=yes  
IPV6INIT=yes  
IPV6TUNNELIPV4=216.66.84.46  
IPV6ADDR=2001:470:1f14:efa::2  

Lutfen degerleri kendinize gore degistirmeyi unutmayin. Bu asamayi da tamamlayinca ping6 ve traceroute6 ile IPv6 yapilandirmasinin calisip calismadigini kontrol edebilirsiniz. Geldigimiz kademede elimizdeki bilgiler su sekilde;

ns1.dnssecenabled.net Ubuntu BIND 9.8.1 Master 198.199.111.195 2001:470:1f04:9cb::2

ns2.dnssecenabled.net CentOS BIND 9.8.2 Slave 198.211.120.12 2001:470:1f14:efa::2  

Simdi alan adimizi kaydettigimiz GoDaddy’ye gidip Glue Record’lari (bunun Turkce’ye nasil cevirilmesi gerektigini bilen varsa lutfen benimle iletisime gecsin) ekleyecegiz. Bir DNS terimi olan glue record’un yaptigi is basitce soyle. dnssecenabled.net’in kayitlarini ns1.dnssecenabled.net ve ns2.dnssecenabled.net uzerinden sunmak istiyoruz. www.dnssecenabled.net’e ulasmak istedigimizde once ns1.dnssecenabled.net’e adresine www.dnssecenabled.net’i nerede bulacagimizi sormamiz gerekiyor ama ns1.dnssecenabled.net zaten dnssecenabled.net alaninda. Iste bunun gibi dongusel bir bagimlilik durumunda alan adini kaydettirdigimiz yere bak bunlar isim sunucularin IP adresleri ona gore diyerek verdigimiz kayitlara glue records deniyor.

GoDaddy’de bu kayitlari ekledigimiz alan “domain control panel”‘de sol alttaki “Host Summary” bolumunde bulunuyor. “Add” tusu ile ns1 ve ona ait IPv4 ve IPv6 adreslerini ekledikten sonra sayfayi yenileyip ayni islemi ns2 icin de yapiyoruz. Boylelikle glue records da eklenmis oluyor. Ardindan yine “domain control panel”‘de “Nameserver” bolumundeki “Set Nameservers” tusuna tiklayip dnssecenabled.net alan adimiz icin glue record’lari az once eklemis oldugumuz ve isim sunuculari barindiracagimiz ns1.dnssecenabled.net ve ns2.dnssecenabled.net adreslerini giriyoruz. Artik geriye iki sunucudaki BIND’i yapilandirmak ve DNSSEC isleri bittiginde GoDaddy’ye donup DS kaydini eklemek kaliyor. Isim sunucularin internette yayilmasi zaman alacagindan su asamada az once ekledigimiz kayitlari goremezsek cok endiselenmemekte fayda var. Fakat kontrol icin bir root isim sunucuyu sorgulayabiliriz.

dig @a.gtld-servers.net dnssecenabled.net NS

Eger asagidakine benzer bir cevap aliyorsak, yapilandirmamizda bir sorun yok demektir.

; > DiG 9.9.2-P1 > @a.gtld-servers.net dnssecenabled.net NS
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 5
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:  
 ; EDNS: version: 0, flags:; udp: 4096  
 ;; QUESTION SECTION:  
 ;dnssecenabled.net. IN NS

;; AUTHORITY SECTION:  
 dnssecenabled.net. 172800 IN NS ns1.dnssecenabled.net.  
 dnssecenabled.net. 172800 IN NS ns2.dnssecenabled.net.

;; ADDITIONAL SECTION:  
 ns1.dnssecenabled.net. 172800 IN A 198.199.111.195  
 ns1.dnssecenabled.net. 172800 IN AAAA 2001:470:1f04:9cb::2  
 ns2.dnssecenabled.net. 172800 IN A 198.211.120.12  
 ns2.dnssecenabled.net. 172800 IN AAAA 2001:470:1f14:efa::2

;; Query time: 234 msec  
 ;; SERVER: 192.5.6.30#53(192.5.6.30)  
 ;; WHEN: Thu May 23 16:28:09 2013  
 ;; MSG SIZE rcvd: 170

Gelelim BIND kurulumu ve yapilandirmasina. Yazinin basinda da bahsettigim uzere Ubuntu sunucu master, CentOS sunucu ise slave olarak gorev yapacak. Bu ornekte su kayitlari tanimlayacagim.

www.dnssecenabled.net A 198.199.111.195  
www2.dnssecenabled.net A 198.199.111.195  
www3.dnssecenabled.net A 198.199.111.195  
www4.dnssecenabled.net A 198.211.120.12  
www5.dnssecenabled.net A 198.211.120.12  
mail.dnssecenabled.net A 198.199.111.195

www.dnssecenabled.net AAAA 2001:470:1f04:9cb::2  
www2.dnssecenabled.net AAAA 2001:470:1f04:9cb::2  
www3.dnssecenabled.net AAAA 2001:470:1f04:9cb::2  
www4.dnssecenabled.net AAAA 2001:470:1f14:efa::2  
www5.dnssecenabled.net AAAA 2001:470:1f14:efa::2  
mail.dnssecenabled.net AAAA 2001:470:1f04:9cb::2

dnssecenabled.net MX mail.dnssecenabled.net  
alt1.dnssecenabled.net CNAME www.dnssecenabled.net  
alt2.dnssecenabled.net CNAME www4.dnssecenabled.net  

Ubuntu icin ise basliyoruz.

sudo apt-get install bind9

Kurulum bittikten sonra /etc/bind/named.conf.options dosyamizda IP ve port ayarlarini yapiyoruz. Daha sonra /etc/bind/named.conf.local dosyasini acip su satirlari giriyoruz ki dnssecenabled.net alanini sunucagimiz isim sunucuya soylemis olalim.

zone "dnssecenabled.net"  
    type master;
    file "/etc/bind/db.dnssecenabled.net"
    allow-transfer { 2001:470:1f14:efa::2;
                     198.211.120.12;};
};

Sira geldi db.dnssecenabled.net dosyasini olusturmaya. Benim dosyamin icerigi yukaridaki kayitlar goz onunde bulunduruldugunda su sekilde gozukuyor.

;
; BIND data file for dnssecenabled.net
;
$TTL    300
@    IN  SOA dnssecenabled.net. root.dnssecenabled.net.(
                  3     ; Serial
                300     ; Refresh
                300     ; Retry
                300     ; Expire
                300)    ; Negative Cache TTL

dnssecenabled.net. IN NS ns1.dnssecenabled.net.  
dnssecenabled.net. IN NS ns2.dnssecenabled.net.  
dnssecenabled.net. IN MX 10 mail.dnssecenabled.net.

ns1 IN A 198.199.111.195  
ns2 IN A 198.211.120.12  
ns1 IN AAAA 2001:470:1f04:9cb::2  
ns2 IN AAAA 2001:470:1f14:efa::2

mail IN A 198.199.111.195  
mail IN AAAA 2001:470:1f04:9cb::2

www IN A 198.199.111.195  
www2 IN A 198.199.111.195  
www3 IN A 198.199.111.195  
www4 IN A 198.211.120.12  
www5 IN A 198.211.120.12  
www IN AAAA 2001:470:1f04:9cb::2  
www2 IN AAAA 2001:470:1f04:9cb::2  
www3 IN AAAA 2001:470:1f04:9cb::2  
www4 IN AAAA 2001:470:1f14:efa::2  
www5 IN AAAA 2001:470:1f14:efa::2

alt1 IN CNAME www.dnssecenabled.net.  
alt2 IN CNAME www4.dnssecenabled.net.  

BIND servisini yeniden baslattigimizda master sunucumuz hazir olacak.

service bind9 restart

Isim sunucumuz aslinda dnssecenabled.net'i barindiran sunucu da oldugundan ters DNS kayitlarini yapmayacagim. Bunun icin baska kaynaklara bakilabilir. Zaten cok zor da degil ayarlamasi. Sira geldi CentOS sunucuya BIND kurulup bu ayarladigimiz sunucunun ikincil sunucusu olarak hizmet vermesini saglamaya.

sudo yum install bind bind-utils

Komutuyla gerekli paketleri kuruyorum. bind-utils aslinda gerekli degil fakat test ve hata giderme amacli kurulmasi iyi olacaktir.

CentOS'ta BIND'in kullandigi dizin yapisi biraz daha degisik. Ilk olarak yapmamiz gereken /etc/named.conf dosyasina gecip IP ve port ayarlarini duzenledikten sonra recursion'i kapatmak. named servisini yeniden baslatmadan once su komutu calistiriyoruz. Aslinda servisi ilk yeniden baslattigimizda kendisi bu anahtari olusturmasi gerekiyor fakat islemleri SSH uzerinden yaptigimizdan yeterli entropi olmayinca anahtar uretmesi uzun zaman aliyor, belki de hic uretemiyor hic o kadar uzun beklemedim :). O yuzden elle olusturuyoruz anahtarimizi.

rndc-confgen -a -r /dev/urandom  
service named restart  

Yerelimizden dig @ns2.dnssecenabled.net google.com A ile recursion yapip yapmadigini kontrol edebiliriz CentOS'a az once kurdugumuz isim sunucumuzun. WARNING: recursion requested but not available diyorsa sorun yok demektir. Simdi master sunucunun slave'i olarak ayarlayacagiz. Bunun icin /etc/named.conf dosyasina su satirlari eklememiz yeterli olacaktir.

zone "dnssecenabled.net" IN {  
    type slave;
    file "slaves/db.dnssecenabled.net";
    masters { 2001:470:1f04:9cb::2;
            198.199.111.195; };
};

Yazinin sonuna firsat bulunca bu yazi icin olusturdugum ve duzenledigim tum ayar dosyalarini barindiran tar.bz2 arsivini koyacagim. Ayarlari oradan da kontrol edebilirsiniz.

Evet boylelikle temel DNS kurulumunu bitirmis olduk. Sira geldi DNSSEC islemlerine. Fakat ondan once iki ana sunucu arasindaki veri transferini nasil daha guvenli hale getirebiliriz ona bakalim. TSIG (transaction signatures) iste tam olarak bu ise yariyor. Alan transferi sirasinda iki sunucunun birbirleriyle konustuklarina emin olabilmelerine simetrik sifreleme yontemiyle imkan taniyor. Simetrik sifreleme kullanildigindan her ikincil(slave) sunucu icin yeni bir anahtar olusturulmasi tavsiye ediliyor. Bu sayede bir ikincil sunucunun ele gecirilmesi daha buyuk bir guvenlik tehdidi olusturmamis oluyor. TSIG aslinda DNSSEC'in bir parcasi degil fakat bunca zahmete girdigimize gore hazir elimiz degmisken TSIG islemini de yapmakta bir sakinca yok. Burada onemli bir hususu gozden kacirmamak gerekiyor. TSIG iki sunucu arasindaki veri transferinde veriyi sifrelemiyor, sadece sunucularin gercekten konusmak istedikleri sunucularla konustuklarini anlamalarina olanak taniyor. Eger transfer sirasinda veriyi sifreleme gereksinimi de duyuyorsaniz VPN ya da duruma gore SSH vs. cozumlerine bakmaniz gerekecek. Fakat onlar bu yazinin konusu degil zira blog degil de ansiklopedi yazmak gerekecek o kadar derine inmeye niyetlenirsek :).

TSIG anahtarini uretmek icin dnssec-keygen aracini kullanacagiz. Yine RFC'lere dalarak hangi algoritmalarin desteklendigini bulup cikarabiliriz fakat ben sizin icin isin buyuk kismini yapip, kabul edilebilir duzeyde degerleri olan komutlari buraya yazacagim. HMAC-SHA512 algoritmasi ile 512 bitlik anahtar uzunlugu seciyorum.

dnssec-keygen -r /dev/urandom -a HMAC-SHA512 -b 512 -n HOST ns1-to-ns2.

Sonda nokta var teamulen. Bu komutta degismesi gereken tek kisim sondaki ns1-to-ns2. kismi ki bu da anahtari tanimama yarayan anahtar adini ifade ediyor. Yani anahtari ns1 ile ns2 arasinda kullanacagim. Burada istediginiz isimi secmekte ozgursunuz. Anahtar uretimi -r /dev/urandom kullanmasaydik yine SSH uzerinde oldugumuzdan ve sistem yeterli entropi toplayamadigindan cok uzun zaman alabilirdi fakat etrafindan dolasmis olduk. Bu komutu verdigimiz dizinde .key ve .private ile biten iki dosya olusacak. Ikisinde de ayni anahtari gorecegiz. Simdi bu uretilen anahtari hem ana hem de ikincil sunucuda BIND'i yapilandirdigimiz dosyalara ekleyecegiz. Ekleyecegimiz satirlar suna benziyor. Tekrar dosya yollarini da yazmakta yarar var. Ubuntu icin /etc/bind/named.conf.options CentOS icin /etc/named.conf

key "ns1-to-ns2." {  
    algorithm hmac-sha512;
    secret "Uh8uk5kUR/whQYNGoq50Z80hA1ab706fdPccJq...";
};

server 198.211.120.12 {  
    keys { "ns1-to-ns2." ;} ;
};

Bunu iki sunucuda da IP adreslerini duzelterek yapiyorsunuz. Ardindan asil sunucu olan Ubuntu'da named.conf.local dosyasinda bulunan zone'umuzdaki allow-trasnfer alanina bu paylasilan anahtari girip iki sunucudaki servisleri de yeniden baslatiyoruz. Artik TSIG'in calisip calismadigini kontrol edebiliriz. Bu testi yapmanin en kolay yolu master sunucudaki alan dosyasinda bir degisiklik yapip DNS servisini yeniden baslatmak. Bir CNAME kaydi ekleyip bu islemi gerceklestiriyorum ve ikincil sunucudaki /var/log/messages dosyasina tail ile goz atiyorum.

client 198.199.111.195#39669: received notify for zone 'dnssecenabled.net': TSIG 'ns1-to-ns2'

benzeri bir cikti goruyorsak TSIG istedigimiz gibi yapilandirilmistir demektir. Tabii server tanimlarini IPv6 adreslerimiz icin eklemeyi de unutmayalim ki hem IPv4 hem de IPv6 transferleri TSIG kullansin.

Yazinin baslangicindan yaklasik 1500-2000 kelime sonra nihayet DNSSEC'e gelebildik. Onceki yazida da bahsettigim uzere ZSK ve KSK adi verilen anahtarlara ihtiyacimiz olacak. Bunlari bir suru algoritma kullanarak olusturabiliriz. RSA/SHA-256 (root alaninin da kullandigi algoritma) ile yolumuza devam edecegiz. 2048 bit uzunluk da su an icin gayet yeterli gozukuyor fakat 4096 secmekte de sakinca yok. TSIG'de oldugu gibi bu is icin de dnssec-keygen kullanacagiz.

dnssec-keygen -r /dev/urandom -f KSK -a 8 -b 4096 dnssecenabled.net

-r'i daha once kullanmistik. -f KSK bu anahtar ciftinin key signing key olarak gorev yapacagini soyluyor. -a 8 ise RSA/SHA-256 algoritmasi. -b bit uzunlugu ve son olarak alanimizin adi. .key ve .private uzantili iki dosya olusmus olmasi gerekiyor. ZSK de benzer komutla uretiliyor fakat bu sefer -f KSK'i komuttan cikartiyoruz.

dnssec-keygen -r /dev/urandom -a 8 -b 2048 dnssecenabled.net

Boylelikle 4 adet dosya olusturmus olduk. Izinlerini 640 olarak duzenlemek isteyebilirsiniz. Burada aslinda biraz da guvenlige deginsek iyi olacak. Normalde BIND'i chroot ederek calistirip, bu sunuculari bir firewall'in ya da hic olmadi duzgun iptables kurallarinin arkasina koymak gercekten onemli. Bu kisimi da umarim bir ileride bir iptables yazisiyla anlatmaya calisirim.

KSK ve ZSK'imizi olusturduktan sonra alan adimizi kaydettirdigimiz (bu ornekte GoDaddy) yere DS kaydimizi vermemiz gerekiyor. Urettigimiz KSK'den DS kaydimizi dnssec-dsfromkey komutu ile uretiyoruz.

dnssec-dsfromkey Kdnssecenabled.net.+008+01207

bu komutta Kdnssec... ile baslayan kisimi kendi KSK'iniz tuttugunuz dosya ile degistirmeniz gerekiyor. Dosya sonundaki .key veya .private uzantisini kullanmiyorsunuz. Komut suna benzer bir cikti verecektir.

dnssecenabled.net. IN DS 1207 8 1 597A5CB9F0...  
dnssecenabled.net. IN DS 1207 8 2 9030FF4BF3...  

Iste bu kayitlar alan adimizi kaydettirdigimiz yere verecegimiz DS kayitlaridir. Bir kenara not edelim. Kayitlari imzalamaya geciyoruz.

dnssec-signzone -a -o dnssecenabled.net -N increment -r /dev/urandom db.dnssecenabled.net Kdnssecenabled.net.+008+01207.private Kdnssecenabled.net.+008+19800.private

Aslinda BIND'in 9.9.x surumleri bu islemleri bizim icin yapabiliyor fakat depolarda 9.8.1 oldugunda elle imzalamak durumunda kaldik. Simdi NSEC'ten NSEC3'e cevirmek icin ne yapacagimiza bakalim. Ayni komuta -H 10 -3 d00dbaaf verdigimizde bizim icin NSEC'ten NSEC3'e cevirecek. -3'ten sonraki kisim hexadecimal olarak yazabileceginiz herhangi bir sey olabilir. Ben deadbeef'ten esinlenip bunu sectim. Simdi eski alani yedekleyip imzalanmasi(db.dnssecenabled.net.signed) uzerine yazalim ve servisi yeniden baslatalim. Su anda slave'e imzalanmis alanin gitmis olmasi gerekiyor. DS kayitlarini eklemenin vakti geldi. GoDaddy'nin kontrol paneline gidiyoruz ve "Add DS Records" altindan gerekli kayitlari ekliyoruz. Bu kayitlar DNS sisteminde yayildiginda dig'e +dnssec parametresi vererek alanimizi sorgulayanlar ad(authenticated data) bayragini donen cevap icerisinde gormeye baslayacaklardir. Iste DNSSEC bu kadar basit.

Alanimiza yeni bir kayit ekledigimizde imzalama ve servisi yeniden baslatma isini su an icin yeniden yapmamiz gerekiyor. Dolayisiyla .signed'i normal dosyanin uzerine yazmadan once yedegini almis olmakta fayda var. Yoksa her seferinde butun kayitlari yazmak iskence olacaktir. BIND 9.9.x surumleri itibariyle bu islemler otomatik yapilabiliyor olmasina ragmen ne Ubuntu 12.04 ne de CentOS 6.4 depolarinda o surum bulunmadigindan islemleri elle yaptik. Fakat BIND surumu yukseldikce isimiz biraz daha kolaylasacak.

Asagida yeni olusturdugumuz alan adinin DNSSEC testine ait goruntuyu paylasiyorum.

dnssecenabled.net-2013-05-23-15-11-05

Gordugunuz gibi bir onceki yazida baktigimiz test.name.tr gibi siyah kalin oklar bulunmuyor ve butun DNS kayitlari DNSSEC ile imzalanmis durumda.

DNSSEC ile ilgili bu ikinci yazida yine anahtar degisimi (key rollover), SSHFP kayitlari ve DANE(TLSA) konusunda yazmaya firsat olmadi fakat onlari da bir sonraki yazida ele alip DNSSEC defterini bir sureligine kapatmayi planliyorum. Ardindan "iptables: anneye anlatir gibi" projesine baslayacagim :).

Sunuculari iki hafta kadar kurcalamak isteyen olursa diye acik birakacagim. Eger olur da girip bir bakmak isterseniz haber etmeniz yeterli.

[1] www.hover.com

[2] http://www.icann.org/en/news/in-focus/dnssec/deployment

24 Mayıs 2013

Posted In: Authoritative, BIND, CentOS, dns, DNS Sunucu, dnssec, Gezegen, IPv6, Master, Slave, Sunucu, Tunnelbroker, ubuntu

DNSSEC

Ana basliga “nasil” sozcugunu koyacaktim fakat yazi, ortalama bir nasil yazisindan biraz daha derine indi. Dolayisiyla okuyacaklarin bunu goz onunde bulundurmasinda fayda var.

Neden DNSSEC?
DNSSEC nasil yazisi okumaya gelmis insanlara “DNS nedir, nicin onemlidir?” anlatmaya gerek olmadigindan DNSSEC standardinin gelistirilmesine onayak olan ihtiyac ya da ihtiyaclar nelerdi bunlara kisaca deginmeye calisacagim.

Onbellek yaniltma saldirilari (DNS Cache Poisoning Attack) diye adlandirilan atak turu, onbellekleme yapan bir isim sunucuya (caching nameserver) asil iletisilmek istenen sunucu yerine o sunucuyu taklit eden baska bir sunucunun gosterilmesi olarak tanimlaniyor. Bunun sonucunda o isim sunucuyu kullanan diger istemcilerden gelen trafik ya gitmesi gereken yere hic ulasmadan baska bir yere gidiyor ya da gecmemesi gereken bir sunucu uzerinden gecirilip nihai hedefine yonlendiriliyor. Bu sayede e-posta iceriklerinin, VoIP vb. iletisimin takibi, hatta kullanicilarin hesaplarinin calinmasi mumkun olabiliyor. Onbellek yaniltma saldirilari disinda, tam olarak olmasa da benzer mantikla calisan aradaki adam (MITM) ve dogrudan o alan adini barindiran ana isim sunucudaki (authoritative nameserver) verinin degistirilmesi mantigiyla calisan saldirilar da mevcut.

Burada saydigim ve saydiklarima benzer saldirilarin onlenebilmesi icin, istemcideki DNS cozucunun bir sekilde aldigi DNS verisinin dogrulugunu ve butunlugunu kontrol etmesi gerekiyor. Iste DNSSEC bu asamada devreye
giriyor. Asimetrik sifreleme yapilarak genel anahtarlarla bir guven zinciri olusturuluyor.

Cogumuz genel anahtarli sifrelemenin e-posta uygulamalarina asinadir. Daha once kullanmamis olanlar da pek cok viki ya da dergide konuyla ilgili yazilar bulabilirler. DNSSEC icin genel anahtarli sifreleme uygulamalarindan verinin imzalanmasi konusuna deginecegiz. Aynen e-posta’da oldugu gibi DNSSEC’te de anahtarinizla DNS verinizi imzaliyorsunuz. DNSSEC dogrulamasi yapan istemciler sizi icinde barindiran zone’dan (alandan) anahtarinizi okuyor ve DNS verisinin degistirilmedigine boylelikle emin oluyorlar. Tabii DNS oldukca dagitik bir yapi oldugundan su an icin mevcut her ccTLD ve TLD’nin bu sistemi uygulamaya baslamadigini goruyoruz. Bu da guven zincirinin belirli noktalarda kirilmasina neden oluyor. “Bu gibi durumlarla bas edilebilir mi? Bas edilebilerse nasil edilebilir?” gibi sorularin yanitlarini yazinin ilerleyen kisimlarinda vermeyi deneyecegim.

DNSSEC Kayit Turleri
DNS’i yeniden icat etmektense DNSSEC varolan DNS uzerine eklenti olarak dusunulmustur. Dolayisiyla beraberinde birkac yeni kayit turu getirir.

-DNSKEY Kaydi
Bir DNS alanindaki kayitlar DNSSEC icin alana ait anahtar ile imzalanirlar. Fakat bu beraberinde su guvenlik riskini dogurur; Olasi bir saldirgan kayitlarin duz metin ve hashlenmis hallerine sahip olacagindan, eger cok sayida DNS kaydini barindiran bir alansa saldirilan, sifresinin kirilabilme ihtimali ortaya cikacaktir. Bu problemin onune gecmek icin iki tur anahtar tanimlanmistir.

a) Key Signing Keys (KSK-Anahtar imzalama anahtarlari)
b) Zone Signing Keys (ZSK-Alan imzalama anahtarlari)

Zone signing key, DNS alanini imzalamak icin kullanilir. Key signing key ise kendisi de dahil butun DNSSEC verisini imzalar. Bu sayede saldirganin elinde tek bir hash olacagindan sifrenin kirilmasi neredeyse olanaksizlasmistir. Sistemi biraz daha guvenilir yapmak icin bu anahtarlarin omurleri kisitlanabilir. Omru dolan anahtarlar, yeni anahtarlarla degistirilir. Bu isleme verilen isim de key rollover oluyor. DNSKEY kaydina geri donelim. Bu kayitlarin KSK ya da ZSK’leri tutan kayitlar oldugunu soylemistik. Ornegin paypal.com (su anda aklima gelen ve DNSSEC kullandigini bildigim ilk alan adi bu oldugundan bu ornegi sectim) icin kayitlarin nasil gozuktuklerine bakalim.

dig paypal.com DNSKEY<br></br>  
;; ANSWER SECTION:<br></br>
paypal.com. 503 IN DNSKEY 256 3 5 AwEAAc/7r7w6qEg59vy...<br></br>  
paypal.com. 503 IN DNSKEY 257 3 5 AwEAAdVtmC6yOQb0+5M...```

Biraz RFC karistirarak gelen cevabi anlamaya calisalim. RFC 4034[1] burada yardimimiza kosuyor ve bizim icin su tanimlari yapiyor. Ilk 4 hane DNS icin de aynisi oldugundan TTL, IN gibi bolumlere deginmeyecegim.

256 Alan imzalama anahtari (ZSK)  
 257 Anahtar imzalama anahtari (KSK)  
 3 Protokol degeri (Sabit olarak 3)  
 5 RSA/SHA1 Algoritmasi

RSA/SHA1 disinda kullanilabilecek algoritmalar da var, bunlar icin tek tek RFC numarasi vermek biraz uzun olacagindan ilgili okuyucuyu IANA sayfasina[3] yonlendireyim. Geri kalan ve okunurlugu arttirmak icin kisalttigim alan ise genel anahtarlarin tutuldugu bolumden olusuyor.

-DS Kaydi  
 Bu kayit tipi, ilgili DNS alani icin kullanilan KSK’nin hashinin tutuldugu kayit tipi oluyor. DS kaydimizi icinde bulundugumuz DNS alani tutuyor. Yani ornek.com alani icin DS kaydimiz .com tarafindan tutuluyor. Tekrar ornegimize donelim ve oradan bakalim.

dig paypal.com DS


;; ANSWER SECTION:

paypal.com. 8698 IN DS 21037 5 2 0DF17B28554954D819E...```

21037 Anahtar Etiketi oluyor ve bir DNS alani icin essiz olmasi gerekiyor
5 RSA/SHA1 Algoritmasi
2 Son alanda gozuken hash’i hesaplamak icin kullanilan algoritma, SHA256

-RRSIG Kaydi
Bir alana ait bir tipten (ornegin sadece A ya da sadece MX) olusan kayit setinin ZSK ile imzalanmasi sonucu elde edilen verinin tutuldugu kayit tipidir. Ayni tipten birden fazla kayit olsa dahi bir tip icin bir RRSIG kaydi tutulur. Ornege bakalim.

dig +dnssec paypal.com MX<br></br>  
;; ANSWER SECTION:<br></br>
paypal.com. 185 IN MX 10 gort.ebay.com.<br></br>  
paypal.com. 185 IN MX 10 lore.ebay.com.<br></br>  
paypal.com. 185 IN MX 10 data.ebay.com.<br></br>  
paypal.com. 185 IN RRSIG MX 5 2 600 20130530031336 20130430022820 11811 paypal.com. r2CuXIHZtJn1VHJ2jPC4```

Ornegin paypal bana uc adet MX kaydi dondurmesine ragmen bu kayitlara ait tek bir RRSIG kaydina sahip oldugunu gorebiliyoruz.

MX ile hangi tip kayitlara ait RRSIG oldugunu soyluyor.  
 5 RSA/SHA1 Algoritmasi  
 2 Etiket numarasi (Burada paypal.com dedigimiz icin 2, wildcard kayit olup olmadigini tespit etmek icin kullaniliyor. Daha fazla detay icin RFC4034[2]‘a bakilabilir)  
 600 Orijinal TTL suresi. Onbellekleme yapan cozucu icin onemli  
 20130530031336 Imzanin suresinin ne zaman dolacagi  
 20130430022820 Imzanin ne zamandan itibaren gecerli olacagi  
 11811 Bu veriyi imzalayan DNSKEY kaydinin etiket numarasi  
 paypal.com. Imzalamayi yapan yer  
 Son alan ise dijital imzayi gosteriyor

-NSEC3(NSEC) Kaydi  
 Simdiye kadar tanimladigimiz kayit tipleri ile bir kaydin gercek olup olmadigini dogrulayabiliyorduk. NSEC3 ile ise bir kaydin olmadiginin dogrulamasini yapabiliyoruz. NSEC ile NSEC3 temel olarak ayni isi yapsalar da NSEC’in bir alan icindeki tum kayitlara ulasilabilmesine olanak veren yapisindan dolayi (herkesin DNS alaninizi transfer edebildigini dusunun) NSEC3 ortaya cikiyor. Paypal neyse ki NSEC kullaniyor da bir ornegini gorebilecegiz ne kadar istenmeyen bir sey olabileceginin.

`dig aaaaaa.paypal.com NSEC`

aaaaaa ile sorgulamaya basliyoruz.

paypal.com. 59 IN NSEC dmarc.paypal.com. A NS SOA MX TXT RRSIG NSEC DNSKEY


_sip.
tls.paypal.com. 59 IN NSEC accounts.paypal.com. SRV RRSIG NSEC```

Bize dmarc, _sip.tls ve accounts kayitlarini verdi. O halde accu ile bir sey deneyip sonraki kayidi almaya calisalim.

dig accu.paypal.com NSEC<br></br>  
paypal.com. 59 IN NSEC _dmarc.paypal.com. A NS SOA MX TXT RRSIG NSEC DNSKEY<br></br>  
accounts.paypal.com. 59 IN NSEC active-history.paypal.com. CNAME RRSIG NSEC```

Artik active-history’yi de biliyoruz. Bu sekilde yeterince sorgu yaparsak gorulecegi uzere paypal’in tum DNS alanini alabiliriz ki pek istenmeyen bir sey. Ornegimizi NSEC3 donduren bir yer ile tamamlayip o kaydin da nasil gozuktugune bir bakalim.

dig verisign.com NSEC3


LVNT2DK6E38UB5HG27E7MCINT8M21C9P.verisign.com. 3599 IN NSEC3 1 0 8 4C44934802D3 LVP1CAGP8QAQJ5OTUH00PN5VDSSARVDE A NS SOA MX TXT RRSIG DNSKEY NSEC3PARAM```

Gordugunuz gibi donen kisim gizlenmis bir sekilde geliyor. Iste NSEC ile NSEC3 arasindaki en onemli fark bu.

-DLV Kaydi
Yazinin baslarinda DNS’in dagitik bir sistem oldugundan ve kimi ccTLD ve TLD’lerin henuz DNSSEC destegi vermeye baslamadiklarindan bahsetmistim. Peki icinde bulundugumuz alan (diyelim .tr) DNSSEC destegi vermiyorsa DNSSEC’i hic mi kullanamayacagiz? Cevap neyse ki hayir. Iste DLV kaydi bu isi yapmamizi saglayan kayit tipi. DNS lookaside validation’in kisaltmasi olan DLV, DNS alanimizi dogrulayacak alternatif bir ust alan belirtebilmemize izin veriyor. ISC’nin (bind ve dhcp’den hatirlayacaginiz) DLV hizmeti mevcut. Ornek yapilandirmamizda https://dlv.isc.org/ adresinden erisilebilen bu hizmeti kullanacagiz. Aslinda DLV kaydini recursor sunucular icin kullaniyoruz. Boylelikle root alaninda bulamadiklari kayitlari bu alternatif guven adasindan dogrulamaya calisiyorlar. Biz bu yazida authoritative bir sunucu kuracagimiz icin pek isimiz dusmeyecek. Fakat dlv.isc.org uzerinden dogrulama yapabilen recursive sunucular icin dlv.isc.org’ta bir kayit olusturacagiz.

Yaziyi burada bir ozetlemekte fayda var. DNSSEC icin bir guven zinciri olusturmaliyiz. Bu guven zinciri root zone’dan baslayip, bizim alanimiza kadar gelmeli. Eger alanimizi icinde barindiran alan imzalanmamissa bir sekilde baska bir rota’dan root zone’a ulastirmaliyiz bu zinciri. Bunu da DLV ile yapiyoruz.

PowerDNS+MySQL ile Ana isim sunucunun DNSSEC icin yapilandirilmasi

Ana isim sunucular (authoritative nameservers) yapi geregi kendi tuttuklari alan bilgileri icin dogrulama yapamiyorlar. Ornek vermek gerekirse, arkadasiniza “Benim yasim 30.” dediginizde, kendinize hemen ardindan “Yasimin 30 olduguna guveniyor muyum?” demiyorsunuz. Guvenmeseydiniz ilk asamada soylemezdiniz degil mi? DNSSEC icin de durum bu sekilde. Yinelemeli sorgu yapan bir isim sunucu (recursive nameserver), ana isim sunucuya (authoritative nameserver) “Boyle boyle bir bilgi geldi, onayliyor musun?” derken, ana isim sunucu kendisine “Boyle bir bilgi paylastim, bunu onayliyor muyum?” demiyor. Dolayisiyla DNSSEC icin ilk asamada yinelemeli sorgu yapan isim sunuculara bu yetenegin kazandirilmasi gerekiyor. Google’in islettigi genel isim
sunucular gecen ay itibariyle[2] istemciden DNSSEC dogrulamasinin talep edildigi bilgisini alirsa dogrulama yapmaya basladilar. Yani aslinda DNS sunucularinizi sadece ana isim sunucu (authoritative nameserver) olarak
yapilandirsaniz da, DNSSEC destegini varsayilan olarak kullanan diger yinelemeli sunucular istemcilere dogrulanmis DNS verinizi sunabilecek. (Burada bir parantez acip DLV degil de dogru duzgun DNSSEC destegi veren bir alan kullandiginiz varsayiyorum. Ornegin .com ya da .net) Fakat bir sirketin ya da kurumun yerel agindan gelen istekler icin yinelemeli sorgu yapan kendi DNS sunucusuna ihtiyaci varsa, o sunucuya DNSSEC verisini nasil yorumlayacaginin ogretilmesi gerekiyor. UNBOUND bu konuda oldukca basarili denedigim kadariyla. Bu arada DNS verisinin dogrulandigini dig sorgusunun ciktisinda bulunan flags kisminda ad bulunup bulunmamasindan anliyoruz.

dig +dnssec paypal.com a<br></br>  
; > DiG 9.9.2-P1 > +dnssec paypal.com a<br></br>
;; global options: +cmd<br></br>
;; Got answer:<br></br>
;; ->>HEADER
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1```

Gordugunuz gibi flags ad (authentic/authenticated data) ile donuyor eger DNSSEC dogrulamasi yapilabiliyorsa.

Ubuntu 12.04 LTS 64 bit uzerinde gerceklestirecegim tum islemleri. Depolarda pdns-server diye arama yaptigimda su anda 3.0.1 surumunun (son surumu tarih itibariyle 3.2) oldugunu goruyorum. Verileri MySQL'de saklayacagim icin pdns-backend-mysql ile birlikte kuruluma basliyorum.

`sudo apt-get install pdns-backend-mysql`

PowerDNS bizim icin MySQL yapilandirmasini onerecek fakat es gecip elle yapmayi tercih ediyorum. Ilk kurulumda oldukca makul degerler ile geliyor fakat degistirmek isterseniz /etc/powerdns/pdns.conf dosyasina goz atabilirsiniz. /etc/powerdns/pdns.d/ altindaki pdns.local.gmysql dosyasini ise veritabanimizi yapilandirdiktan sonra PowerDNS'e tanitmak icin kullanacagiz. Yalniz bu surumde bir bocek var ve bu sekilde conf.d ile kullandigimizda pdnssec komutunu kullanmamiza izin vermiyor. O yuzden ana yapilandirma dosyasi olan pdns.conf'taki !include ile baslayan satiri yorum haline getirip, pdns.local.gmysql dosyasinin icerigini pdns.conf dosyasina aktarmalisiniz.

`mysql -u root -p`

ile komut satirina duselim. Yeni bir veritabani ve bu veritabani icin bir kullanici olusturalim.

CREATE DATABASE mydnsdata;


GRANT ALL PRIVILEGES ON mydnsdata.* TO 'mydnsadmin'@'localhost' identified by 'sifre';


FLUSH PRIVILEGES;


USE mydnsdata;```

Gerekli tablolari olusturalim.[4] Bu kisimi oldugu gibi kopyalayip yapistirabilirsiniz.

CREATE TABLE domains (<br></br>  
id INT AUTO_INCREMENT,<br></br>  
name VARCHAR(255) NOT NULL,<br></br>  
master VARCHAR(128) DEFAULT NULL,<br></br>  
last_check INT DEFAULT NULL,<br></br>  
type VARCHAR(6) NOT NULL,<br></br>  
notified_serial INT DEFAULT NULL,<br></br>  
account VARCHAR(40) DEFAULT NULL,<br></br>  
primary key (id)<br></br>  
) Engine=InnoDB;<br></br>
CREATE UNIQUE INDEX name_index ON domains(name);<br></br>  
CREATE TABLE records (<br></br>  
id INT AUTO_INCREMENT,<br></br>  
domain_id INT DEFAULT NULL,<br></br>  
name VARCHAR(255) DEFAULT NULL,<br></br>  
type VARCHAR(10),<br></br>  
content VARCHAR(64000) DEFAULT NULL,<br></br>  
ttl INT DEFAULT NULL,<br></br>  
prio INT DEFAULT NULL,<br></br>  
change_date INT DEFAULT NULL,<br></br>  
ordername VARCHAR(255) BINARY,<br></br>  
auth BOOL,<br></br>  
primary key(id)<br></br>  
) Engine=InnoDB;<br></br>
CREATE INDEX rec_name_index ON records(name);<br></br>  
CREATE INDEX nametype_index ON records(name,type);<br></br>  
CREATE INDEX domain_id ON records(domain_id);<br></br>  
CREATE TABLE supermasters (<br></br>  
ip VARCHAR(25) NOT NULL,<br></br>  
nameserver VARCHAR(255) NOT NULL,<br></br>  
account VARCHAR(40) DEFAULT NULL<br></br>  
) Engine=InnoDB;<br></br>
CREATE TABLE domainmetadata (<br></br>  
id INT AUTO_INCREMENT,<br></br>  
domain_id INT NOT NULL,<br></br>  
kind VARCHAR(16),<br></br>  
content TEXT,<br></br>  
primary key(id)<br></br>  
);<br></br>
CREATE INDEX domainmetaidindex ON domainmetadata(domain_id);<br></br>  
CREATE TABLE cryptokeys (<br></br>  
id INT AUTO_INCREMENT,<br></br>  
domain_id INT NOT NULL,<br></br>  
flags INT NOT NULL,<br></br>  
active BOOL,<br></br>  
content TEXT,<br></br>  
primary key(id)<br></br>  
);<br></br>
CREATE INDEX domainidindex ON cryptokeys(domain_id);<br></br>  
CREATE INDEX recordorder ON records (domain_id, ordername);<br></br>  
CREATE TABLE tsigkeys (<br></br>  
id INT AUTO_INCREMENT,<br></br>  
name VARCHAR(255),<br></br>  
algorithm VARCHAR(50),<br></br>  
secret VARCHAR(255),<br></br>  
primary key(id)<br></br>  
);<br></br>
CREATE UNIQUE INDEX namealgoindex ON tsigkeys(name, algorithm);```

Bu islemlerin ardindan DNSSEC icin kullanabilecegimiz veritabani semamiz hazir hale geliyor. Simdi veritabanimiza bir alan ekleyecegiz. Istersek bunu yine MySQL uzerinden yapabiliriz fakat degisik bir sey gormek icin bir arayuz kullanalim bu sefer. PowerDNS icin oldukca fazla sayida yonetim arayuzu var. Bunlarin bildiklerimden hicbiri DNSSEC'i desteklemiyor. Dolayisiyla DNSSEC islerini yine terminalden yapacagiz fakat basit bir alani bu arayuzlerden biri ile ekleyelim. Tavsiye edebileceklerim arasinda poweradmin[5] ve powerdns-webinterface[6] var. Zaten ikisi de birbirine oldukca benziyor. Herhangi birini kurabilirsiniz.

Ubuntu icin php5-mysql ve apache2 paketlerine ihtiyac duyacaksiniz bagimlilik olarak. Kurmasi cok kolay oldugu icin daha detaya inmiyorum. Kurulum islemi(bir tar dosyasini indirip actiktan sonra veritabani bilgilerini tutan dosyayi duzenlemek) tamamlandiktan sonra arayuzden alan adimizi ekleyelim. Ben bu yazida .tr altindaki alan adlarinin DNSSEC destegi olmadigini gostermek icin test.name.tr alan adini ekledim.

[![pdns-webinterface](https://blog.cagriemer.net/wp-content/uploads/2013/05/pdns-webinterface-300x101.png)](https://blog.cagriemer.net/wp-content/uploads/2013/05/pdns-webinterface.png)

Bu asamayi da tamamladiktan sonra terminale donup su komutlari verebiliriz.

pdnssec secure-zone test.name.tr


pdnssec set-nsec3 test.name.tr


pdnssec rectify-zone test.name.tr```

PowerDNS bizim icin anahtarlari olusturmaktan tutun, kayitlari imzalamaya kadar her islemi yapmis oldu. Bir sonraki yazida BIND ile ayni islemleri elle nasil yapabiliriz onlari da anlatmaya calisacagim. Unutulmamasi gereken en onemli nokta DNS alanimizda herhangi bir kayit degisikligi yaptigimizda (ekleme/cikarma/degistirme) son komut olan pdnssec rectify-zone alanadi komutunu yeniden calistirmak.

dnssec show-zone test.name.tr

komutu ile KSK ve ZSK'lerimizi gorebiliriz. Iki ZSK olmasinin nedeni PowerDNS'in, yazinin baslarinda bahsettigim key rollover islemini otomatik olarak yapmaya olanak tanimasi. Yazinin son kisimlarinda cevrimici araclarla yapilandirmamizi test ederken bu ikinci ZSK'i yeniden gorecegiz.

.tr'nin henuz DNSSEC destegine kavusmadigini (YIL 2013) defalarca tekrarladim ama bir kere daha tekrarlayayim. Su asamada bizim DLV kayitlarina sahip resolverlar icin dlv.isc.org adresine gidip DNSKEY'imizi (KSK) oraya eklememiz gerekiyor. show-zone komutunun verdigi ciktidaki DNSKEY'i dlv.isc.org adresinden bir hesap acip oraya tanitirsak bize DNS alanimiza eklememiz icin bir TXT kaydi veriyor. Yukaridaki ekran goruntusunde de bu TXT kaydinin ekli oldugunu gorebilirsiniz. Gelip bu kaydi DNS alanimiza ekliyoruz ve rectify-zone iceren komutu bir daha calistiriyoruz. Su asamada dlv.isc.org alanin gercekten bize ait oldugunu dogrulamaya calisacaktir. Bu islem de tamamsa artik alanimizi DNSSEC ile sunuyoruz demektir. dnsviz.net adresine gidip kontrol edelim bakalim her sey duzgun calisiyor mu? Bu arac bize asagidaki gibi bir cikti veriyor.

dnssec-test

Bu ciktida gordugunuz siyah kalin oklar DNSSEC destegi olmayan alanlari gosteriyor. Yani . (root) alani .tr icin, .tr alani .name.tr icin, .name.tr alani ise test.name.tr icin bir DS kaydina sahip degil. Dolayisiyla DNSSEC ne yazik ki desteklenemiyor. Fakat ISC'nin islettigi DLV sayesinde test.name.tr alani dogrulanabiliyor. Yalniz dedigim gibi cozumlemeyi yapan resolver'larin bu DLV kaydini kullanacak sekilde yapilandirilmis olmasi gerekiyor. Yine yukarida bahsettigim ikinci ve henuz kullanimda olmayan ZSK'i de kesikli cizgilerle cizilmis elips icerisinde gorebiliyoruz.

Bu testten de basariyla gectiyseniz, tebrikler. Artik DNS alaniniz bir nebze de olsa daha guvenli. Peki bunca seyi nicin yaptik? Burada favori DNS kaydim olan SSHFP'ye geliyoruz. SSHFP, adi uzerinde SSH fingerprint'leri (sunuculari tanimaya yarayan anahtarlar) DNS uzerinden dagitmaya yariyor. OpenSSH da sagolsun bizim icin bu anahtarlari kontrol edebiliyor. Dolayisiyla sunucuya erisirken gercekten erismek istedigimiz sunucuya gittigimize emin oluyoruz. Tabii eger biri DNSSEC ile guclendirdigimiz DNS alanimizla oynamadiysa. SSHFP'ye BIND ile bu islemleri nasil yaptigimiz yazida tekrar deginecegim.

[1] http://tools.ietf.org/html/rfc4034
[2] http://googleonlinesecurity.blogspot.com/2013/03/google-public-dns-now-supports-dnssec.html
[3] http://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xml
[4] http://doc.powerdns.com/html/generic-mypgsql-backends.html
[5] https://www.poweradmin.org/trac/
[6] https://code.google.com/p/powerdns-webinterface/

22 Mayıs 2013

Posted In: dnssec, Gezegen, PowerDNS, SSHFP, tr

WP Twitter Auto Publish Powered By : XYZScripts.com