Internet guvenligi arastirma grubu, ISRG, ismiyle yeni olusturulan ve kar amaci gutmeyen bir organizasyon tarafindan isletilecek let's encrypt sertifika otoritesinin hangi problemi cozmeye calistigini aciklayarak baslamak yerinde olacaktir diye dusunuyorum. SSL/TLS'in genis capta uygulanabilmesinin onundeki en buyuk engellerden en onemlileri kurulum karmasikligi, burokrasi ve sertifikalarin yuksek ucretleri olarak goruluyor. 2015 yazindan itibaren ucretsiz olarak sertifika dagitmaya baslayacak olan yeni otoritemiz su siralar tek bir komut calistirilarak, hazirda sunulmakta olan sitelerin alan adi dogrulamasini yaptiktan sonra https'ye gecirilmesi islemini yapacak bir istemci yazilimi ve bu yazilimin insa edilerken temel alindigi protokol uzerinde calisiyor. Let's encrypt bu surecte gozetecegi ana prensipleri ise soyle siraliyor;

Bedelsiz: Alan adi sahipleri kontrol ettikleri alanlar icin hicbir ucret odemeden sertifika sahibi olabilecekler

Otomatik: Sertifika alim sureci ve yenilenmesi ve sunucuda konfigure edilmesi gibi islemler tamamen otomatiklestirilerek minimum operator mudahalesi gerektirecek

Guvenli: Let's encrypt modern guvenlik tekniklerinin ve alandaki en iyi uygulamalarin implemente edilebilecegi bir platform olacak

Seffaf: Verilen ya da gecersiz kilinan tum sertifikalar incelemek isteyen herkese acik olacak

Acik: Gelistirilen protokol herkese acik bir standart olacak, gelistirilen yazilimlar ise elverdigince acik kaynak olarak sunulacak

Katilimci: Tek bir organizasyonun kontrolunde olmaktansa her acik standartta oldugu uzere topluluktan katilimcilarin fayda saglayacagi tumlesik bir girisim olmayi amaclayacak

Gelelim nasil calistigina. Altyapi ve istemci yazilimi tamamlandiginda kendi ifadeleriyle

sudo apt-get install lets-encrypt  
sudo lets-encrypt ornek.com  

komutlarini calistirmak tum ayarlari ve sertifika surecini halletmek icin yeterli olacak. Peki arkaplanda neler oluyor? Aslinda bunun icin istemci yazilimin ne yaptigina bakmadan once ACME protokolune bakmakta fayda var. Taslak halindeki RFC'ye gore genel hatlariyla protokol soyle.

Istemci yazilimi operatore hangi alan adlari icin sertifika istedigini soracak. Bu islemin ardindan sertifika otoritelerinin bir listesi gelecek. Eger secilen otorite ucretsiz sertifika saglayan bir otorite degilse odeme bilgisi bu asamada istenecek. Daha sonra yazilim operatore kisa bir sure icinde sertifikanin verilecegini bildirecek. Arkaplanda sunucu, sertifika otoritesi ile ACME kullanarak operatorun belirttigi alan adlari icin sertifika isteginde bulunacak. Sertifika otoritesinin verilen sertifikanin tipine gore belirledigi gereksinimler yerine getirildiginde verilen sertifika otomatik olarak indirilecek ve web sunucu sertifikayi kullanacak sekilde yapilandirilacak. Tercihen operatore e-posta, sms vb. gibi bir yontemle haber verilecek. Normal web hizmeti surecinde web sunucu sertifika otoritesi ile gerektigi taktirde konusarak OCSP (cevrimici sertifika durum protokolu) cevaplari, sertifika listeleri gibi bilgileri almaya devam ederek sorunsuz bir web sunma isinin yururlugunu saglamaya devam edecek.

Burada araya girip bir iki konuya acikliga kavusturayim. Yukarida web sunucu olarak bahsedilse de e-posta, xmpp vs. gibi sertifika kullanabileceginiz her hizmette ACME protokolunu ve bu protokol uzerinden calisan istemciyi kullanabileceksiniz. Su asamada organizasyon dogrulamasi(organization validation) ya da kapsamli dogrulama(extended validation) surecleri nasil isleyecek cok net olmasa da alan adi dogrulama icin(domain validation) bir sorun yok gibi gozukuyor. Protokole doneyim.

Standardimizda uc adet anahtar/anahtar cifti tanimi bulunuyor.

Ozne acik anahtari (subject public key): Sertifikaya konu olan alanlar icin dahil edilecek acik anahtar

Yetkilendirilmis anahtar cifti (authorized key pair): Sertifika otoritesinin herhangi bir kimligin yonettigi/yonetebilecegi sertifikalar icin iletisimde kullanacagi anahtar cifti. Bu cift birden fazla kimlik icin kullanilabiliyor.

Sifirlama anahtari (recovery token): Diger anahtarlarin ya da anahtar ciftlerinin kaybedilmesi durumunda sertifika otoritesine kimlik kanitlamak icin kullanilabilecek gizli anahtar

Butun iletisim https uzerinden json ile saglaniyor. Kimlikler ACME'de anahtar ciftleri ile ifade ediliyor. Bir alan adi icin istek yapilmadan once gecerli bir anahtar ciftinin ozel anahtarinin o alan adini kontrol eden tarafindan sahipliginin gosterilmesi gerekiyor. Bu kisim bildigimiz acik anahtarli sifrelemenin aynisi oldugundan uzerinde cok durmaya gerek yok. Alan adinin ya bir DNS kaydi ile ya da sunulan bir dosya ile bir ozel anahtar tarafindan kontrol edildigi kanitlaniyor. Sertifika otoritesi bu kanitlama basarili olursa basarili mesaji ve sifirlama anahtari donuyor istemciye.

Kimlik kanitlama isleminin ardindan istemci, belirtilen alan icin bir sertifika imzalama istegi olusturuyor(CSR) ve bu istegi ozel anahtari ile imzalayip sunucuya gonderiyor. Sunucu gelen istegin daha once dogruladigi anahtar ciftine ait olduguna emin olduktan sonra sertifikayi olusturuyor ve istemciye gonderiyor. Bu cevapta sertifika yenilemenin tekrar bir dogrulama gerektirmedigi durumlarda, istemci tarafindan yenileme icin kullanilabilecek adres de gonderilebiliyor. Sertifikanin iptali icin istemci basitce, ozel anahtariyla imzaladigi iptal istemini sunucuya gonderiyor ve sunucu bu istegi aldiginda sertifikayi iptal ediyor. Istemci ya da sunucu yazacaklar icin taslak standardin burada atladigim teknik detaylarina yukarida paylastigim protokol adresinden ulasmak mumkun.

Sistem 100 metre yukaridan bakildiginda aciklamaya calistigim sekilde isliyor. Ucretsiz sertifikalarin edinilebilmesine olanak taniyacagi ve TLS implementasyonu onundeki teknik engelleri kaldirma potansiyeli oldugu icin interneti degistirebilecek bir proje olarak goruyor ve heyecanlaniyorum. Umarim Postfix, Nginx, ejabberd gibi projeler de ACME'yi ve dolayisiyla let's encrypt sertifika otoritesini otomatik olarak kullanabilmek ve yapilandirabilmek icin gereken adimlari en kisa surede atarlar. Bu sayede gorece daha guvenli bir internet deneyimi icin gereken en temel adimlardan birini atmis oluruz.

Simdiye kadar uzerinde cokca calisamadigimdan ancak dgst, enc, rand, version ve genel man sayfasini tamamlayabildim. Bir de cogu ozellik OpenSSL tarafindan da belgelendirilmemis oldugundan ne ise yaradigini anlayip aciklamasi epey vakit aliyor bir parametrenin. Bu ufak girizgahtan sonra enc icin yazdigim belgenin ham halini genel bir fikir vermesi adina paylasmak istedim. Bu erken asamada gelebilecek geri donuslere gore uzun donemli haftasonu projemin ilerleyen asamalarini da sekillendirebiliriz diye umuyorum.

OpenSSL’in enc komutu sifreleme ve sifre cozme islemlerini gerceklestirmeye yariyor. Bu belgede enc komutunun man sayfasinda listelenmemisse bile kaynak kodda gozuken tum secenekleri orneklerle birlikte aciklamaya calisacagim.

Kullanilabilecek seceneklerin detayina inmeden once zlib ve base64’a kisaca bir goz atalim. Eger OpenSSL’e ilk arguman olarak enc yerine zlib ya da base64 gecirirseniz ve platformunuzdaki openssl zlib destegi ile birlikte derlendiyse girdi dosyanizin zlib ile sikistirilmis halini ya da base64 ile kodlanmis halini elde edebilirsiniz. Diyelim icerigi asagida gosterilen gibi bir metin dosyaniz var.

Bu sifrelerim dosyasini zlib ile sikistirmak isterseniz calistirmaniz gereken komut soyle olacaktir.

Eger zlib ile sifrelenmis (aslinda sikistirilmis) dosya alirsaniz da icerigini gormek icin vermeniz gereken komut soyle olacaktir.

Zlib ornegiyle base64 ornegi birebir ayni. Yukaridaki komutlarda zlib gordugunuz yere base64 yazarsaniz base64 ile sifreleyecektir. Komutun genel kullanimi hakkinda bir fikir olusmaya baslamistir saniyorum.

enc komutunun alabilecegi butun seceneklere kisaca goz gezdirebiliriz bu noktada.

Kullanilabilecek sifreleme yontemleri ise soyle; aes, bf, camellia, cast, cast5, des, id, rc2, rc4, seed ve tabii bunlarin cesitli anahtar boyutuna ve sifreleme moduna gore olusturulacak varyasyonlari. Burada amac OpenSSL’in enc komutunun nasil calistigini aciklamak oldugundan her bir sifreleme yontemini aciklamaya calismak gibi bir cilginligi denemeyecegim.

Kaldigimiz yerden seceneklere devam edelim. Simdi ayni dosyayi aes-256-ctr ile sifreleyelim ve ciktiyi da eposta ile kolayca aktarabilmek icin base64 olarak verelim.

Eger yukaridaki ornekte de goruldugu uzere sifreyi komutu verirken gostermezsek bize bir sifre soracaktir. Ardindan sifreyi dogrulayacak ve dosyamizi ancak ve ancak iki sifre birbirleriyle tutuyorsa duzgun sekilde olusturacaktir. Komutta aslinda enc kelimesini kullanmayabiliriz. Eger kullanmaz isek aes-256-ctr’i basinda – isareti olmadan kullanmamiz gerekir. Yani su sekilde.

Elimizdeki sifreli dosyalari acmak icin ise yapmamiz gereken su;

Yine bu komutun kisa versiyonu da soyle olacaktir;

-pass secenegi bes deger alabiliyor. Burada eger sifreyi bize sormasini istemezsek yukaridaki orneklerde oldugu gibi, nereden okumasi gerektigini belirtiyoruz. Yani ornegin, komut satirindan sifre gecirmek eger problem degilse su sekilde yapabiliriz sifreleme islemimizi;

Goruldugu uzere dogrudan sifre vermek icin pass:sifre seklinde tanimlamamiz gerekiyor. env:degisken, file:/dosya/yolu, fd:dosyatanimlayicinumara, stdin kullanabilecegimiz diger secenekler. Ornegin bir de file:/dosya/yolu ile yapalim islemimizi. Tabii dosya kullanildiginda parolamizi karmasiklastirabiliriz. Mesela once 2048 bitlik bir dosya olusturalim /dev/urandom yardimiyla.

Alternatif olarak anahtari soyle de uretebiliriz.

Simdi bu dosya ile sifrelemeyi deneyelim sifreleri iceren metini.

Artik anahtarimizi USB bellegimize atabilir, yine daha once ornekledigimiz sekilde base64 ile sifreleyip(kodlayip) bir ciktisini aldiktan sonra ailemize/arkadaslarimiza saklamasi icin gonderebilir ya da cuzdanimiza atabiliriz.

