SNMP Nedir? MIB, OID ve Trap Mekanizması

Bir ağda “internet yavaş” cümlesi kadar çok tekrarlanan ve bir o kadar az işe yarayan başka cümle yoktur. Hangi lokasyonda, saat kaçta, ne kadar yavaş: üçü de bilinmeden yavaşlık bir arıza kaydı değil, bir kanaattir. SNMP (Simple Network Management Protocol), ağdaki cihazlara tam olarak bu soruları düzenli aralıklarla soran ve dönen cevapları ölçüye çeviren protokoldür.

Çalışma mantığını anlamanın en kısa yolu, adresli bir yangın algılama sistemine bakmaktır. Panel, hatta bağlı her dedektörü adresiyle tek tek yoklar ve her seferinde aynı şeyi sorar: “üç numara, durumun ne?” Dedektör cevabını döner, panel kaydeder, sıradakine geçer. Duman gerçekten çıktığında ise dedektör sırasının gelmesini beklemez, hattı kendisi çeker. Bu iki davranış, yani düzenli yoklama ile kendiliğinden gelen ihbar, SNMP’nin bütün mimarisini açıklar.

Bu makale kurumsal network kurulumu hizmetimizin izleme koluna odaklanır ve ağ protokolleri rehberimizde toplu olarak tanıtılan protokollerden birini derinleştirir. Protokolü zaten biliyor ve doğrudan ölçüme geçmek istiyorsanız, community string’in pakette nasıl göründüğü bölümüne atlayabilirsiniz.

SNMP Nedir ve Hangi Sorunu Çözer?

SNMP (Simple Network Management Protocol), ağ cihazlarından durum bilgisi toplamak için kullanılan uygulama katmanı protokolüdür. Switch’e kaç paket düştüğünü, hattın ne kadarının dolu olduğunu, işlemcinin ne durumda olduğunu bu protokolle sorarsınız. Cevap bir cümle değil, bir sayıdır; ve sayı olduğu için saklanabilir, karşılaştırılabilir, grafiğe dönüşebilir.

Çözdüğü sorun teknik değil, aslında dilseldir. “İnternet yavaş” bir ölçüm değil bir kanaattir. Hangi lokasyonda, saat kaçta, ne kadar yavaş: üçü de bilinmediği sürece o cümlenin üzerine hiçbir karar kurulamaz. SNMP kanaati sayıya çevirir.

Bir noktayı hemen ayırmak gerekiyor, çünkü sahada en çok karıştırılan yer burasıdır. SNMP hattın ne kadar dolu olduğunu ölçer; bir cihazın ayakta olup olmadığını ölçmez. İkincisi için izleme sistemleri yankı isteği ve yanıtı, yani ping kullanır. Fark pratikte şuna dönüşür: düşmüş bir kablosuz erişim noktası yüzünden sinyali zayıflayan kullanıcılar da “internet yavaş” der, ama o tabloda hat hiç dolu değildir. Doluluğu SNMP söyler, erişilebilirliği ping; ikisi bir aradayken şikayetin hangisi olduğu tartışma konusu olmaktan çıkar.

Bu ayrımı akılda tutun, çünkü makalenin geri kalanı onun üzerine kurulu: izleme yazılımı bir yüzdür, altındaki mekanizma SNMP’dir.

Cihaz Sayısı Arttığında Ne Bozulur?

SNMP’nin var olma sebebi, insanın ölçeklenmemesidir. Üç cihazlık bir ofiste her birine tek tek bakabilirsiniz. Kırılma noktası basit bir çarpma işlemiyle görünür hâle gelir: On lokasyonda lokasyon başına bir router, bir firewall ve iki switch varsa 40 cihaz eder. Her birinin dört değerini (hat doluluğu, işlemci, bellek, hata sayacı) günde bir kez elle okumak 160 ölçüm demektir. Bunu bir kişi yapamaz, yaparsa da yalnızca bir kez yapar.

Asıl mesele emek değil süreklilik. Arıza, siz baktığınız anda değil bakmadığınız anda çıkar. Bir hattın saat 14.00’te dolduğunu, ancak saat 14.00’te oraya bakıyorsanız görürsünüz. İnsan sürekli bakamaz; bir program bakabilir.

İşte protokolün doğduğu yer burasıdır. SNMP, “cihaza gidip bakma” işini ağ üzerinden yapılabilir, standart ve otomatik bir sorguya çevirir. Cihaza kim üretirse üretsin aynı soruyu aynı biçimde sorabilmenizin sebebi budur.

SNMP Ne Zaman Gerekmez?

Her teknolojinin bir alt eşiği vardır ve bunu söylemek satış yapmamak demektir. Tek switch ve birkaç bilgisayarın olduğu bir ofiste SNMP kurmanın maliyeti karşılığını vermez: kurulacak bir sunucu, bakımı yapılacak bir yazılım ve okunacak bir dashboard ortaya çıkar, ama ölçülecek anlamlı bir trend yoktur.

