Nessus sa ibabaw ng VPN: saan ilalagay ang scanner bago ang unang scan

Ang icon ng VPN sa tabi ng browser ay walang sinasabi tungkol sa prosesong nagpapadala ng mga packet ng scan. Kung tumatakbo ang console at scanner sa magkaibang host, ang tunnel ng browser ay isang landas at ang pinagmulan ng scan ay iba. Magsimula sa punto ng pagpapatupad, pagkatapos ay lumabas: ruta, awtorisasyon at mga kredensyal. Ang pagkakaibang ito ang unang aytem sa listahan sa isang dahilan.

Ito ay checklist bago ilunsad, hindi tutorial sa pag-scan. Bawat hakbang ay gumagawa ng katotohanang maaari mong itala sa rekord ng trabaho bago pa man umalis ang anumang packet sa scanner.

Unang pagsusuri: hanapin ang prosesong nagpapadala ng mga probe

Iguhit nang malinaw ang tatlong papel: ang browser sa laptop A, ang scan console sa host B at ang pribadong target C. Kung tumatakbo rin sa B ang scan engine, kailangan lang ng browser ng landas papuntang B. Kung hiwalay na appliance ng scan ang gumagawa, kailangan ng appliance na iyon ng landas papuntang C.

Browser on laptop A -> console on host B
Scanner process on B (or another appliance) -> private target C

Ang browser na nakakonekta sa VPN ay maaaring umabot sa console habang ang scanner sa likod nito ay wala pang ruta papuntang C. Posible rin ang kabaligtaran: nasa loob ng pribadong network ang scanner at malayo ang console. Alamin kung aling kaayusan ang talagang pinapatakbo mo bago baguhin ang anumang kontrol ng network. Pangalanan ang appliance sa configuration ng scan bago sisihin ang network.

Kung tumatakbo ang scanner sa A, nagbabahagi ng konteksto ang host ng browser at ang scanner, pero hanggang lang hawak ng prosesong iyon ang parehong namespace at routing table. Maaaring hindi mamana ng container o service account ang nakikita ng interactive na browser. Ang console ay surface ng pamamahala, hindi ang scan engine.

Ikalawang pagsusuri: patunayan ang ruta at DNS ng scanner

Patakbuhin ang pagsusuri ng ruta sa host ng scanner, hindi sa laptop. Tanungin ang kernel kung aling interface at gateway ang gagamitin para sa address ng target, pagkatapos ay ulitin para sa hostname ng target. Ang rutang umiiral para sa IP at ang pangalang nagre-resolve sa ibang address ay dalawang magkaibang pagkabigo.

Kumpirmahin ang source address na lilitaw sa target. Maaaring magbigay ang VPN client ng address na iba sa inaasahan ng firewall ng target, at maaaring isulat muli ito ng NAT device. Kailangan ng may-ari ng target ang naobserbahang source, hindi ang address na nakalimbag sa profile ng VPN.

Suriin din ang pabalik na landas. Ang scanner na umabot sa target pero walang natatanggap na sagot ay may problema sa routing o firewall sa pabalik na landas, at kamukhang-kamukha ito ng target na down.

Ikatlong pagsusuri: kunin ang awtorisasyon sa saklaw at pananaw

Hilingin sa may-ari ng target na isulat ang mga sistema, serbisyo, environment, source at time window. Magpasya kung aling pananaw ang kinakatawan ng assessment: panlabas na user ng VPN, pinapayagang internal na client o partikular na segment ng scanner.

Ang pribadong ruta ay hindi pahintulot na subukan ang katabing network. Panatilihing makitid ang listahan ng target, ilista ang mga ibinukod na sistema at magkasundo sa mga kondisyon ng paghinto at sa contact na makapagpapahinto ng pagtakbo. Masaya ang scanner na susuriin ang lahat ng maaabot nito, at iyon mismo ang dahilan kung bakit dapat tahasan ang saklaw.

Itala ang inaprubahang source sa parehong dokumento. Kung ang naobserbahang source ng scanner ay naiiba sa inaprubahan, hindi kinakatawan ng pagtakbo ang napagkasunduang pananaw kahit tama ang listahan ng target.

Ikaapat na pagsusuri: itugma ang mga kredensyal sa lalim ng assessment

Ang pagsusuri ng maabot at ang authenticated na assessment ay magkaibang test. Ang sagot ng port ay patunay na may sumagot; hindi ito patunay na tumakbo ang mga pagsusuring may kredensyal o na inawtorisa ng application ang account.

Gumamit ng mga dedikadong kredensyal lamang kapag hinihingi ng napagkasunduang saklaw ang authenticated na pagsusuri. Kumpirmahin ang mga permiso at lockout policy ng account, at magpasya kung paano itatago at ibabahagi ang mga natuklasan bago pa ito gawin ng scan.

Kung mabigo ang mga kredensyal, huwag tahimik na lumipat sa pagtakbo na walang authentication at huwag tawagin ang ulat na planong assessment. Ang resulta ay ibang test na may ibang kahulugan, at ang pagkakaibang iyon ay bahagi ng ulat.

Ikalimang pagsusuri: i-save ang plano, pagkatapos ay sadyang ilunsad

Sa workflow ng scan ng Nessus, ang pagpili ng template, pag-configure ng mga setting at pag-save o paglunsad ng scan ay hiwalay na hakbang. Gamitin ang paghihiwalay na iyon para repasuhin ang listahan ng target, source at iskedyul bago magsimula ang anumang trapiko.

Bago awtorisahin ang paglunsad, suriin kung aling source ang pinapayagan ng VPN, anong trapiko ang dinadala nito at paano ito bumabawi mula sa putol na tunnel. Huwag palawakin ang access sa firewall dahil lang nabigo ang isang paunang koneksyon; hanapin ang layer na tumanggi dito at ayusin ang layer na iyon.

Pagkatapos ng pagtakbo, itala ang host ng scanner, ang naobserbahang source nito, ang listahan ng target at ang anumang pagsusuring hindi natapos. Ang ulat na ginawa mula sa ibang source o walang inaasahang kredensyal ay hindi kumakatawan sa orihinal na plano, at bahagi ng deliverable ang sabihin iyon.

Alisin ang access para sa trabaho at pangasiwaan ang mga itinatagong resulta ayon sa napagkasunduang proseso. Tapos lang ang checklist kapag tumutugma ang ebidensya sa landas na inaprubahan mo, hindi kapag nagbalik lang ng resulta ang scan.