SNMPv3 Yapılandırması: authPriv ile Ağ Cihazı İzleme Rehberi

SNMPv2c’de community dizesi kabloda düz metin gider. Yönetim trafiğini görebilen biri cihazın tüm MIB ağacını okur; yazma community’si açık bırakılmışsa yapılandırmayı da değiştirir. Sahada hâlâ varsayılan “public” community’siyle çalışan çekirdek switch’ler çıkıyor. Aşağıda switch ve router izlemesini SNMPv3 authPriv’e taşırken gereken kullanıcı–grup–view yapısı, Cisco IOS komutları, erişim kısıtlaması ve Linux’tan doğrulama sırası var.

SNMP sürümleri ve güvenlik seviyeleri: noAuthNoPriv, authNoPriv, authPriv

SNMPv1 ve v2c’de kimlik doğrulama, community dizesinin eşleşmesinden ibarettir. Bütünlük kontrolü yok, şifreleme yok. SNMPv3 ise User-based Security Model (USM, RFC 3414) ile her mesaja kullanıcı adı, kimlik doğrulama özeti ve isteğe bağlı şifreleme ekler. Üç güvenlik seviyesi tanımlıdır:

authNoPriv sahte isteği ve paket değişikliğini engeller; ama arayüz açıklamaları, ARP tablosu ve yönlendirme bilgisi okunur kalır. Bu yarım iştir. Hedef seviye authPriv’dir. Algoritma tarafında MD5 ve DES artık zayıf kabul ediliyor: cihaz destekliyorsa kimlik doğrulamada SHA (tercihen SHA-2 ailesi, RFC 7860), şifrelemede AES-128 veya üzerini seçin (USM için AES tanımı RFC 3826’dadır). Eski platformlar yalnız SHA-1 ve AES-128 sunabilir; bu kombinasyon bile v2c’ye göre ciddi bir adımdır.

SNMPv3 mimarisi: kullanıcı, grup, view ve engine ID

SNMPv3 yapılandırması dört nesneden oluşur. Aralarındaki ilişki oturmadan sorun gidermeye girişmek, körlemesine komut denemek demektir:

• View: Hangi OID ağacının görülebileceğini tanımlar. iso (1) tüm ağaçtır; hassas dallar excluded ile dışarıda bırakılabilir.
• Grup: Güvenlik seviyesini (auth/priv) ve read, write, notify view’larını bağlar. View-based Access Control Model (VACM, RFC 3415) yetkiyi bu düzeyde uygular.
• Kullanıcı: Bir gruba bağlanır, kimlik doğrulama ve şifreleme parolalarını taşır.
• Engine ID: Her SNMP varlığının tekil kimliğidir. Parolalar bu kimlikle “yerelleştirilmiş” anahtara dönüştürülerek saklanır.

Engine ID’nin sahadaki sonucu şudur: Cihazın yerel engine ID’si değişirse (elle değiştirme ya da bazı platformlarda MAC/şasi değişimi) daha önce tanımlanan kullanıcıların anahtarları geçersiz hale gelir. Kullanıcılar yeniden oluşturulmadan veri gelmez. Stack üyesi değişiminden veya RMA’dan sonra gelen “SNMPv3 durdu” çağrılarının önemli kısmı buradan çıkar. Engine ID’yi elle sabitlemek yerine varsayılanı bırakın ve donanım değişimi prosedürüne “SNMPv3 kullanıcılarını yeniden tanımla” adımını yazın. Öngörülebilir yol budur.

Cisco IOS’ta SNMPv3 authPriv yapılandırma örneği

Aşağıdaki örnek, yönetim ağındaki iki izleme sunucusuna (10.10.99.10 ve 10.10.99.11) salt-okunur erişim ve trap gönderimi tanımlıyor. Sözdizimi Cisco IOS/IOS XE’dir.

! 1. Kaynak kısıtlama ACL'i
ip access-list standard ACL-SNMP-NMS
 permit host 10.10.99.10
 permit host 10.10.99.11
 deny   any log
!
! 2. View: tüm ağaç okunabilir
snmp-server view VIEW-RO iso included
!
! 3. Grup: authPriv, salt-okunur, ACL bağlı
snmp-server group GRP-NMS-RO v3 priv read VIEW-RO access ACL-SNMP-NMS
!
! 4. Kullanıcı: SHA kimlik doğrulama, AES-128 şifreleme
snmp-server user nms-ro GRP-NMS-RO v3 auth sha <AuthParola> priv aes 128 <PrivParola>
!
! 5. Trap hedefi ve kaynak arayüz
snmp-server trap-source Loopback0
snmp-server host 10.10.99.10 version 3 priv nms-ro
snmp-server enable traps snmp linkdown linkup coldstart
snmp-server enable traps config
!
! 6. Eski community tanımlarını kaldırma (geçiş tamamlandıktan sonra)
no snmp-server community <eski-community>

Konsolda en çok takılınan noktalar:

