Atenţie, firewall în reţea!

firewall

Până nu demult, majoritatea companiilor credea că datele şi resursele lor de reţea sunt în siguranţă 100% o dată cu instalarea unui firewall. Este bine că ne-am dat repede seama că un firewall este doar un element necesar unei strategii de securitate solide. Firewall-urile sunt bune la ceea ce ele fac, şi anume filtrarea traficului, şi nu pot face totul de unele singure.

Cerinţele actuale s-au schimbat în ceea ce priveşte request-urile vis-a-vis de securitatea perimetrului. Multe dintre companiile despre care vorbeam la începutul materialului au evoluat şi au parte de tot felul de infrastructuri care mai de care mai complexe şi care cuprind: conexiuni dedicate cu parteneri de afaceri, VPN-uri (Virtual Private Netorks) sau structuri complicate de e-commerce. Pornind de aici, firewall-urile au evoluat şi ele din punct de vedere al funcţiilor pe care le livrează. În prezent majoritatea firewall-urilor suportă mai multe interfeţe de reţea şi pot controla traficul între ele, suportă VPN-urile, H.323 (protocol folosit în videoconferinţe). Şi deşi am putea sări în sus de bucurie când vedem toate aceste funcţionalităţi, trebuie să fim conştienţi că atunci când adăugăm din ce în ce mai mult “tunning” acestor echipamente, riscăm şi să deschidem cutia Pandorei (mă refer la apariţia de vulnerabilităţi o dată cu aceste noi features)…plus că atunci când un firewall să zicem că funcţionează şi ca un concentrator VPN, performanţa overall a echipamentului va scade şi ea se va oglindi în funcţia principală a unui firewall, şi anume filtrarea de trafic.

Care este mesajul pe scurt? Să încercăm să folosim firewall-ul pentru scopul lui iniţial şi să încercăm să reducem funcţiile lui auxialiare la minimul posibil. Serviciile suplimentare pot fi furnizate de echipamente dedicate sau alte sisteme din infrastructura reţelei noastre.

Să vorbim un pic despre plasarea unui firewall într-o reţea. În cea mai simplă configuraţie, un firewall vine cu două interfeţe: inside şi outside.  Ele reprezintă două nivele de încredere (trust), pe interfaţa outside fiind conectat peer-ul cu trust mai mic (de ex. Internet-ul), iar pe inside având peer-ul cu reţeaua mai sigură. Bineînţeles, au apărut repede neajunsurile. Ce  ne facem atunci când avem un server web? Unde îl plasăm? Îl lăsăm în untrusted zone singur singurel :-D ? Sau îl punem în trusted zone, acolo unde nimeni nu mai are cum să aibă acces la el? De aceea s-a găsit o soluţie, mai precis alte intefeţe care nu fac parte nici in trusted zone, dar nici din trusted, aşa numitele DMZ-uri (demilitarized zones). O să ziceţi: de ce trebuie să mai avem o zonă, când putem foarte bine să punem serverul web in trusted zone şi să deschidem din firewall porturile 80 şi 443? Şi ce ne facem dacă cineva preia controlul asupra sistemului prin 80 şi 443? De pe sistemul respectiv va avea acces la toată zona noastră trusted. Cum rezolvă DMZ-ul acest issue? Pai, DMZ-ul este tot o reţea care este la fel de bine protejată ca şi cea trusted, doar că între ea şi cea de pe inside se mai filtrează încă o dată traficul, astfel evitând situaţiile de genul celei descrise mai sus.

firewalldeployment

Altă topologie posibilă ar fi cea în care folosim două firewall-uri, unul extern şi unul intern şi cu DMZ-ul situat între cele două.

firewalltopology

Bineînţeles, nu doar cele două topologii de mai sus sunt folosite. Acestea sunt doar nişte xemple simple şi “de bun simţ” ale poziţionării unui firewall. Se pot configura situri legate prin mai multe DMZ-uri cu diferite nivele de trust, astfel având un nivel de control mai ridicat. Imaginaţi-vă un DMZ ce cuprinde toate serverele publice sau altul care conţine servere cu servicii destinate clienţilor şi partenerilor. Interesant, nu?

Data viitoare vom continua cu firewall policies şi NAT.

Post a Response

Creative Commons License
This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Romania License.