Sunteți pe pagina 1din 84

NECLASIFICAT

Cuprins

Capitolul I . Introducere ........................................................................................ 5

Capitolul II . Aspecte teoretice .............................................................................. 7

2.1 Tipuri de monitorizare a reelei ................................................................... 7

2.2 Protocolul de reea ....................................................................................... 8

2.3 Parametrii unei reele ................................................................................ 10

2.3.1 Latena (Latency) ............................................................................... 10

2.3.2 Rata pierderilor (Loss rate) ................................................................ 11

2.3.3 Detectarea rutei (Path Detection) ....................................................... 12

2.3.4 Limea de band ............................................................................... 12

2.4 Instrumente de msurare ........................................................................... 13

2.4.1 Msurtori ale latenei ........................................................................ 13

2.4.2 Msurtori ale pierderilor de rat (Loss rate)..................................... 13

2.4.3 Msurtori ale detectrii rutei (Path Detection) ................................. 14

2.4.4 Instrumente cu utilizri multiple ........................................................ 15

Capitolul III . Protocoale folosite pentru monitorizare ....................................... 17

3.1 Protocoalele fundamentale ale managementului de reea ......................... 17

3.1.1 Internet Control Message Protocol..................................................... 17

3.1.2 Simple Network Management Protocol (SNMP) .............................. 19

3.1.3 Protocoale de management n cadrul sistemului de operare Windows


..................................................................................................................... 28

3.1.4 Telnet .................................................................................................. 32

3.1.5 SSH ..................................................................................................... 33

3.1.6 Syslog ................................................................................................. 34


NECLASIFICAT

din
NECLASIFICAT

3.1.7 Protocoale bazate pe flux de date ( The Flow-Based Protocols) ....... 35

3.1.8 Cisco IP Service Level Agreements ................................................... 38

Capitolul IV . Metode de monitorizare ............................................................... 41

4.1 Intrusion Detection .................................................................................... 41

4.2 Packet Sniffing .......................................................................................... 43

4.3 Vulnerability Scanning.............................................................................. 44

4.4 Firewall Monitoring .................................................................................. 45

4.5 Penetration testing ..................................................................................... 47

Capitolul V . Softuri pentru monitorizare ........................................................... 49

5.1 MRTG (Multi Router Traffic Grapher) software ...................................... 49

5.2 RRDtool (Round-robin Database) software .............................................. 51

5.3 Munin software ......................................................................................... 52

5.4 Nagios software ......................................................................................... 54

5.5 Zabbix software ......................................................................................... 57

5.6 Cacti software ............................................................................................ 59

5.7 Caracteristici PRO i CONTRA ale softurilor .......................................... 61

Capitolul VI . Implementare practic i simulri ................................................ 66

6.1 Componentele si prezentarea general a reelei locale din GNS3 ............ 66

6.2 Configurare echipamente .......................................................................... 67

6.3 Simulri i rezultate obinute .................................................................... 77

Capitolul VII .Concluzii i perspective ............................................................... 82

Bibliografie .......................................................................................................... 84

NECLASIFICAT

din
NECLASIFICAT

List figuri :

Fig. 2.1.1 Setarea unei monitorizri pasive11


Fig. 2.2.1 Structura segmentului ICMP..............................................................11
Fig. 2.2.2 Formatul pachetului UDP ..11
Fig. 2.3.1.1 Reprezentare One Way Delay.........................................................11
Fig. 2.3.1.2 Reprezentare Round Trip Time........................................................11
Fig. 2.3.2.1 Pierderea unui pachet n cazul n care nu ajunge la server..............11
Fig. 2.3.2.2 Pierderea unui pachet n cazul n care acesta
nu mai ajunge la client.....................................................................11
Fig 2.3.3.1 Exemplu de detectare a unei rute......................................................11
Fig. 2.4.3.1 Exemplu de erori n cazul Traceroute...........................................11
Fig. 3.1.1.1 Executarea comenzii ping n linie de comand................................11
Fig. 3.1.1.2 Comanda ping de tip ICMP (Monitorizare activ)..........................11
Fig. 3.1.2.1 Arhitectura SNMP............................................................................11
Fig. 3.1.2.2 Configuraia reelei SNMP...............................................................11
Fig. 3.1.2.1.1 Grupul de obiecte MIB-II..............................................................11
Fig. 3.1.2.2.1 Mesajul SNMPv1..........................................................................11
Fig. 3.1.2.3.mpachetarea datelor n cazul SNMPv2...........................................11
Fig. 3.1.2.4.1 Motorul SNMP..11
Fig. 3.1.2.4.2 Aplicaie SNMP............................................................................11
Fig. 4.1.1 Exemplu de sistem de detecie i prevenire a intruziunilor.11
Fig. 4.1.2 Sistem de detectare a intruziunilor pasiv11
Fig. 4.2.1 Exemplu general pentru packet sniffing............................................11
Fig. 4.3.1 Componentele unui Scaner................................................................11
Fig. 4.4.1 Modul de lucru al unui firewall..11
Fig. 4.5.1 Etapele unei testri de penetrare.........................................................11
Fig. 5.1.1 Exemplu de grafic utiliznd MRTG11
Fig. 5.2.1 Interfaa de testare a RRDtool-ului.11
Fig. 5.3.1 Interfa grafic Munin..11
Fig. 5.4.1 Interfa web pentru Nagios...11
Fig. 5.4.2 Tip alert n softul Nagios..................................................................11
Fig. 5.4.3 Schema de lucru a sistemului de monitorizare Nagios.......................11
Fig. 5.5.1 Panoul central Zabbix 5.6.1 Afiare date despre metrici n Cacti..11
Fig. 6.1.1 Schema de analiz practic din GNS3...11
Fig. 6.2.1 Configurare libphp-adodb..11
Fig. 6.2.2 Configurare Cacti - pasul 1.....11
Fig. 6.2.3 Configurare Cacti - pasul 211
Fig. 6.2.4 Configurare Cacti pasul 3.11
Fig. 6.2.5 Configurare Cacti pasul 411
Fig. 6.2.6 Configurare Cacti pasul 5.11
Fig. 6.2.6 Configurare Cacti pasul 611
Fig. 6.2.6 Configurare Cacti pasul 711
NECLASIFICAT

din
NECLASIFICAT

Fig. 6.2.12 Generatorul de trafic Ostinato 0.8-1..11


Fig. 6.3.1 Seciunea Devices din Cacti................................................................11
Fig. 6.3.2 Trafic pe interfaa Fa0/0 a routerului R1 fr generare
de trafic suplimentar...........................................................................11
Fig. 6.3.3 Generare pachete de tip TCP ctre interfaa Fa0/0.11
Fig. 6.3.4 Captur de date n Wireshark pe interfaa Fa0/011
Fig. 6.3.5 Trafic pe interfaa Fa0/0 a routerului R1 cu
generare de trafic suplimentar............................................................11
Fig. 6.3.6 Statistici pentru Serverul de fiiere (24 h)..11
Fig. 6.3.7 Statistici pentru cele 4 pc-uri (Win. Xp) (24h)..11
Fig. 6.3.8 Traficul pe cele 2 routere i pe serverul web (24h).11

Acronime :

ADSL Asymmetric Digital Tehnologie care permite trasmiterea


Subscriber Line de date digitale
MIB Management Information Baza de informaii de management
Base
NMC Network Maintenance Centre Centru de management de reea
NTM Network Traffic Management Managementul traficului de reea
OID Object Identifier Identificatorul obiectului
SNMP Simple Network Management Protocolul de management de reea
Protocol
CGI Common Gateway Interface Interfaa comun cu gateway-ul
WMI Windows Management Infrastructura de management de
Instrumentation date pentru Windows
NMS Network Management Suport de management pentru reea
Solution
WQL WMI Query Language Subset al limbajului SQL
SLA Service Level Agreement Angajament ntre provider i
customer
MPLS Multiprotocol Label Switching Tehnic de transfer a datelor
ICMP Internet Control Message Protocol pentru semnalizarea i
Protocol diagnosticarea problemelor din reea

NECLASIFICAT

din
NECLASIFICAT

Capitolul I . Introducere

Dac ar fi s ne raportm la prezent, se poate observa c Internetul a ajuns


s fie susinut de o mulime de structuri private (firme comerciale). Internetul
prezint la baza sa nite specificaii foarte detaliate, un exemplu bine cunoscut
fiind aa-numitele protocoale de comunicaie, care au rolul de a descrie regulile
i tehnicile de transmitere a datelor n aceast reea extins.
Aceast extindere treptat a reelelor de comunicaii a adus la apariia
nevoii de management al reelelor i la crearea anumitor organizaii internaionale
de reglementare a comunicaiilor. Instituiile cu un puternic rol privind
standardizarea comunicaiilor sunt ITU-T (International Telecommunication
Union Telecommunication), IEEE (Institute of Electrical and Electronics
Engineers), ETSI (European Telecommunications Standards Insitute).
Termenul de management n cadrul reelelor de comunicaii a aprut ca
urmare a extinderii numrului de utilizatori, a mririi dimensiunii reelelor i
crerii unei diversificri privind serviciile pe care reelele le puteau oferi.
Monitorizarea reelelor de comunicaii este o ramur principal n cadrul
managementului de reea. Dac ne raportm la o organizaie, monitorizarea reelei
reprezint o funcie critic i extrem de important care poate salva resurse
financiare destul de importante, costurile de ntreinere ale infrastructurii, dar i
creterea performanei reelei.
Lucrarea de fa prezint noiuni teoretice despre managementul reelei de
comunicaii, avnd ca direcie principal procesul de monitorizare.Pe lng
aspectele teoretice, lucrarea va conine informaii despre tehnologiile actuale
folosite n cadrul managementului de reea. n cadrul procesului de monitorizare
se vor urmri metodele existente care stau la baza acestui proces avnd ca
finalitate practic simularea unei reele locale de comunicaii.Reeaua va fi
realizat in programul GNS3 , iar n cadrul acesteia se vor aplica i analiza
anumite metode de monitorizare.
Capitolul doi debuteaz cu o descriere mai n amnunt a procesului de
monitorizare ca parte component a managementului de reea i continu cu
prezentarea diferitelor instrumente de msurare. Pe lng aceste dou mari direcii
pe care le urmrete capitolul doi, se va face i o prezentare general a
protocolului de reea i a caracteristicilor reelei.
n capitolul trei sunt descrise principalele protocoale utilizate n studiul i
aplicarea monitorizrii n cadrul reelei. Protocoalele vor fi att cele utilizate pe
platforma Windows, ct i cele care sunt utilizate pe toate sistemele de operare.
Capitolul conine att noiuni teoretice generale despre protocoale, ct i anumite
informaii legate de cteva perspective ale unor mari vendori cum ar fi Cisco,
Juniper Networks i alii.
NECLASIFICAT

din
NECLASIFICAT

Capitolul patru are rolul de a prezenta tipurile de metode de monitorizare


existente i utilizate de ctre cunosctorii n domeniu. n cadrul acestui capitol se
vor detalia metodele n sine de monitorizare. Cteva din aceste metode vor fi
utilizate i n cadrul implementrii practice pentru a putea evidenia eficiena i
rolul fiecrei metode existente.
n capitolul cinci sunt prezentate cteva dintre softurile de monitorizare mai
cunoscute , printre care i softul ales de mine pentru a analiza i rula cteva dintre
metodele de monitorizare . Pe lng detalierea fiecrui soft n parte, exist i o
comparaie general ntre acestea, artnd att dezavantajele ct i avantajele
fiecrui soft n parte.
Capitolul ase este dedicat implementrii i simulrii practice a lucrrii. De-
a lungul capitolului sunt menionate att configurrile echipamentelor folosite n
cadrul crerii proprii reele, ct i cele dou scenarii concepute de mine.
Simulrile, rezultatele i tot ce ine de implementarea practic a lucrrii sunt
menionate n acest capitol.
Capitolul apte este ultimul capitol i conine concluzii i perspective legate
de tema de studiu aleas i menionat la nceputul acestei lucrri scrise. Pe lng
concluziile personale exist i concluzii generale, dar i anumite constatri
generale legate de procesul de monitorizare.

NECLASIFICAT

din
NECLASIFICAT

Capitolul II . Aspecte teoretice

Managementul de reea const n totalitatea aciunilor prin care reeaua de


comunicaii este controlat i supervizat. ndeplinirea acestor obiective se
bazeaz pe funcii de mentenan, supervizare i control.
Monitorizarea const n nregistrarea regulat i observarea serviciilor din
cadrul unui server sau a unui element din reea. Colectarea informaiilor
referitoare la toate aspectele serverului reprezint o mic definiie a procesului de
monitorizare.
Monitorizarea reelei implic metode multiple, care sunt implementate n
scopul meninerii securitii i integritii unei reele interne. Sistemele de
supraveghere permit identificarea proceselor desfurate i scalarea lor, rezultate
n urma crora se realizeaz alocarea resurselor n funcie de nevoile
organizaiei,detectarea posibilelor ameninri interne si externe, totul pentru a
asigura o vizibilitate ct mai mare, pentru a lua msurile cele mai eficiente.
Este foarte important ca cei care au grij de reea i de serviciile care sunt
monitorizate sa fie informai periodic, de preferat ct mai repede, pentru ca acetia
s poat lua msurile potrivite situaiei.
Conceptul de monitorizare a reelei este de a deveni de fapt o parte a unui
proces de monitorizare mult mai mare care implic examinarea n timp real i
trucuri ale procesului din ntreaga organizaie.

2.1 Tipuri de monitorizare a reelei

Exist dou abordri de baz pentru monitorizarea reelei i anume :

- Monitorizarea activ
- Monitorizarea pasiv

Monitorizarea activ presupune injectarea unor date suplimentare n


scopul monitorizrii. Monitorizarea activ suport costurile de expediere a unui
trafic suplimentar n reea. Cu toate acestea, n cele mai multe situaii, mrimea
pachetului de date este relativ mic n comparaie cu capacitatea real a reelei, de
aceea costul injectrii de trafic suplimentar este minim. Costul de injectare a
traficului poate fi redus prin reducerea ratei de probare, ns acest lucru ar putea
duce la scderea calitii caracteristicilor msurate. Acest tip de monitorizare
ofer un control complet n ceea ce privete intervalul de monitorizare,
dimensiunea pachetului i calea care va fi supus monitorizrii.
Monitorizarea pasiv reprezint procesul de observare a traficului existent
n reea i colectare de informaii de la acesta, fr injectarea unor date
suplimentare n reea. ntr-un sistem bazat pe msuratori pasive, informaia
msurat este preluat din pachetele trimise de o alt aplicaie. Pachetele sunt
NECLASIFICAT

din
NECLASIFICAT

capturate de aplicaia de monitorizare, care este implementat fie la sursa i


destinaia hostului, fie de-a lungul unui tunel. Modul pasiv de monitorizare evit
introducerea datelor suplimentare de trafic n reea. Cu toate acestea, n modul
pasiv aplicaia de monitorizare are un acces limitat de control asupra intervalului
de monitorizare, mrimii pachetului sau cii ce trebuie s fie monitorizate. Mai
departe, datorit creterii capacitii de baz a legturilor (link-urilor) este
costisitor s identifici i s msori pachetul unui anumit flux. Monitorizarea
pasiv ar putea de asemenea s creasc procedurile legate de confidenialitate.
Preferina pentru un anumit tip de monitorizare variaz n funcie de
aplicaie. De exemplu, o aplicaie de msurare a performanei cum ar fi un sistem
de detectare a intruziunilor prefer o abordare pasiv , pe cnd o aplicaie privind
mbuntirea performanelor va dori o abordare activ. O aplicaie poate folosi
de asemenea i combinarea celor dou abordri pentru o eficien mai mare.[1]

Monitoring Point

Fig. 2.1.1 Setarea unei monitorizri pasive

2.2 Protocolul de reea

Pentru monitorizarea pasiv, sistemul de msurare (monitorizare) nu are


vreo preferin n a alege protocolul de baz de msurare al reelei i anume dac
aplicaia de monitorizare va supraveghea pachetele care sunt trimise de o alt
aplicaie n desfurare. Cu toate acestea, n abordarea activ, sistemul de
monitorizare trebuie s decid ce protocol de monitorizare se va folosi pentru
trimiterea de date suplimentare.
Internet Control Message Protocol(ICMP) este un protocol din suita
TCP/IP care este folosit la diagnosticarea i semnalizarea problemelor din reea.
Acest protocol este definit n standardul RFC792. Mesajele de tip ICMP sunt
ncapsulate n interiorul pachetelor IP. Protocolul opereaz la nivelul trei i anume
nivelul Reea i nu are nevoie de stabilirea unei conexiuni prin metoda de tip
handshake.

NECLASIFICAT

din
NECLASIFICAT

Bii 0-7 8-15 16-23 24-31

0 Tip Cod Suma de control

32 Restul antetului

Fig. 2.2.1 Structura segmentului ICMP

Transmission Control Protocol (TCP) este un protocol al stivei TCP/IP care


servete la transportul de date, de aici rezultnd si poziia acestuia in cadrul stivei
i anume nivelul transport. n special, TCP ofer ncredere, asigur livrarea
ordonat a unui flux de octei de la un program de pe un computer la alt program
de pe un alt computer aflat n reea. Printre aplicaiile cele mai uzuale ce utilizeaz
TCP putem enumera World Wide Web (WWW), pota electronic (e-mail)
i transferul de fiiere (FTP). Instrumentele bazate pe TCP, de asemenea, solicit
ca gazda de destinaie (destination host) s execute un serviciu pe un port
desemnat. Gazda surs (sending host) stabilete o conexiune de tip TCP ctre
destinaie prin intermediul unui acord bilateral i trimite date ctre gazda
destinaie la portul serverului. Serverul de la destinaie va rspunde printr-un mod
unic folosit n msurarea reelei. O limitare important a instrumentelor bazate pe
protocolul TCP este aceea c protocolul va lua singur deciziile, din moment ce
acesta nu este un protocol bazat pe pachete de date. Prin utilizarea diverselor
optimizri, inclusiv algoritmul prezentat in RFC 896[3] care face referire la
controlul congestiei, pachetele de tip TCP vor fuziona i vor avea dimensiuni mai
mici.
User Datagram Protocol (UDP) este un protocol de comunicaie pentru
calculatoarele ce aparin nivelului Transport al modelului standard OSI. mpreun
cu protocolul de internet (IP), acesta face posibil trimiterea mesajelor ntr-o reea.
Spre deosebire de protocolul TCP, UDP constituie modul de comunicaie far
conexiune. Din moment ce UDP este un protocol bazat pe trimiterea de pachete,
acesta permite trimiterea de date suplimentare la intervale controlate de timp.

Bii 0-15 16-32

0 Portul surs Portul destinaie

32 Lungime Suma de control

64 Date

Fig. 2.2.2 Formatul pachetului UDP

NECLASIFICAT

din
NECLASIFICAT

2.3 Parametrii unei reele

