Hvorfor en firewall-gate bundet til VPN-tilstand ikke er en regel om ping kun gennem tunnelen

Forestil dig en firewall-regel, der slår ICMP echo til for serverens offentlige adresse, hver gang en navngivet VPN-profil er forbundet. Det læses som »ping kun gennem tunnelen«, og den læsning er forkert på en måde, der betyder noget. Reglen begrænser ikke, hvem der kan nå værten; den ændrer, hvad den offentlige grænseflade svarer på, mens en anden forbindelse tilfældigvis er oppe. Det er to forskellige politikker, og den ene udvider eksponeringen i det stille.

Reglen, du tror, du skrev

Det tilsigtede krav er normalt snævert: overvågningssystemet eller den ene administrator på VPN'en skal kunne bekræfte, at serveren lever. Skrevet som en sætning lyder det som adgangskontrol på tunnelen. Skrevet som et firewall-objekt bliver det til en betingelse på den offentlige profil, fordi det er der, echo-anmodningen ankommer.

Når betingelsen er en forbindelsestilstand i stedet for en kildeadresse, er sættet af tilladte afsendere ikke længere VPN-peer-sættet. Alle, der kan nå den offentlige adresse, kan sende en echo-anmodning, mens gaten er åben. Tunnelen blev ikke vejen; tunnelen blev kontakten.

Folkene bag ideen lyver normalt ikke om den effekt, de ønskede. De havde brug for et tjek, der kun svarer, når forbindelsen er sund, og forbindelsens sundhed var lettest at observere gennem VPN'en. Fejlen er at behandle et tilgængelighedssignal som en adgangsbeslutning og derefter automatisere det.

Hvad gaten egentlig styrer

Dette design smelter to uafhængige ting sammen, og at skille dem er det meste af rettelsen. Det første er omfang: hvilken lokal adresse, hvilke fjerne adresser, hvilken protokol og hvilken ICMP-type. Det andet er betingelse: om regelobjektet er aktiveret i dette øjeblik. Omfang er det, en firewall vurderer pr. pakke; betingelse er det, et script skriver i politiklageret, og de to afstemmes på helt forskellige ure.

Hvis kravet virkelig kun er VPN-peers, besvarer omfanget det uden nogen logik for forbindelsestilstand: bind reglen til tunnelgrænsefladen eller til tunnelens adresseområde, begræns de fjerne adresser til klientpuljen, og angiv echo-typen i stedet for »ICMP«. Den regel forbliver korrekt, når ingen VPN er oppe, og kan ikke åbnes af en uvedkommende profil.

Hvis kravet virkelig er en offentlig gate, så sig det i politikteksten, fordi acceptkriterierne ændrer sig. En offentlig gate skal navngive den præcise profil, definere hvad »forbundet« betyder og erklære, at offentlige afsendere er i omfang efter design. Det meste af forvirringen forsvinder i det øjeblik, nogen tvinges til at skrive den sætning ned.

Byg objektet én gang, og skift det så

Forbered én regel med en stabil identitet, deaktiveret, og lad controlleren ændre kun dens aktiverede tilstand. At oprette regler efter vist navn ved hver kørsel er, hvordan et politiklager ender med fem næsten identiske objekter og ingen pålidelig måde at fjerne dem på.

New-NetFirewallRule -Name "VpnGateEchoV4" -DisplayName "Public echo gated on VPN state" -Direction Inbound -Action Allow -Protocol ICMPv4 -IcmpType 8 -LocalAddress 203.0.113.10 -RemoteAddress Any -Enabled False
Set-NetFirewallRule -Name "VpnGateEchoV4" -Enabled True

Navnet er den varige identifikator; det viste navn er dokumentation, som et menneske må redigere. Afstem mod -Name, og scriptet holder op med at producere dubletter. Samme kommandofacon dækker IPv6-tilfældet med -Protocol ICMPv6 -IcmpType 128, som er en separat regel, fordi echo-typens numre er forskellige i de to familier.

Hold adressefamilie og ICMP-type eksplicitte af en anden grund: -Protocol ICMPv4 uden type tillader enhver ICMPv4-besked, som profilen tillader, inklusive dem, du aldrig havde tænkt dig at acceptere. At navngive type 8 indsnævrer reglen til echo-anmodning, som er det eneste, en tilgængelighedskontrol sender.

Hvor automatiseringen modsiger hensigten

Afstemning af en klientprofil hvert par minutter kan ikke give en øjeblikkelig grænse. Mellem forbindelsen, der falder, og den næste afstemning svarer reglen stadig på den offentlige adresse; mellem forbindelsen, der kommer op, og den næste afstemning gør den ikke. At indrømme den forsinkelse er ærligt, og at hævde, at designet håndhæver en streng invariant, er det ikke.

Der er en omfangsfælde i selve tilstandstjekket. Get-VpnConnection rapporterer klientprofiler, der er konfigureret på maskinen, som standard for den aktuelle bruger og for alle brugere med -AllUserConnection. Den rapporterer ikke de fjernbrugere, der i øjeblikket er dialet ind på en RRAS-server; det er en anden observation med en anden kommando. En gate bygget på den forkerte er ikke forbundet med noget.

Dæk derefter de tilstande, ingen skriptet: opstart med reglen allerede aktiveret fra en tidligere kørsel, controller-nedbrud mens gaten er åben, og en profil slettet, mens dens regel forbliver aktiv. Hver især kræver en defineret standard, og den sikre standard for en offentlig tilladelse er deaktiveret. Hvis kravet virkelig ikke kan tåle afstemningsvinduet, er en tilstandsstyret regel det forkerte værktøj, og håndhævelsen hører til tunnelen, ikke til den offentlige grænseflade.

Test til sidst den offentlige anmodning to gange, én gang med den valgte forbindelse oppe og én gang med den nede, fra en vært, der ikke er på VPN'en. En vellykket ping inde fra tunnelen beviser intet om denne politik, og det er den måling, de fleste udrulninger springer over.