| SNMP | |
|---|---|
| namn | Enkelt nätverkshanteringsprotokoll |
| Nivå (enligt OSI-modellen ) | Applicerad |
| Familj | UDP |
| Port/ID | 161/ UDP ,162/ UDP |
| Syftet med protokollet | Hantering av nätverksenheter |
| Specifikation | RFC 1155 , RFC 1212 , RFC 1213 , RFC 1157 , RFC 3411 |
| Huvudsakliga implementeringar (klienter) | Inbyggd i alla nätverksoperativsystem |
| Mediafiler på Wikimedia Commons | |
SNMP ( engelska Simple Network Management Protocol - ett enkelt nätverkshanteringsprotokoll) är ett standardinternetprotokoll för hantering av enheter i IP-nätverk baserat på TCP / UDP- arkitekturer . SNMP-aktiverade enheter inkluderar routrar, switchar, servrar, arbetsstationer, skrivare, modemställ och andra. Protokollet används ofta i nätverkshanteringssystem för att övervaka nätverksanslutna enheter för förhållanden som kräver administratörs uppmärksamhet. SNMP definieras av Internet Engineering Task Force (IETF) som en komponent i TCP/IP . Den består av en uppsättning standarder för nätverkshantering, inklusive ett applikationslagerprotokoll, ett databasschema och en uppsättning dataobjekt.
När du använder SNMP övervakar eller hanterar en eller flera administrativa datorer (kallade managers ) en grupp värdar eller enheter i ett datornätverk. Varje hanterat system har ett permanent körande program som kallas en agent som kommunicerar information till chefen via SNMP .
SNMP-hanterade nätverk består av tre nyckelkomponenter:
En hanterad enhet är ett nätverkselement (hårdvara eller programvara) som implementerar ett hanteringsgränssnitt (inte nödvändigtvis SNMP) som tillåter enkelriktad (skrivskyddad) eller dubbelriktad åtkomst till specifik information om elementet. Hanterade enheter delar denna information med chefen. Hanterade enheter kan hänvisa till alla typer av enheter: routrar, åtkomstservrar, switchar, bryggor, hubbar, IP-telefoner, IP-kameror, värddatorer, skrivare, etc.
En agent är en mjukvarumodul för nätverkshantering som finns på en hanterad enhet eller på en enhet som är ansluten till hanteringsgränssnittet för en hanterad enhet. Agenten har lokal kunskap om ledningsinformation och översätter denna information till eller från en SNMP-specifik form (datamediering).
Network Management System ( NMS ) är en applikation som övervakar och kontrollerar hanterade enheter. NMS tillhandahåller huvuddelen av den databehandling som behövs för nätverkshantering. Alla hanterade nätverk kan ha en eller flera NMS.
Eftersom adresserna till enhetsobjekt är definierade i digitalt format är de svåra att komma ihåg. För enkelhetens skull används ledningsinformationsbaser (MIB). MIB beskriver strukturen för hanterad data på ett enhetsdelsystem; de använder ett hierarkiskt namnutrymme som innehåller objektidentifierare (OID). Varje OID består av två delar: ett textnamn och en numerisk SNMP-adress. MIB:er är valfria och spelar en stödjande roll vid översättning av objektnamnet från mänskligt (ord) till SNMP (numeriskt) format. Mycket lik DNS- servrar. Eftersom strukturen för objekt på enheter från olika tillverkare inte stämmer överens är det nästan omöjligt att bestämma de digitala SNMP-adresserna för de erforderliga objekten utan MIB-basen. MIB använder den notation som anges i ASN.1 .
SNMP arbetar på TCP/IP-applikationslagret (lager 7 i OSI-modellen). SNMP-agenten tar emot förfrågningar på UDP-port 161. Hanteraren kan skicka förfrågningar från vilken tillgänglig källport som helst till agentporten. Agentens svar kommer att skickas tillbaka till källporten på managern. Chefen tar emot notiser (Traps och InformRequests) på port 162. Agenten kan generera notiser från vilken tillgänglig port som helst. När du använder TLS eller DTLS tas förfrågningar emot på port 10161 och traps skickas på port 10162.
SNMPv1 specificerar fem grundläggande protokolldataenheter (PDU). Ytterligare två PDU:er, GetBulkRequest och InformRequest, introducerades i SNMPv2 och portades till SNMPv3.
Alla SNMP PDU:er är byggda enligt följande:
| IP-huvud (IP-huvud) | UDP-huvud (UDP-huvud) | version (version) | community (lösenord) | PDU-typ (PDU-typ) | request-id (request id) | felstatus (felstatus) | felindex (felindex) | variabelbindningar (bundna variabler) |
De sju SNMP-protokollutbytesenheterna listas nedan:
En begäran från en chef till ett objekt för att få värdet på en variabel eller en lista med variabler. De nödvändiga variablerna anges i variabelbindningsfältet (delen av värdefältet används inte). Att hämta värdena för den angivna variabeln måste utföras av agenten som en Atomic-operation . Chefen kommer att returneras ett svar med de aktuella värdena.
En begäran från en chef till ett objekt om att ändra en variabel eller lista med variabler. Bundna variabler anges i brödtexten i begäran. Ändringar av alla specificerade variabler måste utföras av agenten som en atomär operation. Ett svar kommer att returneras till chefen med de (nuvarande) nya värdena för variablerna.
En begäran från en chef till ett objekt för att upptäcka tillgängliga variabler och deras värden. Ett svar med tillhörande variabler kommer att returneras till managern för variabeln som är nästa i MIB i lexikografisk ordning . Att kringgå hela agent-MIB kan göras genom att iterativt använda GetNextRequest från OID 0. Tabellrader kan läsas genom att ange kolumn-OID i de associerade variablerna i begäran.
En förbättrad version av GetNextRequest. Begäran från chef till objekt för flera iterationer av GetNextRequest. Ett svar kommer att returneras till chefen med flera associerade variabler som korsas med början med de associerade variablerna i begäran. De PDU-specifika icke-repeterarna och maxupprepningsfälten används för att styra svarets beteende. GetBulkRequest introducerades i SNMPv2.
Returnerar associerade variabler och värden från agenten till chefen för GetRequest, SetRequest, GetNextRequest, GetBulkRequest och InformRequest. Felmeddelanden tillhandahålls av felstatus- och felindexfält.
Denna enhet används som svar på både Get och Set-förfrågningar och kallas GetResponse i SNMPv1.
Asynkront meddelande från agenten till chefen. Inkluderar det aktuella värdet av sysUpTime, ett OID som identifierar fälltypen och valfria associerade variabler. Destinationsadressering för traps bestäms med användning av trapkonfigurationsvariabler i MIB. Trappmeddelandeformatet har ändrats till SNMPv2 och PDU har bytt namn till SNMPv2-Trap.
Asynkront meddelande från chef till chef eller från agent till chef. Manager-till-manager-aviseringar var redan möjliga i SNMPv1 (med Trap), men SNMP körs vanligtvis på UDP, där meddelandeleverans inte garanteras och inga förlorade paket rapporteras. InformRequest fixar detta genom att skicka tillbaka en bekräftelse på mottagning. Mottagaren svarar med ett svar som upprepar all information från InformRequest. Denna PDU introducerades i SNMPv2.
SNMP version 1 (SNMPv1) är den ursprungliga implementeringen av SNMP-protokollet. SNMPv1 fungerar med protokoll som UDP, IP, CLNS, DDP och IPX. SNMPv1 används flitigt och är de facto nätverkshanteringsprotokollet i Internetgemenskapen.
De första RFC:erna för SNMP, nu känd som SNMPv1, dök upp 1988:
Dessa protokoll har reviderats i följande RFC:er:
Efter en tid ersattes RFC 1156 (MIB-1) av den mer vanliga:
Version 1 har kritiserats för dålig säkerhet. Autentisering av klienter utfördes endast med hjälp av den sk. "gemensam sträng" (gemenskapssträng), faktiskt lösenordet, som överfördes i klartext. Utvecklingen av SNMPv1 på 1980-talet utfördes av en grupp människor som ansåg det officiellt finansierade HEMS/CMIS/CMIP-arbetet från OSI/IETF/NSF-organisationerna som både orealiserbart på dåtidens datorplattformar och potentiellt oanvändbart. SNMP godkändes av tron att det var ett mellanprotokoll som behövdes för att ta steg mot en storskalig utbyggnad av Internet och dess kommersialisering. På den tiden var en autentiserings-/säkerhetsstandard en dröm och omintetgjordes av protokollutvecklingsgrupper.
SNMPv2 ( RFC 1441 - RFC 1452 ) reviderar version 1 och inkluderar förbättringar av prestanda, säkerhet, integritet och kommunikation mellan chefer. Protokollet introducerade GetBulkRequest, ett alternativ till den iterativa användningen av GetNextRequest för att få en stor mängd kontrolldata i en enda begäran. Samtidigt fick den nya sidobaserade SNMPv2-säkerheten aldrig någon utbredd användning, eftersom den av många ansågs vara för komplex.
Gemenskapsbaserad SNMPv2 (SNMPv2c) definieras i RFC 1901 - RFC 1908 . I sin linda var denna version informellt känd som SNMPv1.5. SNMPv2c inkluderar SNMPv2 utan dess kontroversiella säkerhetsmodell; istället används ett enkelt communitybaserat säkerhetsschema från SNMPv1. SNMPv2c har ofta setts som den de facto SNMPv2-standarden, trots att det officiellt bara var en "Draft Standard".
Användarbaserad SNMPv2 (SNMPv2u) definieras i RFC 1909 - RFC 1910 . Detta är i huvudsak en kompromiss som försöker erbjuda större säkerhet än SNMPv1, men utan den extra komplexiteten hos SNMPv2. En variant av denna version, SNMP v2*, kommersialiserades, och själva mekanismen antogs så småningom som ett av de två säkerhetsramverken i SNMP v3.
SNMPv2c har nu fastställts vara inkompatibel med SNMPv1 inom två nyckelområden: meddelandeformat och protokolloperationer. SNMPv2c-meddelanden använder andra format för header och protocol data unit (PDU) än SNMPv1. Dessutom använder SNMPv2c två protokolloperationer som inte är definierade i SNMPv1. Dessutom definierar RFC 2576 två möjliga samexistensstrategier för SNMPv1/v2c: proxyagenter och tvåspråkiga nätverkshanteringssystem.
ProxyagenterEn SNMPv2- agent kan agera som proxyagent på uppdrag av SNMPv1-hanterade enheter, enligt följande:
Proxyagenten mappar SNMPv1-fällor till SNMPv2-fällor och vidarebefordrar dem sedan till NMS.
Tvåspråkiga nätverkshanteringssystemTvåspråkiga SNMPv2-nätverkshanteringssystem stöder både SNMPv1 och SNMPv2. För att stödja en sådan miljö måste kontrollapplikationen i det tvåspråkiga NMS kommunicera med agenten. NMS analyserar sedan informationen som lagras i den lokala databasen för att avgöra om agenten stöder SNMPv1 eller SNMPv2. Baserat på denna information kommunicerar NMS med agenten med hjälp av lämplig version av SNMP.
Även om SNMPv3 inte medför några ändringar i protokollet förutom att lägga till kryptografisk säkerhet, är det en förbättring genom nya textkonventioner, koncept och terminologi.
Säkerhet har varit ett stort problem med SNMP sedan starten. Autentisering i SNMP version 1 och 2 var inte mer än ett lösenord (gemenskapssträng) som skickades i klartext mellan chefen och agenten.
Till skillnad från SNMPv1 och v2, i SNMPv3 innehåller varje meddelande säkerhetsparametrar som är kodade som en oktettsträng. Innebörden av dessa parametrar beror på vilken säkerhetsmodell du använder.
SNMPv3 tillhandahåller viktiga säkerhetsfunktioner:
Sedan 2004 har IETF erkänt SNMPv3 enligt definitionen i RFC 3411 , RFC 3418 (även känd som STD0062) som den nuvarande standardversionen av SNMP. IETF har markerat SNMPv3 som en komplett Internetstandard, vilket är den högsta nivån av RFC-beredskap. Samtidigt anses tidigare versioner vara föråldrade (betecknas som "historiska" - Historiska).
I praktiken stöder SNMP-implementeringar ofta flera versioner: v1, v2c och v3.
SNMP-implementeringar varierar mellan plattformsleverantörer. I vissa fall anses SNMP inte vara tillräckligt seriöst för ett kärnutvecklingsobjekt och är därför bara en valfri funktion. Vissa större hårdvaruleverantörer tenderar att överutvidga sina egna kommandoradsgränssnitt (CLI) och kontrollsystem.
Den till synes enkla trädstrukturen och linjära indexeringen i SNMP är inte alltid väl förstådd inom de interna datastrukturerna som är delar av den underliggande plattformsdesignen. Därför kan bearbetning av SNMP-förfrågningar på vissa datauppsättningar leda till mer CPU-overhead än nödvändigt. Ett exempel på detta problem är stora routingtabeller som BGP och IGP.
Modulära enheter kan dynamiskt öka eller minska sina SNMP-index (även kallade fall) när hårdvara läggs till eller tas bort. Detta används oftast med hårdvara, även om virtuella gränssnitt har samma effekt. Indexvärden tilldelas vanligtvis vid uppstart och förblir oförändrade tills nästa omstart. Hårdvaruindex eller virtuella enheter som läggs till under en aktiv enhet kan tilldelas i slutet av det befintliga intervallet och eventuellt omtilldelas vid nästa omstart.
SNMP i sig är bara ett protokoll för att samla in och organisera information. De flesta SNMP-implementerande verktygssatser erbjuder någon form av upptäcktsmekanism (en standardiserad samling av data som är gemensam för de flesta plattformar och enheter) för att få en ny användare eller artist vid start. En av dessa funktioner är ofta en form av automatisk konfiguration, där nya enheter som upptäcks i nätverket automatiskt pollas. I fallet med SNMPv1 och SNMPv2c är detta en säkerhetsrisk eftersom SNMP-läsgemenskaperna kommer att sändas i klartext på målenheten. Även om säkerhetskraven varierar från organisation till organisation, bör försiktighet iakttas när du använder den här funktionen, särskilt i miljöer som datacenter för blandade hyresgäster, servervärdanläggningar och liknande miljöer.
snmpset och starta om Cisco as53xx
| URI- scheman | |
|---|---|
| Officiell | |
| inofficiell | |
| Grundläggande TCP / IP-protokoll efter lager av OSI-modellen | |
|---|---|
| Fysisk | |
| kanaliserad | |
| nätverk | |
| Transport | |
| session | |
| Representation | |
| Applicerad | |
| Annat ansökt | |
| Lista över TCP- och UDP-portar | |