RADIUS Sunucusu Nedir? 802.1X ile Ağ Kimlik Doğrulama

RADIUS sunucusu, ağa bağlanmak isteyen bir kullanıcının kimliğini merkezi olarak doğrulayan ve ona hangi erişimin verileceğine karar veren sunucudur. Bir ayrımı baştan koyalım: aslında RADIUS’un kendisi bir protokoldür; “RADIUS sunucusu” dediğimiz şey ise o protokolü konuşan ve kararı veren roldür, Windows’ta NPS, Linux’ta FreeRADIUS üstlenir. Kablosuz ağa bağlanan ya da bir switch portuna kablo takan cihaz, henüz ağa alınmadan önce kimlik sorgusundan geçer; bu sorgunun cevabını veren yer o sunucudur. Trafiği UDP üzerinde 1812 ve 1813 portlarından akar.

Buradaki asıl incelik şudur: soruyu siz sormuyorsunuz. Kartlı bir ödemeyi düşünün. Kasada kartınızı uzatırsınız, ama kasiyer hesabınızda para olup olmadığını bilmez ve bilmesine de gerek yoktur. POS cihazı sizin bankanıza sorar, banka onay ya da red döner, kasiyer de yalnızca o cevabı uygular. Siz bankanızla hiç konuşmazsınız. RADIUS tam olarak bu modeldir: istemci ile kimlik sunucusu arasında hiçbir doğrudan kanal yoktur, araya giren cihaz sizin adınıza merkeze sorar. Bu makale boyunca o kasada kalacağız.

Adı bugün kimseye bir şey anlatmayan bir fosil taşıyor: Remote Authentication Dial-In User Service. Protokol 1991’de, kullanıcıların modemle çevirmeli bağlantı kurduğu bir dünyada, Livingston Enterprises’ta doğdu. Çevirmeli bağlantı öleli çok oldu, RADIUS ölmedi; çünkü çözdüğü problem modeme değil, merkezi kimlik doğrulamaya aitti.

Bu eski protokolle benim tanışmam çok daha yeniydi. RADIUS’u ilk kez, masamdaki yönetilebilir bir lab switch’inde AAA’yı, yani ağın kimi içeri alacağını ve neye yetkilendireceğini öğrenmeye çalışırken kurdum: ilk RADIUS sunucumu ayağa kaldırıp bu switch’i ona bağladığımda, kendi kullanıcı adımla ağa alındığım ilk anı hala hatırlıyorum. O switch bugün de aynı masamda duruyor.

Aşağıda önce RADIUS’un ne olduğunu ve araya giren cihazın rolünü, sonra dört mesajdan oluşan sorgu akışını ve paylaşılan anahtarın neden zayıf olduğunu göreceğiz. Ardından 802.1X ile EAP yöntemlerini, RADIUS’un Kerberos ve LDAP arasındaki yerini, NPS ile FreeRADIUS arasındaki platform kararını ve son olarak ağa bağlanamayan bir kullanıcıda izlenecek teşhis sırasını kuracağız. Şu an elinizde bağlanamayan bir cihaz varsa doğrudan teşhis bölümüne atlayabilirsiniz.

Bu makale kurumsal network kurulumu hizmetimizin ağa giriş katmanına odaklanır; RADIUS’un içinde yer aldığı protokol zincirinin tamamını kurumsal ağ protokolleri rehberimizde ele alıyoruz.

RADIUS Sunucusu Nedir ve Ne İşe Yarar?

RADIUS sunucusu, ağ erişim kararını tek bir merkeze taşıyan kimlik doğrulama sunucusudur. Onsuz her switch, her erişim noktası ve her VPN sunucusu kendi kullanıcı listesini kendi içinde tutar; RADIUS ile hepsi aynı yere sorar ve karar tek yerden verilir. Protokolün tanımı Haziran 2000 tarihli RFC 2865 belgesidir.

Bu cümle kulağa idari bir düzenleme gibi geliyor, oysa çözdüğü şey son derece somut. Kırk switch’i olan bir kurumda ortak yönetici parolasını değiştirmek istediğinizde kırk cihaza tek tek bağlanmanız gerekir, ve birini atladığınızda hangisini atladığınızı bilemezsiniz.

Üç yüz çalışanın bildiği tek bir Wi-Fi parolası varsa, işten ayrılan kişi o parolayı da yanında götürür; parolayı değiştirdiğinizde ise üç yüz cihazı yeniden yapılandırmak zorunda kalırsınız. RADIUS bu iki tabloyu da ortadan kaldırır: erişim artık cihazın üzerinde tanımlı bir sırra değil, kişinin kurumsal hesabına bağlıdır. Hesap kapandığı an erişim de kapanır.

Araya Giren Cihaz: Soruyu Sizin Yerinize O Sorar

