snmp

Click here to load reader

Post on 16-Jul-2015

63 views

Category:

Internet

2 download

Embed Size (px)

TRANSCRIPT

Universitatea Politehnica Bucuresti

Facultatea de Electronica,Telecomunicatii si Tehnologia Informatiei

SNMP

Masterand:

Matei Theodor

Cuprins:3I.Introducere

5II. Arhitectura

7III.Informaia de management SNMP

8IV.Structura unui MIB

11V.Tipuri Universale

17VI.Protocolul AgentX

19VII.Versiuni SNMP

20VIII.Format mesaje SNMP v1, v2, v3

21IX.Securitatea n SNMPv1 i SNMPv2

21X.SNMPv3

221.Entiti SNMPv3

232.Securitatea n SNMPv3

24XI.Concluzii:

25Bibliografie:

I.Introducere

Oameni principali care au stat la originea conceptului SNMP sunt:

Keith McCLOGHRIE

Marshall ROSE

Jeffrey D. CASE

Mark FEDOR

Martin Lee SCHOFFSTALL

James R. Davin.

La nceput n 1988, nu a fost nevoie de un instrument de administrare pentru reea in special pentru internet .

Punctul de plecare a fost dat de IAB cu publicarea RFC 1052, n aprilie 1988. Acest RFC este o specificaie pentru standardul de management al reelei. Acesta este intitulat "IAB Recomandri pentru dezvoltarea de Internet Network Management Standards" i explic faptul c gestionarea reelei trebuie s fie:

ct mai mare posibila.

cu diversitate mare de punere n aplicare .

cu diversitate mare de administrare / management.

coperta ca strat protocol .

Din acest punct lucrurile merg mai repede. O parte important a conceptului a fost deja cunoscuta de dezvoltari anterioare, n special n jurul routerelor SGMP (Simple Gateway Protocol). RFC-urile urmtoarele sunt primele documente care se ocup cu SNMP publicat n 1988: RFC 1065 - Structura de identificare i de management al informaiei pentru TCP / IP bazate pe Internet RFC 1066 - Baza de Management Informaional pentru Network Management de TCP / IP bazate pe Internet RFC 1067 - A Simple Network Management Protocol

IAB a dorit ca trecerea de la o arhitectura la alta sa fie una usoara is posibila. n cele din urm, sincronizarea dintre cele dou protocoale a fost foarte dificila i a planului de convergen pe baza CMOT (permind TCP / IP cu gestionarea CMIS / CMIP ) a fost abandonat i, astfel, SNMP se mica nainte. Fiecare protocolul a contribuit la dezvoltarea lui. Concepia SNMP merge mai repede i RFC-urile au fost rescrie cu noi funcii. Versiunea 1.0 a fost atins n mai 1991, cu urmtoarele RFC:

RFC 1155 -Structura de identificare i de management al informaiei pentru TCP / IP bazate pe Internet .Structura de identificare a liniilor directoare de gestionare Informaii pentru nume de obiecte Descrierea modului de gestionare a informaiilor a fost structurat ntr-un tree(copac) la nivel mondial. Stabilete unele restricii pentru a pstra simplitatea protocolului. Introducerea normelor pentru atribuirea nume de obiecte.

RFC 1212 -Concise MIB,Definiii,Finalizarea procesului de RFC 1515 cu definiiile tehnice. mbuntete tehnici definite n RFC 1155.

RFC 1213 -Baza de Management Informaional pentru Network Management de TCP / IP bazate pe Internet: MIB-II Acest memo definete a doua versiune a Information Management Baza (MIB-II) de a se utiliza cu protocoalele de management ale reelei n TCP / IP bazate pe Internet. O list de peste 100 de variabile. Necesare pentru a menine setrile, statutul i statistici ale sistemelor de operare a reelei. RFC 1157 A Simple Network Management Protocol (SNMP) Definiii de mesaje care pot fi schimbate ntre staia de gestionare i entitatea care a reuit s citesca sau s actualizeze valori. Definiii de mesaje de alarm ( SIFON ) trimise ctre sistemul n stare de stres. Definiii ale formatului mesajului i detalii ale protocolului de comunicare.

Diferite grupuri de lucru contribuie la dezvoltarea i deschiderea protocolului prin construirea MIBs pentru toate tipurile de echipamente de reea ( Bridge , Router , Hub, ASCII monitoare, interfa WAN, DS1, DS3, X25 , Frame Relay, Ethernet, Token Ring , FDDI . furnizori ..) i, de asemenea protocoale.

n noiembrie 1991 sunt publicate cerinele pentru integrarea de sonde. Acesta sonda capta pasiv traficul pe un segment de LAN pentru o analiz ulterioar. Aceasta susine statisticile de trafic, defalcare cauzate de protocol, sursa, destinaia i alte criterii. O retea de manageri cu monitorizare este capabila de a stabili pragul stabilit n monitorizarea i staile de gestionare care trebuie s primeasc mesaje de alert.

Aprilie 1993, SNMP V2 devine un standard. Acesta ofera caracteristici noi, care completeaz cteva lipsuri din versiunea anterioar, cum ar fi securitatea i autentificarea. Aceast versiune este criticat pentru c a introduce complexitate i un eec de compatibilitate cu V1.

n cele din urm n 1997, un grup care fuzioneaz este creat. Principalul subiect: a crearea SNMP V3 . Termenul de SNMP (Simple Network Management Protocol) este utilizat pentru a ne referi la o colecie de specificaii pentru managementul reelelor, care include protocolul nsui, definiiile pentru structurile de date i conceptele asociate.

II. Arhitectura

TCP/IP include urmtoarele elemente:

Staia de management

Agentul de management

Protocolul de management de reea

MIB-urile

Staia de management este de obicei un echipament independent sau poate fi doar o capabilitate implementat ntr-un sistem partajat. Ea servete drept interfa pentru gestionarea reelelor de ctre administratori. O staie de management va avea cel puin:

Un set de aplicaii de management pentru analiza datelor, recuperarea erorilor etc.

O interfa prin care administratorul poate monitoriza i controla reeaua.

Capabilitatea de a realiza, pe baza cerinelor administratorului de reea, monitorizarea i contrololul efectiv al elementelor din reea.

O baz de date de informaii extrase din MIB-urile tuturor entitilor de management din reea.

Un alt element activ din sistemul de gestiune al unei reele este agentul de management.

Platforme la cheie cum ar fi host-uri bridge-uri, routere, hub-uri pot fi echipate cu ageni de SNMP pentru a putea fi administrate de pe staiile de management. Agenii de management rspund la cererile de informaii ale staiilor de management i pot pune la dispoziie staiilor de management, n mod asincron, informaii importante solicitate de acestea.

Resursele din reea pot fi gestionate prin reprezentarea acestora ca obiecte. Fiecare obiect este, n esen, o variabil care reprezint o proprietate a agentului de management.

O colecie de astfel de obiecte este cunoscut sub numele de MIB (management information base).

O staie de management poate face ca o anumit aciune s aib loc la nivelul agentului sau poate schimba setrile de configurare ale acestuia, modificand valorile unor variabile.

Staia de management i agenii comunic ntre ei printr-un protocol de reea. Protocolul folosit pentru administrarea reelelor de TCP/IP este SNMP (Simple Network Management Protocol) care include urmtoarele funcionaliti cheie:

get: utilizat de staia de management pentru a afla valorile obiectelor agentului de management

set: utilizat de staia de management s seteze valorile obiectelor agentului de management

trap: utilizat de agent pentru a notifica staia de management de evenimente importante.

Standardul nu specific numrul de staii de management sau raportul dintre staiile de management i ageni. n general este mai bine s avem cel puin dou sisteme de management, pentru siguran n caz de erori. O alta problem este una practic, i anume ct de muli ageni pot fi administrai de o singur staie de management. SNMP a fost proiectat ca un protocol de nivel aplicaie care s fie parte a suitei de protocoale TCP/IP. Acesta opereaz peste UDP (User Datagram Protocol) . ntr-o staie de management independent, un proces de management controleaz accesul la MIB-ul central al staiei de management i pune la dispoziie o interfa cu administratorul de reea. Procesul de management realizeaz managementul de reea utilizand SNMP, care este implementat peste UDP, IP i alte protocoale importante de reea (cum ar fi Ethernet, X.25).

Fiecare agent trebuie de asemenea s implementeze SNMP, UDP i IP. n plus un proces interpreteaz mesajele de SNMP i controleaz MIB-ul agentului.

Deoarece SNMP este implementat peste UDP i acesta nu este un protocol orientat pe conexiune, protocolul SNMP nu este nici el orientat pe conexiune. Nici o conexiune nu este meninut ntre staia de management i agenii ei.

Daca staia de management este responsabil de un numr mare de ageni i dac fiecare agent menine un numr mare de obiecte, atunci aceasta devine nefolosibil dac se fac citiri regulate ale obiectelor tuturor agenilor. De aceea SNMP i MIB-urile asociate sunt gndite s ncurajeze administratorul s foloseasc mesajele de tip trap.

Strategia preferat este urmatoarea. La iniializare i la diverse intervale de timp (uneori o zi) staia de management poate face o citire a obiectelor importante ale tuturor agenilor pe care i cunoate, cum ar fi obiectele care conin statistici de baz , de exemplu numrul de pachete trimise i recepionate prin fiecare interfa pe parcursul unei anumite perioade de timp. Odat ce aceste informaii au fost actualizate, staia de management nu mai face nici o citire dar fiecare agent este responsabil s notifice staia de management pentru orice eveniment deosebit cum ar fi repornirea agentului, o eroare apruta n agent, suprancrcarea agentului. Aceste evenimente sunt communicate prin mesaje SNMP numite trap-uri.

Odat ce staia de management este anunat n legatur cu o condiie de excepie, aceasta poate alege s citeasc valorile obiectelor agentului care a raportat excepia i probabil i ale altor ageni din apropiere pentru a putea identifica orice problem i a obine ct mai multe informaii despre condiiile n care a aprut excepia.

Actualizarea datelor bazat pe mesaje de tip trap salveaz o parte substanial din capacitatea reelei i a timpului de procesare a agentului. Reeaua nu trebuie ncarcat cu informaii care nu sunt necesare staiei de management i agenii nu trebuie s fie ncrcai cu cereri frecvente pentru informaii care nu sunt importante.

Utilizarea protocolului SNMP presupune ca toi agenii, ca i staia de management, s suporte o suit comun de protocoale cum ar fi UDP i IP. Aceasta face ca unele bridge-uri i modem-uri, care nu suport o parte din aceasta suit de protocoale s nu suporte nici SNMP. Mai mult dect atta, pot fi foarte multe sisteme mici care nu implementeaz TCP/IP pentru applicaiile care trebuie s ruleze pe ele i pe care resursele hardware sunt att de limitate nct nu se consider o soluie bun adaugarea acestor protocoale i a agentului de SNMP.

SNMP-ul a fost proiectat astfel nct s fie un utilitar de administrare de reea usor de implementat care s poat fi folosit s satisfac nevoile administrrii unei reele pe termen scurt.

Setul de standarde pentru SNMP pun la dispoziie un cadru pentru definirea informaiilor de management i a protocolului utilizat pentru schimbul de informaii.

Modelul SNMP presupune existena unui manager i a agenilor. Un manager este modulul software ntr-un sistem de management, responsabil pentru administrarea unei pri sau a ntregii configuraii sub controlul aplicaiilor de reea i a utilizatorilor.