Dup ce s-au identificat principiile de baz ale procesului de monitorizare,


n continuare se vor descrie diverse abordri pentru msurarea caracteristicilor
reelei. Fiecare din cele patru caracteristici ale reelei (latena , rata pierderilor,
detectarea rutei i limea de band) sunt discutate n continuare sub form de
subcapitole, ce vor explica conceptele de baz ale fiecrei caracteristici i vor
descrie diferitele abordri pentru msuratorile fiecrei caracteristici n parte.

2.3.1 Latena (Latency)

Latena a fost i este cea mai msurat caracteristic de reea. Aceasta se


refer la timpul (n ms ) necesar pachetului de date pentru a traversa reeaua de la
gazda surs la gazda destinaie. Latena ntre dou gazde ar putea varia din dou
motive: din cauza congestiei i a schimbrilor rutei. Atunci cnd un pachet este
trimis de la expeditor ctre destinatar , acesta traverseaz mai multe routere
intermediare, fiecare dintre acestea avnd ntrzierile proprii. Prin urmare, dou
pachete succesive ar putea urma ci diferite, rezultnd latene diferite pentru
fiecare pachet n parte. Schimbrile de rut sunt destul de ntlnite din cauza
congestiilor sau a erorilor ce apar n reea. Prin urmare, variaia latenei poate fi
utilizat ca metod de detectare a congestiei ntre dou puncte. Noiunea de laten
poate fi asociat cu termenul OWD (One-Way Delay) sau cu termenul RTT
(Round Trip Time).

Internet

Client OWD Server

Fig. 2.3.1.1 Reprezentare One Way Delay

Internet

Client RTT Server

Fig. 2.3.1.2 Reprezentare Round Trip Time

NECLASIFICAT

din
NECLASIFICAT

2.3.2 Rata pierderilor (Loss rate)

Rata pierderilor unei ci reprezint numrul pachetelor ce sunt aruncate n


timp ce traverseaz reeaua. Exist mai multe motive pentru care pachetele se
pierd, ns n cazul unei ci cu band limitat, routerele intermediare pun
pachetele ntr-o coad de ateptare. Cu toate acestea, n cazul n care coada de
ateptare a routerului se apropie de capacitatea de stocare, atunci routerul arunc
pachetele. Pierderea de pachete ar putea avea loc, de asemenea, din cauza unor
defeciuni hardware la router sau la gazda de destinaie. Detectarea pierderii
pachetelor este o adevrat provocare. n teorie, pierderea de pachete poate fi
detectat dac un rspuns la o solicitare nu este primit de ctre expeditor ntr-un
anumit interval de timp. Cu toate acestea, expeditorul (entitatea care trimite
cererea) se confrunt cu o provocare n determinarea duratei de pauz (timeout).
Un rspuns de la gazda de destinaie ar putea fi amnat din motive multiple,
incluznd round trip-ul mare (RTT-ul) , o cale aglomerat, serverul s fie foarte
ncrcat sau chiar viteza mic de conexiune la expeditor. n cazul n care un
expeditor adopt o cale sigur de trecere prin implementarea unui timp mare de
timeout, atunci el va avea parte de performane mai mari, din moment ce un pachet
pierdut poate fi detectat mai devreme. Pe de alt parte, n cazul n care timpul de
ateptare este mai mic, atunci expeditorul se poate trezi cu formarea unei congestii
n reea datorit multitudinilor de cereri trimise, sau ar putea trage o concluzie
greit cum c un pachet ar fi eronat (pierdut), cnd de fapt pachetul doar este n
ntrziere.

Internet X
Packet
Loss Server
Client

Fig. 2.3.2.1 Pierderea unui pachet n cazul n care nu ajunge la server

Internet
X
Packet Server
Client Loss

Fig. 2.3.2.2 Pierderea unui pachet n cazul n care acesta nu mai ajunge la
client
NECLASIFICAT

din
NECLASIFICAT

2.3.3 Detectarea rutei (Path Detection)

O cale de internet const n diferite noduri conectate prin routere.


Detectarea rutei este procesul de determinare (inclusiv numele i adresa IP) cu
privire la toate routerele intermediare vizitate atunci cnd un pachet este trimis
peste o cale de Internet. De reinut c detectarea rutei este diferit de modul de
descoperire a topologiei. Detectarea rutei este procesul de determinare a routerelor
ce sunt traversate de un pachet ce este trimis de-a lungul unei ci, n timp ce
descoperirea topologiei se ocup cu determinarea tuturor combinaiilor de
formare a unei ci ntre dou gazde. Procesul de determinare a rutei reprezint
practic un instrument ce poate fi utilizat n descoperirea topologiei.

A D

Server

Fig 2.3.3.1 Exemplu de detectare a unei rute

Calculul traiectoriilor de-a lungul Internetului se realizeaz prin


intermediul unor protocoale de rutare, care sunt clasificate n dou mari categorii:
Internet Gateway Protocols i Exterior Gateway Protocols, cum ar fi BGP. Primul
tip de protocoale se refer la traseul n cadrul unui sistem autonom, n timp ce al
doilea tip de protocoale este utilizat atunci cnd se face rutare ntre sisteme
autonome.

2.3.4 Limea de band

Limea de band cuantific rata de date a unui link de reea sau a unei ci
de reea ce poate fi transferat. Se msoar n bps sau n bii pe secund. Termenul
de lime de band poate fi utilizat pentru a se referi la dou tipuri de viteze. Viteza
de ncrcare (Upload) indic rata la care datele sunt trimise la destinaie, n timp
ce viteza de descrcare (Download) se refer la rata la care datele sunt
recepionate. Dac o cale are viteza de ncrcare aproximativ egal cu cea de
NECLASIFICAT

din
NECLASIFICAT

descrcare, atunci acea lime de band este una simetric. Cele mai multe reele
principale sunt bazate pe lime de band simetric. Cu toate acestea, acest lucru
nu este neaprat adevrat pentru utilizatorii finali, inclusiv utilizatorii de acas
care se bazeaz pe cablu sau pe tehnologia ADSL. Motivul pentru aceast
diferen este faptul c majoritatea utilizatorilor de acas sunt de obicei interesai
de partea ce implic viteza de descrcare, prin urmare, furnizorii de servicii
Internet (Internet Service Providers) aloc mai multe resurse pentru aceast
ramur a limii de band. Pentru msurarea limii de band sunt importani doi
parametrii: capacitatea i limea de band disponibil.

2.4 Instrumente de msurare

n aceast seciune sunt prezentate cateva instrumente importante de


msurare. Acest subcapitol este n strns legtur cu subcapitolul 2.3 i este
divizat n patru sub-diviziuni. Primele trei sunt dedicate fiecrei caracteristici
specifice reelei, n timp ce a patra descrie cateva instrumente ce prezint utilizri
multiple.

2.4.1 Msurtori ale latenei

Ping este un utilitar de msurare a latenei utilizat la scar larg. Acesta este
o component a majoritii sistemelor de operare, inclusiv UNIX i Windows.
Ping-ul are multiple utilizri, cum ar fi folosirea n cadrul msurrii timpului de
rund (RTT) ntre dou gazde, sau folosirea la detectarea de pachete pierdute de-
a lungul unui traseu. Acest utilitar funcioneaz prin trimiterea unei cereri de tip
ICMP (Internet Control Message Protocol) ctre gazda destinaie i asteptarea
unui rspuns tot de tip ICMP din partea gazdei destinaie. Solicitarea de tip ICMP
este un tip de mesaj care trebuie trimis de fiecare gazd sau router. Gazda surs
trimite o serie de mesaje de tip ping ce sunt identificate printr-o secven
numerotat, iar mesajele de rspuns corespunztoare sunt folosite pentru a se
putea face comparaia i pentru a se putea calcula RTT-ul.
Fping este un accesoriu al utilitarului ping , fiind o variant mbuntit
prin faptul c poate trimite mesaje mai multor gazde destinaie n acelai timp, pe
cnd ping poate trimite doar la o singur gazd. Gazdele pot fi specificate n linie
de comand sau prin intermediul unui fiier. Atat ping ct i fping pot demonstra
precizia limitat a routerelor, filtrelor de firewall n legtur cu problemele de
securitate. Dac un firewall va filtra pachete de tip ping, acesta le va arunca nainte
de a ajunge la destinaia dorit[5].

2.4.2 Msurtori ale pierderilor de rat (Loss rate)

NECLASIFICAT

din
NECLASIFICAT

Sting este un instrument bazat pe protocolul TCP care msoar pierderea


de pachete dintre dou gazde. Se poate detecta cu precizie direcia pierderii
pachetului, adic dac pierderea a avut loc nainte de a ajunge de la surs la
destinaie sau invers. Instrumentul Sting cere ca gazda s ruleze un serviciu bazat
pe protocolul TCP cum ar fi un server web sau un server telnet. Acest protocol
este mprit n dou faze. n prima faz, gazda surs trimite o serie de pachete de
date de tip TCP spre serviciul ce ruleaz pe gazda destinaie. Fiecare pachet
prezint o secven numerotat ce crete pe msur ce pachetele apar n
transmiterea pe rut. inta gazd rspunde cu o confirmare pentru fiecare pachet
recepionat. n a doua faz, gazda surs trimite iniial un pachet de date cu o
secven mai mare dect pachetul anterior.

2.4.3 Msurtori ale detectrii rutei (Path Detection)

Traceroute (tracert n Windows) este un utilitar de urmrire a rutei care este


utilizat pentru detectarea rutei sau pentru erorile din reea. Traceroute
funcioneaz prin trimiterea unei serii de pachete IP cu valori incrementate ale
valorii de timp de supravieuire (TTL-Time to Live). La fiecare pas, trei pachete
cu aceeai valoare TTL sunt trimise. Cnd prima serie de pachete ( cu TTL 1)
sosete la primul nod, routerul arunc pachetele i transmite mesajul ICMP avnd
valoarea timpului depit mpreun cu adresa surs a expeditorului. n acest mod,
o serie de mesaje de tip traceroute sunt trimise fiind incrementat valoarea TTL,
colecteaz informaii despre fiecare router de-a lungul cii i apoi se va construi
noua cale de reea.
TCPtraceroute este o implementare de tip TCP a utilitarului traceroute.
Explicaia din spatele utilizrii protocolului TCP este aceea de a putea trece de
firewall-urile care blocheaz datele de tip UDP i ICMP. Spre deosebire de
scheme convenionale de tip traceroute care trimit mesaje de tip UDP sau ICMP
i ateapt un anumit timp , TCPtraceroute trimite un mesaj de sincronizare de tip
TCP pe portul de destinaie 80. n cazul n care inta gazd ruleaz vreun serviciu
pe portul 80, atunci ea va rspunde cu confirmare de tip SYN ACK, astfel dac
gazda nu ruleaz niciun serviciu pe acel port, va rspunde cu un mesaj de tip RST.
n cazul n care expeditorul primete un mesaj de tip SYN ACK , atunci acesta va
trimite un mesaj de tip RST pentru a reseta conexiunea.
Paris Traceroute a fost dezoltat pentru a mbunti acurateea utilitarului
traceroute. Traceroute sufer de dou defecte majore i anume: unul const
raportarea eronat de legturi false ntre routere, iar al doilea defect const n
posibilitatea de a se pierde legturi deja existente ntre routere. Pentru a nelege
aceste dou deficiene, se va prezenta mai jos un exemplu.

NECLASIFICAT

din
NECLASIFICAT

C E

F
A

Client Server

B D
Fig. 2.4.3.1 Exemplu de erori n cazul Traceroute

n figura de mai sus clientul trimite pachetele de traceroute crescnd


valoarea TTL-ului ctre server. Routerul A implementeaz echilibrarea ncrcrii
i selecteaz fie routerul C, fie routerul B, bazndu-se pe politica de echilibrare a
sarcinii. Pentru primul pachet trimis de ctre client cu o valoare a TTL-ului 1,
routerul A arunc pachetul i rspunde cu un mesaj de tip ICMP cu timp depit.
n cazul n care al doilea pachet cu valoarea TTL-ului 2 este transmis ctre routerul
B(unde este aruncat) i al treilea pachet cu valoarea 3 este trimis ctre routerul
C(unde este aruncat la routerul E), atunci ar aprea c ar exista o legtur ntre
routerul B i routerul E. n plus, legtura dintre punctul C si E rmne neobservat.
Primul defect este apariia unei legturi false ntre C i D, n timp ce apare cel de-
al doilea defect i anume nerespectarea legturii existente ntre C i E.

2.4.4 Instrumente cu utilizri multiple

n seciunea referitoare la msurtori ale latenei am descris utilitarul ping,


care poate fi folosit pentru a msura RTT i rata pierderilor. De asemenea, s-a
prezentat i modul tracerout n subcapitolul msurtori ale detectrii rutei, ce
poate fi utilizat pentru a determina ruta , msura RTT-ul sau estima pierderea de
pachete. n afar de utilitarele ping i traceroute, mai exist o serie de instrumente
care au utilizri multiple.
Scriptroute[6] reprezint o infrastructur de reea public de msurare.
Aceasta permite utilizatorilor s-i ruleze propriile scripturi de msurare de reea
prin intermediul unei interfee web, dar i msurare a latenei, detectarea
pachetelor pierdute sau estimarea rutei. Facilitatea de scriptroute menine o list
de servere active care ruleaz daemonul de scriptroute. Fiecare server activ
ruleaz un server de web prin care accept script-urile utilizatorului prin
intermediul formatului CGI. Script-urile de msurare sunt scrise n Ruby (un
limbaj prietenos de scripting). Serverul Web invoc interpretorul Ruby care
analizeaz scriptul i interacioneaz cu deamonul pentru a facilita msurtorile
ntr-un mediu controlat. Deamonul scriptroute-ului trimite pachete de msurare
prin intermediul unei interfee brute de priz. De exemplu, dac un utilizator
dorete s execute o urmrire de rut ctre gazda destinaie, atunci mesajele de tip
UDP-TTL vor fi generate. n cele din urm, rspunsul de la destinaie corespunde
NECLASIFICAT

din
NECLASIFICAT

cu solicitarea expeditorului i rezultatul este afiat pe interfaa web. Avantajul


major ale scriptroute-ului este c acesta i propune s ofere o disponibilitate
general utilizatorilor normali. Un alt avantaj este faptul c msurtorile sunt
rulate ntr-un mediul controlat pentru a preveni ameninrile de securitate, cum ar
fi atacurile DOS.
Pathping[7] este un utilitar de reea multi-scop. Este folosit pentru a detecta
traseul ctre destinaie i a calcula RTT-ul i rata pierderilor, adic latena pentru
toate nodurile intermediare de la surs ctre destinaie. Este ncorporat pe sistemul
de operare Windows. Pathping este o combinaie dintre traceroute (tracert) i ping.
Acesta trimite mai nti mesajele de tip traceroute ctre gazda destinaie i
determin toate routerele intermediare. Apoi trimite mesaje de tip ping (prin
mesaje de tip ICMP) ctre routerele intermediare i calculeaz latena mpreun
cu rata pierderilor. Avantajul acestui utilitar este c poate detecta pierderea de
pachete pentru routerele intermediare, prin urmare acestea devenind folosite
pentru analiza reelei. Deoarece analiza este realizat pe o perioad mai lung de
timp, rezultatele sunt extinse i comparate cu cele normale de tip ping. Din acest
motiv analiza utilitarului pathping poate dura mult mai mult timp.

NECLASIFICAT

din
NECLASIFICAT

Capitolul III . Protocoale folosite pentru monitorizare

Managementul reelei a luat natere nc de la prima reea care a fost


conectat. De fiecare dat cnd dou sau mai multe pc-uri sunt conectate ntre ele,
n cele din urm apare nevoia de gestionare, monitorizare i analiz a acestora. n
acest scop, o suit de protocoale de management au fost dezvoltate de-a lungul
timpului, care ajut la nelegerea comunicrii ntre dispozitivele din reea. Aceste
protocoale sunt necesare datorit naturii comunicrii n reea. Pur i simplu nu se
pot observa biii care traverseaz firele din centrul de date (data center). Astfel,
singurul mod de a nelege cum se comport reeaua este prin a te baza pe datele
raportate care sunt colectate prin intermediul acestor protocoale speciale.
Cele mai nlnite protocoale sunt Transmission Control Protocol (TCP) i
User Datagram Protocol (UDP) n reeaua local (LAN), dar cele mai multe reele
au de asemenea cerine pentru protocoale mai rar folosite (de exemplu, AppleTalk
i IPX), precum i altele care sunt folosite pentru rutarea extern(de exemplu,
BGP i EIGRP). Ce este interesant despre protocoalele de gestionare a reelei este
c acestea funcioneaz diferit fa de acele protocoale a cror sarcin este de a
transmite date ntre pc-uri. Ca atare, protocolul pe care l utilizezi pentru aplicaia
de acces i transfer de date funcioneaz n paralel cu cele pe care le foloseti
pentru a gestiona reeaua.

3.1 Protocoalele fundamentale ale managementului de reea

Pornind de la elementele de baz , cele dou protocoale fundamentale ale


managementului de reea sunt Internet Control Message Protocol (ICMP) i
Simple Network Management Protocol (SNMP). Dei au fost n aplicabilitate nc
de la nceputurile primelei reele, aceste dou protocoale nc au rmas
instrumente de baz pentru depanarea i gestionarea reelei.

3.1.1 Internet Control Message Protocol

ICMP este considerat unul dintre protocoalele de baz ale suitei Internet
Protocol (IP). Spre deosebire de protocoalele de transfer de date, cum ar fi TCP i
UDP, ICMP nu este n mod obinuit folosit de aplicaii ca o metod de
comunicare.nrdcinat n pachetul IP, ICMP opereaz n afara regulilor
tradiionale ale protocoalelor TCP i UDP. Simpla modificare a regulilor de
conectivitate de tip TCP sau a celor de acces nu are efect asupra protocolului
ICMP. Protocolul prezint un set extrem de limitat de comenzi, care sunt
restricionate pentru sarcinile de explorare a gazdei , conexiune a reelei i rutarea.
Ca atare, traficul ICMP este de obicei disponibil n toate conexiunile, dar acesta
este pe departe cel mai securizat.
Cea mai frecvent comand folosit n cadrul protocolului ICMP este
invocat prin apelarea n linie de comand a cuvntului ping. Executarea
NECLASIFICAT

din
NECLASIFICAT

comenzii asupra unei adrese IP va returna o mic, dar foarte important cantitate
de informaie napoi la utilizatorul ce a iniiat aceast aciune. n figura de mai jos
se poate observa o executare cu succes a comenzii ce ii spune utilizatorului c
gazda este activ , operaional i c rspunde la cererile de baz ale reelei.

Fig. 3.1.1.1 Executarea comenzii ping n linie de comand

Fig. 3.1.1.2 Comanda ping de tip ICMP (Monitorizare activ)

ns acestea nu sunt toate informaiile care sunt obinute din rspunsul


