Netwerksegmentatie & Firewall

Ieder Pad Met Toestemming

In netwerkbeveiliging wint structuur van improvisatie: duidelijke paden, minder privileges en expliciete trust-grenzen.

Voor Netwerksegmentatie & Firewall is segmentatie de hefboom: expliciete paden, deny-by-default en gecontroleerd beheer.

Zo beperk je niet alleen de kans op incidenten, maar vooral ook de omvang en duur als er iets misgaat.

Directe maatregelen (15 minuten)

• Start met MFA, least privilege en tiering voor beheeraccounts.
• Voer segmentatie en expliciete firewallregels door op kritieke paden.
• Borg logging, detectie en hersteltests als structurele operatie.

Waarom dit telt

De kern van Netwerksegmentatie & Firewall is risicoreductie in de praktijk. Technische context ondersteunt de maatregelkeuze, maar implementatie en borging staan centraal.

Waarom segmentatie

Netwerksegmentatie draait om drie dingen:

1. Blast radius beperken – als een werkstation wordt gecompromitteerd, bepaalt segmentatie hoeveel van het netwerk de aanvaller kan bereiken. In een plat netwerk is het antwoord: alles. In een gesegmenteerd netwerk is het antwoord: alleen het segment waar dat werkstation in zit.

2. Laterale beweging stoppen – er zijn 13 lateral movement commands in het aanvalsarsenaal (zie hoofdstuk 6). Elk daarvan vereist netwerktoegang tot het doelsysteem. Als die toegang er niet is, zijn die 13 commands waardeloos. Segmentatie is niet een van de verdedigingen tegen laterale beweging – het is de verdediging.

3. Compliance – PCI DSS vereist segmentatie van het cardholder data environment. ISO 27001 vereist netwerksegmentatie als onderdeel van Annex A.13. NIS2 vereist “adequate network segmentation.” Regelgeving dwingt wat common sense niet kon bereiken.

Flat network vs. gesegmenteerd netwerk

FLAT NETWERK                          GESEGMENTEERD NETWERK

+--------------------------------+    +---------+  +---------+  +----------+
|                                |    | DMZ     |  | Intern  |  | Restrict |
| WS01  WS02  SRV01  DC01  DB01 |    | WEB01   |  | WS01    |  | DC01     |
| PRINTER  WEB01  MGMT01  NAS01 |    | WEB02   |  | WS02    |  | DB01     |
|                                |    | MAIL01  |  | SRV01   |  | MGMT01   |
| Alles praat met alles.         |    +----+----+  +----+----+  +----+-----+
| De intern pingt de DC.         |         |            |            |
+--------------------------------+    +----+------------+------------+---+
                                      |          FIREWALL               |
                                      | Alleen expliciet verkeer door   |
                                      +---------------------------------+

Segmentatiemodellen

Niet alle segmentatie is gelijk. Er zijn vier gangbare modellen, elk met hun eigen afwegingen:

VLAN-gebaseerd – de klassieke aanpak. Werkstations in VLAN 10, servers in VLAN 20, management in VLAN 30. Verkeer tussen VLANs gaat via een layer-3 switch met ACLs. Het probleem: binnen een VLAN kan alles met alles praten.

Subnet-gebaseerd – vergelijkbaar, maar met routing als enforcement. ACLs op de gateway bepalen welk verkeer door mag. Iets flexibeler omdat je subnets kunt nesten.

Microsegmentatie – segmentatie op host-niveau. Elke workload heeft eigen firewall-regels. Twee servers in hetzelfde VLAN kunnen niet met elkaar praten als de microsegmentatie dat niet toestaat. De toekomst, maar veel werk.

Zero Trust (ZTNA) – vertrouw niets, verifieer alles. Elke verbinding wordt geauthenticeerd, ongeacht herkomst. Er is geen “intern” en “extern” – alleen “geverifieerd” en “niet geverifieerd.” Het ideaal. De realiteit is dat de meeste organisaties nog worstelen met basale VLAN-segmentatie.

Zone-ontwerp

Een goed gesegmenteerd netwerk heeft minimaal drie zones:

Ontwerpprincipes: DMZ heeft geen directe toegang tot de restricted zone. Werkstations praten niet met werkstations (geen SMB/WinRM peer-to-peer). Beheerverkeer gaat via een dedicated management VLAN. De domain controller is alleen bereikbaar vanuit management en via LDAP/Kerberos – geen RDP of WinRM vanaf werkstations.

VLAN-configuratie

802.1Q tagging

VLANs werken via IEEE 802.1Q tagging. Elk frame krijgt een tag met het VLAN-ID. Trunk-poorten dragen verkeer voor meerdere VLANs; access-poorten zijn toegewezen aan een enkel VLAN.

VLAN best practices

