Ang tagumpay ng pagpapatotoo, isang naitatag na tunnel at isang RADIUS accounting Start ay tatlong magkakaibang pahayag, at ang email ng pag-login ay may kahulugan lamang kapag pumili ka ng isa sa mga ito. Karamihan sa mga disenyo ng alerto sa VPN ay hinahalo ang tatlo at gumagawa ng inbox na walang pinagkakatiwalaan. Nakasalalay ang desisyon sa kung sino ang nagbabasa ng alerto at ano ang kaya niyang gawin sa susunod na limang minuto. Kapag nagkamali, ang alerto ay nagiging ingay na nagtatago sa nag-iisang kaganapang kailangan mo.

Tatlong tanong ang nagtatakda ng trigger

Itanong kung sino ang tatanggap, ano ang gagawin at gaano kabilis dapat mangyari ang aksyon. Ang isang pangkat ng seguridad na nagmamatyag sa maling paggamit ng mga kredensyal ay gustong makita ang pattern ng pagpalya at pagkatapos ay tagumpay mula sa isang account sa loob ng ilang minuto. Ang pangkat ng operasyon na nagmamatyag sa kapasidad ay gustong makuha ang haba ng sesyon at mga dahilan ng paghinto, hindi ang mga pag-login. Ang helpdesk ay gustong makuha ang pagkakakilanlan ng sesyon para maitugma ito sa isang tiket.

Ang mga sagot na iyon ay tumuturo sa magkakaibang kaganapan, at walang nag-iisang patakaran ang makakasapat sa tatlo. Kung ang aksyon ng tatanggap ay «tawagan ang gumagamit», sapat na ang pagpapatotoo. Kung ang aksyon ay «magpalaya ng lisensya» o «tiyakin na may dala ang tunnel na trapiko», ang pagtatatag o accounting Start lamang ang gagana. Kung ang aksyon ay «isisingil ang oras», kailangan mo ng mga talaan ng Stop at hindi ng pag-login.

Isulat ang sagot sa isang pangungusap bago mag-configure ng anuman. «Sinasabi ng email na ito sa naka-duty na inhinyero na nagbukas ng tunnel ang account X mula sa network Y sa oras na Z, para masuri niya kung ginamit ang maintenance window.» Kung hindi mo kayang punan ang bawat puwang, hindi pa napipili ang trigger.

Itugma ang kaganapan sa pahayag na ginagawa mo

RecordWhat it provesWhat it leaves open
Rejected credentialsThe attempt failed at the credential stepWhether it was a stale client or a real person
Access-AcceptCredentials passed for this attemptAnything about tunnel state or policy
Policy match recordA rule matched the requestWhether later steps completed
Tunnel establishedThe gateway accepted a sessionWhether traffic flowed or the user got an address
Accounting StartUser service began at the accounting layerWhether the application behind it worked
Accounting StopThat session was closed, with a reason fieldWhether the reason is meaningful on your release

May itinatagong dependency ang talahanayan: ang bawat hilera ay mapagkakatiwalaan lamang kung matatag itong inilalabas ng gateway at pinapanatili ng iyong kolektor ang field na kailangan mo. Basahin ang depinisyon ng kaganapan para sa eksaktong release na pinapatakbo mo, dahil nagbabago ang pangalang «sesyon naitatag» sa pagitan ng mga bersyon at ang kahulugan ay mas madalas pang magbago kaysa sa pangalan. Kapag malabo ang depinisyon, humingi ng session capture sa halip na manghula mula sa label.

Ang ituring ang isang Access-Accept bilang pagkumpleto ng lahat ng sumusunod dito ay ang pinakakaraniwang pagkakamali. Berdikto ito sa mga kredensyal, hindi isang sesyon. Ang salamin ng pagkakamaling iyon ay ang basahin ang tugma ng patakaran bilang patunay ng awtorisasyon, gayong maaaring tumugma ang isang patakaran at maaari pa ring mabigo ang susunod na hakbang.

Isang sesyon, isang abiso

Isang account, maraming aparato, mga muling pagpapadala at mga muling pagkonekta: ang isang email kada kaganapan ay mali sa dalawang direksyon, dinodoble ang isang sesyon habang hinahati ang isa pa. Gawing susi ng abiso ang gateway kasama ang identifier ng sesyon, at ituring ang pangalan ng account bilang katangian at hindi susi. Ang gumagamit na may laptop at telepono ay maaaring may dalawang tunnel nang sabay, at pareho silang karapat-dapat sa sariling linya.

Normal ang mga muling ipinadalang talaan ng accounting, kaya alisin ang mga doble ayon sa id ng sesyon at timestamp bago i-render ang mensahe. Ang magkakasunod na sesyon mula sa parehong aparato ay dapat manatiling hiwalay, at ang muling pagkonekta habang may maintenance window ay dapat manatiling nakikita sa halip na mahulog sa nauna. Kung ang kolektor mo ay nagsusulat muli ng mga timestamp sa pag-ingest, alisin ang mga doble ayon sa mga field ng orihinal na talaan, hindi sa mga naka-store.

Ang kulang na talaang Stop ay kawalan ng katiyakan, hindi permanenteng sesyon. Ang mga reboot ng gateway, pagpalya ng kolektor at pagkawala ng UDP ay pawang nag-iiwan ng butas, kaya kailangan ng alerto ang daan ng pagkakasundo na nagtatanong sa live session table bago magpasya ang sinuman na buhay pa ang tunnel.

Paghiwalayin ang audit at ang abiso

Magkaiba ang trabaho ng audit stream at ng alert stream. Itago ang mga raw record, kasama ang account, gateway, id ng sesyon, mga timestamp at dahilan ng pagtatapos, kahit na ang mga regular na email ay pinagsama, sinupil o ipinadala sa maliit na duty list. Ang threshold ng tindi ay filter ng paghahatid, hindi pagpili ng kaganapan sa lifecycle na nais mong ipahayag.

Ipadala ang pinakamababang kontekstong kailangan ng tatanggap para mahanap ang protektadong talaan. Ang mga pangalan ng account, panloob na address at detalye ng sesyon ay sensitibo, at ang email na madaling ma-forward ay email na madaling tumagas.

Pagkatapos ay patunayan ito mula simula hanggang wakas. Magpatakbo ng normal na pag-login at pag-logout, isang muling pagkonekta, dalawang sabay na sesyon at isang sapilitang pagpalya ng paghahatid, at subaybayan ang isang kaganapan mula sa gateway sa pamamagitan ng kolektor hanggang sa naihatid na mensahe. Kung dumating ang email na walang id ng sesyon, kulang ang kontrata. Kung dalawang email ang naglalarawan ng isang sesyon, sira ang korelasyon. Wala sa dalawang problemang iyon ang lumalabas kapag ang tanging sinusubok mo ay gumagana ang paghahatid ng mail.

Kaugnay na mga artikulo