Care sunt motivele pentru a utiliza un firewall în modul transparent?

După ce am căutat câteva informații pe Internet, am găsit doar două avantaje ale a firewall transparent:

• Modul „Stealth”, adică a devenit o gazdă invizibilă în rețea
• Se instalează cu ușurință într-o rețea existentă fără a modifica adresa IP (Internet Protocol).

Dar asta pare un pic incomplet și poate nefondat. Se pare că ar trebui să existe mai multe motive întemeiate pentru vânzătorii (sau colegii open-source) să implementeze un astfel de mod și pentru clienții să cumpere (să folosească) această funcționalitate.

Cel mai mare motiv pe care îl cunosc? ipv6. O mare parte din motivul pentru care a fost propus IPv6 a fost pentru a ocoli problema de epuizare a adreselor IPv4 și a scăpa de „hack-ul urât” care este nat. Din cauza combinației IPv4+NAT, mult prea mulți oameni presupun automat asta firewall == nat ceea ce nu este cazul. Aproape toate firewall-urile pot face NAT, dar nu toate soluțiile NAT pot face firewall.

IPv6 presupune o rețea nemascata, ceea ce provoacă unele probleme oamenilor obișnuiți ca totul să fie mascat. Într-o rețea IPv6, sunteți mult mai sigur presupunând că o adresă IPv6 „publică” nu este o garanție a rutabilității.

Dar nu este vorba doar de IPv6. Universitatea pentru care lucram avea o alocare IPv4 /16 când lucram acolo. Aveau desktop-uri cu adrese IP „publice”. Cu toate acestea, acestea erau încă protejate de firewall, deoarece firewall-urile noastre funcționau în modul „transparent”. Aveam spațiul de adrese, de ce nu? De asemenea, a făcut anumite cazuri de utilizare mai ușor de gestionat fără a fi nevoie să jucați jocuri NAT de redirecționare a portului și de atribuire public-IP.

Dacă definiția dvs. de transparent înseamnă un serviciu de securitate L2, cazurile de utilizare sunt comune chiar și în rețelele IPv4.

• Grupurile de securitate AWS funcționează astfel pentru ei ec2, Virtual Private Cloud și alte servicii.
• Azure Security Groups funcționează în mod similar.
• A trecut ceva timp de când am lucrat cu el, dar cred că rețelele VMWare ESX au avut o opțiune similară.

Aceste sisteme sunt nucleul securității rețelei la furnizorii majori de cloud public. Definiți o listă de reguli de permis/refuzare, iar acestea se aplică resursei. În AWS, aceasta este interfața instanței EC2, Lambda sau alt serviciu. Firewall-ul nu există pe cutie ca un iptables, ci sub mașina virtuală. Acest lucru îl face un dispozitiv L2 transparent.

Este posibil să aveți o cerință pe care unele gazde o trebuie locuiesc în același segment LAN și, în același timp, necesită politici de securitate foarte diferite. De exemplu, poate doriți să fiți în aceeași rețea ca dvs ANUNȚ controlere de domeniu (DC) și totuși doriți să le securizați și să vă separați de restul rețelei cumva.

Pentru aceasta, adăugați un firewall transparent. Pe de o parte, veți avea DC-urile voastre, pe de cealaltă parte veți avea restul și totuși ei pot trăi într-o singură rețea, cum ar fi 192.168.5.0/24, și să se gândească fericiți că nu au niciunul. L3 dispozitive dintre ele. Și toate vor avea același gateway implicit, care va fi probabil implementat pe partea „nesigură”.

Celălalt caz ar putea fi atunci când vine vorba de traficul cu firewall-uri. De exemplu, există servicii care nici măcar nu știu ce este IP, IPv6 sau orice alt L3 și comunică folosind cadre Ethernet brute. ATA prin Ethernet (AoE) mi-a venit prima dată în minte. Am văzut unele automatizări industriale care comunică folosind Ethernet brut. Și când vine vorba de a constata Rafturi AoE sunt accesibile doar anumitor gazde cunoscute, veți folosi ceva de genul acestor „punți-firewall-uri”.