Yönetim Düzlemi Güvenliği: SSH, SNMPv3, NTP ve Syslog

SSH, SNMPv3, merkezi NTP ve syslog iyi bilinen maddelerdir. Yıl Sonu Ağ Güvenliği Kontrol Listesi bu maddelerin var olup olmadığını denetler. Bu yazı şunu soruyor: her protokol ve güvenlik düzeyi neyi korur, neyi açık bırakır, cihazda nasıl doğrulanır?

Yönetim erişimini ACL ile daraltmak ACL yazısında, kimin ne yapabileceğine karar veren AAA CIA ve AAA yazısında anlatıldı; burada tekrar edilmiyor. Komutlar resmî belgelerden alındı, laboratuvarda denenmedi. Yalnızca salt okunur doğrulama komutları veriliyor ve örnek çıktı yok.

Üç düzlem ve dört protokol

Bir ağ cihazındaki işler üç düzleme ayrılır. Veri düzlemi kullanıcı trafiğini iletir. Kontrol düzlemi OSPF ve BGP gibi protokollerle bu iletimin nereye yapılacağına karar verir. Yönetim düzlemi ise cihazın kendisini yönetmek için kullanılan erişimdir: yapılandırma, izleme, zaman ve log.

Bu yazıdaki dört protokol yönetim düzleminde iki farklı rol oynar:

SSH ve SNMP doğrudan erişimdir. SSH ile cihaz yapılandırılır; SNMP ile durum okunur ve bazen değer yazılır. Bunlar ele geçirilirse saldırgan cihazı yönetir ya da ayrıntılı bilgi toplar.
NTP ve syslog destek servisleridir. Cihaza erişim vermezler; olay incelemesinin güvenilirliğini belirlerler. Saati yanlış bir cihazın logu yanlış sıraya girer; yolda kaybolan ya da sahtelenen log, olayın kendisini gizleyebilir.

Yönetim trafiği hangi yoldan gidiyor?

Kampüs topolojisinde yönetim ağı 10.0.99.0/24’tür ve core switch’e bağlıdır. Bu yazı için birkaç öğretici varsayım ekleniyor: yönetim ağı VLAN 99’da, jump host 10.0.99.10, SNMP yöneticisi (NMS) 10.0.99.20. Sunucu VLAN’ı 30’da zaman sunucusu 10.0.30.12, log kolektörü 10.0.30.50. Fiziksel OOB ağı için 10.0.98.0/24 kullanılıyor.

Bu yollar birbirine eşit değildir:

Bant içi yönetim VLAN’ı: Yönetim trafiği ayrı bir VLAN’da, ama kullanıcı trafiğiyle aynı kablo ve switch’lerden geçer.
Yönetim VRF’i: Yönetim arayüzleri ayrı bir yönlendirme tablosundadır; veri ağının rotaları karışmaz. Bu da mantıksal bir ayrımdır, aynı fiziksel bağlantıları kullanabilir.
Fiziksel OOB: Cihazların yönetim ya da konsol portları ayrı bir switch’e ve ayrı kablolamaya bağlanır. NSA’nın OOB rehberi bunu en güvenli seçenek olarak tanımlar; VLAN, VRF ya da VPN ile yapılan sanal ayrımı daha az güvenli bulur, çünkü yönetim trafiği operasyonel bağlantıları paylaşır. Fiziksel OOB’nin ikinci kazancı bağımsızlıktır: core arızasında erişimin sürmesi için jump host’a giden yol ve yönetim altyapısı da üretim ağından bağımsız olmalıdır.

Jump host erişimi daraltır, OOB sağlamaz. Cihazlara yalnızca bir jump host’tan bağlanmak, kimin bağlanabileceğini sınırlar. Ama jump host bant içi bir VLAN’daysa, yönetim trafiği yine veri ağının bağlantılarından geçer.

Yönetim VLAN'ı ve VRF'i trafiği mantıksal olarak ayırır ama veri ağının bağlantılarını paylaşır. Fiziksel OOB ayrı switch ve kablolama kullanır; core arızasında erişimin sürmesi için jump host'a giden yol ve yönetim altyapısı da üretim ağından bağımsız olmalıdır. Oklar bağlantıyı başlatan tarafı gösterir.

SSH: Şifreli oturum, doğru cihaz değil

Neyi korur? RFC 4251’e göre SSH üç katmandan oluşur. Taşıma katmanı sunucu kimlik doğrulaması, gizlilik ve bütünlük sağlar. Kullanıcı kimlik doğrulama katmanı kullanıcıyı sunucuya doğrular. Bağlantı katmanı şifreli tüneli kanallara böler. Telnet ise ne oturumu şifreler ne de sunucuyu doğrular; parola ve komutlar ağda açık gider.

