Overføringskontrollprotokoll

"For TCP er to verter et selskap, tre er en folkemengde"

( JF Kurose, KW Ross - Internett og datanettverk, en ovenfra-og-ned-tilnærming )

Innen telekommunikasjon og informasjonsteknologi er Transmission Control Protocol ( TCP ) en transportlags pakkenettverksprotokoll , som tilhører Internett - protokollpakken , som omhandler overføringskontroll eller å lage pålitelig datakommunikasjon på nettverket mellom avsender og mottaker. Definert i RFC 9293 , de fleste Internett -nettverksapplikasjoner er avhengige av det , det er kun til stede på nettverksterminalene ( vertene ) og ikke på de interne svitsjnodene til transportnettverket , implementert som et nettverksprogramvarelag i operativsystemet til en vert, og den sendende eller mottakende terminalen får tilgang til den ved bruk av passende systemanrop definert i systemets API .

Beskrivelse

TCP kan klassifiseres på transportlaget (nivå 4) i OSI-referansemodellen , og brukes vanligvis i forbindelse med nettverkslagsprotokollen (OSI nivå 3) IP . I TCP/IP-modellen opptar TCP-protokollen lag 4, transport.

I tråd med diktatene til transportnivået etablert av ISO / OSI-modellen og med sikte på å overvinne problemet med mangelen på pålitelighet og kontroll av kommunikasjon som oppsto med storskala sammenkobling av lokale nettverk i et enkelt stort geografisk nettverk TCP er designet og bygget for å bruke tjenestene som tilbys av nettverksprotokoller på lavere nivå ( IP og fysiske lag og datalinklagprotokoller ) som effektivt definerer overføringsmodusen på kommunikasjonskanalen , men som ikke gir noen garanti for pålitelighet på levering i form av forsinkelse, tap og feil av de overførte informasjonspakkene , på flytkontroll mellom terminaler og på kontrollen av nettverksoverbelastning , og kompenserer dermed for problemene ovenfor og bygger dermed en pålitelig kommunikasjonskanal mellom to nettverksapplikasjonsprosesser . Kommunikasjonskanalen som er konstruert på denne måten er sammensatt av en toveis strøm av bytes etter etableringen av en forbindelse ved endene mellom de to kommuniserende terminalene. I tillegg er noen funksjoner i TCP avgjørende for den generelle gode funksjonen til et IP-nettverk. Fra dette synspunktet kan TCP betraktes som en nettverksprotokoll som omhandler å bygge tilkoblinger og garantere pålitelighet på et underliggende IP-nettverk som i hovedsak er av best-innsats typen .

TCP ble født i 1970 som et resultat av arbeidet til en forskningsgruppe fra det amerikanske forsvarsdepartementet . Styrkene er dens høye pålitelighet og robusthet. Dens popularitet skyldes også dens utbredte implementering av University of Berkeley , utgitt i California i kildeform ( TCP Berkeley ). Imidlertid er det mange implementeringer og utviklinger som har skjedd over tid som utviklinger og forbedringer (f.eks . TCP Tahoe , TCP Reno , TCP New Reno ).

Hovedtrekk

Sammenligning med UDP

Hovedforskjellene mellom TCP og User Datagram Protocol ( UDP ), den andre hovedtransportprotokollen i Internett- protokollpakken , er:

Bruk av TCP-protokollen fremfor UDP er generelt foretrukket når det er nødvendig å ha garantier på levering av data eller på rekkefølgen av ankomst av de ulike segmentene (som for eksempel ved filoverføringer). Tvert imot brukes UDP hovedsakelig når interaksjonen mellom de to vertene er idempotent eller hvis det er sterke begrensninger på hastigheten og økonomien til ressursene til nettverket (f.eks . streaming i sanntid, flerspillervideospill).

TCP-segment

TCP PDU kalles et segment . Hvert segment er normalt pakket inn i en IP - pakke , og består av TCP- headeren og en nyttelast ( nyttelast på engelsk ), det vil si dataene som kommer fra applikasjonslaget (f.eks. HTTP). Dataene i overskriften utgjør en kommunikasjonskanal mellom avsender-TCP og mottaker-TCP, som brukes til å implementere funksjonaliteten til transportlaget og ikke er tilgjengelig for lagene på de høyere nivåene.

