| SNMP | |
|---|---|
| Név | Egyszerű hálózatkezelési protokoll |
| Szint ( az OSI modell szerint ) | Alkalmazott |
| Család | UDP |
| Port/ID | 161/ UDP ,162/ UDP |
| A protokoll célja | Hálózati eszközkezelés |
| Leírás | RFC 1155 , RFC 1212 , RFC 1213 , RFC 1157 , RFC 3411 |
| Főbb megvalósítások (kliensek) | Minden hálózati operációs rendszerbe beépítve |
| Médiafájlok a Wikimedia Commons oldalon | |
Az SNMP ( angolul Simple Network Management Protocol – egy egyszerű hálózatkezelési protokoll) egy szabványos internetes protokoll IP-hálózatok eszközeinek TCP / UDP architektúrákon alapuló kezelésére . Az SNMP-képes eszközök közé tartoznak az útválasztók, kapcsolók, szerverek, munkaállomások, nyomtatók, modem állványok és mások. A protokollt általánosan használják a hálózatfelügyeleti rendszerekben a hálózatra csatlakoztatott eszközök figyelésére olyan állapotok esetén, amelyek rendszergazdai figyelmet igényelnek. Az SNMP-t az Internet Engineering Task Force (IETF) határozza meg a TCP/IP összetevőjeként . Hálózatkezelési szabványok készletéből áll, beleértve egy alkalmazási réteg protokollt, egy adatbázissémát és egy adatobjektumkészletet.
SNMP használatakor egy vagy több adminisztratív számítógép (úgynevezett menedzser ) figyeli vagy kezeli a számítógépes hálózaton lévő gazdagépek vagy eszközök csoportját. Minden felügyelt rendszernek van egy állandóan futó programja, az úgynevezett ügynök , amely SNMP-n keresztül továbbítja az információkat a menedzsernek .
Az SNMP által felügyelt hálózatok három fő összetevőből állnak:
A felügyelt eszköz egy hálózati elem (hardver vagy szoftver), amely olyan felügyeleti interfészt (nem feltétlenül SNMP-t) valósít meg, amely lehetővé teszi az egyirányú (csak olvasási) vagy kétirányú hozzáférést az elemre vonatkozó meghatározott információkhoz. A felügyelt eszközök megosztják ezeket az információkat a kezelővel. A felügyelt eszközök bármilyen eszközre vonatkozhatnak: útválasztók, hozzáférési szerverek, kapcsolók, hidak, hubok, IP-telefonok, IP-kamerák, gazdagépek, nyomtatók stb.
Az ügynök egy hálózatfelügyeleti szoftvermodul, amely egy felügyelt eszközön vagy egy felügyelt eszköz felügyeleti interfészéhez csatlakoztatott eszközön található. Az ügynök helyi ismeretekkel rendelkezik a felügyeleti információkról, és lefordítja ezeket az információkat SNMP-specifikus formára vagy onnan (adatközvetítés).
A Network Management System ( NMS ) egy olyan alkalmazás, amely felügyeli és vezérli a felügyelt eszközöket. Az NMS biztosítja a hálózatkezeléshez szükséges adatfeldolgozás nagy részét. Bármely felügyelt hálózatnak egy vagy több NMS-je lehet.
Mivel az eszközobjektumok címei digitális formátumban vannak meghatározva, nehéz megjegyezni őket. Az egyszerűség kedvéért menedzsment információs bázisokat (MIB) használnak. A MIB-k leírják a felügyelt adatok szerkezetét egy eszközalrendszeren; objektumazonosítókat (OID) tartalmazó hierarchikus névteret használnak. Minden OID két részből áll: egy szöveges névből és egy numerikus SNMP-címből. A MIB-k nem kötelezőek, és támogató szerepet játszanak az objektum nevének emberi (szó) formátumról SNMP (numerikus) formátumra történő fordításában. Nagyon hasonlít a DNS szerverekhez. Mivel a különböző gyártóktól származó eszközökön lévő objektumok szerkezete nem egyezik, szinte lehetetlen meghatározni a szükséges objektumok digitális SNMP-címét a MIB-bázis nélkül. A MIB-ek az ASN.1 -ben meghatározott jelölést használják .
Az SNMP a TCP/IP alkalmazásrétegen működik (az OSI modell 7. rétege). Az SNMP-ügynök a 161-es UDP-porton fogadja a kéréseket. A menedzser bármely elérhető forrásportról küldhet kéréseket az ügynökportra. Az ügynök válaszát a rendszer visszaküldi a kezelő forrásportjára. A menedzser a 162-es porton kap értesítéseket (Traps és InformRequests). Az ügynök bármely elérhető portról generálhat értesítéseket. Ha TLS -t vagy DTLS -t használ , a kérések az 10161-es porton érkeznek, a csapdák pedig az 10162-es porton kerülnek elküldésre.
Az SNMPv1 öt alapvető protokolladat-egységet (PDU) határoz meg. Két további PDU, a GetBulkRequest és az InformRequest került be az SNMPv2-be, és portolták át az SNMPv3-ra.
Minden SNMP PDU a következőképpen épül fel:
| IP-fejléc (IP-fejléc) | UDP-fejléc (UDP-fejléc) | verzió (verzió) | közösség (jelszó) | PDU-típus (PDU-típus) | kérésazonosító (kérelemazonosító) | hibaállapot (hibaállapot) | hibaindex (hibaindex) | változó kötések (kötött változók) |
Az alábbiakban felsoroljuk a hét SNMP protokollcsere-egységet:
Kérelem egy menedzsertől egy objektumhoz egy változó értékének vagy a változók listájának lekérésére. A szükséges változók a Változókötések mezőben vannak megadva (az értékek mező szakasza nem használatos). A megadott változó értékeinek lekérését az ügynöknek Atomic műveletként kell végrehajtania . A menedzser egy választ kap vissza az aktuális értékekkel.
Kérelem egy menedzsertől egy objektumhoz egy változó vagy változólista módosítására. A kötött változók a kérés törzsében vannak megadva. Az összes megadott változó módosítását az ügynöknek atomi műveletként kell végrehajtania. A válasz visszaküldésre kerül a menedzsernek a változók (aktuális) új értékeivel.
Kérelem egy menedzsertől egy objektumhoz az elérhető változók és értékük felderítésére. A kapcsolódó változókat tartalmazó választ visszaküldi a menedzsernek a MIB-ben lexikográfiai sorrendben következő változóhoz . A teljes ügynök MIB megkerülése elvégezhető a GetNextRequest iteratív használatával, a 0 OID-től kezdve. A táblázat sorai olvashatók az oszlop OID-k megadásával a kérés kapcsolódó változóiban.
A GetNextRequest továbbfejlesztett változata. Kérelem a kezelőtől az objektumhoz a GetNextRequest többszöri iterációjához. A válasz visszaküldésre kerül a menedzsernek több kapcsolódó változóval, amelyek a kérésben szereplő kapcsolódó változó(k)tól kezdődnek. A PDU-specifikus non-repeaters és max-repetitions mezők a válasz viselkedésének szabályozására szolgálnak. A GetBulkRequest az SNMPv2-ben jelent meg.
A társított változókat és értékeket adja vissza az ügynöktől a GetRequest, SetRequest, GetNextRequest, GetBulkRequest és InformRequest kezelőjének. A hibaértesítéseket a hibaállapot és a hibaindex mezők biztosítják.
Ezt az egységet a Get és a Set kérések válaszaként használják, és az SNMPv1-ben GetResponse-nak hívják.
Aszinkron értesítés az ügynöktől a menedzser felé. Tartalmazza a sysUpTime aktuális értékét, a csapdatípust azonosító OID-t és az opcionális kapcsolódó változókat. A csapdák célcímzése a MIB-ben található trap konfigurációs változók segítségével történik. A csapdaüzenet formátuma SNMPv2-re módosult, a PDU pedig SNMPv2-Trap-re lett átnevezve.
Aszinkron értesítések menedzsertől vezetőig vagy ügynöktől vezetőig. A menedzserek közötti értesítések már az SNMPv1-ben is lehetségesek voltak (Trap használatával), de az SNMP jellemzően UDP-n fut, ahol az üzenetek kézbesítése nem garantált, és nincs jelentés az elveszett csomagokról. Az InformRequest ezt az átvételi elismervény visszaküldésével javítja ki. A fogadó válaszul válaszol, amely megismétli az InformRequest összes információt. Ezt a PDU-t az SNMPv2-ben vezették be.
Az SNMP 1-es verziója (SNMPv1) az SNMP protokoll eredeti megvalósítása. Az SNMPv1 olyan protokollokkal működik, mint az UDP, IP, CLNS, DDP és IPX. Az SNMPv1 széles körben használatos, és ez a de facto hálózatkezelési protokoll az internetes közösségben.
Az első RFC-k az SNMP-hez, mai nevén SNMPv1, 1988-ban jelentek meg:
Ezeket a protokollokat a következő RFC-k módosították:
Egy idő után az RFC 1156 (MIB-1) helyett a gyakrabban használt:
Az 1-es verziót bírálták a gyenge biztonság miatt. Az ügyfelek hitelesítése kizárólag az ún. "közös karakterlánc" (közösségi sztring), valójában a jelszó, amelyet tisztán továbbítottak. Az SNMPv1 fejlesztését az 1980-as években egy olyan embercsoport végezte, akik az OSI/IETF/NSF szervezetek hivatalosan finanszírozott HEMS/CMIS/CMIP munkáját egyszerre megvalósíthatatlannak és potenciálisan kivitelezhetetlennek tartották a korabeli számítástechnikai platformokon. Az SNMP-t abból a meggyőződésből hagyták jóvá, hogy ez egy köztes protokoll, amely szükséges ahhoz, hogy lépéseket tegyenek az internet nagyarányú kiépítése és kereskedelmi forgalomba hozatala felé. Abban az időben a hitelesítési/biztonsági szabvány álom volt, és a protokollfejlesztő csoportok meghiúsították.
Az SNMPv2 ( RFC 1441 – RFC 1452 ) felülvizsgálja az 1-es verziót, és javítja a teljesítményt, a biztonságot, az adatvédelmet és a vezetők közötti kommunikációt. A protokoll bevezette a GetBulkRequest-et, a GetNextRequest iteratív használatának alternatíváját, amellyel nagy mennyiségű vezérlőadatot kaphat egyetlen kérelemben. Ugyanakkor az új SNMPv2 oldalalapú biztonság soha nem terjedt el széles körben, mivel sokak szerint túl bonyolult.
A közösségi alapú SNMPv2-t (SNMPv2c) az RFC 1901 - RFC 1908 határozza meg . Gyerekcipőjében ez a verzió informálisan SNMPv1.5 néven volt ismert. Az SNMPv2c tartalmazza az SNMPv2-t a vitatott biztonsági modellje nélkül; ehelyett az SNMPv1 egyszerű közösségi alapú biztonsági sémáját használjuk. Az SNMPv2c-t gyakran de facto SNMPv2 szabványnak tekintették, annak ellenére, hogy hivatalosan csak "szabványtervezet" volt.
A felhasználó alapú SNMPv2 (SNMPv2u) az RFC 1909 - RFC 1910 szabványban van meghatározva . Lényegében ez egy kompromisszum, amely az SNMPv1-nél nagyobb biztonságot próbál kínálni, de az SNMPv2 bonyolultsága nélkül. Ennek a verziónak az egyik változata, az SNMP v2*, kereskedelmi forgalomba került, és magát a mechanizmust végül az SNMP v3 két biztonsági keretrendszere egyikeként fogadták el.
Az SNMPv2c-ről mostanra megállapították, hogy két kulcsfontosságú területen nem kompatibilis az SNMPv1-gyel: az üzenetformátumok és a protokollműveletek. Az SNMPv2c üzenetek eltérő fejléc- és protokolladat-egység- (PDU) formátumokat használnak, mint az SNMPv1. Ezenkívül az SNMPv2c két olyan protokollműveletet használ, amelyek nincsenek definiálva az SNMPv1-ben. Ezenkívül az RFC 2576 két lehetséges SNMPv1/v2c együttélési stratégiát határoz meg: proxy ügynököket és kétnyelvű hálózatkezelő rendszereket.
Meghatalmazott ügynökökAz SNMPv2 ügynök proxy ügynökként működhet az SNMPv1 által felügyelt eszközök nevében, az alábbiak szerint:
A proxy ügynök leképezi az SNMPv1 csapdákat SNMPv2 csapdákra, majd továbbítja azokat az NMS-nek.
Kétnyelvű hálózatkezelő rendszerekA kétnyelvű SNMPv2 hálózatfelügyeleti rendszerek az SNMPv1-et és az SNMPv2-t is támogatják. Egy ilyen környezet támogatásához a kétnyelvű NMS-ben lévő vezérlőalkalmazásnak kommunikálnia kell az ügynökkel. Az NMS ezután elemzi a helyi adatbázisban tárolt információkat, hogy megállapítsa, hogy az ügynök támogatja-e az SNMPv1 vagy SNMPv2 szabványt. Ezen információk alapján az NMS az SNMP megfelelő verzióját használva kommunikál az ügynökkel.
Noha az SNMPv3 a kriptográfiai biztonság növelésén kívül nem hoz semmilyen változtatást a protokollban, az új szövegkonvenciók, fogalmak és terminológia révén előrelépést jelent.
A biztonság a kezdetek óta nagy probléma az SNMP-vel kapcsolatban. Az SNMP 1-es és 2-es verziójában a hitelesítés nem volt több, mint egy jelszó (közösségi karakterlánc), amelyet tiszta szövegben küldtek el a menedzser és az ügynök között.
Az SNMPv1-től és a v2-től eltérően az SNMPv3-ban minden üzenet biztonsági paramétereket tartalmaz, amelyek oktett karakterláncként vannak kódolva. Ezeknek a paramétereknek a jelentése a használt biztonsági modelltől függ.
Az SNMPv3 fontos biztonsági funkciókat kínál:
2004 óta az IETF az RFC 3411 , RFC 3418 (más néven STD0062) szabványban meghatározott SNMPv3-at az SNMP jelenlegi szabványos verziójaként ismeri el. Az IETF teljes internetes szabványként jelölte meg az SNMPv3-at, amely az RFC készenlét legmagasabb szintjét jelenti. Ugyanakkor a korábbi verziók elavultnak minősülnek ("történelmi" - Történelmi).
A gyakorlatban az SNMP implementációk gyakran több verziót is támogatnak: v1, v2c és v3.
Az SNMP-megvalósítások platformonként eltérőek. Egyes esetekben az SNMP nem tekinthető elég komolynak egy alapvető fejlesztési elemhez, ezért csak egy opcionális szolgáltatás. Egyes nagyobb hardvergyártók hajlamosak túlságosan kiterjeszteni saját parancssori felületeiket (CLI) és vezérlőrendszereiket.
Az SNMP látszólag egyszerű fastruktúrája és lineáris indexelése nem mindig érthető jól a belső adatstruktúrákban, amelyek az alapul szolgáló platform kialakításának elemei. Ezért az SNMP-kérelmek feldolgozása bizonyos adatkészleteken a szükségesnél több CPU-többlethez vezethet. A probléma egyik példája a nagy útválasztó táblák, például a BGP és az IGP.
A moduláris eszközök dinamikusan növelhetik vagy csökkenthetik SNMP-indexeiket (más néven eseteket), amikor hardvert adnak hozzá vagy eltávolítanak. Ezt leggyakrabban hardverrel használják, bár a virtuális interfészek ugyanazt a hatást fejtik ki. Az indexértékek általában rendszerindításkor kerülnek hozzárendelésre, és a következő újraindításig változatlanok maradnak. Az élő eszköz során hozzáadott hardverindexek vagy virtuális entitások hozzárendelhetők a meglévő tartomány végén, és esetleg a következő újraindításkor újra hozzárendelhetők.
Az SNMP maga csak egy protokoll az információk összegyűjtésére és rendszerezésére. A legtöbb SNMP-megvalósító eszközkészlet kínál valamilyen felderítési mechanizmust (a legtöbb platformon és eszközön közös adatgyűjtemény), hogy az indításkor új felhasználót vagy előadót szerezzenek. Az egyik ilyen funkció gyakran az automatikus konfigurálás egyik formája, amelyben a hálózaton felfedezett új eszközök automatikusan lekérdezésre kerülnek. Az SNMPv1 és SNMPv2c esetében ez biztonsági kockázatot jelent, mivel az SNMP olvasási közösségek tiszta szöveggel kerülnek sugárzásra a céleszközön. Bár a biztonsági követelmények szervezetenként eltérőek, óvatosnak kell lenni ennek a funkciónak a használatakor, különösen olyan környezetekben, mint a vegyes bérlői adatközpontok, szervertárhely-létesítmények és hasonló környezetek.
snmpset , és indítsa újra a Cisco as53xx-et
| URI- sémák | |
|---|---|
| Hivatalos | |
| nem hivatalos | |
| Alapvető TCP / IP protokollok az OSI modell rétegei szerint | |
|---|---|
| Fizikai | |
| csatornázott | |
| hálózat | |
| Szállítás | |
| ülés | |
| Reprezentáció | |
| Alkalmazott | |
| Egyéb alkalmazva | |
| A TCP és UDP portok listája | |