Centralizarea managementului și securizarea sistemelor de operare [623582]

Universitatea “Politehnica” din București
Facultatea de Electronică, Telecomunicații și Tehnologia Informației

Centralizarea managementului și securizarea sistemelor de operare
Linux

Proiect de diplomă
prezentat ca cerință parțială pentru obținerea titlului de
Inginer în domeniul Electronică și Telecomunicații
programul de studii de licență Rețele și Software de Telecomunicații

Conducător științific Absolvent
Ș.l. Dr. Ing. Marius VOCHIN Gabriel NICOLAE

2016

Cuprins

Lista figurilor ………………………….. ………………………….. ………………………….. ………………………….. ………… 9
Lista tabelelor ………………………….. ………………………….. ………………………….. ………………………….. ………. 11
Listă de acr onime ………………………….. ………………………….. ………………………….. ………………………….. …. 13
Introducere ………………………….. ………………………….. ………………………….. ………………………….. ………….. 15
Capitolul 1 Managementul și securizarea sistemelor de operare Linux ………………………….. ………….. 17
1.1 Managementul centralizat ………………………….. ………………………….. ………………………….. …………. 17
1.2 Configurarea și administrarea sistemelor distribuite ………………………….. ………………………….. …. 18
1.3 Instrumentele de management al configurației ………………………….. ………………………….. …………. 19
1.3.1 Proprietăți de configurație ………………………….. ………………………….. ………………………….. …… 20
1.3.1.1 Modelul de specificații ………………………….. ………………………….. ………………………….. …….. 21
1.3.1.2 Mecanisme de abstracție ………………………….. ………………………….. ………………………….. ….. 21
1.3.1.3 Mecanisme de modularizare ………………………….. ………………………….. …………………………. 22
1.3.2 Proprietățile implementării ………………………….. ………………………….. ………………………….. …. 23
1.3.2.1 Scalabilitatea ………………………….. ………………………….. ………………………….. ………………….. 23
1.3.2.2 Actualizarea configurației ………………………….. ………………………….. ………………………….. … 23
1.3.2.3 Arhitectura implementării ………………………….. ………………………….. ………………………….. … 23
1.3.2.4 Platforme suportate ………………………….. ………………………….. ………………………….. …………. 24
1.3.3 Proprietăți de management al configurației ………………………….. ………………………….. ……….. 24
1.3.3.1 Utilizabilitatea ………………………….. ………………………….. ………………………….. ………………… 24
1.3.3.2 Evidența versiunii ………………………….. ………………………….. ………………………….. …………… 24
1.3.3.3 Integrarea cu alte rețele ………………………….. ………………………….. ………………………….. ……. 24
1.3.3.4 Controlul accesului ………………………….. ………………………….. ………………………….. …………. 25
1.4 Beneficiile utilizării unui instrument de management al configurației ………………………….. ……… 25
1.5 Comparație între intrumente de management al configurației ………………………….. …………………. 25
1.5.1 Proprietăți de configurare ………………………….. ………………………….. ………………………….. …… 26
1.5.2 Proprietățile implementării ………………………….. ………………………….. ………………………….. …. 26
1.5.3 Proprietăți de management al configurației ………………………….. ………………………….. ……….. 27
1.6 Securitatea ………………………….. ………………………….. ………………………….. ………………………….. ….. 28
1.6.1 Politica paravanelor de protecție ………………………….. ………………………….. ………………………. 29
1.6.2 Clasificări ………………………….. ………………………….. ………………………….. …………………………. 29
1.6.3 Serverul proxy ………………………….. ………………………….. ………………………….. …………………… 30
Capitolul 2 Instrumentul de management al configurației Puppet ………………………….. …………………….. 31
2.1 Descriere ………………………….. ………………………….. ………………………….. ………………………….. ……. 31
2.2 Arhitectur a ………………………….. ………………………….. ………………………….. ………………………….. …. 32

2.3 Securitatea și comunicația ………………………….. ………………………….. ………………………….. …………. 34
2.3.1 Criptografia cu cheie publică ………………………….. ………………………….. ………………………….. . 34
2.3.2 Infrastructuri cu cheie publică ………………………….. ………………………….. …………………………. 35
2.3.3 Certificate ………………………….. ………………………….. ………………………….. …………………………. 35
2.3.4 TLS/SSL ………………………….. ………………………….. ………………………….. ………………………….. 36
2.3.5 HTTPS (Hyper Text Transfer Protocol Secure) ………………………….. ………………………….. …. 37
Capitolul 3 Implementarea și validarea funcțională ………………………….. ………………………….. …………… 39
3.1 Implementarea ………………………….. ………………………….. ………………………….. …………………………. 39
3.2 Configurarea ………………………….. ………………………….. ………………………….. ………………………….. . 42
3.3 Validarea funcțională ………………………….. ………………………….. ………………………….. ……………….. 47
3.4 Analiza performanțelor ………………………….. ………………………….. ………………………….. …………….. 51
Concluzii ………………………….. ………………………….. ………………………….. ………………………….. …………….. 57
Bibliografie ………………………….. ………………………….. ………………………….. ………………………….. …………. 59

Lista figurilor

Figura 1.1 Sarcina de bază a unui sistem centralizat de management ………………………….. ……………….. 18
Figura 1.2 Arhitectura de referință a intrumentelor de management al configurației ……………………….. 20
Figura 1.3 Nivelele de abstracție ale instrumentelor de management ………………………….. ……………….. 22
Figura 1.4 Modul de lucru al unui paravan de protecție ………………………….. ………………………….. ……… 29
Figura 2.1 Architectura Puppet de tip client -server ………………………….. ………………………….. ……………. 32
Figura 2.2 Fluxul de lucru al instrumentului Puppet ………………………….. ………………………….. ………….. 33
Figura 2.3 Ilustrarea fluxului de lucru dintre procesele și componentele instrumentului Puppet ………. 34
Figura 2.4 Conexiunea client -server prin SSL proxy ………………………….. ………………………….. …………. 37
Figura 3.1 Toplogia rețelei client -server ………………………….. ………………………….. ………………………….. . 39
Figura 3.2 Activarea depozitului Puppet pentru distribuția Ubu ntu ………………………….. ………………….. 40
Figura 3.3 Activarea depozitului Puppet pentru distribuția Fedora ………………………….. …………………… 40
Figura 3.4 Fișierul puppet.conf al serverului Puppet ………………………….. ………………………….. ………….. 41
Figura 3.5 Fișierul puppet.conf al unui nod ………………………….. ………………………….. ………………………. 41
Figura 3.6 Testarea conexiunii nod -server ………………………….. ………………………….. ………………………… 41
Figura 3.7 Codul resursei definite accounts::create_accounts ………………………….. ………………………….. 42
Figura 3.8 Generarea cheilor SSH ………………………….. ………………………….. ………………………….. ………. 43
Figura 3.9 Cheia publică SSH ………………………….. ………………………….. ………………………….. …………….. 43
Figura 3.10 Crearea contului de utilizator ………………………….. ………………………….. ………………………… 44
Figura 3.11 Codul subclasei accounts::groups ………………………….. ………………………….. ………………….. 44
Figura 3.12 Codul subclasei accounts::os_vars ………………………….. ………………………….. …………………. 44
Figura 3.13 Codul clasei sshd ………………………….. ………………………….. ………………………….. …………….. 45
Figura 3.14 Clasa firewall::pre ………………………….. ………………………….. ………………………….. …………… 46
Figura 3.15 Clasa firewall::post ………………………….. ………………………….. ………………………….. ………….. 47
Figura 3.16 Modelul de stare al nodului node4.puppet.com ………………………….. ………………………….. … 48
Figura 3.17 Cererea de semnare a certificatului (CSR) ………………………….. ………………………….. ………. 48
Figura 3.18 Listă certificate ………………………….. ………………………….. ………………………….. ……………….. 49
Figura 3.19 Semnare certificat ………………………….. ………………………….. ………………………….. ……………. 49
Figura 3.20 Inițierea procesului de implementare a configurației ………………………….. …………………….. 49
Figura 3.21 Aplicarea catalogului ………………………….. ………………………….. ………………………….. ……….. 50
Figura 3.22 Terminarea procesului de implementare a configurației ………………………….. ………………… 50
Figur a 3.23 Fșierul /etc/passwd ………………………….. ………………………….. ………………………….. ………….. 50
Figura 3.24 Directoare useri ………………………….. ………………………….. ………………………….. ………………. 50
Figura 3.25 Grupuri de useri ………………………….. ………………………….. ………………………….. ………………. 51
Figura 3.26 Tabelă reguli firewall ………………………….. ………………………….. ………………………….. ………. 51
Figura 3.27 Scenariul 1 Utilizare CPU ………………………….. ………………………….. ………………………….. … 52
Figura 3.28 Scenariul 1 Memorie sistem ………………………….. ………………………….. ………………………….. 52
Figura 3.29 Scenariul 2 Utilizare CPU ………………………….. ………………………….. ………………………….. … 53
Figura 3.30 Scenariul 2 Memorie sistem ………………………….. ………………………….. ………………………….. 53
Figura 3.31 Scenariul 3 Utilizare CPU ………………………….. ………………………….. ………………………….. … 54
Figura 3.32 Scenariul 3 Memorie sistem ………………………….. ………………………….. ………………………….. 54

Lista tabelelor

Tabel 1.1 Comparație între instrumentele de management al configurației…………………………………….. 23

Listă de acronime

ADSL Asymmetric Digital Subscriber Line Linie de abonat digitală asimetrică
API Application Program Interface Interfață de programare a aplicațiilor
CA Certificate Authority Unitatea de certificare
CD Compact Disc
CRL Certificate Revocation List Lista certificatelor revocate
CSRs Certificate Signing Requests Cereri de semnare a certificatului
DHCP Dynamic Host Configuration Protocol Protocol de configurare dinamică a host –
urilor
DNS Domain Name System Sistem de nume de domeniu
DSL Domain Specific Language Limbaj specific sistemului
ENC External Node Classifier Clasificator de noduri extern
GUI Graphical User Interface Interfață grafică
HTTP Hypertext Transfer Protocol
HTTPS Hyper Text Transfer Protocol Secure
IP Internet Protocol Protocolul Internet
ISDN Integrated Services Digital Network Rețea de servicii digitale integrate
MAC Media Access Control Controlul accesului la mediu
OSI Open Systems Interconnection Interconectarea sistemelor deschise
PKI Public Key Infrastructure Infrastructura cu cheie pub lică
SMTP Simple Mail Transfer Protocol Protocolul de transfer al corespondenței
SSH Secure Shell
SSL Secure Socket Layer
TCP Transmission Control Protocol Protocol de control al transmisiei
TLS Transport Layer Security Securitatea nivelului transport
UDP User Datagram Protocol
XML Extensible Markup Language Limbaj extensibil de marcare

15
Introducere

