Verkeer binnen een Private VLAN door de Firewall laten afhandelen

kennislevel 1 kennislevel 2 kennislevel 2 Technisch niveau Waddinxveen,30 maart 2021 Waddinxveen, 30 maart 2021 Security Security

Met de implementatie van VLAN’s wordt de beveiliging binnen netwerken verbeterd. Waar servers in 1 VLAN elkaar allemaal kunnen bereiken, is het ook mogelijk om deze te scheiden met behulp van verschillende VLAN’s. Hiermee is het verkeer tussen deze netwerken te beveiligen met Access List’s op switches / routers of (NextGen) Firewalls. Zo kunnen bijvoorbeeld database servers, in een eigen VLAN, niet met werkstations in een ander VLAN verbinden en vice versa. Dit biedt bescherming, in geval de werkstations malware of randsom software bevatten en daarmee belangrijke resources proberen te besmetten.

Er is een manier om de beveiliging binnen je netwerk op een nog hoger niveau te krijgen. Binnenin een VLAN kunnen 2 systemen in een standaard netwerk met elkaar communiceren. Dit maakt het dus mogelijk maakt voor een aanvaller om van de ene server, de andere server aan te vallen.

Indien men niet kan segmenteren in verschillende VLAN’s, is de oplossing om binnen een netwerk / VLAN een Firewall op de server aan te zetten. Een nadeel is, dat dit een grotere beheerlast geeft. Een voorbeeld hiervan zijn de Windows Firewall en IPTables. Deze moeten per server ingesteld worden en er is geen centrale logging.

Specifieke Usercase

Er is een mogelijkheid, het verkeer tussen de servers in hetzelfde VLAN in uw Firewall te inspecteren en te reguleren. Hiermee is het mogelijk om directe verbindingen tussen de servers te reguleren. Een manier om dit te realiseren is met Private VLAN’s en 32 bits subnetmaskers op Servers. In theorie is het mogelijk om al uw servers in 1 VLAN te zetten, aangezien de servers alleen naar elkaar mogen verbinden, als de Firewall dit toelaat.

Deze opstelling heeft zeer specifieke use-cases, waar security een zeer hoge prioriteit heeft.
Nadelen van deze opstelling:

  • Servers kunnen geen gebruik meer maken van Laag2/Laag3 broadcast om met andere systemen te communiceren. Bepaalde applicaties kunnen hiervan afhankelijk zijn.
  • Uplink tussen Switch en Firewall moet meer bandbreedte kunnen verwerken. Al het onderlinge verkeer tussen de servers, alsmede het verkeer van de servers naar andere netwerken wordt door de Firewall afgehandeld. Het is aan te raden om minimaal een 10Gbit verbinding tussen de Switch en Firewall te hebben.
  • DHCP kan een uitdaging zijn om in te stellen, aangezien het Subnetmasker van de server 32 bits moet zijn. Bepaalde DHCP-servers kunnen hier problemen mee hebben. Daarbij zullen de meeste Linux (virtuele) machines een extra route nodig hebben, om communicatie met de firewall/router werkend te krijgen.

Voordelen van deze opstelling:

  • Verhoogde beveiliging: servers kunnen niet meer direct met elkaar communiceren en extra controles (IPS, Anti-Virus) kunnen uitgevoerd worden op verkeer van de servers onderling.
  • Verhoging audit niveau: alle IP-communicatie van de server kan worden gelogd op de Firewall en biedt zelfs de mogelijkheid tot alarmering bij abnormaal gedrag.
  • Software firewall op de server in feite overbodig: de firewall kan al het verkeer van/naar de server controleren, en daarmee de ingebouwde IPTables/Windows Defender Firewall dus overbodig maken.