-p ve -v secenekleri yaptigimiz sifrelemedeki kullanilan girdi ve cikti boyutlarini, uretilen anahtari, salt ve baslangic vektoru degerlerini goruntulemek icin kullaniliyor. Bilgi amacli oldugundan sifreleme ya da desifre etme islemleri sirasinda kullanilmasi hayati onem tasimiyor. -P herhangi bir sifreleme/desifreleme yapmadan anahtari, baslangic vektorunu ve salt degerini bastirip programi sonlandiriyor.

-a ve -base64 orneklerini yukarida vermistik -z ise base64 yerine zlib kullaniyor. Burada deginilmesi gereken bir de -A var. -A yine -a ya da -base64 ile ayni isi yapiyor fakat ciktiyi tek bir satir olarak olusturuyor. Dolayisiyla cok buyuk dosyalarda calismayabiliyor.

-salt ontanimli oldugundan yukaridaki orneklerde kullanmamistik fakat yine komutun okunabilirligi acisindan harici olarak kullanilabilir. -nosalt ise salt kullanilmamasi gerektigini soyluyor ki sozluk ataklarini etkin kilabileceginden kullanilmasi pek onerilmiyor.

-K, -S ve -iv ile hex formatinda sirasiyla anahtar, salt ve baslangic vektoru degerlerini komuta gecirmek mumkun. Fakat eger bir parola kullaniyorsaniz -pass orneklerinde oldugu gibi bu degerleri haricen gecirmenize gerek yok(salt degerini vermek isteyebilirsiniz belki) cunku gecirdiginiz paroladan hesaplanacaklardir.

Acikca gorulecegi uzere eger -K ile anahtar ve -iv ile baslangic vektoru degerlerini veriyorsaniz salt hic kullanilmiyor. Bunun nedeni salt degerinin verdiginiz paroladan anahtar uretilirken kullanilmasi. Yani zaten anahtari verdiginizde bir de salt degeri vermenize gerek yok. -K kullanirsaniz -iv de kullanmaniz gerekiyor. Fakat hem -K verip hem de sifre verip -iv degerini OpenSSL’den sifreden turetmesini istemek de su ornekte oldugu gibi mumkun.

-md parolamizdan bir anahtar olustururken kullanilacak hash fonksiyonunu belirtmeye yariyor. normalde md5 kullaniyor. Ornek;

salt kullanmayarak parolamizdan uretilen anahtarlarin hangi hash fonksiyonu ile uretilmis oldugunu gormus olduk. Farkettiginiz uzere ayni anahtari urettiginden, onceden olusturulmus sozluklerle saldirilabilir hale gelecektir verimiz. Dolayisiyla salt kullanmak cok onemli. md4, md5, ripemd160, sha, sha1, sha224, sha256, sha384, sha512 ve whirlpool kullanilabilecek hash fonksiyonlari olarak siralanabilir.

-engine ayri bir uretec kullanabilmek icin veriliyor komuta. Ornegin rastgele sayi ureten bir donaniminiz varsa ya da baska bir uretec kullanmak istiyorsaniz bunu secebilirsiniz.

-debug ile girdi cikti islemlerinde bir sorun yasaniyorsa nerede sorun yasandigini gorebilirsiniz. Daha cok gelistiricilere yonelik olmakla birlikte baskasi tarafindan yazilmis bir komutun hic openssl kullanmadiysaniz ne yaptigini ogrenmek icin de kullanilabilir belki. Ornek;

Bellekte gerekli islemler icin alan olusturuyor. Dosyayi okuyor. Sifreliyor. Base64’a ceviriyor. Cikti dosyasina yaziyor ve calisirken olusturdugu bellek alanini geri birakiyor.

-none ile cipher degerini bosaltiyoruz. Dolayisiyla herhangi bir sifreleme yapilmiyor. Bunu niye yapmak isteyebilirsiniz bir kullanim alani bulamadim acikcasi. Yine de ornekleyelim;

-nopad’i aciklamak icin biraz ayrintiya girmek gerekecek. Bazi sifreleme modlari verilen mesajin boyutunun ontanimli blok boyutunda olmasini gerektirir. Ornegin aes-cbc bunlardan birisi. Simdi 10 bytelik bir karakter dizisini sifreleyelim ve cikti boyutu ne kadar olacak ona bakalim.

Gordugunuz gibi 16 byte’a tamamladi. Yani cbc 16 byte’lik bloklar bekliyor bizden. O halde -nopad kullanip 10 bytelik dizgi icin ne yapacak ona bakalim.

Hata verdi. Demek ki CBC icin illa 16 byte’a tamamlamamiz gerek mesajimizi. Peki mesajimiz 16 byte ise o zaman ne olacak?

Yine bir sonraki 16 byte’a tamamladi. Fakat sifrelenmis metinin boyutu iki katina cikti. O halde 16 byte’in tam sayi kati oldugunu bildigimiz mesajlar icin -nopad kullanip ciktinin boyutundan tasarruf edebiliriz. Hemen ornekleyecek olursak;

Farkettiginiz uzere bu sefer padding yapmadi, boylelikle biz de boyuttan tasarruf etmis olduk. Iste -nopad de bu ise yariyor. Fakat bu secenegin guvenlik acisindan bir sorun cikarip cikarmayacagindan emin degilim.

Diyelim bir veri akisiniz var ve karsi tarafa gondermeden once sifrelemek istiyorsunuz. Bu islemi de yazida bolca ornekledigimiz aes-256-ctr -blok gibi gozuken stream cipher :)- ile yapmaya karar verdiniz. -bufsize secenegi OpenSSL’in gerekli islemi gerceklestirmeden once ne kadar veriyi almasi gerektigini soyluyor. Yani kullandiginiz sifreden bagimsiz olarak OpenSSL’e gelen veriyle alakali bir secenek -bufsize. Asagidakinden daha uygun bir senaryo yaratamadim ne yazik ki ornek icin, eger akliniza gelen daha anlasilir bir ornek varsa eklemenizi rica ederim.

netcat’e benim icin 10001 numarali portu dinlemesini soyledim. Bu porttan gelen veri akisi OpenSSL ile desifre edilecek ve ardindan mplayer’a gonderilecek. Bu istemci komutumuz. Baska bir terminal penceresinde sunucu komutunu girelim.

Elimde bulunan 1.2GB boyutunda final2.avi isimli videoyu aes-256-ctr ile sifreleyip netcat yardimiyla bu sifrelenmis akisi localhosttaki 10001 numarali porta yolla diyorum. Burada -bufsize 350 milyon byte olarak verildi ki arada gecen sure hissedilebilir olsun. Yani OpenSSL 350M byte veri alana kadar bekliyor ardindan islemi yapiyor. Benim sistemimde mplayer’in baslamasi bu sartlar altinda yaklasik 4 saniye suruyor. Cunku OpenSSL buffer’inin dolmasini bekliyor. Eger 350 milyon yerine 350 bin kullanirsam mplayer sunucu komutunu calistirdigim anda ekrana geliyor yani OpenSSL buffer’ini zaten almis ve islemi gerceklestirmis oluyor. Simdi normalde bunu aslinda tam tersi icin kullanirsiniz. Yani ne kadar az bufsize verirseniz o kadar puruzsuz kesintisiz bir akisiniz olacaktir. Ote yandan bufsize degeri ne kadar kuculurse CPU’ya binen yuk de o oranda artacaktir. O yuzden veri akisinin kesintisizligi ve CPU yuku arasindaki optimum deger bulunmalidir eger boyle bir is yapacaksaniz. Uc bir ornek oldu ama -bufsize’in ne is yaptigini iyi acikladi saniyorum.

Deginmedigimiz bir tek -non-fips-allow kaldi. Bu da FIPS versiyonu kurulmussa eger, standartta olmayan sifre turlerinin kullanilabilmesini sagliyor.

OpenSSL’in ufak bir parcasi olan enc iste burada anlatildigi kadar kullanmasi kolay ve guclu bir uygulama. Ne yazik ki belge bulmakta sikinti yasandigi icin son kullanici arasinda cok yayginlasmis degil. Bu yaziyla sifreleme ve desifreleme islemlerinin aslinda ne kadar kolay yapilabilecegini gostermeye calistim. Bir yandan da enc icin yalandan man sayfasi olmus oldu. Umarim birilerinin isine yarar bir gun.

Gunumuzde neredeyse hemen hemen her “teknolojik” cihaz icinde bulundugu agda DNS istekleri yapiyor. Bu nedenle kimi zaman yanlis yapilandirma kimi zaman da seytani amaclar dolayisiyla, genel dolasima acik olmayan IP adreslerine ait PTR sorgulari bazen yerel aglardan cikip/kacip kok sunuculara kadar gidiyor. Iste AS112[1] projesi adini kendisine atanmis “Autonomous System Number”dan[2][3] alan ve amaci kok sunuculara gelmemesi gerektigi halde gelen PTR sorgularinin neden oldugu yuku azaltmak olan bir proje.

Bu noktada daha once denk gelmemisler icin PTR kaydi nedir, AS numarasi nedir kisa bir tanim yapmakta fayda var diye dusunuyorum. PTR, “domain name pointer” obegindeki isaretci manasina gelen “pointer” kelimesinin kisaltmasi. Cogu zaman sadece ve sadece bir IP adresinin hangi alan adina isaret ettiginin ogrenilmesi icin kullanilsa da aslinda konfigurasyon gerektirmeyen ag kurulumlarinda da (DNS Service Discovery, zeroconf) onemli bir rolu var. Ozet bilgi vermek amaci guduldugunden simdilik ikinci kisimi bir kenara birakabiliriz. Basitce yaptigi is 10.0.0.4’teki bilgisayarin adi ne gibi sorulara cevap vermek. AS numarasi ise internetin neredeyse belkemigi diyebilecegimiz bir kavram. IANA tarafindan bolgesel kayit otoritelerine (Ornegin Avrupa’da RIPE) dagitilan bu numara BGP adi verilen protokolde hangi IP adresinin hangi numara tarafindan anons edildiginin belirlenmesinde kullaniliyor. Yani bir nevi IP adreslerinin IP adresi. Analoji ne kadar dogru oldu pek emin degilim gerci. Kisaca tanimlarimizi yaptigimiza gore AS112 projesine donelim.

En bilinenleri RFC 1918[4] ile tanimlanmis olmak uzere, genel dolasima acik olmayan IP adresleri vardir. Bu adresler yerel aglarda, multicast yapisinda, gelecekteki kullanimlar icin ve dokumantasyon amaciyla ayrilmis IP adresleridir. Bu IP adreslerinin coguna ait PTR kayitlari ya tanimsiz ya da sorguyu yapan agdaki cihaz icin gecersizdir. Dolayisiyla PTR kayitlarinin sorgulanmasi bu istekleri yanitlayan sunuculara ekstra bir yuk getirmektedir. RIPE orneginde 2000-3000 sorgu/saniye[5], IANA’da ise 3000-4000 sorgu/saniye[6] olan bu yukten kurtulmak icin AS112 projesi ortaya cikmistir. RFC 6304[7] ile destek vermek isteyenlerin neler yapmalari gerektiginin ogrenilebilecegi bu proje 2012 verilerine gore[8] 72 uc noktadan olusmaktadir.

[1] https://www.as112.net/
[2] http://as.robtex.com/as112.html#asinfo
[3] http://en.wikipedia.org/wiki/AutonomousSystem(Internet)\
[4] https://tools.ietf.org/html/rfc1918
[5] http://www.ripe.net/data-tools/dns/as112/about
[6] http://dns.icann.org/cgi-bin/dsc-grapher.pl?plot=bynode&server=as112
[7] http://tools.ietf.org/html/rfc6304
[8] https://www.as112.net/2012-survey.html

Ben kriptografi gurusu degilim, kimsenin de boyle bir unvanin hakkini verebilecegini sanmiyorum. O yuzden bu kisa yazida guncel kimi olaylardan ogrendiklerimizle ne yapmaya baslayabiliriz kendi penceremden, bilgimin yettigi kadariyla aktarmaya calisacagim. Yanlisim olursa, simdiden, bana yanlislarimi gostereceginiz icin tesekkur ederim. Amacim konu uzerinde biraz daha dusunulmesini saglamak. Hatta kimbilir belki birkac istekli e-posta grubu bile kurabilir.