Munca administratorilor de sistem și în general a angajaților din domeniu IT, se rezumă la
efectuarea unor sarcini repetitive, precum configurarea mașinilor gazdă, crearea userilor, gestionarea
aplicațiilor și a serviciilor. De obicei, aceste sarcini se repetă de foarte multe ori de -a lungul perioadei
de viață a unei mașini prin adăug area de noi configurații, remedierea erorilor apărute sau dezvoltarea
ei. Toate aceste sarcini conduc la utilizarea ineficientă a timpului.
Răspunsul obișnuit la aceaste sarcini repetitive, care necesită timp pentru a fi duse la bun sfârșit,
ar fi automat izarea lor. Acest lucru conduce la dezvoltarea unor scripturi sau aplicații, dar nu este o
soluție eficientă datorită varietății sistemelor de operare din cadrul unei infrastructuri, fiind necesar câte
un script pentru fiecare. De asemenea, o astfel de sol uție nu este scalabilă. Pe măsură ce adăugăm noi
funcționalități sistemului, scripturile devin mai complexe și mai greu de coordonat. Astfel, apare
nevoia unui sistem centralizat de management. Aici intervin instrumentele de management al
configurației ca re va aduce mașinile din infrastructură la starea pe care noi am descris -o printr -un
limbaj declarativ.
Primul capitol descrie aspectele generale ale managementului centralizat și ale securității
sistemelor, dar prezintă și caracteristicile ce trebuie avu te în vederea alegerii unui instrument de
management al configurației.
Capitolul 2 prezintă instrumentul Puppet, arhitectura lui, principiul de funcționare și securitatea
comunicației între entitățile aflate sub gestionarea sa.
În ultimul capitol sunt pr ezentate realizarea conexiunii client -server Puppet și diferite
configurații pentru o rețea compusă din mașini pe care am instalat distribuții Linux, realizată folosind
programul sursă deschisă Oracle VM VirtualBox. De asemenea, am realizat măsurători de p erformanță
pentru a pune în evidență scalabilitatea instrumentului de management al configurației Puppet.

16

17
Capitolul 1 Managementul și securizarea sistemelor de
operare Linux

1.1 Managementul centralizat

Managementul centralizat este un proces tehnologic ce presupune stabilirea și menținerea
consecventă a performanței, a funcționalității și a atributelor fizice ale unui produs cu cerințele sale, cu
proiectarea și cu informațiile operaționale pe durata întregii vieți. Acesta este f olosit în domeniul
ingineriei civile, ingineriei industriale și militar.[1] În domeniul IT, sunt doua tipuri de management
centralizat: software și de sistem.
Centralizarea software a managementului este utilizată în proiectele software pentru a gestiona
și a urmări modificările aplicațiilor. Aceasta permite dezvoltatorilor să se asigure că în cele din urmă
software -ul livrat satisface toate cerințele. Sistemul centralizat de management permite utilizatorului
implementarea, monitorizarea și menținerea servi ciilor pe un server. Acesta poate fi hardware, software
sau ambele. Atunci când este instalat un nou software sau o nouă piesă hardware, este nevoie de o
anumită configurație, ceea ce înseamnă că anumite valori și anumiți parametrii trebuiesc adăugați sau
modificați.
Mai jos sunt prezentate problemele cele mai des întâlnite în administrarea configurației unei
rețele:

 Incepe cu:

– un număr mare de mașini neconfigurate
– un spațiu de stocare ce conține toate pachetele software și fișierele de date
necesare
– planul și arhitectura funcțiilor pe baza cărora să funcționeze sistemul

 Instalarea software -ului necesar și configurarea mașinilor conform planului de funcționare,
lucru pe care, în general, îl face infrastructura internă, de exemplu: serviciul DNS ( Domai n
Name System )[2], serviciul DHCP ( Dynamic Host Configuration Protocol )[3] etc.

 Reconfigurarea mașinilor atunci când specificațiile serviciilor diferă sau se schimbă

 Reconfigurarea mașinilor ori de câte ori apar schimbări în rețea și acestea trebuiesc menținute
în conformitate cu specificațiile

Câteva din sarcinile unui sistem centralizat de management sunt prezentate în figura 1.1

În general, configurarea unei mașini presupune editarea fișierelor de configurare sau furnizarea
informațiilor solicita te folosind interfețe destinate programării aplicațiilor, API ( Application Program
Interface ), sau interfața grafică, GUI ( Graphical User Interface ). Pentru a configura toate mașinile și
sistemele din rețea conform planului și specificațiilor acesteia, est e necesară alegerea unei configurații
corespunzatoare pentru fiecare, ceea ce din punct de vedere practic, pentru un administrator de sistem

18
este foarte dificil să facă acest lucru manual. Aici intervin instrumentele de management al
configurației.[4]

Figura 1.1 Sarcina de bază a unui sistem centralizat de man agement [5]

1.2 Configurarea și administrarea sistemelor distribuite

În cazul întreprinderilor, acestea utilizează fie aplicații software proprii, fie aplic ații
achizitionate de la terți. Aceste aplicații sunt apoi implementate, configurate și gestionate de către
administratorii de sistem. Acest proces este alcatuit din urmatoarele sarcini:

 Implementarea aplicațiilor prin instalarea tuturor fișierelor sale î n locațiile definite de către
dezvoltatori și furnizorul sistemului de operare Linux, dar și instalarea dependențelor. Pe
majoritatea sistemelor de operare Linux acest proces este gestionat în mod automat de către
instrumentele de management al pachetelor.

19
 Configurarea aplicațiilor prin setarea parametrilor săi de configurare cu valorile dorite. Acestea
sunt determinate de către administratorul de sistem în funcție de mediul și de modul în care va
fi utilizată aplicația. Valorile parametrilor sunt scrise în fișierele de configurare.

 Instalarea update -urilor în timpul rulării, acestea incluzând fixarea erorilor, adăugarea de noi
specificații sau îmbunătățirea securității, și dezvoltarea parametrilor de configurare pentru a
modifica modul în care aplicația fu ncționează.

Configurarea unei mașini presupune selectarea și instalarea de aplicații software, precum și
setarea parametrilor de configurare ai acestora și ai sistemului de operare. Prin intermediul
parametrilor, administratorul de sistem poate adapta funcționalitatea aplicației software în funcție de
sistemul de operare pe care a fost instalată. O aplicație are un format predefinit al valorilor
parametrilor, iar dacă acesta este corect, parametrul va fi scris în fișierul de configurare. Cu toate
aceste a, administratorul de sistem poate determina doar o parte din acești parametrii, restul fiind fie un
duplicat al unui alt parametru de configurare, fie este determinat în mod automat de sistemul de
operare. Atunci când valoarea unui parametru se schimbă es te necesar să se asigure că toți parametrii
dependenți sunt actualizați pentru a nu afecta funcționalitatea aplicației, a sistemului de operare sau a
echipamentelor de rețea și stocare.
Un sistem software distribuit este un sistem ale cărui componente sun t implementate pe
multiple mașini interconectate în rețea care comunică și se coordonează prin transfer de mesaje. O
astfel de distribuție creează interdependențe între parametrii de configurare, deoarece toate
componentele distribuite trebuie să funcțione ze ca un singur sistem, prin urmare, toți parametrii trebuie
să fie actualizați.
Activitatea de gestionare a sistemelor distribuite de mari dimensiuni poate fi obositoare și
repetitivă, întrucât operații și modificări similare trebuie să fie efectuate pe multiple mașini.
Administratorii de sistem au încercat să își automatizeze munca prin crearea de script -uri, controlând
astfel anumite aspecte ale configurației, gestionarea mașinilor și a software -ului care rulează pe ele
(sistem de operare și aplicații) . De obicei, script -urile sunt create pentru mediile în care sunt rulate și nu
sunt scalabile.[6]

1.3 Instrumentele de management al configurației

Instrumentele de management al configurației sunt servicii utilizate de administratorii de sistem
pentru a implementa, administra, supraveghea și menține elementele de configurare ale unui sistem.
Acestea oferă diverse tipuri de automatizare și modele de reprezentare, dar scopul lor este unul comun,
acela de a -l asista pe administrator în procesul de configu rare a sistemului.
Instrumentele de management al configurației oferă o abordare mai structurată în ceea ce
privește automatizarea administrării sistemelor. Ac este instrumente au o gamă largă de capabilități de
automatizare și de captare, precum distribuir ea, programarea și execuția unor script -uri personalizate și
generarea unor rapoarte de execuție. De asemenea, instrumentele de management al configurației oferă
modelul de configurație dorită sistemului/infrastructurii gestionate. Fiecare dintre aceste in strumente au
o arhitectură similară.
În figura 1.2, este prezentată o diagramă simplificată a arhitecturii intrumentelor de
management al configurației. Datele de intrare care descriu configurația dorită a sistemului distribuit
gestionat sunt preluate dint r-un spațiu de stocare. Unul sau mai mulți agenți de translație generează

20
modelul de configurație dorit pentru fiecare resursă a diferitelor mașinini gestionate. Un agent de
implementare aflat pe fiecare mașină preia modelul de configurație și îl implement ează pe mașina pe
care o administrează, impunând astfel starea dorită fiecarei resurse a acesteia.[6]

Figura 1 .2 Arhitectura de referință a intrumentelor de management al configurației

Adoptarea unui instrument de management al configurației într -o infrastructură IT presupune o
investiție semnificativă de timp și bani. Înainte de a face o astfe l de investiție, o întreprindere trebuie să
se asigure că alegerea instrumentului este făcută pe baza unor criterii obiec tive. Criteriile care trebuiesc
avute în vedere se împart în patru categorii de proprietăți:
 proprietăți de configurație
 proprietați de implementare
 proprietăți de management al configurației
 suport

1.3.1 Proprietăți de configurație

Proprietățile de co nfigurație se referă la modul în care datele de intrare ale instrumentelor de
management al configurației sunt prezentate și gestionate, inclusiv mecanismele disponibile pentru a se
ocupa de complexitatea sistemului. Aceste proprietăți sunt de trei tipuri: modelul de configurație,
mecanisme de extragere și mecanisme de modularizare.

21
1.3.1.1 Modelul de specificații

Modelul de specificații reprezintă limbajul utilizat de instrumentul de management, care poate
fi declarativ sau imperativ, și interfața cu u tilizatorul, ce poate fi grafică sau linie de comandă, pentru a
defini specificațiile acestuia.
Instrumentele care folosesc un limbaj declarativ exprimă modelul de stare dorit al infrastructurii
IT, apoi este comparat cu configurația de pe fiecare mașină gestionată, iar dacă există divergențe este
inițiat procesul de trecere la starea dorită.
În ceea ce privește instrumentele ce utilizează un limbaj imperativ, acestea distribuie și
implementează script -uri, scrise de administratorii de sistem, pe mașinile gestionate. Pentru ca script –
urile să funcționeze, toate stările trebuiesc acoperite și verficate în script. De asemenea, instrumentul de
management al configurației trebuie să țină evidența script -urilor deja executate pe fiecare mașină.
Alegerea limbaj ului utilizat este urmată de alegerea interfeței cu utilizatorul. Interfețele de linie
de comandă, de obicei, prezintă o oarecare dificultate când este vorba de utilizarea lor, dar odată
stăpânite, pot conduce la o productivitate mai mare, având avantajul de a putea fi integrate cu
instrumentele de scripting, dar utilizarea unei interfețe grafice este mai rapidă.

