FortiGate Firewall RADIUS: Merkezi Yönetici Girişi

FortiGate Firewall RADIUS ile yönetici girişi, yöneticilerin parolasını FortiGate’te değil merkezdeki RADIUS sunucusunda tutmaktır. Yönetici giriş ekranına kendi adını ve parolasını yazar; FortiGate ikisini RADIUS sunucusuna sorar, cevaptaki grubu bir yönetici kaydıyla eşler ve o kaydın yetki profilini verir. Bir yönetici ayrıldığında hesabı tek yerde kapatırsınız ve her cihazda ayrı ayrı silmeniz gerekmez.

NSA’nın ağ altyapısı rehberi cihazların önce merkezi sunuculara sormasını, yerel yönetici hesabına yalnız bütün merkezi sunuculara ulaşılamadığında düşmesini istiyor. Bu yazı o düzeni FortiGate’te kuruyor ve kopan bir sunucuda ne olduğunu ölçüyor.

Bu yazı FortiGate Firewall ileri seviye rehberimizin 7. adımıdır. Lab’daki FreeRADIUS sunucusu radius01’i ve yedek olarak ikinci bir FreeRADIUS sunucusunu FortiGate’e bağlıyorum, bir joker yönetici kaydı açıyorum ve iki kullanıcıyla giriş deniyorum.

Lab’da üç şey beklenenden farklı çıktı:

1. Fabrika ayarındaki grup eşlemesi herkesi yönetici yaptı. Kullanıcı grubunun eşlemesi Any kaldığında RADIUS’un tanıdığı herkes, yönetici olmayan sıradan bir kullanıcı da FortiGate’e yönetici olarak girdi.
2. Yedek sunucu alanı yönetici girişinde hiç kullanılmadı. RADIUS kaydının Secondary Server alanında çalışan bir sunucu dururken, birincil kapanınca giriş ekranı ikinciliye sormadan düştü.
3. Log üç farklı arızayı tek cümleyle yazdı: parola yanlış, grup eşleşmedi ya da sunucu cevap vermedi; üçü de “invalid password”.

Örnekteki sınır kapısında kontrol binasının kapısındaki nöbetçi, gelen kişinin rozetini merkeze telefonla sorar. Merkezin “bu kişi bizim personelimiz” demesi yetmez; rozette kapı amirliği bandı olmalıdır. Hat düşerse kapının yanındaki camlı kutuda tek bir yedek anahtar durur. FortiGate’te merkez RADIUS sunucusu, bant RADIUS’un döndürdüğü grup, yedek anahtar da yerel acil durum hesabıdır.

Bu yazı, Kurumsal Network Kurulumu hizmetimizde birden çok yöneticinin eriştiği firewall’larda yönetici girişini merkeze taşırken izlediğimiz sırayı anlatır.

FortiGate RADIUS Yönetici Girişi Nasıl Olmalı?

Günlük yönetici girişi en az iki RADIUS sunucusundan yapılır ve FortiGate her sunucuyla ayrı, uzun bir paylaşılan anahtar kullanır. Joker yönetici kaydı yalnız belirli bir RADIUS grubunu kabul eder ve girişi yönetim ağıyla sınırlıdır. Cihazın kendi listesinde yalnız bütün RADIUS sunucuları düştüğünde kullanılan bir acil durum hesabı kalır. RADIUS trafiği yönetim ağının dışına çıkmaz.

Bu düzeni dört kaynak birlikte tarif ediyor:

1. NSA, Network Infrastructure Security Guidance (Mart 2022), bölüm 4.1: NSA, erişilebilirlik için ağda en az iki AAA sunucusu kurulmasını öneriyor. Sunucular cihazları her cihaza özgü ve karmaşık bir ön paylaşımlı anahtarla tanımalı ve mümkünse şifreli bir taşıma kullanmalı. Bölüm 4.2: bütün cihazlar AAA hizmetleri için önce merkezi sunucuları kullanacak biçimde ayarlanmalı, yerel yönetici hesapları yalnız merkezi sunucuların hepsine ulaşılamadığında yedek yöntem olarak kalmalı. Bölüm 4.3 de meşru yöneticilerin yapabileceklerinin sınırlanmasını istiyor.
2. NIST, SP 800-53: ayrıcalıklı hesaplar belirli kişi ve rollerle sınırlanır (AC-6(5)) ve bu hesaplarda çok faktörlü doğrulama kullanılır (IA-2(1)). RADIUS’ta ikinci faktör sunucu tarafında kurulur; lab’da kurmadım.
3. Fortinet, FG-IR-24-255 (Blast-RADIUS): FortiOS 7.0’ın bütün sürümleri etkilenmiş, 7.0 için çözüm düzeltilmiş bir sürüme geçmek.
4. Fortinet Community, 7.2.x RADIUS teşhis notu: iki sunuculu bir RADIUS kaydı, birincil sunucuya ulaşılamadığında ikinci sunucuya geçmeyebilir. Önerilen çözüm: iki ayrı RADIUS sunucusunu aynı gruba kaynak olarak eklemek. FortiGate isteği iki sunucuya birden gönderir ve ilk gelen cevabı kabul eder. Not 7.2.x’i anlatıyor. Lab’daki 7.0.10’da aynı davranışı ölçtüm.

Kararlar ve lab’daki karşılıkları:

FortiGate RADIUS Yönetici Girişinden Önce: Sunucu ve Yedek Hesap

Bu rehber, FortiGate’i bağlayacağınız RADIUS sunucusunu zaten kurduğunuzu varsayar. Sunucuyu nerede kuracağınıza göre iki kurulum rehberimiz var:

1. Windows Server: Windows’un RADIUS sunucusu NPS’tir (Network Policy Server) ve kullanıcıyı doğrudan Active Directory’den doğrular. Kurulumu Windows Server NPS kurulumu rehberimizde anlattık.
2. Linux: FreeRADIUS. Kurulumu Linux RADIUS sunucusu kurulum rehberimizde anlattık. Bu yazıdaki lab FreeRADIUS ile kuruldu.

RADIUS’un nasıl çalıştığını RADIUS nedir yazımızda anlattık.

Yapılandırmaya başlamadan önce üç şey hazır olmalı:

1. FortiGate iki RADIUS sunucusuna da ulaşabilmeli. Lab’da radius01 (192.168.1.129) sunucu ağında, yedek sunucu (192.168.10.15) yönetim ağında; FortiGate sunucu ağına bir statik rota ile çıkıyor. İstekler FortiGate’in yönetim adresinden (192.168.10.1) çıkıyor.
2. Her RADIUS sunucusu FortiGate’i istemci olarak tanımalı. FreeRADIUS’ta bu, clients.conf dosyasındaki bir istemci bloğudur; FortiGate’in adresi ve o sunucuyla paylaşılan anahtar (shared secret) burada yazılır. İki sunucuda iki ayrı anahtar var.
3. Yerel bir acil durum hesabı kalmalı. Bütün RADIUS sunucuları düştüğünde FortiGate’e girebileceğiniz tek yol yerel hesaptır. Lab’da bu hesap rastgele adlı xt2vbx9; girişi güvenilir adreslerle yönetim ağına sınırlı. Adının neden işini ele vermediğini FortiGate admin hesabı yazımızda anlattık.

Her iki sunucuya eklediğim istemci bloğu (paylaşılan anahtarı yer tutucuyla değiştirdim):

client gmfw01 {
	ipaddr = 192.168.10.1
	secret = <paylasilan-anahtar>
	shortname = gmfw01
}

İki deneme kullanıcısı açtım. radius.yonetici, doğrulanınca cevaba Fortinet-Group-Name özniteliğiyle fw-yoneticiler değerini ekliyor; radius.personel ise hiçbir grup taşımıyor ve aynı RADIUS sunucusunu kablosuz ağa ya da VPN’e giren sıradan bir çalışanı temsil ediyor:

radius.yonetici	Cleartext-Password := "<parola>"
	Fortinet-Group-Name = "fw-yoneticiler"

