Master: Securitatea Tehnologiei Informației SECURIZAREA SISTEMULUI DE FIȘIERE CONDUCĂTOR ȘTIINȚIFIC: Col. conf. univ. dr. ing. Ion BĂDOI ABSOLVENT:… [605044]

ROMÂNIA
MINISTERUL APĂRĂRII NAȚIONALE
ACADEMIA TEHNICĂ MILITARĂ

FACULTATEA DE SISTEME INFORMATICE ȘI SECURITATE
CIBERNETICĂ
Master: Securitatea Tehnologiei Informației

SECURIZAREA SISTEMULUI DE FIȘIERE

CONDUCĂTOR ȘTIINȚIFIC:
Col. conf. univ. dr. ing. Ion BĂDOI
ABSOLVENT: [anonimizat] ____________ file
Inventariat sub nr. _______
Poziția din indicator: _____
Termen de păstra re: ______

BUCUREȘTI
2020

NECLASIFICAT
NECLASIFICAT
1 din 47 Cuprins
Listă de figuri ………………………….. ………………………….. ………………………….. … 3
Listă de abrevieri și cuvinte împrumutate din limba engleză …………………….. 4
Abstract ………………………….. ………………………….. ………………………….. ………… 5
Rezumat ………………………….. ………………………….. ………………………….. ……….. 6
1. Introducere ………………………….. ………………………….. ………………………… 7
1.1 Motivația temei alese ………………………….. ………………………….. …….. 7
1.2 Medii de dezvoltare ………………………….. ………………………….. ………. 7
1.3 Tehnologii folosite ………………………….. ………………………….. ………… 8
2. Proiectarea aplicației ………………………….. ………………………….. …………… 8
2.1 Arhitectură Generală ………………………….. ………………………….. ……… 9
2.2 Diagrama cazurilor de utilizare ………………………….. …………………… 9
2.2.1 Serviciul de Windows ………………………….. ………………………….. 10
2.2.2 Aplicația web ………………………….. ………………………….. ………….. 10
2.3 Diagrama c omponentelor ………………………….. ………………………….. 11
2.4 Diagrama de clase ………………………….. ………………………….. ……….. 12
2.5 Diagrama de secvență ………………………….. ………………………….. …..14
3. Descrierea implementării ………………………….. ………………………….. ……15
3.1 Definirea cerințe lor ………………………….. ………………………….. ……… 15
3.2 Serviciul Windows ………………………….. ………………………….. ………. 17
3.2.1 Crearea structurii unui serviciu ………………………….. ……………… 17
3.2.2 Interfața cu utilizatorul ………………………….. …………………………. 18
3.2.3 Comunicarea cu aplicația web ………………………….. ……………….. 18
3.2.4 Modulul de actualizare al regulilor Yara ………………………….. ….19
3.2.5 Modulul de analiză al fișierelor ………………………….. ……………… 23
3.2.6 Modulul de detec ție al evenimentelor ………………………….. …….. 25
3.2.7 Modulul de programare al evenimentelor ………………………….. ..26
3.3 Aplica ția web ………………………….. ………………………….. ………………….. 27
3.3.1 Structura ………………………….. ………………………….. …………………… 27
3.3.2 Controllerul Home ………………………….. ………………………….. …….. 29
3.3.3 Cont rollerul Cert ………………………….. ………………………….. ……….. 29

NECLASIFICAT
NECLASIFICAT
2 din 47 3.3.4 Controllerul Terminal ………………………….. ………………………….. …30
3.3.5 Controllerul Report ………………………….. ………………………….. …….30
3.3.5 Controllerul Agent ………………………….. ………………………….. …….. 31
3.3.6 Si stemul de notificări ………………………….. ………………………….. ….31
3.4 Securitate ………………………….. ………………………….. ……………………….. 32
3.4.1 HTTPS ………………………….. ………………………….. …………………….. 32
3.4.2 Autentificarea serviciului Windows ………………………….. …………. 33
3.5 Structura bazei de date ………………………….. ………………………….. ……… 34
4. Mod de utilizare ………………………….. ………………………….. ……………….. 37
4.1 Serviciul Windows ………………………….. ………………………….. ………. 37
4.2 Aplicația web ………………………….. ………………………….. ……………… 39
5. Teste ………………………….. ………………………….. ………………………….. ……44
6. Concluzii ………………………….. ………………………….. …………………………. 46
6.1 Posibilități de utilizare ………………………….. ………………………….. ….46
6.2 Direcții de viitor ………………………….. ………………………….. ………………. 46
Bibliografie ………………………….. ………………………….. ………………………….. ….47

NECLASIFICAT
NECLASIFICAT
3 din 47 Listă de figuri
FIG. 2.1 ARHITECTURA GENERALĂ A SISTEMULUI ………………………….. ………………………….. ……… 9
FIG. 2.2 DIAGRAMA CAZURILOR DE UTILIZARE A SERVICIULUI DE WINDOWS ………………. 10
FIG. 2.3 DIAGRAMA CAZURILOR DE UTILIZARE A APLICAȚIEI WEB ………………………….. …….. 11
FIG. 2.4 DIAGRAMA COMPONENTELOR SISTEMUL UI ………………………….. ………………………….. … 12
FIG. 2.5 DIAGRAMA DE CLASE SERVICIU WINDOWS (MODULE PRINCIPALE) ………………….. 12
FIG. 2.6 DIAGRAMA DE CLASE SERVICIU WINDOWS (MODULE SECUNDARE DE LUCRU) .. 13
FIG. 2.7 DIAGRAMA DE CLASE APLICAȚIE WEB (PRESENTATION LAYER) ……………………….. 13
FIG. 2.8 DIAGRAMA DE CLASE APLICAȚIE WEB (DATA LAYER) ………………………….. ……………. 14
FIG. 2.9 PORNIRE SERVICIU, ÎNREGISTRARE TERMINAL ȘI TRIMITERE RAPORT ……………… 14
FIG. 3.1 ARHITECTURA SERVICIULUI ………………………….. ………………………….. ………………………….. 17
FIG. 3.2 STRUCTURA TABELULUI CERTIFICATES.DBO ………………………….. ………………………….. . 35
FIG. 3.3 STRUCTURA TABELULUI TERMINALS.DBO ………………………….. ………………………….. …… 35
FIG. 3.4 STRUCTURA TABELULUI REPORTS.DBO ………………………….. ………………………….. ……….. 36
FIG. 4.1 INSTALAREA SERVICIULUI CU DREPTURI DE ADMINISTRATOR ………………………….. 37
FIG. 4.2 PORNIREA SERVICIULUI ………………………….. ………………………….. ………………………….. …….. 38
FIG. 4.3 PAGINA DE ÎNTÂMPINARE ………………………….. ………………………….. ………………………….. …. 39
FIG. 4.4 LISTAREA CERTIFICATELOR ………………………….. ………………………….. ………………………….. 40
FIG. 4.5 CREAREA ȘI REVOCAREA CERTIFICATELOR ………………………….. ………………………….. … 40
FIG. 4.6 LISTAREA CERTIFICATELOR ………………………….. ………………………….. ………………………….. 41
FIG. 4.7 LISTAREA TERMINALELOR ………………………….. ………………………….. ………………………….. … 41
FIG. 4.8 DETALIILE UNUI TERMINAL ………………………….. ………………………….. ………………………….. . 42
FIG. 4.9 LISTA DE RAPOARTE ………………………….. ………………………….. ………………………….. ………….. 43
FIG. 4.10 DETALIILE UNUI RAPORT ………………………….. ………………………….. ………………………….. …. 43
FIG. 4.11 DETALIILE UNUI RAPORT (CONTINUARE) ………………………….. ………………………….. …… 44
FIG. 4.12 NOTIFICARE RAPORT ………………………….. ………………………….. ………………………….. ………… 44
FIG. 5.1 TEST CU FIȘIERE MICI ………………………….. ………………………….. ………………………….. …………. 45
FIG. 5.2 TEST CU FIȘIERE MARI. ………………………….. ………………………….. ………………………….. ………. 45
FIG. 6.1 POSIBILĂ ARHITECTURĂ A UNEI COMPANII ………………………….. ………………………….. …. 46

NECLASIFICAT
NECLASIFICAT
4 din 47 Listă de abrevieri și cuvinte împrumutate din limba engleză
End-user = Utilizator final (client)
Malware = Aplicație malițioasă
IDE = Integrated development environment (mediu de dezvoltare)
REST = Representational State Transfer
Open -Source = Gratuită
Cross -platform = Multi -platformă
IoT = Internet of Things (Internetul Obiectelor)
Store = Se referă la mediul de stocare specializat pentru certificate din Windows
Header = Antetul cererilor HTTP (Hypertext Transfer Protocol)
Presentation Layer = Funționalități care vor interacționa direct cu utilizatorul
Data Layer = Structuri de date și logică u tilizate la interacțiunea cu baza de date
Load Balancing = Tehnologie de distribuire a cererilor într -un mod optim între
instanțele unui serviciu web
IRP = Pachete de cereri Input/Output
API = Application Programming Interface (set de metode puse la dispoziția
clientului)
Certificates = Certificate PKI (Infrastructură cu cheie publică)
Terminals = Terminale (Stații înregistrate pe platformă)
RAM = Random -access memory
SHA1 = Secure Hash Algorithm 1
E-mail = Poștă electronică
LogIn = Autentificare
Token = Secvență de informații
Framework = Ansamblu standardizat de concepte
LocalSystem = Sistemul Local
Pool = Grupare de fire de execuție
Condition = Condiție
Strings = Șiruri de caractere
Crawler = Bot de internet ce extrage conținut web
URL = Uniform Resource Locator (Adresă Web)
Scrap = Extragere conținut din pagina web
Spider = Referință către un program care extrage date din pagini web
Unique = Unic
Wrapper = API dezvoltat peste o funționalitate care nu putea fi accesată î ntr-un
anumit context
Buffer = Zonă de memorie pentru a stoca date temporar
Swap = Procedură de mutare a datelor din memoria RAM pe memoria non -volatilă
Pipeline = Set de date care procesează elemente conectate în serie, unde datele de
ieșire ale unui element reprezintă datele de intrare pentru alt element

NECLASIFICAT
NECLASIFICAT
5 din 47 Abstract

Pentru multe companii, datele sunt foarte importante și multe dintre ele
asigură securitatea lor. Indiferent de natura datelor stocate pe site sau pe serverele
companiei, securitatea lor tre buie sa fie prioritatea cu numărul 1.
Motivul principal pentru protejarea datelor este de a securiza toate
informațiile stocate. Atunci când este vorba de angajații unei companii, asigurarea
securității datelor acestora pe cât de mult posibil este minimul așteptărilor lor.
Un alt motiv este posibilitatea ca angajații să infecteze stațiile de lucru cu
anumite fișiere malițioase fără ca aceștia să știe neapărat. Din acest motiv, pe lângă
încurajarea bunelor practici atunci când se lucrează cu un calculator, s e poate apela
la o soluție de securizare a sistemului de fișiere.

NECLASIFICAT
NECLASIFICAT
6 din 47 Rezumat

