Innen datavitenskap og telekommunikasjon er Simple Network Management Protocol ( SNMP ) en tilkoblingsløs nettverksprotokoll som tilhører Internett-protokollpakken definert av IETF ( Internet Engineering Task Force ). Den opererer på nivå 7 av OSI-modellen , ved å bruke UDP - transportlagprotokoll på portene 161 og 162, noe som gjør det mulig å forenkle konfigurasjon , administrasjon og overvåking ( overvåking ) av enheter koblet i et nettverk (enten de erinterne svitsjnoder som nettverksenheter eller brukerterminalnoder ) , angående alle de aspektene som krever administrative handlinger ( administrasjon ).
SNMP-protokollen forutsetter at administrasjon av en nettverksenhet er mulig gjennom lesing/skriving av elementær informasjon (heretter referert til som "administrerte objekter") som representerer gjeldende konfigurasjon av et system. Det konseptuelle rammeverket definert av IETF for å administrere TCP/IP-nettverk har tre grunnleggende komponenter [1] :
Hvert administrert system (for eksempel en enkel node, en ruter , en skriver eller en hvilken som helst annen enhet som gir et SNMP-administrasjonsgrensesnitt) er vert for en administrasjonsagent ( masteragent ) og vanligvis et antall subagenter. Hovedagenten har i det minste rollen som mellomledd mellom lederen, en ekstern applikasjon som tar ledelsesbeslutninger, for eksempel under direkte kontroll av den menneskelige operatøren, og underagentene, som utfører disse beslutningene. Hver subagent er ansvarlig for å implementere ledelsesbeslutningene gitt av lederen i sammenheng med et bestemt delsystem eller i forhold til et bestemt aspekt av det administrerte systemet. I systemer som gir spesielt enkle styringsmekanismer, kan masteragenter og subagenter slå seg sammen til en enkelt programvarekomponent som både kan kommunisere med lederen og implementere hans beslutninger; i dette tilfellet vil vi bare snakke om agent.
SNMP bruker derfor et klart skille mellom administrasjonsprotokollen og strukturen til det administrerte objektet. I SNMP-arkitekturen er en database kalt MIB ( Management Information Base ) definert for hvert delsystem , administrert av den korresponderende subagenten, som representerer tilstanden til det administrerte delsystemet, eller rettere sagt, en projeksjon av denne tilstanden begrenset til aspektene som ønsker å tillate ledelse. Det er en database som kan defineres ved å låne et begrep fra refleksjon , "årsakssammenhengende": med andre ord, hver modifikasjon av MIB forårsaker en tilsvarende endring i tilstanden til det representerte delsystemet, og omvendt. Å sikre dette eierskapet til MIB er hovedfunksjonen til subagenten som administrerer den.
Tilgang til MIB (lese og skrive) representerer grensesnittet gitt til lederen for å administrere systemet. Hver MIB, mens den varierer i spesifikt innhold, har den samme generelle strukturen i form av et tre og de samme generelle tilgangsmekanismene for lederen (lesing og skriving av data). Hvert objekt i MIB er identifisert av en objekt-ID (OID). En OID er representert av en sekvens av heltall atskilt med prikker. Den representerer banen inne i MIB-treet for å komme fra roten til det. Bladnoder til MIB representerer administrerte objekter . For eksempel er SNMP MIB-nodesystemet representert av OID 1.3.6.1.2.1.1.
Takket være årsakssammenhengen til MIB er det derfor mulig for lederen å handle på tilstanden til delsystemet på en måte som i stor grad er uavhengig av de konkrete prosedyrene som da må settes på plass (av subagenten) for å trekke ut angi informasjon representert i MIB, eller implementere statusendringer etter endringer i innholdet i MIB. Dermed kan du for eksempel ha MIB-data som representerer IP-adressen til det administrerte systemet; for å endre denne adressen trenger lederen bare å få tilgang til MIB ved å overskrive de tilsvarende dataene, uavhengig av detaljene om hvordan en slik endring da faktisk "implementeres" på systemet som administreres gjennom agenten eller subagenten.
SNMP-protokollen i sin første versjon (SNMPv1) ble først definert i 1988 i RFC 1067 og godkjent som en Internett-standard i 1990 i RFC 1157 . Det grunnleggende samhandlingsskjemaet er av typen forespørsel-svar. Protokollen sørger for tre typer forespørselsmeldinger, sendt av lederen til agentene for de administrerte systemene:
De tre typene forespørselsmeldinger tilsvarer et enkelt svarmeldingsformat: Get-response .
Protokollen gir en annen type melding, Trap , sendt av en SNMP-agent til en forhåndsdefinert leder for asynkron varsling av hendelser:
SNMPv1-meldinger består av to deler: en header og en Protocol Data Unit (PDU) . Overskriften består av:
Fellesskapsnavnet brukes i SNMPv1 som en grunnleggende form for autentisering . SNMP forutsetter at enheter på et nettverk er gruppert i fellesskap , hver identifisert av en 32 - byte streng . En enkelt enhet kan tilhøre mer enn ett fellesskap. SNMP-agenten godtar kun forespørsler fra en leder av samme fellesskap som identifiserer seg med samme streng. Siden fellesskapsstrengen overføres i klartekst i SNMP-meldinger, anses SNMPv1-protokollen faktisk for å være usikker, og de fleste enheter forhindrer Set-operasjoner gjennom SNMPv1 .
Det generelle formatet for SNMPv1-meldinger er som følger.
Versjon | Samfunnet | SNMP PDU |
---|
PDU-format for SNMPv1-forespørselsmeldinger ( Get-request / Get-next-request / Set-request ):
PDU-type | Be om ID | 0 | 0 | Variable bindinger |
PDU-format for SNMPv1-svarmeldinger ( Get-response ):
PDU-type | Be om ID | Feilstatus | Feilindeks | Variable bindinger |
Format for SNMPv1 Trap-type PDUer:
PDU-type | Bedriften | Agentadresse | Generisk felletype | Spesifikk fellekode | Tidsstempel | Variable bindinger |
SNMPv1-protokollspesifikasjonene, definert av IETF, har gjennomgått en rekke oppdateringer gjennom årene. De finnes i en rekke RFC- dokumenter . De første RFC-ene angående SNMPv1 dateres tilbake til 1988:
Disse dokumentene ble senere (1990) gjort foreldet av:
Til slutt, etter kort tid, ble RFC 1156 erstattet av dokumentet:
Versjon 2 av SNMP-protokollen (SNMPv2) ble foreslått i 1993 ( RFC 1448 ), revidert i 1996 ( RFC 1905 ) og senere modifisert i 2002 ( RFC 3416 ).
SNMPv2 legger til nye sikkerhetsmekanismer, støtte for en ny distribuert administrasjonsarkitektur og introduserer to nye typer meldinger [2] :
SNMPv2-meldinger har et annet format enn det som er definert for SNMPv1.
Versjon | Overskrift | Sikkerhet | Kontekst-ID | Kontekst-navn | SNMP PDU |
---|
PDU-formatet for Inform -meldinger er det samme som for Get- , Get-next og Set - meldinger, mens det for Get-bulk- meldinger er forskjellig, og vises nedenfor.
Get-bulk PDU-format :
PDU type | Be om ID | Ikke-repetere | Maks-repetisjoner | Variable bindinger |
SNMPv2 støtter både SNMPv1 sentralisert nettverksadministrasjon og en ny distribuert strategi basert på leder-til-leder-interaksjoner. I en distribuert arkitektur kan noen systemer fungere både i rollen som leder og i rollen som agent. Når et system fungerer som en agent, godtar det kommandoer fra en leder på høyere nivå. Disse kommandoene kan be om informasjon som er lagret lokalt i lederen som fungerer som en agent, eller be om informasjon fra en underordnet agent for å fungere som en mellommann (fullmektig).
SNMPv2 løser problemet med mangel på autentisering, den alvorligste sikkerhetsmangelen til SNMPv1. Mangel på autentisering er et alvorlig SNMPv1-sikkerhetsproblem, som et resultat av at SNMPv1 brukes i bedriftsnettverk kun for overvåkingsformål (kun Hent operasjoner ).
SNMPv2 introduserer mekanismer for å forhindre følgende typer sikkerhetstrusler [3] :
SNMPv2 tillater meldingskryptering for å sikre innholdskonfidensialitet og legger til et sammendragsfelt i meldingsformatet for å sikre autentisering mellom to enheter.
Community-Based Simple Network Management Protocol versjon 2 (SNMPv2c), definert i RFC 1901 , fjerner det komplekse sikkerhetssystemet introdusert av SNMPv2 ved å gjenbruke fellesskapsstrengen til versjon 1. SNMPv2c, som beskrevet, er inkompatibel med SNMPv1 av to grunnleggende årsaker: meldingsformat og operasjoner. SNMPv2c-meldinger bruker faktisk en annen header og PDU enn versjon 1. Videre bruker SNMPv2c GetBulk- og Inform -operasjoner som ikke var til stede i forrige versjon. To mulige strategier for sameksistens mellom de to versjonene er: proxy-agent og tospråklig nettverksstyringssystem. [4]
FullmaktsagentProxyløsningen bør brukes for å muliggjøre kommunikasjon mellom enheter som støtter ulike versjoner av SNMP-meldinger. Kommunikasjon sikres ved å oversette meldings-PDUene.
I tilfelle en SNMPv2-melding må sendes til en agent som støtter SNMPv1, brukes følgende oversettelsesregler:
SNMPv3 ble definert av IETF i en serie RFC-er produsert siden 1998. SNMPv3 omstøter ikke tidligere versjoner, men legger til mekanismer i RFC 3414 som tillater følgende tre sikkerhetsnivåer i kommunikasjon mellom leder og agent [5] :
Gjennom disse mekanismene er protokollen i stand til å garantere:
Tabellen nedenfor viser mulige kombinasjoner av sikkerhetsmodellene [6] .
Nivå | Godkjenning | Kryptering | Konsekvenser |
---|---|---|---|
NoAuthNoPriv | Brukernavn | Nei | Bruk en streng (brukernavn) for
godkjenning |
AuthNoPriv | Message Digest Algorithm 5 (MD5)
o Secure Hash Algorithm (SHA) |
Nei | Autentiser gjennom
Hashed Message Authentication Code (HMAC) -MD5 eller HMAC-SHA algoritmer |
AuthPriv | MD5 eller SHA | Datakrypteringsstandard
(DES) |
Legg til DES-kryptering til authNoPriv-malen
56-bit basert på Cipher Block Chaining (CBC) -DES (DES-56) |
Det er mange RFC-er relatert til SNMPv3. Protokollspesifikasjonene er innkapslet i standard RFC-sekvenser, som har vært gjenstand for endringer gjennom årene. Et første sett med SNMPv3-relaterte RFC-er ble produsert i 1998:
Merk at RFC 2271 erstattet den forrige RFC 2261 noen dager senere . Et andre sett med SNMPv3-relaterte RFC-er ble produsert så tidlig som i 1999:
Til slutt ble en ny RFC-sekvens produsert i 2002:
Dokumentet om sameksistens mellom ulike versjoner av SNMP (opprinnelig RFC 2576 ) ble oppdatert som RFC 3584 i 2003. Til slutt, i 2009 ble andre RFC-er angående SNMPv3 produsert av IETF:
Det er flere implementeringer av SNMP-protokollen for både leder- og agentrollene.
Flere implementeringer er i form av et programmeringsbibliotek , designet for bruk av SNMP i mer komplekse programmer. Disse bibliotekene er tilgjengelige for de vanligste programmeringsspråkene.
Andre implementeringer er i form av kommandolinje eller grafiske grensesnittverktøy.
En åpen kildekodepakke med verktøy er Net-SNMP . Net-SNMP er en samling kommandolinjeverktøy som kan brukes i både Unix / Linux og Windows-miljøer. Den støtter v1-v2c-v3-versjoner av SNMP-protokollen. Nedenfor er et enkelt eksempel på bruk av snmpget- kommandoen inkludert i Net-SNMP-pakken.
snmpget -v 2c -c offentlig 149.144.21.254 system.sysDescr.0Kommandoen lar deg hente verdien av sysDescr-variabelen til vert 149.144.21.254. Alternativet -v spesifiserer protokollversjonen (i dette tilfellet 2c), mens alternativet -c angir fellesskapsstrengen for tilgang til enheten (i dette tilfellet offentlig). Det er viktig å merke seg at system og sysDescr kun er aliaser som lar deg få tilgang til verdien av variabelen, faktisk husk at en MIB alltid har en trestruktur og for å få tilgang til en node må du spesifisere banen for å komme til den.
Kommandoen kan deretter skrives om som følger ved å spesifisere hele banen ved å bruke objekt-ID-ene til variablene.
snmpget -v 2c -c offentlig 149.144.21.254 1.3.6.1.2.1.1.1.0Den endelige nullen må alltid spesifiseres fordi variablene kan være enkle skalarer eller tabeller (i dette tilfellet bør raden som skal åpnes angis).
En av hovedbrukene til SNMP er overvåking av sensorer eller kontinuerlig deteksjon av parametere knyttet til utstyr eller tjenester ved bruk av sensorer (både fysiske og virtuelle). Denne applikasjonen brukes for eksempel i overvåking av IT-ressurser.