radius.personel	Cleartext-Password := "<parola>"

Sunucunuz NPS ise aynı öznitelik, kullanıcının AD grubuna bağlı network policy’nin Settings sekmesinde Vendor Specific (satıcıya özel) öznitelik olarak eklenir: satıcı kodu 12356 (Fortinet), öznitelik numarası 1, değer FortiGate’teki grup adı. Fortinet’in NPS ile kurulum notuna göre bu değer FortiGate’teki grup tanımıyla birebir aynı olmazsa giriş başarısız olur.

Lab’da parolalar sunucudaki bir dosyada duruyor. Gerçek kurulumda kullanıcılar çoğunlukla Active Directory’den gelir; FreeRADIUS’un Active Directory entegrasyonunu kurulum rehberinde anlattık.

FortiGate RADIUS Sunucusu Tanımı: Paylaşılan Anahtar ve Test

RADIUS tarafı hazır olunca FortiGate’e sunucuyu tanıtırız. User & Authentication → RADIUS Servers → Create New ekranında:

1. Name alanına FortiGate içindeki ad yazılır; lab’da merkez-radius.
2. Authentication method Default kalır.
3. Primary Server bölümünde IP/Name alanına sunucunun adresi (192.168.1.129), Secret alanına clients.conf’taki paylaşılan anahtarın aynısı yazılır.
4. Secondary Server bölümü ikinci sunucu için var. İlk denemede yedek sunucuyu buraya yazdım; aşağıda bu alanın yönetici girişinde neden işe yaramadığını gösteriyorum.
5. Include in every user group kapalı kalır. Açık olursa bu RADIUS sunucusu FortiGate’teki her kullanıcı grubuna kendiliğinden eklenir.

İki bölümdeki Test Connectivity düğmeleri de Successful dedi.

Bağlantı testi bir kullanıcının parolasını sınamaz. Kullanıcıyı formdaki Test User Credentials düğmesiyle ya da komut satırından sınarsınız: diagnose test authserver radius merkez-radius pap radius.yonetici <parola>. Lab’daki çıktı:

authenticate 'radius.yonetici' against 'pap' succeeded, server=primary assigned_rad_session_id=944788563 session_timeout=0 secs idle_timeout=0 secs!
Group membership(s) - fw-yoneticiler

İkinci satır önemli: FortiGate RADIUS’un cevaptaki grubu okuyabiliyor. Giriş ekranından yapılan bir girişte radius01’de FreeRADIUS’u hata ayıklama kipinde (freeradius -X) çalıştırdım; FortiGate’in gönderdiği istek ve sunucunun cevabı şöyle görünüyor:

(0) Received Access-Request Id 2 from 192.168.10.1:18596 to 192.168.1.129:1812 length 142
(0)   NAS-Identifier = "gmfw01"
(0)   User-Name = "radius.yonetici"
(0)   User-Password = "<gizli>"
(0)   Framed-IP-Address = 192.168.10.225
(0)   NAS-Port-Type = Virtual
(0)   Calling-Station-Id = "192.168.10.225"
(0)   Acct-Session-Id = "38505455"
(0)   Connect-Info = "admin-login"
(0)   Fortinet-Vdom-Name = "root"
...
(0) Sent Access-Accept Id 2 from 192.168.1.129:1812 to 192.168.10.1:18596 length 60
(0)   Fortinet-Group-Name = "fw-yoneticiler"

İstekte yöneticinin bağlandığı bilgisayarın adresi (Calling-Station-Id = "192.168.10.225") ve isteğin bir yönetici girişi olduğu (Connect-Info = "admin-login") da var; RADIUS sunucusunun kaydı kimin nereden girdiğini bu yüzden kendi başına gösterir.

Parola satırını ben gizledim. FreeRADIUS’un hata ayıklama çıktısı parolayı açık yazar, çünkü sunucu onu paylaşılan anahtarla çözmüştür; ağdaki pakette parola bu anahtarla gizlenmiş olarak gider. Anahtarın neden RADIUS’un en zayıf halkası olduğunu RADIUS nedir yazımızda anlattık.

