WebRTC Lokale IP-blootstelling Uitgeschakeld

De blootstelling van lokale IP-adressen via WebRTC vormt een kritieke privacykwetsbaarheid waarbij websites lokale IP-adressen kunnen ophalen zonder toestemming van de gebruiker. Dit gebeurt via het ICE-proces (Interactive Connectivity Establishment) van WebRTC dat alle netwerkinterfaces inventariseert tijdens het verzamelen van kandidaatverbindingen. Aanvallers en trackers gebruiken deze informatie voor verschillende doeleinden. Netwerkfingerprinting maakt gebruik van unieke combinaties van lokale IP-adressen, zoals 192.168.1.50 of 10.0.0.15, die fungeren als persistente trackingidentificatoren, zelfs nadat cookies zijn gewist. Bedrijfsreconnaissance maakt detectie mogelijk van interne IP-bereiken, waarbij 10.x.x.x-adressen doorgaans wijzen op bedrijfsnetwerken en 192.168.x.x-adressen op thuis- of kleine kantooromgevingen. Deze informatie onthult of een gebruiker zich op een bedrijfsnetwerk bevindt. Geolocatie-inferentie combineert lokale IP-adressen met publieke IP-adressen om de fysieke locatie te verfijnen. Interne netwerktopologiekartering onthult meerdere lokale IP-adressen die wijzen op gebrugde netwerken, virtuele adapters en VPN-interfaces. Cross-sessie-tracking is mogelijk omdat lokale IP-adressen vaak stabiel blijven over lange periodes, waardoor heridentificatie mogelijk is. Het betreft een zero-permission-aanval omdat WebRTC IP-inventarisatie geen gebruikersmachtigingsprompts vereist, in tegenstelling tot de geolocatie-API. Reële scenario's omvatten phishingwebsites die WebRTC gebruiken om te detecteren of een slachtoffer zich op een bedrijfsnetwerk bevindt voor gerichte aanvallen, advertentienetwerken die lokale IP-adressen gebruiken als persistente identificatoren om advertentieblokkering te omzeilen, en staatsactoren die lokale IP-patronen gebruiken voor surveillance en doelidentificatie. Door de blootstelling van lokale IP-adressen uit te schakelen, kunnen websites geen privé IP-adressen meer ophalen via WebRTC, terwijl de WebRTC-functionaliteit voor video en audio blijft werken via relayservers.

Implementatie

Deze controle configureert het Edge-beleid om blootstelling van lokale IP-adressen via WebRTC te blokkeren door mDNS-vervaging (Multicast DNS) af te dwingen en lokale ICE-kandidaten te filteren. De registerconfiguratie gebeurt via HKLM:\SOFTWARE\Policies\Microsoft\Edge\WebRtcLocalIpsAllowedUrls, waarbij een lege lijst betekent dat alles wordt geblokkeerd, in combinatie met EnableMediaRouter-beleidsbeperkingen. Wanneer deze controle is ingeschakeld, worden tijdens het verzamelen van WebRTC ICE-kandidaten geen lokale IP-adressen zoals 192.168.x.x of 10.x.x.x blootgesteld. Lokale IP-adressen worden vervangen door mDNS-hostnamen, bijvoorbeeld abc123-def456.local. Websites ontvangen alleen via STUN afgeleide publieke IP-adressen of mDNS-hostnamen. De interne netwerktopologie blijft volledig verborgen voor externe partijen. De WebRTC-functionaliteit blijft werken via STUN- en TURN-relayservers voor NAT-traversal. Het is belangrijk op te merken dat peer-to-peer WebRTC-verbindingen mogelijk een latentieverhoging kunnen ondervinden omdat directe lokale netwerkpaden niet kunnen worden gebruikt, waardoor een terugval naar TURN-relayservers noodzakelijk is.

Vereisten