Eşiği geçtiğinizi gösteren şey cihaz sayısı değildir. Şu üçünden biri varsa geçmişsinizdir: birden fazla lokasyon, kiralık bir hat (yani kapasitesi için para ödediğiniz ve dolduğunda büyütmeniz gereken bir kaynak), ya da kesintiyi kullanıcıdan öğreniyor olmanız. Üçüncüsü en net göstergedir.

SNMP Nasıl Çalışır? Yönetici, Ajan ve Poll Mekanizması

Neyi çözdüğünü gördük; şimdi nasıl çözdüğüne geçelim. SNMP iki taraflı çalışır: bir tarafta soruyu soran yönetici, diğer tarafta cevabı veren ajan vardır. Bu iki rolü ayırmak, protokolle ilgili kafa karışıklığının büyük kısmını baştan siler.

Girişte kurduğumuz panele dönelim. Adresli bir yangın algılama sisteminde duvardaki panel, hatta bağlı her dedektörü adresiyle tek tek yoklar: sırayla sorar, cevabı kaydeder, sıradakine geçer. Panel merkezdir, dedektörler ise yalnızca kendilerine sorulduğunda konuşur. SNMP’nin normal işleyişi birebir budur.

Yönetici ve Ajan: Soran Taraf ile Cevaplayan Taraf

Yönetici (manager), sorguyu üreten taraftır: pratikte bir izleme sunucusudur. Ajan (agent) ise izlenen cihazın üzerinde çalışan yazılımdır. Switch’te, router’da, firewall’da, sunucuda, hatta yazıcıda ve kesintisiz güç kaynağında bir ajan bulunur.

Buradaki ilişki bilinçli olarak asimetriktir ve sebebi güvenliktir: ajan kendiliğinden bağlantı kurmaz, dinler. Cihaz, kendisine sorulmadıkça ağa veri basmaz. Bu tasarım tercihi izlenen tarafın saldırı yüzeyini küçültür, ama bir bedeli vardır ve az sonra o bedeli kapatan mekanizmayı göreceğiz.

Sorgu UDP üzerinden gider ve bu bir tercih değil, gerekliliktir. Bir durum sorgusu tek atımlıktır: cevap gelmezse yeniden sormak, kaybolan paketi kurtarmaya çalışmaktan ucuzdur. Üstelik yüzlerce cihaza saniyeler içinde soru sormanız gerekir; her biri için bağlantı kurup kapatmak protokolün kendisini darboğaza çevirirdi. Taşıma katmanı tercihlerinin ayrıntısını TCP ve UDP farkını anlattığımız yazıda bulabilirsiniz.

Poll: 161 Portunda Düzenli Yoklama

Yöneticinin ajana soru sorması işlemine poll (yoklama) denir ve 161 numaralı UDP portuna gider. İzleme sunucusu belirlediğiniz aralıkla, tipik olarak beş dakikada bir, her cihaza aynı soruları sorar.

Bu tekrar can sıkıcı görünebilir ama değerin kaynağı tam olarak odur. Tek bir ölçüm size bir sayı verir; ardışık iki ölçüm ise fark verir. Bir arayüzün gönderdiği toplam bayt sayısı sürekli artan bir değerdir ve tek başına hiçbir şey söylemez. Beş dakika arayla alınmış iki değerin farkını süreye bölerseniz saniyedeki bant genişliğini elde edersiniz. Grafikteki eğri budur: ham veri değil, iki soru arasındaki fark.

Yukarıdaki saha vakasında olan da tam olarak buydu. Kimse cihaza gidip “şu an dolu musun?” diye sormadı; sistem beş dakikada bir aynı sayacı okudu, farkları biriktirdi ve bir hafta sonra o birikim saat 09.00 ile 10.00 arasında tekrar eden bir tepe olarak göründü.

SNMP Trap Nedir? Cihazın Sormadan Haber Vermesi

Poll düzenlidir, ama düzenli olması aynı zamanda zayıflığıdır. Beş dakikada bir soruyorsanız, sorduktan hemen sonra çöken bir hattı yaklaşık beş dakika sonra öğrenirsiniz. Kritik olaylar için bu gecikme kabul edilemez.

Trap, cihazın sorulmadan kendiliğinden gönderdiği bildirimdir ve 162 numaralı porta düşer. Panelde bunun karşılığı nettir: duman çıktığında dedektör sıranın kendisine gelmesini beklemez, hattı kendisi çeker.

Yön değişimini kaçırmayın, çünkü iki portun ayrı olmasının sebebi budur:

• Poll: yönetici → ajan, hedef port 161. Soruyu yönetici sorar.
• Trap: ajan → yönetici, hedef port 162. Haberi cihaz verir.

