TACACS+ Nedir? RADIUS Farkı ve Linux'ta TACACS+ Sunucusu

TACACS+, bir ağ cihazına kimin girebileceğini, girdikten sonra hangi komutları çalıştırabileceğini ve hangi komutu ne zaman çalıştırdığını merkezi bir sunucudan yöneten protokoldür. Bu üç işe birlikte AAA denir: kimlik doğrulama (authentication), yetkilendirme (authorization) ve kayıt (accounting). TACACS+ üçünü birbirinden ayrı yürütür. Bu yazıda protokolün nasıl çalıştığını ve RADIUS’tan farkını anlatıyorum. Ardından Ubuntu’da bir TACACS+ sunucusu kuruyor, verdiği kararları günlüklerinden ve paketin kendisinden okuyorum.

RADIUS yazımızda kasadaki POS cihazının müşterinin kartını bankaya sorduğunu anlatmıştık. TACACS+ ise aynı bankanın kendi görevlisine bakan yüzüdür. Gişe görevlisi bankanın sistemine kendi sicil numarası ve şifresiyle girer ve o şifreyi şube değil, bankanın merkezi sistemi doğrular.

Görevli bir hesabın bakiyesine bakabilir, ama yetki limitinin üstündeki bir havalede sistem onun yetkisini her seferinde ayrıca sorar. Yaptığı her işlem sicil numarasıyla merkezde kayda geçer ve bankanın teftiş kurulu bir işlemi kimin yaptığını sonradan o kayıttan bulur. TACACS+ ağ cihazlarına aynı düzeni getirir.

Bu yazı kurumsal ağ protokolleri rehberimizin kimlik doğrulama ayağına aittir ve Kurumsal Network Kurulumu hizmetimizin kapsamındadır. Switch’in bu sunucuya nasıl bağlandığını, komut yetkisinin switch tarafını ve sunucu cevap vermediğinde ne olduğunu switch TACACS+ yapılandırması yazımızda ölçtüm. Aynı işi müşterilerimizin ağında nasıl yürüttüğümüzü switch kurulumu ve VLAN yapılandırma hizmeti sayfamızda anlattık.

TACACS+ Nedir? Kim, Ne Yapabilir, Ne Yaptı

TACACS+, ağ cihazlarına yönetici girişini tek bir merkezden doğrulayan, yetkilendiren ve kayda geçiren protokoldür. Switch’e girmenin varsayılan yolu yerel hesaptır: kullanıcı adı ve parola switch’in kendi yapılandırmasında durur. Yerel hesabın nasıl açıldığını ve parolasının nasıl saklandığını switch’te yerel yönetici hesabı yazımızda anlattık. On switch’lik bir ağda bu, on ayrı yerde tutulan aynı hesap demektir. Bir yönetici işten ayrıldığında hesabı on switch’te ayrı ayrı kapatmak gerekir. Hangi yöneticinin hangi switch’te ne yaptığı da hiçbir yerde toplanmaz.

TACACS+ bu üç soruyu tek bir sunucuya taşır:

1. Kimlik doğrulama: bu kişi gerçekten iddia ettiği kişi mi? Kullanıcı adı ve parola cihazda değil sunucuda kontrol edilir. Gişe görevlisinin şifresini şubenin değil merkezin doğrulaması budur.
2. Yetkilendirme: bu kişi şu komutu çalıştırabilir mi? Cihaz her komuttan önce sunucuya sorabilir. Limitin üstündeki her havalede görevlinin yetkisinin ayrıca sorulması da budur.
3. Kayıt: bu kişi ne yaptı? Cihaz çalıştırılan her komutu kullanıcı adıyla sunucuya bildirir. Teftiş kurulunun sonradan okuduğu kayıt budur.

Protokolün kökeni Cisco’dadır. İlk TACACS, BBN’in askerî MILNET ağı için geliştirdiği, UDP üzerinde çalışan basit bir erişim protokolüdür. Cisco onu önce XTACACS adıyla genişletti, sonra kimlik doğrulamayı, yetkilendirmeyi ve kaydı birbirinden ayıran TACACS+‘ı geliştirdi. Protokolü ilk tarif eden belge, Cisco’dan D. Carrel ile L. Grant’in 1997 tarihli taslağıdır (draft-grant-tacacs-02). Bu taslak hiçbir zaman standart olmadı.

