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
;; ANSWER SECTION:
paypal.com. 503 IN DNSKEY 256 3 5 AwEAAc/7r7w6qEg59vy...
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
;; ANSWER SECTION:
paypal.com. 185 IN MX 10 gort.ebay.com.
paypal.com. 185 IN MX 10 lore.ebay.com.
paypal.com. 185 IN MX 10 data.ebay.com.
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
paypal.com. 59 IN NSEC _dmarc.paypal.com. A NS SOA MX TXT RRSIG NSEC DNSKEY
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
;
> DiG 9.9.2-P1
> +dnssec paypal.com a
;; global options: +cmd
;; Got answer:
;; ->>HEADER- opcode: QUERY, status: NOERROR, id: 47088
;; 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 (
id INT AUTO_INCREMENT,
name VARCHAR(255) NOT NULL,
master VARCHAR(128) DEFAULT NULL,
last_check INT DEFAULT NULL,
type VARCHAR(6) NOT NULL,
notified_serial INT DEFAULT NULL,
account VARCHAR(40) DEFAULT NULL,
primary key (id)
) Engine=InnoDB;
CREATE UNIQUE INDEX name_index ON domains(name);
CREATE TABLE records (
id INT AUTO_INCREMENT,
domain_id INT DEFAULT NULL,
name VARCHAR(255) DEFAULT NULL,
type VARCHAR(10),
content VARCHAR(64000) DEFAULT NULL,
ttl INT DEFAULT NULL,
prio INT DEFAULT NULL,
change_date INT DEFAULT NULL,
ordername VARCHAR(255) BINARY,
auth BOOL,
primary key(id)
) Engine=InnoDB;
CREATE INDEX rec_name_index ON records(name);
CREATE INDEX nametype_index ON records(name,type);
CREATE INDEX domain_id ON records(domain_id);
CREATE TABLE supermasters (
ip VARCHAR(25) NOT NULL,
nameserver VARCHAR(255) NOT NULL,
account VARCHAR(40) DEFAULT NULL
) Engine=InnoDB;
CREATE TABLE domainmetadata (
id INT AUTO_INCREMENT,
domain_id INT NOT NULL,
kind VARCHAR(16),
content TEXT,
primary key(id)
);
CREATE INDEX domainmetaidindex ON domainmetadata(domain_id);
CREATE TABLE cryptokeys (
id INT AUTO_INCREMENT,
domain_id INT NOT NULL,
flags INT NOT NULL,
active BOOL,
content TEXT,
primary key(id)
);
CREATE INDEX domainidindex ON cryptokeys(domain_id);
CREATE INDEX recordorder ON records (domain_id, ordername);
CREATE TABLE tsigkeys (
id INT AUTO_INCREMENT,
name VARCHAR(255),
algorithm VARCHAR(50),
secret VARCHAR(255),
primary key(id)
);
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.
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.
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/
Aynı şekilde 
;