FortiGate Joker Yönetici Kaydı: Grup Eşlemesi Neden Şart?

FortiGate RADIUS’a soru sorabiliyor; şimdi cevabı bir yönetici kaydına bağlamak gerekiyor. Bunun iki parçası var. Önce User & Authentication → User Groups → Create New ekranında radius-yoneticiler adında, türü Firewall olan bir grup açılır ve Remote Groups bölümüne merkez-radius eklenir. Sonra System → Administrators → Create New → Administrator ekranında yönetici kaydı açılır:

1. Username alanına kaydın adı yazılır; lab’da uzak-yoneticiler. Bu ad giriş ekranında kullanılmaz, yöneticiler kendi RADIUS adlarıyla girer.
2. Type olarak Match all users in a remote server group seçilir. FortiGate’in listesinde bu kaydın türü Remote+Wildcard görünür.
3. Administrator profile olarak yetki profili seçilir; lab’da prof_admin. Profiller arasındaki farkı admin hesabı yazımızda anlattık.
4. Remote User Group olarak radius-yoneticiler seçilir.
5. Restrict login to trusted hosts açılır ve yönetim ağı (192.168.10.0/24) yazılır; RADIUS’un kabul ettiği bir yönetici de başka bir ağdan giremez.

Komut satırı karşılığı (alanların sırası önemli: vdom satırı remote-group’tan önce gelmezse FortiGate grubu reddediyor):

config system admin
    edit "uzak-yoneticiler"
        set remote-auth enable
        set accprofile "prof_admin"
        set vdom "root"
        set wildcard enable
        set remote-group "radius-yoneticiler"
        set trusthost1 192.168.10.0 255.255.255.0
    next
end

Type listesindeki öbür seçenek, Match a user on a remote server group, her yöneticiyi FortiGate’te adıyla ayrı ayrı tanımlar. Joker kayıt ise yönetici eklemeyi RADIUS tarafına bırakır; kimin yönetici olduğunu artık FortiGate değil, kullanıcı grubunun eşlemesi belirler.

Groups: Any Seçiliyken Her RADIUS Kullanıcısı Yönetici Oldu

Grubu açarken merkez-radius’u eşlemesiz ekledim; grup formunda Group Name sütunu boş kalıyor, eşleme panelindeki karşılığı Groups: Any.

İki kullanıcıyla giriş ekranından giriş denedim. İkisi de girdi. Olay logu (Log & Report → Events → System Events):

2: date=2026-10-02 time=03:25:36 ... logdesc="Admin login successful" sn="1790900736" user="radius.personel" ui="http(192.168.10.225)" method="http" srcip=192.168.10.225 dstip=192.168.10.1 action="login" status="success" reason="none" profile="prof_admin" msg="Administrator radius.personel logged in successfully from http(192.168.10.225)"
3: date=2026-10-02 time=03:25:28 ... logdesc="Admin login successful" sn="1790900728" user="radius.yonetici" ui="http(192.168.10.225)" method="http" srcip=192.168.10.225 dstip=192.168.10.1 action="login" status="success" reason="none" profile="prof_admin" msg="Administrator radius.yonetici logged in successfully from http(192.168.10.225)"

radius.personel hiçbir grup taşımıyordu, yine de prof_admin profiliyle yönetici oldu. Any, “RADIUS’un kabul ettiği herkes” demek. Aynı RADIUS sunucusu kablosuz ağ ya da VPN için de kullanılıyorsa, oraya girebilen her çalışan firewall’a da yönetici olarak girebilir.

Eşlemeyi düzeltmek için gruptaki satırı düzenleyip Groups seçeneğini Specify yaparsınız ve alana RADIUS’un döndürdüğü değeri, fw-yoneticiler, yazarsınız.

Aynı iki girişi tekrarladım. radius.yonetici girdi; radius.personel giriş ekranında Authentication failure gördü. FreeRADIUS iki kullanıcıya da kabul vermişti:

(1) Received Access-Request Id 5 from 192.168.10.1:2296 to 192.168.1.129:1812 length 142
...
(1) pap: User authenticated successfully
...
(1) Sent Access-Accept Id 5 from 192.168.1.129:1812 to 192.168.10.1:2296 length 38

Reddi FortiGate verdi, çünkü cevapta beklenen grup yoktu. Olay logunun bu ret için yazdığı gerekçeye teşhis bölümünde döneceğim.

Örnekteki sınır kapısında nöbetçi artık rozetin kendisine değil, bandına bakıyor: merkez “personelimiz” dese bile kapı amirliği bandı olmayan kişi kontrol odasına girmiyor.

FortiGate RADIUS Yedek Sunucu: Secondary Server Neden Devreye Girmedi?

Merkezî giriş, merkeze bağımlılık da demek; NSA’nın iki sunucu istemesinin sebebi bu. radius01’de FreeRADIUS’u durdurdum. Yedek sunucu RADIUS kaydının Secondary Server alanında çalışıyordu. radius.yonetici ile giriş ekranından girdim ve FortiGate’in yönetim ağındaki trafiği yakaladım:

1790900961.212118 IP 192.168.10.1.7004 > 192.168.1.129.1812:  rx type 32 (142)
1790900961.213374 IP 192.168.1.129 > 192.168.10.1: ICMP 192.168.1.129 udp port 1812 unreachable, length 178
1790900966.216783 IP 192.168.10.1.7004 > 192.168.1.129.1812:  rx type 32 (142)
1790900966.217407 IP 192.168.1.129 > 192.168.10.1: ICMP 192.168.1.129 udp port 1812 unreachable, length 178

FortiGate birincile sordu, sunucu makinesi “bu portta kimse yok” dedi, FortiGate 5 saniye sonra bir kez daha sordu ve giriş ekranı 7 saniyede Authentication failure yazdı. Yedek sunucuya tek istek gitmedi; hata ayıklama kipindeki yedek FreeRADIUS da hiç istek görmedi.

Aynı durumu komut satırından sınadım (diagnose test authserver radius merkez-radius pap radius.yonetici <parola>):

1790901046.452355 IP 192.168.10.1.24365 > 192.168.1.129.1812: RADIUS, Access-Request (1), id: 0x07 length: 119
1790901046.453030 IP 192.168.1.129 > 192.168.10.1: ICMP 192.168.1.129 udp port 1812 unreachable, length 155
1790901051.457708 IP 192.168.10.1.24365 > 192.168.1.129.1812: RADIUS, Access-Request (1), id: 0x07 length: 119
1790901051.458447 IP 192.168.1.129 > 192.168.10.1: ICMP 192.168.1.129 udp port 1812 unreachable, length 155
1790901053.448047 IP 192.168.10.1.13302 > 192.168.10.15.1812: RADIUS, Access-Request (1), id: 0x08 length: 119
1790901053.449134 IP 192.168.10.15.1812 > 192.168.10.1.13302: RADIUS, Access-Accept (2), id: 0x08 length: 60

Test 7 saniyede yedek sunucuya geçti ve server=secondary ile başarılı oldu. Yani yedek sunucu çalışıyor, FortiGate de ona geçmeyi biliyor; yalnız yönetici girişi o noktaya gelmeden pes ediyor.

Bunun bir bekleme süresi meselesi olup olmadığını sınadım. Yönetici girişinin uzak sunucu cevabını beklediği süre config system global altındaki remoteauthtimeout, fabrika ayarında 5 saniye.

Süreyi 30 saniyeye çıkardım ve girişi tekrarladım: FortiGate 30 saniye boyunca yedi kez birincile sordu, yedek sunucuya yine hiç sormadı ve giriş 32,2 saniyede reddedildi. Birincil sunucu cevap vermek yerine paketleri sessizce düşürdüğünde de sonuç aynıydı. Fortinet Community’nin notu bu davranışı 7.2.x için yazıyor; lab’daki 7.0.10’da da aynı.