Un agent este un modul software ntr-un dispozitiv administrabil, responsabil pentru meninerea informaiei locale de management i de trimiterea informaiei catre manager via SNMP. Un schimb de informatie de management poate fi iniiat de manager (prin operaia de get) sau de agent (prin tarp-uri).

III.Informaia de management SNMP

Ca n cazul oricrui sistem de management de reea, baza de date a sistemului de gestiune de reea bazat pe TCP/IP este o baz de date care conine informaii despre elementele care pot fi administrate. i n TCP/IP i n OSI, baza de date este numit baz de informaii de administrare - MIB (management information base). MIB-ul este o colecie structurat de obiecte.

Pentru SNMP, MIB-ul este n esen o structura de baz de date reprezentat printr-un arbore n care nodurile sunt obiectele. Fiecare sistem (server, router, bridge, etc.) dintr-o reea menine un MIB care reflect starea resurselor administrate n sistem. O entitate de management a reelei poate monitoriza resursele acelui sistem prin citirea valorilor obiectelor din MIB i poate controla resursele acelui sistem modificnd acele valori.

Pentru ca MIB-ul s serveasc toate cerinele unui sistem de management de reea, el trebuie s indeplineasc anumite obiective:

1.Obiectul sau obiectele utilizate s reprezinte o resurs anume, trebuie s fie aceleai n fiecare sistem. De exemplu, s cosiderm informaia referitoare la entitatea TCP ntr-un sistem. Numrul total de conexiuni deschise pe parcursul unei perioade de timp reprezint suma tuturor conexiunilor pasive i active. MIB-ul poate stoca doar doua din cele trei valori relevante (numrul de conexiuni active, pasive i numrul total de conexiuni), pentru ca cel de al treilea poate fi calculat dac este cazul. Dac sisteme diferite aleg perechi diferite pentru a fi stocate, este dificil s se scrie un protocol simplu pentru a accesa informaia cerut. Definiia MIB-ului pentru TCP/IP specific s fie stocate numarul de conexiuni active i pasive.

2.Trebuie folosit o modalitate comun de reprezentare pentru a suporta interoperabilitatea.

Al doilea punct este realizat prin definirea unei structuri de management a informatiei. Primul punct este realizat prin definirea obiectelor i structurarea acelor obiecte n MIB.

Structura informaiei de management (care este specificat n RFC-ul 1155 [RFC1155]) defineste un cadru general n care un MIB poate fi definit i construit. Sistemul de management al informaiei (SMI) defineste tipuri de date care pot fi folosite n MIB i specific cum sunt resursele din MIB reprezentate i denumite. Filozofia pe care se bazeaz SMI-ul este de a ncuraja simplicitatea i extensibilitatea MIB-urilor. MIB-ul poate stocadoar tipuri de date simple, scalari i tablouri bidimensionale de scalari. Protocolul SNMP poate citi doar scalarii, incluzndu-i pe cei din tabele.

Sistemul de management al informaiei nu suport creerea de tipuri de date complexe pentru a simplifica implementarea i interoperabilitatea. MIB-urile vor conine n mod inevitabil date definite de diveri productori dac nu ar fi aceste restricii interoperabilitatea ar suferi.

Pentru a pune la dispoziie un mod standardizat pentru reprezentarea informaiei de management, Sistemul de management al informaiei trebuie:

S pun la dispoziie o tehnic standard pentru definirea structurii unui MIB anume;

S pun la dispoziie o tehnic standard pentru definirea obiectelor, incluznd sintaza i valorile pentru fiecare obiect;

S pun la dispoziie o tehnic pentru encodarea valorilor obiectelor;

IV.Structura unui MIBUn MIB este o structur de baz de date reprezentat printr-un arbore n care nodurile sunt obiectele administrate, fiecare din ele reprezentnd cte o resurs, activitate sau alta informaie care trebuie administrat.

Fiecare tip de obiect definit n MIB are asociat un identificator de tip OBJECT IDENTIFIER din ASN.1.

Un identificator de obiect este un identificator unic pentru un tip particular de obiect. Valoarea lui const ntr-o secvent de ntregi. Mulimea identificatorilor de obiectelor definite are o structur arborescent, unde rdacina arborelui este un identificator de obiect definit n standardul ASN.1. ncepnd cu rdcina arborelui de identificatori de obiecte fiecare valoare a unei componente a identificatorului de obiect reprezint un arc n arbore.

ncepnd cu root-ul, sunt trei noduri la primul nivel: iso, ccitt i join-iso-ccitt. Sub nodul iso este un subarbore folosit de alte organizaii, unul pentru U.S Departament of Defense (dod). RFC 1155 [RFC1155] face presupunerea c un subarbore de sub dod va fi alocat pentru administrare de Internet Activity Board dup cum urmeaz:

Astfel nodul internet are ca valoare 1.3.6.1. Aceasta valoare servete ca prefix pentru nodurile de la urmtorul nivel al arborelui.

Pe urmtorul nivel sunt definite urmtoarele noduri:

directory: reservat pentru utilizri ulterioare

mgmt: utilizat pentru obiecte definite n documente aprobate de IAB (Internet Architecture Board)

experimental: utilizat pentru a identifica obiecte folosite n experimente legate de Internet

private: utilizat pentru a identifica obiecte definite unilateral

Subarborele mgmt conine definiiile bazei de informaii de management care a fost aprobat de IAB. n prezent, doua versiuni de MIB au fost dezvoltate: mib-1 i mib-2. A doua versiune este de fapt o extensie a primei. Amandou au ca radacin a arborelui acelai identificator deoarece doar una din cele doua versiuni va fi prezente n orice configuraie.

Alte obiecte pot fi definite ntr-un MIB prin una dintre modalitile de mai jos:

1.Subarborele mib-2 poate fi extins sau nlocuit complet de o nou revizie (mib-3). Pentru a extinde mib-2, un nou subarbore trebuie definit. De exemplu MIB-ul pentru monitorizarea reelelor ndeprtate, este definit ca al aisprezecelea subarbore sub mib-2.

