Agent Snmp Pentru Colectarea Unor Statistici de Retea pe Platforma Windows

Introducere

Unul din primele lucruri pe care un administrator de rețea de calculatoare îl face este implementarea unui sistem de monitorizare a rețelei. Considerat o parte esențială a rețelei, se depune mult efort și resurse pentru a implementa și întreține un sistem de monitorizare, precum și efort și resurse pentru a interpreta rezultatele. În funcție de dimensiunile rețelei, aceste resurse necesare pot ajunge la mărimi considerabile.

Rețelele de calculatoare sunt și mai dinamice în ziua de azi față chiar de câțiva ani în urmă. Serverele sunt configurate să ruleze mai multe mașini virtuale în aceeași configurație fizică. Laptop-urile personale, tabletele și telefoanele fac tot mai mult parte din compoziția unei rețele. Variația frecventă a echipamentelor din rețea generează tipare diferite și pot duce la probleme de funcționare. Performanța rețelei poate avea un impact direct asupra operațiilor comerciale, iar acest lucru duce la dorința tot mai accentuată a adoptării unui sistem de monitorizare a rețelei.

La ora actuală, cererea pentru capacitate și viteza de transfer a datelor se află într-o creștere exponențială. De asemenea, natura traficului de rețea s-a modificat, nu se mai transmit date primare sau informații de tranzacționare , ci avem „rich media”, precum și acces mobil și aplicații dependente de timp (VoIP). In plus, monitorizarea simpla a traficului nu mai este suficienta, trebuie să asigurăm și calitatea livrării. Activitatea de tip „best effort” nu mai este suficientă, prioritizarea a devenit esențiala în a asigura calitatea transmisiei. De exemplu, este esențiala asigurarea priorității traficului de tip VoIP pentru a menține calitatea audio/video pentru conferințe.

Într-o activitate comercială, performanța rețelei poate afecta direct performanța aplicațiilor care o utilizează si, la rândul ei, afectează angajații, clienții și partenerii de afaceri. Monitorizarea rețelei ajută la identificarea nivelelor de bază ale utilizării ei, determină care aplicații generează cel mai mare trafic și colectează date statistice pentru măsurători de eficiență.

Monitorizarea rețelei este, de asemenea, un element important de securitate. În ciuda eforturilor depuse, un software malițios poate să găsească o cale spre mașini din interiorul rețelei. Odată acolo, acesta efectuează activități dăunătoare care pot fi detectate de sistemele de monitorizare a rețelei. De exemplu, software-ul malițios poate contacta un server de comandă și control pentru instrucțiuni și actualizări, sau software care adună cantități mari de date și le transmite în afara rețelei, într-un loc controlat de programatorul lui. Aceste tipuri de activități generează anomalii în tiparele de trafic normale ale rețelei și sunt susceptibile detecției.

In cele din urmă, politicile de trafic de rețea nu mai aparțin doar de domeniul IT și de inginerii de rețea ci a devenit o decizie importantă de management. Politicile de trafic pot influența satisfacția clienților și implicit performanța și imaginea companiei.

Cu acești factori și cu cerințele esențiale de business în prim plan, intră în atribuțiile inginerului de rețea să caute soluții care să depășească monitorizarea simplă a rețelei și să se concentreze pe ținte care garantează cu succes calitatea serviciilor.

În cele ce urmează ne propunem să dezvoltăm un sistem de management al echipamentelor conectate la rețea, pentru a ușura sarcinile zilnice de administrare și monitorizare a inginerilor IT.

CAPITOLUL I SNMP. Noțiuni de bază

Protocolul SNMP (Simple Network Management Protocol) este un protocol popular folosit la managementul rețelelor de calculatoare. A fost creat pentru a asigura o fundație comună care poate fi folosită de către administratorii de rețea pentru a extrage diferite caracteristici de funcționare a echipamentelor legate într-o rețea.

Rețelele de calculatoare cu mii de noduri sunt dificil de administrat fără un număr mare de angajați care să monitorizeze fiecare stație de lucru. Protocolul SNMP, care este folosit frecvent in rețele locale de tip LAN (Local Area Network), permite monitorizarea nodurilor de rețea de la o stație de management. Este folosit pentru colectarea de informații legate de caracteristici de funcționare a echipamentelor de rețea, ex: servere, imprimante, hub-uri, switch-uri, routere, etc., într-o rețea IP (Internet Protocol). De asemenea, poate fi folosit și la configurarea la distanță (remote administration) a acestor echipamente.

Pe lângă monitorizarea echipamentelor de rețea fizice, SNMP permite, de asemenea, să se monitorizeze și servicii de rețea precum DHCP (Dynamic Host Configuration Protocol) sau WINS (Windows Internet Name Service).

Folosim software-ul de management SNMP pentru a monitoriza orice echipament asupra căruia s-a instalat software-ul de agent SNMP. Acesta interacționează la nivel de rețea cu software-ul de management și permite transferul de informații legate de starea rețelei, între echipamentele monitorizate și sistemul de management SNMP care le monitorizează (Fig I.1).

Agenții SNMP furnizează date de management cu privire la sistemele administrate ca și variabile. Protocolul permite, de asemenea, sarcini de management active, cum ar fi modificarea și aplicarea unei noi configurații prin modificarea de la distanță a acestor variabile. Variabilele accesibile prin intermediul SNMP sunt organizate în ierarhii. Aceste ierarhii, și alte metadate (cum ar fi tipul și descrierea variabilei), sunt descrise de baza de informare de management (MIB).

Fig I.1

I.1 Istoric

La început, în 1988, era nevoie de un instrument de administrare pentru rețeaua TCP/IP și în particular pentru Internet.

Punctul de început a fost dat de IAB (Internet Architecture Board – Comisia care supraveghează dezvoltarea protocolului IP și procesul de standardizare) prin publicarea în Aprilie 1998 a RFC 1052. Acest RFC indică cerințele pentru standardul de administrare al rețelei. Este intitulat “Recomandările IAB pentru dezvoltarea de standarde de administrare a rețelei Internet” și spune că administrarea rețelei trebuie:

– să fie cât se poate de mare;

– să fie cât se poate de mare diversitatea implementărilor;

– să fie cât se poate de mare diversitatea administrărilor;

– să acopere cât mai mult protocolul IP;

Din acest moment lucrurile încep să se miște mult mai repede. O parte importantă a conceptului era cunoscuta deja din dezvoltări anterioare în jurul routerelor, în special SGMP(Simple Gateway Monitoring Protocol). Următoarele RFC-uri sunt primele documente care se adresează protocolului SNMP publicate in 1988 [1]:

– RFC 1065 – Structura și identificarea informației de administrare pentru inter rețele TCP/IP (Structure and Identification of Management Information for TCP/IP-based internets)