Neyi korumaz?

Doğru cihaza bağlandığınızı kendiliğinden kanıtlamaz. Sunucunun kimliği, host key istemcinin bildiği anahtarla karşılaştırılarak doğrulanır. RFC 4251, ilk bağlantıda anahtarın kontrol edilmeden kabul edilmesine izin verir ve bu durumda bağlantının pasif dinlemeye karşı korunduğunu ama aktif ortadaki adam saldırısına açık olduğunu belirtir. “Host key değişti” uyarısını geçiştirmek, şifreli bir oturumu saldırganla kurmak demek olabilir.
Yetkilendirme yapmaz. SSH kullanıcıyı doğrular; hangi komutları çalıştırabileceğini cihazın AAA ve rol yapısı belirler. Bağlanan herkesin tam yetkili olması, en az yetki ilkesinin uygulanmadığını gösterir.

Nasıl doğrulanır? Telnet’in kapalı ve yalnızca SSHv2’nin açık olduğu cihazda kontrol edilir. Host key parmak izi kurulumda kaydedilir ve ilk bağlantıda bu kayıtla karşılaştırılır. Açık oturumların sürümü, şifrelemesi ve kullanıcısı gözden geçirilir.

SNMP: Güvenlik düzeyi yetki değildir

SNMPv2c: RFC 3410’a göre SNMPv1 ve SNMPv2c yalnızca düz metin community dizileriyle basit bir kimlik doğrulama yapar ve temelden güvensizdir. Community dizisi trafiği dinleyen herkes tarafından görülebilir.

SNMPv3 ve USM: RFC 3411 üç güvenlik düzeyi tanımlar:

Düzey	Kimlik doğrulama ve bütünlük	Gizlilik
noAuthNoPriv	Yok	Yok
authNoPriv	Var	Yok
authPriv	Var	Var

RFC 3414’teki User-based Security Model (USM), mesajın yolda değiştirilmesine ve kullanıcı taklidine karşı koruma hedefler. authNoPriv’de yolda değiştirilen mesaj doğrulamadan geçmez, ama içerik açıktır. Gizlilik ancak authPriv ile gelir. Algoritma da önemlidir: RFC 3414’ün şifrelemesi DES’tir; RFC 3826 AES-128’i, RFC 7860 SHA-2 tabanlı doğrulamayı tanımlar. NSA’nın 2026 tarihli SNMP rehberi, cihaz destekliyorsa authPriv kullanılmasını, desteklemiyorsa cihazın yükseltilmesini önerir.

Neyi korumaz?

Yetkiyi belirlemez. USM kullanıcıyı doğrular; o kullanıcının hangi nesneleri okuyup yazabileceğine RFC 3415’teki View-based Access Control Model (VACM) karar verir. authPriv bir kullanıcıya yazma izni ve bütün MIB görünümü verilmişse, güvenlik düzeyi yüksek ama yetki geniştir.
Mesaj silinmesini engellemez. RFC 3414’e göre zaman penceresi (150 saniye) gecikmiş ve tekrar oynatılmış mesajları sınırlar, ama mesajların silinmesine ya da bastırılmasına karşı koruma sağlamaz. Hizmet engelleme ve trafik analizi de kapsam dışıdır.

Nasıl doğrulanır? Her SNMPv3 kullanıcısının ve grubunun güvenlik düzeyi ile okuma, yazma ve bildirim görünümleri ayrı ayrı kontrol edilir. Cisco’nun Catalyst 9300 kılavuzu, SNMPv3 kullanıcı bilgisinin show running-config çıktısında görünmediğini ve show snmp user ile okunması gerektiğini belirtir. Bir konfigürasyon yedeğine bakarak SNMPv3 denetimi yapmak bu yüzden eksik kalabilir.

NTP: Zamanı kim söylüyor?

NTP’de üç koruma durumu vardır:

Kimlik doğrulamasız NTP: İstemci, zaman yanıtının yetkili sunucudan geldiğini ve yolda değişmediğini doğrulayamaz.
Simetrik anahtarla doğrulama: Sunucu ve istemci aynı anahtarı paylaşır; mesaj bu anahtarla doğrulanır. RFC 5905’teki MD5 tabanlı yöntem RFC 8573 ile zayıf kabul edilmiş ve AES-CMAC önerilmiştir. Ürünlerin sunduğu seçenekler farklıdır: Cisco’nun IOS XE 17 NTP kılavuzu MD5, CMAC-AES-128, HMAC-SHA1 ve HMAC-SHA2-256’yı listeler; FortiOS 7.6.4 MD5, SHA1 ve SHA256 seçeneklerini sunar.
NTS (RFC 8915): İki ayrı aşamadan oluşur. İlk aşamada, NTS-KE, TLS üzerinden (TCP 4460) sunucu doğrulanır ve anahtarlar kurulur. İkinci aşamada zaman senkronizasyonu yine UDP 123 üzerinden NTPv4 paketleriyle yapılır; paketler uzantı alanlarıyla doğrulanır. Zaman bilgisi TLS içinde taşınmaz: RFC 8915’e göre temel zaman verisi gizli kabul edilmez ve açık gönderilir, yalnızca bazı uzantı alanları şifrelenir.

Neyi korumaz? RFC 8915, kriptografinin gecikme saldırısını önleyemediğini belirtir: yoldaki bir saldırgan paketleri değiştirmeden yalnızca tek yönde geciktirirse istemci yanlış bir offset hesaplar. Hata en fazla gidiş-dönüş gecikmesinin yarısı kadardır. Doğrulama, yanlış yapılandırılmış ya da yanlış saati yayan bir iç sunucuya karşı da koruma sağlamaz.

NTS desteği: İncelenen resmî belgelerde, Cisco IOS XE 17 NTP yapılandırma kılavuzunda ve FortiOS 7.6.4 config system ntp referansında, NTS seçeneği bulunamadı. Huawei VRP ve AOS-CX için NTS desteği resmî belgede doğrulanamadı. Bu yüzden yazıda NTS yapılandırma komutu yok; NTS kullanmak isteyen, kendi model ve yazılım sürümünün belgesini kontrol etmelidir.

Nasıl doğrulanır? Senkronizasyon durumu, seçilen kaynak, stratum ve offset okunur. Doğrulama yapılandırılmış olsa bile cihaz senkron değilse o kaynağı kullanmıyordur.

Syslog: Taşıma, logun kendisini korumaz

Syslog için üç taşıma seçeneği vardır ve güvenlik özellikleri farklıdır:

UDP 514 (RFC 5426): Gönderenin kimliği doğrulanmaz, mesaj sahtelenebilir, gizlilik yoktur ve teslim garantisi yoktur. RFC 5426, bir saldırganın normal etkinliği gösteren mesajları kaydedip daha sonra tekrar gönderebileceğini ve mesajları yolda düşürerek yetkisiz işlemleri gizleyebileceğini açıkça yazar.
TCP (RFC 6587): Bağlantı ve yeniden iletim getirir, güvenlik getirmez. RFC 6587’ye göre bu yöntemde kimlik doğrulama, bütünlük denetimi ve gizlilik yoktur.
TLS, TCP 6514 (RFC 5425): Aktarımda gizlilik ve bütünlük sağlar; cihaz kolektörü doğrular. Kolektörün gönderen cihazı doğrulaması ayrıdır: RFC 5425’e göre istemci sertifikası istenmezse gönderen taklidi engellenmez; bunun için karşılıklı kimlik doğrulama gerekir.

TLS neyi garanti etmez? RFC 5425’e göre TLS syslog’u yalnızca hop-by-hop korur ve mesaj içeriğiyle ilgilenmez; sertifikadaki kimlik, mesajdaki HOSTNAME alanıyla aynı olmak zorunda değildir. Ayrıca:

Cihaz ele geçirilip loglar kaynakta değiştirilirse TLS bunu fark etmez; yalnızca yoldaki değişikliği engeller.
Cihaz bağlantı kopukken ürettiği logları kolektöre hiç göndermeyebilir. Hangi logların tamponda tutulduğu ve ne kadar beklendiği üreticiye göre değişir.
RFC 5424’e göre syslog protokolünde tekrar oynatmayı tespit eden bir mekanizma yoktur.

Nasıl doğrulanır? Cihazda kullanılan taşıma ve port kontrol edilir; FortiOS 7.6.1’de config log syslogd setting altındaki mode (udp, legacy-reliable, reliable) ve enc-algorithm değerleri bunu belirler; mode reliable tek başına TLS sağlamaz, enc-algorithm de kontrol edilir. Kolektörde, cihazdan gönderilen test mesajının gelip gelmediğine ve kaynağın doğrulanıp doğrulanmadığına bakılır. Kolektörde “bu cihazdan şu süredir log gelmedi” uyarısı, protokolün veremediği teslim güvencesini kısmen tamamlar.