Et TCP-segment er strukturert som følger:

TCP-hode
Offset Oktett 0 1 2 3
Oktett Bit  0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 Kildeport Destinasjonshavn
4 32 Sekvensnummer
8 32 Bekreftelsesnummer (hvis ACKangitt)
12 96 Dataoffset Reservert
0 0 0 0		 C
W
R		 E
C
E		 U
R
G		 A
C
K		 P
S
H		 R
S
T		 S
Y
N		 F
I
N		 Vindustørrelse
16 128 Sjekksum Haster peker (hvis URGsatt)
20 160 Alternativer (valgfritt)
20/60

...

160/480
... 		Dato

Tilkobling

Selv før dataoverføringen på kommunikasjonskanalen og overføringskontrolloperasjonene på den mottatte datastrømmen, handler det i TCP-overføring om å etablere forbindelsen i endene mellom applikasjonsprosessene til de kommunikerende terminalene gjennom definisjonen av kontakten eller parets IP-adresse , port for både avsender og mottaker. På den annen side bør det huskes at den interne svitsjen i nodene til datatransportnettverket typisk følger pakkesvitsjing, dvs. uten krets eller dedikert fast forbindelse typisk i stedet for kretssvitsj . Formålet med TCP-tilkoblingen er uansett reservasjon av ressurser mellom applikasjonsprosesser som utveksler informasjon eller tjenester mellom dem (f.eks . server og klient ). På slutten av tilkoblingen utfører TCP fasen med å drepe tilkoblingen. De to prosedyrene er forskjellige og beskrevet nedenfor. Implementeringen av pakkenettverksapplikasjoner faller innenfor rammen av såkalt socket-programmering .

Åpne en tilkobling - Treveis håndtrykk

Prosedyren som brukes for pålitelig å etablere en TCP- forbindelse mellom to verter kalles et treveis håndtrykk , noe som indikerer behovet for å utveksle 3 meldinger mellom avsenderverten og mottakerverten for at forbindelsen skal etableres riktig. Tenk for eksempel på at vert A har til hensikt å åpne en TCP-forbindelse med vert B; trinnene som skal følges er:

  1. A sender et SYN-segment til B - SYN-flagget er satt til 1 og sekvensnummerfeltet inneholder verdien x som spesifiserer det opprinnelige sekvensnummeret til A;
  2. B sender et SYN / ACK-segment til A - SYN- og ACK -flaggene er satt til 1, sekvensnummerfeltet inneholder y -verdien som spesifiserer det innledende sekvensnummeret til B og bekreftelsesnummerfeltet inneholder verdien x + 1 som bekrefter mottaket ISN av A;
  3. A sender et ACK-segment til B - ACK-flagget er satt til 1 og feltet for bekreftelsesnummer inneholder verdien y + 1 som bekrefter mottak av Bs ISN.

Det tredje segmentet ville ideelt sett ikke vært nødvendig for åpningen av forbindelsen siden allerede etter at A har mottatt det andre segmentet, har begge vertene uttrykt sin tilgjengelighet for å åpne forbindelsen. Imidlertid er det nødvendig for også å tillate vert B et estimat av den innledende timeout, ettersom tiden som har gått mellom sending av et segment og mottak av den tilsvarende ACK.

SYN-flagget er nyttig i den praktiske implementeringen av protokollen, og i dens analyse av brannmurer : i TCP-trafikk etablerer SYN-segmentene nye forbindelser, mens de med det inaktive flagget tilhører forbindelser som allerede er etablert.

Segmentene som brukes under håndtrykket er vanligvis 'kun header', dvs. de har Data- feltet tomt da dette er en fase med synkronisering mellom de to vertene og ikke for datautveksling.