Yani 161 ile 162 “iki farklı SNMP portu” değildir; iki farklı konuşma yönüdür. Sunucu tarafında 162’yi dinlemiyorsanız cihazlarınız yıllarca bildirim gönderir ve hiçbiri size ulaşmaz.

Trap’in ne taşıdığını görmek için lab switch’inin kendi kayıt defterine bakmak yeterli. Aşağıdakiler cihazın açılışında ürettiği gerçek olaylar:

Aug 18 12:10:15 TRAPMGR[SNMPCfgTask]: %% Cold Start: Unit: 0
Aug 18 12:09:30 TRAPMGR[trapTask]:    %% Link Up: Vl5
Aug 18 12:09:27 TRAPMGR[trapTask]:    %% Link Up: Gi1/0/3
Aug 18 12:09:24 TRAPMGR[boxs Req]:    %% Temperature state change alarm: Unit Number: 1 Current: Normal, Previous: None
Aug 18 12:09:19 TRAPMGR[trapTask]:    %% Link Down: Vl1

Bu satırların hepsi bir kimsenin sormadığı olaydır. Soğuk başlatma, bir arayüzün ayağa kalkması, sıcaklık durumunun değişmesi: cihaz bunları yaşadığı anda bilir ve bir sonraki yoklamayı beklemesi için hiçbir sebep yoktur.

Bu satırlar cihazın kendi defteri. Peki aynı olay ağda nasıl görünüyor? Switch’e bilerek yanlış bir community string ile sorgu gönderip 162 portunu dinledim; üç denemenin üçünde de bir bildirim düştü. İşte biri, 67 bayt:

0000  30 41 02 01 01 04 06 70 75 62 6c 69 63 a7 34 02  0A.....public.4.
0010  01 02 02 01 00 02 01 00 30 29 30 0e 06 08 2b 06  ........0)0...+.
0020  01 02 01 01 03 00 43 02 5e ad 30 17 06 0a 2b 06  ......C.^.0...+.
0030  01 06 03 01 01 04 01 00 06 09 2b 06 01 06 03 01  ..........+.....
0040  01 05 05                                         ...

Üç ayrıntı bu paketi öğretici yapıyor.

Birincisi, on dördüncü bayttaki a7 değeri. Az sonra göreceğiniz sorgu paketinde bu bayt a0, cevapta a2 olacak. Yani konuşmanın yönü ayrı bir alanda taşınmıyor, doğrudan paketin tipine kodlanmış. Cihazın “bu bir cevap değil, kendiliğimden gönderdiğim bir bildirimdir” demesinin yolu budur.

İkincisi, paketin taşıdığı iki değer. Birincisi 1.3.6.1.2.1.1.3.0, yani cihazın açık kalma süresi: olayın ne zaman olduğunu söylüyor. İkincisi 1.3.6.1.6.3.1.1.4.1.0 ve asıl mesele burada, çünkü bu adresin değeri de bir adres: 1.3.6.1.6.3.1.1.5.5. O numaranın karşılığı “kimlik doğrulama başarısız”.

Bu cümleyi bir kez daha okuyun, çünkü trap’in ne olduğunu tek başına açıklıyor: olayın türü bir cümle değil, bir numaradır. İzleme sunucusu o numarayı kataloğunda arar, karşılığını bulur ve ne yapacağına ona göre karar verir. Metin ayrıştırmaz, sayı eşleştirir. Üç bildirimin açık kalma süreleri de sırasıyla 24237, 24438 ve 24637 çıktı, yani yaklaşık iki saniye arayla; cihaz her denemeyi ayrı ayrı bildirdi.

Üçüncüsü ve en can sıkıcısı yedinci bayt. Evet, public burada da duruyor. Community string yalnızca sizin sorgularınızda değil, cihazın kendiliğinden gönderdiği bildirimlerde de düz metin gidiyor. Yani hiç sorgu yapmasanız bile cihazlarınız o string’i ağa kendi kendine duyurmaya devam eder.

Pratikte doğru kurulum ikisini birlikte kullanır: poll trendi verir, trap olayı verir. Yalnız poll ile çalışırsanız geç haber alırsınız; yalnız trap ile çalışırsanız kapasite planlaması yapamazsınız, çünkü hiçbir şey bozulmadığında trap gelmez ve elinizde tarih boyunca hiçbir veri olmaz.

MIB Nedir? Cihazın Neyi Bildiğinin Kataloğu

Az önceki bildirimde 1.3.6.1.6.3.1.1.5.5 diye bir numara geçti ve ben size onun “kimlik doğrulama başarısız” demek olduğunu söyledim. Peki izleme sunucusu bunu nereden biliyor? Sorunun kapsamı aslında daha geniş: yönetici neyi sorduğunu, ajan da neyin sorulduğunu nereden biliyor? İki tarafın ortak bir sözlüğe ihtiyacı var. O sözlüğün adı MIB.

