Laboration 2 i Datornätverk A, 5p

Institutionen för Informationsteknologi och Medier

Avdelningen för Informations- och kommunikationssystem

Laboration 2, DTEA22, 5p

VT 2005, period 4.

Protokoll- och trafikanalys

Materialet författat av Daniel Forsgren
och reviderat av Magnus Eriksson

Laborationsassistent: Magnus Eriksson, magnus.eriksson@miun.se

Inlämningsdatum: ______________________________________________

Namn, pnr och e-post för laborant(er):

________________________________________________________________

< labburk = ftp.sunet.se >

< labburk-login = anonymous >

< labburk-pass = hyshhysh >

Om inte en ”labburk” skulle vara tillgänglig av någon anledning, exempelvis om du gör labbarna på annan plats än i Universitetets laborationssalar, så kan du använda ftp-applikationen mot en publik server för att generera trafik till övningarna. Prova att pinga <labburk> för att vara säker på att den är tillgänglig. Ett exempel på en annan lämplig server är annars ftp://ftp.sunet.se/, där man kan logga in med login anonymous och godtyckligt lösenord.

Uppgift 1: Vanliga standardprotokoll- och applikationer för IP-nät

IP-paket bär oftast UDP eller TCP-data, och valet av transportprotokoll beror på vad som är lämpligast för applikationen. Oberoende av vilket transportprotokoll som ett applikationspar använder sig av i sin kommunikation (som exempelvis en webserver och en webläsare), så kommer nätverket i regel att överföra alla IP-paket lika. Nätverksrouters tar med andra ord normalt inte hänsyn till hurvida ett IP-paket i sin tur bär ett UDP-datagram eller ett segment i en TCP-konversation. Skillnaderna i överföringsegenskaper mellan transportprotokollen UDP och TCP kommer därför främst av mekanismer i protokollen, och i applikationerna som körs i de kommunicerande ändsystemen.

Applikationsprogram (och applikationsprotokoll), som kräver tillförlitlig nättransport, men inte har speciellt höga krav på en låg fördröjning, använder i regel transportprotokollet TCP. TCP-protokollet är utformat för att verka i harmoni med nätverket, och ser bland annat till att reglera bandbreddsanvändningen för att passa den i varje tillfälle tillgängliga bandbredden längst routen genom nätverket (bandbreddstillgången styrs förstås av situationen i ”flaskhalsen” efter routen). Med TCP omsänds också paket som försvunnit i nätverket (exempelvis på grund av trafikstockning i en routernod, som därmed tvingats kasta paket) automatiskt av transportlagret, utan att någon extra funktionalitet behöver implementeras ovanför transportlagret.

TCP har varit, och är fortfarande det mest använda transportprotokollet för tillämpningar över Internet, därav den populära TCP/IP-kombinationen. Med den ökade användningen av multimediatillämpningar förväntas dock andelen UDP-trafik att ständigt öka i framtida IP-nät, en bandbreddskrävande sådan tillämpning är exempelvis TV-distribution över IP-baserade nätverk.

Vilka skäl kan tänkas finnas för att föredra UDP framför TCP, för strömmande mediaöverföring över IP-nätverk?:

________________________________________________________________

Ovanpå IP-transportprotokollen TCP och UDP finns också olika standardiserade applikationsprotokoll definerade. Syftet med dessa är att mer i detalj specificera hur kommunikationen skall gå till i olika standardtillämpningar (tjänster), och applikationsprotokollen använder i sin tur något av de två standardtransportprotokollen för själva överföringen av data över nätverket. Ett vanligt exempel, som baseras på TCP-transportprotokollet, är HyperText Transfer Protocol (HTTP). HTTP är primärt till för överföring av websidor med tillhörande information, och är optimerat för detta. Två andra vanliga exempel är File Transfer Protocol (FTP) för filöverföringstjänster, och Telnet för fjärrterminallogin. FTP standardiserar hur en server som tillhandahåller ett filbibliotek skall kommunicera med klienter som ansluter till och efterfrågar olika filöverföringstjänster från servern. Till exempel så standardiseras kommandon och procedurer för att skicka, ta emot och lista filer. Telnet definerar hur en telnet-server, som exekveras på en dator som skall tillhandahålla en textbaserad fjärrinloggningstjänst till användare, skall kommunicera med klienter som begär fjärrtillgång till datorn över nätverket.

