FreeRADIUS Kurulumu: Ubuntu'da Adım Adım

FreeRADIUS, Linux üzerinde çalışan açık kaynaklı bir RADIUS sunucusudur ve kurumsal ağa giriş kararını tek bir merkeze taşır. Bu rehberde Ubuntu üzerine sıfırdan bir FreeRADIUS sunucusu kurar, bir test kullanıcısı tanımlar, ilk kimlik doğrulamayı radtest ile doğrular ve arka planda ne konuşulduğunu paket düzeyinde izleriz. Sonunda çalışan, sınanmış bir RADIUS sunucunuz olur.

RADIUS’un ne olduğunu, dört mesajlık akışını ve 802.1X ile ilişkisini ayrı bir yazıda ele aldık: burada kavramı tekrar etmeyip doğrudan kuruluma giriyoruz. Protokolün kendisini merak ediyorsanız önce RADIUS sunucusu nedir rehberimize göz atın. Bu makale kurumsal network kurulumu hizmetimizin ağa giriş katmanının pratik, elimizi kirlettiğimiz tarafıdır.

Aşağıdaki adımların tamamını gerçek bir Ubuntu 24.04 sunucusunda çalıştırdım; gördüğünüz komut çıktıları o kurulumdan birebir alındı. Sizde de aynı sürümlerle çalışırsanız neredeyse aynı çıktıyı görmeniz gerekir.

FreeRADIUS Kurulumu: Paketler ve İlk Servis

Bu rehber, üzerine FreeRADIUS kuracağınız Ubuntu Server’ı zaten ayağa kaldırdığınızı varsayar. İşletim sistemi kurulumu, disk düzeni ve ilk ağ yapılandırması ayrı bir konudur ve Ubuntu Server kurulum rehberimizde ele alınmaktadır.

FreeRADIUS Ubuntu deposunda hazır paket olarak gelir, derlemeye gerek yoktur. İki paket kuruyoruz: sunucunun kendisi ve test araçları.

sudo apt-get update
sudo apt-get install -y freeradius freeradius-utils

freeradius sunucu servisini, freeradius-utils ise radtest ve radclient gibi kimlik doğrulamayı elle sınayacağınız araçları getirir. Kurulum bittiğinde servis kendiliğinden başlar. Sürümü ve servis durumunu doğrulayalım:

freeradius -v
systemctl is-active freeradius

radiusd: FreeRADIUS Version 3.2.5, for host x86_64-pc-linux-gnu
active

Bu noktada elinizde ayakta duran bir RADIUS sunucusu var, ama henüz hiçbir kullanıcı tanımlı değil ve yalnızca localhost üzerinden konuşabiliyor. Sıradaki iki adım tam olarak bu ikisini çözer.

İstemci ve Kullanıcı: clients.conf ve users

RADIUS’ta iki farklı “kimlik” tanımlanır ve bunlar sürekli karıştırılır: istemci ağdaki cihazdır (switch, erişim noktası), kullanıcı ise ağa girmek isteyen kişidir. İkisi ayrı dosyalarda durur.

İstemci (NAS) tanımı clients.conf dosyasındadır. Varsayılan kurulum, test için localhost’u zaten tanımlı getirir ve ortak parolası (shared secret) testing123’tür:

client localhost {
    ipaddr = 127.0.0.1
    secret = testing123
}

Gerçek bir switch eklerken bu bloğun bir benzerini switch’in IP’si ve kendine özel, uzun bir parolayla oluşturursunuz. Şimdilik localhost ilk testimiz için yeterli.

Kullanıcı tanımı ise users dosyasındadır. Dosya tabanlı bu yöntem, mekaniği görmek için en berrak olanıdır. Bir test kullanıcısı ekleyelim:

testuser Cleartext-Password := "TestParola123"

Bu satırı /etc/freeradius/3.0/mods-config/files/authorize dosyasının başına ekleyip servisi yeniden başlatıyoruz:

sudo systemctl restart freeradius

Cleartext-Password ifadesi kafa karıştırabilir: parolanın ağda açık dolaşacağı anlamına gelmez, yalnızca sunucunun parolayı karşılaştırmak üzere düz metin olarak sakladığını söyler. Parolanın ağ üzerindeki hali her zaman shared secret ile korunur, birazdan paket düzeyinde göreceğiz.

İlk Test: radtest ile Access-Accept

Kurulumun çalıştığını radtest ile, hiçbir switch’e ihtiyaç duymadan sınayabiliriz. radtest bir istemciyi taklit eder: verdiğiniz kullanıcı adı ve parolayı bir Access-Request paketine koyup sunucuya gönderir, dönen cevabı gösterir.

radtest testuser TestParola123 127.0.0.1 0 testing123

Buradaki alanlar sırasıyla: kullanıcı adı, parola, sunucu adresi, NAS port numarası ve shared secret. Doğru parolayla sonuç şudur:

Sent Access-Request Id 156 from 0.0.0.0:42648 to 127.0.0.1:1812 length 78
	User-Name = "testuser"
	User-Password = "TestParola123"
	NAS-IP-Address = 127.0.1.1
	NAS-Port = 0
Received Access-Accept Id 156 from 127.0.0.1:1812 to 127.0.0.1:42648 length 38

Received Access-Accept: sunucu kimliği kabul etti. Şimdi bilerek yanlış bir parola verip reddedilmeyi görelim, çünkü bir sistemin doğru çalıştığından emin olmak, yanlışı da doğru reddettiğini görmekten geçer:

radtest testuser YanlisParola999 127.0.0.1 0 testing123

Received Access-Reject Id 65 from 127.0.0.1:1812 to 127.0.0.1:37349 length 38

Kabul için Access-Accept, ret için Access-Reject. Sunucu artık kimlik doğruluyor. Ama ağ üzerinde tam olarak ne gidip geldiğini henüz görmedik ve RADIUS’un en çok yanlış bilinen tarafı da orada.

Ne Konuşuluyor? Paketi Yakalayıp Açmak

RADIUS’un güvenlik davranışını anlamanın en iyi yolu, bir kimlik doğrulama turunu yakalayıp içine bakmaktır. tcpdump ile 1812 portunu dinlerken bir radtest daha çalıştıralım:

sudo tcpdump -i lo -n "udp port 1812" -w radtest.pcap

Yakaladığımız turda iki paket görünür: giden Access-Request ve dönen Access-Accept.

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

Asıl mesele paketin içindedir. Aynı yakalamayı tshark ile açıp Access-Request’in alanlarına bakalım:

sudo tshark -r radtest.pcap -O radius

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

Burada RADIUS’un en kritik güvenlik gerçeği görünür hale gelir: yalnızca User-Password alanı şifrelidir, o da 16 baytlık okunamaz bir bloktur. Geri kalan her şey açık gider. User-Name alanında kullanıcı adı düz metin olarak (testuser), NAS’ın adresi ve bağlanılan port okunabilir haldedir. Ağı dinleyen biri kimin, nereden bağlandığını görür; yalnızca parolayı göremez.

Bunun iki pratik sonucu var. Birincisi, RADIUS trafiği kullanıcı trafiğiyle aynı yerde dolaşmamalı, yönetim ağında kalmalıdır. İkincisi, kablosuz ve 802.1X senaryolarında parolayı koruyan asıl katman RADIUS’un kendi şifrelemesi değil, üzerine kurulan EAP tünelidir. O katmanı ve gerçek 802.1X kurulumunu bir sonraki bölümde ele alacağız.

802.1X ve EAP: Sertifika, Tünel ve Access-Challenge

Buraya kadar PAP ile çalıştık; parolayı shared secret koruyordu. Kurumsal kablosuz ve kablolu ağlarda ise 802.1X ve EAP devreye girer, parola artık shared secret’a değil bir TLS tüneline emanet edilir. Bu tünel için sunucunun bir sertifikası olmak zorundadır, ilk kuracağımız şey odur.

Sunucu Sertifikasını Üretmek

FreeRADIUS’un EAP modülü varsayılan kurulumda etkin gelir; test için tek eksik sertifikadır. FreeRADIUS bunu üretecek betiği hazır getirir, certs dizininde çalıştırıyoruz:

sudo bash -c "cd /etc/freeradius/3.0/certs && make"

Bu komut self-signed bir sertifika otoritesi (CA) ve ona bağlı bir sunucu sertifikası (server.pem) üretir; PEAP’in TLS tünelini bu sertifika kurar. Lab için bu yeterlidir, ama gerçek bir filoda self-signed sertifikanın nerede yetip nerede yetmediği ayrı bir karardır: sertifika otoritesi rehberimize bakın. Diffie-Hellman parametreleri yüzünden üretim birkaç dakika sürebilir. Bittiğinde yapılandırmayı doğrulayıp servisi yeniden başlatıyoruz:

sudo freeradius -XC
sudo systemctl restart freeradius

Configuration appears to be OK çıktısını görmelisiniz.

Access-Challenge: Tek Turda Bitmeyen Konuşma

EAP ile kimlik doğrulama, PAP’ın aksine tek istek-cevap turunda bitmez. Bunu radeapclient ile bir EAP-MD5 turu çalıştırıp görebiliriz:

printf "User-Name=testuser,Cleartext-Password=TestParola123,EAP-Code=Response,EAP-Type-Identity=testuser\n" | sudo radeapclient -x 127.0.0.1:1812 auth testing123

Sent Access-Request     Id 35  EAP-Message = 0x02e1000d017465737475736572
Received Access-Challenge Id 35  EAP-Message = 0x01e200160410...
Sent Access-Request     Id 111 EAP-Message = 0x02e200160410...
Received Access-Accept   Id 111 EAP-Message = 0x03e20004