MIB (Management Information Base), bir cihazdan sorulabilecek bilgilerin standart kataloğudur. İçinde bilgi yoktur; bilginin nerede durduğu yazar. Hangi değerin hangi adreste bulunacağı, tipinin ne olduğu, ne anlama geldiği burada tanımlıdır.

Panelde bunun karşılığı, kurulum sırasında hazırlanan adres listesidir. O listede her dedektörün hangi katta, hangi odada durduğu ve duman mı ısı mı algıladığı yazar. Panel bir cihaza sorduğunda geriye yalnızca bir durum değeri döner; o değeri anlamlı kılan şey, listede karşılığının bulunmasıdır. Liste kaybolsa panel çalışmaya devam eder ama söyledikleri okunamaz hâle gelir.

Eşleşmeyi açıkça yazmakta fayda var, çünkü iki dünyayı birbirine karıştırmak kolay: panelin adres listesi MIB’e, o listedeki tek bir satırın numarası da OID’ye karşılık gelir. Cihazdan dönen sayı ikisinde de aynı işi görür; tek başına anlamsızdır, katalogla birlikte bilgidir.

MIB’in kritik özelliği önceden anlaşılmış olmasıdır. İzleme sunucunuz farklı üreticilerin cihazlarına aynı soruyu sorabiliyorsa, sebebi hepsinin aynı standart kataloğu uyguluyor olmasıdır.

OID Nedir? Katalogdaki Adres

OID (Object Identifier), MIB kataloğundaki tek bir bilginin adresidir. Noktalarla ayrılmış sayılardan oluşur ve hiyerarşiktir: soldan sağa gittikçe daralan bir ağaç.

Sistem tanımını taşıyan standart adres şudur:

1.3.6.1.2.1.1.1.0

Bu dizinin her parçası bir dal: 1.3.6.1 internet ağacının kökü, 2.1 standart yönetim dalı, sonraki 1 sistem grubu, sonraki 1 o gruptaki sistem tanımı nesnesi, sondaki 0 ise o nesnenin tek örneği olduğunu söyler.

Adres hiyerarşik olduğu için tahmin edilebilir. Sistem grubundaki komşu adresler aynı mantıkla dizilir:

1.3.6.1.2.1.1.1.0    sistem tanımı
1.3.6.1.2.1.1.3.0    açık kalma süresi
1.3.6.1.2.1.1.5.0    sistem adı
1.3.6.1.2.1.1.6.0    konum
1.3.6.1.2.1.2.1.0    arayüz sayısı

Lab switch’ine bu adreslerin dördünü sorduğumda çıkan iki sonuç, MIB’i anlatan her yazıda olması gerekirken çoğunda olmayan şeyi gösteriyor. Arayüz sayısı 119 döndü. Cihaz 48 portlu; aradaki fark VLAN arayüzleri, yığın bağlantıları ve mantıksal arayüzlerden geliyor. Yani MIB’den dönen sayı doğrudur ama “port sayısı” değildir; ne anlama geldiğini kataloğun tanımı belirler, sezginiz değil.

İkincisi daha öğretici: sistem adı ve konum alanları boş döndü. Katalogda o adresler var, cihaz da soruyu doğru anlıyor, ama içine kimse bir şey yazmamış. Sahada bu çok yaygındır ve sonucu şudur: izleme panelinizde cihazlar isimsiz görünür, arıza anında hangi kutunun konuştuğunu IP adresinden çıkarmaya çalışırsınız. MIB size bir yer verir; o yeri doldurmak sizin işiniz.

Yangın Paneli Benzetmesi Nerede Kopar?

Her benzetme bir yerde yalan söyler ve nerede söylediğini yazmazsanız okuyucu o yalanı kavramın parçası sanır.

Panel benzetmesi iki yerde kopuyor. Birincisi: paneldeki adres listesi o tesise özeldir, kurulumu yapan firma çıkarır. MIB ise tersine evrenseldir; 1.3.6.1.2.1.1.1.0 adresi dünyadaki her uyumlu cihazda aynı anlama gelir. Standart olmasaydı her cihaz için ayrı bir izleme yazılımı gerekirdi.

İkincisi ve daha önemlisi: yangın panelinin hattı fiziksel olarak ayrıdır, binadaki başka hiçbir sistem o kabloyu kullanmaz. SNMP ise verinizle aynı ağı paylaşır. Panelin hattını dinlemek için binaya girmek gerekir; SNMP trafiğini dinlemek için ağda olmak yeterlidir. Bir sonraki bölümün konusu tam olarak bu fark.

SNMP Sürümleri: v1, v2c ve v3 Farkı

Ortak bir katalog ve iki yönlü bir konuşma kurduk. Ama şu soruyu henüz sormadık: bu soruları sormaya kimin hakkı var?