Google ya da Skype ya da herhangi bir sirket, istihbarat ajanslarinin sunucularimiza dogrudan erisimi yok veya uygulamamiz uzerinden gecen trafigi bu ajanslarin kolayca dinleyebilecegi forma donusturen degisiklikler yapmayacagiz dediginde bu soylediklerine ne kadar guvenebiliyoruz? Herkesin yalan soyledigi, hatta avukatlar alinmasin ama kullanici sozlesmeleri ve bilgilendirmelerinin olasi bir yargilanma durumunda mahkemece kabul edilebilir yalanlari yazma sanati oldugu goz onunde bulunduruldugunda ben bu aciklamalarin hicbirine guvenemiyorum. Evet, son birkac yildir cogu sirket yetersiz de olsa seffaflik raporlari aciklamaya ve kendilerine yapilan hukuki istekleri kamuyla paylasmaya basladi. EFF (Electronic Frontier Foundation – Turkce’ye kazandirilmis bir adi var mi bilmiyorum ama Elektronik Gelecek Vakfi desek olur herhalde. Dijital haklar alaninda faaliyet gosteriyor.) ise isi bir adim daha ileri goturup devletin seffafligiyla ilgili aydinlatici yayinlar yapiyor bir suredir.[3] Fakat bu yeterli degil. A ya da B sirketine gelene kadar trafik hangi kanallardan nasil geciyor bunlari bilmiyoruz.[4] Ya da mesela Verizon orneginde[5] oldugu gibi tek bir istek ile milyonlarca kullanici bilgisi talep edilebildiginde yapilan isteklerin sayisi da anlamsizlasmaya basliyor. Bu da basitce hicbir sirketin sundugu hizmete guvenememeniz yani paranoya anlamina geliyor.

Sadece kriptografi bir cozum mu? Elbette tek basina kriptografi yeterli degil. Bu biraz sadece alicisinin gormesi gereken seyi naylon torba icine koyup torbanin agzina asma kilit takmaya benziyor. Bilgiyi ele gecirmek isteyen kisi asma kilitle ugrasmadan, bicakla torbayi kesiyor. Dolayisiyla sistemin ya da hadi moda adiyla soyleyeyim yazilim hizmetinin (SaaS, software as a service) yaratim surecinde mumkun oldukca cok guvenlik tehdidi dusunulerek yapilandirilmasi, farkli uzmanliklardan insanlarin gorusleri alinarak hayata gecirilmesi gerekiyor. Sifir bilgi (zero knowledge) politikasiyla matematikten hukuga, kuantum fiziginden islemci tasarimina ve akla gelebilecek bir suru alana ait uzmanliklarin bir araya gelip, Turkiye’de henuz pek bulunmayan risk sermayesi yatirimcilarinin fonlayabilecegi kucuk sirketler icin, herkese acik, denetlenebilen ve mumkunse prototipleri olan bilgi birikiminin (know how) olusmasina katkida bulunmasi gerekiyor.

Pratik bir soruyla yaziyi tamamlayayim. Diyelim sirketiniz sifir bilgi politikasiyla kullanicilara gizlilik imkani taniyan bir e-posta hizmeti vermek istiyor. Sunucularinizi nasil, nerelerde kurardiniz? Kimlik yonetimini ne sekilde yapardiniz? Kriptografik tercihleriniz ne yonde ve nasil olurdu? Hangi acik standartlari kullanir ve denetleme mekanizmanizi ne sekilde yapilandirirdiniz?

• Lavabit ve Hushmail genel anahtarli asimetrik sifreleme destegi veren eposta saglayicilari. Edward Snowden’in Lavabit kullandigi biliniyor.

[1] http://www.lavabit.com
[2] http://www.hushmail.com
[3] https://www.eff.org/issues/transparency
[4] http://fabiusmaximus.com/2013/06/11/nsa-surveillance-51264/
[5] http://arstechnica.com/tech-policy/2013/06/top-secret-doc-shows-nsa-demands-verizon-hand-over-millions-of-phone-records-daily/

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.

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

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.

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/

Bir gorsel kimi zaman bin kelimeden daha etkili olabildigi icin bir gorselle anlatima baslamak sistemin nasil calistigini aktarabilmek icin faydali olacaktir diye dusunuyorum. Gorsel icin .dia dosyasini yazinin sonundaki adresten indirebilir, indirdiginiz dosyayi istediginiz gibi duzenleyebilir ve dagitabilirsiniz. Kaynak gosterseniz hos olur ama zorunda degilsiniz.

Bu gorselde bulunan sayilara karsilik gelen istek ve yanitlar ise su sekilde;

Gelen Posta
1) Gonderici, posta gondermek istedigi adres icin MX kayitlarini ister
2) DNS sunucu MX kayitlarini gondericiye iletir
3) Gonderici MX kaydinin gosterdigi sunucuya posta gondermek istedigini soyler
4) Postayi alan sunucudaki MTA(postfix), MySQL’e alicinin tanimli olup olmadigini sorar
5) MySQL ustteki sorguya evet ya da hayir cevabini verir.
6) Evet cevabini alan Postfix, Dovecot’a postayi kendisi icin saklamasini soyler
7) Dovecot(MDA) gelen postayi kullaniciya ait dizine depolar

Posta Kontrolu
8) Alici Dovecot’a postalarini kontrol etmek istedigini soyler
9) Dovecot aliciya iletisim icin bu sertifikayi kullan diyerek cevap verir
10) Alici, gelen sertifika ile hesap bilgilerini sifreler ve tekrar yollar
11) Dovecot MySQL’e hesap bilgilerinin dogru olup olmadigini sorar
12) MySQL bu sorguyu yanitlar.
13) Dovecot depolama yaptigi dizinden kullanici icin tuttugu postalari ister
14) Bilgi Dovecot’a gonderilir
15) Gondermesi gereken her seye sahip olan Dovecot kullaniciya postalarini iletir

Giden Posta
16) Alici, Postfix’e posta gondermek istedigini soyler
17) Postfix sertifikasini gonderir ve kimlik dogrulamasi yapmasini ister alicidan
18) Alici gelen sertifika ile kimlik bilgilerini sifreler ve geri yollar
19) Postfix, Dovecot’tan gelen bilgileri kendisi icin kontrol etmesini ister
20) Dovecot, MySQL’e kullanici bilgilerinin dogru olup olmadigini sorar
21) MySQL, Dovecot’a yanit verir
22) Dovecot, Postfix’e kimlik dogrulamasinin sonucunu bildirir
23) Postfix kullaniciya kimliginin dogru oldugunu postayi gonderebilecegini soyler
24) Alici, postayi Postfix’e iletir.
25) Postfix, karsi tarafin MTA’sina postayi iletir (karsi tarafin MX kaydina sahip oldugu varsayilmistir)

Artik sistemin nasil calistigini anladigimiza gore neye ihtiyacimiz oldugunu listelemeye gecebiliriz. Oncelikle posta gondermek isteyen birinin bizi bulabilmesi icin MX kayitlarimiza erisebilmesi gerekiyor. Dolayisiyla bu kayitlari yapilandiracagiz. Ardindan Postfix, Dovecot ve MySQL kurulumunu yapacagiz. MySQL bizim icin alan adlarini, kullanicilarin kimlik bilgilerini ve takma adlarini saklayacak. Dovecot, IMAP ve POP3 sunucu olarak calismasinin yani sira SASL(Simple Authentication and Security Layer) implementasyonu sayesinde Postfix icin kimlik dogrulamasi yapacak. Postfix ise gelen ve giden postalari ilgili yerlere iletme gorevini ustlenecek. Postfix ve Dovecot ile iletisimin duz metin olarak yapilmamasi icin SSL sertifikalari kullanacagiz. Anlatimi Ubuntu 12.04 LTS uzerinde yaptigimi da hatirlatayim.

Host adinin ayarlanmasi
Ben bu rehberde Venus’un bir ayi olarak dusunulen fakat daha sonradan olmadigi anlasilan neith adini kullanacagim. Posta alip gonderecegimiz adres ise .tk’den ucretsiz olarak kayit ettigim konusmalar.tk adresi olacak. Islemleri root olarak gerceklestiriyorum. Ardindan sudo kullanabilen bir kullanici olusturup SSH uzerinden root girisini kapatacagim fakat o baska bir anlatimin konusu.

nano /etc/hosts<br></br>  
127.0.0.1 localhost konusmalar.tk<br></br>  
198.199.112.50 konusmalar.tk neith<br></br>  
echo neith > /etc/hostname<br></br>  
hostname -F /etc/hostname```

Bu asamada hostname ve hostname -f ciktilari sirayla su sekilde donmeli.  

hostname


neith


hostname -f


konusmalar.tk```

DNS kayitlarinin eklenmesi
MX kayitlari iki alandan olusuyor. Priority (oncelik) ve host adi. Ben VPS saglayicinin DNS hizmetini kullandigimdan kontrol paneline gidip oncelige 10, host adina da konusmalar.tk diyecegim bir kayit yaratacagim. Bu anlatimda tek bir posta sunucu yapilandiracagimizdan onceligin ne ise yaradiginin aslinda bir onemi yok ama kisaca aciklamak gerekirse birden fazla posta sunucu kurdugumuzda hangisinin tercih edilmesi gerektigini soylemek icin kullaniyoruz. Ornegin 10 konusmalar.tk ve 20 alt.konusmalar.tk MX kayitlarimiz var. alt ve @ farkli IP adresleri donduren A kayitlarina sahipler. Bize e-posta gondermek isteyen biri MX sorgusu yapiyor ve bu iki kaydi da aliyor. Ilk olarak onceligi yuksek olan (sayi degeri dusuk olan, bu durumda 10) sunucu ile iletisime gecmek istiyor. Eger bu sunucudan bir nedenden oturu cevap alamazsa ikinci siradaki sunucu ile iletisime gecmeye calisiyor. Basitce oncelik alaninin yaptigi is bu. Fakat dedigim gibi tek bir sunucu yapilandiracagimizdan 100 de verilse 1 de verilse bir onemi olmayacaktir. DNS konusundaki ikinci ve son onemli nokta ise MX kaydini tutan hostun bir A kaydina sahip olmasi gerektigi. Bu ornekte ben sunucunun FQDN’i icin (hostname -f ciktisi) konusmalar.tk kullandim karisikliga neden olmamak icin fakat posta.konusmalar.tk ya da oncelik ayarinda anlattigim gibi alt.konusmalar.tk gibi bir FQDN de kullanabilirdim. Eger boyle bir isim kullansaydim konusmalar.tk DNS alaninin (zone) alt ya da posta isimleri icin bir A kaydina (bu adresin IP’si nedir kaydi A kaydi oluyor) cevap vermesi gerekecekti. Eger sunucu adinizi bu sekilde yapilandirdiysaniz ve posta alamiyorsaniz DNS kaydinizi kontrol etmenizde yarar var.

Gerekli paketlerin kurulmasi

sudo apt-get install mysql-server postfix-mysql dovecot-mysql dovecot-lmptd dovecot-imapd dovecot-pop3d

Bu paketler zaten gerekli olan birkac diger paketi de kuracagindan kurulmasi gereken tum paketleri apt-get’e vermemize gerek yok. POP3 destegi vermek istemiyorsak dovecot-pop3d paketini kurmamiza gerek yok. Ayni sey IMAP icin de gecerli. Geri kalanlar anlatimin takip edilmesi icin mutlaka kurulmasi gereken paketleri iceriyor. Belki dovecot-lmptd biraz yabanci gelebilir. LMTP local mail transfer protocol anlamina geliyor. Kavrami aciklamadan once mail queue ne ise yarar ona bakalim. Diyelim postfix’e su iki posta adresine bizim icin bu postayi ilet dedik. Postfix ilk posta adresine gonderimizi iletti fakat ikincisine ilk denemesinde ulasamadi. Iste bu durumda postfix bizim icin daha sonra denemek uzere gonderimizi kuyruga aliyor ve bir sure sonra tekrar iletmeye calisiyor. Yerelde ise bu isi yapmak cekirdek citlemek icin cekic kullanmaya benziyor. Bu yuzden posta iletilebiliyorsa ileten, iletemiyorsa reddeden bir protokol gereksinimi ortaya cikiyor ve adina da LMTP deniyor. Postfix, Dovecot ile LMTP sayesinde iletisim kuruyor.