Treveis håndtrykket er nødvendig siden den numeriske sekvensen (ISN) ikke er koblet til en generell nettverksklokke , dessuten kan hver IP-pakke ha sin egen måte å beregne det første sekvensnummeret på. Ved mottak av første SYN er det ikke mulig å vite om den mottatte sekvensen tilhører en forsinkelse på grunn av en tidligere forbindelse. Imidlertid lagres den siste sekvensen som ble brukt i forbindelsen, slik at verifisering av SYN som tilhører den gamle forbindelsen kan bli forespurt fra avsenderverten.

Lukke en forbindelse - dobbelt toveis håndtrykk

Når en TCP-forbindelse er etablert, betraktes ikke den som en enkelt toveisforbindelse, men snarere som samspillet mellom to enveisforbindelser; derfor bør hver part avslutte sin egen forbindelse. Det kan også være halvlukkede tilkoblinger , hvor kun én vert har stengt tilkoblingen fordi den ikke har noe igjen å overføre, men kan (og må) fortsatt motta data fra den andre verten.

Forbindelsen kan lukkes på to måter: med et treveis håndtrykk, der de to delene lukker sine respektive forbindelser samtidig, eller med et fireveis (eller bedre 2 separate håndtrykk), der de to forbindelsene er stengt til forskjellige tider.

3-veis håndtrykket for å lukke forbindelsen er det samme som brukes for å åpne forbindelsen, med den forskjellen at flagget som brukes er FIN i stedet for SYN. En vert sender et segment med FIN-forespørselen, den andre svarer med en FIN + ACK, til slutt sender den første den siste ACK, og hele forbindelsen avsluttes.

Det doble 2-veis håndtrykket, derimot, brukes når frakoblingen ikke er samtidig mellom de to kommuniserende vertene. I dette tilfellet sender en av de to vertene FIN-forespørselen, og venter på svaret ACK; den andre terminalen vil da gjøre det samme, og dermed generere totalt 4 segmenter.

En mer aggressiv måte å lukke forbindelsen på er også mulig, ved å sette RESET-flagget i segmentet, og avbryte forbindelsen i begge retninger. TCP-en som mottar en RESET, lukker forbindelsen ved å stoppe enhver dataoverføring.

Multipleksing og porter

Hver aktiv TCP-tilkobling er assosiert med en socket som åpnes av en prosess (socket er verktøyet som tilbys av operativsystemet til applikasjoner for å bruke nettverksfunksjonalitet). TCP tar seg av sortering av data mellom aktive koblinger og relaterte prosesser. For dette er hver forbindelse mellom to verter assosiert med et portnummer på hver av de to vertene, som er et usignert 16-bits heltall (0-65535), inneholdt i det aktuelle overskriftsfeltet.

En TCP-tilkobling vil da bli identifisert av IP-adressene til de to vertene og portene som brukes på de to vertene.

På denne måten kan en server godta tilkoblinger fra flere klienter samtidig gjennom en eller flere porter, en klient kan etablere flere tilkoblinger til flere destinasjoner, og det er også mulig for en klient å etablere flere uavhengige tilkoblinger til samme port på samme samtidig. server.

Server og klient

De to prosessene som kommuniserer over en TCP-tilkobling har forskjellige roller:

De kjente og registrerte portene brukes deretter av serverprosesser, og er konvensjonelt assosiert med bestemte tjenester, slik at en klient vet hvilken port den skal kobles til for å nå en bestemt server.

Serverprosessen, som lytter på en bestemt port, blir sittende fast og venter på at en klient skal koble seg til. Klientprosessen ber om å etablere en tilkobling til en bestemt server på en bestemt port. Normalt tildeles kildeporten som brukes av klienten dynamisk av klientens operativsystem. Når TCP oppretter forbindelsen, blir begge prosessene tildelt en socket som de kan kommunisere med hverandre gjennom. Vanligvis gafler serverprosessen , betro barnet oppgaven med å kommunisere med den nye klienten og lytter igjen. Fra dette tidspunktet har klienter og servere symmetriske roller, og bruker de samme verktøyene for å kommunisere over stikkontakten.

Pålitelighet av kommunikasjon

Ordnet levering og eliminering av duplikater