Protokolün üç sürümü vardır ve aralarındaki fark özellik listesi değil, bu sorunun cevabıdır. v1 ilk sürümdür ve bugün kullanılmasını gerektiren bir sebep yoktur. v2c yaygın olandır, veri tipleri ve toplu sorgulama gibi iyileştirmeler getirmiştir; ama kimlik doğrulama tarafında v1 ile aynı yerde durur. v3 ise bu makalenin asıl konusu olan güvenlik katmanını ekler. Bu sürümün mimarisini Aralık 2002 tarihli RFC 3411, güvenlik modelini aynı tarihli RFC 3414 tanımlar.

SNMP Community String Neden Bir Parola Değildir?

Community string, v1 ve v2c sürümlerinde cihaza erişim için kullanılan metin dizisidir ve yaygın kanının aksine bir parola gibi davranmaz. Parola benzeri tek yanı, bilmeyenin cevap alamamasıdır. Bir parolanın taşıması gereken diğer her özellik eksiktir: karşı tarafa şifrelenmeden gider, her sorguda tekrar gönderilir, ve cevabın içinde bir kez daha geri döner.

Peki bu neden bu kadar önemli? Çünkü sahada bu string genellikle tek ve ortaktır: bütün cihazlarda aynı değer kullanılır. Onu bir kez ele geçiren kişi, o değerin tanımlı olduğu her cihazı sorgulayabilir. Bu tablo tanıdık gelmelidir: aynı kusur şifresiz yönetim protokolünde de aynen vardır ve orada da çözüm protokolü yamamak değil, şifreli olanına geçmek olmuştur.

Lab: Community String’i Pakette Görmek

Buraya kadar iddia ettim; şimdi ölçelim.

Sahada bu konu konuşulduğunda verilen standart cevap şudur: “salt okunur community zaten zararsız, sadece okuyabiliyor.” Deneyin amacı bu cevabın hangi kısmının doğru olduğunu ayırmak. Yönetilebilir bir switch’e salt okunur bir community tanımladım ve snmpwalk gibi hazır bir araç kullanmak yerine isteği elle kurdum, çünkü asıl mesele cevabın kendisi değil paketin içindeki baytlar.

Arayüz sayısını soran istek, başlıklar hariç 43 bayt:

0000  30 29 02 01 01 04 06 70 75 62 6c 69 63 a0 1c 02  0).....public...
0010  04 64 c8 5a 35 02 01 00 02 01 00 30 0e 30 0c 06  .d.Z5......0.0..
0020  08 2b 06 01 02 01 02 01 00 05 00                 .+.........

Sağdaki sütuna bakın. Yedinci bayttan itibaren public yazıyor. Bu bir şifre çözümü değil, bir kod çözme işlemi de değil: string paketin içinde olduğu gibi, düz metin olarak duruyor. Ortadaki 2b 06 01 02 01 02 01 00 dizisi ise sorduğum adresin ta kendisi, yani hangi bilgiyi istediğim de açıkta.

Cihazın cevabı:

0000  30 2a 02 01 01 04 06 70 75 62 6c 69 63 a2 1d 02  0*.....public...
0010  04 64 c8 5a 35 02 01 00 02 01 00 30 0f 30 0d 06  .d.Z5......0.0..
0020  08 2b 06 01 02 01 02 01 00 02 01 77              .+.........w

Sondaki 02 01 77 beklenen cevap: bir tam sayı, değeri 0x77, yani 119. Ama asıl öğretici satır o değil, yedinci bayt. public cevapta da düz metin duruyor. Yani hattı dinleyen birinin community string’i öğrenmek için sorgu anını yakalaması bile gerekmez; cihazın herhangi bir cevabı yeterlidir.

Bir ölçüm daha aldım ve o daha rahatsız edici. Sistem tanımını sorduğumda cihaz bana tam model adını ve yazılım sürümünü düz metin olarak döndü. Bu metni burada maskeliyorum, ve maskeleme sebebim tam olarak sizin de önemsemeniz gereken sebep: bir saldırgan için model ve sürüm bilgisi, hangi açığın işe yarayacağını söyleyen ilk veridir. Açık community string yalnızca “okuma” vermez; cihazın kimliğini verir.

Community string’i yalnız izleme sunucusunun adresine bağlamak bu açığı daraltır ama kapatmaz: switch başka adreslerden gelen sorguya artık cevap vermez, hattı dinleyen biri ise izleme sunucusunun sorgularından string’i yine okur. Bu kısıtın lab switch’indeki öncesini ve sonrasını switch sıkılaştırma yazımızda ölçtüm.

Şimdi zıt vakayı kuralım.

SNMPv3 ile Aynı Sorgu Nasıl Görünür?

SNMPv3, community string’i tamamen kaldırır ve yerine kullanıcı adı, kimlik doğrulama ve şifreleme getirir. Aynı switch’e bir v3 kullanıcısı tanımlayıp aynı soruyu sordum. İstemciyi yine elle yazdım, çünkü karşılaştırmanın anlamlı olması için iki tarafın da aynı koşullarda ölçülmesi gerekiyordu.