– RFC 1066 – Baza de informații de administrare pentru administrarea rețelelor din inter rețele TCP/IP (Management Information Base for Network Management of TCP/IP-based internets)

– RFC 1067 – Un protocol simplu de administrare a rețelei (A Simple Network Management Protocol)

RFC-urile sunt foarte importante în evoluția unui protocol. După un studiu preliminar, un RFC este prezentat ca o etapă a unui standard. După o perioadă de aproximativ șase luni devine o “schiță standard” (Draft Standard). În acest moment, trebuie să existe cel puțin 2 implementări ale acestui protocol.

După o perioadă de 4 luni, dacă IESG (Internet Engineering Steering Group – grup care coordonează activitățile grupurilor de lucru IETF) îl recomandă ca standard, atunci IAB ia decizia finală de a adopta standardul.

In mai 1991 sunt publicate mai multe RFC-uri:

– RFC 1155 Structure and Identification of Management Information for TCP/IP-based Internets Structure and Identification of Management Information Guidelines for Object Names (Structura și identificarea informației de administrare pentru structuri de inter rețele bazate pe TCP/IP și indicații pentru identificarea informației de administrare pentru nume de obiecte);

descrie cum informația de administrare a fost structurată într-un arbore global.

conturează câteva restricții pentru a păstra simplitatea protocolului.

introduce regulile pentru atribuirea numelor obiectelor.

– RFC 1212 Concise MIB Definitions (Definiții MIB precise) completează RFC 1155 cu detalii tehnice.

– RFC 1213 Management Information Base for Network Management of TCP/IP-based internets: MIB-II (Baza de informații de administrare pentru administrarea rețelelor din cadrul inter rețelelor bazate pe TCP/IP: MIB-II). Acest document definește versiunea a doua a MIB (MIB-II, Management Information Base) ce va fi folosită pentru protocoalele de administrare a rețelelor în inter rețele de tip TCP/IP.

– RFC 1157 definește:

Simple Network Management Protocol (SNMP)

Definește mesajele care pot fi transferate între stațiile de administrare și entitatea administrată pentru a citi sau actualiza parametri;

Definește mesajele de avertizare (TRAP) trimise de sistem în situații exceptionale;

Definește formatul mesajelor și detaliile protocolului de comunicare;

Diferite grupuri de lucru au contribuit la dezvoltarea și răspândirea protocolului prin crearea de MIB-uri pentru toate tipurile de echipamente de rețea (switch-uri, routere, hub-uri, interfețe WAN). În noiembrie 1991 sunt publicate cerințele pentru integrarea sondelor. Aceste sonde supraveghează, interoghează și fac captura pasivă a traficului pe un anumit segment de rețea pentru analiza ulterioară. Ele păstrează statistici ale traficului, surse, destinație și alte criterii. Un administrator de rețea are posibilitatea de a pune pragul de avertizare în modului de administrare care va primi mesajul de avertizare.

În aprilie 1993, SNMP versiunea 2 devine standard. Oferă facilități care îmbunătățesc securitatea și autentificarea. Această versiune este criticată pentru că a introdus complexitate în administrare și pentru că este incompatibilă cu SNMP versiunea 1.

În 1997 se înființează un grup reunit care are ca scop crearea versiunii 3 a protocolului SNMP. O parte din eforturi sunt orientate către administrarea protocoalelor multimedia.

Partea centrală a lui SNMP este un set de operații (și informațiile pe care le dau aceste operații) Acest lucru dă administratorilor de rețea abilitatea de a schimba starea unor dispozitive bazate pe SNMP. De exemplu se poate folosi SNMP pentru a închide interfața unui router sau să se verifice viteza conexiunii Ethernet. SNMP poate contoriza până și temperatura de lucru a switch-urilor și să anunțe dacă depășește anumiți parametri.

SNMP este asociat în general cu administrarea de routere, dar este important să înțelegem că poate fi folosit pentru a administra orice tip de componente care acceptă și care folosesc acest protocol. Ca și predecesorul sau SGMP (Simple Gateway Management Protocol) SNMP poate administra sisteme Unix sau Windows, surse de putere și multe alte echipamente. Orice dispozitiv care poate folosi comenzi SNMP poate fi administrat. Asta nu include doar dispozitive fizice ci și software cum ar fi servere web și baze de date.

Alt aspect important este administrarea rețelei per ansamblu față de administrarea unui singur router gazdă și alte dispozitive. Remote Network Monitoring (RMON) a fost dezvoltat ca să ne facă să înțelegem cum funcționează rețeaua în sine și cum dispozitive individuale afectează rețeaua ca un tot unitar. Poate fi folosit nu numai să monitorizam traficul LAN dar și traficul WAN.

I.2 De ce a fost necesar SNMP?

De când a apărut la sfârșitul anilor '60, Internetul a cunoscut o creștere permanentă. Protocolul TPC/IP s-a dezvoltat într-un mediu întreținut atât de fonduri guvernamentale cât și de cercetările academice. Datorită performanțelor sale, protocolul TCP/IP a făcut ca din ce în ce mai multe organizații să-și includă rețelele proprii la cea mai dezvoltată rețea: Internetul. În prezent, Internetul este format din milioane de calculatoare răspândite în jurul lumii.

S-au dezvoltat din ce în ce mai multe aplicații de către utilizatorii de internet. De asemenea, mulți oameni au început să depindă de Internet în munca lor de zi cu zi. TCP/IP a început să fie utilizat pe scară largă în rețelele private ale companiilor comerciale. Companiile nu-și pot permite ca rețeaua să meargă prost sau serverele să cadă pe perioade îndelungate. O alta problemă era securitatea și confidențialitatea. Astfel a apărut nevoia unui protocol de administrare a rețelelor și de monitorizare a funcționarii lor.

I.3 SNMP v1

SNMP versiunea 1 este versiunea inițiala a conceptului de SNMP a fost introdusă pentru a răspunde nevoii de administrare a dispozitivelor ce folosesc protocolul IP. Este definit în RFC 1157. SNMP oferă utilizatorilor un set simplu de operații care permite acestor dispozitive să fie administrate de la distanță. Baza protocolului SNMP este un set simplu de operații care oferă administratorilor posibilitatea de a urmări sau modifica parametrii unor dispozitive ce suportă SNMP. SNMP este asociat cu administrarea routerelor, imprimantelor, surselor de alimentare, etc. Orice dispozitiv care executa programe software ce permite extragerea de informații SNMP poate fi administrat. Aici sunt incluse atât echipamentele hardware cât și aplicații software, cum ar fi serverele web și bazele de date.

SNMP este inclus in stiva TCP/IP în nivelul aplicație și majoritatea implementărilor folosesc UDP pentru a transferul de mesaje. UDP este un protocol fără conexiune și nu oferă siguranța livrării mesajelor, aceasta fiind responsabilitatea celui care a implementat aplicația. SNMP funcționează folosind UDP deoarece este considerata acceptabila pierderea de pachete în comparație cu funcțiile pe care trebuie să le îndeplinească entitățile administrate.

