Nmap toont andere resultaten via een VPN? Zet het doel vast

Twee poortscans van dezelfde website kunnen verschillen omdat de naam tussen de runs naar een ander adres is omgezet, niet omdat de tunnel veranderde wat het doel blootlegt. Een hostnaam is een zoekinstructie, en Nmap volgt die op het moment van scannen. Als de resolver met een ander record antwoordt, heeft de tweede scan een andere machine gemeten.

Zet het numerieke adres vast en de vergelijking wordt weer zinvol. Al het overige in het rapport, van timing tot tussenliggende apparaten, blijft een afzonderlijke variabele die eigen controle nodig heeft.

Twee experimenten die er in een rapport identiek uitzien

Vergelijk een naam met zichzelf en je hebt minstens twee dingen tegelijk veranderd: het pad dat je pakketten afleggen en de bestemming die de resolver teruggaf. Een verschil in de uitvoer kan aan geen van beide worden toegeschreven. Die dubbelzinnigheid is de gebruikelijke reden waarom een voor-en-na-scan een discussie wordt die niemand kan beslechten.

Vergelijk een adres met zichzelf en de bestemming ligt door de opbouw vast. Alles wat nog verschilt, hoort bij het pad, het bronadres, de filtering ertussen of de eigen toestand van de machine. Je hebt één variabele verwijderd, wat niet hetzelfde is als ze allemaal verwijderen.

Schrijf op welk van die twee experimenten je werkelijk hebt uitgevoerd voordat je een conclusie uit een poorttabel trekt. Het onderscheid klinkt academisch tot een rapport zegt dat de VPN een poort heeft geblokkeerd die nooit open was op het adres dat je de tweede keer raakte.

Los eerst op, scan dan het adres dat je hebt vastgelegd

Scheid het omzetten van het sonderen zodat de twee feiten op verschillende plekken belanden. Vraag het systeem wat het heeft omgezet, bewaar dat antwoord en geef Nmap daarna het letterlijke adres. Herhaal dezelfde twee opdrachten met de tunnel omlaag en omhoog.

getent hosts scan.example.net
dig +short scan.example.net A
nmap -Pn -sV -p 443,8443 192.0.2.40

De vlag -Pn is hier belangrijk, want een host die ontdekkingssondes negeert, zou anders als neer worden gerapporteerd en het lege resultaat verkeerd als een gesloten poort worden gelezen. Gebruik -sV alleen tegen doelen die de operator heeft goedgekeurd; versiesondering is luider dan een kale verbinding en hoort binnen de schriftelijke scope.

De referentie voor doelspecificatie van Nmap zegt uitdrukkelijk dat een hostnaam vóór het scannen naar een adres wordt omgezet en dat het gereedschap bij meerdere terugkerende adressen het eerste scant, tenzij je ze allemaal opvraagt. Niets aan dat gedrag is VPN-specifiek. Split-horizon-DNS, een andere resolver of een loadbalancer die in een nieuwe volgorde antwoordt, geven hetzelfde effect zonder enige tunnel.

Houd de omgezette waarde naast de scanuitvoer, met de adresfamilie, de vlaggenset en een tijdstempel. Een reverse lookup die een bedrijfsnaam teruggeeft, is een andere waarneming, geen bewijs van welke backend heeft geantwoord.

Wat een gewijzigde poortstatus je wel en niet kan vertellen

Zodra de bestemming vaststaat, wijst een poort die van open naar gefilterd omslaat meestal op het pad. Denk aan een ACL stroomopwaarts, een stateful firewall of een provider die tunneluitgang anders behandelt dan woonuitgang. Vernauw het door een tweede goedgekeurd adres in hetzelfde subnet te testen wanneer de scope dat toestaat, want het wisselen van de hostnaam zou de resolvervraag opnieuw invoeren. Eén variabele per run is de hele methode.

Een poort die open blijft terwijl de servicebanner verandert, is een ander verhaal. Dat patroon past bij een front-end die verbindingen over backends verdeelt, en geen enkele hoeveelheid scans van jouw kant zal de huurder erachter benoemen.

Wat de scan nooit zegt, is bedoeling. Een gefilterde poort is een beleidsuitkomst, geen bewijs dat iemand jouw tunnel heeft uitgekozen, en een open poort is geen bewijs dat de applicatie erachter je zal bedienen. Correleer met logs van de component die je beheert voordat je een van beide verhalen schrijft.

Leg resultaten vast zodat de vergelijking de beoordeling overleeft

Een bruikbaar record bevat de opgevraagde naam, het omgezette adres en de familie, de exacte vlaggen, het gebruikte bronadres en de autorisatie die de bestemming dekte. Voeg de tijd toe, want DNS-antwoorden roteren en een rapport zonder tijdstempels nodigt dezelfde discussie twee keer uit. Voeg ook de scannerversie toe, want het standaard sondeergedrag verschuift tussen releases. Als twee runs verschillende methoden gebruikten, behandel ze als verschillende experimenten en zeg dat in de kop, niet in de voetnoot.

Label de bevinding voor wat die is: verschillende bestemmingen, verschillende bronpaden of een verschil dat nog niet is verklaard. Die woordenschat houdt een scanrapport eerlijk en voorkomt dat een resolverantwoord opnieuw als VPN-onderscheppingsgebeurtenis wordt gepubliceerd. De volgende stap is meestal nog een run met het adres vastgezet, niet een bredere scan.