Önce sürecin nasıl işlediğine bakalım, çünkü v3’ün mekanizması “şifreleme açık” cümlesinden ibaret değil.

1. Keşif. İstemci önce kimliksiz bir istek gönderir; cihaz kendi motor kimliğini, açılış sayısını ve çalışma süresini bildirir. Bu adım kimlik doğrulamasız yapılır ve dürüst olmak gerekirse v3’ün yumuşak karnıdır: hattı dinleyen biri en azından cihazın var olduğunu ve ne zamandır açık olduğunu öğrenir.
2. Anahtar türetme. Parola doğrudan kullanılmaz. Parola önce tekrarlanarak uzun bir tampona yayılır, hash’i alınır, sonra o hash cihazın motor kimliğiyle birleştirilip yeniden özetlenir. Sonuç, yalnızca o cihaz için geçerli bir anahtardır.
3. İmzalama ve şifreleme. Sorgu gövdesi türetilmiş anahtarla şifrelenir, mesajın tamamı ayrı bir anahtarla imzalanır.

İkinci adımın sonucunu ölçmek, v3’ü anlatmanın en hızlı yolu. İstemcimin parolalardan türettiği kimlik doğrulama anahtarı şuydu:

99e4f6a753f99ab77f6784608e28d89dbab58731

Aynı anda switch’in kendi yapılandırmasına baktığımda, cihazın o kullanıcı için sakladığı değer birebir aynıydı. İki taraf da aynı anahtara bağımsız olarak ulaştı, çünkü ikisi de aynı parolayı aynı yöntemle işledi. Buradan çıkan sonuç v3’ün tasarımının özeti: parola hiçbir zaman ağa çıkmaz ve cihazda da saklanmaz. Saklanan şey ondan türetilmiş, başka cihazda işe yaramayan bir anahtardır.

Gönderilen v3 isteği 131 bayt. Kritik kısımlar:

0030  0b 73 65 72 63 65 69 7a 6c 65 6d 65 04 0c 4e ed  .serceizleme..N.
0040  aa 9d d8 f1 f4 a2 c9 96 73 c9 04 08 c0 f2 fa ed  ........s.......
0050  c9 bc a5 0a 04 2d a8 8b 18 0e 55 9e 7d 09 14 3f  .....-....U.}..?
0060  a2 38 38 c6 b2 21 1f 96 b0 4d a4 fd 3b 4a 3e 86  .88..!...M..;J>.

İki şey birden görünüyor ve ikisi de önemli.

Birincisi: kullanıcı adı açık metin. sistemkusuizleme pakette olduğu gibi duruyor. Bu bir kusur değil tasarım gereği, çünkü karşı taraf hangi kullanıcının anahtarıyla doğrulama yapacağını bilmek zorunda. v3 kullanıcı adını gizlemez; parolayı gizler. İki parolanın da pakette hiçbir biçimde bulunmadığını programatik olarak doğruladım.

İkincisi: 0x50 ofsetinden sonra başlayan bloğun tamamı anlamsız. Orası şifrelenmiş sorgu gövdesi. v2c isteğinde açıkça okuduğumuz adres dizisi burada yok, çünkü sorunun kendisi de şifreli. Cihazın cevabı da aynı şekilde geldi: 173 bayt, içinde okunabilir tek bir alan yok. Model adı ancak türetilmiş anahtarla çözdükten sonra ortaya çıktı.

Şimdi ikisini yan yana koyalım, çünkü asıl ders farkın kendisinde değil, farkın nereden doğduğunda:

Tek örnek bilgi verir, iki zıt örnek ayrım verir. Buradaki ayrım şu: v2c ile v3 arasındaki fark “şifreleme eklenmiş olması” değil, kimliğin ne olduğunun değişmesidir. v2c’de kimlik bir metindir, dolayısıyla kopyalanabilir. v3’te kimlik bir anahtardır ve o anahtar cihaza bağlıdır; kopyalasanız bile başka cihazda çalışmaz.

Syslog ve SNMP Farkı: Ölçmek ile Anlatmak

v3 ile sorunun güvenlik tarafını kapattık. Ama SNMP ne kadar iyi yapılandırılırsa yapılandırılsın cevaplayamadığı bir soru sınıfı var: sayı, olayın hikâyesini anlatmaz. İşlemcinin yüzde 80’de olduğunu SNMP söyler; hangi oturumun başarısız olduğunu söylemez.

Syslog, cihazın olay ürettikçe merkezî bir sunucuya metin satırı göndermesidir. Yönü trap ile aynıdır, yani cihaz sorulmadan konuşur. Farkı yapısındadır.

