Explicație pentru vSwitch Security Policies

Uneori, pentru a explica studenților mei cât mai simplu subiecte complexe recurg la prezentări prin modele. Așa am ajuns să construiesc modelul de mai jos pentru a lămuri simplu (sper că a ieșit mai simplu) setările pentru politicile de securitate pe un switch virtual VMware. 

vswitch_security_policies_first_screen

Așadar, să le luăm pe rând (pe schemă de jos in sus ):

  • tubul de jos e un switch-ul virtual (vSS sau vDS)
  • pe switch avem un port (chenar galben) la care avem conectat un VM (de sus)
  • portul pe switch/VM are două conducte: una pentru traficul de intrare (ingress) și alta pentru traficul de ieșire (eggress). În documentația VMware direcția traficului se definește în raportul cu port-ul pe switch-ul virtual.
  • portul pe switch este dotat cu robinete pentru ambele direcții. Robinetele pot fi in una din două poziții: deschis – traficul trece prin conductă, închis – traficul este blocat. Ambele robinete funcționează în ansamblu: ambele se închid și deschid in același timp.
  • poziția robinetelor pe portul pe switch este dirijată de hypervizor (atenție nu de administrator prin settings-ul MAC Address Changes), detalii urmează.
  • mai sus pe schemă ajungem pe portul NIC-ului din interiorul VM-ului (chenar galben).
  • portul pe VM are câte un filtru dirijat montat pe conducte pentru fiecare direcție: unul pentru traficul de ieșire din VM (stânga) și altul pentru traficul de intrare (dreapta).
  • filtrele sunt dirijate și pot avea două poziții: fie filtrează (reject) fie sunt deschise (accept).
  • filtrele sunt pentru blocarea unui anumit tip de trafic și nu pentru tot traficul integral.
  • filtrul pentru traficul de ieșire din VM (stânga) este controlat de valoarea pentru Forget Transmits din configurația switch-ului sau a grupului de porturi (vezi screen mai jos, fereastra din stânga).
  • filtrul pentru traficul de intrare din VM (dreapta) este controlat de valoare pentru Promiscous Mode din configurația switch-ului sau a grupului de porturi (vezi screen mai jos, fereastra din stânga).
  • spre deosebire de robinetele MAC Address Changes dirijat de hypervizor filtrele din portul VM-ului sunt dirijate direct de administrator prin setările promiscous și forget.
  • pe fiecare filtru este montat câte un contor (manometru) pentru numărarea octeților/pachetelor ce tranzitează conductele RX/TX.
  • contoarele sunt realizat in Guest OS. De exemplu pe un sistem de operare Microsoft Windows acestea pot fi citite din Activity pe statutul la Local Area Connection Settings (în screen mai jos, fereastra din dreapta, activity)
  • este foarte importantă poziția contoarelor în raport cu filtrul. Bunăoară, pachetele ce întră în VM-uri sunt numărate după filtru, astfel încât sunt numărate doar pachetele ce au trecut de filtru. Identic și pentru contorul pachetelor ce părăsesc VM-ul acesta va număra doar pachetele ce au trecut de filtru.

vswitch_security_policies_second_screen

  • valorile implicite pentru setările din politică sunt: (a) Promiscous Mode: Reject, (b) MAC Address Changes: Accept, (c) Forget Transmis: Accept. Acestea pot fi setate la nivel de switch și suprapuse (override) la nivelul grupului de port-uri. Pentru un switch distribuit VMware e posibilă suprapunerea setărilor și la nivelului unui port specific de VM.
  • pe desen, mai sus de port-ul VM-ului se află Guest OS-ul și aplicațiile

Să luăm pe rând fiecare opțiune din politică.

Promiscous Mode

In regim normal un nod de rețea conectat într-un switch Ethernet primește doar frame-uri Ethernet destinate lui, adică frame-uri a cărui adresa MAC destinație coincide cu propriul MAC. Aici se mai adaugă și frame-urile broadcast – cele ce au o adresa destinație cu toți de 1. Configurația cu Promiscous Mode setat în Reject corespunde exact acestui mod de funcționare – cadrele a cărui MAC destinație nu coincid cu MAC-ul VM-ului sunt blocate pe filtrul de intrare (promiscous). Contorul pachetelor RX din Guest OS va număra doar frame-urile trecute de filtru.

Pe de altă parte dacă Promiscous Mode este setat in mode Accept, filtrul de intrare nu mai blochează frame-urile străine VM-ului lăsându-le să treacă fără obstacole. Practic, configurarea Promiscous in Accept înseamnă transformarea grupului de porturi în porturi de HUB.

Când avem nevoie de regimul promiscous in accept ? Atunci când se dorește ascultarea traficului dintr-o rețea (sniffing), de exemplu in scenarii cu servicii IDS/IPS in VM-uri. VM-ul cu IDS/IPS se conectează intr-un grup de porturi configurat cu promiscous mode setat in accept.

