AS112 Projesi

Kisa bir yazi olacak. Ilginc olmasini umuyorum.

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

30 Ağustos 2013

Posted In: dns, Gezegen

DNS kuvvetlendirmeli DDOS saldırıları (DNS Amplification Attacks)

DDoS

DNS kuvvetlendirmeli DDOS saldırıları haberlere konu oluyor, ve eminim ki bu satırları okuyorsanız bunun bir parçası olup olmadığınızı merak ediyorsunuzdur. Öncelikle DNS kuvvetlendirmeli DDOS saldırılarının nasıl gerçekleştirildiğini inceleyelim. En basit haliyle bu saldırı türünde, kurbanın IP adresi (IP Spoofing) ile DNS sunuculara sorgular gönderilir. Kurban gönderilen bu DNS sorgularının yanıtlarını alır. İlk başta problem değilmiş gibi görünüyor olabilir, gün içerisinde pek çok istemci ve sunucu yoğun DNS sorgu trafiği oluşturuyor. Bu senaryoda yaşanabilecek problemler, DNS sunucularının yapılandırmalarının yetersiz olması, kuvvetlendirmenin yapılıyor olması ve ISP lerin RFC leri tam uygulamıyor olmasından kaynaklanıyor.

Genel amaçlı kamusal DNS sunucu yönetmiyorsanız, sadece kendi alan adlarınızın veya müşterilerinizin IP adreslerinden gelen DNS sorgularını kabul etmelisiniz. Eğer DNS sunucunuz İnternet’e açıksa, recursion tipi DNS sorgularına yanıt vermemeli, sadece otoritesi olduğu alan adlarına ait sorguları yanıtlamalı. Saldırıyı gerçekleştiren taraf recursive DNS sunuculara değiştirilmiş kaynak IP li sorgular gönderir. Recursive DNS sunucu bu sorguların yanıtlarını kurbanın IP adresine döner.

Saldırgan küçük DNS sorguları gönderir, çok fazla DNS kaydı olduğu bilinen bir alanadı için “ANY” paremetresi kullanılarak tüm kayıtlar istenir. Sorgu paketleri 60byte seviyelerindeyken dönülen cevap 3-4kb seviyesinde olabilir. Buda yaklaşık 50-70 katı bir kuvvetlendirme sağlar. Saldırgan küçük DNS sorgularını fazla sayıda recursive DNS sunucuya gönderebilir, ve tüm sunucular kurbana yanıtları döner. Bu yöntem ile kısa süre içerisinde kurbana ezici bir trafik yönlendirilmiş olur.

ISPler, DNS kuvvetlendirme saldırısında da kullanılan kaynak IP değişimiyle gerçekleştirilen saldırıları engelleyebilirler. Internet Engineering Task Force (IETF) – Best Current Practices (BCP) dokümanı olarak Request for Comments (RFC) hazırlamakta. RFC 2827 – BCP 38 “Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing”. Bu dokümanda temel olarak, kaynak IP adresinin istemcinin bulunduğu aralıkta olmaması durumunda paketlerin nasıl düşürüleceği anlatılmakta. Eğer ISP lerin çoğunluğu bu BCP 38 de tanımlanan kurallara uyarsa, pek çok kaynak IP değişikliğine dayanan saldırının önü kesilmiş olacak.

IPv4 adreslerinin azlığından, ev ve iş bağlantılarının pek çoğu Address Translation (NAT) kullanarak Internet üzerindeki IP lere verimli erişim sağlıyor. NAT kullanımı aynı zamanda kaynak IP değişikliği yapılmasına da engel oluyor, çünkü kaynak IP adresi NAT cihazı tarafından yazılıyor. IPv6 yaygınlaştıkça NAT kullanımına duyulan ihtiyaç azalacak. Günümüzde olduğu gibi, IPSler BCP leri IPv6da da takip etmediği taktirde, kaynak IP adresi değişimine dayanan saldırılar artacaktır.

Ayr.bkz. “Yansıma DDOS Atakları (Reflection DDoS Attacks)”

Hamdi ÖZCAN – ozcan.com

24 Ağustos 2013

Posted In: lkd, teknik, tr

DNS kuvvetlendirmeli DDOS saldırıları (DNS Amplification Attacks)

DDoS