RADIUS mimarisinde üç taraf vardır ve ortadaki taraf, protokolü diğer kimlik doğrulama protokollerinden ayıran şeydir. Kasadaki tabloyla eşlemek gerekirse:

• İstemci (siz): ağa girmek isteyen laptop, telefon ya da yazıcı. Kartını uzatan kişi.
• NAS (kasiyer ve POS cihazı): switch, kablosuz erişim noktası ya da VPN sunucusu. Kararı vermez, soruyu iletir ve gelen cevabı uygular.
• RADIUS sunucusu (banka): kimliği doğrulayan, policy’yi işleten ve cevabı üreten merkez.

Ortadaki cihazın adı NAS (Network Access Server) ve isimlendirme ilk bakışta kafa karıştırıcıdır, çünkü burada bir “sunucu” gibi davranmaz. Yaptığı iş bir aracılıktır: sizden aldığı credential’ı (kimlik bilgisi) RADIUS sunucusuna taşır, dönen kararı porta uygular. Kendi başına “bu kullanıcı geçebilir” diyemez, tıpkı POS cihazının hattı koptuğunda kasiyerin “boş ver, geçebilirsin” diyememesi gibi.

Bu üçlü yapının pratikte iki sonucu var. Birincisi, ağa giren cihaz RADIUS sunucusunun adresini hiç bilmez; onunla konuşan taraf switch’tir. İkincisi, RADIUS sunucusunun ağdaki konumu istemciden tamamen bağımsızdır: sunucu başka bir binada, hatta başka bir lokasyonda olabilir, istemci bunu fark etmez. Merkezileştirmeyi mümkün kılan da bu ayrımdır.

AAA: RADIUS’un Üç İşi

RADIUS üç iş yapar ve bu üçlü literatürde AAA kısaltmasıyla anılır. Sırayla:

1. Authentication (kimlik doğrulama): “Bu kişi gerçekten iddia ettiği kişi mi?” Kart gerçek mi, şifre doğru mu?
2. Authorization (yetkilendirme): “Doğru kişi, peki neye hakkı var?” Kartınız geçerli olabilir ama limitiniz beş yüz liraysa bin liralık işlem geçmez. Ağ tarafında bunun karşılığı, doğrulanan kullanıcının hangi VLAN’a düşeceği ve hangi kaynaklara erişebileceğidir.
3. Accounting (kayıt): “Kim, ne zaman, ne kadar?” Ekstrede görünen satır. Oturumun ne zaman başladığı, ne zaman bittiği ve ne kadar trafik aktığı bu adımda kaydedilir.

Üçünün ayrı ayrı sayılması gereksiz bir titizlik gibi görünebilir, ama sahada arızanın hangi harfte olduğunu bilmek teşhis süresini doğrudan kısaltır. Kullanıcı hiç bağlanamıyorsa sorun birinci harftedir. Bağlanıyor ama yanlış VLAN’a düşüyorsa, kimlik doğrulaması çalışmış, ikinci harf yanlış yapılandırılmıştır. Bu ayrımı teşhis bölümünde tablo halinde kuracağız.

İkinci ve üçüncü harf farklı portlarda akar: kimlik doğrulama 1812, kayıt 1813 numaralı UDP portunu kullanır. Bu, protokolün kendi geçmişinin bir izidir; RADIUS ilk yıllarında 1645 ve 1646 portlarını kullanıyordu, o portlar başka bir uygulamaya tahsisliydi ve numaralar sonradan taşındı. Eski bazı cihazların varsayılanı hâlâ 1645 olabilir, ve iki taraf farklı porta bakıyorsa istek hiç ulaşmaz.

RADIUS Nasıl Çalışır? Access-Request’ten Access-Accept’e

RADIUS’un kimlik doğrulama akışı dört mesaj tipinden oluşur ve bunların yalnızca ikisi tek bir turda kullanılır. İstemci ağa girmeye çalıştığında NAS bir Access-Request gönderir, RADIUS sunucusu da üç cevaptan birini döner: Access-Accept, Access-Reject ya da Access-Challenge.

Provizyon isteğiyle aynı yapıdır. Kasiyer tutarı girer, POS bankaya sorar, banka onaylar ya da reddeder; bazen de “bu işlem için şifre girilsin” der ki bu da üçüncü cevap tipidir. Konuşma tek turda bitmeyebilir.

Dört Mesaj ve Ne Anlama Geldikleri

Dördünün ne zaman devreye girdiği şöyle ayrışır:

