File Transfer Protocol (FTP) Problem och lösningar

Transkript

1 File Transfer Protocol (FTP) Problem och lösningar Fredrik Pettersson Daniel Torstensson IT1 - DOIP21 TDTS09 Datornät och internetprotokoll Linköpings universitet Linköping

2 Sammanfattning Den här rapporten behandlar filöverföringsprotokollet File Transfer Protocol (FTP). Syftet är att beskriva hur FTP är tänkt att användas och hur det tekniskt fungerar för att sedan kunna utreda protokollets svagheter. Vi ska om möjligt även beskriva lösningar till protokollets problem. FTP är ett applikationslagerprotokoll som utnyttjar de underliggande protokollen TCP och IP för transport respektive adressering. FTP har en del större brister som exempelvis avsaknaden av kryptering, låg säkerhet, många anslutningar, stor initial fördröjning och avsaknad av kontrollsumma.ofta är lösningen på dessa problem att utnyttja utökningar av protokollet eller att helt enkelt använda ett helt annat protokoll. För att få en säkrare överföring kan man utnyttja olika protokoll, som exempelvis SSH, för att skicka filer med FTP över en krypterad anslutning. Avsaknaden av mer säkra överföringsalternativ gör det tydligt att FTP:s grundtankar är relativt gamla med tanke på Internets utveckling och dagens fokus på säkerhet i nät.

3 Innehållsförteckning 1. Inledning Syfte Metod och källor Avgränsningar Beskrivning av protokollet Bakgrund Underliggande protokoll Internet Protocol (IP) för adressering Transport med Transmission Control Protocol (TCP) Så fungerar File Transfer Protocol (FTP) Protokollets brister Ingen kryptering och låg säkerhet Flera anslutningar och många kommandon Avsaknad av kontrollsumma och datumstämpel Lösningar på protokollets brister Kryptering och utökad säkerhet Möjlighet till kontrollsumma Diskussion och slutsatser...6 Referenser...8

4 1. Inledning Idag ses Internet som en självklarhet för många människor. Internet används för fritidsintressen, men för många är Internet också ett obligatoriskt inslag i arbetet. Möjligheten att kunna tillgodogöra sig information via Internet eller att kommunicera med sina kontakter genom att exempelvis skicka e-post är naturligtvis mycket viktiga, men också möjligheten att kunna dela med sig av sitt material och sina filer till medarbetare är väsentlig. Detta kan idag göras på ett antal olika sätt. Ett vanligt förekommande sätt är att organisationens eller företagets anställda loggar in på en central server för att komma åt delade filer. Den anställde kan sedan jobba med filen innan denne laddar upp en uppdaterad version på servern som medarbetare sedan kan arbeta vidare med. Denna arbetsgång skulle kunna hanteras och lösas med hjälp av ett protokoll som File Transfer Protocol (FTP) (IETF, 1985). Den här rapporten behandlar protokollet FTP som används för att överföra filer. Vi kommer att använda förkortningen FTP genom hela rapporten eftersom det är en allmänt känd och använd förkortning. 1.1 Syfte Rapportens syfte är att förklara hur FTP är tänkt att användas och hur det tekniskt fungerar. Vi ska sedan utifrån dessa kunskaper utreda vilka svagheter som protokollet har. Dessutom ska vi ta reda på vilka lösningar som finns på dessa problem. 1.2 Metod och källor Rapporten är främst en litteraturstudie och för att ta reda på hur FTP fungerar har vi framförallt använt oss av olika dokument kallade Request for Comments (RFC). Dessa är dokument som innehåller tekniska beskrivningar och ledande principer angående föreslagna Internetstandarder som publicerats av Internet Engineering Task Force (IETF). IETF är en organisation som arbetar med frågor som rör vilka tekniker och standarder som ska användas på Internet (IETF, 2008). 1.3 Avgränsningar För att kunna beskriva och diskutera protokollets brister på en mer teknisk nivå har vi valt att beskriva hur FTP är tänkt att användas och hur det tekniskt fungerar. Det kändes även nödvändigt att lite kort beskriva de andra protokoll som utnyttjas av FTP, Internet Protocol (IP) och Transmission Control Protocol (TCP), för att ge läsaren ytterligare kunskap i ämnet. Vi har dock inte behandlat varje liten brist med protokollet utan har istället valt att fokusera på de största och till synes viktigaste bristerna med protokollet. 2. Beskrivning av protokollet Här ska vi beskriva mer ingående hur FTP är tänkt att användas, hur det tekniskt fungerar samt vad det har för funktionalitet. Först följer bakgrund och historia och sedan för att kunna förstå tekniska detaljer följer en kort beskrivning av de två underliggande protokollen som FTP utnyttjar. Sedan följer en mer detaljerad beskrivning av själva FTP. 1

