Egyszerű hálózatkezelési protokoll - Simple Network Management Protocol

SNMPv3 STD0062
Kommunikációs protokoll
OSI réteg Alkalmazás
Port (ok) 161, 162 (csapda)
RFC (k) 3411–3418
Biztonságos SNMP
Kommunikációs protokoll
OSI réteg Alkalmazás
Port (ok) 10161, 10162 (Csapda)
RFC (k) 6353
Internet protokoll csomag
Alkalmazási réteg
Szállítási réteg
Internet réteg
Linkréteg

Az egyszerű hálózatkezelési protokoll ( SNMP ) egy internetes szabványos protokoll az IP -hálózatokon lévő felügyelt eszközökről szóló információk gyűjtésére és rendszerezésére , valamint az adatok módosítására, hogy megváltoztassa az eszköz viselkedését. Az SNMP -t jellemzően támogató eszközök közé tartoznak a kábelmodemek, útválasztók, kapcsolók, szerverek, munkaállomások, nyomtatók és egyebek.

Az SNMP -t széles körben használják a hálózatkezelésben a hálózatfigyeléshez . Az SNMP a menedzsment adatokat változók formájában teszi közzé a felügyelt rendszereken, amelyek egy felügyeleti információs bázisba (MIB) szerveződnek, és leírják a rendszer állapotát és konfigurációját. Ezek a változók ezután távolról lekérdezhetők (és bizonyos körülmények között manipulálhatók) az alkalmazások kezelésével.

Az SNMP három jelentős változatát fejlesztették ki és telepítették. Az SNMPv1 a protokoll eredeti változata. Az újabb verziók, az SNMPv2c és az SNMPv3, javítják a teljesítményt, a rugalmasságot és a biztonságot.

Az SNMP az Internet Engineering Task Force (IETF) által meghatározott Internet Protocol Suite része . A hálózatkezelésre vonatkozó szabványkészletből áll , beleértve egy alkalmazásréteg -protokollt, egy adatbázis -sémát és egy adatobjektum -halmazt .

Áttekintés és alapfogalmak

Az SNMP kommunikáció elve

Az SNMP tipikus alkalmazásaiban egy vagy több menedzsernek nevezett adminisztrátori számítógép feladata a számítógépek hálózatában lévő gépek vagy eszközök csoportjának felügyelete vagy kezelése . Minden felügyelt rendszer végrehajt egy ügynök nevű szoftverkomponenst, amely SNMP -n keresztül jelenti az információkat a menedzsernek.

Az SNMP által felügyelt hálózat három kulcskomponensből áll:

A felügyelt eszköz olyan hálózati csomópont, amely SNMP interfészt valósít meg, amely lehetővé teszi az egyirányú (csak olvasható) vagy kétirányú (olvasás és írás) hozzáférést a csomópont-specifikus információkhoz. A felügyelt eszközök csomópont-specifikus információkat cserélnek az NMS-ekkel. A felügyelt eszközök, amelyeket néha hálózati elemeknek is neveznek, bármilyen típusú eszközök lehetnek, beleértve, de nem kizárólagosan, az útválasztókat , hozzáférési kiszolgálókat , kapcsolókat , kábelmodemeket , hidakat , hubokat , IP -telefonokat , IP -videokamerákat , számítógép -gazdagépeket és nyomtatókat .

Az ügynök egy hálózatkezelő szoftver modul, amely egy felügyelt eszközön található. Az ügynök helyi ismeretekkel rendelkezik a menedzsment információkról, és ezeket az információkat lefordítja egy SNMP-specifikus űrlapra.

A hálózatkezelő állomás végrehajtja a felügyelt eszközöket figyelő és vezérlő alkalmazásokat. Az NMS -ek biztosítják a hálózatkezeléshez szükséges feldolgozási és memória erőforrások nagy részét. Egy vagy több új tagállam létezhet bármely felügyelt hálózaton.

Vezetői információs bázis

Fő cikk: Vezetői információs bázis

Az SNMP -ügynökök változóként teszik közzé a felügyelt rendszerek kezelési adatait. A protokoll ezen változók távoli módosításával lehetővé teszi az aktív felügyeleti feladatokat is, például a konfiguráció módosítását. Az SNMP -n keresztül elérhető változók hierarchiákba vannak rendezve. Az SNMP maga nem határozza meg, hogy a felügyelt rendszernek mely változókat kell kínálnia. Inkább az SNMP egy bővíthető konstrukciót használ, amely lehetővé teszi az alkalmazások számára, hogy saját hierarchiájukat határozzák meg. Ezeket a hierarchiákat menedzsment információs bázisként (MIB) írják le . A MIB -k leírják egy eszköz alrendszer felügyeleti adatainak szerkezetét; az objektumazonosítókat (OID) tartalmazó hierarchikus névteret használják . Minden OID azonosít egy változót, amely olvasható vagy beállítható SNMP -n keresztül. A MIB -k a Structure of Management Information 2.0 verzió (SMIv2, RFC 2578 ), az ASN.1 részhalmaza által meghatározott jelölést használják .  