comenzii ping. n rspunsul cererii ping exist i informaii suplimentare despre
starea conexiunii dintre surs i destinaie .Rspunsul scurt al cererii ofer detalii
cu privire la numrul de milisecunde necesare pentru a completa cererea tur-retur.
Conexiunile latente ale reelei pot aprea din cauza unor factori cum ar fi
aglomerarea benzii, rata ridicat a erorilor dintre legturile surs-destinaie i
problemele de procesare ale dispozitivelor conectate de-a lungul rutei.
Viteza de transfer efectiv dintre surs i destinaie depinde n mare msur
de o serie de factori. Ca un exemplu, de fiecare dat cnd un pachet de date
strbate un router , switch sau un firewall, o cantitate mic de ntrziere este
introdus n RTT. Astfel, pe msur ce numrul nodurilor crete, performana
efectiv a conexiunii scade uor. Viteza de transfer poate fi, de asemenea, afectat
NECLASIFICAT

din
NECLASIFICAT

de dimensiunea datelor transferate de la surs la destinaie. Datele de dimensiuni


mari sunt deobicei fragmentate pentru a crete performana n transmiterea lor de
la surs la destinaie. Ping implicit va trimite un ir repetitiv de caractere de 32 de
bytes ca date utile (payload) pe timpul cererii. Att mrimea payload-ului, ct i
o setare ce determin dac acesta poate fi fragmentat, sunt opiuni comune cu
fiecare comand de tip ping a oricrui sistem de operare. Unele comenzi de tip
ping permit personalizarea payload-ului ca o opiune avansat. Acest lucru este
adesea folosit pentru a verifica dac componena datelor n sine prezint un impact
asupra performanei conexiunii. Fiecare dintre aceste capabiliti sunt disponibile
pentru a verifica ct de bine merge o conexiune n funcie de dimensiunea i
coninutul cererii ping (a payload-ului acestuia). n ultimele patru linii ale
rspunsului reuit de tip ping se afl informaii legate de pierderea de pachete.
Pachetele care nu ajung cu succes la destinaie sunt considerate pierdute (lost) de
ctre utilitarul ping. Numrul de pachete pierdute (precum i procentul rezultat
din pierderea traficului n funcie de traficul total) reprezint un nivel de date
transferate, care trebuie prezentate de TCP pentru a se asigura cu succes transferul
de date utile (payload). Aceast desemnare indic adesea c o problem are loc n
acea conexiune de reea, cum ar fi degradarea semnalului, link-uri suprasaturate,
pachete care au fost corupte sau respinse n timpul transmisiei, sau alte
probleme interne cu privire la rutare. Dei specificaiile problemelor sunt lsate
n baza altor protocoale mai detaliate, aceast comand simpl ofer o modalitate
uoar de a evalua disponibilitatea conexiunii la cel mai nalt nivel. Chiar dac
pierderea de pachete pentru comunicaii, cum ar fi transferurile de fiiere tind doar
s reduc performana general a legturii, prezena acesteia poate fi foarte
problematic pentru anumite tipuri de trafic. De exemplu, VoIP, videoconferina,
accesul la distan, streamingul i alte tipuri de trafic sunt n mod special afectate
de pierderi de pachete.

3.1.2 Simple Network Management Protocol (SNMP)

La nceput, n 1988, nu a fost nevoie de un instrument de administrare


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

- cu diversitate mare de administrare / management.


- ct mai mare posibil.
- cu diversitate mare de punere n aplicare.

O parte important a conceptului a fost deja cunoscut de dezvoltri


anterioare, n special n jurul routerelor SGMP (Simple Gateway Protocol). RFC-
NECLASIFICAT

din
NECLASIFICAT

urile urmtoarele sunt primele documente care se ocup cu SNMP publicat n


1988:
- RFC 1065 - Structura de identificare i de management al informaiei pentru TCP
/ IP bazate pe Internet
- RFC 1066 - Baza de Management Informaional pentru Network Management de
TCP / IP bazate pe Internet
- RFC 1067 - A Simple Network Management Protocol
Protocolul SNMP impune existena a dou entiti: a elementelor de
administrare (ageni) i a staiilor de administrare. ntre aceste elemente protocolul
trebuie s asigure comunicarea conform figurii 3.1.2.1.
Elementele administrate sunt acele elemente din cadrul reelei care permit
rularea softului agent de administrare. Agenii permit comunicarea ntre staiile
de administrare i cele administrate prin SNMP i execut funciile cerute de staia
de administrare.
Staiile de administrare sunt echipamente care permit executarea
aplicaiilor de management pentru a controla i superviza elementele administrate
din reea. n mod obinuit, staia de administrare are i o interfa grafic pentru a
putea raporta operatorului date din reea.

Staie de administrare

Aplicaie de
management

Reea SNMP

Agent Agent
Element administrat Element administrat Proxy
Baz de date management Baz de date management

Fig. 3.1.2.1 Arhitectura SNMP [8]

Standardul nu specific numrul de staii de management sau raportul dintre


staiile de management i ageni. n general, este mai bine s avem cel puin dou
sisteme de management, pentru siguran n caz de erori. O alt problem este una
practic, i anume ct de muli ageni pot fi administrai de o singur staie de
management.
NECLASIFICAT

din
NECLASIFICAT

SNMP a fost proiectat ca un protocol de nivel aplicaie care s fie parte a


suitei de protocoale TCP/IP. Acesta opereaz peste UDP (User Datagram
Protocol). ntr-o staie de management independent, un proces de management
controleaz accesul la MIB-ul central al staiei de management i pune la
dispoziie o interfa cu administratorul de reea. Procesul de management
realizeaz managementul de reea utilizand SNMP, care este implementat peste
UDP, IP i alte protocoale importante de reea (cum ar fi Ethernet, X.25).
Agenii sunt instalai pe elementele de reea i ndeplinesc cerinele primite
de la staiile de administrare. Pentru a ndeplini cerinele trebuie s aib acces la
MIB (Management Information Base). Agenii pot fi vzui ca subsisteme din
componena elementelor de reea, n general au caracter pasiv i acioneaz doar
dac primesc comand de la aplicaia de reea. Singurul caz care determin
agentul s acioneze far comand de la aplicaia de reea este cazul n care apare
o serie de erori clar definite. Apariia unor astfel de erori se numete
capcan(trap), iar numrul lor este limitat pentru a preveni alarmele false.

Fig. 3.1.2.2 Configuraia reelei SNMP

Staia de administrare SNMP este format din aplicaii i baze de date cu


scopul de a monitoriza i controla un grup de ageni. Asupra unui agent,
NECLASIFICAT

din
NECLASIFICAT

administratorul poate trimite cereri de furnizare de informaii folositoare pentru


management sau cereri de schimbare a modului de funcionare a unui element
din reea.
n comparaie cu agenii, staiile de administrare au o complexitate mare. O
staie de administrare poate prelua date de la mai muli ageni pe care i i
controleaz pe baza datelor primite.
Deoarece SNMP este implementat peste UDP i acesta nu este un protocol
orientat pe conexiune, protocolul SNMP nu este nici el orientat pe conexiune.
Nicio conexiune nu este meninut ntre staia de management i agenii ei. Dac
staia de management este responsabil de un numr mare de ageni i dac fiecare
agent menine un numr mare de obiecte, atunci aceasta devine nefolosibil dac
se fac citiri regulate ale obiectelor tuturor agenilor. De aceea SNMP i MIB-urile
asociate sunt gndite s ncurajeze administratorul s foloseasc mesajele de tip
trap.

3.1.2.1 Structura unui MIB

Un MIB este o structur de baz de date reprezentat printr-un arbore n


care nodurile sunt obiectele administrate, fiecare din ele reprezentnd cte o
resurs, activitate sau alt informaie care trebuie administrat. Fiecare tip de
obiect definit n MIB are asociat un identificator de tip OBJECT IDENTIFIER
din ASN.1.
Un identificator de obiect este un identificator unic pentru un tip particular
de obiect. Mulimea identificatorilor de obiecte definite are o structur
arborescent, unde rdacina arborelui este un identificator de obiect definit n
standardul ASN.1. ncepnd cu rdcina arborelui de identificatori de obiecte
fiecare valoare a unei componente a identificatorului de obiect reprezint un arc
n arbore.
ncepnd cu root-ul, sunt trei noduri la primul nivel: iso, ccitt i join-iso-
ccitt. Sub nodul iso este un subarbore folosit de alte organizaii, unul pentru U.S
Departament of Defense (dod). RFC 1155 [RFC1155] face presupunerea c un
subarbore de sub dod va fi alocat pentru administrare de Internet Activity Board
dup cum urmeaz n figura 3.1.2.1.1.
MIB este prezent n dou versiuni, MIB-I i MIB-II.
MIB-I este descris n RFC 1212 cu completrile din RFC 1155. n
compunerea sa intr doar obiectele strict necesare pentru administrarea reelelor
de Internet care au la baz protocolul TCP/IP.
MIB-II este varianta evoluat a MIB-I coninnd mai multe obiecte i
funcionaliti. Motivul pentru care MIB-II a fost construit pe structura MIB-I este
pstrarea compatibilitii. Fa de MIB-I, MIB-II adaug nc dou grupuri:
grupul de transmisie, acesta include obiectele MIB care descriu caracteristici ale
mediilor de comunicaie i grupul SNMP care conine informaii despre felul n
care SNMP lucreaz n reea.
NECLASIFICAT

din
NECLASIFICAT

Fig. 3.1.2.1.1 Grupul de obiecte MIB-II

3.1.2.2 SNMPv1

NECLASIFICAT

din
NECLASIFICAT

SNMPv1 este prima variant a protocolului, aprut n urma nevoii de


management asupra dispozitivelor bazate pe IP. Definirea protocolului prin care
se execut comunicarea ntre agent i administratori este cuprins n RFC 1157,
regulile de descriere a variabilelor n RFC 1155, RFC 1212 i RFC 1215 iar
structura informaiilor de administrare i un model al obiectului de informaie n
RFC 1155.
A fost gndit ca un protocol simplu i robust pentru managementul reelelor
IP, mai ales pentru partea de configurare i defecte. De remarcat n descrierea
modului n care se face comunicarea ntre administratori i ageni este preambulul
mesajului. Acesta conine cmpuri cu informaii care permit controlul accesului
i autentificarea entitii cu care comunic.
Preambulul SNMPv1 este compus din: numr, versiune i community
string, aa cum este descris n figura 3.1.2.2.1.
Numrul de versiune conine un ir de bii care definesc versiunea de SNMP
folosit. n cazul incompatibilitii de versiune, mesajul este aruncat.
Community string definete relaia dintre administrator i agent. Iniial, la
definirea agentului SNMP pe un echipament de reea, se specific acest cmp,
community string. Toi agenii dintr-un grup vor avea acelai community string i
li se va permite accesul administratorilor care trimit n preambul un community
string identic cu cel memorat de ageni. Sunt definite dou moduri de acces:
modul read-only, permite comenzile get, get-next i trap i modul read-write care
permite n plus i comanda set.
n cazul n care community string-ul recepionat de agent este diferit de cel
tiut, agentul arunc mesajul i poate genera un mesaj trap tip Authentification
Failure adresat administratorului de reea.

UDP PDU Request Error Error


Version Community name value ...
Header Type ID Status Index
Fig. 3.1.2.2.1 Mesajul SNMPv1

Numele definite de community string sunt memorate ntr-un fiier sub


form de caractere ASCII. n acest fiier se regsesc patru cmpuri:
- Community. Acest cmp conine un ir de caractere care alctuiesc numele
comunitii.
- Managers. Este compus dintr-o list de adrese IP ale echipamentelor cu drept de
utilizare al profilului de acces.
- Acces. Tipul de acces permis pentru fiecare membru al comunitii, read-only sau
read-write.
- Traps. Conine lista de manageri la care agentul poate trimite mesaj trap.

3.1.2.3 SNMPv2

NECLASIFICAT

din
NECLASIFICAT

A doua variant a SNMP este descris ntr-o serie de protocoale n funcie


de problematica vizat. Cele mai importante RFC-uri sunt: RFC 1901 Introducere
n SNMPv2, prezint Internet Standard Network Management Framework, RFC
1908 Coexistenta versiunii unu si versiunii doi, RFC 3417 Poceduri de nivel
transport folosite n transmiterea mesajelor SNMPv2.
Cel mai mare plus adus fa de varianta 1 este posibilitatea criptrii
mesajelor i administrarea securitii.
Securitatea protocolului const n conceptul de Party(participant). Acest
concept const n existena unui mediu participant n care prin folosirea unui
protocol de transport, de preferat UDP, administratorii i agenii, prin
autentificare, pot transmite mesaje criptate. n cadrul unei comunicaii fiecare
entitate este vazut ca un participant.
Conceptul de participant cuprinde identitatea de participant, protocolul de
autentificare, protocol de criptare i o locaie logic a participantului adic portul
de pe care sunt transmise datele. n practic o entitate poate s comunice cu mai
muli participani fr a aprea erori n interpretarea identitii partenerului de
comunicare. De exemplu: agentul 1 poate comunica cu managerul 2 i managerul
3, folosind mediile de participare 4 i 5.
Un Party este compus din identitate i parametri de transport.
Parametrii de transport ai unui party sunt: partyTDomain, conine tipul de
serviciu de transport, partyTAddress, conine adresa IP i portul de nivel transport
i partyMaxMessageSize care conine numrul maxim de octei ai unui mesaj.
Entitile n SNMPv2 reprezint procese care genereaz mesaje. n timpul
comunicrii cu alte entiti, entitatea care trimite mesajul devine participant.
Pentru a putea comunica, fiecare entitate are memorat o baz de date numit
Party Database. Aceast baz de date care conine o list cu toi participanii
valizi.
Entitatea dispune i de o baz de date numit Content Database n care sunt
memorate obiectele administrate accesibile local sau la distan. ntre entitate i
obiectele administrate este o relaie de proximitate.
Relaia de proximitate trebuie stabilit n momentul n care un agent vrea
s comunice cu o entitate pentru tratarea unei cereri de administrare. Relaiile pot
fi de tip proxy nativ sau proxy strin.
Proxy nativ se folosete n cazul n care ambele entiti folosesc aceleai
protocoale de administrare, iar proxy strin n caz contrar. Pentru a rula proxy
strin este nevoie s folosim un element de reea care s se ocupe de executarea
sarcinilor de procesare pentru administrare astfel nct datele recepionate s poat
fi interpretate corect.

mpachetarea datelor se face diferit fa de SNMPv1, cu preambuluri


diferite care conin indicatori legai de criptare, autentificare, identitatea
participanilor i contextul.
Conform figurii 3.1.2.3.1 observm cmpurile urmtoare:
NECLASIFICAT

din
NECLASIFICAT

- privDst, conine componenta privat a elementului destinaie


- authInfo, conine informaii de autentificare i criptare
- dstParty, destinaia participant
- srcParty, sursa participant
- context, contextul SMNPv2
- PDU, comanda ce trebuie efectuat

privDst authInfo dstParty scrParty Context PDU

General

privDst digest dscTime srcTime dstParty scrParty Context PDU

Autentificat, criptat

Fig. 3.1.2.3.1 mpachetarea datelor n cazul SNMPv2

La fel ca la prima variant a protocolului, comunicaia ntre dou entiti


este de tip cerere-rspuns.
Pentru a expedia o cerere sau o notificare trap, participantul surs adaug
la operaia de executat contextul, datele despre participantul surs i datele despre
participantul destinaie. Datele despre participantul destinaie se obin din Party
Database. Mesajul poate conine i date de autentificare i poate fi criptat.
Mesajul este transmis i dirijat n reea folosind adresa participantului
destinaie i protocolul de transport folosit n reea.
Odat recepionat mesajul, se execut autentificarea. Dac mesajul nu se
poate autentifica este aruncat. Dup autentificare se verific adresa participantului
surs i tipul operaiei prin cutarea acestora n bazele de date locale, Party
Database i Content Database. n cazul n care cutarea n bazele de date eueaz,
destinatarul poate trimite un mesaj trap prin care informeaz managerul de eroarea
aprut. Se poate ntmpla i cazul n care operaia de executat este n baza de
date, dar nu este permis, ceea ce va duce la generarea unui mesaj de informare
pentru participantul surs. Dup toate verificrile, participantul destinaie execut
operaia conform relaiei de proximitate, nativ sau strin.
Odat executat operaia, participantul care a fost destinaie va emite un
mesaj rspuns ctre participantul care a fost surs. Procedeul de pregtire a
mesajului este analog cu descrierea anterioar.

3.1.2.4 SNMPv3

NECLASIFICAT

din
NECLASIFICAT

SNMPv3 este cea mai nou versiune a protocolului. Funcionarea i


implementarea acestei versiuni sunt descrise n urmtoarele RFC-uri: RFC 2570
Introducere n SNMPv3, RFC 3411 Arhitectura SNMP, RFC 3412 Expedierea i
procesarea mesajelor, RFC 3413 Aplicaii SNMP, RFC 3414 Modelul utilizator,
securitate, RFC 3415 Modelul de control al accesului i vizualizrii, RFC 3416
Operaiile protocolului pentru SNMPv2, RFC 3417 Proceduri de transport pentru
SNMPv2, RFC 2576 Coexistena versiunilor SNMP.
Noul protocol a introdus noi politici de securitate, convenii textuale i noi
tehnologii.
Politicile de securitate au urmrit asigurarea unor funcii i servicii care s
garanteze o comunicaie sigur. Principalele planuri n care s-au implementat
politici de securitate sunt urmtoarele:
- Identificarea entitilor SNMP. Fiecare entitate are atribuit un nume unic n reea,
numit EngineID. Entitatea 1 poate comunica cu entitatea 2 doar dac cele dou
entiti i cunosc identificatorii
- Asigurarea a 3 tipuri de comunicaie: fr autentificare i fr intimitate
(NoAuthNoPriv), cu autentificare fr intimitate (AuthNoPriv), cu autentificare
i cu intimitate(AuthPriv)
- Protecie mpotriva modificrii informaiei transmise
- Protecie mpotriva modificrii intenionat sau neintenionat a ordinii mesajelor
- Protecie mpotriva aciunilor de mascarad, aciuni prin care un sistem ar putea
s se autentifice i s transmit sau s recepioneze mesaje SNMP
- Protecie mpotriva interceptrii mesajelor
- Creearea de proceduri prin care entitile s ii descopere vecinii

Principala convenie textual este nlocuirea termenilor de agent i


administrator(manager) cu noiunea general de entitate. Fiecare entitate este
alctuit din motor i aplicaie, n funcie de rolul pe care l ndeplinete n reea.
Aa cum este descris n figura 3.1.2.4.1, motorul SNMP are n compunere:
Dispecer (Dispatcher), Subsistemul de procesare al mesajelor (Message
Processing Subsystem), Subsistemul de control al accesului (Acces Control
Subsystem), Sistemul de securitate (Security Sistem).

Motor SNMP
Subsistemul de Subsistemul
Subsistemul
Dispecer procesare al de control al
de securitate
mesajelor accesului