Panelde bu ayrım fiziksel olarak vardır: adresli alarm sinyali önceden numaralanmış bir koddur, panelin bastığı olay defteri ise cümlelerden oluşur. İkisi de aynı olayı bildirir, biri makine için biri insan için.

Aynı Olay İki Kanaldan Nasıl Görünür?

Lab switch’inin kendi kayıtlarından bir satır:

<189> Aug 18 12:09:19 192.168.1.2-1 TRAPMGR[trapTask]: traputil.c(735) 221 %% Link Down: Vl1

Baştaki <189> süs değil: syslog’un öncelik alanıdır ve mesajın hangi kaynaktan geldiğini ve ne kadar acil olduğunu tek bir sayıya sıkıştırır. Bu sayının nasıl çözüldüğünü, sekiz önem derecesini ve protokolün neyi garanti etmediğini Syslog protokolü rehberimizde ele alıyoruz; burada bizi ilgilendiren, satırın geri kalanının cümle olması.

Aynı olayın trap tarafında ne taşıdığını yukarıda ölçtüm: bir metin satırı değil, 1.3.6.1.6.3.1.1.5.5 gibi önceden tanımlanmış bir numara ve ona bağlı değerler. İkisini yan yana koyunca fark şuna dönüşür:

• Trap makine tarafından eşleştirilebilir. Belirli bir OID geldiğinde belirli bir aksiyon tetiklemek kolaydır, çünkü kod sabittir.
• Syslog insan tarafından okunabilir. “Hangi arayüz, ne zaman, hangi süreçte?” bilgisi cümlenin içindedir ve arıza incelemesinde okuduğunuz şey budur.

Doğru kurulum ikisini de toplar. Türkiye’de syslog’un ayrıca hukuki bir tarafı var: 5651 sayılı kanunun istediği log arşivinin omurgası pratikte bu akıştır, konunun ayrıntısını 5651 log yönetimi rehberimizde ele alıyoruz.

En yaygın hata ikisini kurup sahipsiz bırakmaktır. Bildirimler kurulur, herkese gider, kimse bakmaz. Bir yıl sonra alarm sesi gürültüye dönüşür ve gerçek olay kalabalığın içinde kaybolur.

Sahada SNMP: Kurulum Sırası ve Teşhis

Mekanizmayı ve sürümleri gördük. Geriye bunu gerçek bir ağda kurarken izlenecek sıra kalıyor.

Nereden Başlanır, Hangi Sırayla Açılır?

Sıra önemlidir, çünkü yanlış sırada yapılan kurulum çalışır ama açık kalır.

1. Önce erişimi sınırlayın, sonra protokolü açın. SNMP yalnızca izleme sunucusunun bulunduğu yönetim ağından erişilebilir olmalı. Bunun doğru yeri cihaz yapılandırması değil ağ tasarımıdır; yönetim trafiğini ayrı bir segmentte tutmanın nasıl kurulduğunu VLAN yapılandırmasını anlattığımız yazıda bulabilirsiniz. Sınır cihazında 161 ve 162 portlarının dışarıya kapalı olduğunu ayrıca doğrulayın; firewall kural yönetimi tarafında bu tek satırlık bir iştir ama atlanması pahalıdır.
2. v3 kullanın, v2c’yi geçiş dönemi için bırakın. Cihazların çoğu ikisini aynı anda destekler. Doğru geçiş yolu şudur: önce izleme sunucusunda v3 kullanıcısını tanımlayın, tek bir cihazda doğrulayın, sonra kalanları taşıyın, en sonunda v2c’yi kapatın. Sorun genellikle protokolde değil, eski izleme yazılımının v3 desteğinde çıkar.
3. Salt okunur kalın. Yazma yetkisi SNMP üzerinden verilmemelidir. Cihaz yapılandırması yönetim oturumundan yapılır; şifreli yönetim kanalının nasıl kurulduğunu ayrıca ele aldık.
4. Sistem adı ve konum alanlarını doldurun. Lab ölçümünde bu iki alan boş çıkmıştı ve sahada çoğu cihazda boştur. Doldurulmadığında izleme paneliniz isimsiz kutulardan oluşur.
5. Cihazın saatini doğrulayın. Grafiğin değeri zaman ekseninin doğruluğuna bağlıdır; sapmış bir saat, satürasyonun ne zaman olduğu sorusunu cevaplanamaz hâle getirir. Saat senkronizasyonunu sistemleri izlemeye başlamadan önce kurun.

Cihaz tarafındaki komutlar üreticiye göre değişir, ama mantık aynıdır; switch ve router yapılandırmasının genel çerçevesini ayrı bir rehberde topladık. Bir switch’te v3 kullanıcısını ve trap hedefini tanımlamayı, doğrulamasıyla birlikte switch SNMP yapılandırması yazımızda gösterdik.

Çalıştığını Nasıl Doğrularsınız?

Kurulum bitince “oldu mu?” sorusunun cevabını almadan ilerlemeyin. Üç adım yeterli.