5 2.1 Bakgrund FTP är ett gammalt protokoll, den första RFC:n som beskriver FTP publierades 1971 och beskriver en idé om ett fildelningsprotokoll. Protokollet utvecklades dock för direkt implementation på två datorer tillhörande Massachusetts Institute of Technology (MIT) (IETF, 1971). Denna RFC följdes upp år 1980 av RFC 765 och senare även av den nuvarande RFC 959 (IETF, 1980; IETF 1985). Målen med FTP är enligt protokollets RFC att gynna delning av filer, att uppmuntra användandet av fjärranvända datorer, att underlätta för användare att hantera filer trots olika filsystem eller plattformar och att överföra data effektivt och pålitligt. Det går att använda FTP direkt från en terminal, men det är avsett för att användas av en applikation. Det är alltså tänkt att användaren ska utnyttja applikationer som i sin tur utnyttjar själva protokollet, allt för att underlätta för användaren (IETF, 1985). 2.2 Underliggande protokoll Enligt modellen Open Systems Interconnection (OSI) kan man dela upp kommunikation mellan datorsystem i olika lager. Varje lager har en specifik uppgift och innehåller ett antal olika funktioner för att hantera denna uppgift som utgör en viss del av kommunikationen (Zimmermann, 1980). FTP är enligt OSI-modellen ett utav de protokoll som tillhör applikationslagret vilket är det lager som ligger närmast användaren. FTP använder sig av TCP som är ett protokoll som tillhör transportlagret. TCP utnyttjar i sin tur IP som tillhör nätverkslagret. Figuren nedan visar sambandet som, enligt Zimmermanns modell, finns mellan de lager och protokoll som vi kommer beskriva i samband med FTP. Längst upp i figuren visas applikationslagret och det tillhörande protokollet FTP. Protokoll i detta lager befinner sig närmast användaren och utnyttjar det underliggande transportlagret för transportering av data. TCP och andra protokoll i transportlagret utnyttjar det underliggande nätverkslagret och dess protokoll (exempelvis IP) för adressering av paket (Zimmermann, 1980). Applikationslager File Transfer Protocol (FTP) Transportlager Transmission Control Protocol (TCP) Nätverkslager Internet Protocol (IP) Figur 1. OSI-modellen (Zimmermann, 1980), egen bearbetning Internet Protocol (IP) för adressering Internet Protocol (IP) är ett protokoll som används för adressering av paket i paketbaserade nätverk, exempelvis Internet. Data som ska skickas via dessa nätverk delas upp i små paket och adresseras till mottagaren innan de skickas. IP lägger på ett pakethuvud (header) till varje paket med data. Detta huvud innehåller bl.a. information om avsändar- och mottagaradress så att paketen kan dirigeras åt rätt håll genom nätverket av speciella nätverksenheter som kallas för routrar (IETF, 1981a). Internet baseras idag i huvudsak på version 4 av IP-protokollet (IPv4). En IPv4-adress har en storlek på 32 bitar, antalet unika adresser är endast 2 32 stycken, vilket ses som en begränsning. 2

