Gateway of doorgestuurde client? Het bronadres lezen

De webserver logt één adres, en iedereen gaat ervan uit dat het bij het proces van de gateway zelf hoort. Het kan toebehoren aan een doorgestuurde client wiens privéadres bij de vertaalstap verdween. De bestemming ziet de zichtbare netwerkbron en niets meer. Dat is een grensverklaring, niet de bewering dat de oorsprong nooit kan worden vastgesteld.

Wat de bestemming werkelijk ziet

Neem een client op 10.20.0.7, een gateway met het buitenadres 198.51.100.10 en een bestemming op internet. Als de gateway de bron van de client vertaalt, registreert de socket van de bestemming 198.51.100.10. Het privéadres is uit het pakket verdwenen, en de bestemming kan het niet uit die header teruglezen. Die getallen zijn illustratief, geen opname uit uw netwerk.

De waarneming blijft nuttig: ze identificeert de netwerkbron die de bestemming moet toestaan of blokkeren. Ze identificeert alleen niet de persoon of het proces erachter. Voor de operator van de bestemming bepaalt dat onderscheid of een blokkade een netwerkbeslissing of een accountbeslissing is.

De vertaaltoestand is niet zichtbaar voor de bestemming

De gateway houdt de koppeling bij tussen de vertaalde verbinding en de oorspronkelijke client, en precies die toestand ontbreekt bij de bestemming. de traditionele NAT-beschrijving scheidt het vertaalrecord van de headers die daarna zichtbaar zijn. Eén kant lezen geeft je niet de andere.

Verschillende ontwerpen leveren verschillend bewijs. Gerouteerd verkeer met behouden bronadressen toont het echte adres van de client, terwijl een applicatieproxy de verbinding beëindigt en een nieuwe maakt. Een route met behouden bron vereist ook dat het adres van de client vanaf de bestemming teruggerouteerd kan worden, wat niet elke implementatie biedt. Vraag welk ontwerp is uitgerold voordat u een logregel interpreteert.

conntrack -L -s 198.51.100.10
tcpdump -ni eth0 host 198.51.100.10

TTL en vingerafdrukken zijn aanwijzingen, geen bewijs

De TTL in IPv4 hangt af van de beginwaarde die de afzender kiest en van het aantal hops dat het pakket heeft doorlopen. Zonder beide feiten kan een waarde niet bewijzen dat er een VPN-hop heeft plaatsgevonden. Een bekende extra gerouteerde hop onderscheidt ook geen LAN-router, tunnelpad of andere doorstuurregeling. Behandel een TTL-verschil als een vraag, niet als een conclusie.

Andere signalen gedragen zich hetzelfde. Een User-Agent-header kan door de applicatie worden ingesteld, en gelijkenis in timing kan gedeelde infrastructuur weerspiegelen in plaats van een gedeelde persoon. Meerdere gebruikers kunnen één uitgang delen, en één gebruiker kan tussen sessies van pad wisselen. Samengenomen kunnen meerdere zwakke signalen een nadere blik op de administratie van een gateway rechtvaardigen, maar door ophoping worden ze geen sterk bewijs.

Autoriseer op identiteit, niet op adres

Als de bestemming het beheer van de gateway moet scheiden van de activiteit van externe gebruikers, geef die rollen dan afzonderlijke geauthenticeerde identiteiten en toegestane bewerkingen. Een gedeelde openbare bron kan nog steeds als netwerkbeperking dienen, maar is geen vervanging voor het authenticeren van de gebruiker of het apparaat.

Houd het bewijs gelabeld: de waargenomen bron, het geauthenticeerde account, het tijdstip en de gevolgtrekking die wordt overwogen. Vertaal «hier is geen interne bron zichtbaar» niet als «nergens is toerekening mogelijk». Het label doet ertoe wanneer iemand die niet bij het onderzoek betrokken was het record maanden later leest.

Leg de datum van de waarneming vast en het systeem dat deze heeft geproduceerd. Een niet-toegeschreven logfragment is later moeilijk te verdedigen.