TACACS+ TCP 49 numaralı portu kullanır ve RFC 8907 ile 2020’de belgelendi. Bu RFC bir standart değil, bilgilendirme (Informational) belgesidir; özetinde de söylendiği gibi, bugün cihaz yönetiminde geniş ölçüde kullanılan protokolü yazıya geçirir.

TACACS+ ile RADIUS Farkı

Ağ cihazlarında merkezi kimlik için ikinci seçenek RADIUS’tur. İkisinin farkı, taşıdıkları işin türünden gelir. RADIUS kullanıcıyı ağa alır; bir bilgisayarın ağa bağlanması, Wi-Fi ya da VPN girişi onun işidir. TACACS+ ise yöneticiyi cihazın içine alır.

Pratikteki en büyük fark komut bazlı yetkidir. RADIUS’ta yönetici girişte kaba bir yetki seviyesi alır ve o seviyedeki her komutu çalıştırır. TACACS+‘ta switch her komuttan önce sunucuya sorar ve bir yöneticiye yalnız show komutlarını açabilirsiniz. RADIUS’un nasıl çalıştığını ve hangi durumda cihaz girişi için yeterli olduğunu RADIUS makalemizde anlattık.

RADIUS ve TACACS+ Birlikte Kullanılabilir mi?

Kullanılabilir. İkisi farklı işlere baktığı için aynı ağda yan yana durur. RADIUS kabloyla porta bağlanan cihazı ve Wi-Fi’ye giren kullanıcıyı doğrular; TACACS+ ise switch’in komut satırına giren yöneticiyi doğrular. Asıl soru “Hangisi üstün?” değil, “Cihaz hangisine önce soruyor?” sorusudur ve bunu protokol değil, cihazdaki yöntem listesi belirler.

Switch’te her AAA adımının kendi listesi vardır: giriş, oturum yetkisi, komut yetkisi ve kayıt. Hangi sunucuya hangi sırayla sorulacağı her listeye ayrı ayrı yazılır. Lab switch’imde giriş listesinin seçenekleri RADIUS’u ve TACACS+‘ı yan yana sunuyor:

gmsw01(config)#aaa authentication login tacacsList ?

enable                   Select enable as the authentication method.
line                     Select line as the authentication method.
local                    Select local as the authentication method.
none                     Select no authentication.
radius                   Select RADIUS as the authentication method.
tacacs                   Select TACACS+ as the authentication method.

Liste hat başına da ayrı seçilir. Aynı switch’te show authentication methods çıktısı konsol, Telnet ve SSH hatlarını ayrı ayrı gösteriyor; porta 802.1X ile bağlanan cihazların doğrulaması da (DOT1X) kendi satırında duruyor. Yani bir switch’in portları RADIUS’a, yönetici girişi TACACS+‘a aynı anda bağlı olabilir.

Hangi Sunucu Karar Verir? Red ile Sessizlik Ayrı Şeylerdir

Bir listede birden çok sunucu olduğunda kararı şu kural belirler: sonraki yöntem, önceki sunucu “hayır” dediğinde değil, hiç cevap vermediğinde denenir. Cisco’nun AAA yapılandırma kılavuzu iki durumu ayrı adlandırır. Sunucunun kullanıcıyı reddetmesi FAIL’dir ve süreç orada durur; sunucunun cevap vermemesi ERROR’dur ve ancak o zaman listedeki bir sonraki yönteme geçilir: “The additional methods of authentication are used only if the previous method returns an error, not if it fails.”

Lab switch’imde bu kuralın yarısını ölçtüm. TACACS+ servisi durduğunda ve sunucu hiç cevap vermediğinde switch listedeki yerel hesaba geçti. Sunucunun reddettiği bir kullanıcının yerel hesaba düşmediğini ayrıca sınamadım; o yarı kılavuzun tarifidir.

SSH girişi tacacs radius local sırasıyla tanımlı bir switch’i düşünün. Kuralın sonucu üç ayrı durumdur:

1. TACACS+ sunucusu kullanıcıyı kabul ediyor. Girişi TACACS+ yapar; RADIUS’a ve yerel hesaba hiç sorulmaz.
2. TACACS+ sunucusu parolayı reddediyor. Giriş kapanır. RADIUS’ta ya da switch’te aynı adla geçerli bir hesap olsa bile onlara sorulmaz.
3. TACACS+ sunucusu cevap vermiyor. Switch zaman aşımını bekler, sonra RADIUS’a sorar; RADIUS da cevap vermezse yerel hesaba bakar.

