Licenta Final Rev2 [305202]

UNIVERSITATEA „OVIDIUS” CONSTANȚA

FACULTATEA DE MATEMATICĂ ȘI INFORMATICĂ

SPECIALIZAREA INFORMATICĂ

LUCRARE DE LICENȚĂ

Securitatea Informației

IDS și Firewall pe Raspberry PI

Coordonator științific: Absolvent: [anonimizat] 2017

Abstract

Internetul a devenit astăzi o parte vitală a [anonimizat]-a adus în diverse domenii. Această utilizare pe scară largă a internetului, împreună cu creșterea extraordinară a comerțului electronic și a comerțului electronic, a creat o necesitate vitală pentru securitatea informațiilor.

Acesta este un raport privind posibilitatea utilizării unui Raspberry Pi că sistem de detectare a intruziunilor ( IDS ) într-un mediu SOHO pentru a spori securitatea rețelei. Scopul acestui studiu a [anonimizat] a intruziunilor în rețea (NIDS) dar și că firewall. Utilizatorii casnici și companiile de dimensiuni mici ar putea beneficia de o [anonimizat]. O soluție posibilă este să rulați un software de detectare a intruziunilor, [anonimizat] o distribuție Linux ARM. Această lucrare ilustrează instrucțiuni pas cu pas pentru a descărca și a configura pachetele software și pentru a [anonimizat], configurare firewall dar și configurarea serviciului Snort pentru a [anonimizat] 1.2GHz cu o memorie alocată de 1GB.

Cuvinte cheie: [anonimizat], NIDS, firewall, [anonimizat], [anonimizat], DHCP.

Introducere

O rețea de calculatoare reprezintă un ansamblu de echipamente de comunicații(calculatoare, laptop-uri, telefoane, PDA-uri , etc) interconectate prin intermediul unor medii fizice de transmisie(cablu UTP/STP, [anonimizat], [anonimizat] , mediu wireless), [anonimizat], precum și al utilizării în comun a resurselor fizice(hardware), logice(software) [anonimizat].

Internet-ul(INTERnațional NETwork) reprezintă ansamblul tuturor calculatoarelor interconectate între ele.

[anonimizat] (serviciul de e-mail) său pentru a realiza conexiuni multiple la un server. La acea vreme securitatea informației nu reprezenta o problemă, iar protocoalele folosite nu aveau posibilitatea de a cripta datele (ex: Telnet, RIP,etc.).

Ulterior, oamenii au văzut adevăratul potențial al rețelelor de calculatoare și multitudinea de beneficii aduse de acestea: [anonimizat](imagini,videoclipuri,etc), [anonimizat]( [anonimizat], etc). [anonimizat] a [anonimizat].

Odată cu creșterea numărului de utilizatori ai rețelei Internet a crescut și numărul atacurilor cibernetice.

Primele atacuri au fost neintenționate, de exemplu viermele Morris este considerat primul “worm” distribuit pe Internet în anul 1988 pentru a afla câte calculatoare sunt conectate la rețeaua Internet. Au urmat și alte atacuri cum ar fi Melissa Email Virus(1999), Mafiaboy DoS Attack(2000), Love Bug Worm(2000), Code Red DOS Attack (2001), etc.

“Cine?” , “Când?” , “De unde?” , “Ce?” , “De ce?” sunt întrebările esențiale referitoare la securitatea comunicațiilor , care determină împreună o nouă sintagmă, “the five Ws”. Cine accesează rețeaua de calculatoare? Când se produce accesul la rețea? De unde este accesata rețeaua? Ce informații sunt accesate? De ce sunt accesate acele informații?

Securitatea informației este un concept mai larg care se referă la asigurarea integrității,a confidențialității, și a disponibilității informației(ISO/IEC 17799:2005). Confidențialitatea este asigurată prin criptarea informației, integritatea se obține prin mecanisme și algoritmi de

dispersie iar disponibilitatea este asigurată prin întărirea securității rețelei său rețelelor de sisteme informatice.

Standardul de securitate ISO/IEC 17799 [1] stabilește principiile generale pentru inițierea, implementarea, menținerea și îmbunătățirea managementului securității informațiilor într-o organizație.

Controalele interne pot fi considerate principiile care stau la baza implementării unui sistem de management al securității. Chiar dacă sursele unor astfel de măsuri pot fi destul de variate, punctul de plecare într-un astfel de demers îl reprezintă legislația aplicabilă. Este crucial că cel care se ocupă de implementarea unui sistem de management al securității să aibă cunoștințe despre actualele cerințe legislative:

• Legea nr. 161 din 19 aprilie 2003 privind unele masuri pentru asigurarea transparentei în exercitarea demnitarilor publice, a funcțiilor publice și în mediul de afaceri, prevenirea și sancționarea corupției.

• Legea nr. 506 din 17 noiembrie 2004 privind prelucrarea datelor cu caracter personal și protecția vieții private în sectorul comunicațiilor electronice.

• Legea nr. 677 din 21 noiembrie 2001 pentru protecția persoanelor cu privire la prelucrarea datelor cu caracter personal și libera circulație a acestor date.

• Legea nr. 455 din 18 iulie 2001 privind semnătura electronica.

• Legea nr. 544 din 12 octombrie 2001 privind liberul acces la informațiile de interes public.

• Hotărârea nr. 1259 din 13 decembrie 2001 privind aprobarea Normelor tehnice și metodologice pentru aplicarea Legii nr. 455-2001 privind semnătura electronica.

• Ordinul Avocatului Poporului nr. 52 din 18 aprilie 2002 privind aprobarea Cerințelor minime de securitate a prelucrărilor de date cu caracter personal.

• Ordinul Avocatului Poporului nr. 53 din 18 aprilie 2002 privind aprobarea formularelor tipizate ale notificărilor prevăzute de Legea nr. 677/2001 pentru protecția persoanelor cu privire la prelucrarea datelor cu caracter personal și libera circulație a acestor date.

• Ordinul Avocatului Poporului nr. 54 din 18 aprilie 2002 privind stabilirea unor situații în care nu este necesara notificarea prelucrării unor date cu caracter personal care cad sub incidenta Legii nr. 677/2001 pentru protecția persoanelor cu privire la prelucrarea datelor cu caracter personal și libera circulație a acestor date.

• Legea nr. 182 din 12 aprilie 2002 privind protecția informațiilor clasificate.

Capitolul 1

1.1 Tipuri de atacuri informatice

În prezent, sistemele informatice pot fi atacate atât din interior cât și din exterior. Un studiu realizat în anul 2014 ne arată faptul că aproximativ 70% dintre atacurile asupra rețelelor de calculatoare sunt din interior. Atacurile interne se referă la: furt de parole, spionaj industrial, utilizarea necorespunzătoare a sistemelor,erori de operare,etc.

1.1.1 Viruși secvențe de cod distructive create pentru infectarea sistemelor informatice. Aceștia prezintă 2 caracteristici de bază: se auto-execută și se auto-multiplică. Secvențele de cod sunt strecurate în interiorul unui program, printre instrucțiuni. Virusul nu este activat până în momentul în care programul nu este executat. Odată activat, acesta încearcă să se infiltreze printre instrucțiunile altor programe, ducând la contaminarea întregului sistem.

Există mai multe tipuri de viruși printre care amintim: viruși MBR, viruși BS, viruși de fișiere(infectează o anumită categorie de fișiere .exe , .com , .ovl , .sys ,etc.), viruși de macro-uri, viruși de link-uri , etc.

1.1.2 Viermi(worms) programe distructive ce folosesc comunicarea între sisteme pentru a se putea răspândi. Aceștia nu infectează un anume tip de fișier precum virușii, ci infectează întregul sistem.

Conform RFC 1135 [2] “un vierme este un program scris în limabajul C care poate rula independent, consumând resursele gazdei pentru a se executa și care poate propaga o versiune funcțională a să către alte calculatoare”.

Stuxnet este un exemplu de astfel de program, descoperit în anul 2010, și despre care se speculează că ar fi responsabil de atacul cibernetic de la uzină nucleară Natanz, Iran. Stuxnet operează în 6 faze [3] :

Infectarea sistemelor – a fost proiectat pentru a infecta sistemlele Microsoft Windows.

Căutarea programelor bazate pe Microsoft Windows – de exemplu programul Siemens Step7, software folosit pentru programarea sistemelor industriale de control.

Actualizare worm – în aceasta fază programul malițios verifică dacă sistemul infectat deține software că cel descris în faza 2. Dacă sistemul nu are acest tip de software, programul rămâne inactiv. În cazul în care detectează software ce poate fi exploatat, încearcă să se conecteze la rețeaua de Internet pentru a se putea actualiza.

Compromiterea sistemului – programul se folosește de vulnerabilitățile “zero-day”, vulnerabilități ce nu au fost încă descoperite de experții în securitate , pentru a compromite controlerele logice ale sistemului.

Controlul – Worm-ul Stuxnet,spionează operațiunile care se realizează pe sistemul vizat, după care, în urma datelor acumulate preia controlul sistemului.

Înșeală și distruge – În timp ce programul schimba modul de funcționare al sistemului trimite date false către controlere și senzori înștiințând că sistemul funcționează în parametri, până în momentul când sistemul este distrus.

1.1.3 Cai troieni (Trojan horses) [4] reprezintă un program software de tip spion care deși pare a realiza unele funcții “utile” , în realitate executa secvențe de cod care au că scop exploatarea privilegiilor utilizatorului.Aceștia au în componenta lor 3 elemente: programul Server , programul Client și programul Build/Edit Server.

Aceștia se pot împărți în mai multe categorii astfel: Backdoors(preluarea controlului calculatorului victima prin accesul la Internet) , Password Stealer/Keylogger (citirea datelor introduse de la tastatură și salvarea acestora într-un fișier care poate fi trimis către adresa de e-mail al atacatorului), Logical Bombs(efectuează operații care pot compromite securitatea sistemului),etc.

1.1.4 Atac de recunoaștere descoperirea și cartografierea sistemelor informatice , căutarea oricărei informații utile ce poate fi folosită într-un atac ulterior( Ping Sweep , Sniffing , Port Scan).Detaliile ce pot fi acumulate în urma acestor tipuri de atacuri sunt: numele de domenii web, adresele IP folosite de sisteme, serviciile TCP/UDP folosite, ID-uri sesiuni ce rulează, sistemul de operare folosit,arhitectura sistemului, tabelele de routare, informații SNMP, etc.

Verificare sistemelor live

Scanare ICMP – comanda ping se bazează pe trimiterea mesajelor de tip ICMP ECHO REQUEST spre un host. Dacă host-ul este live, va returna un mesaj de tip ICMP ECHO REPLY.Această scanare este utilă pentru a verifica dacă un sistem este activ său dacă ICMP trece printr-un firewall.

ICMP ECHO REQUEST

ICMP ECHO REPLY

Fig 1.1 Scanare ICMP

Ping Sweep – folosit pemtru a determina sistemele live dintr-un interval de adrese IP prin trimiterea mesajelor ICMP ECHO REQUEST la mai multe IP-uri.

Hping2 / Hping3 – utilitare din linia de comandă pentru a scana rețeaua dar și pentru a crea pachete pentru protocolul TCP/IP.Se folosește pentru a verifica existența unui firewall, traceroute avansat, ghicire uptime sisteme,etc.

Verficare porturi deschise [5]

Scanare TCP Connect(Scanare Full-Open) – Scanarea se realizează utilizand principiul three-way handshake, după care închide conexiunea trimițând un pachet RST

SYN Pachet + Port(80)

SYN + ACK Pachet

ACK

RST

Fig 1.2 Scanare TCP Connect când portul este deschis