Burada yeni bir mesaj tipi çıkar: Access-Challenge. Sunucu “gönderdiğin yeterli değil, şu meydan okumaya cevap ver” der ve konuşma bir tur daha sürer. Paket düzeyinde akış dört adımdır:

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

Gerçek PEAP-MSCHAPv2’de bu tur sayısı çok daha fazladır, çünkü araya bir de TLS tüneli kurulur; ama mantık aynıdır. Bu ayrım teşhiste işe yarar: tek Access-Request’in hemen ardından gelen bir Access-Reject konuşmanın hiç başlamadığını, onlarca Challenge’dan sonra gelen bir Reject ise sertifika ya da policy tarafını işaret eder.

Gerçek 802.1X: Korumanın Nerede Olduğu

Sunucu tarafı artık PEAP’e hazır: sertifika üretildi, EAP modülü çalışıyor. Gerçek bir 802.1X kurulumunda sıradaki adım, switch ya da erişim noktasını bu RADIUS sunucusuna yönlendirmek (NAS olarak clients.conf’a eklemek) ve istemcilerde PEAP profilini tanımlamaktır. Bu sunucuyu bir 802.1X hattına bağlayıp kabulü, reddi ve MAC doğrulamasını switch 802.1X yapılandırması yazımızda ölçtüm. Reddin kabulden neden bir saniye geç geldiğini de orada gösterdim.

Burada PEAP’in en çok atlanan güvenlik noktası devreye girer: koruma sunucuda değil, istemcinin sunucu sertifikasını doğrulamasındadır. Self-signed bir sertifika kullandığımız için istemciler bu sertifikayı tanımaz ve bağlanırken uyarı verir; canlıda bu yüzden sertifika ya bir kurumsal CA’dan alınır ya da self-signed CA istemcilere güvenilir olarak dağıtılır.

İstemcide “sertifikayı doğrulama”yı kapatmak uyarıyı susturur ama korumayı da kaldırır: aynı ağ adını yayınlayan sahte bir erişim noktasına da aynı güvenle bağlanılır. EAP yöntemleri arasındaki farkı ve bu güvenlik ayrımını RADIUS sunucusu nedir rehberimizde ele aldık.

İleri Adımlar: Web Yönetimi ve Active Directory

Buraya kadar dosya tabanlı, komut satırından yönetilen çalışan bir FreeRADIUS sunucusu kurduk. Üretim yolunda iki yönde derinleşir.

Web Yönetimi: daloRADIUS

Komut satırı ve users dosyası küçük ortamlar ile öğrenmek için berraktır, ama kullanıcı sayısı arttıkça bir web arayüzü günlük yönetimi kolaylaştırır. daloRADIUS, FreeRADIUS’a bir yönetim paneli ekler; tek şartı, kullanıcıların dosya yerine bir SQL veritabanında tutulmasıdır, çünkü web arayüzü ile sunucu aynı veritabanını paylaşır.

Bir dürüst uyarı: daloRADIUS bir web sunucusu ve PHP demektir, yani ek bir saldırı yüzeyi. Beş kullanıcılık bir ortamda users dosyası zaten yeterlidir; GUI, gerçekten kalabalık bir kullanıcı tabanını yönettiğinizde kazandırır. Bu kurulumu ayrı bir rehberde ele alıyoruz.

Active Directory Entegrasyonu

FreeRADIUS kendi kullanıcı listesini tutmak zorunda değildir; kurumsal ortamda kimliği doğrudan Active Directory’de doğrular, tıpkı Windows tarafındaki NPS gibi. Burada kritik bir incelik var: PEAP-MSCHAPv2 kullanıyorsanız FreeRADIUS’u Samba/winbind ile domain’e katmanız gerekir, LDAP tek başına yetmez. Çünkü MSCHAPv2’nin parolayı taşıma biçimi düz bir LDAP bağlantısıyla doğrulanamaz. Bu entegrasyonu da ayrı bir rehberde adım adım göstereceğiz.

Sonuç: FreeRADIUS Hazır, Sırada Ölçeklendirme Var

Elinizde artık kurulmuş, sınanmış ve ne konuştuğu paket düzeyinde görülmüş bir RADIUS sunucusu var. Ağ erişim kararını tek merkeze taşımak, paylaşılan parolaları ortadan kaldırmak ve her girişi isimli bir hesaba bağlamak: hepsi bu tek sunucunun sağladığı şeydir. Buradan sonrası ölçeklendirmedir. Gerçek switch’leri NAS olarak eklemek, kullanıcıları Active Directory’ye ya da SQL’e taşımak ve 802.1X’i sahada devreye almak, hep bu çalışan temelin üzerine kurulur. Temeli sağlam attıysanız gerisi eklemedir.

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