FTP

A lap 2010. október 31., 13:08-kori változata

Az FTP, azaz File Transfer Protocol, egy alkalmazás rétegbeli protokol, melyet fájlok átvitelére találtak ki. Egy korai változata már 1971-ben megjelent RFC 114 néven. A mostani szabványt az RFC 959 írja le, mely 1985-ben készült. Azóta számos kiegészítése született, de maga az FTP szabvány azóta nem változott.

1 Története

A FTP nagyon régről indul, az első változata 1971 áprilisában jelent meg (ez még a TCP/IP előtt volt!), ez volt az RFC 114. Akkor a hálózat használatát két nagy kategóriába lehetett sorolni: direkt és indirekt. A direkt használat az volt, amikor az illető bejelentkezett a távoli számítógépre és egy terminálon keresztül úgy használta azt, mintha fizikailag is ott ülne előtte. Az indirekt pedig azt jelentette, hogy letöltök távolról egy erőforrást, a helyi gépen használom, majd ha végeztem, akkor visszatöltöm. Ez utóbbi felhasználást segítette az FTP.

Ez a legelső verzió definiálta az alapvető parancsokat és azok formátumát, ami egy kicsit eltérőek a maitől és nem hiszem, hogy ezt emberi interakcióra tervezték, ugyanis a parancsokban NULL byte is szerepel, illetve néhány számot bináris formában kell megadni. A felhasználó azonosítása csupán név alapján történt, jelszavakat nem támogatott. Akkoriban nem volt ilyen jól menő üzletág az internetes csalás.

Az RFC 133 szigorítja az üzenetek kezelését, oly módon, hogy az előző verzióban a szerver nem minden esetben küldött választ a kliensnek. Ez ebben a verzióban kötelező. Mindig a szerveré az utolsó szó. Továbbá a hibakezelés részt is kiegészítették.

Az RFC 141 inkább követelményeket fogalmaz meg, semmint konkrét protokoll javaslatokat. Ne feledjük, hogy az RFC az Request For Comments. Ez itt a komment.

Az RFC 172 az első teljesebb átalakítás, túl sok új funkciót nem ad hozzá, de az egész protokollt letisztázza, és egy külön adatátviteli protokollt (RFC 171) használ a konkrét adatcserére.

Az RFC 265 az RFC 172 kis kiegészítése, két új tranzakció típust vezet be, illetve újabb hibakódokat. (Még mindig 1971-ben járunk, novembert írunk.)

Az RFC 354 (1972. júluis) egy viszonylag nagy módosítás volt, ekkor nyerte el a mai formájának alapját. A parancsok immár tiszta ASCII, újsorral lezáva, a válaszokkódok is megkapták a mai strukturáltságukat, és bevezették, hogy az adatkapcsolatnak nem kell állandóan nyitva lennie.

Ezután számos kiegészítés keletkezett, melyek új funkciókat definiáltak, kérdéseket vetettek fel bizonyos helyzetekről. Ezeknek az eredmény lett az RFC 542 1973 augusztusában, mely kísértetiesen hasonlít a ma is használt protokollra. Változások főleg az adatkapcsolat specifikációjában, a kérdés-válasz szekvenciákban, és azokon a területeken volt, amik a TELNET protokolltől függnek. Viszont ez a verzió még mindig a TCP elődjét, a NCP-t preferálta.

Sok év szünet után 1980-ban jelent meg az RFC 765, amely legszembetűnőbb változtatása az, hogy az egész protokollt TCP/IP alapra helyezi. Plusz az elmúlt évek tapasztalatát, és a felvetődött kérdéseket, problémákat orvosolta.

A ma használt változat 1985 októberében keletkezett (RFC 959). Néhány új opcionális parancs került bevezetésre meg pár apróbb módosítás úgy, hogy az előző verzióval kompatibilis legyen. Azóta is számos kiegészítés készült, de ezek csak kiegészítések, az alap FTP maradt a régi. Például biztonsági kiegészítések, többnelyvűség, egységes könyvtárlistázás, és a sok kiegészítéssel szükségessé vált egy olyan kiegészítés is, mellyel a kliens felderítheti, hogy a szerver melyik kiegészítéseket támogatja...

2 Működése

Az FTP protokoll kliens-szerver architektúrájú. A szerver általában a 21-es TCP porton fogadja a klienseket. Az itt felépülő kapcsolat lesz a "parancskapcsolat". Ezen a kapcsolaton csak a parancsok és szerver válaszai mennek, a konkrét adatok, a fájlok tartalma egy külön adatkapcsolaton fog továbbítódni. Az adatkapcsolat felépítéséről az #Aktív vs. passzív mód fejezetben olvashatsz bővebben. Az adatkapcsolat csak egy adatfolyam erejéig szól, utána a kapcsolatot bezárják, és legközelebb újra ki kell építeni.

3 Parancsok

A teljesség igénye nélkül néhány gyakrabban előforduló parancs és jelentésük:

USER 

A (parancs)kapcsolat feléptése után a kliens ezzel mondja meg, hogy melyik felhasználó csatlakozott

PASS 

A felhasználónév megadása után ezzel lehet megadni a jelszót