Voor de implementatie van WebRTC-blokkering van lokale IP-blootstelling zijn verschillende technische en organisatorische voorwaarden vereist die zorgvuldig moeten worden overwogen voordat de configuratie wordt uitgerold. De eerste en meest kritieke vereiste betreft de versie van Microsoft Edge die binnen de organisatie wordt gebruikt. Microsoft Edge versie 77 of nieuwer is absoluut noodzakelijk, omdat alleen Chromium-gebaseerde versies ondersteuning bieden voor mDNS-vervaging, de privacyfunctie die lokale IP-adressen vervangt door hostnamen. Deze functionaliteit vormt de kern van de bescherming tegen IP-blootstelling en is essentieel voor het succesvol implementeren van deze beveiligingsmaatregel. Organisaties die nog oudere versies van Edge gebruiken, moeten eerst een upgrade uitvoeren voordat ze deze configuratie kunnen toepassen. Naast de Edge-versievereiste zijn Windows 10 of Windows 11 met administratorrechten noodzakelijk voor de configuratie van het beleid via het Windows-register. Deze rechten zijn vereist omdat de configuratie wordt opgeslagen in het HKLM-registerpad, wat alleen toegankelijk is voor gebruikers met verhoogde bevoegdheden. Voor centraal beheer is Group Policy Management of Microsoft Intune vereist, waardoor organisaties de instellingen kunnen implementeren en beheren zonder dat gebruikers deze kunnen wijzigen. Deze gecentraliseerde beheermethode is cruciaal voor het handhaven van consistente beveiligingsinstellingen binnen de gehele organisatie. Een belangrijke voorbereidende stap die vaak over het hoofd wordt gezien, is de inventarisatie van WebRTC-afhankelijke applicaties binnen de organisatie. Applicaties zoals Microsoft Teams web, Google Meet of Zoom kunnen afhankelijk zijn van WebRTC-functionaliteit en moeten grondig worden getest voordat de blokkering wordt geactiveerd. Deze inventarisatie helpt organisaties om potentiële compatibiliteitsproblemen vroegtijdig te identificeren en passende oplossingen te ontwikkelen. Hoewel optioneel, worden TURN-relayservers sterk aanbevolen voor peer-to-peer WebRTC-applicaties die mogelijk problemen ondervinden zonder lokale connectiviteit. Deze servers zorgen ervoor dat WebRTC-verbindingen blijven werken via relaypaden wanneer directe lokale netwerkverbindingen worden geblokkeerd. De implementatie van TURN-servers vereist aanvullende planning en mogelijk extra infrastructuurkosten, maar biedt significante voordelen voor de betrouwbaarheid van WebRTC-verbindingen. Netwerkmonitoringtools zijn nodig om het verzamelen van WebRTC ICE-kandidaten te inspecteren en te verifiëren dat lokale IP-adressen daadwerkelijk worden geblokkeerd. Deze tools helpen IT-beheerders om de effectiviteit van de configuratie te valideren en eventuele problemen tijdig te identificeren. Een testomgeving met diverse netwerktopologieën, waaronder bedrijfsnetwerken, thuisnetwerken en mobiele hotspots, is essentieel om te garanderen dat de blokkering onder alle omstandigheden correct functioneert. Deze testomgeving moet representatief zijn voor de werkelijke gebruikersomgevingen binnen de organisatie. Tot slot moet een communicatieplan voor gebruikers worden opgesteld om hen te informeren over mogelijke WebRTC-connectiviteits- of latentieproblemen die kunnen optreden na implementatie. Dit communicatieplan helpt om gebruikersverwachtingen te beheren en voorkomt onnodige supportverzoeken wanneer kleine prestatieverschillen optreden.

Implementatie