Zaken om rekening mee te houden:

  • Grootste deel van de Firewalls zijn compatibel met deze opstelling. Er is over het algemeen geen uitzonderlijke of merk-specifieke configuratie vereist aan Firewall zijde.
  • (Virtuele) Machines, die niet met 32 bits subnetmaskers om kunnen gaan, zijn niet compatibel met deze netwerk opstelling. Deze zullen in een apart VLAN gezet moeten worden.
  • Multicast streams werken niet in het Isolated Private VLAN. Als een van de (Virtuele) machines in het VLAN Multicast uitstuurt, kan deze niet naar andere servers gestuurd worden in hetzelfde VLAN. Dit is een beperking van private VLAN’s.
  • Een Private VLAN kun je over het algemeen niet over dezelfde uplink laten functioneren, als een regulier VLAN. Je hebt voor de Private VLAN’s vaak aparte uplinks nodig tussen de switches en firewalls. Dit is niet op alle switch platformen hetzelfde.
  • Private VLAN over LAG (LACP/Statische LAG/PaGP) kan op sommige switch platformen / software versies niet ondersteund zijn. Raadpleeg de documentatie van uw switchfabrikant of dit ondersteund is op uw apparatuur.
  • Voor volledig correcte werking moeten virtuele switches op virtualisatie platformen (Hyper-V, VMWare, etc.) ook Private VLAN configuratie actief hebben. Dit om de beveiliging end-to-end volledig te maken.

Private VLAN’s, beknopte uitleg

Een Private VLAN is een speciaal type VLAN. Het is een manier om verkeer naar een router/switch uplink toe te laten, maar dit niet- of beperkt toe te laten tussen systemen onderling. Er zijn 3 types Private VLAN beschikbaar op switches

  • Primary VLAN
  • Isolated VLAN
  • Community VLAN
Primary VLAN
Dit type VLAN is het hoofd VLAN van de onderliggende Private VLAN’s. Dit VLAN is bedoeld om richting uw Firewalls, Routers en andere switches te gebruiken. Isolated en Community VLAN’s worden aan een Primary VLAN gekoppeld. Al het verkeer in een Isolated / Community VLAN wordt altijd naar de Primary VLAN gestuurd.

Isolated VLAN
Dit type VLAN laat verkeer van en naar de Primary VLAN toe, maar niet tussen de poorten die zich in hetzelfde Isolated VLAN bevinden. Een Isolated VLAN maakt in feite voor elke poort een “tunnel” van en naar de Firewall/Switch uplink, waarbij het verkeer niet kan afslaan naar andere poorten.

Community VLAN
Dit type VLAN laat verkeer van en naar de Primary VLAN toe. Daarnaast laat dit ook verkeer tussen poorten in ditzelfde VLAN toe. In een Community VLAN kunnen servers in hetzelfde Private VLAN dus direct met elkaar communiceren, maar niet met servers in andere private (Community) VLAN’s. Een voorbeeld netwerk ziet er zo uit:

SolidBE verkeer binnen een vlan door de firewall laten afhandelen

Configuratie

We maken een opstelling waarbij gebruik wordt gemaakt van:
  • 1 FortiGate firewall
  • 1 Ruckus ICX switch
  • 3 fysieke machines
Fysiek (OSI Laag 1) is dit de opstelling:
SolidBE verkeer binnen een vlan door de firewall laten afhandelen

Geen van de machines in deze opstelling mogen direct met elkaar communiceren. Al het verkeer moet via de Firewall lopen. Dit zodat we op de Firewall het verkeer tussen de servers kunnen inspecteren om vervolgens te accepteren of te weigeren.

Op OSI laag 2 is dit de opstelling: SolidBE verkeer binnen een vlan door de firewall laten afhandelen Configuratie van de Ruckus ICX switch:

vlan 601 name privatevlan1 by port
pvlan type isolated
untagged ethe 1/1/37 to 1/1/39
!
vlan 600 name privateprimary by port
pvlan type primary
untagged ethe 1/1/36
pvlan mapping 601 ethe 1/1/36
!

Hierbij zijn 2 VLAN’s aangemaakt. VLAN 601 is het Isolated VLAN en wordt untagged naar de servers doorgezet. Primary VLAN 600 wordt aangemaakt en daar wordt de uplink naar de Firewall untagged aan toegevoegd. VLAN 601 wordt aan dit Primary VLAN gekoppeld.

