Enkel nettverksadministrasjonsprotokoll

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 ).

Arkitektur

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] :

  1. styringssystem ( leder );
  2. administrasjonsagent ( agent eller masteragent ), aktiv i enheten, og eventuelle underagenter ;
  3. administrert objektsamling .

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 versjon 1

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 .

SNMPv1 meldingsformat

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

RFC-er relatert til SNMPv1

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:

SNMP versjon 2

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 meldingsformat

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

Management Architecture

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).

Sikkerhet

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.

SNMPv2c

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]

Fullmaktsagent

Proxylø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:

SNMP versjon 3

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)

RFC-er relatert til SNMPv3

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:

Implementeringer

Det er flere implementeringer av SNMP-protokollen for både leder- og agentrollene.

SNMP-biblioteker

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.

SNMP-verktøy

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.0

Kommandoen 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.0

Den endelige nullen må alltid spesifiseres fordi variablene kan være enkle skalarer eller tabeller (i dette tilfellet bør raden som skal åpnes angis).

Kommersielle produkter

Applikasjoner

SNMP-overvåking

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.

Merknader

  1. ^ RFC 3411 - En arkitektur for å beskrive Simple Network Management Protocol (SNMP) Management Frameworks
  2. ^ RFC 3416 - Versjon 2 av Protocol Operations the Simple Network Management Protocol (SNMP)
  3. ^ http://www.net130.com/tutorial/other/Internet%20Overview.pdf– Chapter8-Network Management
  4. ^ RFC 3584 - Sameksistens mellom versjon 1, versjon 2 og versjon 3 av Internett-standarden Network Management Framework
  5. ^ RFC 3414 - Brukerbasert sikkerhetsmodell (USM) for versjon 3 av Simple Network Management Protocol (SNMPv3)
  6. ^ https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/snmp/configuration/xe-3se/3850/snmp-xe-3se-3850-book/nm-snmp -snmpv3.pdf - CISCO SNMP versjon 3
  7. ^ http://netsnmpj.sourceforge.net/ netsnmpj: Åpen kildekode SNMP for Java
  8. ^ http://www.snmp4j.org/ SNMP4J - The Object Oriented SNMP API for Java Managers and Agents
  9. ^ http://pysnmp.sourceforge.net/ PySNMP
  10. ^ https://www.nuget.org/packages/Lextm.SharpSnmpLib/ #SNMP Library
  11. ^ https://docs.oracle.com/cd/E19957-01/802-4523/802-4523.pdf SunNet Manager 2.2.3 referansehåndbok
  12. ^ https://www.ibm.com/us-en/marketplace/ibm-tivoli-netview-for-zos IBM Tivoli NetView for z / OS

Bibliografi

Relaterte elementer

Andre prosjekter

Eksterne lenker