Kimlik doğrulamayı bir sunucuya, yetkiyi öbürüne vermek de biçim olarak mümkündür, çünkü her adım kendi listesidir. Bunun iki şartı vardır. Komut yetkisi yalnız TACACS+‘ta bulunur. Lab switch’imde komut yetkisi listesi yalnız tacacs ve none yöntemlerini, komut kaydı listesi yalnız tacacs yöntemini kabul ediyor. TACACS+ sunucusu da komutu kullanıcının profiline bakarak onayladığı için kullanıcı orada da tanımlı olmalıdır. Bu karışımı lab’da denemedim.

RADIUS ile TACACS+ Birlikte Nasıl Kullanılır? Görev Paylaşımı

İki protokolü birlikte kullanmanın en temiz yolu, ağa girişi RADIUS’a ve cihaz yönetimini TACACS+‘a bırakarak işi göreve göre bölmektir. Bir yöneticinin kimliğini RADIUS’la, komutlarını TACACS+‘la denetlemek aynı kişiyi iki sunucuda tutarlı tutmayı gerektirir ve bir arızada hangi sunucunun ne dediğini okumayı zorlaştırır. Göreve göre bölünmüş bir ağda iş şöyle paylaşılır:

Aynı kişi bu tabloda iki kez görünebilir. Bir ağ yöneticisi sabah bilgisayarıyla ağa RADIUS üzerinden bağlanır, öğleden sonra bir switch’e girdiğinde TACACS+ onu karşılar. Bankada da müşterinin kartını onaylamak ile görevlinin limitini sormak ayrı işlerdir; hangisine önce bakılacağını sistemler değil, şubenin yazılı prosedürü belirler.

Kurulum sırası şöyledir:

1. Kimlik kaynağını tek tutun. İki sunucu da aynı dizine bağlanır, örneğin Active Directory’ye. Kullanıcı bir kez tanımlanır ve işten ayrılan bir kişinin hesabı tek yerde kapanınca hem ağa hem cihazlara girişi birlikte kapanır. FreeRADIUS’un dizine nasıl bağlandığını FreeRADIUS kurulumu rehberimizde anlattık.
2. Yetkiyi dizindeki gruplara bağlayın. Ağ yöneticileri bir gruba, salt okunur hesaplar başka bir gruba girer ve her sunucu kendi kararını bu gruba göre verir. Yeni bir yöneticiye yetki vermek sunucu yapılandırmasına dokunmayı değil, onu gruba eklemeyi gerektirir.
3. RADIUS’u ağa giriş için kurun. Windows tarafında NPS, Linux tarafında FreeRADIUS bu işi üstlenir; ikisinin farkını RADIUS yazımızda anlattık.
4. TACACS+‘ı cihaz yönetimi için kurun. Sunucu kurulumu aşağıdaki bölümde adım adım duruyor.
5. Cihazda listeleri ayırın. Port doğrulaması RADIUS’a, yönetici girişi TACACS+‘a gider ve giriş listesinin sonunda yerel acil durum hesabı durur. Switch komutlarını switch TACACS+ yapılandırması yazımızda gösterdik.
6. İki sunucunun kaydını aynı yerde toplayın. “Kim ağa girdi?” ile “Kim switch’te ne yaptı?” sorularının cevabı bir olayda aynı zaman çizelgesinde okunmalıdır. Günlükleri bir merkezi syslog sunucusunda toplamak bunu sağlar.

TACACS+ sunucusu yedeksizse giriş listesinde TACACS+‘tan sonra RADIUS’u yedek yöntem olarak yazabilirsiniz. Önceki alt başlıktaki kural gereği RADIUS’a ancak TACACS+ cevap vermediğinde sorulur. O oturumda komutlar yine TACACS+‘a sorulamaz; lab’daki komut yetkisi listesinde sonraki yöntem none olduğu için komutlar yetki sorulmadan çalışır.