Op OSI Laag 3 is dit de opstelling:
SolidBE verkeer binnen een vlan door de firewall laten afhandelen Configuratie van de FortiGate:
Configuratie via de CLI
config system interface
edit "b"
set vdom "root"
set ip 10.6.1.1 255.255.255.0
set allowaccess ping
set type physical
set alias "privateprimary"
set role lan
next
end
config firewall policy
edit 0
set name "InterVLANAccess"
set srcintf "b"
set dstintf "b"
set srcaddr "all"
set dstaddr "all"
set action accept
set schedule "always"
set service "PING"
set logtraffic all
set comments “Private VLAN ICMP Access”
next
end

Configuratie via de Web UI:
FW Interface configuratie SolidBE verkeer binnen een vlan door de firewall laten afhandelen
FW Policy Configuratie:
SolidBE verkeer binnen een vlan door de firewall laten afhandelen

We stellen 1 fysieke interface in op de FortiGate. Deze is specifiek voor het Private VLAN. Omdat het Private VLAN Untagged staat op de switch, hebben we hier geen VLAN-interface nodig. In dit voorbeeld is Interface “b” gebruikt.

We maken 1 policy regel aan in de Firewall, die van de Private VLAN interface naar de Private VLAN interface (Intra-Zone) gaat en alleen ICMP-Ping toelaat. Indien gewenst kunt u ook eventueel een Firewall regel maken, die verkeer (met eventueel source NAT) naar internet toelaat. Dit is zoals u al gewent bent.

In tegenstelling tot een standaard opstelling gaan de servers een afwijkende configuratie krijgen. In plaats van een 24 bits subnetmasker (zoals deze ook op de interface van de firewall geconfigureerd is), gaan we 32 bits subnetmaskers gebruiken. Hiermee stuurt de server al het verkeer naar zijn default gateway. Ook al zit de bestemming in hetzelfde VLAN. Immers het subnet op de server bevat alleen zijn eigen IP-adres. Alle overige IP-adressen vallen erbuiten en zullen naar de default gateway gestuurd worden.

Op Linux Server 1 is het volgende ingesteld:
(LET OP! Dit is configuratie voor Netplan onder Ubuntu 20.04. Andere Linux distributies zonder Netplan moeten geconfigureerd worden zoals beschreven in de documentatie van de desbetreffende Distributie)

#File: /etc/netplan/00-installer-config.yaml

network:
ethernets:
ens160:
addresses:
- 10.6.1.10/32
gateway4: 10.6.1.1
nameservers:
addresses:
- 8.8.8.8
- 8.8.4.4
routes:
- to: 10.6.1.1/32
via: 0.0.0.0
scope: link
version: 2

Op Linux Server 1 is het volgende ingesteld :


#File: /etc/netplan/00-installer-config.yaml

network:
ethernets:
ens160:
addresses:
- 10.6.1.11/32
gateway4: 10.6.1.1
nameservers:
addresses:
- 8.8.8.8
- 8.8.4.4
routes:
- to: 10.6.1.1/32
via: 0.0.0.0
scope: link
version: 2

LET OP: Als u dit configureert op een andere Linux distributie: het kan vereist zijn om een host route toe te voegen. Dit wordt hierboven ook gedaan in de ‘routes:’ sectie. Deze route geeft aan dat de route naar de default gateway “on-link” is. Zijn default gateway valt buiten het subnet van de server. Door deze route gaat de server toch ARP-en voor het IP-adres van de default gateway.

Op de Windows server is het volgende ingesteld:
SolidBE verkeer binnen een vlan door de firewall laten afhandelen Bovenstaande Windows/Linux configuratie zorgt ervoor dat de servers al het verkeer naar de default gateway sturen. De Default gateway routeert het verkeer dan vervolgens weer door naar de desbetreffende server. Uiteraard wanneer dit toegestaan wordt in het Firewall policy.

Als u in deze opstelling subnetmasker 255.255.255.0 (of /24) gebruikt, zullen de servers niet met elkaar kunnen communiceren. Dit omdat het ARP-mechanisme in een Isolated Private VLAN niet werkt. De servers kunnen geen verkeer direct naar elkaar sturen. Er zijn verschillende ARP work-arounds te bedenken op de Firewall, maar bovenstaande configuratie is compatibel met vrijwel alle firewall/router merken.