6 Därför har en ny version med större adressrymd utvecklats. IP version 6 (IPv6) kan ses som en möjlig efterföljare till IPv4 med en adresstorlek på 128 bitar. Även om IPv6 inte är lika utbrett som IPv4, så har många nya routrar anpassats så att protokollen fungerar parallellt (Savorić, 2004) Transport med Transmission Control Protocol (TCP) Transmission Control Protocol (TCP) är ett transportprotokoll som används i stor utsträckning på Internet. TCP utnyttjar IP och skapar pålitliga anslutningar. Det är ett felkorrigerande protokoll som garanterar att alla paket som skickas kommer fram och att de kommer fram i rätt ordning (Matthews, 2005). Detta gör att det lämpar sig perfekt just för exempelvis e-post eller filöverföring. TCP har så kallad full-duplex och möjliggör alltså sändande och mottagande av data i två riktningar samtidigt (IETF, 1981b). TCP har även funktioner för flödes- och stockningskontroll så att varken mottagare eller nät blir överbelastade (Matthews, 2005). Trestegshandskakning är en term som brukar användas då man talar om TCP. Då syftar man på hur det går till då man skapar en anslutning med TCP. När en anslutning ska skapas skickar sändaren som det första steget i handskakningen ett paket med en speciell flagga satt, nämligen kontrollflaggan synchronize (SYN). Flaggan SYN är en bit i TCP:s pakethuvud som indikerar att en ny anslutning ska initieras. Om mottagaren godtar förfrågan om skapandet av en anslutning skickar denne som svar tillbaka ett paket med både SYN- och ACK-flaggan satta. Flaggan acknowledgment (ACK) är en svarsflagga som indikerar att den godtar öppningsförsöket. Mottagarens SYN-flagga anger att denne också vill initiera en anslutning från sitt håll. Detta ses som det andra steget i handskakningen. För att bekräfta mottagarens SYN-paket så skickar klienten ett svarspaket med ACK och med detta tredje steg i handskakningen ses anslutningen som upprättad. Nu kan data börja överföras. Om mottagaren inte skulle vilja upprätta en anslutning med sändaren skickar denne istället för SYNACK ett paket med flaggan reset the connection (RST) satt och då avbryts uppkopplingsförsöket (IETF, 1981b). När någon part vill stänga ner en anslutning skickas ett paket med flaggan no more data from sender (FIN) satt. Mottagaren av FIN-paketet skickar ett paket med ACK-flaggan satt. Oftast avslutar även mottagaren sin del av anslutningen genom att också skicka ett paket med FIN-flaggan satt, men detta är inte obligatoriskt. Anslutningen är inte helt stängd förrän båda parter har skickat FIN-paket som svarats med en ACK (IETF, 1981b; Matthews, 2005). 2.3 Så fungerar File Transfer Protocol (FTP) File Transfer Protocol (FTP) är som tidigare nämt ett protokoll som enligt OSI-modellen tillhör applikatonslagret. FTP använder transportlagrets TCP för att upprätta anslutningar och därmed så används även IP. FTP används för att överföra filer från en dator till en annan. Det går att överföra filer från en FTPserver till användarens egen lokala dator, men användaren kan också välja att överföra saker från en FTP-server till en annan FTP-server genom att styra processen från en egen (tredje) dator (IETF, 1985). Som vi tidigare konstaterat är grundtanken till FTP gammal och protokollet har utökats flera gånger. Detta skedde exempelvis 1998 med FTP Extensions for IPv6 and NATs (IETF, 1998). FTP använder skilda uppkopplingar för att skicka kommandon och överföra data. Först skapas en slags kontroll -anslutning med hjälp av TCP genom den typiska trestegshandskakningen. På denna uppkoppling skickas sedan användarnamn och lösenord i klartext (okrypterat) till servern för att kunna påbörja en överföring. Denna anslutning sker oftast mot port 21 hos servern som är den standardiserade porten för FTP (IETF, 1985). 3

