FTP

A lap 2010. november 7., 13:40-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 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úlius) 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álaszkó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. Továbbá 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. Kiegészítőkre példák: biztonsági kiegészítések, többnyelvűség támogatása, egységes könyvtárlistázás, illetve 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 kicsoda is ő
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 Biztonság

Mivel az FTP nem biztonságos, nem támogat titkosítás, hitelesítést, a jelszavak plain textben közlekednek, szükségessé vált bevezetni olyan megoldásokat, melyekkel ezek orvosolhatóak.

RFC 2577: Ez az RFC kiemel néhányat az FTP biztonsági hiányosságaiból (támadási lehetőségek). Ezek némelyikére egyszerű megoldásokat nyújt, másokra csak felhívja a figyelmet.

RFC 2228: Ez a kiegészítés bevezet új, opcionális parancsokat (és a hozzájuk tartózó hibakódokat is), melyekkel a kliens megegyezhet a szerverrel egy biztonsági szintben/titkosítási módban. Lehetőség van a felhasználó biztonságos azonosítására és hitelesítésére (az eddigi plain text jelszó helyett), titkosított adat- és parancskapcsolatra. Ez a kiegészítés nem definiálja, hogy milyen titkosítási algoritmusok használhatóak, csak az egyeztetés módját adja meg.

RFC 4217: FTP with TLS, vagy ismertebb nevén FTPS. Ez az előző pontban leírt biztonsági kiegészítéseket használja fel, illetve azt mondja meg, hogy azokat hogyan kell implementálni a TLS támogatáshoz.

FTP over SSH: Ez nem az FTP protkoll kiterjesztése, a módszer lényege, hogy egy SSH kapcsolaton keresztül visszük át a csomagjainkat (tunneling), így azok élvezik az SSH által nyújtott biztonságot. Előnye, hogy UNIX rendszereken egyszerűen kiépíthető, de a kliens oldalán is szükséges egy SSH kliens megléte, így nem használható olyan esetekben, amikor szeretnénk, hogy minél több felhasználó tudjon probléma nélkül csatlakozni hozzánk.

SFTP: Ennek még annyi köze sincs az FTP-hez, mint az előbb említett módszernek, leginkább nincs is köze hozzá, csak a tisztán látás érdekében sorolom fel itt. Ez a módszer az SSH kapcsolaton keresztüli fájlátvitellel foglalkozik. Nem ugyanaz, mint az előbb említett módszer, ott az SSH-t csak alagutazásra használtuk, de a szerveren szükség van egy FTP szerverre. Itt a fájlátvitel az SSH protokoll része, és mindössze egy SSH szerver szükséges hozzá.

A biztonságnak azonban ára van: Ha NAT mögött van a szerver vagy a kliens, akkor a NAT feladata a protokoll üzeneteiben az IP cím és portszám lecserélése olyanra, amit a helyi hálózaton kívülről is el lehet érni. A titkosított adatfolyamban azonban a NAT ezt nem tudja megtenni.

8 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.

9 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.

10 Könyvtár listázás

A könyvtár listázás formátuma nincs egészen megszabva, ami azt illeti, nem is akarták megszabni. Idézet az RFC 959-ből:

Since the information on a file may vary widely from system to system, this information may be hard to use automatically in a program, but may be quite useful to a human user.

drwxrws---    2 536      536            71 Sep 23  2008 RCS
-r--r--r--    1 536      536          1912 Aug 05  2007 README
-r--r--r--    1 536      536           578 Mar 18  2003 README_ABOUT_BZ2_FILES
drwxrwsr-x    7 536      536            93 Jul 22  2005 dist
-r--r--r--    1 536      536          2322 Sep 23  2008 index.html
drwxrwsr-x   12 536      536           150 Apr 21 20:40 linux
drwxr-x---    2 536      536             6 Oct 27  1998 lost+found
drwxrwsr-x    3 536      536            18 Sep 23  2008 media
drwxrwsr-x   20 536      536          4096 Jun 25 22:34 scm
drwxrwsr-x    3 536      536            59 Nov 05  2003 site
drwxrwsr-x   13 536      536           154 Aug 22  2009 software
drwxr-sr-x    3 536      536            22 Apr 30  2008 tools

drwx------    2 1002       users            4096 Oct  5 08:06 .
drwx------    2 1002       users            4096 Oct  5 08:06 ..
-rw-r--r--    1 1002       users              69 Oct  5 08:03 FTP_test2.txt

A fenti két minta között elsőre nem szembetűnő, de bosszantó eltérések vannak:

a fájl tulajdonosának és csoportjának megadása névvel vagy számmal történik? Vagy vegyesen?
a dátum
- első mezője a hónap 3 betűs angol rövidítése (lexikografikus rendezést megöltük)
- második mezője a nap sorszáma. De bevezető nullákkal vagy anélkül? (lexikografikus rendezést felnégyeltük)
- harmadik mezője pedig vagy évszám vagy időpont. Akkor időpont, ha idén történt a módosítás. (lexikografikus rendezést elhamvasztottuk)
- időzóna?
- egyáltalán az ott a módosítási idő?
a mezőket egynél több whitespace karakter is határolhatja, azért, hogy szemmel ránézve szép oszlopos rendezettséget lássunk

FTP