Sekvensnummeret , eller sekvensnummeret, brukes til å identifisere og ordne posisjonere nyttelasten til TCP-segmentet i datastrømmen. Faktisk, med den typiske pakkesvitsjede overføringen av datanettverket, kan hver pakke følge forskjellige veier i nettverket og komme ut av rekkefølge ved mottak.

Ved mottak forventer TCP å motta det neste segmentet til det siste segmentet mottatt i rekkefølge, det vil si den hvis sekvensnummer er lik sekvensnummeret til det sist mottatte i rekkefølge, pluss størrelsen på nyttelasten til det ventende segmentet ( dvs. datofeltet ).

I forhold til TCP-sekvensnummeret, utfører mottakeren følgende prosedyrer:

Pakkebekreftelse og reoverføring

For hvert segment som mottas i rekkefølge, sender TCP på mottakersiden også et bekreftelsesnummer eller bekreftelsesnummer for kvitteringen. Bekreftelsesnummeret i et segment er relatert til dataflyten i motsatt retning . Spesielt er bekreftelsesnummeret sendt fra A (mottaker) til B lik sekvensnummeret forventet av A og gjelder derfor dataflyten fra B til A , en slags rapport om hva som er mottatt.

Spesielt vedtar TCP-protokollen den kumulative bekreftelsespolicyen , dvs. ankomsten av bekreftelsesnummeret indikerer til den sendende TCP at mottakeren har mottatt og korrekt videresendt til sin søknadsprosess segmentet med et sekvensnummer lik bekreftelsesnummeret som er angitt (- 1) og også alle de foregående segmentene . Av denne grunn holder sendersiden TCP midlertidig i en buffer en kopi av alle dataene som er sendt, men ennå ikke bekreftet: når sistnevnte mottar et bekreftelsesnummer for et bestemt segment, trekker den ut at alle segmentene foran dette nummeret har vært riktige mottatt, og frigjør databufferen. Den maksimale størrelsen på pakker som kan finnes kumulativt er spesifisert av størrelsen på det såkalte skyvevinduet .

For å unngå ventetider som er for lange eller for korte for hvert segment som sendes, starter TCP en timer , kalt retransmission timer RTO (Retransmission Time Out): hvis sistnevnte ikke mottar en bekreftelse ACK for segmentet sendt før timeren utløper, TCP antar at alle segmenter som er overført siden dette har gått tapt og fortsetter deretter med å sende på nytt.

Merk at, i TCP, tillater ikke bekreftelsesnummermekanismen mottakeren å kommunisere til senderen at et segment har gått tapt, men noen av de følgende har blitt mottatt ( negativ bekreftelsesnummermekanisme ), så det er mulig at kun for ett segment tapt pakke må sendes på nytt mange. Denne suboptimale oppførselen kompenseres for av enkelheten til protokollen. Denne teknikken kalles Go-Back-N (gå tilbake N segmenter); alternativet, det vil si å designe protokollen på en slik måte at bare pakkene som faktisk går tapt blir overført på nytt, kalles Selective Repeat ; imidlertid tillater bruken av noen felt bruk av selektiv repetisjon.

Bekreftelsesnumrene og de relative tilbakesendingstidtakerne gjør det derfor mulig å oppnå pålitelig levering , det vil si å sikre at alle data som sendes fortsatt leveres i tilfelle noen pakker kan gå tapt under overføring gjennom nettverket (feilkontroll når det gjelder bekreftelsesoverføring).

Flytkontroll

Påliteligheten til TCP-kommunikasjon er også garantert av den såkalte flytkontrollen, det vil si å sikre at dataflyten i overføring ikke overstiger mottakerens eller lagringskapasiteten til mottakeren med pakketap og større vekt og latenser i påfølgende forespørsler om reoverføring. Den implementeres gjennom spesifikasjonen av mottakeren av et passende felt kjent som RCV_WND ( mottaksvindu ) , en dynamisk variabel (dvs. avhengig av tilgjengelig plass) som spesifiserer det maksimale antallet segmenter som kan mottas av mottakeren. Definert:

da nødvendigvis, å ha TCP for å unngå overløp av sin egen buffer, vil vi ha:

RCV_WND = RcvBuffer - [ LastByteRcvd - LastByteRead ]

