Enkel nettverksadministrasjonsprotokoll - Simple Network Management Protocol

SNMPv3 STD0062
Kommunikasjonsprotokoll
OSI -lag applikasjon
Port (er) 161, 162 (Trap)
RFC (r) 3411–3418
Sikker SNMP
Kommunikasjonsprotokoll
OSI -lag applikasjon
Port (er) 10161, 10162 (Trap)
RFC (r) 6353
Internettprotokollpakke
Påføringslag
Transportlag
Internett -lag
Linklag

Simple Network Management Protocol ( SNMP ) er en Internett -standardprotokoll for innsamling og organisering av informasjon om administrerte enheter på IP -nettverk og for å endre denne informasjonen for å endre enhetens oppførsel. Enheter som vanligvis støtter SNMP inkluderer kabelmodem, rutere, switcher, servere, arbeidsstasjoner, skrivere og mer.

SNMP er mye brukt i nettverksadministrasjon for nettverksovervåking . SNMP avslører styringsdata i form av variabler på de administrerte systemene organisert i en administrasjonsinformasjonsbase (MIB) som beskriver systemstatus og konfigurasjon. Disse variablene kan deretter fjernspørres (og i noen tilfeller manipuleres) ved å administrere applikasjoner.

Tre betydelige versjoner av SNMP er utviklet og distribuert. SNMPv1 er den opprinnelige versjonen av protokollen. Nyere versjoner, SNMPv2c og SNMPv3, har forbedringer i ytelse, fleksibilitet og sikkerhet.

SNMP er en komponent i Internet Protocol Suite som definert av Internet Engineering Task Force (IETF). Den består av et sett av standarder for nettverksadministrasjon, inkludert et applikasjonslaget protokollen, en databaseskjema , og et sett av dataobjekter .

Oversikt og grunnleggende begreper

Prinsipp for SNMP -kommunikasjon

Ved typisk bruk av SNMP har en eller flere administrative datamaskiner kalt ledere som oppgave å overvåke eller administrere en gruppe verter eller enheter på et datanettverk . Hvert administrert system utfører en programvarekomponent kalt en agent som rapporterer informasjon via SNMP til lederen.

Et SNMP-administrert nettverk består av tre viktige komponenter:

En administrert enhet er en nettverksnode som implementerer et SNMP-grensesnitt som gir enveis (skrivebeskyttet) eller toveis (lese og skrive) tilgang til nodespesifikk informasjon. Administrerte enheter utveksler nodespesifikk informasjon med NMS-ene. Noen ganger kalt nettelementer, kan de administrerte enhetene være alle typer enheter, inkludert, men ikke begrenset til, rutere , tilgang servere , svitsjer , kabelmodemer , broer , hubber , IP-telefoner , IP-videokameraer , PC verter og skrivere .

En agent er en modul for nettverksadministrasjon som ligger på en administrert enhet. En agent har lokal kunnskap om ledelsesinformasjon og oversetter denne informasjonen til eller fra et SNMP-spesifikt skjema.

En nettverksadministrasjonsstasjon utfører applikasjoner som overvåker og kontrollerer administrerte enheter. NMS -er utgjør hoveddelen av behandlings- og minneressursene som kreves for nettverksadministrasjon. Ett eller flere NMS -er kan eksistere på et administrert nettverk.

Ledelsesinformasjonsbase

Hovedartikkel: Ledelsesinformasjonsbase

SNMP -agenter avslører styringsdata på de administrerte systemene som variabler. Protokollen tillater også aktive administrasjonsoppgaver, for eksempel konfigurasjonsendringer, gjennom ekstern modifikasjon av disse variablene. Variablene som er tilgjengelige via SNMP er organisert i hierarkier. SNMP definerer ikke selv hvilke variabler et administrert system skal tilby. SNMP bruker heller en utvidbar design som lar applikasjoner definere sine egne hierarkier. Disse hierarkiene beskrives som en ledelsesinformasjonsbase (MIB). MIB beskriver strukturen til styringsdataene til et enhetsundersystem; de bruker et hierarkisk navnerom som inneholder objektidentifikatorer (OID). Hver OID identifiserer en variabel som kan leses eller settes via SNMP. MIB bruker notasjonen definert av Structure of Management Information Version 2.0 (SMIv2, RFC  2578 ), et delsett av ASN.1 .