Örnekteki nöbetçinin elinde merkezin iki numarası var: tek kayıtta ikinci numarayı yalnız birinci numara iki kez çaldıktan sonra arıyor, kapıdaki kişi ise o kadar beklemiyor. İki ayrı kayıtta nöbetçi iki numarayı aynı anda arıyor ve ilk açanın cevabıyla kapıyı açıyor.

Çözüm: İki Ayrı RADIUS Kaydı Aynı Grupta

Fortinet’in önerdiği yol yedek sunucuyu ayrı bir RADIUS kaydı olarak tanımlayıp aynı kullanıcı grubuna ikinci eşleme olarak eklemek:

1. User & Authentication → RADIUS Servers → Create New: Name yedek-radius, Primary Server IP/Name 192.168.10.15 ve o sunucunun kendi anahtarı.
2. merkez-radius kaydındaki Secondary Server alanı boşaltılır.
3. radius-yoneticiler grubunda Remote Groups → Add: Remote Server yedek-radius, Groups Specify fw-yoneticiler.

Komut satırı karşılığı:

config user radius
    edit "merkez-radius"
        unset secondary-server
    next
    edit "yedek-radius"
        set server "192.168.10.15"
        set secret <yedek-sunucunun-anahtari>
    next
end
config user group
    edit "radius-yoneticiler"
        set member "merkez-radius" "yedek-radius"
        config match
            edit 1
                set server-name "merkez-radius"
                set group-name "fw-yoneticiler"
            next
            edit 2
                set server-name "yedek-radius"
                set group-name "fw-yoneticiler"
            next
        end
    next
end

Bekleme süresini fabrika değerine (5 saniye) geri aldım, radius01 kapalıyken aynı girişi tekrarladım:

1790901684.147305 IP 192.168.10.1.9864 > 192.168.1.129.1812: RADIUS, Access-Request (1), id: 0x0e length: 142
1790901684.147446 IP 192.168.10.1.9864 > 192.168.10.15.1812: RADIUS, Access-Request (1), id: 0x0f length: 142
1790901684.147775 IP 192.168.1.129 > 192.168.10.1: ICMP 192.168.1.129 udp port 1812 unreachable, length 178
1790901684.149315 IP 192.168.10.15.1812 > 192.168.10.1.9864: RADIUS, Access-Accept (2), id: 0x0f length: 60

FortiGate iki sunucuya aynı anda sordu (iki istek arasında 0,14 milisaniye var), yedek sunucunun kabulüyle giriş 171 milisaniyede geçti ve log girişi profile="prof_admin" ile yazdı. İki sunucu açıkken de her girişte iki istek gidiyor; iki sunucunun kaydında da aynı giriş görünür.

FortiGate’te RADIUS Sunucularının İkisi de Kapalıyken: Acil Durum Hesabı

Son ölçümde iki sunucu birden düştü: ikisini de durdurdum ve iki giriş denedim:

1. radius.yonetici: giriş ekranı 7,1 saniye sonra Authentication failure dedi. FortiGate iki sunucuya ikişer kez sordu.
2. xt2vbx9 (yerel acil durum hesabı): 183 milisaniyede super_admin profiliyle girdi.

2: date=2026-10-02 time=03:42:59 ... logdesc="Admin login successful" sn="1790901779" user="xt2vbx9" ui="http(192.168.10.225)" method="http" srcip=192.168.10.225 dstip=192.168.10.1 action="login" status="success" reason="none" profile="super_admin" msg="Administrator xt2vbx9 logged in successfully from http(192.168.10.225)"
3: date=2026-10-02 time=03:42:52 ... logdesc="Admin login failed" sn="0" user="radius.yonetici" ui="http(192.168.10.225)" method="http" srcip=192.168.10.225 dstip=192.168.10.1 action="login" status="failed" reason="passwd_invalid" msg="Administrator radius.yonetici login failed from http(192.168.10.225) because of invalid password"

Yerel hesabın hızı tesadüf değil. Yakalamada xt2vbx9’un girişi için tek bir RADIUS isteği yok; FortiGate adı yerel listesinde bulunca RADIUS’a sormuyor. NSA’nın 4.2 bölümündeki sıra tam bu: önce merkezi sunucular, yerel hesap yalnız hepsi düştüğünde. Komut satırı testi de iki sunucu kapalıyken bunu açıkça yazıyor:

authenticate 'radius.yonetici' against 'pap' failed(no response), assigned_rad_session_id=944788577 session_timeout=0 secs idle_timeout=0 secs!

Buradan iki kural çıkıyor:

1. Yerel acil durum hesabı silinmez. Parolası güvenli bir yerde durur, girişi güvenilir adreslerle sınırlıdır ve her kullanımı bir olay olarak incelenir.
2. Yedek sunucu ayrı kayıtla eklenir ve sınanır. Bağlantı testi iki sunucuda da başarılı görünse bile, birincili kapatıp giriş ekranından denemeden yedeğin çalıştığına güvenilmez. Tek sunucunun neden yetmediğini RADIUS nedir yazımızda anlattık; switch tarafındaki karşılığını NPS cevap vermediğinde switch’in ne yaptığını ölçtüğümüz yazıda bulabilirsiniz.

FortiGate RADIUS ve Blast-RADIUS: Message-Authenticator Yok

FreeRADIUS, FortiGate’ten gelen ilk isteği alır almaz hata ayıklama çıktısına bir uyarı yazdı:

BlastRADIUS check: Received packet without Message-Authenticator.
Setting "require_message_authenticator = false" for client gmfw01
...
UPGRADE THE CLIENT AS YOUR NETWORK IS VULNERABLE TO THE BLASTRADIUS ATTACK.
Once the client is upgraded, set "require_message_authenticator = true" for  client gmfw01

FortiOS 7.0.10 isteğe Message-Authenticator özniteliğini eklemiyor ve RADIUS sunucu kaydının bütün alanları arasında bunu açacak bir ayar yok (show full-configuration user radius). FreeRADIUS da zorunluluğu bu istemci için kendiliğinden kapattı. Sunucu NPS ise tersi olabilir: NPS yazımızda anlattığımız istemci başına zorunluluk açıksa NPS özniteliği taşımayan isteği atar, yani 7.0’daki bir FortiGate’in hiçbir yönetici girişi geçmez. Bu ayarı açmadan önce FortiGate’in sürümüne bakın. Blast-RADIUS, istemciyle sunucu arasına girebilen birinin RADIUS cevabını değiştirebildiği bir protokol açığı; Message-Authenticator bunu engelleyen imza.

Fortinet’in bildirimi 7.0 için düzeltilmiş sürüm vermiyor; düzeltme 7.2.11, 7.4.6 ve 7.6.1’de. 7.0’da kalan bir FortiGate’te RADIUS trafiği yalnız yönetim ağından geçmeli ve sürüm yükseltmesi plana girmeli. Lab’da iki sunucu da FortiGate’e yönetim ağı ve sunucu ağı üzerinden bağlı; araya kullanıcı ağı girmiyor. Message-Authenticator’ın paket içindeki yerini switch RADIUS yazımızda anlattık.

FortiGate RADIUS Teşhisi: “Invalid Password” Her Zaman Parola Değil

Başarılı bir RADIUS girişi olay logunda profile="prof_admin" ile yazılıyor; kimin hangi profille girdiğini buradan okursunuz. Başarısız girişlerde ise log yanıltıcı. Grup eşleşmediği için reddedilen radius.personel denemesi:

2: date=2026-10-02 time=03:27:53 ... logdesc="Admin login failed" sn="0" user="radius.personel" ui="http(192.168.10.225)" method="http" srcip=192.168.10.225 dstip=192.168.10.1 action="login" status="failed" reason="passwd_invalid" msg="Administrator radius.personel login failed from http(192.168.10.225) because of invalid password"

Parola doğruydu; FreeRADIUS kullanıcıyı kabul etmişti. İki sunucu kapalıyken yapılan radius.yonetici denemesi de yukarıda aynı gerekçeyle, reason="passwd_invalid" ile duruyor. Yani bu satır üç farklı durumu tek cümleyle yazıyor: parola yanlış, grup eşleşmedi ya da sunucu cevap vermedi.

