Tema are ca scop prezentarea protocolului TCP/IP, a protocolului SNMP și a componentelor sale și modul de aplicare a sa în administrarea rețelelor… [303416]

1. Prezentarea temei

Tema are ca scop prezentarea protocolului TCP/IP, a protocolului SNMP și a componentelor sale și modul de aplicare a [anonimizat] ([anonimizat], [anonimizat], [anonimizat]).

Partea aplicativă constă în realizarea unei aplicații de tip SNMP MIB Browser & [anonimizat] a aplicației SNMP MIB Browser & [anonimizat], de a [anonimizat] a vedea și analiza conținutul concret al obiectelor administrate și structurarea arborescentă a informației de management. Prezentarea de exemple concrețe pe o rețea, a SNMP MIB Browser și a modulului Network SNMP Browser. [anonimizat] ( Virtual Private Network ) [anonimizat], deoarece este o aplicație care nu implica costuri și funcționeaza foarte bine. Această aplicație necesita o bună cunoaștere a [anonimizat], CSS, PHP de asemenea și a framework-ului Node.js.

[anonimizat]. [anonimizat] a scana o rețea locala și a [anonimizat].

2. Protocolul TCP/IP

2.1 Definiția protocolului TCP/IP

TCP/IP (Transmission Control Protocol/Internet Protocol) este cel mai utilizat protocol folosit în rețelele locale cât și pe Internet datorită disponibilității și flexibilități lui având cel mai mare grad de corecție al erorilor. 
TCP/IP permite comunicarea între calculatoarele din întreaga lume indiferent de sistemul de operare instalat.

2.2 Istoric

În anii 1960, guvernul SUA finanțează proiectarea și dezvoltarea procotolului TCP/IP. 
Ministerul Apărării Naționale al SUA dorea un protocol de rețea care să meargă indiferent de condițiile de pe rețea. Atât timp cât conexiunea fizică între calculatoare este funcțională și conexiunea logică a [anonimizat]. 
Era nevoie de o [anonimizat]. 
Crearea acestui protocol a [anonimizat]. 
La început el a [anonimizat] a [anonimizat].

2.3 Cum funcționează

Protocolul TCP/IP este compus din patru niveluri: Aplicație, Transport, Rețea și Acces la rețea. 
Modelul TCP/IP este asemănător cu modelul OSI (Open Systems Interconnection). 
Atentie: A nu se confunda numele nivelurilor TCP/IP cu numele nivelurile din OSI.

2.3.1 [anonimizat], [anonimizat]ele niveluri. 
El comasează nivelurile Aplicație, Prezentare și Sesiune din modelul OSI (Figura2.1)

Figura 2.1

Nivelul Aplicație conține următoarele protocoale de nivel înalt:

Transfer de fișiere: TFTP, FTP și NFS

E-mail: SMTP

Remote: telnet, rlogin

Managementul de rețele: SNMP

Managementul de nume: DNS

HTTP

2.3.2 Nivelul Transport

Nivelul Transport asigură conexiunea logică dintre calculatorul sursa și calculatorul destinație, fluxul de date și corecția erorilor. (Figura 2.2)

Figura 2.2

Nivelul transport include protocoale TCP și UDP. 
TCP (Trasmission Control Protocol) este un protocol orientat pe conexiune care permite că un flux de octeți trimiși de la un calculator să ajungă fără erori pe orice alt calculator din Internet. Dacă pe calculatorul destinație un pachet ajunge cu erori, TCP cere retrimiterea acelui pachet. 
TCP fragmentează fluxul de octeți în mesaje discrețe și pasează fiecare mesaj nivelului Rețea. 
TCP tratează totodată controlul fluxului pentru a se asigura că, calculatorul sursa nu inundă calculatorul destinație cu mai multe pachete decât poate acesta să prelucreze. 
Toate aceste lucruri sunt realizate prin utilizarea secvențelor de număr, sliding windows și acknowledgments. 
UDP (User Datagram Protocol) este un protocol nesigur, destinat pentru aplicații care trebuie să interogheze rapid, fară retrimiterea pachetelor eronate.

UDP este folosit în aplicațiile de transmisii video sau audio și aplicații client-server. 
Exemple de aplicații care folosesc procolul UDP:

DNS (DOMAIN NAME SERVER)

TFTP (TRIVIAL FILE TRANSFER PROTOCOL)

IPTV (TV prin Internet)

VOIP (Telefonie prin Internet)

2.3.3 Nivelul Rețea

Scopul nivelul rețea este de a găsi cel mai optim traseu prin care poate trimite pachetele. 
Nivelul rețea corespunde cu același nivel rețea din modelul OSI. (Figura2.3)

Figura 2.3

Protocoalele care lucrează la nivelul Rețea din modelul TCP/IP sunt:

IP (Internet Protocol)

ICMP (Internet Control Message Protocol)

ARP (Address Resolution Protocol)

RARP (Reverse Address Resolution Protocol)

IP caută cea mai bună cale de a trimite pachetele. 
ICMP oferă capabilități de control și în schimbul de mesaje. 
ARP determină adresa MAC pentru adresele IP 
RARP determină adresa IP pentru o adresa MAC cunoscută. 
Problemele majore se referă la dirijarea pachetelor și evitarea congestiei în rețea. De aceea este rezonabil să presupunem că nivelul Rețea din TCP/IP funcționează asemănător cu nivelul rețea din OSI.

2.3.4 Nivelul Acces la Rețea

Nivelul Acces la Rețea se ocupă cu toate problemele legate de transmiterea efectivă a unui pachet IP pe o legătură fizică, incluzând și aspectele legate de tehnologii și de medii de transmisie, adică nivelurile OSI Legătură de date și Fizic.(Figura 2.4)

Figura 2.4