Prezenta lucrare explică o variantă de implementare a unui sistem de
securizare a fișierelor.
Sistemul constă dintr -o aplicație agent care va fi instalată pe stațiile de lucru
ale angajaților și dintr -o aplicație web care va avea rolul de serviciu centralizator.
Agentul este dezvoltat sub formă de serviciu. Acesta rulează în background
fără să intervină în activitatea utilizatorului. Nu prezintă o intefață grafică. Instala rea
se va efectua astfel încât acesta să ruleze cu statut de administrator. Controlul acestui
serviciu se va realiza prin intermediul panoului de control al serviciilor. Scopul
principal al agentului este să detecteze și să scaneze fișierele care au fost c reate sau
modificate pe stația utilizatorului. Toate rapoartele vor fi trimise către serviciul
centralizator.
Serviciul centralizator este o aplicație web, care în mod normal este operată
de echipa de securitate a companiei. Fiecare agent din rețea va apel a un API special
pus la dispoziție și se va autentifica prin intermediul unui certificat. Aplicația
furnizează statistici cu privire la starea generală a terminalelor, posibilitatea de
gestionare a certificatelor de autentificare, vizualizarea stațiilor în registrate din rețea
și analiza rapoartelor.

NECLASIFICAT
NECLASIFICAT
7 din 47 1. Introducere
1.1 Motivația temei alese

Un sistem clasic antivirus, instalat pe o stație end -user, desfășoară, în general,
o singură analiză asupra unui fișier nou. Dacă acesta dă greș, stația poate fi
compromisă. În cazul în care fluxul de fișiere, care se introduc pe stație, este mare,
procesul în sine (de analiză) poate fi un consumator de resurse. Mai mult decât atât,
un astfel de flux mare de fișiere are șanse să blocheze stația.
Externalizarea procesului de detecție malware este o soluție mai scalabilă, mai
puțin consumatoare de resurse, poate fi mai complexă și poate oferi rapoarte din mai
multe analize desfășurate cu programe antivirus diferite.

1.2 Medii de dezvoltare

IDE-ul în care a fost dezv oltată aplicația web cu o arhitectură de tip RESTful
și serviciul de Windows este Visual Studio Community 2019. Acesta este un mediu
de dezvoltare care aparține celor de la Microsoft. Este folosit pentru dezvoltarea
programelor pentru computer, de asemenea și site -uri web, aplicații web, servicii
web și aplicații pentru dispozitive mobile. Visual Studio folosește platforme de
dezvoltare de la Microsoft cum ar fi Windows API, Windows Forms, Windows
Presentation Foundation, Windows Store și Microsoft Silverli ght. Poate produce atât
cod nativ cât și cod gestionat de o mașină virtuală. Visual Studio include un editor
care suportă IntelliSense (componentă pentru completarea codului), de asemenea și
instrumente de restructurare a codului existent fără modificarea comportamentului
extern [1][23].
IDE-ul în care a fost dezvoltat modulul de actualizare cu reguli Yara a
serviciului de Windows este PyCharm Community. Acesta este un mediu de
dezvoltare folosit pentru dezvoltarea programelor pe computer, în principal
speci alizat pentru limbajul Python. Este dezvoltat de compania cehă JetBrains.
Furnizează metode pentru analiza codului, teste integrate, integrare cu sisteme de
control al versiunii, și suportă dezvoltarea de aplicații web cu platforma Django [2].
Gestionarea b azei de date s -a realizat prin intermediul aplicației SQL Server
Management Studio. Acesta este un mediu integrat pentru gestionarea oricărei
infrastructuri SQL. SSMS este folosit pentru a accesa, configura, gestiona,
administra și dezvolta, toate componen tele din SQL Server, baza de date SQL Azure
și SQL Data Warehouse. SSMS oferă un singur utilitar complet care combină un
grup larg de instrumente grafice cu un număr de editori de script -uri pentru a oferi
acces la serverul SQL dezvoltatorilor și administr atorilor cu nivele diferite de
calificare[3] [23].

NECLASIFICAT
NECLASIFICAT
8 din 47 1.3 Tehnologii folosite