hvor åpenbart å benekte overløpet:

RcvBuffer ≥ [ LastByteRcvd - LastByteRead ]

På sin side vil avsenderen holde styr på den siste byten som ble sendt og den siste byten som ACK ble mottatt for, slik at den ikke renner over mottakerens buffer.

Legg merke til hvordan, hvis mottaksvinduet er tomt (RCV_WND == 0), vil avsenderen fortsette å sende én-byte-segmenter, for å garantere synkronisering mellom avsender og mottaker.

Flytkontrollproblemer i TCP

Det er noen strømningskontrollproblemer i TCP som oppstår både på sender- og mottakersiden. Disse problemene går under navnet Silly window-syndrom og har forskjellige effekter og årsaker avhengig av siden.

Tumt vindu på mottakersiden : hvis mottakeren tømmer mottaksbufferen veldig sakte, er det kun en liten plass ledig når mottakeren trekker ut informasjon fra mottaksbufferen (veldig lite mottaksvindu) og denne mottaksvinduverdien kommuniseres tilbake til senderen. problemet er at nå bruker senderen et veldig smalt overføringsvindu og derfor kan det skje at den blir tvunget til å sende veldig korte segmenter sammenlignet med den kanoniske headeren på 20 byte, med en påfølgende reduksjon av overføringseffektiviteten.

For å redusere dette problemet får TCP mottakeren til å "lyve" til senderen og indikerer et nullvindu inntil mottaksbufferen er tømt for halvparten eller for en del minst lik MSS (= Maximun Segment Size), og unngår dermed at senderen sender svært korte segmenter som begrenser effektiviteten til overføringen.

Denne løsningsalgoritmen kalles Clark-algoritmen.

Dumt vindu på sendersiden : oppstår når applikasjonen genererer data veldig sakte. Siden TCP leser dataene som er tilstede i overføringsbufferen ved å lage segmenter som den sender til den andre siden, i tilfelle applikasjonen genererer dataene veldig sakte, kan TCP-enheten bli tvunget til å lage veldig korte segmenter (og med mange over hodet).

Løsningen kalles Nagle-algoritmen, der kilde-TCP sender den første delen av data selv om den er kort, og når det er på tide å lage nye segmenter, opprettes disse segmentene bare hvis utdatabufferen inneholder nok data til å fylle en MSS eller til og med når den mottar gyldig tilbakemelding.

Overbelastningskontroll

Til slutt, den siste typen kontroll utført av TCP for å sikre kommunikasjonspålitelighet er såkalt overbelastningskontroll, dvs. sikre at overbelastningsfenomener i nettverket begrenses så mye som mulig på grunn av overdreven trafikk på nettverksenheter med pakketap. og større vekt og forsinkelser i påfølgende retransmisjonsforespørsler, som over tid modulerer mengden av data som overføres som en funksjon av den interne overbelastningstilstanden. Det særegne ved denne kontrollen er at den utføres ved å handle på overføringen i endene, det vil si på nettverksterminalene og ikke ved å bytte inne i nettverket takket være informasjonen som kan trekkes fra selve terminalen om tilstanden til pakkeoverføring. Nærmere bestemt, når tilstanden til intern overbelastning av nettverket har blitt "estimert" etter å ha valgt tapet av overførte pakker som en referanseparameter avledet fra feil-ACKene for bekreftelse av selve pakkene, implementeres denne kontrollen gjennom definisjonen av avsenderen av et passende felt kjent som C_WND ( congestion window ) som dynamisk tildeler, over tid, det maksimale antallet segmenter som skal overføres til mottakeren.

TCP-tidtakere

Retransmission Timer (RTO-> Retransmission Time Out)

Som beskrevet ovenfor tjener tilbakesendingstidtakeren til å verifisere at hvert overført segment er bekreftet.