De implementatie van WebRTC lokale IP-blootstellingsblokkering vereist een gestructureerde aanpak waarbij verschillende technische configuratiestappen worden doorlopen om ervoor te zorgen dat lokale IP-adressen niet meer worden blootgesteld aan externe websites. De implementatie kan worden uitgevoerd via twee primaire beheermethoden: Group Policy voor on-premises omgevingen of Microsoft Intune voor cloudgebaseerde beheer. Beide methoden maken gebruik van Windows-registerconfiguraties om de gewenste beveiligingsinstellingen af te dwingen. De kern van de implementatie bestaat uit het configureren van het Edge-beleid WebRtcLocalIpsAllowedUrls, waarbij een lege lijst wordt ingesteld om alle blootstelling van lokale IP-adressen te blokkeren. Daarnaast wordt mDNS-vervaging afgedwongen, wat een privacyfunctie is die lokale IP-adressen vervangt door hostnamen met het .local-domein. Deze aanpak zorgt ervoor dat websites geen toegang meer hebben tot private IP-adressen zoals 192.168.x.x, 10.x.x.x of 172.16.x.x, terwijl de WebRTC-functionaliteit voor video- en audiocommunicatie intact blijft via STUN- en TURN-relayservers. Voor organisaties die Group Policy gebruiken, begint het implementatieproces met het openen van de Group Policy Management Console en het navigeren naar de gewenste Group Policy Object (GPO) die van toepassing is op de Edge-clients. Binnen de GPO-editor moet worden genavigeerd naar Computer Configuration, gevolgd door Administrative Templates, Microsoft Edge en vervolgens WebRTC-beleid. Hier kan het beleid WebRtcLocalIpsAllowedUrls worden geconfigureerd. Het is cruciaal om dit beleid in te stellen op 'Enabled' en vervolgens een lege lijst te specificeren, wat betekent dat geen enkele website toestemming heeft om lokale IP-adressen te verkrijgen. Voor Microsoft Intune-omgevingen wordt het implementatieproces uitgevoerd via de Microsoft Endpoint Manager Admin Center, waar een Configuration Profile wordt gemaakt specifiek voor Microsoft Edge. Binnen dit profiel worden dezelfde registerinstellingen geconfigureerd, waarbij de registerpad HKLM:\SOFTWARE\Policies\Microsoft\Edge\WebRtcLocalIpsAllowedUrls wordt ingesteld met een lege waarde. Na de configuratie moet het beleid worden toegewezen aan de relevante gebruikersgroepen of apparaten, afhankelijk van de organisatorische behoeften. Een belangrijke overweging tijdens de implementatie is het uitvoeren van uitgebreide compatibiliteitstests voordat het beleid wordt uitgerold naar productieomgevingen. Dit omvat het testen van WebRTC-afhankelijke applicaties zoals Microsoft Teams, Google Meet, Zoom en andere videoconferencingoplossingen om te verifiëren dat de functionaliteit niet wordt aangetast. Organisaties moeten ook overwegen om TURN-relayservers te implementeren als onderdeel van de implementatie, omdat deze servers ervoor zorgen dat WebRTC-verbindingen betrouwbaar blijven werken wanneer lokale netwerkpaden worden geblokkeerd. De implementatie moet worden begeleid door een communicatieplan dat gebruikers informeert over mogelijke veranderingen in WebRTC-prestaties, zoals iets hogere latentie bij peer-to-peer-verbindingen. Daarnaast moeten IT-beheerders worden getraind in het monitoren en troubleshooten van WebRTC-verbindingsproblemen die kunnen optreden na de implementatie. Het is aanbevolen om de implementatie gefaseerd uit te voeren, te beginnen met een pilotgroep van gebruikers, gevolgd door monitoring van de impact en eventuele aanpassingen voordat de volledige organisatie wordt uitgerold.

Gebruik PowerShell-script webrtc-local-ip-exposure-disabled.ps1 (functie Invoke-Monitoring) – Controleert of WebRTC lokale IP-blootstelling is geblokkeerd. Valideert dat ICE-kandidaten geen private IP-adressen bevatten en mDNS-vervaging actief is..

Gebruik PowerShell-script webrtc-local-ip-exposure-disabled.ps1 (functie Invoke-Remediation) – Configureert Edge-beleid om de blootstelling van lokale IP-adressen te blokkeren. Stelt WebRtcLocalIpsAllowedUrls in op een lege lijst en dwingt mDNS-vervaging af voor alle ICE-kandidaten..

Gebruik PowerShell-script webrtc-local-ip-exposure-disabled.ps1 (functie Invoke-Revert) – Verwijdert de beperkingen voor de blootstelling van lokale IP-adressen. WebRTC kan daarna weer privé IP-adressen inventariseren (ALLEEN voor het oplossen van WebRTC-verbindingsproblemen)..

Technische Details