7 När denna kontroll -anslutning är klar finns det olika alternativ för att skapa anslutningar för filöverföring. Vi beskriver dessa olika lägen nedan: Active mode - I standardläget som kallas active mode är det klienten som öppnar en godtycklig port och skickar ett meddelande till FTP-servern innehållande vilken port den har öppnat och lyssnar på. Det skapas då en anslutning mellan klienten och servern över denna port och data kan sedan börja skickas (IETF, 1985). Passive mode - Om klienten exempelvis befinner sig bakom en brandvägg eller en router med Network Address Translation (NAT) kan klienten inte alltid öppna de portar som krävs. Istället används då ett läge som kallas för passive mode. Detta läge innebär att när klienten vill skapa en dataöverföringsanslutning skickar den en förfrågan till servern som då öppnar en godtyckligt vald port. Servern skickar sedan information om vilken port den lyssnar på efter inkommande trafik från klienten (IETF, 1985). Extended passive mode I september 1998 publicerades en RFC som kan ses som ett tilläg till den tidigare FTP-standarden. Här preciserades ett nytt läge. Detta läge kallas för extended passive mode och fungerar ungefär likadant som passive mode. Skillnaden är att serven bara skickar upplysningar om vilken port som den lyssnar på. Klienten får helt enkelt förutsätta att samma IP-adress som redan används för kontroll -anslutningen kan utnyttjas även för dataöverföringsanslutningen (IETF, 1998). 3. Protokollets brister Här tittar vi på olika brister och svagheter som vi har funnit med FTP. Vi har fokuserat på de största bristerna med protokollet.vi kommer först att behandla protokollets brister vad gäller säkerheten för att sedan gå vidare till andra svagheter, som den omständliga hanteringen av anslutningar och kommandon. Slutligen beskriver vi protokollets avsaknad av dels kontrollsumma och dels ordentlig datumstämpel. 3.1 Ingen kryptering och låg säkerhet FTP-standarden är en relativt osäker metod för att överföra filer eftersom det inte finns några som helst inbyggda krypteringsalternativ. Denna avsaknad av kryptering innebär en stor säkerhetsrisk eftersom man, då man använder sig av FTP, skickar användarnamn och lösenord i klartext. Även FTP-kommandon och filinnehållet i de filer som överförs med FTP överförs i ett okrypterat format (IETF, 1985). Detta gör att protokollet är väldigt känsligt för attacker. Det är alltså väldigt lätt av avlyssna med så kallade packet sniffer -program (program som används för att analysera nätverkstrafik, exempelvis wireshark) (Wireshark, 2008). Ett exempel på hur en attack kan göras mot en FTPserver är att när servern öppnar en port och lyssnar efter inkommande trafik så kontrollerar den inte varifrån denna trafik kommer. Detta gör att en tredjepart kan skicka en begäran att hämta en fil istället för den riktiga användaren och därmed stjäla filen utan att behöva ange varken användarnamn eller lösenord. Denna process kan naturligtvis automatiseras med hjälp av någon slags applikation som gör just denna typ av anslutningsförsök. Om detta görs slumpmässigt och upprepade gånger har man upptäckt att det förekommer en ganska stor risk att attacken lyckas (Seifreid, 2008). Med hjälp av FTP kan man dessutom öppna en godtycklig port på servern man är ansluten till. Denna funktion är egentligen till för att man ska kunna hämta filer på en annan server, men kan utnyttjas för felaktiga syften. Detta kan exempelvis utnyttjas för att skapa en så kallad FTP bounce attack. Denna attack innebär att man hoppar via ett antal servrar genom att öppna olika portar och 4