LIST 

Könyvtárlistázás

DELE 

(Delete) Fájl törlése

RETR 

(Retrieve) A kliens szemszögéből egy fájl letöltése

STOR 

(Store) A kliens szemszögéből egy fájl feltöltése

APPE 

(Append) Egy feltöltés folytatása (fájlhoz hozzáfűzés)

REST 

(Restart) Egy letöltés folytatása

RNFR 

(Rename from) Az itt megadott fájlt átnevezi/áthelyezi az RNTO parancsban megadottra

RNTO 

(Rename to) A RNFR parancsban megadott fájlt átnevezi/áthelyezi az itt megadottra

MKD 

(Make directory) Könyvtár létrehozása

CWD 

(Change working directory) Könyvtárváltás

PWD 

(Print working directoy) Aktuális könyvtár lekérdezése

ABOR 

Az adatcsatornán éppen folyó fájlátvitel (aszinkron) megszakítása

4 Szerver válaszok

A HTTP-ben, POP3-ban használt válaszokhoz hasonlóan a szerver itt is egy 3 jegyből álló kódot küld válaszként, aminek az első számjegye meghatázorra a művelet sikerességét.

1xx 

Előzetes pozitív válasz (elkezdte végrehajtani, eddig OK, de még nincs kész)

2xx 

Siker

3xx 

Közbenső pozitív válasz (a felhasználónak további parancsot kell kiadnia, hogy a műveletet el tudja kezdeni a szerver, pl. RNFR és RNTO, vagy USER és PASS)

4xx 

Ideiglenes hiba, a felhasználó újrapróbálkozhat a kéréssel

5xx 

Permanens hiba, nem érdemes újrapróbálkozni ugyanezzel a kéréssel

5 Aktív vs. passzív mód

A szerver szempontjából a kliens lehet aktív vagy passzív. Ennek az adatkapcsolat felépítésében van szerepe. Az aktív kliens tud kapcsolatot fogadni, a passzív nem. A kliens minden adatkapcsolat felépítése előtt küld a szervernek egy PORT vagy egy PASV parancsot, ami meghatározza, hogy a kliens most aktív vagy passzív kliensként fog viselkedni. Ez egy adatkapcsolatig szól, tehát egy parancskapcsolat során tetszőleges sorrendben, tetszőleges számban lehet aktív illetve passzív egy kliens.

Az aktív kliens egy PORT parancsot küld, melyben megad egy IP címet és egy portszámot. A szerver a 20-as TCP portjáról ide fog csatlakozni, és ezen az adatkapcsolaton fogja elküldeni vagy fogadni az adatokat.

A passzív kliens egy PASV parancsot küld, amire a szerver válaszol egy IP és portszám párossal, ahova a kliensnek kapcsolódnia kell. Ha ez megtörtént, akkor indulhat az adatátvitel.

Az IP cím és portszám elküldése egy furcsa formában történik. Az IP cím 4 bájtos, a portszám 2 bájtos. Ezt a 6 bájtot küldik el decimálisan, vesszővel elválasztva. Példa:

PORT 127,0,0,1,20,10

Az IP cím jól kiolvasható: 127.0.0.1. A portszám már kevésbé. Az 20-as a portszám felső bájtja, a 10-es az alsó. Visszaalakítani a következő képlettel lehet: 256*20 + 10. C nyelven akár így is: 20 << 8 + 10. A fenti portszám az 5130 akar lenni. További példa a #Minta session fejezetben olvasható.

6 FXP

A protokoll nem szabja meg, hogy a PORT parancsban milyen IP címet kell megadni, olyat írok oda, ami nekem jól esik. Ezt kihasználva egymásnak lehet ereszteni két FTP szervert úgy, hogy az "A" gépnek PASV parancsot küldök, a "B" gépnek pedig egy PORT parancsban elküldöm az "A" által visszaadott IP-t és portszámot. Az ötlet az, hogy a felhasználónak kis sávszélessége van, a szervereknek meg nagy, így két szerver között átvihetek gyorsan egy fájlt anélkül, hogy az a felhasználón keresztülmenne (kikerültük a szűk keresztmetszetet).

7 Defektek, hibák, hátrányok

