Hoe je test wat een noodschakelaar dekt op een gecompromitteerde host

Zet de noodschakelaar aan, haal de tunnelserver offline en kijk wat de machine nog doet. De test is de moeite waard omdat hij scheidt wat de firewall werkelijk afdwingt van wat je aannam, en de resultaten zijn smaller dan de meeste productpagina's suggereren. Een noodschakelaar bestuurt netwerkpaden; hij bestuurt geen software die al op het apparaat draait. Ik voer deze reeks uit op elke machine waarvan de client beweert fail-closed te zijn, en het duurt ongeveer tien minuten.

Begin bij de client, niet bij de server

Het handhavingspunt is de host waar je zit: de firewall van het besturingssysteem, een hulpdienst of het stuurprogramma van de VPN-client zelf. Dat telt, want alles wat de schakelaar kan doen, wordt begrensd door wat die laag ziet. Als de client de blokkade uitvoert met een routeringsregel en een markering, kan alles met genoeg rechten een eigen regel toevoegen; gebruikt hij een kernel-firewalltabel, dan kunnen dezelfde rechten de tabel bewerken. De sterkte van de versleuteling komt hier nooit aan te pas.

De eerste vraag is dus wie het beleid op dit apparaat bezit en wat het mag overschrijven. Op een beheerde werkmachine is het antwoord meestal de endpointagent van de organisatie, en een persoonlijke VPN haalt die mogelijkheden niet weg, hoe de tunnel ook is geconfigureerd.

Stap één: bevestig de blokkade op de paden waarvan je denkt dat hij ze dekt

Haal de tunnel aan de verre kant neer, niet bij de client, zodat de client nog steeds denkt dat hij verbonden zou moeten zijn. Probeer daarna wat een mens werkelijk zou proberen:

curl -m 5 -sS -o /dev/null -w '%{http_code}
' https://example.com
ping -c 2 1.1.1.1
ip route
nft list ruleset   # or: iptables -S

Je wilt een client die snel en schoon faalt, niet een die blijft hangen tot de time-out van de browser. Hangend betekent meestal dat pakketten stil worden weggegooid door een regel zonder weigering, wat acceptabel is, maar het kan ook betekenen dat de client een verouderde standaardroute naar een dode interface heeft achtergelaten. Lees de routeringstabel terwijl de tunnel omlaag is: een standaardroute die nog naar het tunnelapparaat wijst en een firewallregel die alleen nieuwe uitgaande verbindingen blokkeert, zijn twee verschillende toestanden, en alleen één daarvan is fail-closed.

Herhaal dezelfde commando's met de allow-LAN-optie van de client aan en uit. Die schakelaar is waar de meeste verrassingen wonen, omdat hij een pad heropent dat de rest van het beleid moest sluiten.

Stap twee: controleer DNS en IPv6 als afzonderlijke paden

Naamresolutie is het gat dat de meeste implementaties overleeft, omdat de query via iets anders dan de systeemresolver naar buiten kan. Vraag met een hulpmiddel dat je resolverconfiguratie negeert, en controleer tegelijk de v6-kant:

dig +short example.com
dig +short @1.1.1.1 example.com
curl -6 -m 5 -sS https://example.com -o /dev/null -w '%{http_code}
'
ip -6 route

Lege antwoorden op beide naamquery's met de tunnel omlaag zijn het resultaat dat je wilt. Als de tweede query antwoordt, is een hardgecodeerd resolveradres bereikbaar en is de tunnel niet de enige uitweg uit de machine. Als alleen het v6-verzoek slaagt, dekt het beleid IPv4 en negeert het IPv6, wat dezelfde lekkage in een andere adressenfamilie is.

Browsers maken dit van buitenaf moeilijker te lezen, omdat een browser die voor DNS over HTTPS is ingesteld de query via een HTTPS-verzoek oplost: de query is alleen geblokkeerd voor zover poort 443 naar dat eindpunt dat is. Op een host waar het beleid het lokale subnet toestaat, kan dat verzoek nog steeds een resolver op de LAN bereiken.

Stap drie: scheid netwerkblootstelling van eindpuntblootstelling

Nu het deel dat geen firewallregel bereikt. Een noodschakelaar blokkeert paden van de machine af; hij verhindert niet dat software op de machine gegevens leest voordat ze versleuteld zijn, en hij verhindert niet dat die software de tunnel legaal gebruikt. Een keylogger, een kwaadaardige extensie, een scherm dat ontgrendeld is achtergelaten, een synchronisatieclient met brede rechten: ze verplaatsen allemaal informatie over een verbinding die de schakelaar graag toestaat.

Hetzelfde geldt voor bewakingssoftware die een werkgever met opzet heeft geïnstalleerd. Het blokkeren van routes verwijdert die niet, en een nieuwe VPN-server kopen is niet de reparatie, omdat de blootstelling vóór de tunnel zit.

Een klembordbeheerder die naar een cloudaccount uploadt, maakt het punt scherp. Het verkeer is versleuteld, de bestemming is toegestaan, en de noodschakelaar meldt de hele tijd een gezonde toestand.

Stap vier: schrijf de bewering die je test ondersteunt

Na de uitvaltest kun je concrete feiten noemen: welke applicaties faalden, welke paden stopten, hoe DNS en IPv6 zich gedroegen en of de blokkade hield toen de tunnel viel. Je kunt niet zeggen dat het besturingssysteem schoon is, en niet dat een dienst aan de verre kant je login privé houdt.

Houd de twee problemen gescheiden en geef elk zijn eigen controle:

• Noodschakelaar: de gedefinieerde faileis, geverifieerd met een uitvaltest die je na elke clientupgrade herhaalt.
• Apparaatvertrouwen: ondersteunde updates, eindpuntbescherming uit een betrouwbare bron, herziening van onverklaarde rechten en authenticatieverzoeken.
• Incident: volg het proces van het platform of de organisatie bij vermoeden van compromittering; een nieuwe server is geen opruimstap.
• Openbaarmaking: als je om hulp vraagt, plak dan geen privésleutels of volledige diagnostische archieven, want logboeken en schermafbeeldingen dragen dezelfde geheimen als de verbinding.

Voer de reeks opnieuw uit na de volgende update, want een noodschakelaar is configuratie die met versies meebeweegt. De test is het enige bewijs dat het gedrag waarop je vertrouwt nog steeds het gedrag is dat je krijgt.