De blokkering van WebRTC-lokale IP-blootstelling werkt door middel van ICE-kandidaatfiltering en mDNS-obfuscatie. De configuratie wordt opgeslagen in het Windows-register via het pad HKLM:\SOFTWARE\Policies\Microsoft\Edge\WebRtcLocalIpsAllowedUrls, waarbij een lege array betekent dat alle lokale IP-blootstelling wordt geblokkeerd. Het ICE-protocol (Interactive Connectivity Establishment) kent verschillende kandidaattypen die worden gebruikt voor het opzetten van WebRTC-verbindingen. Het host-type vertegenwoordigt lokale IP-adressen, het srflx-type verwijst naar via STUN verkregen publieke IP-adressen, het relay-type gebruikt TURN-relayservers, en het prflx-type betreft peer-reflexieve kandidaten. De mDNS-obfuscatie is een privacyfunctie van Chromium die lokale IP-adressen vervangt door hostnamen met het .local-domein, conform RFC 6762 Multicast DNS. In plaats van een lokaal IP-adres zoals 192.168.1.50 wordt bijvoorbeeld een mDNS-hostnaam zoals abc123-def456-ghi789-jkl012.local gebruikt. Wanneer het beleid actief is, retourneert de JavaScript API RTCPeerConnection.getLocalCandidates() mDNS-hostnamen in plaats van IP-adressen. Websites kunnen hierdoor niet detecteren welke IP-bereiken worden gebruikt, zoals 10.x, 172.16.x of 192.168.x, wat de privacy en beveiliging van het interne netwerk beschermt. Wanneer lokale connectiviteit wordt geblokkeerd, gebruiken WebRTC-verbindingen automatisch TURN-relayservers als terugvaloptie. Hoewel TURN-relayservers ongeveer 50 tot 100 milliseconden extra latentie toevoegen in vergelijking met directe peer-to-peer-verbindingen, voorkomt deze aanpak privacylekken en blijft de functionaliteit behouden.

Best Practices

Voor effectieve bescherming tegen de blootstelling van lokale IP-adressen via WebRTC moeten organisaties een uitgebreide teststrategie implementeren voordat de configuratie in productie wordt genomen. WebRTC-afhankelijke applicaties zoals Microsoft Teams web, Google Meet en Zoom web moeten grondig worden getest op verbindingsproblemen en latentie na de implementatie van de blokkering. Deze tests moeten worden uitgevoerd in verschillende netwerkomgevingen, waaronder bedrijfsnetwerken, thuisnetwerken en mobiele hotspots, om te garanderen dat de functionaliteit onder alle omstandigheden behouden blijft. Organisaties moeten gebruikmaken van online WebRTC-lektesttools zoals browserleaks.com/webrtc en ipleak.net om te valideren dat lokale IP-adressen daadwerkelijk niet meer zichtbaar zijn voor externe websites. Deze validatie moet regelmatig worden herhaald om te verifiëren dat de configuratie actief blijft en niet onbedoeld wordt gewijzigd. Het is belangrijk om het verwachte mDNS-hostnaamformaat (*.local) te documenteren voor beveiligingsmonitoringteams, zodat deze teams onderscheid kunnen maken tussen legitieme mDNS-hostnamen en mogelijke beveiligingsincidenten. Dit voorkomt vals-positieve resultaten in beveiligingsmonitoringsystemen en voorkomt onnodige alarmen. Voor bedrijfsapplicaties die afhankelijk zijn van WebRTC-functionaliteit wordt sterk aanbevolen om TURN-relayservers te implementeren. Deze servers zorgen ervoor dat WebRTC-verbindingen van hoge kwaliteit blijven zonder dat lokale IP-adressen worden blootgesteld. De implementatie van TURN-relayservers vereist zorgvuldige planning met betrekking tot netwerkcapaciteit, omdat deze servers alle WebRTC-verkeer moeten routeren wanneer directe peer-to-peer-verbindingen niet mogelijk zijn. Organisaties moeten WebRTC-verbindingskwaliteitsmetrieken monitoren, waaronder latentie, pakketverlies en jitter, om de prestaties van relay-servers te volgen en eventuele problemen tijdig te identificeren. Deze monitoring helpt bij het optimaliseren van de TURN-infrastructuur en het garanderen van een goede gebruikerservaring. Gebruikers moeten worden geïnformeerd over mogelijke veranderingen in de verbindingskwaliteit, met name dat peer-to-peer-videochat mogelijk een hogere latentie heeft door het gebruik van relay-servers. Deze communicatie voorkomt verwarring en helpt gebruikers realistische verwachtingen te stellen. In zeer zeldzame gevallen kunnen specifieke interne applicaties lokale netwerkconnectiviteit vereisen voor optimale functionaliteit. Voor deze gevallen kunnen organisaties overwegen om uitzonderingen te maken door specifieke domeinen toe te voegen aan de WebRtcLocalIpsAllowedUrls-whitelist. Deze uitzonderingen moeten echter zeer beperkt worden gehouden en alleen worden toegepast na een grondige risicoanalyse en goedkeuring van de beveiligingsafdeling. Tot slot moeten organisaties valideren dat mDNS-vervaging correct werkt op verschillende netwerktypen, waaronder WiFi, Ethernet, VPN-verbindingen en mobiele hotspots, om te garanderen dat de privacybescherming onder alle omstandigheden effectief is.