1. Access-Request: NAS’tan sunucuya giden tek istek tipidir. Kullanıcı adını, NAS’ın kimliğini, bağlantının hangi porttan geldiğini ve credential’ı taşır.
2. Access-Accept: Erişim onaylandı. Bu mesaj yalnızca “evet” demez, yetkilendirme bilgisini de taşır: kullanıcının düşeceği VLAN, uygulanacak erişim listesi, oturum süresi sınırı gibi değerler bu paketin içinde döner.
3. Access-Reject: Erişim reddedildi. Protokol gereği sebep bildirmek zorunda değildir ve çoğu yapılandırmada bildirmez de; teşhis bilgisi istemciye değil, sunucunun kendi kaydına yazılır. Kullanıcı yalnızca bağlanamadığını görür.
4. Access-Challenge: “Yeterli değil, devam et.” Sunucu ek bilgi ister ve konuşma bir tur daha sürer.

Kayıt tarafı ayrı bir çift mesajla yürür: oturum başlarken Accounting-Request Start, biterken Accounting-Request Stop gönderilir ve her birine sunucu Accounting-Response ile karşılık verir. Bu çifti ayrı bir belge, yine Haziran 2000 tarihli RFC 2866 tanımlar. Kimlik doğrulama başarısız olduğunda bu çift hiç oluşmaz, dolayısıyla kayıt tarafında hiç görünmeyen bir cihaz genellikle ilk adımda takılmış cihazdır.

Access-Challenge: Tek Turda Bitmeyen Konuşma

Access-Challenge, RADIUS’un tek soruluk bir sorgudan çok turlu bir konuşmaya dönüştüğü yerdir ve modern kurulumların neredeyse tamamında devreye girer. Sebebi basit: sertifika tabanlı kimlik doğrulama tek pakete sığmaz.

Kartlı ödemede bunun karşılığı, POS’un ekrana “şifrenizi girin” yazdığı andır. Banka henüz onay vermemiştir, reddetmemiştir de; konuşmayı sürdürmek için sizden bir şey ister. Ağ tarafında bu tur sayısı ondan fazla olabilir, çünkü karşılıklı sertifika alışverişi parça parça taşınır.

Bunun teşhis açısından önemli bir sonucu var. Yakaladığınız trafikte tek bir Access-Request ve hemen ardından gelen bir Access-Reject görüyorsanız, konuşma daha başlamadan bitmiş demektir ve sorun büyük ihtimalle kullanıcı kimliğinde değil, öncesindedir. Buna karşılık onlarca Access-Challenge turundan sonra gelen bir Access-Reject, sertifika ya da policy tarafına işaret eder. Aynı hata mesajını veren iki farklı arıza, paket sayısıyla birbirinden ayrılır.

Shared Secret: RADIUS’un En Zayıf Halkası

RADIUS’ta NAS ile sunucu arasındaki güven, iki tarafa da elle yazılan shared secret adlı ortak bir parolaya dayanır. Bu parola trafikte hiç gönderilmez; paketlerin doğruluğunu ispatlamak ve kullanıcı parolasını gizlemek için kullanılır.

Sorun, bunun nasıl yapıldığındadır. Protokolün orijinal tasarımı MD5 üzerine kuruludur ve paketin tamamını şifrelemez: yalnızca kullanıcı parolasını taşıyan alan gizlenir, geri kalan her şey açık gider. Kullanıcı adı, NAS’ın adresi, hangi porttan bağlanıldığı ve dönen VLAN bilgisi ağı dinleyen biri için okunabilir haldedir.

Bu zayıflık RADIUS’u kullanılamaz yapmaz, ama iki pratik kural doğurur. Birincisi, RADIUS trafiği kullanıcı trafiğiyle aynı yerde dolaşmamalı; yönetim ağında kalmalıdır. İkincisi, kullanıcı parolasının korunması shared secret’a bırakılmamalıdır. Modern kurulumlarda parolayı koruyan şey RADIUS’un kendi şifrelemesi değil, üzerine kurulan EAP tünelidir; bir sonraki bölümün konusu tam olarak budur.

Protokolün bu tarafını düzeltmek için RadSec adıyla bilinen, RADIUS’u TLS üzerinde taşıyan bir yöntem de var. Kurumsal ağlarda henüz yaygın değildir ve desteği cihaz tarafında sınırlıdır; ama RADIUS trafiğinin lokasyonlar arasında, kurum sınırının dışından geçtiği yapılarda gündeme gelmesi gereken bir seçenektir.

RADIUS Trafiğini Wireshark ile İzlemek

Buraya kadar RADIUS’un ne söz verdiğini anlattık: parola gizlenir, geri kalanı açık gider, konuşma bazen çok turlu olur. Şimdi bu sözleri ağ üzerinde doğrulayalım. Bir FreeRADIUS sunucusunda 1812 portunu dinlerken bir kimlik doğrulama turu çalıştırıp yakalanan paketlere baktım; aşağıdaki çıktılar o yakalamadan.

