Hvis du gikk glipp av forrige artikkel i denne serien kan du lese, etter Forstå ICMP-protokollen (del 1)
.

Vel, vi vet nå at ICMP er faktisk en veldig viktig protokoll i den store sammenhengen. Uten den ville vi aldri vite hva som skjedde i tilfelle av en feil som oppdages av våre pakker på nettverk eller Internett for den saks skyld. Det er derfor ICMP er en av de fire grunn protokoller. Alle TCP /IP stack implementeringer har disse fire kjerne protokoller i dem for at svært grunn. De trengs for operativsystemet til å fungere, og kommunisere effektivt. Uten dem datamaskiner ikke ville fungere og Internett ville ikke være slik vi kjenner den i dag.

På dette notatet, hvor om vi tar en titt på noen andre ICMP feilmeldinger som vi sannsynligvis vil møte. Møte som er, hvis du var sniffing tilkoblingen, og dermed samle pakker.

Det er ingen som lytter

Vi vet at hvis du sender en TCP /IP-pakke til en port som ikke har en tjeneste å lytte på det, at du vil få en RST pakke tilbake. Dette gjør at du vet at det er ingen tjeneste der. Hva skjer hvis du sender en UDP /IP-pakke til en port som har ingen UDP basert tjeneste lytte på den? Vel noe helt annet enn hva som skjer med en TCP basert tilkobling. La oss ta en titt på pakken nedenfor for en forklaring på hva som skjer.

00: 00: 05,579927 192.168.1.100 > 192.168.1.200: ICMP: 192.168.1.100 udp
port 64032 uoppnåelig plakater (DF) (ttl 50, id 64521, len 56)
0x0000 4500 0038 fc09 4000 3201 97fc c0a8 0164 E..8 .. @. 2 .... 'Z.
0x0010 c0a8 01c8 0303 01C9 0000
0000
4500 00f2
............ E ...
0x0020 d385 4000 F011 01b6 c0a8 0164 c0a8 01c8
.. @ ..... ..... 'Z.
0x0030 0035 FA20 00de 0000
0,5 ......

Når du sender en UDP basert pakke til en port som port 53 (DNS-protokollen lytter på port 53), men det er ingenting der, målmaskinen ville generere en ICMP basert pakke. Pakken ville ganske mye akkurat ser ut som den ovenfor. Det er på tide å innse nå at UDP og ICMP har en slags symbiotisk forhold. Mens TCP vil ha RST pakker, og slik sendt tilbake, vil UDP imidlertid ha ICMP feilmeldinger i stedet. Disse meldingene vil indikere hva som skjedde med den pakken som ble sendt.

Så hva betyr "udp port 64032 unreachable" egentlig betyr? Vel, det betyr at målmaskinen faktisk ikke har en tjeneste som kjører på den. For eksempel hvis målportnummeret var 53, da det ville bety at det ikke er noen DNS-server som kjører på datamaskinen. Dette er hvordan kildedatamaskinen vil finne ut at det er ingen slik tjeneste. Den resulterende ICMP feilmelding ville fortelle det så mye.

Det er vel og bra, men hvordan gjør at ICMP feilmelding fortelle kildedatamaskinen nøyaktig hva pakke det var som forårsaket ICMP feilmelding skal genereres? Det er et utmerket spørsmål. Måten at ICMP fungerer er at det vil bruke IP å bære den rundt, og følge den faktiske ICMP header vil være IP header, og første åtte byte av transportprotokollen som faktisk forårsaket feilen å begynne med. En smule forvirrende, skjønner jeg, men vennligst se på pakken ovenfor. Jeg har understreket den delen som viser den opprinnelige pakken som forårsaket ICMP feilmelding til å begynne med. Som i sin tur blitt returnert til sin eier via IP, og ICMP packet header.

Denne måten når kildedatamaskinen mottar denne ICMP feilmelding det vil se på IP header blir gjennomført, og transportprotokollen også. Husk nå, at i løpet av de fire første byte av transportprotokollen, er portnumre. Både avsender og mottaker er der. På denne måten kildedatamaskinen er i stand til å fortelle hvilken prosess det var som trengte å bli gjort oppmerksom på feilen dvs .: port 1 124, og dette er det flyktige port som ble tilordnet til Internet Explorer var det startet opp av brukeren.