Riktig innstilling av denne tidtakeren er vanskelig, men veldig viktig, da en for kort tidtaker fører til ubrukelige reoverføringer (tidtakeren utløses mens bekreftelsen eller pakken fortsatt reiser), mens en for lang tidtaker medfører venting ved faktisk tap av pakker. Det er klart at dette intervallet må være minst lik Round Trip Time , dvs. toveis reisetiden til en pakke for å returnere til avsenderen i form av ACK. Denne RTT, på grunn av den iboende naturen til pakkesvitsjing i nettverket, er typisk variabel på en tilfeldig måte. TCP justerer deretter retransmisjonstidtakeren kontinuerlig basert på et glidende gjennomsnittsestimat av rundreisetiden .

Utholdenhetstidtaker

Som forklart ovenfor, bruker TCP skyvevindusmetoden for å håndtere dataflytkontrollen som mottakeren er i stand til å akseptere fra avsenderen. Blant de gyldige verdiene i dette feltet er det også null, noe som betyr at mottakeren ber om et øyeblikkelig avbrudd av dataoverføringen.

I det uheldige tilfellet at pakken som gjenåpner vinduet går tapt, vil avsenderen av TCP-kanalen forbli på vent på ubestemt tid. For å unngå dette starter TCP en tidtaker, kalt utholdenhetstidtaker , hver gang mottakeren lukker vinduet. Når denne timeren utløper, sender avsenderen en probepakke til mottakeren, og forårsaker et svar: på denne måten kan avsenderen være sikker på at vinduet er lukket (mottar en annen pakke med Vindu-feltet satt til 0) eller frigjøre seg fra stallen ( mottar en pakke med ikke-null Vindu-felt).

Keepalive timer

RFC 793 som definerer TCP-protokollen forutser ikke spesielle handlinger som skal utføres når det ikke er noen data som skal overføres på forbindelsen . Noen implementeringer lar imidlertid periodisk overføre tomme segmenter, kalt keepalives , for å unngå å holde seg i minneforbindelser på ubestemt tid med systemer som kanskje ikke engang er aktive lenger. I mange systemer har applikasjonsprogramvaren muligheten til å velge om du vil aktivere keepalives for hver tilkobling eller ikke.

Når du bruker keepalives, er keepalive- timeren derfor til stede : den tilbakestilles når hvert segment mottas eller sendes, og når det utløper, sendes en keepalive. En typisk verdi er to timer.

Tidsbestemt vent

Den siste tidtakeren som brukes av TCP er den tidsbestemte ventetiden . I praksis, før de faktisk kobler fra en forbindelse, venter de to endene av kanalen i en tid som tilsvarer det dobbelte av levetiden til en felles pakke: Dette forhindrer at pakker fortsatt sirkulerer gjennom nettverket selv etter lukking.

Sårbarhet

TCP-protokollen er designet for første gang som et verktøy som skal brukes i lukkede og private nettverk, administrert av institusjoner eller universiteter som derfor ikke har problemet med å garantere sikkerheten; funksjoner som sikkerhet, integritet og autentisitet for kommunikasjon mellom to verter er henvist til høyere nettverksnivåer . Det finnes derfor ulike implementeringsløsninger for å overvinne denne mangelen. Resultatene av en omfattende sikkerhetsvurdering av denne protokollen, sammen med mulige løsninger, ble publisert i 2009 [1] , og studeres for tiden av IETF . De viktigste og mest utbredte metodene for å utføre et angrep på transportnivå på en kommunikasjon som er avhengig av denne protokollen er rapportert og generisk illustrert nedenfor.

Denial of service

Et Dos -angrep har som formål å sende en server inn i en endeløshet ved å okkupere alle ressursene den har til rådighet. Dette målet kan oppnås gjennom flere teknikker. En første måte er å bruke en metode som kalles SYN flood . For å åpne en TCP-tilkobling, som allerede nevnt, kreves en treveis håndtrykkmekanisme. Hvis klienten som ba om å opprette en tilkobling ikke svarer på serveren med ACK-pakken etter at den har mottatt sin SYN-ACK, vil serveren forbli på vent. Ved å bruke IP-spoofing- teknikker og gjentatte ganger sende spesialmonterte SYN-pakker og ikke den tilsvarende ACK, kan en enkelt vert forbruke store mengder ressurser på serveren som vil fortsette å lagre informasjon om falske tilkoblinger i minnet. Mulige løsninger på dette problemet er introduksjonen av tidtakere på slutten av hvilke serveren vil avbryte tilkoblingen eller innføringen av en mekanisme kalt SYN-informasjonskapsler , selv om sistnevnte har sitt eget sett med sårbarheter. Et annet angrep som tar sikte på å forbruke alle ressursene til et system er bruken av Sockstress- programvare , denne muligheten kan enkelt avverges ved å bruke retningslinjer for systemressursadministrasjon.