Dispozitivele administrate sunt monitorizate și controlate folosind 4 comenzi SNMP: citire, scriere, trap (capcana) și operații de traversare. Comenzile de citire sunt folosite de entitatea de administrare pentru a monitoriza dispozitivele administrate. Entitatea de administrare analizează diferite variabile care sunt folosite de echipamentele administrate. Comenzile de scriere sunt folosite de entitatea de administrare pentru a controla dispozitivele administrate. Entitatea de administrare schimba valoarea variabilelor folosite de echipamentele administrate. Comanda trap (capcana) este folosită de echipamentele administrate pentru a raporta asincron evenimente către entitatea de administrare. Când apar anumite evenimente, un echipament administrat trimite un mesaj trap către entitatea de administrare. Operațiile de traversare sunt folosite de entitatea de administrare pentru a determina ce variabile suportă un echipament administrat și să adune secvențial informații în tabelele de variabile [1].

I.4 SNMP v2

Pe lângă securitatea îmbunătățita, versiunea 2 include și un mecanism de strângere multiplă și detalierea mesajelor de eroare raportate către entitatea de administrare. Mecanismul de strângere multiplă suportă aducerea de tabele și cantități mari de informații. Acest mecanism îmbunătățește performanțele rețelei când se accesează cantități mari de date.

SNMP v2 a îmbunătățit suportul pentru rezolvarea erorilor și include coduri de eroare în plus ce permit diferențierea anumitor condiții de eroare. Mai mult, trei tipuri de excepții sunt suportate in SNMP v2. Ele sunt:

− No such object

− No such instance

− End of MIB

SNMPv1 și v2 au o mare răspândire datorită următoarelor:

– sintaxa de definire a datelor este independenta de platformă – este un subset de ANS.1

– o notație de transfer independentă de platformă – BER;

– comunicațiile SNMP cu formate de mesaje și tipuri de mesaje;

– mesajul conține versiunea de SNMP;

– mesajul conține un șir de caractere ca un fel de autentificare;

– un ghid de definire a datelor de management – SMI;

– structuri de stocare a datelor de administrare – fișiere MIB;

Un șablon de mesaj (PDU) folosit de protocolul SNMPv2 este prezentat în Fig I.2 [5]:

Fig I.2

Versiune – Versiunea mesajului SNMP.

Nume comunitate – Un șir de caractere ASCII care afișează numele comunității din care provine PDU-ul. Această valoare poate fi de până la 255 de caractere.

Tip PDU – Tipul de PDU conținut de mesajul SNMP. Tipul PDU poate fi una dintre următoarele:

GetRequest

GetNextRequest

SetRequest

GetResponse

ID cerere – Un număr unic care este folosit pentru a distinge între diferite cereri și să le asocieze cu răspunsul corespunzător.

Stare eroare – Folosit pentru a indica faptul că a apărut o eroare în timp ce agentul a efectuat procesarea unei cereri.

Index eroare – Este utilizat pentru a oferi informații suplimentare prin identificarea variabilei din listă care a provocat o eroare.

Lista de variabile – O listă simplă de variabile, care reprezintă asocierile numelor variabilelor MIB cu valorile lor corespunzătoare.

I.5 Interoperabilitate între versiunile 1 și 2

Din păcate versiunile 1 și 2 de SNMP nu sunt compatibile în două domenii importante: formatul mesajelor și operațiile de protocol. Mesajele din versiunea 2 au un header și o unitate de protocol diferită de cea din versiunea 1. Mai mult, SNMPv2 folosește două protocoale care nu sunt specificate de SNMPv1. Totuși există două versiuni de coexistentă între versiunea 1 și versiunea 2: agenții proxy și sistemul de administrare bilingv. În cazul folosirii de agenți proxy agentul de la versiunea 2 lucrează ca un proxy pentru cel de versiunea 1. Pașii sunt următorii: un NMS de la un SNMPv2 emite o comandă pentru un agent SNMPv1, NMS-ul trimite mesajul SNMP la agentul proxy SNMPv2, agentul proxy face comenzile Get, GetNext și Set pentru mesaj spre agentul SNMPv1 nemodificate, mesajele de GetBulk sunt convertite de agentul proxy la mesaje GetNext care sunt trimise la agentul SNMPv1. Alternativa este un sistem de administrare rețea bilingv. Aceasta înseamnă că sistemul în sine oferă suport pentru SNMPv1 și SNMPv2. Pentru a facilita aceasta aplicația contactează un agent. Apoi NMS-ul examinează informația stocată în baza de date locală și spune dacă agentul acceptă SNMPv1 sau v2. În funcție de răspunsul primit de la baza de date, NMS-ul comunică cu agentul folosind versiunea corespunzătoare de SNMP.

I.6 Vulnerabilități ale versiunilor 1 și 2

Aceste două versiuni sunt vulnerabile la atac prin programe de “ascultat pachete” pentru că nu implementează nici un fel de codare. Sunt vulnerabile la algoritmii de tip “brute force” sau bazați pe dicționar pentru a ghici codurile din rețea. Deși sunt implementate să funcționeze peste TCP și alte protocoale, este în general folosit peste conexiunea UDP care este vulnerabilă la atacuri asupra IP-ului. Astfel toate versiunile sunt vulnerabile dacă se trece de lista de acces care restricționează accesul SNMP. Capabilitățile de scriere pot fi folosite pentru a cauza probleme majore. Aceste metode sunt folosite foarte rar în practică tocmai din aceste motive. Din aceste motive este catalogat ca un sistem foarte vulnerabil la atacuri.

Există evident metode de evitare sau minimizare a acestor probleme. Pașii principali ar fi: aplicarea unui patch de la distribuitor, oprirea tuturor serviciilor SNMP neesențiale, filtrarea accesului SNMP doar la dispozitivele care trebuie administrate, schimbare parolelor față de cele normale.

I.7 SNMP v3

Este cea mai nouă versiune de SNMP. Cea mai mare contribuție a ei este securitatea rețelei. Deși SNMPv3 nu face nicio modificare a protocolului în afară de adăugarea de securitate criptografică, el arată mult diferit datorită noii convenții textuale, concepte și terminologie. SNMPv3 adăugat în primul rând securitate și îmbunătățiri ale configurării de la distanță a echipamentelor. Din cauza lipsei de securitate a versiunilor anterioare ale SNMP, administratorii de rețea au folosit alte mijloace, cum ar fi telnet pentru configurare, administrare și management de defecte. În prezent, SNMPv3 este folosit foarte intens pentru monitorizarea și managementul performanței de către administratorii de rețea.