2.Poate fi construit un MIB experimental pentru o aplicaie anume. Astfel de obiecte vor fi poziionate n subarborele mgmt.

3.Extensii particulare (definite de diveri productori) pot fi incluse n subarborele private. Unul dintre ele este definit n RFC-ul 1227 (MUX MIB).

Subarborele private are acum definit doar un nod copil numit enterprise.

Acest poriune de subarbore este folosit pentru a permite diversilor producatori s mbunateasc administrarea produselor lor i s partajeze informaia cu ali utilizatori i producatori mpreun cu care trebuie s asigure interoperabilitatea sistemelor lor. Cte un subarbore n subarborele enterprise este alocat pentru fiecare productor care se nregistreaz pentru un identificator de obiect enterprise.

Ramificarea nodului internet n patru subarbori pune la dispoziie un fundament bun pentru evoluia MIB-urilor. Cum producatorii i ali implementatori experimenteaz noi obiecte, ei au avantajul de a ctiga destul de mult prin promovarea lor nainte ca se s fie acceptate ca parte a unor specificaii standardizate i includerea lor n subarborele mgmt.

Sintaxa unui obiect

Fiecare obiect dintr-un MIB SNMP este definit ntr-un mod formal; definiia specific tipul de date a obiectului, intervalul de valori admise i relaia cu alte obiecte din MIB. Notaia ASN.1 este folosit pentru definirea fiecrui obiect individual din MIB i pentru definirea ntregii structuri a MIB-ului. Pentru a pstra ideea de simplicitate, doar un subset restrns de elemente i faciliti din ASN.1 sunt folosite.

V.Tipuri Universale

Exist o clasa de tipuri UNIVERSALE n ASN.1 care const n tipuri de date independente de aplicaii care sunt de uz general. n cadrul clasei UNIVERSALE doar urmatoarele tipuri de date sunt permise s fie folosite pentru a defini obiectele dintr-un MIB:

integer (UNIVERSAL 2)

octetstring (UNIVERSAL 4)

null (UNIVERSAL 5)

object identifier (UNIVERSAL 6)

sequence, sequence-of (UNIVERSAL-16)

Primele patru sunt tipuri primitive care sunt folosite ca baz pentru alte tipuri de obiecte. De remarcat c tipul enumerated nu este inclus. Mai mult cand o list de ntregi trebuie definit, ea va fi definit folosind tipul integer. Valoare 0 nu poate fi folosit. Aceasta permite diverselor erori de implementare s fie mai usor de prins.

Identificatorul de obiect este un identificator unic al unui obiect constnd ntr-o secven de ntregi, numii subidentificatori. Secvena se citeste de la stnga la dreapta, definete locaia obiectului n structura arborescent a MIB-ului. De exemplu obiectul tcpConnTable este derivat dup cum urmeaz:

iso org dod internet mgmt mib-2 tcp tcpConnTable 1 3 6 1 2 1 6 13Acest identificator ar trebui s fie, n mod normal, scris 1.3.6.1.2.1.6.13.

Ultimul element din lista precedenta const dintr-un constructor de tipuri sequence i sequence-of. Aceste tipuri sunt folosite pentru a defini tabele.

Tipuri utilizate des n aplicaii

Clasa APLICATION n ASN.1 const n tipuri de date care sunt relevante pentru aplicaii particulare. Fiecare aplicaie incluznd SNMP, este responsabil pentru definirea propriilor tipuri de date APLICATION.

RFC 1155 listeaz un numr de tipuri de date larg rspndite n aplicaii, altele vor putea fi definite n documentele RFC noi. Urmtoarele tipuri sunt definite:

NetworkAddress: Acest tip este definit utiliznd construcia CHOICE, pentru a permite selecia de adrese formate dintr-una sau mai multe familii de protocoale.

IpAddress: Aceasta este o adresa pe 32 de bii folosind un format specific IP-ului.

Counter: Acesta este un ntreg nenegativ care poate fi incrementat dar nu i decrementat.

Gauge: Acesta este un ntreg nenegativ care poate fi decrementat i incrementat.

Timeticks: Este un ntreg nenegativ care contorizeaz timpul n sute de secunde.

Opaque: Acest tip suport capabilitatea de a timite date arbitrare. Datele sunt codificate ca OCTET STRING pentru transmisie. Datele pot fi n orice format definit de ASN.1 sau alta sintax.

Tipul Counter, cunoscut de asemenea ca rollover counter,este unul dintre cele mai utilizate tipuri n definirea obiectelor. Scopul unor aplicaii este de a contoriza numrul de pachete sau de octei trimisi sau receptionai.

Un tip alternativ pentru Counter, pe care cei care au definit SMI-ul l-au luat n considerare, este latch counter, care se oprete la cea mai mare valoare posibil i apoi trebuie resetat. Conform [SNMPRMON], el nu este folosit din cauza urmtoarelor probleme care ar putea s apar. S presupunem c mai multe sisteme de management pot accesa un obiect de tip Counter anume, asta inseamn mai multe sisteme de monitorizare pot accesa dispozitivul monitorizat. Cnd mai multe sisteme pot accesa acel counter care a atins valoarea maxim, sunt mai multe alternative de rezolvare a problemei:

1.Se poate desemna doar un sistem de management care s fie responsabil pentru resetarea contorului. Problema este ca daca acel sistem este oprit din diverse motive sau eueaz n aceast operaie, contorul ramne blocat la cea mai mare valoare.

2.S se permit mai multor sisteme s reseteze acel contor cnd este cazul. n acest caz mai multe sisteme pot reseta contorul, acest fapt ducnd la pierderea unei informaii importante.

