[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