FortiGate Firewall Admin Hesabı: Yetki Profilleri

FortiGate Firewall’da her yönetici kendi hesabıyla girer ve o hesabın neleri değiştirebileceğini bir yetki profili belirler. NSA ve NIST’in tarif ettiği düzende yöneticiler Active Directory’deki ayrı yönetici hesaplarıyla, merkezi bir sunucu üzerinden girer; cihazın kendi listesinde yalnız acil durumda kullanılan bir yerel hesap kalır. Bu yazı FortiGate Firewall yapılandırma rehberimizin 3. adımı. Bu düzenin her parçasını lab’daki FortiGate’te ölçtüm.

Örnekteki sınır kapısında her görevlinin kendi mührü vardır. Belgeye basılan damga kimin mührünü taşıyorsa iş onundur; mührü olmayan görevli belgeleri okuyabilir ama damgalayamaz. Kasada bir de yedek mühür durur ve yalnız merkezle bağlantı koptuğu gün çıkar. FortiGate’te mühür yazma yetkisinin, damga logdaki kullanıcı adının, yedek mühür de acil durum hesabının karşılığıdır.

Bu yazı, Kurumsal Network Kurulumu hizmetimizde devraldığımız her FortiGate’te ilk ayırdığımız şeyi anlatır: hesapları.

FortiGate Admin Hesabı Neden Kişiye Ait Olur?

FortiGate, yapılan her değişikliği onu yapan hesabın adıyla loga yazar. Bunu görmek için kendi hesabımla SSH’tan bir adres nesnesi ekledim ve olay kaydına baktım:

date=2026-10-01 time=08:34:25 ... logdesc="Object attribute configured" user="ilker.pehlivan" ui="ssh(192.168.10.225)" action="Add" cfgtid=117637120 cfgpath="firewall.address" cfgobj="iz-denemesi" cfgattr="subnet[10.34.30.99 255.255.255.255]comment[admin hesabi yazisi icin iz denemesi]" msg="Add firewall.address iz-denemesi"

Satır değişikliğin kimde olduğunu (user), hangi yoldan geldiğini (ui, SSH ve kaynak adres), neye dokunduğunu (cfgpath, cfgobj) ve hangi değerleri yazdığını (cfgattr) birlikte söylüyor. Herkes ortak admin hesabını kullansaydı user alanında yalnız admin yazardı ve “bu kuralı kim ekledi?” sorusunun cevabı kaybolurdu.

Ortak hesabın ikinci bedeli ayrılan personelde görünür. Parolayı bilen biri işten ayrıldığında parola değişir ve herkes etkilenir; kişiye ait hesapta yalnız o hesap kapatılır. NSA’nın ağ altyapısı rehberi de ortak yönetici hesaplarının kapatılmasını ve her yöneticiye ayrı hesap açılmasını ister, çünkü ortak hesapta yapılan değişiklik bir kişiye bağlanamaz.

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

Günlük yönetici girişi merkezi bir sunucudan yapılır: Active Directory’ye LDAPS ile bağlanan bir LDAP sunucusu ya da bir RADIUS sunucusu. Cihazın kendi listesinde yalnız merkezi sunucuya ulaşılamadığı gün kullanılan bir acil durum hesabı kalır.

Bu düzeni üç kaynak birlikte tarif ediyor:

1. NSA, ağ yöneticileri için yayımladığı Network Infrastructure Security Guidance rehberinde (Mart 2022 sürümü) cihazların önce merkezi sunucuya sormasını, yerel hesaba yalnız bütün merkezi sunuculara ulaşılamadığında düşmesini istiyor (bölüm 4.2). Aynı rehber en az iki merkezi sunucu ve LDAPS gibi şifreli bir bağlantı öneriyor (bölüm 4.1).
2. NIST, SP 800-53 kataloğunda ayrıcalıklı hesapların belirli kişi ve rollerle sınırlanmasını (AC-6(5)) ve bu hesaplarda çok faktörlü doğrulamayı (IA-2(1)) istiyor.
3. Fortinet, yönetici hesabı önerilerinde yeni bir super_admin hesabı açıp fabrika admin hesabının adını değiştirmeyi, girişi güvenilen adreslerle sınırlamayı ve iki aşamalı doğrulamayı sayıyor.