SYN Pachet + Port(80)

RST

Fig 1.3 Scanare TCP Connect când portul este închis

Scanare ascunsă( scanare Half-Open) – Acest tip de verificare implică resetarea conexiunii TCP dintre client și server inainte de a se finaliza procedeul three-way handshake.Atacatorul trimite un singur pachet SYN către server pe portul pe care se dorește verificarea.Dacă portul este deschis, serverul va răspunde cu un pachet SYN/ACK, iar dacă portul este închis serverul va răspunde cu un pachet RST.În cazul în care portul este deschis, atacatorul va întrerupe conexiunea la server prin trimiterea unui pachet RST.

Scanare Inverse TCP Flag – Atacatorul trimite pachete TCP de sondă(TCP probe packets) cu un flag setat (FIN, URG, PSH) său fără niciun flag setat(NULL) către portul serverului.

Probe Packet (FIN/URG/PSH/NULL)

Fără Răspuns

Fig1.4 Scanare Inverse TCP Flag când portul este deschis

Probe Packet (FIN/URG/PSH/NULL)

RST/ACK

Fig1.5 Scanare Inverse TCP Flag când portul este închis

Scanare XMAS –Atacatorul trimite un cadru TCP cu flag-urile FIN,URG și PSH setate către server.Scanările FIN funcționeaza doar la sistemele de operare care au implemntarea TCP bazată pe RFC 793.Acest tip de scanare nu este compatibil cu sistemele Microsoft Windows.

FIN+URG+PSH

Fără Răspuns

Fig1.6 Scanare XMAS când portul este deschis

FIN+URG+PSH

RST

Fig1.7 Scanare XMAS când portul este închis

Scanare ACK Flag Probe – Atacatorul trimite pachete TCP de sondă(TCP probe packets) cu flag-ul ACK setat către server iar apoi analizează informațiile din header-ul pachetetelor RST primite(câmpurile TTL și WINDOW) pentru a afla dacă portul este închis său deschis.

ACK Probe Packets

Răspunsuri RST

Fig 1.8 Scanare ACK Flag Probe bazată pe TTL

Dacă valoarea TTL a pachetului RST pe un anumit port este mai mică decât valoarea limita 64, atunci portul respectiv este deschis.

ACK Probe Packets

Răspunsuri RST

Fig1.8 Scanare ACK Flag Probe bazată pe WINDOW

Dacă valoarea WINDOW a pachetului RST pe un anumit port este diferită de zero, atunci portul respectiv este deschis.

Scanarea ACK Flag Probe poate fi folosită și pentru a verifica dacă serverul are filtrare de pachete pe porturi.Atacatorii trimit un pachet de sonda ACK cu un număr de secventa ales aleator: dacă nu se primește răspuns portul este filtrat(firewall stateful este prezent) iar dacă se primește pachet RST portul nu este filtrat

.

Scanare UDP – În cazul scanării porturilor UDP nu se realizează procesul three-way handshake, iar sistemul nu răspunde cu mesaj când portul este deschis.Dacă portul UDP este închis, sistemul trimite mesajul “ICMP Port unreachable”. Programele de tip trojan, spyware, rootkit folosesc porturile UDP.

Banner-grabbing – Este metoda prin care se poate determina ce sistem de operare rulează pe un anumit dispozitiv.Acest procedeu se poate realiza:

Activ – se trimit pachete special create către sistem iar răspunsurile sunt notate, după care sunt comparate cu alte răspunsuri dintr-o bază de date pentru a determina SO.

Pasiv – mesajele de eroare oferă informații despre tipul serverului, tipul de SO, și instrumentul SSL folosit de sistem. Capturarea de pachete și analizarea acestora poate oferi de asemnea detalii despre sistemul de operare. O altă metoda este verificarea extensiilor din URL (ex: .aspx => server IIS și platforma Windows).

Fig1.10 Banner-grabbing folosind telnet

Fig1.11 Banner-grabbing folosind netcat

Fig1.12 Ping Scanaflarea stațiilor active

Fig1.13 Informații despre sistemul de operare

Fig1.14 Informații despre porturile deschise (Port Scan)

Fig1.15 Informații despre servicii și versiunea acestora (Service Scan)

Fig1.16 Captura traficului din linia de comandă folosind utilitarul de recunoaștere tcpdump

Fig1.17, 1.18 Informații despre serverele de nume și de mail ale unui domeniu folosind utlitarul de recunoaștere host

1.1.5 Negarea Serviciului (Denial of Service [DoS] ) este unul din cele mai folosite atacuri și este foarte ușor de realizat(pe baza unor scripturi său programe).

se realizează pe baza transmiterii unui număr foarte mare de cereri către un server său calculator până când acesta nu mai poate reacționa eficient la traficul de Internet legitim, său poate deveni indisponibil.

Fig 1.19 Exemplu de trafic valid cu rezultat de DoS: Slashdot effect

TCP SYN flood [6] : Acest tip de atac constă în inițializarea unui număr mare de conexiuni TCP cu un server, fără a termina handshake-ul inițial( half-open connections). Aceste conexiuni consumă resursele serverului iar acesta nu mai poate procesa alte cereri legitime.

Fig1.20 TCP SYN Flood

1.1.6 MITM Attack – atacatorul poate intercepta și modifica conținutul mesajelor transmise de către 2 calculatoare, victimele neștiind că sesiunea și schimbul de mesaje este controlat de atacator.

ARP Poisoning reprezintă un atac de tip MITM.

Etapele unui atac MITM [7]:

Starea inițiala-rețeaua funcționează în parametri normali înaintea începerii atacului(stația A deține informații corecte despre stația B)

Fig1.21 Atac MITM – Starea inițială a rețelei

Atacul- Stația B reprezintă atacatorul care dorește interceptarea traficului dintre stațiile A și C.

B trimite un mesaj de tip ARP către A ce conține C.IP –B.MAC

A primește mesajul și schimbă conținutul cache-ului

B va ruta traficul de la A

Fig1.22 Atac MITM – PC B trimite mesaj ARP către PC A

Atacul-B dorește interceptarea traficului dintre stațiile C și A

B trimite un mesaj de tip ARP ce va conține A.IP –B.MAC

C primește mesajul și schimbă conținutul cache-ului

Fig1.23 Atac MITM – PC B trimite mesaj ARP către PC C

Starea finală- stațiile A și C vor crea frame-uri cu adresa stației B în antetul de nivel 2 iar switch-ul va comuta frame-urile respective către atacator.

Fig1.24 Atac MITM – Starea finală a rețelei

1.1.7 VLAN Hopping

Switch spoofing [8]: Stația atacatorului negociază o legatura trunk cu switch-ul prin DTP iar ulterior atacatorul poate trimite trafic în oricare VLAN

Fig1.25 VLAN Hopping – Switch Spoofing

Double Tagging[9]-este mai simplu de realizat dat fiind faptul că atacatorul nu necesită implementarea DTP.Aceasta tehnică este folosita și de ISP-uri în 802.1Q tunneling

Fig1.26 VLAN Hopping – Double Tagging

Switch-ul elimină tag-ul de VLAN20 și trimite frame-ul mai departe pe trunk

Switch-ul 2 vede tag-ul 10 și trimite frame-ul pe VLAN10

Fig1.27 VLAN Hopping – Double Tagging

1.1.8 Atacuri STP

Protocolul STP nu folosește autentificare, deci este vulnerabil.

Atacul STP are în general 3 pași [10]:

Conectarea la rețeaua de switch-uri

Trimitere de BDPU-uri (Bridge Protocol Data Unit) cu BID mic.

Devenire root bridge

Fig 1.28 Atac STP – Starea inițiala a rețelei

Traficul dintre stațiile A și B trece prin Switch-ul 1

Switch-ul 2 reprezintă sistemul folosit de atacator (Linux cu Yersinia)

Se conectează Switch-ul 2 la rețea și anunță BPDU-uri cu BID=1(prioritate 0)

Fig 1.29 Atac STP – Starea finala a rețelei

În acest moment traficul dintre stațiile A și B trece prin Switch-ul 2

Atacatorul pornește o captură de trafic pe Switch-ul 2 pentru a putea analiza comunicația dintre stațiile A și B.

1.2 Tehnici de securitate

Pentru a diminua riscul că persoanele neautorizate să acceseze informații din interiorul unei rețele trebuiesc implementate următoarele tehnici pentru a spori securitatea rețelei:

Dispozitivele de rețea și mediile de transmisie la nivelul fizic trebuie protejate astfel încât atacatorul să nu aibă access fizic la acestea

Blocarea accesului la nivelul de rețea

Folosirea de tunele securizate său VPN-uri pentru transportul securizat al datelor

Folosirea de algoritmi de criptare a datelor

Politicile de securitate moderne includ urmptoarele nivele de securitate:

Folosirea unui firewall și a unui IDS pentru asigurarea conexiunilor sigure la rețeaua Internet

Transmiterea informației în format criptat prin tunele de securitate, totodata folosind și certificatele digitale pentru asigurarea comunicării cu persoana dorită

Securitatea la nivelul aplicație

1.2.1 Firewall

Firewall-urile reprezintă dispozitive său programe software care controleaza fluxul de trafic între host-uri și rețele. În timp ce traficul de rețea trece prin firewall acesta decide ce trafic transmite mai departe și ce trafic blochează pe baza unor reguli definite de către utilizator[11].Acestea sunt instalate la granița dintre două rețele și au următoarele proprietăți:

tot traficul dintre rețele trece prin firewall

doar traficul autorizat poate trece de firewall continuându-și traseul până la destinație

sistemul este imun la atacurile asupra securității acestuia

Există diferite tipuri de mecanisme folosite de firewall-uri pentru restricționarea traficului printre care amintim: firewall de filtrare pachete (Packet Filter), poartă de acces la nivel de circuit(Circuit-Level Gateway), poartă de acces la nivel de aplicație(Aplicațion-Level Gateway său Proxies), firewall cu inspecție multistrat(Stateful Multilayer Inspections), server proxy.

1.2.1.1 Firewall de filtrare pachete

Aceste tipuri de firewall analizează fiecare pachet IP care este transmis prin sistem(intră/iese său este rutat), verificând informațiile din header(tip, adresă sursă, adresă destinație, număr de port) iar în funcție de rezultat se decide dacă pachetul este transmis mai departe său dacă este blocat[12]. Firewall-urile de tip filtrare de pachete operează la nivelul rețea, acestea neavând funcție de autentificare prin parole, utilizatorul identificându-se doar după adresa IP.

Filtrele de pachete au fost folosite începând cu kernel-ul 1.1 al sistemelor Linux fiind bazate pe ipfw din BSD(1994).Ulterior s-a introdus utilitarul ipfwadm pentru controlul regulilor de filtrare. Rusty Russel a introdus în 1998 utilitarul ipchains iar în anul 1999 utilitarul iptables.

Fig 1.30 Firewall de filtrare pachete

Ipchains [13] este firewall-ul folosit de kernelul linux și își găsește utilizarea în setarea, menținerea și inspectarea regulilor de firewall.

Regulile de filtrare întreținute de Nucleul Linux se pot împarți în patru categorii:

IP input chain pachetele IP care intră în sistem

IP output chain pachete IP care ies din sistem

IP forwarding chainpachete IP ce trebuiesc rutate

Chain-uri definite de administratorul rețelei

În momentul primirii unui pachet acesta este analizat iar dacă nu se potrivește cu regulile de filtrare se examinează următoarea regulă din lanț, și aceasta operație continuă până când pachetul ajunge la sfârșitul lanțului, caz în care pachetul va fi blocat său transmis mai departe în funcție de politica lanțului.Dacă în urma analizei pachetul se potrivește uneia dintre reguli, acesta este transmis altui lanț de reguli său poate fi:

ACCEPT lăsat să între/iasă în/din sistem

DENYrefuzat

REJECTrefuzat dar inștiințează expeditorul printr-un mesaj ICMP că mesajul a fost refuzat

MASQmascat,făcând să pară că provin de la host-ul local

REDIRECTredirectat la un socket local

Iptables [14]este următoarea generație de filtre de pachete după Ipchains, semănând foarte mult cu predecesorul său avand în plus extensii folosite la modificarea câmpurilor pachetelor care intră/ies. Iptables oferă posibilitatea definirii mai multor tabele de reguli de firewall, fiecare tabel având un număr de chain-uri prestabilite dar pot fi adaugate și chain-uri definite de utilizator.

Țintele built-în ale Iptables sunt:

ACCEPTpermite transmisia pachetului mai departe

DROPrefuză transmiterea pachetului

QUEUEtrimite pachetul în userspace pentru a fi prelucrat de aplicațiile utilizator

RETURNabandonarea regulilor chain-ului curent și revenirea la regulile de chain-ul anterior

1.2.1.2 Circuit-Level Gateways

Acest tip de firewall rulează la nivelul TCP al modelului TCP/IP, monitorizând sesiunile TCP dintre rețeaua locala, server și rețeaua Internet. Tot traficul este transmis pe un singur port(de obice 1080) utilizând un server intermediar. Un dezavantaj al ‘porților de circuit’ este faptul că nu verifică pachetele ce provin din traficul cu rețeaua publica, ci doar le filtrează după titlu. Sunt firewall-uri rar întalnite deși sunt mai sigure decât filtrarea pachetelor și mai rapide decât aplicațiile proxy.[15]

Fig 1.31 Circuit-Level Gateway

1.2.1.3 Aplication-Level Gateways

Reprezintă cele mai bune și complexe soluții firewall, fiind totodată și cele mai scumpe. În cazul acestor tipuri de firewall utilizatorul este nevoit să se conecteze prima oară la application gateway,iar în cazul în care conexiunea este acceptată se continuă cu conectarea la stația destinație.Toate transmisiile au aceeași rută:de la client la application gateway și de la application gateway la destinatar.Ca și în cazul serverelor proxy singura adresă văzută din afara rețelei locale este cea a application gateway-ului, protejând astfel rețeaua internă.[16]

Fig 1.32 Application-Level Gateway

Firewall-urile oferă o protecție scăzută când vine vorba de atacurile provenite din interior, la fel ca și în cazul virușilor. În ceea ce privește viteza de comunicare cu exteriorul există o oarecare limitare a vitezei dar nu și în cazul rețelelor legate la rețeaua Internet prin linii de mare viteza.

1.2.2 Network Address Translation (NAT)

Inițial, protocolul NAT a fost introdus pentru a “salva” adrese IP versiunea 4.În luna mai 1994, RFC1631 a văzut acest protocol ca o soluție temporară pentru folosirea a cât mai puține adrese IP publice.În interiorul unei rețele interne, calculatoarele folosesc adrese IP private, precum 10.0.0.0/8, aceste adrese nefiind folosite în rețeaua Internet.În momentul în care se realizează o conexiune în exteriorul rețelei LAN, protocolul NAT inlocuiește adresa privată(adresa IP sursă, de exemplu 10.65.1.7) din pachetul IP cu o adresă publică(23.1.8.3). Sistemul destinație la care se dorește trimiterea pachetului vede sursa pachetului IP-ul 23.1.8.3 și nu 10.65.1.7. [17]

Sursă 10.65.1.7 Sursă:23.1.8.3

Destinație:39.5.1.40 I Destinație: 39.5.1.40 II

IV Sursă: 39.5.1.40 III Sursă: 39.5.1.40

Destinație: 10.65.1.7 Destinație: 23.1.8.3

IP Privat: 10.65.1.1 IP Public:23.1.8.3

Fig 1.33 Network Address Translation

1.2.3 Serverele Proxy

Serverele Proxy fac parte din tehnicile de securitate, acestea fiind un intermediar între stația de lucru și Internet. În momentul în care se face o cerere către un server din afara rețelei interne, serverul proxy preia cererea de la stația de lucru și o trimite mai departe către destinația dorită, iar răspunsul destinației este deasemenea trimis serverului proxy , care la rândul lui trimite pachetele către stația de lucru. Utilizarea unui astfel de server este des întalnit în marile companii pentru a putea controla modul în care este folosită conexiunea la rețeaua Internet de către angajați(se poate restricționa accesul la anumite pagini Web, oferă log-uri detaliate referitor la activitatea angajaților pe Internet).Un alt punct forte al acestor servere îl reprezintă ascunderea adreselor IP și a locației dar și blocarea cookie-urilor sau acceptarea lor fără a ajunge pe stația de lucru, acest lucru conferind un plus de anonimitate la accesarea rețelei Internet.

Fig 1.34 Server Proxy

Sunt 2 tipuri de servere proxy:

Aplicație proxy – aplicație ce așteaptă cereri de la client și le rezolvă

Proxy SOCKS – acest tip de server face mapare de porturi

1.2.3.1 Aplicație proxy

Cel mai bun exemplu este când o persoană face telnet pe un calculator și de acolo face telnet în lumea exterioară. Cu ajutorul unui server proxy aplicație acest lucru este automatizat. Când dau telnet în lumea exterioară clientul meu trimite cererea întâi la server-ul proxy. Apoi proxy-ul se conectează la serverul din lumea exterioară cerut de mine și-mi returnează datele cerute. Serverele proxy loghează acțiunile pe care le întreprind. Există http proxy-uri, ftp proxy-uri care prelucrează datele înainte de a le trimite clientului (scanează datele pentru viruși, filtrează cuvinte „nepotrivite”, etc.). Serverele proxy aplicație pot autentifica utilizatorii. De asemenea ele se pot configura să accepte conexiuni de la anumite adrese și de la altele, nu. Exemplu de server proxy aplicație este Squid.

1.2.3.2 Proxy SOCKS

Serverul proxy SOCKS [18] este un proxy generic și suportă aproape fiecare aplicație.În momentul actual sunt două versiuni, SOCKS v4 ce oferă un mechanism pentru trafic bazat pe conexiunile TCP pentru a se conecta în mod transparent la un server de aplicații pintr-un socket gateway. Această versiune nu oferă servicii de autentificare. În SOCKS v5 sunt implementate următoarele functii:autentificarea clientului, rezoluția de nume dar și suport pentru pachetele UDP.

Socket-ul clientului deschide o conexiune TCP cu socket-ul serverului (de obicei portul 1080). Clientul trimite un pachet “Client Negotiation” în care sunt trecute mai multe metode de autentificare pe care serverul le poate folosi vis-à-vis de client.

Fig1.35 Structura pachet Client Negotiation

VER – versiune socks

NMETHOD – metodele care vor fi enumerate ulterior pentru autentificare client-server

METHODS – lista metodelor prin numerele lor de identificare

Dacă serverul proxy pachetul trimis de client, îi va răspunde acestuia cu un pachet “Server Negotiation”, unde valoarea din campul METHOD reprezintă metoda de autentificare cerută de server. Procesul continuă cu autentificarea clientului LAN.

Fig1.36 Structură pachet Server Negotiation

După pasul de autentificare, socket-ul clientului trimite o cerere către serverul SOCKS, mesajul “Client Request”, prin care îl informeaza ce serviciu dorește, pe ce adresă IP și pe ce port.

Fig 1.37 Structură pachet Client Request

Clienții vor trimite intotdeauna cereri CONNECT ( 0x01 ) către serverul SOCKS, după ce autentificarea client-server este finalizată. Sunt și servicii precum FTP, la care este necesar să trimitem și cereri BIND (0x02) după cererile CONNECT.

CMD – Command. Poate avea doar trei valori: 0x01 pentru “CONNECT”, 0x02 pentru “BIND” și 0x03 a pentru “UDP Asociate”

RSV – Reserved

ATYP – Address Type. Poate fi IPv4(0x01), IPv6(0x03) său DomainName (0x02)

După primirea pachetului “Client Request”, serverul proxy evaluează solicitarea ținând cont de adresa LAN a clientului, și de alte reguli de control ale accesului date de obicei de un firewall. Dacă cererea clientului este refuzată, conexiunea este abandonată. În caz contrar, serverul proxy va trimite un răspuns ( pentru cererile CONNECT și UDP) sau doua răspunsuri (pentru cererile BIND).Aceste răspunsuri sunt date de valoarea din campul REP.

Fig 1.38 Structură pachet Server Reply

REP – Replies – Răspunsuri pe care le poate trimite serverul:

0x00: Conexiune realizată cu serverul

0x01: Eroare SOCKS proxy

0x02: Conexiune nepermisă de server

0x03: Rețeaua nu este accesibilă

0x04: Gazda la distanță nu este accesibilă

0x05: Solicitare de conectare cu gazda la distanța refuzată

0x06: Timeout ( valoare TTL expirată)

0x07: Comanda SOCKS nu este suportată

0x08: Tipul adresei nu este suportat

0x09 through 0xFF: nedefinite

BND.ADDR – Adresa IP publică a serverului proxy SOCKS.

BND.PORT – Portul deschis pe serverul SOCKS pe care se trimit datele.

Dacă conexiunea este una reușita, serverul proxy redirecționează toate pachetele către socket-ul clientului și vice versa, pe toată durata sesiunii de comunicare.

1.2.4 Sisteme de detecție a intruzionilor

Detecția intruziunilor reprezintă un proces informatic de monitorizare a acțiunilor neautorizate de exploatare sau penetrare a unui sistem de calcul sâau chiar a unei rețele de calculatoare prin “ocolirea” sistemelor de securitate ale stației de lucru/rețelei respective.Pentru evitarea acestor breșe de securitate s-au dezovltat sisteme de detecție a intruziunilor (IDS), definite ca produse hardware sau software al căror rol este de a monitoriza și analiza posibilele intruziuni.

Sistemele de tipul Intrusion Detection System se pot clasifica în două grupe principale și anume IDS de rețea (NIDS) și IDS de stație (HIDS).

În comparatie cu echipamente firewall care filtrează traficul în interiorul unei rețele pe baza regulilor de tip “allow” și “deny”, IDS face analiza asupra traficului permis de către un firewall sau un router pentru a identifica posibilele tentative de atac.

Sistemele de detecție a intruziunilor pot fi [19] implementate fie ca sonde, fie ca agent. Din punct de vedere al eficienței sondele reprezintă cea mai bună soluție deoarece acestea minimizează substanțial resursele folosite de către stațiile de lucru existente prin ascultarea pasivă a rețelei și raportarea fără intrerupere către consola centrală.

Principalele functii executate de serviciile de detectare a intruziunilor la nivel de dispoztiv de rețea sunt:

Inspectarea fluxului de date ce trece prin rețea

Identificarea semnăturilor de atac și a anomaliilor ce apar în traficul de date

Lansarea procedurilor de apărare

Generarea unor log-uri și alarme ce instiințează administratorii de rețea

Răspunderea automată în cazul unor anumite probleme anterior predefinite.

Toate IDS-urile cunoscute sunt livrate cu reguli care să detecteze scanările Nmap deoarece acestea preced de obicei un atac. Multe dintre acestea s-au transformat în sisteme de prevenire a intruziunilor (IPS) care blochează în mod activ traficul presupus malefic. Din păcate pentru administratorii de rețea și vânzătorii IDS-urilor, detectarea în mod corect a relelor intenții prin analizarea pachetelor este o problemă dificilă. Atacatorii cu răbdare, îndemânare și ajutor din partea anumitor opțiuni Nmap pot în mod normal să treacă de IDS nedetectați. Între timp, administratorii au de a face cu o mulțime de alerte false când trafic inocent este greșit diagnosticat și se emite o atenționare său este chiar blocat.