Abstraktionen ”port” är viktig i ändsystemen, och används för att man skall kunna skicka ett visst UDP eller TCP-paket till rätt applikation (applikationer kopplar sina sockets till portar på både server- och klientsidan, på serversidan är i regel vissa ”välkända” portar knutna till tjänsten). Centralt i nätverket, där ju UDP såväl som TCP överförs likvärdigt enkapsulerade i IP-paket, saknar dock portnumret mening, och det är därför normalt sett bara i de kommunicerande ändsystemen portvärdena tolkas (de hör till transportprotokollets header).

I RFC nummer 1700, sidan 15, finns standardportarna för några olika tjänster listade (en del modernare tjänster saknas dock i detta dokument).

Ange vilka tjänster som använder följande standardserverportar och transportprotokoll:

21/tcp:_________________________________________________________

25/tcp:_________________________________________________________

80/tcp:_________________________________________________________

Alla de vanliga applikationsprotokollen, som HTTP, FTP och TELNET, skickar all information i klartext (i alla dessa exempel över TCP). Detta innebär att vem som helst, som har tillgång till trafiken som passerar någon nätverksnod efter den väg som kommunikationen följer, har möjlighet att direkt läsa all information som förs över, som inloggningsuppgifter och kreditkortsnummer. Det är på grund av detta som banker och Internet-handlare numera ofta använder en krypterad version av HTTP, kallad HTTPS, för deras webtjänster (inledningen till URL:en indikerar vilket protokoll som används). Det finns även krypterade versioner av applikationsprotokoll som FTP (SFTP) och Telnet-liknande lösningar för terminalaccess (Secure Shell, SSH). En ännu generellare lösning är att kryptera all IP-kommunikation på lägre nivå (förutom IP-paketheaders – nätverksnoderna måste ju fortfarande kunna skicka paketen till rätt destination), ett standardiserat sätt att göra detta för är att använda protokollet IPSec, vilket bland annat diskuteras i RFC 2401. I sektion 3.2 av detta dokument beskrivs de två huvudsakliga protokollen för att ge trafiksäkerhet.

Vilka två protokoll nämns (skriv även ut vad förkortningen står för)?:

________________________________________________________________

Uppgift 2: Protokollanalysatorn Ethereal

Vi skall nu använda en typ av program som kan användas både för legitima såväl som illegitima syften, nämligen en fritt tillgänglig protokollanalysator (populärt kallad ”paketsniffer”), Ethereal. En annan vanlig paketsniffer, som dock saknar grafiskt användargränssnitt, är tcpdump som inkluderas med många Unix-liknande operativsystem. Ethereal, som är släppt under en så kallad Open Source-licens (närmare bestämt GNU) för en rad olika plattformar och operativsystem, finns att hämta hem och läsa mer om på URL http://www.ethereal.com/. Manualen till hela programvaran finns att hämta som Adobe pdf-fil exempelvis på denna URL, och en belysande ”FAQ” finns här. Glöm inte att även installera WinPcap om du installerar programvaran själv i Microsoft Windows.

Med en paketsniffer kan man ”snappa upp” all trafik som är tillgänglig på nätverket på låg nivå (OSI-nivå 2), och kan sedan analysera den insamlade datan på en önskad nivå och i ett önskat sammanhang, till exempel som enskilda Ethernet-frames (nivå 2), IP-paket (nivå 3), TCP-strömmar (nivå 4) och applikationsprotokolltrafikflöden (nivå 5+), till exempel HTTP. Trots namnet så kan Ethereal även användas med andra typer av underliggande nätverksgränssnitt än Ethernet. URL http://www.ethereal.com/media.html ger några exempel.

Ge tre olika fysiska mediatyper som Ethereal kan avlyssna under Windows:

________________________________________________________________

