FortiGate Firewall Yedek Alma ve Geri Yükleme

FortiGate Firewall yedek alma, cihazın yapılandırmasını bir dosya olarak cihazın dışına almaktır; geri yükleme de o dosyayı cihaza geri yazmaktır. NSA’nın ve Fortinet’in tarif ettiği düzende yedek her değişiklikten önce ve sonra alınır, cihazın dışına şifreli bir yolla (SFTP ya da SCP) taşınır, geçmişiyle saklanır ve düzenli olarak denenir.

Bu yazı FortiGate Firewall yapılandırma rehberimizin 16. adımıdır. Arayüzden yedek almayı ve şifreli ile şifresiz dosyanın farkını FortiGate kullanım rehberimizde ölçtük; burada yedeğin düzenini kuruyorum.

Lab’da üç şey beklenenden farklı çıktı. Salt okuma yetkili bir hesabın çektiği yedekte diğer yöneticilerin hiçbiri yoktu. Hiçbir şey değişmeden alınan iki yedek 240 satır farklıydı. FortiOS 7.0 da yedeği SFTP’ye gönderebildi ama oradan geri yükleyemedi.

Örnekteki sınır kapısında talimat panosu kulübenin duvarında asılıdır ve bir kopyası bölge müdürlüğünde saklanır. Kopyayı geri asmak için kapı bir süre kapanır; pano kopyanın alındığı güne döner ve o günden sonra eklenen her şey düşer. FortiGate’te pano çalışan yapılandırma, kopya yedek, müdürlük yedek sunucusu, kapalı kapı da geri yüklemenin kesintisidir.

Bu yazı, Kurumsal Network Kurulumu hizmetimizde yönettiğimiz her firewall için kurduğumuz yedek düzenini anlatır.

FortiGate’te Geri Dönüş Yolu Neden Yalnız Yedektir?

NSA’nın ağ altyapısı rehberi (bölüm 3.2) çoğu ağ cihazının iki yapılandırma tuttuğunu yazar: biri kalıcı belleğe kaydedilmiş, biri bellekte çalışan. Böyle bir cihazda kaydedilmemiş yanlış bir değişiklik, cihaz yeniden başlatılarak geri alınabilir. FortiGate’te bu ayrım fabrika ayarında yoktur:

    set cfg-save automatic

cfg-save automatic, her değişikliğin yazıldığı anda kalıcı olduğunu söylüyor. Yanlış bir kural da, silinen bir yönetici hesabı da kaydedilmiştir; cihazı yeniden başlatmak onu geri getirmez. Dönülecek tek yer, değişiklikten önce alınmış bir kopyadır.

FortiGate’te Yedek Düzeni Nasıl Olmalı?

Yedek üç katmanda durur: cihazın içindeki sürümler, cihazın dışında her gece güncellenen ve geçmişi tutulan yedek, bir de büyük bir değişiklikten hemen önce elle alınan yedek. Cihaz dışı yedek şifreli bir yolla taşınır, deposuna yalnız yedek hesabı erişir ve yedek ara ara geri yüklenerek denenir.

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

1. Fortinet FortiOS 7.0 Best Practices, Configuration changes sayfası: değişiklik prosedürü, herhangi bir değişiklikten önce çalışan yapılandırmanın yedeğini alma adımıyla başlar ve değişiklikten sonra yeni bir yedekle biter. Aynı sayfa birden çok eski yapılandırmanın saklanmasını önerir.
2. NSA Network Infrastructure Security Guidance (Mart 2022, sürüm 1.0): bölüm 3.1 yedeği değişiklik kontrolünün parçası sayar ve çalışan yapılandırmanın düzenli olarak en son yedeklerle karşılaştırılmasını ister. Bölüm 3.2 taşımayı ve depoyu tarif eder: yapılandırmalar uzağa kopyalanırken SFTP ya da SCP gibi şifreli bir protokol kullanılır, yedekleme ya da arşivleme düzeni ve yedek deposu da yetkisiz erişime karşı korunmalıdır. Aynı bölüm cihazın kendi diskinde duran eski yedek dosyalarının silinmesini önerir.
3. NIST SP 800-41 Rev. 1 (Eylül 2009), bölüm 5.5: firewall policy’leri ve kural setleri düzenli olarak yedeklenmeli. Cihaz yapılandırmayı birden çok biçimde verebiliyorsa (cihazın yüklediği biçim ve denetçinin okuduğu biçim) yedek hepsinde tutulur.
4. Fortinet PSIRT bildirimi FG-IR-19-007 (Haziran 2020): yapılandırmadaki ENC değerleri sabit bir anahtarla şifrelenmiştir ve yapılandırmaya ya da yedek dosyasına erişen kişi parolaları çözebilir. Bildirimin önerdiği geçici önlem açıktır: yedek alırken yapılandırma dosyası her zaman parolayla korunur.

Üç katmanın farkı:

Tablonun ortadaki sütunu yazının büyük kısmını alıyor, çünkü cihaz dışı yedeğin iki yolu var ve ikisinin de bir bedeli var.

Kaç Yedek, Ne Kadar Süre?

NSA de NIST de bir sayı vermiyor, Fortinet yalnız birden çok eski yapılandırma diyor. Pratik karşılığı iki yerde farklı:

1. Cihaz dışında: her gerçek değişiklik için bir sürüm ve bunların hepsini tutan bir geçmiş. Bir FortiGate yapılandırması 360 KB civarında; yıllarca sürüm tutmak bir yedek sunucusunun diskinde fark edilmez. Sayıyı belirleyen disk alanı değil, kurumun ne kadar geriye dönmek isteyebileceğidir.
2. Cihazın içinde: birkaç sürüm. NSA’nın 3.2 bölümü cihazda duran eski yedek dosyalarının silinmesini öneriyor, çünkü her eski sürüm o günün parolalarını da taşır. Uzun geçmiş cihaz dışındaki depoda durur.

Ne Zaman Yedek Alınır?

1. Her değişiklikten önce ve sonra: Fortinet’in prosedüründeki iki yedek.
2. Her gece: değişikliği yapan kişi yedeği unutsa bile kopya bir günden eski olmasın.
3. Yazılım güncellemesinden önce: güncelleme yapılandırmayı da dönüştürür; geri dönüş eski sürümün yedeğiyle yapılır.
4. Geri yüklemeden hemen önce: geri yükleme yanlış giderse dönülecek bir yer kalsın.

Yedeğin denenmesi de bir zamanlamadır: bu yazıdaki gibi bir geri yükleme bakım penceresinde ara ara yapılır.

FortiGate Sürümleri: Revisions

Cihazın kendi sürüm listesi, oturum kapanırken alınan kopyalardır. Seçeneğin fabrika ayarına baktım:

    set revision-backup-on-logout disable

Fabrika ayarında kapalı; açtım (config system global, set revision-backup-on-logout enable). Sonra üç oturum açıp kapattım: ayarı açan oturum, depo arayüzüne açıklama yazan oturum ve hiçbir şeyi değiştirmeyen bir oturum. İlk ikisi sürüm üretti, üçüncüsü üretmedi:

ID  TIME                   ADMIN             FIRMWARE VERSION          	COMMENT
...
3   2026-10-02 00:04:16    ilker.pehlivan    V7.0.10-build450-REL0 	Automatic backup (logout)
4   2026-10-02 00:04:20    ilker.pehlivan    V7.0.10-build450-REL0 	Automatic backup (logout)

Menü yolu: sağ üstteki kullanıcı adı → Configuration → Revisions. Ekran sürümleri sürüme göre gruplar; iki sürüm seçilip Diff ile karşılaştırılır, Revert ile eskisine dönülür.

Sürümlerin bir sınırı var: cihazın içindeler. Cihaz arızalanırsa ya da değiştirilirse sürümler de gider. Cihazın içindeki kopyanın cihazla birlikte gideceğini switch tarafında switch yapılandırma yedeği yazımızda anlattık; FortiGate’te de aynı kural geçerli.

Fark 243 Satır, Değişiklik Tek Satır

3 ve 4 numaralı sürümleri Diff ile karşılaştırdım. Aralarındaki tek değişiklik depo arayüzünün açıklamasıydı, ama farkta 243 satır değişmiş görünüyordu: 122 eklenen, 121 silinen.

Kalan satırlar şöyle dağılıyordu:

1. 42 satır set password ENC satırıydı: 21 silinen, 21 eklenen.
2. 198 satır bu parolaların ve sertifika özel anahtarlarının şifreli gövdesiydi.
3. 2 satır dosyanın sürüm numarasıydı (#conf_file_ver).

Hiçbir parolayı değiştirmemiştim. FortiGate şifreli metni her kayıtta yeniden üretiyor; bu yüzden değişmemiş bir parola da farkta değişmiş görünüyor. Teşhis sırası şöyle:

1. Farkta önce şifreli olmayan satırlara bakılır; ENC taşıyan satırlar ve onların devamı atlanır.
2. Aynı şey otomatik yedekte de olur: hiçbir şey değişmeden alınan iki yedek de farklıdır. Bunu aşağıdaki çekme betiğinde ölçtüm ve betiği buna göre yazdım.

FortiGate’ten Cihaz Dışına Yedek: TFTP ve SFTP

Cihaz dışı yedek için FortiGate execute backup config komutunu TFTP, FTP ve SFTP ile çalıştırabiliyor. Lab’daki yedek sunucusu 192.168.1.46; TFTP tarafını TFTP sunucusu kurulumu yazımızda kurduk. Aynı yedeği önce TFTP ile, sonra SFTP ile gönderdim ve sunucu tarafında ağı yakaladım.

TFTP ile önce parolasız yedeği gönderdim:

gmfw01 # execute backup config tftp gmfw01-sifresiz.conf 192.168.1.46
Please wait...
Connect to tftp server 192.168.1.46 ...
#
Send config file to tftp server OK.

Aynı komutu sonuna bir yedek parolası ekleyerek tekrarladım. Sunucuya düşen iki dosya çok farklıydı:

1. Parolasız yedek: 359.935 bayt, ilk satırı #config-version=FGVM64-7.0.10-FW-build0450-230221:opmode=0:vdom=0:user=ilker.pehlivan. Sürümü ve yedeği alan kullanıcıyı açıkça yazıyor; içinde 26 set password ENC satırı ve 21 özel anahtar bloğu var.
2. Parolalı yedek: 57.894 bayt, ilk satırı #FGBK|4|FGVM64|7|00|0450|; sonrası okunamıyor.

TFTP’nin kendisi şifresiz bir protokol. Parolasız yedeğin yakalamasında adresler, kurallar, kullanıcı adları ve ENC ile saklanan parola satırları, yani yapılandırmanın tamamı yolda okunuyordu. FG-IR-19-007’nin anlattığı risk burada başlıyor: ENC değerinin kendisi bir koruma sayılmaz. Dosyaların izni de -rw-rw-rw- idi, yani sunucudaki herkes okuyabiliyordu; bunun sebebini ve düzeltmesini TFTP yazımızın izin bölümünde anlattık.

Aynı yedeği SFTP ile, bu kez parolasız gönderdim (execute backup config sftp gmfw01-sftp-sifresiz.conf 192.168.1.46 fgtyedek <sftp-parolasi>). Yakalanan 248 paketin hiçbirinde tek bir yapılandırma satırı görünmedi. Ama sunucuya düşen dosya yine düz metindi:

#config-version=FGVM64-7.0.10-FW-build0450-230221:opmode=0:vdom=0:user=ilker.pehlivan

İki koruma iki ayrı işi yapıyor:

1. SFTP yolu korur: dosya yolda okunamaz, sunucuya kimin bağlandığı doğrulanır.
2. Yedek parolası dosyayı korur: dosya sunucunun diskinde, bir başka yedekte ya da e-postada da okunamaz.

NSA şifreli yolu ve korunan depoyu, Fortinet’in bildirimi de parolalı yedeği istiyor; ikisi birbirinin yerini tutmuyor. Bildirimin kalıcı çözümü private-data-encryption seçeneğidir: ENC değerleri sabit anahtar yerine cihaza özel bir anahtarla şifrelenir. Lab’daki deneme lisanslı sanal makinede bu seçenek komut satırında yoktu (command parse error before 'private-data-encryption'), bu yüzden etkisini ölçemedim. Seçenek sizin cihazınızda varsa, açmadan önce kendi sürümünüzün kılavuzundaki sayfasını okuyun.

Parolalı yedeğin bir bedeli de var: içi şifreli olduğu için parola kaybında içinden parola satırı silinemez. 7.2.4 ve sonrasında parolası kaybolan FortiGate’e dönmenin yolu tam olarak bu satırı silip yedeği geri yüklemek. Bu yüzden parolalı yedeğin yanında, erişimi kısıtlı ve şifreli bir depoda şifresiz bir kopya da tutulur. Ölçümünü FortiGate şifre sıfırlama yazımızda anlattık.

Lab’da TFTP’nin NAT arkasından çalışması için yönlendiricide TFTP yardımcısının açılması da gerekti. Yakalamada sunucunun cevabı 69 numaralı porttan değil, yeni bir porttan (58507) geliyordu; yardımcı olmadan NAT bu cevabı tanımadı ve sunucuya 0 baytlık dosyalar düştü.

Cihazın Gönderdiği Yedek: Otomasyon Zinciri

Elle yedek unutulur. FortiGate’te düzenli yedek, bir tetikleyici ile bir eylemi bağlayan otomasyon zinciriyle (Security Fabric → Automation) kurulabilir. Her gece 02:00’de SFTP’ye şifreli yedek alan zincir:

config system automation-trigger
    edit "gece-yedek"
        set trigger-type scheduled
        set trigger-hour 2
    next
end
config system automation-action
    edit "sftp-yedek"
        set action-type cli-script
        set script "execute backup config sftp gmfw01-otomatik.conf 192.168.1.46 fgtyedek <sftp-parolasi> <yedek-parolasi>"
        set accprofile "super_admin"
    next
end
config system automation-stitch
    edit "gunluk-yedek"
        set trigger "gece-yedek"
        config actions
            edit 1
                set action "sftp-yedek"
            next
        end
    next
end

Bu blokta iki parolayı ben maskeledim; cihazın kendi show çıktısında ikisi de yazıldığı gibi duruyor. Zincir, otomasyon listesinde Schedule grubunda görünüyor:

Geceyi beklemeden zinciri elle tetikledim (diagnose automation test gunluk-yedek). Sunucuya 58.141 baytlık şifreli bir dosya düştü ve olay loguna zincirin çalıştığı yazıldı:

1: date=2026-10-02 time=00:07:09 ... logdesc="Automation stitch triggered" stitch="gunluk-yedek" trigger="gece-yedek" stitchaction="sftp-yedek" from="scheduled" msg="stitch:gunluk-yedek is triggered."

Betikteki Parola Üç Yere Yazılıyor

Eylemin formunu açınca betik, iki parolasıyla birlikte açık görünüyor:

Yapılandırmadaki öteki parolalar ENC ile şifreli saklanırken betik yazıldığı gibi kaydediliyor. Eylemi kurduğum anda olay loguna bir Object attribute configured kaydı düştü; kaydın içinde betik, iki parolasıyla birlikte, aynen yazıyordu:

3: date=2026-10-02 time=00:06:55 ... logdesc="Object attribute configured" user="ilker.pehlivan" ui="ssh(192.168.10.225)" action="Add" ... cfgpath="system.automation-action" cfgobj="sftp-yedek" cfgattr="action-type[cli-script]script[execute backup config sftp gmfw01-otomatik.conf 192.168.1.46 fgtyedek [SFTP-PAROLASI] [YEDEK-PAROLASI]]accprofile[super_admin]" ...

Bu satırda parolaları ben maskeledim. Olay logu syslog sunucusuna da gidiyor; sunucunun diskinde aradığımda parola /var/log/uzak/gmfw01/-.log dosyasında çıktı. Yani iki parola üç yere yazıldı:

1. Yapılandırmaya: cihazı okuyabilen her yönetici ve bundan sonraki her yedek onu taşıyor.
2. Cihazın olay loguna.
3. Syslog sunucusunun diskine: UDP ile, şifresiz.

SFTP parolası yedek sunucusundaki bir hesabın parolası olduğu için, bu düzende firewall’un yapılandırmasını ya da loglarını okuyabilen herkes yedek deposunun kapısını da açabilir. Yedeği cihaza göndertmek yerine sunucuya çektirmek bu sorunu ortadan kaldırıyor.

Sunucunun Çektiği Yedek: Anahtar Kimde Durur?

Bir arkadaşınıza defterinizin fotokopisini iki yoldan verebilirsiniz. Ya kopyayı onun evine siz götürürsünüz; bunun için evinin anahtarı sizin cebinizde durmalıdır. Ya da o sizin kapınıza gelip kopyayı alır; bunun için onu tanımanız yeter. İlkinde arkadaşınızın anahtarı sizin cebinizdedir, ikincisinde kimsenin anahtarı başkasının cebinde değildir.

Bu sahneyi sınır kapısının beş parçası taşıyor:

1. Yedek talimat panosunun kopyasıdır.
2. Yedek sunucusu bölge müdürlüğüdür; kopyalar orada saklanır.
3. SFTP parolası müdürlüğün kapı anahtarıdır.
4. Olay logu kapının nöbet defteridir; kapıda yapılan her iş oraya yazılır.
5. FortiGate’teki açık anahtar kapıdaki iz defterine basılmış mühür izidir; müdürlükten gelen memur mührünü basınca kapı onu tanır.

Örnekteki sınır kapısında kopyayı müdürlüğe kapıdaki görevli götürürse, müdürlüğün anahtarı kapıda durur ve görevli işini nöbet defterine yazarken anahtarın numarasını da yazar. Kopyayı müdürlükten gelen memur alırsa kapıda yalnız memurun mühür izi durur; izden anahtar da mühür de yapılamaz. FortiGate’te mekanizma şöyle işliyor:

1. Yedek sunucusunda bir anahtar çifti üretilir. Özel anahtar sunucuda kalır.
2. FortiGate’te bir yedek hesabı açılır ve hesaba açık anahtar yazılır; hesap yalnız yedek sunucusunun adresinden ve yalnız gece penceresinde girebilir.
3. Sunucu her gece SCP ile bağlanır ve sys_config dosyasını, yani yapılandırmanın kendisini, kendi diskine kopyalar.
4. Sunucu yeni kopyayı geçmişle karşılaştırır ve yalnız gerçek bir değişiklik varsa yeni sürüm yazar.

NIST’in otomatik SSH erişimi rehberi NISTIR 7966 (Ekim 2015) bu düzeni önerir: SSH ile otomatik erişimde önerilen kimlik doğrulama yöntemi açık anahtarla doğrulamadır. Fortinet’in 7.0 en iyi uygulama kılavuzu da yönetim erişimi sayfasında aynısını söylüyor: SSH üzerinden betikle yönetilen bir FortiGate’te, betiğin içinde parola tutmamak için kullanıcı sertifikayla doğrulanır. Kazançlar:

1. Firewall’da yedek deposunun hiçbir parolası durmaz; yapılandırmayı, logu ya da syslog sunucusunu okuyan kişi depoya giremez.
2. Anahtar tek adresten çalışır: FortiGate’teki hesap yalnız yedek sunucusunun adresinden girişe izin verir. NISTIR 7966 otomatik anahtarlar için bu kaynak sınırını açıkça istiyor.
3. Her çekiş loga düşer ve tek tip bir kayıt bırakır; 5. adımda bu kaydı izlemenin dayanağı yapıyoruz.

Bedel de aynı mekanizmadan geliyor ve üçü de ölçüldü:

1. Yedek hesabı super_admin olmak zorunda kaldı; kısıtlı profillerin çektiği yedek eksik geldi (3. adım).
2. Anahtar komut satırı da açıyor. NISTIR 7966 otomatik anahtarların bir komut sınırıyla bağlanmasını istiyor; 7.0.10’un yönetici hesabında böyle bir sınır yok. En yakın sınırı 5. adımda saatle kuruyoruz.
3. Çekilen dosya şifresiz geliyor.

Bu yüzden özel anahtar dosyası ve depo, firewall’un kendisi kadar korunur: yedek sunucusunu ele geçiren kişi, anahtarla firewall’a da girer.

1. Adım: Yedek Sunucusunda Anahtar Üretin

Yedek sunucusunda, yedeği yalnız bu işe ayrılmış fgtyedek kullanıcısı alıyor. Anahtar çiftini o kullanıcı adına ürettim:

sudo -u fgtyedek ssh-keygen -q -t ed25519 -N "" -C "fgtyedek@sistemkusu-syslog" -f /srv/fgt-yedek/.ssh/id_ed25519

Komutun parçaları:

1. -t ed25519: anahtar türü.
2. -N "": anahtar dosyasının parolası yok.
3. -f: anahtarın yeri; /srv/fgt-yedek dizininin izni 700, yani dizine yalnız fgtyedek girebilir.

Yönetici hesabı yazısında anahtar dosyasına parola koymanızı söyledik, burada koymuyoruz. Gece 02:00’de anahtarın parolasını yazacak kimse yok. NISTIR 7966 da bunu söyler: otomatik erişimde anahtar genellikle parolasız durur, parolayı betiğe yazmak ise güvenliğe pek az şey katar. Mührün kilidi olmayınca korumayı dizinin izni ve FortiGate’teki hesabın sınırları üstlenir.

Yedek sunucunuz Windows ise anahtar aynı araçla üretilir. OpenSSH istemcisi Windows Server 2019’dan bu yana isteğe bağlı bir Windows özelliği olarak geliyor ve Microsoft’un belgesine göre Windows Server 2025’te fabrika ayarında kurulu. Lab’daki Windows Server 2025’te (web01) OpenSSH_for_Windows_9.5p2 kuruluydu, ayrıca bir şey yüklemedim. Komut PowerShell’de, gece görevini çalıştıracak hesapla açılmış bir pencerede yazılır:

ssh-keygen -q -t ed25519 -N '""' -C "fgtyedek@web01" -f C:\fgt-yedek\.ssh\id_ed25519

Linux’taki komuttan üç farkı var ve üçünü de web01’de ölçtüm:

1. Boş parola '""' diye yazılır. Windows PowerShell 5.1 boş bir argümanı komuta hiç iletmiyor. Linux’taki gibi -N "" yazınca -N parola olarak bir sonraki parçayı (-C) aldı, komut Too many arguments. ile durdu ve anahtar üretilmedi. -N '""' ile anahtar parolasız üretildi.
2. Anahtarı dosyanın kendi izni korur. C:\ altında açtığım C:\fgt-yedek dizini, Users grubunun okuma iznini miras aldı. ssh-keygen bu mirası özel anahtara geçirmedi: dosyayı yalnız Administrators, SYSTEM ve anahtarı üreten hesap açabiliyor. Açık anahtar dosyası (.pub) herkese okunur, bunda sakınca yok: içinde yalnız mühür izi var.
3. Anahtarı gece görevini çalıştıracak hesap üretir. Anahtarı yönetici hesabıyla ürettiğimde dosyanın sahibi o yönetici oldu ve görevi çalıştıracak fgtyedek hesabının dosyada hiç izni yoktu. Linux’taki sudo -u fgtyedek komutunun Windows’taki karşılığı, PowerShell penceresini o hesapla açmaktır: lab’daki sunucunun adıyla runas /user:web01\fgtyedek powershell.

Windows’ta gece görevini Task Scheduler çalıştırır. Lab’da görevi yalnız Users grubundaki yerel bir hesapla kurduğumda Windows Server 2025 görevi hiç başlatmadı. Görev günlüğünde 0x80070569 hatası duruyordu: hesabın toplu iş olarak oturum açma hakkı yoktu. Bu hak Local Security Policy → User Rights Assignment → Log on as a batch job altında görev hesabına verilir.

Yedek sunucusunun FortiGate’in yönetim ağına (192.168.10.0/24) giden kalıcı bir yolu da olmalı; lab’da bunu sunucunun ağ ayarına yazdım.

2. Adım: FortiGate’te Yedek Hesabını Açın

Menü yolu: System → Administrators → Create New → Administrator. Formun alanları:

1. Username: fgt-yedek.
2. Type: Local User. Parola alanı doldurulur ama bu parola hiçbir yerde kullanılmaz; rastgele üretip kimseye vermedim.
3. Comments: hesabın işi. Lab’da Yedek sunucusu 192.168.1.46 her gece 02:00 anahtarla yedek ceker; parola kullanilmaz.
4. Administrator profile: super_admin; neden olduğu bir sonraki adımda.
5. Restrict login to trusted hosts: açık, yalnız yedek sunucusunun adresi, 192.168.1.46/32.

Anahtarın alanı yönetici formunda yok; komut satırında verilir. Kaydın karşılığı:

config system admin
    edit "fgt-yedek"
        set trusthost1 192.168.1.46 255.255.255.255
        set accprofile "super_admin"
        set comments "Yedek sunucusu 192.168.1.46 her gece 02:00 anahtarla yedek ceker; parola kullanilmaz"
        set vdom "root"
        set ssh-public-key1 "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIERVOi7izIuX6sHhWOW4MVJ18qoXiTyPnWC5DJrtNRSZ fgtyedek@sistemkusu-syslog"
        set password ENC ...
    next
end

SCP’nin çalışması için config system global altında admin-scp açık olmalı; lab cihazında açıktı.

3. Adım: Yetkiyi Ölçün, Eksik Yedeğe Dikkat

En az yetki ilkesine göre yedek hesabı salt okuma yetkisiyle başlamalı. Önce bütün yetkileri read olan bir profille denedim; SCP çalıştı ve 338.263 baytlık bir dosya geldi. Ama dosya, birkaç dakika önce aldığım tam yedekten 21 KB küçüktü. İki dosyanın yönetici listesini karşılaştırdım:

== a.conf
edit"fgt-yedek"
== b.conf
edit"admin" edit"sistemkusu" edit"ilker.pehlivan" edit"ag-yoneticileri" edit"xt2vbx9"

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

1. Salt okuma hesabının çektiği yedek (a.conf) yalnız kendi hesabını içeriyor.
2. Tam yedek (b.conf) beş yöneticinin hepsini içeriyor; acil durum hesabı xt2vbx9 dahil.

Eksik yedekte panolar da yoktu. Bu dosya geri yüklense cihazda fgt-yedek dışında yönetici kalmaz.

Fortinet’in SCP ile kısıtlı yetkiyle yedek notu (Aralık 2024) System altında yalnız yönetici kayıtlarına okuma-yazma, gerisine okuma yetkisi öneriyor. O profille de sonuç aynıydı: 338.720 bayt ve yönetici bölümünde yalnız fgt-yedek. Not FortiOS 7.4.4 ve sonrası için yazılmış; lab’daki 7.0.10’da işe yaramadı. Hesabı super_admin yapınca altı yöneticinin hepsi geldi ve dosya 361.626 bayta çıktı.

Yedek, onu çeken hesabın gördüğü kadardır. Sürümünüz ne olursa olsun, kısıtlı bir profille çektiğiniz ilk yedeğin config system admin bölümünü sayın; tam yedekteki yönetici sayısını tutmuyorsa profil yetmiyor demektir.

Yetkinin genişliğini hesabın sınırları dengeler: yalnız anahtarla, yalnız yedek sunucusunun adresinden ve 5. adımda yalnız gece penceresinde. Yöneticilerin girişini anlattığımız yönetici hesabı yazısındaki güvenilen adres kuralı burada en dar hâliyle uygulanıyor.

4. Adım: Çekme Betiğini ve Gece Görevini Kurun

Yedek sunucusundaki betik yapılandırmayı çekiyor ve git geçmişine yazıyor. İlk sürümü her çekişi yeni bir sürüm olarak yazdı; arka arkaya iki çekişin farkı:

 gmfw01.conf | 240 ++++++++++++++++++++++++++++++------------------------------
 1 file changed, 120 insertions(+), 120 deletions(-)

Cihazda hiçbir şey değişmemişti. Sürümlerde gördüğümüz yeniden şifreleme, her dışa aktarmada da oluyor. Bu yüzden betik karşılaştırmadan önce şifreli değerleri atlıyor:

#!/bin/bash
# gmfw01 yapilandirmasini anahtarla ceker; degistiyse git gecmisine yeni surum olarak yazar.
# Calisan kullanici: fgtyedek (cron, her gece 02:00)
set -euo pipefail
DEPO=/srv/fgt-yedek/gecmis
ANAHTAR=/srv/fgt-yedek/.ssh/id_ed25519
GECICI=$(mktemp)
trap 'rm -f "$GECICI"' EXIT

scp -O -q -o BatchMode=yes -i "$ANAHTAR" fgt-yedek@192.168.10.1:sys_config "$GECICI"

# Gelen dosya gercekten bir yapilandirma mi: ilk satir #config-version ile baslar
if ! head -1 "$GECICI" | grep -q '^#config-version='; then
  echo "$(date '+%F %T') HATA: gelen dosya yapilandirma degil"
  exit 1
fi

# FortiGate her disa aktarmada sifreli degerleri yeniden uretir.
# Karsilastirmada ENC satirlari, devam satirlari ve ozel anahtar govdeleri atlanir.
sade() {
  awk '/-----BEGIN [A-Z ]*PRIVATE KEY-----/ {k=1}
       k { if (/-----END/) k=0; next }
       / ENC / {e=1; next}
       e && /^[A-Za-z0-9+\/=]+$/ {next}
       {e=0; print}' "$1" | grep -v '^#conf_file_ver'
}

cd "$DEPO"
if git ls-files --error-unmatch gmfw01.conf >/dev/null 2>&1 && \
   cmp -s <(sade "$GECICI") <(git show HEAD:gmfw01.conf > "$GECICI.eski" && sade "$GECICI.eski"); then
  rm -f "$GECICI.eski"
  echo "$(date '+%F %T') degisiklik yok"
  exit 0
fi
rm -f "$GECICI.eski"
install -m 600 "$GECICI" "$DEPO/gmfw01.conf"
git add gmfw01.conf
git commit -q -m "gmfw01 $(date '+%F %T')"
echo "$(date '+%F %T') yeni surum: $(git rev-parse --short HEAD)"

Betiğin parçaları:

1. scp -O ... sys_config: yapılandırmayı anahtarla çeker. -O eski SCP kipidir; FortiGate’in SCP sunucusu bunu bekliyor.
2. İlk satır denetimi: gelen dosya bir hata mesajıysa geçmişe yazılmaz.
3. sade: ENC satırlarını, devamlarını ve özel anahtar gövdelerini atar; karşılaştırma yalnız gerçek ayarlar üzerinden yapılır.
4. install -m 600: depodaki dosyayı yalnız fgtyedek okuyabilir. Dosya şifresiz geldiği için deponun dizini de 700.

Betiği her gece çalıştıran görev fgtyedek kullanıcısının crontab’ında duruyor. Satır 23:00’ü gösteriyor, çünkü lab’daki sunucunun saat dilimi UTC; nedenini 5. adımda anlatıyorum:

# Sunucu UTC; 23:00 UTC = 02:00 Istanbul (FortiGate fgt-yedek giris penceresi 02:00-02:15)
0 23 * * * /usr/local/bin/fgt-yedek-cek.sh >> /srv/fgt-yedek/cek.log 2>&1

Betiği arka arkaya iki kez çalıştırdım, sonra depo arayüzüne açıklama yazıp bir kez daha çalıştırdım:

2026-10-01 21:19:11 degisiklik yok
2026-10-01 21:19:14 degisiklik yok
2026-10-01 21:19:20 yeni surum: d14d90e

Satırlardaki saat sunucunun saati, UTC; İstanbul’da üç saat ileri. Son iki sürümün sade farkı yalnız gerçek değişikliği gösteriyor:

131a132
>         set description "Depo VLAN 90"

Yalnız değiştiğinde sürüm yazan ve geçmişi git deposunda tutan aynı düzeni switch yapılandırma yedeği yazımızda switch için kurduk.

5. Adım: Girişi Gece Penceresine Bağlayın

Anahtar yalnız dosya kopyalamıyor. Yedek sunucusundan aynı anahtarla bir komut çalıştırdım:

sudo -u fgtyedek ssh -i /srv/fgt-yedek/.ssh/id_ed25519 fgt-yedek@192.168.10.1 "get system status"

...
gmfw01 # Version: FortiGate-VM64 v7.0.10,build0450,230221 (GA.M)
Virus-DB: 1.00000(2018-04-09 18:07)

Komut çalıştı; yani anahtarı ele geçiren kişi super_admin yetkisiyle bir komut satırı açar. NISTIR 7966 otomatik anahtarların bir de komut sınırıyla bağlanmasını istiyor. 7.0.10’da config system admin altındaki alanların hiçbiri komutu sınırlamıyor; en yakın sınır schedule alanı, hesabın hangi saatlerde girebileceğini belirliyor. Hesabı her gece 02:00 ile 02:15 arasına bağladım:

config firewall schedule recurring
    edit "yedek-penceresi"
        set start 02:00
        set end 02:15
        set day sunday monday tuesday wednesday thursday friday saturday
    next
end
config system admin
    edit "fgt-yedek"
        set schedule "yedek-penceresi"
    next
end

Pencerenin dışında, 00:35’te çekme denemesi reddedildi:

fgt-yedek@192.168.10.1: Permission denied (publickey,password).

Pencereyi geçici olarak o saate çekince aynı komut 360.676 baytlık yedeği getirdi; sonra pencereyi 02:00’ye geri aldım. Reddedilen denemenin olay logundaki kaydı beklediğim sebebi yazmıyordu:

1: date=2026-10-02 time=00:35:28 ... logid="0100032002" type="event" subtype="system" level="alert" vd="root" logdesc="Admin login failed" sn="0" user="fgt-yedek" ui="ssh(192.168.1.46)" method="ssh" srcip=192.168.1.46 dstip=192.168.10.1 action="login" status="failed" reason="name_invalid" msg="Administrator fgt-yedek login failed from ssh(192.168.1.46) because of invalid user name"

FortiGate, penceresi dışındaki hesabı yok sayıyor ve sebebi “geçersiz kullanıcı adı” diye yazıyor. Logda bu satırı gören kişi bir saat ayarını değil bir yazım hatasını arar.

Pencere bir de saat dilimi tuzağı kuruyor. Pencere FortiGate’in saatiyle (İstanbul, +0300) çalışıyor, crontab ise sunucunun saatiyle. Lab sunucusu UTC’de olduğu için ilk kurduğum 0 2 * * * satırı İstanbul’da 05:00 demekti ve her gece pencerenin dışında kalacaktı. Bu yüzden satır 0 23 * * *. Türkiye 2016’dan beri yaz saatine geçmediği için fark yıl boyu üç saat.

Pencere izlemeye de bir dayanak veriyor. Sunucunun her çekişi olay loguna tek tip bir kayıt bırakıyor, giriş kaydı bırakmıyor:

3: date=2026-10-02 time=00:19:19 ... logid="0100032143" type="event" subtype="system" level="warning" vd="root" logdesc="System configuration backed up by SCP" user="fgt-yedek" ui="sshd" action="backup" msg="User fgt-yedek backed up the configuration by SCP"

Komut satırı oturumu ise Admin login successful (0100032001) kaydı bıraktı. fgt-yedek adına düşen bir giriş kaydı, anahtarın yedek dışında kullanıldığını gösterir; logların nereye gittiğini ve nasıl izlendiğini log ayarları yazımızda kurduk.

Çeken Düzeni Geri Almak

Düzeni kaldırmak iki yerde iş ister:

1. FortiGate’te fgt-yedek hesabı ve yedek-penceresi takvimi silinir.
2. Yedek sunucusunda fgtyedek kullanıcısının crontab satırı kaldırılır.

Hesap silinince açık anahtar da gider; iz defterinden iz silinince müdürlüğün memuru kapıda artık tanınmaz.

FortiGate Yedeğini Geri Yüklemek: Kesinti ve Kayıp

Yedeğin değeri geri yüklendiğinde ortaya çıkar. Bu yazının ölçümlerine başlamadan önce SFTP’ye şifreli bir dönüş noktası yedeği almıştım. Onu geri yüklemek istedim ve CLI’da ilk sürpriz çıktı:

gmfw01 # execute restore config
dhcp                  Load config file via DHCP.
flash                 Load config file from flash to firewall.
ftp                   Load config file from FTP server.
management-station    management-station
tftp                  Load config file from TFTP server to firewall.
usb                   Load config file from USB disk to firewall.
usb-mode              Load config file from USB disk and reboot.

FortiOS 7.0’da yedek komutu SFTP’yi kabul ediyor, geri yükleme komutu etmiyor. SFTP’deki ya da çekilmiş yedeğin geri dönüş yolları şunlar:

1. Arayüz: dosya bilgisayara alınıp Configuration → Restore ekranından yüklenir. Lab’da iki yedeği de bu yoldan geri yükledim.
2. FTP ya da TFTP: dosya bir FTP/TFTP sunucusuna konur ve execute restore config ile alınır. İkisi de şifresiz; dosyanın yedek parolasıyla şifreli olması burada da korur.
3. SCP: Fortinet topluluk forumundaki örneklerde dosya fgt-restore-config adıyla cihaza kopyalanıyor. Lab’da super_admin yetkili hesabımla denediğimde 501-Permission Denied döndü ve olay loguna hiçbir kayıt düşmedi. Bu yolu kendi cihazınızda denemeden geri dönüş planına yazmayın.

Dönüş noktası yedeğini arayüzden geri yükledim. Menü yolu: kullanıcı adı → Configuration → Restore; File alanına dosya, Password alanına yedek parolası. OK deyince arayüz uyardı:

Onaylayınca cihaz yeniden başladı. Yönetim ağındaki bir makineden yarım saniyede bir attığım ping 00:14:40 ile 00:15:24 arasında, 43,8 saniye cevapsız kaldı. Cihaz açıldıktan sonra yapılandırmaya baktım:

1. Otomasyon zinciri, yedek hesabı ve yedek profili yoktu (entry is not found in table). Üçünü de yedekten sonra kurmuştum.
2. Sürüm ayarı geri dönmüştü: revision-backup-on-logout yeniden disable idi; depo arayüzünün açıklaması da gitmişti.
3. Sürüm listesi yerindeydi: 1’den 8’e kadar bütün sürümler duruyordu. Sürümler yapılandırmanın parçası değil, cihazın diskinde tutuluyor.

Geri yükleme, cihazı yedeğin alındığı ana döndürür; o andan sonraki her değişiklik düşer. Yedek hesabını, sürüm ayarını ve çekme düzenini geri yüklemeden sonra yeniden kurdum.

Çekilen Yedeği Geri Yüklemek

Çeken düzenin deposundaki dosya şifresizdir ve SCP ile alınmıştır; geri dönüşte işe yarayıp yaramadığını ayrıca denedim:

1. Yapılandırmayı sys_config olarak çektim.
2. İşaret olsun diye depo arayüzünün açıklamasını Depo VLAN 90 gecici yaptım.
3. Çektiğim dosyayı aynı Restore ekranından, Password alanını boş bırakarak yükledim.

Arayüz aynı yeniden başlatma uyarısını verdi. Ping bu kez 42,3 saniye kesildi; cihaz açıldığında açıklama yeniden Depo VLAN 90 idi, 5. adımda kurduğum yedek-penceresi takvimi de yerindeydi.

Depodaki her sürüm bu yüzden doğrudan geri yüklenebilir bir dosyadır. Fortinet forumundaki personel cevabına göre dosyanın adı .conf ile bitmeli; betik onu zaten gmfw01.conf olarak saklıyor. Lab’daki sanal makinede iki geri yükleme de 45 saniyenin altında kaldı; kendi cihazınızın açılış süresini bir bakım penceresinde ölçün.

Örnekteki sınır kapısında bu, panoyu müdürlükteki kopyayla değiştirirken kapıyı kapatmaktır: kopyadan sonra panoya eklenen not da panoyla birlikte iner.

Doğrulama: FortiGate’in Yedek Düzeni Doğru mu?

1. revision-backup-on-logout enable ve değişiklik yapılan her oturum bir sürüm üretiyor.
2. Cihaz dışı yedek şifreli bir yolla (SFTP ya da SCP) alınıyor; TFTP kullanılıyorsa yedek parolalı.
3. Firewall’un yapılandırmasında ve logunda yedek deposunun parolası yok.
4. Yedek tam: dosyadaki config system admin bölümünde bütün yöneticiler var.
5. Geçmiş tutuluyor ve yalnız gerçek değişikliklerde yeni sürüm yazılıyor.
6. Depoyu yalnız yedek hesabı okuyabiliyor: dizin 700, dosya 600.
7. Yedek hesabı yalnız yedek sunucusunun adresinden ve gece penceresinde girebiliyor; logda bu hesap adına Admin login successful kaydı yok.
8. Yedek bir kez geri yüklenerek denendi ve kesintinin süresi biliniyor.

Sonuç: FortiGate’te Yedek, Geri Yüklenebildiği Kadar Yedektir

FortiGate her değişikliği anında kalıcı yaptığı için geri dönüş yolu yalnız yedektir. Fortinet’in, NSA’nın ve NIST’in kesiştiği düzende yedek her değişiklikten önce ve sonra alınır, şifreli bir yolla cihazın dışına taşınır, geçmişiyle ve korunan bir depoda saklanır. Lab’da altı şey beklenenden farklı çıktı:

1. Salt okuma yetkili ve Fortinet’in kısıtlı yetki önerisine uyan hesapların çektiği yedeklerde öteki yöneticilerin hiçbiri yoktu; tam yedek için çeken hesabın super_admin olması gerekti.
2. Hiçbir şey değişmeden alınan iki yedek 240 satır farklıydı; FortiGate şifreli değerleri her dışa aktarmada yeniden üretiyor.
3. Otomasyon betiğindeki iki parola yapılandırmaya, olay loguna ve syslog sunucusunun diskine düz metin yazıldı.
4. FortiOS 7.0 yedeği SFTP’ye gönderebiliyor ama SFTP’den geri yükleyemiyor; SCP ile geri yükleme de 501-Permission Denied döndü. İki yedek de yalnız arayüzden geri yüklendi.
5. Gece penceresinin dışında reddedilen yedek hesabı logda invalid user name sebebiyle yazıldı.
6. Geri yükleme 43,8 saniye sürdü ve yedekten sonra kurulan her şeyi sildi; cihazın diskindeki sürümler kaldı.

Örnekteki sınır kapısında müdürlükteki kopya, yani yedek sunucusundaki yedek, ancak geri asılabildiği gün değer kazanır. Müdürlüğün anahtarı da kapıdaki görevlinin cebinde değil müdürlükte durduğunda güvendedir; kapıda yalnız memurun mühür izi kalır.

Yapılandırmanın neyin ne zaman değiştiğini gösteren tarafını BT dokümantasyonu yazımızın değişiklik kaydı bölümünde anlattık. Sıradaki adım rehberin 17. adımı, doğrulama ve teşhis; açılış listesinin kalanı 20 adımlık kontrol listesinde duruyor.

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