A protokoll részletei

Az SNMP az Internet Protocol Suite alkalmazásrétegében működik . Minden SNMP üzenet a User Datagram Protocol (UDP) protokollon keresztül kerül továbbításra . Az SNMP -ügynök kéréseket fogad a 161 -es UDP -porton . A menedzser kéréseket küldhet bármely elérhető forrásportról az ügynök 161 -es portjára. Az ügynök válaszát visszaküldi a kezelő forrásportjára. A menedzser értesítéseket ( Traps és InformRequests ) kap a 162. porton. Az ügynök bármely elérhető portról generálhat értesítéseket. A Transport Layer Security vagy a Datagram Transport Layer Security együttes használatakor a kérelmek a 10161 -es porton érkeznek, és az értesítések a 10162 -es portra kerülnek.

Az SNMPv1 öt alapvető protokolladat -egységet (PDU) határoz meg . Két másik PDU, a GetBulkRequest és az InformRequest az SNMPv2 -ben, a Report PDU pedig az SNMPv3 -ban lett hozzáadva. Minden SNMP PDU a következőképpen készül:

IP fejléc UDP fejléc változat közösség PDU típusú kérés-azonosító hiba-állapot hibaindex változó kötések

A PDU típusú mező által azonosított hét SNMP PDU típus a következő:

GetRequest
Menedzser-ügynök kérés egy változó vagy változólista értékének lekérésére. A kívánt változókat a változókötések határozzák meg (az értékmező nincs használatban). A megadott változóértékek lekérését az ügynök atomműveletként hajtja végre . A válasz az aktuális értékekkel tér vissza.
SetRequest
Menedzser-ügynök kérés egy változó vagy változólista értékének megváltoztatására. A változó kötések a kérelem törzsében vannak megadva. Az összes megadott változót az ügynök atomműveletként hajtja végre. A válasz a változók (aktuális) új értékeit adja vissza.
GetNextRequest
Menedzser-ügynök kérés az elérhető változók és értékeik felfedezésére. Visszaadja a válasz változó kötelező a lexikografikusan következő változót a MIB. Az ügynök teljes MIB -je végigjárható a GetNextRequest iteratív alkalmazásával, OID 0 -tól kezdődően. A táblázat sorai úgy olvashatók, hogy megadják az OID oszlopokat a kérés változó kötéseiben.
GetBulkRequest
Kezelő -ügynök kérés a GetNextRequest több iterációjára . A GetNextRequest optimalizált változata . Olyan választ ad vissza, amely több változó kötést tartalmaz a kérés változó kötéséből vagy kötéseiből. A PDU-specifikus, nem ismétlő és max. Ismétléses mezők a válasz viselkedésének szabályozására szolgálnak. A GetBulkRequest az SNMPv2 -ben került bevezetésre.
Válasz
A GetRequest , SetRequest , GetNextRequest , GetBulkRequest és InformRequest változókat tartalmazó kötéseket és nyugtázást küld az ügynöktől a menedzsernek . A hibajelentést a hibaállapot és a hibaindex mezők biztosítják. Bár a get -re és a set -re is válaszként használták, ezt a PDU -t GetResponse -nak hívták az SNMPv1 -ben.
Csapda
Aszinkron értesítés az ügynöktől a menedzsernek. Míg más SNMP kommunikációban a menedzser aktívan információt kér az ügynöktől, ezek olyan PDU -k, amelyeket az ügynök küld a menedzsernek anélkül, hogy kifejezetten kérték volna. Az SNMP csapdák lehetővé teszik az ügynök számára, hogy kéretlen SNMP üzenet útján értesítse a felügyeleti állomást a jelentős eseményekről. A csapda PDU -k tartalmazzák az aktuális sysUpTime értéket, a csapda típusát azonosító OID -t és az opcionális változó kötéseket. A csapdák célcímzését egy alkalmazásspecifikus módon határozzák meg, jellemzően a MIB trap konfigurációs változóin keresztül. A csapdaüzenet formátuma megváltozott az SNMPv2-ben, és a PDU-t átnevezték SNMPv2-Trap-ra .
InformRequest
Nyugtázott aszinkron értesítés. Ezt a PDU -t az SNMPv2 -ben vezették be, és eredetileg menedzser -menedzser kommunikációként határozták meg . A későbbi megvalósítások lazították az eredeti definíciót, hogy az ügynök kezelhesse a kommunikációt. A menedzser-menedzser értesítések már lehetségesek voltak az SNMPv1-ben csapdát használva , de mivel az SNMP általában az UDP-n fut, ahol a szállítás nem biztosított, és a leesett csomagokat nem jelentik, a csapda kézbesítése nem volt garantált. Az InformRequest ezt kijavítja, mivel a nyugtát visszaküldik az átvételkor.