För att paketsniffern skall kunna läsa all nätverkstrafik på ett nätverksgränssnitt, så måste den ”tappa in” och läsa trafik långt ner i protokollstacken (på nivå 2). Då går den också förbi protokollstackens normala funktionalitet på högre nivåer, och man kan till exempel få tillgång till ett inkommande IP-paket som som har en destinationsport som inget program egentligen ”lyssnar på” i datorn som paketsniffern exekveras på. Det är till exempel också möjligt att läsa paket som har ett annat destinations-IP än datorn som paketsniffern lyssnar på (till exempel i en gateway där all aggregerad trafik till och från ett subnät passerar).

Säkerhetsimplikationerna av detta är uppenbara i fallet gateway/router – en illasinnad person som har möjlighet att exekvera en paketsniffer på ett IP-subnäts gateway har möjlighet att fritt undersöka all trafik som går till och från subnätet. Valet mellan ”hubbat” eller ”switchat” lokalt nät blir också viktigt för säkerheten av liknande skäl.

Förklara varför ett switch-baserat lokalt nät är att föredra framför ett hub-baserat nät ur säkerhetssynpunkt:

________________________________________________________________

Allt detta möjliggörs genom att man kan läsa data ”rått” på gränssnittet med hjälp av drivrutinen WinPcap (eller libpcap i Unix-liknande operativsystem), se mer på URL http://winpcap.polito.it/. Användaren av paketsniffern kan sätta upp kriterier för exakt vilken trafik som skall samlas in för senare analys med hjälp av ett filter-uttryck (till exempel ”tcp and dst 10.14.1.254 and port 21” för att enbart lyssna på TCP-trafik med destination 10.14.1.254 och port 21), och därmed sålla bort de potentiellt stora mängderna trafik som man inte är intresserad av.

På grund av säkerhetsimplikationerna så brukar dock användning av dessa mjukvaror kräva administratörsrättigheter i de flesta operativsystem. I Universitetets laborationssalar så får du av säkerhetsskäl inga allmänna administratörsrättigheter på datorn. Dock finns en lösning som gör att du ändå kan använda Ethereal i labbet. Detta fungerar så att du startar en ”Virtual PC”, det vill säga en virtuell separat installation av Windows XP, i en ”sandlåda” på datorn, med tillgång till några få program. För närvarande är dessa program, förutom Ethereal, en ftp-klient och en telnet-klient.

Det interface du skall lyssna på i Virtual PC-installationen har inte en IP-adress från den normala 10/8-serien, utan i stället en från 192.168/16-serien.

Uppgift 3: Headeranalys

Vår första handfasta övning med Ethereal blir att samla in lite godtycklig IP-trafik, och studera den information vi kan få ut av headerinformation på olika OSI-nivåer.

Starta Ethereal-applikationen (”Start-program-ethereal” i labbet), och välj ”Start” under ”Capture”-menyn i Ethereal. För att avgränsa mängden trafik att analysera så filtrerar vi bort alla frames som inte bär på TCP-data, detta görs genom att skriva ”tcp” i fältet ”Capture filter” innan ”OK” trycks i rutan ”capture options”. Se också till att rätt nätverksgränssnitt är valt under ”Interface”, det valda gränssnittets IP-adress syns under och bör alltså vara från 192.168.x.y om du gör labbarna i Universitetets laborationsmiljö. I annat fall skall IP-adressen för det interface som kopplar dig mot Internet visas.

Starta nu någon av ”telnet” eller ”ftp”-applikationerna. Skriv ”open <labburk>” för att koppla dig mot labburken och därmed generera trafik (det kan även komma med annan trafik, som genereras av operativsystemet eller andra applikationer, detta kan man begränsa med hjälp av tydligare filteruttryck). Tryck ”STOP” då några paket registrerats i räknarna på skärmen.

Du har nu en lista som innehåller alla frames (ramar) som Ethereal fångat upp, på grund av filtret kommer alla att vara IP-paket som bär TCP-data.

Välj ut en frame mitt i listan, som bär på ett IP-paket (varje IP-paketet är enkapsulerat i en Ethernet-frame, eller flera om paketet är fragmenterat), och svara på följande med hjälp av Ethereals headerdata-fönster (det i mitten). Glöm inte att du kan expandera varje headerinformationsgrupp med hjälp av ”+”-tecknen i kanten.

