TCP-omoverføringer mot IPsec-replay-avvisninger: les hvert lag

Tre forskjellige verktøy rapporterer tre forskjellige duplikater, og bare én av dem er en nettverkshendelse du kan gjøre noe med. En TCP-omoverføring er en avsender som sender et område på nytt, en duplisert ACK er en mottaker som gjentar en bekreftelse, og en ESP-replay-avvisning er en sikkerhetsassosiasjon som avviser et sekvensnummer den allerede har godtatt. Ingen av de tre innebærer noen av de andre. Les hver teller på laget som produserer den, før du setter dem sammen til en historie.

Tre tellere som aldri måler den samme hendelsen

TCP-omoverføringsmerkingen betyr at avsenderen la et sekvensområde på ledningen igjen. Tap er én grunn til det, og opptaket du har mangler kanskje bare den opprinnelige pakken eller bekreftelsen som ville forklart tidspunktet. En duplisert ACK er mottakeren som gjentar en kumulativ bekreftelse etter TCP-gjenopprettingsreglene, noe som verken er en duplisert applikasjonsskriving eller en andre kopi av dataene.

ESP arbeider i sitt eget sekvensrom. Hver sikkerhetsassosiasjon nummererer pakkene den sender, og mottakeren holder et vindu av numre den allerede har godtatt, så en ESP-pakke som ankommer to ganger, forkastes bare på det grunnlaget. Et sendt TCP-segment på nytt reiser derfor i en ny ESP-pakke med et nytt sekvensnummer, noe som er korrekt oppførsel på begge lag. De samme bytene kan se nye ut i én teller og gamle ut i en annen, og ingen av lagene lyver.

Hva analyzeren kan og ikke kan se

Begynn med analyzerens ordforråd, fordi filternavnene beskriver observasjoner og ikke det indre av endepunktene. Å telle med de samme navnene som verktøyet bruker, holder deg ærlig om hva som faktisk ble målt. En telling fra et ufullstendig opptak er en telling av det som overlevde, ikke av det som skjedde på ledningen.

tshark -r trace.pcap -Y "tcp.analysis.retransmission" | wc -l
tshark -r trace.pcap -Y "tcp.analysis.duplicate_ack" | wc -l

Les ekspertinformasjonen ved siden av tallene, fordi advarsler om sjekksum og rekkefølge endrer hvor mye vekt de fortjener. Et sammenslått spor fra to sensorer kan vise én ramme to ganger, og å telle begge kopiene oppfinner en gjenopprettingshendelse som aldri skjedde.

ESP-tellere bor i kjernetilstanden

ESP-sekvensnumre tilhører sikkerhetsassosiasjonen, ikke TCP-strømmen, så gatewayen er stedet å spørre. Tilstandsoversikten rapporterer pakke- og feiltellere per assosiasjon som ingen opptak kan rekonstruere.

ip -s xfrm state
tshark -r trace.pcap -Y "esp" -T fields -e esp.seq | head

RFC 4303 definerer sekvensnummeret og anti-replay-vinduet som forbruker det, og derfor stiger telleren selv når ingenting er galt. Monotone ytre sekvensnumre uten en tilsvarende TCP-anomali peker på en annen avsender eller en duplisert rute snarere enn på en omoverføringsstorm. Et ytre opptak av en kryptert tunnel skjuler vanligvis de indre TCP-sekvensnumrene, så det kan ikke bevise hva den indre stakken gjorde. Ta opp inne i tunnelen bare der policyen tillater det, og slå aldri av anti-replay for å dempe en urelatert advarsel.

Hvor observasjonspunktet endrer svaret

Før du eskalerer, skriv ned hvordan opptaket ble gjort: grensesnittet, om opptaksprosessen rapporterte tap, og om tidsstemplene er sammenlignbare mellom sensorer. Ett observasjonspunkt kan ikke se begge ender av en rute, så enhver uttalelse om mottakerens oppførsel er en slutning og ikke en måling. Et spor tatt på gatewayen og et spor tatt på verten vil være uenige om rekkefølgen under belastning, og den uenigheten tilhører vanligvis opptaket og ikke tunnelen. Å korrelere to visninger er det som gjør en telling til bevis.

Bruk én tillatt applikasjonsstrøm og noter endepunktenes tellere ved siden av opptakets tall i samme øyeblikk. Hvis tallene er uenige, stol på laget som eier hendelsen, og behandle det andre som en observasjonsartefakt til det motsatte er bevist. Den regelen avgjør de fleste av disse sakene uten å røre tunnelkonfigurasjonen.

Å lese tallene i riktig rekkefølge

Begynn på laget der spørsmålet ble stilt: en TCP-advarsel besvares fra et TCP-opptak, og en ESP-avvisning besvares fra sikkerhetsassosiasjonens tellere på gatewayen. Først da spør du om de to visningene beskriver den samme pakken. En konklusjon som trenger begge lag, bør nevne begge, fordi en påstand om tunnelen som hviler på en TCP-merking alene, er en gjetning.

Noter laget, telleren og observasjonspunktet for hvert funn, og neste leser vil ikke smelte tre hendelser sammen til én innbilt feil. Eskaler med de tre feltene, og rettelsen følger vanligvis fra det første.