Drivere, modemuri, plăci de rețea, și alte componente se găsesc în nivelul Acces la rețea. 
Nivelul de acces la rețea definește procedurile folosite pentru interogarea cu echipamentele de rețea și de acces la mediu de transmisie. Protocolul standard, cum ar fi Serial Line Internet Protocol (SLIP) și punct-la-punct Protocol (PPP) trebuie să asigure accesul la rețea prin intermediul unui modem de conectare. Multe protocoale sunt necesare pentru a determina elementele de hardware și software, precum și specificațiile de transmitere la acest nivel.

Cum se formează un pachet TCP/IP

Figura 2.5 O simplă comparație între modelul OSI și modelul TCP/IP

Asemănări:

Ambele au niveluri

Ambele au niveluri de aplicare, chiar dacă acestea includ servicii diferite

Deosebiri:

TCP/IP combină din modelul OSI nivelurile aplicație, prezentare și de sesiune în propriul nivel numit Aplicație.

TCP/IP combină din modelul OSI nivelurile Legatură Date și Fizic în propriul sau nivel numit Acces la rețea.

TCP/IP pare simplu pentru că are mai puține niveluri.

În cazul în care TCP/IP nivelul Transport utilizează UDP, acesta nu oferă încredere livrării de pachete. Nivelul transport din modelul OSI oferă încredere.

Internetul a fost dezvoltat pe baza standardelor de protocoale TCP/IP. TCP/IP a câștigat credibilitate din cauza protocoalelor. 
Modelul OSI nu este folosit în construcția de rețele, el este folosit că un ghid, cu scopul de a-i ajuta pe elevi să înțeleagă procesul de comunicare.

3. Sisteme de management de rețea (Network Management Systems – NMS)

Managementul rețelelor (network management) se referă la mentenanța și administrarea rețelelor mari de calculatoare și de telecomunicații la nivel superior.

Managementul rețelelor constă în execuția unui set de funcții necesare pentru controlul, planificarea, alocarea, coordonarea și monitorizarea resurselor rețelei.

Instrumentele software existente care ușureaza gestionarea rețelelor mari, trebuie dezvoltate constant pentru a se adapta la noile tehnologii și produse ce vor fi integrate în rețea. De aceea managerii rețelei trebuie să aiba o ințelegere clară atât a modului în care pot fi gestionate noile echipamente și produse pentru a comunica cerintele către dezvoltatorii software-ului de management precum și a modului în care instrumentele de management sunt proiectate și funcționeaza. Similar, pentru a putea dezvolta instrumente eficiente din punct de vedere al costului de exploatare, dezvoltatorii trebuie să aibă o ințelegere clara a provocărilor cu care se confrunta managerii în gestionarea rețelelor și cum aceste provocări determină costul management-ului rețelei.

Software-ul folosit pentru managementul rețelor mari (date/telecom) poartă numele generic de “Network Management System”, pe scurt NMS. Acestea sunt aplicații complexe, de multe ori distribuite, având o disponibilitate foarte ridicată (high availability).

Avantajele oferite de NMS-uri sunt următoarele:

descoperirea automată a elementelor rețelei;

vedere grafică (topologică) a rețelei;

managementul defectelor (fault management);

managementul performanțelor (performance management);

configurărea de la distanță a elementelor de rețea (remote configuration);

managementul alarmelor (alarms management);

trimiterea de notificări prin sms/email când sunt probleme;

crearea de statistici/rapoarte cu privire la problemele din rețea.

În 1996 ITU-T a întrodus FCAPS, un model pentru gestionarea rețelelor. FCAPS este un acronim pentru: Fault, Configuration, User Management, Performance, Security care reprezintă categoriile de management acoperite sub termenul de “network management”

Fault Management – scopul fault managementului este de a recunoaște, izola, corecta și inregistra căderile care apar în rețea. În momentul în care apare o problema o notificare este trimisă către o consolă de monitorizare sau/și către o lista de persoane prin mail sau sms. Caderile sunt inregistrate și pe baza lor se fac statistici și predicții.

Configuration Management – în rețelele mari, gestionarea configuratiilor este foarte importantă.

Gestionarea configuratiilor iși propune:

strangerea și stocarea configurățiilor de la echipamentele de rețea

simplificarea configurării echipamentelor

urmarirea schimbărilor făcute în configuratii

automatizarea configurărilor (de exemplu mapările dintre adrese și numele DNS)

User Management – scopul este de a administra un set de utilizatori autorizați, prin definirea utilizatorilor, parolelor și a drepturilor de acces, și de a administra operații ale echipamentelor cum ar fi backup-ul și sincronizarea.

Performance Management – permite managerilor să determine eficiența curentă a rețelei. Gestionarea perfomanțelor adresează chestiuni ca lațimea de bandă, utilizarea rețelei, rata erorilor, timpi de raspuns etc. Prin colectarea datelor legate de performanță, pot fi depistate tendințe ce indică probleme în buna funcționare a rețelei înainte de a fi afectate serviciile oferite. Security Management – este procesul prin care se controleaza accesul la resursele rețelei.

Presupune acțiuni ca autorizare, autentificare, criptare, folosirea de sisteme de detecție și prevenire a întruziunilor etc.

Exista un numar mare de protocoale pentru gestionarea rețelelor (network management protocols). Protocoale cunoscute sunt: SNMP – Simple Network Management Protocol, CMIP – Common Management Informațion Protocol, WBEM – Web-Based Enterprise Management, TL1 – Transacțion Language 1, JMX – Java Management Extension etc. Protocolul SNMP este în acest moment cel mai utilizat protocol pentru gestionarea rețelelor.

Acesta este un protocol “simplu” și eficient, ajungând prin versiunea 3 la maturitate. În continuare va fi descrisă evoluția acestui protocol, funcționarea lui precum și modalități de utilizare.

4. SNMP – Simple Network Management Protocol