DNS kuvvetlendirmeli DDOS saldırıları haberlere konu oluyor, ve eminim ki bu satırları okuyorsanız bunun bir parçası olup olmadığınızı merak ediyorsunuzdur. Öncelikle DNS kuvvetlendirmeli DDOS saldırılarının nasıl gerçekleştirildiğini inceleyelim. En basit haliyle bu saldırı türünde, kurbanın IP adresi (IP Spoofing) ile DNS sunuculara sorgular gönderilir. Kurban gönderilen bu DNS sorgularının yanıtlarını alır. İlk başta problem değilmiş gibi görünüyor olabilir, gün içerisinde pek çok istemci ve sunucu yoğun DNS sorgu trafiği oluşturuyor. Bu senaryoda yaşanabilecek problemler, DNS sunucularının yapılandırmalarının yetersiz olması, kuvvetlendirmenin yapılıyor olması ve ISP lerin RFC leri tam uygulamıyor olmasından kaynaklanıyor.

Genel amaçlı kamusal DNS sunucu yönetmiyorsanız, sadece kendi alan adlarınızın veya müşterilerinizin IP adreslerinden gelen DNS sorgularını kabul etmelisiniz. Eğer DNS sunucunuz İnternet’e açıksa, recursion tipi DNS sorgularına yanıt vermemeli, sadece otoritesi olduğu alan adlarına ait sorguları yanıtlamalı. Saldırıyı gerçekleştiren taraf recursive DNS sunuculara değiştirilmiş kaynak IP li sorgular gönderir. Recursive DNS sunucu bu sorguların yanıtlarını kurbanın IP adresine döner.

Saldırgan küçük DNS sorguları gönderir, çok fazla DNS kaydı olduğu bilinen bir alanadı için “ANY” paremetresi kullanılarak tüm kayıtlar istenir. Sorgu paketleri 60byte seviyelerindeyken dönülen cevap 3-4kb seviyesinde olabilir. Buda yaklaşık 50-70 katı bir kuvvetlendirme sağlar. Saldırgan küçük DNS sorgularını fazla sayıda recursive DNS sunucuya gönderebilir, ve tüm sunucular kurbana yanıtları döner. Bu yöntem ile kısa süre içerisinde kurbana ezici bir trafik yönlendirilmiş olur.

ISPler, DNS kuvvetlendirme saldırısında da kullanılan kaynak IP değişimiyle gerçekleştirilen saldırıları engelleyebilirler. Internet Engineering Task Force (IETF) – Best Current Practices (BCP) dokümanı olarak Request for Comments (RFC) hazırlamakta. RFC 2827 – BCP 38 “Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing”. Bu dokümanda temel olarak, kaynak IP adresinin istemcinin bulunduğu aralıkta olmaması durumunda paketlerin nasıl düşürüleceği anlatılmakta. Eğer ISP lerin çoğunluğu bu BCP 38 de tanımlanan kurallara uyarsa, pek çok kaynak IP değişikliğine dayanan saldırının önü kesilmiş olacak.

IPv4 adreslerinin azlığından, ev ve iş bağlantılarının pek çoğu Address Translation (NAT) kullanarak Internet üzerindeki IP lere verimli erişim sağlıyor. NAT kullanımı aynı zamanda kaynak IP değişikliği yapılmasına da engel oluyor, çünkü kaynak IP adresi NAT cihazı tarafından yazılıyor. IPv6 yaygınlaştıkça NAT kullanımına duyulan ihtiyaç azalacak. Günümüzde olduğu gibi, IPSler BCP leri IPv6da da takip etmediği taktirde, kaynak IP adresi değişimine dayanan saldırılar artacaktır.

Ayr.bkz. “Yansıma DDOS Atakları (Reflection DDoS Attacks)”

Hamdi ÖZCAN – ozcan.com

24 Ağustos 2013

Posted In: lkd, teknik, tr

Kadınlar Makinesi (1.Etkinlik GNU/Linux)

Ada Lovelace’ın yolundan giden kadınların katılımının teşvik edileceği “Kadınlar Makinesi” etkinliklerinin ilki GNU/Linux temasıyla 15 Ağustos 2013 Perşembe akşamı 19:30′da İstanbul HackerSpace’de başlıyor.

Etkinliğe bilgisayar ile katılmak sizin için avantajlı olacaktır.
Etkinlik Tarihi: 15 Ağustos 2013, 19:30
Konuşmacılar: Nermin Canik, İlden Dirini
Etkinlik Kontenjanı: 25 kişi

Kayıt için root@istanbulhs.org adresine e-posta atmanız gerekmektedir.
Adres: Eğitim Mah. Ömerbey Sok. Keskin Hancı İş Merkezi No.19/B 34722 Kadıköy/İstanbul
Tarif: Kadıköy evlendirme dairesinin önündeki ışıklardan karşıya geçip, dereyi sol tarafınıza alarak yürüyün. Sağ tarafınızda İş merkezleri, büyük binalar bulunacak. Yolu bitirdiğinizde MNG Kargo göreceksiniz. Onun önünden sağa girin. Sonra da ilk sola girin. Çıkmaz sokağın en sonundayız.