Merkezi girişin değeri, hesabın tek bir yerde yaşamasından gelir:

Tablonun son satırı acil durum hesabının neden var olduğunu açıklıyor.

FortiGate’te Kaç Yerel Admin Hesabı Olmalı?

NSA de NIST de bir sayı vermiyor; ikisi de hesap sayısının işin gerektirdiği kadarla sınırlanmasını istiyor (NSA bölüm 5.3). NSA ayrıca yerel hesapların yalnız merkezi sunuculara ulaşılamadığında kullanılmasını istiyor (bölüm 5.4). Bunun pratik karşılığı her FortiGate’te tek bir yerel acil durum hesabıdır. Günlük işi yapan her kişiye ayrıca yerel hesap açmak, kişi ayrıldığında silinmesi unutulacak ikinci bir liste kurmak demektir.

Fabrika admin hesabı da bu sayıya girer. NSA’ya göre fabrika credential’ları (kimlik bilgileri) herkesçe bilinir ve otomatik tarayıcıların ilk hedefidir (bölüm 5.2); Fortinet bu yüzden fabrika hesabının adını değiştirmeyi öneriyor. Lab cihazımda admin ve ölçüm yaptığım yerel ilker.pehlivan hesabı duruyor, çünkü serinin bütün ölçümleri bu cihazda yapılıyor. Kurulumu biten bir cihazda yerel listede yalnız acil durum hesabı kalır.

Acil Durum Hesabı Ne Zaman Kullanılır?

Acil durum hesabı üç durumda kullanılır:

1. İlk kurulumda: merkezi giriş henüz tanımlanmamıştır ve cihaza girmenin tek yolu yerel hesaptır.
2. Merkezi sunucuya ulaşılamadığında: domain controller kapalıdır, aradaki rota kopmuştur ya da LDAPS sertifikasının süresi dolmuştur.
3. Merkezi girişin ayarı bozulduğunda: örneğin yanlış bir grup eşlemesi bütün yöneticileri dışarıda bırakmıştır.

Hesabın saklanma biçimi de kullanımı kadar önemlidir:

1. Parolası en az 15 karakterdir. NIST SP 800-63B tek başına kullanılan parolada 15 karakteri alt sınır koyuyor (bölüm 3.1.1.2); NSA da cihazda saklanan parolalar için aynı uzunluğu istiyor. Parola yöneticisinin ürettiği rastgele bir dizi iki koşulu da karşılar.
2. Parolayı cihaza doğrudan erişimi olmayan güvenilir biri saklar. NSA’nın önerisine göre yönetici acil durumda parolayı ister, olay bitince parola değiştirilir (bölüm 5.4).
3. Girişi yönetim ağıyla sınırlıdır. Hesaba güvenilen adres tanımlanır.
4. Her girişi incelenir. Hesap yalnız acil durumda kullanıldığı için logdaki her giriş satırı bir olaydır.

Aynı mantığı Active Directory tarafında break-glass hesabı olarak anlattık.

Günlük Hesap ile Yönetici Hesabı: ilker.pehlivan ve ilker.pehlivan.adm

Lab’da adı birbirine benzeyen üç hesap var ve üçü ayrı işlere yarıyor:

1. FortiGate’teki yerel ilker.pehlivan cihazın kendi listesinde durur; parolası ve SSH anahtarı FortiGate’tedir. Serinin ölçümlerini bu hesapla yapıyorum. Acil durum hesabı bu değil, aşağıda açtığım rastgele adlı ayrı hesaptır; RADIUS yazısında iki RADIUS sunucusu da kapalıyken giren o oldu.
2. Active Directory’deki ilker.pehlivan günlük hesabımdır. Bilgisayara, e-postaya ve dosya sunucusuna bununla girerim.
3. Active Directory’deki ilker.pehlivan.adm yalnız yönetim işi için açılmış ayrı hesaptır. FortiGate’e AD üzerinden bu hesapla girerim.