1.3.1.2 Mecanisme de abstracție

Un instrument de management al configurației bun este în măsură să facă abstracție de
complexitatea și eteroge nitatea ce caracterizează infrastructurile IT ale căror resurse hardware și
software provenite de la diferiți furnizori sunt utilizate în mod simultan. Aceste resurse trebuie
configurate astfel încat să poată funcționa în cadrul aceleiași infrastructuri.
Instrumentele pot fi structurate pe șase nivele de abstracție, având la bază modul în care
limbajul utilizat de intrumentul de management al configurației gestioneaza complexitatea și
eterogenitatea infrastructurii. Acestea pot fi de nivel înalt, cerințe c apăt-la-capăt, până la cele de nivel
jos, la nivel de bit.
 Cerințe capăt -la-capăt: sunt cerințe de tip non -funcționale. Ele descriu caracteristicile serviciilor
pe care infrastructura IT trebuie să le ofere, precum disponibilitatea, securitatea, fiabilitatea,
ușurința în utilizare etc.
 Reguli de distribuție: sunt reguli ce specifică distribuția instanțelor în rețea. O instanță este
definită ca fiind un sistem component al infrastructurii IT ce este descris de un set de
parametrii. Exemple de inst anțe ar fi serverele web sau serverele de mail.
 Configurația instanțelor: la acest nivel, fiecare instanță este o reprezentare independentă de
implementare a unei configurații.
 Instanțe dependente de implementare: la acest nivel este specificată configuraț ia necesară
sistemului mai în detaliu. Aici sunt descrise specificațiile de configurare în ceea ce privește
conținutul fișierelor de configurare.
 Fișierele de configurare: în cadrul acestui nivel, fișierele de configurare finale sunt mapate pe
mașini. Spre deosebire de nivelul anterior, acest nivel nu cunoște conținutul unui fișier de
configurare.
 Configurații la nivel de bit: ultimul nivel prezintă maparea unor imagini de disc pe mașini. De
asemenea, nu este cunoscut conținutul acestora.

Un instrument d e management al configurației se ocupă de automatizarea implementării
specificațiilor configurațiilor. În cazul configuraților la nivel de bit, implementarea este realizată prin
copierea secvențelor de biți pe discuri, în timp ce implementarea configurații lor la nivelul capăt -la-

22
capăt este un proces mai complex. Nivele de abstracție ale instrumentelor de management al
configurației se pot observa în figura 1.3.

Figura 1 .3Nivelele de abstracție ale instrumentelor de management

1.3.1.3 Mecanisme de modularizare

Unul dintre principalele motive pentru care administratorii de sistem automatizează
configurarea mașinilor este evitarea sarcinilor repetitive în vederea eficientizării muncii lor. Mai mult
decât atât, sarci nile repetitive cresc șansele de apariție a erorilor. Sarcinile repetitive sunt prezente în
infrastructurile IT deoarece sunt multe părți ale configurației pe mai multe mașini. Un instrument de
management al configurației care permite scrierea configurație i în module reduce riscul apariției
erorilor.
În forma sa cea mai de bază, modularizarea se realizează printr -un mecanism de grupare: o
mașină A este declarată a fi membră a grupului X și ca o consecință moștenește toate părțile de
configurare a sistemulu i asociat cu X. Mecanismele mai avansate includ grupuri bazate pe interogare,
definirea automată a grupurilor pe baza datelor de mediu ale mașinii țintă și a grupurilor ierarhice.
O altă proprietate a mecanismelor de modularizare este dacă permite părtilo r terțe să aibă o
contribuție parțială la specificațiile configuraților. Părțile terțe pot fi furnizorii de componente hardware
și software sau firme de consultanță. Administratorii de sistem apoi pot modela infrastructura în funcție
de abstracțiile furniz ate de modulele părților terțe.

23
1.3.2 Proprietățile implementării

Specificațiile configurației ar trebui să conducă la modele de stare sau script -uri care sunt
implementate pe sisteme. Aceste proprietăți sunt divizate în patru categorii: scalabilitate, actualizarea
fluxului de lucru, arhitectura implementării și platformele suportate.

1.3.2.1 Scalabilitatea

Infrastructurile mari sunt supuse constant unor schimbări în configurația lor. Instrumentele de
management al configurației trebuie să se ocupe de aceste schimbări și să fie în măsură să pună în
aplicare rapid noile modificări, chiar și pentru infrastructuri de mari dimensiuni. De obicei, pentru
infrastructurile de mari dimensiuni este mai benefică utilizarea unor specificații de conf igurare de nivel
înalt, dar asta implică necesitatea unei puteri mai mari de procesare.

1.3.2.2 Actualizarea configurației

Managementul actualizării configurației se ocupă de planificarea și execuția modificărilor.
Modificările pot duce la afectarea se rviciilor prezente pe mai multe mașini și dependente de alte
servicii.
Un aspect al managementului actualizării configurației este starea de transfer. Comportamentul
unui serviciu este dat atât de specificațiile configurației, cât și de datele pe care le utilizează. Atunci
când un serviciu este actualizat sau transferat pe o alta mașină , instrumentul de management al
configurației trebuie să se asigure că starea acestuia rămâne aceeași în ciuda modificărilor apărute.
Un alt aspect al managementului actua lizării este coordonarea modificărilor distribuite. Acest
lucru necesită o atenție sporită pentru a nu afecta procesele din cadrul infrastructurii IT. O modificare
care afectează mai multe mașini și servicii trebuie să fie executată ca o singură operație.

1.3.2.3 Arhitectura implementării

Implementarea tipică unui instrument de management al configurației este ilustrată în figura
1.2. Un instrument de management al configurației pornește de la o specificație centrală pentru toate
dispozitivele gestionate . În continuare, acesta procesează această specificație în modele de stare pentru
dispozitive și distribuie aceste modele de stare sau specificația completă pentru fiecare dispozitiv
gestionat. Un agent care rulează pe dispozitiv impune apoi modelul de sta re dispozitivului.
Instrumentele de management al configurației își diferențiază arhitectura de implementare în
funcție de două proprietăți: arhitectura cu agent de translație și arhitectura cu agent de translație care
utilizează mecanisme de "tragere" sa u "împingere".
Procedurile posibile pentru arhitectura cu agent de translație pot fi clasificate în funcție de
numărul de agenți de translație în comparație cu numărul de mașini gestionate. Una din proceduri este
managementul centralizat în care avem un s erver central și un singur agent de translație, situație în
care, într -o rețea mare, serverul este foarte solicitat, iar performanțele acestuia au de suferit. O altă
procedură este managementul slab distribuit ce presupune prezența mai multor agenți de tra nslație în
rețea și organizarea ierarhică a acestora. O a treia procedură este managementul distribuit în care
fiecare mașină gestionată are propriul agent. Dificultatea acestei abordări este aplicarea relațiilor între
mașini, deoarece fiecare mașină este responsabilă cu translatarea propriei configurații.
În privința celei de -a doua proprietăți, mecanismul de "tragere" înseamnă că agentul de
implementare trebuie să apeleze agentul de translație pentru a prelua configurațiile. În cazul
mecanismului de "împ ingere" agentul de translație este cel care apelează agentul de implementare.

24
Datorită faptului că informații precum parole sau chei de securitate sunt conținute în configurații, iar
aceste informații sunt expuse către toți agenții de implementare, introdu ce un risc de securitate și este
necesar un mecanism de autentificare și autorizare .

1.3.2.4 Platforme suportate

Infrastructurile moderne conțin o mare varietate de sisteme de operare, precum Windows,
UNIX, MAC OS X, dar și diferite tipuri de mașini, pr ecum calculatoare desktop, laptop, tablete,
smartphone și echipamente de rețea. Un instrument de management al configurației care suportă
diferite platforme este esențial pentru reducerea duplicării specificațiilor de configurare, în ciuda
relațiilor numer oase între mașinile pe care rulează diferite sisteme de operare.

1.3.3 Proprietăți de management al configurației

Cu cât specificațiile unui instrument de management al configurației sunt mai multe, cu atât
sunt mai greu de dezvoltat și implementat. Ia tă câteva dintre specificațiile ce trebuiesc avute în vedere
atunci când alegem un instrument de management al configurației:

1.3.3.1 Utilizabilitatea

Utilitatea unui instrument de management al configurației poate fi împarțită în trei categorii:
 Ușurința utilizării limbajului: utilizatorii țintă ai instrumentelor de management al configurației
sunt administratorii de sistem. Limbajul utilizat de acestea ar trebui să fie suficient de puternic
pentru a înlocui instrumentele existente, dar ușor de în teles și de utilizat de către administratorii
de sistem.
 Suport pentru testarea modificărilor: pentru a vedea impactul unei modificări de configurație
asupra infrastructurii, instrumentul de management al configurației poate oferi suport pentru
testare înt r-o infrastructură virtuală similară cu cea de producție.
 Monitorizarea infrastructurii: insrumentul de management al configurației poate oferi un sistem
integrat de monitorizare sau o interfață pentru alte instrumente de monitorizare pentru a verifica
starea actuală a unei infrastructuri.

1.3.3.2 Evidența versiunii

Unele instrumente de management al configurației își stochează configurațiile care sunt, în
esență, sub formă de cod în fișiere text. În consecință, păstrarea unei evidențe a versiunii config urației
este necesară pentru a permite dezvoltatorilor și administratorilor de sistem să pastreze un istoric al
modificărilor apărute. O astfel de evidență poate fi utilizată pentru revenirea la versiunea anterioară a
configurației, în cazul în care noua c onfigurație are un impact negativ asupra funcționării sistemului.

1.3.3.3 Integrarea cu alte rețele

Infrastructura gestionată de instrumentul de management al configurației este conectată la alte
rețele și necesită date din alte surse decât propria conf igurație pentru a funcționa în mod corespunzător.
Astfel, administratorii de sistem ar putea avea nevoie de informații din baze de date externe în
configurații sau informații cu privire la caracteristicile mașinilor gestionate. Un instrument de

25
management al configurației trenuie să se integreze cât mai bine cu alte rețele pentru ca informațiile
deja existente în sistem să nu fie duplicate

1.3.3.4 Controlul accesului

În cazul în care o infrastructură este configurată și gestionată pe baza unor fișiere de configurare
este necesară restricționarea accesului la aceste fișiere. Autentificarea și autorizarea administratorilor
de sistem înainte de a face modificări de configurație este necesară, pentru a preveni schimbările
nedorite asupra mașinilor gestionate.

1.4 Beneficiile utilizării unui instrument de management al configurației

În organizațiile a căror infrastructură IT nu este gestionată cu un instrument de management al
configurației, atunci administratorul de sistem trebuie să facă urmatorii pași pe ntru fiecare mașină:
 instalarea sistemului de operare de pe CD sau memorie flash
 configurarea sistemului de operare
 instalarea aplicațiilor necesare de pe CD sau un depozit de pachete
 configurarea aplicațiilor
 rularea aplicațiilor