Nå kan vi også fortelle hva eksakt type ICMP feilmelding dette er av type og kode. Dette er sett i det ovenfor fet skrift del av pakken. Dette er standard ICMP spissen. Vennligst nå se i TCP /IP jukselapp, å bryte ut feltene.

0303

Den første 03 refererer til den type ICMP feilmelding, og i dette tilfellet arket forteller oss at er Type "Destination Unreachable". Etter det er en annen 03 og som refererer til koden, som er "Port Unreachable". Så langt så bra, så dette er akkurat hva pakkene forteller oss i ascii i overskriften delen.

01C9

Denne verdien er sjekksummen av ICMP spissen. Hvis du husker hver kjerne-protokollen har en sjekksum feltet. Dette er beregnet ved kilden datamaskinen, og deretter omregnet ved målmaskinen. Det i utgangspunktet brukes til å sørge for at protokollen header selv ikke ble skadet på vei til sin destinasjon. Det eneste unntaket er UDP, som ikke trenger å bruke sjekksummen verdi i seg spissen. De siste fire byte som vist ved den 0000 0000 er rett og slett settes til null som det ikke er noe bestemt melding som skal transporteres i overskriften.

At ganske mye brytes opp målet nås feilmelding. Det siste vi vil se på er "admin forbudt filter" feilmelding.

00: 00: 13,953415 192.168.1.100 > 192.168.1.200: ICMP: host 192.168.1.200 nås - admin forbudt filter plakater (ttl 255, id 57951, len 56)
0x0000 4500 0038 e25f 0000 ff01 81e6 c0a8 0164 E..8._. ........ en
0x0010 c0a8 01c8 030d fcf2 0000 0000
4500 001c
..Y ......... E ... < BR> 0x0020 30f2 0000 3a01 6848 c0a8 0164 c0a8 01c8
0 ...:.. hH..Y ... en
0x0030 0800
< U> 6f16 a8c3 e025
..o ....%

Denne typen budskap var etter all sannsynlighet generert av en ruter. I all sannsynlighet, ruteren som har bestemmelses kilden IP vist ovenfor. Denne konfigurasjonen vil bli gjort av administrator av ruteren som har kanskje satt en ACL sperrekommunikasjonsforsøk fra kilden IP i spørsmålet. Dette er ofte gjort av noen selskaper hvis de finner gjengangerne som prøver å trenge inn i sine nettverk. De vil rett og slett sette opp en ACL nekte tilgang til IP i spørsmålet. Det ville i sin tur genererer meldingen ovenfor.

Nok en gang, jeg har uthevet ICMP header, og understreket IP og protokoll at IP var bærer når den opprinnelige feilen ble opprettet. Kan du finne ut hva protokollen var at fulgt IP header i denne pakken? Jeg har uthevet de to første byte av protokollen. Det var faktisk en ICMP Echo forespørsel som ble sendt, og som resulterte i ruteren si NEI! Vi tillater ikke ICMP ekko forespørsler om å bli akseptert. Det er derfor vi så "admin forbudt filter" -melding. Admin sette opp ruteren til å nekte noen inngående ICMP Echo forespørsel pakker.

Vel som du nå kan se det er faktisk mye å ICMP-protokollen. Det er nok flere ICMP feilmeldinger, noe som kan genereres. Jeg vil oppfordre deg til å prøve deg på pakke laging. Dette vil tillate deg å sette teori ut i praksis. På den måten kan simulere ulike pakke forhold, og deretter studere svarer pakker. Det er en fin måte å lære mer om TCP /IP. På dette notatet, jeg håper du fant denne artikkelen til nytte for deg, og jeg tar gjerne imot kommentarer. Til neste gang!

Hvis du gikk glipp av forrige artikkel i denne serien kan du lese, etter Forstå ICMP-protokollen (del 1)
.