Un alt mod de a efectua detecția este acela care se bazează pe sesizarea distincției între comportament „normal” și, respectiv, „anormal” în cadrul sistemului țintă. Metoda constă în crearea de profile de comportament pentru programe său utilizatori ai sistemului și clasificarea că posibil intruzive a acelora care deviază de la profilele stabilite. Acest lucru se poate realiza folosind statistici simple său metode „inteligente”, cum ar fi cele bazate pe rețele neurale, tehnici de modelare și simulare, tehnici de extragere de date relevante. În orice caz, motorul de analiză poate combina mai multe metode de detecție pentru a realiza o determinare mai completă a intruziunilor.

Componenta Politica de Detecție [20] conține informații pre-programate despre modul de detectare a intruziunilor. Practic, aici sunt stocate semnăturile intruziunilor și pragurile de alarmă. Informațiile de configurare pentru detectarea anomaliilor, că și regulile referitoare la informațiile care trebuie transmise la unitatea de răspuns, sunt, de asemenea, stocate la acest nivel. Baza de date cu informații de stare (state information) conține informații dinamice folosite pentru detecție. Acestea pot fi informații de stare despre semnăturile intruziunilor parțial completate și despre comportamentul curent al sistemului.

Colectare date Detecție Răspuns

Fig 1.39 Sistem de detectare a intruziunilor

Informațiile despre evenimente care sunt categorisite drept intruzive său anormale de către motorul de analiză sunt trimise la Unitatea de Răspuns. În baza regulilor pre-programate din baza de date Politica de Răspuns, se decide modul de răspuns la diferite evenimente.

Într-un sistem distribuit, unitatea de răspuns poate primi intrări de la mai multe motoare de analiză și, de asemenea, poate corela alarmele. Posibilele acțiuni de răspuns sunt acelea de notificare a administratorului, de reconfigurare automată a sistemului țintă pentru blocarea acțiunilor autorului intruziunii, său de implementare a unor mecanisme specifice care să susțină răspuns manual (al utilizatorului). O altă opțiune de răspuns ar fi aceea de a permite sistemului IDS să modifice configurația pentru colectarea datelor său politica de detecție pentru a permite colectarea mai multor informații despre un eveniment în desfășurare.

1.2.4.2 Metodologii comune de detecție

Detecția bazata pe semnături. Semnătura este la baza, un model al unei amenințări cunoscute.Acest tip de detecție compară semnăturile din baza de date împotriva evenimentelor observate pentru a identifica posibilele incidente.Această metoda este foarte eficientă în detectarea amenintarilor cunoscute, dar în mare parte ineficientă la detectarea amenintarilor anterioare.

Incercarea de conexiune telnet cu numele de utilizator root sau un log al sistemului de operare , cu o valoare de cod de stare 645 (auditul gazdei a fost dezactivat) pot fi considerate semnături.Se poate spune că este cea mai simplă metodă de detectare, deoarece compară doar unitatea curentă de activitate, cum ar fi un pachet sau o intrare din loguri, cu o listă de semnături utilizând operatorii de comparare ai șirurilor de caractere.

Detectarea anomaliilor – reprezintă procesul de comparare a definițiilor, activităților ce sunt considerate normale cu definițiile acelor evenimente observate pentru a identifica abaterile semnificative.

Un mare plus al acestei metode este faptul că detecția amenințărilor necunoscute anterior este foarte eficientă. De exemplu, să presupunem că o stație de lucru este infectată cu un nou tip de malware. Acest malware poate reduce drastic performanțele calculatorului prin trimiterea de spam-uri, inițializarea a foarte multe conexiuni la rețea, fiind astfel caracterizat cu un comportament diferit față de profilul implementat calculatorului respectiv.

După o perioadă de formare de câteva zile sau chiar saptamani, este generat un profil inițial.Acesta poate fi static sau dinamic. Odată cu generarea profilului static, acesta nu mai poate fi schimbat decât cu exceptia cazului în care IDS-ul va genera un nou profil. Profilul dinamic se ajusteaza în mod constant pe măsura ce se observa alte evenimente suplimentare.

Analiza protocoalelor de tip stateful – reprezintă procesul de comparare a profilurilor prestabilite ale definițiilor, general acceptate, ale activităților benigne ale protocoalelor pentru fiecare stare de protocol împotriva evenimentelor observate pentru a identifica deviațiile.

”Stateful” înseamnă că IDS-ul este capabil să înțeleagă și să urmărească starea protocoalelor specifice nivelului rețea, transport său aplicație, în cazul celor care au noțiunea de stare.Aceasta analiza se bazeaza pe profiluri universale, dezvoltate de furnizori de software și organisme de standardizare (IETF, RFC) , în care sunt descrise felul în care ar trebuie să fie utilizate anumite protocoale.

Această analiză include, de obicei, controale rezonabile asupra unor comenzi individuale, cum ar fi lungimea minimă și maximă de argumente. Dacă o comandă are, de obicei, un nume de utilizator ca argument format din maxim 20 de caractere, atunci un argument cu o lungime de 1000 de caractere este suspect. În cazul în care argumentul cu o lungime mare conține date binare, gradul de suspiciune va crește.

Această metodă de analiză este o consumatoarea foarte mare de resurse, din cauza complexității analizei realizate și supraîncărcarea ce rezultă din urmărirea simultană a mai multor sesiuni.De altfel, acest fapt reprezintă și dezavantajul principal al acestei metode. O altă problemă serioasă este aceea că atacurile care nu încalcă caracteristicile de comportament general acceptat al protocolului nu sunt detectate(ex: efectuarea mai multor acțiuni benigne într-o perioadă scurtă de timp pentru a provoca o blocare a serviciului – DoS)

Capitolul 2

2.1 Firewall de filtrare pachete

2.1.1 Iptables

Iptables a fost dezvoltat de Netfilter Project și a fost introdus pe majoritatea distribuțiilor de linux începând cu versiunea de kernel 2.4 în ianuarie 2001.Iptables oferă monitorizare completă a protocoalelor, inspecția pachetelor de nivel aplicație, limitarea traficului dar și un puternic mecanism pentru filtrarea datelor.

2.1.1.1 Filtrarea pachetelor folosind iptables

O politică iptables este construită dintr-un număr de reguli care descriu acțiunile ce ar trebui realizate de către kernel împotriva anumitor clase de pachete de date.Fiecare regulă este aplicată unui lanț (iptable chain) dintr-o tabelă(table). Un lanț reprezintă o colecție de reguli care sunt comparate, într-o anumită ordine, cu pachetele care partajează o caracteristică comună (cum ar fi traficul routat către sistemul Linux). Tabela reprezintă un constructor iptables care delimitează categorii largi de funcționalitate, cum ar fi filtrarea pachetelor său Network Address Translation). Există 4 tabele și anume: “filter” – unde se aplică regulile de filtrare , “nat” – unde se aplică regulie NAT, “mangle” – unde se implementează reguli speciale pentru alterarea pachetelor de date și “raw” – unde sunt aplicate regulile care ar trebui să funcționeze independent de subsistemul de urmărire a conexiunilor Netfilter.Fiecare tabelă vine cu seturi de reguli predefinite dar exista și posibilitatea de a crea un nou set de reguli care este asociat unei etichete cum ar fi INPUT_ESTABLISHED său DMZ_NETWORK.

Cele mai importante și des folosite lanțuri predefinite sunt:

INPUT – reprezintă setul de reguli ce este traversat de pachete care sunt destinate sistemului local Linux după efectuarea unui calcul de rutare în cadrul kernel-ului.

OUTPUT – este lanțul rezervat pentru pachetele generate de sistemul Linux

FORWARD – este setul de reguli ce guvernează pachetele de date care sunt redirecționate prin sistemul Linux.

Mai sunt 2 lanțuri suplimentare care sunt importante pentru implementarea serioasă a iptable și anume PREROUTING și POSTROUTING din tabela nat, care sunt folosite pentru a modifica anteturile de pachete înainte și după ce se face un calcul al rutei IP în cadrul kernel-ului.

Linux Kernel

Intrare Iesire

pachete pachete

Fig 2.1 Circuitul unui pachet filtrat

2.1.1.2 Potriviri iptables

O potrvire iptables este o condiție ce trebuie îndeplinită de un pachet de date, pentru ca iptables să proceseze în funcție de acțiunea specificăta de regulă ținta.De exemplu, pentru a aplica o regulă doar pentru pachetele TCP, se folosete potrivirea –protocol.

Cele mai importante și des intalnite potriviri sunt:

–source ( -s ) – adresa IP sau rețeaua sursă

–destination ( -d ) – adresa IP său rețeaua destinație

–protocol ( -p ) – valoarea IP

–în-interface ( – i ) – interfața de intrare

–out-interface ( -o) – interfața de ieșire

–state – un set de stari de conexiune

–string – o secvență de octetți de date de la nivelul aplicație

–comment – asociază până la 256 de octeți de date de comentarii cu o regulă din memoria kernelului

2.1.1.3 Tinte iptables

Iptables accepta un set de ținte care declanșează o acțiune când un pachet se potrivește cu o regulă.Cele mai importante ținte folosite sunt:

ACCEPT – permite unui pachet să își continue drumul către destinație

DROP – renunță la un pachet. Nu se efectuează nicio altă prelucrare și, în ceea ce privește stiva de primire, este ca și cum pachetul nu ar fi fost trimis niciodată

LOG – înregistrează pachetul într-un jurnal de sistem

REJECT – renunță la pachet iar în același timp trimite un pachet de răspuns corespunzător( de exemplu un pachet TCP Reset pentru o conexiune TCP sau un mesaj ICMP Port Unreachable pentru un pachet UDP)

RETURN – Continuă procesarea unui pachet în cadrul unui lanț de reguli

Pentru a defini o configurație eficientă firewall pentru o rețea compusă din mai multe mașini client și două servere:

Acestea din urmă ( un server web și un server DNS) trebuie să fie accesibile din rețeaua externă

Sistemele din rețeaua interna ar trebui să poata iniția următoarele tipuri de trafic prin paravanul de protecție către serverele externe: interogări DNS, transferuri FTP, interogări NTP, sesiuni SSH, sesiuni SMTP, sesiune web peste HTTP/HTTPS, interogări whois.

Cu excepția accesului la serviciile enumerate mai sus, orice alt tip de trafic ar trebui blocat.

Sesiunile inițiate din rețeaua internă sau direct din firewall ar trebui să fie urmărite de către iptables, iar serviciile NAT ar trebui de asemnea să fie active

Firewall-ul ar trebuie să implementeze comenzi împotriva pachetelor falsificate(spoofed packets) din rețeaua internă care sunt redirecționate către orice altă adresă IP externă:

Firewall-ul trebuie să fie accesibil prin SSH din rețeaua internă, dar de nicaieri altundeva dacă nu ruleaza fwknop pentru autentificare

SSH ar trebui să fie singurul proces ce ruleaza pe firewall

Firewall-ul ar trebui să accepte solicitarile ICMP Echo atât din rețeaua internă, cât și din cea externă, dar pachetele ICMP nesolicitate care nu sunt Echo Requests ar trebui să fie abandonate de la orice adresă IP sursă.

2.1.2 Scriptul iptables.sh