Configurarea regimului Promiscous in Accept trebuie făcut cu atenție și doar dacă e argumentat. Adevărul e că din moment ce se acceptă trecerea pachetelor străine in VM-uri acestea din urmă devin responsabile de prelucrarea pachetelor care cândva erau blocate de hypervizor și asta nu înseamna nimic altceva decât overhead in plus pe VM-uri. Din interes, urmăriți într-un experiment simplu contorul pachetelor recepționate pe un VM conectat intr-un grup de porturi setat cu promiscous in mode accept.  Lăsați VM-ul silențios ca activitate de rețea. Într-un final veți urmări valori în schimbare pentru contorul pachetelor recepționate chiar dacă acestea nu aparțin VM-ului. Totuși, dacă e nevoie de promiscous in accept pentru un VM conectat într-un grup de porturi se recomandă separarea acestuia de restul VM-urilor intr-un grup de port-uri aparte pe care se va activa regimul promiscous. Astfel, VM-urile din grupul inițial nu vor fi afectate de regimul promiscous. Pentru un switch distribuit (vDS) promiscous mode in activ poate fi setat per port așa că aici lucrurile sunt mai simple.

Forget Transmits

Filtrul Forget Transmits funcționează pe direcția de ieșire a pachetelor din VM și blochează toate frame-urile a căror MAC sursă nu coincide cu MAC-ului VM-ului (de fapt MAC-ul efectiv pe NIC-ul respectivului a VM).

Apare o întrebare: De unde in Guest OS să se ia frame-uri a căror MAC sursă diferă de MAC-ul VM-ului ? Răspunsul e simplu, din aplicații și aici am in vedere aplicații de genul GNS3 cu routere conectate prin cloud la un network extern sau VM-uri intr-un VMware Workstation sau ESXi nested.

Implicit e setat ca Accept. 

MAC Address Changes

Configurația pentru MAC Address Changes dirijează cu capacitatea hypervizorului de a bloca portul (robinetele) pe virtual switch in cazuri când Guest OS-ul întreprinde tentative de substituire a adresei MAC setată inițial pe NIC-ul VM-ului. Mai precis, daca MAC Address Changes e setat ca Reject hypervizorul va bloca robinetele odată cu modificare adresei MAC asociate inițial cu NIC-ul VM-ului și invers dacă MAC Address Changes este setat ca Accept hypervizorul va ignora orice tentativă de substituire a adresei  MAC și va lăsa robinetele tot timpul deschise. Pe scurt, dacă am numi adresa inițială setată pe NIC (BIA) ca MAC[i] (initial) și adresa MAC substituită MAC[e] (efective) atunci efectul la MAC Address Changes s-ar putea de prezentat astfel:

  • Pentru MAC Address Changes = Reject (a) dacă MAC[i]<>MAC[e] atunci blochează robinetele sau (b) dacă MAC[i]=MAC[e] atunci lasă robinetele deschise
  • Pentru MAC Address Changes = Accept indiferent daca MAC[i] coincide sau nu cu MAC[e] robinetele sunt lăsate neatinse de MAC Address Changes.

De remarcat, că contorul din Guest OS pentru pachetele ieșite din VM vor fi numărate chiar dacă portul a fost blocat de MAC Address Changes și e de la sine înțeles că în același timp contorul pentru pachete primite va rămâne intact.

Important de menționat faptul că MAC Address Changes nu reacționează în nici un mod la frame-urile generate din aplicații (GNS3, VMware Workstation .. ) dor la cele a sistemului de operare, la fel cum și filtrul Forget Transmits nu poate filtra frame-uri din OS cu adresa MAC substituită. Confirmat in teste pe laborator.

Implicit este setat ca Accept.

Menționasem mai sus că hypervizorul detectează substituirea in OS a adresei MAC setate pe NIC. Întrebarea e: Cum e posibil asta ? Nu am un răspuns confirmat dar intuiesc că lucrurile stau cam asa: Odată ce se încarcă sistemul de operare valoarea pentru adresa MAC burrned (ROM) in NIC-ul VM-ului este citită și plasată pe o adresă well know din RAM-ul VM-ului. Adresa well know poate fi una common pentru toate sistemele operare sau specifică per OS. Sistemul de operare va folosi această valoare ca adresa MAC sursă pentru toate frame-urile generate de SO. Acum, dacă se intervine, din OS se poate schimba valoarea MAC-ului din RAM într-o altă valoare (effective MAC) în așa fel încât frame-urile ulterioare să plece deja cu MAC-ul nou. Substituirea MAC-ului mai este numită MAC address spoofing și e folosită in unele scenarii de atac de rețea. Dat fiind faptul că VM-ul aparține hypervizorului, acesta din urmă are acces la RAM-ului VM-ului și deci poate citi direct valoarea MAC-ului substituit de pe adresa well know menționată mai sus. In așa fel hypervizorul poate să compare valoarea adresei MAC atribuită inițial și valoarea de facto folosită de OS și in continuare în funcție de MAC Address Changes poate bloca sau nu porturile pe switch.