İki AD hesabını ayırmanın sebebini Microsoft’un en az yetki rehberindeki örnek iyi anlatıyor. E-postadaki zararlı eki açan bir yönetici, o an oturumdaki hesabın bütün yetkisini saldırgana vermiş olur. Günlük hesap yönetici yetkisi taşımıyorsa açılan ek yalnız o kullanıcının verisine ulaşır. NIST SP 800-53 de ayrıcalıklı hesabı olan kişinin yönetim dışı işlerde ayrıcalıksız hesabını kullanmasını istiyor (AC-6(2)).

Adın sonundaki .adm bizim kullandığımız bir ad geleneğidir; hiçbir standart ad şartı koymaz, önemli olan hesabın ayrı olmasıdır. Adın hesabın türünü söylemesi ise logu okuyan kişinin user="ilker.pehlivan.adm" satırını tek bakışta yönetim işi diye ayırmasını sağlar.

Yönetici hesabı yetkisini bir AD grubundan alır ve her rolün grubu ayrıdır. Firewall’u yöneten ağ yöneticisi ile domain’i yöneten sistem yöneticisi farklı kişilerse, firewall’a giriş yalnız firewall grubuna verilir; lab’da bu grup USER_FW_YONETICILER.

Bu grubun Domain Admins’e ya da Tier 0 grubuna üye olması gerekmez: ilker.pehlivan.adm yalnız USER_FW_YONETICILER üyesi. Tier 0’ın ne olduğunu ve hangi hesabın nereye girebileceğini Active Directory sıkılaştırma yazımızda anlattık.

FortiGate’e Active Directory Grubuyla Yönetici Girişi (LDAPS)

Merkezi giriş, FortiGate’te ondan önce kurulmuş beş şeye dayanır. Sıra önemlidir, çünkü her biri bir öncekine yaslanır:

1. Doğru saat. LDAPS bir TLS bağlantısıdır ve domain controller’ın sertifikası cihazın saatine göre kontrol edilir. Saat rehberin 4. adımında, NTP ayarı yazımızda kurulur.
2. İç DNS. Sunucu alanına domain controller’ın tam adı yazılır, bu yüzden FortiGate’in DNS’i domain controller’ı gösterir. DNS rehberin 5. adımında, DNS ayarı yazımızda kurulur.
3. Domain controller’a giden yol. Domain controller FortiGate’e doğrudan bağlı bir ağda değilse ona bir rota gider; lab’da yönetim ağından sunucu ağına bir statik rota var. Rotalar rehberin 12. adımıdır.
4. LDAPS ile bağlanan bir LDAP sunucusu kaydı. Sunucu, Active Directory’nin domain controller’ı: sunucu alanında dc01.ad.sistemkusu.com, port 636. Kaydın adı lab’da dc01-ldap; bu ad yalnız FortiGate’in içinde, kaydı seçerken görünür.
5. AD grubunu eşleyen bir kullanıcı grubu. Lab’da ag-yoneticileri; eşlediği AD grubu USER_FW_YONETICILER.

Son ikisini Active Directory entegrasyonu yazımızda ekran ekran gösterdik. Yöneticiler ikinci bir doğrulamayla girecekse bu listeye bir RADIUS sunucusu eklenir; aşağıda anlatıyorum.

Bu yüzden rehberin 3. adımında merkezi giriş henüz kurulamaz. İlk gün cihazda yerel acil durum hesabı ve yetki profilleri hazırlanır ve kurulum o hesapla yapılır (yukarıdaki listenin 1. maddesi). AD grubuyla giriş, bu beş şey hazır olduğu gün açılır. Bağlantının LDAPS olması şarttır, çünkü FortiGate kullanıcıyı LDAP’a parolasıyla doğrulatır ve düz LDAP (389) bu parolayı şifresiz taşır. Firewall’a giren yöneticinin parolası ağdan okunabilir hâle gelir.