La inceputul dezvoltării ARPANET-ului, dacă intarzierea la un anumit sistem gazdă era foarte mare, persoana care detecta problema executa programul Ping pentru a primi un pachet de la destinație. Analizând amprentele de timp din antetul pachetului returnat, putea fi stabilită localizarea problemei și se luau masuri pentru a fi rezolvată. În plus, numarul de rutere era atat mic, incat era posibila verificarea tuturor pentru a descoperi care dintre ele avea probleme.

Când ARPANET a devenit Internet, această rețea internatională, cu multiple coloane vertebrale și o mulțime de operatori, soluția a incetat să mai fie adecvată, așa că a fost nevoie de instrumente mai bune de administrare a rețelei. Două prime incercări au fost definite în RFC 1028 și RFC 1067, dar viața lor a fost scurtă. În mai 1990 a fost publicat RFC 1157, definind versiunea l a SNMP-ului (Simple Network Management Protocol – protocol simplu de administrare a rețelei). Impreună cu un document însoțitor (RFC 1155) despre informațiile de administrare, SNMP furniza o metodă sistematică de monitorizare și administrare a unei rețele de calculatoare. Această structură și acest protocol au fost implementate pe scară largă în cadrul aplicațiilor comerciale și au devenit standarde „de facto” pentru administrarea rețelelor.

SNMP este un protocol standardizat de către IETF (Internet Engineering Task Force), având drept utilizare ușurarea monitorizării și managementului echipamentelor din rețele IP. Fiind suportat de foarte multe tipuri de echipamente și în același timp simplu, SNMP este cel mai utilizat protocol pentru “network management”.

Prima versiune, SNMPv1, a apărut în 1988 ca o nevoie de a avea un standard pentru managementul rețelelor a căror dimensiune creștea exponențial. SNMPv1 a fost inițial descris în 3 RFC-uri (Request For Comments):

1065 (Structure and Identification of Management Information for TCP/IP-based internets),

1066 (Management Information Base for Network Management of TCP/IP-based internets)

1067 (A Simple Network Management Protocol) care au fost înlocuite cu RFC-urile 1155, 1156 și 1157.

Autentificarea în acest protocol se face pe baza de comunități, care sunt de fapt niste parole care sunt transmise în text clar pentru ca aplicațiile de management să poată accesa dispozitivele SNMP.

Versiunea a doua protocolului, SNMPv2c, este definit de RFC-urile 3416, 3417, și 3418. Litera “c” de la sfarsitul versiunii indică ca protocolul este bazat pe comunități.

Ultima versiune a protocolului, SNMPv3, aduce cea mai importanta contribuție în ceea ce privește securitatea: autentificare puternica și comunicație privata între entitățile gestionate. În 2002 s-a facut tranziția pentru versiunea 3 de la un standard “draft” la un standard complet.

SNMPv3 este descris în RFC-urile 3410, 3411, 3412, 3413, 3414, 3415, 3416, 3417, 3418 și 2576.

În lumea SNMP exista doua tipuri de entități:

a. Managerul – este un server pe care rulează un software de management (NMS) și care este responsabil pentru primirea trap-urilor (datagrame informaționale trimise asincron, nu ca efect al unei cereri) și interogarea agenților (polling);

b. Agentul – este un software care rulează într-un element de rețea gestionat. Poate fi un proces separat (un daemon în Unix de exemplu) sau poate fi incorporat în sistemul de operare (de exemplu în IOS la routerele Cisco).

Agentul păstreaza un istoric al aspectelor operaționale ale unui dispozitiv, răspunde cu informațiile necesare la cererile NMS-ului iar în cazul în care apar evenimente care influențează buna funcționare a dispozitivului, trimite trap-uri către NMS. Interacțiunea dintre manager și agent este reprezentata în figura 4.1. Fiecare agent deține o listă a obiectelor gestionate și a stării lor (de exemplu un agent într-un router gestionează toate interfețele, fiecare interfață fiind un obiect gestionat).

Figura 4.1 Interacțiunea NMS-Agent

Structura informației de management (Structure of Management Information – SMI) oferă o cale de a defini obiectele gestionate și comportamentul lor.