Utiliznd contoarele rollover, aceste dificulti sunt evitate. n schimb dup ce un astfel de contor este automat resetat de cateva ori, este dificil pentru un sistem de management s stie daca valoarea x a contorului este de fapt x sau ((N*maxim_value)+x). Singura soluie de a rezolva aceasta problem este s se citeasc destul de des valoarea contorului de ctre toate sistemele de management.

De obicei tipul Gauge este folosit pentru a masura valoarea curent a unei entiti cum ar fi numarul de pachete stocate ntr-o coad. O alt utilizare este s se depoziteze valoarea unei entitai de la nceput pn la sfritul unui interval de timp. Aceasta face ca un astfel de tip s fie utilizat pentru a monitoriza rata schimbrilor valorii unei entitai.

Tipul Gauge este de asemenea asemnator cu latched counter deoarece atunci cand atinge valoarea maxima el nu este automat resetat la 0. Mai mult, daca valoarea unui obiect de acest tip este incrementat peste valoarea maxima suport, el ramne blocat la valoarea maxim.

Soluii pentru rezolvarea unei astfel de situai sunt:

1.Se poate permite s se decrementeze valoarea obiectului de acest tip

2.Poate rmne blocat la valoarea maxim pn este resetat de catre sistemul de management.

Tipul timeticks este folosit pentru un timer relativ. Timpul este msurat relativ la un eveniment (cum ar fi timpul de pornire a dispozitivului monitorizat sau reiniializarea lui) din sitemul administrat. Valoarea unui astfel de timer nu poate fi direct comparat cu valoarea unui alt timer de pe un alt sistem.

Unii ar fi preferat un timp absolut utiliznd reprezentarea ASN.1. Din pcate, majoritatea sistemelor care suport suita de protocoale TCP/IP nu suport un protocol de sincronizare a timpului ceea ce face ca un timp absolut sa nu poat fi folosit n SNMP.

Un tip considerat important de William Stallings n [SNMPRMON], dar care nu este folosit n SNMP, este threshold type. Un astfel de tip poate fi folosit n urmtorul mod: dac valoarea maxim este depsit (limita negativ sau pozitiv), un eveniment este trimis ctre staiile de management. Cei care au lucrat la proiectarea SMI s-au gndit c aceast capabilitate ar putea conduce la trimiterea prea multor evenimente n reea. Un alt tip periculos de eveniment este cel provocat de o congestie. ncrcarea reelei cu astfel de evenimente nrutaete situaia. Oricum Remote Monitoring MIB (RMON) definete un astfel de tip.

Un MIB const ntr-un set de obiecte. Fiecare obiect are un tip i o valoare. Tipul obiectului definete un tip particular de obiect care poate fi administrat. Definirea unit tip de obiect este mai mult o descriere sintactic. O instan a unui obiect este o instan particular a unui tip care a primit o valoare anume.

ASN.1 include un set de tipuri universale predefinite si o gramatica pentru definirea de noi tipuri care sunt definite din tipurile existente. O alternativ pentru definirea obiectelor ar fi definirea unui nou tip numit OBJECT si atunci fiecare obiect din MIB-ul respectiv ar fi de tipul OBJECT. Aceast abordare este tehnic posibil dar ar rezulta o definire prea general. De obicei este nevoie s se foloseasc o mare varietate de tipuri. n plus MIB-urile suport definirea tablourilor bidimensionale sau vectori de valori.

Deoarece obiectele pot conine o varietate de informaii acestea reprezentnd o varietate de entiti, este nevoie de o varietate foarte mare de tipuri, unul pentru fiecare categorie general de obiecte. Aceasta s-ar putea defini direct n ASN.1. Oricum nici aceasta nu este o variant bun pentru c daca restricia n ceea ce priveste definiia unui nou tip de obiect ar fi ca aceasta sa fie scrisa n ASN.1, ar nsemna s existe multe variaii n formatul definiiilor obiectelor. De altfel, utilizarea definiiilor de tipuri de obiecte ntr-un mod nestructurat complic utilizarea protocolului SNMP.

O alternativ mult mai abstract utilizat pentru SNMP este utilizarea unui macro pentru definirea unui set de tipuri apropiate utilizate la definirea obiectelor. O definiie a unui macro stabilete sintaxa unui set de tipuri asemanatoare, n timp ce o instan a unui macro definete un anumit tip.

Macro definition definete instanele unor macrouri; specific sintaxa unui set de tipuri nrudite

Macro instance este o instan generat dintr-un macro specific pe baza unor argumente pentru parametrii macro-ului; specific un tip particular

Macro instance value reprezint o intrare cu o valoare specific

Macro-urile utilizate pentru MIB-urile de SNMP au fost iniial definite n RFC 1155 (Structura informaiei de management) i extins mai trziu n RFC 1212 (Definiia concis a MIB-ului). RFC-ul 1155 este utilizat pentru definirea obiectelor n MIB-I. RFC-ul 1212 este utilizat n definirea obiectelor n MIB-II.Mai jos este prezentat definiia macroului OBJECT-TYPE din [RFC1212]. Componentele cheie sunt urmtoarele:

SYNTAX: sintaxa abstract pentru tipul unui obiect

ACCESS: definete modul n care o instan a unui obiect poate fi accesat via SNMP sau un alt protocol

STATUS: indic regulile de implementare cerute pentru acest obiect. Acestea pot fi mandatory sau opionale

DescrPart: o descriere textual a semanticii tipului obiectului respectiv. Aceast clauz este opional

ReferPart: o referin textual la un obiect definit ntr-un alt MIB. Aceasta este o clauz opional .

IndexPart: utilizat n definirea tabelelor. Acest clauz poate fi prezent doar dac tipul obiectului respectiv corespunde unei linii conceptuale.

DefValPart: definete o valoare implicit acceptabil care poate fi utilizat cnd instana obiectului este creat la dorina unui agent. Clauza aceasta este opional.

VALUE NOTATION: Acesta indic numele utilizat pentru a accesa obiectul via SNMP.

VI.Protocolul AgentX