Kurulum asamasinda MySQL icin root sifresi istenecek. Sonrasinda gelen postfix yapilandirma ekraninda Internet Site secimi yapip, System mail name sordugu yere konusmalar.tk adresini girecegim. Eger alt.konusmalar.tk ya da posta.konusmalar.tk olarak yapilandirsaydim DNS kayitlarimi buraya o degerlerden biri gelecekti.

MySQL yapilandirmasi

Yazinin baslarinda MySQL’in bizim icin kullanici ve alan adi bilgilerini tutacagini soylemistik. Bunun icin bir veritabani ve bu veritabaninda uc adet tablo olusturacagiz. Veritabanina sanalposta, olusturacagimiz uc tabloya ise sirayla, sanalalanadlari, sanalkullanicilar ve sanal_takmaadlar isimlerini verecegim. Bu veritabanini kontrol eden kullanici sanalpostayoneticisi olacak ve sifresi anlatim kolayligi acisindan 12345 olacak. Umarim kendi sunucunuzda boyle bir sifre kullanmiyorsunuzdur.

mysql -u root -p<br></br>  
>> CREATE DATABASE sanalposta;<br></br>
>> GRANT SELECT ON sanalposta.* TO 'sanalpostayoneticisi'@'127.0.0.1' IDENTIFIED BY '12345';<br></br>
>> FLUSH PRIVILEGES;```

Ilk satirda veritabanimizi olusturduk. Ardindan gelen iki satirda ise localhost’tan erisim yapacak ve 12345 sifresiyle kimlik dogrulayacak kullaniciya, sanalposta veritabaninda olusturacagimiz tum tablolarda SELECT islemi yapabilmesi icin izin verdik. Sira geldi sanal_alanadlari tablosunu olusturmaya.

CREATE TABLE sanal_alanadlari (

id int(5) UNSIGNED ZEROFILL NOT NULL auto_increment,

name varchar(64) NOT NULL,

PRIMARY KEY (id)


) ENGINE=InnoDB DEFAULT CHARSET=utf8;```

En son RFC’yi kontrol ettigimde bir alan adi nokta dahil maksimum 64 karakter olabiliyordu. Dolayisiyla name sutununu 64 karaktere sinirladik. int(5) ise sadece gorsellik acisindan onemli oldugundan uzerinde durmaya pek gerek yok. sanal_kullanicilar tablomuzu ise su sekilde olusturuyoruz.

>> CREATE TABLE `sanal_kullanicilar` (<br></br>
`id` int(5) UNSIGNED ZEROFILL NOT NULL auto_increment,<br></br>
`domain_id` int(5) UNSIGNED ZEROFILL NOT NULL,<br></br>
`password` varchar(106) NOT NULL,<br></br>
`email` varchar(100) NOT NULL,<br></br>
PRIMARY KEY (`id`),<br></br>  
UNIQUE KEY `email` (`email`),<br></br>  
FOREIGN KEY (domain_id) REFERENCES sanal_alanadlari(id) ON DELETE CASCADE<br></br>  
) ENGINE=InnoDB DEFAULT CHARSET=utf8;```

Kullanici tablomuzda bir kullanici id’si, bu tabloyu alan adlari tablosuna baglayan domain_id, kullanici sifresi ve e-posta sutunlarini olusturduk. @alanadi.com su asamada maksimum 65 karakter tutabileceginden kullanici adina 35 karakter yer kaliyor. Eger daha uzun kullanici adlari tanimlayacaksaniz email kismindaki varchar degerini degistirebilirsiniz. Son olarak sanal_takmaadlar tablomuzu olusturalim.

CREATE TABLE sanal_takmaadlar (

id int(5) UNSIGNED ZEROFILL NOT NULL autoincrement,

domain_id int(5) UNSIGNED ZEROFILL NOT NULL,

source varchar(100) NOT NULL,

destination varchar(100) NOT NULL,

PRIMARY KEY (id),


FOREIGN KEY (domainid) REFERENCES sanal_alanadlari(id) ON DELETE CASCADE


) ENGINE=InnoDB DEFAULT CHARSET=utf8;```

Bir onceki asamada email alani icin varchar degerini degistirdiyseniz buradaki source ve destination alanlarinda da ayni degisikligi yapmak isteyeceksiniz. Gelelim olusturdugumuz bu tablolara veri eklemeye.

>> INSERT INTO `sanalposta`.`sanal_alanadlari`<br></br>
(`id` ,`name`)<br></br>
VALUES<br></br>  
('1', 'konusmalar.tk');```

>> INSERT INTO `sanalposta`.`sanal_kullanicilar`  
 (`id`, `domain_id`, `password` , `email`)  
 VALUES  
 (‘1′, ‘1’, ENCRYPT(‘sifre1′, CONCAT(‘$6$’, SUBSTRING(SHA(RAND()), -16))), ‘kullanici1@konusmalar.tk’),  
 (‘2′, ‘1’, ENCRYPT(‘sifre2′, CONCAT(‘$6$’, SUBSTRING(SHA(RAND()), -16))), ‘kullanici2@konusmalar.tk’);

Yukaridaki istekte rand() ile 0-1 arasinda bir rastgele sayi urettik. Ardindan sha() ile bunu hashledik ve substring(hash, -16) ile bu hash degerinin son 16 hanesini aldik. concat(‘$6$’, hash’in son 16 hanesi) ile elimizdeki degerin basina $6$ ekledik ki bu da crypt icin SHA512 anlamina gelir. Ardindan ENCRYPT ile sifremizi ve az once olusturdugumuz tuzumuzu birlestirip sifre alanimiza bu degeri verdik. /etc/shadow dosyanizdaki root girdisine bakarsaniz benzer bir yapi goreceksiniz.

INSERT INTO sanalposta.sanal_takmaadlar

(id, domain_id, source, destination)

VALUES


('1', '1', 'root@konusmalar.tk', 'kullanici1@konusmalar.tk');```

root posta hesabi icin de bir yonlendirme belirlemis olduk boylece takmaadlar tablomuzda. Simdi bu degerleri kontrol edebiliriz.

>> USE sanalposta;<br></br>
>> SHOW TABLES;```

+——————–+  
 | Tables_in_anlatim |  
 +——————–+  
 | sanal_alanadlari |  
 | sanal_kullanicilar |  
 | sanal_takmaadlar |  
 +——————–+  
 3 rows in set (0.00 sec)

>> SELECT * FROM sanal_alanadlari;

+——-+—————+  
 | id | name |  
 +——-+—————+  
 | 00001 | konusmalar.tk |  
 +——-+—————+  
 1 row in set (0.00 sec)

>> SELECT * FROM sanal_kullanicilar;

+——-+———–+———————————————————–+  
 | id | domain_id | password | email |  
 +——-+———–+——————-+—————————————+  
 | 00001 | 00001 | $6$bf198693267470de$YukkyGzAs/ | kullanici1@konusmalar.tk |  
 | 00002 | 00001 | $6$da2ea5ba6e70ac34$pRLBLvIRtJ | kullanici2@konusmalar.tk |  
 +——-+———–+———————————————————–+  
 2 rows in set (0.00 sec)

password alani burada gosterdigimden cok daha uzun olacak, duzgun gozukmesi icin bir kismini kestim. $ isaretlerine dikkat ederseniz concat ve encrypt islemlerinin sonucunu gorebilirsiniz.

`>> SELECT * FROM sanal_takmaadlar;`

+——-+———–+——————–+————————–+  
 | id | domain_id | source | destination |  
 +——-+———–+——————–+————————–+  
 | 00001 | 00001 | root@konusmalar.tk | kullanici1@konusmalar.tk |  
 +——-+———–+——————–+————————–+  
 1 row in set (0.00 sec)

Yukaridakilere benzer ciktilar goruyorsaniz her sey yolunda demektir.

**Postfix Yapilandirmasi**

/etc/postfix/main.cf dosyasinin yorumlardan arindirilmis nihai hali su sekilde olacak. Bu ayarlari dosyayi gosterdikten sonra aciklayacagim.

smtpdbanner = $myhostname ESMTP $mailname (Ubuntu)


biff = no


appenddotmydomain = no


readmedirectory = no


smtpdtlscertfile=/etc/ssl/certs/dovecot.pem


smtpdtlskeyfile=/etc/ssl/private/dovecot.pem


smtpdtlssecuritylevel=may


smtpdtlsauthonly=yes


smtpdsasltype = dovecot


smtpdsaslpath = private/auth


smtpdsaslauthenable = yes


smtpdrecipientrestrictions = permitsaslauthenticated, permitmynetworks, rejectunauthdestination


myhostname = konusmalar.tk


aliasmaps = hash:/etc/aliases


aliasdatabase = hash:/etc/aliases


myorigin = /etc/mailname


mydestination = localhost


relayhost =


mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 198.199.112.50


mailboxsizelimit = 0


recipientdelimiter = +


inetinterfaces = all


virtualtransport = lmtp:unix:private/dovecot-lmtp


virtualmailboxdomains = mysql:/etc/postfix/mysql-virtual-mailbox-domains.cf


virtualmailboxmaps = mysql:/etc/postfix/mysql-virtual-mailbox-maps.cf


virtualaliasmaps = mysql:/etc/postfix/mysql-virtual-alias-maps.cf```

Postfix, bence, belgelendirmesi en iyi olan ozgur yazilim projelerinden biri. main.cf altindaki her ayarin aciklamasini da http://www.postfix.org/postconf.5.html adresinden bulabilirsiniz. Ustte paylastigim 25-30 tanesinin kisa aciklamalari soyle.

smtpdbanner = $myhostname ESMTP $mailname (Ubuntu)

Herhangi bir bilgisayardan asagidaki komutu verirseniz

telnet konusmalar.tk 587

size suna benzer bir cikti donecektir.

Trying 198.199.112.50...<br></br>  
Connected to konusmalar.tk.<br></br>  
Escape character is '^]'.<br></br>  
220 konusmalar.tk ESMTP Postfix (Ubuntu)```

iste buradaki 220 konusmalar.tk ESMTP Postfix (Ubuntu) satirini smtpd_banner ayari ile kontrol ediyoruz. smtpd_banner’in $myhostname ile baslamasi zorunlu, fakat bunun disinda istediginiz degisikligi yapabilirsiniz. Yani soyle bir goruntu elde etmek mumkun. Fakat bu kisimda belki Ubuntu’yu silmek disinda bir degisiklik yapmanizi pek onermem. Zannetmiyorum ama bu bilgileri e-posta gondermek icin kullanmaya calisan enteresan(!) uygulamalar olabilir.

Trying 198.199.112.50...


Connected to konusmalar.tk.


Escape character is '^]'.


220 konusmalar.tk Linux cok guzel, gelsenize!```

Eger 1980’de yasamiyorsaniz biff ayarini no yapmanizda bir sakinca yok. Kullanicilar posta kontrol etmek icin lokal hesaplariyla sisteme giris yapmayacaklarindan -hatta bir lokal hesaplari olmayacagindan- biff kullanmak istemiyoruz.

appenddotmydomain ayari lokal posta icin gitmesi gereken adresin sonuna alanadinin koyulup koyulmayacagini soyluyor. yani root a gitsin bu posta dediginizde sonuna @konusmalar.tk koymak isteyip istemediginiz soyluyorsunuz. Hayir diye devam ediyorum.

readme_directory derleme, calistirma islemlerini anlatan dosyalarin nerede tutulacagini soyluyor ki hic ihtiyacimiz yok.