Fig. 3.1.2.4.1 Motorul SNMP

NECLASIFICAT

din
NECLASIFICAT

Dispecerul se ocup de trimiterea i de recepionarea mesajelor. Mesajele


recepionate sunt citite, se determin versiunea SNMP i dac versiunea este
compatibil direcioneaz mesajele spre subsistemul de procesare.
Subsistemul de procesare al mesajelor are rolul de a pregti mesajele pentru
trimitere i de a extrage informaia din mesajele recepionate. Acest subsistem
poate s fie compatibil cu diferite versiuni ale SNMP.
Subsistemul de control al accesului are rolul de a manageria accesul la
obiectele stocate n MIB.
Subsistemul de securitate asigur criptarea i autentificarea. Criptarea se
face pe baza algoritmului DES (Data Encryption Standard). Autentificarea se face
pentru fiecare entitate prin folosirea algoritmului MD5 (Message-Digest 5) sau al
algoritmului SHA (Secure Hash Algoritm).
Conform figurii 3.1.2.4.2, aplicaia are n compunere: Generator de
comenzi (Command generator), Generatorul de rspunsuri la comenzi (Command
responder), Generator de notificri (Notigication originator), Receptorul de
notificri (Notification receiver), Expeditor proxy (Proxy forwarder) i alte
blocuri funcionale.

Aplicaie SNMP

Generator de Generator de Expeditor


comenzi notificri proxy

Generator de Receptor de
Alte blocuri
rspunsuri notificri

Fig. 3.1.2.4.2 Aplicaie SNMP

Generatorul de comenzi este implementat de un sistem de management i


genereaz comenzile get, getnext, getbulk, set.
Generatorul de rspunsuri la comenzi este implementat pe o entitate
administrat cu rol de a rspunde comenzilor trimise de generator.
Generatorul de notificri este implementat pe un echipament administrat i
este responsabil de trimiterea mesajelor tip trap.
Receptorul de notificri este implementat la nivelul sistemului de
management de reea i se ocup de recepionarea mesajelor tip trap.
Expeditorul proxy se ocup de trimiterea mesajelor ntre entiti.

3.1.3 Protocoale de management n cadrul sistemului de operare Windows

NECLASIFICAT

din
NECLASIFICAT

Succesul monitorizrii i gestionrii sistemelor bazate pe Windows necesit


mai mult dect protocoalele standard cum ar fi ICMP i SNMP. De aceea, sunt
protocoale specifice pentru Windows de care este mare nevoie. Aceste protocoale
exist n nivelul Aplicaie al stivei IP i din proiectare, acestea se bazeaz pe altele
din nivele de mai jos ale stivei pentru partea de rutare i comutare (routing and
switching). Aceste protocoale adugate sunt utilizate pentru aplicaii cum ar fi
DNS, Web , FTP i transferal de e-mail, printre multe altele.
Sistemul de operare Windows se folosete de propria suit de protocoale
pentru comunicaiile dintre serverele i staiile de lucru n cadrul
sistemului.Aceste protocoale au la baz tot TCP i UDP pentru a permite
comunicaia de-a lungul unei reele IP. Dou exemple de protocoale de nivel nalt
sunt Remote Procedure Call (RPC), protocolul utilizat pentru comunicaii ntre
procese Windows i protocolul Remote Desktop (RDP), care este utilizat pentru
trasferul de informaii de tip afiare i control dintre un server i un client.
Alte protocoale care sunt folosite de sistemul de operare Windows:

- Windows Management Instrumentation (WMI)


- WS-Management (prin Windows Remote Management v1.1 , v2.0)

Evidenierea acestor protocoale de tip Operating System specifice este


necesar datorit informaiilor pe care le pot partaja administratorului de reea.
Protocoalele de genul ICMP i SNMP discutate mai sus sunt capabile din
proiectare s prezinte doar anumite tipuri de metrici administratorului de reea.
Cu toate acestea , compania Microsoft a fcut un efort substanial pentru a
permite contientizri WMI pentru aplicaii i sisteme de operare. Astfel, suportul
profund de monitorizare care nu ar fi putut fi altfel supravegheat prin ICMP sau
SNMP este disponibil pentru mai multe aplicaii folosind WMI. Orice soluie de
management de reea (Network Management Solution-NMS), care dorete s fie
parte a sistemului de operare Windows i a aplicaiilor sale, trebuie s ofere n
plus suport pentru aceste protocoale.

3.1.3.1 Remote Procedure Call

Fundamentul comunicrii n reeaua sistemului de operare Windows se


bazeaz pe protocolul RPC. Ca atare, RPC este o parte important i necesar
tuturor mediilor Windows. Implementarea Microsoft a protocolului RPC
folosete un serviciu de mapare, cruia i este dat n atribuii s identifice i s
catalogheze care sunt porturile ce trebuie s fie utilizate i de ctre ce servicii n
cadrul serverului. Aceast determinare este fcut atunci cnd staia pornete,
precum i atunci cnd serviciile sunt pornite n timpul operaiunilor normale.
Dei natura dinamic RPC permite un numr mare de servicii pe fiecare
sistem pentru a comunica ntr-o reea local, aceeai abordare dinamic nseamn

NECLASIFICAT

din
NECLASIFICAT

c orice numr de porturi TCP pot fi deschise i ascultate pe o instan Windows,


n orice moment .
O conexiune RPC pe Windows Server 2008 poate avea loc ntre o serie de
porturi (ntre 49152/TCP i 65535/TCP) att la surs, ct i la destinaie. Ca
urmare, un eficient NMS trebuie s fie n msur s monitorizeze disponibilitatea
de comunicare bazat pe RPC, precum i care sunt serviciile de ascultare i pe
care dintre porturi. Aceste informaii ofer o bun perspectiv a tipurilor de
comunicare care au loc n reea i ajut la izolarea problemelor legate de
comunicrile ntre procese. Mai mult, cu ct mai multe forme de tip malware
folosesc aceeai infrastructur dinamic ce este utilizat de ctre serviciile legale
pentru Windows, cu att acest nivel de monitorizare permite administratorilor s
elimine intruziunile n timp real, pe msur ce apar.

3.1.3.2 Windows Management Instrumentation

Traficul RPC n sine ofer doar o reprezentare la nivel nalt a fluxului per
total de comunicare. n sistemul de operare Windows, Microsoft a dezvoltat
protocolul WMI ca o alternativ a SNMP-ului. Acest protocol de monitorizare i
de management de la distan reprezint implementarea Microsoft a standardelor
Web-Based Enterprise Management (WBEM) i Common Information Model
(CIM).
WMI funcioneaz la fel ca SNMP, dar pe lng SNMP acesta poate fi
folosit pentru colectarea datelor n funcie de mai multe metrici i actualizarea
anumitor configuraii. Cu toate acestea, WMI este mult diferit de SNMP ,
deoarece WMI se limiteaz la sistemul de operare Windows i la aplicaiile
instalate. O alt diferen ntre cele dou protocoale este aceea a modurilor n care
poate fi conectat baza de date. Activitatea de cerere/rspuns SNMP este definit
direct n SNMP, pe cnd cererile WMI pot fi nfurate ntr-una din mai multe
limbi. Ca exemple pentru scripturi administrative, implementrile Microsof , att
VBScript ct i Windows PowerShell includ suport pentru crearea de interogri
WMI.
Sintaxa de interogare folosit pentru apelurile WMI este, de asemenea,
extensibil. ntruct SNMP include doar dou comenzi pentru solicitarea de
informaii (GET i GET-NEXT), WMI ofer i modul WMI Query Language
(WQL) pentru interogri. Furnizorii specifici WMI pot spori propriul lor suport
de interogare n cazul n care o tehnic de enumerare este ncorporat furnizorului.
De exemplu, interogarea general WQL pentru enumerarea informaiei de la
furnizorul de Win32_DiskDrive ar semna cu *Selectai din Win32_DiskDrive.
Rezultatul interogrii ar avea ca deznodmnt o colecie de articole de la
acel furnizor. WQL include constrngeri suplimentare pentru limitarea
informaiilor care rezult, cu toate c o practic comun este de a construi
constrngeri n limbajul de scripting disponibil acolo unde este posibil. Acest

NECLASIFICAT

din
NECLASIFICAT

lucru permite cel mai mare nivel de flexibilitate n timp ce eludeaz limitri n
opiunile de constrngere native pentru WQL.

3.1.3.3 WS-Management

Transportul nativ WMI pentru Windows nainte de Windows Server 2008 a


fost Distributed Common Object Model (DCOM).Bazndu-se pe RPC pentru
bazele sale de conectivitate, DCOM a funcionat bine n cadrul reelelor locale.Cu
toate acestea, natura dinamic a RPC le face pe amndou problematice n privina
operrii prin intermediul firewall-urilor sau arhitecturilor de reea care nu sunt
relativ deschise. Aceast limitare a nsemnat c realizarea gestionrii de la distan
a sistemelor n afara LAN-ului tradiional a fost dificil sau imposibil prin
combinarea WMI- DCOM.
Pentru a rezolva aceast problem, Microsoft a adoptat mai trziu cadrul
standard WS-Management n Windows Server 2008. Implementarea realizat de
Microsoft a WS-Managementului este reprezentat de ctre propriul su serviciu
i anume Windows Remote Management (WinRM). Aceast specificaie se
bazeaz pe standardele deschise DMTF i standardele de Internet pentru serviciile
web.
n cadrul unei implementri de servicii de web, WS-Management (i , astfel
,WinRM) poate trece mult mai uor de datele WMI prin reele cu firewall dect
protocolul RPC. Un serviciu web reprezint un obiectiv bazat pe web prin care un
client poate interfaa cu o cerere i poate prezenta informaii. Pentru un serviciu
web, acest punct final poate opera ntr-un singur port cunoscut (de obicei 80-TCP
sau 443-TCP) mai bine dect o serie de porturi dinamice.
Este important s se recunoasc faptul c implementarea realizat de
Microsoft n legtur cu nivelele lui WS-Management n stiva WMI/DCOM ,
permit expunerea stivei prin intermediul unui serviciu structurat de web. Cnd
este activat ( deoarece nu este activat n mod implicit), aceast arhitectur
pstreaz compatibilitatea anterioar WMI/DCOM cu scripturile tradiionale
WMI i cu infrastructurile aplicaiilor n timp ce adaug abilitatea pentru SOAP
(anun clienii s interacioneze cu serverul printr-un transport prietenos de tip
web).Pentru organizaiile IT nseamn acum c sistemele tradiionale ce erau greu
de gestionat , cum ar fi cele din DMZ sau extranet pot fi gestionate acum prin
intermediul WSManagement. ntr-adevr, aceleai tipuri de informaii care pot fi
colectate prin soluii bazate pe WMI pot fi acum obinute n aceste sisteme care
nu aparin LAN-ului.

3.1.3.4 Remote Desktop Protocol

Ultimul protocol de management al Windows-ului este protocolul RDP,


care a crescut n mod dramatic n utilizare de cnd a nceput s lucreze cu
Windows NT 4.0 Server , Terminal Server Edition. Iniial proiectat pentru o
NECLASIFICAT

din
NECLASIFICAT

utilizare specializat n conectarea utilizatorilor de la distan la aplicaii pe un set


centralizat de servere, utilizarea RDP a crescut n scopul de a introduce conexiuni
administrative la servere.
Spre deosebire de mai multe protocoale bazate pe tranzacii observate n
SNMP, WMI i altele, RDP poate fi considerat mai mult ca un protocol de
streaming, cu toate c aceast descriere nu este n totalitate corect. RDP trimite
actualizri de ecran de la server la client atunci cnd sesiunile serverelui se
schimb. Acesta trimite comenzi de la tastatur i mouse de la client la server
atunci cnd tastele sunt apsate, sau cnd ntreruperile mouse-ului sunt procesate.
Interceptrile de date dintr-o conexiune RDP va avea ca rezultat un amestec de
actualizri de ecran intercalate cu comenzi de tastatur sau mouse, ce va realiza o
reconstrucie non-trivial fr unelte specializate.
n mod implicit, RDP opereaz peste portul int 3389/TCP. Astfel, acest
singur port TCP trebuie sa fie rutabil prin firewall-uri sau prin ACL-urile reelei
pentru conectarea gazdelor RDP. RDP poate fi reconfigurat ctre o rut prin
porturi alternative. Mediile de nalt securitate folosesc adesea instrumente pentru
a ncapsula traficul n SSL, care i schimb portul implicit n 443/TCP, adaug
securitate i autentificare i permite trecerea n siguran a traficului RDP pe
Internet.
Streamul RDP-ului permite trecerea actualizrilor peste conexiunile
sczute de lime de band. Astfel, conexiunile de mare utilizare pot rmne n
data center avnd numai datele rezultate ce trebuie s ajung la utilizator. Pentru
anumite aplicaii, acest lucru este un avantaj al suportului de la distan. Cu toate
acestea, aceeai interactivitate face ca protocolul s fie insensibil la laten. ntr-
adevr, dac ii miti mouse-ul ca i cnd ai dori s observi micarea cursorului
cu cea a minii tale, ar aprea ntrzieri de secunde.
Ca urmare, nevoile de monitorizare pentru RDP tind ctre statisticile
agregate peste mai multe detalii specifice sesiunii. Cu o cretere a folosirii
suportului de aplicaii cu control de la distan, gestionarea reelei fcut de RDP
probabil va include integrrile de monitorizare necesare (att la nivel de reea ct
i prin intermediul integrrilor de tip WMI) s identifice i s raporteze cu privire
la condiiile de experien ale utilizatorului.

3.1.4 Telnet

Telnet este considerat unul dintre cele mai vechi protocoale nc n uz i


astzi .Dezvoltat pentru prima dat n 1969, telnet reprezint de fapt un acronim
care a stat la baza conceptului de teletype network. n acea perioad, comanda
telnet a fost utilizat n conectarea sistemelor de tip mainframe, cu aceeai
utilizare, relativ neschimbat de-a lungul duratei sale de via. Utilizarea de astzi
a comenzii telnet este n rimul rnd ca un mecanism de accesare a interfeei n
linie de comand a unui sistem UNIX sau Linux. n domeniile reelisticii, telnet

NECLASIFICAT

din
NECLASIFICAT

este de asemenea utilizat n mod obinuit pentru conectarea n linie de comand


la o interfa a unui dispozitiv de reea.
De la lansarea Windows NT 4.0 SP3, sistemul de operare Windows
Microsoft a ncorporat un server telnet n serviciile sale pentru produsele ce
prezint add-onuri UNIX, care ulterior a fost redenumit Subsystem for UNIX-
based Applications n Windows Server 2003 R2. Cu toate c serverul telnet al
companiei Microsoft creeaz ntr-adevr un serviciu Windows (daemon) pentru
primirea cererilor de telnet, utilizarea sa pe platforma Windows este mai puin
frecventat n reelele de astzi.
Comanda telnet ncapsuleaz datele de utilizator n acelai canal ca i
informaiile sale proprii de control pe msur ce trece ctre dispozitivul sau gazda
destinaie. Astfel, telnet funcioneaz att ca un protocol de management ct i ca
un protocol de transfer de date. Telnet se afl la nivelul Aplicaie din stiva OSI i
folosete de obicei portul 23 /TCP ca port de reea.
Utilizarea n zilele de azi a telnetului a sczut din practica comun pentru
mai multe reele de afaceri din cauza incapacitii sale de a autentifica serverele
destinaie. Protocolului i lipsete capabilitatea de a cripta cu cheie, care asigur
datele sale n timpul distribuirii informaiilor. Combinaia acestor limitri face ca
utilizarea telnetului s nu mai fie o practic sigur. nlocuirea comenzii telnet s-a
fcut prin comanda ssh, care include capacitile necesare pentru o conexiune
securizat. Cu toate acestea, aceast limitare cu privire la utilizarea telnetului este
pe departe de a elimina utilitarul din lista de instrumente de management ale
administratorului. O carecteristic a protocolului care a rmas n comun i n ziua
de astzi este capacitatea de a crea conexiuni TCP ntre o surs i o destinaie.
Aceast conexiune brut este utilizat pentru a verifica conexiunea dintre dou
gazde la nivelul 3 i 4 (TCP i portul).

3.1.5 SSH

SSH sau comanda Secure Shell a nlocuit n cele mai multe medii de
nlocuit telnet ca cea mai bun practic pentru conectarea de la distan a
serverelor i a pc-urilor. Din punctul de vedere al utilizatorului, funcionalitatea
de baz a SSH-ului realizeaz n esen aceeai funcie ca telnet: s realizeze o
interfa la linia de comand pe un server de la distan identificat. Ceea ce difer
la SSH este modul n care acesta asigur conexiunea de la un capt la cellalt.
Iniial dezvoltat n 1995, SSH folosete criptografia cu cheie public pentru a
autentifica computerul de la distan. Dup autentificare, SSH creeaz o
conexiune care este apoi fixat pentru a asigura att integritatea, ct i
confidenialitatea datelor.Spre deosebire de telnet, a crui baz de cod s-a
stabilizat relativ prin lunga sa istorie, o serie de implementri SSH sunt
NECLASIFICAT

din
NECLASIFICAT

disponibile n ziua de astzi. Versiunile lui nenumrate au fost create n mai multe
moduri ca urmare a descoperirii vulnerabilitilor de securitate a versiunii
anterioare. Versiunea acceptat n prezent este intitulat SSH-2 i este un standard
de Internet propus s fie examinat de Internet Engineering Task Force (IETF).
Utilizarea efectiv a SSH difer de cea a Telnet-ului prin faptul c SSH
poate fi o platform pe care funcionalitile suplimentare pot fi gzduite. n plus
fa de crearea unei conexiuni securizate la o interfa de tip linie de comand,
protocolul SSH poate fi utilizat pentru :

- Comand ntr-o singur linie


- Transfer de fiiere , manifestat ca SCP , SFTP sau rsync
- Port forwarding sau tunneling
- Crearea de conexiuni VPN, activat prin distribuia OpenSSH
- Navigarea pe web prin intermediul protocolului SOCKS
- Remote directory mounting , manifestat ca SSHFS
Pe scurt, cu toate c cele mai multe dispozitive de reea pstreaz
capacitatea de a utiliza Telnet pentru managementul de la distan, tot SSH
rmne cea mai bun practic. Dei SSH nu este disponibil nativ n sistemul de
operare Microsoft Windows, clienii pentru SSH sunt disponibili ca aplicaii
instalate pentru a realiza managementul necesar.

3.1.6 Syslog