En basit tur, yani parolayla doğrudan doğrulama (PAP) yakalandığında iki paket görünür:

IP 127.0.0.1.42648 > 127.0.0.1.1812: RADIUS, Access-Request (1), length: 78
IP 127.0.0.1.1812 > 127.0.0.1.42648: RADIUS, Access-Accept (2), length: 38

Bir istek gitti, bir kabul döndü. Asıl mesele Access-Request’in içindedir. Paketi tshark ile açmadan önce şu üç şeye bakacağımızı aklınızda tutun: kullanıcı adı nasıl görünüyor, parola nasıl görünüyor, geri kalan alanlar nasıl görünüyor.

RADIUS Protocol
    Code: Access-Request (1)
    Attribute Value Pairs
        AVP: t=User-Name(1) val=testuser
        AVP: t=User-Password(2) val=Encrypted
            User-Password (encrypted): 504f2ecbe9e3fe3a777f370faf6aa128
        AVP: t=NAS-IP-Address(4) val=127.0.1.1
        AVP: t=NAS-Port(5) val=0

Bu dökümün söylediği tam olarak şudur:

1. User-Name = testuser: kullanıcı adı düz metin, olduğu gibi okunabilir.
2. User-Password (encrypted): parola 16 baytlık, okunamaz bir blok. Gizlenen tek alan budur.
3. NAS-IP-Address ve NAS-Port: hangi cihazdan, hangi porttan bağlanıldığı açık.

İşte yazının başında verdiğimiz sözün kanıtı: yalnızca parola gizli, geri kalan her şey açık gidiyor. Ağı dinleyen biri kimin nereden bağlandığını görür, yalnızca parolayı göremez. Kasadaki benzetmeye dönersek, provizyon fişinde kartın hangi mağazadan ve hangi kasadan geçtiği yazar; fişte görünmeyen tek şey PIN’dir.

Peki parola yanlışsa? Aynı turu bilerek yanlış parolayla çalıştırdığımda üçüncü mesaj tipi çıktı:

IP 127.0.0.1.37349 > 127.0.0.1.1812: RADIUS, Access-Request (1)
IP 127.0.0.1.1812 > 127.0.0.1.37349: RADIUS, Access-Reject (3)

Access-Reject. Sunucu sebebini istemciye bildirmez, yalnızca reddeder; nedeni kendi kaydına yazar. Kullanıcı yalnızca bağlanamadığını görür.

Şimdi 802.1X’in kullandığı EAP’a bakalım, çünkü orada konuşma tek turda bitmez. Bir EAP turu yakaladığımda araya dördüncü mesaj tipi girdi:

Access-Request (1)    → istemci: kimliğim testuser
Access-Challenge (11) → sunucu: şu meydan okumaya cevap ver
Access-Request (1)    → istemci: işte cevabım
Access-Accept (2)     → sunucu: kabul

Access-Challenge (11): sunucu “gönderdiğin yeterli değil, devam et” diyor ve tur uzuyor. Gerçek PEAP’te bu turlar onlarca olur, çünkü araya bir de TLS tüneli kurulur. Bu sayı teşhiste işe yarar: tek Request’in hemen ardından gelen bir Reject, konuşmanın hiç başlamadığını; uzun bir Challenge dizisinden sonraki Reject ise sertifika ya da policy sorununu işaret eder.

Son olarak muhasebe (accounting) 1813 portunda ayrı akar ve kendi mesaj çiftini kullanır:

Accounting-Request (4)  → oturum başladı: sess001
Accounting-Response (5) → kaydedildi

Beş mesaj tipinin hepsini ağ üzerinde gördük: Request, Accept, Reject, Challenge ve Accounting çifti. Bu akışı kendi sunucunuzda kurup yakalamak isterseniz, kurulumdan paket yakalamaya kadar her adımı FreeRADIUS kurulum rehberimizde anlatıyoruz.

802.1X ve EAP: Kimlik Doğrulanmadan Açılmayan Port

802.1X, bir switch portunun ya da kablosuz bağlantının kimlik doğrulanana kadar kapalı kalmasını sağlayan standarttır. RADIUS kararı verir, 802.1X o kararın uygulandığı yerdir. İkisi ayrı şeylerdir ve sahada sürekli birbirinin yerine kullanılırlar.

Aradaki farkı kasadaki tabloya oturtmak kolay: RADIUS bankanın verdiği cevapsa, 802.1X kasanın çalışma kuralıdır. “Provizyon gelmeden ürün müşteriye verilmez” kuralı. Kural olmasa banka onayı da bir işe yaramaz; kasiyer cevabı beklemeden ürünü uzatır.

