NPS-groepsbeleid is geen handhaving van VPN-resources

Twee groepen, twee toegangsprofielen, één VPN-gateway, en uiteindelijk bereiken beide groepen dezelfde servers. De gebruikelijke oorzaak is geen kapot beleid maar een ontbrekende tweede helft van het ontwerp: NPS bepaalt wie een sessie mag opzetten, en iets anders moet bepalen wat die sessie mag bereiken. Als alleen de eerste helft bestaat, slaagt de autorisatie voor iedereen die zich authenticeert. Het beleid doet zijn werk, en het ontwerp is nog steeds onvolledig.

Een netwerkbeleid dat bij een groep past, is bewijs over toelating. Het is geen bewijs over pakketten, en de kloof tussen die twee uitspraken is waar het grootste deel van dit werk gebeurt.

Vind het beleid dat de sessie werkelijk toeliet

NPS evalueert geordende netwerkbeleidsregels, en de eerste ingeschakelde regel waarvan de voorwaarden overeenkomen, wint. Voorwaarden kunnen groepslidmaatschap van gebruiker of computer, verbindingstype, tijd en apparaatstatus omvatten. Een breed beleid dat eerder in de lijst staat, laat een verbinding dus toe voordat een smallere regel verderop überhaupt wordt bekeken. De volgorde is geen detail van de interface; de volgorde is het beleid.

Lees de lijst op volgorde en bepaal welke overeenkwam, en noteer vervolgens welke instellingen die teruggaf. De groepsnaam in de editor is niet het resultaat; het resultaat is de autorisatie die de server ontving. Houd gebruikerautorisatie en apparaatautorisatie gescheiden waar de uitrol beide gebruikt, want een account dat een tunnel mag openen, is niet automatisch een account dat elke interne dienst zou moeten bereiken.

Het RADIUS-antwoord is een instructie, geen filter

Een Filter-Id-kenmerk draagt de naam van een filterlijst. Het levert geen overdraagbare set pakketfilterregels die elke ontvanger begrijpt, en een naam sturen die de gateway nooit heeft gedefinieerd, handhaaft helemaal niets. Dezelfde voorzichtigheid geldt voor VLAN-kenmerken: een tunnelsessie aan een VLAN toewijzen is op zichzelf geen gerouteerde toegangsregel voor die gebruiker.

Hier doet een ontwerp dat aan de NPS-kant compleet lijkt, stilzwijgend niets. Bevestig met de documentatie van de gatewayleverancier welke autorisatiekenmerken worden ondersteund en wat de ontvanger met elk ervan doet, in plaats van aan te nemen dat een standaardkenmerknaam standaardgedrag betekent.

Plaats de handhaving waar het verkeer langskomt

Een gateway die de pakketten van de gebruiker verwerkt, kan een filter per sessie toepassen, een groep aan een gatewaybeleid koppelen, of de sessie een adres geven uit een afgescheiden pool die een firewall anders behandelt. Elk daarvan kan werken, en ze falen op verschillende manieren. Bepaal welk mechanisme uw gateway ondersteunt voordat u het beleid schrijft dat het benoemt. Schrijf daarna op wat er met een sessie gebeurt als dat mechanisme ontbreekt, want stilte is de standaard.

Beschrijf de beoogde toestemming in vier delen: bronidentiteit of groep, bestemming, protocol en poort. Voeg de afhankelijkheden toe die de gebruiker echt nodig heeft, zoals DNS of een authenticatiedienst, anders breekt de beperking loginstromen die niemand bedacht had te testen. Schrijf de regel tegen de interface die werkelijk filtert, niet tegen de interface die toevallig openstaat in de editor.

Houd ook rekening met vertaling. Als een firewall verderop één vertaald bronadres ziet voor elke tunnelgebruiker, kan die individuen niet alleen aan dat adres onderscheiden, en een regel die is geschreven alsof dat wel kan, is of nutteloos of te breed.

Cliëntprofielen leven aan de niet-vertrouwde kant

Een beheerd VPN-profiel kan routes, regels voor gesplitste tunnel of applicatiefilters pushen, en die vormen hoe een welopgevoed apparaat zich gedraagt. Ze zijn geen bescherming voor de dienst, want de cliënt is de partij die u probeert te beperken. Een route in een profiel verwijderen is ook geen autorisatie, omdat een cliënt een andere weg naar dezelfde bestemming kan hebben.

Behandel cliëntinstellingen als gemak en gatewayinstellingen als controle. Als de twee het oneens zijn, heeft de gateway gelijk, want die is degene die de pakketten ziet.

Accepteer met twee accounts en volg dan op volgorde

Maak twee gewone testaccounts met verschillende beoogde rechten, zet nieuwe sessies op en controleer het effectieve gatewaybeleid voor elk. Test daarna één onschuldige toegestane handeling en één specifiek geweigerde resource. Een mislukte ping bewijst op zichzelf heel weinig, omdat ICMP gefilterd kan zijn terwijl de TCP-dienst erachter vrolijk antwoordt.

Als beide accounts nog steeds brede toegang krijgen, volg dan in vaste volgorde: welk beleid overeenkwam, welke autorisatie het antwoord droeg en wat de gateway ermee deed. Meer NPS-kenmerken toevoegen voordat u bevestigt dat de ontvanger ze implementeert, is hoe een klein autorisatieprobleem een wijzigingsvenster zonder resultaat wordt.