Baza informației de management (Management Information Base (MIB) poate fi vazută ca o bază de date de obiecte gestionate pe care un agent le urmarește.

Orice stare sau informație statistică care poate fi accesată de NMS este definită într-un MIB. SMI-ul oferă calea de a defini obiectele, iar MIB-ul este definiția obiectelor folosind sintaxa SMI. Un agent poate implementa mai multe MIB-uri, dar toți agenții implementează MIB-II (RFC 1213). Scopul principal al acestui MIB este de a defini informații de management generale pentru TCP/IP cum ar fi: numărul de octeți trimiși/receptionați, viteza interfețelor, MTU (Maximum Transfer Unit) etc.

Un numar semnificativ de MIB-uri au fost propuse ca standard pentru a gestiona multe lucruri cum ar fi ATM (RFC 2515), Frame Relay (RFC 2115), RDBMS (RFC 1697), DNS Server (RFC 1611) etc. Pe langă aceste MIB-uri standard, fiecare vendor poate creea MIB-uri proprietare pentru a putea monitoriza elemente specifice tipului sau de echipament.

Securitatea în SNMPv1 și SNMPv2

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

comunități. În SNMPv2 au fost prevăzute modalități 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 mulți producători de echipamente oferă suport doar pentru

monitorizarea echipamentelor, partea de control (echivalentul operației set) fiind disponibilă

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

introducerea versiunii 3 a acestui standard (SNMPv3).

SNMPv3

Specificațiile pentru SNMPv3 au fost aprobate de către IESG (Internet Engineering Steering Group) ca standard în anul 2002. Prima variantă de standard (draft) fusese aprobată de același comitet în 1999. Principalele modificări 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

convenții, 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 găsesc în

paragrafele care urmează. Prin acest mod de prezentare practic se definește o arhitectură, în

loc de un simplu set de mesaje și operații.

4.1 Datagrama UDP a protocolului SNMP

SNMP-ul utilizează User Datagram Protocol (UDP) ca protocol de transport pentru a pasa datele între agenți și manageri. UDP-ul (RFC 768) a fost ales în ciuda TCP-ului (Transmission Control Protocol) datorită lipsei unei conexiunii între cele două entitați care comunică, în acest fel resursele folosite fiind reduse. Dezavantajul folosirii UDP-ului este că se pot pierde datagrame ce conțin trap-uri, fară a exista posibilitatea să se notifice acest lucru. SNMP-ul foloseste portul UDP 161 pentru a trimite și a primi cereri și portul 162 pentru a primi trap-uri de la dispozitivele gestionate. Comunicația dintre NMS și agent are loc în felul urmator (vezi Figura 4.2).

La nivelul aplicație se decide tipul acțiunii ce va fi întreprinsa: agentul trimite un trap către NMS, NMS-ul trimite o cerere către un agent. Nivelul aplicație oferă servicii către un enduser (în cazul nostru un operator), de exemplu afișarea stării unui port a unui switch. Nivelul UDP permite la două gazde să comunice; header-ul UDP conține printre alte informații și portul destinație al dispozitivului către care se trimite trap-ul/cererea (161 pentru cerere, 162 pentru trapuri). Nivelul IP incearcă să livreze pachetele la destinație iar nivelul fizic, responsabil de transmiterea informațiilor pe mediul fizic. (Anexa 2)

Figura 4.2 Modelul de comunicație TCP/IP (Anexa 3)

4.2 Comunități SNMP

SNMPv1 and SNMPv2 folosesc noțiunea de comunitate ca mecanism de securitate pentru comunicația dintre NMS și agent. Acestea nu sunt decât simple parole care au marele dezavantaj de a fi transmise în clar la versiunile 1 și 2. Există 3 tipuri de comunități: read-only, read-write și trap.

Primul tip de comunitate read, așa cum și numele sugereaza, permite doar citirea datelor nu și modificarea acestora (de exemplu citirea numarului de octeți transmisi/primiti pe o interfață).

Comunitatea read-write permite atât citirea datelor cât și scrierea acestora (de exemplu resetarea unui router se poate face prin setarea unei variabile în agent).

Comunitatea “trap” permite recepționarea trap-urilor (notificari asincrone) de la agent. Majoritatea vendorilor livrează echipamentele cu comunități setate implicit și anume “public” pentru comunitatea read-only și “private” pentru comunitatea “read-write”. Acestea trebuie schimbate cu atât mai mult dacă informațiile de management vor traversa și alte rețele. Pentru a reduce riscurile atacurilor bazate pe SNMP, firewall-urile pot fi setate să permită trafic pe portul UDP 161 (cereri SNMP) doar dacă au ca origine adresa IP a NMS-ului. În mod asemănător agenții pot fi configurati să comunice doar cu adresa IP a NMS-ului. Când agentul primeste cereri SNMP de la adrese IP străine sau când o autentificare eșuează, acesta poate fi configurăt să trimită trap-uri.

4.3 Trap-uri SNMP

Un trap este o notificare asincrona trimisă de un agent SNMP către un NMS folosind protocolul UDP (port 162). De fapt un trap este un grup de date care este definit într-un MIB și este unic identificat printr-un ID. Trap-urile sunt de două categorii: generice și specifice unui vendor. Trap-urile generice sunt în număr de 7 și sunt următoarele:

coldStart (0) – indică faptul că agentul a fost rebootat; toate variabilele de management vor fi resetate

warmStart (1) – indică faptul ca agentul s-a reinițializat. Nici una din variabilele de management nu vor fi resetate

linkDown (2) – trimis când o interfață a unui dispozitiv este cazuta.

linkup (3) – trimis când o interfață a unui dispozitiv se ridica

authenticationFailure (4) – indică o incercare de interogare a agentului cu o comunitate greșită.

egpNeighborLoss (5) – indică ca un vecin EGP a căzut.

enterpriseSpecific (6) – indică ca trap-ul este vendor specific. Pentru a procesa acest trap correct, NMS-ul trebuie să decodeze numarul trap-ului specific care este o parte a mesajului SNMP.

Unul din punctele forte ale SNMP-ului este posibilitatea ca orice vendor de echipamente să iși construiască propriul MIB și să monitorizeze orice particularitate a echipamentului său crede de cuviință. Un trap specific este identificat în mod unic de ID-ul vendorului și de numarul trap-ului care este dat de către vendor.

Trap-urile sunt recepționate de către NMS care, în funcție de complexitatea sa, poate să afișeze un mesaj pe o consolă de monitorizare, poate trimite un mail/sms către o persoană responsabilă de evenimentele din rețea sau poate chiar să întreprindă acțiuni ca de exemplu resetarea unui echipament (tot prin intermediul SNMP).

4.4 Structura informației de management (SMI)

Informația de management este informația despre nodurile și echipamentele gestionate. Ea poate fi organizată în variabile, fiecare menținând anumite aspecte sau proprietăți ale elementului de rețea. Fiecare element de informație este conceput ca o abstractizare folosind noțiunea de obiect gestionat. Ele reprezintă resurse fizice sau logice care sunt gestionate, iar proprietățile acelor obiecte reprezintă informația efectivă. Pentru a înțelege ce tip de informații poate furniza un echipament, trebuie să ințelegem cum sunt reprezentate datele în contextul SNMP-ului. Structura informației de management (SMI) definește exact cum sunt denumite obiectele gestionate și ce tipuri de date au asociate. SMIv1 este descrisă în RFC 1155 dar în cursul timpului au apărut imbunatățiri concretizate în SMIv2 (RFC 2578). RFC 1155 conține descrierea unui model informațional pentru managementul rețelelor impreună cu un set generic de tipuri de date utilizat pentru descrierea informației de management.

Definirea obiectelor gestionate poate fi imparțită în trei atribute:

Numele – numele, sau identificatorul obiectului (object identifier – OID), definește în mod unic un obiect gestionat. Numele apar în două forme, una numerică și una care poate fi usor citită.

Tipul și sintaxa – tipul de date al obiectului gestionat este definit utilizand un subset al Abstract Syntax Notation One (ASN.1).

ASN.1 este un standard care descrie structuri de date pentru reprezentarea, codarea, transmiterea și decodarea datelor. Acest standard ofera un set de reguli formale pentru descrierea structurii obiectelor care sunt independente de tehnicile de codare specific unei mașini. ASN.1 a fost definit în 1984 (colaborare între OSI și ITU-T) ca parte a standardului CCITT X.409, în 1988 a fost definit de propriul standard X.208 iar în 1995 după revizii substantiale este acoperit de seria de standarde X.680. ASN.1 defineste sintaxa abstractă a informației dar nu restricționează modul în care informația este codată.

Variate reguli de codare oferă sintaxa de transfer a valorilor datelor a căror sintaxa este descrisă în ASN.1: BER (Basic Encoding Rules), CER (Cannonical Encoding Rules), XER (XML Encoding Rules) etc.

ASN.1 este folosit în protocoale ca SMTP, H323 (VoIP), SNMP etc.

Codarea – o instanță a unui obiect gestionat este codata într-un sir de octeți folosind BasicEncoding Rules (BER). BER definește cum obiectele sunt codate și decodate pentru a fi transmise peste un mediu de transport cum este Ethernet-ul. Regulile de codare sunt denumite în mod generic sintaxa de transfer în contextul ASN.1 Această sintaxa definește elemente cum ar fi: o reprezentare pentru tipuri de date de bază, o structură informației de lungime, o mijloacele pentru definirea tipurilor de date compuse bazate pe mai multe tipuri de date primitive. Fiecare element de date este codat ca un identificator de tip, o descriere a lungimii, datele efective și, acolo unde este necesar, un marcaj sfarșit de conținut. Acest tip de marcaj este denumit în mod comun codare TLV (type-length-value).

De notat că pe langă protocoalele enumerate mai sus, ASN.1 impreună cu BER este folosit în majoritatea serviciilor de telefonie celulara pentru transmiterea mesajelor de control peste rețea.

4.5 Denumirea OID-urilor

Obiectele gestionate sunt așezate într-o ierarhie sub forma de arbore. Această structură este baza pentru schema de nume a SNMP-ului. Un identificator de obiect (OID) este format dintr-o serie de numere întregi pe baza nodurilor arborelui, și desparțite prin punct. Există și o forma ce poate fi citita usor (asemănător adreselor IP), aceasta fiind o insiruire de nume separate prin punct. În figura 4.3 este reprezentată structura de arbore pertinentă pentru SNMP. În acest arbore primul nod este denumit nod-radăcină, orice parte ce conține descendenți este denumit subarbore iar extremitățile sunt denumite frunze. Exemplu de subarbori sunt ccitt(0), iso(1), și joint(2). Pentru SNMP este interesant subarborele iso(1).org(3).dod(6).internet(1) care are OID-ul 1.3.6.1 (sau iso.org.dod.internet). Reprezentarea numerică este modul în care un obiect gestionat este reprezentat într-un agent.

Ramura directory nu este utilizată în present.

Ramura mgmt defineste un set de obiecte Internet standard ce sunt gestionate.

Ramura experimental este rezervată pentru teste. Obiectele de sub ramura private sunt definite de organizații/vendori sau persone individuale.

internet OBJECT IDENTIFIER ::= { iso org(3) dod(6) 1 }

directory OBJECT IDENTIFIER ::= { internet 1 }

mgmt OBJECT IDENTIFIER ::= { internet 2 }

experimental OBJECT IDENTIFIER ::= { internet 3 }

private OBJECT IDENTIFIER ::= { internet 4 }

Prima linie declara internet ca OID 1.3.6.1 și este definit ca subarbore al iso.org.dod (1.3.6). Operatorul ::= este operatorul definiție. Celelalte ramuri sunt declarate în mod similar ca subarbori pentru internet. Subarborele private conține ramura enterprises, utilizată de vendori pentru a defini obiecte private pentru orice tip de hardware sau software. Definiția în SMI este: enterprises OBJECT IDENTIFIER ::= { private 1 }

Asignarea și gestionarea numerelor enterprise pentru fiecare organizație, vendor, instituție sau persoana individuală este facută de IANA (Internet Assigned Numbers Authority). De exemplu numarul enterprise privat pentru Cisco este 9 ceea ce duce la OID-ul de baza 1.3.6.1.4.1.9

Figura 4.3 Structura de arbore SNMP

Obiectele care au legătură directă cu SNMP se găsesc pe ramura internet care conține două mari ramuri :

mgmt=2, care este definită de către RFC-urile de la Internet Engineering Task Force (IETF) și este aceeași pentru toate obiectele SNMP

private=4, care este menținută de către Internet Assigned Numbers Authority (IANA), și este definită de către companii și organizații la care fiecare ramură este atribuită.

Management (mgmt), este ramura publică cea mai folosită, care definește parametri de management a rețelelor care sunt comuni la toate echipamentele de la toti producătorii. În continuarea acestei ramuri se găsește MIB-II (mib-2) – un MIB special care trebuie implementat de către orice echipament care suportă SNMP.(Anexa 1)

4.6 Operații SNMP

SNMPv1 definește cinci tipuri de mesaje care sunt schimbate între un manager și un agent. Fiecărui tip de mesaj îi corespunde o anumită instrucțiune SNMP. Acestea sunt:

– GET – se preiau datele (manager -> agent);

– GET-NEXT – se preia următoarea valoare (manager -> agent);

– SET – se stabilesc parametrii MIB (manager -> agent);

– RESPONSE – răspuns pentru SET/GET sau EROARE (agent -> manager);

– TRAP – se obțin informații dinspre nod spre administrator (agent -> manager).

Atunci când managerul primește o atenționare, acesta o interpretează și ia anumite decizii pe baza informației primite. Tipul atenționării este definit de câmpul tip trap din mesajul SNMP. Sunt definite șapte tipuri de atenționări (0-6), descrise în următorul tabel:

4.7 SNMP Management

O stație de lucru care rulează Windows XP/7/8/10 poate fi monitorizată și controlată prin intermediul comenzilor SNMP. Serviciile nu fac parte din pachetul standard și trebuie instalate separat: Control Panel –> Add or Remove Programs/Programs and features –> Add/Remove Window Components –> Management and Monitoring Tools –> Simple Network Management Protocol. Odată ce serviciul SNMP este acțivat el poate fi configurăt să permită unui agent SNMP accesul la sistem. Trebuie configurati parametrii Agent, Trap și Security Settings din proprietățile SNMP Service.

Pentru a acțiva această facilitate se apelează Start –>Control Panel –> Administrative Tools –> Services. Apoi se acțivează serviciile SNMP și SNMP Trap.

Valorile pentru Agent pot fi oarecare. Serviciile sunt listate în partea de jos a casetei de dialog. Acestea oferă informații care vor fi stocate în variabilele MIB-2. End-to-end se referă la variabile MIB TCP, Internet se referă la IP MIB și Datalink la adrese Ethernet hardware.

Tab-ul Security specifică numele comunităților (community names) și drepturile lor de a accesa variabilele MIB. Figura ** prezintă două community names: unul default, public care are numai acces READ_ONLY și protocol care are permisiuni READ_WRITE.

Tab-ul Traps specifică unde sunt trimise evenimentele capturate de SNMP. Acest nume de comunitate va fi folosit de sistemul de operare în mesajele de tipul trap. Numele trebuie să fie identic cu cel configurăt pe stația de management. Trap destination va conține adresa IP a stației de management. În exemplul din figura** este definită o comunitate protocol cu IP-ul 127.0.0.1.

Evenimentele SNMP pot fi interceptate folosind software specializat.

3 SNMP MIB Browser & Network Scanner – Network Device Management

Tema acestei lucrări a fost crearea unei aplicații de tip SNMP browser & Network SNMP scanner. Aplicația este formata din doua module SNMP MIB Browser și Network SNMP Scanner. Aceasta a fost programata în limbaj JavaScript cu ajutorul framework-ului Node.js care oferă o platformă pentru limbajul JavaScript in domeniul rețelistic.

3.1 Node.js

Node.JS este JavaScript ce rulează pe partea de server și a fost creat de Ryan Dahl și de alti programatorii în 2009 pe când lucrau la compania Joyent. În 2011 a fost lansat NPM (Node Package Manager) cu scopul de a facilita instalarea modulelor JavaScript create de către comunitatea Node.js. Pe masura ce comunitatea Node.js a devenit tot mai numeroasă au aparut diferite conflicte legate de modul de gestionare al viitoarelor versiuni ale Node.js.

Permite dezvoltarea de aplicații Web la nivel de server în limbajul JavaScript, recurge la V8 – procesor (interpretor) JavaScript creat de Google, implementat în C++ și disponibil liber. Oferă suport pentru cele mai importante protocoale Web și Internet HTTP (HyperText Transfer Protocol), DNS (Domain Name System), TLS (Transport Layer Security), funcționalități de nivel scăzut (socket-uri TCP).

Node.js este setat să ruleze asincron și va putea rula sincron numai în situația în care script-urile noastre vor dori asta. Node.js funcționează asincron cu scopul de a oferi un timp de raspuns cât mai rapid indiferent de cate evenimente sunt declanșate. Este foarte important să avem grija că întreg script-ul nostru să ruleze asincron și să nu rulăm o funcție sau o metoda în mod sincron decât în situatia în care nu avem alternativă, dar și în acest caz trebuie să stim exact ce facem.

Am configurăt Node.js să funcționeze că webserver cu ajutorul librăriei Express.js. https://expressjs.com/en/starter/installing.html

De asemenea am atașat și librăria Path.js. Modulul Path oferă o platforma pentru navigarea de fișiere și de directori. Funcția implicită a modulului Path variază în funcție de sistemul de operare pe care rulează o aplicație Node.js. În mod specific, atunci când rulează pe un sistem de operare Windows, modulul de cale va presupune că sunt utilizate căi de stil Windows.

https://nodejs.org/api/path.html

3.2 Pornirea aplicației

Pasul 1

Pornirea aplicației se realizează deschizând lina de comanda Command Prompt, apoi localizăm aplicația ex: E: apoi întroducem comanda cd (change directory) snmp/app apoi introducem comanda node index.js care va porni webserverul necesar pentru că aceasta aplicație să funcționeze.

Pasul 2

Deschidem un browser de internet și în campul destinat link-ului întroducem urmatorul link:

localhost:3000. Aplicatia rulează local si asculta la portul 3000 alocat pentru webserverul din Node.js. De îndata ce acest link este accesat aplicația rulează.

3.3 Network Scanner

Modulul Network Scanner scanează o rețea pentru a verifica ce device-uri sunt în rețeaua dată și dacă suporta/au activat protocolul de comunicații SNMP. Afisează lista device-urilor din rețea care au activat protocolul SNMP, afiseaza IP numele și o fotografie cu device-ul.

Aplicația funcționeaza pe baza rețelei. În acest modul avem trei câmpuri care trebuie completate/ selectate: Network IP, Subnet Mask și portul.

Pentru a studia modulul Network Scanner al aplicației am instalat și configurat alpicatiile SoftEther VPN Server și SoftEther VPN Client. Aceste aplicații sunt necesare deoarece studiul pe care l-am efectuat este realizat pe rețeaua locala administrativă a hotelului Hilton Sibiu unde lucrez ca IT Manager.

SoftEther VPN ("SoftEther" înseamnă "Software Ethernet")este unul dintre cele mai puternice și ușor de folosit soft-uri multi-protocol VPN din lume. Acesta rulează pe Windows, Linux, Mac, FreeBSD și Solaris.

SoftEther VPN Project a fost dezvoltat de Universitatea Tsukuba din Japoina mai exact de urmatorii membri ai universitatii: Daiyuu Nobori, Ph.D., Tetsuo Sugiyama, Ph.D., Genya Hatakeyama, Christopher Smith.

SoftEther VPN este o aplicatie open source. Avem posibilitatea să utilizam SoftEther pentru orice utilizare personală sau comercială.

SoftEther VPN este o alternativă optimă la serverele VPN OpenVPN și Microsoft. SoftEther VPN are o funcție de clonare a serverului OpenVPN. Putem integra ușor de la OpenVPN la SoftEther VPN. SoftEther VPN este mai rapid decât OpenVPN. SoftEther VPN suportă, de asemenea, Microsoft SSTP VPN pentru Windows Vista / 7 / 8/ 10. Nu mai trebuie să plătim taxe scumpe pentru licența Windows Server pentru funcția de acces VPN la distanță.

Dacă avem smartphone-uri, tablete sau laptop-uri, funcția de server L2TP / IPsec a serverului SoftEther VPN vă va ajuta să stabiliți o rețea VPN cu acces de la distanță din rețeaua locală. Serverul L2TP VPN al serverului SoftEther VPN este compatibil puternic cu Windows, Mac, iOS și Android.

Arhitectura SoftEther VPN

Virtualizarea dispozitivelor Ethernet este cheia arhitecturii SoftEther VPN. SoftEther VPN virtualizează dispozitive Ethernet pentru a realiza o rețea privată flexibilă privată atât pentru VPN cu acces de la distanță, cât și pentru VPN la nivel de site. SoftEther VPN implementează programul Virtual Network Adapter că un adaptor de rețea Ethernet tradițional emulat de software. SoftEther VPN implementează programul Virtual Ethernet Switch (numit Virtual Hub) că un switch Ethernet tradițional emulat de software. Soft-VPN VPN implementează sesiunea VPN că un cablu Ethernet emulat software-ul între adaptorul de rețea și comutator.

Modulul aplicației Network Scanner funcționeaza astfel:

-trebuie stabilit IP-ul de pornire al rețelei pe care dorim să facem scanarea, în cazul nostru IP-ul este 192.168.1.1;

-stabilirea SubnetMask-ului 255.255.255.0 in cazul nostru sau pentru diverse configuratii de IP-uri putem selecta alta optiune;

-stabilirea portului, în cazul nostru avem alocat portul 161 implicit SNMP.

După ce am configurat acești parametri apăsam butonul GO pentru a începe scanarea rețelei și afișarea listei device-urilor din rețea care au activat protocolul SNMP, afișează IP, numele și o fotografie cu deviceul pentru o recunoastere mai usoară.

În partea dreapta avem un tabel care ne indică rețeaua, broadcast-ul, gazda minim, gazda maxia, cate gazde avem în rețeaua scanată și cate IP-uri din rețea au raspuns interogării aplicației Network Scanner.

În urma scanări retelei administrative a hotelului Hilton Sibiu, aplicatia Network Scanner a descoperit că exista șapte device-uri care au protocolul SNMP activat.

192.268.1.1 Router Ubiquiti EdgeRouter Lite

192.168.1.2 Switch TP-LINK TL-SG2452

192.168.1.9 Server HP Proliant Gen 8

192.168.1.55 Multifunctional Canon IR2018

192.168.1.70 Multifunctional Xerox 6505DN

192.168.1.79 Multifunctional Xerox WorkCentre 7220

192.168.1.94 Multifunctional HP M521 DN

3.4 SNMP MIB Browser

Modulul SNMP MIB Browser se utilizează pentru a prelua informații variabile MIB (Management Information Base) de la dispozitivele de rețea pentru a ajuta la diagnosticarea problemelor de rețea.

Browserul SNMP MIB obține date MIB de la dispozitivele din tipologia descoperită. Folosind SNMP MIB Browser, putem naviga în cadrul MIB al dispozitivului selectat și putem extrage valoarea oricăror variabile MIB.

Browserul SNMP MIB ne permite să emitem interogări SNMP MIB pe un dispozitiv de rețea specificat și să afișeze rezultatele acestor interogări.

Browserul SNMP MIB ne permite să efectuam acțivități de diagnosticare atunci când încercam să rezolvam problemele de pe dispozitivele de rețea. În special, browserul SNMP MIB ne permite să efectuam următoarele acțivități:

– vizualizarea valorilor obiectelor MIB pentru orice dispozitiv din rețea. Putem să navigam arborele MIB, să emitem interogări SNMP – utilizând comenzile Get, Get Next, Get Subtree, Get All – și vizualizam datele rezultate. Aceste date ne pot ajuta să rezolvam problemele ale uni dispozitiv.

– diagnosticarea imediată pe dispozitivele de rețea care afișează un comportament defect. Acest modul sunt patru campuri care trebuie completate/selectate: Adress (adresa IP a device-ului care dorim să aflăm diverse informații din MIB-ul acestuia), portul (161 implicit pentru protocolul SNMP), OID (Object Identifier) și Operation( pentru a executa operațiile Get, Get Next, Get subtree, Get all) toate aceste detalii sunt configurate pe comunitatea public.

Operația GET se efectueaza pentru a obține una sau mai multe valori din obiectele gestionate.

GET NEXT: această operație este similară cu operația GET, dar preia valoarea următoului OID din arbore. Această operație este utilizată pentru traversarea arborelui MIB.

GET ALL: aceasta operație preia toate informatiile generate de OID.

GET SUBTREE: aceasta operație oferta toate informatiile ale unui arbore sau subarbore generate de OID.

Exemple practice ale aplicației SNMP MIB Browser

a) Aflarea detaliitor hardware și software a serverului HP Proliant Gen8 care are adresa IP 192.168.1.9 , portul implicit SNMP 161, OID .1.3.6.1.2.1.1.0 și executand comanda GET.