Kapalı port ifadesi burada mecaz değil. 802.1X yapılandırılmış bir portta cihaz kabloyu taktığında elektriksel bağlantı kurulur, ama porttan kimlik doğrulama trafiği dışında hiçbir paket geçmez. Cihazın gördüğü tablo şudur: kablo takılı, bağlantı ışığı yanıyor, hiçbir şey çalışmıyor. Bu belirti çoğu teknisyeni kablo ve switch portu kontrol etmeye götürür, oysa katman çok daha yukarıdadır.

Bu kapının bir switch’te nasıl kurulduğunu, açılış anında hangi portları kapattığını ve 802.1X konuşamayan yazıcının MAC adresiyle nasıl içeri alındığını switch 802.1X yapılandırması yazımızda ölçtüm.

802.1X’in Üç Rolü

802.1X’te taraflar RADIUS’takiyle aynıdır ama standart onlara kendi adlarını verir, ve bu adları bilmek cihaz yapılandırma ekranlarında işinizi kolaylaştırır:

• Supplicant: kimlik sunan taraf, yani istemcinin kendisi. Windows’ta bu iş Wired AutoConfig ve WLAN AutoConfig servislerine aittir; kablolu tarafta bu servis varsayılan olarak kapalıdır ve açılmadığı sürece cihaz porta hiç cevap vermez.
• Authenticator: switch ya da kablosuz erişim noktası. RADIUS tarafındaki NAS ile aynı cihazdır, yalnızca farklı standardın diliyle anılır.
• Authentication Server: RADIUS sunucusu. Kararı veren taraf.

Supplicant tarafındaki o kapalı servis, geçiş projelerinde en çok zaman kaybettiren ayrıntılardan biridir: sunucu tarafı kusursuz kuruludur, switch doğru yapılandırılmıştır, ama istemci sessizdir. Sunucu kayıtlarında hiçbir istek görünmez, çünkü ortada gönderilmiş bir istek yoktur.

PEAP-MSCHAPv2 ile EAP-TLS Arasındaki Fark

Credential’ın nasıl taşınacağını EAP (Extensible Authentication Protocol) belirler ve kurumsal ağlarda pratikte iki yöntem kullanılır. Aralarındaki fark, kullanıcının neyle kimliğini kanıtladığıdır:

PEAP kurulumu kolay olduğu için yaygındır. EAP-TLS ise daha güçlüdür, çünkü ortada çalınabilecek bir parola yoktur; ama her istemciye sertifika dağıtmayı ve o sertifikaların süresini takip etmeyi gerektirir. Dağıtımı otomatikleştirmeden EAP-TLS’e geçmek, bir yıl sonra hepsi aynı hafta içinde süresi dolan bir cihaz filosu bırakır.

Seçimi belirleyen soru şu: cihazlarınız yönetiminizde mi? Domain’e üye, policy’yle yönetilen bir filoda EAP-TLS gerçekçidir. Çalışanların kendi telefonlarının da bağlandığı bir ağda ise sertifika dağıtımı pratikte çalışmaz ve PEAP kalır.

İki yöntemin de dayandığı sertifikaların nereden geldiği, kimin bastığı ve istemcilerin onlara neden güvendiği başlı başına bir konudur; sertifika otoritesi rehberimizde güven zincirini ve iç CA ile public CA arasındaki kararı ele alıyoruz.

PEAP’in Güvenliği İstemcinin Elindedir

PEAP’te asıl korumayı sağlayan şey parolanın kendisi değil, parolanın içinden geçtiği TLS tünelidir; ve o tünelin güvenli olup olmadığına istemci karar verir. Bu cümle PEAP’in en çok atlanan tarafıdır. O tünelin hangi sürümle kurulduğunu ve pazarlığında ne göründüğünü ayrı bir yazıda açtık.

Akış şöyle işler: istemci bağlanırken RADIUS sunucusu kendi sertifikasını sunar, istemci bu sertifikayı tanıdığı bir kök otoriteye ait mi diye kontrol eder, doğruysa tüneli kurar ve parolayı ancak o tünelin içinden gönderir. Zincirdeki kritik halka ortadaki kontroldür. İstemci “sertifikayı doğrulama” ayarıyla yapılandırılmışsa, aynı ağ adını yayınlayan sahte bir erişim noktasına da aynı güvenle bağlanır ve parolasını oraya teslim eder.

Kasadaki karşılığı şudur: şifrenizi girdiğiniz cihazın gerçekten bankaya bağlı bir POS olduğunu kontrol etmeden tuşlamak. Cihaz doğruysa sorun yoktur; kontrol etmediğiniz için, olmadığında da haberiniz olmaz.

Bu yüzden bir 802.1X kurulumunun kalitesi sunucu tarafına bakılarak ölçülemez. Sunucu doğru kurulmuş, policy’ler düzgün yazılmış olabilir; korumanın gerçekleştiği yer istemci yapılandırmasıdır.