Birincisi, tek bir sorgu atın. İzleme sunucusundan tek bir cihaza tek bir adres sorun. Cevap gelirse yol açıktır. Dikkat edilecek nokta cevabın içeriği değil, gelmiş olmasıdır.

İkincisi, cevabın anlamlı olduğunu kontrol edin. Arayüz sayısı sorduğunuzda dönen değer cihazın büyüklüğüyle uyumlu mu? Lab ölçümünde bu değer 119 çıkmıştı ve fiziksel port sayısından fazlaydı; bu bir hata değil, mantıksal arayüzlerin de sayılmasıydı. Dönen sayıyı yorumlamadan kabul etmeyin.

Üçüncüsü, 162’yi dinlediğinizi doğrulayın. Poll çalışıyor diye trap de çalışıyor sanmayın; ikisi ayrı yönlerdir ve ayrı ayrı bozulurlar.

Sık Yapılan Hatalar

Yanlış community string sessizce düşer, ve bu teşhisi zorlaştırır. Bunu labda ayrıca ölçtüm: cihaza bilerek yanlış bir string ile sorgu gönderdiğimde hiçbir cevap gelmedi. Hata mesajı yok, ret yok, açıklama yok. Sonucu şu: elinizdeki tabloda “string yanlış”, “cihaz kapalı”, “araya firewall giriyor” ve “SNMP hiç açılmamış” durumlarının dördü de aynı görünür. Teşhis ederken bu dört ihtimali ayırmanın tek yolu, birini birine değiştirip tekrar denemektir.

Ama burada ince bir nokta var ve trap ölçümü tam olarak onu gösteriyor: olay aslında sessiz değil, yalnızca yanlış tarafa sessiz. Sorguyu gönderen taraf hiçbir şey duymazken, cihaz aynı anda izleme sunucusuna bir kimlik doğrulama hatası bildirimi yolluyor. Yani başarısız denemeler görünürdür; ama yalnızca 162 portunu dinleyen taraf için görünürdür. Trap toplamanın güvenlik tarafındaki en somut karşılığı budur: yanlış community ile yapılan yoklama denemelerini ancak bu kanal size söyler.

Cihaz varsayılan olarak açık gelmiyor olabilir, ama bu sizi rahatlatmasın. Lab switch’ine ilk denememi hiçbir yapılandırma yapmadan, en bilinen varsayılan string ile attım ve cevap gelmedi; cihaz kutudan SNMP kapalı geliyordu. Yaygın olarak tekrarlanan “her switch varsayılan olarak açık gelir” cümlesi bu cihazda doğru değil.

Ama buradan çıkan sonuç “risk yok” değil: risk cihazın varsayılanında değil, siz SNMP’yi açarken seçtiğiniz stringde ve onun ağda taşınma biçiminde. Ölçüm bunu zaten gösterdi, seçtiğiniz string ne olursa olsun v2c ile düz metin gidiyor.

Aynı string’i her cihazda kullanmak. Tek bir dinleme, bütün envanteri açar.

Beş dakikalık aralığı her metrik için doğru sanmak. Kapasite trendi için uygundur, ama saniyeler süren bir tepe bu aralıkta görünmez. Ortalama, kısa süreli doygunluğu gizler.

Trap kurup kimseye atamamak. Bildirimin gittiği yer bir posta kutusu değil, bir kişi ya da nöbet listesi olmalıdır.

Sonuç: SNMP ile Kanaatin Yerini Ölçüm Alır

SNMP karmaşık bir protokol değil; iki cümleyle özetlenebilir. Yönetici düzenli aralıklarla sorar, ajan cevap verir. Acil bir durumda ajan sırasını beklemeden kendi haber verir. Geri kalan her şey bu iki cümlenin ayrıntısıdır: MIB iki tarafın neyi konuştuğunu, OID hangi adresi sorduğunuzu, sürüm numarası ise sormaya kimin hakkı olduğunu belirler.

Sahadaki asıl kazanç da teknik değil. İzleme kurulmuş bir ağda “internet yavaş” cümlesi bir tartışma başlatmaz; bir grafiğe bakılır, saat aralığı bulunur, sebep aranır. Kanaatin yerini ölçüm aldığı anda sorun çözülmemiş olsa bile çözülebilir hâle gelir.

Bu protokolü ağınızın bütünü içinde nereye oturttuğumuzu kurumsal ağ protokolleri rehberimizde toplu olarak ele alıyoruz. Ölçümün araç tarafını, yani toplanan verinin grafiğe ve alarma nasıl dönüştüğünü ise Cacti kurulum rehberimizde işliyoruz; bu makale onun ön koşuluydu. Çok lokasyonlu bir ağda bu kurgunun gerçek bir kurumda nasıl sonuç verdiğini görmek isterseniz izleme altyapısı vaka çalışmamıza göz atabilirsiniz.

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