Waarom 'n vuurmuurhek op VPN-toestand nie 'n blote ping-reël is nie

Stel jou 'n vuurmuurreël voor wat ICMP-echo vir die bediener se publieke adres aanskakel sodra 'n genoemde VPN-profiel gekoppel is. Dit lees soos “ping net deur die tonnel”, en dié lees is verkeerd op 'n manier wat saak maak. Die reël beperk nie wie die gasheer mag bereik nie; dit verander wat die publieke koppelvlak antwoord terwyl een of ander ander verbinding toevallig aan is. Dis twee verskillende beleide, en een van hulle verbreed die blootstelling sonder dat iemand dit agterkom.

Die reël wat jy dink jy geskryf het

Die bedoelde vereiste is gewoonlik smal: die moniteringstelsel, of die enkele administrateur op die VPN, moet kan bevestig dat die bediener leef. As 'n sin neergeskryf, klink dit na toegangsbeheer op die tonnel. As 'n vuurmuurvoorwerp neergeskryf, word dit 'n voorwaarde op die publieke profiel, want dit is waar die echo-versoek aankom.

Sodra die voorwaarde 'n verbindingstoestand is eerder as 'n bronadres, is die stel toegelate senders nie meer die VPN-eweknieë nie. Enigiemand wat die publieke adres kan bereik, kan 'n echo-versoek stuur terwyl die hek oop is. Die tonnel het nie die pad geword nie; die tonnel het die skakelaar geword.

Die mense wat dié idee bemark, lieg gewoonlik nie oor die effek wat hulle wou hê nie. Hulle het 'n kontrole nodig gehad wat net antwoord wanneer die skakel gesond is, en die skakel se gesondheid was die maklikste deur die VPN waar te neem. Die fout is om 'n beskikbaarheidsein as 'n toegangsbesluit te behandel en dit dan te outomatiseer.

Wat die hek werklik beheer

Twee onafhanklike dinge word deur hierdie ontwerp saamgegooi, en om hulle te skei is die grootste deel van die regmaak. Die eerste is omvang: watter plaaslike adres, watter afgeleë adresse, watter protokol en watter ICMP-tipe. Die tweede is voorwaarde: of die reëlvoorwerp op hierdie oomblik geaktiveer is. Omvang is wat 'n vuurmuur per pakkie evalueer; voorwaarde is wat 'n script in die beleidstoor skryf, en die twee word op heeltemal verskillende horlosies versoen.

As die vereiste werklik net VPN-eweknieë is, antwoord omvang dit sonder enige verbindingstoestand-logika: bind die reël aan die tonnelkoppelvlak of aan die tonnel-adresreeks, beperk die afgeleë adresse tot die kliëntpoel, en spesifiseer die echo-tipe eerder as “ICMP”. Dié reël bly korrek wanneer geen VPN aan is nie en kan nie deur 'n onverwante profiel oopgegooi word nie.

As die vereiste werklik 'n publieke hek is, sê dit dan in die beleidsteks, want die aanvaardingskriteria verander. 'n Publieke hek moet die presiese profiel noem, definieer wat gekoppel beteken, en verklaar dat publieke senders volgens ontwerp in omvang is. Die meeste verwarring verdwyn op die oomblik dat iemand gedwing word om daardie sin neer te skryf.

Bou die voorwerp een keer en skakel dit dan

Voorsien een reël vooraf met 'n stabiele identiteit, gedeaktiveer, en laat die beheerder slegs die geaktiveerde toestand daarvan verander. Om by elke lopie reëls volgens vertoonnaam te skep, is hoe 'n beleidstoor met vyf byna identiese voorwerpe en geen betroubare manier om hulle te verwyder, eindig.

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

Naam is die blywende identifiseerder; vertoonnaam is dokumentasie wat 'n mens mag wysig. Versoen teen -Name en die script hou op om duplikate te produseer. Dieselfde opdragvorm dek die IPv6-geval met -Protocol ICMPv6 -IcmpType 128, wat 'n aparte reël is omdat die echo-tipenommers tussen die twee families verskil.

Hou adresfamilie en ICMP-tipe eksplisiet om 'n tweede rede: -Protocol ICMPv4 sonder 'n tipe laat elke ICMPv4-boodskap toe wat die profiel permitteer, insluitend dié wat jy nooit bedoel het om te aanvaar nie. Om tipe 8 te noem, vernou die reël na echo-versoek, wat die enigste ding is wat 'n bereikbaarheidskontrole stuur.

Waar die outomatisering die bedoeling weerspreek

Om elke paar minute 'n kliëntprofiel te poll, kan nie 'n onmiddellike grens lewer nie. Tussen die verbinding wat val en die volgende poll antwoord die reël steeds op die publieke adres; tussen die verbinding wat opkom en die volgende poll doen dit nie. Om daardie vertraging te erken, is eerlik, en om te beweer dat die ontwerp 'n streng onveranderlike afdwing, is nie.

Daar is 'n omvangstrik in die toestandkontrole self. Get-VpnConnection rapporteer kliëntprofiele wat op die masjien opgestel is, by verstek vir die huidige gebruiker en vir alle gebruikers met -AllUserConnection. Dit rapporteer nie die afgeleë gebruikers wat tans by 'n RRAS-bediener ingeskakel is nie; dit is 'n ander waarneming met 'n ander cmdlet. 'n Hek wat op die verkeerde een gebou is, is aan niks gekoppel nie.

Dan moet die toestande gedek word wat niemand ge-script het nie: opstart met die reël wat reeds uit 'n vorige lopie geaktiveer is, 'n beheerder wat crash terwyl die hek oop is, en 'n profiel wat geskrap word terwyl sy reël lewendig bly. Elkeen het 'n gedefinieerde verstek nodig, en die veilige verstek vir 'n publieke toelating is gedeaktiveer. As die vereiste die poll-venster werklik nie kan verdra nie, is 'n toestandgebaseerde reël die verkeerde instrument en hoort die handhawing by die tonnel, nie by die publieke koppelvlak nie.

Toets laastens die publieke versoek twee keer, een keer met die gekose verbinding aan en een keer met dit af, vanaf 'n gasheer wat nie op die VPN is nie. 'n Suksesvolle ping van binne die tonnel toets niks oor hierdie beleid nie, en dit is die meting wat die meeste ontplooiings oorslaan.