Yönetici kaydı System → Administrators → Create New → Administrator ile açılan formda kurulur:

1. Username: kaydın adı. Bu kayıt bir kişiyi değil bir grubu temsil eder; lab’da ag-yoneticileri.
2. Type: Match all users in a remote server group. Bu türe joker kayıt denir: FortiGate’te kişi başına değil, grubun bütün üyeleri için tek bir kayıt açılır ve gruptaki herkes kendi AD hesabıyla girer. Kayıt, iskambildeki joker gibi her kişinin yerine geçer; listede türü Remote+Wildcard, komut satırında set wildcard enable olarak görünür. Yanındaki Match a user on a remote server group tek bir AD kullanıcısı içindir ve her yönetici için ayrı kayıt ister.
3. Administrator profile: gruba verilecek yetki. Profillerin farkı aşağıdaki bölümün konusu.
4. Remote User Group: AD grubunu eşleyen kullanıcı grubu, ag-yoneticileri.
5. Restrict login to trusted hosts: yönetim ağı; lab’da yönetim VLAN’ı 192.168.10.0/24.

Tür değişince formdan Password ve Two-factor Authentication alanları kalkıyor. Joker kayıt tek bir kişiye ait olmadığı için ona bir parola ya da kişisel bir token bağlanamaz; ikinci doğrulama, kimliği doğrulayan sunucunun işidir. LDAP’ın kendisi ikinci bir doğrulama taşımaz; ayrıcalıklı hesapta çok faktörlü doğrulama isteyen kurumda giriş RADIUS üzerinden bir MFA sunucusuna bağlanır.

Aynı kaydın komut satırındaki karşılığı:

config system admin
    edit "ag-yoneticileri"
        set remote-auth enable
        set trusthost1 192.168.10.0 255.255.255.0
        set accprofile "super_admin"
        set comments "AD grubu USER_FW_YONETICILER, LDAPS"
        set wildcard enable
        set remote-group "ag-yoneticileri"
    next
end

ilker.pehlivan.adm ile web arayüzüne girdim. Olay kaydı girişin kimin adına ve hangi yetkiyle yapıldığını yazdı:

date=2026-10-01 time=08:36:26 ... logdesc="Admin login successful" user="ilker.pehlivan.adm" 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 ilker.pehlivan.adm logged in successfully from http(192.168.10.225)"

Satırdaki http lab cihazının deneme lisansından geliyor: lisans yönetim arayüzünü HTTPS yerine HTTP’ye zorluyor. Gerçek cihazda arayüze yalnız HTTPS ile girilir; nedenini yönetim erişimi yazımızda anlattık.

FortiGate “Invalid Password” Dediğinde Parola Doğru Olabilir

Merkezi girişin iki başarısız hâlini de denedim:

1. Gruba üye olmayan bir AD hesabı. muhasebe.deneme’nin parolası doğruydu; diagnose test authserver ldap aynı parolayla succeeded dedi. Hesap yalnız USER_FW_YONETICILER’e üye değildi.
2. Domain controller’a ulaşılamayan yönetici. FortiGate ile dc01 arasındaki yolu kestim ve ilker.pehlivan.adm ile doğru parolayla girmeyi denedim.

İki giriş de reddedildi ve log ikisine de aynı sebebi yazdı:

date=2026-10-01 time=08:36:31 ... logdesc="Admin login failed" ... user="muhasebe.deneme" ... status="failed" reason="passwd_invalid" msg="Administrator muhasebe.deneme login failed from http(192.168.10.225) because of invalid password"
date=2026-10-01 time=08:47:20 ... logdesc="Admin login failed" ... user="ilker.pehlivan.adm" ... status="failed" reason="passwd_invalid" msg="Administrator ilker.pehlivan.adm login failed from http(192.168.10.225) because of invalid password"

İki hesabın da parolası doğruydu. Bu satırı gören kişi önce parolaya değil, hesabın grubuna ve FortiGate’in sunucuya ulaşıp ulaşamadığına bakar; diagnose test authserver ldap ikisini birbirinden ayırır. RADIUS yazısındaki teşhis LDAPS için de geçerli.