Configurarea mașinilor din infrastructură în acest fel poate dura ore sau chiar zile, ceea ce
înseamnă că administratorul este limitat în ceea ce poate face în acest timp. Faptul că toate acestea
necesită foarte mult timp înseamnă că o infrastructură aflată într -o continuă schim bare este greu de
gestionat. Această metodă este, de asemenea, predispusă la erori.
În cel mai bun caz, dacă infrastructura este gestionată fără un intrument de management al
configurației, administratorul de sistem poate crea o imagine a unei mașini conf igurate complet și să o
încarce și pe restul, dar în continuare acest lucru necesită timp.
Pe de altă parte, gestionarea infrastructurii IT cu un instrument de management al configurației
presupune definirea stării fiecărei mașini, iar acesta se va ocupa de configurare. Astfel, pașii pe care
administratorul de sistem va trebui să -i facă sunt:
 instalarea sistemului de operare de pe CD sau memorie flash
 instalarea unui instrument de management al configurației
 definirea stărilor dorite a fi implementate pe m așini în instrumentul de management al
configurației

În consecință, utilizarea unui astfel de instrument va diminua considerabil timpul alocat de
administratorul de sistem pentru configurarea mașinilor dintr -o infrastructură IT, reducându -se, de
asemenea , riscul de apariție a erorilor.

1.5 Comparație între intrumente de management al configurației

Există o mulțime de instrumente diferite de management al configurației, de tip sursă deschisă
(în engleză "open -source") sau comerciale, utilizate în mod a ctiv de administratorii de sistem pentru
gestionarea infrastructurilor IT. Printre cele mai cunoscute instrumente de acest gen sunt CFEngine[1],
Chef[2], Puppet[3] sau BCFG2[4].

26
Această comparație va avea la bază aspectele prezentate în subcapitolul 1.3.

1.5.1 Proprietăți de configurare

Instrumentele de management al configurației CFEngine și Puppet folosesc un limbaj specific
domeniului DSL(Domain Specific Language)[9] declarativ pentru datele de intrare. CFEngine are la
bază limbajul de programare C[ 5], iar Puppet limbajul Ruby[6]. BCFG2 folosește un limbaj XML[7]
declarativ și configurația este scrisă utilizând limbajul Python[8]. Pe de altă parte, instrumentul de
management al configurației Chef, folosește un DSL imperativ și are la bază limbajul Ru by.
Ca și in cazul tipului de limbaj, instrumentele pot fi grupate și in funcție de tipul de interfață cu
utilizatorul. În general, instrumentele de tip sursă deschisă au o interfață linie de comandă, în timp ce
instrumentele comerciale oferă, de asemenea , o interfață grafică. Instrumente, precum CFEngine, Chef
și Puppet furnizează o interfață web care permite gestionarea unor aspecte.
Toate instrumentele oferă un mecanism de grupare a mașinilor gestionate. BCFG2 permite
gruparea statică și ierarhică ale grupurilor, pe când Chef poate defini grupuri statice și grupuri bazate
pe interogări. CFEngine și Puppet utilizează conceptul de clase, care pot conține alte clase pentru a crea
ierarhii. CFEngine poate atribui clase static sau condițional, utilizând expr esii, iar Puppet poate atribui
clase dinamic folosind instrumente externe.
Puppet oferă posibilitatea scrierii configurației în module, Chef utilizează cookbooks , acestea
fiind unitatea fundamentală de descriere a stării dorite, iar CFEngine utilizează pa chete. Toate acestea
sunt folosite la alocarea configurațiilor reutilizabile. Pe de altă parte, BCFG2 nu oferă posibilitatea de a
scrie module de configurație.

1.5.2 Proprietățile implementării

Scalabilitatea este proprietatea unei rețele sau a unui sistem care arată capacitatea de a suporta
corect un volum mai mare de încărcare, sau de a permite mărirea sau extinderea sa. Modalitatea de a
verifica scalabilitatea unui instrument de management al configurației este de a testa și analiza fiecare
instrum ent intr -o infrastructura și numararea mașinilor care rulează. Instrumentele au fost împarțite în
trei grupuri în funcție de numarul de mașini gestionate:
 mai puțin de 1000: BCFG2
 între 1000 și 10000:Puppet și Chef
 mai mult de 10000:CFEngine
Instrumentul CFEngine are o puternică arhitectură distribuită în care accentul se pune pe agenții
de implementare ce rulează pe mașinile gestionate. Serverul central este utilizat doar pentru coordonare
și pentru politicile de distribuție. Instrumentele BCFG2, Chef și Puppet folosesc un server central, iar
ulimele două pot lucra ca un sistem autonom, fără a avea nevoie de un server central pentru
implementarea unor specificații locale.
În privința agenților de implementare, toate cele patru instrumente de management al
configurației folosesc mecanismul de "tragere" a configurației de pe serverul central. Serverele centrale
ale instrumentelor Chef și Puppet pot notifica agenții de implementare dacă o nouă configurație este
disponibilă pentru implementare.
Platformele pe ntru care oferă soluții sunt prezentate în tabelul 1.1. Se poate observa că s -a pus
accentul pe soluțiile oferite pentru diferitele distribuții ale sistemului de operare Linux.

27
1.5.3 Proprietăți de management al configurației

Utilizabilitatea este o proprietate foarte greu de definit. În cazul instrumentelor de management
al configurației este clasificată în ușoară, medie și grea. Acest lucru a fost determinat prin evaluarea a
cât de ușor i -ar fi unui utilizator nou să folosească și să învete un instr ument. Utilizabilitatea
instrumentelor CFEngine și Puppet este medie, datororită sintaxei personalizate. În cazul
instrumentului Puppet care are o terminologie dificilă, nu a fost catalogat ca fiind un instrument cu
utilizabilitate grea, deoarece pune la d ispoziția utilizatorului o documentație bine pusă la punct. BCFG2
și Chef au fost clasificate ca fiind greu de utilizat, primul datorita datelor de intrare în format XML și
distribuirea configurației într -o mulțime de directoare diferite, iar al doilea dat orită terminologiei
personalizate și a limbajului Ruby imperativ.
Toate cele patru instrumente au date de intrare în format text pentru crearea configuraților.
Acestea pot fi gestionate într -un depozit extern cum ar fi Git[10] pentru a ține o evidență a v ersiunii
configurațiilor.
În ceea ce privește integrarea cu alte rețele, BCFG2, CFEngine, Chef și Puppet pot identifica în
timpul rulării caracteristici ale mașinilor gestionate care pot fi folosite atunci când o configurație este
gata pentru a fi impleme ntată.[7]

Proprietăți Puppet CFEngine Chef BCFG2
Tip de limbaj Declarativ Declarativ Imperativ Declarativ
Limbaj Ruby C Ruby Python
Interfața cu
utilizatorul GUI, Linie de
comandă Linie de comandă GUI, Linie de
comandă Linie de
comandă
Proprietăți de
configurare Fișiere de configurare,
implementarea
instanțelor dependente
, configurarea
instanțelor Fișiere de
configurare,
implementarea
instanțelor
dependente implementarea
instanțelor
dependente Fișiere de
configurare
Tip de grupare Statică, bazată pe
interogări, ierarhică Statică, bazată pe
interogări,
ierarhică Statică, bazată
pe interogări Statică, ierarhică
Module de
configurație Da Da Da Nu
Relații între
sisteme one-to-many, one -to-
one many -to-many,
one-to-many, one –
to-one n/a many -to-many
Scalabilitate 1000-10000 >10000 1000 -10000 <1000
Agent de
translație Management
centralizat Management
distribuit Management
centralizat Management
centralizat
Mecanisme de
distribuție “tragere”, “împingere” “tragere”,
“împingere” “tragere” “tragere”,
“împingere”
Platforme
suportate AIX, HP -UX, Linux,
Mac OS X, Windows,
Solaris AIX, HP -UX,
Linux, Mac OS
X, Solaris,
Windows Linux, Mac OS
X, Solaris,
Windows AIX, Linux, Mac
OS X, Solaris
Tabel 1.1 Comparație între instrumentele de management al configurației[7]

28
1.6 Securitatea

Sistemul de operare Linux are inevitabil mai multe avantaje decât sistemul de operare Windows
în ceea ce privește securitatea. Atacatorii întotdeauna vor căuta sistemele vulnerabile pentru a le accesa
sau pentru a lansa atacuri informatice. De asemenea, în principal aceștia își îndreaptă atenția către
domeniile cu cele mai mari șanse de a găsi sisteme neprotejate, cu alte cuvinte acele sisteme care sunt
cele mai frecvent întâlnite în Internet. În acest caz, Windows este c el mai răspândit sistem de operare.
Linux este mai puțin comun decât sistemele bazate pe Windows, fapt ce conduce la o
probabilitate mai mică de apariție a atacurilor și îl face un sistem de operare mai sigur. Cu toate
acestea, chiar dacă este vorba de si steme Windows sau Linux, securitatea este foarte importantă și nu
trebui neglijată.
Cel mai important prim pas în dezvoltarea unui mediu sigur este de a evita, ori de câte ori este
posibil, ca sistemul Linux să fie prima linie de apărare împotriva atacuri lor din exterior. Cel mai bun
mod de a face acest lucru este să ne asigurăm că avem un paravan de protecție (în engleză firewall)
instalat între sistemul Linux și conexiunea la Internet. În cazul în care sistemul Linux este conectat
direct la un cablu sau un modem DSL indicat ar fi montarea unui ruter sau a unei stații wireless pentru
a introduce o caracteristică de firewall între modem și sistem. Chiar dacă sistemul de operare Linux are
un paravan de protecție ce poate fi configurat este bine să nu ne bază m doar pe acesta. [8]
În rețelele de calculatoare, un paravan de protecție este un sistem de securitate care
monitorizează și controlează traficul de date ce intră sau iese dintr -o rețea pe baza unor reguli de
securitate predefinite[9]. Acesta acționează ca o barieră între o rețea locală sigură și alte rețele de
neîncredere, precum Internetul. Paravanul de protecție controlează accesul la resursele rețelei prin
filtrarea traficului. Acest lucru înseamnă că numai traficul permis în politicile paravanului de protecție
este lăsat să intre sau să iasă din rețea, restul traficului fiind refuzat.[10]
Un paravan de protecție poate ține la distanță traficul Internet malițios, de exemplu hackerii,
viermi cibernetici și anumite tipuri de viruși, înainte ca aceștia s ă pună probleme sistemului. În plus, un
paravan de protecție poate împiedica participarea computerului la un atac împotriva altora, fără
cunoștința sau voința utilizatorului. Utilizarea unui paravan de protecție este importantă în special dacă
rețeaua sau computerul pe care dorim să le protejăm sunt conectate în permanență la Internet.
Paravanul de protecție cooperează îndeaproape cu un program de rutare care examinează
fiecare pachet de date din rețea, locală sau exterioară, ce va trece prin serverul pasarelă (în engleză
bridge server), pentru a hotărî dacă va fi trimis mai departe spre destinație sau nu. De asemenea, un
paravan de protecție include sau lucrează împreună cu un server proxy care face cereri de pachete în
numele stațiilor de lucru ale ut ilizatorilor. În cele mai întâlnite cazuri aceste programe de protecție sunt
instalate pe calculatoare ce îndeplinesc numai această funcție și care sunt instalate în fața ruterelor.
Soluțiile de protecție prin paravan se împart în două mari categorii:
 soluțiile profesionale hardware sau software dedicate protecției întregului trafic dintre rețeaua