smtpdtlscertfile=/etc/ssl/certs/dovecot.pem
smtpdtlskeyfile=/etc/ssl/private/dovecot.pem
smtpdtlssecuritylevel=may
smtpdtlsauthonly=yes

Onemli kisimlardan bir tanesi burasi. Iletisimin duz metin olarak yapilmamasi icin sertifika kullanacagimizi soylemistik. Postfix icin sertifika ayarini burada yapiyoruz. Dovecot kurulurken bizim icin sertifika olusturuyor. Dolayisiyla eger bir CA tarafindan imzalanmis sertifika kullanmiyorsak Dovecot’in bizim icin urettiklerini kullanabiliriz. smtpdtlscertfile ve smtpdtlskeyfile sertifikanin ve ozel anahtarin nerede tutuldugunu belirtiyor. smtpdtlssecuritylevel ile iletisimin mumkunse sertifika ile sifrelenmesini istiyoruz. Burada encrypt ile zorunlu tutabilirdik fakat SquirrelMail kurulumu yaptigimizda encrypt biraz basimizi agritabilir. Eger securitylevel icin may dersek smtpdtlsauth_only ile giris yapilmasi icin sertifika kullanilmasini zorunlu hale getirebiliriz ki istedigimiz de zaten buydu.

Bir sonraki onemli kisim SASL ayarlarini yaptigimiz kisim. Yazinin basinda Postfix’in kimlik dogrulamasi yaparken Dovecot’a benim icin su kullaniciyi dogrular misin diyecegini ve bu islemi SASL ile yapacagini soylemistik.

smtpdsaslauthenable = yes
smtpdsasltype = dovecot
smtpdsasl_path = private/auth

authenable ile Postfix’e SASL kullanacagimizi soyledik. SASL icin konusacagi daemon’i da smtpdsasl_type’a dovecot degerini vererek gosterdik. Dovecot ile konusurken kullanacagi soketin yerini path degiskeniyle verdik. Buraya Dovecot’i yapilandirirken bir daha deginecegiz.

smtpdrecipientrestrictions = permitsaslauthenticated, permitmynetworks, rejectunauth_destination

Yukaridaki ayar hangi kullanicilarin posta gonderebilecegini yapilandirmak icin gereken bir ayar. Icinde reject ya da defer tipinden en az bir tane deger olmasi gerekiyor. permitsaslauthenticated eger bir kullanici SASL kullarak giris yapmissa posta gondermesine izin verilecegi anlamina geliyor. permitmynetworks mynetworks’te belirtilen agdaki istemcilere posta gonderme izini verildigini soyluyor. rejectunauth_destination ile eger posta Postfix’in bildigi bir alana gelmiyor ise reddetmesi gerektigini anlatiyoruz.

myhostname = konusmalar.tk
aliasmaps = hash:/etc/aliases
aliasdatabase = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = localhost
relayhost =
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 198.199.112.50
mailboxsizelimit = 0
recipientdelimiter = +
inetinterfaces = all

Yukaridaki bolumde myhostname, mydestination ve mynetworks parametreleri ilgi alanimiza giriyor. myhostname’i MX kaydindaki gibi ayarliyoruz. mydestination’da sadece localhost’u birakiyoruz. mynetworks’e ise kendi IP adresimizi ekliyoruz.

Gelelim Postfix’in MySQL ile nasil konusacagina.

virtualtransport = lmtp:unix:private/dovecot-lmtp
virtualmailboxdomains = mysql:/etc/postfix/mysql-virtual-mailbox-domains.cf
virtualmailboxmaps = mysql:/etc/postfix/mysql-virtual-mailbox-maps.cf
virtualalias_maps = mysql:/etc/postfix/mysql-virtual-alias-maps.cf

virtual_transport degeri bize Postfix’in postalari MDA(Dovecot) ile nasil degis tokus edecegini anlatiyor. Bunun icin daha once de bahsettigimiz gibi LMTP protokolunu kullanacagiz.

virtualmailboxdomains kisminda Postfix’in kontrol edecegi alan adlarini MySQL’den nasil alacagini anlatan dosyayi, virtualmailboxmaps’te ise eslesen alanadlari icin kullanicilari nasil bulacagini gosteren dosyayi belirtiyoruz. virtualaliasmaps ise MySQL’de son olarak ekledigimiz sanal_takmaadlar tablosundaki sorgularin nasil yapilacagini anlatiyor. Boylelikle Postfix yapilandirmasinda son asamaya girmis oluyoruz. O da az once verdigimiz dosya yollarindaki dosyalari olusturmak.

/etc/postfix/mysql-virtual-mailbox-domains.cf dosyasi

user = sanalpostayoneticisi<br></br>  
password = 12345<br></br>  
hosts = 127.0.0.1<br></br>  
dbname = sanalposta<br></br>  
query = SELECT 1 FROM sanal_alanadlari WHERE name='%s'```

/etc/postfix/mysql-virtual-mailbox-maps.cf dosyasi

user = sanalpostayoneticisi


password = 12345


hosts = 127.0.0.1


dbname = sanalposta


query = SELECT 1 FROM sanal_kullanicilar WHERE email='%s'```

/etc/postfix/mysql-virtual-alias-maps.cf dosyasi

user = sanalpostayoneticisi<br></br>  
password = 12345<br></br>  
hosts = 127.0.0.1<br></br>  
dbname = sanalposta<br></br>  
query = SELECT destination FROM sanal_takmaadlar WHERE source='%s'```

Simdi Postfix’i yeniden baslatalim ve bakalim MySQL ile konusabiliyor mu test edelim.

service postfix restart


postmap -q konusmalar.tk mysql:/etc/postfix/mysql-virtual-mailbox-domains.cf


postmap -q kullanici1@konusmalar.tk mysql:/etc/postfix/mysql-virtual-mailbox-maps.cf


postmap -q root@konusmalar.tk mysql:/etc/postfix/mysql-virtual-alias-maps.cf```

Ilk iki sorgu icin 1 ciktisini, son sorgu icin ise hangi posta hesabina yonlendirdiysek onun ciktisini gormeliyiz. Ciktilar dedigim sekildeyse bir sorun yok demektir.

Dovecot yapilandirmasi

Dovecot 2.x surumlerine kadar tek bir yapilandirma dosyasina sahipti fakat yapilandirmanin daha kolay(!) olacagi dusunulerek 2.x surumleri itibariyle bu tek yapilandirma dosyasi birden cok dosyaya dagitildi. Bana sorarsaniz birden cok dosya ile yapilandirmasi daha zor. Fakat gelecege yatirim acisindan bu halini ogrenmek amaciyla birden cok dosya ile yapilandirma yapacagiz. Islem bittiginde doveconf -n ile aslinda bunca isin tek bir dosya ile ne kadar kolay yapilabilecegini gorecegiz.

Dovecot’un bizim icin yapacagi isler sunlardi. MySQL ile konusup kullanicilarin kimliklerini kontrol edecek Postfix icin. Postfix ile LMTP uzerinden konusup kullanicilarin postalarini dosya sisteminde ilgili dizine gonderecek. IMAP ya da POP3 sunucu olarak gorev yapip SSL destegi sunacak.

Ise /etc/dovecot/dovecot.conf ile baslayacagiz. Dosya ayni squid yapilandirma dosyasi gibi inanilmaz sayida yorum iceriyor. Yorumlari kaldirdiktan sonra elimizde kalanlar ise sunlar.