Komut başına denetim gerekmiyorsa cihaz girişini de yalnız RADIUS’a bağlamak yetebilir. On üç lokasyondaki switch girişini kişisel Active Directory hesaplarına RADIUS ile bağladığımız projeyi ağ erişimi sıkılaştırma vaka çalışmasında anlattık. Orada salt okunur ayrımı RADIUS’un kaba yetki seviyesiyle çözülüyordu; komut bazında ayrım gerekseydi TACACS+ şart olurdu.

TACACS+ Sunucusu Kurulumu: Ubuntu’da tac_plus-ng

Windows Server’ın kendi araçlarıyla TACACS+ sunucusu kurulamaz, bu yüzden sunucuyu Linux’a kuruyorum; Windows’taki seçenekleri bu bölümün sonunda anlattım. Lab’da TACACS+ sunucusunu merkezi log için kurduğumuz sistemkusu-syslog adlı Ubuntu 24.04 sunucusuna kuruyorum. Bu bölüm o sunucunun zaten ayakta olduğunu varsayar; Ubuntu kurulumunu Ubuntu Server kurulum rehberimizde anlattık.

İlk sürpriz paket deposunda çıktı. Ubuntu 24.04 depolarında bir TACACS+ sunucu paketi yok; apt-cache search tacacs yalnız bir Perl istemci kütüphanesi döndürdü. Debian arşivindeki eski tacacs+ paketi de 4.0.4.27a sürümünde kalmış. Bu yüzden güncel ve bakımı süren açık kaynak tac_plus-ng’yi kaynaktan derliyorum:

sudo apt-get update
sudo apt-get install -y build-essential libpcre2-dev libssl-dev
git clone --depth 1 https://github.com/MarcJHuber/event-driven-servers.git
cd event-driven-servers
./configure --prefix=/usr/local tac_plus-ng
make
sudo make install

Yapılandırmayı /usr/local/etc/tac_plus-ng.cfg dosyasına yazıyorum. Üç kullanıcı var: sistemkusu-yonetici ile ilker her komutu çalıştırabiliyor, sistemkusu-izleyici yalnız show komutlarını çalıştırabiliyor. ilker switch’te yerel olarak da tanımlı, bu yüzden sunucuya ulaşılamadığında ne olduğunu bu hesapla ölçtüm:

id = spawnd {
	listen { port = 49 }
	spawn { instances min = 1 instances max = 4 }
	background = no
}

id = tac_plus-ng {
	log erisim { destination = /var/log/tac_plus-ng/erisim.log }
	log yetki { destination = /var/log/tac_plus-ng/yetki.log }
	log kayit { destination = /var/log/tac_plus-ng/kayit.log }
	access log = erisim
	authorization log = yetki
	accounting log = kayit

	host lab-switch {
		address = 192.168.1.2
		key = "<paylaşılan anahtar>"
	}

	profile yonetici {
		script {
			if (service == shell) {
				if (cmd == "") { set priv-lvl = 15 permit }
				permit
			}
		}
	}

	profile izleyici {
		script {
			if (service == shell) {
				if (cmd == "") { set priv-lvl = 15 permit }
				if (cmd =~ /^show /) permit
				if (cmd =~ /^terminal length /) permit
				if (cmd =~ /^exit/) permit
				deny
			}
		}
	}

	user sistemkusu-yonetici {
		password login = clear "<parola>"
		profile = yonetici
	}

	user sistemkusu-izleyici {
		password login = clear "<parola>"
		profile = izleyici
	}

	user ilker {
		password login = clear "<parola>"
		profile = yonetici
	}
}

host bloğu sunucunun kime cevap vereceğini belirler; yalnız switch’in adresi yazılı. key switch’te de aynı olmalıdır, çünkü paketin gövdesi bu anahtarla gizlenir. profile blokları yetkiyi tanımlar: cmd == "" oturumun açılmasıdır, öbür satırlar komut başına karardır. Lab’da parolalar düz metin yazıldı. Gerçek bir kurulumda sunucu kullanıcıları Active Directory gibi bir dizine bağlanır; tac_plus-ng’nin kaynağıyla gelen örnekler arasında Active Directory yapılandırması da var.

Sözdizimini sudo tac_plus-ng -P /usr/local/etc/tac_plus-ng.cfg ile sınadım, sonra kaynakla gelen systemd birimiyle servisi başlattım. Servisin günlüğü sunucunun 49 numaralı portu açtığını gösteriyor:

Sep 23 15:24:39 sistemkusu-syslog tac_plus-ng[6251]: bind to [::]:49 succeeded