Protocolul AgentX permite mai multor subageni s fac informaia dintr-un MIB disponibil ntr-un mod transparent aplicaiilor de management bazate pe SNMP.

AgentX este prima specificaie standardizat de IETF pentru agenii extensibili de SNMP (conform [STAgentX]). nainte de publicarea protocolului AgentX n [RFC2741], utilizatorii erau nevoii s foloseasc soluii nestandard sau s porneasc mai muli ageni de SNMP pe porturi diferite de UDP, folosind proxy-uri pentru a le accesa printr-un port standard de SNMP. Amndou abordri sunt dificile. Lipsa unui standard cere adesea ca implementatorii de subageni de SNMP s trebuiasc s suporte mai multe protocoale de subageni de SNMP dac acelai agent este suportat pe sisteme diferite de operare.

AgentX-ul pune la dispoziie o soluie standard pentru problema extinderii agenilor de SNMP. Acesta este proiectat s fie independent de orice versiune de SNMP. Un subagent AgentX va lucra cu un agent master SNMPv1, SNMPv2 sau SNMPv3 far nici o schimbare.

Protocolul AgentX specific o metod de a informa agentul master despre informaia pe care o va avea n responsabilitate pentru subageni. Fiecare subagent AgentX poate opera n propriul spaiu de procese, punnd la dispoziie o alternativ mai robust agenilor monolitici de SNMP.

n plus, procesele pot pune la dispoziie accesul la starea lor intern prin protocolul AgentX, care este apoi accesibil dintr-o staie de management prin protocolul SNMP. Cum serverele si aplicaiile devin din ce n ce mai complexe, aceast facilitate devine extrem de important. Fr un mod standard de a accesa starea curent i datele proceselor server, sistemele software pot de veni greu de gestionat.

Facnd aceast informaie disponibil prin AgentX putem folosi unelte de management bazate pe SNMP.

Arhitectura unui sistem care folosete protocolul AgentX const n dou tipuri de procese (agentul master i mai muli subageni) care comunica ntre ele prin TCP/IP. Agentul master utilizeaz protocolul AgentX pentru a comunica cu subagenii i protocolul SNMP pentru a comunica cu clienii de SNMP. El este trebuie s menin o tabel n care s stocheze informaii referitoare obiectele de SNMP de care este responsabil fiecare subagent.

Cnd agentul master recepioneaz o cerere via SNMP, acesta gasete n tabela intern agentii responsabili de regiunea de MIB cerut i trimite cererea ctre subageni utiliznd protocolul AgentX.

Subagenii AgentX sunt responsabili pentru punerea la dispoziie a informaiei de management. Cnd un subagent este pornit, se conecteaz la master i nregistreaz diverse regiuni MIB pentru care are informaii. Subagentul nu trebuie s suporte i protocolul SNMP i nu trebuie s comunice cu ceilali subageni, astfel agentul master trebuie s arbitreze eventualele conflicte dintre subageni.Ca parte a serviciului de arbitrare, agentul master pune la dispoziie un serviciu de alocare a indecilor i rezolv suprapunerile diverselor reginui MIB nregistrate, ntr-o manier deterministic.

Alocarea indecilor este un serviciu pus la dispoziie pentru a permite nregistrarea liniilor unei tabele SNMP dintr-un MIB. De exemplu, dac subagentul dorete s nregistreze o linie din tabela ifTable ([RFC2233]), acesta poate cere alocarea unui indecs pentru coloana ifIndex (care este indexul tabelei). n funcie de parametrii cererii, agentul master va ncerca s-i acorde un index anume, unul care nu este folosit la momentul respectiv sau unul care nu a fost folosit niciodat pentru tabela respectiv.

Cnd un subagent dorete s declare ca este rspunztor de un set de OID-uri, acesta trimite o cerere agentului master. nainte de asta, subagentul poate fi nevoit s cear alocarea indexului nregistrat. O ntegistrare se termin cu succes dac nu cauzeaz ambiguitate n legtur cu regiunea nregistrat. Dac apare o situaie de ambiguitate (un alt subagent a nregistrat o parte din regiunea specificat), agentul master va decide crui din cei doi subageni va aloca regiunea comun n funcie de lungimea celui mai mare OID nregistrat de ficare dintre subageni i n funcie de prioritatea specificat de subagent.

Setul de faciliti ale protocolului AgentX este gndit s permit protocolului s fie transparent cu staiile de management SNMP i s elimine orice necesitate de comunicare ntre subageni. Sunt cteva faciliti specificate n protocol, care fac acest protocol foarte transparent:

Operaiile set de SNMP sunt atomice. AgentX-ul respect aceast proprietate a SNMP-ului chiar dac OID-urile specificate in cereri sunt nregistrate la subageni diferii. Aceast proprietate este realizat prin folosirea commmit-ului n doua faze.

Agentul master este responsabil cu rezolvarea conflictelor legate de indecii tabelelor SNMP, astfel nct mai muli subageni s poat pun la dispoziie accesul la informaia de management n linii separate ale aceleiai tabele SNMP. Atta timp ct toi subagenii utilizeaz agentul master pentru a aloca indeci n tabele nainte de a le nregistra, se poate garanta ca nu va fi niciun conflict la nregistrare.

Agentul master este responsabil cu rezolvarea i nregistrarea conflictelor care apar prin ncercrile subagenilor de a nregistra regiuni de MIB duplicate sau care se suprapun. Aceasta face ca subagenii s nregistreze regiunile specifice aplicaiilor implementate.

VII.Versiuni SNMP

Scopul SNMP este de a oferi un set simplu de operaii (i informaii pe care aceste operaii le obin) care dau administratorului posibilitatea de a afla i schimba starea unor echipamente,

cu condiia s aib implementat acest protocol. A existat un predecesor numit SGMP (Simple

Gateway Management Protocol) care a fost gndit doar pentru a controla routere din Internet.