FortiGate’te Yerel Acil Durum Hesabı Açmak

Yol kesikken aynı saniyede yerel acil durum hesabıyla da denedim. Lab’da bu hesabın adı xt2vbx9; neden böyle bir ad taşıdığını aşağıdaki uyarıda anlatıyorum. AD hesabının cevabı 7 saniye sürmüştü, çünkü FortiGate domain controller’dan cevap bekledi. xt2vbx9 10 milisaniyede girdi, çünkü parolası FortiGate’in kendi listesinde duruyor ve dizine bağlı değil:

date=2026-10-01 time=08:47:20 ... logdesc="Admin login successful" ... user="xt2vbx9" ui="http(192.168.10.225)" ... status="success" reason="none" profile="super_admin" msg="Administrator xt2vbx9 logged in successfully from http(192.168.10.225)"

Hesap aynı formda açılır, Type bu kez Local User kalır:

1. Username: tahmin edilemeyen bir ad; aşağıdaki uyarıya bakın. Lab’daki xt2vbx9 rastgele üretildi ve hiçbir şey söylemiyor.
2. Password: en az 15 karakterlik rastgele bir dizi.
3. Comments: hesabın ne zaman kullanılacağını söyleyen not. Ad hesabın işini ele vermediği için hesabın acil durum hesabı olduğunu yalnız bu alan söyler; lab’da Acil durum hesabi: yalniz AD/LDAPS yokken.
4. Administrator profile: super_admin. Merkezi giriş bozulduğunda onu düzeltebilecek hesap budur.
5. Restrict login to trusted hosts: yönetim ağı.

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

config system admin
    edit "xt2vbx9"
        set trusthost1 192.168.10.0 255.255.255.0
        set accprofile "super_admin"
        set comments "Acil durum hesabi: yalniz AD/LDAPS yokken"
        set password <en-az-15-karakterlik-parola>
    next
end

Hesap açıldıktan sonra parolası güvenilir kişiye teslim edilir ve kimse onu günlük işte kullanmaz. Merkezi girişi kurmadan önce bu hesabı açıp girişini denemek, yanlış bir ayarın sizi cihazın dışında bırakmasını önler.

FortiGate Yetki Profilleri: super_admin ve prof_admin Farkı

Yetkiler System → Admin Profiles ekranında tutulur. Fabrika ayarında iki profil hazır geliyor: super_admin ve prof_admin. Adından dolayı prof_admin sınırlı bir yönetici sanılabilir. Profilin içine baktığımda on izin grubunun onunun da okuma-yazma (read-write) olduğunu gördüm.

Farkı ölçmek için prof_admin profiliyle bir profyonetici hesabı açtım ve bu hesapla beş iş denedim. Adres nesnesi eklemek ve başka bir yönetici hesabı açmak çalıştı; hesap kaydedildi. Genel ayardaki oturum süresini değiştirmek de çalıştı (set admintimeout 31 kaydedildi). İki iş ise reddedildi:

gmfw01 (admin) $ node_check_object fail! for name admin
value parse error before 'admin'
Command fail. Return code -37
...
gmfw01 (profyonetici) $ The Super Admin attribute can't be changed while the user is logged in
node_check_object fail! for accprofile super_admin
value parse error before 'super_admin'
Command fail. Return code -651

İlk hata super_admin hesabı admin’i düzenleme denemesine, ikincisi hesabın kendine super_admin profilini verme denemesine ait. Yani prof_admin’in tek sınırı super_admin’e dokunamamaktır; geri kalan her şeyi değiştirebilir, başka yöneticiler de açabilir. Günlük işi yapan bir yöneticiye bu profil verilebilir, ama yalnız izlemesi gereken birine verilmez.

FortiGate Salt Okunur Profil: Log Okuyacak Kişi İçin

Yalnız izleyecek birine, örneğin logları okuyan bir denetçiye, ayrı bir profil açılır. System → Admin Profiles → Create New ile açılan formda her izin grubu için None, Read ya da Read/Write seçilir.