Definirea unui script firewall eficient necesită implementarea seturilor de reguli INPUT, OUTPUT și FORWARD. Pentru a începe scriptul este esențial să definim trei variabile, IPTABLES, MODPROBE ( pentru calea către iptables și binarele modprobe ) și INT_NET ( pentru adresa subnet și masca de rețea ).De asemenea modulele pentru urmărirea conexiunii se încarcă cu comanda modprobe.

[iptablesfw]# nano -w iptables.sh

#!/bin/sh

IPTABLES=/sbin/iptables

MODPROBE=/sbin/modprobe

INT_NET=192.168.10.0/24

### eliminarea regulilor actuale și setarea țintei DROP

$IPTABLES -F

$IPTABLES -F -t nat

$IPTABLES -X

$IPTABLES -P INPUT DROP

$IPTABLES -P OUTPUT DROP

$IPTABLES -P FORWARD DROP

### încărcare module de urmărire a conexiunii

$MODPROBE ip_conntrack

$MODPROBE iptable_nat

$MODPROBE ip_conntrack_ftp

$MODPROBE ip_nat_ftp

2.1.2.1 Lanțul INPUT

După cum am mai spus, acest constructor iptables decide dacă un pachet este destinat său nu sistemului local.Dacă prima regulă în lanțul INPUT este setată pentru a renunța la toate pachetele (său dacă politica lanțului este DROP), atunci toate eforturile de a comunica direct cu sistemul pe baza oricărei comunicații IP (TCP,UDP său ICMP) vor eșua.

Potrivirea stării (“-m state”) este folosită de alături de criteriile INVALID (se aplică pachetelor ce nu pot fi indentificate ca făcând parte dintr-o conexiune existenta), ESTABLISHED (se aplică pachetelor doar după ce subsistemul Netfilter de urmărire a conexiunilor a verificat pachetele pentru ambele direcții), și RELATED (se aplică pachetelor care încep o nouă conexiune, iar aceasta este asociata unei conxiuni deja existente).

Prin indroucerea celor trei comezi IPTABLES de mai jos , pachetele care nu se potrivesc cu o stare valida vor fi înregistrate în log-uri și se va renunța la ele

### Reguli verificare conexiune

$IPTABLES -A INPUT -m state –state INVALID -j LOG –log-prefix "DROP INVALID " –log-ip-options –log-tcp-options

$IPTABLES -A INPUT -m state –state INVALID -j DROP

$IPTABLES -A INPUT -m state –state ESTABLISHED,RELATED -j ACCEPT

### Reguli anti-spoofing

$IPTABLES -A INPUT -i eth1 -s ! $INT_NET -j LOG –log-prefix "SPOOFED PKT "

$IPTABLES -A INPUT -i eth1 -s ! $INT_NET -j DROP

### Reguli ACCEPT

$IPTABLES -A INPUT -i eth1 -p tcp -s $INT_NET –dport 22 –syn -m state –state NEW -j ACCEPT

$IPTABLES -A INPUT -p icmp –icmp-type echo-request -j ACCEPT

### Regula INPUT LOG predefinită

$IPTABLES -A INPUT -i ! lo -j LOG –log-prefix "DROP " –log-ip-options –log-tcp-options

În acest set de reguli au fost adăugate regulile anti-spoof astfel încât pachetele ce provin din rețeaua internă trebuie să aibă adresa sursă din subnet-ul 192.168.10.0/24.Sunt și două reguli de tip ACCEPT, prima ce permite conexiunile SSH din cadrul rețelei interne iar a doua pentru a accepta din orice sușa mesajele ICMP Echo Requests. La sfârșit este regulă LOG predefinita.

2.1.2.2 Lanțul OUTPUT

Acest set de reguli permite aplicarea controalelor de nivel kernel pachetelor de rețea ce sunt generate de sistemul local.De exemplu, dacă o conexiune SSH este inițiată către un sistem extern de un utilizator local, lanțul OUTPUT poate fi folosit pentru a permite/interzice pachetul SYN extern.

###### OUTPUT chain ######

### Reguli verificare conexiune

$IPTABLES -A OUTPUT -m state –state INVALID -j LOG –log-prefix "DROP INVALID " –log-ip-options –log-tcp-options

$IPTABLES -A OUTPUT -m state –state INVALID -j DROP

$IPTABLES -A OUTPUT -m state –state ESTABLISHED,RELATED -j ACCEPT

### Reguli ACCEPT pentru permiterea conexiunilor de ieșire

$IPTABLES -A OUTPUT -p tcp –dport 21 –syn -m state –state NEW -j ACCEPT

$IPTABLES -A OUTPUT -p tcp –dport 22 –syn -m state –state NEW -j ACCEPT

$IPTABLES -A OUTPUT -p tcp –dport 25 –syn -m state –state NEW -j ACCEPT

$IPTABLES -A OUTPUT -p tcp –dport 43 –syn -m state –state NEW -j ACCEPT

$IPTABLES -A OUTPUT -p tcp –dport 80 –syn -m state –state NEW -j ACCEPT

$IPTABLES -A OUTPUT -p tcp –dport 443 –syn -m state –state NEW -j ACCEPT

$IPTABLES -A OUTPUT -p tcp –dport 4321 –syn -m state –state NEW -j ACCEPT

$IPTABLES -A OUTPUT -p udp –dport 53 -m state –state NEW -j ACCEPT

$IPTABLES -A OUTPUT -p icmp –icmp-type echo-request -j ACCEPT

### Regula OUTPUT LOG predefinită

$IPTABLES -A OUTPUT -o ! lo -j LOG –log-prefix "DROP " –log-ip-options

–log-tcp-options

2.1.2.3 Lanțul FORWARD

Acum, să examinăm regulile iptables care se referă la pachetele care nu au o sursă său o adresă destinație asociată cu paravanul de protecție, dar care totuși încearcă să navigheze prin sistemul de firewall.Lanțul FORWARD oferă abilitatea de a adăuga opțiuni de control ale pachetului ce permit redirecționarea acestuia peste interfețele firewall.

###### Lanțul FORWARD ######

### Reguli verificare conexiune

$IPTABLES -A FORWARD -m state –state INVALID -j LOG –log-prefix "DROP INVALID " –log-ip-options –log-tcp-options

$IPTABLES -A FORWARD -m state –state INVALID -j DROP

$IPTABLES -A FORWARD -m state –state ESTABLISHED,RELATED -j ACCEPT

### Reguli anti-spoofing

$IPTABLES -A FORWARD -i eth1 -s ! $INT_NET -j LOG –log-prefix "SPOOFED PKT "

$IPTABLES -A FORWARD -i eth1 -s ! $INT_NET -j DROP

### Reguli ACCEPT

$IPTABLES -A FORWARD -p tcp -i eth1 -s $INT_NET –dport 21 –syn -m state –state NEW -j ACCEPT

$IPTABLES -A FORWARD -p tcp -i eth1 -s $INT_NET –dport 22 –syn -m state –state NEW -j ACCEPT

$IPTABLES -A FORWARD -p tcp -i eth1 -s $INT_NET –dport 25 –syn -m state –state NEW -j ACCEPT

$IPTABLES -A FORWARD -p tcp -i eth1 -s $INT_NET –dport 43 –syn -m state –state NEW -j ACCEPT

$IPTABLES -A FORWARD -p tcp –dport 80 –syn -m state –state NEW -j ACCEPT

$IPTABLES -A FORWARD -p tcp –dport 443 –syn -m state –state NEW -j ACCEPT

$IPTABLES -A FORWARD -p tcp -i eth1 -s $INT_NET –dport 4321 –syn -m state –state NEW -j ACCEPT

$IPTABLES -A FORWARD -p udp –dport 53 -m state –state NEW -j ACCEPT

$IPTABLES -A FORWARD -p icmp –icmp-type echo-request -j ACCEPT

### Regula LOG predefinită

$IPTABLES -A FORWARD -i ! lo -j LOG –log-prefix "DROP " –log-ip-options –log-tcp-options

2.1.2.4 Network Address Translation

Pentru conexiunile inițiate din interior, în implementarea scriptului vom folosini NAT source (SNAT) iar pentru conexiunile ce sunt inițiate din exterior vom folosi destination NAT (DNAT).

Tabela nat din cadrul iptables este dedicată tuturor regulilor NAT, dar totodata aceasta tabela conține și lanțurile PREROUTING – folosit pentru a aplica reguli în tabela nat acelor pachete ce nu au fost trecut înca prin algoritmul de rutare din kernel pentru a determina interfața pe care ar trebui să fie transmise, și POSTROUTING – responsabil pentru procesarea pachetelor ce au trecut prin algoritmul de rutare și sunt pe punctul de a fi transmise.

###### NAT rules ######

$IPTABLES -t nat -A PREROUTING -p tcp –dport 80 -i eth0 -j DNAT –to 192.168.10.3:80

$IPTABLES -t nat -A PREROUTING -p tcp –dport 443 -i eth0 -j DNAT –to 192.168.10.3:443

$IPTABLES -t nat -A PREROUTING -p tcp –dport 53 -i eth0 -j DNAT –to 192.168.10.4:53

$IPTABLES -t nat -A POSTROUTING -s $INT_NET -o eth0 -j MASQUERADE

În exemplul de mai sus primele reguli PREROUTING permit că cererile DNS și serviciile web dintr-o rețea externă să fie trimise către serverele interne corespunzătoare, iar regulă POSTROUTING permite conexiunilor ce provin din rețeaua internă și sunt destinate pentru rețeaua Internet să pară ca și cum ar proveni de la adresa IP 71.157.X.X.

Ultimul pas în construirea politicii iptable îl constituie activarea redirecționarii IP în kernel-ul Linux.

###### forwarding ######

echo "[+] Enabling IP forwarding…"

echo 1 > /proc/sys/net/ipv4/ip_forward

-A – Append – adaugă regula la sfârșitul cozii

-m – match – folosit la potrivirea stărilor (VALID, ESTABLISHED, INVALID)

-p, –protocol [!] protocol : specifică protocolul (de nivel transport) pachetelor care sunt verificate de regulă. Valoarea protocol poate fi una dintre valorile “tcp”, “udp”, “icmp” sau “all”

-s, –source, –src [!] address[/mask] [!] [port[:port]] : specifică sursa pachetului.

-d, –destination, –dst [!] address[/mask] [!] [port[:port]] : specifică destinația pachetului

-j, –jump tinta : aceasta opțiune specifică ținta regulii. Ținta poate fi ori un lanț (chain) definit de utilizator ori una din țintele speciale (specificăte mai sus) care decid soarta unui pachet

-i, –interface [!] nume : specifică interfața de rețea prin care un pachet este receptionat (pentru lanțul input) său prin care un pachet este trimis (pentru lanțurile output și forward)

-o, –interface[!]nume : specifică interfața de rețea prin care un pachet este transmis

–dport, –destination-port [!] [port[:port]] : se poate specifică portul destinație separat.

2.2 Network Intrusion Detection System (NIDS)

Un sistem de detectare a intruziunilor (IDS) [23] este un sistem care este utilizat pentru a detecta traficul rău intenționat și atacurile împotriva unei rețele său a unui singur sistem gazdă.

Un IDS lucrează folosind teoria că există o diferență între utilizatorii legitimi și traficul lor de rețea și utilizatorii rău intenționați și traficul acestora. Un IDS utilizează două metode diferite pentru a căuta o activitate rău intenționată: detectarea anomaliei statistice și detecția bazată pe reguli[21]