Compliance en Auditing

De blokkering van WebRTC-lokale IP-blootstelling ondersteunt verschillende complianceframeworks door privacylekken te voorkomen. Binnen de Algemene Verordening Gegevensbescherming (AVG) draagt artikel 25, dat handelt over gegevensbescherming door ontwerp en door standaardinstellingen, bij aan het voorkomen van onnodige verzameling van lokale IP-adressen, die als persoonsgegevens worden beschouwd. Artikel 32 van de AVG, dat handelt over de beveiliging van de verwerking, biedt bescherming tegen persistente tracking via IP-fingerprinting, wat een belangrijke privacyrisico vormt. Binnen ISO 27001 draagt controle A.13.2.1, dat handelt over informatieoverdrachtsbeleid, bij aan het voorkomen van ongeautoriseerde openbaarmaking van netwerktopologie aan externe partijen. Het NIST SP 800-53-controle SC-7, dat handelt over grensbescherming, voorkomt dat informatie over interne netwerken lekt naar externe websites. De CIS Microsoft Edge Benchmark vereist expliciet WebRTC-blokkering van lokale IP-blootstelling voor privacybescherming als onderdeel van de aanbevolen beveiligingsconfiguratie. De ePrivacyrichtlijn biedt bescherming tegen tracking zonder toestemming via lokale IP-fingerprinting, wat een belangrijke privacybescherming vormt voor Europese burgers. Binnen het BIO-kader, specifiek Thema 12 over netwerken, draagt deze maatregel bij aan de bescherming van de interne netwerkstructuur tegen externe inventarisatie door aanvallers. Samen vormen deze compliancevereisten een sterke rechtvaardiging voor de implementatie van WebRTC-lokale IP-blokkering binnen Nederlandse overheidsorganisaties.

Troubleshooting

Bij de implementatie van WebRTC-blokkering van lokale IP-adressen kunnen verschillende problemen optreden die specifieke oplossingen vereisen. Wanneer WebRTC-videogesprekken hoge latentie vertonen van meer dan 200 milliseconden, is dit vaak het verwachte gedrag door het gebruik van TURN-relayservers. Om de prestaties te verbeteren, kunnen organisaties dedicated TURN-servers op het bedrijfsnetwerk implementeren die lagere latentie bieden dan publieke relayservers. Peer-to-peer-bestandsdelingstoepassingen kunnen niet meer werken omdat deze applicaties vaak lokale connectiviteit vereisen. In dergelijke gevallen moeten organisaties overwegen om servergebaseerde bestandsdelingalternatieven te gebruiken of, in zeer specifieke gevallen, een uitzondering te verlenen voor specifieke applicaties na grondige beveiligingsevaluatie. Wanneer WebRTC-lektestsites nog steeds lokale IP-adressen tonen, moet worden geverifieerd dat WebRtcLocalIpsAllowedUrls een lege array is, Edge moet opnieuw worden gestart, de cache moet worden gewist, en de configuratie moet worden getest met edge://webrtc-internals. Als mDNS .local-hostnamen niet verschijnen in ICE-kandidaten, moet worden gecontroleerd of Edge versie 89 of nieuwer wordt gebruikt, aangezien mDNS-obfuscatie alleen beschikbaar is in nieuwere versies, en de status van de Windows mDNS-service moet worden gecontroleerd. Wanneer WebRTC-verbindingen volledig falen zonder audio of video, moet de connectiviteit van TURN- en STUN-servers worden geverifieerd, firewallregels voor UDP- en TCP-poorten moeten worden gecontroleerd, en tests moeten worden uitgevoerd met publieke STUN-servers zoals stun.l.google.com. Als het beleid niet actief is na implementatie, moet 'gpupdate /force' worden uitgevoerd, Edge moet opnieuw worden gestart, en het register moet worden geverifieerd met 'Get-ItemProperty HKLM:\SOFTWARE\Policies\Microsoft\Edge WebRtcLocalIpsAllowedUrls'. Wanneer interne bedrijfs-WebRTC-applicaties niet werken, kan het applicatiedomein worden toegevoegd aan de WebRtcLocalIpsAllowedUrls-whitelist, hoewel dit zeer specifiek moet gebeuren en alleen voor vertrouwde interne applicaties. Als gebruikers klagen over kwaliteitsvermindering van video, kan de bandbreedte van TURN-relayservers een knelpunt zijn, waardoor organisaties de TURN-infrastructuur moeten opschalen of relayverkeer moeten prioriteren in QoS-beleid.

