Eksamensprojekt IT Sikker netværkskommunikation Af Nicklas Bo Jensen Klasse 3.4 RTG Vejleder: Piotr Dzierzynsky Side 1 af 14
Indholdsfortegnelse Indledning... 3 Netværk... 4 Sniffing... 4 Løsning... 6 Resultat/konklusion... 12 Ordforklaring... 13 Kilder... 14 Side 2 af 14
Indledning Jeg har valgt at arbejde med opgave A, fra projektoplægget, som handler om et lokalt problem man skal løse eller et område man vil belyse. Jeg vil arbejde med kommunikation, navnlig mellem to computere. Jeg vil kigge på netværk, client/server, kommunikationsprotokoller og herunder de problemer der er i forbindelse med netværkskommunikation, og her kigge på beskyttelsemåder og kryptering. I vores daglige brug af computeren, sender vi mange informationer over netværk og ud på internettet, nogen gange uden at tænke på hvem der kan læse de informationer vi sender. Mange tænker over om deres informationer bliver sendt sikkert, når de handler på internettet og bruger deres dankort, men mange af de kommunikationsprotokoller vi bruger til hverdag er usikre, og uden kryptering. Fx http, ftp og pop3, som bliver brugt i hele verden i stor stil hver dag, uden tanke på om der er nogen der læser med. Et eksempel på hvordan folk kan lytte med er ved hjælp af en type programmer der bliver kaldt en sniffer, den lytter på netværket efter pakker og opsnapper kodeord osv. En søgning på Google på 'sniffer' giver over 10 millioner resultater, hvor en stor del er sniffer programmer. Man kan altså stille et stort spørgsmåltegn ved hvor godt beskyttet vores informationer er? For at vide hvordan man kan beskytte sig, må man undersøge hvordan man kan blive angrebet, hvordan ens informationer kan blive 'stjålet'? I dag ved stort set alle at man skal passe på fx virus, og at der generelt er nogen der har adgang til ens computer udefra. Jeg vil begrænse mit projekt til, hvad der kan ske når vi kommunikerer med omverdenen, efter at vores data har forladt vores computer. Side 3 af 14
Netværk Vores netværkskommunikation kan beskrives med OSI modellen. Generelt går det ud på at vi har to programmer, der kører på hver sin computer, som gerne vil snakke med hinanden. Det sker igennem en masse protokoller, ledninger, Kommunikatkion switche osv. Modellen er her tegnet uden alle de forskellige lag, men det der kendetegner den, er at hvert lag i stakken udfører en bestemt opgave. Og hvert lag kan kun kommunikere med de lag der ligger ovenover og nedenunder. Applikation Applikation Hardware Applikation Hardware kunne være fx http eller FTP protokollen. Mens Fysisk de protokoller, man nok kender bedst der lægger mellem applikation og hardware er TCP og IP. Internet Protocol er en unik adresse(indenfor et givent netværk) og bliver brugt til at tilgå computere. Den nuværende version IP4, består af 4 tal der er opdelt af punktummer. Nogen IP adresser er dog reserveret til specielle formål, fx 127.0.0.0 er reserveret til loopback. Localhost(den lokale computer), er fx altid 127.0.0.1. TCP bliver også brugt meget, og er en protokol der sørger for at de pakker der bliver sendt af sted ankommer, tabte pakker bliver sendt igen og sørger for at pakkerne ankommer i den rækkefølge de blev sendt i. TCP bruger desuden port numre til sin kommunikation. FX er http på port 80. De protokoller der bliver brugt til kommunikationen er alfa omega for at ens pakker kommer sikkert frem. Jeg har valgt at kigge på SMTP, som er en meget populær protokol der bliver brugt til mail. Protokollen sørger for at forbinde til en mailserver, og hente de mails der er på serveren. Et problem der er med SMTP protokollen, er at den sender brugernavn, password og mails som rå tekst. Nedenunder ses hvor jeg har prøvet at logge ind på en mail server, og som det kan ses er brugernavn og kodeord nemt at aflæse. Mange folk bruger deres mail program, uden at tænke over at de måske er dårligt beskyttet. Men kan man uden videre lytte til hvad en anden på netværket sender laver? Sniffing Sniffing svarer til at aflytte trafikken. Jeg har brugt programmet Wireshark til sniffing, men det er ikke let at lytte med på hvad de andre laver. Problemet er at moderne netværkshardware, som en switch, der bliver brugt til at fordele forbindelser, dirigerer trafikken fra en port til en anden port, Side 4 af 14
uden at der sker noget på de andre porte. Hvis man sammenligner med en HUB, der har lidt samme funktionalitet, men den gentager alle signaler på alle porte. Så hvis der er to der sidder på samme HUB, så bliver alt hvad han foretager sig vist til de andre computere helt automatisk. Men med en switch kan man ikke umiddelbar se hvad de andre foretager sig. Jeg kunne godt forestille mig, at man på mange offentlige netværk, kunne have sin egen HUB med, og sætte den imellem switch og den router der forbindet netværket til internettet, som vist på tegningen, og på den måde opsnappe hele netværkets trafik. Switch Hub Internettet Men man behøver ikke at slæbe en HUB med for at aflytte, man kan fx lave et man in the middle angreb, udnytte en svaghed der er i ARP protokollen. Address Resolution Protocol bruges til at finde adressen på en netværksenhed. Fx når to enheder er på samme netværk, og den ene gerne vil sende en pakke til den anden bruges ARP til at finde adressen på den anden maskine. Man kan få de fleste styresystemer til at opdatere deres ARP cache, og snyde dem til at sende pakkerne til en, i stedet for fx en router. På den måde kan man aflytte en forbindelse. Der findes værktøjer der automatiserer alt det her, fx Ettercap, og ikke nok med at de modtager en af netværkets computeres trafik, så sender de det videre til routeren bagefter, så personen aldrig finder ud af at hans pakker er blevet aflyttet. Man skulle tro at det krævede at man havde fysisk adgang til et netværksstik for at lave denne type angreb. Men mange har åbne trådløse netværk, eller svagt krypterede netværk, som gør det muligt selv at misbruge hjemmenetværk. Men hvad kan man gøre for at undgå at alle ens passwords, e mails og trafik bliver aflyttet og misbrugt? Der findes netværksudstyr, der kan besværliggøre sniffing, fx switchen. Men det mest effektive værktøj, udover at sørge for at folk slet ikke for adgang til ens netværk, imod sniffing er kryptering. Billet viser idéen bag et man-in-themiddle attack Fra http://www.irongeek.com/i.php?page=security/aquickintrotosniffers Side 5 af 14
Løsning Mit produkt skal kunne skabe kommunikation mellem 2 computere, med en krypteret forbindelse, så den ikke umiddelbart kan aflyttes. Jeg har valgt at lave et chat program, som består af en server og en client. De forbinder, og kan så chatte med hinanden. Først vil jeg udvikle chat programmet uden kryptering, og så implementere krypteringen bagefter. Et af de krav jeg har til programmet er at det skal have en grafisk brugergrænseflade. Jeg har valgt at skrive programmet i Java, da Java simpelthen er et godt programmeringssprog at skrive netværksapplikationer. Koden skriver jeg i det udviklingsmiljø NetBeans, da jeg har brugt NetBeans til mine andre projekter. Jeg har udviklet programmet efter følgende tidsplan: GUI Den er blevet designet med Netbeans GUI Builder, som er en træk og slip metode, til at designe en GUI. Den er opbygget simpelt, og med et stort felt til at vise chatbeskederne. Client GUI Består af 1 tekstområde, 3 tekstfelt, 3 label og 3 knapper Side 6 af 14
Server GUI Består af 1 tekstområde, 2 tekstfelter, 2 label og 3 knapper Protokol Jeg kunne have valgt at bruge en protokol, fra en anden chat applikation, men vurderer at det er nemmere at udvikle sin egen protokol, når programmet ikke er mere avanceret. Server Client Venter på forbindelse på en indstillelig port Modtager indkommende beskeder hele tiden Sender beskeder, når de bliver skrevet Sender beskeden CHAT_SLUT når serveren stoppes Forbinder til serveren, porten er indstillelig Modtager indkommende beskeder hele tiden Sender beskeder, når de bliver skrevet Sender beskeden CHAT_SLUT når serveren stoppes Side 7 af 14
Design af system Mine programmer fungerer ved at de reagerer på brugerens input, altså når brugeren trykker på en af knapperne. Det er opnået ved hjælp af en : Start server/forbind Når serveren startes, åbnes der en socket med: ServerSocket værtssokkel = new ServerSocket(port); og der ventes på en ny forbindelse med: Socket forbindelse = værtssokkel.accept(); Til at håndtere datastrømmene, bruger jeg PrintWriter() og BufferedReader(), da de funktioner arbejder med strenge og tegn. Herefter startes en ny tråd, der i baggrunden tjekker efter nye indkommende beskeder og skriver dem ud til chatboksen. Først havde jeg lavet en uendelig løkke der tjekkede efter nye beskeder, med while(true), men det brugte 100% af cpu en. Derfor valgte jeg at lave det som en ny tråd, som jeg desuden også kan sætte til at sove: Thread.sleep(100); Så programmet sparer på cpu ens ressourcer. Der bruges readline() til at læse indkommende beskeder. Stop server/afbryd Når serveren stoppes, lukker den alle forbindelser, med metoden oprydning(). Desuden skriver den til den man chatter med iht. protokollen. Send besked Simpelt nok, skrives det der står i tekstfeltet ud til den anden chatter med ud.println(). Desuden skrives chatteksten også i chatboksen. Desuden så bliver alle undtagelser fanget med try, som det er krævet når man arbejder med netværkskommunikation i Java. Afprøvning Jeg afprøver mit system, ved at køre både serveren og klienten på samme computer. Klienten forbinder til 127.0.0.1 eller localhost. Porten jeg bruger er 5000, men man kan bruge mange porte, bare de ikke er optaget af andre programmer, så man kan fx ikke bruge port 80. Nedenunder ses en chat: Side 8 af 14
Jeg har samtidig sniffet på localhost, for at se om den sender de rigtige ting. Og passende kan jeg se alle beskeder der bliver sendt mellem serveren og klienten. Desuden passer beskeden der bliver sendt til den anden chatter, når man afbryder, iht. protokollen. Nedenunder ses resultatet af en snifning med Wireshark. Programmet er delt op i 4 hoveddele. Øverst har vi menuen, og en masse indstillinger. Her startes snifningen, ved at sniffe på localhost. Det skal bemærkes at snifning på localhost ikke er muligt på windows, da windows netværksdriverne blokerer for dette, men under de fleste linux systemer er det muligt, her er Ubuntu brugt. Anden del af programmet er de forskellige pakker der er sniffet. Næste del er indholdet af pakkerne, hvor de er fortolket, så det kan aflæses af et menneske. Sidste del er pakkens rå data. Her kan man se beskeden Hejsa indgår. Side 9 af 14
Kryptering Men problemet med det program jeg har nu, er programmet er meget sårbart ovenfor sniffing. For at afhjælpe dette problem vil jeg sørge for at forbindelsen er krypteret. I Java findes der to overordnet funktioner jeg kan bruge til dette. Java Cryptography Extension(JCE) og Java Secure Socket Extension(JSSE). JCE giver funktioner til kryptering, mens JSSE giver sikre sockets, det indebærer for eksempel SSL, som både sørger for kryptering, men også for autenticitet, altså at den der sender data rent faktisk også er den rigtige. Ulempen ved SSL, er at det kræver et certifikat, man kan godt lave det der hedder et self signed certifikat, mens et rigtigt gyldigt certifikat koster penge at få, hos en godkendt udbyder, fx Verisign. Jeg har valgt selv at lave krypteringen, her er der mange krypteringsmetoder til rådighed i JCE. Jeg har valgt at bruge en metode der hedder DES. Den er forholdsvis sikker, men dens kryptering kan godt brydes, fx er det lykkedes Electronic Frontier Foundation at bryde en streng der er krypteret med DES på ca. 22 timer. 1 Min kryptering har jeg valgt at lave i en anden klasse, der hedder DesEncrypter. Som jeg så kan kalde fra min ChatClient og ChatServer. Man kan uden videre lave en des kryptering, uden at kende den underliggende algoritme. Jeg har valgt en implementation af des, hvor jeg krypterer en streng, og så bruger de samme sockets som jeg brugte før. Den nøgle der bliver krypteret med, har jeg valgt skal være en fast altid i programmet. Mest af alt fordi det er det nemmeste at programmere, ellers skulle jeg have lavet så klienterne udvekslede en nøgle, som de så krypterer efter. Det er bare svært at lave, så det bliver svært at aflæse nøglen. Ulempen ved min måde at gøre det på, er at hvis man kender nøglen, kan man dekryptere det og på den måde at aflytte det på. Men med mindre at man har kildekoden, er det meget svært at bryde. Afprøvning Jeg har afprøvet programmet på samme måde som før, og det virkede på samme måde. Som bruger kan man ikke se at beskederne bliver krypteret når de bliver sendt og netværket. Jeg har også sniffet pakkerne under testen, og der var ikke noget af det der var læsbart, det var bare vollapyk, som jeg havde regnet med. 1 http://en.wikipedia.org/wiki/data_encryption_standard Side 10 af 14
Herunder ses resultatet af en snifning med den krypterede forbindelse, som det kan ses er den data man kan læse volapyk. Side 11 af 14
Resultat/konklusion Jeg synes mit produkt virker fint, og jeg er selv tilfreds med det. Måske kunne serveren og klienten være samlet til et program, da meget af den kode der er i hver klient er ens. Og man så kunne vælge om programmet skulle være server eller klient. Krypteringen af beskederne er også god, man kan i hvert fald ikke sniffe indholdet, men den er ikke perfekt. Des kryptering kan brydes, hvis man virkelig vil, men det kræver meget computerkraft. Man kan heller ikke skjule at samtalen finder sted, men kun gøre indholdet ulæseligt. Desuden fungerer det godt, at tjekke for indkommende beskeder i en tråd, da det er cpu venligt. En ide til videreudvikling kunne være at lave en nøgle udveksling. Så i stedet for at begge programmer har en indkodet nøgle de bruger til kryptering og dekryptering, som det er nu, så skal de genere en nøgle og udveklse denne. Fx ved hjælp af Diffie Hellman protokollen, som gør at to parter kan etablere en sikker nøgle, over en usikker forbindelsen. Matematikken bag ved protokollen er ikke specielt avanceret, og selve protokollen er også okay forståelig, men at implementere protokollen er lidt besværligt. Det ville jeg have gjort hvis jeg havde havde tid til det. Side 12 af 14
Ordforklaring Jeg har besluttet at forklare nogen af de ord jeg bruger i rapporten i en ordforklaring: Protokol En protokol er en beskrivelse af en kommunikation imellem computere. Den beskriver de regler og procedurer som skal følges for en given kommunikation. Fx http eller ftp protokollen. Sockets Det er en måde for et server program og et klient program at kommunikere over et netværk. Sockets er et interface imellem en applikation og fx TCP/IP. Der er hovedsagligt 3 typer sockets, Datagram sockets, Stream Sockets og Raw Sockets. Jeg beskæftiger med med Stream Sockets i mit produkt, som benytter sig af TCP/IP. Sniffing Det at overvåge trafikken i et netværk. Kan bruges både legitimt og til fx at aflytte personlige oplysninger, kodeord osv. TCP/IP Er den kommunikationsprotokol som det meste netværkstrafik, herunder internettet benytter sig af. Består af en masse underprotokoller som hver tager ser af en opgave. Fx TCP som sørger for selve data overførslen. TCP protokollen går op i stabilitet og ordnet levering. Altså bliver alle tabte pakker afsendt indtil de bliver modtager og de bliver leveret i den rigtige rækkefølge. Derfor er TCP ikke den hurtigste protokol til formålet. Side 13 af 14
Kilder Internetsider: http://javabog.dk/ http://java.sun.com/docs/books/tutorial/ Bøger: Java Network Programming Af Eliotte Rusty Harold O'Reilly Java Network Programming Merlin Hughes http://www.oreilly.com/catalog/javanp3/objektorienteret program Af Jacob Falk http://javabog.dk Side 14 af 14