Soluțiile IDS pot fi poziționate în diferite locații din rețea. Acesta poate fi plasat direct pe un dispozitiv de rețea, cum ar fi un router, un switch, un sistem gazdă său poate fi plasat că dispozitiv propriu dedicat. Atunci când este plasat în rețeaua fizică, este cunoscut că IDS bazat pe rețea. Atunci când este plasat pe un sistem gazdă, este cunoscut că IDS bazat pe gazdă. Plasarea optimă pentru un IDS depinde de mediul pe care îl va proteja. În unele cazuri, există mai mult de un loc care este optim și în aceste cazuri speciale este posibilă implementarea a mai mult de un IDS pentru a oferi securitate mai mare.[24]

2.2.1 IDS bazat pe rețea (NIDS)

IDS-ul bazat pe rețea este folosit pentru a găsi traficul rău intenționat într-o rețea fizică. Aceasta poate fi plasată pentru a forța datele să circule prin ea său pe un port de acoperire. IDS va procesa apoi datele capturate care traversează rețeaua. Dacă găsește pachete de date suspecte, va trimite o alertă. Alerta este scrisă într-un fișier jurnal care poate fi citit de administratori. Aceasta este adesea asociată cu un software care va scana fișierul log pentru alerte noi și le va raporta administratorului. [25]

2.2.2 Snort

Snort este o IDS bazat pe rețea. Este un software open source creat de Martin Roesch. Deoarece Snort este un software open source, acesta este suportat pe un număr de sisteme de operare. Snort este un software versatil, deoarece este capabil să analizeze traficul în timp real și poate fi folosit pentru a efectua o serie de funcții diferite, cum ar fi analiza traficului și sniffing de pachete. Aceste funcții pot fi utilizate pentru detectarea și prevenirea atacurilor împotriva rețelei [26]. Snort aplică semnături și reguli pentru a găsi trafic de rețea rău intenționat

Snort este împărțit în mod logic în mai multe componente. Aceste componente colaborează pentru a detecta anumite atacuri și pentru a genera output-ul într-un format necesar din sistemul de detectare. Un IDS bazat pe Snort este alcatuit din următoarele componente majore:[24]

Decodor Pachete

Ia pachete de la diferite tipuri de interfețe de rețea și pregătește pachetele care urmează să fie preprocesate sau care urmează să fie trimise la motorul de detectare. Interfețele pot fi Ethernet, SLIP, PPP , etc.

Preprocesoare

Sunt componente sau pluginuri care pot fi utilizate cu Snort pentru a aranja sau modifica pachetele de date înainte că motorul de detectare să facă unele operații pentru a afla dacă pachetul este utilizat de un intrus. Unele preprocesoare efectuează de asemenea detectarea prin găsirea de anomalii în anteturile de pachete și generarea de alerte. Preprocesoarele sunt foarte importante pentru că orice IDS să pregătească pachetele de date care urmează să fie analizate în raport cu regulile din motorul de detectare. Hackerii folosesc diferite tehnici pentru a păcăli IDS în moduri diferite. De exemplu, este posibil să fi creat o regulă pentru a găsi o semnătură "scripts / iisadmin" în pachetele HTTP. Dacă vă potrivi exact acest șir, puteți fi ușor păcălit de un hacker care face mici modificări la acest șir.

Pentru a complica situația, hackerii pot introduce și caractere hexazecimale Uniform Resource Identifier (URI) său caractere Unicode care sunt perfect legale în ceea ce privește serverul web. Rețineți că serverele web înțeleg, de obicei, toate aceste șiruri și sunt capabile să le preproceseze pentru a extrage șirul "scripts / iisadmin" dorit. Cu toate acestea, dacă IDS caută o potrivire exactă, nu reușește să detecteze acest atac. Un preprocesor poate rearanja șirul astfel încât să poată fi detectat de IDS.

Preprocesoarele sunt de asemenea utilizate pentru defragmentarea pachetelor. Atunci când o piesă mare de date este transferată unei gazde, pachetul este de obicei fragmentat. De exemplu, lungimea maximă prestabilită a oricărui pachet de date dintr-o rețea Ethernet este de obicei de 1500 de octeți. Această valoare este controlată de valoarea maximă a unității de transfer (MTU) pentru interfața de rețea. Aceasta înseamnă că dacă trimiteți date care depășesc 1500 de octeți, acestea vor fi împărțite în mai multe pachete de date, astfel încât fiecare fragment de pachet să fie mai mic său egal cu 1500 de octeți. Sistemele de recepție sunt capabile să reasambleze din nou aceste unități mai mici pentru a forma pachetul original de date. Pe IDS, înainte de a putea aplica orice reguli său de a încerca să găsiți o semnătură, trebuie să reasamblați pachetul. De exemplu, jumătate din semnătură poate fi prezentă într-un segment, iar cealaltă jumătate într-un alt segment. Pentru a detecta corect semnătura, trebuie să combinați toate segmentele de pachete. Hackerii folosesc fragmentarea pentru a învinge sistemele de detectare a intruziunilor. Preprocesorele sunt folosite pentru a proteja împotriva acestor atacuri.

Motorul de detecție

Motorul de detectare este cea mai importantă parte a lui Snort. Responsabilitatea să este de a detecta dacă există o activitate de intruziune într-un pachet. Motorul de detectare utilizează Snortrules în acest scop. Regulile sunt citite în structurile de date interne său în lanțuri unde sunt potrivite împotriva tuturor pachetelor. Dacă un pachet corespunde unei reguli, se iau măsurile corespunzătoare; altfel pachetul este abandonat. Acțiunile adecvate pot fi înregistrarea pachetelor său generarea de alerte.

Motorul de detectare este partea critică a momentului Snort. În funcție de cât de puternic este calculatorul dvs. și de câte reguli ați definit, este posibil să dureze mai mult timp pentru a răspunde la diferite pachete. Dacă traficul din rețea este prea mare atunci când Snort funcționează în modul NIDS, este posibil să renunțe la unele pachete și poate să nu primească un răspuns real în timp real. Sarcina pe motorul de detectare depinde de următorii factori:

Numărul de reguli

Puterea stației pe care rulează Snort

Viteza magistralei interne folosită pe mașina Snort

Nivelul de trafic care se face pe rețea

Rețineți că sistemul de detectare poate diseca un pachet și poate aplica reguli diferitelor părți ale pachetului. Aceste părți pot fi:

Antetul IP al pachetului.

Antetul nivelului transport. Acest antet include anteturile TCP, UDP sau alte straturi de transport. Poate funcționa și pe antetul ICMP.

Antetul nivelului aplicație. Antetele pentru nivelul aplicațiile includ, dar nu se limitează la acestea, antetul DNS, antetul FTP, antetul SNMP și antetul SMTP. Este posibil să fie necesar să utilizați anumite metode indirecte pentru anteturile stratului de aplicație, cum ar fi compensarea datelor care trebuie căutate.

Packet payload. Aceasta înseamnă că puteți crea o regulă folosită de motorul de detectare pentru a găsi un șir în interiorul datelor prezente în interiorul pachetului.

Sistemul de inregistrare și alertare

În funcție de ce detectează motorul de detectare într-un pachet, pachetul poate fi folosit pentru a înregistra activitatea său pentru a genera o alertă. Jurnalele sunt păstrate în fișiere text simple, în fișiere de stil tcpdump său într-o altă formă. Toate fișierele din jurnal sunt stocate în folderul /var/log/snort în mod implicit. Puteți utiliza opțiunile din linia de comandă pentru a modifica locația generării de jurnale și alerte. Multe opțiuni din linia de comandă discutate în capitolul următor pot modifica tipul și detaliul informațiilor înregistrate de sistemul de înregistrare și alertare.

Module de iesire

Modulele de ieșire său modulele plug-în pot efectua operațiuni diferite, în funcție de modul în care doriți să economisiți rezultatele generate de sistemul de înregistrare și de alertare al Snort. În principiu, aceste module controlează tipul de ieșire generat de sistemul de înregistrare și alertare. În funcție de configurație, modulele de ieșire pot face următoarele lucruri:

Înregistrarea în fișiserul /var/log/snort/alerts sau intr-un alt fișier

Trimiterea capcanelor SNMP

Trimiterea mesajelor unității syslog

Modificarea configurației pe routere și firewall-uri

Trimite mesaje de blocare a mesajelor de tip server (SMB) către mașinile Microsoft Windows

Structura unei reguli:

Toate regulie Snort sunt formate de 2 parti logice: antetul regulei și optiunile acesteia. Antetul conține informații despre ce acțiune va lua regula respectiva. Acesta conține, de asemenea, criterii pentru potrivirea unei reguli împotriva pachetelor de date. Partea de opțiuni conține, de obicei, un mesaj de alertă și informații despre ce parte a pachetului ar trebui utilizată pentru a genera mesajul de alertă. Partea opțiunilor conține criterii suplimentare pentru potrivirea unei reguli cu pachetele de date. O regulă poate detecta un tip său mai multe tipuri de activități de intruziune. Normele inteligente ar trebui să poată aplica mai multor semnături de intruziune.

Fig 2.2 Structura unui antet de regula Snort

Action – Determină tipul de acțiune întreprinsă atunci când criteriile sunt îndeplinite și o regulă este exact potrivită cu un pachet de date. Acțiunile tipice generează un mesaj de avertizare său jurnal său invocă o altă regulă.

Protocol – Este folosit pentru a aplica regula pe pachete doar pentru un anumit protocol. Acesta este primul criteriu menționat în regulă

Address – Definește adresele de destinație și sursă. Adresele pot fi o singură gazdă, mai multe gazde sau adrese de rețea.

Port – Determină porturile de sursă și de destinație ale unui pachet pe care se aplică regula. În cazul protocoalelor de nivel de rețea precum IP și ICMP, numerele porturilor nu au nici o semnificație.

Direction – Specifică care adresa și port sunt folosite că sursa și care sunt folosite că destinație.

De exemplu, luați în considerare următoarea regulă care generează un mesaj de alertă ori de câte ori detectează un pachet ICMP ping (ICMP ECHO REQUEST) cu TTL egal cu 100:

alert icmp any any -> any any (msg: "Ping with TTL=100"; \ ttl: 100;)

Partea din regulă înainte de paranteză de pornire se numește antetul regulii. Partea de regulă care este închisă de paranteze este partea opțiunilor.

2.2.2.1 Preprocesoare

HTTP Decode – Permite sistemelor de detecție a intruziunilor să utilizeze caractere hexazecimale în URI pentru a învinge atacurile cunoscute. De exemplu, acest lucru se poate face inserând ceva că % 3A% 2F% 2F în URI pentru a înlocui caracterele //. Preprocesorul de decodare HTTP normalizează cererile HTTP astfel încât acestea să poată fi procesate corect de către motorul de detectare.

preprocessor http_decode: 80 8080 443

Portscan – Este un proces de a afla care porturi sunt deschise pe o anumită gazdă său pe toate gazdele dintr-o rețea. Primul pas în orice activitate de intrus este, de obicei, de a afla ce servicii rulează pe o rețea. Odată ce un intrus a găsit aceste informații, sunt încercate atacuri pentru vulnerabilități cunoscute pentru aceste servicii. Proprocesorul de porturi este proiectat pentru a detecta activitățile de scanare în port. Preprocesorul poate fi utilizat pentru logarea activităților de scanare port într-o anumită locație, pe lângă logarea standard.

preprocessor portscan: 192.168.1.0/24 5 10 \ /var/log/snort/portscan.log

Modulul frag2 – Preprocesorul frag2 utilizează un algoritm de arbore splay, care este o structură de date auto-organizatoare. Pentru configurare, utilizare și administrare a Snort, nu trebuie să înțelegeți acest algoritm. Cu ajutorul lui frag2, puteți configura limitele de expirare și de memorie pentru defragmentarea pachetelor. Implicit, preprocesorul folosește 4 MB de memorie și o perioadă de timp de expirare de 60 de secunde. Dacă un ansamblu de pachete nu are succes în această perioadă de timp, fragmentele anterioare colectate sunt aruncate.