[::] sunucunun bütün adreslerinden gelen bağlantıyı kabul ettiğini gösterir. Kime cevap vereceğini ise yukarıdaki host bloğu belirler.

Windows’ta TACACS+ Sunucusu Kurulabilir mi?

Windows Server’ın kendi araçlarıyla TACACS+ sunucusu kurulamaz. Windows’un kimlik doğrulama sunucusu NPS’tir ve Microsoft onu RADIUS’un uygulaması olarak tanımlar: “NPS is the Microsoft implementation of the RADIUS standard specified by the Internet Engineering Task Force (IETF) in Request for Comments (RFCs) 2865 and 2866.” (Microsoft Learn, Network Policy Server). Aynı sayfada TACACS+ hiç geçmiyor.

Lab’da kullandığım tac_plus-ng de Windows’u desteklenen platformlar arasında saymıyor. Projenin kendi belgesi Linux, FreeBSD ve OpenBSD’yi sayıyor ve öteki platformların yakın zamanda denenmediğini yazıyor (event-driven-servers).

Windows ağırlıklı bir kurumun önünde şu yollar durur:

• TACACS+ sunucusunu Windows üstündeki bir Linux sanal sunucusunda çalıştırmak. Hyper-V’deki bir Ubuntu sanal sunucusu bu bölümdeki kurulumu olduğu gibi taşır ve kullanıcılar yine Active Directory’den gelebilir. Sanal sunucunun nasıl çalıştığını hypervisor yazımızda anlattık.
• Komut başına yetki gerekmiyorsa NPS ile RADIUS’u kullanmak. Cihaz girişi Windows’un kendi aracıyla merkezileşir, ama komut yetkisi ve komut kaydı olmaz. NPS’in bu işteki yerini RADIUS yazımızda anlattık.
• Windows’a kurulan ticari bir TACACS+ sunucusu almak. Windows’ta TACACS+ sunucusu çalıştırmanın tek yolu budur; bu ürünler Windows Server’ın parçası değildir, üçüncü taraf yazılım olarak satın alınır. Seçim lisans, destek ve dizin entegrasyonu üzerinden yapılır.

Benim tercihim ilk yoldur. Sunucu tarafı açık kaynak kalır ve bu yazıdaki ölçümler olduğu gibi geçerli olur.

TACACS+ Sunucusunun Günlükleri: Her Karar Satır Satır

Sunucu dinliyor. Switch’i bu sunucuya bağlamayı switch TACACS+ yapılandırması yazımızda adım adım anlattık; burada aynı denemelerin sunucuda nasıl göründüğünü okuyorum. Sunucu üç ayrı günlük tutuyor ve her biri AAA’nın bir harfine denk geliyor.

İlk giriş denemesi servisin kendi günlüğüne şöyle düştü:

Sep 23 15:25:08 sistemkusu-syslog tac_plus-ng[6253]: 192.168.1.2 shell login for 'sistemkusu-yonetici' from 192.168.1.115 on unknown succeeded (profile=yonetici)

Bu satır üç şeyi söyler:

1. 192.168.1.2 isteği gönderen istemcidir, yani switch.
2. from 192.168.1.115 yöneticinin switch’e bağlandığı bilgisayardır. Switch bu adresi sunucuya kendisi bildirir.
3. profile=yonetici kullanıcıya uygulanan yetki profilidir.

Komut kararları ayrı iki günlükte durur. sistemkusu-izleyici switch’te show clock çalıştırdı ve configure denedi; switch ikinci komutu configure: Command Is Not Authorized diyerek geri çevirdi. Sunucunun yetki ve kayıt günlükleri aynı anı şöyle yazdı:

$ sudo tail -8 /var/log/tac_plus-ng/yetki.log
...
2026-09-23 15:26:47 +0000 192.168.1.2	sistemkusu-izleyici	unknown		izleyici	permit	shell	show clock
2026-09-23 15:26:48 +0000 192.168.1.2	sistemkusu-izleyici	unknown		izleyici	deny	shell	configure
2026-09-23 15:26:56 +0000 192.168.1.2	sistemkusu-yonetici	unknown		yonetici	permit	shell
2026-09-23 15:26:57 +0000 192.168.1.2	sistemkusu-yonetici	unknown		yonetici	permit	shell	configure
$ sudo tail -8 /var/log/tac_plus-ng/kayit.log
...
2026-09-23 15:26:48 +0000 192.168.1.2	sistemkusu-izleyici	unknown		stop	shell	show clock
2026-09-23 15:26:51 +0000 192.168.1.2	sistemkusu-izleyici	unknown		stop	shell	exit
2026-09-23 15:26:58 +0000 192.168.1.2	sistemkusu-yonetici	unknown		stop	shell	configure
...