În anul 2002 a ajuns un standard complet. Următoarele RFC definesc standardul: RFC 3410, RFC 3411, RFC 3412, RFC 3413, RFC 3414, RFC 3415, RFC 3416, RFC 3417, RFC 3418, și RFC 2576. deși standardul este complet, vânzătorii de software nu vor să treacă pe noul sistem. În aceste condiții cele mai multe implementări sunt pentru versiunea 1, deși aceasta a fost trecută la nivel de standard istoric. Arhitectura SNMPv3 este prezentată în Fig I.3.

Fig I.3

SNMP v3 oferă un mediu sigur de administrare a echipamentelor gestionate, care acoperă următoarele [2]:

Identificarea entităților SNMP pentru a facilita comunicarea între ele – fiecare are un identificator numit SNMPEngineID și comunicarea este posibilă doar dacă o entitate cunoaște entitatea propriului ei coleg. Notificările și capcanele sunt excepții de la aceasta regulă;

Suport pentru modele securizate – un model securizat este cel care definește regulile de securitate într-o rețea;

Definirea de țeluri de securitate care includ protecție față de următoarele probleme:

Modificarea informației – protecție împotriva entităților care ar putea modifica un mesaj de la o sursa autorizată în tranzit;

Mascarada – protecția împotriva considerării ca un sistem are autorizările necesare când acesta nu le are;

Modificarea ordinii mesajelor – protecție împotriva reordonării mesajelor sau întârzierea lor;

Siguranța – protecție împotriva ascultării mesajelor de către o alta parte;

Specificații pentru USM – USM (User-based Security Model) constă în definiția generală a următoarelor mecanisme de comunicație disponibile:

comunicații fără autentificare sau intimitate (NoAuthNoPriv);

comunicații cu autentificare dar fără intimitate (AuthNoPriv);

comunicații cu autentificare și intimitate;

Definirea diferitelor metode și protocoale de comunicare – în prezent există MD5 și SHA care sunt utilizate de USM;

Definirea unei proceduri de descoperire – pentru a facilita comunicarea între entități;

Definirea unei proceduri de sincronizare de timp – pentru a facilita comunicarea securitzată între entitățile SNMP.

Definirea cadrului MIB pentru SNMP – pentru a facilita configurarea și modificarea entităților de la distanță.

Versiunea 3 are două facilitați suplimentare foarte importante și anume: administrare și securitate. Securitatea se referă la autentificare și criptare a datelor.

Deși fiecare versiune a SNMP a ajuns la maturitate oferind funcționalități bogate, s-a pus accent pe aspectul securitate la fiecare actualizare a protocolului. Mai jos se prezintă aspectele de securitate ale fiecărei versiuni [4]:

I.8 Utilizare SNMP

Așa cum sugerează și numele, protocolul este destul de simplu pentru că este simplu de înțeles și agentul software necesită puțină programare. Este aceasta simplitate care îi conferă stadiul de cel mai utilizat protocol pentru administrarea rețelei. O implementare SNMP este mult mai directă decât alte implementări de administrare de rețea.

Principalele avantaje:

Protocol standardizat: ca un protocol internet este standard deschis și dezvoltat prin eforturile comunității Internet, iar implementările viitoare sunt bazate pe standarde deja existente.

Universal acceptat: toți marii producători oferă suport pentru SNMP. Toate dispozitivele bazate pe SNMP acceptă un set comun de informații despre rețea.

Portabilitate: este independent de limbajul de programare și de platforma de lucru. Standardul are un set de operații care trebuie să se comporte identic pe toate sistemele.

Cerințe minime: facilitățile oferite de SNMP sunt la un preț foarte scăzut ca procent din performanta sistemului.

SNMP a fost conceput astfel încât să poată fi portat pe orice sistem din orice rețea. Este foarte utilizat deoarece este cel mai popular dintre protocoale, este și cel mai răspândit și orice distribuitor știe despre el.

I.9 Principiul de funcționare

Cele trei componente importante ale SNMP care formează o parte integrantă a fundației o reprezintă echipamentul de rețea, agentul și manager-ul. Descriem pe larg acești termeni, precum și relația dintre ei. Figura I.4 descrie principiul care stă la baza comunicației SNMP [3]:

Fig I.4

Echipamentul de rețea este acel obiect administrat (device) dintr-o rețea, care necesită o formă de monitorizare sau management.

Agentul oferă interfața dintre manager și echipamentele de rețea ce urmează a fi gestionate, cum ar fi routere, switch-uri, bridge-uri, hub-uri sau servere de rețea. Agentul rezidă în interiorul echipamentului de rețea și colectează informații de funcționare pe care le pune la dispoziția manager-ului, la cerere. În practică, agentul este un program care se execută în interiorul echipamentului de rețea și colectează obiectele gestionate cum ar fi cele hardware, parametrii de configurare, statisticile de performanță, etc.

Un exemplu tipic de agent are următoarele caracteristici:

Implementează protocolul SNMP în întregime;

Stochează și extrage informații de monitorizare, așa cum s-au definit in MIB;

Colectează și întreține informații despre mediul său local;

Semnalizează un eveniment către manager;

Joaca rol de intermediar (proxy) pentru noduri de rețea care nu sunt controlabile prin SNMP;

Manager-ul sau sistemul de management este o entitate distinctă care administrează multitudinea de agenți dintr-o locație aflată la distanță. În practică, este un program care este folosit la conectarea la diferiți agenți și extrage informațiile de stare necesare pentru a asigura funcționarea în parametri optimi a echipamentului de rețea. Manager-ul oferă interfața dintre om și sistemul de management.

Dacă luăm ca exemplu o organizație care are multiple sedii în diferite zone geografice, administrarea tuturor echipamentelor din această organizație va fi foarte dificilă. Atunci când în aceasta organizație avem instalați agenți în toate calculatoarele și administratorul de sistem are instalată aplicația manager, întreținerea acestei rețele este semnificativ mai simplă și mai eficientă din punct de vedere al costurilor. Administratorul trebuie doar să ceară unui agent toate informațiile/parametrii de funcționare și acesta va ști imediat starea de funcționare a acelui echipament.

Un exemplu tipic de Manager are următoarele caracteristici:

Implementează sistemul de management al rețelei;

Implementează în întregime protocolul SNMP;

Întreabă agenții, primește răspunsuri de la agenți, setează variabile și recunoaște evenimente declanșate de către aceștia;

Comunicația dintre Manager și Agent prin intermediul rețelei se face cu ajutorul PDU-urilor (Protocol Data Units). Acestea permit Managerului să interacționeze cu un Agent. Măsura prin care acest lucru este posibil este data de informațiile disponibile și transmise de la Agent. Înainte ca aceste informații să fie transmise prin rețea, ele trebuie să fie pregătite și încapsulate pentru a fi transmise prin intermediul structurilor de transmisie fizice. PDU-urile sunt încapsulate în protocolul UDP (User Datagram Protocol) care este un protocol de transport fără conexiune, aparținând stivei TCP/IP și descris în detaliu în standardul RFC 768.

