Pakketopname op afstand: de sensor blijft lokaal, de analist werkt op afstand

Pakketopname hoort waar de pakketten al stromen, en de analist op afstand zit daar zelden. De werkbare opstelling is een sensor op het geobserveerde segment plus een VPN die beheer en ophalen draagt, niet de hele gespiegelde verbinding. Die splitsing houdt de laptop van de analist buiten het opnamepad en houdt gevoelige payloads op locatie. De stappen hieronder kiezen de interface, begrenzen het bestand en verplaatsen alleen wat de vraag nodig heeft.

Een laptop op afstand is geen tap

Deelnemen aan het netwerk via VPN geeft uw machine een route naar de sensor, geen zicht op verkeer tussen andere hosts. Een opname op uw laptop ziet alleen pakketten die aan de interface van uw laptop worden afgeleverd. Het observeren van een geschakelde verbinding vereist dat de netwerkeigenaar een spiegel of een tap levert die een sensor ter plaatse voedt. Zelfs dan heeft de spiegel grenzen, omdat overbelaste bestemmingen frames laten vallen en een gateway nooit verkeer ziet dat binnen dezelfde VLAN blijft.

Een versleutelde stroom blijft ook bij de sensor versleuteld, omdat de TLS-payload bij de eindpunten hoort. Opname levert headers, timing en volume, geen platte tekst.

Kies de interface die de stroom kan zien

Voordat u iets filtert, lijst u de interfaces op en bevestigt u welke het pad draagt waar u naar vroeg. Gokken tussen een fysieke poort, een bond en een bridge is een gebruikelijke manier om een leeg bestand te verzamelen.

ip -br link
dumpcap -D

Koppel de interfacenaam aan het observatiepunt in het wijzigingsrecord, niet aan een naam die u van een andere host kent. Als de pakketteller op nul blijft terwijl de dienst zichtbaar bezig is, staat de sensor op het verkeerde segment of is de spiegel voor de andere richting ingesteld. Bewijs het pad eerst met een bekende uitwisseling, zodat een kapotte spiegel niet voor een stille toepassing wordt aangezien. Schrijf de details van interface en spiegel in de opnamenotities zolang ze nog vers zijn.

Begrens de opname met een filter en een ring

Een opname zonder grenzen vult de schijf en verzamelt meer dan de vraag vereist. Zet de toegestane bron, bestemming en protocol in het filter en begrens daarna de bestandsgrootte en het aantal bestanden.

tcpdump -i eth0 -n -s 128 -c 5000 -W 4 -C 25 -w /var/tmp/cap.pcap 'host 203.0.113.10 and tcp port 443'

Het adres en de poort hierboven zijn voorbeelden uit het documentatiebereik, dus vervang ze door de goedgekeurde waarden en houd het venster kort genoeg dat het bewijs de ring overleeft. De snapshotlengte snijdt de payload af en behoudt de headers, wat meestal genoeg is voor een connectiviteitsvraag en veel eenvoudiger op te slaan. Lees de kernel-dropregel die tcpdump bij het afsluiten afdrukt, want een hoog aantal drops betekent dat de opname onvolledig is en niet stil. Bewaar het venster dat u nodig hebt voordat de ring het overschrijft, en noteer de filterstring naast de bestandsnaam.

Verplaats het bestand, niet de hele verbinding

Haal de voltooide opname op via het beheerkanaal in plaats van de spiegel over de WAN te streamen. Eén overdracht is eenvoudiger te autoriseren, te loggen en te verwijderen dan een doorlopende export.

scp [email protected]:/var/tmp/cap.pcap ./

Houd het bestand alleen leesbaar voor het operatoraccount en verwijder het van de sensor zodra de analysecopie is geverifieerd. Als live-export echt de eis is, dimensioneer dan de spiegel-inkapseling en het transport samen, want de overhead kan het linkbudget overschrijden. Noteer de zichtbaarheidsgaten hoe dan ook, want een opname is bewijs met een bekend observatiepunt en geen volledige registratie van het netwerk.