Nessus over VPN: hvor scanneren skal placeres før den første scanning

Et VPN-ikon ved siden af browseren siger intet om den proces, der sender scanningspakkerne. Hvis konsollen og scanneren kører på forskellige værter, er browserens tunnel én vej, og scanningens kilde er en anden. Begynd ved udførelsespunktet og arbejd dig udad: ruten, autorisationen og loginoplysningerne. Den skelnen står først på tjeklisten af en grund.

Dette er en tjekliste før start, ikke en scanningsvejledning. Hvert trin giver et faktum, som du kan skrive i sagsprotokollen, før et eneste paket forlader scanneren.

Kontrol et: find den proces, der sender proberne

Tegn de tre roller eksplicit: browseren på bærbar A, scanningskonsollen på vært B og det private mål C. Hvis B også kører scanningsmotoren, har browseren kun brug for en vej til B. Hvis en særskilt scanningsenhed udfører arbejdet, har den enhed brug for vejen til C.

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

En browser forbundet til VPN kan nå konsollen, mens scanneren bag den stadig ikke har nogen rute til C. Det modsatte er også muligt: scanneren er inde i det private netværk, og konsollen er ekstern. Find ud af, hvilket arrangement du faktisk kører, før du ændrer nogen netværkskontrol. Navngiv enheden i scanningskonfigurationen, før du giver netværket skylden.

Hvis scanneren kører på A, deler browserens vært og scanneren en kontekst, men kun så længe processen bevarer samme navnerum og samme routingtabel. En container eller en tjenestekonto arver måske ikke det, den interaktive browser ser. Konsollen er en administrationsflade, ikke scanningsmotoren.

Kontrol to: bevis scannerens rute og DNS

Kør rute kontrollen på scannerværten, ikke på den bærbare. Spørg kernen, hvilket interface og hvilken gateway den ville bruge til mål adressen, og gentag for målets værtsnavn. En rute, der findes for IP-adressen, og et navn, der opløses til en anden adresse, er to forskellige fejl.

Bekræft kildeadressen, som vil optræde ved målet. En VPN-klient kan tildele en anden adresse end den, målets firewall forventer, og en NAT-enhed kan skrive den om igen. Målets ejer har brug for den observerede kilde, ikke adressen trykt i VPN-profilen.

Kontrollér også returvejen. En scanner, der når målet, men ikke modtager svar, har et routing- eller firewallproblem på vejen tilbage, og det ser identisk ud med et mål, der er nede.

Kontrol tre: få omfang og synsvinkel autoriseret

Lad målets ejer skriftligt angive systemer, tjenester, miljø, kilde og tidsvindue. Beslut, hvilken synsvinkel vurderingen repræsenterer: en ekstern VPN-bruger, en optaget intern klient eller et bestemt scanningssegment.

En privat rute er ikke tilladelse til at teste tilstødende netværk. Hold mållisten snæver, oplys udelukkede systemer, og aftal stopbetingelser og en kontakt, der kan standse kørslen. Scanneren undersøger gerne alt, hvad den kan nå, og netop derfor skal omfanget være eksplicit.

Noter den godkendte kilde i samme dokument. Hvis scannerens observerede kilde afviger fra den godkendte, repræsenterer kørslen ikke den aftalte synsvinkel, selv når mållisten er korrekt.

Kontrol fire: tilpas loginoplysningerne til vurderingens dybde

En tilgængelighedskontrol og en autentificeret vurdering er forskellige tests. Et portsvar beviser, at noget svarede; det beviser ikke, at kontroller med loginoplysninger blev kørt, eller at applikationen autoriserede kontoen.

Brug kun dedikerede loginoplysninger, når det aftalte omfang kræver autentificerede kontroller. Bekræft kontoens tilladelser og låsepolitik, og beslut, hvordan fund lagres og deles, før scanningen producerer dem.

Hvis loginoplysningerne fejler, må du ikke stiltiende falde tilbage på en uautentificeret kørsel og kalde rapporten den planlagte vurdering. Resultatet er en anden test med en anden betydning, og den forskel hører i rapporten.

Kontrol fem: gem planen, og start så bevidst

I Nessus' scanningsworkflow er valg af skabelon, konfiguration af indstillinger og lagring eller start af scanningen separate trin. Brug den adskillelse til at gennemgå mållisten, kilden og tidsplanen, før trafik begynder.

Før du autoriserer starten, skal du kontrollere, hvilken kilde VPN tillader, hvilken trafik den bærer, og hvordan den kommer sig efter en brudt tunnel. Udvid ikke firewalladgangen, blot fordi en foreløbig forbindelse fejlede; find det lag, der afviste den, og ret det lag.

Efter kørslen skal du notere scannerværten, dens observerede kilde, mållisten og alle kontroller, der ikke kunne gennemføres. En rapport udarbejdet fra en anden kilde eller uden de tilsigtede loginoplysninger repræsenterer ikke den oprindelige plan, og at sige det er en del af leverancen.

Træk sagens adgang tilbage, og håndtér opbevarede resultater efter den aftalte proces. Tjeklisten er først færdig, når evidensen svarer til den vej, du godkendte, ikke når scanningen blot returnerede resultater.