Grupat n acest volum datorit rdcinilor sale bazate pe UNIX, Syslog este
un protocol fundamental diferit n ceea ce privete utilitatea sa de management al
reelei. Syslog este un mecanism prin care informaiile de tip jurnal de evenimente
de la unul sau mai multe servere sau dispozitive pot fi agregate ntr-o singur baz
de date pentru o stocare i analiz ulterioar. La fel ca Telnet i SSH, Syslog are
o istorie lung, ncepnd cu dezvoltarea sa iniial din anii 1980 cu proiectul
Sendmail.
Datorit recentei creteri a tehnologiei utile pentru aceste tipuri de analize,
utilizarea de astzi a Syslog este adesea axat pe datele pentru auditori. La un
nivel ridicat, industria de astzi i legile de reglementare a informaiilor cu privire
la aciunile utilizatorului i administratorului trebuiesc consolidate ntr-o baz de
date protejat.
Aceast baz de date, n general, trebuie s includ caracteristici de baz
non-repudiere, care o protejeaz de tergere sau de corupie a datelor. Aceast
capacitate nu este disponibil n mod obinuit pe dispozitive individuale.
Utilizarea Syslog pentru a consolida aceste informaii pe mai multe dispozitive,
ntr-o baz de date separat, ndeplinete aceste cerine necesare de audit. Punerea
n aplicare a Syslog-ului n servere i dispozitive de reea poate i de obicei este
dramatic de diferit n funcie de dispozitiv. De exemplu, configurarea unui

NECLASIFICAT

din
NECLASIFICAT

firewall de tip CISCO PIX pentru Syslog poate utiliza o structur de comand
similar cu exemplul urmtor:

logging on
logging standby
logging timestamp
logging trap notifications
logging facility 19
logging host inside 192.168.1.203

n schimb, configurarea aceluiai tip de logare pe un comutator Cisco Catos


poate utiliza urmtoarea structur de comand :

set logging server enable


set logging server 192.168.1.203
set logging level all 5
set logging server severity 6

Unix, Linux i Microsoft Windows au de asemenea mecanisme diferite


pentru activarea logrii Syslog. Trebuie s se consulte documentaia produsului
pentru informaii specific asociate cu activarea i configurarea syslog pe fiecare
dispozitiv. Un alt aspect important este c un serviciu Syslog sau daemon trebuie
s fie activat pe gazda destinaie (192.168.1.203, n exemplele anterioare), pentru
a primi informaii.
Telnet, SSH i Syslog n sisteme de management de astzi, ca i cele axate
pe Microsoft Windows, sunt utile pentru gestionarea reelei. Telnet i SSH sunt
ambele utile pentru testarea reelei, precum i conectarea dispozitivelor din reea.
Activarea Syslog-ului pe dispozitivele din reea creeaz automat o baz de date
de informaii utile pentru auditoria de conformitate.

3.1.7 Protocoale bazate pe flux de date ( The Flow-Based Protocols)

Protocoalele de management discutate n aceast lucrare pun ntr-un mod


plcut nevoile de gestionare ale mananagementului cu cele ale inventarului.
Capabilitile de baz de depanare au fost de asemenea discutate cu instrumente
cum ar fi ping i telnet.Cu toate acestea, orice reea care se extinde dincolo de
doar cteva componente , necesit capabiliti avansate de analiz, care pur i
simplu nu sunt disponibile cu aceste seturi de instrumente de baz. n ziua de
astzi, atunci cnd utilizatorii apeleaz pentru a informa c reeaua este lent,
trebuie s deii funcionaliti suplimentare care indic cauza problemei.
Instrumentele tradiionale pentru a realiza acest nivel profund de depanare,
de multe ori s-au concentrat pe analiza de pachete i de inspecie. Cu toate acestea,
procesul de a gsi sens n pachete individuale este extreme de dificil pentru toate,
dar cel mai experimentat de inginerii de reea. n plus, aceste instrumente nu sunt
NECLASIFICAT

din
NECLASIFICAT

concepute pentru a oferi ca inginer o imagine la nivel nalt a componentelor de


reea. Perspectiva lor de nivel sczut, pur i simplu nu ofer un fel de valori care
explic modul n care se mic n jurul reelei.
Cu o astfel de perspectiv, un inginer de reea se poate uita la un nivel
ridicat de fluxuri pentru a izola rapid utilizarea benzii i identificarea
comportamentelor de trafic bazate pe porturi, protocoale, puncte finale i aplicaii
individuale de reea. Aceast perspectiv la nivel nalt este dobndit printr-o suit
de protocoale denumit n mod obinuit ca NetFlow.

3.1.7.1 Fluxurile de reea

Pentru nceput trebuie considerat n primul rnd ceea ce reprezint un flux


de reea. Un flux este identificat prin combinarea unui set de domenii-cheie dintr-
un flux de pachete de reea. Aceste domenii-cheie tind s includ urmtoarele:

- Adresele IP pentru surs i destinaie


- Porturile pentru surs i destinaie
- Structura protocolului de nivel 3
- Tipul serviciului (byte) (ToS)
- Indice de interfa logic

Orice flux de reea, prin definiie, va fi format din toate pachetele de reea,
care au aceleai informaii n fiecare dintre aceste domenii. De exemplu, n cazul
n care un serviciu de reea pe un server comunic cu un altul, acea comunicare a
serviciilor va tinde s apar ntre cele dou gazde, peste un port neschimbtor,
folosind un protocol neschimbtor i ToS, prin aceeai interfa logic. Odat ce
este adunat un set de date care conine aceleai apte elemente, patru seturi de
informaii statistice pot fi obinute:

- Timpul de funcionare al sistemului la nceputul fluxului


- Timpul de funcionare al sistemului la sfritul fluxului
- Numrul de pachete n flux
- Numrul de octei n flux
Dei mici n numrtoare, aceste patru buci de informaii ilumineaz o
cantitate mare de detalii despre comunicarea dintre dou calculatoare. Rata de
schimb de date poate fi acum msurat. Timpul necesar pentru ca o comunicare
s aib loc, ct i cantitatea de timp n care cele dou calculatoare comunic pot
fi colectate n mod similar. Cantitatea mare de date ce este transferat n acest
timp este o alt valoare important obinut prin aceast msuratoare. Evident,
informaiile NetFlow trebuie s aib loc din punctul de vedere al dispozitivului,
care sunt trimiterea i/sau primirea pachetelor. Astfel, orice informaie bazat pe
flux trebuie s fie privit cu recunoaterea sursei sale de msurare.

NECLASIFICAT

din
NECLASIFICAT

3.1.7.2 NetFlow, J-Flow, sFlow i IPFIX

Industria din zilele noastre utilizeaz termenul NetFlow n mod generic, dar
protocolul NetFlow este de fapt o dezvoltare a celor de la Cisco Systems. Ca atare,
orice dispozitive bazate pe tehnologia celor de la Cisco vor utiliza implementarea
NetFlow de analiz bazat pe flux. Patru versiuni ale protocolului NetFlow rmn
n uz astzi, cu dou dintre acestea rar vzute n reelele de afaceri de azi:

- NetFlow Versiunea 5 - Iniial dezvoltat de Cisco Systems, dar folosit n


prezent de ctre ali furnizori, inclusiv Adtran
- NetFlow Versiunea 7 Rar ntlnit astzi, specific pentru switchuri
Cisco Catalyst
- NetFlow Versiunea 8 Rar ntlnit astzi , a introdus tehnologia de
agregare
- NetFlow Versiunea 9 versiunea cea mai comun n desfurare n
prezent, include disponibilitatea de mas a
caracteristicilor de agregare anterioare
Dei Cisco Systems este creditat cu prima punere n aplicare n curs de
dezvoltare, ali vnztori au dezvoltat propriile variante ale arhitecturii pentru a fi
utilizate n mod hardware. Exist trei exemple majore de implementare:

- J-Flow Dezvoltat de Juniper Networks pentru utilizarea n propriile echipamente


hardware, efectiv la fel ca Cisco NetFlow Versiunea 5
- sFlow O implementare bazat pe standarde (RFC 3176) a crei dezvoltare este
mprtit de HP, Extreme , Foundry, Juniper i Nortel , sFlow este unic prin
faptul c msurtorile sale se bazeaz pe o eantionare statistic a datelor de flux,
care are ca efect reducerea cantitii totale de date care este necesar pentru a fi
inclus n eantion pentru a obine un rezultat statistic similar
- IPFIX Considerat ca fiind urmtoarea versiune de Netflow, sau NetFlow
Versiunea 10, IPFIX se bazeaz pe Cisco NetFlow Versiunea 9; printre alte
capabiliti, IPFIX ofer ablonul de export al datelor

3.1.7.3 Avantajul utilizrii NetFlow-ului

Puterea protocoalelor bazate pe flux exist n omniprezena lor. Ca i


Simple Network Management Protocol (SNMP), codul necesar i procesul pentru
a permite i folosi protocoalele bazate pe flux sunt deja incluse cu aproape toate
componentele hardware disponibile n reea. Astfel, componentele hardware
existente au nevoie ca NetFlow-ul sa fie configurat i activat pentru a ncepe s te
bucuri de capacitile sale de analiz. Ca i configuraiile cu Syslog, diferitele
dispozitive vor avea mecanisme diferite pentru a permite exportul de flux de
informaii. Pentru un router CISCO IOS, paii de configurare ar putea s semene
cu urmtorul exemplu:
NECLASIFICAT

din
NECLASIFICAT

router#enable
Password:*****
router#configure terminal
router1234(config)#interface FastEthernet 0/1
router1234(configif)#ip routecache flow
router1234(configif)#exit
router1234(config)#ip flowexport destination 192.168.1.100 9996
router1234(config)#ip flowexport source FastEthernet 0/1
router1234(config)#ip flowexport version 5
router1234(config)#ip flowcache timeout active 1
router1234(config)#ip flowcache timeout inactive 15
router1234(config)#snmpserver ifindex persist
router1234(config)#^Z
router#write

Aceti pai permit exportul de informaii de tip flux pe interfaa


FastEthernet 0/1 pentru a fi direcionat ctre serverul 192.168.1.100 prin portul
9996. Aceast configuraie trebuie s fie activat pentru fiecare dintre interfeele
pe care fluxul de informaii ar trebui s fie exportat.
Evident, configurarea informaiilor NetFlow peste dispozitivele de reea i
interfeele din mediul nconjurtor realizeaz doar o jumtate din configurare.
Nivelul informaiilor care pot fi colectate printr-o interfa NetFlow este mare i
necesit calcul suplimentar de ctre un server la punctul final n cazul n care
datele sale sunt utile administratorului. Astfel, treaba serverului este de a calcula
datele, msura impotriva altor informaii de intrare i crearea de vizualizri ce
arat informaii cu caracter activ.

3.1.8 Cisco IP Service Level Agreements

Protocolul final de management care va fi discutat n aceast lucrare este o


caracteristic de proprietate, care este inclus cu Cisco IOS. Aceast caracteristic
, numit IP Service Level Agreements (IP SLA), reprezint un alt mecanism prin
care statisticile i alte metrici de performan i de utilizare pot fi msurate n
ntreaga reea.
Cu toate c informaia obinut cu IP SLA este adesea folosit pentru
aceleai tipuri de activiti de depanare i de analiz asa cum se ntmpl cu datele
NetFlow, informaiile reale colectate sunt diferite. Cu NetFlow, dispozitivele
individuale adun statistici agregate peste interfeele individuale, prezentnd
rezultatele unui server central de procesare.
Datele obinute prin activarea metricilor IP SLA sunt diferite prin faptul c
acestea reprezint rezultatele unei serii de teste, n curs de desfurare, care sunt
preconfigurate pentru dispozitive de reea specifice. Aceste teste periodice sunt
utilizate pentru a valida conexiunea precum i a evalua metricile de performan
instantanee de-a lungul interfeelor specificate. SLA n IP SLA se refer la
NECLASIFICAT

din
NECLASIFICAT

capacitatea acestui protocol de a testa n mod automat i n mod repetat dac un


anumit comportament de reea funcioneaz la niveluri ateptate.
De exemplu, reelele de afaceri care ncorporeaz servicii VoIP n reea
necesit o contientizare a faptului c nivelul calitii serviciului rmne la un
nivel ridicat. Cu toate c informaiile de tip NetFlow ofer o nelegere a
volumului de date care apare pe diferite dispozitive din reea, datele de testare
suplimentar sunt utile pentru msurarea n mod repetat i raportarea acestora cu
privire la experiena utilizatorului.
De exemplu, n cazul serviciilor VoIP, nivelul de bruiaj al protocolului
UDP n ntreaga reea este o metric a crei valoare poate fi tradus direct ntr-un
apel de calitate. Jitterul UDP-ului are loc atunci cnd latena de-a lungul
conexiunilor reelei nu prezint o rat constant. Datorit naturii serviciilor VoIP,
schimbarea rapid a jitterului n raport cu latena conexiunii are un efect dramatic
asupra calitii apelului. Pentru a identifica atunci cnd acest comportament merge
dincolo de pragul acceptabil, un test IP SLA poate fi configurat pentru a msura
jitterul dintre dou puncte finale.
Acest singur test ajut administratorul s neleag comportamentul care
apare la acea singur locaie. Dar, acolo unde cea mai mare putere a IP SLA ului
apare este n abilitatea de a sincroniza teste similare de-a lungul ntregii reele
distribuite , artnd n mod eficient aceeai valoare a metricii de-a lungul mediului
n acelai timp. Pentru o aplicaie distribuit, cum ar fi VoIP, aceast viziune pe
scar larg asist administratorii de reea cu privire la urmrirea problemelor de
reea precum i localizarea lor.

3.1.8.1 Extinderea monitorizrii tradiionale cu ajutorul IP SLA

Acest concept de a fi peste tot n acelai moment de timp tinde sa fie un


interes pentru extinderea dispozitivelor tradiionale de monitorizare a reelei. n
monitorizarea reelei tradiionale, arhitectura presupune un tip de metodologie
hub-and-spoke. Cu toate acestea, tradiionala metodologie hub-and-spoke vede
limitele sale atunci cnd se ncearc msurarea performanei de la un site la altul.
Aceast configuraie este deosebit de problematic atunci cnd sistemul
central de management al reelei nu exist n niciunul dintre cele dou site-uri care
urmeaz s fie msurate. De asemenea, provocatoare sunt arhitecturile de reea
care nu ruteaz accesul la Internet printr-o singur conexiune central. Atunci
cnd site-urile individuale se conecteaz prin intermediul legturilor de tip Multi-
Protocol Label Switching (MPLS), colectarea corect a statisticilor reprezint o
provocoare atunci cnd sunt folosite metodele tradiionale.
Un mecanism pentru a ocoli aceast limitare a fost utilizarea de sonde
hardware, a cror instalare necesit o conexiune fizic la reeaua n care erau
nsrcinate cu monitorizarea. Sondele de reea monitorizeaz pasiv datele de-a
lungul reelei la care sunt conectate, supunnd metrici napoi la sistemul de
NECLASIFICAT

din
NECLASIFICAT

management central. Deoarece sondele funcioneaz n linie cu reeaua,


comportamentele pe care le observ se refer la segmentul de reea individual
unde acestea sunt instalate.
Cu toate acestea, faptul c sondele hardware sunt dispozitive fizice, adaug
un nivel semnificativ la antetul administrativ al folosirii lor. Instalarea sondei
nseamn a fi prezent fizic la locul de monitorizare. Achiziionarea de sonde
implic costuri, care scaleaz n mod liniar pe msur ce este nevoie de mai multe
sonde. n cele din urm, cu toate c sondele pot oferi nivelul de detaliu necesar
pentru a msura metricile menionate mai sus, ele fac acest lucru cu ajutorul unei
sarcini nsoitoare. Ca i codul de baz care permite colectarea metricilor
NetFlow, codul de baz al IP SLA-ului este complex i probabil deja instalat pe
echipamentul de reea. Astfel, activndu-le pentru utilizare implic mai mult dect
reconfigurarea dispozitivelor de reea, determinarea testelor ce urmeaz s fie
executate i artnd rezultatele unui sistem de management de reea pentru
prelucrare.
De exemplu, pentru a configura un test de ping bazat pe ICMP care s aib
loc la fiecare 30 de secunde ntre dispozitivul de reea i adresa IP 192.168.1.100
de la distan , o structur de comand similar ar putea fi urmtoarea :

Switch(config)# ip sla 1
Switch(configipsla)# icmpecho 192.168.1.100
Switch(configipslaecho)# frequency 30
Switch(configipslaecho)# exit
Switch(config)# ip sla schedule 5 starttime now life forever
Switch(config)# end

n aceast structur, testul ICMP provenit de la switch i cu gazda


192.168.1.100 ca destinaie este configurat s aib loc la fiecare 30 de secunde i
s ruleze pentru totdeauna. Informaiile despre adresa IP SLA sunt pasate napoi
ctre sistemul de management al reelei prin acelai canal utilizat de ctre Simple
Network Management Protocol. Ca atare, configuraia SNMP a dispozitivului
trebuie s fie activate pentru ca informaiile de tip IP SLA s poat s fie
prezentate.

NECLASIFICAT

din
NECLASIFICAT

Capitolul IV . Metode de monitorizare

n ultimii ani, micile ntreprinderi au devenit inte ale intruziunilor de reea


, deoarece hackerii sunt contieni de faptul c cele mai multe ntreprinderi nu pun
n aplicare practicile de securitate. Percepia este c securitatea reelei este
important numai pentru companiile mari, organizaiile guvernamentale i
instituiile financiare. Aceast percepie se schimb rapid odat cu creterea
numrului de ntreprinderi de mrimi mici.
Exist o mare varietate de metode de monitorizare a reelei, care sunt puse
n aplicare de ctre profesionitii IT. Tehnicile sunt implementate prin soluii de
monitorizare a reelei, care detecteaz i rspund problemelor legate de securitate
i de performan n mod automat.

4.1 Intrusion Detection

Prin aceast metod se monitorizeaz reelele locale pentru accesul


neautorizat de ctre hackeri. Aceast metod poate fi implementat manual, cu
toate acestea, cei mai muli profesioniti IT prefer s utilizeze un program de
detectare a intruziunilor, care detecteaz automat virui i malwar, vulnerabiliti
de reea cum ar fi backdoors, logic bombs i alte ameninri de securitate.
Programele de detectare a intruziunilor genereaz rapoarte n urma unui control
de sistem astfel nct orice probleme pot fi abordate.
Un sistem de detectare a intruziunilor (IDS) este o aplicaie software sau
hardware care monitorizeaz activitile legate de reea sau de sistem pentru a
identifica activiti cu caracter negative sau nclcri ale politicilor i produce
rapoarte la o staie de management. Utilizatorii de acas i cei business sunt
conectai la reeaua global Internet folosind metoda conexiunii permanent active,
acest lucru permind hackerilor s atace. Atacurile i intruziunile cost enorm
companiile n contextul de furt de informaii, pierderi de productivitate n urma
serviciilor compromise, precum i costurile pentru remedierea echipamentelor
afectate. Pe parcusul anilor, numrul de infiltrri n sistem a crescut i sunt din ce
n ce mai sofisticate. Doar sistemele automate de detective i prevenire a
intruziunilor ar putea atenua atacuri complexe cu viteza necesar sau prevenirea
pagubelor.

NECLASIFICAT

din
NECLASIFICAT