Protokolldetaljer

SNMP opererer i applikasjonslaget i Internett -protokollpakken . Alle SNMP -meldinger transporteres via User Datagram Protocol (UDP). SNMP -agenten mottar forespørsler på UDP -port 161. Lederen kan sende forespørsler fra en hvilken som helst tilgjengelig kildeport til port 161 i agenten. Agentresponset sendes tilbake til kildeporten på lederen. Lederen mottar varsler ( Traps and InformRequests ) på port 162. Agenten kan generere varsler fra en hvilken som helst tilgjengelig port. Når den brukes med Transport Layer Security eller Datagram Transport Layer Security , mottas forespørsler på port 10161 og varsler sendes til port 10162.

SNMPv1 spesifiserer fem kjerne -protokollen dataenheter (PDUer). To andre PDUer, GetBulkRequest og InformRequest ble lagt til i SNMPv2 og rapporten PDU ble lagt til i SNMPv3. Alle SNMP PDUer er konstruert som følger:

IP -topptekst UDP -topptekst versjon samfunnet PDU-type forespørsel-id feil-status feilindeks variable bindinger

De syv SNMP PDU-typene som er identifisert av feltet PDU-type er som følger:

GetRequest
En forespørsel fra leder til agent for å hente verdien av en variabel eller liste over variabler. Ønskede variabler er spesifisert i variabelbindinger (verdifeltet brukes ikke). Hentning av de angitte variabelverdiene skal utføres som en atomoperasjon av agenten. Et svar med gjeldende verdier returneres.
SetRequest
En forespørsel fra leder til agent om å endre verdien til en variabel eller liste over variabler. Variable bindinger er spesifisert i forespørselens brødtekst. Endringer av alle spesifiserte variabler skal utføres som en atomoperasjon av agenten. Et svar med (nåværende) nye verdier for variablene returneres.
GetNextRequest
En forespørsel fra leder til agent for å oppdage tilgjengelige variabler og deres verdier. Returnerer et svar med variabelbinding for den leksikografisk neste variabelen i MIB. Hele MIB -en til en agent kan gås av iterativ applikasjon av GetNextRequest som starter med OID 0. Rader i en tabell kan leses ved å spesifisere kolonne -OID -er i forespørselens variable bindinger.
GetBulkRequest
En forespørsel fra leder til agent for flere iterasjoner av GetNextRequest . En optimalisert versjon av GetNextRequest . Returnerer et svar med flere variabelbindinger som går fra variabelbindingen eller bindinger i forespørselen. PDU-spesifikke ikke-repeatere og maks-repetisjonsfelt brukes til å kontrollere responsatferd. GetBulkRequest ble introdusert i SNMPv2.
Respons
Returnerer variable bindinger og bekreftelse fra agent til leder for GetRequest , SetRequest , GetNextRequest , GetBulkRequest og InformRequest . Feilrapportering er levert av feilstatus og feilindeksfelt. Selv om den ble brukt som et svar på både får og sett, ble denne PDU kalt GetResponse i SNMPv1.
Felle
Asynkron melding fra agent til manager. Mens lederen i annen SNMP -kommunikasjon aktivt etterspør informasjon fra agenten, dette er PDU -er som sendes fra agenten til lederen uten å bli eksplisitt forespurt. SNMP -feller gjør det mulig for en agent å varsle administrasjonsstasjonen om viktige hendelser ved hjelp av en uoppfordret SNMP -melding. Felle PDUer inkluderer gjeldende sysUpTime -verdi, en OID som identifiserer type felle og valgfrie variabelbindinger. Destinasjonsadressering for feller bestemmes på en applikasjonsspesifikk måte, vanligvis gjennom konfigurasjonsvariabler for feller i MIB. Formatet på felle-meldingen ble endret i SNMPv2 og PDU ble omdøpt til SNMPv2-Trap .
InformRequest
Godkjent asynkron varsling. Denne PDU ble introdusert i SNMPv2 og ble opprinnelig definert som leder til leder kommunikasjon. Senere implementeringer har løsnet den opprinnelige definisjonen for å tillate agent til lederkommunikasjon . Manager-to-manager varsler var allerede mulig i SNMPv1 ved hjelp av en felle , men ettersom SNMP vanligvis kjører over UDP der levering ikke er sikret og droppede pakker ikke rapporteres, var levering av en felle ikke garantert. InformRequest løser dette ettersom en bekreftelse returneres ved mottak.

