Kvifor ei brannmurport bunden til VPN-tilstand ikkje er ein regel om ping berre gjennom tunnelen

Sjå føre deg ein brannmurregel som slår på ICMP echo for den offentlege adressa til tenaren kvar gong ein namngjeven VPN-profil er tilkopla. Det blir lese som «ping berre gjennom tunnelen», og den lesinga er feil på ein måte som tel. Regelen avgrensar ikkje kven som kan nå verten; han endrar kva det offentlege grensesnittet svarar på medan ei anna tilkopling tilfeldigvis er oppe. Det er to ulike politikkar, og ein av dei utvidar eksponeringa i det stille.

Regelen du trur du skreiv

Det tiltenkte kravet er vanlegvis smalt: overvakingssystemet, eller den eine administratoren på VPN-en, skal kunne stadfeste at tenaren lever. Skriven som ei setning høyrest han ut som tilgangskontroll på tunnelen. Skriven som eit brannmurobjekt blir han eit vilkår på den offentlege profilen, fordi det er der echo-førespurnaden kjem inn.

Når vilkåret er ein tilkoplingstilstand i staden for ei kjeldeadresse, er settet med tillatne avsendarar ikkje lenger VPN-peer-settet. Alle som kan nå den offentlege adressa, kan sende ein echo-førespurnad medan porten er open. Tunnelen vart ikkje vegen; tunnelen vart brytaren.

Folka bak ideen lyg vanlegvis ikkje om effekten dei ville ha. Dei trong ein sjekk som berre svarar når lenkja er sunn, og helsa til lenkja var lettast å observere gjennom VPN-en. Feilen er å handsame eit tilgjengelegheitssignal som ei tilgangsavgjerd og deretter automatisere det.

Kva porten faktisk styrer

Dette designet smeltar saman to uavhengige ting, og å skilje dei er det meste av rettinga. Det første er omfang: kva lokal adresse, kva fjerne adresser, kva protokoll og kva ICMP-type. Det andre er vilkår: om regelobjektet er aktivert i dette augneblinken. Omfang er det ein brannmur vurderer per pakke; vilkår er det eit skript skriv i politikkarkivet, og dei to blir avstemde på heilt ulike klokker.

Viss kravet verkeleg berre er VPN-peers, svarar omfanget på det utan nokon logikk for tilkoplingstilstand: bind regelen til tunnelgrensesnittet eller til adresseområdet til tunnelen, avgrens dei fjerne adressene til klientbassenget, og oppgi echo-typen i staden for «ICMP». Den regelen held seg korrekt når ingen VPN er oppe, og kan ikkje opnast av ein uvedkomande profil.

Viss kravet verkeleg er ein offentleg port, sei det i politikkteksten, fordi akseptkriteria endrar seg. Ein offentleg port må namngje den nøyaktige profilen, definere kva «tilkopla» tyder, og erklære at offentlege avsendarar er i omfanget etter design. Det meste av forvirringa forsvinn i det augneblinken nokon blir tvinga til å skrive ned den setninga.

Bygg objektet éin gong, og skift det så

Klargjer éin regel med ein stabil identitet, deaktivert, og la kontrolløren endre berre den aktiverte tilstanden hans. Å opprette reglar etter visingsnamn ved kvar køyring er korleis eit politikkarkiv endar med fem nesten identiske objekt og ingen påliteleg måte å fjerne dei 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

Namnet er den varige identifikatoren; visingsnamnet er dokumentasjon som eit menneske kan redigere. Avstem mot -Name, og skriptet sluttar å lage duplikat. Same kommandoform dekkjer IPv6-tilfellet med -Protocol ICMPv6 -IcmpType 128, men det er ein eigen regel fordi echo-typenumra er ulike i dei to familiane.

Hald adressefamilie og ICMP-type eksplisitte av ein annan grunn: -Protocol ICMPv4 utan type tillèt kvar ICMPv4-melding som profilen tillèt, inkludert dei du aldri meinte å godta. Å namngje type 8 snevrar regelen inn til echo-førespurnad, som er det einaste ein tilgjengelegheitssjekk sender.

Der automatiseringa motseier hensikta

Avstemming av ein klientprofil kvart par minutt kan ikkje gje ei umiddelbar grense. Mellom tilkoplinga som fell og neste avstemming svarar regelen framleis på den offentlege adressa; mellom tilkoplinga som kjem opp og neste avstemming gjer han det ikkje. Å innrømme den forseinkinga er ærleg, og å hevde at designet handhevar ein streng invariant er det ikkje.

Det er ei omfangsfelle i sjølve tilstandssjekken. Get-VpnConnection rapporterer klientprofilar som er konfigurerte på maskinen, som standard for gjeldande brukar og for alle brukarar med -AllUserConnection. Han rapporterer ikkje fjernbrukarane som nett no er innringde til ein RRAS-tenar; det er ei anna observasjon med ein annan kommando. Ein port bygd på den gale er ikkje kopla til noko.

Deretter dekkjer du tilstandane ingen skriptar: oppstart med regelen allereie aktivert frå ei tidlegare køyring, kontrollørkrasj medan porten er open, og ein profil sletta medan regelen hans framleis lever. Kvar treng ein definert standard, og den trygge standarden for ei offentleg løyve er deaktivert. Viss kravet verkeleg ikkje toler avstemmingsvindauget, er ein tilstandsstyrt regel feil verktøy, og handhevinga høyrer til tunnelen, ikkje til det offentlege grensesnittet.

Til slutt, test den offentlege førespurnaden to gonger, éin gong med den valde tilkoplinga oppe og éin gong med ho nede, frå ein vert som ikkje er på VPN-en. Ein vellukka ping innanfrå tunnelen beviser ingenting om denne politikken, og det er målinga dei fleste utrullingar hoppar over.