Rețele Private VLAN (PVLAN) – part II

După o scurtă introducere în rețele PVLAN făcută în prima parte a articolului am să continui cu o prezentare pentru câteva exemple de utilizare PVLAN. În părțile ce vor urma planific să descriu tipuri de interfețe trunk specifice PVLAN pe switch-uri Cisco, condițiile impuse pentru un switch peste care sunt tranzitate VLAN-uri private precum și modul în care pot fi configurate PVLAN-urile pe un switch distribuit VMware.

Exemple de utilizare

Să analizăm câteva use case-uri tipice pentru rețele PVLAN:

  • rețea hosting provider
  • rețea demilitarizată DMZ
  • rețea de backup
  • rețea desktop-uri virtuale VDI.

Rețea hosting provider

O rețea a unui hosting provider adună la un loc (într-un singur network) nodurile/host-urile mai multor clienți – ultimii, funcție de dimensiunea provider-ului posibil să ajungă de ordinul sutelor, miilor, zecilor de mii s.a.m.d. Sigur, fiecare client își dorește un mediu de rețea securizat și izolat de restul clienților, dar, securizat și izolat însemnă VLAN-uri și subnet-uri IP dedicate per client or acest lucru e aproape imposibil pentru hoster-ii mari, pe de-o parte VLAN-urile tradiționale suferă de o scalabilitate proastă – un maxim de 4094 de VLAN ID-uri și pe de altă parte overhead în plus pe IP – adrese IP pierdute pe numărul/broadcast-ul rețelei, interfețe L3 pe router/firewall pentru fiecare subnet, overhead administrativ.

PVLAN-urile oferă o soluție simplă și totodată scalabilă pentru așa fel de scenarii. În loc de VLAN-uri/subnet-uri separate per client, va fi suficient ca în rețeaua hoster-ului să se configureze un PVLAN pe o singură rețea L3. Pentru segregare, fiecare client se va ancora în VLAN-ul secundar izolat din PVLAN. Serviciile partajate se vor conecta în port-urile promiscous pe VLAN-ul primar. Design-ul va consuma două VLAN-uri (primar și secundar izolat), două adrese IP și o singură interfață pentru router/firewall folosit ca și default gateway la subnet. Soluția e de-a dreptul fără limite de scalabilitate, imaginați-vă că aceasta e bună și pentru de un hoster cu 1M de clienți – indiferent de dimensiune se vor consuma aceleași două VLAN-uri și un singur subnet iar clienții în același timp vor rămâne izolați între ei. Vedeți mai jos o ilustrare pentru un astfel de scenariu:

PVLAN-part2-usecase-secureISP

Rețea demilitarizată DMZ

În rețeaua unei companii PVLAN-urile se pot dovedi extrem utile pe segmentul ei de DMZ. Într-o arhitectură de rețea securizată se obișnuiește ca serverele cu acces public ale companiei să fie organizate într-un segment de rețea izolat, separat de celelalte servere interne. Respectivul segment formează așa numita zona demilitarizată DMZ a rețelei. Într-un DMZ, este permis accesul din rețeaua publică (Internet) la serverele din DMZ și totodată blocat pe alte rețele interne. Pe de altă parte, serverelor din DMZ le este permis să comunice cu rețelele interne. Segmentul de DMZ este separat de rețelele interne și rețeaua publică prin dispozitive firewall. Altfel spus, DMZ-ul permite expunerea controlată a unui grup de servere într-o rețea publică fără să se compromită securitatea pentru celelalte servere din infrastructură.

Chiar dacă oferă un layer în plus de protecție, DMZ-ul nu ne poate apăra de situațiile în care sunt compromise însuși servere din DMZ. Odată rupte – de exemplu prin exploatarea unei găuri în chiar sistemul de operare, intrusul poate încerca să obțină acces neautorizat în rețelele interne sau pe alte servere din DMZ. Toate serverele din DMZ rămân deschise unul în față de celălalt iar securitatea întregului ansamblu se raportează la securitatea celui mai slab protejat server.