Monitoring

Effectieve monitoring van WebRTC lokale IP-blootstellingsblokkering is essentieel om te verifiëren dat de beveiligingsmaatregelen correct functioneren en om eventuele problemen tijdig te identificeren. Monitoring moet worden uitgevoerd op verschillende niveaus, waaronder beleidsconfiguratie, netwerkgedrag en gebruikerservaring. De primaire monitoringactiviteit bestaat uit het regelmatig controleren van de Edge-beleidsconfiguratie om te verifiëren dat WebRtcLocalIpsAllowedUrls correct is ingesteld op een lege lijst. Dit kan worden gedaan via PowerShell-scripts die het Windows-register uitlezen op het pad HKLM:\SOFTWARE\Policies\Microsoft\Edge\WebRtcLocalIpsAllowedUrls. De monitoring moet verifiëren dat de waarde daadwerkelijk leeg is en niet is gewijzigd door gebruikers of andere processen. Daarnaast moeten organisaties regelmatig WebRTC-lektests uitvoeren met behulp van online tools zoals browserleaks.com/webrtc of ipleak.net om te valideren dat lokale IP-adressen niet zichtbaar zijn voor externe websites. Deze tests moeten worden uitgevoerd op verschillende netwerktypen, waaronder bedrijfsnetwerken, thuisnetwerken en mobiele hotspots, om consistentie te garanderen. Monitoring van WebRTC-verbindingskwaliteit is eveneens belangrijk, omdat de blokkering van lokale IP-adressen kan leiden tot verhoogde latentie wanneer TURN-relayservers worden gebruikt. Organisaties moeten metrische gegevens verzamelen over verbindingslatentie, pakketverlies en verbindingsstabiliteit om te identificeren of er prestatieproblemen optreden die mogelijk verband houden met de blokkering. Het monitoren van edge://webrtc-internals pagina's op representatieve apparaten biedt gedetailleerde inzichten in ICE-kandidaten en kan bevestigen dat alleen mDNS-hostnamen met .local-domein worden gebruikt in plaats van lokale IP-adressen. Automatische monitoring via PowerShell-scripts kan worden geconfigureerd om periodiek de beleidsstatus te controleren en waarschuwingen te genereren wanneer afwijkingen worden gedetecteerd. Deze scripts moeten worden geïntegreerd met bestaande monitoringoplossingen zoals Microsoft Endpoint Manager of System Center Operations Manager voor gecentraliseerde rapportage. Gebruikersfeedback moet ook worden gemonitord om te identificeren of er problemen zijn met WebRTC-afhankelijke applicaties die mogelijk verband houden met de blokkering. Organisaties moeten een proces hebben voor het verzamelen en analyseren van gebruikersklachten over videoconferencing-kwaliteit of connectiviteitsproblemen. Loganalyse van TURN-relayservers, indien geïmplementeerd, biedt waardevolle inzichten in verbindingspatronen en kan helpen bij het identificeren van potentiële knelpunten. Tot slot moeten compliance-audits regelmatig worden uitgevoerd om te verifiëren dat de blokkering voldoet aan de vereisten van frameworks zoals AVG, ISO 27001 en CIS Benchmarks.

Gebruik PowerShell-script webrtc-local-ip-exposure-disabled.ps1 (functie Invoke-Monitoring) – Controleert of WebRTC lokale IP-blootstelling is geblokkeerd. Valideert dat ICE-kandidaten geen private IP-adressen bevatten en mDNS-vervaging actief is..

Remediatie