RFC  1157 spesifiserer at en SNMP -implementering må godta en melding på minst 484 byte. I praksis godtar SNMP -implementeringer lengre meldinger. Hvis den er implementert på riktig måte, blir en SNMP -melding kastet hvis dekodingen av meldingen mislykkes og dermed misformede SNMP -forespørsler ignoreres. En vellykket dekodet SNMP -forespørsel blir deretter autentisert ved hjelp av fellesskapsstrengen. Hvis godkjenningen mislykkes, genereres en felle som indikerer en autentiseringsfeil og meldingen slippes.

SNMPv1 og SNMPv2 bruker lokalsamfunn for å etablere tillit mellom ledere og agenter. De fleste agenter støtter tre fellesskapsnavn, ett hver for skrivebeskyttet, lese-skrive og felle. Disse tre fellesskapsstrengene styrer ulike typer aktiviteter. Det skrivebeskyttede fellesskapet gjelder for å få forespørsler. Les-skriv-fellesskapsstrengen gjelder for angitte forespørsler. Fellefellesskapsstrengen gjelder for mottak av feller . SNMPv3 bruker også fellesskapsstrenger, men gir mulighet for sikker autentisering og kommunikasjon mellom SNMP -manager og agent.

Protokollversjoner

I praksis støtter SNMP -implementeringer ofte flere versjoner: vanligvis SNMPv1, SNMPv2c og SNMPv3.

Versjon 1

SNMP versjon 1 (SNMPv1) er den første implementeringen av SNMP -protokollen. Utformingen av SNMPv1 ble gjort på 1980 -tallet av en gruppe samarbeidspartnere som så på den offisielt sponsede OSI/IETF/NSF (National Science Foundation) innsatsen (HEMS/CMIS/CMIP) som både uimplementerbar i datidens databehandlingsplattformer så vel som potensielt ubrukelig. SNMP ble godkjent basert på en tro på at det var en midlertidig protokoll som var nødvendig for å ta skritt mot storskala distribusjon av Internett og kommersialisering.

Den første forespørselen om kommentarer (RFC) for SNMP, nå kjent som SNMPv1, dukket opp i 1988:

  • RFC  1065  -Struktur og identifisering av administrasjonsinformasjon for TCP/IP-baserte internett
  • RFC  1066  -Administrasjonsinformasjonsbase for nettverksadministrasjon av TCP/IP-baserte internett
  • RFC  1067  - En enkel nettverksadministrasjonsprotokoll

I 1990 ble disse dokumentene erstattet av:

  • RFC  1155  -Struktur og identifisering av administrasjonsinformasjon for TCP/IP-baserte internett
  • RFC  1156  -Administrasjonsinformasjonsbase for nettverksadministrasjon av TCP/IP-baserte internett
  • RFC  1157  - En enkel nettverksadministrasjonsprotokoll

I 1991 ble RFC  1156 (MIB-1) erstattet av de oftere brukte:

  • RFC  1213  -Versjon 2 av administrasjonsinformasjonsbasen (MIB-2) for nettverksadministrasjon av TCP/IP-baserte internett

SNMPv1 er mye brukt og er de facto nettverksadministrasjonsprotokoll i internettsamfunnet.

SNMPv1 kan bæres av transportlagsprotokoller som User Datagram Protocol (UDP), Internet Protocol (IP), OSI Connectionless-mode Network Service (CLNS), AppleTalk Datagram Delivery Protocol (DDP) og Novell Internetwork Packet Exchange (IPX).

Versjon 1 har blitt kritisert for dårlig sikkerhet. Spesifikasjonen tillater faktisk plass til tilpasset autentisering, men mye brukte implementeringer "støtter bare en triviell autentiseringstjeneste som identifiserer alle SNMP -meldinger som autentiske SNMP -meldinger.". Sikkerheten til meldingene blir derfor avhengig av sikkerheten til kanalene som meldingene sendes over. For eksempel kan en organisasjon vurdere sitt interne nettverk som tilstrekkelig sikkert til at ingen kryptering er nødvendig for sine SNMP -meldinger. I slike tilfeller pleier "fellesskapsnavnet", som overføres i klartekst , å bli sett på som et de facto -passord, til tross for den opprinnelige spesifikasjonen.