Vilken OSI-nivå berör headerinformationen under den första gruppen?:

________________________________________________________________

Framenummer: ___________________________________________________

Tidsdifferens (delta) jämfört med föregående frame: _____________________

Framestorlek i bytes: ______________________________________________

Protokoll som bärs i denna frame: ____________________________________

Källans fysiska (Ethernet)-adress: ___________________________________

(Du kan ofta också se vilken tillverkare Ethernet-hårdvaran har utifrån den fysiska adressen, då olika tillverkare tilldelas egna fysiska adressintervall).

Källans IP-adress: ________________________________________________

Destinationens fysiska adress: ______________________________________

Destinationens IP-adress: __________________________________________

Under ”Internet Protocol” kan man extrahera information ur headern för det IP-paket som ramen bär på.

Vilken OSI-nivå berör denna headerinformation?: ________________________

Time-To-Live: ____________________________________________________

Transportprotokollnummer (inom parantes): ___________________________

Headerchecksumma: ______________________________________________

Under ”Transmission Control Protocol” kommer man slutligen åt headerinformation för det specifika transportprotokoll som används.

Vilken OSI-nivå berör denna headerinformation?: ________________________

Källport: ________________________________________________________

Destinationsport: _________________________________________________

Relativt sekvensnummer: __________________________________________

Headerstorlek i byte: ______________________________________________

Uppgift 4: Studie av upprättandet och nedbrytandet av en TCP-anslutning

I denna övning ska vi studera hur en socketanslutning upprättas lite mer i detalj. En socket är en abstraktion av en virtuell koppling mellan två IP-adress- och portpar, och använder oftast transportprotokollet TCP. Bitar av kommunikationen transporteras i TCP-segment, som i sin tur bärs individuellt över nätverket i IP-paket. En socket är uppbyggd av en serversocket som används i serverprocessen (till exempel en webserver som Apache) och en klientsocket som används i klientprocessen (till exempel en webläsare som Internet Explorer). Serverprocessen lyssnar efter anslutningar från klienter på en viss port på serverdatorn (standardporten för HTTP är till exempel 80 på serversidan). Klienterna väljer en ledig port, som används för kommunikationen mot serverdatorn. Då en socket initieras utförs först en handskakning mellan klient- och serverprocesserna. Efter att denna är utförd är socketen etablerad och klar för att överföra data åt båda hållen.

Här kommer upprättandet och nedbrytningen av en socket att undersökas i FTP-fallet.

Starta först en capture-session i Ethereal. För att minska ner på mängden fångad trafik kan du förstås utnyttja något lämpligt filteruttryck, till exempel ”tcp and port x”, där x är standardporten för den applikation du studerar.