Pentru a reduce vulnerabilitatea serverelor din DMZ în fața unui vecin compromis se pot utiliza rețelele private PVLAN. Să luăm ca exemplu scenariul din schema prezentată mai jos (stânga), avem aici un segment DMZ cu două servere DNS, un server de poștă și un server WEB. Serverele din DMZ nu au nevoie să comunice între ele cu excepția DNS-urilor care lucrează în failover unul pentru altul și care au nevoie să schimbe periodic informații între ele.

PVLAN-part2-usecase-DMZ&LB

Pentru un setup cu PVLAN-uri serverele SMTP și WEB se vor plasa în Secondary Isolated VLAN al VLAN-ului privat iar serverele DNS se vor conecta în porturile asociate cu un Secondary Community VLAN dedicat. În așa fel, serverele DNS vor putea să comunice liber intre ele dar nu și cu celelalte servere din DMZ la fel și restul serverelor vor fi restricționate să comunice unul cu altul. Acum suprafața de atac va fi blocată pe perimetrul serverul compromis asigurându-se protecție pentru celelalte servere din DMZ.

Vom face același lucru și pentru cazul cu mai multe servere conectate în spatele unui Load Balancer, de exemplu într-o fermă de servere HTTP pentru un site WEB (vezi in desenul de mai sus pe dreapta). În regim normal serverele nu au nevoie să comunice între ele așa că pentru o securitate mai bună va fi bine să le izolăm între ele, de exemplu prin conectarea într-un Secondary Isolated VLAN dintr-un PVLAN.

Ce este interesant, migrarea de pe o arhitectură cu un singur VLAN pe una cu PVLAN poate fi realizată transparent, fără reconfigurări și întreruperea serverelor. Tot de ce este nevoie e ca pe switch-uri să se adauge VLAN-urile secundare după care să se modifice corespunzător configurația pe porturi. Nu se schimbă configurația IP nici pe servere nici pe echipamentul de rețea.

Rețea de backup

Chiar dacă un pic arhaică – mai ales pentru un mediu cu servere virtuale, arhitectura cu backup-ul serverelor inițiate de agenți instalați direct pe OS și cu trafic de backup împins printr-o rețea dedicată are totuși drept la viață. Într-o astfel de arhitectură, fiecare server are câte o conexiune în plus la rețea – una dedicată traficului de backup prin care agentul de backup transmite traficul de backup spre aplicația de backup. Pe partea de backup, toate serverele figurează ca făcând  parte dintr-o singură rețea de date. Evident că o așa arhitectură nu e tocmai securizată, paradoxal pe de-o parte serverele sunt organizate în subnet-uri protejate de firewall-uri iar pe de altă parte legate transparent într-o rețea mare de backup. Rețeaua de backup poate să devină mediul pentru propagarea unui atac pe servere – de exemplu de pe un server compromis într-o rețea pe un alt server dintr-o altă rețea; sau răspândirea virușilor s.a.m.d.

O soluție pentru securizarea rețelei de backup poate fi implementarea de PVLAN. Într-un PVLAN, serverele se vor conecta în porturi configurate pentru Secondary Isolated VLAN astfel încât să nu se observe unul pe celălalt iar serverul cu aplicația de backup se va conecta într-un port promiscous în așa fel încât să poată fi accesat de celelalte servere. Mai jos o ilustrare pentru o astfel de arhitectură.

PVLAN-part2-usecase-bkp&VDI

Rețea desktop-uri virtuale VDI

Pentru o securizare în plus se obișnuiește ca într-un VDI (mai ales pentru unul cu destinație publică ca de ex. desktop-urile virtuale dintr-o bibliotecă sau kiosk-urile din salile unui hotel) să se restricționeze comunicațiile între desktop-urile virtuale. Ca și în case-urile de mai sus, obiectivul se atinge simplu prin implementarea de PVLAN (btw supported pe switch-uri virtuale vSphere/Hyper-V) cu includerea desktop-urilor virtuale în VLAN-ul secundar izolat din PVLAN.