RADIUS, Kerberos ve LDAP: Sıra Neden RADIUS’la Başlar?

RADIUS, Kerberos ve LDAP’ın üçü de kimlikle ilgilenir ama farklı anlarda devreye girerler: RADIUS ağa girerken, Kerberos ağa girdikten sonra servislere erişirken, LDAP ise o kişinin neye yetkili olduğu sorulduğunda. Sıra tesadüf değil, bağımlılık zinciridir.

Bunu gündelik bir sırayla eşlemek mümkün: önce mağazaya girersiniz, sonra kasada kimliğinizi ispatlarsınız, sonra hangi kampanyaya dahil olduğunuza bakılır. Adımların yeri değişmez, çünkü her biri bir öncekinin çıktısına muhtaçtır.

Üç Protokolün İş Bölümü

Ayrım, hangi sorunun cevaplandığına bakılarak netleşir:

1. RADIUS: “Bu cihaz ağa girebilir mi?” Henüz IP adresi bile yoktur. Doğrulama başarısızsa cihaz DHCP’ye bile ulaşamaz, dolayısıyla zincirin geri kalanı hiç başlamaz.
2. Kerberos: “Bu kullanıcı gerçekten o mu?” Ağa girilmiştir, kullanıcı oturum açar ve süreli bir biletle servislere kimliğini kanıtlar. Bilet mantığını ve arıza teşhisini Kerberos nedir rehberimizde ele alıyoruz.
3. LDAP: “Bu kullanıcı neye yetkili?” Grup üyeliği, hangi birimde olduğu ve hangi kaynağa erişebileceği dizinden okunur. Dizin sorgusunun nasıl kurulduğunu LDAP nedir rehberimizde paket düzeyinde açıyoruz.

Buradan çıkan ve teşhiste çok işe yarayan bir sonuç var: RADIUS arızası, kendini RADIUS arızası gibi göstermez. Kullanıcı size “internet yok” der, siz DHCP’ye ve DNS’e bakarsınız, ikisi de sağlıklıdır. Çünkü cihaz o katmanlara hiç ulaşmamıştır. Zincirin ilk halkası koptuğunda belirtiler ikinci ve üçüncü halkaya aitmiş gibi görünür.

Üçü arasındaki ilişkiyi tamamlayan bir ayrıntı daha var: RADIUS sunucusu kendi kullanıcı listesini tutmaz. NPS kullanıcıyı Active Directory’de doğrular, FreeRADIUS de çoğu kurumsal kurulumda aynı dizine bağlanır. Yani RADIUS, Kerberos ve LDAP’ın alternatifi değildir; onların önüne yerleşen ve aynı dizine danışan bir kapıdır.

RADIUS ile TACACS+ Farkı: Cihaz Yönetimi Tarafı

RADIUS kullanıcıyı ağa alır, TACACS+ ise yöneticiyi cihazın kendisine alır. İkisi rakip gibi görünür, oysa farklı işleri daha iyi yaparlar. TACACS+‘ın kendisini ve gövdedeki korumanın neden şifreleme sayılmadığını TACACS+ nedir yazımızda, switch’te komut bazlı yetkiyi lab’da nasıl kurduğumuzu switch TACACS+ yapılandırması yazımızda anlattık:

Aradaki en pratik fark son iki satırdadır. TACACS+ ile bir yöneticinin yalnızca belirli komutları çalıştırmasına izin verebilirsiniz; RADIUS’ta yetki, oturum açarken verilen kaba bir seviyeden ibarettir. Cihaz yönetiminde denetim ihtiyacı yüksekse fark burada hissedilir.

Sahada gördüğüm tablo şu: çok sayıda kurum, ağ cihazı yönetimini de RADIUS ile yapıyor. Bunun sebebi TACACS+‘ın yetersizliği değil, RADIUS’un zaten kurulu olması. Kendi projelerimizde de bu yolu seçtiğimiz oldu. Bir switch’i NPS’e bağlayıp yetki seviyesini ve kaydın neleri tuttuğunu lab’da switch RADIUS yapılandırması yazımızda ölçtük. Aynı işi bir firewall’da FreeRADIUS ile kurup grup eşlemesinin neden şart olduğunu FortiGate RADIUS yönetici girişi yazımızda gösterdik.

Onlarca switch’in yönetici parolasının yıllardır değişmediği, o parolayı bilen herkesin işten ayrıldıktan sonra da bilmeye devam ettiği bir kurumda, on üç lokasyondaki switch girişini kişisel Active Directory hesaplarına bağladık. Ortak parolayı değiştirmedik, kaldırdık. Ağ yöneticileri kendi hesaplarıyla giriyor, stajyerlere yapılandırmayı bozmasınlar diye salt okunur yetki tanımlandı, ve merkezi sunucuya ulaşılamadığı durum için switch’in yerel hesabına düşen bir yedek yol bırakıldı.