Az RFC  1157 meghatározza, hogy az SNMP -megvalósításnak legalább 484 bájt hosszúságú üzenetet kell elfogadnia. A gyakorlatban az SNMP implementációk hosszabb üzeneteket fogadnak el. Ha helyesen hajtják végre, akkor az SNMP üzenetet elvetik, ha az üzenet dekódolása sikertelen, és így figyelmen kívül hagyják a hibásan formázott SNMP kéréseket. A sikeresen dekódolt SNMP kérést ezután a közösségi karakterlánc használatával hitelesítik. Ha a hitelesítés sikertelen, csapda keletkezik, amely jelzi a hitelesítési hibát, és az üzenet elmarad.

Az SNMPv1 és az SNMPv2 közösségeket használ a vezetők és az ügynökök közötti bizalom megteremtésére. A legtöbb ügynök három közösségnevet támogat, egyet-egyet csak olvasható, olvasható és írható. Ez a három közösségi karakterlánc különböző típusú tevékenységeket irányít. A csak olvasható közösség vonatkozik kap kéréseket. Az olvasás-írás közösségi karakterlánc a beállított kérésekre vonatkozik. A csapda közösségi karakterlánc a csapdák fogadására vonatkozik . Az SNMPv3 közösségi karakterláncokat is használ, de lehetővé teszi a biztonságos hitelesítést és kommunikációt az SNMP -kezelő és az ügynök között.

Protokoll változatok

A gyakorlatban az SNMP implementációk gyakran több verziót támogatnak: jellemzően SNMPv1, SNMPv2c és SNMPv3.

1. verzió

Az SNMP 1 -es verziója (SNMPv1) az SNMP protokoll kezdeti megvalósítása. Az SNMPv1 tervezését az 1980 -as években egy együttműködő csoport végezte, akik a hivatalosan szponzorált OSI/IETF/NSF (National Science Foundation) erőfeszítéseket (HEMS/CMIS/CMIP) megvalósíthatatlannak tartották az akkori számítási platformokon, valamint potenciálisan kivitelezhetetlen. Az SNMP -t annak a meggyőződésnek az alapján hagyták jóvá, hogy ez egy ideiglenes protokoll, amely szükséges ahhoz, hogy lépéseket tegyen az Internet széles körű bevezetése és kereskedelmi forgalomba hozatala felé.

Az első megjegyzéskérés (RFC) az SNMP -hez, ma SNMPv1 néven ismert, 1988 -ban jelent meg:

  • RFC  1065-  TCP/IP-alapú internetek kezelési információinak felépítése és azonosítása
  • RFC  1066-  Kezelési információs bázis a TCP/IP-alapú internetek hálózatkezeléséhez
  • RFC  1067  - Egyszerű hálózatkezelési protokoll

1990 -ben ezeket a dokumentumokat felváltotta:

  • RFC  1155-  TCP/IP-alapú internetek kezelési információinak felépítése és azonosítása
  • RFC  1156-  Kezelési információs bázis a TCP/IP-alapú internetek hálózatkezeléséhez
  • RFC  1157  - Egyszerű hálózatkezelési protokoll

1991-ben az RFC  1156-ot (MIB-1) felváltotta a leggyakrabban használt:

  • RFC  1213-  A menedzsment információs bázis (MIB-2) 2. verziója a TCP/IP-alapú internetek hálózatkezeléséhez

Az SNMPv1 -et széles körben használják, és ez a de facto hálózatkezelési protokoll az internetes közösségben.

Az SNMPv1 hordozhatók olyan szállítási rétegprotokollokkal, mint a User Datagram Protocol (UDP), az Internet Protocol (IP), az OSI Connectionless-mode Network Service (CLNS), az AppleTalk Datagram Delivery Protocol (DDP) és a Novell Internetwork Packet Exchange (IPX).

Az 1 -es verziót a rossz biztonság miatt kritizálták. A specifikáció valójában lehetővé teszi az egyéni hitelesítés használatát, de a széles körben használt megvalósítások "csak egy triviális hitelesítési szolgáltatást támogatnak, amely minden SNMP üzenetet hiteles SNMP üzenetként azonosít". Az üzenetek biztonsága tehát attól függ, hogy milyen csatornákon keresztül történik az üzenetek küldése. Például egy szervezet úgy gondolhatja, hogy belső hálózata kellően biztonságos, és nincs szükség titkosításra az SNMP üzeneteihez. Ilyen esetekben a "közösségi név", amelyet egyértelmű szövegben továbbítanak , az eredeti specifikáció ellenére hajlamos a de facto jelszóra.

2. verzió