Aplicația web s -a dezvoltat cu ajutorul tehnologiei .NET Core (C#). Este o
platformă de dezvoltare open -source , cu scop general, realizată de Microsoft și de
comunitatea .NET pe Github. Este o tehnologie cross -platform (suportă Windows,
macOS, Linux) și poate fi folosită în dezvoltarea aplicațiilor pentru diverse
dispozitive, cloud și IoT [4].
Pentru dezvoltarea serviciului de Windows s -a utilizat C#. Este un limbaj de
programare s implu, modern și orientat pe obiecte. C# își are rădăcinile în familia de
limbaje C. Acesta include suport pentru programarea orientată pe componente.
Arhitectura programelor contemporane se bazează din ce în ce mai mult pe
componente sub forma unor pachet e ce au toate dependințele necesare [5].
SQL (Structured Query Language) este un limbaj folosit în programarea și
structurarea datelor stocate într -un sistem de gestionare a unei baze de date
relaționale (RDBMS). Este util în special în manipularea datelor structurate în cazul
în care există relații între diferite entități sau variabile ale datelor. SQL oferă două
avantaje principale față de versiunile mai vechi de API -uri de citire/scriere cum ar fi
ISAM sau VSAM: primul, a introdus conc eptul de accesare al înregistrărilor cu o
singură comandă; al doilea, elimină nevoia de a specifica modul de accesare a unei
înregistrări, spre exemplu cu sau fără index. SQL constă în mai multe tipuri de
declarații, care pot fi clasate ca sublimbaje: limb aj de interogare al datelor (DQL),
limbaj de definire al datelor (DDL), limbaj pentru controlul datelor (DCL) și limbaj
pentru manipularea datelor (DML). Domeniul de aplicare al SQL include
interogarea datelor, manipularea datelor (inserare, actualizare și ștergere), definirea
datelor (crearea și modificarea schemelor) și controlul accesului la date[6] [23].

2. Proiectarea aplicației

Unified Modeling Language (UML) este un limbaj standard de modelare
destinat vizualizării arhitecturii unui sistem într -o diagr amă. Acesta include
elemente cum ar fi: activități, componentele individuale ale sistemului și cum
interacționează acestea cu componentele software, cum funcționează sistemul, cum
interacționează entitățile între ele (componente și interfețe) și interfața externă cu
utilizatorul. Inițial a fost destinat pentru documentarea sistemelor dezvoltate prin
paradigma programării orientate pe obiecte însă setul de documentare a fost extins
de-a lungul timpului și este folositor în mai multe contexte. UML nu este în sine o
metodă de dezvoltare, totuși a fost construit în așa fel încât să fie compatibil cu
metodele principale de dezvoltare orientate pe obiecte din acele timpuri.

NECLASIFICAT
NECLASIFICAT
9 din 47 Este foarte importantă diferența dintre un model UML și un set de diagrame
al unui siste m. O diagramă este o reprezentare grafică parțială a modelului unui
sistem. Setul de diagrame nu trebuie să acopere complet modelul, iar ștergerea unei
diagrame nu modifică modelul.
Diagramele UML pot reprezenta modelul unui sistem din punct de vedere
static (structural), unde se evidențiază structura statică a unui sistem folosindu -se
obiecte, atribute, operații și relații, sau dinamic (comportamental), unde se
evidențiază comportamentul dinamic al unui sistem prin afișarea colaborărilor dintre
obiecte și a schimbărilor interne de stări ale obiectelor[7] [23].

2.1 Arhitectur ă Generală

Fig. 2.1 Arhitectura generală a sistemului

Un proces va face o cerere de scriere către sistemul de fișiere al terminalului
vizat. Evenimentul de scriere (inclusiv de modifica re) va fi captat de către serviciul
de Windows, fișierul în cauză va fi programat pentru analiză, ulterior fiind selectat
și trimis către ambele module de analiză.

2.2 Diagrama cazurilor de utilizare

Diagrama cazurilor de utilizare este o reprezentare a interacțiunii dintre
utilizator și sistem care arată relația dintre utilizator și diferite cazuri de utilizare în
care este implicat utilizatorul. O astfel de diagramă poate identifica diferite tipuri de
utilizatori ai sistemului și diferite cazuri de utilizare și va fi de obicei acompaniată
de alte tipuri de diagrame[8] [23].

NECLASIFICAT
NECLASIFICAT
10 din 47 2.2.1 Serviciu l de Windows

Serviciul va fi instalat pe terminal de către administratorul de sistem împreună
cu certificatul de autentificare. Certificatul va fi stocat în store -ul mașinii curente, în
zona certificatelor personale , și va putea fi accesat doar de aplicațiile cu drept de
administrator.
La pornirea serviciului, acesta va extrage din store -ul menționat anterior
certificatul și va inițializa un apel , către servic iul web central , de înregistrare.
Certificatul extras va fi atașat în header -ul fiecărui apel pentru autentificare. La
înregistrare se vor trimite informații specifice terminalului.

Fig. 2.2 Diagrama cazurilor de utilizare a serviciului de Windows

2.2.2 Aplicația web

Administratorul sistemului de securitate se autentifică cu nume de utilizator
și parolă. După ce autentificarea s -a realizat cu succes, administratorul are
posibilitatea să vadă terminalele înregistrate și autentificate, certificatele valide sau
revocate, cu care terminalele se autentifică la fiecare cerere, și lista de rapoarte
corespunzătoare unei stații clasificate dupa gradul de risc (Normal, Avertizare sau
Alertă).

NECLASIFICAT
NECLASIFICAT
11 din 47

Fig. 2.3 Diagrama cazurilor de utilizare a aplicaț iei web

2.3 Diagrama componentelor

Diagrama componentelor este folosită pentru modelarea aspectelor fizice ale
sistemelor orientate pe obiecte care sunt folosite pentru vizualizarea, specificarea și
documentarea sistemelor bazate pe componente.
Diagrama de componente „sparge” sistemul actual în curs de dezvoltare
într-o varietate de funcționalități de nivel înalt. Fiecare componentă are un scop clar
în întreg sistemul și interacționează cu alte elemente esențiale doar în momentul în
care schi mbul de informații este necesar[9] [23].
Sistemul pentru securizarea fișierelor se împarte în trei mari component cu
scop bine definit : Serviciul Windows, Aplicația Web (Componenta centralizatoare)
și baza de date.

NECLASIFICAT
NECLASIFICAT
12 din 47

Fig. 2.4 Diagrama componentelor sistemului

Serviciul Windows trimite informa țiile către aplicația web de tip RESTful
prin intermediul metodei POST, aceasta mai departe stochează informațiile primite
în baza de date [23].

2.4 Diagrama de clase

Diagrama de clase este un tip de diagramă cu structură statică care descrie
structura sistem ului prin afișarea claselor, atributele lor, metodele și relațiile dintre
obiecte. Diagrama de clase este principalul bloc de dezvoltare în modelarea orientată
pe obiecte. Este folosită în general în modelarea conceptuală a sistematicii unei
aplicații, și în modelarea detaliată când modelele se vor translata în cod. Diagramele
de clase mai pot fi folosite pentru modelarea datelor. Clasele din diagrama de clase
reprezintă elementele principale, interacțiunile din aplicație și clasele ce trebuie
programate[10 ][23].

Fig. 2.5 Diagrama de clase serviciu Windows (Module principale)

NECLASIFICAT
NECLASIFICAT
13 din 47

Fig. 2. 6 Diagrama de clase serviciu Windows (Module secundare de lucru )

Fig. 2. 7 Diagrama de clase aplicație Web (Presentation Layer )

NECLASIFICAT
NECLASIFICAT
14 din 47

Fig. 2. 8 Diagrama de clase aplicație Web (Data Layer )

2.5 Diagrama de secvență

Diagrama de secvență afișează interacțiunile dintre obiecte aranjate într -o
secvență de timp. Aceasta descrie obiectele și clasele implicate în scenariu și
secvența de mesaje schimbate între obiectele necesare pentru a realiza
funcționalitatea scenariului. Diagramele de secvență sunt de obicei asociate cu
realizarea cazurilor de utilizare în vizualizarea logică a sistemului în curs de
dezvoltare[11] [23].

Fig. 2. 9 Pornire se rviciu, înregistrare terminal și trimitere raport

NECLASIFICAT
NECLASIFICAT
15 din 47 3. Descrierea implementării
3.1 Definirea cerințe lor

Modul de implementare al sistemului pentru securizarea fi șierelor trebuie să
fie scalabil, astfel încât să asigure securitatea pentru un număr mai mare de clienți
în același timp. Cantitatea de monstre trebuie distribuită între serviciile centrale într –
un mod optim (load balancing).
Serviciul de pe stația client, trebuie să aibă toate modulele sincronizate astfel
încât modulul de captare a l evenimentelor de scriere sau modificare în sistemul de
fișiere să funcționeze independent de modulul de analiză malware. Procesul de
analiză a l fișierelor este consumator de resurse și de cele mai multe ori nu va fi la fel
de rapid precum modulul de captare a l evenimentelor.
Procesele vor trimite cereri IRP către sistemul de fișiere. Acestea vor fi captate
de către modulul de detecție în timp rea l. Nu vor fi trimise direct către modulul de
analiză ci vor fi gestionate de modulul de programare al evenimentelor. Acest pas
intermediar este necesar, deoarece fișierele sunt de diferite dimensiuni iar
optimizarea procesului de selecție și prioritizare o feră un avantaj pe partea de
scalabilitate a soluției. Modulul de analiză va funcționa permanent și va încerca
extragerea evenimentelor din modulul de programare. În momentul în care nu există
fișiere, analizorul va intra în starea de așteptare p ână când modulul de programare îl
va debloca și va continua extragerea. Analiza unui fișier se relizează în două moduri :
– Analizor cu reguli Yara: este o analiză statică efectuată prin compilarea
unor fișiere ce conțin structuri Yara și compararea conținutului fiecăr ui
fișier cu secvențele din regulile respective. Dacă secvențele se potrivesc în
fișier, atunci se presupune că fișierul ar fi malițios. Raportul constă dintr-
o listă cu identificatorii care s -au potrivit împreună cu metadatele lor.
– VirusTotal : este o plat form ă ce oferă un API în care se poate încărca un
fișier cu dimensiunea în limita licenței, se analizează de către un set de
programe antivirus, raportul este trimis într -o coadă de așteptare, după care
se trimite o cerere pentru descărcarea raportului.
Serviciul va fi dotat și cu un modul separat de actualizare a l regulilor Yara.
Acesta trebuie sincronizat cu modulul de analiză pentru ca ulterior raportul final să
conțină informații din două surse.
Comunicarea între servicii va fi securizată (TLS) iar modu lul instalat pe stația
client va atașa la fiecare cerere un certificat de autentificare astfel încât un posibil
modul similar și malițios să nu compromită serviciul central cu rapoarte false.
Site-ul va avea un meniu care să permită accesul la toate inform ațiile pe care
serviciul Windows le va extrage.
Acest meniu va conține următoarele taburi :

NECLASIFICAT
NECLASIFICAT
16 din 47 – Home reprezint ă o pagină care furnizează informații prelucrate de interes
general cum ar fi numărul total de terminale înregistrate, numărul total de
fișiere analizate, numărul total de fișiere potențial malițioase, grafic cu
număr de fișiere potențial malițioase în fun cție de zi, top de reguli Yara
care s -au potrivit, top de rezultate malițioase provenite de la VirusTotal,
grafic cu număr de fișiere scanate.
– Certificates reprezintă o pagină care afișează o listă cu toate certificatele
disponibile valide, revocate sau ex pirate. De asemenea, aceasta va oferi
posibilitatea de creare a unor noi certificate de autentificare pentru
terminale pe bază de parolă și semnate cu cheia privată a unui certificat ,
care la rândul său este semnat cu cheia privată a certificatului aplica ției
web cu care se realizează securizarea prin TLS. Pentru fiecare certificat se
vor putea vizualiza detalii cum ar fi: subiectul, autoritatea care l -a generat,
versiunea, data de c ând va deveni valid, data de expirare, amprenta, seria,
dimensiunea și for matul cheii publice. Funționalitatea de revocare
presupune crearea unor liste de revocare semnate cu cheia privată a
certificatului folosit la semnarea certificatelor de autentificare. La
momentul revocării, certificatul va fi eliminat de pe server rămânân d în
baza de date doar detalii despre acesta. Certificatele se vor putea descărca
pe stația client cu exceția celor revocate.
– Terminals reprezintă o pagină care afișează o listă cu toate stațiile
înregistrate pe platformă. Pentru fiecare stație se vor pute a vizualiza
rapoartele asociate și detalii precum: numele sta ției, denumirea sistemului
de operare și versiunea acestuia, adresa MAC, info rmații legate de
procesor și de placa de bază , memoria RAM și câteva detalii despre
certificatul asociat cu care se de sfășoară autentificarea. În momentul în
care certificatul asociat este revocat sau expirat, evenimentul este
semnalizat iar procedurile de soluționare sunt aplicate.
– Reports reprezintă o pagină care afișează lista de rapoarte provenite de la
toate stațiile înregistrate . Acestea sunt marcate în funcție de gradul de risc:
Normal, Avertisment (Galben) și Alertă (Roșu). Pentru fiecare raport se
vor putea vizualiza următoarele detalii : data efectu ării, SHA1 , SHA256,
numărul total de rezultate pozitive provenite de la VirusTotal, numele
stației, denumirea sistemului de operare, listă cu identificatorii Yara care
s-au potrivit împreună cu metadatele lor, listă cu toate programele antivirus
de la VirusTotal împreună cu rezultatele lor și o listă cu mesaje în cazul î n
care au apărut erori în timpul verificărilor.
– Register – platforma oferă posibilitatea de înregistrare cu adresă de e -mail
și parol ă.

NECLASIFICAT
NECLASIFICAT
17 din 47 – LogIn – în urma autentificării cu succes a utilizatorului va rezulta un token
care va fi stocat sub forma unui cookie pe stația clientului.

3.2 Serviciul Windows

În următoarele capitole vor fi prezentați pașii pentru dezvoltarea unui serviciu
de Windows care va putea să satisfacă cerințele prezentate în capitolul anterior. Se
va explica structura unui astfel de proi ect, fișierele importante și anumite clase din
framework.

Fig. 3.1 Arhitectura serviciului

3.2.1 Crearea structurii unui serviciu

Serviciile Microsoft permit crearea unor aplicații executabile de lungă durată
care rulează în propria lor sesiune. Aceste servicii pot fi pornite automat cand stația
bootează, pot fi puse într -o stare de pauză, pot fi repornite și nu prezintă o interfață
pentru utilizator. Sunt ideale pentru realizarea unor procese care să nu interfereze cu

NECLASIFICAT
NECLASIFICAT
18 din 47 activitatea utilizatorului. Aceste servicii pot rula în contextul de securitate al unui
profil diferit față de cel autentificat curent . Serviciul sistemului va fi instalat și va
rula sub statutul de securitate al mașinii pentru a spori accesul privilegiat la unele
funcționalități ale sistemului de operare (LocalSystem) .
Metoda OnStart() indică ce acțiuni ar trebui urmate când serviciul pornește.
Aceasta va fi suprascrisă cu scopul de a inițializa componentele necesare realizării
procesului de monitorizare și analiză. Această metodă va fi apelată în momentul în
care din panoul de control al serviciilor (Service Control Manager) se va apăsa Start.
Panoul de control este singura modalitate de interacțiune cu utilizatorul, drept
urmare , starea serviciului trebuie permanent actualizată prin apelul metodei
SetServiceStatus importată din biblioteca dinamică advapi32.dl l.
Înainte de a porni serviciul, acesta trebuie instalat, ulterior înregistrat prin
intermediul panoului de control. Pentru soluția curentă s -au configurat numele
serviciului, descrierea, numele de afișare (care va apărea în lista de servicii din
panou), tipul de pornire (Automat – acest lucru va permite serviciului să pornească
după bootarea calculatorului) și statutul cu care acesta va rula pe stația client
(Local System) . Implicit, executabilul rulează sub contextul utilizatorului curent
autentificat și nu va putea accesa store -ul de certificate personale din LocalSystem ,
unde este instalat certificatul de autentificare generat pe server.
Metoda Run() este punctul de intrare pentru serviciu. În acest punct s -a
configurat metoda de jurnalizare a erorilor și excepțiilor ce pot apărea în timpul
rulării serviciului. Toate mesajele vor fi disponibile în aplicația EventViewer din
Windows.

3.2.2 Interfața cu utilizatorul

Serviciul nu prezintă o interfață cu utilizatorul. Singura cale de comunicare
între serviciu și administratorul de sistem se realizează prin panoul de control.
SystemControlManager este pornit la bootarea calculatorului. Acesta este un server
către care servic iile trimit informații cu privire la starea lor de rulare. Stările se
clasifică în : START_PENDING, RUNNING, CONTINUE_PENDING,
PAUSE_PENDING, PAUSE, STOP_PENDING și STOPPED.

3.2.3 Comunicarea cu aplicația web

Comunicarea cu aplicația web se va realiza cu ajutor ul unui modul separat ce
primește un obiect INetJob. Fiecare subclasă a interfeței INetJob trebuie să
implementeze metoda asincronă ExecuteAsync(). Modulul va prelua aceste cereri și
va executa metoda menționată anterior într -un fir de execuție separat pen tru
optimizarea transferului de informații.

NECLASIFICAT
NECLASIFICAT
19 din 47 Pentru realizarea acestui flux s -a utilizat clasa ThreadPool. Aceasta furnizează
un pool de fire de execuție care poate fi utilizat la execuția unor sarcini, unor procese
I/O asincrone sau firele de execuție se p ot aștepta între ele pentru finalizarea unor
sarcini. În momentul în care ThreadPool reutilizează un fir de execuție din grup, nu
șterge conținutul vechi din spațiul de depozitare local , drept pentru care s -au luat
măsuri suplimentare de ștergere pentru a nu afecta informațiile din rapoartele trimise
anterior. Metoda asincronă din INetJob este trimisă ca referință către metoda
QueueUserWorkItem ce deleagă sarcina către un fir de execuție.
Există dou ă tipuri de subclase ce implementează interfața INetJob :
– EnrollmentJob – este grupul de instrucțiuni care se execut ă la pornirea
serviciului. Acest a este necesar pentru înregistrarea terminalului pe
platforma de centralizare. Informațiile extrase sunt : nume le sta ției,
denumirea sistemului de operare, versiunea sistemului de operare, adresa
MAC, informații legate de procesor și placa de bază și cantitatea de RAM.
Modulul central (Engine) se înregistrează la EnrollmentJob și așteaptă
răspunsul cu succes al ser verului. În cazul unei înregistrări realizat e cu
succes, modulul central pornește modulul de actualizare a l regulilor Yara
și firul de execuție ce va extrage permanent evenimente din modulul de
programare.
– NetScanJob – este grupul de instrucțiuni care se execută în momentul în
care modulul central primește o notificare de analiză realizată cu succes.
Este instanțiat cu informația primită (informații ce provin de la cele două
submodule de analiză a le fișierelor) și trimis către execuție . În cazul în care
răspunsul de la aplicația web este o excepție, informația din NetScanJob
este stocată local și criptată în contextul statutului aplicației
(LocalSystem). Pentru criptare s -a utilizat clasa DataProtectionScope cu
opțiunea CurrentUser. Datele protejate nu vor p utea fi decriptate decât de
procesele care vor avea statut de LocalSystem. După fiecare analiză
realizată cu succes, înainte de adăugarea raportului într -o instanță se
verifică dacă există fișiere care nu au fost trimise în urma unei erori de
transmitere. Toate informațiile sunt stocate într -o listă de NetJobScan și
trimise spre execuție.
Ambele subclase de INetJob trebuie să atașeze un certificat X509 în antetul
cererii HTTP. Certificatul se obține din store -ul LocalComputer și este căutat după
numele auto rității emitente.

3.2.4 Modulul de actualizare a l regulilor Yara

Regulile Yara sunt un mod de identificare a fișierelor malițioase prin crearea
unor reguli care caută anumite caracteristici.

NECLASIFICAT
NECLASIFICAT
20 din 47 Fiecare regulă trebuie să înceapă prin cuvântul rule urmând numele de
identificare. Acest nume poate conține orice caracter alfanumeric și caracterul
underscore , însă primul caracter nu trebuie să fie cifră. Regulile sunt compuse din
câteva secțiuni. Secțiunea condition este singura care trebuie să fie obligatorie.
Această secțiune specifică condiția de adevărat sau fals din rezultatul regulii pentru
fișierul aflat sub investigație. Secțiunea Strings dă secțiunii Condition un înțeles.
Aici se pot defini șirurile de caractere ce se vor căuta în fișier. Există câteva tipuri
de șiruri care se vor căuta: hexazecimal, text, expresii regulate, ș.a. Metadatele sunt
folosite pentru a identifica fișierele care s -au potrivit cu o anumită regulă. Valorile
pot fi șiruri de caractere, numere întregi ori adevărat sau fals. Valoril e stocate în
această secțiune nu pot fi folosite în secțiunea de condiții, singurul lor scop este să
stocheze informații suplimentare despre regulă [11].
Modulul de actualizare este pornit în momentul în care înregistrarea
terminalului se realizează cu succ es. Modulul central se înregistrează la modulul de
actualizare iar în momentul în care prima descărcare are loc, firul de execuție ce
extrage evenimente din modulul de programare poate începe fluxul de analiză.
Execuția fluxului începe prin pornirea unui p roces din serviciul de Windows
care să apeleze programul de actualizare. Acest proces se va executa independent de
serviciu, presupune utilizarea aplicației Command Prompt, nu va crea o fereastră de
CommandPrompt (dotorită statutului de execuție a l servici ului) și nu va utiliza
PowerShell. Finalizarea acestuia este așteptată în cadrul aceluiași fir de execuție.
Următorul apel este realizat după șaizeci de minute. Scopul acestei așteptări este de
a nu aglomera rețeaua cu trafic inutil. Frecvența de actualiza re a regulilor nu este
mare, drept urmare nu este necesară apelarea continuă a procesului.
Programul extern apelat din serviciu este alcătuit dintr -o serie de scripturi
scrise in limbajul de programare Python. Acesta este un program de tip web crawler .
Un web crawler , este un bot de internet care caută în World Wide Web după
anumite informații. Motoarele de căutare în internet și alte pagini Web folosesc
astfel de programe pentru actualizarea conținutului respectiv pentru actualizarea
indicilor.
Un crawler consumă resursele sistemelor pe care le vizitează și deseori
vizitează pagini fără aprobare. Probleme legate de frecvența cererilor, programare și
“polite țe” vin în joc atunci când sunt accesate colecții mari de pagini. Există
mecanisme pentru paginile web publice care nu doresc să fie accesate de către un
bot și vor ca aceste restricții sa fie cunoscute de către agentul de crawl. Spre exemplu,
fișierul robots.txt poate cere boților să indexeze anumite pagini din site sau să nu
mai acceseze nimic.
Un Web Cr awler începe cu o listă de URL -uri, numite semințe (termen utilizat
pentru a indica rădăcina de unde a început programul să indexeze). În timp ce
crawlerul vizitează aceste URL -uri, identifică toate adresele din pagini și le adaugă

NECLASIFICAT
NECLASIFICAT
21 din 47 într-o listă de URL -uri pentru a le vizita în viitor. Procesul de vizitare se desfășoară
recursiv în conformitate cu politicile de implementare și scop. Crawlerul poate stoca
doar pagini HTML în fișiere distincte. De obicei se utilizează o funcție de HASH
pentru diferențierea num elor de fișiere. Există anumite platforme de implementare a
unor astfel de programe ce permit configurarea restricției de unicitate pentru URL –
uri, astfel încât să se accelereze procesul de vizitare. Problema de unicitate este una
des întâlnită deoarece o pagină web poate furniza utilizatorului mai multe variante
de a ajunge la aceeași resursă, drept urmare vor exista descărcări pentru același
conținut destul de frecvent.
Comportamentul unui Web Crawler este dat de rezultatul unei combinații
dintre următoarele politici:
– Politica de selec ție care spune ce pagini să fie vizitate
– Politica de revizitare care spune ce pagini să fie verificate pentru
modificări
– Politica de “polite țe” care stabilește cum să se evite supraîncărcarea site-
urilor Web
– Politica de paralelizare care stabilește coordonarea unui grup de crawlere
Un crawler nu trebuie să aibă doar o strategie bună de navigare, ci trebuie să
aibă la bază o arhitectură foarte optimizată. Neglijarea acestor două mențiuni poate
duce la un consum mare de resurse al mașinii de pe care se execută programul.
Un crawler de obicei se identifică unui site web printr -un câmp numit User –
Agent din tr-o cerere HTTP. Administratorii de site -uri web verifică de obicei lista
de evenimente (logs) pentru a determina ce bo ți au vizitat paginile și cât de frecvent.
Câmpul poate conține un URL de unde administratorul poate afla informații [12].
Programul utilizat în sistemul de securizare a l fișierelor pentru actualizarea
regulilor s -a dezvoltat având la bază biblioteca open -source Scrapy.
Scrapy este un framework de web crawling și web scraping rapid, de nivel
înalt, folosit pentru a extrage date structurate din paginile web. Spiders sunt cl ase
care definesc modul în care un site (sau un grup de site -uri) vor fi accesate (în
general, accesarea recursivă a adreselor web) și cum vor fi extrase datele structurate
din pagini. Se poate configura un flux pentru un anumit comportament ce va
satisfac e cerințele necesare [13].
Pentru un spider un flux complet se desfășoară în felul următor :
– Se ini țializează cereri de crawl cu primele adrese web și se implementează
o metodă unde va fi gestionat răspunsul cu conținutul descărcat. Primele
cereri sunt obțin ute prin apelarea metodei start_requests() care generează
cereri pe baza adreselor web din câmpul start_urls iar în metoda parse() se
gestionează răspunsurile.
– În metoda parse, se parcurge conținutul paginii web din răspuns și se
returnează fie date struc turate, obiecte de tipul Item (în general utilizate

NECLASIFICAT
NECLASIFICAT
22 din 47 pentru descărcarea fișierelor) sau alte cereri pentru a implementa
parcurgerea recursivă. Aceste cereri vor avea o metodă de gestionare a
răspunsurilor (de obicei aceiași).
– Pentru gestionarea răspunsurilo r se folosesc anumiți selectori cu ajutorul
cărora se construiesc datele structurate facilitând parcurgerea optimizată a
conținutului HTML.
– Într-un final, datele sunt stocate într -o bază de date sau salvate în fișiere
printr -un mecanism gata implementat.
În contextul sistemului de securizare s -a utilizat un Spider comun și anume
CrawlSpider . Motivația a fost mecanismul avansat de accesare a l adreselor web din
pagini prin utilizarea unor reguli. Acestea trebuie definite într -un câmp al clasei sub
formă de l istă. Fiecare regulă definește un anumit comportament de parcurgere a l
site-ului. Dacă mai multe reguli, se potrivesc pe o singură adresă, va fi luată în
considerare prima regulă. Comportamentul de parcurgere se configurează cu ajutorul
clasei LinkExtracto r. Pentru fiecare adresă extrasă, aceasta generează un nou apel.
Scriptul va porni de la o adresă de GitHub care conține mai multe fișiere cu
extensia *.yar. Pentru o parcurgere optimă, s -au utilizat două reguli:
– Prima regul ă stabilește ce adrese din cadru l paginii să fie accesate recursiv.
O condiție necesară este setarea atributului unique pentru a se evita cât de
mult posibil extragerea aceluiași conținut. Împreună cu definirea unor
expresii regulate, extragerea va fi una optimă. Acest lucru este posibil
deoarece este mai ușor de optimizat parcurgerea unui site în particular
decât crearea unor condiții pentru parcurgerea unui grup mai mare de site –
uri, având în vedere dinamica cu care administratorii schimbă structurile.
– A doua regulă stabilește dacă adre sa web respectivă este un fișier cu
extensia *.yar. În caz ul de validare a l condiției, adresa se accesează iar
modul de prelucrare al răspunsului se realizează în parse_item(). De
asemenea, se va configura câmpul unique pentru evitarea descărcării
aceluiaș i fișier. În parse_item() se extrage din pagina web adresa care
trimite către conținutul efectiv al fișierului, după care acesta se trimite spre
descărcare. Această funționalitate se desfășoar ă independent de acțiunea
de parcurgere. Scrapy furnizează o sui tă de clase Item Pipelines cu care se
pot descărca diverse fișiere. Acestea nu vor descărca fișiere care au fost
descărcate recent, locația se poate configura manual iar numele fișierelor,
implicit, este reprezentat de un algoritm de hash. Pentru păstrarea
lizibilității și pentru o administrare ușoară, fluxul a fost schimbat astfel
încât să fie păstrată denumirea inițială a fișierului.
Programul a necesitat câteva setări în plus pentru o parcurgere a site -ului cât
mai eficientă și mai puțin intrusivă. Luând în considerare politicile comportamentale
menționate anterior, crawlerul a fost configurat în felul următor :

NECLASIFICAT
NECLASIFICAT
23 din 47 – Num ărul maxim de apeluri concurente este setat la zece.
– Numărul maxim de fire de execuție pentru gestionarea cererilor este setat
la zece.
– Numărul maxim de apeluri concurente pe domeniu este 2.
– Adâncimea maximă de parcurgere este stabilită la 8.
– În cazul în care descărcarea unei pagini sau a unui fișier durează mai mult
de nouăzeci de secunde, se mai încearcă o singură dată descărcarea. Dacă
se atin ge al doilea eșec, cererea este abandonată.
– Nu se admit mai mult de 1500 de cereri pentru un singur domeniu.
– Fiecare descărcare se va desfășura cu o întârziere de 0.25 de secunde.
Aceste configurări au fost necesare din cauza politicilor de administrare a
platformei GitHub. În cazul în care nu sunt luate aceste măsuri, GitHub poate
respinge cererile trimițând un cod HTTP de 403. Cererea este înțeleasă de aplicația
web iar datele din cerere sunt valide, însă aceasta refuză să rezolve cererea. Acest
lucru poa te apărea atunci când un utilizator nu este autentificat, trebuie să aibă
anumite permisiuni de acces sau parcurge site -ul cu un comportament care nu este
tolerat de către server.
Comanda asincronă provenită din serviciu este compusă din trei părți:
– Schimb area directorului de lucru c ătre
ProgramData/YaraAgent /YaraScrapper .
– Activarea mediului de execuție virtual. Acest pas este necesar pentru
interpretarea scripturilor de Python și pentru rezolvarea dependințelor
necesare bibliotecii Scrapy.
– Sintaxa comenzii de execuție a unui script din Scrapy.

3.2.5 Modulul de analiză a l fișierelor

Modulul de analiză se inițializează în cadrul modului central. Ulterior acesta
se și înregistrează pentru gestionarea analizelor desfășurate cu succes.
Modulul se apelează, în cadrul firului de execuție care rulează permanent
pentru extragerea evenimentelor din modulul programator, prin metoda ScanFile
unde se trimite calea către fișierul respectiv. Fluxul utilizează tot un pool de fire de
execuție (similar cu cel m enționat la modulul de comunicare cu aplicația web) iar
fiecare cerere de scanare va fi tratată independent de celelalte. Modulul lucrează cu
instanțe de gestionare a fluxului intern și anume InternalJob. Aceasta este o clasă
abstractă care trebuie să conț ină permanent calea absolută către un fișier. Instanța
concretă utilizată este ScanJob și va implementa funcționalitatea de extragere a
dimensiunii fișierului utilizată în cadrul celor două submodule de analiză.
Primul submodul se numește YaraScanner. Aces ta efectuează o analiză statică
asupra fișierelor comparând regulile descărcate de crawler cu fișierul trimis către

NECLASIFICAT
NECLASIFICAT
24 din 47 analiză. Biblioteca integrat ă în acest submodul se numește YaraSharp care este un
wrapper peste biblioteca YARA din cadrul platformei VirusT otal. Scopul ei este să
ajute analiștii să identifice și să clasifice monstre de programe malițioase.
Primul pas în utilizarea bibliotecii este de compilare a regulilor Yara. Acest
lucru se efectuează în momentul în care modulul de actualizare execută prim a
descărcare, iar modulul central inițializează modulul de analiză. După finalizarea
fluxului , modulul central șterge înregistrarea din modulul de actualizare. Acestă
măsură a fost luată cu scopul de a nu modifica regulile în timp ce fluxul de detecție
și analiză funționează, deoarece există riscul de apariție a unor conflicte de acces
între firele de execuție. Pentru păstrarea regulilor actualizate la zi, serviciul le va
prelua de fiecare dată când terminalul este pornit. Un alt motiv pentru care
compilare a regulilor o singură dată de la pornirea serviciului este necesară, este
faptul că firele de execuție din pool păstrează datele vechi din spațiul de depozitare.
Compilarea regulilor ocupă aproximativ 190 de MB din memoria RAM. Dacă
fiecare fir de execuție recompila regulile în contextul unei frecvențe mari de analiză
a fișierelor, terminalul nu mai avea suficientă memorie pentru a lăsa serviciul pornit,
drept urmare un semnal era trimis pentru închiderea forțată a aplicației. Cu
configurația curentă, fieca re fir de execuție reutilizează regulile gata compilate,
eliminând riscurile menționate anterior. După analiza fișierului în cauză, se parcurge
lista cu regulile care s -au potrivit. În completarea raportului de analiză, din fiecare
regulă Yara se extrag identificatorul și metadatele (informații despre regula
respectivă ce pot să includă autorul, impactul, referința către informații
suplimentare, descrierea, data de creare, ș.a.). Dacă pe parcursul analizei apare o
excepție, aceasta este adăugată ca mesaj în structura de date ce constituie raportul
final care este trimis către aplicația web.

Al doilea submodul se numește VirusTotalScanner. Aici s -a dezvoltat o
integrare cu platforma VirusTotal pentru un raport mai detaliat. Informațiile extrase
sunt:
– Șirul d e identificare al analizei care este o concatenare între SHA256 și un
număr identificator
– SHA1 și SHA256 utilizate pentru a verifica integritatea analizei
– Numele fișierului analizat
– Numărul total de rezultate pozitive
– Numărul total de analize efectuate de diferite programe antivirus
– Data în care s -a efectuat analiza (Aceasta a fost modificată cu data curentă
a terminalului. VirusTotal completează cu data din fusul orar în care sunt
amplasate serverele)
– Lista cu toate programele antivirus utilizate, versiune a curentă și rezultatul
analizei

NECLASIFICAT
NECLASIFICAT
25 din 47 VirusTotal face o inspecție care implică peste 70 de programe antivirus și
servicii care furnizează o bază de date cu domenii sau URL -uri malițioase.
VirusTotal oferă o varietate de metode POST publice, incluzând pe cele di n interfața
web, programe desktop de încărcare, extensii de navigator web și un API. Interfața
web are prioritatea cea mai mare față de celelalte metode puse la dispoziție.
Rezultatele provenite din analize, care sunt concludente și utile, sunt distribuite către
parteneri pentru îmbunătățirea metodelor de detecție a programelor malițioase.
Semnăturile virușilor sunt actualizate în timp real de către VirusTotal prin
intermediul companiilor partenere. Acest lucru asigură faptul că platforma folosește
ultimele versiuni din seturile respective . Scanările efectuate asupra site -urile web se
realizează prin trimiterea unor cereri către bazele de date a le partenerilor care au fost
puse la dispoziția platformei VirusTotal , iar în alte cazuri , cereri către companii care
dezvoltă soluții antivirus. Imediat ce un partener actualizează baza de date cu
versiuni noi de semnături, acest lucru se reflectă instant în rapoartele rezultate din
analiză.
Pe lângă partenerii oficiali ai platformei, VirusTotal oferă posib ilitatea
clienților finali să comenteze asupra unor rapoarte cu scopul îmbunătățirii și
eliminării rezultatelor pozitive false [14].
Pentru submodulul din serviciu s -au utilizat 3 metode din API.
– ScanFile() ce primește ca parametrii fișierul într -o secvență de octeți și
numele fișierului.
– GetReport() ce primește ca parametru rezultatul SHA256 din scanarea
fișierului. Există o întârziere până când raportul este disponibil pentru
descărcare. Acesta poate fi pus într -o coadă sau poate să nu fie disponib il
deloc. Soluția este implementarea unui număr maxim de încercări (în cazul
curent 3) cu o întârziere de o secundă între ele. În cazul în care raportul nu
este disponibil după consumarea încercărilor, este adăugat un mesaj de
excepție în raportul final.

3.2.6 Modulul de detec ție al evenimentelor

Acest modul este inițializat la pornirea serviciului în modulul central. El
funcționează independent de toate celelalte module. Modulul central se înregistrează
la modulul pentru programarea evenimentelor. În momentul în care are loc un
eveniment de scriere sau modificare a l unui fișier, se apelează două metode de
gestionare a evenimentelor, FileSystemWatcher_Created() respectiv
FileSystemWatcher_Changed(). Acestea primesc ca parametru obiectul de tip
FileSystemEventArg s de unde se extrage calea absolută către fișierul în cauză.
Modulul central, fiind înregistrat la modulul de detecție, primește o înștiințare, după
care fișierul respectiv este trimis către programare pentru analiză.

NECLASIFICAT
NECLASIFICAT
26 din 47 Pentru detectarea evenimentelor de cr eare respectiv modificare a le unui fișier
s-a utilizat clasa FileSystemWatcher din frameworkul .NET. Aceasta ascultă
modificările ce se produc la nivelul sistemului de fișiere dându -se un director anume.
Se pot urmări, de asemenea, și modificările fișierel or și subdirectoarelor din
directorul vizat. În contextul serviciului, modulul de detecție a fost configurat să
urmărească modificările produse la nivelul sistemului de fișiere din fiecare partiție
a sistemului de operare într -un mod recursiv. Informațiile despre partiții s -au extras
utilizând clasa DriveInfo, iar pentru fiecare partiție în parte s -a configurat câte o
instanță de FileSystemWatcher. Motivul acestei abordări este faptul că
FileSystemWatcher este configurat să monitorizeze calea unui singur di rector, drept
urmare fiecare instanță este configurată cu directorul rădăcină al fiecărei partiții.
Detecția este concentrată pe crearea și modificarea fișierelor și nu a directoarelor.
Sistemul de operare Windows notifică componenta de serviciu în legătu ră cu
modificările la nivelul sistemului de fișiere printr -un buffer pus la dispoziție de
FileSystemWatcher [15]. Dacă sunt foarte multe modificări într -un timp scurt,
bufferul se poate supraîncărca. Acest lucru cauzează pierderea unor evenimente de
către c omponentă. Se poate modifica dimensiunea bufferului prin proprietatea
InternalBufferSize, însă acest lucru nu este recomandat, deoarece memoria alocată
în plus nu este paginată, deci nu se poate aplica procedura de swap pe disc. Bufferul
trebuie sa fie men ținut cât mai mic, însă destul de mare pentru a nu pierde
declanșarea unor evenimente. Filtrarea directoarelor s -a realizat prin proprietatea
NotifyFilter iar acest lucru diminuează probabilitatea de pierdere a evenimentelor.
Alți factori care contribuie l a diminuarea pierderilor sunt vizarea exclusivă a
evenimentel or de creare și modificare a le fișierelor și numărul de instanțe de
FileSystemWatcher care pun la dispoziție mai multe buffere.

3.2.7 Modulul de programare a l evenimentelor

Acest modul, ca toate cele prezentate p ână acum, este inițializat în modulul
central. În momentul în care apare un eveniment de scriere sau modificare a l unui
fișier, modulul de programare îl gestionează astfel încât să fie extras, la momentul
potrivit, de către modulul de anal iză.
Gestionarea unui eveniment se realizează prin metoda
ScheduleJobForScanning() care primește ca parametru un obiect de tipul
ScheduleJob. Acest tip de obiect face parte din categoria de comunicare internă,
precum ScanJob, care de asemenea moștenește cl asa abstractă InternalJob. În
momentul în care ScheduleJobForScanning() se apelează, modulul de programare
se înregistrează la instanța de ScheduleJob, după care apelează metoda
ExecuteFileChecker() din cadrul instanței. În acest moment se pornește un fir de
execuție care verifică dacă fișierul este disponibil pentru citit. Dacă metoda de

NECLASIFICAT
NECLASIFICAT
27 din 47 verificare întoarce fals, acesta așteaptă o secundă după care revine cu verificarea.
Când fișierul este disponibil, i se setează nivelul de prioritate, utilizat ulterior î n
procesul de extragere pentru analiză, în funție de mărimea acestuia după cum
urmează :
– SMALL are prioritatea cea mai mare
– MEDIUM cu o prioritate de mijloc
– BIG cu prioritatea cea mai mica
După terminarea configurărilor, se anunță modulul de programare. În funcție
de prioritatea aleasă, acesta stochează evenimentul în una dintre cele 3 liste,
clasificate după nivelul de prioritate și protejate în cazul în care are loc un acces
concurențial. Dacă sunt identificate fișiere cu aceeași cale absolută, atunci cel din
urmă fișier este ignorat. Tot în această metodă se anunță firul de execuție, care se
ocupă de extragerea evenimentelor pentru analiză, cum că există cel puțin un
eveniment pregatit într -una din cele 3 liste.
Extragerea evenimentelor din liste se realiz ează prin metoda
FetchJobForScannig(). Dacă niciun eveniment nu este disponibil, se întoarce
valoarea null iar firul de execuție apelant se blochează și așteaptă un semnal de la
metoda explicată anterior. Extragerea se realizează după un algoritm care, în cazul
în care sunt disponibile evenimente cu fiecare prioritate, trebuie să întoarcă o
secvență alcătuită din 5 evenimente SMALL, două evenimente MEDIUM și una
BIG. Dacă nu sunt disponibile evenimente cu prioritate mare, se trece la următoarea
prioritate. Dacă s -au întors evenimente cu o anumită prioritate până la epuizarea
numărului stabilit, în lista respectivă încă sunt disponibile evenimente iar în listele
cu evenimente de prioritate inferioară nu există niciun element , atunci se va întoarce
un element tot cu aceeași prioritate chiar dacă se depășește limita stabilită de
algoritm pentru a nu se bloca fluxul de extragere.

3.3 Aplica ția web

În următoarele capitole se vor explica pașii pentru construirea unei aplicații
web cu funcționalitate RESTful. Se v or aborda subiecte precum structura unui site
de acest tip, ce tehnologi i s-au utilizat și c um s -a realizat comunicarea cu baza de
date[23].

3.3.1 Structura

Arhitectura folosită în dezvoltarea proiectului este MVC (Model -View –
Controller). Aceasta separ ă o aplicație în trei componente principale : Model, View
și Controller. Acest model arhitectural ajută la crearea unor aplicații care sunt mai

NECLASIFICAT
NECLASIFICAT
28 din 47 ușor de testat și mai ușor de actualizat decât aplicațiile obișnuite. Aplicațiile
dezvoltate cu MVC conțin :
– Modele: Sunt clasele care reprezint ă datele unei aplicații. Modelele
folosesc o logică de validare a datelor pentru a forța cerințele clientului
pentru un set de date. În mod obișnuit, obiectele model preiau și stochea ză
date în baza de date.
– View -uri: Sunt componentele care afișează interfața grafică clientului. În
general, interfața afișează datele dintr -un model.
– Controllere : Sunt clasele care gestionează cererile provenite de la
navigatorul web. Acestea primesc modele cu date și apelează un view
pentru întoarcerea unui răspuns. Într -o aplicație de tip MVC, view -ul doar
afișează informații iar controller -ul gestionează și răspunde datelor de
intrare ale utilizatorului și interacțiunilor acestuia. Spre exem plu,
controller -ul se ocupă de datele din rută (calea către o resursă din adresa
web) și furnizează informațiile către un model. Modelul poate folosi
informațiile pentru a face interogări în baza de date. Spre exemplu,
https://localhost:port/Agent/Enroll are ruta Agent (controller) și Enroll
(acțiunea din controllerul Agent). Fiecare metodă din controller reprezintă
o acțiune către care un client poate face o cerere HTTP.
Modelul architectural MVC ajută la crearea unor aplicații care separă diferite
aspecte din aplicație (date de intrare, logica cu structure de date și logica de
interfață), în același timp, legăturile dintre elemente sunt slabe, ceea ce duce la o
administrare mai eficientă. Acest model spe cifică unde trebuie să fie poziționat
fiecare tip de logică. Logica de interfață aparține view -urilor. Datele de intrare se
încadrează în controllere. Structurile de date sunt gestionate cu modele. Această
separare ajută la gestionarea complexității în tim pul dezvoltării aplicației, deoarece
permite dezvoltarea în particular al unui aspect din implementare fără a crea un
impact asupra codului din altă secțiune. Spre exemplu, se poate lucre la un view fără
a depinde în vreun fel de structurile de date [16]. Representational State Transfer
(REST) este un stil arhitectural care definește un set de constrângeri și proprietăți
bazate pe HTTP. Serviciile web care intră în conformitate cu stilul arhitectural
REST, furnizează interoperabilitate între calculatoarele d in internet. Serviciile web
RESTful permit sistemelor solicitante să acceseze și să manipuleze resursele web
utilizând un set predefinit și uniform de operații stateless (niciuna din părțile
comunicante nu reține vreo informație legată de stare). Într -un servicu RESTful,
cererile realizate către o resursă prin URI vor determina un răspuns care poate fi în
HTML, XML, JSON sau alte formate. Răspunsul poate confirma că s -a produs o
alterare a resursei stocate. Când este folosit HTTP, fiind și cel mai comun, op erațiile
disponibile sunt GET, POST, PUT, DELETE și alte metode CRUD (create, read,
update, delete) predefinite HTTP [17][23].

NECLASIFICAT
NECLASIFICAT
29 din 47 3.3.2 Controllerul Home

Controllerul Home va gestiona fluxul de pe pagina de pornire a aplica ției web.
Acesta conține două metode : Index și Error. Index va fi apelat din meniul de navigare
cu zona Admin (zonele sunt utilizate în .NET Core pentru a grupa mai multe
controllere), controllerul Home și acțiunea Index.
Index are rolul de a interoga baza de date pentru a obține informațiil e care
trebuie afișate în view. Această acțiune va prelua setul de date din tabelul cu
potrivirile Yara în ordinea descrescătoare a numărului de apariții , pentru inițializarea
graficului de tip plăcintă care afișează cele mai întâlnite reguli în cadrul fiș ierelor
posibil malițioase, setul de date cu rezultatele provenite din platforma VirusTotal tot
în ordinea descrescătoare aparițiilor, numărul total de fișiere posibil malițioase în
funcție de zi, numărul total de analize pe zi, numărul stațiilor înregistr ate și numărul
total de analize cu rezultat posibil malițios. Toate aceste informații sunt preluate de
la toate stațiile înregistrate și pot fi utile într -un raport de verificare a tendițelor de
dezvoltare a le aplicațiilor malițioase în general. Amchart este biblioteca utilizată
pentru configurarea graficelor și este dezvoltată în JavaScript și TypeScript.
Interacțiunea utilizatorului cu această pagin ă este destul de restrânsă. Acesta
poate interacționa doar cu graficele puse la dispoziție și să extragă un sumar util cu
privire la activitatea din organizația în care este instalată soluția.

3.3.3 Controllerul Cert

În cadrul acestui controller se definește funcționalitatea de gestionare a
certificatelor pentru c lienți. Acesta conține următoarele acțiuni: Index, Create,
Details, Revoke și Download.
Index va fi apelat din meniul de navigație și este responsabil cu afișarea
paginii principale din aceasă secțiune. Aici se regăsește lista tuturor certificatelor
client disponibile pentru descărcare sau revocate , afișate într -o manieră intuitivă.
Crearea certificatelor presupune introducerea intervalului de valabilitate și a
parolei pentru certificatul emitent. Acest certificat este stocat local pe server într -un
fișier cu extensia pfx , este protejat cu parolă și este semnat de către certificatul
principal al aplicației utilizat în crearea sesiunii TLS. În criptografie, PKCS#12
definește o arhivă pentru stocarea a diverse obiecte criptografice într -un singur fișier.
În ge neral este folosit pentru a asocia o cheie privată cu un certificat din formatul
standardului X509 sau pentru a asocia toți membrii cu un lanț de încredere. Un fișier
PKSC#12 poate fi criptat și semnat. Containerele interne, numite “SafeBags”, pot,
de asem enea, să fie criptate și semnate. Câteva containere sunt configurate să
stocheze certificate, chei private și liste de revocare (CRL – Certificate Revocation
List). Extensia acestor fișiere este .p12 sau .pfx [18].

NECLASIFICAT
NECLASIFICAT
30 din 47 Revocarea unui certificat presupune creare a unei liste de revocare unde se
introduce seria certificatului în cauză. Acest CRL este semnat tot cu cheia privată a
certificatului utilizat în generarea certificatelor pentru clienți. Toate listele sunt
stocate local pe server. În criptografie, o listă de revocare a certificatelor (CRL) este
o listă de certificate digitale care au fost revocate de către autoritatea emitentă (CA)
înainte de data la care certificatul nu mai este valid. Atât revocarea cât și crearea
unui certificat se face pe baza parolei c are protejează fișierul .pfx salvat local pe
server.
La apelarea acțiunii Details se deschide un modal ce conține mai multe
informații despre certificatul respectiv. Toate detaliile au fost enumerate în
capitolele anterioare.
Acțiunea Download permite admi nistratorului să descarce certificatul ales și
să-l instaleze pe mașina client unde este necesară autentificarea serviciului.
Toate operațiile criptografice de gestionare a certificatelor client s -au realizat
cu ajutorul bibliotecii BouncyCastle. Această b ibliotecă este o colecție de API -uri
folosite în criptografie. Aceasta include atât API -uri pentru Java cât și pentru C#.

3.3.4 Controllerul Terminal

Acest controller este responsabil cu afișarea listei de terminale înregistrate pe
aplicația centralizatoare. Dispune de două acțiuni : Index și Details.
Prin Index acesta interoghează baza de date și întoarce o listă cu terminale
împreună cu view -ul asociat pentru a reda interfața grafică descrisă mai sus.
Details afișează detaliile terminalului selectat. Toate informațiile sunt dispuse
într-un modal și au fost enumerate în capitolele anterioare.
În view -ul Index, asociat acțiunii cu același nume din controller, mai există o
funcționalitate și anume Reports. Aceasta permite navigarea către pagina de Reports
(descrisă în capitolul următor) unde este prezentată o listă cu toate rapoartele
asociate stației in cauză.

3.3.5 Controllerul Report

Prin acțiunea Index, acest controller afișează lista de rapoarte provenite de la
toate terminale le înregistrate. Acestea sunt afișate intuitiv în funcție de gradul de
risc. Acțiunea Details permite navigarea către toate detaliile raportului selectat. Aici
se pot vizualiza gradul de risc al fișierului posibil malițios, informații generale cu
privire l a raport (enumerate în capitolele anterioare), lista completă cu rezultatele
analizelor efectuate de VirusTotal și YaraSharp și lista de mesaje de eroare, dacă au
existat pe parcursul desfășurării analizei unui fișier. Un specialist în analiză malware

NECLASIFICAT
NECLASIFICAT
31 din 47 poate utiliza raportul în vederea luării unei decizii cu privire la introducerea stației
în cauză în carantină (anularea accesului la rețeaua internă a companiei).

3.3.5 Controllerul Agent

Acest tip de controller este mai special, deoarece furnizează un API către
clienții aplicației de centralizare a rapoartelor, adică serviciile instalate pe terminale.
Nu urmează fluxul arhitecturii de MVC deoarece nu furnizează nicio interfață
grafică pentru interacțiunea cu utilizatorul.
Acesta conține două acțiuni :
– Enroll : Este utilizat de către servicii pentru înregistrarea stației. Aici este
locul unde ajung toate informațiile legate de terminalul în cauză. Toate
detaliile sunt stocate în baza de date și afișate în pagina Terminals a
aplicației web. La prima apelare a ac estei acțiuni se asociază certificatul
corespunzător stației client, care a fost instalat de către administrator la
prima configurare. La a doua apelare, stația este deja înregistrată și se
consideră că trebuie actualizat certificatul. Asta doar dacă certi ficatul trece
de etapa de validare din cadrul acțunii.
– Report : După înregistrarea cu succes a stației, serviciul începe să trimită
rapoarte ori de câte ori este analizat un fișier nou creat sau modificat de pe
stația respectivă. Toate informațiile sunt sa lvate în baza de date fără alte
prelucrări în avans.

3.3.6 Sistemul de notificări

SignalR este o bibliotecă open -source care simplifică adăugarea
funcționalităților desfășurate în timp real în aplicații. Funcționalitățile în timp real
permit codului din partea de server (backend) să trimită notificări către clienți.
SignalR furnizează un API pentru dezvoltarea unor apeluri RPC (Remote
Procedure Call – Într-o infrastructură cu sisteme distribuite, RPC se desfășoară
atunci când un program de pe un anumit te rminal cauzează o subrutină să se execute
în alt spațiu de adresă , de obicei pe un alt terminal din aceeași rețea ) de la server
către client. RPC -urile apelează funcțiile JavaScript de pe clienți.
SignalR gestionează automat conexiunile, trimite simultan mesaje tuturor
clienților conectați, poate trimite mesaje unui grup restrâns de clienți și se poate scala
în cazul în care traficul de rețea se aglomerează.
Pentru comunicarea între clienți și server, SignalR utilizează hub -uri. Un hub
este un pip eline de nivel înalt care permite unui client și unui server să apeleze
metode din spațiul fiecăruia.

NECLASIFICAT
NECLASIFICAT
32 din 47 În aplicația web, implementarea hub -ului este destul de simplistă. Există doar
o singură metodă suprascrisă, OnConnectedAsync(), care trimite către toți c lienții
abonați la funcția Connected din JavaScript, identificatorul conexiunii. În
controllerul Agent , în momentul apelării acțiunii Report, după ce au loc toate
stocările în baza de date a componentelor unui raport, se apeleaz ă asincron, prin
intermediul hub -ului, funcția ReceiveMessage la care sunt abonați toți clienții.
Notificările sunt afișate indiferent de locația în pagină pentru a facilita o analiză și
un răspuns cât mai rapid în cazul unui incident.

3.4 Securitate

Securitatea informaț iei reprezintă o practică de prevenire a accesului,
utilizării, dezvăluirii, perturbării, modificării, înregistrării sau distrugerii
neautorizate a informațiilor. Este un termen general care poate fi folosit indifferent
de forma datelor.
Scopul securității informațiilor este de a echilibra protecția confidențialității,
integrității și disponibilității datelor cu menținerea atenției pentru eficientizarea
politicii de securitate. Acest lucru se poate realiza printr -un proces de gestionare a
riscului care iden tifică bunurile, sursele de amenințare, vulnerabilitățile, potențialele
impacturi și posibilitățile de control, urmat de evaluarea eficienței planului de
gestionare a riscurilor[ 19][23].
În acest capitol se vor detalia măsurile de securitate impuse pentru a preveni
eventualele incidente de securitate ce pot apărea în cadrul sistemului de securizare a
fișierelor, configurat în cadrul unei instituții pentru protejarea stațiilor utilizate de
către angajați. De asemenea, se vor explica și anumite spețe de atacu ri în care
sistemul ar fi vulnerabil dacă nu s -ar fi luat măsuri.

3.4.1 HTTPS

HTTP Secure (HTTPS) este o extensie a protocolului HTTP pentru o
comunicație sigură într -o rețea de calculatoare și este foarte folosit în internet. În
HTTPS, protocolul de com unicații este criptat folosind Transport Layer Security
(TLS) sau, predecesorul, Secure Socket Layer (SSL).
Principala motivație pentru HTTPS este autentificarea site -ului web accesat și
protecția intimității și integrității datelor schimbate în tranzit. O feră protecție
împotriva atacului man -in-the-middle. În practică, acest protocol furnizează o
siguranță rezonabilă în ceea ce privește comunicarea cu site -ul real fără implicarea
unui impostor.
În criptografie și securitatea calculatoarelor, atacul man -in-the-middle
reprezintă un atac în care atacatorul ascunde în mod secret sau alterează comunicația

NECLASIFICAT
NECLASIFICAT
33 din 47 între două părți care cred că realizarea comunicației se face direct între ei. Atacatorul
are posibilitatea să intercepteze mesa jele relevante schimbate între cele doua părți și
să introducă altele noi.
HTTPS a fost inițial folosit pentru tranzacții care implicau plăți pe World
Wide Web, poștă electronică și tranzacții sensibile în interiorul sistemului unei
corporații. Din anul 20 18, HTTPS este mult mai folosit de utilizatori decat HTTP,
în primul rand pentru protecția autenticității paginilor din toate tipurile de site -uri
web, securizarea credențialelor conturilor de autentificare și păstrarea comunicațiilor
dintre utilizatori, i dentitatea și căutările pe internet, private.
Majoritatea browserelor afișează un mesaj de avertizare dacă primesc un
certificat invalid. Browserele mai vechi, când se conectau la un site web cu un
certificat invalid, prezentau utilizatorilor un mesaj în c are îi întrebau dacă vor să
continue. Browserele mai noi afișează un mesaj de avertizare pe toată fereastra, de
asemenea afișează informații de securitate legate de site în bara de adrese [20][23].
HTTPS a fost configurat în sistem prin intermediul IIS. Int ernet Information
Services (IIS) este un server web creat de Microsoft pentru a putea fi folosit cu
familia de sisteme de operare Windows. IIS suportă HTTP, HTTPS, FTP, FTPS,
SMTP și NNTP [23].
Autentificarea site -ului s -a realizat, în stadiul de producție, cu un certificat
self-signed. Acesta a fost instalat în store -ul mașinii în categoria Trusted. În
criptografie, un certificat self -signed este un certificat identitate care este semnat de
entitatea pe care o certifică. Acest termen nu are legatură cu iden titatea unei persoane
sau a unei organizații care a realizat procedura de semnare. În termeni tehnici un
certificat self -signed este semnat cu propria cheie privată.
Într-o infrastructură tipică de cheie publică (PKI), o semnatură digitală de la
o autorita te de certificare (CA) atestă faptul că un certificat este valid. Fiecare CA
are una sau mai multe chei iar certificatele asociate acestor chei publice reprezintă
ancorele de încredere care folosesc un tip special de certificate self -signed [23].

3.4.2 Aut entificarea serviciului Windows

În contextul instalării serviciului Windows pe un terminal, care nu este încă
protejat, fluxul începe prin generarea unui nou certificat pentru client de pe aplicația
web (în cazul în care nu sunt certificate disponibile). Pentru a păstra caracterul unic
și pentru a facilita asocierea certificatului cu un terminal specific, numele subiectului
din certificat va fi generat prin clasa Guid. Global Unique Iden tifier (GUID)
reprezintă un număr întreg pe 16 octeți care poate fi folosit în orice context care
necesită utilizarea unui identificator unic. Acest tip de identificator are o
probabilitate destul de mică să se repete. Certificatul se instalează în store -ul care

NECLASIFICAT
NECLASIFICAT
34 din 47 poate fi accesat doar de aplicațiile cu statut de administrator , după care se instalează
serviciul.
La pornirea serviciului, acesta va inițializa cererea de înregistrare către server,
iar după finalizarea cu succes a acesteia se pornește fluxul de trimitere al rapoartelor.
Fiecare cerere va fi însoțită de certificatul de autentificare. Acesta este convertit într –
un șir de caractere în format hexazecimal și va fi atașat în antetul cererii numit X –
ARR -ClientCert. Certificatul este identificat în store după numele emitentului,
YaraCA.
Când cererea de la serviciu ajunge la server, acesta extrage șirul de caractere
în format hexazecimal din antet , îl convertește într -un șir de octeți, după care se
creează un obiect X509Certificate2 cu ajutorul bibliotecii BouncyCastle. Se extrage
certificatul emitent din pfx împreună cu cheia privată și se apelează metoda de
verificare VerifyCertificate din CertHandler. În primă instanță se verifică perioada
de valabilitate a certificatului și dacă este semnat de autoritat ea emitentă citită din
fișierul .pfx. Pe urmă, se citesc toate listele de revocare (CRLs), se construiește un
obiect X509CrlParser (toate operațiile prin intermediul BouncyCastle) și se verifică
dacă numărul serial al certificatului client se regăsește înt r-una din liste. În ultima
verificare, se citește amprenta certificatului emitentului și se verifică cu amprenta
emitentului din certificatul client. Prin acest mod se verifică faptul că emitentul
extras din .pfx este cel care într-adevăr a semnat certific atul cu cheia sa privată. În
oricare dintre cele 3 stagii de verificare se poate întoarce fals dacă verificarea a eșuat.
Acest flux de verificare de pe aplicația web se desfășoară doar în controllerul
Agent . Este singurul mod prin care serviciul Windows po ate trimite cereri către site –
ul web. Un posibil atacator trebuie să cunoască mai multe informații până să dea la
o parte sistemul de securitate iar acest lucru presupune chiar și dezasamblarea
aplicației. Presupunând că acesta scapă de sesiunea criptată H TTPS, toate cererile
oricum îi vor fi respinse pentru că nu are acces la certificat. Singura modalitate de a
trimite rapoarte false către server este de a instala în vreun mod o aplicație care să
se execute cu drepturi de administrator și să aibă acces la certificatul clientului.
Rămâne doar să afle care este modalitatea de apel către API -ul pus la dispoziție, care
de altfel este secret.

3.5 Structura bazei de date

Fiecare tabel este construit după o structură standard pentru a facilita
performanța intero gărilor. În principal, toate tabelele sunt construite doar pentru
stocare și nu au un rol mai special care să influențeze frecvența de stocare a datelor
provenite de la serviciu sau aplicația web.
În Fig 3.2 , este prezentat tabelul în care sunt stocate inf ormații despre toate
certificatele client generate, revocate sau expirate. Subiectul certificatului este

NECLASIFICAT
NECLASIFICAT
35 din 47 utilizat în momentul asocierii unui terminal la înregistrare. Dacă nu este găsit
certificatul cu subiectul respectiv la înregistrare, aplicația web va întoarce un cod de
eroare către client. În momentul revocării, certificatul este șters fizic de pe server,
însă toate informațiile despre acesta rămân în baza de date.

Fig. 3.2 Structura tabelului Certificates.dbo

Fig. 3.3 reprezintă tabelul pentru stocarea informațiilor provenite de la fiecare
terminal. Prin câmpul CertificateId se implementează o relație de one -to-many (unul
la mai mulți ) cu tabelul descris anterior, Certificates, însă dezvoltarea este structurată
în așa fel încât fiecare te rminal să aibă asociat un singur certificat (relație de unu la
unu).

Fig. 3.3 Structura tabelului Terminals.dbo

NECLASIFICAT
NECLASIFICAT
36 din 47 Fig. 3.4 ilustrează configurația tabelului în care sunt stocate informațiile
generale despre rapo arte. În momentul în care este primit un ra port prin intermediul
API-ului pus la dispoziție de server, informația în format JSON este deserializată
într-un model numit ReportModel. Acesta este modelul principal care se stochează
în baza de date, deoarece cheia s -a principală se regăsește într -o sui tă de tabele în
care se gasesc celelalte seturi de informații care alcătuiesc raport ul final, ce se poate
vizualiza pe pagina Reports a site -ului web, selectând un raport din cele listate.

Fig. 3.4 Structura tabelului Reports .dbo

Tabelele Scans.dbo, YaraResults.dbo, Messages.dbo și YaraMetas.dbo conțin
seturile de informații care alcătuiesc raportul final, exceptând pe ultimul deoarece
este dependent direct de cheia primară a tabelului YaraResults.dbo , care la rândul
său are cheie străină c ătre tabelul Reports.dbo.
Conexiunea dintre aplicația web și baza de date s -a realizat cu ajutorul
tehnologiei EntityFramework Core. Aceasta este varianta simplificată, extensibilă,
open -source și cross -platform a versiunii populare de furnizare a accesulu i la date
numit EntityFramework.
EF Core poate deservi rolul de a asocia obiecte din C# cu tabelele din baza de
date. Acest lucru scutește dezvoltatorul de necesitatea scrierii unei secțiuni de cod
pentru accesarea datelor.
Cu EF Core, accesul la date este desfășurat prin intermediul unui model. Un
model este creat prin intermediul unor clase entitate și a unui context care reprezintă
o sesiune cu baza de date. Acest lucru permite dezvoltatorului să interogheze și să
salveze date [21].

NECLASIFICAT
NECLASIFICAT
37 din 47 4. Mod de utilizare

În acest capitol se va prezenta modul de utilizare al sistemului de securizare
al fișierelor. Se vor prezenta atât serviciul de Windows, cât și site -ul web prin
intermediul imaginilor și a câtorva explicații ale acțiunilor prezentate în imagin i
(unde este nece sar).

4.1 Serviciul Windows

Serviciul se instaleaz ă prin intermediul ferestrei Developer Command Prompt
for VS. Această fereastră este deschisă cu d repturi de administrator pentru ca
serviciul să se execute cu drepturi de administrator. Comanda utilizată est e installutil
WindowsYaraService.exe unde a doua parte din comandă reprezintă binarul generat
în urma acțiunii de build a proiectului.

Fig. 4.1 Instalarea serviciului cu drepturi de administrator

Developer Command Prompt for Visual Studio permite util izarea unor
instrumente din frameworkul .NET mult mai ușor. Este un command prompt
(aplicație de interpretare a comenzilor disponibilă pe majoritatea sistemelor de
operare Windows) în care sunt setate automat variabile de mediu.
După instalarea cu succes a serviciului, acesta se pornește din fereastra de
comandă a serviciilor.

NECLASIFICAT
NECLASIFICAT
38 din 47

Fig. 4.2 Pornirea serviciului

În figura anterioară , serviciul de Windows se pornește manual o singură dată,
după care acesta se va porni automat de fiecare dată când stația bootează. Această
modalitate de pornire se poate schimb a dând clic dreapta pe serviciu, accesare
proprietăți și schimbarea tipului de start din caseta de selecție.
Numele și descrierea pe care serviciul le are (WindowsYaraService respectiv
YaraScan ner), împreună cu contul cu care este logat acesta (LocalSystem), au fost
stabilite în momentul dezvoltării serviciului în secțiunea ProjectInstaller. Numele se
poate vizualiza în coloan a Name, descrierea în Description, starea curentă a
serviciului în Sta tus, modalitatea de pornire a serviciului în Startup Type
(Automatic) și contul cu care acesta este autentificat în Log On As (Local System).
După configurările realizate, în general de către administratorul de sistem al
companiei ce implementează soluția, serviciul monitorizează evenimentele de
scriere și citire al fișierelor din sistem. Serviciul nu prezintă o interfață grafică cu
utilizatorul și rulează în background, drept urmare, nu va interveni în vreun fel
anume în activitatea utilizatorului.

NECLASIFICAT
NECLASIFICAT
39 din 47 4.2 Aplica ția web

Aplica ția web va fi instalată pe un server al companiei și administrată de
administratorul de sistem (sysadmin). Personalul care va monitoriza starea
terminalelor și vor analiza rapoartele, va fi compus din specialiști în analiză
malware.
După aut entificare, analistul va fi întâmpinat de pagina Home unde va putea
vizualiza un sumar cu statistici. Pe baza acestora, analistul va putea trage anumite
concluzii și va forma niște decizii în legătură cu starea de securitate a instituției, în
general.

Fig. 4.3 Pagina de întâmpinare

NECLASIFICAT
NECLASIFICAT
40 din 47 Certificates este pagina unde se vor genera, descărca, vizualiza și sterge
certficatele clienților. Acestea sunt listate și catalogate după caz. Cele cu roșu sunt
expirate sau au fost revocate, cu albastru sunt certificatele care încă nu au trecut în
perioada de valabilitate iar cele în gri sunt valide.
Certificatele cu roșu și albastru nu vor fi disponibile pentru descărcare, în plus
pentru cele în roșu nu va mai fi disponibilă funcționalitatea de revocare, ele deja
fiind inv alide.
Atât crearea cât și revocarea unui certificat se va face pe bază de parolă.
Aceasta va fi utilizată pentru extragerea certificatului împreună cu cheia privat ă din
fișierul .pfx.

Fig. 4.4 Listarea certificatelor

Fig. 4.5 Crearea și revocarea certificatelor

NECLASIFICAT
NECLASIFICAT
41 din 47 Butonul verde poate fi accesat pentru vizualizarea detaliilor legate de
certificat. Acestea vor apărea într -un modal.

Fig. 4.6 Listarea certificatelor

Următoarea pagină din meniu este lista cu terminalele înregistrate. Dacă
certificatul asociat unui terminal este revocat sau expirat, atunci terminalul va fi listat
cu roșu (similar cu tabelul certificatelor).

Fig. 4.7 Listarea terminalelor

NECLASIFICAT
NECLASIFICAT
42 din 47

Fig. 4.8 Detaliile unui terminal

În partea dreapt ă din fereastra de detalii sunt prezente informații legate de
certificatul asociat. În cazul în care analistul malware observă că o anumită stație
trimite rapoarte neconcludente și după un anumit format, el poate verifica în această
pagină subiectul certif icatului asociat stației problemă, va identifica certificatul în
listă și -l va revoca, dacă este cazul.
Butonul Reports permite analistului să navigheze către pagina de rapoarte
asociate stației selectate.
Ultimul buton din meniul de navigare îl reprezintă Reports. Aici sunt listate
rapoartele provenite de la toate stațiile înregistrate. Ele sunt catalogate în funcție de
gradul de risc. Cu galben sunt cele care necesită atenție, cu roșu sunt cele care trebuie
studiate mai îndeaproape iar cu gri sunt cele fă ră nicio neregulă detectată.
Pentru fiecare raport se pot studia detaliile acestuia accesând butonul Details
din partea dreaptă. În această pagină se poate vedea sumarul raportului, se pot analiza
listele provenite de la VirusTotal și YaraSharp și se pot c iti mesajele de eroare.

NECLASIFICAT
NECLASIFICAT
43 din 47

Fig. 4.9 Lista de rapoarte

Fig. 4.10 Detaliile unui raport

NECLASIFICAT
NECLASIFICAT
44 din 47

Fig. 4.11 Detaliile unui raport (Continuare)

Fiecare scanare va fi notificată. Caseta de notificare va fi vizibilă în dreapta,
în partea de sus. Caseta se poate a ccesa pentru navigarea rapidă către detaliile
raportului respectiv.
Informațiile care pot fi extrase imediat din notificare sunt gradul de risc al
raportului, numele stației și numele fișierului pentru care s -a generat raportul.

Fig. 4.12 Notificare raport

5. Teste

Pentru testarea performanței sistemului , s-a utilizat un script simplu care a
creat 16 fișiere într -o secundă.
În starea de așteptare, serviciul utilizează aproximativ 175 mb de memorie. În
momentul în care scriptul a fost pornit, în Fig. 5.1 se pot observa mici variații în

NECLASIFICAT
NECLASIFICAT
45 din 47 utilizarea puterii de calcul iar în partea de memorie schimbările sunt insesizabile.
Acest lucru se datorează faptului că fișierele sunt de aproximativ 1kb.

Fig. 5.1 Test cu fișiere mici

Tot cu acela și script, doar că de data asta cu 16 fișiere de 32 mb , se pot observa
în Fig. 5.2 variații mai mari de resurse, însă pe durate destul de scurte.

Fig. 5.2 Test cu fișiere mari.

NECLASIFICAT
NECLASIFICAT
46 din 47 6. Concluzii

6.1 Posibilități de utilizare

Sistemul poate fi utilizat de către o companie care dorește monitorizarea
activităților angajaților în materie de creare și modificare de fișiere. Sistemul va
colecta toate monstrele, le va scana și va trimite rapoartele către serviciul web
centralizator unde va avea acces personalul s pecializat în securitate.

Fig. 6.1 Posibilă arhitectură a unei companii

6.2 Direcții de viitor

Sistemul poate fi îmbunătățit pe mai multe aspecte:
– YaraSharp: I ntegrarea cu YaraSharp poate fi detașată pe un server separat.
Acest lucru aduce un plus în frecvența cu care fișierele sunt analizate iar
resursele utilizate se vor diminua

NECLASIFICAT
NECLASIFICAT
47 din 47 – Raport : Toate informațiile din raport se pot organiza astfel încât să fie cât
mai intuitive. Acesta poate include mult mai multe informații pentru
analiză cu rezultat cât mai concludent posibil.

Bibliografie

[1]https://en.wikipedia.org/wiki/Microsoft_Visual_Studio
[2]https://en.wikipedia.org/wiki/PyCharm
[3]https://docs.mic rosoft.com/en -us/sql/ssms/sql -server -management -studio –
ssms?view=sql -server -ver15&viewFallbackFrom=sql -server -2019
[4]https://docs.microsoft.com/en -us/dotnet/core/
[5]https://docs.microsoft.com/en -us/dotnet/csharp/tour -of-csharp/
[6]https://en.wikipedia.org/wiki/SQL
[7]https://en.wikipedia.org/wiki/Unified_Modeling_Language
[8]https://en.wikipedia.org/wiki/Use_case_diagram
[9]https://en.wikipedia.org/wiki/Component_diagram
[10]https://en.wikipedia.org/wiki/ Class_diagram
[11]https://blog.malwarebytes.com/security -world/technology/2017/09/explained –
yara-rules/
[12]https://en.wikipedia.org/wiki/Web_crawler
[13]https://docs.scrapy.org/en/latest/
[14]https://support.virustotal.com/hc/en -us/articles/115002126889 -How -it-works
[15]https://docs.microsoft.com/en –
us/dotnet/api/system.io.filesystemwatcher?view=netframework -4.8
[16]https://docs.microsoft.com/en -us/aspnet/core/tutorials/first -mvc-app/adding –
controller?view=aspnetcore -3.1&tabs=visual -studio
[17]https://en.wikipedia.org/wiki/Representati onal_state_transfer
[18]https://en.wikipedia.org/wiki/PKCS_12
[19]https://en.wikipedia.org/wiki/Information_security
[20]https://en.wikipedia.org/wiki/HTTPS
[21]https://docs.microsoft.com/en -us/ef/core/
[22]https://docs.microsoft.com/en –
us/aspnet/core/signalr/introduction?View=aspnetcore -3.1
[23]Serviciu pentru jurnalizarea accesului la fișiere într -un sistem Andr oid, Tomei
Alexandru, 2018