TCP-omoverføringar mot IPsec-replay-avvisingar: les kvart lag

Tre ulike verktøy rapporterer tre ulike duplikat, og berre éin av dei er ei nettverkshending du kan gjere noko med. Ei TCP-omoverføring er ein avsendar som sender eit område på nytt, ein duplisert ACK er ein mottakar som gientek ei stadfesting, og ei ESP-replay-avvising er ein tryggingsassosiasjon som avviser eit sekvensnummer han allereie har godteke. Ingen av dei tre inneber nokon av dei andre. Les kvar teljar på laget som produserer han, før du set dei saman til ei historie.

Tre teljarar som aldri måler den same hendinga

TCP-omoverføringsmerkinga betyr at avsendaren la eit sekvensområde på linja igjen. Tap er éin grunn til det, og opptaket du har manglar kanskje berre den opphavlege pakken eller stadfestinga som ville forklart tidspunktet. Ein duplisert ACK er mottakaren som gientek ei kumulativ stadfesting etter TCP-gjenopprettingsreglane, noko som korkje er ei duplisert applikasjonsskriving eller ein andre kopi av dataa.

ESP arbeider i sitt eige sekvensrom. Kvar tryggingsassosiasjon nummererer pakkane han sender, og mottakaren held eit vindauge av nummer han allereie har godteke, så ein ESP-pakke som kjem to gonger, blir forkasta berre på det grunnlaget. Eit TCP-segment som blir sendt på nytt, reiser derfor i ein ny ESP-pakke med eit nytt sekvensnummer, noko som er korrekt åtferd på begge lag. Dei same byta kan sjå nye ut i éin teljar og gamle ut i ein annan, og ingen av laga lyg.

Kva analysatoren kan og ikkje kan sjå

Byrja med ordforrådet til analysatoren, fordi filternamna skildrar observasjonar og ikkje det indre av endepunkta. Å telje med dei same namna som verktøyet brukar, held deg ærleg om kva som faktisk vart målt. Ei teljing frå eit ufullstendig opptak er ei teljing av det som overlevde, ikkje av det som skjedde på linja.

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

Les ekspertinformasjonen ved sida av tala, fordi åtvaringar om sjekksum og rekkjefølgje endrar kor mykje vekt dei fortener. Eit samanslege spor frå to sensorar kan vise éin ramme to gonger, og å telje begge kopiane finn opp ei gjenopprettingshending som aldri skjedde.

ESP-teljarar bur i kjernetilstanden

ESP-sekvensnummer høyrer til tryggingsassosiasjonen, ikkje TCP-straumen, så gatewayen er staden å spørje. Tilstandsoversynet rapporterer pakke- og feilteljarar 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-vindauget som brukar det, og derfor stig teljaren sjølv når ingenting er gale. Monotone ytre sekvensnummer utan ei tilsvarande TCP-anomali peikar på ein annan avsendar eller ein duplisert rute snarare enn på ein omoverføringsstorm. Eit ytre opptak av ein kryptert tunnel skjuler vanlegvis dei indre TCP-sekvensnummera, så det kan ikkje bevise kva den indre stakken gjorde. Ta opp inne i tunnelen berre der retningslinjene tillèt det, og slå aldri av anti-replay for å dempe ei urelatert åtvaring.

Kvar observasjonspunktet endrar svaret

Før du eskalerer, skriv ned korleis opptaket vart gjort: grensesnittet, om opptaksprosessen rapporterte tap, og om tidsstempa er samanliknbare mellom sensorar. Eitt observasjonspunkt kan ikkje sjå begge endar av ei rute, så kvar utsegn om åtferda til mottakaren er ei slutning og ikkje ei måling. Eit spor teke på gatewayen og eit spor teke på verten vil vere usamde om rekkjefølgja under belastning, og den usemja høyrer vanlegvis til opptaket og ikkje tunnelen. Å korrelere to visingar er det som gjer ei teljing til bevis.

Bruk éin tillaten applikasjonsstraum og noter teljarane til endepunkta ved sida av tala i opptaket i same augneblink. Viss tala er usamde, stol på laget som eig hendinga, og handsam det andre som ein observasjonsartefakt til det motsette er bevist. Den regelen avgjer dei fleste av desse sakene utan å røre tunnelkonfigurasjonen.

Å lese tala i rett rekkjefølgje

Byrja på laget der spørsmålet vart stilt: ei TCP-åtvaring blir svara frå eit TCP-opptak, og ei ESP-avvising blir svara frå teljarane til tryggingsassosiasjonen på gatewayen. Først då spør du om dei to visingane skildrar den same pakken. Ei slutning som treng begge lag, bør nemne begge, fordi ein påstand om tunnelen som kviler på ei TCP-merking åleine, er ei gissing.

Noter laget, teljaren og observasjonspunktet for kvart funn, og neste lesar vil ikkje smelte tre hendingar saman til éin innbilt feil. Eskaler med dei tre felta, og rettinga følgjer vanlegvis frå det første.