preprocessor frag2 – predefinit

preprocessor frag2: 2097152, 30 – Memorie 2Mb și perioada de expirare de 30 secunde

Modulul stream4 – Acesta oferă două funcții de bază: reasamblarea fluxului TCP și inspecția stateful a pachetelor. Trebuie să configurați două preprocesoare în fișierul snort.conf pentru Stream4 pentru a funcționa corect. Aceste module sunt "stream4" și "stream4_reassemble". Ambele au un număr de argumente. Dacă nu specificăți un argument, se utilizează o valoare implicită. Formatul general al preprocesorului stream4 este după cum urmează:

preprocessor stream4: [noinspect], [keepstats], [timeout ], [memcap ], [detect_scan], \ [detect_state]

–noinspect – Dezactivează inspecția de tip stateful

–keepstats – Înregistrează rezumatul sesiunii în fișierul session.log

–timeout – Timeout pentru menținerea unui flux în stare activă ( implicit 30 secunde )

–memcap – Cantitatea maximă de memorie utilizată de modul ( implicit 8 MB )

–detect_scan – Detectează activitatea de scanare port

–detect_state – Detectează diverse probleme legate de fluxurile TCP

Formatul general al preprocesorului stream4_reassemble este după cum urmează:

preprocessor stream4_reassemble: [clientonly], [serveronly], [noalerts],\ [ports<portlist>]

–clientonly – Reasamblarea pachetelor de date pentru fluxul de client

–serveronly – Reasamblarea pachetelor de date pentru fluxul de server

–noalerts – Nu alertați pentru atacuri de tip inserție său evaziune

–ports – Lista porturilor pentru care vor fi asamblate fluxurile. Numerele porturilor trebuie separate de un caracter spațiu

Modulul spade – Acesta este folosit pentru a detecta anomaliil generale în pachetele IP și un număr de cuvinte cheie preprocesor sunt asociate cu acesta. SPADE păstrează o evidență a datelor istorice și utilizează valorile pragului pentru a raporta anomalii. Ar trebui să țineți cont de unele cerințe de eficiență și de memorie pentru SPADE. Poate fi nevoie de o mulțime de memorie pentru a păstra datele statistice ale SPADE și poate fi necesară o putere de procesare semnificativă pentru rețelele de încărcare ridicată.

ARP Spoofing – Preprocesorul arpspoof detectează anomalii în pachetele ARP. Mai exact, face următoarele:

• Pentru toate solicitările ARP, dacă adresa MAC sursă și adresa MAC a expeditorului sunt diferite, este generată o alertă. Dacă adresa MAC a sursei din pachet nu se potrivește cu adresa MAC asociată cu adresa IP sursă, atunci este generată o alertă.

• Pentru răspunsurile ARP, adresa MAC a sursei este comparată cu adresa MAC a expeditorului. În mod similar, adresa MAC de destinație este comparată cu adresa MAC a receptorului. O alertă este generată dacă aceste intrări nu se potrivesc.

• Pentru cererile ARP unicast, dacă adresa MAC destinație nu este adresa de difuzare (FF: FF: FF: FF: FF), este generată o alertă. Pentru a verifica această anomalie, trebuie să plasați o linie în fișierul snort.conf “preprocessor arpspoof: -unicast”.

•Puteți să introduceți în prealabil perechile de adrese MAC / IP în memoria cache internă Snort. Preprocesorul va compara aceste intrări pre-populate cu informații din pachetele ARP primite. În caz de nepotrivire, va fi generată o alertă.

Capitolul 3

Configurare firewall pe Raspberry Pi

După implementarea următoarelor etape vom avea un firewall pentru protecția rețelei având următoarele caracteristici:

Întărește politicile privind traficul de rețea

Asigurarea că pachetele anormale nu ies său intră în rețeaua noastră

Server DHCP ce distribuie parametrii de rețea în LAN

DNS cache/server pentru a mări viteza cererilor DNS și filtrarea de interogări DNS greșite

NIDS pentru a detecta traficul rău intenționat, cum ar fi malware-ul său exploatările de vulnerabilitate.

Rețea centrală de monitorizare a nodului pentru urmărirea și depanarea traficului de rețea.

De ce avem nevoie pentru realizarea propriului firewall?

O placă de dezvoltare Raspberry Pi

Un card microSD de minim 8GB

Un cablu Ethernet

Cablu mini-usb pentru alimentare

Imaginea virtuală a unei distribuții linux. ArchLinux ARMv8 în cazul de față

Software pentru trecerea ȘO pe cardul microSD.Win32DiskImager în cazul de față

După instalarea programului Win32DiskImager, îl deschidem, selectam imaginea .img a distribuției linux, selectam cardul SD după care apăsam pe butonul Write.Scoatem cardul din laptop/PC și îl introducem în placa de dezvoltare după care o alimentăm la o sursă de curent. Acum avem o distribuție de linux, ArchLinux.

După introducerea datelor de conectare (root/root) este recomandat să schimbăm parola introducând comanda passwd .

3.1 Configurare limbă

Pentru instalarea sistemului de operare într-o altă limbă în afară de limba engleză:

Cautăm țara dorită în fișierul /etc/locale.gen

Introducem comanda locale-gen pentru compilarea fișierul locale.gen după ce am adus modificări acestuia din urmă.

Introducem comanda reboot pentru repornirea sistemului de operare.

3.2 Configurare rețea

Mutam calea directorului în /etc/netctl după care copiem configurația fișierului exemplu intr-un alt fișier ce va reprezenta interfața pe care dorim să o folosim.

Deschidem fișierul eth0 și facem următoarele modificari:

Trebuie să asignăm un IP static pentru firewall-ul nostru dar și masca de rețea, respectiv gateway.În configurația de mai sus avem rețeaua 192.168.0.0/24, cu gateway LAN având IP 192.168.0.1/24 și adresa IP firewall 192.168.0.3/24.

Adaugam IP-ul firewall în fișierul /etc/hosts

Pornim interfața

Setăm că interfața să pornească odată cu sistemul de operare.

Repornim sistemul

3.3 Instalarea și pregătirea sistemului:

Actualizarea sistemului

Inițializarea cheilor

Adăugare user și parola

Pentru că user-ul să poata executa orice comanda este necesar să modificăm fișierul /etc/sudoers. Trebuie doar să ștergem caracterele de comentariu din fața rândului.

Instalare pachete

După repornirea sistemul introducem comanda htop..Dacă de exemplu memoria totală este sub 128MB înseamnă că start.elf împarte memoria astfel 128MB pentru GPU și 128MB pentru sistemul de operare.Pentru a aloca o anumită memorie sistemului trebuie să introducem următoarele comenzi, unde XXX reprezintă valoarea memoriei

Avem un sistem de operare actualizat și funcțional, dar nu este folosită toată capacitatea de stocare a cardului. Pentru a utiliza întreaga memorie trebuie să refacem partiția.

3.4 Configurare SSH

SSH (Secure Shell) este serviciul prin care ne putem conecta de la distanță folosind un client SSH.Pentru a ne conecta de la distanță la firewall trebuiesc făcute câteva modificări în fișierul /etc/ssh/sshd_config.

3.6 Securizarea nivelului rețea

Încărcarea tuturor fișierelor de configurație se face executând comanda:

După executarea comenzii căutam fișierul /usr/lib/sysctl.d/50-default.conf , îl copiem în cadrul directorului /etc/sysctl.d/ și îl redenumim 51-net.conf.Pentru o bună securitate fișierul trebuie să aibă următorii parametri bine definiți:

Toți parametrii ce nu trimit redirecționări ICMP sunt cruciali.Folosind un gateway cu o singură placa de rețea ( NIC ), adresa IP asignata firewall-ului trebuie să fie în același subnet cu celelalte gazde din LAN, dar și în același subnet cu router-ul/modemul DSL care este ultmimul gateway.Dacă permitem firewall-ului trimiterea redirecționărilor ICMP, acesta va spune gazdelor care fac trafic, să încerce să redirecționeze tot traficul direct către router, fiind mai eficient deoarece distanța este de doar un “hop”. În cazul în care redirecționările ICMP treceau prin firewall iar apoi în router, distanța era de 2 “hopuri”.

3.7 Configurare servere DHCP și DNS

Având un server DHCP configurat pe firewall, acesta va permite gateway-ului să trimită informații noilor gazde, astfel încât:

Gazdele vor trimite tot traficul prin firewall, precum un gateway

Gazdele vor trimite toate interogările DNS, precum un server DNS.

Serverul DNS ne va permite să avem răspunsuri DNS mai rapide, deoarece ele vor fi stocate în memoria cache.Unele interogări DNS comune se fac de mai multe ori, în timp ce răspunsul poate fi stocat în memoria cache o dată. Având răspunsul salvat, se va răspunde fără a a mai fi nevoie să interogheze serverele DNS ale ISP.

Sistemul de operare Linux oferă un pachet dnsmasq ce conține DHCP și DNS într-un singur daemon, folosește puține resurse și este ușor de configurat.

Instalare pachet dnsmasq

Urmează deschiderea fișierului de configurație cu un editor de text și modificarea acestuia în funcție de nevoi.

După modificarea fișierului, îl salvăm după care repornim serviciul dnsmasq pentru a se aplica noua configurație.După repornirea serviciului trebuie să intrăm pe interfața routerului/modemului și să dezactivăm funcția DHCP deoarece, în caz contrar vom avea 2 servere DHCP în același subnet.

Dacă folosim sistemul de operare Microsoft Windows și avem configurat DHCP, deschidem command prompt (cmd) cu drepturi de administrator și introducem următoarele comenzi:

Pentru verificarea funcționarii serviciului DNS este necesar să rulăm comanda tcpdump cu parametrii aferenți în timp ce pe o altă stație de lucru vom da ping într-un server web.

După cum putea vedea, după dezactivarea serverului DHCP al gateway-ului și introducerea comenzilor pe stația de lucru cu S.O Microsoft Windows, aceasta din urmă și-a alocat IP de la serverul DHCP pe care tocmai l-am configurat. În ceea ce privește funcționalitatea serverului DNS, acesta funcționează după cum se vede în output-ul comenzii tcpdump.

3.8 Configurare firewall

Următorul pas este crearea scriptului și definirea regulilor de filtrare.Următorul script va avea implementate următoarele funcții:

Blochează intrările/ieșirile pachetelor TCP invalide (chiar și din fluxurile deja stabilite).

Optimizează interogările DNS (câmpul IP TOS)

Identifica traficul după tipul acestuia, iar apoi aplica un set de reguli tipului de trafic respectiv

Asignarea adreselor se face aleatoriu în procesul NAT

Accepta doar câteva porturi de ieșire standard( HTTP, HTTPS, FTP)

Înregistrează cu exactitate pachetele care au fost abandonate și evita inundarea jurnalului (log flood)

Renunța la pachetele de intrare cu valoarea TTL mică (poate fi vorba despre un atac ttl_expiry său despre traceroute)

Detectează și blochează conexiunile malware de ieșire

Crearea fișierelor și acordarea drepturilor.

Primele 2 comenzi sunt introduse pentru crearea fișierelor firewall.advanced ce va conține regulile de filtrare a pachetelor și firewall.flows unde vor fi implementate regulile pentru redirecționarea traficului în cadrul unui lanț de reguli (de exemplu FORWARD_OUȚ, LAN_ÎN, etc).Am preferat să împart scriptul astfel deoarece este mai ușor de citit, urmând că scriptul firewall.flows să fie apelat în scriptul principal. Ultima comandă acorda drepturi de execuție doar utlizatorului ce deține fișierul respectiv.