Versjon 2

SNMPv2, definert av RFC  1441 og RFC  1452 , reviderer versjon 1 og inkluderer forbedringer innen ytelse, sikkerhet og leder-til-leder-kommunikasjon. Den introduserte GetBulkRequest , et alternativ til iterative GetNextRequests for å hente store mengder styringsdata i en enkelt forespørsel. Det nye festbaserte sikkerhetssystemet som ble introdusert i SNMPv2, av mange sett på som altfor komplekst, ble ikke bredt vedtatt. Denne versjonen av SNMP nådde det foreslåtte modenhetsnivået, men ble ansett som foreldet av senere versjoner.

Samfunnsbaserte Simple Network Management Protocol versjon 2 , eller SNMPv2c , er definert i RFC  1901 - RFC  1908 . SNMPv2c består av SNMPv2 uten den kontroversielle nye SNMP v2-sikkerhetsmodellen, og bruker i stedet det enkle samfunnsbaserte sikkerhetsopplegget til SNMPv1. Denne versjonen er en av relativt få standarder for å oppfylle IETFs utkast til standard modenhetsnivå, og ble mye ansett som de facto SNMPv2 -standarden. Den ble senere omarbeidet som en del av SNMPv3.

Brukerbasert enkel nettverksadministrasjonsprotokoll versjon 2 , eller SNMPv2u , er definert i RFC  1909 - RFC  1910 . Dette er et kompromiss som prøver å tilby større sikkerhet enn SNMPv1, men uten å pådra seg den høye kompleksiteten til SNMPv2. En variant av dette ble kommersialisert som SNMP v2* , og mekanismen ble til slutt vedtatt som en av to sikkerhetsrammer i SNMP v3.

64-bit tellere

SNMP versjon 2 introduserer muligheten for 64-biters datatellere. Versjon 1 ble designet kun med 32-bit tellere som kan lagre heltallverdier fra null til 4,29 milliarder (nøyaktig 4 294 967 295). En 32-biters versjon 1-teller kan ikke lagre maksimalhastigheten på et 10 gigabit eller større grensesnitt, uttrykt i bits per sekund. På samme måte kan en 32-bits tellersporingsstatistikk for et 10 gigabit eller større grensesnitt vende tilbake til null igjen på mindre enn ett minutt, noe som kan være et kortere tidsintervall enn en teller blir spurt for å lese den nåværende tilstanden. Dette vil resultere i tapte eller ugyldige data på grunn av uoppdaget verdioverføring og ødeleggelse av trendsporingsdata.

64-biters versjon 2-telleren kan lagre verdier fra null til 18,4 quintillion (nøyaktig 18 446 744 073 709 551 615), og det er derfor lite sannsynlig at det vil oppstå en motrulling mellom avstemningshendelser. For eksempel er 1,6 terabit Ethernet spådd å bli tilgjengelig innen 2025. En 64-biters tellerøkning med en hastighet på 1,6 billioner bits per sekund vil kunne beholde informasjon for et slikt grensesnitt uten å rulle i 133 dager.

SNMPv1 og SNMPv2c interoperabilitet

SNMPv2c er inkompatibel med SNMPv1 på to sentrale områder: meldingsformater og protokolloperasjoner. SNMPv2c -meldinger bruker forskjellige header- og protokolldataenhet (PDU) -formater enn SNMPv1 -meldinger. SNMPv2c bruker også to protokolloperasjoner som ikke er spesifisert i SNMPv1. For å overvinne inkompatibilitet definerer RFC  3584 to SNMPv1/v2c sameksistensstrategier: proxy-agenter og tospråklige nettverksadministrasjonssystemer.

Fullmakter

En SNMPv2 -agent kan fungere som en proxy -agent på vegne av SNMPv1 -administrerte enheter. Når et SNMPv2 NMS utsteder en kommando beregnet for en SNMPv1 -agent, sender den den til SNMPv2 -proxyagenten i stedet. Proxy middel forover Get, GetNext, og Setmeldinger til SNMPv1 middelet uforandret. GetBulk -meldinger konverteres av proxy -agenten til GetNextmeldinger og videresendes deretter til SNMPv1 -agenten. I tillegg mottar og kartlegger proxy -agenten SNMPv1 -trapemeldinger til SNMPv2 -trapemeldinger og videresender dem deretter til NMS.