Az RFC  1441 és az RFC  1452 által meghatározott SNMPv2 felülvizsgálja az 1. verziót, és javításokat tartalmaz a teljesítmény, a biztonság és a menedzserek közötti kommunikáció területén. Bemutatta a GetBulkRequest , az iteratív GetNextRequests alternatíváját nagy mennyiségű felügyeleti adat egyetlen kérésben történő lekérésére. Az SNMPv2-ben bevezetett új, párton alapuló biztonsági rendszert, amelyet sokan túlzottan bonyolultnak tartanak, nem fogadták el széles körben. Az SNMP ezen verziója elérte a javasolt standard érettségi szintet, de a későbbi verziók elavultnak ítélték.

Közösségi alapú Simple Network Management Protocol version 2 vagy SNMPv2c , határozza meg az RFC  1901 - RFC  1908 . SNMPv2c tartalmaz SNMPv2 nélkül a vitatott új SNMP v2 biztonsági modell segítségével helyett az egyszerű közösségi alapú biztonsági rendszere SNMPv1. Ez a verzió egyike azon viszonylag kevés szabványnak, amelyek megfelelnek az IETF Draft Standard lejárati szintjének, és széles körben tekintették a de facto SNMPv2 szabványnak. Később az SNMPv3 részeként újratervezték.

Felhasználó-alapú Simple Network Management Protocol version 2 vagy SNMPv2u , határozza meg az RFC  1909 - RFC  1910 . Ez egy kompromisszum, amely az SNMPv1 -nél nagyobb biztonságot próbál nyújtani, de nem vonja maga után az SNMPv2 magas összetettségét. Ennek egy változata került forgalomba SNMP v2* néven , és a mechanizmust végül az SNMP v3 két biztonsági keretrendszerének egyikeként fogadták el.

64 bites számlálók

Az SNMP 2. verziója bevezeti a 64 bites adatszámlálók lehetőségét. Az 1-es verziót csak 32 bites számlálókkal tervezték, amelyek nulla és 4,29 milliárd közötti egész számot képesek tárolni (pontosan 4 294 967 295). A 32 bites 1-es verziószámláló nem tudja tárolni a 10 gigabites vagy annál nagyobb felület maximális sebességét, másodpercenként bitben kifejezve. Hasonlóképpen, a 32 bites számlálókövetési statisztikák 10 gigabites vagy annál nagyobb felület esetén kevesebb, mint egy perc alatt visszafordulhatnak a nullára, ami rövidebb időintervallum lehet, mint a számláló lekérdezése az aktuális állapot leolvasásához. Ez a fel nem fedezett érték-átváltás miatt elveszett vagy érvénytelen adatokat eredményezhet, valamint a trendkövető adatok sérülését eredményezheti.

A 64 bites 2-es verziószámláló nullától 18,4 quintillion-ig (pontosan 18 446 744 073 709 551 615) képes tárolni az értékeket, így jelenleg nem valószínű, hogy a számláló felborulna a lekérdezési események között. Például az előrejelzések szerint az 1,6 terabites Ethernet 2025-re válik elérhetővé. A 64 bites számláló, amely 1,6 billió bit / másodperc sebességgel növekszik, képes lenne megőrizni az ilyen interfészre vonatkozó információkat anélkül, hogy 133 napig gurulna.

SNMPv1 és SNMPv2c interoperabilitás

Az SNMPv2c két kulcsfontosságú területen nem kompatibilis az SNMPv1 -el: üzenetformátumok és protokollműveletek. Az SNMPv2c üzenetek más fejléc- és protokolladat -egység (PDU) formátumokat használnak, mint az SNMPv1 üzenetek. Az SNMPv2c két protokollműveletet is használ, amelyeket az SNMPv1 nem tartalmaz. Az inkompatibilitás kiküszöbölése érdekében az RFC  3584 két SNMPv1/v2c együttélési stratégiát határoz meg: proxy ügynököket és kétnyelvű hálózatkezelő rendszereket.

Proxy ügynökök

Az SNMPv2 ügynök proxyügynökként működhet az SNMPv1 felügyelt eszközök nevében. Amikor egy SNMPv2 NMS kiad egy SNMPv1 ügynöknek szánt parancsot, akkor azt az SNMPv2 proxy ügynöknek küldi. A proxy ügynök változatlanul továbbítja a Get, GetNextés Setüzeneteket az SNMPv1 ügynöknek. A GetBulk üzeneteket a proxy ügynök üzenetté alakítja, GetNextmajd továbbítja az SNMPv1 ügynöknek. Ezenkívül a proxyügynök fogadja és leképezi az SNMPv1 csapdaüzeneteket az SNMPv2 csapdaüzenetekhez, majd továbbítja azokat az NMS -nek.

Kétnyelvű hálózatkezelő rendszer