8 FTP-anslutningar. På detta sätt kan man också göra en så kallad port scan då man, ganska diskret, med hjälp av speciell mjukvara undersöker vilka portar servern lyssnar på. Då kan man bilda sig en uppfattning om hur nätverket är uppbyggt, vilket kan vara skadligt för vissa organisationer om det hamnar i fel händer. Dessutom kan en klient istället för ansluta från sin egen IP-adress, gömma sig bakom en (eller flera) FTP-servrars IP-adress och därmed dölja sin identitet (CERT Coordination Center, 2008). Det är förövrigt mycket svårt att reglera den FTP-trafik som använder active mode genom en brandvägg. Eftersom flera olika, slumpvis valda, portar används måste man öppna ett intervall med väldigt många portar som kanske inte alltid används. Detta leder då till säkerhetsrisker (IETF, 1985). 3.2 Flera anslutningar och många kommandon För att utnyttja FTP krävs flera TCP-anslutningar och för att skapa nya anslutningar krävs relativt många kommandon vilket kan anses omständligt. En speciell kontroll -anslutning krävs för skicka alla FTP-kommandon och kontrollera de andra anslutningarna som vi beskrev i avsnitt 2.2. En ny anslutning krävs sedan för varje nedladdning, uppladdning eller för en listning av alla tillgängliga kataloger. För varje ny TCP-anslutning sker automatiskt den så typiska trestegshandskakningen. Alla anslutningar kan tänkas skapa problem för brandväggar som behöver konfigureras för att kunna förstå och hantera alla dessa olika anslutningar (IETF, 1985). För att starta en anslutning med FTP krävs förutom ett antal olika paketväxlingar, utförda av TCP, också ett antal kommandon. Beroende på tillstånd måste först FTP-servern eller klienten ange vilken port denne lyssnar på. Sedan ska alla inloggningsuppgifter skickas, innan användaren kan börja utnyttja kommandon för att navigera runt på och se vilka filer som finns på servern. Detta bidrar till tidsfördröjningar innan själva datamängden börjar skickas (IETF, 1985). 3.3 Avsaknad av kontrollsumma och datumstämpel När man överför en fil via FTP och överföringen, av någon anledning, avbryts så finns det inget sätt för mottagaren att se detta. Mottagaren kan alltså inte veta om det blev ett drastiskt avbrott under överföringen eller om hela filen faktiskt överfördes korrekt. I protokollet finns ingen inbyggd kontrollsumma så att mottagaren kan hålla reda på detta. Det finns heller inte något sätt för mottagaren att få reda på detta (IETF, 1985). Då en användare begär en listning av alla tillgängliga kataloger på en FTP-server ser denne endast datum och tidpunkt då en viss fil har laddats upp till servern. Användaren kan däremot inte se när själva filen egentligen är skapad eller då den senast blev ändrad eftersom det inte finns något inbyggt stöd för detta i FTP. Det kan tänkas att många skulle uppskatta denna funktionalitet som faktiskt erbjuds på många plattformar idag (IETF, 1985). 4. Lösningar på protokollets brister I detta kapitel ska vi titta på olika lösningar (i den mån det finns några) till de svagheter med FTP som vi beskrivit tidigare i avsnitt 3 om protokollets brister. Värt att nämna kan vara att flera av de problem som finns i FTP inte har några egentliga lösningar. Ofta får man helt enkelt använda ett tillägg till FTP eller använda ett helt annat protokoll. Vad som egentligen aldrig löses inom ramen av FTP är problemet (se avsnitt 3.2) med alla de anslutningar som måste skapas och antalet kommandon som måste skickas. Inte heller det faktum att användaren inte kan se när en fil egentligen är skapad eller då den senast ändrades (se avsnitt 5

9 3.3) löses utan att använda olika tillägg till FTP. Ofta finns det många vidareutvecklingar av FTP eller helt nya protokoll som implementerar den funktionalitet som saknas i protokollets grundutförande. Exempel på utökningar ges i samband med de funktioner de implementerar. 4.1 Kryptering och utökad säkerhet Man kan endast lösa problemet med avsaknaden av kryptering om man ser utanför FTP:s egna ramar. Man kan exempelvis använda Secure Shell (SSH) för att upprätta en säker och krypterad uppkoppling och sedan skicka FTP-paketen över denna uppkoppling. Då används en tekink som kallas tunneling och med detta menas att man kapslar in FTP-paketen i SSH-paket som bildar en krypterad tunnel mellan sändare och mottagare. Det finns även andra liknande protokoll som använder Secure Sockets Layer (SSL) eller dess uppföljare Transport Layer Security (TLS) för att kryptera FTP-trafiken (IETF, 2005). Den stora nackdel med läget active mode, att man måste öppna väldigt många portar i en eventuell brandvägg för att det ska fungera så som tänkt, kan lösas relativt enkelt. Lösningen står att finna i de andra två tillstånden, passive mode och extended mode, som öppnar portar hos servern istället för hos klienten (IETF, 1985; IETF, 1998). 4.2 Möjlighet till kontrollsumma Att mottagaren ska kunna se om en fil överförts korrekt eller har blivit avbruten stöds inte i FTP (se avsnitt 3.3). För att lösa detta problem tar man hjälp av något utomstående protokoll, som servern stödjer, för att på servern beräkna en kontrollsumma. Denna kontrollsumma skickas sedan med varje paket så att klienten kan beräkna och jämföra denna och på så vis upptäcka eventuella avbrott som uppstått. När klienten väl vet om att ett avbrott har inträffat så kan den använda kommandot REST i kombination med GET som båda är definierade i FTP. Klienten skickar i REST-kommandot antalet byte som redan överförts och därmed sätts detta antal byte som startvärde att börja nästa överföringen med. Om detta följs av ett GET-kommando återupptas överföringen då där den avbröts (IETF, 1985). Vissa FTP-serverapplikationer erbjuder möjligheten att lägga in tillägg (moduler) som beräknar filens kontrollsumma. Ett exempel på detta är ett projekt med öppen källkod kallat ProFTPD som kan konfigureras med olika moduler, en del med fokus på kontrollsummor. (Saunders, 2006). 5. Diskussion och slutsatser I vår rapport har vi beskrivit hur FTP är tänkt att fungera och hur det faktiskt fungerar rent tekniskt. Vi har kommit fram till att FTP har ett antal större brister och att det till åtminstone några av dessa brister finns konkreta lösningar. FTP har följande större brister: Ingen kryptering - FTP erbjuder ingen kryptering av vare sig användarnamn, lösenord eller filinnehåll. Låg säkerhet - FTP är känsligt för olika attacker och det kan vara svårt att konfigurera en brandvägg så att den endast skyddar och inte begränsar protokollet. Många anslutningar - FTP kräver att många anslutningar öppnas över ett antal olika portar. Stor initial fördröjning - Det tar lång tid att starta en filöverföring eftersom många 6