Tospråklig system for nettverksadministrasjon

Tospråklige SNMPv2 nettverksadministrasjonssystemer støtter både SNMPv1 og SNMPv2. For å støtte dette dobbeltstyringsmiljøet undersøker et administrasjonsprogram informasjon som er lagret i en lokal database for å avgjøre om agenten støtter SNMPv1 eller SNMPv2. Basert på informasjonen i databasen, kommuniserer NMS med agenten ved å bruke den riktige versjonen av SNMP.

Versjon 3

Selv om SNMPv3 ikke gjør noen endringer i protokollen bortsett fra tillegg av kryptografisk sikkerhet, ser den veldig annerledes ut på grunn av nye tekstkonvensjoner, begreper og terminologi. Den mest synlige endringen var å definere en sikker versjon av SNMP, ved å legge til sikkerhet og eksterne konfigurasjonsforbedringer til SNMP. Sikkerhetsaspektet tas opp ved å tilby både sterk autentisering og datakryptering for personvern. For administrasjonsaspektet fokuserer SNMPv3 på to deler, nemlig varslingsopphavsmenn og proxy -speditører. Endringene letter også ekstern konfigurasjon og administrasjon av SNMP-enhetene, i tillegg til å løse problemer knyttet til storstilt distribusjon, regnskap og feilbehandling.

Funksjoner og forbedringer inkludert:

  • Identifikasjon av SNMP -enheter for å lette kommunikasjonen bare mellom kjente SNMP -enheter - Hver SNMP -enhet har en identifikator kalt SNMPEngineID, og ​​SNMP -kommunikasjon er bare mulig hvis en SNMP -enhet kjenner identiteten til sin kollega. Feller og varsler er unntak fra denne regelen.
  • Støtte for sikkerhetsmodeller - En sikkerhetsmodell kan definere sikkerhetspolicyen i et administrativt domene eller et intranett. SNMPv3 inneholder spesifikasjonene for en brukerbasert sikkerhetsmodell (USM).
  • Definisjon av sikkerhetsmål der målene for meldingsautentiseringstjeneste inkluderer beskyttelse mot følgende:
    • Endring av informasjon-Beskyttelse mot noen uautoriserte SNMP-enheter som endrer transittmeldinger generert av en autorisert rektor.
    • Masquerade - Beskyttelse mot forsøk på ledelsesoperasjoner som ikke er autorisert for noen rektor ved å anta identiteten til en annen rektor som har de nødvendige autorisasjonene.
    • Endring av meldingsstrøm-Beskyttelse mot at meldinger blir skadelig ombestilt, forsinket eller spilt på nytt for å påvirke uautoriserte administrasjonsoperasjoner.
    • Avsløring - Beskyttelse mot avlytting på utvekslingene mellom SNMP -motorer.
  • Spesifikasjon for USM - USM består av den generelle definisjonen av følgende tilgjengelige kommunikasjonsmekanismer:
    • Kommunikasjon uten autentisering og personvern (NoAuthNoPriv).
    • Kommunikasjon med autentisering og uten personvern (AuthNoPriv).
    • Kommunikasjon med autentisering og personvern (AuthPriv).
  • Definisjon av forskjellige autentiserings- og personvernprotokoller-MD5, SHA og HMAC-SHA-2 autentiseringsprotokoller og CBC_DES og CFB_AES_128 personvernprotokoller støttes i USM.
  • Definisjon av en oppdagelsesprosedyre - For å finne SNMPEngineID for en SNMP -enhet for en gitt transportadresse og transportendpunktadresse.
  • Definisjon av tidssynkroniseringsprosedyren - For å lette autentisert kommunikasjon mellom SNMP -enhetene.
  • Definisjon av SNMP -rammeverket MIB - For å lette ekstern konfigurasjon og administrasjon av SNMP -enheten.
  • Definisjon av USM MIB - For å lette ekstern konfigurasjon og administrasjon av sikkerhetsmodulen.
  • Definisjon av den visningsbaserte tilgangskontrollmodellen (VACM) MIB-er-For å lette ekstern konfigurasjon og administrasjon av tilgangskontrollmodulen.