Kaynak: http://istanbulhs.org/kadinlar-makinesi/                              

13 Ağustos 2013

Posted In: GLFS

Türkiye ve Linux

Uzun süredir  işlerimin yoğunluğu sebebi ile Linux dünyası ile ilgili hiç yazı yazamadım. Biliyorsunuz. 2011 senesinde “Özgür Bilişim Teknolojileri sınıfı” projesini başlatıp en azından kendi adıma örnek bir proje olarak bitirdim. O gün kurduğum “Pardus Kurumsal 2” işletim sistemleri hala ilk günkü kararlı yapısında çalışmaya devam ediyor. Pardus ile aramda kalan tek bağ (gönlümün bir yerlerinde hep bir bağ olsa da) o bilgisayar sınıfından ibaret. Birde unutmadan, Fatih Projesi sebebiyle Bilişim Teknolojileri Rehber Öğretmeni olarak çalıştığım okullarda Akıllı tahtalar açılırken “Boot Menu” de çıkan dokunmatik ekranla seçim yapılamayan “Pardus” yazısı…

Neredeyse 1 yıldır gelişmeleri de takip etmiyorum. Posta gruplarında kopan büyük tartışmalar. Topluluklarda ve yönetimde oluşan çatlaklar, kavgalar vs. açıkçası beni biraz bu konulardan soğuttu diyebilirim.

Linux Özgürlükçüdür.

Linux kullanmak veya açık kaynak kodlu bir yazılım kullanmanın altında bedava yazılım kullanmaktan çok öte bir düşünce yapısı var. Özgürlükçü, demokratik, insan haklarına saygılı ve paylaşımı seven, insanlığa hizmet etmek isteyen bir düşünce yapısı.

Sanırım bizim ülke olarak Linux ile ilgili yaşadığımız sorunlar aslında bütün bunlarla ilgili. Hayatımızdaki kavga buraya da yansıyor. Örneğin birileri Pardus’un ulusal olmasına takılırken birileri başka bir Linux versiyonunu ulusal olmadığı için kullanmayı veya desteklemeyi reddetti. Hatta işletim sisteminden vazgeçtim paket yöneticisi bize özgü olmalı mı olmamalı mı tartışmaları.

Şimdi bu tartışan insanların bir kısmı ya Linux kullanmıyor veya 2. işletim sistemi olarak kullanıyorlar.

Keşke herkes Linux Debian kullanıyor olsa.

Öncelikle Pardus 2013ü kurmadım. Kendi bilgisayarımda uzun zamandır Linux Mint kullanıyorum ve etrafımdakilerin bilgisayarlarına Linux Mint ve  Ubuntu kuruyorum.

Şimdi Pardus 2013 Debian tabanlı oldu diye ortalık yıkıldı. “kopya Linux” diyenler, neler neler…

Şimdi Pardus yönetimi, topluluk vs. bunların içinde yaşanan bütün sorunları boşverelim. Şöyle bir düşünelim;

Birisi alsa Debian Linux versiyonunu ve buna bir Pardus duvar kağıdı değişecek şekilde hazırlasa ve piyasaya sürse. Bizler de Debian kaynaklarındaki bilgilerden yararlanıp bu duvar kağıdı değişik Debian’ı kullanan insanlara yardım etsek ne olur. Bu kopya Linux’u Okullardaki bilgisayarlara kursalar, paket yönetici ile uğraşacakları enerjiyi okullarda kullanılmasının arttırılmasında harcasalar. Öğrenciler Linux ile ders işlenen sınıflarda ders alsa, Linux bilgisayar laboratuvarlarında yazılım geliştirmeyi öğrenseler, Öğretmenler Linux üzerinden sınav ve ders içerikleri hazırlasa, idareciler okulu Linux ile idare etseler…

Fazla değil 10 sene sonra 1 değil 10 tane Ulusal işletim sistemine sahip oluruz.

Başka bir açıdan ihtiyacımız olan şey bu gelişime kaynak olacak firmalar.

Bu iş dünyada kurulan vakıflar ve bu vakıflara aktarılan paralar ile yürümekte. Vestel, Casper veya herhangi bir firma bu işe gönül ve para verecek, milyonlarca insanın gönlünü alacak geleceğine yön verecek. Ama belki ticari sebeplerle ve belkide yapılan anlaşmalar verilen sözler sebebi ile kimse elini taşın altına koymuyor.