unei întreprinderi și Internet
 paravanele de protecție personale dedicate monitorizării traficului pe calculatorul personal

Utilizarea unei aplicații din cea de-a doua categorie este benefică atunci când calculatorul
personal dispune de o conexiune la Internet, pentru a oferi un plus de siguranță transmisiilor de date.
Cum astăzi majoritatea utilizatorilor trec de la conexiuni încete, de tip dial -up[11] la moda lități de
conectare rapide, precum cablu, ISDN[12], ADSL[13] sau date mobile, pericolul unor atacuri reușite
asupra sistemelor personale crește, deoarece mărirea vitezei de transmisie spre și dinspre Internet
mărește probabilitatea de strecurare a intrușil or rău intenționați și nedoriți.[14]
În figura 1.4 este prezentat modul de lucru al unui paravan de protecție.

29

1.6.1 Politica paravanelor de protecție

Înainte de a construi un paravan de protecție trebuie hotărâtă politica sa, pentru a ști exact care
va fi funcția sa și în ce fel se va implementa această funcție.
Politica paravanului de protecție se poate alege urmând câțiva pași:
 se aleg mai întâi serviciile care trebuiesc oferite de paravanul de protecție
 se desemnează grupurile de utilizatori care vor fi protejați
 se definește amănunțit gradul de protecție de care are nevoie fiecare grup de utilizatori și cum
vor fi implementate protecț iile necesare
 se face cunoscut utilizatorilor că oricare alte forme de acces nu sunt permise

Politicile definite la un moment dat tind să se complice cu timpul, dar la început este bine ca ele
să fie simple și obiective.

1.6.2 Clasificări

Paravanele d e protecție pot fi clasificate după nivelul din stiva de rețea la care operează și
modul de implementare. Astfel, în funcție de nivelul din stiva TCP/IP[15] (sau OSI[16]) la care
operează, paravanele de protecție pot fi:
 La nivelul 2 (nivelul Rețea), parav anul de protecție realizează o filtrare de pachete (în engleză
packet filtering) formată dintr -o listă de reguli de acceptare și interzicere a traficului de date.
Aceste reguli definesc în mod explicit ce pachete vor fi permise sau nu să treacă prin interf ața
de rețea. Regulile folosesc antetul pachetelor pentru a decide dacă trimite un pachet la destinația
sa sau interzice pachetul și trimite un mesaj de eroare mașinii expeditoare. Aceste reguli pot fi
bazate pe o gamă largă de factori, precum adresa IP[17 ] sursă sau destinație, tipuri de
protocoale, adrese MAC (Media Access Control)[18] etc. Acest paravan de protecție este unul
Figura 1. 4Modul de lucru al unui paravan de protecție [29]

30
fără menținere de stare (în engleză stateless firewall) și necesită mai puțină memorie, filtrele
simple putând fi mai rapide.[19]
 La nivelul 3 (nivelul Transport), paravanul de protecție realizează tot o filtrare de pachete, dar
de această dată păstrază o evidență a stării conexiunilor și a pachetelor blocate care nu
corespund cu starea așteptată. Acest lucru este realizat prin incor porarea nivelului de transport.
Acesta este un paravan cu menținere de stare (în engleză stateful firewall) și spre deosebire de
filtrarea de pachete fără menținere de stare, acesta interceptează pachetele de la nivelul de rețea,
le verifică pentru a vedea dacă sunt permise de către o regulă existentă și ține evidența fiecărei
conexiuni într -o tabelă de stări. Aceasta, de obicei, conține adresele IP sursă și destinație,
porturile TCP (Transmission Control Protocol)[20] sau UDP (User Datagram Protocol)[21] ș i
informații de stare ale conexiunii.
Există trei stări pentru traficul TCP: stabilirea conexiunii, transmiterea datelor, închiderea
conexiunii. Paravanul cu menținere de stare verifică antetul segmentului TCP pentru a
monitoriza starea fiecărei conexiuni. Fiecare pachet nou este comparat cu informațiile din tabela
de stări pentru a vedea dacă pachetul face parte dintr -o conexiune stabilită, în caz contrar este
evaluat conform regulilor de securitate pentru o nouă conexiune.
 La nivelul 4 (nivelul Aplicație) paravanul la nivel de aplicație (în engleză application -layer
firewall) ar trebui să intercepteze toate pachetele care circulă către sau de la o aplicație. Acest
lucru oferă paravanului de protecție posibilitatea de a permite sau interzice traficul produs de o
aplicație în funcție de modul în care rulează în rețea. De exemplu, un paravan la nivel de
aplicație poate determina dacă un mesaj e -mail conține un atașament nepermis, cum ar fi un
fișier executabil, sau daca se utilizează mesageria instantanee prin portul 80, utilizat în mod
obișnui de protocolul HTTP ( Hypertext Transfer Protocol)[22]. O altă caracteristică este că
poate fi utilizat pentru a permite sau bloca anumite pagini web care au anumite tipuri de
conținut sau care au certificate SSL semnate de o anumită unitate de certificare CA
(Certification Authority).[23]

1.6.3 Serverul proxy

Serverul proxy este un paravan de protecție care funcționează la nivelul aplicație. Acesta
acționează în calitate de intermediar între două rețele pentru traficul generat de o aplicație specifică de
rețea. Un astfel de paravan previne conexiunea directă între cele două părți ale acestuia, sesiunea fiind
efectuată prin serverul proxy, care poate permite sau interzice traficul pe baza propriului set de
reguli .[24]

31
Capitolul 2 Instrumentul de management al configurației
Puppet

2.1 Descriere

Puppet este un instrument de management al configurației care permite administratorilor de
sistem definirea stării infrastructurii IT. Orice modificare care trebuie efectuată se traduce într -o
modificare în configurația puppet pentru respectiva resursă (fi șier/pachet/nod/grup de noduri etc.), care
este aplicată în mod automat pe toate serverele sau nodurile vizate de respectiva schimbare.
Descrierea acestei stări se realizează folosind limbajul Puppet, care este un limbaj declarativ ce
are la bază limbajul Ruby. Configurația generală se găsește în fișierul
/etc/code/enviroment/production/manifests/site.pp . Această soluție se bazează pe resurse (resources),
manifeste (manifests) și module (modules). Întelegerea acestor 3 concepte te ajută să descoperi
filozo fia din spatele Puppet.[25]
Aproape fiecare aspect al unui sistem – fișiere, utilizatori, pachete, servicii – este văzut ca o
resursă. Asta înseamnă că descrierea unei resurse este separată de implementarea ei. Acest lucru este
obținut prin modelarea stăr ilor pe care o resursa le poate avea. Puppet dispune de un număr satisfăcător
de tipuri predefinite de resurse, care pot fi găsite în documentația lor oficială. Spre exemplu, să spunem
că vrem ca un serviciu să “ruleze” fară să știm care este comanda de po rnire a serviciului respectiv.
Pornirea serviciului puppet -agent este extrem de simplă, trebuie doar să introduceți următoarea
comandă:

puppet resource service puppet -agent ensure=running

Chiar dacă diferite distribuții Linux au modalități diferite de a porni un serviciu, acest lucru nu
contează aici. Soluția Puppet se ocupă de toate aceste aspecte. Mai mult decât atât, putem folosi aceeași
comandă pe diferite sisteme de operare – Linux și Windows.
Dacă vrem configurații persistente, trebuie să stocăm d efinițiile resurselor în fișiere denumite
manifeste. Acestea conțin definiții scrise folosind limbajul declarativ Puppet, cu o sintaxa similară cu
cea a limbajului Ruby. Nu trebuie să listăm toate atributele posibile pentru o resursă. Fiecare atribut are
o valoare implicită care va fi folosită dacă nu vrem să declaram ceva în mod specific. Spre exemplu,
definim utilizatorul “user” cu directorul home în "/home/user" și shell -ul predefinit în "/bin/bash":

user { "user":
ensure => present,
home => "/home/us er",
shell => "/bin/bash",
}

Un modul reprezintă un set de clase, definiții, template -uri și fișiere care împreună, îndeplinesc
un singur scop. De aici rezultă și prima recomandare în scrierea unui modul: trebuie să îndeplinească o
singură funcționalit ate. Problema care apare este că module riscă să ajungă prea mari și greu de
gestionat. În plus, își pierd din portabilitate. O soluție mai elegantă este despărțirea configurațiilor în
module separate, reducându -se astfel complexitatea fiecăruia.

32
Clasa re prezintă un bloc de cod care poate fi instanțiat. Fiecare modul are definită în fișierul
manifests/init.pp clasa principală a modulului. Instanțierea unei clase la nivelul unui nod, astfel încât să
se aplice schimbările sale se realizează folosind directiv a include.
Clasele suportă moșteniri și pot fi instanțiate de mai multe ori în configurația generală puppet,
care se găsește în fișierul site.pp. De asemenea, clasele pot fi parametrizate. În cadrul unei clase
definim starea dorită a sistemului folosind r esurse de tipuri predefinite sau definite de
administrator.[26]

2.2 Arhitectura

Puppet poate funcționa atât într -o arhitectură de tip client -server, cu un server central și agenți
Puppet care vor implementa configurația luata de la server pe mașinile gestionate, sau un mod singur în
rețea.

Figura 2 .1 Architectura Puppet de tip client -server [30]

În cazul arhitecturii de tip client -server, serviciul puppet agent trimite periodic informații despre
starea mașinii gestionate, numită nod, către serverul Puppet master și solicită un catalog de
configurație. Un catalog este un document care descrie starea dorită a sistemului pentru o anumită
mașină. Acesta prezintă toate resursele ce trebuie gestonate și toate dependențele dintre aceste resurse.
Serviciul master compilea ză și returnează catalogul pentru nodul respectiv, utilizând mai multe surse
de informații la care are acces. Aceste informații sunt preluate de la un nod extern de clasificare ENC
(în engleză external node classifier) ce returnează detalii despre clasele ce pot fi utilizate de acel nod, în

33
funcție de scopul și mediul în care va fi folosit și parametrii ce definesc acele clase. Aceste clase sunt
stocate într -o bază de date.
Odată ce a primit catalogul, serviciul Puppet agent îl va aplica verificând fiecare resursă
descrisă în catalog. Dacă găsește o resursă ce nu este definită în starea dorită a sistemului, va face
modificările necesare pentru a fi în concordanță. După aplicarea catalogului, agentul va trimite un
raport al întregului proces serverului Puppe t Master.

Figura 2 .2 Fluxul de lu cru al instrumentului Puppet [27]