! Cisco IOS -- VLAN-configuratie

! Stap 1: Maak VLANs aan
vlan 10
 name WERKSTATIONS
vlan 20
 name SERVERS
vlan 30
 name MANAGEMENT
vlan 40
 name DMZ
vlan 99
 name NATIVE_UNUSED
vlan 999
 name BLACKHOLE

! Stap 2: Configureer access-poorten
interface GigabitEthernet0/1
 description Werkstation-poort
 switchport mode access
 switchport access vlan 10
 switchport nonegotiate
 spanning-tree portfast
 spanning-tree bpduguard enable

! Stap 3: Configureer trunk-poorten
interface GigabitEthernet0/24
 description Trunk naar core switch
 switchport trunk encapsulation dot1q
 switchport mode trunk
 switchport trunk native vlan 99
 switchport trunk allowed vlan 10,20,30,40
 switchport nonegotiate

! Stap 4: Ongebruikte poorten uitschakelen
interface range GigabitEthernet0/12-23
 switchport mode access
 switchport access vlan 999
 shutdown

VLAN hopping voorkomen

VLAN hopping is een aanval waarbij een aanvaller verkeer naar een ander VLAN stuurt. Twee varianten:

1. Switch spoofing: de aanvaller doet alsof zijn poort een trunk is via DTP (Dynamic Trunking Protocol)
2. Double tagging: de aanvaller stuurt frames met twee 802.1Q-tags, waarbij de switch de eerste tag stript en het frame naar het VLAN van de tweede tag stuurt

Verdediging:

! DTP uitschakelen op ALLE access-poorten
interface GigabitEthernet0/1
 switchport nonegotiate

! Native VLAN wijzigen op trunks (niet VLAN 1)
interface GigabitEthernet0/24
 switchport trunk native vlan 99

! Tag native VLAN verkeer op trunks
vlan dot1q tag native

! Unused VLANs niet op trunks toestaan
interface GigabitEthernet0/24
 switchport trunk allowed vlan 10,20,30,40

De gouden regel: switchport nonegotiate op elke poort. DTP is een aanvalsvector die in 2026 niet meer hoort te bestaan.

Firewall-regels

Default deny

De belangrijkste regel: default deny, inbound en outbound. De meeste firewalls zijn “default allow outbound” – precies waarom ongewenste command-and-control-kanalen zo makkelijk ontstaan.

iptables (Linux)

#!/bin/bash
# Basisregels: default deny met expliciete toelating

# Flush bestaande regels
iptables -F
iptables -X

# Default policy: DROP alles
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT DROP

# Loopback toestaan
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

# Established/related verbindingen toestaan
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# SSH inbound alleen vanuit management VLAN (10.0.30.0/24)
iptables -A INPUT -p tcp --dport 22 -s 10.0.30.0/24 -j ACCEPT

# HTTP/HTTPS outbound alleen via proxy (10.0.30.10)
iptables -A OUTPUT -p tcp --dport 3128 -d 10.0.30.10 -j ACCEPT

# DNS outbound alleen naar interne DNS (10.0.30.53)
iptables -A OUTPUT -p udp --dport 53 -d 10.0.30.53 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 53 -d 10.0.30.53 -j ACCEPT

# NTP outbound alleen naar interne NTP
iptables -A OUTPUT -p udp --dport 123 -d 10.0.30.123 -j ACCEPT

# Log en drop de rest
iptables -A INPUT -j LOG --log-prefix "FW-DROP-IN: " --log-level 4
iptables -A OUTPUT -j LOG --log-prefix "FW-DROP-OUT: " --log-level 4
iptables -A INPUT -j DROP
iptables -A OUTPUT -j DROP

nftables (Linux, moderne vervanging)

#!/usr/sbin/nft -f
flush ruleset

table inet filter {
    chain input {
        type filter hook input priority 0; policy drop;
        iif "lo" accept
        ct state established,related accept
        ip saddr 10.0.30.0/24 tcp dport 22 accept
        icmp type echo-request limit rate 5/second accept
        log prefix "nft-drop-in: " counter drop
    }
    chain output {
        type filter hook output priority 0; policy drop;
        oif "lo" accept
        ct state established,related accept
        ip daddr 10.0.30.53 udp dport 53 accept
        ip daddr 10.0.30.123 udp dport 123 accept
        ip daddr 10.0.30.10 tcp dport 3128 accept
        log prefix "nft-drop-out: " counter drop
    }
    chain forward {
        type filter hook forward priority 0; policy drop;
    }
}

pf (BSD / macOS)

# /etc/pf.conf
mgmt_net = "10.0.30.0/24"
dns_srv  = "10.0.30.53"
proxy    = "10.0.30.10"