Sikkerhet var en av de største svakhetene til SNMP frem til v3. Godkjenning i SNMP versjon 1 og 2 utgjør ikke annet enn et passord (community string) sendt i klar tekst mellom en leder og agent. Hver SNMPv3 -melding inneholder sikkerhetsparametere som er kodet som en oktettstreng. Betydningen av disse sikkerhetsparametrene avhenger av hvilken sikkerhetsmodell som brukes. Sikkerhetsmetoden i v3 -mål:

  • Konfidensialitet - Kryptering av pakker for å forhindre sniking av en uautorisert kilde.
  • Integritet - Meldingens integritet for å sikre at en pakke ikke har blitt manipulert under transport, inkludert en valgfri beskyttelsesmekanisme for pakke.
  • Autentisering - for å bekrefte at meldingen er fra en gyldig kilde.

v3 definerer også USM og VACM, som senere ble fulgt av en transportsikkerhetsmodell (TSM) som ga støtte for SNMPv3 over SSH og SNMPv3 over TLS og DTLS.

  • USM (brukerbasert sikkerhetsmodell) gir autentisering og personvern (kryptering) og fungerer på meldingsnivå.
  • VACM (View-based Access Control Model) bestemmer om en gitt hovedstol får tilgang til et bestemt MIB-objekt for å utføre spesifikke funksjoner og opererer på PDU-nivå.
  • TSM (Transport Security Model) gir en metode for autentisering og kryptering av meldinger over eksterne sikkerhetskanaler. To transporter, SSH og TLS/DTLS, er definert som bruker TSM -spesifikasjonen.

Fra og med 2004 anerkjenner IETF Simple Network Management Protocol versjon 3 som definert av RFC  3411 - RFC  3418 (også kjent som STD0062) som den nåværende standardversjonen av SNMP. Den IETF har utpekt SNMPv3 en full Internett-standard , det høyeste modenhetsnivå for en RFC. Den anser tidligere versjoner for å være foreldede (betegner dem på forskjellige måter "historisk" eller "foreldet").

Gjennomføringsproblemer

SNMPs kraftige skrivefunksjoner, som ville tillate konfigurasjon av nettverksenheter, blir ikke fullt utnyttet av mange leverandører, delvis på grunn av mangel på sikkerhet i SNMP -versjoner før SNMPv3, og delvis fordi mange enheter ganske enkelt ikke kan konfigureres via individuelle MIB -objektendringer.

Noen SNMP -verdier (spesielt tabellverdier) krever spesifikk kunnskap om tabellindekseringsordninger, og disse indeksverdiene er ikke nødvendigvis konsistente på tvers av plattformer. Dette kan forårsake korrelasjonsproblemer når du henter informasjon fra flere enheter som kanskje ikke bruker det samme tabellindekseringsskjemaet (for eksempel henter diskutnyttelsesberegninger, der en bestemt diskidentifikator er forskjellig på tvers av plattformer.)

Noen store utstyrsleverandører har en tendens til å utvide sine proprietære kommandolinjegrensesnitt (CLI) sentriske konfigurasjons- og kontrollsystemer.

I februar 2002 ga Carnegie Mellon Software Engineering Institute (CM-SEI) Computer Emergency Response Team Coordination Center (CERT-CC) ut en veiledning om SNMPv1, etter at Oulu University Secure Programming Group utførte en grundig analyse av håndtering av SNMP-meldinger. De fleste SNMP -implementeringer, uavhengig av hvilken versjon av protokollen de støtter, bruker den samme programkoden for dekoding av protokollen dataenheter (PDU) og problemer ble identifisert i denne koden. Andre problemer ble funnet med dekoding av SNMP -felle -meldinger mottatt av SNMP -administrasjonsstasjonen eller forespørsler mottatt av SNMP -agenten på nettverksenheten. Mange leverandører måtte utstede oppdateringer for sine SNMP -implementeringer.

Sikkerhetsimplikasjoner

Bruke SNMP til å angripe et nettverk

Fordi SNMP er designet for å tillate administratorer å overvåke og konfigurere nettverksenheter eksternt, kan den også brukes til å trenge inn i et nettverk. Et betydelig antall programvareverktøy kan skanne hele nettverket ved hjelp av SNMP, derfor kan feil i konfigurasjonen av lese-skrive-modus gjøre et nettverk utsatt for angrep.