10 kommandon och användaruppgifter ska skickas innan någon data kan börja överföras. Kontrollsummor saknas - Mottagaren har ingen möjlighet att veta om filöverföringen lyckades eller om den avbröts. Datumstämplar saknas Det finns inget stöd för att se när en fil egentligen är skapad eller då den senast blev ändrad. De flesta av problemen ovan kan dock inte lösas utan att använda helt andra protokoll. I många fall används FTP, men med olika tillägg till protokollet. Det finns i dagsläget många andra alternativ som implementerar olika lösningar på flera av de brister som finns inom FTP. I vår rapport har vi behandlat följande lösningar: För att komma runt problemet med avsaknaden av kryptering (första punkten ovan) kan man använda Secure Shell (SSH) eller andra liknande protokoll för att skapa en säker anslutning och sedan skicka filer med FTP. Problemet med active mode och antalet olika portar (andra och tredje punkterna ovan) är ett problem som faktiskt kan lösas inom FTP med hjälp av passive mode. Det går att införa kontrollsummor (femte punkten ovan) genom att utnyttja tillägg till FTP. FTP är som vi redan konstaterat ett gammalt protokoll, i alla fall om man jämför med Internets rasande utvecklingstakt. Om ett nytt filöverföringsprotokoll skulle utvecklas och släppas idag skulle det nog ha sett ganska annorlunda ut. Vi tror inte att FTP:s grundtankar skulle sett ut som de faktiskt gör med dagens stora fokus på Internetsäkerhet. De stora brister som vi har hittat angående exempelvis avsaknaden av kryptering skulle därför troligen inte ha släppts igenom utan åtgärder. Men förmodligen såg man nog främst stora möjligheter med ett standardiserat filöverföringsprotokoll. Så stora tankar kring säkerheten fanns kanske inte och man ville inte begränsa protokollet utan snarare göra det så användarvänligt som möjligt. En av grundtankarna med protokollet var ju faktiskt att uppmana till ett större filutbyte. (IETF, 1985) FTP har tydliga brister men används trots detta fortfarande av många. Vad detta beror på är svårt att säga. En del av användarna kanske inte anser att säkerheten är särskilt viktig medan andra kanske saknar kunskaper om bristerna i protokollet. Ofta används dock FTP ihop med andra protokoll för att försäkra sig om att filerna överförs på ett säkert sätt eller för att få tillgång till utökade funktioner. En tänkt minskning av FTP -användandet skulle kunna bero på att många användare går över till mer populära och moderna tekniker som exempelvis peer-to-peer -tekniken (p2p). En anledning till att många användare väljer denna teknik istället kan vara att den inte kräver att man har tillgång till en server som vid användning av FTP. (Wikipedia, 2008) 7