Spre deosebire de acesta, SNMP poate controla diverse sisteme de operare i echipamente. El

este elementul central al Internet Standard Management Framework (ISMF) care conine

dou tipuri de entiti SNMP (manageri i ageni), un protocolul de transfer a informaiei i

informaia propriu zis de management. Proiectanii IETF au dezvoltat pn acum trei versiuni majore de protocol. Acestea sunt prezentate n Tabelul 2.1.VersiuneDescriere

SNMPv1A fost gndit ca un protocol simplu i robust pentru managementul

reelelor IP, mai ales pentru partea de configurare i defecte.

Rezultatul a fost un protocol acceptat de marea majoritate a productorilor, i astfel aproape toate echipamentele au suport pentru SNMP. Dezavantajul este c nu are suport dect pentru reele IP, este ineficient la transferul unor cantiti mari de

informaie, i practic este fr nici un mecanism de securitate

SNMPv2Aceast versiune a ncercat s elimine dezavantajele primei versiuni, ns a fost dificil s se gseasc o soluie agreat de toat lumea i de aceea au aprut mai multe versiuni ale acestui standard. Din pcate n industrie a existat reticent la implementarea acestui protocol

SNMPv2pSNMPv2p a adus mbuntiri protocolului de comunicare, la partea de operaii, tipuri de date i unele mbuntiri la mecanismul de securitate.

SNMPv2cAceast versiune este numit community string-based SNMPv2.

Folosete acelai mecanism de securitate ca i SNMPv1 bazat pe nume de comunitate.

SNMPv2uLa fel ca i SNMPv2c, dar a mbunatatit sistemul de securitate, prin introducerea unui mecanism de autentificare criptat.

SNMPv3Versiunea 3 a adus schimbri mari nu numai la protocol n sine dar i la conceptele din sistemul de management. Permite securitate bazat pe criptografie, permind protecie prin autentificare.

Un manager este un echipament (un server) denumit NMS (Network Management Station) pe

care ruleaz un sistem de operare capabil s ofere servicii de management pentru reea. El

este responsabil pentru interogarea i primirea de notificri din partea agenilor din reea. Al

doilea tip de entitate, agentul, este un program care ruleaz n echipamentele din reea care

sunt gestionate. Poate fi un program independent (un daemon) sau poate fi integrat n

sistemul de operare al echipamentelor.VIII.Format mesaje SNMP v1, v2, v3

SNMP folosete UDP (User Datagram Protocol) ca i protocol de strat transport pentru a

transfera date ntre manager i agent. El a fost ales n defavoarea protocolului TCP pentru c

este neorientat pe conexiune, nsemnnd c nu trebuie stabilit o legatur prealabil ntre

agent i manager. Acest lucru poate introduce probleme suplimentare, din cauz c nu exist

confirmri pentru pachetele transmise i pierdute. Rmne n sarcina aplicaiei SNMP s

determine dac pachetul a fost pierdut i s ncerce retransmisia dac se dorete.

Protocolul de comunicaie n SNMP se bazeaz pe operaii de cerere de informaii i primirea

rspunsului. Un mesaj SNMP conine o unitate de mpachetare a datelor (PDU) la care se

adaug un antet (coninutul acestuia difer de la o versiune de SNMP la alta). Un agent

SNMP va trimite informaii n dou cazuri :

1. ca rspuns la o cerere formulat de manager

2. cnd are loc un eveniment i se genereaz o notificare

n versiunea 1 a protocolului au fost definite urmtoarele tipuri de operaii care pot fi folosite

de ctre manager i agent.Nume operaieDirecie DescriereDescriere

GetManager AgentAccesarea valoarea unui obiect din agentul SNMP

Get-NextManager AgentAccesarea tuturor obiectelor din MIB, prin citirea

acestor n mod secvenial

SetManager AgentSchimbarea valorii curente a unui obiect din MIB

Get-ResponseAgent ManagerRspuns la Get, Get-Next i Set

TrapAgent ManagerNotificarea unui SNMP manager de apariia unor

evenimente

Tabelul 2.3 Operaii definite n SNMPv1n versiunea 2 a standardului au fost adugate urmtoarele tipuri de operaii:

Nume operaieDirecieDescriere

Get-BulkManager AgentAccesarea unor informaii n cantiti mari,minimiznd numarul de mesaje schimbate

NotificationAgent ManagerAcelai tip ca i Set i Get, iniial gndit pentru

notificri

InformManager ManagerFolosit la comunicarea ntre manageri

Report--Nu a fost implementat

Tabelul 2.4 Operaii adugate n SNMPv2IX.Securitatea n SNMPv1 i SNMPv2

n ambele versiuni de protocol varianta cea mai implementat de securitate este cea bazat pe

comuniti. n SNMPv2 au fost prevzute modaliti de autentificare a utilizatorului, ele nu

prea sunt implementate. Practic SNMPv1 i SNMPv2 nu implementeaz nici o metod de

autentificare sau criptare, fiind vulnerabile la o multitudine de atacuri de securitate.

Din aceste motive, cei mai muli productori de echipamente ofer suport doar pentru

monitorizarea echipamentelor, partea de control (echivalentul operaiei set) fiind disponibil

doar prin conectare direct la echipament. Partea de securitate a fost rezolvat prin

introducerea versiunii 3 a acestui standard (SNMPv3).

X.SNMPv3

Specificaiile pentru SNMPv3 au fost aprobate de ctre IESG (Internet Engineering Steering Group) ca standard n anul 2002. Prima variant de standard (draft) fusese aprobat de acelai comitet n 1999. Principalele modificri aduse se refer la securitate i la posibilitatea de

configurare de la distan a echipamentelor. Prin modalitatea de elaborare, prima impresie

este c lucrurile difer foarte mult fa de versiunile precedente, prin introducerea de noi