UDP (User Datagram Protocol) este protocolul de nivel transport care suportă mesaje SNMP. Un transmițător SNMP trimite un mesaj în rețea fără a stabili o conexiune în prealabil cu receptorul. Protocolul UDP nu garantează transmiterea mesajelor, dar este un protocol care poate transmite un număr mare de mesaje fără a folosi prea multe resurse de rețea.

Examinăm comunicația între un manager și un agent. Unele protocoale, sunt orientate pe octet, cu un singur octet schimbat pentru a comunica, pe când altele sunt orientate pe pachete cu schimburi de pachete de date pentru a comunica. Pachetele conțin antet, date și octeți de control. Protocolul SNMP este, de asemenea, orientat pe pachete cu următoarele pachete (Protocol Data Unit sau PDUs) SNMPv1 utilizate pentru a comunica: Get, GetNext, Set, GetResponse, Trap.

Fig 1.4

Sistemul de management a rețelei bazat pe protocolul SNMP este compus din trei parți componente, care sunt respectate atât de aplicațiile de management cât și de agenți (Fig I.5) [3]:

Protocolul în sine, care definește funcționarea operațiilor de bază ale SNMP, precum și formatul mesajelor schimbate între aplicația de management și agenți;

Structure of Management Information (SMI), reprezintă un set de reguli folosite la specificarea formatului de definiție a obiectelor administrate (echipamentelor de rețea) care sunt accesate folosind SNMP;

Management Information Base (MIB), o colecție de reguli care definesc proprietățile obiectelor administrate sau echipamentelor de rețea;

Fig I.5

Modulele MIB, împreuna cu SMI sunt exprimate folosind o notație bazată pe text, numita Abstract Syntax Notation One (ASN.1), aceasta fiind formată dintr-o multitudine de definiții de date în format text ASCII. Este alcătuit dintr-un set de reguli generale pentru descrierea structurii obiectelor, independente de tehnicile proprii de codare ale echipamentelor. În contextul SNMP, ASN.1 specifică modul în care datele sunt reprezentate și transmise între calculatoare. Avantajul ce mai important al ASN.1 este că nu depinde de mașinile între care se face transmisia de date.

Informațiile MIB-ului sunt transportate prin rețea folosind mesaje SNMP, ele fiind codificate folosind sistemul Basic Encoding Rules (BER). BER este similar cu SMI, doar că mesajele sunt codificate în format binar. Atât ASN.1 cât și BER sunt componente esențiale pentru implementarea protocolului SNMP.

I.10 MIB

Parametrii și variabilele ce urmează a fi gestionate sunt aranjate în ceea ce se numește MIB (Management Information Base) sau baza de date a informațiilor virtuale. Managerul și agentul utilizează baza de gestionare a informațiilor și un set de comenzi relativ mic pentru a schimba informații. MIB-ul este organizat într-o structură de arbore cu variabilele individuale, cum ar fi punctul de stare sau descriere, fiind reprezentat ca frunzele de pe ramurile unui arbore. Un tag numeric lung sau un obiect de identificare (OID – Object Identifier) este folosit pentru a distinge fiecare variabilă unică în MIB și în mesajele SNMP.

Un MIB reprezinta o listă de obiecte unice de identificare a fiecărui element reunit într-o rețea SNMP. Managerul SNMP nu poate monitoriza dispozitive cu excepția cazului în care le-a reunit în listele MIB. MIB-ul este, de asemenea, un ghid de capabilități a dispozitivelor SNMP. De exemplu, dacă MIB-ul listează OID-urile pentru mesajele Trap, dar nu și pentru mesajele GetResponse, se va prezenta un raport de alarme, dar nu va răspunde la alarma sondaj.

Fiecare element SNMP gestionează obiecte specifice, fiecare obiect având caracteristici specifice. Fiecare obiect sau caracteristică are un cod unic de identificare constând din numere separate prin puncte zecimale (de exemplu, 1.3.6.1.4.1.2682.1).

Structura de gestionare a informațiilor (SMI), un standard SNMP descris în NWG RFC 1155, definește structura informației MIB și tipurile de date admisibile. SMI identifică modul în care resursele din cadrul MIB sunt reprezentate și numite. Filozofia din spatele SMI este de a încuraja simplitate și extensibilitate a cadrului MIB. Specificația SNMP include ASN.1, care asigura un model oficial pentru definirea obiectelor și tabelelor de obiecte din MIB. Următoarele cuvinte cheie sunt folosite pentru a defini un obiect MIB:

Sintaxa (Syntax) – definește structura de date abstracte care corespunde tipului de obiect. SMI limitează intenționat constructele ASN.1 care pot fi folosite, pentru a promova simplitatea.

Accesul (Access) – definește faptul că valoarea obiectului poate fi doar extrasă și nemodificată (doar citire), sau dacă poate fi de asemenea modificată (citire-scriere).

Descriere (Description) – conține o definiție textuală a tipului de obiect. Definiția oferă toate definițiile semantice necesare pentru interpretare.

I.11 OID

Fiecare obiect din MIB are câte un identificator de obiect (OID), pe care aplicația de management îl folosește pentru a solicita valoarea obiectului de la agent. Un OID este o secvență de numere întregi care identifică în mod unic un echipament gestionat, prin definirea unei căi către acest obiect prin intermediul unei structuri de tip arbore numit arborele OID sau copacul de înregistrare. Atunci când un agent SNMP dorește să acceseze un anumit obiect gestionat, el traversează arborele OID pentru a găsi obiectul. Ierarhia de identificatori de obiecte al MIB și formatul său este prezentată în figura I.6.

Fig I.6

În această ierarhie, fiecare obiect MIB privat care este manageriat de aplicația Agent are un identificator unic. Un prefix de .1.3.6.1.4.1.140 arată o cale către obiectele private din MIB-ul nostru.

OID-urile folosite în aplicația noastră sunt private, adică generate în particular pentru programul nostru, iar acestea sunt enumerate mai jos:

public static final OID currentOs = new OID(".1.3.6.1.2.1.1.1.0");

public static final OID currentOsArch = new OID(".1.3.6.1.2.1.1.2.0");

public static final OID userHome = new OID(".1.3.6.1.2.1.1.3.0");

public static final OID pathSeparator = new OID(".1.3.6.1.2.1.1.4.0");

public static final OID userDir = new OID(".1.3.6.1.2.1.1.5.0");

public static final OID fileSep = new OID(".1.3.6.1.2.1.1.6.0");

public static final OID newDir = new OID(".1.3.6.1.2.1.1.7.0");