Ayırmak için iki yere bakılır:

1. diagnose test authserver radius merkez-radius pap <kullanıcı> <parola>. Sunucu kapalıysa sonuç failed(no response); parola yanlışsa doğrulama başarısız; doğrulama başarılı ama giriş yine reddediliyorsa Group membership(s) satırındaki grup ile kullanıcı grubundaki Specify değeri karşılaştırılır.
2. RADIUS sunucusunun kendi kaydı. FreeRADIUS’ta Sent Access-Accept satırı varsa ve cevapta Fortinet-Group-Name yoksa sorun grupta; Access-Reject varsa parolada; istek hiç görünmüyorsa yolda ya da paylaşılan anahtarda.

Bu denemeleri yaparken bir sınırı da hesaba katın: FortiGate aynı adresten üç başarısız yönetici girişinden sonra o adresi 60 saniye kilitliyor (admin-lockout-threshold 3, admin-lockout-duration 60). Kilit tarayıcıyı da SSH’ı da kapsıyor; kilitlenme davranışını yönetim erişimi yazımızda ölçtük.

RADIUS teşhisini giriş ekranı yerine diagnose test authserver ile yapmak bu yüzden de daha güvenli, ama yedek sunucu sorusunda tek başına yetmez: komut satırı yedeğe geçti, giriş ekranı geçmedi.

Doğrulama: FortiGate RADIUS Yönetici Girişi Doğru Kuruldu mu?

1. İki RADIUS sunucusu iki ayrı kayıt olarak tanımlı, her biri kendi anahtarıyla; ikisi de aynı kullanıcı grubunda Specify fw-yoneticiler ile eşli.
2. Joker yönetici kaydı grup eşlemeli, profili işin gerektirdiği kadar ve girişi güvenilir adreslerle sınırlı.
3. Grubu olmayan bir RADIUS kullanıcısı giriş ekranında reddediliyor.
4. Birincil sunucu kapalıyken giriş ekranından girilebiliyor; bağlantı testine değil gerçek girişe bakılmış.
5. İki sunucu da kapalıyken yerel acil durum hesabı giriyor, RADIUS yöneticisi girmiyor.
6. Log: başarılı girişlerde profile= alanı doğru profili gösteriyor.

Sonuç: FortiGate’te Girişi RADIUS, Yöneticiliği Grup Belirler

FortiGate’te RADIUS ile yönetici girişi kimlik doğrulamayı merkeze taşır, ama yetkiyi kendiliğinden daraltmaz ve yedek sunucuyu kendiliğinden kullanmaz. Lab’dan çıkan dört kural:

1. Joker kayıt grup eşlemesiz açılmaz. Any, RADIUS’un kabul ettiği herkesi yönetici yaptı; Specify ile yalnız fw-yoneticiler grubu girdi.
2. Yedek sunucu ayrı bir kayıttır. Secondary Server alanı yönetici girişinde hiç kullanılmadı; iki ayrı kayıtla giriş 171 milisaniyede yedekten geçti.
3. Yerel acil durum hesabı kalır. İki sunucu da kapalıyken tek giriş yolu oydu ve RADIUS’a hiç sorulmadan çalıştı.
4. Log gerekçesine değil teste güvenilir. Olay logu üç farklı arızayı “invalid password” diye yazdı; ayrımı diagnose test authserver ve RADIUS sunucusunun kaydı yaptı.

Lab’daki son hâl: ölçüm bitince RADIUS kayıtları, kullanıcı grubu ve joker yönetici kaydı silindi, radius01 yapılandırması yedekten geri yüklendi ve yedek sunucu kaldırıldı. FortiGate’te yerel listede xt2vbx9 acil durum hesabı olarak duruyor.

Örnekteki sınır kapısında nöbetçi merkezi iki numaradan birlikte arar, rozetin bandına bakar ve iki hat da düşerse camlı kutudaki anahtar kapıyı açar; üçü birlikte olunca kontrol odasına kimin girdiği bellidir. Sıradaki adım rehberin 8. adımı, şubeler arası IPsec tüneli.

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