set block-policy drop
set skip on lo0
block log all
pass on lo0
pass out quick inet proto { tcp udp } keep state
pass in on egress proto tcp from $mgmt_net to any port 22
pass out on egress proto { tcp udp } to $dns_srv port 53
pass out on egress proto tcp to $proxy port 3128

Windows Firewall (PowerShell)

# Default deny inbound (standaard op Windows, maar verifieer)
Set-NetFirewallProfile -Profile Domain,Public,Private `
    -DefaultInboundAction Block `
    -DefaultOutboundAction Block `
    -Enabled True

# Blokkeer SMB inbound op werkstations
New-NetFirewallRule -DisplayName "Block SMB In" `
    -Direction Inbound -LocalPort 445 -Protocol TCP -Action Block

# Blokkeer WinRM inbound op werkstations
New-NetFirewallRule -DisplayName "Block WinRM In" `
    -Direction Inbound -LocalPort 5985,5986 -Protocol TCP -Action Block

# Blokkeer RPC inbound op werkstations
New-NetFirewallRule -DisplayName "Block RPC In" `
    -Direction Inbound -LocalPort 135 -Protocol TCP -Action Block

# Sta DNS outbound alleen toe naar interne DNS
New-NetFirewallRule -DisplayName "Allow DNS Out" `
    -Direction Outbound -RemotePort 53 -Protocol UDP `
    -RemoteAddress 10.0.30.53 -Action Allow

# Blokkeer directe DNS naar extern
New-NetFirewallRule -DisplayName "Block External DNS" `
    -Direction Outbound -RemotePort 53 -Protocol UDP `
    -RemoteAddress Any -Action Block

Elke drop-regel moet loggen. Firewallregels zonder logging zijn onzichtbaar. Gebruik log-prefixes (FW-DROP-IN:, FW-DROP-OUT:) en stuur ze naar je SIEM.

ACL best practices

Slecht geschreven ACLs zijn erger dan geen ACLs – ze geven een vals gevoel van veiligheid.

Specifiek boven generiek

! FOUT: te breed
access-list 100 permit ip 10.0.10.0 0.0.0.255 10.0.20.0 0.0.0.255

! GOED: alleen wat nodig is
access-list 100 permit tcp 10.0.10.0 0.0.0.255 host 10.0.20.5 eq 443
access-list 100 permit tcp 10.0.10.0 0.0.0.255 host 10.0.20.6 eq 3306

Documentatie van elke regel – ticket-nummer, aanvrager, goedkeuring en review-datum bij elke ACL-entry.

Regelmatige review – elk kwartaal. Verwijder regels die niet meer nodig zijn. Regels met nul hits in 90 dagen zijn kandidaten voor verwijdering (show access-list op Cisco, iptables -L -v -n op Linux).

Egress filtering – de meest vergeten vorm. Blokkeer directe HTTP/HTTPS outbound, forceer proxy. Elke ongecontroleerde outbound-verbinding is een potentieel C2-kanaal.

Microsegmentatie

Firewallregels op individuele hosts of workloads, ongeacht hun locatie in het netwerk.

Host-based firewalls op elke server

# Webserver: alleen HTTP/HTTPS inbound, alleen DB outbound
nft add rule inet filter input tcp dport { 80, 443 } accept
nft add rule inet filter output ip daddr 10.0.50.10 tcp dport 3306 accept
nft add rule inet filter output ct state established,related accept
nft add rule inet filter output drop

# Database: alleen verkeer van de webserver
nft add rule inet filter input ip saddr 10.0.20.5 tcp dport 3306 accept
nft add rule inet filter input ct state established,related accept
nft add rule inet filter input drop

Service mesh en container-omgevingen

# Kubernetes NetworkPolicy: alleen frontend mag naar backend
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-allow-frontend
spec:
  podSelector:
    matchLabels:
      app: backend
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: frontend
      ports:
        - protocol: TCP
          port: 8080
  policyTypes:
    - Ingress

Windows IPsec isolation

# Vereist Kerberos-authenticatie voor al het verkeer
New-NetIPsecRule -DisplayName "Require Auth" `
    -InboundSecurity Require -OutboundSecurity Request `
    -Phase1AuthSet (New-NetIPsecAuthProposal -Machine -Kerberos).Name

Platform-specifieke tools

Monitoring & validatie

Segmentatie zonder validatie is assumptie. Je denkt dat het werkt, maar je weet het niet.

Firewall log-analyse

# Top 10 geblokkeerde bronnen
grep "FW-DROP-IN" /var/log/firewall.log \
    | awk '{for(i=1;i<=NF;i++) if($i ~ /^SRC=/) print $i}' \
    | sort | uniq -c | sort -rn | head -10

Network flow monitoring