Bu profille bir okuyucu hesabı açıp SSH ile bağlandım. Komut istemi gmfw01 # yerine gmfw01 $ oldu. show ile yapılandırmayı okuyabildim; config ile başlayan her satıra ise cihaz “Unknown action 0” dedi. Yazma komutları bu hesap için hiç yok.

Formun en altındaki Permit usage of CLI diagnostic commands seçeneği ise fabrikadan açık geliyordu. Teşhis komutlarının neyi kapsadığını görmek için aynı okuyucu hesabıyla yönetim portunda paket yakalamayı denedim:

gmfw01 $ Using Original Sniffing Mode
interfaces=[port1]
filters=[icmp]
3.076166 port1 -- 192.168.10.225 -> 192.168.10.1: icmp: echo request
3.076233 port1 -- 192.168.10.1 -> 192.168.10.225: icmp: echo reply

Bütün izin grupları salt okunur olan hesap, cihazın portundan geçen paketleri yakalayabildi. Paket yakalama yapılandırmayı değiştirmez, ama trafiğin kendisini gösterir; bir denetçinin görmesi gereken şey bu değildir. Seçeneği kapatınca (set system-diagnostics disable) aynı komut “Unknown action 0” ile reddedildi. Salt okunur profilde bu seçenek kapatılır.

FortiGate Admin Hesabında İki Aşamalı Doğrulama

Yerel hesap formundaki Two-factor Authentication seçeneği lab cihazımda fabrikadan kapalıydı. Açıldığında dört doğrulama türü çıkıyor: FortiToken Cloud, FortiToken, Email ve SMS. Parolası çalınan bir yönetici hesabı firewall’un bütün kurallarına erişim demektir; NIST de ayrıcalıklı hesaplarda çok faktörlü doğrulamayı şart koşuyor (SP 800-53, IA-2(1)). İki aşamalı doğrulamanın neden işe yaradığını ayrı yazıda anlattık.

AD grubuyla giren yöneticilerde bu seçenek formda yok; ikinci doğrulama yukarıda anlattığımız gibi merkezi tarafta kurulur. Lab cihazımda iki aşamalı girişi ölçmedim: FortiToken bir token ister, e-posta ve SMS de cihaza tanımlı bir gönderim sunucusu ister.

FortiGate Admin Hesabına SSH Anahtarı Tanımlamak

SSH anahtarı, FortiGate’e komut satırından parola yazmadan girmenin yoludur. Komut satırından giren yerel hesaplar için uygundur: her gece yapılandırma yedeğini alan bir betik ya da lab’daki ölçüm hesabım gibi. Önce anahtarın ne olduğunu, sonra FortiGate’e nasıl tanıtıldığını adım adım anlatıyorum.

SSH Anahtarı Nedir? Özel Anahtar ve Açık Anahtar

Parolayla girişte kapıdaki görevliye gizli bir söz söylersiniz ve söz doğruysa kapı açılır. Bu yöntemde sözün kendisi kapıya kadar gider; kısa bir söz de tahmin edilebilir.

SSH anahtarı ise bir söz değil, birlikte üretilen iki parçalı bir çifttir:

1. Özel anahtar (gizli anahtar da denir) cebinizdeki mühürdür. Yalnız sizin bilgisayarınızda durur ve kimseye verilmez; FortiGate’e de verilmez.
2. Açık anahtar o mührün kâğıda bastığı izdir. Herkes görebilir, çünkü izden mühür yapılamaz. FortiGate’e verdiğimiz parça budur.

İki parça aynı anda ve birbirine bağlı üretilir. Bir açık anahtarın izini yalnız onun kendi özel anahtarı bırakabilir.

FortiGate Anahtarla Girişi Nasıl Doğrular?

Örnekteki sınır kapısının kulübesinde bir iz defteri durur ve her görevlinin mühür izi o deftere basılıdır. Gelen kişi mührünü görevliye vermez. Görevli ona o güne özel yeni bir kâğıt uzatır, kişi kâğıdı kendi mührüyle damgalar ve görevli damgayı defterdeki izle karşılaştırır. FortiGate de her girişte aynı üç adımı uygular:

1. FortiGate yeni bir kâğıt uzatır. Bağlantıya özel, her seferinde farklı bir veri gönderir.
2. Bilgisayarınız kâğıdı özel anahtarla imzalar. Özel anahtar bilgisayardan çıkmaz; FortiGate’e yalnız imza gider.
3. FortiGate imzayı hesabın açık anahtarıyla karşılaştırır. İmza o açık anahtarın çiftinden geldiyse kapı açılır.

Bu düzenin iki kazancı var:

1. Ağda sır dolaşmaz. Ne parola gider ne özel anahtar; hattı dinleyen biri yalnız o bağlantıya ait bir imza görür.
2. Yakalanan imza bir daha işe yaramaz. Her girişte kâğıt değiştiği için dünkü imza bugünkü kâğıda uymaz.

Sorumluluk da size geçer. Özel anahtar dosyası mührün kendisidir ve dosyayı kopyalayan kişi sizin yerinize girer. Bu yüzden anahtar üretilirken dosyaya ayrıca bir parola (passphrase) konur; dosya çalınsa bile o parola olmadan kullanılamaz. Mekanizmanın tamamını SSH nedir yazımızda anlattık.

1. Adım: Anahtar Çiftini Bilgisayarınızda Üretin

Windows’ta PowerShell’i, Linux’ta terminali açıp şu komutu yazın:

ssh-keygen -t ed25519 -C "ilker.pehlivan@yonetim-pc" -f ilker_fw_anahtar

Komutun üç parçası var:

1. -t ed25519 anahtarın türüdür. Ed25519 kısa ve güçlü bir türdür; lab’daki FortiOS 7.0.10 bu türü kabul etti.
2. -C anahtarın sonuna eklenen nottur ve anahtarın kime ait olduğunu söyler.
3. -f anahtar dosyalarının adıdır.

Komut anahtar dosyası için bir parola sorar. Boş bırakmayın; bu parola, yukarıda anlattığımız mührün kilididir. Lab’da aldığım çıktının ilk satırları:

Generating public/private ed25519 key pair.
Your identification has been saved in ilker_fw_anahtar
Your public key has been saved in ilker_fw_anahtar.pub
The key fingerprint is:
SHA256:m2mf5SSDHUvapQHrYzKKPZfkC6tjuKYO87oUH4M3WT4 ilker.pehlivan@yonetim-pc
...

Komutu çalıştırdığınız klasörde iki dosya oluşur:

1. ilker_fw_anahtar özel anahtardır. Bilgisayarınızda kalır ve kimseyle paylaşılmaz.
2. ilker_fw_anahtar.pub açık anahtardır; .pub İngilizce “public”, yani açık demektir. FortiGate’e bu dosyadaki satır gider.

2. Adım: Açık Anahtarı FortiGate’e Yazın

Yönetici formunda anahtar alanı yok; yukarıdaki acil durum formunda da yalnız parola alanları görünüyor. Açık anahtar bu yüzden komut satırından yazılır.

ilker_fw_anahtar.pub dosyasını Not Defteri ile açın. Dosya tek satırdır ve ssh-ed25519 ile başlar. Satırın tamamını kopyalayıp FortiGate’in komut satırında hesaba yapıştırın. Lab’da hesabın birinci anahtar yeri dolu olduğu için ikinci yeri kullandım:

config system admin
    edit "ilker.pehlivan"
        set ssh-public-key2 "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIIsj... ilker.pehlivan@yonetim-pc"
    next
end

Her hesapta üç anahtar yeri var: ssh-public-key1, ssh-public-key2 ve ssh-public-key3. Örneğin masaüstü ve dizüstü bilgisayarınız için ayrı anahtarlar tanımlayabilirsiniz.

3. Adım: Anahtarla Bağlanın

Bağlantıyı özel anahtar dosyasını göstererek açın. -v ayrıntılı çıktı verir ve girişin hangi yoldan yapıldığını gösterir:

ssh -v -i ilker_fw_anahtar ilker.pehlivan@192.168.10.1

Lab’da anahtarın parolasını bir kez ssh-agent’a verdim (ssh-add), bu yüzden satırların sonunda agent yazıyor. Ayrıntılı çıktının ilgili satırları:

debug1: Authentications that can continue: publickey,password
debug1: Offering public key: ilker_fw_anahtar ED25519 SHA256:... explicit agent
debug1: Server accepts key: ilker_fw_anahtar ED25519 SHA256:... explicit agent
Authenticated to 192.168.10.1 ([192.168.10.1]:22) using "publickey".

Satırlar sırayla şunu söylüyor:

1. Authentications that can continue: FortiGate hem anahtarı hem parolayı kabul ediyor.
2. Offering public key: bilgisayar anahtarını sundu.
3. Server accepts key: FortiGate açık anahtarı hesabın satırında buldu.
4. Authenticated ... using "publickey": imza tuttu ve giriş anahtarla açıldı.

İlk satır bir şeyi daha söylüyor: anahtar tanımlı hesap parolayla da girebilir. Parolalı SSH girişini kapatan admin-ssh-password ayarı (config system global) tek hesaba değil bütün hesaplara uygulanır. AD’den SSH ile giren yöneticiler parola kullandığı için lab’da bu ayarı açık bıraktım.

Anahtarı Geri Almak

Kişi ayrıldığında ya da bilgisayarı kaybolduğunda açık anahtar hesaptan silinir (unset ssh-public-key2). Sildikten sonra aynı anahtarla bağlanmayı denedim:

ilker.pehlivan@192.168.10.1: Permission denied (publickey,password).

Defterden iz silinince mühür artık o kapıyı açmaz.

Doğrulama: FortiGate Hesapları ve Yetkileri Beklendiği Gibi mi?

Hesaplar kurulduktan sonra beş şey kontrol edilir:

1. Yerel hesap listesi. get system admin bütün yönetici kayıtlarını listeler. Kurulumu biten cihazda yerel türde tek hesap acil durum hesabıdır; listede kimseye ait olmayan ya da ayrılmış birine ait hesap kalmaz.
2. Merkezi giriş. AD’deki yönetici hesabıyla girilir ve logda kişinin adı ile profili görünür. Gruba üye olmayan bir AD hesabı, parolası doğru olsa bile reddedilir.
3. Acil durum hesabı. Domain controller’a ulaşılamazken giriş yapabilir ve girişi logda ayrı bir satır olarak görünür.
4. Yetkinin sınırı. Salt okunur hesapla bir değişiklik denenir; reddedilmelidir. Teşhis seçeneği kapatıldıysa diagnose komutları da reddedilir.
5. Logdaki iz. Kişisel hesapla yapılan bir değişiklikten sonra Log & Report → Events altındaki sistem olaylarında o değişikliğin satırı, hesabın adıyla görünmelidir.

Sonuç: Yetkiyi Profil Belirler, İzi Hesap Bırakır

FortiGate’te hesap, değişikliğin kimde olduğunu söyler; profil o kişinin neleri değiştirebileceğini belirler, merkezi giriş de hesabın tek yerden açılıp kapanmasını sağlar. Lab’da üç şey beklenenden farklı çıktı:

1. prof_admin neredeyse tam yetkiliydi. Adı sınırlı bir yönetici gibi duruyordu.
2. Salt okunur profil trafiği dinleyebiliyordu, çünkü teşhis komutları açık kalmıştı.
3. Parolası doğru iki yönetici “invalid password” ile düştü. Biri gruba üye değildi, diğeri sunucuya ulaşılamadığı için giremedi.

Örnekteki sınır kapısında da her görevli kendi mührünü taşır, mührü olmayan yalnız okur. Kasadaki yedek mühür merkezle bağlantı koptuğu gün çıkar ve kullanıldığı gün kayda geçer. Kimin hangi mühre sahip olduğu da kapı açılmadan yazılır.

Kurulumun geri kalanını 20 adımlık kontrol listesinde 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