Fig. 4.1.1 Exemplu de sistem de detecie i prevenire a intruziunilor[9]

Fig. 4.1.2 Sistem de detectare a intruziunilor pasiv[10]


NECLASIFICAT

din
NECLASIFICAT

4.2 Packet Sniffing

Este o ironie crud n securitatea informaiilor pe care multe dintre


caracteristicile care fac mai uoar utilizarea calculatoarelor sau mai eficient i
instrumentele folosite pentru a proteja i securiza reeaua pot fi de asemenea
folosite pentru a exploata i a compromite aceleai echipamente i reele. Acesta
este cazul cu packet sniffing.
Un packet sniffer este un program care inspecteaz fiecare pachet de
informaii care trece prin reea. Scopul acestuia este de a detecta software-ul de
monitorizare a reelei neautorizat , care poate fi instalat de ctre hackeri pentru
spionaj asupra proceselor de activitate sau a celor legate de informaii. Folosind
informaiile capturate de program , un administrator poate identifica pachetele
eronate i poate folosi datele pentru a identifica blocajele i a ajuta la meninerea
unei transmisii eficiente a datelor n reea.
n forma sa simpl, un packet sniffer surprinde pur i simplu toate pachetele
de date care trec printr-o interfa de reea dat. De obicei, programul ar captura
numai pachetele care au fost destinate pentru aparatul n cauz .Cu toate acestea,
dac sunt plasate n modul promiscuous, programul este de asemenea capabil s
captureze toate pachetele care traverseaz reeaua indiferent de destinaie. Prin
plasarea unui packet sniffer pe o reea n modul promiscuous, un intrus ar putea
captura i analiza tot traficul de reea. ntr-o anumit reea, informaiile legate de
numele de utilizator i parola sunt transmise n general n text cla , ceea ce
nseamn c informaiile ar putea fi vizualizate prin analizarea pachetelor
transmise.
Prin nsi natura sa, packet snifferul este pasiv. El surprinde pur i simplu
pachetele care cltoresc pe interfaa monitorizat din cadrul reelei. Exist
modaliti de a identifica interfeele de reea din reea, care ruleaz n modul
promiscuous, dei i acest lucru ar putea fi folosit ca mijloc pentru localizarea
pachetelor nedorite.

Packet Sniffer

Router Router
Host A B Host B
A

Fig. 4.2.1 Exemplu general pentru packet sniffing

NECLASIFICAT

din
NECLASIFICAT

Exemple de programe tip packet sniffer:

- WireShark Packet Sniffer


- Capsa Packet Sniffer
- SniffPass Password Sniffer
- Microsoft Network Monitor
- Tcpdump
- Kismet
- EtherApe
- Cain and Abel
- NetworkMiner
- KisMAC

4.3 Vulnerability Scanning

Un scaner de vulnerabilitate este o aplicaie software care evalueaz


vulnerabilitile de securitate n reele sau sisteme gazd i produce un set de
rezultate de scanare. Cu toate acestea, deoarece att administratorii ct i atacatorii
pot utiliza acelai instrument pentru fixarea sau exploatarea unui sistem ,
administratorii trebuie s efectueze o scanare i s rezolve problemele nainte ca
un atacator s execute aceeai scanare i s exploateze vulnerabilitile gsite.
n primul rnd , un scaner de vulnerabilitate permite depistarea precoce i
manipularea problemelor cunoscute de securitate. Prin utilizarea evalurilor de
securitate n curs de desfurare folosind scanere de vulnerabilitate este uor de
identificat acele vulnerabiliti care pot fi prezente n reea, att din perspectiv
intern, ct i extern.
n al doilea rnd, un dispozitiv nou sau chiar un sistem nou poate fi conectat
la reea fr autorizaie. Un scaner de vulnerabilitate poate ajuta la identificarea
echipamentului, care ar putea pune n pericol sistemul global i securitatea reelei.
n al treilea rnd , un scaner de vulnerabilitate ajut s verifice inventarul
tuturor dispozitivelor cu privire la reea. Inventarul include tipul de dispozitiv,
versiunea sistemului de operare i nivelul patchului, configuraii hardware i alte
informaii relevante de sistem. Aceste informaii sunt utile n managementul
securitii i n urmrire (tracking).

NECLASIFICAT

din
NECLASIFICAT

Scan Engine

User Interface
Scan Report
Database Module

Fig. 4.3.1 Componentele unui Scaner

Exemple de programe de tip vulnerability scanner:


- Nmap
- Superscan
- Nessus
- GFI LANguard Network Security Scanner
- Nikto
- Paros
- Acunetix Web Vulnerability Scanner
- Microsoft Baseline Security Analyser (MBSA)

4.4 Firewall Monitoring

Un firewall poate ine la distan traficul Internet cu intenii rele, de


exemplu hackerii, viermii i anumite tipuri de virui, nainte ca acetia s pun
probleme sistemului. n plus, un firewall poate mpiedica participarea
computerului la un atac mpotriva altora, fr cunotina sau voina utilizatorului.
Utilizarea unui firewall este important n special dac reeaua sau echipamentul
protejat sunt conectate n permanen la Internet.
Firewall-urile monitorizeaz traficul care vine n interiorul i n afara
reelei. Monitorizarea firewall-ului urmrete activitile unui firewall pentru a
asigura procesul de screening pentru conexiunile de intrare i de ieire.
Firewall-urile sunt clasificate n trei categorii principale: filtrare de pachete,
gateway-uri de circuit i gateway-uri de aplicaii. Administratorul poate defini o
list a echipamentelor i a serviciilor acceptabile (bazate pe numere de porturi) i
o list cu interzis pentru echipamente i servicii nedorite. Deoarece un filtrru de
NECLASIFICAT

din
NECLASIFICAT

pachete este capabil s analizeze headerele protocoalelor de Internet (TCP/IP i


UDP), flagurile TCP pot fi de asemenea utilizate pentru a filtra pachete. UDP nu
este bazat pe conexiune i de aceea nu reine nicio informaie de tip state.
Un firewall coopereaz ndeaproape cu un program de rutare, care
examineaz fiecare pachet de date din reea (fie cea local sau cea exterioar) ce
va trece prin serverul pasarel, pentru a hotr dac va fi trimis mai departe spre
destinaie sau nu. De asemenea, un firewall include sau lucreaz mpreun cu un
server proxy care face cereri de pachete n numele staiilor de lucru ale
utilizatorilor. n cele mai ntlnite cazuri aceste programe de protecie sunt
instalate pe calculatoare ce ndeplinesc numai aceast funcie i care sunt instalate
n faa routerelor.

Soluiile de protecie prin firewall se mpart n :

- Soluii profesionale hardware sau software dedicate proteciei ntregului trafic


dintre reeaua unei ntreprinderi i restul Internetului.
- Firewall-uri personale dedicate monitorizrii traficului pe echipamentul personal

nainte de a construi un firewall trebuie hotrt politica sa, pentru a ti


exact care va fi funcia sa i n ce fel se va implementa aceast funcie. Politica
firewall-ului se poate alege urmnd civa pai simpli [11] :
- se aleg nti serviciile care trebuie oferite de paravanul de protecie
- se desemneaz grupurile de utilizatori care vor fi protejai
- se definete amnunit gradul de protecie de care are nevoie fiecare grup de
utilizatori i cum vor fi implementate proteciile necesare
- se face cunoscut utilizatorilor c oricare alte forme de acces nu sunt premise

LAN

LAN
Firewall
WAN

LAN

NECLASIFICAT

din
NECLASIFICAT

Fig. 4.4.1 Modul de lucru al unui firewall

4.5 Penetration testing

Testarea de penetrare este efectuat de ctre profesionitii IT prin utilizarea


unor metode asemntoare celor folosite de hackeri pentru a strpunge reeaua.
Scopul acestui proces este de a duce securitatea reelei la un alt nivel, prin
descoperirea vulnerabilitilor pe care hackerii ar putea s le cunoasc, dar nc
nu au fost detectate prin intermediul altor metode de monitorizare.
Testarea de penetrare este o combinaie de tehnici care ia n considerare
diverse aspecte ale sistemelor i testelor, analizelor i ofer soluii. Aceasta se
bazeaz pe o procedur structural care efectueaz teste de penetrare pas cu pas
ca n figura 4.5.1 :

NECLASIFICAT

din
NECLASIFICAT

Fig. 4.5.1 Etapele unei testri de penetrare

NECLASIFICAT

din
NECLASIFICAT

Capitolul V . Softuri pentru monitorizare

O parte important din activitatea unui administrator de reea o reprezint


monitorizarea reelei pentru performan, utilizare trafic, defecte i disponibilitate
i s rspund rapid la probleme. Un instrument de reea de monitorizare este un
software bazat pe o combinaie de soft sau hard care monitorizeaz reeaua de la
un capt la altul, ce colecteaz date cu privire la sute de metrici de performan ,
printre care limea de band, latena, capacitatea de reacie i utilizarea
procesorului.
Cele mai multe produse de monitorizare a reelei funcioneaz bine pentru
reele de dimensiuni mici i medii , fie prin cablu fie prin wireless. Dar reelele
mai complexe, cele ale nteprinderilor i mediilor distribuite, au nevoie de o
platform cuprinztoare care ofer vizibilitate asupra serverelor fizice i virtuale,
link-uri de reea de arie larg (WAN), o arhitectur de tip software-defined
network (SDN), servicii bazate pe cloud, aplicaii bazate pe reea.
Pentru monitorizare se pot folosi multe softuri, unele din ele sunt gratis cu
licene GPL (General Public License), iar altele sunt cu bani. Softurile de
monitorizare ca MRTG (Multi Router Traffic Grapher), RRDtool (Round-robin
Database), Munin, Cacti, Nagios i altele sunt descrise mai jos.

5.1 MRTG (Multi Router Traffic Grapher) software

MRTG este un instrument de monitorizare care poate monitoriza


performana dispozitivelor de reea, sistemelor, aplicaiior i parametrii mediului
n acelai timp. Acesta genereaz o pagin HTML cu format imagine de tip PNG
(Portable Network Graphics) pentru a reprezenta grafic statisticile de trafic. Se
poate configura pentru a monitoriza orice variabil SNMP, cum ar fi sistemele de
ncrcare sau interfee de reea.
Programul a fost nscris n Perl Tobias Outaykerom- institutul naional al
Danemarcei, o cercetare de mediu n 1994 i a fost conceput iniial pentru a
monitoriza sarcina de canal care leag reeaua Institutului la Internet. Mai trziu,
un ofier de la Cisco Systems, Dave Rand, a mbuntit eficiena codului , scris
pentru el de ctre un modul pe limbajul C. Pachetul MRTG ruleaz pe platforme
Unix , Linux i Microsoft Windows. Pentru a ncepe lucrul cu MRTG, nu trebuie
s fii un expert n domeniul de cunoatere a limbajului C sau Perl. Exist mai
multe ghiduri care v pot ajuta ca s il configurai pentru a monitoriza interfee de
reea. Pentru o utilizare mai avansat a MRTG-ului care implic sarcini complexe
de monitorizare, trebuie s deii cunotine ale limbajului Perl. Tot ce este nevoie
este de a rula script-ul de instalare pe un calculator care ruleaz Windows NT sau
de a instala pachetul RPM pe Linux. Pe Web-site-ul MRTG exist linkuri pentru
distribuia gratuit Perl-ActivePerl din partea societii ActiveState i se
instaleaz la fel de uor ca orice alt aplicaie pe Windows.

NECLASIFICAT

din
NECLASIFICAT

MRTG lucreaz prin citirea datelor din protocolul SNMP GET care citete
periodic valorile, de exemplu ifInOctets(OID 1.3.6.1.2.1.2.2.1.10) i
ifOutOctets(1.3.6.1.2.1.2.2.1.16), care nregistreaz numrul de intrri
(ifInOctets) i de ieiri (ifOutOctets) de octei pentru o interfa. Ambii parametrii
sunt afiai ntr-un calendar n PNG pentru pagina HTML. Aceti parametrii se
pot referi la orice dispozitiv, de la router la server. MRTG afieaz valorile medii
ale parametrilor monitorizai n timpul sptmnii, lunii i anului , calculate pe
baza unor msurtori efectuate la intervale de 5 minute. Un program sptmnal
se bazeaz pe intervale de jumtate de or, cu o medie a rezultatelor de ase ori
consecutiv. n consecin, graficul lunar se bazeaz pe date pentru inervale de o
sptmn n medie dou ore, iar anual-datele pentru luna n medie la fiecare 24
de ore frecvena cu care a colectat i media de date la intervale adecvate, puse n
aplicare n instrumente de monitorizare.
Un pachet MRTG nu susine o baz de date exterioar. Informaiile sunt
stocate n fiiere de tip text ASCI , care sunt terse imediat dup utilizarea lor
pentru a calcula mediile de sptmni, luni i ani.

Fig. 5.1.1 Exemplu de grafic utiliznd MRTG

NECLASIFICAT

din
NECLASIFICAT

5.2 RRDtool (Round-robin Database) software

RRDtool i propune s se ocupe de serii de date pe timp, cum ar fi limea


de band, temperaturi sau ncrcarea procesorului. Datele sunt stocate ntr-o baz
de date pe bazat pe un buffer circular, astfel amprenta de stocare rmne
constant n timp. Acest lucru este diferit de conceptul de informatic al
programrii round-robin. Acesta include de asemenea instrumente pentru a
extrage date de tip round-robin ntr-un format grafic pentru care a fost prevzut
iniial. Exist i o implementare independent Java complet numit rrd4j. Pentru
a crea unele grafice cu acest soft este nevoie de cunotine n limbajele de
programare Perl, Python, Ruby i PHP.
Putem afirma c RRDtool este unul dintre principale instrumente de
monitorizare , deoarece acesta reprezint i un DBMS (Database Management
System) pentru foarte multe softuri cum ar fi : BackupPC, Cacti, Cherokee,
Ganglia, Lighttpd, Monitorix, MRTG, Munin, Nagios, Nmon, ntop, OpenNMS ,
SmokePing, SNM, SysUsage, Zenoss Core i multe alte softuri.
Softul presupune date de timp variabile n intervale de o anumit lungime.
Acest interval de timp, de obicei numit pas, este specificat la creearea unui fiier
RRD i nu poate fi modificat ulterior. Deoarece datele nu pot fi ntotdeauna
disponibile la momentul potrivit, RRDtool va interpola n mod automat toate
datele transmise pentru a se potrivi cu etapele temporale ale procesului intern.
Valoarea pentru un anumit pas, care a fost interpolat, este numit punct de
date primar(PDP). PDP-urile multiple pot fi consolidate n conformitate cu o
funcie de consolidare (CF) pentru a forma un punct de date consolidate (CDP).
Funcii de consolidare tipice sunt: media, minimul, maximul. Dup ce datele au
fost consolidate, CDP rezultat este stocat ntr-o arhiv round-robin (RRA). O
arhiv round-robin stocheaz un numr fix de CDPs-uri i specific ct de multe
PDP-uri ar trebui s fie consolidate ntr-un singur CDP i care CF trebuie
folosit.Timpul total acoperit de RRA poate fi calculat dup cum urmeaz :