A kétnyelvű SNMPv2 hálózatkezelő rendszerek mind az SNMPv1, mind az SNMPv2 protokollt támogatják. A kettős felügyeleti környezet támogatása érdekében a felügyeleti alkalmazás megvizsgálja a helyi adatbázisban tárolt információkat, hogy meghatározza, hogy az ügynök támogatja-e az SNMPv1-et vagy az SNMPv2-t. Az adatbázisban található információk alapján az NMS az SNMP megfelelő verziójával kommunikál az ügynökkel.

3. verzió

Bár az SNMPv3 nem változtat a protokollon a kriptográfiai biztonságon kívül, az új szöveges konvenciók, koncepciók és terminológia miatt nagyon másnak tűnik. A leglátványosabb változás az SNMP biztonságos verziójának meghatározása volt, az SNMP biztonsági és távoli konfigurációs fejlesztéseinek hozzáadásával. A biztonsági szempontokat úgy kezeljük, hogy erős hitelesítést és adattitkosítást kínálunk a magánélet védelme érdekében. Az adminisztrációs szempontból az SNMPv3 két részre összpontosít, nevezetesen az értesítések kezdeményezőire és a proxy továbbítókra. A változtatások megkönnyítik az SNMP entitások távoli konfigurálását és adminisztrációját, valamint a nagyméretű telepítéssel, elszámolással és hibakezeléssel kapcsolatos kérdéseket is.

Jellemzők és fejlesztések:

  • Az SNMP entitások azonosítása a kommunikáció megkönnyítése érdekében csak az ismert SNMP entitások között - Minden SNMP entitás rendelkezik SNMPEngineID nevű azonosítóval, és az SNMP kommunikáció csak akkor lehetséges, ha az SNMP entitás ismeri társa azonosságát. A csapdák és az értesítések kivételek e szabály alól.
  • Biztonsági modellek támogatása - A biztonsági modell definiálhatja a biztonsági házirendet egy adminisztrációs tartományon vagy egy intraneten belül. Az SNMPv3 tartalmazza a felhasználóalapú biztonsági modell (USM) specifikációit.
  • A biztonsági célok meghatározása, ha az üzenet hitelesítési szolgáltatás céljai közé tartozik a következők elleni védelem:
    • Információ módosítása-Védelem néhány jogosulatlan SNMP-egység ellen, amelyek megváltoztatják a meghatalmazott megbízó által generált tranzitüzeneteket .
    • Álarc - Védelem az olyan megbízási kísérletek ellen, amelyek nem engedélyezettek egyes megbízók számára, feltételezve egy másik megbízót, aki rendelkezik a megfelelő jogosultságokkal.
    • Üzenetfolyam módosítása-Védelem az üzenetek rosszindulatú újrarendelése, késleltetése vagy újrajátszása ellen, amelyek befolyásolják a jogosulatlan kezelési műveleteket.
    • Nyilvánosságra hozatal - Védelem az SNMP motorok közötti cserék lehallgatása ellen.
  • Az USM specifikációja - Az USM az alábbi kommunikációs mechanizmusok általános definíciójából áll:
    • Kommunikáció hitelesítés és adatvédelem nélkül (NoAuthNoPriv).
    • Kommunikáció hitelesítéssel és adatvédelem nélkül (AuthNoPriv).
    • Kommunikáció hitelesítéssel és adatvédelemmel (AuthPriv).
  • A különböző hitelesítési és adatvédelmi protokollok meghatározása-Az US5 támogatja az MD5, SHA és HMAC-SHA-2 hitelesítési protokollokat, valamint a CBC_DES és CFB_AES_128 adatvédelmi protokollokat.
  • Felfedezési eljárás meghatározása - Egy adott szállítási címhez és szállítási végpontcímhez tartozó SNMP entitás SNMPEngineID azonosítójának megkeresése.
  • Az időszinkronizálási eljárás meghatározása - Az SNMP entitások közötti hitelesített kommunikáció megkönnyítése.
  • Az SNMP keretrendszer meghatározása MIB - Az SNMP entitás távoli konfigurációjának és adminisztrációjának megkönnyítése.
  • Az USM MIB -k meghatározása - A biztonsági modul távoli konfigurációjának és adminisztrációjának megkönnyítése.
  • A nézeten alapuló beléptetési modell (VACM) MIB-k meghatározása-A hozzáférés-szabályozó modul távoli konfigurációjának és adminisztrációjának megkönnyítése érdekében.

A biztonság a v3 -ig az SNMP egyik legnagyobb gyengesége volt. Az SNMP 1. és 2. verziójának hitelesítése nem jelent mást, mint egy jelszó (közösségi karakterlánc), amelyet világos szövegben küldünk a menedzser és az ügynök között. Minden SNMPv3 üzenet biztonsági paramétereket tartalmaz, amelyeket oktett karakterláncként kódolnak. Ezeknek a biztonsági paramétereknek a jelentése az alkalmazott biztonsági modelltől függ. A v3 biztonsági megközelítése a következőket célozza:

  • Bizalmasság - Csomagok titkosítása , hogy megakadályozzák az illetéktelen forrás általi leskelődést.
  • Integrity - Az üzenet integritása annak biztosítására, hogy a csomag ne legyen manipulálva szállítás közben, beleértve az opcionális csomagvisszajátszási védelmi mechanizmust.
  • Hitelesítés - annak ellenőrzésére, hogy az üzenet érvényes forrásból származik -e.