Prin urmare, agentul are acces la propriile informații ale sistemului, configurațiile acestuia și
fiecare raport pe care îl generează. Serverul are copii după toate datele, acces la toate modulele Puppet
și la orice bază de date și servicii de care ar avea nevoie ca să compileze configurația.
Dincolo de componentele utilizate în acest flux de lucru sunt multe tipuri de date pe care Puppet
le folo sește pentru comunicația internă. Aceste tipuri de date sunt critice, deoarece ele reprezintă modul
în care toate comunicațiile sunt făcute și sunt date publice pe care alt instrument le poate utiliza sau
produce.[27]
Cele mai importante tipuri de date su nt:
 Facts: datele de sistem colectate de la fiecare mașină și folosite la compilarea configurațiilor

34
 Manifeste: fișiere ce conțin codul Puppet, în general organizate în colecții denumite module
 Catalog: document ce conține informații despre resursele unui nod ce urmează a fi gestionat și
dependențele dintre acestea
 Raport: Evenimentele generate pe parcursul aplicării unui catalog

Figura 2 .3 Ilustrarea fluxului de lucru dintre procesele și compon entele instrumentului Puppet [27]

2.3 Securitatea și comunicația

2.3.1 Criptografia cu cheie publică

Criptografia cu cheie publică (în engleză Public Key Cryptography) este o familie de algoritmi
și metode pentru criptarea și verificarea informației.
Principiul fundamental al criptografiei cu cheie publică este că doi participanți pot face
schimburi sigure de informatii fără a furniza vreo cheie secretă. Aceast lucru permite aplicații noi, care
ar fi imposibil de realizat cu criptare simetrică, unde toți participanții trebuie s ă aibă o copie a unei chei
secrete.

35
În criptografia cu cheie publică, fiecare participant are o pereche de chei (în engleză key pair),
care constă într -o cheie publică și o cheie privată. Acestea sunt numere mari, aproape imposibil de
ghicit și sunt legat e matematic într -un mod special. Ele au și câteva specificații:
 oricărei chei publice îi corespunde o singură cheie privată, și invers
 o cheie privată nu poate fi obținută din cheia publică corespunzătoare
 folosind o parte a perechii de chei se poate efect ua un calcul care poate fi inversat numai prin
utilizarea celeilalte părți a perechii de chei

Cheia publică poate și ar trebui să fie împărtățită în mod liber. Cheia privată trebuie însă să
rămână privată. În cazul în care o copie a acesteia este furată , atacatorul poate juca rolul proprietarului
de drept, până când toți ceilalți participanți nu mai utilizează și nu mai au încredere în cheia publică
corespunzătoare.
Dacă avem partea publică a unei perechi de chei putem cripta un mesaj astfel încât acest a să
poată fi decriptat de către oricine posedă cheia privată corespunzătoare.
De asemenea, daca avem partea publică a unei perechi de chei putem semna digital un mesaj.
Acest lucru implică combinarea mesajului și a cheii private pentru a crea un șir de c aractere unic, numit
semnătură, care poate fi creat doar cu acea cheie privată. Apoi, cine are cheia publică corespunzătoare
o poate utiliza împreuna cu mesajul original pentru a analiza semnătura. Semnătura digitală ne permite
să dovedim că oricine a sem nat mesajul a fost în posesia cheii private și să determinăm dacă mesajul a
fost modificat dupa ce semnătura a fost făcută. Astfel, semnăturile pot fi folosite atât pentru a
demonstra identitatea cuiva, cât și să facă informatia publică în timp ce mesajul este protejat de
modificări sau de falsificare.
În producție pentru ca un sistem de criptare cu cheie publică să fie util trebuie să fie combinat
cu un alt sistem care leagă perechile de chei cunoscute într -o anumită formă de identitate. Acesta poate
fi un registru local, cum ar fi cheile SSH, un registru central, precum DNS -ul, sau o combinație între
ele.

2.3.2 Infrastructuri cu cheie publică

O infrastructură cu cheie publică (în engleză public key infrastructure(PKI)) este o modalitate
de a asocia cheile publice cu informații sigure despre utilizatorul ei. Acest lucru face criptarea cu cheie
publică mult mai eficientă, din moment ce utilizatorii nu mai sunt nevoiți să păstreză o lista cu toate
cheile publice anterioare.
Infrastructura cu cheie publ ică utilizată de protocoalele de securitate SSL/TLS (Secure Socket
Layer/Transport Layer Security) este definită de standardul X.509. Instrumentul de management al
configurației Puppet utilizează OpenSSL care are implementat acest standard.

2.3.3 Certifi cate

Un certificat este un document de identificare ce conține o cheie publică, metadate despre
acesta și despre utilizatorul său și o semnatură de la unitatea de certificare CA (în engleză certificate
authority). Toate acestea sunt în strânsă legătură pentru a asigura o comunicație securizată:
 cheia publică ne permite să determinăm dacă entitatea cu care dorim să comunicăm deține cheia
privată corespunzătoare pentru a putea iniția o comunicație securizată.
 metadatele ne spun detalii despre entitate, pre cum cine este, ce îi este permis să facă și perioada
de valabilitate a certificatului

36
 o semnătură dovedește că perechea de chei a unei entități a fost verificată anterior și se verifica
direct dacă certificatul este corect. Aceasta, de asemenea previne mod ificările informațiilor din
certificat, în cazul în care acestea apar certificatul nu va mai fi validat.

Aceste certificate sunt emise de CA, ce este autorizată să semneze noile certificate, dar și valida
sau revoca pe cele deja existente.
Instrumentul de management al configurației Puppet are abilitatea de a crea și administra o
unitate de certificare. Acest lucru oferă posibilitatea ca Puppet să fie utilizat în infrastructuri în care o
infrastructură cu chei publice nu este prezentă. Cu această funcție integrată, Puppet are facilități
suplimentare atunci când noi noduri trebuiesc gestionate, agentul de noduri putând solicita în mod
automat semnarea unui certificat la prima interacțiune cu serverul Puppet.
Unitatea de certificare a instrumentului Puppet este alcătuită din urmatoarele componente:
 servicii HTTPS oferite de serverul Puppet master , care primește cereri de semnare a
certificatului CSRs(în engleză certificate signing requests) și transmite certificatele emise de
unitatea de certificare, lista certificatelor revocate CRL (în engleză certificate revocation list) și
certificatele semnate.
 spațiu de stocare în care se găsesc certificatele, cheile private ale CA, un inventar al
certificatelor semnate împreună cu copiile acestora, cererile de semnare a certificatelor și lista
certificatelor revocate
 comenzi pentru linia de comandă pentru a vedea cererile în așteptare și pe ce cele semnate și de
revocare

2.3.4 TLS/SSL

TLS (Transport Layer Security) este un protocol criptografic ce folosește standard ul X.509 PKI
pentru a crea canale de comunicație securizate. SSL (Secure Socket Layer) este versiunea precedentă a
acestui protocol, care este în continuare foarte utilizat.
SSL va avea întotdeauna doi participanți: un client, care va iniția conexiunea, și un server, care
va accepta conexiunea. O entitate poate funcționa uneori ca client și alteori ca server. Un server trebuie
întotdeauna să dețină un certificat semnat de unitatea de certificare pe care clientul o consideră de
încredere.
Inițierea unei c onexiuni SSL implică urmatoarele proceduri:
 clientul și serverul negociază pentru a afla ce versiune de protocol va fi folosită
 serverul prezintă clientului certificatul pe care acesta trebuie să îl valideze după ce verifică lista
cu unitățile de certifica re de încredere, lista certificatelor revocate și perioada de valabilitate a
certificatului
 clientul trimite o cheie temporară criptată serverului pentru ca doar deținătorul certificatului să
o poată citi
 cheia este folosită de ambele entități pentru a cripta traficul de date din conexiunea realizată

Utilizarea unei conexiuni SSL atrage de la sine mai multe avantaje. În primul rând ambele
entități participante au acces la un canal de comunicație criptat al cărui trafic nu poate fi interceptat. În
ceea c e privește clientul acesta va ști că doar serverul deținător al certificatului și al cheii temporare va
putea decripta informațiile transmise. Acesta va putea utiliza orice metadata din certificatul serverului
pentru a autentifica și autoriza serverul. Dac ă clientul nu a făcut o cerere de autentificare serverului,
serverul nu va ști nimic despre client. Dacă cererea a fost facută, serverul va ști că unitatea de
certificare a verificat metadatele din certificatul clientului și le poate utiliza pentru autenti ficarea și
autorizarea clientului.

37
2.3.5 HTTPS (Hyper Text Transfer Protocol Secure)

Din moment ce SSL este un protocol relativ general, acesta este utilizat pentru încapsularea
unor protocoale mai specifice, precum HTTP (Hyper Text Transfer Protocol) sa u SMTP (Simple Mail
Transfer Protocol)[2].
HTTPS reprezintă protocolul standard HTTP încapsulat într -un flux SSL, în care este realizată
o conexiune SSL, după care clientul va trimite cereri normale HTTP către server pe un canal securizat,
toate datele fi ind criptate.
Instrumentul de management al configurației Puppet utilizează protocolul HTTPS pentru tot
traficul; serviciul Puppet agent al nodurilor reprezintă clienții și solicită catalogul de la serverul Puppet
master . Datorită faptului că Puppet folose ște protocolul HTTPS, acesta are nevoie de certificate ce au
la bază infrastructura cu cheie publică, care la rândul ei utilizează criptarea de chei publice.
Majoritatea punctelor finale ale Puppet necesită autentificarea clientului, prin urmare Puppet
master trebuie să se asigure că nodurile sunt autorizate înainte de a le trimite cataloagele. Acest lucru
înseamnă că serverul Puppet master și Puppet agent trebuie să aibă propriile servicii.
Tehnic, orice port poate fi folosit pentru protocolul HTTPS. Pe web, prin convenție este utilizat
portul 443. Puppet însă utilizează portul 8140, deoarece traficul nu este de tip web.
De obicei, este necesar ca sistemele de tip client -server ce utilizează protocolul HTTPS să se
împartă în multiple componente sau servi cii semi -independente pentru a spori performanța. Protocolul
SSL este una dintre aceste componente.
O componentă care se ocupă de SSL într -o arhitectură orientată pe servicii este numită
terminație proxy. Proxy -urile SSL funcționeză pe baza acelorași ceri nțe ca și componentele SSL ale
unei stive de aplicație – acestea trebuie să valideze certificate, să asigure canale de comunicație
securizate și să ofere informații despre certificate pentru a fi utilizate de celelalte componente ale stivei.
De asemenea, c onexiunea dintre serverul proxy și cel de aplicații trebuie să fie foarte sigură, deoarece
informațiile vor fi transmise necriptate. Terminațiile proxy se ocupă de conexiunile primite, urmând a
trimite cereri HTTP serverului de aplicații. Atunci când prime ște un răspuns, îl va trimite clientului pe
canalul securizat. Dacă aplicația are nevoie de date despre SSL sau certificat, proxy -ul le va furniza
introducând datele în antetul cererii HTTP pe care o trimite serverului de aplicații.[28]

