NPS grupas politika nav VPN resursu izpilde

Divas grupas, divi piekļuves profili, viena VPN vārteja, un galu galā abas grupas sasniedz tos pašus serverus. Parastais iemesls nav salauzta politika, bet gan trūkstoša otrā dizaina puse: NPS izlemj, kas drīkst izveidot sesiju, un kaut kam citam jāizlemj, ko šī sesija drīkst sasniegt. Ja pastāv tikai pirmā puse, autorizācija izdodas ikvienam, kurš autentificējas. Politika dara savu darbu, un dizains joprojām ir nepilnīgs.

Grupai atbilstoša tīkla politika ir pierādījums par pielaišanu. Tas nav pierādījums par paketēm, un plaisa starp šiem diviem apgalvojumiem ir vieta, kur notiek lielākā daļa šī darba.

Atrodiet politiku, kas sesiju patiešām pielaida

NPS izvērtē sakārtotas tīkla politikas, un uzvar pirmais iespējotais noteikums, kura nosacījumi atbilst. Nosacījumi var ietvert lietotāja vai datora grupas dalību, savienojuma veidu, laiku un ierīces stāvokli. Tāpēc plaša politika, kas sarakstā atrodas agrāk, pielaiž savienojumu, pirms šaurāks noteikums zemāk vispār tiek izskatīts. Secība nav saskarnes detaļa; secība ir politika.

Izlasiet sarakstu secībā un nosakiet atbilstošo, pēc tam pierakstiet, kādus iestatījumus tā atgrieza. Grupas nosaukums redaktorā nav rezultāts; rezultāts ir autorizācija, ko serveris saņēma. Turiet lietotāja autorizāciju un ierīces autorizāciju atsevišķi tur, kur izvietojums izmanto abas, jo konts, kuram drīkst atvērt tuneli, nav automātiski konts, kuram vajadzētu sasniegt katru iekšējo pakalpojumu.

RADIUS atbilde ir norādījums, nevis filtrs

Filter-Id atribūts nes filtra saraksta nosaukumu. Tas nepiegādā pārvietojamu pakešu filtrēšanas noteikumu kopu, ko saprastu ikviens uztvērējs, un nosaukuma, ko vārteja nekad nav definējusi, sūtīšana neizpilda pilnīgi neko. Tāda pati piesardzība attiecas uz VLAN atribūtiem: tuneļa sesijas piešķiršana VLAN pati par sevi nav maršrutēta piekļuves noteikums šim lietotājam.

Šeit NPS pusē pilnīgs izskatāms dizains klusi nedara neko. Apstipriniet vārtejas piegādātāja dokumentācijā, kuri autorizācijas atribūti tiek atbalstīti un ko uztvērējs dara ar katru, tā vietā lai pieņemtu, ka standarta atribūta nosaukums nozīmē standarta uzvedību.

Novietojiet izpildi tur, kur plūst trafiks

Vārteja, kas apstrādā lietotāja paketes, var piemērot filtru katrai sesijai, kartēt grupu uz vārtejas politiku vai piešķirt sesijai adresi no atsevišķa pūla, ko ugunsmūris uztver citādi. Jebkurš no šiem var darboties, un tie neizdodas dažādos veidos. Nosakiet, kuru mehānismu jūsu vārteja atbalsta, pirms rakstāt politiku, kas to nosauc. Pēc tam pierakstiet, kas notiek ar sesiju, kad šī mehānisma nav, jo klusums ir noklusējums.

Aprakstiet paredzēto atļauju četrās daļās: avota identitāte vai grupa, galamērķis, protokols un ports. Pievienojiet atkarības, kas lietotājam patiešām vajadzīgas, piemēram, DNS vai autentifikācijas pakalpojumu, citādi ierobežojums salauzīs pieteikšanās plūsmas, kuras neviens nebija iedomājies pārbaudīt. Rakstiet noteikumu pret saskarni, kas patiešām filtrē, nevis pret saskarni, kas nejauši ir atvērta redaktorā.

Ņemiet vērā arī adrešu tulkošanu. Ja ugunsmūris lejāk redz vienu tulkotu avota adresi katram tuneļa lietotājam, tas nevar atšķirt indivīdus tikai pēc šīs adreses, un noteikums, kas rakstīts tā, it kā varētu, būs vai nu bezjēdzīgs, vai pārāk plašs.

Klienta profili dzīvo neuzticamajā pusē

Pārvaldīts VPN profils var virzīt maršrutus, sadalītā tuneļa noteikumus vai lietojumprogrammu filtrus, un tie veido, kā uzvedas labi audzināta ierīce. Tie nav pakalpojuma aizsardzība, jo klients ir tā puse, kuru jūs cenšaties ierobežot. Maršruta noņemšana profilā arī nav autorizācija, jo klientam var būt cits ceļš uz to pašu galamērķi.

Uztveriet klienta iestatījumus kā ērtību, bet vārtejas iestatījumus kā kontroli. Kad abi nesaskan, vārtejai ir taisnība, jo tā ir tā, kas redz paketes.

Pieņemiet ar diviem kontiem, pēc tam sekojiet secībā

Izveidojiet divus parastus testa kontus ar atšķirīgām paredzētām atļaujām, izveidojiet jaunas sesijas un pārbaudiet katra efektīvo vārtejas politiku. Pēc tam pārbaudiet vienu nekaitīgu atļautu darbību un vienu konkrēti aizliegtu resursu. Neizdevies ping pats par sevi pierāda ļoti maz, jo ICMP var būt filtrēts, kamēr TCP pakalpojums aiz tā labprāt atbild.

Kad abi konti joprojām iegūst plašu piekļuvi, sekojiet noteiktā secībā: kura politika atbilda, kādu autorizāciju nesa atbilde un ko vārteja ar to izdarīja. Vairāk NPS atribūtu pievienošana pirms apstiprinājuma, ka uztvērējs tos ievieš, ir ceļš, kā maza autorizācijas problēma pārvēršas izmaiņu logā bez rezultāta.