A v3 meghatározza az USM -et és a VACM -et is, amelyeket később egy szállítási biztonsági modell (TSM) követett, amely támogatta az SNMPv3 -at az SSH -n, és az SNMPv3 -t a TLS -en és a DTLS -en keresztül.

  • Az USM (felhasználói alapú biztonsági modell) hitelesítési és adatvédelmi (titkosítási) funkciókat biztosít, és üzenetszinten működik.
  • A VACM (nézet alapú hozzáférés-vezérlési modell) határozza meg, hogy egy adott megbízónak van-e hozzáférése egy adott MIB objektumhoz, hogy bizonyos funkciókat elvégezzen, és PDU szinten működik.
  • A TSM (Transport Security Model) módszert biztosít az üzenetek hitelesítésére és titkosítására külső biztonsági csatornákon keresztül. Két szállítást, az SSH -t és a TLS/DTLS -t határozták meg, amelyek a TSM specifikációt használják.

2004-től az IETF elismeri Simple Network Management Protocol version 3 által meghatározott RFC  3411 - RFC  3418 (más néven STD0062), mint a jelenlegi standard változat SNMP. Az IETF kijelölte az SNMPv3 -t teljes internetes szabványnak , amely az RFC legmagasabb érettségi szintje . A korábbi verziókat elavultnak tartja (különböző módon "történelmi" vagy "elavult" -ként jelölve).

Végrehajtási kérdések

Sok gyártó nem használja ki teljes mértékben az SNMP hatékony írási képességeit, amelyek lehetővé teszik a hálózati eszközök konfigurálását, részben az SNMPv3 előtti SNMP -verziók biztonsági hiánya miatt, másrészt pedig azért, mert sok eszköz egyszerűen nem konfigurálható egyéni A MIB objektum megváltozik.

Egyes SNMP -értékek (különösen a táblázatos értékek) speciális ismereteket igényelnek a táblázat -indexelési sémákról, és ezek az indexértékek nem feltétlenül következetesek platformonként. Ez korrelációs problémákat okozhat, amikor több olyan eszközről kér le információkat, amelyek esetleg nem használják ugyanazt a táblázatindexelési sémát (például a lemezkihasználási mutatók lekérése, ahol a lemez azonosítója platformonként eltérő.)

Egyes nagy berendezésgyártók hajlamosak túlterjeszteni saját parancssori interfész (CLI) központú konfigurációs és vezérlőrendszereiket.

2002 februárjában a Carnegie Mellon Software Engineering Institute (CM-SEI) Computer Emergency Response Team Coordination Center (CERT-CC) tanácsadót adott ki az SNMPv1-ről, miután az Oulu Egyetem Biztonságos Programozási Csoportja alapos elemzést végzett az SNMP üzenetkezelésről. A legtöbb SNMP -megvalósítás, függetlenül attól, hogy a protokoll melyik verzióját támogatja, ugyanazt a programkódot használja a protokoll -adategységek (PDU) dekódolásához, és a problémákat azonosították. Más problémákat találtunk az SNMP kezelőállomás által kapott SNMP csapdaüzenetek dekódolásával vagy az SNMP ügynök által a hálózati eszközön kapott kérések dekódolásával. Sok gyártónak kellett javításokat kiadnia az SNMP implementációihoz.

Biztonsági vonatkozások

Az SNMP használata a hálózat megtámadására

Mivel az SNMP -t úgy tervezték, hogy a rendszergazdák távolról felügyelhessék és konfigurálhassák a hálózati eszközöket, a hálózatba való behatolásra is használható. A szoftvereszközök jelentős része képes a teljes hálózatot beolvasni SNMP használatával, ezért az olvasási-írási mód konfigurációjában elkövetett hibák érzékenyebbé tehetik a hálózatot a támadásokra.

2001-ben a Cisco olyan információkat tett közzé, amelyek azt jelzik, hogy még csak olvasható módban is a Cisco IOS SNMP implementációja sebezhető a szolgáltatásmegtagadási támadásokkal szemben. Ezeket a biztonsági problémákat IOS frissítéssel lehet kijavítani.

Ha az SNMP -t nem használják hálózatban, akkor le kell tiltani a hálózati eszközökön. Az SNMP csak olvasható mód konfigurálásakor nagy figyelmet kell fordítani a hozzáférés-vezérlés konfigurációjára, és arra, hogy mely IP-címekről fogadják el az SNMP-üzeneteket. Ha az SNMP szervereket IP -címük alapján azonosítják, az SNMP csak ezekre az IP -címekre válaszolhat, és a más IP -címekről érkező SNMP -üzenetek megtagadásra kerülnek. Az IP -cím hamisítása azonban továbbra is biztonsági aggály.