• A protokollt eredetileg interaktívra tervezték, azaz, hogy a felhasználó majd kézzel pötyögi be a parancsokat és olvassa a válaszokat. Ezért a szabvány nem specifikálja a könyvtár listázás formátumát. Olvasni mindenki tud, de egy programból feldolgozni elég nehézkes: van-e fájlméret mező, van-e dátum mező, milyen sorrendben jönnek...
• Aktív módban a szervernek kapcsolódnia kell a kliensekhez. Erre nehéz jó tűzfalszabályt létrehozni.
• Aktív módban, akár kliens, akár szerveroldalon vagyunk, NAT használata esetén címfordítást kell végeznie az átjárónak, átírni az üzenetben az IP címet (és portszámot), hiszen a helyi hálózaton pl. 192.168.1.3 a címünk, de ebből a túloldal nem fog tudni hozzánk kapcsolódni. Ráadásul ha titkosított kapcsolaton megy az FTP, akkor ezt nem is tudjuk megtenni.
• A PORT paranccsal lehet port scannelni. Ha sikerült kapcsolódnia, akkor az adott port nyitva van, ha nem, akkor nincs. Védekezés: csak azt az IP címet fogadja el PORT parancsban, amin éppen folyik a parancskapcsolat. Ezzel megöltük az FXP lehetőségét.
• A PORT paranccsal lehet levelet küldeni. Feltöltünk a szerverre egy fájlt, ami egy levél küldéséhez szükséges SMTP parancsokat tartalmazza. A PORT parancsban egy SMTP szerver IP címét adjuk meg, portszámnak pedig a 25-öst. Az SMTP szerver fogadja a kapcsolatot, az FTP szerver pedig elküldi neki a fájlt, azaz elküldi az SMTP parancsokat. Védekezni FTP oldalról az előző pontban leírtaknak megfelelően.
• A PASV parancs kiadása utána a szerver vár egy kapcsolatra. Ha az eredeti kliens helyett egy támadó csatlakozik oda hamarabb, akkor a támadó tölthet fel fájlt / fogadhatja a letölteni kívánt fájlt. Természetesen az eredeti felhasználó nevével és jogosultságaival. Ehhez vagy le kell hallgatnunk a parancskapcsolatot vagy kitartóan próbálkozni a szerver összes portján, előbb-utóbb majd csak összejön. Védekezés az előző pontban leírtakhoz hasonlóan: csak onnan fogadunk el kapcsolatot, ahova a parancskapcsolat is szól. Ez megintcsak ellehetetleníti az FXP-t.

8 Minta session

A mintában az "S:" kezdetű sorokat a szerver küldte a kliens felé, a "C:" kezdetűket pedig a kliens a szervernek.

S: 220---------- Welcome to Pure-FTPd [privsep] [TLS] ----------     // \
S: 220-You are user number 1 of 5 allowed.                           // |
S: 220-Local time is now 08:02. Server port: 21.                     //  > Banner
S: 220-This is a private system - No anonymous login                 // |
S: 220 You will be disconnected after 10 minutes of inactivity.      // /
C: USER vki                                                          // - Felhasználónév
S: 331 User vki OK. Password required                                // - 3xx-es visszatérési kód,
                                                                     //   azaz vár még valamire a
                                                                     //   szerver: jelszóra
C: PASS jelszo                                                       //   A jelszó plain textben van.
S: 230-User vki has group access to:  users                          //
S: 230 OK. Current directory is /                                    //
C: PORT 127,0,0,1,10,10                                              // - PORT parancs > aktív mód,
                                                                     //   a szerver fog csatlakozni
S: 200 PORT command successful                                       //   a klienshez.
C: STOR FTP_test.txt                                                 // - Fájl feltöltés
S: 150 Connecting to port 2570                                       // - Létrejön az adatkapcsolat
S: 226-File successfully transferred                                 // - Átvitel sikeres volt
S: 226 9.134 seconds (measured here), 7.55 bytes per second          //
C: PASV                                                              // - PASV -> most passzív
                                                                     //   módban vagyunk
S: 227 Entering Passive Mode (127,0,0,1,175,57)                      // - A szerver megmodja hova
                                                                     //   csatlakozzon a kliens
C: LIST                                                              // - Könyvtárlistázás
S: 150 Accepted data connection                                      // - Létrejött az adatkapcsolat
S: 226-Options: -a -l                                                //
S: 226 3 matches total                                               //
C: PASV                                                              // - Ismét passzív mód
S: 227 Entering Passive Mode (127,0,0,1,20,4)                        //
C: RETR FTP_test.txt                                                 // - Fájl letöltés
S: 150 Accepted data connection                                      //
S: 226-File successfully transferred                                 //
S: 226 0.000 seconds (measured here), 1.07 Mbytes per second         //
C: RETR nonexistentfile                                              // - Nem létező fájl letöltése
S: 550 Can't open nonexistentfile: No such file or directory         // - 5xx-es hibakód
C: RNFR FTP_test.txt                                                 // - Átnevezés erről
S: 350 RNFR accepted - file exists, ready for destination            // - 3xx-es visszatérési
                                                                     //   kód: vár valamire
C: RNTO FTP_test2.txt                                                // - Erre
S: 250 File successfully renamed or moved                            // - Sikeres átnevezés
C: QUIT                                                              // - Kilépés
S: 221-Goodbye. You uploaded 1 and downloaded 1 kbytes.              // - Köszönj szépen :)
S: 221 Logout.                                                       //

A fenti sessionből nagyon is látszik, hogy ezt a protokollt tényleg emberi interakcióra tervezték. A szerver szinte mindig teljes mondattal válaszol, a végén elköszön tőlünk, olyan statisztikákat közöl, amit egy gépi kliens simán megmérne magának, de nyilván az embernek érdekes (milyen gyors volt a letöltés, session végén összesítés, hogy mennyi adatot küldtem/fogadtam.). Valójában a válaszok formái, a közölt statisztikák szerverprogramonként változhatnak, a 3 jegyű visszatérési kódok viszont kötöttek.