Doğrulama, bütünlük ve gizlilik ayrı özelliklerdir. authNoPriv ve NTS mesajın değiştirilmesini engeller ama içeriği gizlemez; TLS syslog yalnızca yolu korur ve gönderen cihazı ancak karşılıklı doğrulamayla doğrular.

Doğrulama komutları

Komutlar yalnızca durumu okur. Resmî belgede doğrulanamayan komut tabloya konmadı.

Kontrol	Cisco IOS XE 17.12 (Catalyst 9300)	Huawei VRP	FortiOS 7.6
SSH sunucusu ve oturumlar	`show ip ssh`, `show ssh`	`display ssh server status`, `display ssh server session`	—
SNMPv3 kullanıcı ve grupları	`show snmp user`, `show snmp group`	—	—
NTP durumu	`show ntp status`, `show ntp associations`	`display ntp-service status`	`diagnose sys ntp status`

Huawei komutlarının kaynağı, SSH için Fit AP V200R010C00 komut referansı, NTP için Huawei’nin S serisi sorun giderme sayfasıdır; switch modelinizin komut referansında ayrıca kontrol edin. Aruba AOS-CX komutları resmî belgede doğrulanamadığı için tabloda yer almıyor.

Kendinizi deneyin

Alıştırma 1: Core switch’te NMS’in kullandığı SNMPv3 kullanıcısı authNoPriv düzeyinde ve yalnızca okuma görünümüne sahip. Cihaz logları UDP 514 ile 10.0.30.50’ye gidiyor. Yönetim trafiğinin geçtiği bir segmentte iki saldırgan var: biri yalnızca trafiği dinleyebiliyor (pasif), diğeri paketleri düşürebiliyor, değiştirebiliyor ve sahte paket gönderebiliyor (aktif). Her biri SNMP ve syslog ile neler yapabilir, neler yapamaz?

Cevap ve açıklama

Pasif saldırgan, SNMP: authNoPriv içeriği şifrelemediği için sorgulanan bütün değerleri okur: arayüz adları, yönlendirme bilgileri, yazılım sürümü. Kullanıcı adı da görünür. Anahtarı bilmediği için geçerli bir SNMP mesajı üretemez.
Pasif saldırgan, syslog: Bütün logları okur; yönetici adları ve yapılandırma değişiklikleri keşif bilgisidir.
Aktif saldırgan, SNMP: Mesajı değiştirebilir ama değiştirilmiş mesaj doğrulamadan geçmez ve reddedilir. Mesajı okumak ile mesajı doğrulamayı geçecek şekilde değiştirmek arasındaki fark budur: authNoPriv birincisini engellemez, ikincisini engeller. Saldırgan mesajları düşürebilir; USM silmeye karşı koruma vermez. Eski bir mesajı tekrar göndermesi 150 saniyelik zaman penceresiyle sınırlıdır.
Aktif saldırgan, syslog: Cihaz adına sahte log gönderebilir; mesajları değiştirebilir, düşürebilir ya da tekrar oynatabilir. UDP syslog bunları fark etmez.
Yetki: Kullanıcının yalnızca okuma görünümü olduğu için anahtar ele geçirilse bile yazma yapılamaz. Bu koruma güvenlik düzeyinden değil, VACM’den gelir.
Düzeltme: SNMP kullanıcısı authPriv’e (AES) geçirilir; syslog için TLS (TCP 6514) kullanılır ya da en azından trafik ayrı bir yönetim yolunda tutulur.

Alıştırma 2: Bir güvenlik olayında, aynı olaya ait üç log kolektörde şu zaman damgalarıyla görünüyor:

FortiGate: 2027-03-03T09:14:58.900+03:00
Core switch: 2027-03-03T06:15:01.120Z
Bir erişim switch’i: Mar 3 09:19:40

İnceleme ekibi core switch’in saatinin üç saat geri olduğunu düşünüyor. Ek kanıtlar: FortiGate’te diagnose sys ntp status, synchronized: yes gösteriyor; 10.0.30.12 reachable ve selected, clock offset 0.004 sec. Core switch’te show ntp associations, 10.0.30.12 satırında * ve reach 377 gösteriyor, offset 1.2 ms. Erişim switch’inde yapılandırılmış tek NTP sunucusu 10.0.30.13; bu satırda * yok ve reach 0. Hangi fark gösterimden, hangisi gerçek saat sapmasından kaynaklanıyor?