Aplicația în coloana Value ne va afișa detaliile hardware și software ale device-ului interogat.

b) Aflarea traficului făcut de placa de rețea a server-ului HP Proliant Gen8 cu IP 192.168.1.9 prin intoducerea OID .1.3.6.1.2.1.1.3.0 și executand operația GET, valoarea va fi explimata în kbps.

c) Traficul facut de routerul Edge Router Lite avand IP 192.168.1.1 prin interogarea OID.1.3.6.1.2.1.1.3.0, valoarea va fi explimata în kbps.

d) Aflarea detaliilor Switch-ului TP- LINK TL-SG2452 cu IP 192.168.1.2, cate porturi are și ce fel de porturi prin interogarea OID .1.3.6.1.4.1.11863.1.1.15.1.1.1.1.0 și executand operația GET ALL.

e) Descoperirea arborelui MIB pentru switch-ul TP- LINK TL-SG2452 apeland OID .1.3.6.1.2.1.1 și executand operația GET SUBTREE. Aplicația ne va afisa diverse informatii cum ar fi: numele device-ului, locatia acestuia, website-ul producătorului, traficul făcut de acesta și detalii despre cate porturi sunt disponibile și ce fel de porturi.

f) În acest exemplu am apelat IP 192.168.1.79 care aparține multifuncționalei Xerox 7220, am apelat consecutiv urmatoarele OID .1.3.6.1.2.1.43.1.1.16.1 pentru a afla numele multifuncționalei, .1.3.6.1.4.1.253.8.53.13.2.1.6.1.20.33 pentru a afla cate pagini color a printat, .1.3.6.1.4.1.253.8.53.13.2.1.6.1.20.34 pentru a afla cate pagini alb-negru a printat și .1.3.6.1.2.1.43.18.1.1.8.1.3 pentru a afla ce resurse trebuie schimbate pentru a putea continua funcționalitatea acestui multifuncțional.