• SNMPv3 kullanıcıları show running-config çıktısında görünmez. Bu bir hata değil, güvenlik tasarımıdır; kontrol show snmp user ile yapılır. Pratik sonucu ağırdır: konfigürasyon yedeğinden geri yükleme yaptığınızda kullanıcıları yeniden oluşturmanız gerekir.
• Yeni IOS XE sürümleri SHA-2 (ör. SHA-256) ve AES-192/256 seçenekleri sunar. Sözdizimi platforma göre değiştiği için kullandığınız sürümün komut referansından doğrulayın.
• Kimlik doğrulama ve şifreleme parolaları farklı ve en az 8 karakter olsun. Net-SNMP gibi istemciler daha kısa parolayı reddeder.
• snmp-server enable traps parametresiz yazılırsa platformdaki tüm trap türleri açılır ve izleme sunucusu gürültüye boğulur. İhtiyaç duyulan türleri tek tek açın.

Uyguladıktan sonra cihazda show snmp user, show snmp group, show snmp view ve show snmp engineID çıktılarına bakın. Grup “priv” seviyesinde ve doğru ACL ile görünmeli.

Erişim kısıtlama: ACL, yönetim VLAN’ı ve trap hedefleri

authPriv trafiği şifreler; ajana kimin istek gönderebileceğini sınırlamaz. Bu ayrı bir katmandır ve çoğu kurulumda eksik kalır:

1. Grup ACL’i: Yukarıdaki gibi access parametresiyle yalnız izleme sunucularının adreslerine izin verin. deny any log satırı yetkisiz denemeleri syslog’a düşürür; kapıyı kimin yokladığını görürsünüz.
2. Yönetim düzlemi: SNMP, SSH ve syslog trafiği ayrı bir yönetim VLAN’ında veya VRF’te taşınmalı; kullanıcı VLAN’larından cihaz yönetim adreslerine erişim L3 sınırında kapatılmalı. Segmentasyon kararları için kurumsal ağda VLAN tasarımı yazısına bakın.
3. Trap hedefleri: Sorgular UDP 161’e, trap’ler UDP 162’ye gider. Trap onaysızdır; kritik bildirimlerde onaylı informs değerlendirilebilir (snmp-server host 10.10.99.10 informs version 3 priv nms-ro). Burada sık atlanan bir ayrıntı var: SNMPv3 inform’da yetkili (authoritative) taraf alıcıdır. Cihazda izleme sunucusunun engine ID’si snmp-server engineID remote ile tanımlanmalı, kullanıcı da remote parametresiyle o engine ID’ye göre ayrıca oluşturulmalıdır. Yapılmazsa trap’ler çalışır, inform’lar sessizce düşer.
4. Write erişimi: İzleme için write view tanımlamayın. Yapılandırma değişikliği SNMP üzerinden değil, denetlenebilir SSH/API kanallarından yapılır.

snmpwalk ve snmpget ile doğrulama

Cihazı izleme platformuna eklemeden önce izleme sunucusunun kendisinden Net-SNMP araçlarıyla test edin. Sorunun cihazda mı platformda mı olduğu baştan ayrılır.

# sysDescr ve sysUpTime okuma
snmpget -v3 -l authPriv -u nms-ro -a SHA -A 'AuthParola' -x AES -X 'PrivParola' \
  10.10.20.1 SNMPv2-MIB::sysDescr.0 SNMPv2-MIB::sysUpTime.0

# Arayüz adlarını listeleme
snmpwalk -v3 -l authPriv -u nms-ro -a SHA -A 'AuthParola' -x AES -X 'PrivParola' \
  10.10.20.1 IF-MIB::ifName

# 64 bit arayüz sayaçları (yüksek hızlı portlar için zorunlu)
snmpwalk -v3 -l authPriv -u nms-ro -a SHA -A 'AuthParola' -x AES -X 'PrivParola' \
  10.10.20.1 IF-MIB::ifHCInOctets

Net-SNMP’nin hata mesajları arızanın yerini doğrudan söyler:

“Timeout” görüyorsanız kontrol sırası şudur: Önce izleme sunucusunda tcpdump -ni any udp port 161 ile isteğin gerçekten çıkıp çıkmadığına, sonra cihazda ACL sayaçlarına (show access-lists ACL-SNMP-NMS) bakın. Sayaç artmıyorsa paket cihaza ulaşmıyordur; aradaki firewall kuralını kontrol edin. Bir uyarı: Parolayı komut satırına yazmak onu kabuk geçmişine kaydeder. Testten sonra geçmişi temizleyin ya da parametreleri kullanıcıya özel ~/.snmp/snmp.conf dosyasında tutun.

İzleme sunucusunda SNMPv3 kimlik bilgisi yönetimi

SNMPv3’ün asıl yükü cihazda değil, izleme platformunda çıkar. Birkaç yüz cihazlık bir kurumsal ağ altyapısında şu kararları baştan verin:

• Tek kullanıcı mı, cihaz grubu başına kullanıcı mı? Tek kullanıcı yönetimi kolaylaştırır, ama bir parola sızarsa tüm ağ açıkta kalır. Orta yol, cihaz rolüne veya lokasyona göre birkaç kullanıcı tanımlamaktır.
• Parolaların saklanması: Platformun gizli değişkenlerini kullanın (örneğin Zabbix’te “Secret text” türündeki makrolar). Şablon açıklamalarında veya dışa aktarılan dosyalarda düz metin parola bırakmayın.
• Parola rotasyonu: SNMPv3’te parola değiştirmek, kullanıcıyı yeniden tanımlamak demektir. Kesintisiz rotasyon için yeni parolalı ikinci bir kullanıcı ekleyin, platformu ona geçirin, eski kullanıcıyı sonra silin.
• Otomasyon: Kullanıcı tanımı running-config’te görünmediği için yapılandırma standardı kontrolü bunu yakalamaz. Kullanıcının varlığını show snmp user çıktısını periyodik toplayarak doğrulayın.

Platform henüz seçilmediyse SNMPv3 desteği ve diğer karar kriterleri Zabbix, LibreNMS ve PRTG karşılaştırması yazısında. Arayüz sayaçlarının ötesinde trafiğin kaynak–hedef dağılımını görmek istiyorsanız NetFlow, sFlow ve IPFIX tarafına geçmeniz gerekir. SNMP yalnız “ne kadar” der.

v2c’den v3’e geçişte sık yapılan hatalar

Geçişi birkaç cihazlık bir pilotla başlatın. Pilotta v2c ve v3 yan yana çalışır; izleme platformu v3 ile veri aldığını kanıtladıktan sonra community tanımları kaldırılır. Sahada en sık gördüğümüz hatalar:

1. Community’yi kaldırmayı unutmak: v3 eklenip v2c bırakıldığında güvenlik kazanımı sıfırdır. Geçiş sonunda tüm cihazlarda show running-config | include snmp-server community çıktısının boş olduğunu doğrulayın.
2. Grup ile kullanıcı seviyesini uyuşturmamak: Grup priv, kullanıcı yalnız auth ile tanımlanırsa sorgular reddedilir.
3. 32 bit sayaçlarla devam etmek: SNMPv1 64 bit sayaç desteklemediği için bazı eski şablonlar hâlâ ifInOctets kullanır. 32 bitlik sayaç yaklaşık 4,29 milyar baytta başa döner: tam yüklü 1 Gbit/s portta yaklaşık 34 saniyede, 10 Gbit/s portta yaklaşık 3,4 saniyede. Yoklama aralığı bundan uzunsa grafik yanlış değer üretir. Şablonların ifHCInOctets/ifHCOutOctets kullandığını kontrol edin.
4. Trap kaynağını sabitlememek: trap-source verilmezse trap’ler çıkış arayüzünün IP’siyle gelir; platform bunları tanımadığı bir cihazdan gelmiş gibi işler.
5. Zaman penceresini atlamak: USM, engine boot ve engine time değerleriyle eski mesajların tekrar oynatılmasını engeller. Cihaz yeniden başladıktan sonra platform bu değerleri yeniden öğrenir. Sürekli “notInTimeWindow” hatası görüyorsanız aynı engine ID’ye sahip iki cihaz arayın; klonlanmış sanal cihazlarda sık çıkar.
6. CPU etkisini hesaba katmamak: Şifreleme ajan tarafında ek işlem yükü getirir. ARP, MAC ve yönlendirme gibi büyük tabloları kısa aralıklarla yürümek yerine yoklama aralığını veri türüne göre ayırın.

Ağ genelinde izleme altyapısının kurulması ve periyodik kontrollerin planlanması için ağ bakım, izleme ve periyodik kontrol hizmetine; cihaz yapılandırma standardı için switch ve router kurulumu sayfasına bakabilirsiniz.

Sık sorulan sorular

SNMPv3 kullanıcısı neden running-config içinde görünmüyor?

Cisco IOS, SNMPv3 kullanıcılarını parolalarıyla birlikte yapılandırma dosyasına yazmaz; kullanıcılar show snmp user ile görülür. Konfigürasyon yedeğinden geri yükleme yaptığınızda kullanıcıları ayrıca yeniden tanımlamanız gerekir.

authNoPriv seviyesi yeterli değil mi?

Değil. authNoPriv sahte isteği ve mesaj değişikliğini engeller ama içeriği şifrelemez; arayüz açıklamaları, ARP ve yönlendirme tabloları ağı dinleyen biri tarafından okunur. Üretim ortamında hedef authPriv’dir.

SNMPv3 cihaz CPU’sunu ne kadar etkiler?

Şifreleme ve özet hesaplama v2c’ye göre ek işlem yükü getirir; etki yoklanan OID sayısına ve sıklığına bağlıdır. Büyük tabloları seyrek, arayüz sayaçlarını sık yoklayın ve geçişten sonra cihazın CPU grafiğini birkaç gün izleyin.

Engine ID değişirse ne olur?

Kullanıcı anahtarları engine ID ile yerelleştirildiği için engine ID değişince mevcut kullanıcılar çalışmaz ve yeniden oluşturulmaları gerekir. Donanım değişimi ve RMA prosedürüne SNMPv3 kullanıcılarını yeniden tanımlama adımını yazın.