Okurken dört alana bakılır:

1. Saat ve istemci kararın ne zaman ve hangi cihaz için verildiğini gösterir.
2. Kullanıcı ve profil kimin, hangi yetki tanımıyla işlem yaptığını gösterir.
3. Karar yalnız yetki günlüğünde bulunur: permit izin, deny red demektir.
4. Komut satırın sonunda durur. Kayıt günlüğündeki stop, komutun çalışıp bittiğini bildiren kayıttır.

Bir arızadan sonra “Bu değişikliği kim yaptı?” sorusunun cevabı artık cihazda değil, sunucunun kayıt günlüğündedir. Teftiş kurulunun bir işlemi sicil numarasından bulması da budur.

Günlüklerdeki saatlerin anlamlı olması için hem switch’in hem sunucunun saati doğru olmalıdır. Bunu switch NTP server ayarı yazımızda anlattık.

TACACS+ Paketinde Ne Görünür? Gövde Gizlenir, Şifrelenmez

Tabloda TACACS+‘ın gövdenin tamamını gizlediğini yazdık. Sunucuda paket yakalayıp switch’in ilk kimlik doğrulama paketine baktım. TCP başlığından sonra gelen TACACS+ başlığı şöyle:

c001 0100 13a2 7469 0000 001c

Bu on iki bayt açıkta durur ve şöyle okunur:

1. c0: protokol sürümü.
2. 01: paket türü, kimlik doğrulama.
3. 01: sıra numarası, oturumun ilk paketi.
4. 00: bayrak baytı. RFC 8907’de bu baytın en düşük biti “gövde gizlenmedi” anlamına gelir. Bit kalkık değil, yani gövde gizlenmiş.
5. 13a27469: oturum kimliği.
6. 0000001c: gövde uzunluğu, 28 bayt.

Başlığın ardından gelen 28 baytta sistemkusu-yonetici adı okunmuyor, bayt dizisi rastgele görünüyor. Ama bu bir şifreleme değil. RFC 8907’nin güvenlik bölümü bunu açıkça söyler: bu korumaya “şifreleme değil gizleme (obfuscation) demek daha doğrudur, çünkü anlamlı bir bütünlük, gizlilik ya da tekrar oynatma koruması sağlamaz” (RFC 8907, bölüm 10.1). Aynı bölüm, TACACS+ kullananların sunucuya yalnız bilinen istemcilerin erişmesini sağlamasını ve aktarım yolunun tamamını denetlemesini şart koşar.

Banka benzetmesi burada kopuyor. Bir bankanın gişesiyle merkezi arasındaki trafiği açık bir hattan geçirmesi beklenmez; TACACS+ ise gövdeyi şifrelemez, yalnız gizler. Yolu korumak protokole değil, onu kuran kişiye kalır.

Lab’da bir bulgu bu uyarıyı somutlaştırıyor. Switch’in çalışan yapılandırmasında paylaşılan anahtar düz metin duruyor: tacacs-server host satırının altındaki key satırında anahtarın kendisi yazılı. Switch yapılandırmasının yedeğini ele geçiren biri bu anahtarı da ele geçirir; RFC’ye göre gövdeyi gizleyen de bu anahtardır. Yedek dosyasını neden gizli belge gibi saklamak gerektiğini switch yapılandırma yedeği yazımızda anlattık.

TACACS+ En İyi Uygulamaları: Canlıya Almadan Önce

Sunucu kuruldu ve kararlarını yazıyor. Canlıya almadan önce aşağıdaki uygulamaları yerine getirin. Maddelerin çoğu lab’da gördüğüm bir arızadan, anahtarla ilgili olanlar RFC 8907’den geliyor:

• İki sunucu kurun. Merkez durduğunda bütün cihazların yönetimi yavaşlar. Lab’da sunucu cevap vermezken switch’e giriş yaklaşık 10 saniye, her komut 5 saniye sürdü; ölçümün tamamını switch TACACS+ yapılandırması yazımızda anlattık.
• Yerel acil durum hesabını listenin sonunda tutun. Sunucuya ulaşılamadığında cihaza girmenin tek yolu budur. Lab’da sunucu durduğunda yalnız switch’te yerel karşılığı olan hesap girebildi; bu hesabın nasıl açıldığını switch’te yerel yönetici hesabı yazımızda anlattık.
• Sunucuyu izlemeye alın. Sunucunun durduğu, bir yöneticinin girememesinden değil izleme sisteminin alarmından öğrenilmelidir.
• Yetkiyi role göre ve en düşük yetkiden başlayarak verin. Lab’daki izleyici profili yalnız show komutlarına izin verdi ve configure komutunu geri çevirdi. Profil kişiye değil role yazılır; yeni bir yönetici profile eklenerek yetki alır.
• Salt okunur hesabı komut yetkisiyle birlikte açın. İzleyici profili de oturumu en yüksek seviyeden açıyor ve kısıtlama ancak cihazda komut yetkisi bağlandığında başlıyor. Komut yetkisi bağlanmadan önce lab’daki izleyici hesap switch’e tam yetkiyle girmişti.
• Otomatik işlerin hesaplarını sunucuda tanımlayın. Lab’da yedek betiğinin kullandığı yedekci hesabı sunucuda yoktu ve erişim günlüğüne shell login failed düştü. Yedek, izleme ve envanter hesapları sunucuda en düşük yetkiyle tanımlanır.
• Kullanıcıları bir dizine bağlayın. Yukarıdaki yapılandırmadaki düz metin parola yalnız lab içindir; gerçek bir kurulumda kullanıcılar Active Directory gibi bir dizinden gelir.
• Her cihaza ayrı ve uzun bir anahtar verin, anahtarı düzenli değiştirin. RFC 8907, sunucunun her istemci için ayrı bir anahtar tanımlamaya izin vermesini şart koşar, yöneticilerin anahtarları düzenli aralıklarla değiştirmesini ister ve istemcilerin 16 karakterden kısa anahtarla sunucu tanımlanmasına izin vermemesini önerir (RFC 8907, bölüm 10.5.1).
• Yapılandırma yedeklerini gizli belge gibi saklayın. Lab switch’inin çalışan yapılandırmasında paylaşılan anahtar düz metin duruyordu; yedeği ele geçiren anahtarı da ele geçirir.
• Trafiği yalnız yönetim ağından geçirin. Gövde şifrelenmez, yalnız gizlenir; RFC 8907 bu yüzden aktarım yolunun tamamının denetlenmesini şart koşar (yukarıdaki paket bölümü).
• Sunucuyu yalnız cihazlara açın. host bloğuna yalnız cihazların adresleri yazılır ve TCP 49 güvenlik duvarında yalnız onlara açılır.
• Saatleri aynı kaynağa bağlayın. Cihazın ve sunucunun saati tutmazsa bir arızada iki tarafın kaydını yan yana okuyamazsınız.
• Cihazdaki değişikliği ikinci bir oturum açıkken yapın. Kimlik doğrulamayı değiştiren yanlış bir satır yeni girişleri keser; açık kalan oturum geri dönüş yolunuzdur.

Sonuç: TACACS+ Her Kararı Kaydeder, Yolunu Siz Korursunuz

TACACS+ ağ cihazına yönetici girişini tek bir sunucuda doğrular, her komutu ayrıca yetkilendirir ve her kararı kullanıcı adıyla kaydeder. Lab’da sunucunun günlüğü, izleyici hesabın configure denemesini deny, show clock komutunu permit diye yazdı. Ortak yönetici parolasıyla çalışan bir ağda bu kaydın hiçbiri tutulmaz.

Bedeli iki yerdedir. Gövde yalnız gizlendiği için taşıdığı yolu sizin korumanız gerekir, merkez durduğunda da bütün cihazların yönetimi yavaşlar. Gişe görevlisinin her işlemini merkez onaylar, ama merkezin kendisi de korunmak ve yedeklenmek zorundadır.

Protokolün ağ protokolleri arasındaki yerini kurumsal ağ protokolleri rehberimizde, switch tarafını switch TACACS+ yapılandırması yazımızda anlattık.

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