Vybrané aplikační protokoly Telnet, SSH FTP, TFTP, NFS
Pozorování: Nižší vrstvy síťového modelu jsou implementovány jako součást operačního systému .... ...a vyšší vrstvy již jsou nad operačním systémem (jsou aplikacemi) OS V případě TCP/IP:
do transportní vrstvy včetně jsou součástí OS
Důsledek: Konkrétní forma rozhraní mezi aplikační a transportní vrstvou je závislá na implementaci (na použitém OS) !!! ... ale z pohledu ostatních uzlů to nesmí být patrné !!! ... pro ně musí být zachována jednotná “obecná představa” na rozhraní mezi T.V. a A.V. jsou porty jednotlivé porty jsou identifikovány svými čísly každá konkrétní implementace musí být transparentně “zamapována” do této představy aplikační vrstva
port oddělující prvek mezi aplikací a OS
transportní vrstva
Aplikační vrstva -připomenutí V TCP/IP neexistuje samostatná prezentační a relační vrstva ... aplikace si příslušné mechanismy musí implementovat samy (pokud je potřebují) mohou využívat pouze základní sortiment funkcí TCP/IP protokolu
Většina aplikací vychází z modelu klient/server .. počítá s existencí poskytovatelů služeb (serverů) ... a s existencí “konzumentů” služeb (klientů)
Konkrétní implementace opět závisí na operačním systému
Implementace serveru - příklady MS DOS: rezidentní program (TSR) MS Windows: úloha, proces NetWare: modul NLM Unix: proces (typu démon, bez uživatelského rozhraní) obvykle jde o proces, který běží trvale, a je spouštěn na popud operačního systému (ev. jiného procesu), ale nikoli uživatelem
Implementace klienta Obvykle běžný aplikační proces, spouštěný na přímý popud uživatele Obvykle s uživatelským rozhraním
řádkového typu grafického typu (GUI) výjimka: uživatelské rozhraní nemají klienti typu NFS, BootP apod.
Vzdálené přihlašování a protokol Telnet
Protokol Telnet Telnet - jeden z nejstarších a nejrozšířenějších prostřeků pro vzdálené přihlašování v rámci TCP/IP Snaží se nevázat na konkrétní systémové prostředí (nezávislý na OS) nabízí jen jednoduché služby, nikoli např. možnost automatického přihlašování apod.
vychází z architektury klient/server
klient dnes nejčastěji funguje na principu: terminálové emulace (terminálem již není pouze jednoúčelový terminál ale víceúčelové PC)
Telnetové spojení počítačová síť
aplikace
lokální terminálová relace
host
telnet, zajišťující funkce terminálu telnetový emulátor
vzdálená terminálová relace
A
TA1
TA2
TA3
terminál
terminál
terminál
... nebo sériová linka
T1
3
počítač, chovající se jako terminál
Telnet - základní principy Telnet server je realizován na aplikační úrovni (jako systémová úloha - démon), a nikoli “uvnitř” OS výhoda: snazší modifikace nevýhoda: je to méně efektivní než přímé zabudování do OS
telnet klient
telnet server
op. systém
op.
TCP/IP síť
aplikace
systém
Protokol Telnet Telnetd - je proces běžící na vzdáleném počítači chová se k běžícím procesům jako lokální terminál (pseudoterminál pty) přijímané a vysílané znaky ale nejsou odesílány na fyzický terminál (tty) ale ke klientovi protokolu telnet po síti
Telnet server naslouchá na veřejném TCP portu 23 po vytvoření spojení jsou data přenášena: po znacích (spolu s řídícími znaky protokolu Telnet) nebo po řádcích
V rámci protokolu jsou definovány dva režimy: domluva doplňkových parametrů (NO - Nogotiating Options) síťový virtuální terminál (NVT - Network Virtual Terminal)
Telnet Síťový virtuální terminál (NVT) imaginární obousměrné znakové zařízení vytvořené na obou koncích spojení klient přijímá znaky ve vzdáleném terminálu, transformuje je do jednotné formy NVT a odesílá je serveru server zajistí mapování kláves a řídících kódů do cílové aplikace
Domluva doplňkových parametrů (NO) umožňují oběma stranám dohodnout se na jiném, než co vyplývá z pevně daných vlastností NVT, např.: že přenášená data budou odesílána po řádcích s možností jejich lokální editace že budou používat vzdálené echo jakou velikost displeje budou používat jaký způsob řízení toku budou používat...
Telnet Klávesnice NVT pracuje poloduplexním přenosem uživatelská data jsou přenášena jako 7bitové ASCII znaky s přidaným osmým znakem: 0 – znak 1 – řídící povel
řídící znaky tak tvoří samostatnou znakovou sadu nejde tedy o řídící znaky definované v normální ASCII pro zajištění transparence se nepoužívá 8. bit (kvůli volitelné možnosti přenosu 8-bitových znaků) používá se prefixace (uvození) speciálním znakem IAC (Interpret As Command), s kódem 255 případný výskyt znaku IAC v datech se řeší jeho zdvojením.
Telnet - řídící příkazy Je možné rozdělit do 3 kategorií:
editační příkazy: umožňují mazat znak a řádku
řídící příkazy: umožňují přerušit probíhající proces, zastavit jeho výstup ...
“dohadovací” příkazy: umožňují oběma stranám dohodnout se na případných rozšířeních oproti NVT IAC - Interpret as command
Příklad:
IAC EC - smazání znaku (erase character), číselně 255 247 IAC AO - zastavení výstupu (abort output), číselně 255 245 IAC GA - povolení pokračování (go ahead), číselně 255 249
Přenos souborů, protokoly FTP a TFTP
Přenos vs. sdílení souborů Jeden ze základních nástrojů pro týmovou spolupráci: uživatelé chtějí pracovat se soubory, který se nacházejí na jiných počítačích přesněji: chtějí zpracovávat obsah vzdálených souborů, pomocí aplikací, které běží na “jejich” uzlech
Řešení má dva aspekty: přenos dat (obsahu souboru) zajištění vícenásobného přístupu
Problematika přenosu dat Přenos dat (obsahu souboru) lze zajistit v zásadě dvěma způsoby: transparentním způsobem, který je pro uživatele neviditelný NFS, SAMBA...
netransparentním způsobem, který si uživatel musí uvědomovat FTP, TFTP...
Transparentní řešení - sdílení Transparentní řešení je obvykle označováno jako: sdílení souborů (file sharing)
V rámci rodiny protokolů TCP/IP je pro sdílení souborů určen především protokol: NFS (Network File System) alternativou ze světa MS-Windows je protokol SMB
Z hlediska uživatele: je jedno, že se různé soubory nacházejí na různých počítačích uživatel pouze “vidí” rozdíl mezi místními a vzdálenými soubory
Netransparentní řešení Uživatel musí sám (explicitně) podnikat určité akce, aby získal přístup ke vzdáleným souborům
.. jde typicky o přenos celých souborů ... označuje se jako file transfer V rámci TCP/IP jsou k přenosu souborů určeny protokoly FTP (File Transfer Protocol) a TFTP (Trivial FTP) Postupem času se vyvinulo mnoho další specifických aplikačních protokolů a aplikačních řešení pro výměnu souborů mezi uživateli: DC, eMule, Gnutella...
Problémy přenosu a sdílení Protokoly pro přenos a sdílení se musí vyrovnat s mnoha úskalími, typu: rozdílnost v pohledu na soubory, jejich jména, přípony .... vlastnictví souborů, jejich atributy ..... Řešení je snazší u netransparentního přístupu
Protokol FTP (File Transfer Protocol) Je starší než rodina protokolů TCP/IP pochází již z roku 1971 (vznikl nad protokolem NCP) Teprve později “portován” nad přenosové protokoly TCP/IP
Protokol FTP: není transparentní - vyžaduje od uživatele zadávání specializovaných příkazů poskytuje uživatelům prostředky pro: kopírování souborů mezi počítači výpisy adresářů výmaz a přejmenování vzdálených souborů přechod mezi adresáři vytváření a rušení adresářů definování struktury souboru a způsobu přenosu ...
Formát dat pro přenos Formáty uložení dat na koncových počítačích se mohou lišit FTP zavádí jednotný formát dat pro potřeby přenosu konverze z/do tohoto formátu ponechává na koncových uzlech FTP přenáší data vždy jako 8-bitové byty
to umožňuje propojovat jakékoli systémy, pro které existuje FTP
Přenos dat: implicitně je obsah souboru přenášen jako spojitý proud dat (tzv. stream mode) alternativou je blokový režim (block mode), mezi bloky jsou vloženy “zarážky”, umožňující po výpadku znovu obnovit přenos souboru
další alternativou je zhuštěný režim (compressed mode) jednoduchá metoda komprese (eliminující opakující se znaky)
Implementace protokolu FTP Vychází z modelu klient/server klient je typicky aplikačním programem server obvykle systémovým procesem (démonem, rezidentním programem apod.) FTP tedy není vhodný pro jednorázovou výměnu souborů
Zajištění potřebných funkcí v rámci FTP je rozděleno mezi dva subjekty: protokolový interpret (PI, Protocol Interpreter) přenosový proces (DTP, Data Transfer Process) interpret protokolu existuje trvale, přenosový proces vzniká až na základě konkrétního požadavku přenosu
Řídící a datové spojení “distribuovanosti” na úrovni procesů (PI vs. DTP) odpovídá i existence různých druhů spojení mezi klientem a serverem: řídící spojení (control connection), pro komunikaci PI-PI řídící spojení iniciuje klient server “poslouchá” na dobře známém portu (č. 21)
datové spojení (data connection), pro komunikaci DTP-DTP využívají se přenosové služby TCP datové spojení iniciuje server (jeho přenosový proces), a je realizováno přes dynamicky přidělený port server (PI a DTP) server (PI a DTP) datové spojení řídící spojení
je tak možná i komunikace více uzlů
řídící spojení klient - složka PI
Řídící příkazy FTP obsahuje celou skupinu řídících příkazů: příkazy řídícího jazyka jsou přenášeny řídícím spojením řídící příkazy mají textovou povahu, a jsou přenášeny ve tvaru shodném s protokolem Telnet řídící příkaz jsou využívány pro: řízení přístupu (access control commands) - např. pro zadání uživatelského jména a hesla (heslo - nešifrované) nastavení parametrů přístupu (transfer parameter commands) - např. pro změnu implicitních čísel portů, pro nastavení režimu přenosu apod. výkonné příkazy (FTP service commands) - pro vlastní přenos souborů, rušení, přejmenovávání atd., pro přechody mezi adresáři apod.
příkazy řídícího jazyka mohou být vysílány “ručně”, např. pomocí Telnetu (na porty FTP)
Příklad V praxi je na straně klienta vždy implementováno nějaké uživatelské rozhraní (řádkové, grafické, ..... - které překládá vlastní jazyk do FTP uživatelský jazyk řídící jazyk GET
RETR
PUT
STORE
DIR
LIST
CD
CWD
Protokol TFTP V některých případech je implementace FTP serveru či klienta zbytečně komplikovanou záležitostí např. bootstrap bezdiskových stanic nahrávání sw do µ−proc. zařízení nahrávání sw a konf. souborů do CISCO zařízení ...
V rámci rodiny TCP/IP proto existuje “ořezaná” verze FTP pod názvem TFTP (Trivial FTP) vlastnosti: využívá přenosových služeb protokolu UDP (FTP využívá TCP) TFTP si spolehlivost zajišťuje sám TFTP využívá jednotlivé potvrzování a přenáší data po blocích velikosti 512 bytů
TFTP - odlišnosti od FTP TFTP nezajišťuje na vzdáleném počítači žádné systémové akce typu ls, cwd, rm apod. TFTP nezná pojem aktuálního adresáře uživatel musí explicitně zadat úplnou přístupovou cestu k souboru, který má na mysli (a musí jej znát)
TFTP nezná pojem uživatele nezajišťuje žádné přihlašování na vzdáleném počítači definice TFTP ponechává na implementaci, jak se vyřeší přístupová práva proto pozor na prezentování TFTP do vnější zóny
zapínat pouze na konkrétní akci
Transparentní sdílení souborů a protokol NFS
Transparentní sdílení souborů Pro uživatele není rozdíl mezi vzdálenými a místními soubory uživatel si nemusí uvědomovat existenci síťového prostředí a příslušných mechanismů sdílení
uživatel ani nemusí vědět, kde se požadovaný soubor nachází např. v případě připojení pomocí příkazu mount
požadavek na přístup k souboru
posouzení požadavku a jeho správné nasměrování
Operační systém - redirector
síť
Praktická realizace - aspekty Realizace vychází z modelu klient / server V rodině protokolů TCP/IP je velmi rozšířen: NFS - Network File System
pochází od firmy Sun Microsystems původně byl proprietárním řešením posléze byl NFS předložen IAB (IETF) ke standardizaci dnes je standardem (RFC 1094) a jeho specifikace jsou public domain na platformě M$-Windows však většinou ne free
dnes je implementován snad na všech platformách připouští, aby klient i server stáli na různých platformách
Protokol NFS - vlastnosti NFS je bezestavovým protokolem každý jednotlivý požadavek klienta vůči serveru je “uzavřen” - před a po provedení příkazu se server nachází ve stejném stavu
velmi to zjednodušuje zajištění korektnosti komunikace klienta a serveru (reakci na nestandardní situace, výpadky, ..) bezestavovost NFS je klíčem k velké robustnosti NFS
bezestavový charakter připouští pouze použití idempotentních operací (takových, které lze vícekrát opakovat se stejným efektem) nelze např. používat příkazy typu “pošli mi další část souboru XY” mohou to být pouze příkazy typu “pošli mi M bytů souboru XY, počínaje bytem N”
Otázka: Je možné realizovat všechny požadavky na přístup k souborům pomocí idempotentních operací? NE!!! nelze např. provést OPEN (otevření), a soubor ponechat otevřený, obdobně pro CLOSE řešení: pro každý požadavek je soubor znovu otevřen a zavřen
Některé případy nelze obejít, jako u OPEN a CLOSE uzamknutí souboru pro potřeby vícenásobného přístupu APPEND (přidání za aktuální konec souboru)
NFS řeší zákazem takovýchto operací (např. u APPEND), nebo jejich přesunutím mimo (vně) NFS (např. u uzamykání) do vyšší vrstvy
Důsledek: Díky svému bezestavovému charakteru může být NFS velmi efektivní nemá velké nároky na kvalitu a charakter přenosových služeb v rámci TCP/IP vystačí i s protokolem UDP
Protokol NFS - multiplatformnost NFS si klade za cíl být multiplatformní nemůže se proto vázat na konvence žádné specifické platformy nelze např. používat specifické vyjádření přístupové cesty např.: c:\doma\prace\neco.txt – UNIX nepřečte
pro odkazy na konkrétní soubory se v rámci NFS používají: systémové identifikátory (file handles)
pro klienta: jednoznačný identifikátor souboru nebo adresáře
pro server: handle obsahující: systém souborů identifikaci serveru ...
systémové identifikátory přiděluje server, klient je pouze používá systémové identifikátory mají absolutní povahu a nikoli relativní, NFS nezná pojem aktuálního adresáře
Systémová identifikátory - handles Když klient vlastní systémový identifikátor adresáře může si vyžádat výpis jeho obsahu součástí výpisu je seznam znakových řetězců, popisujících jednotlivé soubory a podadresáře
Zásada server nikdy nesestavuje dohromady jména souborů, adresářů a podadresářů (např. v rámci specifikace přístupových cest) dělá to až klient, s využitím svých “místních” konvencí je tak velmi dobře zajištěna platformní nezávislost
systémový identifikátor (handle) je ukazatelem na jedno konkrétní místo v rámci systému souborů serveru
Problém Klient musí získat alespoň jeden vstupní bod do systému souborů serveru (alespoň jednu systémovou identifikaci) pak má k dispozici prostředky pro procházení celého stromu (systému souborů serveru)
jak ale klient získá alespoň jednu systémovou identifikaci (tu první)? zde není možné se vyhnout přesné specifikaci přístupové cesty řeší se mimo protokol NFS, prostřednictvím tzv. mount serverů
Mount servery Každý server nabízí přístup ke své stromové struktuře souborů tyto stromy tzv. ”exportuje” - zveřejňuje jejich vstupní body (kořeny stromů) klient si pak může připojit vzdálený strom ke svému systému souborů jako podstrom (v případě Unixu operací mount) nebo jako samostatnou diskovou jednotku (v případě Windows) .....
operace počátečního připojení (mount) vzdáleného stromu není idempotentní (a nelze to obejít) navíc se při této operaci musí specifikovat úplná přístupová cesta ke kořeni připojovaného stromu proto se tato část řeší mimo NFS, v rámci tzv. mount serveru, který je již závislý na konkrétní platformě
Mount server vs. NFS server NFS server je optimalizován na rychlost mount server nemusí být rychlý - slouží pouze k autentizaci
Mount server je nutně stavový NFS server je součástí jádra OS (v případě Unixu) mount server je implementován na aplikační úrovni Prověřuje identitu uživatelů
Zabezpečené připojení - SSH Připojení pomocí protokolů Telnet, či FTP má základní nevýhodu: v přenosu nezašifrovaných dat
Jsou přenášena nejen nezabezpečená data, ale i autentizační informace
proto vznikla v roce 1995 náhrada:
Protokol SSH - Secure Shell protokol SSH vytváří mezi klientem a serverem šifrovaný – zabezpečený kanál
přenášená data se jeví útočníkům jako náhodný šum
SSH princip SSH používá metodu: asymetrického šifrování je založena na existenci dvou klíčů tvořících pár
zprávu je možné
veřejný
tajný
pouze zašifrovat pomocí jednoho a pouze dešifrovat pomocí druhého klíče
myšlenka: dvě velká prvočísla Ttajné a Ddopis V=TxD - výsledné velké prvočíslo bez znalosti T nejsem schopen v rozumném čase rozložit V na D
SSH navazování spojení Před spojením na šifrovaném kanálu probíhá autentizace výměnou klíčů: spojení: server naslouchá na portu 22 server vygeneruj 768 bitový klíč při startu a nikdy jej klient pošle serveru žádost o sestavení spojení neukládá na disk oba se dohodnou na používané verzi server pošle klientovi svůj veřejný klíč klient pomocí něj zašifruje vytvořený klíč sezení a pošle ho zpět serveru dešifrovat zaslaný klíč sezení může rychle pouze server a to díky znalosti neveřejné části svého klíče v tuto chvíli mají oba společný klíč sezení, který používají na šifrování komunikace klíč sezení se mění každou hodinu
šifrovaný provoz je pak pro uživatele transparentní
SSH 1 a SSH 2 Brzy po SSH1 se objevila nová verze kompletně přepsaná verze SSH1
SSH2
SSH2 je lépe portovatelná na různé platformy SSH2 přidává podporu pro SFTP SSH2 využívá nový, bezpečnější mechanizmus výměny klíčů
Implementace některé hostitelské servery podporují již pouze tento způsob relací s uživateli implementace pro Windows – TeraTerm, Putty, přenos souborů WinSCP implementace pro Unix – ssh, scp
Využití SSH SSH nesloží pouze pro vzdálený login Přes zabezpečený kanál je možné tunelovat i další ne-bezpečné protokoly ppp NFS VPN...
ariable X11 Display V Port Forwarding
ssh
client
Host
V budoucnosti možná nahrazeno IPv6 a jeho mechanizmy...
Konec přednášky
