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í aplikace počítačová síť telnet, zajišťující funkce terminálu lokální terminálová relace host A vzdálená terminálová relace telnetový emulátor TA1 TA2 TA3 T1 3 terminál terminál terminál... nebo sériová linka 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 aplikace op. systém op. systém TCP/IP síť
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) datové spojení server (PI a DTP) je tak možná i komunikace více uzlů řídící spojení ří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 GET PUT DIR CD řídící jazyk RETR STORE LIST 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 proto vznikla v roce 1995 náhrada: Protokol SSH - Secure Shell Jsou přenášena nejen nezabezpečená data, ale i autentizační informace 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 veřejný tajný zprávu je možné pouze zašifrovat pomocí jednoho a pouze dešifrovat pomocí druhého klíče myšlenka: dvě velká prvočísla T tajné a D dopis V = T x D - 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 klient pošle serveru žádost o sestavení spojení oba se dohodnou na používané verzi server pošle klientovi svůj veřejný klíč server vygeneruj 768 bitový klíč při startu a nikdy jej neukládá na disk 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... X11 Display Variable Port Forwarding ssh client Host V budoucnosti možná nahrazeno IPv6 a jeho mechanizmy...
Konec přednášky