Nessus prin VPN: unde să plasăm scanerul înainte de prima scanare

O pictogramă VPN lângă browser nu spune nimic despre procesul care trimite pachetele de scanare. Dacă consola și scanerul rulează pe gazde diferite, tunelul browserului este o cale, iar sursa scanării este alta. Începeți cu punctul de execuție, apoi mergeți spre exterior: ruta, autorizarea și acreditările. Această distincție este primul punct din listă dintr-un motiv.

Aceasta este o listă de verificare înainte de lansare, nu un tutorial de scanare. Fiecare pas produce un fapt pe care îl puteți consemna în evidența lucrării înainte ca vreun pachet să părăsească scanerul.

Prima verificare: localizați procesul care trimite sondele

Desenați explicit cele trei roluri: browserul pe laptopul A, consola de scanare pe gazda B și ținta privată C. Dacă B rulează și motorul de scanare, browserului îi trebuie doar o cale către B. Dacă munca o face un aparat de scanare separat, acel aparat are nevoie de calea către C.

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

Un browser conectat la VPN poate ajunge la consolă în timp ce scanerul din spate încă nu are rută către C. Este posibil și invers: scanerul este în rețeaua privată, iar consola este la distanță. Aflați ce configurație rulați de fapt înainte de a schimba vreun control de rețea. Numiți aparatul în configurația scanării înainte de a da vina pe rețea.

Dacă scanerul rulează pe A, gazda browserului și scanerul partajează un context, dar numai cât timp procesul păstrează același spațiu de nume și același tabel de rutare. Un container sau un cont de serviciu poate să nu moștenească ceea ce vede browserul interactiv. Consola este o suprafață de administrare, nu motorul de scanare.

A doua verificare: dovediți ruta și DNS-ul scanerului

Rulați verificarea rutei pe gazda scanerului, nu pe laptop. Întrebați nucleul ce interfață și ce poartă ar folosi pentru adresa țintei, apoi repetați pentru numele de gazdă al țintei. O rută care există pentru IP și un nume care se rezolvă la altă adresă sunt două defecțiuni diferite.

Confirmați adresa sursă care va apărea la țintă. Un client VPN poate atribui o adresă diferită de cea așteptată de firewallul țintei, iar un dispozitiv NAT o poate rescrie din nou. Proprietarul țintei are nevoie de sursa observată, nu de adresa tipărită în profilul VPN.

Verificați și calea de întoarcere. Un scaner care ajunge la țintă dar nu primește răspunsuri are o problemă de rutare sau de firewall pe drumul de întoarcere, iar asta arată identic cu o țintă căzută.

A treia verificare: obțineți autorizarea sferei și a punctului de vedere

Cereți proprietarului țintei să numească în scris sistemele, serviciile, mediul, sursa și fereastra de timp. Decideți ce punct de vedere reprezintă evaluarea: un utilizator VPN extern, un client intern admis sau un anumit segment de scaner.

O rută privată nu este permisiune de a testa rețelele adiacente. Țineți lista țintelor îngustă, enumerați sistemele excluse și conveniți condițiile de oprire și un contact care poate opri execuția. Scanerul sondează bucuros tot ce poate atinge, și exact de aceea sfera trebuie să fie explicită.

Consemnați sursa aprobată în același document. Dacă sursa observată a scanerului diferă de cea aprobată, execuția nu reprezintă punctul de vedere convenit, chiar și când lista țintelor este corectă.

A patra verificare: potriviți acreditările cu profunzimea evaluării

O verificare de accesibilitate și o evaluare autentificată sunt teste diferite. Un răspuns de port dovedește că ceva a răspuns; nu dovedește că verificările cu acreditări au rulat sau că aplicația a autorizat contul.

Folosiți acreditări dedicate doar când sfera convenită cere verificări autentificate. Confirmați permisiunile și politica de blocare a contului și decideți cum vor fi stocate și partajate constatările înainte ca scanarea să le producă.

Dacă acreditările eșuează, nu reveniți în tăcere la o execuție neautentificată și nu etichetați raportul drept evaluarea planificată. Rezultatul este un alt test cu altă semnificație, iar diferența aparține raportului.

A cincea verificare: salvați planul, apoi lansați deliberat

În fluxul de scanare Nessus, alegerea unui șablon, configurarea setărilor și salvarea sau lansarea scanării sunt pași separați. Folosiți această separare pentru a revizui lista țintelor, sursa și programul înainte de a începe orice trafic.

Înainte de a autoriza lansarea, verificați ce sursă permite VPN-ul, ce trafic transportă și cum se recuperează după un tunel căzut. Nu lărgi accesul prin firewall doar pentru că o conexiune preliminară a eșuat; găsiți stratul care a refuzat-o și reparați acel strat.

După execuție, consemnați gazda scanerului, sursa observată, lista țintelor și verificările care nu au putut fi finalizate. Un raport produs dintr-o altă sursă sau fără acreditările prevăzute nu reprezintă planul inițial, iar a spune asta face parte din livrabil.

Retrageți accesul pentru lucrare și tratați rezultatele păstrate conform procesului convenit. Lista de verificare este încheiată doar când dovezile corespund căii pe care ați aprobat-o, nu când scanarea a returnat pur și simplu rezultate.