Buradaki salt okunur ayrımı RADIUS’un kaba yetki seviyesiyle çözülebilen bir ihtiyaçtı; komut bazında ayrım gerekseydi karar TACACS+ yönünde olurdu. Kurulumun tamamını ağ erişimi sıkılaştırma vaka çalışmasında anlatıyoruz.

Karar kuralı olarak şunu kullanabilirsiniz: yöneticinin hangi komutu çalıştırdığını denetlemeniz gerekiyorsa TACACS+, “kim, ne zaman, hangi cihaza girdi?” sorusunu cevaplamak yetiyorsa RADIUS. İkincisi çoğu KOBİ ölçeğinde yeterlidir ve zaten kurulu olan altyapıya bir kalem daha eklemez.

RADIUS Sunucusu Nerede Çalışır? NPS ve FreeRADIUS

RADIUS sunucusu bir ürün değil, bir roldür; o rolü Windows tarafında NPS (Network Policy Server), Linux tarafında FreeRADIUS üstlenir. İkisi de aynı protokolü konuşur, dolayısıyla switch tarafındaki yapılandırma neredeyse aynıdır. Fark, kimlik deposuna nasıl bağlandıkları ve kimin bakımını üstleneceğidir.

NPS ayrı bir ürün değil, Windows Server’ın bir rolüdür: mevcut bir Windows sunucusuna eklenirse ek lisans çıkmaz, ama best practice olan ayrı bir sunucuya kurulduğunda o sunucunun Windows Server lisansı ve gerekiyorsa CAL’ları devreye girer. En güçlü yanı Active Directory’ye doğrudan bağlanması: kullanıcı ve grup bilgisi zaten oradadır, ayrı bir kullanıcı deposu kurmanız gerekmez. FreeRADIUS ise açık kaynaktır, esnekliği çok daha yüksektir ve karmaşık policy senaryolarında NPS’in yapamadığı şeyleri yapar; buna karşılık yapılandırması dosya tabanlıdır ve öğrenme eğrisi diktir.

Hangi Platform Hangi Ortama Uygun?

Karar, teknik üstünlükten çok ortamın kendisine bağlıdır:

Tablodaki ölçüt bilinçli olarak “hangisi daha iyi” değil. Bir kimlik sunucusu kurumun en kritik bileşenlerinden biridir ve çöktüğünde kimse ağa giremez; dolayısıyla onu gece yarısı ayağa kaldıracak ekibin tanıdığı platform, teknik olarak daha zengin olan platformdan daha değerlidir.

İki platformun kurulumunu burada anlatmıyoruz, ikisi de kendi rehberinde duruyor: FreeRADIUS kurulumu ve Windows Server NPS kurulumu. Bu makalenin konusu, o kurulumların ortak zeminini oluşturan protokolün kendisi.

Tek RADIUS Sunucusu Neden Yetmez?

Tek RADIUS sunucusuyla çalışan bir ağda o sunucu durduğunda kimse ağa giremez, ve bu abartı değil tanımın kendisidir: 802.1X yapılandırılmış bir portun varsayılan davranışı, cevap alamadığında kapalı kalmaktır.

Bu yüzden yedeklilik bir iyileştirme değil, kurulumun parçasıdır. Üç önlem birlikte alınır:

1. İkinci bir RADIUS sunucusu tanımlayın. Switch ve erişim noktaları birden fazla sunucu tanımlamayı destekler; birincisi cevap vermediğinde ikincisine geçerler.
2. Ağ cihazlarının yerel yönetici hesabını silmeyin. Günlük kullanımdan çıkarın ama bırakın: merkezi sistem çöktüğünde cihaza girmenin tek yolu odur.
3. Kritik cihazlar için portun davranışını bilinçli seçin. Bazı senaryolarda, RADIUS erişilemezken portun sınırlı bir VLAN’a düşmesi tamamen kapanmasından iyidir. Bu bir güvenlik ödünüdür ve kasıtlı verilmelidir.

RADIUS Teşhisi: Bağlanamayan Kullanıcıda Sıra

RADIUS arızasında teşhis, belirtiyi doğru katmana yerleştirmekle başlar. Kullanıcı size neredeyse her zaman “internet yok” ya da “ağa bağlanamıyorum” der; oysa bu iki cümle birbirinden çok farklı iki arızayı da anlatabilir.

Ayrımı yapan soru şudur: cihaz hiç ağa alınmadı mı, yoksa alındı da yanlış yere mi alındı? Birincisi kimlik doğrulama, ikincisi yetkilendirme sorunudur ve ikisinin bakılacak yeri farklıdır.