Codul aplicației SNMP MIB Browser & Network SNMP Scanner:

Index.js

Main.js

Scanner.ejs

Default.ejs

Snmp.js

.project

Bower.json

Package.json

Readme.md

Main.css

Concluzii

Nevoia de sisteme de management al rețelelor este tot mai mare datorită cresterii acestora în dimensiune și complexitate. Protocolul SNMP este o opțiune viabilă pentru astfel de sisteme deoarece este standardizat, este relativ simplu permițand dezvoltarea de aplicații in-house într-un timp scurt și foarte multe echipamente îl suportă. Desigur, acest protocol are și dezavantaje, cum ar fi utilizarea protocolului UDP pentru transport ceea ce nu garanteaza livrarea mesajelor sau lipsa securitații pentru versiunile 1 și 2c dar acestea nu cantaresc foarte mult în luarea deciziei de utilizare a protocolului SNMP pentru gestionarea echipamentelor. Există și protocoale care depasesc aceste neajunsuri și ofera în plus alte funcționalitati (de exemplu protocolul Q3), dar complexitatea lor este sporită și uneori nu se justifica. Gama sistemelor de management al rețelelor este foarte variata, plecand de la pachete software « free » ce conțin un set de aplicații minime necesare în gestionarea rețelei prin SNMP precum și instrumente de dezvoltare a aplicațiilor și pana la sisteme comerciale foarte complexe ce pot gestiona zeci de mii de noduri, oferind funcționalitati deosebite, rapoarte și statistici privind incidentele, corelarea evenimentelor din rețea etc., dar toate aceste funcționalități având un preț mai mare. În momentul în care se ia decizia ca un nou echipament să fie întrodus în rețea, trebuie raspuns la întrebarea: « Care sunt costurile de management ale acestui echipament ? » Dacă acel tip de echipament stie să comunice SNMP, iar informațiile care se pot obține sunt cele dorite, atunci costurile pot fi minime, iar un sistem de management bazat pe SNMP este alegerea potrivită.