11 Referenser CERT Coordination Center (2008) Problems With The FTP PORT Command or Why You Don t Want Just Any PORT in a Storm, Artikel om om säkerhetsbrister i FTP från CERT/CC, organisation som arbetar med säkerhetsfrågor, CERT Coordination Center (CERT/CC), 4 januari Elektroniskt tillgänglig: < Hämtad: Internet Engineering Task Force (IETF) (2008), IETF Home Page, Internet Engineering Task Force, IETF Secretariat, Elektroniskt tillgänglig: < Hämtad: Matthews, J. (2005), Computer Networking - Internet Protocols in Action, John Wiley & Sons Inc., IETF (1971), A File Transfer Protocol, RFC 114, Internet Engineering Task Force (IETF), april Elektroniskt tillgänglig: < Hämtad: IETF (1980), File Transfer Protocol, RFC 765, Internet Engineering Task Force (IETF), juni Elektroniskt tillgänglig: < Hämtad: IETF (1981a), Internet Protocol - Darpa Internet Program Protocol Specification, RFC 791, Internet Engineering Task Force (IETF), september Elektroniskt tillgänglig: < Hämtad: IETF (1981b), Transmission Control - Protocol Darpa Internet Program Protocol Specification, RFC 793, Internet Engineering Task Force (IETF), september Elektroniskt tillgänglig: < Hämtad: IETF (1985), File Transfer Protocol (FTP), RFC 959, Engineering Task Force (IETF), oktober Elektroniskt tillgänglig: < Hämtad: IETF (1998), FTP Extensions for IPv6 and NATs, RFC 2428, Internet Engineering Task Force (IETF), september Elektroniskt tillgänglig: < Hämtad: IETF (2005), Securing FTP with TLS, RFC 4217, Internet Engineering Task Force (IETF), oktober Elektroniskt tillgänglig: < Hämtad: Saunders, TJ. (2006) ProFTPD module mod_md5, TJ Saunders, utvecklare av ProFTPD och ProFTPD module mod-md5, om modulen publicerat på Elektroniskt tillgänglig: < Hämtad: Savorić, M. (2004), Improving Congestion Control in IP-based Networks by Information Sharing, Doktorsavhandling, Tekniska Universitetet, Berlin, Elektroniskt tillgänglig: < Hämtad Seifreid, K. (2008), FTP Attacks, Kurt Seifreid om FTP Attacks publicerat på developer.com. Elektroniskt tillgänglig: < Hämtad: Wikipedia (2008), Peer-to-peer, Artikel om peer-to-peer publicerad på wikipedia.org. Elektroniskt tillgänglig: < Hämtad: Wireshark (2008), About Wireshark, publicerat på wireshark.org, Gerald Combs. Elektroniskt tillgänglig: < Hämtad:

12 Zimmermann, H.(1980), OSI Reference Model - The ISO Model of Architecture for Open Systems Interconnection, IEEE Transactions on Communications, Vol. COM-28, No 4, april Elektroniskt tillgänglig: < RightsManagement_eid= pdf> Hämtad