[Gelistirici] [Pardus-kullanicilari] Ahenk 2.0 Planları

Burak Arslan burak.arslan at arskom.com.tr
19 Nis 2009 Paz 17:25:46 EEST


selim ok wrote:
>
> Sonucta geldigimiz noktaya bakinca bunun sertifika dagitimindan farki 
> kalmiyor Gürer'in dedigi gibi.
kaliyor; aciklayayim.

guvensiz aglar uzerinden guvenli iletisimin temel prensibi: guven yoktan 
var edilemez, bir guven turu bir baskasina cevrilir. (albert levi'nin 
sozudur)

kerberos ile, kerberos destekleyen bir terminal uzerinden bir kdc'ye 
auth olabilmek icin once o terminal icin bir private key olusturulmasi 
gerekiyor. bu private key'in guvenli bir sekilde kdc'den terminale 
tasinmasi isi, su sekilde yapiliyor: terminal ben seninle konusabilmek 
istiyorum diyor, kdc de "ok al bu senin sifren ama bu sifreyi domain 
admin sifresiyle acman lazim, o zaman login olabilirsin" diyor. o sirada 
o terminali domain'e katmaya calisan domain yoneticisi admin sifresini 
giriyor ve sunucu private key'ini ogrenmis oluyor.

terminal ele gecirildiginde ele gecen sifre aslinda bu sifredir. bunun 
ele gecmesi kullanici sifrelerini bir tehlikeye sokmamaktadir, sadece o 
terminalden hangi kullanicinin login olmaya calistigini ogrenebilir 
saldirgan. ticket cache'deki ticket'i kullanarak yapilacak bir 
saldirinin ise ticket'in gecerlilik suresi (sanirim max. 5 veya 10 
dakika) icerisinde yapilmasi gereklidir.

(ayrica parantez icinde belirtmek isterim ki, saldirgan oraya kadar 
girebilmisse rootkit de kurar, keylogger da kurar, o terminalden 
yurutulen butun trafigi ele gecirir zaten, kerberos'la tls'le niye ugrassin)

ssl'in sertifika dagitim protokolunde ise boyle bir guven donusumu yok. 
gelen sertifikanin fingerprint'ini manuel olarak kontrol etmek 
gerekiyor, bunu da kimseye yaptiramazsiniz. eger ciddi bir kimlik 
dogrulama protokolu olarak ssl/tls tercih edilecekse, bu ozelligin 
(sertifika dogrulama) protokole eklenmesi lazim. ya da dedigim gibi 
sertifikalarin terminallere guvenilir bir sekilde onceden kurulmasi, ve 
daha sonradan bu sertifikalarin cesitli sebeplerle (askere giden it 
personeli yerine gelen eleman, "bunun sifresi neydi merve'cigim" diyen 
personel kankasi, priviledge escalation, vesair vesair) 
degistirilmediginden emin olunmasi lazim.

bu da yetmiyormus gibi, ssl/tls sisteminde private key ele gectigi an, o 
andan sonraki (eger iletisimi kaydediyorsa onceki de olabilir, emin 
degilim) butun konusmalar saldirganin eline geciyor. kerberosta boyle 
bir risk yok. kerberosta PKI yonetimi diye birsey de yok zaten, hersey 
otomatik oluyor.

hatta ve hatta, dunyada kurulmus tum ahenk benzeri sistemler (active 
directory dahil) kerberos kullanmakta, ustelik bu sistemler biraz 
entegrasyon cabasiyla birbiriyle konusabilmektedir. (inanmazsiniz ama 
microsoft bile kerberos protokolune cok bir degisiklik yapamamistir.) 
kisaca kerberos kullanilmasi ahenk'in it sektorunde daha kolay kabul 
edilmesini de saglayacaktir.

kisaca, hem yonetimi daha kolay oldugu icin, hem de guvenli oldugu icin, 
hem de sektorde kabul edilmis de facto bir standart oldugu icin kerberos 
tercih edilmelidir. eger anlattigim kripto algoritmalarinda bir 
yanlislik yoksa (ki, tekrar ediyorum, bu mumkundur) benim gorusum budur.

saygilarimla,
burak




Gelistirici mesaj listesiyle ilgili daha fazla bilgi