Stßle rostoucφ snaha a vzr∙stajφcφ poΦet ·sp∞Ün²ch pokus∙ hacker∙ (sna₧φ se o prolomenφ ochrany s cφlem dokßzat sob∞ a svΘmu odbornΘmu okolφ svoje znalosti a dovednosti) Φi cracker∙ (sna₧φ se prolomit ochranu s cφlem n∞jak²m zp∙sobem v∞dom∞ poÜkodit napaden² subjekt) o prolomenφ bezpeΦnostnφch vlastnostφ jednotliv²ch zp∙sob∙ ochrany privßtnφch dat vyskytujφcφch se na internetu vedou p°ednφ nßvrhß°e protokol∙ a standard∙ k zamyÜlenφ, jak maximßln∞ zv²Üit bezpeΦnost t∞chto dat a p°itom nevytvo°it takovΘ bezpeΦnostnφ protokoly, jejich₧ prolomenφ by sice bylo problematickΘ a tak°ka nemo₧nΘ, ale souΦasn∞ by s touto velkou v²hodou takΘ vzrostla doba nutnß k obsluze jednotliv²ch bezpeΦnostnφch mechanism∙ u₧φvan²ch t∞mito nov²mi °eÜenφmi. Jednφm z protokol∙, kterΘ se sna₧φ najφt optimßlnφ hranici mezi t∞mito dv∞ma zßkladnφmi po₧adavky na zabezpeΦenφ p°enosu dat, je protokol SSH.
┌vod do SSH
Stejn∞ jako v p°edchozφch dφlech serißlu se i tentokrßt nejprve seznßmφme se zßkladnφmi informacemi a historick²mi souvislostmi z v²voje protokolu SSH.
SpoleΦnost SSH Communications Security vyvinula Secure Shell a SSH protokol û tedy technologie, kterΘ se v souΦasnΘ dob∞ stßvajφ standardem pro Üifrovßnφ tzv. "terminal connections" p°es internet. Tyto technologie jsou Üiroce rozÜφ°eny p°edevÜφm mezi sφ¥ov²mi administrßtory, jim₧ poskytujφ t°i zßkladnφ utility: slogin, ssh a scp.
Secure Shell je bezpeΦn² p°ihlaÜovacφ program, kter² zm∞nil vzdßlenΘ °φzenφ sφ¥ov²ch hostitel∙ p°es internet. Nahrazuje tedy d∙v∞rn∞ znßmΘ programy, jako jsou telnet, rlogin a ftp.
Jednφm z d∙vod∙, kterΘ vedly k nahrazenφ t∞chto program∙, byla snaha odstranit velkΘ bezpeΦnostnφ riziko, jemu₧ je u₧ivatel p°i pou₧φvßnφ t∞chto program∙ nev∞domky vystaven. Zmφn∞nΘ programy toti₧ p°enßÜejφ u₧ivatelskß jmΘna nebo hesla p°es sφ¥ ve form∞ znßmΘ jako "clear text". U₧itφ tohoto zp∙sobu p°enosu dat se logicky stalo pro ·toΦnφky pom∞rn∞ jednoduch²m zp∙sobem, jak zφskat u₧ivatelskß jmΘna spolu s odpovφdajφcφmi hesly. Tφm se dostßvala ·toΦnφk∙m do rukou zbra≥, kterou nevßhali zneu₧φt p°i sv²ch nekal²ch aktivitßch.
V²vojß°∙m tohoto novΘho protokolu (SSH) se poda°ilo vytvo°it produkt, kter² reagoval na negativnφ vlastnosti v²Üe popsan²ch program∙ a zφskal charakteristickΘ znaky, kter²mi jsou: automatickß autentizace u₧ivatel∙ û to znamenß, ₧e ji₧ ₧ßdnß hesla nejsou p°enßÜena ve zmi≥ovanΘ "clear text" form∞ vφceΦetnΘ autentizaΦnφ metody û reakce na ·toky znßmΘ jako "spoofing identity";autentizace takΘ na konci spojenφ û autentizace serveru a klientu pro zlepÜenφ ochrany nap°φklad proti "TrojskΘmu koni" apod.Üifrovßnφ a komprese dat û slou₧φcφ k zajiÜt∞nφ vyÜÜφ bezpeΦnosti a rychlosti p°enosu;bezpeΦn² p°enos soubor∙ û u₧itφm tunelovßnφ a Üifrovanφ libovolnΘho spojenφ.
Architektura SSH
Jak ji₧ vφme, SSH je protokol pro zabezpeΦenΘ vzdßlenΘ p°ihlaÜovßnφ (remote login) a pro u₧itφ ostatnφch bezpeΦn²ch sφ¥ov²ch slu₧eb p°es jinak nezabezpeΦenΘ sφt∞.
Tento protokol se sklßdß ze t°φ hlavnφch stavebnφch kamen∙, kter²mi jsou nßsledujφcφ protokoly (viz obr. 1):
Transport layer protocol (SSH-TRANS) û tento protokol m∙₧e b²t u₧φvßn jako zßklad pro °adu bezpeΦn²ch sφ¥ov²ch slu₧eb. Poskytuje serveru autentizaci, utajenφ a integritu. Pomocφ tohoto protokolu jsou dohodnuty algoritmy ve°ejn²ch klφΦ∙, metody v²m∞ny klφΦ∙, symetrickΘ Üifrovacφ algoritmy, algoritmy ov∞°ujφcφ zprßvy a haÜovacφ algoritmy. Voliteln∞ m∙₧e tento protokol poskytnout i kompresi.
User authentication protocol (SSH-USERAUTH) û slou₧φ pro pot°eby autentizace klientu serverem (host-based client authentication). Tato autentizace m∙₧e probφhat ve dvou cestßch. Prvnφ z nich je tzv. Password authentication. V tomto modu se SSH chovß tΘm∞° identicky jako telnet. V pr∙b∞hu vytvß°enφ novΘho spojenφ je u₧ivatel dotßzßn na heslo, podle n∞ho₧ je dßle bu∩ p°ihlßÜen, Φi zamφtnut systΘmem. Heslo je ovÜem v tomto p°φpad∞ nejprve zaÜifrovßno p°ed odeslßnφm p°es sφ¥ a nßsledn∞ deÜifrovßno vzdßlen²m hostitelem. Druhou variantou je tzv. RSA Authentication. V tomto modu je vytvo°en pßr ve°ejn²ch a tajn²ch klφΦ∙. Po vytvo°enφ ve°ejnΘho klφΦe je tento klφΦ umφstn∞n na vzdßlen² host, ke kterΘmu se chce klient p°ihlßsit. To je velmi podobnΘ jako u₧φvßnφ .rhosts file p°i vytvß°enφ spojenφ p°es rlogin. DalÜφ mo₧nostφ je u₧φvat tzv. passphrase, spolu s ve°ejn²m klφΦem.
Connection protocol (SSH-CONN) û rozd∞luje zaÜifrovan² tunel do n∞kolika logick²ch kanßl∙. Nap°φklad v jednom z t∞chto logick²ch kanßl∙ m∙₧e poskytovat tzv. interaktivnφ "sezenφ/relaci" p°i p°ihlßÜenφ (interactive login session) a v druhΘm nap°φklad vzdßlenΘ provßd∞nφ p°φkaz∙.
Pr∙b∞h autentizace
Nejd°φve si zjednoduÜen∞ popφÜeme, jak probφhß autentizace serveru klientem û tzv. Server Host Authentication.
PotΘ, co klient vyÜle po₧adavek o spojenφ se serverem, jsou v dalÜφm kroku vzßjemn∞ p°edßny informace o protokolech a verzφch. Po tΘto v²m∞n∞ se vytvo°φ nov² klφΦ serveru (ve°ejn² a tajn²), kter² je pravideln∞ generovßn a dr₧en v pam∞ti. Tento ve°ejn² klφΦ (Server public key) je dßle zaslßn klientu spolu s hostitelsk²m ve°ejn²m klφΦem (Host public key), spolu s cookie a informacemi o Üifrßch. Klient v dalÜφm kroku zkontroluje, zda Host public key pat°φ mezi znßmΘ klφΦe. Pokud ne, zeptß se, jestli mß pokraΦovat. Nßsleduje-li kladnß odpov∞∩, p°idß ve°ejn² klφΦ do ~/.ssh/ssh_known_hosts. Je-li pak vÜe v po°ßdku (kladnß odpov∞∩ i p°i p°φpadnΘ zm∞n∞ Host ID), je v dalÜφm kroku vytvo°en Session ID. Postup tvorby tohoto ID lze p°irovnat k funkci, jejφmi₧ vstupy jsou ve°ejnΘ klφΦe (Host and Server public key) a cookie. V dalÜφm kroku je vytvo°en klφΦ relace (Session key). Tento zaÜifrovan² klφΦ relace je spolu s kopiφ cookie zaslßn serveru. Server nßsledn∞ vygeneruje tzv. "Cipher key".
Pozn.: Proces tvorby Session ID a Cipher key je navr₧en tak, aby mohl probφhat na obou stranßch spojenφ. VeÜkerß ostatnφ komunikace je pak ji₧ Üifrovßna tφmto klφΦem.
Nynφ se podφvßme, jak²m zp∙sobem probφhß tzv. RSA Client û Host Authentication.
Nejprve zaÜle klient serveru sv∙j Client Host public key a sv∙j hostname. Po obdr₧enφ t∞chto informacφ server zkontroluje, zda je Client hostname bu∩ v /etc/hots.equiv, nebo v ~/.rhosts. Dßle kontroluje, zda je Client Host public key v ssh_known_hosts v /etc, nebo v ~/.ssh. Ob∞ kontroly musφ dopadnout dob°e. V dalÜφm kroku zaÜifruje nßhodnΘ Φφslo (Random Number û RN) pomocφ Client Host public key. Klient v dalÜφm kroku deÜifruje RN pomocφ tajnΘho klφΦe (Client Host private key) a vypoΦφtß MD5 kontrolnφ souΦet pro (RN + Session ID). Server v dalÜφm kroku zkontroluje, zda se jφm vypoΦφtan² MD5 kontrolnφ souΦet shoduje s klientsk²m.
Pozn.: Obdobn²m zp∙sobem jako v p°edchozφm odstavci (SSH-USERAUTH) probφhß tzv. User/Password Authentication.
Zßv∞r
Protokol SSH m∙₧eme rovn∞₧ s klidn²m sv∞domφm za°adit mezi protokoly, jejich₧ pomocφ budeme sv∞°ovat svß data do pomysln²ch vÜeobjφmajφcφch rukou poΦφtaΦov²ch sφtφ, a to zejmΘna proto, ₧e jsou vyu₧φvßny dob°e znßmΘ a prov∞°enΘ algoritmy pro Üifrovßnφ, integritu a ve°ejnΘ klφΦe. VÜechny tyto algoritmy jsou dohodnuty a v p°φpad∞ poÜkozenφ Φi prolomenφ jednoho algoritmu staΦφ pouze "p°epnout" na jin² algoritmus bez pot°eby modifikovat zßkladnφ protokol.
╚tenß°i, kte°φ rßdi experimentujφ v danΘ problematice, si mohou stßhnout nap°φklad ze serveru www.ssh.fi: SSH« Secure ShellTM 2.1 BETA for Windows, nebo ze strßnek spoleΦnosti Data Fellows: F-Secure SSH Client (viz obr. 2).