I 2001 ga Cisco ut informasjon som indikerte at SNMP-implementeringen av Cisco IOS , selv i skrivebeskyttet modus, er sårbar for visse denial of service- angrep. Disse sikkerhetsproblemene kan løses gjennom en IOS -oppgradering.

Hvis SNMP ikke brukes i et nettverk, bør det deaktiveres på nettverksenheter. Når du konfigurerer skrivebeskyttet SNMP-modus, bør du være nøye med konfigurasjonen av tilgangskontrollen og fra hvilken IP-adresser SNMP-meldinger godtas. Hvis SNMP -serverne identifiseres med IP -adressen deres, har SNMP bare lov til å svare på disse IP -ene, og SNMP -meldinger fra andre IP -adresser vil bli nektet. Imidlertid er forfalskning av IP -adresser fortsatt et sikkerhetsproblem.

Godkjenning

SNMP er tilgjengelig i forskjellige versjoner, hver har sine egne sikkerhetsproblemer. SNMP v1 sender passord i klartekst over nettverket. Derfor kan passord leses med pakkesniffing . SNMP v2 tillater hashing av passord med MD5 , men dette må konfigureres. Nesten all programvare for nettverksadministrasjon støtter SNMP v1, men ikke nødvendigvis SNMP v2 eller v3. SNMP v2 ble spesielt utviklet for å gi datasikkerhet , det vil si autentisering , personvern og autorisasjon , men bare SNMP versjon 2c fikk godkjenning fra Internet Engineering Task Force (IETF), mens versjoner 2u og 2* ikke klarte å få IETF -godkjenning på grunn av sikkerhet problemer. SNMP v3 bruker MD5, Secure Hash Algorithm (SHA) og nøkkelalgoritmer for å tilby beskyttelse mot uautorisert datamodifisering og spoofing -angrep . Hvis det er behov for et høyere sikkerhetsnivå, kan Data Encryption Standard (DES) eventuelt brukes i krypteringsblokkkjedemodus . SNMP v3 er implementert på Cisco IOS siden utgivelse 12.0 (3) T.

SNMPv3 kan være utsatt for brutal kraft og ordbokangrep for å gjette autentiseringsnøkler eller krypteringsnøkler, hvis disse nøklene genereres fra korte (svake) passord eller passord som finnes i en ordbok. SNMPv3 tillater både levering av tilfeldige, jevnt fordelte kryptografiske nøkler og generering av kryptografiske nøkler fra et passord levert av brukeren. Risikoen for å gjette autentiseringsstrenger fra hashverdier som overføres over nettverket, avhenger av den kryptografiske hashfunksjonen som brukes og lengden på hashverdien. SNMPv3 bruker godkjenningsprotokollen HMAC - SHA-2 for den brukerbaserte sikkerhetsmodellen (USM). SNMP bruker ikke en mer sikker utfordring-håndtrykk-godkjenningsprotokoll . SNMPv3 (som andre SNMP -protokollversjoner) er en statsløs protokoll , og den er designet med en minimal mengde interaksjoner mellom agenten og manageren. Dermed ville det å innføre et utfordringsrespons-håndtrykk for hver kommando påføre agenten (og muligens selve nettverket) en byrde som protokolldesignerne anså for overdreven og uakseptabel.

Sikkerhetsmanglene til alle SNMP -versjoner kan dempes av IPsec -autentisering og konfidensialitetsmekanismer. SNMP kan også transporteres sikkert over Datagram Transport Layer Security (DTLS).

Mange SNMP -implementeringer inkluderer en type automatisk oppdagelse der en ny nettverkskomponent, for eksempel en svitsj eller ruter, blir oppdaget og avstemt automatisk. I SNMPv1 og SNMPv2c gjøres dette gjennom en fellesskapsstreng som overføres i klartekst til andre enheter. Klartekstpassord er en betydelig sikkerhetsrisiko. Når fellesskapsstrengen er kjent utenfor organisasjonen, kan den bli målet for et angrep. For å varsle administratorer om andre forsøk på å hente fellesskapsstrenger, kan SNMP konfigureres til å passere fellesskapsnavn-autentiseringsfeil. Hvis SNMPv2 brukes, kan problemet unngås ved å aktivere passordkryptering på SNMP -agenter på nettverksenheter.