Time covered = (#CDPs stored) x (#PDPs per CDP) x steps

Urmtoarea inserare va suprascrie cea mai veche intrare. Acest


comportament n acest context face referire la round-robin i este motivul pentru
numele programului. Totui, acest lucru este diferit de definiia informatic, care
este o metod de distribuire a resurselor ntre mai muli consumatori sau procese.
Pentru a acoperi mai multe intervale de timp i/sau de a folosi mai multe funcii
de consolidare, un fiier RRD poate s conin mai multe RRA-uri. Funcia de
recuperare de date a RRDtool-ului selecteaz automat arhiva cu cea mai mare
rezoluie care acoper nc intervalul de timp solicitat. Acest mecanism este de
asemenea utilizat de subsistemul grafic al softului.

NECLASIFICAT

din
NECLASIFICAT

Fig. 5.2.1 Interfaa de testare a RRDtool-ului [13]

5.3 Munin software

Munin este un sistem de monitorizare open-source gratuit folosit pentru a


monitoriza reeaua i infrastructura unei aplicaii soft n cazul procesului de
monitorizare. Acesta ofer monitorizare i servicii de alertare pentru servere,
switch-uri, aplicaii, servicii etc. Acesta avertizeaz utilizatorii atunci cnd
lucrurile nu merg bine i i alerteaz a doua oar printr-o notificare c problema a
fost rezolvat. Munin este programat n Perl i folosete RRDtool pentru a crea
grafice, care sunt accesibile printr-o interfa web.
Aproximativ 500 de plugin-uri de monitorizare sunt disponibile n prezent.
Acesta este destinat pentru a face mai uor determinarea a ceea ce este diferit
astzi, atunci cnd o problem de performan se ntmpl i pentru a oferi
vizibilitate n capacitatea i utilizarea resurselor. Munin a fost creat de ctre
Jimmy Olsen la sfritul anului 2003, bazat pe RRD de Tobi Oetiker.Dezvoltarea
acestuia a ncetinit din 2005, dar softul este un instrument stabil i nc este
meninut n reele de comunicaii pentru a se efectua procesul de monitorizare.
NECLASIFICAT

din
NECLASIFICAT

Numele su este derivat din mitologia nordic i se refer la unul din cei
doi corbi care raportau tirile din lume zeului Odin, iar cel de-al doilea corb se
numea Hugin. Munin nseamn memorie i Hugin nseamn gndit. Softul
prezint o arhitectur de tip master-slave, n care masterul se conecteaz la toate
nodurile la intervale regulate de timp i le cere date. Apoi acesta stocheaz datele
n fiiere RRD i (dac este necesar) actualizeaz graficele. Unul dintre
obiectivele principale a fost de a uura crearea de noi plugin-uri (grafice).
Plugin-urile sunt programe specializate, care sunt numite de nodurile
Munin-ului pentru a aduna i raporta date curente, i s descrie modul n care ar
trebui s fie prezentate. Exist peste 300 de plugin-uri n distribuia de baz, peste
180 de plugin-uri n partea de depozitare, i un numr necunoscut de plugin-uri
publicate n mod independent. Ele pot fi scrise n orice limbaj de programare sau
scripting. Toate acestea sunt necesare pentru a realiza spaiul softului pentru
imprimarea cheii i volorile pereche ale ieirilor standard.
Sistemul este alctuit din dou pri independente: un server (n sine
Munin), instalat pe main, care va colecta toate datele, precum i un mic Munin
deamon-nod, care este instalat pe mainile pe care le monitorizeaz. Acest
deamon este un mic Perl Script, care ascult portul 4949 cu ajutorul
Net:Serverului, unde acesta scaneaz plug-in-urile instalate n /etc/Munin/plugin-
uri i i aduce aminte numele lor. Fiecare server Munin n 5 minute se conecteaz
la toate nodurile i primete informaii de la toate plug-in-urile i menine o baz
de date de tip rrdtool. Astfel, pentru salvarea statisticilor nu avem nevoie de o
baz de date n MySQL.

Fig. 5.3.1 Interfa grafic Munin

NECLASIFICAT

din
NECLASIFICAT

Cel mai bun lucru n Munin sunt plug-in-urile. Simplitatea incredibil de


punere n aplicare permite s scrii plug-in-uri pentru tot ce vrei n cel mai puin
timp petrecut cu documentarea sistemului. Poate c acest lucru explic faptul c
un sistem relativ tnr a crescut ntr-un numr mare dintr-o dat doar prin aceste
plug-in-uri.
De fapt, fiecare plug-in este un sistem de fiiere executabile care prin
producia lor ofer valorile curente ale parametrilor. Cel mai simplu mod pentru
a analiza este un exemplu foarte simplu.
O alt descoperire plcut n legtur cu acest soft este existena Munin-
nod-win-ului, care permite s monitorizezi i servere bazate pe Windows. Dup
cum am observat, Munin deja este un mic sistem de monitorizare care arat prin
grafice, datele ce sunt colectate din 5 n 5 minute, dar la toate aceste date mai are
i opiunea s anune dac careva din acele servicii care sunt monitorizate au
problem sau exist posibilitatea de a aprea o problem. Acest soft are o interfa
grafic web care este uor de utilizat i este destul de nelegtoare pentru cei care
au grij de monitorizarea reelei. Acest soft poate monitoriza mai multe date dect
MRTG, RRDtool.

5.4 Nagios software

Nagios este un sistem liber de monitorizare a sistemelor informatice i


reelelor de calculatoare. Pe lng acestea el monitorizeaz nodurile sau serviciile
de reea i n cazul n care apar probleme ( de exemplu, serviciul nu rspunde)
notific administratorul. Monitorizarea continu a tuturor componentelor va
dezvlui zonele cu probleme i le va rezolva, nainte de producerea unui eec, care
pot afecta performanele reelei. Nagios monitorizeaz activitatea serviiciilor de
reea: SMTP, POP3, IMAP, SSH, Telnet, FTP, HTTP, DNS i multe altele. De
asemenea, el poate fi folosit pentru a urmri utilizarea resurselor de pe server:
ncrcarea procesorului , consumul de memorie, spaiul de pe disc.
Nagios este creat pentru monitorizare de la distan pe un sistem criptat
SSH sau SSL. Arhitectura sa simpl de expansiune poate crea propriile ei ci de
servicii de testare i manipulare evenimente (de exemplu, a reporni un serviciu de
reea). Conceptul de nod mam permite s defineasc ierarhia i relaiile dintre
gazde. Nagios este apreciat pentru abilitatea de a construi hri ale infrastructurii
de reea i grafice a parametrilor diferitelor sisteme care sunt observate.

NECLASIFICAT

din
NECLASIFICAT

Fig. 5.4.1 Interfa web pentru Nagios

Serviciile oferite de acest soft sunt :

- Monitorizarea serviciilor de reea (SMTP , POP3, HTTP , NNTP , ICMP ,


SNMP)
- Monitorizarea resurselor gazd (sarcina procesorului, utilizare Disk,
serviciile oferite)
- Este utilizat n cele mai multe sisteme de operare de reea Microsoft
Windows, chiar i cu modul NRPE_NT
- Suport pentru monitorizarea de la distan prin intermediul tunelurilor
criptate SSH sau SSL
- Uor de utilizat pe baz de modul de arhitectur ( plug-in-uri) s permit
folosirea oricrui limbaj de programare la alegere (Shell, C++, Perl, Python
, PHP , C# i altele) pentru a dezvolta cu uurin propriile lor ci de
verificare a serviciilor
- Servicii de testare simultan

NECLASIFICAT

din
NECLASIFICAT

- Trimite alerte atunci cnd apar probleme cu serviciul sau gazda (prin e-
mail, pager, SMS sau n orice alt mod stabilit de ctre utilizator prin
intermediul sistemului de modul )
- Capacitatea de a defini evenimentele care au auvt loc cu serviciile sau
gazdele, pentru a rezolva problemele n mod proactiv
- Abilitatea de a organiza munca n comun a mai multor sisteme de
monitorizare pentru mbuntirea fiabilitii i de a crea un sistem de
monitorizare distribuit
- Include nagiostats , care afieaz rezumatul global, pentru toate gazdele
care sunt monitorizate

Fig. 5.4.2 Tip alert n softul Nagios

NECLASIFICAT

din
NECLASIFICAT

Fig. 5.4.3 Schema de lucru a sistemului de monitorizare Nagios

5.5 Zabbix software

Zabbix este un software de monitorizare open source enterprise pentru


reele i aplicaii creat de Alexei Vladishev. Acest soft este proiectat pentru a
monitoriza i urmrii starea diverselor servicii de reea, servere i alte elemente
hardware de reea. Zabbix folosete MySQL, PostgreSQL, SQLite, Oracle sau
IBM DB2 pentru a stoca date. Partea sa de background este scris n C, iar partea
din fa este scris n PHP. Zabbix ofer mai multe opiuni de monitorizare :

- Simplele controale pot verifica disponibilitatea i capacitatea de reactive a


serviciilor standard, cum ar fi SMTP sau HTTP fr a instala orice software
de monitorizare pe gazda de reea
- Un agent Zabbix poate fi, de asemenea, instalat pe UNIX i Windows
pentru a monitoriza statistici cum ar fi ncrcarea procesorului, utilizarea
de reea, spatiul pe disc, etc.
- Ca o alternativ la instalarea unui agent pe o gazd, Zabbix include support
pentru monitorizarea prin controale ICMP, SNMP, TCP, precum i IPMI,
JMX, SSH, Telnet, utiliznd parametrii personalizai. Zabbix suport o
varietate de mecanisme de notificare aproape n timp real, inclusiv XMPP
NECLASIFICAT

din
NECLASIFICAT

Eliberat n conformitate cu termenii GNU General Public License version


2, Zabbix este un software gratuit. Zabbix a nceput ca un proiect intern n anul
1998. Dup trei ani, n 2001 a fost lansat la dispoziia publicului n conformitate
cu GPL. A fost nevoie de mai mult de trei ani, pn la prima versiune stabil, 1.0,
ce a fost lansat n anul 2004.

Caracteristici soft
- Performan ridicat, capacitate mare (capabil de a monitoriza sute de mii
de dispozitive)
- Auto-descoperire servere i dispozitive de reea
- Monitorizare distribuit cu administrare web centralizat
- Suport pentru mecanismul de trapping i mecanismul polling
- Ageni de nalt performan ( client software pentru Linux, Solaris, HP-
UX, AIX, FreeBSD, OpenBSD, OS X, Tru64/OSF1, Windows 2000,
Windows Server 2003, Windows XP, Windows Vista, Windows Server
2008, Windows 7)
- Monitorizare JMX
- Monitorizare Web
- Autentificare securizat a utilizatorului
- Permisiuni flexibile ale utilizatorului
- Interfa Web
- Metrici de raportare de tip SLA i ITIL KPI
- Notificri de tip e-mail

Zabbix este format din mai multe module distincte :

- Server
- Ageni
- Proxy
- Interfa (Frontend)

n timp ce serverul, proxy-ul i agenii sunt scrii n limbajul C, frontend-


ul este implementat n PHP i Javascript. Java Gateway, disponibil ncepnd cu
Zabbix 2.0, este scris n Java.

NECLASIFICAT

din
NECLASIFICAT

Fig. 5.5.1 Panoul central Zabbix [14]

5.6 Cacti software

Cacti este un instrument open-source, bazat pe interfa web pentru a arta


statisticile de monitorizare ale reelei. Cacti permite unui utilizator s interogheze
servicii la intervale de timp predeterminate i afieaz datele rezultate. Acesta
este, n general, utilizat pentru a ilustra serii de date n timp a metricilor, cum ar
fi ncarcarea procesorului i utilizarea limii de band a reelei. O utilizare
comun este de a monitoriza traficul de reea cu ajutorul unui router sau switch,
avnd pe o interfa instalat SNMP.
Partea de interfa poate susine utilizatori multipli, fiecare cu propriile lui
seturi de grafice, de aceea este uneori utilizat de ctre furnizorii de gzduire web
(n special serverele dedicate, serverele virtuale private i furnizorii de colocare)
pentru a afia statistici de lime de band pentru clienii lor. Acesta poate fi folosit
pentru a configura colectarea de date n sine, permind anumite setri s fie
monitorizate fr nici o configurare manual a RRDtool-ului. Cacti poate fi extins
pentru a monitoriza orice surs prin scripturi shell i executabile.
Cacti poate folosii cmd.php, un script PHP potrivit pentru instalri mai mici
sau Spine, un poller bazat pe C, care poate scala mii de gazde.
NECLASIFICAT

din
NECLASIFICAT

Proiectul Cacti a fost nceput de Ian Berry pe 2 septembrie 2001. Berry a


fost inspirat pentru a ncepe proiectul de lucru n timp ce lucra pentru un furnizor
de internet, n timp ce era nc n liceu i nva PHP i MySQL. Scopul su central
n crearea softului a fost de a oferi mai mult uurin n utilizarea acestuia dect
RRDtool i mai mult flexibilitate dect MRTG.

Caracteristici principale ale softului :

- Elemente grafice nelimitate


- Suport auto-padding pentru grafice
- Manipularea datelor n grafice
- Surse de date flexibile
- Colectarea de date pe o perioad de timp nestandardizat
- Suport ncorporat SNMP
- abloane grafice
- abloane surse de date
- Arbore, list i previzualizare a datelor n grafice

5.6.1 Afiare date despre metrici n Cacti

Datorit numeroaselor funcii ale softului, un instrument de management


bazat pe utilizator este construit astfel nct s putei aduga utilizatori i s le poti
da drepturi la anumite zone din program. Acest lucru ar permite ca cineva s
creeze anumii utilizatori care pot schimba parametrii graficului, n timp ce alii
pot doar vizualiza graficele .Fiecare utilizator i menine, de asemenea, propriile
setri atunci cnd vine vorba de vizualizarea graficelor.
NECLASIFICAT

din
NECLASIFICAT

n cele din urm, Cacti este capabil de a scala la un numr mare de surse de
date i grafice prin utilizarea template-urilor. Acest lucru permite crearea unui
singur ablon grafic sau surs de date care definete orice surs sau date grafice
asociate acestuia.

5.7 Caracteristici PRO i CONTRA ale softurilor

1. Zabbix

PRO:

- Zabbix monitorizeaz toate protocoalele principale (HTTP, FTP,


SSH, POP3, SMTP, SNMP, MySQL, etc)
- Prezint alerte prin e-mail i/sau SMS
- Prezint o interfa web foarte bun
- Agent nativ disponibil pe Windows, OS X, Linux, FreeBSD etc.
- Aplicaie de monitorizare n mai multe etape (laten, vitez,
coninut)
- Poate vizualiza i compara orice valoare pe care o monitorizeaz
- Monitorizeaz fiierele de tip jurnal i repornirile
- Prezint proxy-uri locale de monitorizare
- Raportare n timp real de tip SLA

CONTRA:

- Zabbix este mult mai complex n a-l configura


- Scalarea este un pic ciudat
- Nu prezint detectare de tip flapping
- Documentaia este plin de informaii neclare
- Folosete o baz de date (cum ar fi MySQL)

2. Nagios

PRO:
- Nagios monitorizeaz toate protocoalele principale (HTTP, FTP,
SSH, POP3, SMTP, SNMP, MySQL, etc)
- Prezint alerte prin e-mail i/sau SMS
- Niveluri de alert multiple: EROARE, AVERTISMENT, OK
- Detectare de tip flapping
- Afiarea automat a topografiei reelei
- Este un soft complet stand-alone, nu are nevoie de un alt soft
suplimentar
- Monitorizeaz coninut de tip web
NECLASIFICAT

din
NECLASIFICAT

CONTRA:

- Nagios are nevoie de acces SSH sau un addon (NRPE) pentru a


monitoriza de la distan sistemul (structuri interne de fiiere
deschise, procesele n derulare, memorie )
- Interfaa web este n cea mai mare parte doar pentru a citi date
- Nu prezint diagrame cu valori monitorizate

3. Hyperic HQ

PRO:

- Soft puternic, prezentnd funcii de monitorizare la nivel nalt


- Prezint alerte
- Prezint sisteme grafice de monitorizare
- Are o interfa de utilizator foarte bine conceput, care permite o
navigare uoar

CONTRA:

- Hyperic HQ nu este stabil la aciunile corective automate pe termen


scurt
- Este nevoie de mai mult efort manual pentru a rula caracteristicile de
remediere ale softului

4. SolarWinds Orion Network Performance Monitor 10.1

PRO:

- Design excelent privind interfaa grafic de utilizator


- Maparea automat a reelei
- Sprijin din partea comunitii oferit de Thwack
- Acces mobil
- Suport nativ Vmware
-
CONTRA:

- Nu se pot configura alertele de pe interfaa web a softului


- Configurare stngace din partea Group Dependency
- Modulul de raportare are nevoie de mai multe rapoarte ad-hoc
- Nu prezint suport nativ pentru Microsoft Hyper-V

NECLASIFICAT

din
NECLASIFICAT

5. WhatsUp Gold Gold Premium

PRO:

- Configurare i descoperire uoar a reelei


- Set mare de faciliti
- Mai multe opiuni de notificare, inclusiv prin e-mail i SMS
- Rapoarte personalizate i detaliate. Suport interval de date
personalizate

CONTRA:

- Este non-intuitiv
- Interfa destul de simpl, fr prea multe detalii i de stil vechi
- Configurarea necesit att interfaa Web, ct i cea Windows
- Raportare neprietenoas pasiv de tip SNMP

6. ManageEngine OpManager

PRO:

- Set mare de faciliti


- Niciun client nu este necesar, doarece este complet bazat pe browser
web.
- Dispozitive monitorizate prin SNMP, WMI, SSH/Telnet
- Notific administratorii prin alarme sau praguri de escaladare

CONTRA:

- Necesit o mulime de configurri manuale


- Erori n clasificarea dispozitivelor
- Interfa de utilizator neconvenional, ngreunnd navigarea
- Configurarea poate fi complex
- Nu exist mai multe alarme de prag (de ex. AVERTISMENT,
CRITIC, etc.)

7. Sciencelogic EM-7

PRO:

- Cost: EM7 ncepe de la 25.000 $ pentru un singur pachet all inclusive


care poate gestiona cteva sute de dispozitive, n timp ce ofertele

NECLASIFICAT

din
NECLASIFICAT

celor de la CA, Hewlett-Packard i IBM sunt de cel puin 10 ori mai


scumpe [15]
- Instalare i configurare rapid
- GUI robust, ofer meniuri de tip pop-up pe dispozitive i este uor
de navigat

CONTRA:

- Nu accept Windows WMI


- Nu poate colecta informaii de tip flux, aa cum o realizeaz
sistemele gen sFlow sau cele Cisco Systems
- Nu ofer topologia reelei i nu poate corela ntreruperile de
funcionare dintre sistem i reea

8. GFI Network Server Monitor

PRO:

- Uor de configurat (se ateapt ca dispozitivele s fie Up i s ruleze


minim o or)
- Alerteaz i corecteaz automat problemele reelei i ale serverului
- Ofer o bibliotec detaliat de controale incorporate pe care le poi
utiliza instantaneu
- Interfa de configurare intuitiv, simpl

CONTRA:

- Costul produsului variaz n funcie de numrul de adrese IP


monitorizate
- Interfaa web este destul de limitat raportat la standardele actuale

9. OpenNMS : OpenNMS 1.6.10

PRO:

- Acordarea licenei este gratuit


- Ofer suport bun i documentare prin wiki-uri i list de adrese
- Minimizeaz alertarea excesiv
- Costurile de sprijin sunt rezonabile prin intermediul grupului
OpenNMS

NECLASIFICAT

din
NECLASIFICAT

CONTRA:

- Interfaa nu este prea intuitiv


- Necesit nvarea i modificarea diferitelor fiiere de configurare
pentru personalizare
- Banii salvai din acordarea licenei gratis pot fi cheltuii pentru
dezvoltare i ntreinere (mai scumpe dect licena n sine)

10. Spicework Spiceworks Help Desk & Network Monitoring Platform

PRO:

- Este un soft gratuit


- Uor de instalat i configurat pentru echipamentele ce ruleaz
Windows
- All in one pentru inventariere, monitorizare i Help Desk
- Punct de plecare pentru managementul IT

CONTRA:

- n cadrul reelelor mai mari performana poate fi lent


- Scalabilitate limitat
- Nu faciliteaz gestionarea controlului dispozitivelor monitorizate
- Este nevoie de o anumit configuraie iniial a dispozitivului, pentru
a putea fi recunoscut de Spiceworks
- VMWare i sistemele de tip *nix nu sunt la fel de descoperite ca i
Windows-ul
- Nu ofer aceai profunzime de monitorizare i control la nivel de
nteprindere

NECLASIFICAT

din
NECLASIFICAT

Capitolul VI . Implementare practic i simulri

Pentru partea practic s-a creat o reea n programul Graphical Network


Simulator 3 (GNS3) n care s-au analizat i implementat cteva din metodele de
monitorizare existente i prezentate de-a lungul lucrrii. Din paleta de softuri
pentru monitorizare s-a ales programul Cacti. Acesta este instalat pe una dintre
mainile virtuale din cadrul reelei, rulnd pe un sistem de operare Ubuntu 16.04
LTS. Softul a fost ales deoarece este un soft gratuit i usor de utilizat i cu ajutorul
lui s-a reuit evidenierea scenariilor propuse.

6.1 Componentele si prezentarea general a reelei locale din GNS3

n figura 6.1.1 este ilustrat topologia reelei create i pe care se execut


toat analiza propus. n cadrul acestei reele s-au folosit urmatoarele
componente:

- 2x Routere c3745 (IOS Router)


- 2x Ethernet Switch-uri
- 8x Maini virtuale : - 4x Windows Xp
- 4x Ubuntu 16.04 LTS (Cacti, File Server, Web
Server, Ostinato 0.8-1 )

NECLASIFICAT

din
NECLASIFICAT

SW 1
PC 1
Internet

R1 R2 SW 3
PC 2

SW 2 PC 3

PC 4

File Web Ostinato


Cacti
Server Server 0.8-1
Fig. 6.1.1 Schema de analiz practic din GNS3

n partea stng a figurii 6.1.1 se poate observa routerul R1 avnd


asignat pe interfaa FastEthernet 0/0 adresa 10.0.0.2 cu masca
255.255.255.252 , iar pe interfaa FastEthernet 0/1 adresa 192.168.10.1 cu
masca 255.255.255.0. Pe interfaa FastEthernet 1/0 are asignat n mod
automat o adres de ctre serverul DHCP. Pe aceeai interfa ntreaga reea
va iei ctre Internet. n reeaua 192.168.10.0 exist maina virtual
CactiServer, care are instalat pe aceasta softul de monitorizare ales (Cacti).
n cadrul aceleiai reele exist i serverul de web i serverul de fiiere, dar
i generatorul de trafic (Ostinato 0.8-1). Toate aceste maini virtuale au ip-
uri asignate n mod static.
n partea dreapt a figurii exist routerul R2 care are asignat pe
interfaa FastEthernet 0/0 adresa 10.0.0.1 cu masca 255.255.255.252, iar pe
interfata FastEthernet 0/1 are ca adres 172.16.0.1 cu masca 255.255.255.0.
n cadrul reelei 172.16.0.0 /24 exist patru maini virtuale ce prezint pe
acestea ca sistem de operare Windows Xp, ele avnd rolul de ageni SNMP.
Managerul SNMP n cazul reelei l reprezint softul de monitorizare Cacti
ce este instalat pe maina virtual CactiServer

6.2 Configurare echipamente

Pentru a pune n aplicare una din metodele de monitorizare i anume


folosirea protocolului SNMP , att pe routerul 1, ct i pe routerul 2 au fost
configurate urmtoarele setri:

R1#show running-config
NECLASIFICAT

din
NECLASIFICAT

Building configuration...

Current configuration : 5467 bytes


!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname R1
!
boot-start-marker
boot-end-marker
!

no aaa new-model
memory-size iomem 5
no ip icmp rate-limit unreachable
ip cef
!

ip name-server 192.168.1.1
interface FastEthernet0/0
ip address 10.0.0.2 255.255.255.252
ip nat inside
ip virtual-reassembly
duplex auto
speed auto
!
interface Serial0/0
no ip address
shutdown
clock rate 2000000
!
interface FastEthernet0/1
ip address 192.168.10.1 255.255.255.0
ip nat inside
ip virtual-reassembly
duplex auto
speed auto
interface FastEthernet1/0
ip address dhcp
ip nat outside
ip virtual-reassembly
duplex auto
speed auto
!
router rip
redistribute static
network 10.0.0.0
NECLASIFICAT

din
NECLASIFICAT

network 192.168.1.0
network 192.168.10.0
no auto-summary
!
ip forward-protocol nd
ip route 0.0.0.0 0.0.0.0 192.168.1.1
ip route 0.0.0.0 0.0.0.0 192.168.100.1
!
ip dns server
!
no ip http server
no ip http secure-server
ip nat pool adrese 192.168.1.30 192.168.1.40 netmask 255.255.255.0
ip nat inside source list 1 pool adrese overload
ip access-list standard Monitorizare
ip access-list standard SNMP_ACL
permit 10.0.0.2
permit 10.0.0.1
permit 192.168.10.2
permit 192.168.10.3
permit 192.168.10.1
permit 192.168.10.4
permit 192.168.10.5
permit 172.16.0.4
permit 172.16.0.5
permit 172.16.0.1
permit 172.16.0.2
permit 172.16.0.3
!
access-list 1 permit 192.168.10.0 0.0.0.255
access-list 1 permit 10.0.0.0 0.0.0.252
access-list 1 permit 172.16.0.0 0.0.0.255
snmp-server community Monitorizare RO
snmp-server community public RO Monitorizare
snmp-server location RO
snmp-server contact Radu
snmp-server enable traps snmp authentication linkdown linkup coldstart warmstart
snmp-server enable traps vrrp
snmp-server enable traps ds1
snmp-server enable traps tty
snmp-server enable traps eigrp
snmp-server enable traps xgcp
snmp-server enable traps flash insertion removal
snmp-server enable traps ds3
snmp-server enable traps envmon
snmp-server enable traps icsudsu
snmp-server enable traps isdn call-information
snmp-server enable traps isdn layer2
snmp-server enable traps isdn chan-not-avail
snmp-server enable traps isdn ietf
NECLASIFICAT

din
NECLASIFICAT

snmp-server enable traps ds0-busyout


snmp-server enable traps ds1-loopback
snmp-server enable traps atm subif
snmp-server enable traps bgp
snmp-server enable traps bulkstat collection transfer
snmp-server enable traps cnpd
snmp-server enable traps config-copy
snmp-server enable traps config
snmp-server enable traps dial
snmp-server enable traps dsp card-status
snmp-server enable traps entity
snmp-server enable traps event-manager
snmp-server enable traps frame-relay
snmp-server enable traps frame-relay subif
snmp-server enable traps hsrp
snmp-server enable traps ipmobile
snmp-server enable traps ipmulticast
snmp-server enable traps mpls ldp
snmp-server enable traps mpls traffic-eng
snmp-server enable traps mpls vpn
snmp-server enable traps msdp
snmp-server enable traps mvpn
snmp-server enable traps ospf state-change
snmp-server enable traps ospf errors
snmp-server enable traps ospf retransmit
snmp-server enable traps ospf lsa
snmp-server enable traps ospf cisco-specific state-change nssa-trans-change
snmp-server enable traps ospf cisco-specific state-change shamlink interface-old
snmp-server enable traps ospf cisco-specific state-change shamlink neighbor
snmp-server enable traps ospf cisco-specific errors
snmp-server enable traps ospf cisco-specific retransmit
snmp-server enable traps ospf cisco-specific lsa
snmp-server enable traps pim neighbor-change rp-mapping-change invalid-pim-
message
snmp-server enable traps pppoe
snmp-server enable traps cpu threshold
snmp-server enable traps rsvp
snmp-server enable traps rtr
snmp-server enable traps syslog
snmp-server enable traps l2tun session
snmp-server enable traps vsimaster
snmp-server enable traps vtp
snmp-server enable traps isakmp policy add
snmp-server enable traps isakmp policy delete
snmp-server enable traps isakmp tunnel start
snmp-server enable traps isakmp tunnel stop
snmp-server enable traps ipsec cryptomap add
snmp-server enable traps ipsec cryptomap delete
snmp-server enable traps ipsec cryptomap attach
snmp-server enable traps ipsec cryptomap detach
NECLASIFICAT

din
NECLASIFICAT

snmp-server enable traps ipsec tunnel start


snmp-server enable traps ipsec tunnel stop
snmp-server enable traps ipsec too-many-sas
snmp-server enable traps rf
snmp-server enable traps voice poor-qov
snmp-server enable traps voice fallback
snmp-server enable traps dnis
snmp-server host 10.0.0.1 version 2c public
snmp-server host 10.0.0.2 version 2c public
snmp-server host 172.16.0.1 version 2c public
snmp-server host 172.16.0.2 version 2c public
snmp-server host 172.16.0.3 version 2c public
snmp-server host 172.16.0.4 version 2c public
snmp-server host 172.16.0.5 version 2c public
snmp-server host 192.168.10.1 version 2c public
snmp-server host 192.168.10.2 version 2c public
snmp-server host 192.168.10.3 version 2c public
snmp-server host 192.168.10.4 version 2c public
snmp-server host 192.168.10.5 version 2c public
no cdp log mismatch duplex
!
control-plane
!
line con 0
exec-timeout 0 0
privilege level 15
logging synchronous
line aux 0
exec-timeout 0 0
privilege level 15
logging synchronous
line vty 0 4
login
!
end
Pentru instalarea softului Cacti pe maina virtual (Ubuntu 16.04
LTS) trebuiesc efectuai urmtorii pai:

1. Instalare Lamp server (Apache, MySQL, PHP)

Sudo apt-get install apache2 mysql-server php5 libapache2-mod-php5

2. Instalare RRDtool

Sudo apt-get y install rrdtool

3. Instale SNMP i SNMPd

NECLASIFICAT

din
NECLASIFICAT

Sudo apt-get y install snmp snmpd

4. Instalare Cacti i Spine

Sudo apt-get y install cacti cacti-spine

n urma efecturii pasului 4 vor aprea n ordine urmtoarele mesaje:

Fig. 6.2.1 Configurare libphp-adodb

Fig. 6.2.2 Configurare Cacti - pasul 1

NECLASIFICAT

din
NECLASIFICAT

Fig. 6.2.3 Configurare Cacti - pasul 2

Fig. 6.2.4 Configurare Cacti pasul 3

nainte de a ncepe configurarea web , trebuie ca serviciul smpd s fie


pornit.

Sudo /etc/init.d/snmpd start

Acum se poate trece la partea de configurare web prin accesarea: http://ip-


server/cacti.

Fig. 6.2.5 Configurare Cacti pasul 4


NECLASIFICAT

din
NECLASIFICAT

Fig. 6.2.6 Configurare Cacti pasul 5

NECLASIFICAT

din
NECLASIFICAT

Fig. 6.2.7 Configurare Cacti pasul 6

NECLASIFICAT

din
NECLASIFICAT

Fig. 6.2.8 Configurare Cacti pasul 7

De reinut c parola i numele de utilizator by default sunt admin i admin.


Dup ce introducem numele de utilizator i parola (admin, admin) putem s
introducem noua parol n caz c dorim s o personalizm.
Generatorul de trafic (Ostinato 0.8-1) este preconfigurat de cei de la GNS3
i se poate gsi la aceast locaie:
- https://www.gns3.com/marketplace/appliances

Fig. 6.2.12 Generatorul de trafic Ostinato 0.8-1

NECLASIFICAT

din
NECLASIFICAT

6.3 Simulri i rezultate obinute

n figura 6.3.1 se pot observa echipamentele din ntreaga reea ce sunt


supuse procesului de monitorizare, cu ajutorul softului de monitorizare Cacti. n
interfaa grafic a programului sunt afiate anumite detalii (ID, Graphs, Data
Sources, Status, Hostname, Current(ms), Average(ms), Availability) n funcie de
care softul ine cont pentru a realiza o bun analiz asupra echipamentelor.

Fig. 6.3.1 Seciunea Devices din Cacti

Un prim scenariu este acela de a folosi generatorul de trafic Ostinato pentru


a trimite o cantitate destul de mare de date pe interfaa routerului R1 (Fa0/0). n
figura 6.3.2 este afiat traficul pe interfaa Fa0/0 a routerului fr a genera vreun
trafic suplimentar voit.

Fig. 6.3.2 Trafic pe interfaa Fa0/0 a routerului R1 fr generare de trafic


suplimentar
NECLASIFICAT

din
NECLASIFICAT

Pentru primul pas, cu ajutorul generatorului se vor trimite ctre adresa


192.168.10.1, 200 de pachete de tip TCP , cu o rat de 2 pachete/s dup cum se
poate observa n figura 6.3.3.

Fig. 6.3.3 Generare pachete de tip TCP ctre interfaa Fa0/0

Cu ajutorul utilitarului Wireshark se poate observa cum generatorul trimite


pachete ctre interfaa routerului exact dup setrile aplicate. n figura 6.3.4 se
poate observa o captur n programul Wireshark .

NECLASIFICAT

din
NECLASIFICAT

Fig. 6.3.4 Captur de date n Wireshark pe interfaa Fa0/0

Dup 30 minute n care traficul a fost generat, iar softul i-a updatat baza
MySQL, se poate observa o cretere a traficului pe interfaa specificat, ceea ce
ne arat c protocolul SNMP configurat pe interfaa routerului este o metoda de
success pentru a putea monitoriza echipamentul n sine. n figura 6.3.5 este afiat
traficul pe interfaa Fa0/0 dup ce traficul suplimentar a fost generat.

Fig. 6.3.5 Trafic pe interfaa Fa0/0 a routerului R1 cu generare de trafic


suplimentar

NECLASIFICAT

din
NECLASIFICAT

Un al doilea scenariu este acela de a monitoriza reeaua cu parametrii iniiali


n interval de 24 de ore. Dup ce au trecut cele 24 de ore s-a putut vedea c reeaua
a rulat n mod normal, fr alte intervenii personale ca n cazul precedent de a
crea trafic suplimentar cu ajutorul generatorului de trafic. Prin acest scenariu s-a
dorit observarea modului cum toi agenii SNMP trimit ctre manager date, ct
de multe date i la ce interval de timp.

Fig. 6.3.6 Statistici pentru Serverul de fiiere (24 h)

Fig. 6.3.7 Statistici pentru cele 4 pc-uri (Win. Xp) (24h)

NECLASIFICAT

din
NECLASIFICAT

Fig. 6.3.8 Traficul pe cele 2 routere i pe serverul web (24h)

NECLASIFICAT

din
NECLASIFICAT

Capitolul VII .Concluzii i perspective

Creterea numrului de dispozitive, dar i a dimensiunii reelelor necesit


o administrare eficient, implicnd o documentare mai detaliat i cernd noiuni
de baz pentru proiectarea managementului de reea.
n ultimii ani infrastructura reelelor este ndreptat ctre reelele ce prezint
servicii centralizate. De aceea obiectivele propuse de OSI pentru administrarea
reelei i ariile funcionale s-au completat cu cerine suplimentare de management,
similare cu serviciile oferite n prezent i anume: servicii difereniale, mai rapide
i mai facile, personalizate, flexibile.
Indiferent de modelul ales pentru monitorizarea reelei, administratorul de
reea trebuie s cunoasc foarte bine funcionarea n totalitate a reelei att din
punct de vedere fizic, logic, informaional, ct i factorii care o influeneaz pentru
a o putea administra n mod optim. Un sistem de monitorizare bine optimizat este
esenial pentru reeaua de comunicaii deoarece acesta ii permite administratorului
de reea s examineze complet fluxul de date i s identifice zonele cu probleme
pn la nivelul de pachete, folosind o interfa grafic, foarte uor de folosit i
interpretat. De exemplu, n cadrul unei monitorizri de tip VoIP se pune accent
pe datele cu care protocoalele VoIP lucreaz n acel moment, pe aspectul QoS
care prezint date de o importan mai mare fa de cele care nu se execut n timp
real.
n zilele noastre este mult mai uor s monitorizezi anumite echipamente ,
deoarece dac nainte ca administrator de reea trebuia sa fii 24/24 prezent lng
staia pe care se afla sistemul de monitorizare, acum monitorizarea se execut la
un nivel ridicat i eficient i nu necesit prezena administratorului. Datele pot fi
stocate n anumite log-uri i pot fi analizate dup aceea. Cu ajutorul sistemului de
monitorizare putem determina toate informaiile legate de ceea ce se ntmpl la
intrarea i la ieirea unui router din partea clientului. Acest lucru permite
furnizorului de servicii s monitorizeze reeaua cu un pas nainte i s execute o
monitorizare efectiv a traficului i a serviciilor oferite. Un sistem de monitorizare
fie el soft sau hard, bine optimizat, poate permite de asemenea vizualizarea i
raportarea coninutului i istoricului de date stocate, statistici de performan i
poate monitoriza starea de sntate a reelei n funcie de locaie sau de client.
Un sistem de monitorizare bine configurat trebuie s ntiineze ct mai
rapid, n cazul n care apar probleme legate de reea sau/i de serviciile
prestate.Exist multe astfel de sisteme, fiecare avnd att avantaje ct i
dezavantaje. Pentru a identifica un sistem de monitorizare optimal trebuie s
testezi foarte multe dintre ele i s te gndeti ce date i ce servicii doreti s
monitorizezi.
ntr-o reea local, n funcie de structura acesteia, se poate captura traficul
din toat reeaua sau doar traficul destinat calculatorului pe care s-a instalat
software-ul de monitorizare. De exemplu, ntr-o reea de tip Ethernet care
folosete switchuri, este posibil ocolirea n scopuri ru intenionate a filtrrii
NECLASIFICAT

din
NECLASIFICAT

de pachete pe care switchurile o pun n practic i accesarea traficului destinat


altor staii de reea. Capturarea traficului ntregii reele poate servi ns i unor
scopuri de administrare, deoarece ea furnizeaz o imagine de ansamblu asupra
reelei n cauz.De exemplu, o tehnic folosit n acest scop este configurarea pe
un switch a unui port special denumit port de mirroring, care va oglindi toate
pachetele ce trec prin toate porturile switchului.
n reelele care folosesc switchuri n detrimentul huburilor, analizorul de
reea va fi incapabil s capteze datele de reea, datorit naturii intrisece a
switchurilor (a izolrii pe care ele o introduc). Att n reelele cablate ct i cele
fr fir, pentru ca analizorul de reea s fie capabil s captureze i pachete de date
care nu i sunt explicit dedicate (n aceast categorie intrnd pachete unicast sau
de difuzare n LANul din care respectiva staie face parte) , adaptorul de reea
trebuie setat ntr-un mod de operare special, care de obicei se numete
promiscuous mode. Este de notat c nu orice analizor de reea suport acest mod
de operare.
n reelele fr fir, chiar dac este posibil setarea plcii de reea wireless
n modul promiscous, pachetele care nu corespund setului de servicii pentru care
adaptorul este configurat vor fi de obicei ignorate. Pentru a putea vizualiza i
aceste pachete este nevoie de setarea unui alt mod de operare i anume acela de
monitorizare a reelei.
Este foarte important ca cei care au grij de reea i de serviciile care sunt
monitorizate sa fie informai periodic, de preferat cat mai repede, pentru ca acetia
s poat lua msurile potrivite situaiei.

n orice reea pachetul reprezint ultima surs ctre aflarea adevrului, deci
o soluie de gestionare a reelei trebuie s furnizeze abilitatea de ptrunde n
detaliu n reea pentru a surprinde i analiza aceste pachete. Fluxul de date este de
asemenea critic pentru nelegerea comportamentului reelei i ofer o vizibilitate
de ansamblu destul de bun la nivel end-to-end.
Analizele comportamentale avansate examineaz ceea ce este normal
pentru reea i avertizeaz dac apar modificri. Metricile aplicaiilor i ale reelei
(cum ar fi timpul de rspuns, viteza de transfer, rata de conectare) sunt msurate
i urmrite n timp pentru a dezvolta o linie de referin a ceea ce este tipic.
Construirea i actualizarea msurtorilor care compun aceast linie de referin
permit o soluie de tip NPM cu analize pentru a cunoate diferena dintre
activitatea tipic a reelei i o schimbare brusc a activitii care poate indica o
problem.

NECLASIFICAT

din
NECLASIFICAT

Bibliografie
[1] Combining active and passive network measurements to build scalable
monitoring systems on the grid. ACM Sigmetrics Performance Evaluation
Review (2003).
[3] https://tools.ietf.org/html/rfc896
[5] S. Savage. Sting: a TCP-based Network Measurement Tool. USENIX
Symposium on Internet Technologies and Systems (1999).
[6] Scriptroute Network Measurement. www.scriptroute.org
[7] Windows XP Pathping.
www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/cnet/cnbd_trb
_vxmb.mspx
[8] https://slideplayer.com/slide/6409901/
[9] https://ro.wikipedia.org/wiki/Sistem_de_detectare_a_intruziunilor
[10] https://ro.wikipedia.org/wiki/Sistem_de_detectare_a_intruziunilor
[11] https://ro.wikipedia.org/wiki/Paravan_(software)
[13] https://www.drupal.org/files/images/rrdtool.png
[14] https://en.wikipedia.org/wiki/Zabbix
[15] https://www.monitis.com/blog/11-top-server-management-monitoring-
software/

NECLASIFICAT

din