Nu alle configuratie op de machines staat, kunnen we via de Windows machine naar de linux machines pingen:
SolidBE verkeer binnen een vlan door de firewall laten afhandelen Bij een traceroute ziet u dat het verkeer naar de Firewall gerouteerd wordt. Deze routeert het verkeer vervolgens naar de server:
SolidBE verkeer binnen een vlan door de firewall laten afhandelen In de Firewall logs wordt het verkeer door de Firewall geaccepteerd (geel arceerde regel):>br>
SolidBE verkeer binnen een vlan door de firewall laten afhandelen
Bij het uitzetten van de eerder gemaakte regel (de regel, die ICMP-verkeer binnen het Isolated VLAN toestond), werkt de ping niet meer
SolidBE verkeer binnen een vlan door de firewall laten afhandelen In de Firewall logs wordt het verkeer door de Firewall geweigerd: SolidBE verkeer binnen een vlan door de firewall laten afhandelen Nu kunt u deze policy verder uitbreiden. De 2 Linux servers kunnen nu niet met elkaar communiceren via de Firewall. Er is geen regel in de firewall en daarom blokkeert de Firewall dit. Als we bijvoorbeeld SSH mogelijk willen maken moeten we dit in de Firewall nu eerst toestaan.

Beide Linux Servers hebben een OpenSSH server functioneel. Op dit moment kan priv1 server (10.6.1.10) niet met priv2 server (10.6.1.11) communiceren, omdat de Firewall dit blokkeert:
SolidBE verkeer binnen een vlan door de firewall laten afhandelen We willen dat priv1 wel met priv2 kan verbinden over SSH, maar niet andersom. Dit kunnen we in de Firewall configureren. We maken 2 adres objecten en een nieuwe policy aan in de Firewall:
Configuratie via de CLI
conf firewall address
edit "priv1"
set associated-interface "b"
set subnet 10.6.1.10 255.255.255.255
next
edit "priv2"
set associated-interface "b"
set subnet 10.6.1.11 255.255.255.255
next
end
config firewall policy
edit 44
set name "SSH from Priv1 to priv2"
set srcintf "b"
set dstintf "b"
set srcaddr "priv1"
set dstaddr "priv2"
set action accept
set schedule "always"
set service "SSH"
set logtraffic all
set comments "Allow SSH from Priv1 to priv2"
next
end
Configuratie via de web UI
Object aanmaken voor priv1: SolidBE verkeer binnen een vlan door de firewall laten afhandelen
Object aanmaken voor priv2: SolidBE verkeer binnen een vlan door de firewall laten afhandelen FW Policy Configuratie
SolidBE verkeer binnen een vlan door de firewall laten afhandelen Nu kan de priv1 server naar priv2 server over SSH verbinden!

SolidBE verkeer binnen een vlan door de firewall laten afhandelen
Andersom werkt het niet:
SolidBE verkeer binnen een vlan door de firewall laten afhandelen

Samenvattend

Met bovenstaande configuratie bouwt u een zeer robuust en veilig netwerk. Toegang tussen de servers in hetzelfde VLAN wordt compleet geregeld door de Firewall. Hiermee is de behoefte voor een Software Firewall op de server bij deze opstelling niet noodzakelijk. Dit wordt immers allemaal op de centrale Fortigate FW gedaan. Inclusief centrale logging. De FW zou zelfs NextGen securityfeatures in kunnen zetten voor inspectie van het verkeer.

U kunt altijd contact met ons opnemen, wanneer u hulp nodig heeft om deze configuratie in te richten in uw netwerk. Of natuurlijk om te kijken wat Private VLAN’s specifiek voor uw netwerk kunnen betekenen.

SolidBE helpt u graag bij de inrichting van een veilige netwerkomgeving!

Wilt u hulp van een gecertificeerd Fortinet expert?

Contact

SolidBE B.V.
Maarten Schoutenstraat 19
2741 SV Waddinxveen

KVK 51248794
NL 82 3170 846 B01
NL07 RABO 0157 5353 98