NetFlow/sFlow geven inzicht in verkeerspatronen: maak een baseline van normaal verkeer tussen zones, detecteer afwijkingen (werkstation-naar-werkstation op poort 445 is bijna altijd verdacht), en monitor volume-anomalieen die op data-exfiltratie kunnen duiden.

Segmentatie testen

# Vanuit werkstations: kan ik de database bereiken?
nmap -Pn -p 3306 10.0.50.10        # Verwacht: filtered
# Vanuit werkstations: kan ik RDP naar de DC?
nmap -Pn -p 3389 10.0.50.1         # Verwacht: filtered
# Vanuit de DMZ: kan ik intern scannen?
nmap -Pn -sn 10.0.10.0/24          # Verwacht: unreachable

Voer deze tests regelmatig uit. Netwerken veranderen. “Tijdelijke” uitzonderingen worden permanent.

Purple team validatie

Combineer de aanvalscommands uit dit handboek met je segmentatieregels:

1. Probeer lateral_wmi vanuit het werkstations-VLAN naar de servers – wordt het geblokkeerd?
2. Probeer een gesimuleerde ongewenste tunnel vanuit de DMZ naar intern – werkt egress filtering?
3. Probeer een gesimuleerde DNS-tunnel vanuit een server – wordt dit gedetecteerd?
4. Probeer lateral_psremoting tussen werkstations – is peer-to-peer verkeer geblokkeerd?

Als een van deze tests slaagt, is je segmentatie niet effectief voor dat scenario.

Veelvoorkomende fouten

Checklist

Er is een fenomeen in de IT-wereld dat ik het “Mondriaan-effect” noem. Het gaat als volgt: er wordt een consultant ingehuurd. Die consultant maakt een prachtige netwerktekening. Gekleurde vlakken. Strakke lijnen. DMZ in het rood. Interne zone in het blauw. Management in het groen. Restricted zone in het paars. Het is een kunstwerk. Het hangt ingelijst aan de muur van de serverruimte.

Ondertussen kan de stagiair vanaf zijn werkstation pingen naar de domain controller. De printer in de hal zit in hetzelfde VLAN als de salarisadministratie. De “tijdelijke” any-any-regel voor dat ene project uit 2019 staat er nog steeds in. En de firewall die 200.000 euro heeft gekost, functioneert in de praktijk als een dure switch met een mooi dashboard.

“We gaan segmenteren” is het IT-equivalent van “we gaan refactoren.” Het staat op de roadmap. Het heeft een Jira-ticket. Er is een high-level design. Maar er is nooit budget, nooit tijd, en nooit draagvlak. Want segmentatie betekent dat dingen kapotgaan. Applicaties die vertrouwen op het platte netwerk stoppen met werken. Gebruikers bellen de helpdesk. Managers schrijven boze mails. En voor je het weet besluit iemand dat “we de segmentatie even terugdraaien tot na de go-live” – en die go-live is nooit.

Het mooiste zijn de incidentrapporten achteraf. “De aanvaller kon zich lateraal door het netwerk bewegen.” Nee. De aanvaller kon dat niet omdat hij zo slim was. De aanvaller kon dat omdat jullie netwerk zo plat was dat je er een pannenkoek op kon bakken. De domain controller was bereikbaar vanaf het gastenwifi. De backup-server accepteerde SMB van het hele /16. De “firewall” stond op monitor-only.

Segmentatie is saai. Het genereert geen mooie dashboards. Het wint geen security-awards. Het levert geen LinkedIn-posts op over “innovative zero trust architectures.” Het levert helpdesk-tickets op en boze telefoontjes van afdelingshoofden die niet meer bij hun gedeelde schijf kunnen. Maar het is het verschil tussen “de aanvaller heeft een werkstation gecompromitteerd” en “de aanvaller bezit het hele netwerk.”

Kies je ongemak: nu segmenteren, of straks het incidentrapport schrijven.

Samenvatting

Netwerksegmentatie is de meest effectieve en meest genegeerde verdediging tegen laterale beweging. Een goed gesegmenteerd netwerk met default deny firewalls, gescheiden VLANs voor werkstations, servers, management en DMZ, en egress filtering op elke zone, maakt het overgrote deel van de aanvalstechnieken in dit handboek onbruikbaar. De implementatie vereist discipline: DTP uitschakelen, native VLANs wijzigen, elke ACL documenteren, kwartaal-reviews uitvoeren, en segmentatie daadwerkelijk testen met de tools die aanvallers gebruiken. Microsegmentatie via host-based firewalls en container network policies voegt een extra laag toe die beschermt zelfs wanneer de netwerksegmentatie faalt. Het is niet glamoureus. Het genereert geen mooie dashboards. Maar het werkt – mits je het doet. En dat “mits” is waar de meeste organisaties stranden.