Implementarea listelor de reguli pentru identificarea fluxului

Implementarea regulilor de filtrare în scriptul principal firewall.advanced

3.9 Modificare SYSLOG

Fără a înregistra traficul, avertismentele de securitate de la firewall, DHCP/DNS său NIDS sunt nefolositoare.Este important că log-urile să nu fie șterse la intervale scurte de timp.În continuare vom modifica fișierul logrotate.conf astfel încât înregistrările să fie păstrate timp de 3 luni.

3.10 Instalare și configurare SNORT

Snort este un sistem de detectarea a intruziunilor în rețea(NIDS) open-source. Verificarea datelor din cadrul pachetelor este funcția pe care iptables nu o poate face eficient. SNORT verifica mai adânc pachetele permițând astfel să detecteze traficul malițios.

Vom face câteva modificări în fișierul de configurare pentru a dezactiva câteva preprocesoare și seturile de reguli mai puțin utile dar și activarea funcției “lowmem” deoarece serviciul are nevoie de 1-2GB memorie RAM.

După instalare, Snort nu are nicio regulă implementată.Trebuie să ne înregistrăm un cont pentru a putea descărca setul de reguli.După înregistrarea contului, descărcăm setul de reguli îl dezarhivam, după care mutăm fișierele cu regulile ce ne interesează în directorul snort .

Următorul pas constă în crearea următoarelor 2 fișiere pe care Snort le va folosi:

[emil@RasPiWall ~] sudo touch /etc/snort/rules/white_list.rules

[emil@RasPiWall ~] sudo touch /etc/snort/rules/black_list.rules

Vom crea o regulă pentru testarea alertelor:

[emil@RasPiWall ~] sudo nano /etc/snort/rules/local.rules

alert icmp any any -> $HOME_NET any (msg:"ICMP alert test"; sid:10000001;)

Executarea serviciului Snort în modul consolă și verificarea apariției alertei ce am definit-o mai sus prin trimiterea unor pachete ICMP ECHO REQUEST de pe o altă stație din LAN.

[emil@RasPiWall ~] sudo snort -A console -q -u snort -g snort -c /etc/snort/snort.conf -i eth0

09/03-08:55:48.730337 [**] [1:10000001:0] ICMP test [**] [Priority: 0] {ICMP} 192.168.0.102 -> 192.168.0.3

09/03-08:55:48.730493 [**] [1:10000001:0] ICMP test [**] [Priority: 0] {ICMP} 192.168.0.3 -> 192.168.0.102

09/03-08:55:49.731753 [**] [1:10000001:0] ICMP test [**] [Priority: 0] {ICMP} 192.168.0.102 -> 192.168.0.3

09/03-08:55:49.731885 [**] [1:10000001:0] ICMP test [**] [Priority: 0] {ICMP} 192.168.0.3 -> 192.168.0.102

Din câte se poate vedea serviciul este funcțional, așa că vom testa din nou dar de data aceasta vom executa snort în modul daemon, dar pentru acest lucru este necesar să creăm un fișier swap pentru alocarea memoriei. 512MB sunt suficienți deoarece în modul consola folosește ~ 300MiWall ~] sudo dd if=/dev/zero of=/swapfile.img bs=1M count=512

512+0 records în

512+0 records out

536870912 bytes (537 MB, 512 MiB) copied, 47.4229 s, 11.3 MB/s

Concluzie

În acest studiu am examinat posibilitățile de utilizare a unui Raspberry Pi 3 că NIDS într-o rețea SOHO. Cu un buget de aproximat 400 de lei se poate realiza o soluție firewall și NIDS personalizata în funcție de necesități, dar totodată avem și un server DNS ce ne permite rezolvarea interogărilor mai rapid prin memorarea domeniilor și adresele aferente acestora într-un fișier cache.

Concluzia noastră este aceea că un Raspberry Pi poate fi într-adevăr utilizat că NIDS, dar numai în anumite circumstanțe.Nu putem folosi toate regulile utilitarului Snort deoarece suntem limitați de memoria RAM, dar în funcție de nevoi putem alege prin rotație regulile de care avem nevoie. Utilizarea unui Raspberry Pi că IDS are un efect negativ asupra transferului de rețea.

Că o declarație de încheiere, credem că prețul este unul dintre cele mai puternice argumente pentru acest tip de implementare. Costul scăzut al Raspberry Pis înseamnă că acesta poate fi un IDS mai accesibil comparativ cu o soluție scumpă pentru întreprinderi. Soluția noastră deschide posibilități pentru utilizatori în creșterea securității rețelei de domiciliu.Privind în viitor, credem că dispozitivele Raspberry Pi au multe posibilități de explorare și că ultimul cuvânt, rolul său în securitatea rețelei, nu a fost încă spus.

Lista Acronime

Referinte

[1] – https://www.iso.org/standard/39612.html

[2] RFC 1135 – Section 7.3 "A Tour of the Worm"

[3] http://spectrum.ieee.org/telecom/security/the-real-story-of-stuxnet

[4] Peter Gregory: Computer Viruses for Dummies 2004 : pag 234,Chapter 14 – Trojan Horses, Worms, Spam and Hoaxes

[5]Michal Zalewski: Silence on the Wire: A Field Guide to Passive Reconnaissance and Indirect Attack 2005

[6] Qijun Gu, PhD. , Peng Liu, PhD. : Denial of Service Attacks – Network Based Attacks

[7] Stacy Prowell, Rob Kraus, Mike Borkin – Seven Deadliest Network Attacks, 2010 Elsevier Inc – Chapter 6 – How Man-În-The-Middle Attacks Works

[8] http://www.ciscopress.com/articles/article.asp?p=2181837&seqNum=10 VLAN Security and Design (3.3) – Switch Spoofing Attack (3.3.1.1)

[9] http://www.ciscopress.com/articles/article.asp?p=2181837&seqNum=10 VLAN Security and Design (3.3) – Double-Tagging Attack (3.3.1.2)

[10] Stacy Prowell, Rob Kraus, Mike Borkin – Seven Deadliest Network Attacks, 2010 Elsevier Inc – Chapter 5 – How Spanning Tree Attacks Works

[11] Brian Komar, Ronald Beekelaarand Joern Wettern – Firewalls for Dummies 2nd Edition , Wiley Publishing, Inc 2003 – Part I: Introducing Firewall Basics , Chapter 1: Why Do You Need a Firewall? , Definning a Firewall

[12] Brian Komar, Ronald Beekelaarand Joern Wettern – Firewalls for Dummies 2nd Edition , Wiley Publishing, Inc 2003 – Part I: Introducing Firewall Basics , Chapter 3: Understanding Firewall Basics, Basic functions of a firewall

[13] http://ccrma.stanford.edu/planetccrma/man/man8/ipchains.8.html

[14] Michael Rash LINUX FIREWALLS Attack Detection and Response with iptables, psad, and fwsnort , 2007 – Chapter 1 Care and Feeding of Iptables

[15] http://firewall-review.narod.ru/circuit_level_gateway.html

[16] http://ipv6.com/articles/gateways/Application-Level-Gateway.htm

[17] Brian Komar, Ronald Beekelaarand Joern Wettern – Firewalls for Dummies 2nd Edition , Wiley Publishing, Inc 2003 – Part I: Introducing Firewall Basics , Chapter 3: Understanding Firewall Basics , Network Address Translation (NAT)

[18] RFC 1928 SOCKS Protocol Version 5 https://www.ietf.org/rfc/rfc1928.txt

[19] S. Northcutt. Intrusion detection faq: What is network based intrusion

detection? Sans. [Online]. Available: http://www.sans.org/securityresources/

idfaq/network_based.php

[20] Jones A., Sielken R. Computer System Intrusion Detection: A Survey, White Paper, http://www.cs.virginia.edu/~jones/IDS-research/Documents/jones-sielken-surveyv11.pdf

[21] S. Northcutt, J.Novak, „Network Intrusion Detection, 3rd Edition”, New Riders

Publishing, 2002

[22] W. Starlings, Network Security Essentials Applications and Standards, 4th ed. Prentice Hall, 1 Lake Street, Upper Saddle River, NJ 07458: Pearson Education, Inc., 2011.

[23] M. Berge. Intrusion detection faq: What is intrusion detection? SANS. [Online]. Available: https://www.sans.org/securityresources/idfaq/what_is_id.php

[24] E. Carter. (2002, 2) Intrusion detection systems. Cisco. [Online]. Available: http://www.ciscopress.com/articles/article.asp?p=25334

[25] S. Northcutt. Intrusion detection faq: What is network based intrusion detection? Sans. [Online]. Available: http://www.sans.org/securityresources/idfaq/network_based.php [Kontrollerad: 2015-05-09]

[26] Snort. What is snort? Sourcefire. [Online]. Available: https://www.snort.org/faq/what-is-snort

Lista figurilor

Fig 1.1 – Scanare ICMP

Fig 1.2 – Scanare TCP Connect când portul este deschis

Fig 1.3 – Scanare TCP Connect când portul este închis

Fig 1.4 – Scanare Inverse TCP când portul este deschis

Fig 1.5 – Scannare Inverse TCP când portul este închis

Fig 1.6 – Scanare XMAS când portul este deschis

Fig 1.7 – Scanare XMAS când portul este închis

Fig 1.8 – Scanare ACK Flag Probe bazata pe TTL

Fig 1.9 – Scanare ACK Flag Probe bazata pe WINDOW

Fig 1.10 – Banner-grabbing folosind telnet

Fig 1.11 – Banner-grabbing folosind netcat

Fig 1.12 – Aflare host-uri active folosind nmap (Ping Scan)

Fig 1.13 – Aflare informatii despre SO folosind nmap

Fig 1.14 – Informatii despre porturile deschise (Port Scan)

Fig 1.15 – Informatii despre servicii și versiunea acestora (Service Scan)

Fig 1.16 – Utilitarul tcpdump – captura traficului din linia de comanda

Fig 1.17, 1.18 – Utilitarul host – informatii despre server nume/mail al unui domeniu

Fig 1.19 – Exemplu de trafic valid cu rezultat de DoS: Slashdot effect

Fig 1.20 – TCP SYN Flood

Fig 1.21 – Atac MITM – Starea inițiala a rețelei

Fig 1.22 – Atac MITM – PC B trimite mesaj ARP către PC A

Fig 1.23 – Atac MITM – PC B trimite mesaj ARP către PC C

Fig 1.24 – Atac MITM – Starea finala a rețelei

Fig 1.25 – VLAN Hopping – Switch Spoofing

Fig 1.26, 1.27 – VLAN Hopping – Double Tagging

Fig 1.28 – Atac STP – Starea inițiala a retelie

Fig 1.29 – Atac STP – Starea finala a rețelei

Fig 1.30 – Firewall de filtrare pachete

Fig 1.31 – Circuit-Level Gateawy

Fig 1.32 – Application-Level Gateway

Fig 1.33 – Network Address Translation

Fig 1.34 – Server Proxy

Fig 1.35 – Structura pachet Client Negotiation

Fig 1.36 – Structura pachet Server Negotiation

Fig 1.37 – Structura pachet Client Request

Fig 1.38 – Structura pachet Server Reply

Fig 1.39 – Sistem de detectare al intruziunilor

Fig 2.1 – Circuitul unui pachet filtrat

Fig 2.2 – Structura unui antet de rugla Snort

Anexa A1 – Fișierul firewall.flows

Anexa A2 – Fișierul firewall.advanced

Anexa A3 – Fișierul snort.conf