SNMP este un protocol de bază pentru monitorizarea sistemelor (rutere, imprimante, sisteme multimedia, IPTV, VOIP).

SNMP este un protocol foarte puternic pentru monitorizarea unei rețele informatice,deoarecere se poate folosi pe orice dispozitiv: calculatoare, switch-uri, access point-uri, imprimante, multifuncționale pe care rulează orice sistem de operare:Windows sau sistemele bazate pe Linux.

Bibliografie

[1] Stephen B. Morris, Network Management, MIBs and MPLS: Principles, Design and

Implementation, Addison Wesley, 2003

[2] Douglas Mauro, Kevin Schmidt, Essential SNMP, 2nd Edition, O'Reilly, 2005

[3] David T. Perkins (Author), Evan McGinnis (Author), Understanding SNMP MIBs, Prentice Hall, PTR, 1996

[4] RFC 1155 – Structure of Management Informațion(SMI)

[5] RFC 1157 – Simple Network Management Protocol (SNMP)

[6] SNMP Tutorial: The Fast Track Introduction to SNMP Alarm Monitoring by Marshall DenHartog

[7] Node.js https://nodejs.org/en/docs/

[8] SoftEther VPN Project https://www.softether.org/

[9] Wireshark https://wiki.wireshark.org/SNMP

[10] Wikipedia Simple Network Management Protocol https://en.wikipedia.org/wiki/Simple_Network_Management_Protocol

[11] Internetworking with TCP/IP.: Principles, protocols, and architecture, Book by Douglas Comer, 1988

[12] The TCP/IP Guide: A Comprehensive, Illustrated Internet Protocols Reference, Book by Charles M. Kozierok, 2005

8. Anexe

Anexa 1

Anexa 2

Anexa 3