public static final OID currentDirNames = new OID(".1.3.6.1.2.1.1.8.0");

public static final OID currentDirTypes = new OID(".1.3.6.1.2.1.1.9.0");

public static final OID hwNames = new OID(".1.3.6.1.2.1.2.5.0");

public static final OID hw = new OID(".1.3.6.1.2.1.2.6.0");

public static final OID hwMeasurement = new OID(".1.3.6.1.2.1.2.7.0");

public static final OID currentDir = new OID(".1.3.6.1.2.1.2.1.0");

I.12 Operații de bază

SNMP este un protocol bazat pe cerere și răspuns. Mai jos sunt enumerate operațiile de bază:

Cerere de date

Modificare de variabile

Recepție de mesaje nesolicitate

Manager-ul trimite o cerere de date către un Agent folosind următoarele operații [4]:

GET: operația GET este o cerere trimisa de către Manager spre un obiect administrat și poate extrage una sau mai multe valori.

GETNEXT: aceasta operație este similara cu GET, diferența o face faptul că ea extrage valoarea următorului OID din sistem.

GETBULK: este folosită pentru a extrage cantități mari de date dintr-o tabelă.

Modificarea de variabile se face cu ajutorul operației SET, care este folosită de către Manager pentru a modifica o valoare a unei variabile a echipamentului de rețea administrat.

TRAPS: spre deosebire de comenzile de mai sus care sunt inițiate de către SNMP Manager, Traps (Capcanele) sunt inițiate de către Agenți. Ei semnalizează către Manager despre declanșarea unui eveniment sau daca o variabila a ieșit din parametrii predefiniți.

INFORM: aceasta comanda este similara cu comanda TRAP inițiata de către Agent, cu deosebirea că INFORM include informația de confirmare a recepționarii mesajului de către Manager

RESPONSE: acesta este comanda utilizată pentru a comunica valorile sau acțiunile de la managerul SNMP.

I.13 Categorii de informații de administrare

Protocolul SNMP furnizează următoarele tipuri de informații de administrare:

Informații de stare – acestea se referă la informațiile despre starea curentă a resurselor fizice și logice în raport cu datele operaționale;

Informațiile de configurare – aceste informații arată cum este configurat din punct de vedere fizic dispozitivul. (adrese MAC, parametrii hardware);

Informații de configurare logică – se referă la setările parametrilor și resursele logice configurate ale dispozitivului ca adresele de IP, numere de telefon sau interfețe logice;

Log-uri – acestea includ informații istorice de performanță relaționate la informațiile de stare;

CAPITOLUL II Resurse folosite

Din motive de simplitate și de reducere a costurilor, pentru dezvoltarea aplicației am apelat la funcții și librarii open-source, ale căror cod sursă este deschisă publicului larg, asigurând un cost minim de implementare și de utilizare.

Aplicația propusă folosește următoarele resurse:

GSON

SWT

SNMP4J

SIGAR

Java 1.8.0_45

Eclipse IDE pentru Java

Server web care include: server Apache, PHP și bază de date MySQL administrată de aplicația phpMyAdmin, versiunea 4.4.9

Vom descrie pe scurt resursele enumerate mai sus.

II.1 GSON

GSON este o librărie open-source Java care poate fi folosită pentru a converti obiecte Java în echivalentul lor JSON. De asemenea, se folosește pentru a converti string-uri JSON în obiecte Java echivalente. GSON poate lucra cu obiecte Java arbitrare, inclusiv obiecte pre-definite la care nu avem disponibil codul sursă.

Există disponibile doar câteva proiecte open-source, care pot converti obiecte Java în JSON. Cele mai multe dintre ele necesită să așezăm adnotări Java în clase, lucru ce nu se poate face dacă nu avem acces la codul sursă. Cele mai multe, de asemenea, nu susțin în totalitate utilizarea Java Generics. Implementarea GSON consideră ideile de mai sus ca obiective importante de design.

Beneficiile GSON [6]:

Furnizează metode simple toJson() și fromJson() de a converti obiecte Java în JSON și vice versa

Permite obiecte preexistente și nemodificabile să fie convertite în și din JSON

Suport extins de Java Generics

Permite reprezentări personalizate pentru obiecte

Suport obiecte arbitrar complexe (cu ierarhii de moștenire adânci și utilizarea vastă a tipurilor generice)

Versiunea de librărie GSON pe care o folosim este v2.3.1.

II.2 SWT

SWT (Standard Widget Toolkit) este un set de instrumente open-souce al limbajului Java care este proiectat pentru a furniza acces eficient și portabil la instrumentele de interfațare cu utilizatorul, pentru sistemul de operare pe care a fost implementat.

SWT este componenta software care oferă funcționalitate nativă a widget-urilor pentru platforma Eclipse într-un mod independent de sistemul de operare. Este similară cu componenta AWT/Swing din Java cu o diferență: SWT folosește un set bogat de widget-uri native. Chiar și în situații ideale, librăriile widget performante sunt foarte dificil de scris și de menținut. Acest lucru se datorează complexității native ale sistemelor widget și multor diferențe subtile între platforme [7].

Cu ajutorul acestui set de instrumente SWT am realizat interfața grafică a aplicației, prin intermediul căruia se pot efectua toate operațiile și funcțiile lor.

Versiunea de librărie SWT pe care o folosim este v4.4.2.

II.3 SNMP4J

SNMP4J (SNMP for Java) este o implementare foarte performantă, open-source și de ultima generație a protocolului SNMP pentru platforma Java Standard Edition.

SNMP4J este un API (Application Programming Interface) SNMP orientat pe obiecte, folosit pentru aplicațiile de tip Manager si Agent ale protocolului SNMP. El suportă funcții de generare de comenzi pentru aplicațiile de tip Manager cât și funcții de răspundere la aceste comenzi pentru aplicațiile de tip Agent.

Din păcate nu există multe implementări open-source ale protocolului SNMP pentru Java, acesta fiind motivul alegerii acesteia pentru dezvoltarea aplicației noastre.

API-ul SNMP4J pentru Java oferă următoarele caracteristici [8]:

Suport SNMPv3 cu autentificare MD5 și SHA și securitate DES, 3DES, AES 128, AES 192 și AES 256;

Modele de prelucrare de mesaje cu implementări de tipul MPv1, MPv2c și MPv3

Toate tipurile de PDU;

Mapări de transport conectabile. UDP, TCP, și TLS sunt suportate nativ;

Solicitări sincrone și asincrone;

Suport pentru generarea de comenzi, precum și răspuns la comenzi;

Gratuit, open-source cu modelul de licență Apache;

Suport pentru Java ™ 1.4.1 sau mai nou;

Logare pe baza Log4j;

Suport multi-threading;

Versiunea de API SNMP4J pe care o folosim este v2.3.3

II.4 SIGAR

