[Gelistirici] Ahenk 2.0 Planları

[Burak Arslan]

selamlar,

puppet konusunda:
policyleri ldap'ta tutmak, cok kisir bir deklaratif dil kullanmak demek. 
(sadece key=value diyebiliyorusunuz, bence kotu fikir.) puppet policy 
belirlerken (cfengine'in emperatif dilinin aksine) tam tesekkullu, ama 
yine deklaratif bir dil kullandigi icin  puppet dilinde policy ureten 
bir gui yazip istemci yonetimini puppet vasitasiyla yapmak daha kisa 
zamanda daha guclu bir urun ortaya cikmasina yardimci olacaktir. (gui 
ile policyleri uretin, gerisini puppet yapsin) boylece hem gui isteyen 
insan hem de script yazmak isteyen insani mutlu edebiliriz.

authentication konusunda:
tls tuneli icinden pam_ldap ile ldap sunucusuna simple bind ile 
authentication yapiyorsunuz. bu en guvensiz ikinci authentication 
yontemi. (en guvensizi tls/ssl kullanmadan ayni isi yapmak)

neden derseniz ;)

biliyorsunuz tls/ssl altyapisi beraberinde yonetilmesi gereken bir PKI 
ile geliyor. yani bir root sertifika yaratiliyor, ve bu sertifikanin 
imzaladigi sertifikalar sunucu ve istemcilere dagitiliyor.

bu dagitim isi guvenilir(?) it personeli tarafindan elle yapilacaksa 
sorun yok. ama pratikte bu islem otomatik yapilacaktir. sertifika 
iletimi sirasinda bir aktif mitm saldirisi yapilarak bu sertifikalar 
yolda yakalanarak degistirebilir. boylece mitm kardes istemci ve 
sunucuya kendi urettigi sertifikalari gondererek baglantiyi istedigi 
gibi izleyebilir / degistirebilir / kaydedebilir. boylece de istemcilere 
istedigini kurabilir vs. rezalet yani :)

internette alisveris vs yaparken kullandigimiz ssl/tls in de kocaman bir 
kandirmaca olmasi iste bu sebeptendir. (browser'in icinden cikan kok 
sertifikalarin bize gelirken yolda degistirilmedigini kimse garanti 
edemiyor. paketin yaninda gordugunuz paket digestinin de yolda 
degistirilmedigini kimse garanti edemiyor.)

zaten kerberosu yaratan ekip de bu sorunlari inkar edemedikleri / 
cozemedikleri icin bu ise girismislerdir. (gerci o zaman ssl var miydi 
bilemiyorum)

peki kerberos bunlari nasil cozer ? cok basitlestirilmis bir sekilde: 
istemci, kerberos sunucusuna (AS) kullanici adini cleartext olarak 
gonderir. kerberos sunucusu encrypted bir mesaj gonderir. mesajin 
sifresi kullanicinin sifresidir. istemci kullanicinin girdigi sifre ile 
gelen mesaji decrypt eder ve ortaya cikan yeni mesaji TGS'ye gonderir. 
eger TGS gelen mesajdan birsey anlayabilmisse (== sifre dogruysa) 
istemciye bir ticket gonderir. vesaire.

gordugunuz gibi sifre kesinlikle ortalikta dolasmiyor, aktif mitm'in 
yapabilecegi tek sey replay saldirisi. bunun da onune senkronize 
saatlerle geciliyor. network time protocol denen bir nimet de gunumuzde 
rahatca kullanilabildigi icin bu pratik bir sorun degil.

ayrica wikipedia'da belirtilen kerberos'un eksikleri ya dupeduz yalan ya 
da diger sistemlerde de ayni eksikler mevcut. alternatif olarak konunun 
uzmanlarindan albert levi'nin ders notlarina 
http://people.sabanciuniv.edu/levi/cs432_532/ adresinden erisebilirsiniz.

kisaca eger ahenk sisteminin ciddi, buyuk kuruluslarca da ciddiye 
alinmasini istiyorsaniz kerberos kullanmalisiniz.

son olarak belirtmek istedigim bir nokta var ki o da su: kriptografi ile 
hobi olarak ugrasan birisi olarak(asil isim istatistiksel dogal dil 
isleme), kriptografide turkiyenin et yetkin kurumu olarak bildigimiz bir 
kurumun calisanlarina kriptografi anlatirken ellerim terlemiyor degil. 
ben sadece bilebildigimce konuya yorum getirmeye calistim. bir yanlisim 
olmussa duzeltmeniz benim de bilgimin artmasina sebep olacaktir.