!include_try /usr/share/dovecot/protocols.d/*.protocol<br></br>
protocols = imap lmtp<br></br>  
dict {<br></br>  
#quota = mysql:/etc/dovecot/dovecot-dict-sql.conf.ext<br></br>
#expire = sqlite:/etc/dovecot/dovecot-dict-sql.conf.ext<br></br>
}<br></br>
!include conf.d/*.conf<br></br>
!include_try local.conf```

Bu dosyaya bizim ekledigimiz aslinda su satirlar.

!include_try /usr/share/dovecot/protocols.d/*.protocol  
 protocols = imap pop3 lmtp

POP3 ya da IMAP istemiyorsak buradan kaldirabiliriz. Siradaki dosya /etc/dovecot/conf.d/10-mail.conf dosyasi. Yine yorumlardan sonra icerigi su sekilde.

maillocation = maildir:/var/mail/vhosts/%d/%n


mailprivileged_group = mail```

mail_location’da postalarin tutulmasini istedigimiz dizini veriyoruz. %d alanadini %n ise kullanici adini ifade ediyor. Bu dosyayla da isimiz bitti.

Simdi gerekli dizini yaratalim.

mkdir -p /var/mail/vohsts/konusmalar.tk

Simdi de Dovecot’un dosya sisteminde posta saklamak icin kullanacagi kullanici hesabini olusturalim.

groupadd -g 2000 vmail<br></br>  
useradd -g vmail -u 2000 vmail -d /var/mail<br></br>  
chown -R vmail:vmail /var/mail```

/etc/dovecot/conf.d/10-auth.conf dosyasina gelip kimlik kanitlama ayarlarini yapalim. Yorumlanmis satirlardan sonra kalan satirlar soyle. !include auth-system.conf.ext satirinin basina # koyalim. Sisteme giris yapmis kullanici diye bir sey olmayacagindan ayarina da gerek yok.

disableplaintextauth = yes


auth_mechanisms = plain login


!include auth-sql.conf.ex``` t

auth-sql.conf.ext dosyasi ile MySQL ile nasil konusacagini anlatacagiz.

/etc/dovecot/conf.d/auth-sql.conf.ext

passdb {<br></br>  
driver = sql<br></br>  
args = /etc/dovecot/dovecot-sql.conf.ext<br></br>  
}<br></br>
userdb {<br></br>  
driver = static<br></br>  
args = uid=vmail gid=vmail home=/var/mail/vhosts/%d/%n<br></br>  
}```

Yukaridaki dosyada belirttigimiz dovecot-sql.conf.ext dosyasinin icerigi ise soyle olacak yorumlardan sonra.

driver = mysql


connect = host=127.0.0.1 dbname=sanalposta user=sanalpostayoneticisi password=12345


defaultpassscheme = SHA512-CRYPT


passwordquery = SELECT email as user, password FROM sanalkullanicilar WHERE email='%u';```

Dizin sahipligini duzeltelim.

chown -R vmail:dovecot /etc/dovecot<br></br>  
chmod 750 /etc/dovecot```

/etc/dovecot/conf.d/10-master.conf dosyasinda soket ayari su sekilde yapiliyor. SSL kullanmasini istedigim icin imap-login ve pop-login’in port degerini 0 ile degistirdim. service-lmtp ve smtp-auth icin postfix’e gosterdigim ayarlari yaptim. Dosyadaki kimi yorumlari eklemelerin nereye yapilacagini gostermek icin birakiyorum.

service imap-login {


inetlistener imap {


port = 0


}

inetlistener imaps {

port = 993

ssl = yes

}```

Number of connections to handle before starting a new process. Typically

# the only useful values are 0 (unlimited) or 1. 1 is more secure, but 0
# is faster.
#service_count = 1

Number of processes to always keep waiting for more connections.

#processminavail = 0

If you set service_count=0, you probably need to grow this.

#vsz_limit = 64M
}

service pop3-login {
inetlistener pop3 {
port = 0
}
inetlistener pop3s {
#port = 995
#ssl = yes
}
}

service lmtp {
unix_listener /var/spool/postfix/private/dovecot-lmtp {
mode = 0600
user = postfix
group = postfix
}

Create inet listener only if you can’t use the above UNIX socket

#inet_listener lmtp {
# Avoid making LMTP visible for the entire internet
#address =
#port =
#}
}

service imap {
# Most of the memory goes to mmap()ing files. You may need to increase this
# limit if you have huge mailboxes.
#vsz_limit = 256M

Max. number of IMAP processes (connections)

#process_limit = 1024
}

service pop3 {
# Max. number of POP3 processes (connections)
#process_limit = 1024
}

service auth {
# authsocketpath points to this userdb socket by default. It’s typically
# used by dovecot-lda, doveadm, possibly imap process, etc. Its default
# permissions make it readable only by root, but you may need to relax these
# permissions. Users that have access to this socket are able to get a list
# of all usernames and get results of everyone’s userdb lookups.

unix_listener /var/spool/postfix/private/auth {
mode = 0666
user = postfix
group = postfix
}

unix_listener auth-userdb {
mode = 0600
user = vmail
#group = vmail
}

Postfix smtp-auth

#unix_listener /var/spool/postfix/private/auth {
# mode = 0666
#}

Auth process is run as this user.

user = dovecot
}

service auth-worker {
# Auth worker process is run as root by default, so that it can access
# /etc/shadow. If this isn’t necessary, the user should be changed to
# $defaultinternaluser.
user = vmail
}

service dict {
# If dict proxy is used, mail processes should have access to its socket.
# For example: mode=0660, group=vmail and global mailaccessgroups=vmail
unix_listener dict {
#mode = 0600
#user =
#group =
}
}

Siradaki dosya /etc/dovecot/conf.d/10-ssl.conf dosyasi. Yorumlardan sonra kalan satirlar su sekilde. Ayarlar zaten kendini aciklar nitelikte.

ssl = required<br></br>  
ssl_cert = ssl_key = ```

Bu asama ile posta sunucu yapilandirmamizi tamamladik. Dovecot ve Postfix servislerini yeniden baslatalim.

service postfix restart


start dovecot```

Thunderbird ile ornek olarak olusturdugumuz kullanicilardan birini yapilandirabilirsiniz. Yeni kullanicilar ya da alanadlari eklemek icin MySQL komut satirina dusup ornek kullanicilari ekledigimiz sekilde sorgulari ya da istekleri tekrar calistirmaniz gerekiyor. Tabii bu arada hangi alanadinin hangi id ile tutuldugu gibi detaylar gozden kacirilmamali. Catchall diye tabir edilen ve bir kullanici adiyla eslesmeyen tum postalari yakalamak icin sanal_takmaadlari tablosuna source icin @alanadi.com adresini verebilirsiniz.

Squirrelmail kurulumu ile rehberi tamamlamadan once yapmak isteyebileceginiz bir iki sey uzerinde durayim. Submission portunu(587) acmak icin /etc/postfix/master.cf dosyasini duzenlemelisiniz. Benim yapilandirmamda ilgili bolum soyle gorunuyor. Farkettiginiz uzere bu dosyada da main.cf dosyasinda oldugu gibi smtpdsaslauthenable ve smptdclient_restrictions gibi secenekleri kullanabiliyoruz.

submission inet n - - - - smtpd<br></br>  
-o syslog_name=postfix/submission<br></br>
-o smtpd_sasl_auth_enable=yes<br></br>
-o smtpd_client_restrictions=permit_sasl_authenticated,permit_mynetworks,reject```

Servislerin calisip calismadigi, calisiyorlarsa hangi portlari dinlediklerini gormek icin ise benim kullandigim komut su. IPv6 henuz ilginizi cekmiyorsa buyuk hata yapiyorsunuz fakat t’nin yanina 4 ekleyebilirsiniz sadece IPv4 icin. Ilk uc kolonu almazsak cikti suna benzeyecektir. Ben sadece IMAPs sundugum icin 993, SMTP icin ise 25 ve 587 calistiriyorum. Siz bu ciktida SSH ve calistiriyorsaniz diger daemon’lari da goreceksiniz.

`netstat -plnt4`

Active Internet connections (only servers)  
 Local Address Foreign Address State PID/Program name  
 127.0.0.1:3306 0.0.0.0:* LISTEN 22790/mysqld  
 0.0.0.0:587 0.0.0.0:* LISTEN 24543/master  
 0.0.0.0:25 0.0.0.0:* LISTEN 24543/master  
 0.0.0.0:993 0.0.0.0:* LISTEN 22920/dovecot

**Squirrelmail yapilandirmasi**

Ilk olarak gerekli paketi kuruyoruz.

`apt-get install squirrelmail`

Squirrelmail bir suru bagimliligiyla birlikte kurulacaktir. Ardindan su komutu veriyoruz.

`squirrelmail-configure`

SquirrelMail Configuration : Read: config.php (1.4.0)  
 ———————————————————  
 Main Menu —  
 1. Organization Preferences  
 2. Server Settings  
 3. Folder Defaults  
 4. General Options  
 5. Themes  
 6. Address Books  
 7. Message of the Day (MOTD)  
 8. Plugins  
 9. Database  
 10. Languages

D. Set pre-defined settings for specific IMAP servers

C Turn color on  
 S Save data  
 Q Quit

Command >>

gibi bir ekran bizi karsilayacaktir. Onemli bolum 2. Server Settings dedigi bolum. R ile bir onceki menuye donuluyor. S ile yapilan ayarlar kaydediliyor. Q ise ile yapilandirmadan cikiliyor. 2’ye basrak ayarlara gecelim. Bu menude A ve B tuslariyla IMAP ve SMTP ayarlarinizi yapabilirsiniz.

Son islem ise Apache’ye squirrelmail yapilandirmasini tanitmak. Hazir gelen yapilandirmayi kopyalayalim.

`cp /usr/share/squirrelmail/config /etc/apache2/sites-available`

Sites-available altina aldigimiz dosyada istedigimiz degisiklikleri yapabiliriz. Ornegin alias direktifini duzenleyelim.

Alias /posta /usr/share/squirrelmail

Degisikliklerimizi de yaptiktan sonra Apache’yi yeniden yukleyelim.

`service apache2 reload`

Artik kullanicilar hesaplarina http://konusmalar.tk/posta adresine eriserek giris yapabileceklerdir.

[![Screenshot from 2013-05-20 14:09:59](https://blog.cagriemer.net/wp-content/uploads/2013/05/Screenshot-from-2013-05-20-140959-300x229.png)](https://blog.cagriemer.net/wp-content/uploads/2013/05/Screenshot-from-2013-05-20-140959.png)

Ekler:  
 doveconf -n ile tek bir dosya olsaydi yapilandirmanin nasil olacagini gorecegiz demistim. Su sekilde gozukuyor.

2.0.19: /etc/dovecot/dovecot.conf

OS: Linux 3.2.0-23-virtual x86_64 Ubuntu 12.04.2 LTS ext4

authmechanisms = plain login


maillocation = maildir:/var/mail/vhosts/%d/%n


mailprivilegedgroup = mail


passdb {


args = /etc/dovecot/dovecot-sql.conf.ext


driver = sql


}

protocols = imap lmtp


service auth-worker {


user = vmail


}

service auth {


unixlistener /var/spool/postfix/private/auth {


group = postfix


mode = 0666


user = postfix


}

unixlistener auth-userdb {


mode = 0600


user = vmail


}

user = dovecot


}

service imap-login {


inetlistener imap {


port = 0


}

}

service lmtp {


unixlistener /var/spool/postfix/private/dovecot-lmtp {


group = postfix


mode = 0600


user = postfix


}

}

service pop3-login {


inetlistener pop3 {


port = 0


}

}

ssl = required


sslcert = ssl_key = userdb {


args = uid=vmail gid=vmail home=/var/mail/vhosts/%d/%n


driver = static


}

```

Diyagramin kaynagi ise surada: https://blog.cagriemer.net/wp-content/uploads/2013/05/posta.dia

Kabaca anlatmak gerekirse betigin yaptigi isler soyle; Uygulama icin gereken bagimliliklari kontrol ettikten sonra Google Code’dan kaynak kodu indirip derliyor. Derlemenin ardindan google-authenticator ikiligini calistiriyor ve ev dizinine bir seferlik acil durum sifrelerinin ve gizli anahtarin tutuldugu bir dosya olusturuyor.

Ardindan libqrencode3 sayesinde terminalde, telefonunuzdaki Google Authenticator uygulamasini yapilandirmak icin kullanabileceginiz bir kare kod goruntuluyor. Yine bu asamada bir de cevrimici olarak goruntuleyebilecegiz kare kod baglantisi basiyor. Asagidaki ekran goruntusunun kare kod uzerindeki ilk satirina dikkatlice bakarsaniz gorebilirsiniz.

Kare kod’un kalitesi icin ozur dilerim, hata onarmada oldukca basarili oldugu icin iyice bulaniklastirmam gerekti. Bu islem de tamamlandiktan sonra /etc/pam.d/sshd dosyasinin basina su satiri ekliyor.

auth required pam_google_authenticator.so

Son olarak /etc/ssh/sshd_config dosyasinda su asagidaki degisikligi yapip SSH servisini yeniden baslatiyor.

ChallengeResponseAuthentication yes

Bu islemden itibaren makineye her SSH erisimi yapmaya calistiginizda once sizden Verification Code dedigi bir seferlik sifreyi girmenizi istiyor. Eger bu sifre dogru ise kullanici sifrenizi girip oturum acabiliyorsunuz. Eger oturum acmak icin sifre yerine genel/ozel anahtar ciftinizi kullaniyorsaniz herhangi bir etkisi olmuyor. Kodun icerisinde de belirttigim uzere eger giris yapamiyorsaniz, sunucunuzun ve Google Authenticator uygulamanizin saatlerinin dogru olduguna emin olmalisiniz.

Betik, yazilabilecek en duzgunu en hizlisi degildir muhtemelen fakat benim bilgim bu kadarini yazmaya yetiyor. Dolayisiyla soyle olursa daha iyi olur ya da burada sunu yapman lazim aslinda gibi onerilerinizi iletirseniz memnun olurum.

[1] http://yakindanegitim.org
[2] http://blog.yakindanegitim.org/2013/05/ara-donem-degerlendirme-sonuclar.html
[3] https://github.com/YakindanEgitim
[4] https://code.google.com/p/google-authenticator/source/browse/#git%2Flibpam
[5] https://github.com/cagriemer/betikler/blob/master/totpssh.sh

Upstart betiklerinin nasıl yazılacağına geçmeden önce init ne iş yapar değinmek doğru olacaktır. Çekirdek tarafından başlatılan init, sistemdeki bütün süreçlerin başlatılması işlemini yerine getirir. init tarafından yönetilen tüm süreçler “iş” olarak tanımlanır ve /etc/init dizini altındaki dosyalarda tutulur. Ubuntudaki init(8)* olay-tabanlı bir artsüreçtir. Bu da sistem durumundaki herhangi bir değişiklikte işlerin ya da süreçlerin otomatik olarak başlatılıp durdurulabilmesini sağlar. Bağımlılık-tabanlı init artsüreçlerinden farkları bu işlemleri yapmak için başka işlerin başlamasını beklememek ve bağımlılık listelerini bir döngüyle taramamaktır denebilir.

Sistemde init ile ilgili kullanabilecek üç dizinden söz edilebilir. Bunlar şöyledir,

/etc/init : upstart yapılandırma dosyalarının tutulduğu dizindir
/etc/init.d : geleneksel init betiklerinin ve geriye dönük uyumluluğa sahip upstart yapılandırmalarının bulunduğu dizindir.
/etc/default : upstart ve geleneksel init’in çalışma şekillerini kontrol eden dosyaların tutulduğu dizindir

Sayılan dizinlerde tutulan dosyalar özetle, bir süreci kontrol etmek için yapılması gerekli olan işlemleri barındırırlar. Upstart sayesinde örneğin SSH sunucuyu şu komutlarla yönetmek mümkündür.

start ssh : süreci başlatır
stop ssh : süreci sonlandırır
reload ssh : sürecin yeni yapılandırma dosyalarını kullanmasını sağlar
restart ssh : sürece SIGHUP sinyali göndererek yeniden başlatılmasını sağlar
status ssh : sürecinin çalışıp çalışmadığı bilgisini döndürür

Bütün bu yukarıda sayılan iş tanımları Upstart sayesinde mümkündür. /etc/init/ssh dosyası içerisinde ssh artsürecini başlatan exec kısımı bulunur. Bir uygulamanın varolan init dosyasını incelemektense, sıfırdan bir init dosyası örneği oluşturmak konseptin anlaşılması adına daha iyi olacaktır. Ubuntu’da bu işi sıfırdan yapmak için init(5)** man sayfası çok iyi bir kaynaktır. Bu dosya oluşturulacak betiklerin /etc/init dizininde .conf ya da .override uzantısı ile oluşturulması gerektiğini söyler. .conf uygulamanın ya da sürecin temel yapılandırması iken .override temel yapılandırmaki tanımları ezen kuralları içeren dosyadır. Dolayısıyla bir süreç için yalnızca bir .conf dosyası ya da hem .conf hem de .override dosyası kullanılabilecekken, yalnızca .override dosyasının kullanılması mümkün değildir. Yapılandırma dosyaları çalıştırma izinleri olmayan düz metin dosyaları olmalıdır.

Temel Kısımlar

exec – script
Bütün iş dosyaları exec ya da script kısımı içermek zorundadır. Fakat ikisini birden barındıramazlar.[1] Bu iki kısımın farkı, exec ile bir komut verilebilecekken script ile komutlardan oluşan bir betik yazılabilmesidir. Bir de eğer script kullanıldıysa end script şeklinde sonlandırmak gerekmektedir.

pre-start – post-start – pre-stop – post-stop
Çalıştırmak istenilen işi başlatmadan ya da durdurmadan önce ve başlattıktan ya da durduktan sonra çalıştırılacak komutlar da pre/post-start/stop script kısımları altında tanımlanmaktadır. Yine bu kısımlar end script ile sonlandırılırlar.

start on – stop on
Yapılandırma dosyasına eklenecek bu satırlar hangi olay sonucu sürecin başlatılacağını ya da durdurulacağını belirtir. Bu kısımda tanımlanabilecek ilk olay startup’tır. Bilgisayar ilk başladığında dosya sistemi sadece okunabilir haldeyken ve ağ bağlantıları yokkenki durumu belirtir. Belirli işleri belirli çalıştma düzeylerinde (runlevel) başlatmak için kullanılabilecek seçenek runlevel’dır. Bahsedilmeye değer kullanılabilecek son iki seçenek ise started ve stopped seçenekleridir. Bu seçenekler kontrol edilmek istenen süreçlerin hangi süreçler başlatıldıktan ya da durdurulduktan sonra yönetileceğini anlatır. Ubuntu için tanımlı bütün olayların listesine upstart wikisinde bulunan “cookbok” isimli belgenin ilgili kısımından ulaşılabilir.[2]

console
Bu yazıda değinilecek son önemli kısım console kısımıdır. Console kısımı sayesinde bir sürecin girdi ya da çıktılarının nereden alınıp nereye gönderileceği kontrol edilebilir. Kullanılabilecek dört seçenek logged, output, owner ve none seçenekleridir. none için /dev/null kullanılır ve süreçle etkileşime girilmez. output seçeneği /dev/console’u kullanır ve işleri uçbirim üzerinden yürütür. owner seçeneği output’a ek olarak uçbirimin sahibi kullanıcıya süreçlere CTRL+C gibi belirli sinyaller gönderebilme olanağı tanır. Öntanımlı olarak gelen logged ise çıktıların log tutucaya gönderileceğini belirtir.

Bu yazıda bahsedilen kısımlar dışında kullanılabilecek kısımların tam listesine upstart wiki’den[3] erişilebilir. Ayrıca detaylı bir başucu kaynağı upstart cookbook[4] da sık kullanılanlar arasında yerini almalıdır.

Örnek Uygulama

Şimdi yukarıda tanımlanan temel işlemleri kullanan iki basit yapılandırma dosyası oluşturulacaktır.

sudo nano /etc/init/surecbir.conf komutu ile dosya açılarak içerisine şunlar yazılır.

pre-start script<br></br>  
    mkdir /home/kullanıcı_adı/Masaüstü/dizinim<br></br>
end script<br></br>  
script<br></br>  
    echo "Çalışıyor!" > /home/kullanıcı_adı/Masaüstü/dizinim/calisma.log<br></br>
end script<br></br>  
post-start script<br></br>  
    sleep 5<br></br>
end script<br></br>  
post-stop script<br></br>  
    chown -R kullanıcı_adı:kullanıcı_adı /home/kullanıcı_adı/Masaüstü/dizinim<br></br>
end script```

CTRL+X ile dosya kaydedilir.

sudo nano /etc/init/sureciki.conf komutu ile yeni bir dosya açılarak içerisine şunlar yazılır.

start on stopped surecbir


script


echo "Bu iş ilk işin sonlanması ile başladı." >> /home/kullanici_adi/Masaüstü/dizinim/calisma.log

end script```

CTRL+X ile dosya kaydedilir.

Şu anda iki adet süreci tanımlamış bulunmaktasınız. Bunlar surecbir ve sureciki olarak adlandırıldılar. İkinci süreç ilk sürece bağımlı olduğundan onun elle başlatılmasına gerek yoktur. İlk süreci şu komut ile başlatabilirsiniz.

sudo service surecbir start

Bu komut sonrasinda ilk olarak masaüstünde bir dizinim klasörü oluşturulacaktır. Tanımı pre-start altında yapılmıştır. Ardından dizinim içerisinde calisma.log isimli bir dosya oluşturulacak ve içeriğine “Çalışıyor!” yazılacaktır. Bu işlemin de tanımı script altında verilmiştir. Ardından surecbir isimli süreç beş saniye boyunca bir şey yapmadan bekleyecek ve sonlanacaktır. Bu kısım da post-start altında tanımlı bulunmaktadır. Sürecin sonlanması ile masaüstünde bulunan dizinim klasörünün sahipliği içindeki dosyalar ile birlikte kullanıcınıza verilecektir. Bu işlem de post-stop kısımında tanımlanmıştır.

surecbir sürecinin sonlanmasının ardından sureciki sureci baslayacak ve calisma.log dosyasina “Bu iş ilk işin sonlanması ile başladı.” satırını ekleyecektir. sureciki’nin ne zaman başlayacağını tanımlayan kısım start on kısımıdır.

Kullanıcı Süreçleri

Upstart’ın güncel sürümleri, sistem kullanıcılarının kendi işlerini tanımlamalarına da izin vermektedir. Böylelikle yönetici hakları gerekmeksizin, kullanıcılar kendi süreçlerini yaratabilmekte ve çalıştırabilmektedirler. Sistem için kullanılabilecek stanza’ların(bu yazıda kısım olarak adlandırıldılar) tümü henüz kullanıcı tanımlı işler için tanımlanmamış olmasına rağmen, temel işleri görebilecek şekilde kullanıcı tanımlı Upstart yapılandırmaları oluşturulabilmektedir. Bunun için yapılması gereken ev dizininde .init isimli bir dizin oluşturup iş tanımlarını tutan .conf dosyalarını bu dizin altına koymaktır. Bir de Ubuntu Upstart öntanımlı olarak kullanıcı işlerinin çalıştırılmasına izin vermediği için /etc/dbus-1/system.d/Upstart.conf dosyası bir yedeği alınarak, Upstart’ın Launchpad sayfasından indirilen yapılandırma ile değiştirilmelidir. Ardından start-stop gibi komutlarla kullanıcı tanımlı işler çalıştırılabilir.

.init dizinini oluşturmak ve Upstart.conf dosyasını değiştirmek için izlenmesi gereken adımlar kısaca şöyledir. Eğer bu yapılandırma değiştirilmek istenirse yedek dosyasının geri döndürülmesi yeterli olacaktır.

mkdir ~/.init<br></br>
cd ~<br></br>
wget http://bazaar.launchpad.net/~upstart-devel/upstart/trunk/download/head:/upstart.conf-20080508231852-jw3hh1a1d02tcmj7-1/Upstart.conf<br></br>
sudo mv /etc/dbus-1/system.d/Upstart.conf /etc/dbus-1/system.d/Upstart.conf.yedek<br></br>
sudo mv Upstart.conf /etc/dbus-1/system.d/Upstart.conf

Bu yazıda Upstart gibi çok geniş bir konuya giriş yapılmış ve temel işlemlerin nasıl yapılacağı anlatılmıştır. Daha kapsamlı işlemler için kullanıcıların başvuru yapabilecekleri kaynaklar gösterilmiş ve iki basit örnekle kavramın anlatımı tamamlanmaya çalışılmıştır. Başlangıç süreçleri ile ilgili daha fazla bilgi edinmek için /etc/rc* dizinlerinin ne işe yaradığının, o dizinlerde bulunan dosyaların nasıl isimlendirildiğinin ve nasıl yazıldığının araştırılması bu yazıya tamamlayıcı olması açısından önerilmektedir.

Bu yazi ilk defa Temmuz 2012’de cikan Ubuntu Turkiye E-dergisi SUDO’nun 43. sayisinda yayimlanmistir.

• man 8 init (5. ve 8. bölümlerinde tanımlanan init farklıdır)
  ** man 5 init (5. ve 8. bölümlerinde tanımlanan init farklıdır)
  [1] http://upstart.ubuntu.com/wiki/Stanzas?highlight=((CategoryDoc))#script
  [2] http://upstart.ubuntu.com/cookbook/#ubuntu-well-known-events-ubuntu-specific
  [3] http://upstart.ubuntu.com/wiki/Stanzasfor0.5.1
  [4] http://upstart.ubuntu.com/cookbook/

sshdconfig(5) man sayfasini okurken yapmak istedigim seyin ChrootDirectory direktifi sayesinde yapilabilecegini gordum. Problem ChrootDirectory’nin varsayilan olarak tum kullanicilari hapsetmesiydi. Sisteme yonetici olarak erismesi gereken uc kisiyi bir sekilde bu yeni olusturacagim tunel kullanicisindan ayirmam gerekiyordu. sshdconfig(5) sayfasinda chroot diye arama yaparken bir de Match direktifine denk geldim. Match ifadesi User, Group, Host ve Address kriterleriyle eslesme yapabiliyormus. Eslesme ardindan ise genel ayarlari ne sekilde ezecegimizi belirtmemiz gerekiyormus. Yapmak istedigime geri donecek olursak, kullanicilari ev dizinlerine hapsetme. Yalniz bir kullanici sana adim ORNEK diyorsa onu ev dizinine hapsetmelisin. Match ifadeleri bir baska Match ifadesine rastlayana ya da dosya bitene kadar devam ediyorlarmis. Dolayisiyla ornegin normalde X11Forwarding’e izin verdigimizi varsayarsak Match bloguna yazilacak X11Forwarding no ile kritere uyan oturumlar icin X yonlendirmeyi kapatabilmek mumkun.

man sayfasina gore ChrootDirectory en az bir kabuk, /dev/null, /dev/zero, /dev/stdin, /dev/stdout, /dev/arandom ve /dev/tty aygit dugumlerini icermeliymis. Bu bilgiyi bir kenarda tutup yavas yavas islemi nasil yapacagimizi anlatmaya baslayayim.

Once yeni kullanicimizi olusturuyoruz.

sudo adduser --home /home/ornek --shell /bin/bash ornek

Sifreyi ve bir iki soruyu yanitladiktan sonra kullanicimiz olusturulmus oldu. Simdi /etc/ssh/sshd_config dosyasinin en sonuna su ifadeleri eklemeliyiz. Duzenledigimiz yapilandirma dosyasinin aktif hale gelmesi icin servisi yeniden baslatiyoruz.

Match User ornek ChrootDirectory %h sudo service ssh restart

Su anda ornek kullanicisi SSH baglantisi yapmak isterse sifresini girdikten sonra su iki satiri gorecek ve baglanti kuramayacaktir.

Connection to ornek.com closed by remote host. Connection to ornek.com closed.

Yukarida da belirttigim gibi kullanici bir kabuk bulmayi bekliyor -olustururken /bin/bash demistik- fakat hapsoldugu dizinde -ki %h ile ev dizini olan /home/ornek altina hapsediyoruz- /bin/bash yok. O halde kopyalayalim.

sudo mkdir /home/ornek/bin sudo cp /bin/bash /home/ornek/bin

Su asamada baglanmayi denerse yine ayni sekilde hata alacaktir. (Ubuntu 12.04.2 LTS 64 bit altinda calistigimizi tekrar hatirlatayim) Bunun nedeni BASH’in kullandigi kitaplik nesnelerinin dinamik olarak baglanmis olmasi. Peki bunu nasil ogreniyoruz? Asagidaki komutu calistiralim ve ciktisina bakalim.

file /bin/bash /bin/bash: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=0xe643cefb2c672ad94e955067c511537ddbab48da, stripped

Yukaridaki cikti kabaca bize BASH’i calistirmak icin birkac baska dosyaya ihtiyacimiz oldugunu soyluyor. Neyse ki bu dosyalari bulmak cok kolay. ldd komutunun bir dosyanin hangi paylasilan nesnelere ihtiyaci oldugunu gosterdigini biliyoruz. Hemen BASH icin bakalim. linux-vdso.so.1 icin bir dizin vermemis fakat bellek adresi oldugunu tahmin ettigim bir adres var. O halde bizim bir kopyalama islemi yapmamiza gerek yok. libtinfo.so.5, libdl.so.2, libc.so.6 nesnelerini /home/ornek/lib/x86_64-linux-gnu altina, ld-linux-x86-64.so.2 nesnesini ise /home/ornek/lib64 altina kopyalamamiz gerekiyor.

ldd /bin/bash linux-vdso.so.1 => (0x00007ffff8dfc000) libtinfo.so.5 => /lib/x8664-linux-gnu/libtinfo.so.5 (0x00007f5e61aa7000) libdl.so.2 => /lib/x8664-linux-gnu/libdl.so.2 (0x00007f5e618a3000) libc.so.6 => /lib/x8664-linux-gnu/libc.so.6 (0x00007f5e614e3000) /lib64/ld-linux-x86-64.so.2 (0x00007f5e61cd5000) sudo mkdir -p /home/ornek/lib/x8664-linux-gnu sudo mkdir /home/ornek/lib64 sudo cp /lib/x8664-linux-gnu/libtinfo.so.5 /home/ornek/lib/x8664-linux-gnu/ sudo cp /lib/x8664-linux-gnu/libdl.so.2 /home/ornek/lib/x8664-linux-gnu/ sudo cp /lib/x8664-linux-gnu/libc.so.6 /home/ornek/lib/x8664-linux-gnu/ sudo cp /lib64/ld-linux-x86-64.so.2 /home/ornek/lib64/ sudo chown -R root:root /home/ornek

Tekrar giris yapmayi denerse kullanici, su asamada giris yapabilecektir. Fakat bu haliyle henuz saydigim gereksinimlerin tumunu yerine getirebilmis degiliz. Kullanici bir ev dizini bulmayi bekliyor fakat /home/ornek altinda hapsoldugundan -yani /home/ornek dizinini / olarak gordugunden- ev dizinini bulamiyor. Bu yuzden dogrudan / altinda basliyor oturumuna. Bulmayi bekledigi dizini olusturup izinlerini verelim.

sudo mkdir -p /home/ornek/home/ornek sudo chown ornek:ornek /home/ornek/home/ornek

ls, nano, rm, cat ve grep hala eksik. Oncelikle bu komutlar icin hangi nesnelere ihtiyac duyuldugunu ogrenmeliyiz. libncursesw.so.5 disindaki nesneleri zaten BASH icin kopyalamistik. Dolayisiyla onu ve /bin/nano’yu kopyalayalim.

ldd /bin/nano linux-vdso.so.1 => (0x00007fffe97ff000) libncursesw.so.5 => /lib/x8664-linux-gnu/libncursesw.so.5 (0x00007f93b0480000) libc.so.6 => /lib/x8664-linux-gnu/libc.so.6 (0x00007f93b00c1000) libdl.so.2 => /lib/x8664-linux-gnu/libdl.so.2 (0x00007f93afebc000) libtinfo.so.5 => /lib/x8664-linux-gnu/libtinfo.so.5 (0x00007f93afc95000) /lib64/ld-linux-x86-64.so.2 (0x00007f93b06b4000) sudo cp /lib/x8664-linux-gnu/libncursesw.so.5 /home/ornek/lib/x8664-linux-gnu sudo cp /bin/nano /home/ornek/bin

Su anda nano’yu calistirabiliriz diye dusunuyorsaniz, yaniliyorsunuz. ornek kullanicisi ile hemen denememizi yapalim. Bir terminal emulatoru bulamadi. xterm icin gereken dosyayi kopyalayalim.

-bash-4.2$ nano ornekyazi Error opening terminal: xterm. sudo mkdir -p /home/ornek/lib/terminfo/x sudo cp /lib/terminfo/x/xterm /home/ornek/lib/terminfo/x/

Nano’yu boylelikle calisir hale getirdik. Simdi sirada ls ve rm var. rm icin gereken butun nesneleri daha once kopyalamistik. /bin/rm’i kopyaladigimizda o da calisir hale gelecek.

ldd /bin/rm linux-vdso.so.1 => (0x00007ffff8621000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fac4d2bf000) /lib64/ld-linux-x86-64.so.2 (0x00007fac4d685000) sudo cp /bin/rm /home/ornek/bin

ls ile devam ediyoruz. Eksik olanlari yerlerine kopyalayalim.

ldd /bin/ls linux-vdso.so.1 => (0x00007fffdd5ff000) libselinux.so.1 => /lib/x8664-linux-gnu/libselinux.so.1 (0x00007f3fde415000) librt.so.1 => /lib/x8664-linux-gnu/librt.so.1 (0x00007f3fde20d000) libacl.so.1 => /lib/x8664-linux-gnu/libacl.so.1 (0x00007f3fde004000) libc.so.6 => /lib/x8664-linux-gnu/libc.so.6 (0x00007f3fddc45000) libdl.so.2 => /lib/x8664-linux-gnu/libdl.so.2 (0x00007f3fdda41000) /lib64/ld-linux-x86-64.so.2 (0x00007f3fde63b000) libpthread.so.0 => /lib/x8664-linux-gnu/libpthread.so.0 (0x00007f3fdd823000) libattr.so.1 => /lib/x8664-linux-gnu/libattr.so.1 (0x00007f3fdd61e000) sudo cp /lib/x8664-linux-gnu/libselinux.so.1 /home/ornek/lib/x8664-linux-gnu/ sudo cp /lib/x8664-linux-gnu/librt.so.1 /home/ornek/lib/x8664-linux-gnu/ sudo cp /lib/x8664-linux-gnu/libacl.so.1 /home/ornek/lib/x8664-linux-gnu/ sudo cp /lib/x8664-linux-gnu/libdl.so.2 /home/ornek/lib/x8664-linux-gnu/ sudo cp /lib/x8664-linux-gnu/libpthread.so.0 /home/testci/lib/x8664-linux-gnu/ sudo cp /lib/x8664-linux-gnu/libattr.so.1 /home/ornek/lib/x86_64-linux-gnu/ sudo cp /bin/ls /home/ornek/bin/ls

ls’i de calisir hale getirdik. BASH ile ilgili dosyalari ev dizinine alip izinlerini duzenleyelim.

sudo cp /home/ornek/.bash* /home/ornek/home/ornek sudo cp /home/ornek/.profile /home/ornek/home/ornek sudo chown -R root:root /home/ornek sudo chown -R ornek:ornek /home/ornek/home/ornek

Kullanici giris yaptiginda .bashrc PS1 degiskenine kullanici adini atamaya calisacak fakat kullanici adini bulamadigi icin “I have no name!” ismiyle karsilasacagiz. Gereken dosyalari olusturalim. Genel bilgi olarak /etc/profile ve /etc/profile.d/ nedir ne ise yarar arastirilirsa iyi olacaktir. Aslinda bu dosyalar gerekli degil fakat kullaniciya masaustunde alistigi ortami yaratmak istiyoruz.

sudo mkdir /home/ornek/etc grep ornek /etc/passwd | sudo tee /home/ornek/etc/passwd grep ornek /etc/group | sudo tee /home/ornek/etc/group sudo cp /etc/profile /home/ornek/etc/profile sudo cp -R /etc/profile.d/ /home/ornek/etc

Su asamada giris yapilirsa id komutunun bulunamadigindan yakinacaktir. /etc/profile dosyasi id ile kullanici numarasini kontrol eder. Olusturalim.

sudo mkdir -p /home/ornek/usr/bin sudo cp /usr/bin/id /home/ornek/usr/bin

Tekrar giris yaptigimizda /etc/passwd ve /etc/group yerinde olmasina ragmen yine “I have no name!” ile karsilasilacagiz. Bunun nedeni bu dosyalari okumak icin gereken kitaplik nesnelerinin kayip olmasi. nsswitch.conf(5) man sayfasi FILES bolumunde ilgili dosyalardan bahseder.

sudo cp /lib/x8664-linux-gnu/libnssfiles* /home/ornek/lib/x86_64-linux-gnu/

Iste artik kullanici adi da gozukuyor. Gelelim geride kalan son birkac komut ve gorsel zenginlestirmeye. ~/.bashrc dircolors komutuna ihtiyac duyar ls’in renkli cikti verebilmesi icin. Hemen ayarlayalim.

sudo cp /usr/bin/dircolors /home/ornek/usr/bin

Kullanicinin hapsoldugu kok dizindeki gereksiz dosyalari silelim. Geri kalan gereksinimlerimizi tamamlayalim. Hepsinin paylasilan nesnelerini daha once kopyaladigimiz icin ana programlari kopyalamamiz yeterli.

sudo rm -rf /home/ornek/.cache sudo rm /home/ornek/.bash* sudo rm /home/ornek/.profile sudo cp /bin/cat /home/ornek/bin sudo cp /bin/grep /home/ornek/bin sudo cp /bin/cp /home/ornek/bin sudo cp /bin/mv /home/ornek/bin sudo chown -R root:root /home/ornek sudo chown -R ornek:ornek /home/ornek/home/ornek

Su asamada istedigimiz sekilde chroot ortamimizi yapilandirmis olduk. Butun bu islemleri baska bir kullanici icin de tekrarlamamak adina /home/ornek dizinimizin bir arsiv yedegini alabilir ve yeni kullanicilar yaratirken bu yedekten ev dizinlerini rahatlikla olusturabiliriz. chroot ortamindaki /etc/passwd, /etc/group dosyalarinin duzenlenmesi unutulmamali. Ayrica dosya isimleri ve sahiplikleri yeniden duzenlenip sunucudaki asil /etc/ssh/sshd_config dosyasina da kullaniciya ait Match direktifi eklenmeli ya da olan Match direktifine ek yapilmali ve ssh servisi yeniden baslatilmalidir. Fakat sunu da hatirlatmak gerek ki chroot etmeniz gereken kullanicilar eger sistemde yonetim islemlerini yapacak kullanicilardan fazla hale geliyorsa varsayilan ayari tum kullanicilari chroot edecek sekilde degistirip yonetim yetkisine sahip kullanicilari match ile kacmak daha mantikli olacaktir.

Bonus: Yazinin basinda /dev altindaki cesitli sanal aygitlarin da sshd_config(5) tarafindan baglanmasinin onerildigini yazmistim. Su ana kadar bu hesabi olusturdugumuz kullanici bu dugumlerin eksikliklerinden kaynaklanan bir hata bildirmedi. Fakat ornegin scp’yi de kullanicinin erisimi olan komutlar arasina katarsaniz /dev/null aygitini bulamadigindan yakinacaktir. Bunun icin aygit dugumlerini su adimlari izleyerek olusturabilirsiniz.

sudo mkdir /home/ornek/dev cd /home/ornek/dev sudo MAKEDEV -v std

Ardindan icinde bulundugunuz dizinde olusturulmus pekcok aygit dugumu goreceksiniz. Bunlardan kmem, mem, ram, loop olanlarini silmenizde bir sakinca yok. Digerleri cat ile kullanicinin da isine yarayabilecek olanlar.

Yazida dilimin dondugunce yonettigimiz makinede hesaba sahip olan bir SSH kullanicisini nasil istegimize gore kisitlayabilecegimizi anlatmaya calistim. Umarim benzer ihtiyaci olan birine yol gosterir.