SIGAR (System Information Gatherer And Reporter) este un API care furnizează o interfața portabilă pentru extragerea unor informații legate de sistem, cum ar fi:

Memoria sistemului, memoria swap, CPU, încărcarea medie, uptime, datele de conectare;

Memoria per-proces, procesor, argumente, variabile de sistem, fișiere deschise;

Detectare sistem de fișiere și valori;

Detecția interfețelor de rețea, informații de configurare și valori;

Tabele de conexiune TCP și UDP;

Tabele de rutare a rețelei;

Aceste informații sunt disponibile în majoritatea platformelor existente, dar fiecare sistem de operare are propriul mod de a le furniza.

SIGAR oferă dezvoltatorilor cu un API pentru a accesa aceste informații, indiferent de platforma de bază [9].

II.5 Mediul de dezvoltare Eclipse

Eclipse este un mediu de dezvoltare IDE (Integrated Development Environment) pentru aplicații Java. Acesta conține un spațiu de lucru de bază și un sistem extensibil de plugin-uri pentru personalizarea mediului de dezvoltare. Scris în Java, Eclipse poate fi folosit pentru a dezvolta aplicații Java. Eclipse SDK este software open-source și gratuit, disponibil pe o multitudine de platforme și sisteme de operare [10].

Versiunea de IDE Eclipse pe care o folosim este v4.2.2 „Luna”.

II.6 Server-ul web

Având în vedere că sistemul de management este proiectat pentru a fi folosit de mai mulți utilizatori (administratori de rețea), am implementat o metodă de autentificare a acestora, bazată pe nume de utilizator și parolă, acestea fiind stocate într-o bază de date MySQL instalată pe server-ul de test. Administrarea bazei de date se face folosind aplicația phpMyAdmin.

Pentru a implementa server-ul web într-o manieră simplă, am instalat stiva WAMP (Windows Apache MySql PHP), care conține toate componentele necesare suportului web. Server-ul web Apache utilizat este reprezentat de versiunea v2.4.9, versiunea PHP folosită este v5.6.9, iar versiunea MySQL este v5.6.17.

CAPITOLUL III Sistemul de monitorizare propus

Conform descrierii din Capitolul I legată de structura generică a unui sistem de monitorizare, am dezvoltat pentru sistemul nostru o implementare similară, bazată pe o aplicație de management numită „Manager” și o aplicație de tip agent numită „Agent”.

Aplicația Manager este cea care oferă funcționalitatea de management, ea fiind instalată, de obicei, pe calculatorul inginerului de rețea și cu ajutorul căreia se administrează toți agenții conectați.

Aplicația Agent se instalează pe toate calculatoarele din rețea care se doresc a fi gestionate prin intermediul protocolului SNMP și asigură informațiile necesare pentru Manager.

Baza de date are numele snmp_user_db și conține o tabelă numită users, care are stocate datele de identificare ale fiecărui utilizator. Datele de identificare sunt înregistrate în felul următor: numele de utilizator este reprezentat de adresa de email, iar parola este reprezentată în câmpul aferent (Fig III.1).

Fig III.1

III.1 Aplicația Agent

Aplicația Agent se lansează în execuție de pe un echipament care se dorește gestionat. Acest lucru se realizează executând fișierul agent.jar din Windows Explorer:

Fig III.2

Odată pornit, Agentul permite inserarea adresei URL a calculatorului gazdă gestionat, precum și portul pe care se vor efectua comunicațiile de date (Fig III.2). Pentru evitarea conflictelor se recomandă folosirea porturilor cu un număr mai mare de 1024. De asemenea, fereastra Agent specifică și starea in care se afla aplicația Agent: „Ready” când nu există Manageri conectați, respectiv „Connected” când avem Manageri conectați.

De menționat este faptul că este necesară forwardarea portului menționat in câmpul Port în cazul în care calculatorul gestionat se află în spatele unui router.

Odată pornită aplicația Agent, ea este rezidentă în memorie și așteaptă conexiuni pe portul specificat în câmpul Port.

III.2 Aplicația Manager

Aplicația Manager se execută de pe calculatorul administratorului de rețea. Pentru a o porni, se execută fișierul manager.jar din Windows Explorer. Va apărea întâi o fereastră de conectare cu ajutorul căreia ne autentificăm și primim acces la fereastra principală (Fig III.3).

Fig III.3

Odată ce autentificarea se efectuează cu succes prin apăsarea butonului Connect, utilizatorului îi este afișată fereastra principală a sistemului de management, prin intermediul căreia se pot citi si extrage funcțiile care au fost implementate (Fig III.4).

Fig III.4

Pentru a activa conexiunea de date, trebuie să selectăm unul dintre calculatoarele care sunt afișate în fereastra Clienții Mei. Starea curentă este descrisă în câmpul Stare din Detalii Client, în cazul nostru starea este Deconectat. Odată selectat sistemul dorit, va apărea un buton Connect, iar prin apăsarea acestuia ne conectăm și ne este permis accesul la variabilele și funcțiile extrase din acesta (Fig III.5).

În zona Detalii Client putem observa și alte informații utile cum ar fi: adresa IP a calculatorului gazdă precum și portul de date pe care l-am setat inițial în fereastra de configurare a modulului Agent (Fig III.5).

Fig III.5

III.3 Funcționalitate

Informațiile care sunt extrase și afișate în fereastra Manager-ului sunt variabile ale sistemului de operare aparținând calculatorului gestionat. Aceste funcții sunt clasificate conform tipului de informații pe care le afișează, în tab-uri numite: Info SO, Info HW și Navigator fișiere.

Primul set de date este unit în tab-ul Info SO și conține următoarele variabile (Fig III.6):

Numele sistemului de operare instalat

Directorul utilizatorului curent

Arhitectura sistemului

Calea către directorul care conține fișierele executabile

Separatorul de căi

Separatorul de fișiere

Fig III.6

Al doilea set de variabile este unit în tab-ul Info HW și conține informații legate de configurația și specificațiile hardware ale calculatorului gazdă (Fig III.7):

Numărul de nuclee și tipul procesorului central, viteza de tact și unitatea de măsură

Cantitatea totală de memorie instalată, cantitatea de memorie în uz și cantitatea de memorie disponibilă

Durata de timp de când a fost pornit sistemul (uptime)

Enumerarea tuturor tipurilor de interfețe de rețea a sistemului gazdă și detaliile lor de configurare: adresa IP, masca IP, adresa MAC

Fig III.7

De asemenea, s-a implementat și un manager de fișiere pentru sistemul gestionat, care permite navigarea în sistemul de fișiere și directoare din calculatorul aflat la distanță. Cererea de navigare către un director anume se face selectând directorul dorit și apăsând butonul Cere folder. De asemenea, aplicația afișează și dimensiunile fișierelor din calculatorul gazdă. Funcționalitatea este prezentă în tab-ul Navigator fișiere (Fig III.8).

