| SNMP | |
|---|---|
| Navn | Simpel netværksstyringsprotokol |
| Niveau (ifølge OSI-modellen ) | Anvendt |
| Familie | UDP |
| Port/ID | 161/ UDP ,162/ UDP |
| Formål med protokollen | Administration af netværksenheder |
| Specifikation | RFC 1155 , RFC 1212 , RFC 1213 , RFC 1157 , RFC 3411 |
| Vigtigste implementeringer (klienter) | Indbygget i alle netværksoperativsystemer |
| Mediefiler på Wikimedia Commons | |
SNMP ( engelsk Simple Network Management Protocol - en simpel netværksstyringsprotokol) er en standard internetprotokol til styring af enheder på IP-netværk baseret på TCP / UDP -arkitekturer . SNMP-aktiverede enheder omfatter routere, switche, servere, arbejdsstationer, printere, modemstativer og andre. Protokollen bruges almindeligvis i netværksstyringssystemer til at overvåge netværkstilsluttede enheder for forhold, der kræver administratorens opmærksomhed. SNMP er defineret af Internet Engineering Task Force (IETF) som en komponent i TCP/IP . Den består af et sæt standarder for netværksstyring, herunder en applikationslagsprotokol, et databaseskema og et sæt dataobjekter.
Når du bruger SNMP, overvåger eller administrerer en eller flere administrative computere (kaldet managers ) en gruppe værter eller enheder på et computernetværk. Hvert administreret system har et permanent kørende program kaldet en agent , der kommunikerer information til manageren via SNMP .
SNMP-administrerede netværk består af tre nøglekomponenter:
En administreret enhed er et netværkselement (hardware eller software), der implementerer en administrationsgrænseflade (ikke nødvendigvis SNMP), der tillader envejs (skrivebeskyttet) eller tovejsadgang til specifik information om elementet. Administrerede enheder deler disse oplysninger med administratoren. Administrerede enheder kan referere til enhver form for enhed: routere, adgangsservere, switche, broer, hubs, IP-telefoner, IP-kameraer, værtscomputere, printere osv.
En agent er et netværksstyringssoftwaremodul, der er placeret på en administreret enhed eller på en enhed, der er forbundet til administrationsgrænsefladen på en administreret enhed. Agenten har lokal viden om ledelsesinformation og oversætter denne information til eller ud af en SNMP-specifik form (dataformidling).
Network Management System ( NMS ) er et program, der overvåger og kontrollerer administrerede enheder. NMS leverer hovedparten af den databehandling, der er nødvendig for netværksstyring. Ethvert administreret netværk kan have en eller flere NMS'er.
Da adresserne på enhedsobjekter er defineret i digitalt format, er de svære at huske. For nemheds skyld anvendes ledelsesinformationsbaser (MIB'er). MIB'er beskriver strukturen af administrerede data på et enhedsundersystem; de bruger et hierarkisk navneområde, der indeholder objektidentifikatorer (OID'er). Hver OID består af to dele: et tekstnavn og en numerisk SNMP-adresse. MIB'er er valgfrie og spiller en understøttende rolle ved oversættelse af objektnavnet fra human (ord) til SNMP (numerisk) format. Meget lig DNS -servere. Da strukturen af objekter på enheder fra forskellige producenter ikke stemmer overens, er det næsten umuligt at bestemme de digitale SNMP-adresser for de nødvendige objekter uden MIB-basen. MIB'er bruger notationen specificeret i ASN.1 .
SNMP opererer på TCP/IP-applikationslaget (lag 7 af OSI-modellen). SNMP-agenten modtager anmodninger på UDP-port 161. Manageren kan sende anmodninger fra enhver tilgængelig kildeport til agentporten. Agentens svar vil blive sendt tilbage til kildeporten på manageren. Manageren modtager notifikationer (Traps og InformRequests) på port 162. Agenten kan generere notifikationer fra enhver tilgængelig port. Når du bruger TLS eller DTLS , modtages anmodninger på port 10161, og traps sendes på port 10162.
SNMPv1 specificerer fem grundlæggende protokoldataenheder (PDU'er). Yderligere to PDU'er, GetBulkRequest og InformRequest, blev introduceret i SNMPv2 og overført til SNMPv3.
Alle SNMP PDU'er er bygget som følger:
| IP-header (IP-header) | UDP-header (UDP-header) | version (version) | fællesskab (adgangskode) | PDU-type (PDU-type) | request-id (request id) | fejlstatus (fejlstatus) | fejlindeks (fejlindeks) | variable bindinger (bundne variable) |
De syv SNMP-protokoludvekslingsenheder er anført nedenfor:
En anmodning fra en leder til et objekt om at få værdien af en variabel eller en liste over variabler. De nødvendige variabler er angivet i variabelbindingsfeltet (sektionen af værdifeltet bruges ikke). Hentning af værdierne for den specificerede variabel skal udføres af agenten som en atomoperation . Lederen vil få et svar tilbage med de aktuelle værdier.
En anmodning fra en leder til et objekt om at ændre en variabel eller liste over variabler. Bundne variabler er angivet i anmodningens brødtekst. Ændringer af alle specificerede variabler skal udføres af agenten som en atomoperation. Et svar vil blive returneret til lederen med de (nuværende) nye værdier af variablerne.
En anmodning fra en leder til et objekt om at opdage tilgængelige variabler og deres værdier. Et svar med tilknyttede variable vil blive returneret til manageren for den variabel, der er næste i MIB i leksikografisk rækkefølge . Omgåelse af hele agent-MIB kan ske ved iterativt at bruge GetNextRequest startende fra OID 0. Tabelrækker kan læses ved at angive kolonne-OID'er i de tilknyttede variabler i anmodningen.
En forbedret version af GetNextRequest. Anmodning fra leder til objekt for flere iterationer af GetNextRequest. Et svar vil blive returneret til lederen med flere tilknyttede variabler krydset startende med de tilknyttede variabler i anmodningen. De PDU-specifikke ikke-repeatere og max-repetitions-felter bruges til at kontrollere reaktionens adfærd. GetBulkRequest blev introduceret i SNMPv2.
Returnerer tilknyttede variabler og værdier fra agenten til administratoren for GetRequest, SetRequest, GetNextRequest, GetBulkRequest og InformRequest. Fejlmeddelelser leveres af fejlstatus- og fejlindeksfelter.
Denne enhed bruges som svar på både Get- og Set-anmodninger og kaldes GetResponse i SNMPv1.
Asynkron meddelelse fra agenten til lederen. Indeholder den aktuelle værdi af sysUpTime, en OID, der identificerer fældetypen, og valgfrie tilknyttede variabler. Destinationsadressering for traps bestemmes ved hjælp af trap-konfigurationsvariabler i MIB. Trappemeddelelsesformatet er blevet ændret til SNMPv2, og PDU'en er blevet omdøbt til SNMPv2-Trap.
Asynkron besked fra leder til leder eller fra agent til leder. Manager-til-manager-meddelelser var allerede mulige i SNMPv1 (ved hjælp af Trap), men SNMP kører typisk på UDP, hvor meddelelseslevering ikke er garanteret, og ingen mistede pakker rapporteres. InformRequest retter dette ved at sende en kvittering for modtagelsen tilbage. Modtageren svarer med et svar, der gentager alle oplysningerne fra InformRequest. Denne PDU blev introduceret i SNMPv2.
SNMP version 1 (SNMPv1) er den originale implementering af SNMP-protokollen. SNMPv1 fungerer med protokoller som UDP, IP, CLNS, DDP og IPX. SNMPv1 er meget udbredt og er de facto netværksstyringsprotokol i internetsamfundet.
De første RFC'er til SNMP, nu kendt som SNMPv1, dukkede op i 1988:
Disse protokoller er blevet revideret i følgende RFC'er:
Efter nogen tid blev RFC 1156 (MIB-1) erstattet af den mere almindeligt anvendte:
Version 1 er blevet kritiseret for dårlig sikkerhed. Autentificering af klienter blev kun udført ved hjælp af den såkaldte. "fælles streng" (fællesskabsstreng), faktisk adgangskoden, som blev transmitteret i det klare. Udviklingen af SNMPv1 i 1980'erne blev udført af en gruppe mennesker, der betragtede OSI/IETF/NSF-organisationernes officielt finansierede HEMS/CMIS/CMIP-arbejde som både urealiserbart på datidens computerplatforme og potentielt ubrugeligt. SNMP blev godkendt ud fra den tro, at det var en mellemprotokol, der var nødvendig for at tage skridt i retning af storstilet udrulning af internettet og dets kommercialisering. På det tidspunkt var en autentificerings-/sikkerhedsstandard en drøm og blev forpurret af protokoludviklingsgrupper.
SNMPv2 ( RFC 1441 - RFC 1452 ) reviderer version 1 og inkluderer forbedringer i ydeevne, sikkerhed, privatliv og kommunikation mellem ledere. Protokollen introducerede GetBulkRequest, et alternativ til den iterative brug af GetNextRequest for at opnå en stor mængde kontroldata i en enkelt anmodning. Samtidig fik den nye SNMPv2 sidebaserede sikkerhed aldrig udbredt udbredelse, da den af mange blev opfattet som for kompleks.
Fællesskabsbaseret SNMPv2 (SNMPv2c) er defineret i RFC 1901 - RFC 1908 . I sin vorden var denne version uformelt kendt som SNMPv1.5. SNMPv2c inkluderer SNMPv2 uden dens kontroversielle sikkerhedsmodel; i stedet bruges et simpelt fællesskabsbaseret sikkerhedsskema fra SNMPv1. SNMPv2c er ofte blevet set som den de facto SNMPv2 standard, på trods af at det officielt kun var en "Draft Standard".
Brugerbaseret SNMPv2 (SNMPv2u) er defineret i RFC 1909 - RFC 1910 . Grundlæggende er dette et kompromis, der forsøger at tilbyde større sikkerhed end SNMPv1, men uden den ekstra kompleksitet af SNMPv2. En variant af denne version, SNMP v2*, blev kommercialiseret, og selve mekanismen blev til sidst vedtaget som en af de to sikkerhedsrammer i SNMP v3.
SNMPv2c er nu blevet fastslået at være inkompatibel med SNMPv1 på to nøgleområder: meddelelsesformater og protokoloperationer. SNMPv2c-meddelelser bruger andre header- og protokoldataenhedsformater (PDU) end SNMPv1. Desuden bruger SNMPv2c to protokoloperationer, der ikke er defineret i SNMPv1. Derudover definerer RFC 2576 to mulige SNMPv1/v2c-sameksistensstrategier: proxy-agenter og tosprogede netværksadministrationssystemer.
Proxy-agenterEn SNMPv2- agent kan fungere som proxy-agent på vegne af SNMPv1-administrerede enheder, som følger:
Proxyagenten kortlægger SNMPv1-fælder til SNMPv2-fælder og videresender dem derefter til NMS.
Tosprogede netværksstyringssystemerTosprogede SNMPv2-netværksadministrationssystemer understøtter både SNMPv1 og SNMPv2. For at understøtte et sådant miljø skal kontrolapplikationen i det tosprogede NMS kommunikere med agenten. NMS'en analyserer derefter informationen, der er gemt i den lokale database, for at bestemme, om agenten understøtter SNMPv1 eller SNMPv2. Baseret på disse oplysninger kommunikerer NMS med agenten ved hjælp af den relevante version af SNMP.
Selvom SNMPv3 ikke medfører andre ændringer i protokollen end at tilføje kryptografisk sikkerhed, er det en forbedring gennem nye tekstkonventioner, koncepter og terminologi.
Sikkerhed har været et stort problem med SNMP siden starten. Godkendelse i SNMP version 1 og 2 var ikke mere end en adgangskode (fællesskabsstreng), der blev sendt i klartekst mellem manageren og agenten.
I modsætning til SNMPv1 og v2 indeholder hver besked i SNMPv3 sikkerhedsparametre, der er kodet som en oktetstreng. Betydningen af disse parametre afhænger af den sikkerhedsmodel, du bruger.
SNMPv3 giver vigtige sikkerhedsfunktioner:
Siden 2004 har IETF anerkendt SNMPv3 som defineret i RFC 3411 , RFC 3418 (også kendt som STD0062) som den aktuelle standardversion af SNMP. IETF har markeret SNMPv3 som en komplet internetstandard, hvilket er det højeste niveau af RFC-beredskab. Samtidig anses tidligere versioner for at være forældede (benævnt "historiske" - Historiske).
I praksis understøtter SNMP-implementeringer ofte flere versioner: v1, v2c og v3.
SNMP-implementeringer varierer mellem platformsleverandører. I nogle tilfælde anses SNMP ikke for at være seriøs nok til et kerneudviklingselement og er derfor kun en valgfri funktion. Nogle større hardwareleverandører har en tendens til at overudvide deres egne kommandolinjegrænseflader (CLI) og kontrolsystemer.
Den tilsyneladende simple træstruktur og lineære indeksering i SNMP er ikke altid godt forstået inden for de interne datastrukturer, der er elementer i det underliggende platformdesign. Derfor kan behandling af SNMP-anmodninger på visse datasæt føre til mere CPU-overhead end nødvendigt. Et eksempel på dette problem er store routingtabeller såsom BGP og IGP.
Modulære enheder kan dynamisk øge eller formindske deres SNMP-indekser (også kaldet tilfælde), når hardware tilføjes eller fjernes. Dette er mest almindeligt brugt med hardware, selvom virtuelle grænseflader har samme effekt. Indeksværdier tildeles typisk ved opstart og forbliver uændrede indtil næste genstart. Hardwareindekser eller virtuelle entiteter, der tilføjes under en live-enhed, kan tildeles i slutningen af det eksisterende interval og muligvis omtildeles ved næste genstart.
SNMP i sig selv er blot en protokol til indsamling og organisering af information. De fleste SNMP-implementerende værktøjssæt tilbyder en form for opdagelsesmekanisme (en standardiseret samling af data, der er fælles for de fleste platforme og enheder) for at få en ny bruger eller kunstner ved opstart. En af disse funktioner er ofte en form for automatisk konfiguration, hvor nye enheder opdaget på netværket automatisk bliver pollet. I tilfælde af SNMPv1 og SNMPv2c er dette en sikkerhedsrisiko, fordi SNMP-læsefællesskaberne vil blive udsendt i klartekst på målenheden. Selvom sikkerhedskravene varierer fra organisation til organisation, skal der udvises forsigtighed, når du bruger denne funktion, især i miljøer som blandede lejerdatacentre, serverhostingfaciliteter og lignende miljøer.
snmpset og genstart Cisco as53xx
| URI- ordninger | |
|---|---|
| Officiel | |
| uofficiel | |
| Grundlæggende TCP / IP-protokoller efter lag af OSI-modellen | |
|---|---|
| Fysisk | |
| kanaliseret | |
| netværk | |
| Transportere | |
| session | |
| Repræsentation | |
| Anvendt | |
| Andet anvendt | |
| Liste over TCP- og UDP-porte | |