Figura 2 .4 Conexiunea client -server prin SSL proxy

38

39
Capitolul 3 Implementarea și validarea funcțională

3.1 Implementarea

Pentru realizarea și simularea rețelei în care am implementat un instrumentul de management al
configurației Puppet am folosit programul de creare a mașinilor virtuale Oracle VM VirtualBox[1]. În
acesta am creat mașini virtuale pe care am instalat sistemul de operare Linux. Distribuțiile Linux
utilizate sunt Ubuntu care se bazează pe pachete Debian și Fedora, bazată pe pachete Red Hat Linux.
Puppet poate funcționa atât într -o arhitectură de tip client -server, cât și singur în rețea. De
interes este însă primul caz, unde serverul Puppet poarta numele de puppetserver și c lienții care vor
comunica cu serverul pentru a -și "trage configurația", numiți noduri.
În figura 3.1 este ilustrată topologia rețelei, formată din serverul Puppet și 4 noduri.
Pentru instalarea serverului Puppet am ales distribuția Linux Ubuntu, ca pentr u cele 4 noduri să
folosesc distribuțiile Ubuntu și Fedora.

Figura 3 .1 Toplogia rețelei client -server

Pentru a putea instala serverul și agentul care va translata modelul de stare configurat pe server
la noduri, este necesară activarea depozitului de pachete Puppet. Acest lucru este posibil prin
descărcarea unui pachet cu extensia .deb și instalarea acestu ia utilizând instrumentul dpkg și opțiunea

40
de instalare -i în cazul distribuției Ubuntu, respectiv extensia .rpm și pentru instalare se va utiliza
intrumentul rpm împreună cu opțiunile -Uvh.

Figura 3 .2 Activarea depozitului Puppet pentru distribuția Ubuntu

Figura 3 .3 Activarea depozitului Puppet pentru distribuția Fedora

La instalare se vor folosi pachetele puppetserver pentru server și puppet -agent pentru agentul de
translație. Comenzile necesare sunt apt-get install puppetserver , respectiv apt-get/yum install puppet –
agent .
Odată instalate, fișierul principal de configurare trebuie modificat conform actualei
infrastructuri. Acesta este fișierul puppet.conf atât î n cazul serverului, cât și în cazul nodurilor. Aici
sunt configurate setările de referiță ale serverului Puppet și ale agentului Puppet, precum numele
certificatului asociat nodului, intervalul de timp la care agentul aplică catalogul de configurație sau
serverul de la care agentul va lua configurația.
În Figura 3.4 este prezentat conținutul fișierul puppet.conf al serverului. Acesta este format din
una sau mai multe secțiuni. Secțiunea [main] este secțiunea globală și este utilizată de toate comenzile
și serviciile. Secțiunea [master] este utilizată de serviciul Puppet master , care se ocupă de funcționarea
serverului și comanda Puppet cert , care se ocupă de semnarea certificatului cerere în vederea realizării
conexiunii de transmitere a configurației între server și noduri.

41

Figura 3 .4 Fișierul puppet.conf al serverului Puppet

În Figura 3.5 este conținutul fișierului puppet.conf al unui nod ce este utilizat de serviciul
Puppet agent.

Figura 3 .5 Fișierul puppet.conf al unui nod

Înainte de a porni cele două servicii trebuie să ne asigurăm că în fișierul nodului /etc/hosts
numele serverului de la care va cere configurația are asociată o adresa IP și se va testa dacă avem
conexiune între server și nod. În acest sens am trimis un pachet ICMP de la nod la server, așa cum se
poate observa în Figura 3.6.

Figura 3 .6 Testarea conexiunii nod -server

42
3.2 Configurare a

Din dorința de a redu ce complexitatea configurației, am ales scrierea acesteia în module.
Pentru conturile userilor ce vor fi implementate pe nod -uri am creat modulul accounts . Pentru
simplificarea administrării am creat un tip de resursă definită, care este un bloc de cod Pu ppet ce poate
fi utilizat de mai multe ori cu diferiți parametrii. Am numit acest tip de resursă
accounts::create_accounts , unde accounts este clasa principală din care face parte. Clasa principală
trebuie să aibă același nume cu cel al modulului. Parametrii resursei definite sunt reprezentați de
variabile. Orice resursă definită conține cel puțin o resursă ce va fi adaugată în catalogul ap licat de
Puppet pe nodurile țintă pentru a asigura starea dorită a sistemului. Instanțele unui tip de resursă
definită pot fi declarate în același mod ca cele ale unei resurse normale. Parametrii utilizați la definirea
unui tip de resursă definită devin at ributele folosite la declararea resursei. Resursa user crează un user,
al cărui nume la logare este stocat în variabila $title și conține următoarele atribute:
 comment : informații despre user
 home : directorul home al utilizatorului
 shell : interpretorul de linie de comandă utilizat de sistemul de operare Linux
 uid: numarul de identificare al userului
 managehome : atributul de creare a directorului home al utilizatorului
 password : parola userului
 groups : grupurile din care face parte userul

Figura 3 .7 Codul resursei definite accounts::create_accounts

Pentru asigurarea unei logări securizate am utilizat chei SSH: cheie publică și cheie privată.
SSH este o modalitate mai sigură de a controla accesul userilor decât modalit atea clasică "user și

43
parolă". Astfel un user nu se poate loga cu un cont controlat de cheia publică, doar dacă deține cheia
privată potrivită. În acest sens am utilizat resursa ssh_authorized_key cu atributele:
 ensure : valoarea present a acestui atribut specifică utilizarea unei chei SSH la logare
 user: contul pentru care această cheie va permite accesul
 type: repezintă algoritmul de criptare utilizat
 key: cheia publică a serverului Puppet

În figura 3.8 se poate o bserva generarea cheilor publică și privată, iar în figura 3.9 cheia publică
utilizată.

Figura 3 .8 Generarea cheilor SSH

Figura 3 .9 Cheia publică SSH

Pentru adăugarea conturilor de user am utilizat subclasa accounts::add_accounts ce utilizează
resursa definită anterior, accounts::create_accounts . Pentru fiecare cont se vor aloca valori fiecărui
atribut al acesteia. Pentru că nu ne dorim ca parola să fie în clar, am trecut parola criptată cu algoritmul
SHA -1. În figura 3.10 avem codul utilizat la crearea contului pentru userul user1 .

44

Figura 3 .10 Crearea contului de utilizator

Pentru grupul din care vor face parte use rii am creat subclasa accounts::groups al cărui cod
poate fi obser vat în figura 3.11. În cazul userilor pentru care dorim privilegii de administrator, deoarece
avem noduri bazate pe distribuția Debian și noduri bazate pe distribuția Red Hat, noii useri tre buie să
fie in grupul sudo pe sistemele Debian și în grupul wheel pe sistemele Red Hat. Această valoare poate
fi setată automat utilizând informațiile (facts) pe care serverul Puppet le primește de la fiecare nod.
Pentru realizarea acestui lucru se apeleaz ă variabila $rootgroup definită în subclasa accounts::os_vars
din figura 3.12.

Figura 3.11 Codul subclasei accounts::groups

Figura 3.12 Codul subclasei accounts::os_vars

45
Clasa principală accounts din manifestul init.pp va include toate aceste clase, ulterior fiind
folosită la configurarea nodului.
Pentru gestionarea cheilor SSH și pentru conectarea la distanță avem nevoie de o conexiune
SSH, ceea ce implică o comunicație client server.
În acest sens am creat modulul sshd, a că rui clasă principală sshd poate fi observată în
figura 3.13. Aceasta este defi nită în manifestul init.pp din modules/sshd/manifests . Resursa package se
asigură că pachetele specifice distribuției fiec arui nod, ale căror denumire o obține din informațiile
primite de la acesta și o memorează în variabila $ssh_packages , este instalată. Resursa service
gestionează serviciul ssh în cazul distribuției Debian sau sshd în cazu l celei Red Hat și se asigură ca
acesta să fie pornit. Înainte ca Puppet să poată gestiona serviciul ssh, pachetul specific fiecărei
distribuții este necesar. Resursa file, numită sshd_config , care gestioneză serverele este un fișier pus la
dispoziție de Puppet Master. În fișierul sshd_c onfig am specificat ca userul administrator al sistemului,
root, să nu se poată conecta utilizând o conexiune SSH și am setat ca la un interval de 10 minute în care
nu s-au mai primit date de la client să se trimită un mesaj prin care să se ceară un răspun s de la client.
Resursa file are câteva atribute pr intre care deținătorul, grupul și modul, prin care sun t specificate
permisiunile pe care le are utilizatorul asupra fișierului. La fel ca și resursa service , resursa file depinde
de pachetul specific distr ibuției. Atributul notify este utilizat ca la fiecare modificare de conținut a
fișierului , serviciul ssh să fie repornit. Fișierul sshd_config va fi copiat pe mașina nod din locația
/file/sshd_config a modulului sshd.

Figura 3.13 Codul clasei sshd

46
În ceea ce privește securitatea, am instalat modulul firewall disponibil pe Puppet Forge[ 31] ce
permite gestionarea regulilor de firewall cu Puppet. Modulul firewall introduce resursa firewall , ce este
utilizată pentru a gestiona și configura regulile firewall cu ajutorul limbajului declarativ Puppet. Acesta
oferă suport pentru iptables și ip6tables. Modulul firewall are efect imediat asupra firewall -ului prezent
pe sistem, producând modificări la aplicarea catalogului. Pe ntru definirea regulilor de firewall am creat
clasele firewall::pre și firewall::post . Regulile introduse în cele două clase sunt generale, acestea
asigurându -se că mențin conexiunea și interzic pachetele care nu se potrivesc regulilor. Aceste reguli
sunt definite în manifestul modulului conform funcționalitătii descrise de modelul de stare dorit.
Am adăugat clasa firewall::pre în fișierul firewall/manifests/pre.pp . Fișierul pre.pp trebuie să
conțină reguli implicite ce vor fi aplicate primele asupra pache telor. Acestea trebuie să permită accesul
traficului de rețea, precum traficul ICMP, traficul TCP și traficul de ieșire. De asemenea, am permis
acceptarea conexiunilor SSH, ce utilizează portul 22 și conexiunilor HTTP/HTTPS ce sunt utilizate de
instrumentu l de management al configurației Puppet. Toat e aceste reguli se aplică înlănț uit, lucru
evidențiat de săgețile de înlănțuire " ->". Conținutul fișierului pre.pp este în figura 3.14.

Figura 3.14 Clasa firewall::pre

47

În fișierul firewall/manifests/post.pp am definit clasa firewall::post în care sunt specificate
regulile de firewall ce vor fi aplicate la sfârșit. Regula definită va interzice toate pachetele ce nu
corespund regulilor din clasa firewall::pre . Conținutul fișierului post.pp poate fi observată în figura
3.15.

Figura 3.15 Clasa firewall::post

3.3 Validarea funcțională