Fig III.8

Securitatea transmisiei de date dintre modulele Agent și Manager este esențială funcționării corecte și sigure a întregului sistem de management, iar aceasta a fost implementată sub forma unei conexiuni VPN (Virtual Private Network) între calculatorul Manager și calculatorul gestionat. Sistemul de operare Windows 8.1 de pe care se execută aplicația Manager asigură suport nativ pentru conexiuni VPN, iar la celălalt capăt se află un server VPN PPTP, configurat în interfața de bază a router-ului intermediar.

CAPITOLUL IV Concluzii

În ziua de azi, existența unui sistem performant de management al rețelei este esențial pentru buna desfășurare a activității unei companii. Protocolul SNMP poate satisface cu ușurință de nevoia de creștere a afacerii companiei, datorită flexibilității și manevrabilității protocolului. În prezent, există și alte tipuri de protocoale care sunt dezvoltate, dar nici unul dintre ei nu poate înlocui SNMP deoarece până la ora actuală este protocolul cel mai simplu, și relativ ușor de implementat.

De-a lungul dezvoltării sale, SNMP s-a dovedit a fi un protocol foarte util pentru gestionarea rețelei. Administratorii de rețea au beneficii multiple la adoptarea SNMP, și la utilizarea acestui protocol pentru monitorizarea și gestionarea rețelelor. Deși standardul SNMP este oarecum complex, care implică cunoștințe specifice de obiecte MIB, precum și o cantitate semnificativă de configurare legate de ambii agenți SNMP și software de management, utilizarea SNMP s-a dovedit a fi o metodă eficientă de a realiza un sistem administrat.

Perspective

Comparativ cu alte metodele de monitorizare și gestionare, SNMP reduce cantitatea de efort și atenție depusă pe elementul de rețea. Costul redus de implementare și adoptarea unei platforme comune permit o dezvoltare eficientă. Acest lucru permite sistemului SNMP să fie folosit pe aproape orice rețea IP, folosind de obicei un singur obiect de management centralizat. Deși rețele IP mari pot necesita proxy-uri SNMP pentru a minimiza traficul SNMP pe rețeaua WAN, reducerea numărului de obiecte de management în comparație cu metodele anterioare permite departamentului IT să se concentreze asupra altor aspecte și la simplificarea rețelei de gestionare.

Prin utilizarea de agenți și de sisteme de management SNMP, sistemele de monitorizare IT au crescut dramatic și au redus semnificativ necesitatea administratorilor de a monitoriza manual componentele de rețea individuale. Capacitatea de a avea sisteme care să informeze aplicații centralizate de management (și în cele din urmă factorii umani), de condiții de eroare, a dus la creșterea uptime-ului și disponibilității active a rețelei. Deși nu este perfect, protocolul SNMP oferă multe dintre instrumentele necesare pentru colectarea și analiza datelor, pentru a permite reglarea sistemului pentru o performanță optimă și pentru a identifica unde și când este nevoie de o dezvoltare în viitor a rețelei.

Propuneri pentru îmbunătățire a sistemului de management

Aplicația descrisă în capitolele de mai sus este menită să fie o soluție completă a unui sistem de management a echipamentelor dintr-o rețea de calculatoare. Ea a fost proiectată spre a fi de ajutor inginerilor de rețea, pentru a ușura efortul necesar administrării componentelor individuale a sistemului.

Ca orice sistem, aplicația poate fi îmbunătățită în continuare, conform nevoilor și cerințelor unei companii, iar câteva dintre aceste idei sunt expuse în cele ce urmează:

Adăugare de suport pentru parametri noi de funcționare a echipamentelor gestionate, cum ar fi: includerea de informații legate de temperaturile de funcționare ale componentelor și declasatoare de eveniment atunci când acestea sunt depășite;

Îmbunătățirea interfețelor grafice cu utilizatorul pentru un aspect mai plăcut;

Îmbunătățirea securității comunicației dintre Agenți și Manageri SNMP pentru a evita posibile incidente indezirabile legate de terțe părți cu intenții malițioase. O posibilă implementare poate consta în criptarea comunicației de date în ambele sensuri folosind un sistem de criptare modern (ex: AES) cu cheie de 128 sau 256 biți.

Îmbunătățirea navigatorului de fișiere pentru suport extins de funcții și comenzi.

Bibliografie

[1] https://technet.microsoft.com/en-us/library/cc776379(v=ws.10).aspx
Consultat la 01.06.2015 și 11.06.2015

[2] https://en.wikipedia.org/wiki/Simple_Network_Management_Protocol
Consultat la 11.06.2015

[3] http://www.scrigroup.com/management/Network-Management54395.php

Consultat la 11.06.2015

[4] https://www.manageengine.com/network-monitoring/what-is-snmp.html

Consultat la 11.06.2015

[5] https://www-01.ibm.com/support/knowledgecenter/SSB23S_1.1.0.10/com.ibm.ztpf-ztpfdf.doc_put.10/gtpc1/pdus.html

Consultat la 11.06.2015

[6] GSON, https://code.google.com/p/google-gson/ si https://search.maven.org/#artifactdetails%7Ccom.google.code.gson%7Cgson%7C2.3.1%7Cjar

https://en.wikipedia.org/wiki/Gson

Consultate la 11.06.2015

[7] SWT, https://www.eclipse.org/swt/
Consultat la 11.06.2015

[8] SNMP4J, http://www.snmp4j.org/index.html

Consultat la 11.06.2015

[9] SIGAR, https://support.hyperic.com/display/SIGAR/Home

Consultat la 11.06.2015

[10] Eclipse IDE, https://eclipse.org/

Consultat la 11.06.2015

DECLARAȚIE DE AUTENTICITATE A

LUCRĂRII DE FINALIZARE A STUDIILOR

Titlul lucrării: agent SNMP pentru colectarea unor statistici de rețea pe platforma Windows.

Autorul lucrării: Petrea Cristian Nicolae.

Lucrarea de finalizare a studiilor este elaborată în vederea susținerii examenului de finalizare a studiilor organizat de către Facultatea de Inginerie Electrică și Tehnologia Informației din cadrul Universității din Oradea, sesiunea Iulie 2015 a anului universitar 2014 – 2015.

Prin prezenta, subsemnatul Petrea Cristian Nicolae, CNP [anonimizat], declar pe proprie răspundere că această lucrare a fost scrisă de către mine, fără nici un ajutor neautorizat și că nici o parte a lucrării nu conține aplicații sau studii de caz publicate de alți autori.

Declar, de asemenea, că în lucrare nu există idei, tabele, grafice, hărți sau alte surse folosite fără respectarea legii române și a convențiilor internaționale privind drepturile de autor.

Oradea,

01.07.2015 Semnătura