Tilkoblingskapring

Som tidligere nevnt, identifiseres hver TCP-pakke av et sekvensnummer som unikt identifiserer den i kommunikasjonen. En angriper som er i stand til å avskjære en TCP-økt og omdirigere pakker, kan deaktivere en TCP-tilkobling. For å gjøre dette lærer angriperen neste sekvensnummer for den pågående kommunikasjonen og lager en falsk pakke som ser ut som den neste i flyten og sender den til mottakeren i stedet for originalen. Når mottakeren mottar den falske pakken, aksepterer de den på grunn av riktig sekvensnummer, men finner en pakkelengde som er annerledes enn forventet, mister de synkroniseringen med kildeverten og lukker deretter forbindelsen. Denne prosessen kan kombineres med teknikker for ARP-spoofing eller modifisering av rutingprotokollen for å administrere pakkeflytkontroll, for å oppnå permanent kontroll over TCP-forbindelsen. Implementering av denne typen angrep var ikke vanskelig før RFC 1948 , da sekvensnummeret var lett forutsigbart takket være IP-spoofing-teknikker. Dette er grunnen til at startsekvensnummeret til dags dato er valgt tilfeldig.

TCP Veto

En angriper som i tillegg til sekvensnummeret også er i stand til å forutsi størrelsen på neste pakke kan lure mottakeren til å godta en ondsinnet pakke uten å bryte den eksisterende forbindelsen. Angriperen genererer en pakke med sekvensnummeret og med en nyttelaststørrelse for neste forventede segment, men har full frihet over dataene som skal legges inn. Når denne pakken er mottatt, godtar mottakeren den uten problemer. Når den legitime pakken mottas, blir den forkastet av mottakeren siden den allerede har mottatt en med det sekvensnummeret på den forbindelsen, som en vanlig duplikatpakke. Derav begrepet som beskriver dette angrepet: den legitime pakken nedlegges veto av den ondsinnede pakken. I motsetning til tilkoblingskapring, blir tilkoblingen aldri tapt, og kommunikasjonen fortsetter normalt etter at den skadelige pakken er akseptert. TCP Veto gir angriperen mindre kontroll over kommunikasjonen, men gjør angrepet spesielt vanskelig å oppdage. Trafikken som krever tilkoblingskapring for å sjekke tilkoblingen skjer ikke i dette tilfellet, og unngår å tiltrekke seg uønsket oppmerksomhet. Det eneste beviset på en TCP Veto-forekomst er en enkelt duplikatpakke, en normal hendelse i TCP. Avsenderen av den legitime pakken vil derimot ikke ha noen oppfatning av angrepet.

TCP Tilbakestill

I TCP-pakker er det et flagg i overskriften, kalt RST . I mange pakker er denne biten satt til null og har ingen effekt, hvis den i stedet settes til én, indikerer den for mottakeren at han umiddelbart kan avbryte forbindelsen og derfor frigjøre alle de okkuperte ressursene, siden avsenderen ikke har til hensikt å sende flere pakker. En angriper kan deretter lytte til samtalen mellom to verter, og sende en eller begge av en pakke med RST-flagget satt til én. Denne metoden lar deg avbryte TCP-tilkoblinger raskt og uten å etterlate noen spesielle spor. Angriperen må imidlertid skjule pakken ved å endre IP-adressen for opprinnelse, for å lure verten.

Merknader

  1. ^ Sikkerhetsvurdering av overføringskontrollprotokollen (TCP) ( PDF ), på cpni.gov.uk. Hentet 23. desember 2010 (arkivert fra originalen 6. mars 2009) .

Relaterte elementer

Andre prosjekter

Eksterne lenker