Nessus via VPN: waar de scanner moet staan vóór de eerste scan

Een VPN-pictogram naast de browser zegt niets over het proces dat de scanpakketten verstuurt. Als de console en de scanner op verschillende hosts draaien, is de tunnel van de browser het ene pad en de bron van de scan het andere. Begin bij het uitvoeringspunt en werk naar buiten toe: de route, de autorisatie en de inloggegevens. Die scheiding staat niet voor niets bovenaan de checklist.

Dit is een checklist vóór de start, geen scantutorial. Elke stap levert een feit op dat je in het opdrachtverslag kunt vastleggen voordat er ook maar één pakket de scanner verlaat.

Punt één: lokaliseer het proces dat de probes verstuurt

Teken de drie rollen expliciet: de browser op laptop A, de scanconsole op host B en het private doel C. Draait op B ook de scanengine, dan heeft de browser alleen een pad naar B nodig. Doet een aparte scanner-appliance het werk, dan heeft die appliance het pad naar C nodig.

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

Een browser die met de VPN is verbonden, kan de console bereiken terwijl de scanner erachter nog geen route naar C heeft. Het omgekeerde kan ook: de scanner zit in het private netwerk en de console is op afstand. Zoek uit welke opstelling je werkelijk draait voordat je een netwerkbeheer aanpast. Benoem de appliance in de scanconfiguratie voordat je het netwerk de schuld geeft.

Draait de scanner op A, dan delen de browserhost en de scanner een context, maar alleen zolang dat proces dezelfde namespace en dezelfde routingtabel behoudt. Een container of een serviceaccount erft mogelijk niet wat de interactieve browser ziet. De console is een beheeromgeving, niet de scanengine.

Punt twee: bewijs de route en DNS van de scanner

Voer de routecontrole uit op de scannerhost, niet op de laptop. Vraag de kernel welke interface en gateway hij voor het doeladres zou gebruiken en herhaal dat voor de hostnaam van het doel. Een route die voor het IP bestaat en een naam die naar een ander adres verwijst, zijn twee verschillende storingen.

Bevestig het bronadres dat bij het doel zal verschijnen. Een VPN-client kan een ander adres toekennen dan de firewall van het doel verwacht, en een NAT-apparaat kan het opnieuw herschrijven. De eigenaar van het doel heeft de waargenomen bron nodig, niet het adres dat in het VPN-profiel staat.

Controleer ook het retourpad. Een scanner die het doel bereikt maar geen antwoorden ontvangt, heeft een routerings- of firewallprobleem op de terugweg, en dat ziet er precies zo uit als een doel dat plat ligt.

Punt drie: laat scope en gezichtspunt autoriseren

Laat de eigenaar van het doel de systemen, diensten, omgeving, bron en het tijdvenster schriftelijk benoemen. Bepaal welk gezichtspunt de beoordeling vertegenwoordigt: een externe VPN-gebruiker, een toegelaten interne client of een specifiek scannersegment.

Een private route is geen toestemming om aangrenzende netwerken te testen. Houd de doellijst klein, vermeld uitgesloten systemen en spreek stopvoorwaarden af plus een contactpersoon die de run kan stoppen. De scanner probeert graag alles wat hij kan bereiken, en juist daarom moet de scope expliciet zijn.

Leg de goedgekeurde bron in hetzelfde document vast. Wijkt de waargenomen bron van de scanner af van de goedgekeurde, dan vertegenwoordigt de run niet het afgesproken gezichtspunt, ook al is de doellijst correct.

Punt vier: stem inloggegevens af op de diepgang van de beoordeling

Een bereikbaarheidscontrole en een geauthenticeerde beoordeling zijn verschillende tests. Een poortantwoord bewijst dat er iets antwoordde; het bewijst niet dat controles met inloggegevens zijn uitgevoerd of dat de applicatie het account heeft geautoriseerd.

Gebruik alleen speciale inloggegevens wanneer de afgesproken scope geauthenticeerde controles vereist. Bevestig de rechten en het vergrendelingsbeleid van het account en bepaal hoe bevindingen worden opgeslagen en gedeeld voordat de scan ze oplevert.

Mislukken de inloggegevens, val dan niet stilzwijgend terug op een niet-geauthenticeerde run en bestempel het rapport niet als de geplande beoordeling. Het resultaat is een andere test met een andere betekenis, en dat verschil hoort in het rapport.

Punt vijf: sla het plan op en start bewust

In de Nessus-scanworkflow zijn het kiezen van een sjabloon, het configureren van instellingen en het opslaan of starten van de scan afzonderlijke stappen. Gebruik die scheiding om de doellijst, de bron en de planning te beoordelen voordat er verkeer begint.

Controleer voordat je de start autoriseert welke bron de VPN toestaat, welk verkeer hij draagt en hoe hij herstelt van een weggevallen tunnel. Vergroot de firewalls toegang niet alleen omdat een voorbereidende verbinding mislukte; zoek de laag die weigerde en herstel die laag.

Leg na de run de scannerhost, de waargenomen bron, de doellijst en alle controles vast die niet konden worden afgerond. Een rapport dat vanaf een andere bron of zonder de bedoelde inloggegevens is gemaakt, vertegenwoordigt het oorspronkelijke plan niet, en dat benoemen hoort bij het eindproduct.

Trek de opdrachttoegang in en behandel bewaarde resultaten volgens het afgesproken proces. De checklist is pas klaar wanneer het bewijs overeenkomt met het pad dat je hebt goedgekeurd, niet wanneer de scan simpelweg resultaten opleverde.