simdiden tesekkur ediyorum.

iyi calismalar
burak

> On Wednesday 15 April 2009 11:07:21 Semen Cirit wrote:
>
> >/ Bence biraz daha inceleyebiliriz. Bize uygun olursa işlerimizi
> />/ kolaylaştırabilir gibi geliyor.
> /
> puppet, cfengine vb çözümler admin scriptlerini bir grup bilgisayar üzerinde 
> çalıştırmak üzerine kurulu. İşi kolaylaştırmak için bu scriptlere üst düzey 
> yapılandırma fonksiyonları sağlıyorlar falan.
>
> Active directory, ahenk vb sistemlerde ise, merkezi bir veri tabanı dizini 
> var. Bunun üzerinde standart politikaların belirlendiği bir yönetim GUI si 
> var. Bilgisayarlar üzerinde çalışan agentlar bu verilere göre kendilerini 
> yapılandırıyor.
>
> Birinde politikalar programla öbüründe tanımla belirtiliyor, biri deneyimli 
> sunucu adminlerine öbürü gui'yle yönetim yapmak isteyen IT support 
> çalışanlarına daha uygun.
>
> >/ Ama bildiğim kadarıyla kerberos network trafic encryption yaparken (daha
> />/ güvenli hale getiren kısım: bunu yaparken 3 aşamalı bir hand shaking ile
> />/ yapıyor 1-Client/Server Authentication 2-Authentication Service
> />/ 3-Ticket-Granting-Service (TGS)), SASL ise authentication session
> />/ encryption yapıyor. Ve TLS ise user authentication kısmı ile değil
> />/ sadece encrypte edilmiş trafic yolunu belirlemede kullanılıyor diye
> />/ biliyorum.
> /
> Ecrypte edilmiş trafic yolu ne yav? Bu paragraftan hiç bir şey anlamadım :)
>
> Basitçe açıklayayım bu kavramları:
>
> Bize lazım olan şeyler iletişimin güvenliliği (encryption) ve client ile 
> server'ın karşılıklı olarak birbirinin kimliğini doğrulayabilmesi 
> (authentication).
>
> TLS şifreleme katmanı ama yalnızca şifreleme sağlamaz, handshake sırasında 
> taraflar birbirlerinin sertifikalarını kontrol ederek kimlik de 
> doğrulayabilirler.
>
> SASL nin şifreleme ile hiç alakası yok ve kendisi direk bir auth protokolü 
> değil. Çeşitli auth mekanizmalarının kullanılabilmesine olanak sağlayan bir 
> üst protokol. Mesela EXTERNAL metodunu kullanırsan, SASL verisini ileten 
> katmanın (TLS, IPSec yada neyse) verdiği kimlik bilgisini kullandırabilirsin. 
> Parola ile doğrulamayı açık text olarak (PLAIN metodu), yada 
> challange-response yoluyla (DIGEST-MD5 metodu) yapabilirsin. Eğer istersen 
> GSSAPI metoduyla kimlik doğrulamayı Kerberos üzerinden yapabilirsin. SASL 
> sana karşıda bu metotların hangisi var onu söyler, sonra seçtiğin metot için 
> gerekli bilgi aktarımını sağlar.
>
> Bunlardan hangisini nasıl kullandığımız Ahenk yapısını etkileyecek bir karar 
> değil, LDAP'ta hepsi rahatça kullanılabiliyor. Config dosyasına şu metodu 
> kullan diye bir satırlık parametre yazmak yeterli, kalan herşey transparent.
>
> Kerberos'un amacı ise farklı bir problemi çözmek: single sign-on. Bunun 
> dışında daha fazla güvenlik sağladığı gibi bir şey yok. [0] adresindeki 
> drawback'lere bakarsan da Kerberos'un kendi güvenliğini sağlamanın hiç de 
> basit bir problem olmadığını göreceksin.
>
>   

-------------- sonraki bölüm --------------
Bir HTML eklentisi temizlendi...
URL: <http://liste.pardus.org.tr/gelistirici/attachments/20090417/7e616839/attachment-0002.htm>