Agrasif bir yazı oldu. Hatam varsa affola, sizlerde fikirlerinizi belirtirseniz sevinirim.

Son bir sözüm daha var;

Yakın bir zamanda akademik sebeplerle uzun süredir ertelediğim vatani görevimi yapmak üzere askere gideceğim. işlemleri yapmak üzere gittiğim askerlik şubesinde Pardus kullandıklarını gördüm. Askeriyenin Pardus kullanımı ile ilgili olarak izlenimlerimi de ilerki yazılarımda aktarmayı düşünüyorum.

11 Ağustos 2013

Posted In: Fatih Projesi, linux, Linux kullanımı, pardus

Profesyonel Paranoya

Lavabit* belirsiz bir sureligine kapatildi.[1] Hushmail*[2] simdilik Kanada sinirlarinda oldugundan ve gerekirse mahkeme emriyle anahtar ciftlerinizi sifreleyen parolanizi saklayabildiginden hizmet vermeye devam ediyor. Onun da akibeti bence belirsiz.

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/

9 Ağustos 2013

Posted In: Gezegen

Koding, yeni bir bakış açısı…

header

Geliştirme yapmaya karar vermiş her insan kişisinin başına gelenler tabi ki bizim de başımıza geldi; donanımların pahalı olması, yazılım geliştirmek için gerekli yazılımların çok da kolay bulunabilir/kullanılabilir hale getirilememesi, yaptığınızı kolay bir şekilde paylaşıp diğer insanlardan ihticayınız olan geri bildirimi alamamanız vs. vs.

Şimdi biraz okuyan, kendini geliştiren ve kullanılabilir/satılabilir bir yazılım geliştirmeye karar veren ilk insanın yapacağı hareket büyük ihtimalle bir sunucu kiralamak/almak, o sunucuyu ayağa kaldırmak, ayarlarını yapmak için bir kaç gününü harcamak olacaktır. Alan adı vs. gibi ayrıntılara girmiyorum bile. Bunların hepsini başarabilirse (ne geliştiriciler kaybettik bu arada) oturacak kod yazacak ve ortaya işe yarar bir ürün çıkacak…

Sanırım bir önceki paragrafın sonundaki üç nokta bir çok şey anlatıyor. Bu işler çok zor ve bir çok insan bu aşamalarda pes ediyor ya da yavaşlıyor. İşte tam da bu nedenden dolayı ortaya çıkan Koding’in, bugün (biraz önce) kapılarını herkese açtık, (Basın bültenine buradan ve Devrim Yaşar‘ın harika blog yazısına da buradan ulaşabilirsiniz -İngilizce) artık davetiye beklemeden Koding.com‘a giderek kayıt olabilir ve birazdan sıralayacağım harikalardan ücretsiz yararlanabilirsiniz! 

– Enfes bir geliştirme ortamı

dev_

– Harika bir editor

editor_

– Sınırlar olmadan sanal makine deneyimi: Tarayıcınızın içinden erişebileceğiniz hatta yönetici yetkilerine (a.k.a root) sahip olduğunuz bir sanal makineden bahsediyorum :) free as in beer. VM’lerde Ubuntu kullanıyoruz.

root-vms_

– Gerçek Terminal, tarayıcının tam da içinde!

terminal_

– Kolay, yenilikçi alan adı yönetimi

domains_

– Hayatınızı kolaylaştıracak Koding uygulamaları

kdapps_

– Açık kaynak uygulama kodları, Koding Framework

kdframework_

– Kod, görüş, düşünce, harika makaleler paylaşmak

social_

social2_

– Etiketler, konular

tags_

– Grup desteği ile projenize ya da ekibinize özel Koding kopyaları yaratmak

groups_

– Tam ihtiycanız olduğunda size yön gösterecek harika bir kitap

book_

 

Tüm bunlara ulaşmak için koding.com ‘da bir hesap açmanız yeterli!

8 Ağustos 2013

Posted In: gezegen.linux, Türkçe, web

Apache sunucuda IPv6 ayarları

Apache2 ile sunduğunuz alt alan adlarını IPv6 üzerinden erişilebilir kılmak isterseniz yapmanız gereken adımlar şu şekilde:

Apache2 varsayılan olarak hem v4 hem de v6  üzerinden erişimi destekler geliyor. Hali hazırda v4 ayarlarınızı bozmadan v6 için ayar yapıp yolunuza devam edebilirsiniz.