Hitelesítés

Az SNMP különböző változatokban érhető el, mindegyiknek saját biztonsági problémái vannak. Az SNMP v1 jelszavakat tiszta szövegben küld a hálózaton keresztül. Ezért a jelszavak csomagszippantással olvashatók . Az SNMP v2 lehetővé teszi a jelszó kivonatolását az MD5 használatával , de ezt konfigurálni kell. Gyakorlatilag minden hálózatkezelő szoftver támogatja az SNMP v1 -et, de nem feltétlenül az SNMP v2 vagy v3 -at. Az SNMP v2 -t kifejezetten az adatok biztonsága , azaz a hitelesítés , az adatvédelem és az engedélyezés érdekében fejlesztették ki , de csak az SNMP 2c verzió nyerte el az Internet Engineering Task Force (IETF) jóváhagyását , míg a 2u és 2* verziók a biztonság miatt nem szerezték meg az IETF jóváhagyását problémák. Az SNMP v3 az MD5, a Secure Hash Algoritm (SHA) és a kulcsos algoritmusok használatával védelmet nyújt a jogosulatlan adatmódosítás és hamis támadások ellen . Ha magasabb szintű biztonságra van szükség, az adattitkosítási szabvány (DES) opcionálisan használható a titkosítási blokk láncolási módjában. Az SNMP v3 a 12.0 (3) T kiadás óta megvalósult a Cisco IOS rendszeren.

Az SNMPv3 nyers erővel és szótári támadásoknak lehet kitéve a hitelesítési kulcsok vagy a titkosítási kulcsok kitalálása miatt, ha ezeket a kulcsokat rövid (gyenge) jelszavakból vagy a szótárban található jelszavakból állítják elő. Az SNMPv3 lehetővé teszi, hogy véletlenszerűen egyenletesen elosztott titkosítási kulcsokat biztosítson, és titkosítási kulcsokat generáljon a felhasználó által megadott jelszóból. Annak kockázata, hogy a hálózaton keresztül továbbított kivonatértékekből kitalálja a hitelesítési karakterláncokat, az alkalmazott kriptográfiai kivonatfüggvénytől és a kivonatérték hosszától függ. SNMPv3 használja HMAC - SHA-2 hitelesítési protokoll a felhasználó-alapú biztonsági modell (USM). Az SNMP nem használ biztonságosabb kihívás-kézfogás hitelesítési protokollt . Az SNMPv3 (más SNMP protokollverziókhoz hasonlóan) állapot nélküli protokoll , és minimális számú interakcióval lett megtervezve az ügynök és a menedzser között. Így a kihívás-válasz kézfogás bevezetése minden parancsnál olyan terhet róna az ügynökre (és esetleg magára a hálózatra), amelyet a protokolltervezők túlzottnak és elfogadhatatlannak tartanak.

Az összes SNMP verzió biztonsági hiányosságai enyhíthetők az IPsec hitelesítési és titoktartási mechanizmusokkal. Az SNMP biztonságosan hordozható a Datagram Transport Layer Security (DTLS) rendszeren keresztül is.

Sok SNMP -megvalósítás tartalmaz egyfajta automatikus felderítést, amikor egy új hálózati összetevő, például egy kapcsoló vagy útválasztó automatikusan felderül és lekérdezésre kerül. Az SNMPv1 és az SNMPv2c esetében ez egy közösségi karakterláncon keresztül történik, amelyet világos szövegben továbbítanak más eszközökre. A tiszta szövegű jelszavak jelentős biztonsági kockázatot jelentenek. Amint a közösségi karakterlánc ismert a szervezeten kívül, az támadás célpontjává válhat. Annak érdekében, hogy figyelmeztesse a rendszergazdákat a közösségi karakterláncok begyűjtésére tett egyéb kísérletekre, az SNMP konfigurálható úgy, hogy átadja a közösségnév-hitelesítési hibacsapdákat. SNMPv2 használata esetén a probléma elkerülhető, ha engedélyezi a jelszó titkosítását a hálózati eszközök SNMP ügynökein.

A közösségi karakterláncok általános alapértelmezett konfigurációja "nyilvános" az írásvédett hozzáféréshez, és "privát" az írás-íráshoz. A jól ismert alapértelmezések miatt az SNMP vezette a SANS Intézet gyakori alapértelmezett konfigurációs problémáinak listáját, és tizedik lett a SANS Top 10 legkritikusabb internetes biztonsági fenyegetései között 2000-ben. A rendszer- és hálózati rendszergazdák gyakran nem változtatnak ezeken konfigurációk.