Den vanlige standardkonfigurasjonen for fellesskapsstrenger er "offentlig" for skrivebeskyttet tilgang og "privat" for lese-skrive. På grunn av de velkjente standardene toppet SNMP toppen av listen over SANS-instituttets vanlige standardkonfigurasjonsproblemer og var nummer ti på SANS Topp 10 mest kritiske trusler mot Internett for år 2000. System- og nettverksadministratorer endrer ofte ikke disse konfigurasjoner.

Enten den kjører over TCP eller UDP, er SNMPv1 og v2 sårbare for IP -spoofing -angrep. Med spoofing kan angriperne omgå enhetsadgangslister i agenter som er implementert for å begrense SNMP -tilgang. SNMPv3 -sikkerhetsmekanismer som USM eller TSM forhindrer et vellykket spoofing -angrep.

RFC -referanser

  • RFC  1155 (STD 16) -Struktur og identifisering av administrasjonsinformasjon for TCP/IP-baserte internett
  • RFC  1156 (Historic) -Management Information Base for Network Management of TCP/IP-based internets
  • RFC  1157 (Historic) - En enkel nettverksadministrasjonsprotokoll (SNMP)
  • RFC  1213 (STD 17) -Management Information Base for Network Management of TCP/IP-based internets: MIB-II
  • RFC  1452 (informativ) -Sameksistens mellom versjon 1 og versjon 2 av Internett-standard Network Management Framework (foreldet av RFC  1908 )
  • RFC  1901 (eksperimentell) -Introduksjon til fellesskapsbasert SNMPv2
  • RFC  1902 (Draft Standard) - Struktur for styringsinformasjon for SNMPv2 (foreldet av RFC  2578 )
  • RFC  1908 (Standards Track) -Sameksistens mellom versjon 1 og versjon 2 av Internett-standard Network Management Framework
  • RFC  2570 (Informasjonell) -Introduksjon til versjon 3 av Internett-standard Network Management Framework (foreldet av RFC  3410 )
  • RFC  2578 (STD 58) - Management of Management Information Version 2 (SMIv2)
  • RFC  3410 (Informasjonell) - Innledning og anvendelseserklæringer for Internett Standard Management Framework
  • STD 62 inneholder følgende RFC -er:
    • RFC  3411  - En arkitektur for å beskrive Simple Network Management Protocol (SNMP) Management Frameworks
    • RFC  3412  - Behandle og sende meldinger for Simple Network Management Protocol (SNMP)
    • 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 Access Control Model (VACM) for Simple Network Management Protocol (SNMP)
    • RFC  3416  - versjon 2 av protokolloperasjonene for Simple Network Management Protocol (SNMP)
    • RFC  3417  - Transporttilordninger for Simple Network Management Protocol (SNMP)
    • RFC  3418  - Management Information Base (MIB) for Simple Network Management Protocol (SNMP)
  • RFC  3430 (eksperimentell) - Simple Network Management Protocol (SNMP) over Transmission Control Protocol (TCP) Transport Mapping
  • RFC  3584 (BCP 74) -Sameksistens mellom versjon 1, versjon 2 og versjon 3 av Internett-standard Network Management Framework
  • RFC  3826 (foreslått) -Avansert krypteringsstandard (AES) -krypteringsalgoritme i den SNMP brukerbaserte sikkerhetsmodellen
  • RFC  4789 (foreslått) - Simple Network Management Protocol (SNMP) over IEEE 802 -nettverk
  • RFC  5343 (STD 78) - Simple Network Management Protocol (SNMP) Context EngineID Discovery
  • RFC  5590 (STD 78) - Transportundersystem for Simple Network Management Protocol (SNMP)
  • RFC  5591 (STD 78) - Transportsikkerhetsmodell for Simple Network Management Protocol (SNMP)
  • RFC  5592 (foreslått) - Secure Shell Transport Model for Simple Network Management Protocol (SNMP)
  • RFC  5608 (foreslått) -ekstern autentisering Innringt brukertjeneste (RADIUS) bruk for enkle nettverksadministrasjonsprotokoll (SNMP) transportmodeller.
  • RFC  6353 (STD 78) - Transport Layer Security (TLS) Transportmodell for Simple Network Management Protocol (SNMP)
  • RFC  7630 (foreslått) -HMAC-SHA-2-godkjenningsprotokoller i den brukerbaserte sikkerhetsmodellen (USM) for SNMPv3

Se også

Referanser

Videre lesning

Eksterne linker