Starta nu antingen FTP-applikationen, och skriv ”open <labburk>”. Stoppa sedan infångningen i Ethereal direkt, utan att ge några ytterligare kommandon (om du kör ncftp mot ftp://ftp.sunet.se/ kan eventuellt hela inloggningen gå igenom automatiskt – då får du in ytterligare trafik efter upprättandet av anslutningen, som du får bortse från), och svara på följande med hjälp av informationen i Ethereal.

Serveradress: ____________________________________________________

Serverport: ______________________________________________________

Klientadress: _____________________________________________________

Klientport: _______________________________________________________

Då TCP-anslutningen sätts upp genomförs ett trevägshandskakning mellan de två kommunicerande parterna. En klient initierar handskakningen genom att skicka ett synkroniseringspaket [SYN] till rätt port på servern. Att ett TCP-segment är av typen [SYN] indikeras i TCP-headerns flaggfält. Kontrollera vilket värde flaggfältet i TCP-headern på det första [SYN]-paketet har i ditt fall.

TCP Flags: _______________________________________________________

Servern svarar med att skicka ett [SYN, ACK]-paket som svar tillbaks till klienten (synchronization acknowledgement), vilket ger ett annat flags-värde i TCP-headern. Kontrollera vilket det är.

TCP Flags: _______________________________________________________

För att slutföra anslutningen skickar klienten tillbaks ett [ACK]-paket till servern. Kontrollera flaggvärdet igen.

TCP Flags: _______________________________________________________

Anslutningen är nu upprättad, och kan användas bidirektionellt.

Vi skall nu också studera nedbrytandet av en TCP-anslutning. Detta görs med en fyrvägshandskakning mellan de kommunicerande parterna som upprättat en anslutning. Gör en fullständig inloggning på FTP-servern och starta sedan en ny capture-session i Ethereal. Skriv ”quit” i FTP-applikationen och stoppa sessionen i Ethereal.

Nedbrytningen görs i båda riktningar. Även nedbrytningen initieras av klienten, som först skickar ett [ACK, FIN]-paket (paket 1) till servern (acknowledgement, finish). Kontrollera flaggvärdena på detta paket.

TCP Flags: _______________________________________________________

Servern svarar nu med ett [ACK]-paket (paket 2), och börjar sedan bryta ner anslutningen även från sin sida. Redovisa (inom hakar, [ ]) vilka ytterligare två pakettyper som skickas i fortsättningen av nedbrytningen, och i vilken riktning varje paket i den går (server-klient eller klient-server).

Paket 3: _________________________________________________________

Paket 4: ________________________________

Anslutningen är nu nedbruten på normalt sätt.

Anslutningar kan också brytas ner mer abrupt, till exempel på grund av nätverksproblem, för stor fördröjning (timeout), abrupt avslutade applikationer och liknande. Då kan i stället ett enda Reset [RST]-paket eller ett [RST, ACK]-paket få bryta ner anslutningen. Testa detta genom att sniffa med Ethereal (använd inget TCP-specifikt filter i detta fall, eftersom [RST]-paket inte är del av TCP-anslutningen, dock är [RST, ACK]-paket det) medan du kopplar dig till FTP-servern, men avbryter med CTRL-C på inloggningsprompten (detta terminerar FTP-klienten abrupt). Om du kör ncftp i labbet så fungerar inte CTRL-C, stäng då i stället fönstret med ”krysset” för fönstret, så avbryts klienten.

Observerad sista pakettyp: _________________________________________

Flags-värde för detta paket: ________________________________________

Uppgift 5: Sniffning av FTP-session

I denna uppgift skall vi följa en FTP-konversation med hjälp av Ethereal, för att försöka ta reda på vad den innehåller, vilket borde gå eftersom FTP är ett okrypterat protokoll.

Starta en ny capture-session i Ethereal (använd ett lämpligt filter för att enbart fånga din ftp-session om du vill). Logga in fullständigt på en valfri FTP-server. Skriv ett kommando på webservern, till exempel ”ls” för att lista filer. Skriv sedan ”exit” för att stänga anslutningen. Stoppa sedan Ethereal-sessionen.

Högerklicka nu på något av de fångade paketen i din FTP-session. Välj ”follow TCP stream”.

Kan du se inloggningsuppgifterna: ____________________________________

Anteckna FTP-kommandon som du observerar under sessionen, med argument (till exempel USER, brukar vara rödmarkerat):

______________________________________________________________ __

________________________________________________________________

Vi skall nu testa att koppla telnetklienten till FTP-servern du nyss använde, och ge FTP-kommandon. Det kan göras genom att peka ftp-klienten till FTP-porten på servern, i stället för till standardporten för telnet (23). Starta nu telnetklienten, och skriv ”open <labburk> 21”.

Skriv in de FTP-kommandon du noterade i förra uppgiften, och notera resultatet av varje kommando. Börja med USER <användarnamn> och så vidare.

Kunde du logga in på FTP-servern med telnet-klienten?

________________________________________________________________

Kunde du hämta en fillista med telnet-klienten?:

________________________________________________________________

Vilket resultat ger kommandot HELP?:

________________________________________________________________

FRIVILLIGA TILLÄGGSUPPGIFTER (behöver ej redovisas)

Ethereal erbjuder många andra möjligheter, undersök dem. Titta speciellt efter annan typ av trafik, till exempel sådan som genereras av operativsystemet. Om du inte gör labbarna i Universitetets datorsalar kan du också ladda ner och undersöka paketdumpfiler från olika scenarion på URL: http://wiki.ethereal.com/SampleCaptures