Enkel nettverksadministrasjonsprotokoll
| SNMP (Simple Network Management Protocol) | |||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Familie: | Internett-protokollfamilie | ||||||||||||||||||||||||
| Driftsområde: | Nettverksadministrasjon | ||||||||||||||||||||||||
| Siste versjon: | SNMPv3 | ||||||||||||||||||||||||
| Porter: | 161 / UDP 162 / UDP (felle) |
||||||||||||||||||||||||
| |||||||||||||||||||||||||
| Standarder: |
RFC 1157 (SNMP, 1990) RFC 3410 ff (SNMPv3, 2002) (se tekst) |
||||||||||||||||||||||||
Den Simple Network Management Protocol ( SNMP ; tysk Simple Network Management Protocol ) er en nettverksprotokoll som IETF , er utformet for å nettverkselementer (f.eks. Rutere , tjenere , brytere fra en sentral stasjon overvåke og kontrollere, skrivere, datamaskiner, etc.) å kunne. Protokollen regulerer kommunikasjonen mellom de overvåkede enhetene og overvåkingsstasjonen. SNMP beskriver strukturen til datapakkene som kan sendes og kommunikasjonsprosessen. Den ble designet slik at en hvilken som helst nettverkskompatibel enhet kan inkluderes i overvåkingen. De nettverksadministrasjonsoppgaver som er mulig med SNMP inkluderer:
- Overvåking av nettverkskomponenter,
- Fjernkontroll og ekstern konfigurasjon av nettverkskomponenter,
- Feiloppdagelse og feilvarsling.
På grunn av sin enkelhet, modularitet og allsidighet har SNMP utviklet seg til standarden som støttes av de fleste administrasjonsprogrammer så vel som av sluttapparater.
funksjonalitet
Såkalte agenter brukes til overvåking . Dette er programmer som kjører direkte på de overvåkede enhetene eller maskinvaren som utfører de samme oppgavene. Disse programmene / enhetene kan registrere statusen til nettverksenheten og også gjøre innstillinger selv eller utløse handlinger. Ved hjelp av SNMP er det mulig at den sentrale styringsstasjonen kan kommunisere med agentene via et nettverk. Det er syv forskjellige datapakker som kan sendes:
- FÅ FORESPØRSEL
- å be om et ledelsesdatasett.
- GETNEXT FORESPØRSEL
- for å få følgende post (for å gjenta over tabeller).
- GETBULK (fra SNMPv2)
- å hente et spesifisert antall dataposter samtidig, ligner på flere GETNEXT-REQUEST.
- SETT FORESPØRSEL
- for å endre en eller flere dataposter for et nettverkselement. Noen ganger krever et nettverkselement samtidig endring av flere dataposter for å kontrollere konsistensen. For eksempel krever konfigurasjonen av en IP-adresse samtidig spesifikasjon av nettverksmasken.
- FÅ SVAR
- Svar på en av de forrige pakkene.
- FELLE
- uoppfordret melding fra en agent til lederen om at en hendelse har skjedd. Programmer som Wireshark , som brukes til å dekode protokoller som SNMP, kaller også denne datapakken RAPPORT . En TRAP kan også sendes hvis datapostendringen (e) som er beskrevet i en SET-REQUEST- pakke ikke kunne utføres, og ikke bare for å indikere en funksjonsfeil (f.eks. En feil i en modul av et nettverkselement) Rapporter til.
- INFORMERE FORESPØRSEL
- strukturert som en felle, bare at dette anerkjennes av mottakeren.
De tre GET- pakkene ( GET , GETNEXT , GETBULK ) kan sendes av lederen til en agent for å be om data om den respektive stasjonen. Dette svarer med en RESPONSE- pakke som enten inneholder de forespurte dataene eller en feilmelding.
Med SET-REQUEST- pakken kan en leder endre verdier hos agenten. Dette gjør det mulig å foreta innstillinger eller utløse handlinger. Agenten bekrefter også aksept av verdiene med en GET-RESPONSE- pakke.
Hvis agenten oppdager en feil under overvåking av systemet, kan den rapportere dette til administrasjonsstasjonen uten å bli bedt om å gjøre det ved hjelp av en TRAP- pakke. Disse pakkene er ikke bekreftet av lederen. Agenten kan derfor ikke avgjøre om den sendte TRAP- pakken har kommet til lederen.
For å holde nettverksbelastningen lav, brukes den forbindelsesløse UDP- protokollen til å sende meldinger . Agenten og lederen kommuniserer (forespørsler / svar) på port 161, mens port 162 kreves for å motta TRAP- meldingene.
Ledelsesinformasjonsbase
Rammeverket for SNMP-basert styring inkluderer ikke bare protokollen, men også representasjonen av databasen som er tilgjengelig i nettverksenheten, og som refereres til som “Management Information Base” eller “MIB” for kort.
Versjoner
Versjon 1
Den første versjonen av SNMP ble definert i følgende RFCer i 1988 :
- RFC 1155 - Struktur og identifikasjon av styringsinformasjon for TCP / IP-baserte internett (erstatter RFC 1065 )
- RFC 1156 - Management Information Base for Network Management of TCP / IP-based internets (erstatter RFC 1066 )
- RFC 1157 - En enkel nettverksadministrasjonsprotokoll (erstatter RFC 1067 og RFC 1098 )
Hovedproblemet med den første versjonen er utilstrekkelig sikkerhet under overføring. Et av problemene er ukryptert overføring av passordet, noe som betyr at det enkelt kan avlyttes og brukes av uautoriserte parter.
Sikker SNMP
Det økte sikkerhetsbehovet førte til at det i 1992 ble utgitt tre RFCer om SNMPsec (Secure SNMP).
- RFC 1351 - SNMP administrativ modell
- RFC 1352 - SNMP sikkerhetsprotokoller
- RFC 1353 - Definisjoner av Managed Objects for Administration of SNMP Parties
Denne versjonen ble aldri introdusert, men erstattet av SNMPv2.
Festbasert SNMP versjon 2 (SNMPv2p)
I 1993 ble SNMPv2p publisert av IETF . Det forbedret SNMPv1 når det gjelder sikkerhet og konfidensialitet ved å kryptere fellesskapsstrengen og innføre kommunikasjon mellom forskjellige ledere. Den nye GetBulk-kommandoen har gjort spørringstabeller mye enklere.
- RFC 1441 - Introduksjon til versjon 2 av Internett-standard Network Management Framework
- RFC 1445 - administrativ modell for versjon 2 av Simple Network Management Protocol (SNMPv2)
- RFC 1446 - Sikkerhetsprotokoller for versjon 2 av Simple Network Management Protocol (SNMPv2)
- RFC 1447 - Party MIB for versjon 2 av Simple Network Management Protocol (SNMPv2)
Denne versjonen brukes ikke lenger i dag.
Brukerbasert SNMP versjon 2 (SNMPv2u)
Med SNMPv2u prøver man å øke sikkerheten med brukernavn.
- RFC 1909 - En administrativ infrastruktur for SNMPv2
- RFC 1910 - Brukerbasert sikkerhetsmodell for SNMPv2
Denne versjonen brukes ikke lenger i dag.
Samfunnsbasert SNMP versjon 2 (SNMPv2c)
Når det gjelder sikkerhet, er SNMPv2c oppdatert med SNMPv1. Den utvides bare med noen få ekstra funksjoner som allerede var tilgjengelige med SNMPv2p:
- Tabeller trenger ikke lenger å bla gjennom med GetNext-kommandoen, men kan hentes samtidig med GetBulk-kommandoen.
- Kommunikasjon mellom forskjellige ledere.
Denne versjonen har hersket og fått bred aksept. I dag, når folk snakker om SNMPv2, mener de vanligvis denne versjonen.
- RFC 1901 - Introduksjon til samfunnsbasert SNMPv2
- RFC 1905 - Protokolloperasjoner for versjon 2 av Simple Network Management Protocol (SNMPv2) (erstatter RFC 1448 )
- RFC 1906 - Transportkartlegginger for versjon 2 av Simple Network Management Protocol (SNMPv2) (erstatter RFC 1449 )
Versjon 3
SNMP versjoner 1 og 2c tilbyr nesten ingen sikkerhetsmekanismer. Det er her tulletolkningen av forkortelsen SNMP som "Security is not my problem" kommer fra. I den nåværende versjonen 3 er sikkerhetsmekanismene utvidet betydelig. Den tilhørende økning i kompleksitet (f.eks sentrale ledelsen ) har ført til at SNMPv3 er ennå ikke så utbredt som SNMPv2.
SNMP i den siste versjonen 3 er definert av en rekke nye RFCer (spesifikasjonen ble laget i desember 2002):
- RFC 3410 - Innlednings- og anvendelseserklæringer for Internet-Standard Management Framework
- RFC 3411 - En arkitektur for å beskrive Simple Network Management Protocol (SNMP) Management Frameworks
- RFC 3412 - Meldingsbehandling og utsendelse for SNMP (Simple Network Management Protocol)
- RFC 3413 - Simple Network Management Protocol (SNMP) -applikasjoner
- RFC 3414 - Brukerbasert sikkerhetsmodell (USM) for versjon 3 av Simple Network Management Protocol (SNMPv3)
- RFC 3415 - Visningsbasert tilgangskontrollmodell (VACM) for SNMP (Simple Network Management Protocol)
- RFC 3416 - versjon 2 av protokolloperasjonene for Simple Network Management Protocol (SNMP)
- RFC 3417 - Transportkartlegginger for Simple Network Management Protocol (SNMP)
- RFC 3418 - Management Information Base (MIB) for Simple Network Management Protocol (SNMP)
Pakkestruktur (SNMPv1)
Beskrivelsen av SNMP-pakkene gjøres av ASN.1 , kodingen for transport over nettverket ved bruk av Basic Encoding Rules (BER). De fleste SNMP-pakkene er strukturert identisk. Bare når det gjelder fellemeldinger, sendes annen informasjon i PDU- overskriften.
| SNMP pakkehode | PDU-topptekst | PDU kropp | |||||||
|---|---|---|---|---|---|---|---|---|---|
| Versjonsnummer | Fellesskapsnavn | Pakketype (Get, GetNext ...) | Forespørsel-ID | Feilstatus | Feilindeks | Variabel binding 1 | Variabel binding 2 | ... | Variabel binding n |
Pakkestrukturen til en SNMPv1-pakke inneholder ingen størrelsesinformasjon, siden hvert felt blir bragt inn i formatet for lengden på typen lengde ved hjelp av ASN.1 .
SNMP pakkehode
Versjonsnummeret (SNMPv1, SNMPv2 eller SNMPv3) og gruppenavnet overføres i overskriften. Ved å tildele samfunn gis tilgangsrettigheter. I de fleste tilfeller brukes samfunnsnavnet "offentlig" som standard for skrivebeskyttet tilgang og "privat" for lese- og skrivetilgang (lese-skrive). Siden disse to fellesskapsnavnene er kjent som standardinnstillingen, bør de endres. Dette øker imidlertid ikke uunngåelig sikkerheten, siden fellesskapsnavnene overføres som klar tekst over nettverket.
PDU-overskrift (ikke-felle pakker)
Type SNMP-pakke og størrelsen på PDU overføres i første del av PDU-overskriften. Strukturen til den andre delen avhenger av typen SNMP-pakke.
Slik at svarpakker kan tilordnes de forrige forespørslene, er det forespørsels-ID-en, som er identisk for forespørsel og svar. Dette gjør det mulig å sende flere henvendelser og tildele svarene riktig igjen.
Feilstatus og indeks brukes i svarpakker for å indikere hvorfor en forespørsel ikke kunne behandles. Så lenge det ikke oppstår noen feil, tildeles begge felt verdien null. I tilfelle en feil indikerer feilindeksen antall dataposter der feilen oppstod. Feilstatusen indikerer årsaken til feilen. Med SNMPv1 kan feilstatusen ha en av 6 mulige verdier:
- ingen feil
- Pakken er for stor til å sendes
- den OID støttes ikke
- Feil datatype eller verdi (bare mulig som svar på angitte pakker)
- skrivebeskyttet tilgang (bare mulig som svar på angitte pakker)
- ukjent generasjonsfeil
PDU header (fellepakker)
De to første feltene i PDU-overskriften er identiske med de andre SNMP-pakkene for feller. Pakketypefeltet indikerer at det er en felle. I den andre delen overføres andre verdier som bare kreves for feller.
| PDU-topptekst | |||||
|---|---|---|---|---|---|
| Pakketype (felle) | OID for enheten som genererte fellen | Avsenderens IP-adresse | generell felle- ID | selskapsspesifikk felle- ID | Tidspunktet da fellehendelsen skjedde |
Avsenderens IP-adresse og dens produsentspesifikke OID (1.3.6.1.4.1. *) Sendes også for å identifisere hvem meldingen kommer fra. OID indikerer hva slags enhet det er. Dette er viktig å vite om det er en selskapsspesifikk felle som bare gjelder denne enhetstypen.
Dette følges av den generelle TrapID. Det er syv mulige generelle TrapIDer:
| betegnelse | Verdi i fella PDU |
|---|---|
| Kaldstart (kaldstart) | 0 |
| Varm start (varm start) | 1 |
| Link Down (linkDown) | 2 |
| Link Up (linkUp) | 3 |
| Autentisering Feil | 4. plass |
| EGP - Tapt naboer (egpNeighborLoss) | 5 |
| selskapsspesifikk (enterpriseSpecific) | Sjette |
Hvis "selskapsspesifikk (enterpriseSpecific)" er spesifisert i "TrapID" -feltet, overføres ID-en til den selskapsspesifikke fellen i følgende felt.
Siden det er mulig at fellepakker ikke kommer i den rekkefølgen de ble sendt i, er det også en tidsspesifikasjon som spesifiserer til hundredeler av et sekund hvor lenge SNMP-agenten kjørte til fellehendelsen skjedde. Dette gjør det mulig å sette fellehendelsene i riktig kronologisk rekkefølge.
PDU kropp
De faktiske verdiene overføres i PDU-kroppen. Hver verdi overføres i en såkalt variabel binding:
| OID | Variabel binding |
| verdi |
En variabel binding inkluderer OID og selve verdien.
Det er ingen spesifikasjon for hvor mange variable bindinger som kan sendes i PDU-kroppen. Det er derfor mulig å spørre flere verdier med en get-kommando. Hvis svarpakken imidlertid blir for stor, kan den tilsvarende feilmeldingen sendes tilbake i svarpakken.
Med feller er det også mulig at ingen variable bindinger blir sendt. I dette tilfellet anses TrapID som tilstrekkelig informasjon.
I SNMP-pakken er det ingen bestemmelse for å spesifisere antall sendte variable bindinger. Dette kan du bare finne ut ved å spesifisere størrelsen på PDU-kroppen og størrelsen på de enkelte variable bindingene.
Sikkerhetsproblemer
En ulempe med SNMP versjon 1 til 2c er mangelen på sikkerhet. Disse versjonene av SNMP støtter ikke pålogging med passord og brukernavn; såkalte fellesskap brukes. Disse har imidlertid den ulempen at hver bruker i nettverket kan lese ut systeminformasjon og til og med endre verdier med et passende program.
Fellesskap er enkle navn, for eksempel "OFFENTLIG" (kan bare lese) eller "PRIVATE" (kan også skrive), som overføres med forespørsel fra SNMP-tjenesten. De er ikke noe annet enn en tidligere avtalt nøkkel ( forhåndsdelte nøkler ). Du kan selvfølgelig også bruke veldig lange og kompliserte samfunnsnavn. Dette er imidlertid begrenset, siden SNMP-pakker ikke er kryptert og derfor lett kan "snuse" av en angriper.
Tillatt vert: Det er imidlertid muligheten for å begrense IP-adressene til systemene som har lov til å kontakte et overvåket SNMP-system. Dette er relativt enkel beskyttelse, men det kan være mulig å overstyre den med ARP spoofing og IP spoofing .
Ledelsesbeskyttelse: Siden tidlig på 1990-tallet har det vært vanlig å opprette et eget nettverk for å overvåke systemene for å skille brukerdatatrafikken fra ledertrafikken. Dette kalles out-of-band. Trafikk som flyter over det konvensjonelle datanettverket kalles in-band kommunikasjon. Siden dette andre nettverket øker kostnadene for overvåking, er det bare fornuftig å bruke det i sikkerhetsrelevante områder, for eksempel banksektoren.
Read Only: Det er også mulig å tilordne en "Read Only" til visse systemer. Dermed kan hver overvåkingsenhet bare lese. Dette brukes ofte med rutere.
SNMP versjon 3 tilbyr blant annet kryptering og bedre autentisering , som for tiden ofte ikke brukes på grunn av større kompleksitet.
litteratur
- Larry Walsh: SNMP Mib Handbook. Wyndham Press, mars 2008, ISBN 978-0-9814922-0-9 .
- Douglas R. Mauro og Kevin J. Schmidt: Essential SNMP: Help for System and Network Administrators 2nd Edition, O'Reilly Media, september 2005, ISBN 978-0-596-00840-6 .
- William Stallings: SNMP, SNMPv2, SNMPv3 og RMON 1 og 2 . 2. utgave, Addison-Wesley Longman, februar 1999, ISBN 978-0-201-48534-9 .
Se også
- Agent Extensibility Protocol (AgentX)