Függetlenül attól, hogy TCP -n vagy UDP -n fut, az SNMPv1 és v2 sebezhetőek az IP -hamisító támadásokkal szemben. A hamisítással a támadók megkerülhetik az eszközhozzáférési listákat azokban az ügynökökben, amelyek az SNMP -hozzáférés korlátozására szolgálnak. Az SNMPv3 biztonsági mechanizmusok, például az USM vagy a TSM megakadályozzák a sikeres hamisítást.

RFC hivatkozások

  • RFC  1155 (STD 16)-A TCP/IP-alapú internetek felügyeleti információinak felépítése és azonosítása
  • RFC  1156 (Történelmi) -Kezelési információs bázis a TCP/IP-alapú internetek hálózatkezeléséhez
  • RFC  1157 (történelmi) - Egyszerű hálózatkezelési protokoll (SNMP)
  • RFC  1213 (STD 17) -Kezelési információs bázis a TCP/IP-alapú internet hálózatok kezeléséhez: MIB-II
  • RFC  1452 (Információs) -Együttélés az Internet-szabványú hálózati menedzsment keretrendszer 1. és 2. verziója között (Az RFC  1908 elavult )
  • RFC  1901 (kísérleti) -Bevezetés a közösségi alapú SNMPv2-be
  • RFC  1902 (szabványtervezet) - Az SNMPv2 felügyeleti információi struktúrája ( RFC  2578 elavult )
  • RFC  1908 (szabványkövetés) -Együttélés az internetes szabványú hálózatkezelési keretrendszer 1. és 2. verziója között
  • RFC  2570 (Információs) -Bevezetés az Internet-szabványú hálózatkezelési keretrendszer 3. verziójába (Az RFC  3410 elavult )
  • RFC  2578 (STD 58) - A felügyeleti információk szerkezete, 2. verzió (SMIv2)
  • RFC  3410 (Információs) - Bevezetés és alkalmazhatósági nyilatkozatok az Internet Standard Management Framework számára
  • Az STD 62 a következő RFC -ket tartalmazza:
    • RFC  3411  - Egyszerű architektúra az egyszerű hálózatkezelési protokoll (SNMP) felügyeleti keretek leírásához
    • RFC  3412  - Üzenetfeldolgozás és -küldés az egyszerű hálózatkezelési protokollhoz (SNMP)
    • RFC  3413  - Egyszerű hálózatkezelési protokoll (SNMP) alkalmazások
    • RFC  3414  - User-alapú biztonsági modell (USM) 3. verziójának a Simple Network Management Protocol (SNMPv3)
    • RFC  3415  - Kattintás alapú Access Control Modell (VACM) a Simple Network Management Protocol (SNMP)
    • RFC  3416  - Az egyszerű hálózatkezelési protokoll (SNMP) protokollműveletek 2. verziója
    • RFC  3417  - Szállítási leképezések az egyszerű hálózatkezelési protokollhoz (SNMP)
    • RFC  3418  - Kezelési információs bázis (MIB) az egyszerű hálózatkezelési protokollhoz (SNMP)
  • RFC  3430 (kísérleti) - Egyszerű hálózatkezelési protokoll (SNMP) az átviteli vezérlő protokoll (TCP) felett
  • RFC  3584 (BCP 74) -Együttlét az Internet-szabványú hálózatkezelési keretrendszer 1., 2. és 3. verziója között
  • RFC  3826 (javasolt)-A fejlett titkosítási szabvány (AES) titkosítási algoritmus az SNMP felhasználói alapú biztonsági modellben
  • RFC  4789 (javasolt) - Egyszerű hálózatkezelési protokoll (SNMP) az IEEE 802 hálózatokon keresztül
  • RFC  5343 (STD 78) - Egyszerű hálózatkezelési protokoll (SNMP) kontextus EngineID Discovery
  • RFC  5590 (STD 78) - Az egyszerű hálózatkezelési protokoll (SNMP) szállítási alrendszere
  • RFC  5591 (STD 78) - Közlekedési biztonsági modell az egyszerű hálózatkezelési protokollhoz (SNMP)
  • RFC  5592 (javasolt) - Biztonságos héj szállítási modell az egyszerű hálózatkezelési protokollhoz (SNMP)
  • RFC  5608 (javasolt) -Távoli hitelesítési telefonos felhasználói szolgáltatás (RADIUS) használata az egyszerű hálózatkezelési protokoll (SNMP) szállítási modellekhez.
  • RFC  6353 (STD 78) - Transport Layer Security (TLS) szállítási modell az egyszerű hálózatkezelési protokollhoz (SNMP)
  • RFC  7630 (javasolt) -HMAC-SHA-2 hitelesítési protokoll az SNMPv3 felhasználói alapú biztonsági modelljében (USM)

Lásd még

Hivatkozások

További irodalom

Külső linkek