/etc/apache2/sites-enabled dizininde etkinleştirilmiş alan adlarınızdan birinin foo.edu.tr olduğunu varsayalım. foo.edu.tr için oluşturduğunuz basit bir sanal uç dosyası aşağıdakine benziyor olabilir.

<VirtualHost AAA.BBB.CC.DD>
DocumentRoot /var/www/foo
ServerName foo.edu.tr

<Directory /var/www/foo>
php_admin_value open_basedir /var/www/foo:/tmp
allow from all
Options -Indexes SymLinksIfOwnerMatch
</Directory>
</VirtualHost>

Burada VirtualHost etiketi içerisine IPv4 adresi yazmışız. v4 adresinden sonra köşeli parantezler içerisinde v6 adresini ekleyebilir veya * ile olası tüm adresleri kapsatabilirsiniz.

<VirtualHost AAA.BBB.CC.DD [2001:a98:a080:2:xxxx:xxxx:xxxx:xxx]>

Sonrasında /etc/apache2/ports.conf altında

NameVirtualHost *:80
Listen *:80

satırlarının olduğunu kontrol etmeniz gerekiyor. Ben buradaki NameVirtualHost satırını # ile yorum satırı haline getirip tek tek IP adresi yazmayı tercih ettim. /etc/apache2/httpd.conf içerisine

NameVirtualHost AAA.BBB.CC.DD
NameVirtualHost [2001:a98:a080:2:xxxx:xxxx:xxxx:xxx]

satırlarını ekledim. Sonrasında yapılan ayarları Apache’nin algılaması için

$ sudo /etc/init.d/apache2 reload

komutunu çalıştırmalısınız. NameVirtualHost *:80 tanımında * kullanımlarında sanal uç dosyalarında da * kullanmak gerekiyor olabilir. * ile kullanımı denemediğimi belirtmiş olayım. Buraya kadar yaptıklarınız ile v6 adresinden sunduğunuz web sayfanıza erişmek isteyenlere Apache’nin cevap vermesini sağladınız. Bu v6 adresine dışarıdan erişilebilmesi için eğer bir ateş duvarı kullanıyorsanız web sunucusundaki servislere erişim için kural tanımlaması da yapmalısınız. Son olarak da DNS kayıtlarınızda v6 tanımlamasının olabilmesi için şöyle bir satır girmelisiniz:

foo.edu.tr.        IN      AAAA    2001:a98:a080:2:xxxx:xxxx:xxxx:xxx/code>

3 Ağustos 2013

Posted In: Gezegen, Sunucu

PHP – Symfony Component’i ile Dependency Injection

Nesne yönelimli programlamada bazı nesneler birbiri ile bağlantılı olmak durumunda kalabiliyor. Ancak bu “bağlama” işlemleri için eğer doğru bir yazılım tasarımı yapılmazsa, kodun “maintain” (sürdürmek) edilebilmesi oldukça zorlaşır. Özellikle kodun maintain edilebilmesi için nesnelerin birbirlerine tightly coupled (sıkı bağlama) değil de loosely coupled (gevşek bağlama) olarak bağlanması gereklidir.

Birbiri ile bağlantılı nesnelerin yine birbirlerine “enjekte” edilebilmesi için arada bir framework olmalı (framework olmadan alternatif çözüm üretmek de mümkün). Aslında dependency injection kavramı tam bu kapıya çıkıyor. Nesnelerin bir framework aracılığıyla diğer nesnelere enjekte edilmesidir dependency injection.

PHP’de ise dependency injection için birçok framework var. Ancak bunların da birçoğu outdated (zaman aşımına uğramış).

Bu işler için Symfony‘nin kendi içinde bir dependency injection component’i bulunuyor.

Yazının devamında bulunan kodda, Symfony’nin dependency injection component’i ile yazdığım bir örneği görebilirsiniz.

Money sınıfı iCurrency interface’ine loosely coupled olarak bağlı. Böylece iCurrency‘den türetilen herhangi bir sınıfı kendi içerisinde çalıştırabilecek.
Ancak arada bir interface olmamış olsaydı, doğrudan Dollar sınıfına bağlansaydı, ileri de Euro para birimi kullanılacağı zaman bir de ekstra olarak Money sınıfının bağımlılığı düzenlenecekti.

İlgili kodu görmek için buraya tıklayın.

İlgili kodun PHPUnit ile yazdığım Unit Test’lerine buradan ulaşabilirsiniz.

1 Ağustos 2013

Posted In: Genel, Gezegen

Twitter Auto Publish Powered By : XYZScripts.com