Alarme të hyrjes në VPN: cili ngjarje duhet t'i aktivizojë ato në të vërtetë?
Suksesi i vërtetimit, një tunel i vendosur dhe një RADIUS accounting Start janë tre pretendime të ndryshme. Zgjidhni atë për të cilin marrësi juaj mund të veprojë dhe më pas i korreloni.
Suksesi i vërtetimit, një tunel i vendosur dhe një RADIUS accounting Start janë tre pretendime të ndryshme, dhe një email hyrjeje merr kuptim vetëm pasi zgjidhni një prej tyre. Shumica e modeleve të alarmeve VPN i përziejnë të tre dhe krijojnë një kuti postare që askush nuk e beson. Vendimi varet nga kush e lexon alarmin dhe çfarë mund të bëjë në pesë minutat e ardhshme. Nëse gaboni, alarmi kthehet në zhurmë që fsheh ngjarjen e vetme që ju duhej.
Tre pyetje vendosin aktivizuesin
Pyetni kush do ta marrë, çfarë do të bëjë dhe sa shpejt duhet të ndodhë veprimi. Një ekip sigurie që mbikëqyr keqpërdorimin e kredencialeve dëshiron një model dështimi dhe më pas suksesi nga një llogari brenda minutash. Një ekip operacionesh që mbikëqyr kapacitetin dëshiron kohëzgjatjen e sesionit dhe arsyet e shkëputjes, jo hyrjet. Një ndihmë desk dëshiron identitetin e sesionit për ta përputhur me një tiketë.
Këto përgjigje tregojnë ngjarje të ndryshme, dhe asnjë rregull i vetëm nuk i plotëson të treja. Nëse veprimi i marrësit është «telefono përdoruesin», vërtetimi mjafton. Nëse veprimi është «liro një licencë» ose «verifiko nëse tuneli transportoi trafik», vetëm vendosja ose accounting Start funksionon. Nëse veprimi është «fakturo kohën», ju nevojiten regjistrime Stop dhe jo një hyrje.
Shkruani përgjigjen si një fjali të vetme përpara se të konfiguroni ndonjë gjë. «Ky email i thotë inxhinierit të gatishmërisë se llogaria X hapi një tunel nga rrjeti Y në kohën Z, që ai të mund të kontrollojë nëse u përdor dritarja e mirëmbajtjes.» Nëse nuk mund të plotësoni çdo fushë, aktivizuesi nuk është zgjedhur ende.
Përputhni ngjarjen me pretendimin që bëni
| Record | What it proves | What it leaves open |
|---|---|---|
| Rejected credentials | The attempt failed at the credential step | Whether it was a stale client or a real person |
| Access-Accept | Credentials passed for this attempt | Anything about tunnel state or policy |
| Policy match record | A rule matched the request | Whether later steps completed |
| Tunnel established | The gateway accepted a session | Whether traffic flowed or the user got an address |
| Accounting Start | User service began at the accounting layer | Whether the application behind it worked |
| Accounting Stop | That session was closed, with a reason field | Whether the reason is meaningful on your release |
Tabela fsheh një varësi: çdo rresht është i besueshëm vetëm nëse porta e lëshon atë në mënyrë të besueshme dhe mbledhësi juaj ruan fushën që ju nevojitet. Lexoni përkufizimin e ngjarjes për versionin e saktë që ekzekutoni, sepse emri «sesion i vendosur» ndryshon midis versioneve dhe kuptimi ndryshon më shpesh se emri. Kur një përkufizim është i paqartë, kërkoni një regjistrim sesioni në vend që të hamendësoni nga etiketa.
Trajtimi i një Access-Accept si përfundimi i çdo gjëje që vjen pas është gabimi më i zakonshëm. Është një verdikt për kredencialet, jo një sesion. Gabimi i pasqyruar është të lexosh një përputhje politike si provë autorizimi, kur një rregull mund të përputhet dhe hapi tjetër mund të dështojë gjithsesi.
Një sesion, një njoftim
Një llogari, disa pajisje, ridërgime dhe rilidhje: një email për çdo ngjarje do të jetë i gabuar në të dyja drejtimet, duke dublikuar një sesion ndërsa ndan një tjetër. Bëjeni çelësin e njoftimit portën plus një identifikues sesioni, dhe trajtoni emrin e llogarisë si atribut dhe jo si çelës. Një përdorues me laptop dhe telefon mund të mbajë dy tunele njëkohësisht, dhe të dyja meritojnë rreshtin e vet.
Regjistrimet kontabël të ridërguara janë normale, prandaj hiqni dublikatat sipas id-së së sesionit dhe vulës kohore përpara se të paraqisni mesazhin. Sesionet e njëpasnjëshme nga e njëjta pajisje duhet të mbeten të ndara, dhe një rilidhje gjatë një dritareje mirëmbajtjeje duhet të mbetet e dukshme në vend që të bashkohet me të mëparshmen. Nëse mbledhësi juaj i rishkruan vulat kohore gjatë marrjes, hiqni dublikatat sipas fushave të regjistrimit origjinal, jo atyre të ruajtura.
Një regjistrim Stop që mungon është pasiguri, jo një sesion i përhershëm. Rindezjet e portës, ndërprerjet e mbledhësit dhe humbja e UDP lënë boshllëqe, prandaj alarmi ka nevojë për një rrugë rakordimi që pyet tabelën e sesioneve aktive përpara se dikush të konkludojë se një tunel është ende aktiv.
Mbani audimin dhe njoftimin të ndara
Rrjedha e audimit dhe rrjedha e alarmeve kanë detyra të ndryshme. Ruani regjistrimet e papërpunuara, duke përfshirë llogarinë, portën, id-në e sesionit, vulat kohore dhe arsyen e përfundimit, edhe kur email-et rutinë grupohen, shtypen ose dërgohen në një listë të vogël gatishmërie. Një prag ashpërsie është filtër dorëzimi, jo një zgjedhje e ngjarjes së ciklit të jetës që donit të shpallnit.
Dërgoni kontekstin minimal që i nevojitet marrësit për të gjetur regjistrimin e mbrojtur. Emrat e llogarive, adresat e brendshme dhe detajet e sesionit janë të ndjeshme, dhe një email që përcillet mirë është një email që rrjedh mirë.
Më pas provojeni nga fillimi në fund. Kryeni një hyrje dhe dalje normale, një rilidhje, dy sesione njëkohësisht dhe një dështim të detyruar dorëzimi, dhe gjurmoni një ngjarje nga porta përmes mbledhësit deri te mesazhi i dorëzuar. Nëse email-i arrin pa id sesioni, kontrata është e paplotë. Nëse dy email-e përshkruajnë një sesion, korrelacioni është i prishur. Asnjëri prej problemeve nuk shfaqet kur e vetmja gjë që testoni është se dorëzimi i postës funksionon.