Remediatie van WebRTC lokale IP-blootstellingsproblemen vereist een systematische aanpak waarbij eerst wordt geïdentificeerd waarom de blokkering niet correct functioneert, gevolgd door gerichte correctieve acties. Wanneer monitoring aangeeft dat lokale IP-adressen nog steeds worden blootgesteld, moet het remediatieproces beginnen met het verifiëren van de Edge-beleidsconfiguratie. Het meest voorkomende probleem is dat het beleid WebRtcLocalIpsAllowedUrls niet correct is geconfigureerd of is overschreven door andere beleidsinstellingen. Remediatie begint met het controleren van het Windows-register op het pad HKLM:\SOFTWARE\Policies\Microsoft\Edge\WebRtcLocalIpsAllowedUrls om te verifiëren dat de waarde leeg is of niet bestaat. Als de waarde niet leeg is, moet deze worden verwijderd of worden ingesteld op een lege array. Voor Group Policy-omgevingen moet worden gecontroleerd of de GPO correct is toegepast door het uitvoeren van 'gpupdate /force' op de betrokken apparaten, gevolgd door een herstart van Microsoft Edge. In Microsoft Intune-omgevingen moet worden geverifieerd dat het Configuration Profile correct is toegewezen aan de apparaten en dat de registerinstellingen correct zijn geconfigureerd. Als het beleid correct is geconfigureerd maar lokale IP-adressen nog steeds worden blootgesteld, kan dit wijzen op een Edge-versieprobleem. Organisaties moeten verifiëren dat Microsoft Edge versie 89 of nieuwer wordt gebruikt, omdat mDNS-vervaging alleen beschikbaar is in nieuwere versies. Wanneer oudere Edge-versies worden gedetecteerd, moet een upgrade worden uitgevoerd naar een ondersteunde versie. Een ander veelvoorkomend probleem is dat de Windows mDNS-service niet actief is, wat kan voorkomen dat mDNS-hostnamen worden gegenereerd. In dergelijke gevallen moet de mDNS-service worden gecontroleerd en indien nodig worden gestart. Wanneer WebRTC-verbindingen volledig falen na de implementatie van de blokkering, moet worden gecontroleerd of TURN- en STUN-servers bereikbaar zijn en of firewallregels de benodigde UDP- en TCP-poorten toestaan. Remediatie kan ook het implementeren of configureren van TURN-relayservers omvatten om betrouwbare WebRTC-connectiviteit te garanderen. Voor organisaties die specifieke interne applicaties hebben die lokale netwerkconnectiviteit vereisen, kan het nodig zijn om uitzonderingen te configureren door specifieke domeinen toe te voegen aan de WebRtcLocalIpsAllowedUrls-lijst. Dit moet echter zeer zorgvuldig worden gedaan en alleen voor vertrouwde interne applicaties na een grondige beveiligingsevaluatie. Automatische remediatie via PowerShell-scripts kan worden geconfigureerd om automatisch correctieve acties uit te voeren wanneer afwijkingen worden gedetecteerd, zoals het opnieuw toepassen van beleidsinstellingen of het herstarten van Edge-services. Het is belangrijk om na remediatie altijd verificatietests uit te voeren om te bevestigen dat de problemen zijn opgelost en dat de blokkering correct functioneert.

Gebruik PowerShell-script webrtc-local-ip-exposure-disabled.ps1 (functie Invoke-Remediation) – Configureert Edge-beleid om de blootstelling van lokale IP-adressen te blokkeren. Stelt WebRtcLocalIpsAllowedUrls in op een lege lijst en dwingt mDNS-vervaging af voor alle ICE-kandidaten..

Compliance & Frameworks

• CIS M365: Control () - CIS Edge Benchmark - Blokkeer blootstelling van lokale IP-adressen via WebRTC
• BIO: 12.01.03 - BIO Thema 12 Netwerken - Bescherming interne netwerkstructuur
• ISO 27001:2022: A.13.2.1 - Informatieoverdrachtsbeleid - voorkomt openbaarmaking van netwerktopologie

Automation

Gebruik het onderstaande PowerShell script om deze security control te monitoren en te implementeren. Het script bevat functies voor zowel monitoring (-Monitoring) als remediation (-Remediation).

Risico zonder implementatie

Management Samenvatting

Schakel WebRTC lokale IP-blootstelling uit door mDNS-vervaging af te dwingen en WebRtcLocalIpsAllowedUrls-beleid te configureren. Voorkomt netwerkfingerprinting, bedrijfsreconnaissance en privacy-tracking terwijl WebRTC-functionaliteit blijft werken via relayservers.

• Implementatietijd: 16 uur
• FTE required: 0.06 FTE