Tunneling Voorkomen

Rechten Omlaag, Controle Omhoog

Aanvalspaden worden klein zodra rechten, segmenten en beheerkanalen consequent zijn ingericht.

Voor Tunneling Voorkomen 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 Tunneling Voorkomen is risicoreductie in de praktijk. Technische context ondersteunt de maatregelkeuze, maar implementatie en borging staan centraal.

Verdediging

Nu, het cynische deel. Want iemand moet het zeggen.

“Ons netwerk is gesegmenteerd.”

Ja. Dat zeggen ze allemaal. Het staat in de PowerPoint. Het staat in het beveiligingsbeleid. Er is ooit een architect geweest die een prachtige tekening heeft gemaakt met gekleurde vlakken en pijltjes, en iedereen heeft geknikt en “goed plan” gezegd.

En dan blijkt dat de applicatieserver in de DMZ een tweede netwerkkaart heeft die rechtstreeks in het database-VLAN hangt, “omdat de applicatie anders te langzaam is”. Of dat er een beheer-VLAN is dat overal bij kan, en dat iedereen van IT daar toegang toe heeft “voor troubleshooting”. Of dat de firewall-regels ooit als tijdelijke maatregel zijn verruimd en nooit meer zijn teruggedraaid, omdat niemand meer weet waarom ze er stonden.

Segmentatie die niet wordt gehandhaafd, is geen segmentatie. Het is decoratie.

Maar goed. Er zijn dingen die je kunt doen om tunneling moeilijker te maken. Niet onmogelijk – niets is onmogelijk als de aanvaller voldoende tijd en motivatie heeft – maar moeilijker.

Egress filtering

De meeste firewalls controleren inkomend verkeer alsof hun leven ervan afhangt, en laten uitgaand verkeer zonder enige inspectie door. Dat is alsof je een nachtclub runt waar de uitsmijter alleen controleert wie er binnenkomt, maar iedereen die naar buiten loopt met een flatscreen onder zijn arm vrolijk doorlaat.

Implementeer egress filtering. Beperk welke poorten uitgaand verkeer mogen gebruiken. Sta SSH alleen toe naar bekende bestemmingen. Forceer HTTP-verkeer via een proxy. En log alles.

# Voorbeeld: alleen bekende bestemmingen voor SSH
iptables -A OUTPUT -p tcp --dport 22 -d known_ssh_server -j ACCEPT
iptables -A OUTPUT -p tcp --dport 22 -j DROP

DNS inspection

DNS-tunneling werkt omdat niemand naar DNS-verkeer kijkt. Verander dat.

• Monitor query-lengtes: normale DNS-queries zijn kort. DNScat2-queries zijn lang en bevatten gecodeerde data.
• Monitor query-volumes: een machine die honderden DNS-queries per minuut doet naar hetzelfde domein is verdacht.
• Gebruik een DNS firewall die bekende tunneling-domeinen blokkeert.
• Forceer al het DNS-verkeer via je eigen resolvers en blokkeer directe DNS naar externe servers.

Network monitoring

Deploy een IDS/IPS die tunneling-patronen herkent:

• SSH over niet-standaard poorten
• HTTP-verkeer dat geen echte HTTP-payload bevat (Chisel)
• Abnormale DNS-patronen
• Langdurige verbindingen naar enkele hosts

SSH hardening

• Beperk SSH-toegang tot specifieke IP-adressen en gebruikers
• Schakel agent forwarding uit tenzij expliciet nodig: AllowAgentForwarding no
• Schakel TCP forwarding uit waar het niet nodig is: AllowTcpForwarding no
• Log alle SSH-verbindingen en monitor op anomalieen
• Gebruik certificaat-gebaseerde authenticatie in plaats van wachtwoorden

Microsegmentatie

De trend in moderne netwerken is microsegmentatie: niet alleen segmenteren per VLAN, maar per workload. Elke applicatie, elke service, elke container heeft zijn eigen set van firewall-regels die alleen het strikt noodzakelijke verkeer toestaan.

Het is meer werk. Veel meer werk. Maar het betekent dat een gecompromitteerde webserver niet automatisch bij de database kan, zelfs als ze in hetzelfde VLAN zitten. De tunnel moet niet alleen het netwerk overbruggen, maar ook de applicatielaag, en dat maakt pivoting exponentieel moeilijker.

De cynicus heeft het laatste woord

Weet je wat het mooiste is aan tunneling? Het toont perfect aan hoe de beveiligingsindustrie werkt.

Een organisatie geeft honderdduizenden euro’s uit aan next-generation firewalls met deep packet inspection, SSL-interceptie, en AI-powered threat detection. Ze huren een consultant in om de netwerksegmentatie te ontwerpen. Ze laten een architectuurtekening maken die eruitziet als een kunstwerk van Mondriaan.

En dan doet een penetratietester ssh -D 1080 op een vergeten Linux-server in de DMZ en heeft binnen twee minuten toegang tot het complete interne netwerk.

Niet omdat de tools niet werken. Niet omdat de firewall slecht is. Maar omdat ergens, op een dinsdagmiddag om half vijf, iemand een uitzondering heeft gemaakt. “Alleen tijdelijk.” “Alleen voor dit project.” “Alleen voor deze server.”

Tijdelijke uitzonderingen zijn de permanente bewoners van elk beveiligingsbeleid. Ze komen binnen met de belofte dat ze morgen weer vertrekken, en vijf jaar later zitten ze er nog steeds, met pantoffels aan en een abonnement op de kabelkrant.

De enige verdediging die echt werkt tegen tunneling is niet een product of een tool. Het is discipline. Het is de discipline om elke uitzondering te documenteren, te reviewen, en te verwijderen wanneer hij niet meer nodig is. Het is de discipline om firewall-regels te auditen. Het is de discipline om te controleren of de architectuurtekening nog overeenkomt met de werkelijkheid.

En discipline, zo weten we uit de menselijke geschiedenis, is precies datgene waar we als soort het slechtst in zijn.

Referentietabel

Samenvatting

Tunneling is de kunst van het leggen van verborgen verbindingen door netwerken die bedoeld zijn om die verbindingen te voorkomen. Van de simpele elegantie van SSH local port forwarding tot de brute kracht van een Metasploit pivot-chain; van de transparantie van sshuttle tot het ultieme stealth-kanaal van DNS-tunneling – elke tool heeft zijn plaats.

De keuze hangt af van drie factoren:

1. Wat is beschikbaar? SSH? HTTP? Alleen DNS?
2. Wat heb je nodig? Een enkele poort? Een heel subnet? Een volledige SOCKS proxy?
3. Hoe stil moet je zijn? Maakt detectie uit, of is snelheid belangrijker?

In het volgende hoofdstuk verlaten we de tunnels en duiken we in de wereld van Linux post-incident herstel – waar de servers stil zijn, de logs uitgebreid, en de cronjobs verraderlijk.