În fișierul /etc/puppetlabs/code/enviroment/production/manifests/site.pp este definit mo delul de
stare dorit pentru fiecare nod. Numele nodului trebuie să fie la fel ca numele certificatului certname ,
prezent în fișierul puppet.conf al nodului. Definiția unui nod este un bloc de cod Puppet care va fi
inclus doar în catalogul nodului specifica t. Această caracteristică permite atribuirea anumitor
configurații nodurilor specificate.
În cazul nodului node4.puppet.com am inclus modulul accounts pentru crearea userilor,
modulul sshd pentru gestionarea logării userilor utilizând chei SSH și modulul firewall pentru
implementarea regulilor de firewall în vederea securizării sistemului.
Am utilizat resursa resources , a cărui atribut purge va suprascrie orice resursă firewall
negestionată. Aceasta va șterge orice regulă de firewall existentă pe nod și se va asigura că vor exista
doar regulile definite de Puppet. Secvența de cod următoare va seta parametrii standard pentru toate
reguliile firewall ce vor fi stabilite mai târziu . De asemenea, aceasta stabilește ordinea în care clasele
firewall::pre și firewall::post vor fi rulate pentru a nu afecta conexiunea. Secvența de cod class {
['firewall::pre', 'firewall::post']: } declară cele două clase pentru a satisface dependențele.
Am adăugat resursa firewall "200 allow Puppet Master" pentru a mă asigura că pe portul 8140
utilizat de serverul Puppet traficul este întotdeauna acceptat.
În figura 3.16 este definit modelul de stare pentru nodul node4.puppet.com .

48

Figura 3.16 Modelul de stare al nodului node4.puppet.com

Pentru a putea implementa modelul de stare pe nod este necesara generarea și semnarea
certificatului SSL. Serviciul puppet agent de pe nod va trimite serverului o cerere de semnare a
certificatului. În figura 3.17 am inițiat cererea de semnare a certificatului.

Figura 3.17 Cererea de semnare a certificatului (CSR)

49
În figura 3.18 se poate observa că cererea de semnare a certificatului a ajuns la server și este în
lista de certificate. După ce va fi semnat în dreptul nodului va apă rea semnul "+".

Figura 3.18 Listă certificate

În figura 3.19 este comanda utilizată pentru semnarea certificatului.

Figura 3.19 Semnare certificat

În figura 3.20 nodul este informat că certificatul a fost semnat, iar agentul de translație a început
procesul de implementare a co nfigurației.

Figura 3.20 Inițierea procesului de implementare a configurației

50

În figura 3.21 se poate observa colectarea de către server a datelor despre nod. De asemenea, se
poate observa inițierea procesului de aplicare a catalogului creat.

Figura 3.21 Aplicarea catalogului

Figura 3.22 reprezintă încheierea procesului de implementare a configurației, durata aplicării
acesteia fiind de aproximativ 400 de secunde.

Figura 3.22 Terminarea procesului de implementare a configurației

Pe nodul node4, în fișierul de useri /etc/passwd am verificat dacă userii definiți în modulul
accounts au fost adăugați. În figura 3.23 se poate observa existența useri lor în fișierul /etc/passwd al
nodului node4.

Figur a 3.23 Fșierul /etc/passwd

Am folosit comanda ll pentru a vedea dacă directoarele userilor au fost create.

Figur a 3.24 Directoare useri

51
Ulterior am verificat dacă useri fac parte din grupul puppetgroup , iar în cazul userilor user1 și
user3 dacă sunt în grupul de useri cu permisiuni de administrator. Acest lucru se poate observa în
figura 3.25.

Figur a 3.25 Grupuri de useri

Pentru a vedea dacă regulile de firewall au fost implementate a m folosit comanda iptables -L. În
figura 3.26 se poate observa că toate regulile configurate anterior au fost implementate cu succes.

Figura 3.26 Tabelă reguli firewall

3.4 Analiza performanțelor

În ceea ce privește analiza perf ormanțelor am urmărit rata de utilizare a procesorului și a
memorie RAM. Pentru a realiza acest lucru am folosit platforma Datadog. Acesta este o platformă de
monitorizare și analiză a infrastructurilor IT ce are la bază SaaS ( Software as a service ). Monitorizarea
este posibilă prin implementarea unui agent Datadog în instrumentul de management al configurației
Puppet. În acest sent am instalat modulul datadog -datadog_agent .
În primul scenariu am urmărit media ratei de utilizare la anumite momente de timp a celor patru
nuclee ale procesorului și utilizarea memoriei atunci când implementarea configurației are loc pe toate
cele patru noduri simultan. După cum se poate observa în figura 3.27 media atinge o valoare de vârf de
apoape 100%. În ceea ce privește memoria utilizat ă aceasta rămâne aproape constantă pe toata durata
implementării și este jumătate din cea disponibilă , dupa cum se poate observa în figura 3.28. Aplicarea
catalogului pe fiecare nod a durat între 500 -600 de secunde, în funcție de distribuția Linux prezentă pe
nod.

52

Figura 3.27 Scenariul 1 Utilizare CPU

Figura 3.28 Scenariul 1 Memorie sistem

În al doilea scenariu, aplicarea catalogului se face pe un singur nod. În figura 3.29 putem
observa că valoarea medie de vârf este de aproximativ 60 de pro cente. Utilizarea memorie scade și ea
până la 2.10GB. De asemenea, durata de aplicare a catalogului pe nod scade considerabil la 120 de
secunde. Mmemoria utilizată pot fi văzute în figura 3.30.

53

Figura 3.29 Scenariul 2 Utilizare CPU

Figura 3.30 Scenariul 2 Memorie sistem

În cel de al treilea scenariu am optat pentru rularea puppet agent pe un nod configurat, care va
aplica un nou catalog, în ciuda faptului că nu am făcut modificări de configurație. În această situație
rata de utilizare a pro cesorului rămâne sub 50%, pe când în cazul memoriei nu apar modificări. Durata

54
de aplicare a catalogului este de ordinul secundelor. Cele două măsurători pot fi vazute în figura 3.31,
respectiv figura 3.32.

Figura 3.31 Scenariul 3 Utilizare CPU

Figura 3.32 Scenariul 3 Memorie sistem

55

În concluzie, cu cât numă rul de noduri crește și resursele serverului devin mai solicitate, dar
asta nu face instrumentul de management al configurației Puppet mai puțin scalabil în viața reală,
scenariile prezentate mai sus fiind realizate cu ajutorul unor mașini virtuale prezente pe aceași mașină
gazdă, scopul fiind acela de a sublinia faptul că apar modificări în utilizarea resurselor serverului și
durata de aplicare a catalogului diferă.

56

57
Concluzii

Infrastructurile IT moderne conțin sute sau mii de sisteme. Să le mențină funcționale pe toate în
modul în care ar trebui să funcționeze poate fi o adevarată provocare pentru administratorii de sistem.
Utilizarea unui instrument de management al configurației va aduce multe beneficii. Utilizând un astfel
de instrument îi va ajuta să mențină sistemele conform specificațiilor de funcționare și să
economisească timp. De asemenea, utilizarea unui astfel de instrument va reduce riscul de apariție a
erorilor, ce inevitabil ar fi apărut în c azul infrastructurilor gestionate fară un instrument de
management. Toate acestea pot fi realizate prin definirea unui model de stare dorit, iar un agent de
implementare al instrumentului se va asigura că va fi implementat pe sistemul dorit.
Puppet este un puternic instrument de management al configurației ce utilizează un limbaj
propriu pentru a gestiona resursele unei infrastructuri și pentru a a utomatiza munca administratorilor de
sistem. Arhitectura acestuia este de tip client -server, astfel clientul trimite periodic informații despre
sistem, iar serverul va tranmite configurația conform modelului de stare. Comunicația dintre client și
server es te una securizată prin protocolul HTTPS, toate datele transferate fiind criptate SSL.

58

59
Bibliografie

[1] MIL -HDBK -61A, "Military handbook: Configuration Management Guidance", Department of
Defense: United States of America, 2001, p. 3 -5.
[2] http://www.webopedia.com/TERM/D/DNS.html
[3] R. Droms, "Dynamic Host Configuration Protocol", RFC: 2131, 1997
[4] P. Anderson, "Why Configuration Management Is Crucial",The USEN IX Association, ;login: vol.
31(1), 2006, p. 5 -8.
[5] P. Anderson, "System Configuration", The USENIX Association, 2006
[6] B. Vanbrabant, "A framework for integrated configuration management of distributed systems",
KU Leuven – Faculty of Engineering Scie nce, 2014
[7] Eben M. Haber and John Bailey, "Proceedings of the 2007 symposium on Computer human
interaction for the management of information technology", CHIMIT ’07, New York, 2007
[8] http://www.linuxtopia.org/. Accesat la data de 30.08.2016
[9] http:/ /searchsecurity.techtarget.com/definition/firewall
[10] R. Oppliger "Internet Security: FIREWALLS and BEYOND", Communications of the ACM,
1997
[11] http://whatismyipaddress.com/dialup
[12] http://www.tc.etc.upt.ro/teaching/idd -cd/idd -cd-cap5.pdf
[13] J. Ke rnan, "Asymmetrical digital subscriber line (ADSL) an indepth study", Thesis. Rochester
Institute of Technology, 2002. [Online]
http://scholarworks.rit.edu/cgi/viewcontent.cgi?article=1316&context=theses
[14] https://ro.wikipedia.org/wiki/Paravan_(softwa re)
[15] http://www.cisco.com/c/en/us/support/docs/ip/routing -information -protocol -rip/13769 -5.html
[16] http://www.cisco1900router.com/what -is-ios-model -the-overall -explanation -of-ios-7-layers.html
[17] Internet Protocol, RFC: 791, 1981. [Online] https:// www.ietf.org/rfc/rfc791.txt
[18] https://www.techopedia.com/definition/5301/media -access -control -address -mac-address
[19] Steve Suehring, "Linux Firewalls Enhancing Security with nftables and Beyond – Fourth Edition",
Pearson Education, 2015
[20] Transmiss ion Control Protocol, RFC: 793, 1981 [Online]https://www.ietf.org/rfc/rfc793.txt
[21] User Datagram Protocol, RFC: 768, 1980 [Online] https://www.ietf.org/rfc/rfc768.txt
[22] Hypertext Transfer Protocol, RFCs: 2616, 1999 [Online] https://tools.ietf.org/ht ml/rfc2616
[23] http://searchsecurity.techtarget.com/definition/certificate -authority
[24]Karen Scarfone, Paul Hoffman, Guidelines on Firewalls and Firewall Policy, National Institute of
Standards and Technology, 2009
[25] http://www.todaysoftmag.ro/article/1151/automatizare -folosind -puppet
[26] http://www.luxoft -training.ro/news/managementul -sistemelor -cu-puppet/
[27] http://www.aosabook.org/en/puppet.html
[28] https://docs.puppet.com/
[29] http://www.internetsafety.ae/protect -device/firewalls/
[30] http://www.slashroot.in/puppet -tutorial -how-does-puppet -work
[31] https://forge.puppet.com/