Belirtiden Sebebe

Tablodaki dördüncü satır özellikle sinsidir. Sertifika süresi dolduğunda hiçbir şey değişmemiştir: yapılandırmaya dokunulmamış, switch’e girilmemiş, policy düzenlenmemiştir. Değişen tek şey tarihtir, ve arıza bu yüzden “hiçbir şey yapmadık, kendi kendine bozuldu” diye bildirilir.

Teşhis Sırası

Sıra, aramayı her adımda yarıya bölecek biçimde kurulur. Sunucudan başlamayın, çünkü sunucu tarafındaki kayıtlar isteğin oraya ulaşmış olmasını varsayar:

1. Aynı porttaki ya da aynı ağdaki başka bir cihaz bağlanıyor mu? Bu tek soru aramayı ikiye böler. Tek cihaz etkileniyorsa sorun o cihazda ya da kullanıcı hesabında; herkes etkileniyorsa sunucuda, sertifikada veya yoldadır.
2. İstemci tarafı istek gönderiyor mu? Kablolu bağlantıda Wired AutoConfig servisi kapalıysa cihaz hiç konuşmaz. Sunucuda hiçbir kayıt yoksa ve cihaz sessizse, sorun burada aranır.
3. Sunucu isteği görüyor mu? Windows tarafında Event Viewer üzerinden Custom Views altındaki Server Roles görünümü bu kayıtları taşır. İstek hiç görünmüyorsa arada bir yol sorunu vardır: 1812 portu kapalı olabilir ya da o cihaz sunucuda tanımlı olmayabilir.
4. İstek görünüyor ama reddediliyorsa reddin sebebine bakın. Kayıt yalnızca “reddedildi” demez; hangi policy’nin eşleştiğini ya da hiçbirinin eşleşmediğini de yazar. Policy eşleşmemesi ile kimlik hatası farklı satırlardır.
5. Reddin sebebi policy’yse grup üyeliğini ve policy sırasını kontrol edin. Policy’ler yukarıdan aşağıya değerlendirilir ve ilk eşleşen uygulanır; yanlış sırada duran geniş bir policy, altındakileri hiç çalıştırmaz.

Beşinci adım, kurulumdan aylar sonra ortaya çıkan arızaların en sık kaynağıdır. Yeni bir policy eklenirken listenin üstüne konur, kimse sırayı kontrol etmez ve o güne kadar çalışan bir kural sessizce devre dışı kalır.

Bu sıranın dördüncü ve beşinci adımları sunucunun kendi kayıtlarına dayanır. İstek sunucuya hiç ulaşmıyorsa ya da neyin taşındığını görmeniz gerekiyorsa, tek yol trafiği doğrudan okumaktır.

Sonuç: Kasiyer Kararı Vermez

RADIUS’un tek cümlelik özeti şudur: ağa giriş kararını cihazdan alıp merkeze taşır. Switch ve erişim noktası artık kendi üzerinde tutulan bir sırra göre değil, kurumun kimlik dizinine sorarak davranır. Paylaşılan parolanın kaldırılması, bir personel ayrıldığında erişimin kendiliğinden kapanması ve “kim, ne zaman, nereden?” sorusunun cevaplanabilir olması, hep bu tek değişikliğin sonucudur.

Protokolün kendisi otuz yılı aşkın bir tasarımdır ve zayıf tarafları vardır: paylaşılan anahtar zayıftır, paketin çoğu açık gider. Ama korumanın gerçekten kurulduğu yer protokolün kendisi değil, üzerine konan EAP tüneli ve o tüneli doğrulayan istemci yapılandırmasıdır. Bir 802.1X kurulumunu değerlendirirken bakılacak yer sunucu odası değil, kullanıcının makinesindeki ayardır.

Bu katmanın kurulum tarafını, yani envanterden izleme kipine ve zorlamanın açılmasına kadar işin nasıl yürüdüğünü ağ erişim kontrolü hizmetimizde anlattık. Ağa giriş katmanının ardından gelen halkaları, adres dağıtımından isim çözümlemesine ve kimlik doğrulamaya kadar tek bir zincir halinde kurumsal ağ protokolleri rehberimizde ele alıyoruz. Kablosuz tarafta bu kimlik katmanının fiziksel karşılığını, kapsama ve kanal planlamasını ise kablosuz ağ tasarımı rehberimizde bulabilirsiniz.

Yazan İlker Pehlivan

BT Danışmanı | Ağ, Sistem ve Güvenlik Yönetimi

İlker Pehlivan, karmaşık BT altyapılarını ölçeklenebilir ve güvenli sistemlere dönüştürür. Buradaki rehberleri kendi laboratuvarında kurup ölçerek yazar.

LinkedIn