convenii, concepte i terminologii. n standard este descris arhitectura global de management i se prezint mult mai detailat modalitatea de implementare a echipamentelor

care vor oferi suport pentru SNMP.

n noua arhitectura, conceptul de agent i manager nu mai exist. A fost introdus conceptul de

entitate SNMP, care poate fi manager, agent sau ambele. Mai multe detalii se gsesc n

paragrafele care urmeaz. Prin acest mod de prezentare practic se definete o arhitectur, n

loc de un simplu set de mesaje i operaii.

1.Entiti SNMPv3Structura unei entiti SNMPv3 este prezentat n Figura 2.3

Figura 2.3 Structura unei entiti n SNMPv3

n SNMPv3 motorul SNMP are rolul de a recepiona i trimite mesaje SNMP, ca la manager sau agent din vechile versiuni. Pe lng aceste funcii mai ofer servicii de

autentificare, criptare i control acces. Principalele componente sunt descrise n Tabelul 2.5.

ComponentDescriere

DispecerAre rolul de a trimite i recepiona mesaje SNMP. Determin versiunea de protocol folosit i dac versiunea este suportat

transfer mesajul spre subsistemul

de procesare mesaje

Subsistem procesare mesajePregtete mesajul care va fi transmis sau extrage datele din mesajele recepionate. Conine cte un submodul separat pentru fiecare versiune de SNMP suportat

Subsistem securitateSe ocup de autentificare i criptarea datelor

Subsistem control accesControleaz accesul la obiectele din MIB.

Tabelul 2.5 Componentele principale ale motorului SNMPAplicaia SNMP se folosete de serviciile motorului SNMP i ofer partea de funcionalitate

deja cunoscut n SNMP. Componentele principale sunt :

ComponentDescriere

Generator comenziGenereaz cererile get, get-next, get-bulk, i set i proceseaz rspunsurile. Funciile oferite sunt specifice managerilor.

Rspuns comenziRspunde la cererile get, get-next, get-bulk, i set. Funciile oferite sunt specifice agenilor.

Generator notificriGenereaz notificri. Funciile oferite sunt specifice agenilor.

Receptor notificriRecepionez notificri. Funciile oferite sunt specifice managerilor

Proxy ForwarderImplementeaz mecanismul de transfer de mesaje ntre diverse entiti SNMP

Tabelul 2.6 Componentele principale ale aplicaiei SNMPCa i la precedentele versiuni, mesajul SNMP are dou pri : un antet i o unitate de date

protocol (PDU). Nu exist modificri la partea de unitate de date protocol, fiind la fel ca la

SNMPv2 doar c poate fi criptat dac este cazul. n schimb, antetul SNMPv3 conine

13 cmpuri importante pentru partea de identificare i autentificare.2.Securitatea n SNMPv3

Principalele obiective fixate pentru securitate n SNMPv3 se refer la:

determinarea dac un mesaj a ajuns la destinaie fr erori i n timp util

s determine dac operaia cerut poate fi efectuat, innd cont de drepturile

utilizatorului

determinarea permisiunilor pentru un mesaj recepionat n funcie de cine l-a generat

Aceste obiective sunt ndeplinite de modulele de securitate i control acces [Wij98]. SNMPv3

suport mai multe modele de securitate (definite deja sau care vor fi definite). Pentru a

menine compatibilitate ntre echipamente, fiecare echipament trebuie s implementeze

modelul USM (User-based Security Model) [Blu98]. Acest model implementeaz

urmtoarele :

autentificare autentificarea utilizatorului (poate folosi algoritmii MD5 i SHA)

Oportunitate n timp protejare mpotriva modificrii fluxului de mesaje prin

trimiterea timpului n fiecare mesaj

Criptare folosete algoritmul DES pentru criptarea i decriptarea mesajelor.

XI.Concluzii:Analiznd implementrile de ageni SNMP existente pentru IEEE 802.3, s-a constatat c ele sunt dependente de tipul de productor (Allied Telesyn, Cisco, 3COM, etc). Sunt i cazuri

cnd nu exist suport pentru implementri SNMP. S-a dorit implementarea unui agent

hardware generic care s poat fi integrat pe orice tip de echipament, indiferent de fabricant.

Conectarea spre acesta se face prin interfee seriale asincrone (SCI), sincrone (SPI) sau

paralele (GPIO pe 8 bii), iar spre reea prin interfaa EPHY de tip MII (Medium-Independent

Interface) conform cu IEEE 802.3, IEEE 802.3u. Soluia se bazeaz pe microcontrolerul

MC9S12NE64 (Freescale), care va fi utilizat i pentru alte contribuii, i MIB-II. Singura

parte dependent de echipament este reprezentat de modulele software care colecteaz

datele i le stochez n MIB-II.

Bibliografie:

[1] J.Case, K.McCloghrie, M.Rose, S.Waldbusser, Structure of Management Information for version 2 of the Simple Network Management Protocol (SNMPv2)., RFC1902, IETF, January 1996.

[2] J.Case, K.McCloghrie, M.Rose, S.Waldbusser, Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2).,RFC1905, IETF, January 1996.

[3] J.Case, D.Harrington, R.Presuhn, B.Wijnen, Message Processing and Dispatching for the Simple Network Management Protocol (SNMP).,RFC2572, IETF, April 1999.

[4] J.Case, R.Frye, J.Saperia, SNMPv3 Survival Guide, John Wiley & Sons 1999 E.Chamberlain, HowTo: Monitor Asterisk with SNMP, 2009,

http://voxilla.com/2009/02/03/configuring-asterisk-snmp-support-1131

[5] D.Choi, H.Jang, K.Jeong, P.Kim, S.Kim, Delivery and Storage Architecture for Sensed Information Using SNMP, Management of Convergence Networks and Services, Springer Berlin / Heidelberg, September 2006

[6] D.Harrington, R.Presuhn, B.Wijnen, An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks.,RFC3411, IETF, December 2002

2