Příklady otázek ke zkoušce z předmětu PSI
1.
Uveďte a. formát adresy IPv4, b. co je to subnetting, c. co je to supernetting, d. co je to CIDR. 2. Co je to MIME? Popiš některou z kódovacích technik, které dovolují přenos neASCII znaků prostřednictvím zpráv elektronické pošty. 3. Popište protokol DHCP, a. funkce, b. typy zpráv (protokol výměny zpráv), c. parametry (hlavní parametry, pomocné) d. jak souvisí DHCP s bootováním počítače. 4. Jaký je vztah mezi a. doménovým jménem a IP adresou, jak se převádí, b. IP adresou a fyzickou adresou počítače, na které pracuje klient? c. Jak se tyto identifikátory získávají? 5. RMON-I, a. princip činnosti, b. skupiny RMON (vyjmenujte alespoň 4), c. tabulky RMON a princip přístupu k informacím. 6. Směrování RIP, a. princip, algoritmus opravy směrovacích tabulek b. algoritmy urychlení konvergence. 7. Protokoly pro přenos v reálném čase, a. RTP, RTCP, b. RTSP 8. Jaký je rozdíl mezi řízením toku dat a obranou proti zahlcení při přenosech pomocí protokolu TCP? a. Vysvětlete princip řízení toku dat v sítích TCP/IP, b. Vysvětlete jak se TCP brání zahlcení, jak se zahlcení projevuje, c. Uveďte alespoň 2 algoritmy obrany proti zahlcení včetně principu činnosti. 9. Jaký je rozdíl mezi TFTP a FTP? a. Který z nich je realizován pomocí TCP a který pomocí UDP? b. Který z nich má zabudované ověřování? c. Na jaké účely se používají? 10. Architektury obranných valů. Načrtněte architekturu následujících typů obranných valů. a. Screening Router b. Bastion Host c. Dual Homed Gateway d. Screened Subnet
11. Protokol TCP, formát záhlaví, volitelné parametry. 12. Popište protokol ARP a RARP, funkce, typy zpráv. 13. Schémata pro ověřování uživatele využívající symetrické i asymetrické šifrování. 14. Elektronická pošta, princip, protokoly pro příjem elektronické pošty. 15. Protokol SNMP. Popište funkci operace get-next na příkladu s přístupem k tabulkám. 16. Směrování OSPF, architektura. 17. Mobilní IP, princip činnosti. 18. Přenos hlasu IP sítěmi, protokol VoIP. 19. Funkce relační úrovně. 20. Architektury obranných valů. 31. IP adresa, subnetting, supernetting, CIDR. 32. Protokol IP, formát záhlaví, fragmentace, TTL, TOS, volitelné parametry 33. Popište protokol DHCP, funkce, typy zpráv, parametry 34. Jmenné služby, architektura, typy serverů, princip převodu, typy převáděných informací. 35. RMON, princip činnosti, skupiny RMON, princip přístupu k informacím. 36. Směrování RIP, princip, algoritmy urychlení konvergence. 37. Protokoly pro přenos v reálném čase, RTP, RTCP, RTSP, RSVP 38. Princip řízení toku dat v sítích TCP/IP. 39. protokol TFTP 40. Skupinové směrování, RPB, RPM, TRPB 41. Jak pracuje systém jmenných domén (DNS)? Které části jsou umístěny v klientu, v serveru a případně v jiných počítačích?
42. Co je to MIME? Popiš některou z kódovacích technik, které dovolují přenos ne-ASCII znaků prostřednictvím zpráv elektronické pošty.
43. Co jsou to cookie? K čemu slouží? 44. Jaký je rozdíl mezi TFTP a FTP? Který z nich je realizován pomocí TCP a který pomocí UDP? Který z nich má zabudované ověřování? Na jaké účely se používají?
45. Zapiš pseudokód pro konkurenční server. 46. Jaký je vztah mezi doménovým jménem, IP adresou a fyzickou adresou počítače, na které pracuje klient? Jak se tyto identifikátory získávají?
47. Co je to „Slow Start“, k čemu slouží, jak funguje. 48. Co je to OID, jaký je rozdíl mezi identifikátorem objektu a jeho instancí, uveďte příklad. 49. Co je to agregovaný index v RMON II, k čemu slouží, jaký má formát, uveďte příklad. 50. Jak se vypočte oprava směrovací tabulky při směrování typu DVA. 51. Popište protokol IGMP, čemu slouží. 52. Co je to Network Virtual Terminal, jak se provádí dohadování parametrů (Telnet), které příkazy se používají.
53. Porovnejte vlastnosti (odlišnosti) protokolů FTP a TFTP. 54. Jaký je rozdíl mezi metodami symetrického a asymetrického šifrování, uveďte vlastnosti, známé šifrovací algoritmy, porovnání složitosti a bezpečnosti. Co je to hashovací funkce, kde se používá.
55. Jak se provádí DoS útok pomocí protokolu TCP a jako pomocí ICMP. 56. SNMP 57. Protokol ICMP 58. Protokol RTP a RTCP, jak spolu souvisí, k čemu slouží, jaká informace je přenášena (přibližně).
OTÁZKA č.1 http://www.networksorcery.com/enp/protocol/ip.htm http://www.novinky.cz/archiv/Index/Drobnohled/1681.html Formát IPv4
Subnetting: The assignment of subnets is done locally. The entire network still appears as one IP network to the outside world. Lze rozdělit jednu síťovou IP adresu na několik menších síťových adres tomu se říká subnetting.
<subnet number>
Supernetting: Lze spojit několik "sousedních" síťových adres do jedné síťové adresy tomuto postupu se říká supernetting
Classless Inter-Domain Routing (CIDR) Umožňuje použit pro adresovani v podsiti takovy počet bitů, ktery neni na hranici 8. Adresa se udava ve tvaru adresa/počet bitů siťove časti Např. 147.228.67.0/24
OTÁZKA č.2 http://www.cpress.cz/knihy/tcp-ip-bezp/CD-dalsi/CD-mime/mime.htm#Pro%E8%20MIME MIME (Multipurpose Internet Mail Extensions): protokol na posilani emailu - text in character sets other than US-ASCII - header information in non-ASCII character sets - multi-part message bodies MIME zavádí hlavičky: o o o o o o
MIME-Version - přítomnost této hlavičky v mailu indikuje, že je zpráva sestavena podle RFC2045 až RFC2049. Content-Type - specifikuje typ a podtyp dat posílaných v těle zprávy (text, audio, video, virtuální realita). Content-Transfer-Encoding - specifikuje použité kódování, pomocí kterého je zpráva převedena do formátu vyhovujícímu přenosovému mechanismu (do ASCII). Content-ID - identifikace zprávy použitelná v možném odkazu Content-Description - textový popis obsahu. Content-řetězec - je rezervováno pro boudouci použití v MIME.
7 bitové kódování 8 bitové Binární Base64 Quoted printable http://en.wikipedia.org/wiki/Quoted-printable Quoted-printable encoding Any 8-bit byte value may be encoded with 3 characters, an "=" followed by two hexadecimal digits (0–9 or A–F) representing the byte's numeric value. For example, a US-ASCII form feed character (decimal value 12) can be represented by "=0C", and a US-ASCII equal sign (decimal value 61) is represented by "=3D". All characters except printable ASCII characters or end of line characters must be encoded in this fashion. Printable ASCII characters except "=", i.e. those with decimal values between 33 and 126 excepting decimal value 61 (=), may be represented by themselves. ASCII tab and space characters, decimal values 9 and 32, may be represented by themselves, except if these characters appear at the end of a line. If one of these characters appears at the end of a line it must be encoded as "=09" (tab) or "=20" (space). If the data being encoded contains meaningful line breaks, they must be encoded as an ASCII CR LF sequence, not as their original byte values. Conversely if byte values 10 and 13 have meanings other than end of line then they must be encoded as =0A and =0D. Lines of quoted-printable encoded data must not be longer than 76 characters. To satisfy this requirement without altering the encoded text, soft line breaks may be added as desired. A soft line break consists of an "=" at the end of an encoded line, and does not cause a line break in the decoded text. Toto kódování se používá tehdy, je-li většina znaků psána v ASCII kódování (bez speciálních českých znaků). Tyto znaky se odešlou nezměněny a kódují se pouze speciální české znaky. Před tyto se přidá znak "=". Většina textu je tedy čitelná i bez zpětného dekódování, takže by neměl být problém i u E-mailových klientů, kteří nepodporují toto kódování nebo Base64. Příkladem může být například spisovatel "Karel Havlíček Borovský", jehož jméno by po překódování vypadalo takto: "Karel_Havl=ED=E8ek_Borovsk=FD". To, že je text kódovaný tímto typem se dozvíme z hlavičky mailu, kde je uvedeno pole " Content-Transfer-Encoding: quoted-printable".
Znaky v hlavičce, které nejsou ASCII Znaky, které nejsou ASCII by se v žádném případě neměly vyskytnout v záhlaví zprávy. Na otázku co se stane, když se tam takový znak vyskytne není jednoznačná odpověď. Zpráva může dojít příjemci bez problému, zpráva může být nějakým serverem na cestě vrácena nebo se může ztratit. RFC2047 řeší otázku jak do parametrů hlaviček dodat ne ASCII znaky. Problém i zde se skládá ze dvou částí: o o
Co takový znak vyjadřuje (obdoba Content-Type)? Např. hexadecimálně znak F8 může v jedné abecedě představovat ř a v jiné azbukové š. Jak je kódován do ASCII (obdoba Content-Transfer-Encoding). Např. base64 nebo quoted printable.
Syntaxe parametru hlavičky je v tomto případě =?charset?kódování?řetězec?= charset je např. iso-8859-x kódování je buď b pro base64 bebo q pro quoted printable. Příklad: Chce-li si odesilatel do hlavičky From zadat své jméno s diakritikou, pak: From: =?iso8859-2?q?V=E1clav Vopi=E8ka?= Je zpráva od Václava Vopičky
OTÁZKA č. 3 http://cs.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol http://www.networksorcery.com/enp/protocol/dhcp.htm DHCP (Dynamic host configuration protocol) : - používá se pro automatické přidělování IP adres koncovým stanicím v síti - současně s IP adresou posílá server stanicím (klientům) další nastavení potřebná pro používání sítě jako je adresa nejbližšího směrovače (default gateway), masku sítě, adresy DNS serverů a) automatic alocation – permanent IP address b) dynamic alocation – dhcp assigns an IP address for a limited period of time c) manual alocation – network administrator
Typy zpráv: - DHCPDISCOVER – ask for find available dhcp servers - DHCPOFFER – response from discover dhcp and offering IP address - DHCPREQUEST – client ask for that address - DHCPACK – ack from server to client (additional information) - DHCPNACK – negative ack (expire IP address or wrong IP address) - DHCPDECLINE – client to server - IP address already in use - DHCPRELEASE – client to server – canceling of the rest of time to expire IP address - DHCPINFORM – client to server, already has an IP address Formát DHCP založen na BOOTP protocolu a je zpětně kompaktibilní.
OTÁZKA č.4 http://cs.wikipedia.org/wiki/DNS Doménové jméno: .<subdomena>.<subdomena>. … .<domena>, DNS (převod na adresu a zpět) IP adresa: IPv4, IPv6 Fyzická adresa: jednoznačné identifikační číslo 12 místné hexadecimální číslo síťové karty Získávání těchto parametrů: c) ipconfig –all (udava vyrobce), b) prideleni na zaklade DHCP nebo BOOTP, pevne nastavitelna
Postup hledání www.wikipedia.org 1. 2. 3. 4. 5.
6. 7. 8.
Uživatel zadal do svého WWW klienta doménové jméno www.wikipedia.org. Resolver v počítači se obrátil na lokální DNS server s dotazem na IP adresu pro www.wikipedia.org. Lokální DNS server tuto informaci nezná. Má však k dispozici adresy kořenových serverů. Na jeden z nich se obrátí (řekněme na 193.0.14.129) a dotaz mu přepošle. Kořenový server také nezná odpověď. Ví však, že existuje doména nejvyšší úrovně org, a jaké jsou její autoritativní servery, jejichž adresy tazateli poskytne. Lokální server jeden z nich vybere (řekněme, že zvolí tld1.ultradns.net s IP adresou 204.74.112.1) a pošle mu dotaz na IP adresu ke jménu www.wikipedia.org. Oslovený server informaci opět nezná, ale poskytne IP adresy autoritativních serverů pro doménu wikipedia.org. Jsou to ns0.wikimedia.org (207.142.131.207), ns1.wikimedia.org (211.115.107.190) a ns2.wikimedia.org (145.97.39.158). Lokální server opět jeden z nich vybere a pošle mu dotaz na IP adresu ke jménu www.wikipedia.org. Jelikož toto jméno se již nachází v doméně wikipedia.org, dostane od jejího serveru nepochybně autoritativní odpověď, že hledaná IP adresa zní 145.97.39.155 Lokální DNS server tuto odpověď předá uživatelskému počítači, který se na ni ptal
Lokální počítač obsahuje: adresu lokálního DNS serveru Lokální DNS server obsahuje: IP adresy korenovych serveru Korenove servery obsahuji: informace o korenove domene (znaji všechny existujici domeny nejvyssi urovne a jejich autoritativni servery)
OTÁZKA č.5 http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/rmon.htm http://www.svetsiti.cz/view.asp?rubrika=Tutorialy&temaID=23&clanekID=34 http://www.svetsiti.cz/view.asp?rubrika=Tutorialy&temaID=23&clanekID=35 http://www.svetsiti.cz/view.asp?rubrika=Tutorialy&temaID=23&clanekID=36 RMON (Remote monitoring) : vzdálené monitorování -
RMON model se skládá ze dvou částí (agent = sonda na monitorovaném zařízení, správní aplikace běžící na centrální konzoli) Pomocí aplikace zkonfigurujeme klienta ke sběru požadovaných aplikací, které jsou zasílány na centrální konzolu
SNMP pooling - kontinuální monitorování - má své nevýhody: - ve větších sítích může významně přispět k zatížení sítě - při monitorování mnoha údajů může také podstatně zatížit správcovskou konzolu Základní ideou při návrhu RMON bylo mít inteligentního agenta, který je schopen co nejpodrobnějšího monitorování síťového segmentu a uchovávání sesbíraných informací. Získané informace (aktuální i historická data) z různých agentů lze pak prezentovat na centrální správcovské konzole při minimální komunikační zátěži a zároveň minimální výpočetní zátěži konzoly. RMON standard definuje skupiny informací, které mohou být monitorovány síťovým analyzátorem nebo sondou (agentem). RMON MIB (Management Information Base) standard umožňuje vzdálené monitorování Ethernet i Token Ring segmentů a to využitím již zavedeného protokolu SNMP. RMON je typickým příkladem distribuovaného řešení. Stejně jako klasický SNMP model, i RMON model se skládá ze dvou částí. Tou první je agent (sonda), která je umístěna na monitorovaném segmentu. Druhou částí je správní aplikace, běžící na centrální konzole, v ideálním případě jako nadstavba základní správní platformy. Pomocí této RMON aplikace můžeme zkonfigurovat agenta ke sběru požadovaných informací, které jsou zasílány na centrální konzolu při vyžádání nebo při výskytu definované události. Těchto agentů - sond může být rozmístěno v síti tolik, kolik má síť segmentů. Samozřejmě u velkých sítí se tyto sondy umisťují strategicky jen na nejdůležitější segmenty, případně podle potřeby na ty segmenty, kde se objevují nějaké problémy. Centralizovaná filosofie RMON je obzvláště výhodná v dnešních sítích, které jsou často směsicí Ethernet a Token Ring topologie (toto tvrzení platí spíše pro vyspělejší svět, u nás je situace z historických důvodů odlišná). První implementace RMON se sice objevily v zařízeních typu Ethernet, brzy ale byly RMON MIB z výše uvedeného důvodu oficiálně rozšířeny i o Token Ring. Tak byly k základním statistickým informacím, společným oběma topologiím, přidány explicitní informace o lokálním kruhu. RMON MIB host tabulka obsahuje statistiku komunikace pro všechny uzly sítě a tato tabulka je indexována pomocí jejich MAC adres. Skupiny RMON: Group 1.1. Group 2.2. Group 3. Group 4. Group 5. Group 6. Group 7. Group 8. Group 9.
Ethernet Statistic : statistika provozu Ethernet History : historický pohled na RMON statistiku Alarms : nastavení prahové úrovně a vzorkovací intervaly Hosts : poskytuje prenosovou statistku pro každý sitovy uzel v tabulkovem formatu Host Top N : setridene tabulky podle statistik v zavislosti na MAC adrese Traffic Matrix: zobrazuje vzajemnou komunikaci mezi jednotlivymi uzly Filters : Packet Capture : vytvoreni vicenasobnych buferu pro zachycene pakety Events: vytvoreni zaznamu jednotlivych udalosti
OTÁZKA č. 6 http://www.fi.muni.cz/~kas/p090/referaty/2001-podzim/routovani.1.html#rip http://en.wikipedia.org/wiki/Routing_Information_Protocol Routovací protokoly slouží pro automatické plnění routovacích tabulek. RIP (Routing Information Protocol): - směrovací protokol umožňující směrovačům komunikovat mezi sebou a reagovat na změny topologie počítačové sítě - pouziva Routing vector protocol Request packets, response packets. Routovací tabulka: • IP-adresu cílove sítě • siťovou masku • IP-adresu následujícího routeru • síťový interface, do kterého se bude paket směrovat směrem k následujícímu routeru • metriku (cenu - vybírá se vždy cesta o nejnižší ceně - metrice) • protokol kterým byla položka získaná a časové razítko. Routing vector protocol Routing vector protocol (RVP) je velice jednoduchý protokol. Routery vysílají protokolem RVP do svých síťových interfaců obsah své routovací tabulky. Takže sousední routery si mohou přečíst vzájemně své routovací tabulky. Router A přijme z určitého síťového interface routovací tabulku svého souseda B. V routovací tabulce svého souseda B připočte ke všem metrikám cenu (metriku) k sousedovi a začne porovnávat, není-li v takto opravené sousedově routovací B tabulce nějaká nová cesta, aby si ji zařadil do své routovací tabulky. Také zjišťuje, neni-li tam cesta k síti, kterou sice v tabulce má, ale s nižší metrikou. Pokud v sousedově routovací tabulce najde lepší cestu, pak původní položku své routovací tabulky nahradí novou. Princip: přijde-li paket na router, pak si router z jeho záhlaví zjistí IP-adresu příjemce. Hledá ji v IP-adresách cílové sítě své routovací tabulky. Najde-li cílovou siť v routovací tabulce, pak v záhlaví IP-paketu sníží položku TTL alespoň o jedničku. Pokud má položka TTL po snížení hodnotu 0, pak router paket zahodí a pošle odesílateli protokolem ICMP zprávu, že životnost jeho paketu vypršela. Podle routovací tabulky router zjistí, do kterého síťového interface má paket poslat. Zjistí-li, že je to ten samý interface, kterým paket přišel, pak jej do interfacu pošle, ale odesílateli o tom pošle protokolem ICMP zpravu, aby se vzpamatoval a opravil si routovaci tabulku. Čili i protokolem ICMP se muze dynamicky měnit routovaci tabulka. Protokol ICMP však není aplikačni protokol, je soucasti IP-protokolu. Nenajde-li router v routovaci tabulce cílovou síť, ale má v tabulce položku default, pak zvolí směr v položce default. Nemá-li ani default, pak paket zahodí a pošle odesílateli protokolem ICMP zprávu, že taková síť je nedosažitelná. Metrika, kterou používá protokol RIP, je počet směrovačů na cestě k cíli. Nejnižší metrika je pro přímo připojené sítě ke směrovači, nejdelší cesta je 15 skoků (směrovačů), vyšší metrika (16) označuje neplatnou cestu (nedostupnou síť). RIP vysílá aktuální směrovací informace na všeobecnou adresu v periodě 30 s. Triggered update: směrovač ihned bez čekání na periodu vyšle novou metriku směrovací cesty,došlo-li k její změně Split horizont: do rozhraní, z něhož získal informace o směrovacích cestách, je zpět neposílá Poison reverse: do rozhraní, z něhož získal informace o směrovacích cestách, je zpět posílá s metrikou ω=nedostupné
OTÁZKA č. 7 http://en.wikipedia.org/wiki/Real-time_Transport_Protocol http://www.elektrorevue.cz/clanky/03018/index.html http://cs.wikipedia.org/wiki/RTP http://en.wikipedia.org/wiki/Real_Time_Streaming_Protocol http://amarok.cesketelekomunikace.cz/xkacal00/?action=is_rsvp http://amarok.cesketelekomunikace.cz/xkacal00/?action=is_massege http://en.wikipedia.org/wiki/Resource_reservation_protocol RTP (Real-time transport protocol): definuje standartni balickovy format pro dorucovani zvukovych a obrazovych videii dat po internetu -
spolehlivý koncový přenos interaktivního videa synchronizace časového přenosu zjištění ztráty nebo nesprávného pořadí dat identifikace přenášených dat číslování,označování času pro zobrazování obrazů/přehrávání zvuků komprese,nejčastěji nad UDP nezajišťuje doručení/včasné doručení/správné pořadí
To use real-time services in an application, two protocols must be implemented: • The Real-Time Transport Protocol (RTP) provides the transport of real-time data packets. • The RTP Control Protocol (RTCP) monitors the quality of service provided to existing RTP sessions. QoS (zajistuje RTPC): • •
• •
Volná kapacita sítě - rozdíl mezi instalovanou kapacitou a zátěží neboli využitou kapacitou. Je třeba sledovat nejen průměrné hodnoty, ale i jejich dynamiku v různých časových měřítcích. Ztrátovost paketů - kolik procent paketů nedorazí od odesílatele k příjemci. Ke ztrátě může dojít v důsledku dočasného přetížení některého komponentu komunikační trasy, například po vyčerpání kapacity vyrovnávacích pamětí, přetížení procesoru směrovače a podobně. Pro chování aplikací je rovněž důležitá i dynamika ztrátovosti, to je zda se ztráty vyskytují ve shlucích. Zpoždění - doba potřebná k přenosu paketu od odesílatele k příjemci. Změna zpoždění - jak se mění zpoždění jednotlivých paketů během přenosu. Tato vlastnost je pro aplikace často důležitější než absolutní hodnota zpoždění.
RTCP (Real-time transport control protocol): řízení výkonnosti/diagnostické účely=s protokolem RTP,periodické vysílání paketů od každého účastníka RTP všem ostatním účastníkům RTSP (Real-time Streaming Protocol): multimediální přenosy od jednoho zdroje více uživatelům - rozděluje data do mnoha paketů velikosti pro šířku pásma klient-server - obdržením dostatku paketů může klient-SW přehrát 1.paket,dekomprimovat 2.,přijímat 3.=>pro přehrátí není nutné stažení celého souboru RSVP (Resource ReSerVation Protocol): signalizační protokol pro rezervaci šířky pásma v síti přijímající stanice pro přenos dat citlivých na zpoždění(hlas VoIP,obraz IP video streaming,videokonference) - inicializuje přijímací stanice vysláním požadavku 1.směrovači směrem k zdroji datového toku,směrovač ověří splnitelnost a pošle dále,pokud je žádost splnitelná po celé cestě=>vznikne jednosměrná REZERVOVANÁ CESTA - při rezervaci v opačném směru je iniciátorem druhá strana - přednost=Žádný nadbytečný paket=>Pásmo je dostupné pro jiná spojení po téže cestě.
OTÁZKA č.8 http://www.svetsiti.cz/view.asp?rubrika=Tutorialy&temaID=1&clanekID=10 http://www.svetsiti.cz/view.asp?rubrika=Tutorialy&temaID=1&clanekID=9 http://www.svetsiti.cz/view.asp?rubrika=Tutorialy&temaID=1&clanekID=8 http://www.svetsiti.cz/view.asp?rubrika=Tutorialy&temaID=1&clanekID=7 http://www.cpress.cz/knihy/tcp-ip-bezp/CD-0x/9.html Řízení toku dat v TCP: - transportní vrstva - spolehlivé, spojované, potrvzované doručování - navazani spojeni tzv. handshake - kladne , kontinualni potvrzovani Obr.: Handshake Protokol TCP je založen na dvoustranné komunikaci mezi síťovými hostiteli. Přijímá data vyslaná programy a převádí je do proudu bajtů. Tyto bajty jsou rozděleny do segmentů, očíslovány a seřazeny podle toho, jak mají být postupně odesílány. Před zahájením výměny dat mezi dvěma hostiteli TCP je nutné mezi nimi vytvořit relaci. K inicializaci relace TCP se používá proces nazývaný třícestné potvrzování (handshake). Tento proces synchronizuje čísla sekvencí a poskytuje řídicí informace potřebné k vytvoření virtuálního připojení mezi oběma hostiteli. Po ukončení úvodní fáze třícestného ověření jsou mezi vysílajícími a přijímajícími hostiteli postupně ve stanoveném pořadí odesílány a potvrzovány jednotlivé segmenty. Podobný proces ověření používá protokol TCP při ukončování připojení, kdy je třeba zajistit, aby oba hostitelé odeslali a přijali všechna data. Projevy zahlcení: zahazování paketů Vyhýbání se zahlcení: velikost okenka snaží se specifikovat, kolik může odesilatel odeslat nepotvrzených dat aniž by došlo k zahlcení sítě (nastavení velikosti okna pomocí pomalého startu)
OTÁZKA č. 9 http://cs.wikipedia.org/wiki/File_Transfer_Protocol http://cs.wikipedia.org/wiki/Tftp http://en.wikipedia.org/wiki/Trivial_File_Transfer_Protocol FTP: • • • • • •
FTP provides minimal security through user logins FTP provides a reliable service through its use of TCP, port 21 FTP uses two connections (spojovane) FTP provides many commands Sdílení dat (často hudba, videa, vlastní tvorba, …). Správa účtů internetových stránek.
Nevýhody: • • • • •
Hesla a soubory jsou zasílány jako běžný text (nejsou šifrovaná). Je použito mnoho TCP/IP spojení (jedno pro příkazy a každé další pro upload/download souborů). Firewall může blokovat stahování, problémy mohou také nastat při stahování velkých souborů nebo při stahování trvající dlouhou dobu. Je možné zachytávat data třetím počítačem, proto se nedoporučuje používat FTP pro důležitá data. FTP má poměrně dlouhou dobu odezvy, proto není vhodné stahovat velké množství malých souborů.
TFTP: • • • • • • •
TFTP does not use logins TFTP does not since it uses UDP, port 69 TFTP uses one connection (stop and wait) , čeka na potvrzení každého bloku TFTP provides only five commands Přenos po 512b boot bezdiskových stanic (routery apod.) v jednom spojení lze přenést jen jediný soubor
OTÁZKA č. 10 http://www.pcmag.com/encyclopedia_term/0,2542,t=screening+router&i=50923,00.asp http://www.unix.org.ua/orelly/networking/firewall/ch05_01.htm#FIRE-05-S1-1 http://www.geocities.com/EnchantedForest/Dell/4500/papers/security/dhg.htm http://www.unix.org.ua/orelly/networking_2ndEd/fire/ch06_03.htm Screening router
Bastion host
Dual Homed Gateway
Screened Subnet Základní typy obranných valů - Kombinace technických a programových prostředků - Technické prostředky – směrovač a/nebo počítač (UNIX) - Programové prostředky – přístupový seznam ve směrovači, specializovaný oddělovací program Typy obranných valů Filtrující směrovač (Screening Router) • Provádí filtraci paketů podle směru přenosu, IP adresy a čísla portu Opevněný počítač (Bastion Host ) • • Používá se při realizaci důležitých serverů, které mají být navíc velmi bezpečné. Např.SMTP, FTP, DNS, HTTP, atd. • Think of it as the lobby of a building. Outsiders may not be able to go up the stairs and may not be able to get into the elevators, but they can walk freely into the lobby and ask for what they want. Brána se dvěma vstupy (Dual Homed Gateway) • Úplně odděluje vnitřní a vnější síť. Služby musí být umístěny na této bráně a jsou přístupné jak z vnitřní sítě, tak i z vnější sítě. Screened Subnet • Pomocí dvou filtrujících směrovačů se vytvoří oblast mezi vnitřní a vnější sítí, nazývaná demilitarizovaná zóna. Do této subsítě se připojí Bastion Hosts, nesoucí služby, které mají být přístupné jak z vnější, tak i z vnitřní sítě. Filtrujícími směrovači lze dosáhnout toho, že pakety s vnějšími adresami nejsou přenášeny do vnitřní sítě a naopak pakety s adresami vnitřní sítě nejsou přenášeny do sítě vnější. Screened Host Gateway • Vnitřní síť je chráněna filtrujícím směrovačem, který propouští pouze pakety určené pro vybraný počítač (Bastion Host). Pakty mohou být filtrovány nejen podle IP adresy, ale i podle portu (přístup k určitým službám). Brána aplikační úrovně • Pomocí filtrujícího směrovače jsou propouštěny pouze pakety určené aplikační bráně. Zde jsou instalovány aplikační proxy, které umožní komunikaci a klienty ve vnitřní síti.
OTÁZKA č. 11 http://cs.wikipedia.org/wiki/TCP http://www.tcpipguide.com/free/t_TCPMessageSegmentFormat-3.htm TCP protocol Volitelné parametry: - velikost segmentu - velikost okénka (n-násobek max. velikosti 64kB) pro případ že maximalni velikost okenka je mala. Urgent data: - zpracovavaji se prednostne a jinym zpusobem, pokud je nastaven prislusny flag bit Pasivní otevření (passive open) spojení je jakousi obdobou zpětného volání. Je iniciován procesem nabízejícím službu ostatním volajícím. Znamená to, že prostřednictvím služby pasivního otevření upozorní uzly na to, že pokud si to přejí, mohou aktivně navázat proces na známém TCP portu. Aktivní otevření (active open) je prováděno klientem, který se chce spojit s procesem na vzdáleném serveru. Na základě přijetí požadavku aktivního otevření vytváří server TCP proces pro správu kontrolních informací datového toku. Spojení je vytvořeno po úspěšné výměně synchronizačních paketů (SYN). Synchronizační pakety zajišťují výměnu počátečních sekvenčních čísel a základních kontrolních informací, na kterých se obě komunikující strany musí shodnout před zahájením přenosu dat. Proces ustavení spojení má 4 základní funkce : • • • •
výměnou požadavku a odpovědi ujišťuje obě strany procesu, že ta druhá existuje zajišťuje výměnu volitelných parametrů jako jsou velikost paketu, velikost okna (window) a úroveň služeb (QoS) alokuje transportní zdroje jako je např. velikost bufferu vytváří vstupní informace do tabulky spojení
Záhlaví:
OTÁZKA č. 12 http://cs.wikipedia.org/wiki/Address_Resolution_Protocol http://www.tcpipguide.com/free/t_ProxyARP-2.htm http://cs.wikipedia.org/wiki/Reverse_Address_Resolution_Protocol http://www.networksorcery.com/enp/protocol/rarp.htm ARP (Address Resolution Protocol): používá se k získání ethernetové (MAC) adresy sousedního stroje z jeho IP adresy. Obr.: ARP Proxy Používá se v situaci, kdy je třeba odeslat IP datagram na adresu ležící ve stejné podsíti jako odesilatel. Data se tedy mají poslat přímo adresátovi, u něhož však odesilatel zná pouze IP adresu. Pro odeslání prostřednictvím např. Ethernetu ale potřebuje znát cílovou ethernetovou adresu. Proto vysílající odešle ARP dotaz (ARP request) obsahující hledanou IP adresu a údaje o sobě (vlastní IP adresu a MAC adresu). Tento dotaz se posílá linkovým broadcastem – na MAC adresu identifikující všechny účastníky dané lokální sítě. ARP dotaz nepřekročí hranice dané podsítě, ale všechna k ní připojená zařízení dotaz obdrží a jako optimalizační krok si zapíší údaje o jeho odesilateli (IP adresu a odpovídající MAC adresu) do své ARP cache. Vlastník hledané IP adresy pak odešle tazateli ARP odpověď (ARP reply) obsahující vlastní IP adresu a MAC adresu. Tu si tazatel zapíše do ARP cache a může odeslat datagram. Informace o MAC adresách odpovídajících jednotlivým IP adresám se ukládají do ARP cache, kde jsou uloženy do vypršení své platnosti. Není tedy třeba hledat MAC adresu před odesláním každého datagramu – jednou získaná informace se využívá opakovaně. V řadě operačních systémů (Linux, Windows XP) lze obsah ARP cache zobrazit a ovlivňovat příkazem arp. ARP PROXY: smerovac se vydava za cilovou adresu, vyuzitelne pokud jsou dve fyzicky oddelene podsite (obr) RARP (Reverse Address Resolution Protocol): se v počítačových sítích s IP protokolem používá k získání vlastní IP adresy počítače při znalosti MAC adresy (tu každý počítač zná, má ji v trvalé paměti síťové karty). Vysílající vyšle RARP dotaz (RARP request) obsahující vlastní MAC adresu. Dotaz se posílá na MAC broadcast, tedy všem počítačům v dané fyzické síti. V ní by se měl nacházet RARP server opatřený tabulkou obsahující IP adresy příslušející jednotlivým MAC adresám. Server prohlédne tabulku a pokud v ní najde MAC adresu tazatele, pošle mu zpět RARP odpověď (RARP reply) s IP adresou, kterou si má nastavit. RARP umožňuje centrální správu IP adres, trpí však dvěma významnými nedostatky: • •
Dotaz se posílá na fyzickou (MAC) broadcastovou adresu, nepřekročí tedy hranice fyzické sítě. V důsledku toho nelze mít v rozsáhlejší síti složené z několika podsítí jeden společný RARP server. Předává pouze IP adresu. Stanice však ke svému síťovému životu potřebuje více informací (masku podsítě, implicitní bránu, adresu DNS serveru). Tyto informace nelze přenášet prostřednictvím RARP.
Důsledkem těchto nevýhod je, že se RARP prakticky nepoužívá. Pro automatickou konfiguraci stanic se častěji nasazují lepší protokoly DHCP nebo BOOTP. Typy zprav: 1. 2. 3. 4.
ARP request ARP reply RARP request RARP reply
OTÁZKA č. 13 http://st.vse.cz/~XRENP01/cert.htm Šifrování: Symetrické: Základním principem této metody je použití stejného šifrovacího klíče na zašifrování i odšifrování zprávy. Z toho vyplívá, že před vlastní komunikací je nejprve nutné předat druhé straně důvěryhodným způsobem šifrovací klíč a údaje o použitém algoritmu. Metoda využívá skutečnosti, že i při relativně malé délce klíče je i pro současnou techniku velmi časově náročné klíč uhádnout. Navíc s prodlužováním klíče tento čas exponenciálně roste. V současné době se nejvíce používají algoritmy DES, TRIPLEDES a IDEA. Hlavní výhodou této metody je rychlost. Nevýhodou je, že nelze splnit požadavek nezpochybnitelnosti odpovědi, protože nelze určit, kdo zprávu odeslal a kdo ji převzal. Autenticnost se zajisti zakodovanim nejake zprávy, odeslanim, rozkodovanim, zakodovanim a odeslanim zpet, pokud je shoda, pak je zprava autenticna.
Asymetricke: Asymetrická kryptografie používá dvou klíčů - veřejného a privátního. Tyto klíče si uživatel vygeneruje pomocí nějakého softwaru (např. SSL) => každý uživatel má svůj privátní a veřejný klíč. Princip metody spočívá v tom, že privátní klíč si majitel pečlivě uschová (čipová karta apod.) a svůj veřejný klíč dá ostatním k dispozici. Odesilatel pomocí svého privátního klíče zprávu zašifruje a odešle. Pomocí veřejného klíče odesilatele mohou příjemci zprávy zprávu dešifrovat a tím také mají informaci o tom, kdo zprávu poslal (tedy víme kdo ji poslal a je overene autenticnost zprávy, tedy je duveryhodna). Protože veřejný klíč odesilatele je přístupný všem, zpráva je jím pouze podepsaná, nikoli zašifrovaná proti zneužití (důvěryhodná). Tímto způsobem je zajištěna podmínka integrace a nezpochybnitelnosti odpovědi.
Pokud chceme zajistit bezpečnost přenášených dat z hlediska zneužití, zašifruje odesilatel zprávu pomocí veřejného klíče adresáta. Pouze adresát pak tuto zprávu dešifruje pomocí svého privátního klíče. Tím je zajištěn přenos zprávy zašifrované (důvěryhodné), ale nepodepsané.
Kombinací obou výše uvedených případů asymetrického kryptování lze dosáhnout přenosu zprávy jak důvěryhodné tak i autorizované. Celý postup ukazuje následující schéma:
OTÁZKA č. 14 http://www.ohnesorg.cz/publikace/1695.html Elektronická pošta: způsob odesílání a přijímání zpráv přes elektronické komunikační systémy. Termín e-mail platí jak pro internetový e-mailový systém založený na protokolu SMTP (Simple Mail Transfer Protocol), tak i pro intranetové systémy, které dovolují uživatelům uvnitř jedné společnosti nebo organizace posílat si vzájemně zprávy (tyto systémy často používají nestandardní protokoly, mívají ovšem bránu, která jim dovoluje posílat a přijímat e-maily z internetu). Princip: Zpráva je nejdříve podle RFC 822 přeformátována do požadované podoby, je tedy opatřena tzv. hlavičkami, adresou odesílatele a příjemce, datem a časem vytvoření. Hlavičky se od těla zprávy oddělují jedním prázdným řádkem. Zpráva je z klientského počítače většinou nejdříve poslána na server jeho providera. Server u providera vyhodnotí z transportní obálky, na který stroj se má pošta poslat. Každý server, přes který zpráva prochází, je povinen na její začátek umístit hlavičku Received:. Pokud využijeme funkce zobrazení zdrojového textu zprávy, můžeme si přečíst, kudy k nám zpráva přišla a kde se všude toulala. Když zpráva doputuje k cíli, tedy stroji, kde Franta má fyzicky umístěnu svou poštovní schránku, je do ní uložena. Protokoly pro přijem posty: - Smtp (7bit - ascii) - pop (vytvareni lokalni kopie) - mime (binarni data, podpora nejen English) - smime (sifrovani, bezpecnost) - imap4 (cteni, mazani, kopirovani emailu na postovnim serveru)
OTÁZKA č. 15 http://www.svetsiti.cz/view.asp?rubrika=Tutorialy&temaID=23&clanekID=29 http://www.svetsiti.cz/view.asp?rubrika=Tutorialy&temaID=23&clanekID=30 http://snmp.adventnet.com/help/snmpapi/snmpv3/snmp_operations/retrievingintro.html SNMP (Simply network management protocol): - protocol pro správu site - model klient-server Klientský program, zvaný síťový manager, vytváří virtuální spojení se serverem, zvaným SNMP agent, který běží na sledovaném síťovém zařízení. Agent monitoruje stav zařízení a poskytuje o něm informace manageru (např. počet zpracovaných paketů/sec, počet chybových paketů atd.). Síťový administrátor, pracující se síťovým managerem, tak může mnohem snadněji spravovat síť, identifikovat a řešit vzniklé problémy. Informace, poskytované agentem, jsou uspořádány podle databáze MIB (Management Information Base), která svojí strukturou odpovídá danému zařízení.
•
•
SNMP Manager - je program, který běží na síťové stanici. U větších systémů jde většinou o vyhrazenou výkonnou pracovní stanici s běžícím software NMS (Network Management System). Funkce tohoto SNMP Manageru pak spočívá v dotazování jednotlivých SNMP Agentů pomocí SNMP operací. Smyslem je získat všechny potřebné informace o daném zařízení, které agent reprezentuje. SNMP Manager poskytuje většinou grafické rozhraní, které umožňuje prezentaci získaných dat, sledování síťových alarmů a archivaci dat (např. k analýze časového vývoje). SNMP Agent - je malý program, běžící na síťovém zařízení, který jej reprezentuje a odpovídá na dotazy SNMP Managera. Agent proto neustále monitoruje a sbírá informace o všech dostupných funkcích a stavech daného zařízení. K získání informací o daném zařízení, manager musí vyslat požadavek na dané zařízení a projít informace poskytované agentem. Musí projít celou stromovou strukturou MIB až k objektu, který obsahuje potřebná data, aby mohl získané informace interpretovat.
MIB (Management Information Base). MIB je datová hierarchická stromová struktura, která odpovídá danému konkrétnímu zařízení. Každá řádka v tabulce MIB hodnot musí obsahovat index nebo jinou hodnotu, která jednoznačně řádek identifikuje. Např. RMON MIB host tabulka obsahuje statistiku komunikace pro všechny uzly sítě a tato tabulka je indexována pomocí jejich MAC adres. Když správní stanice nezná hodnotu tohoto indexu (např. v případě, že je na síti poprvé nalezeno v jednom prohledávacím cyklu více uzlů), musí stanice použít sérii dotazů. Použitím SNMP příkazu GetNext obdrží informace vždy jen o jednom uzlu, jeho opakováním získá celou tabulku.
GetRequest - žádost o informaci, kterou posílá Manager Agentovi k získání informace o stavu nebo hodnotě jistého objektu. Jde vlastně o příkaz "Read". V rámci jednoho příkazu je možné žádat informace o více objektech. To redukuje nutnou komunikaci mezi zařízeními. GetNextRequest - žádost o další informaci. Protože informace jsou organizovány hierarchicky, jde o žádost o informaci na další, nižší vrstvě MIB struktury. GetRespons - tento příkaz je vyslán Agentem jako odpověď na příkaz GetRequest, kterým vrací vyžádanou informaci. SetRequest - příkaz nastavuje hodnotu proměnné v MIB Agenta. Jde vlastně o příkaz "Write". Ne všichni výrobci SNMP zařízení jej umožňují. Pak ale uživatelé nemohou ve skutečnosti provádět "management" zařízení, ale pouze jeho monitorování. Trap - tento příkaz je vyslán Agentem Managerovi jako oznámení nějaké významné události. Na rozdíl od předchozích příkazů, není očekávaná odpověď. Výrobci samozřejmě definují vlastní Traps, specifické pro jejich zařízení. Např. u inteligentního rozbočovače to mohou být události jako Power Supply Failure, Autopartitioned Port, Jabbering Port atd.
Speciálním typem agenta je tzv. proxy agent. Proxy agent může pracovat pro zařízení, které např. neumí komunikovat pomocí protokolu SNMP a tak participovat na sběru informací do MIB. Jiným využitím proxy agenta je např. caching - sběr informací - do společné MIB zařízení vzdálené sítě nebo údajů, které se nemění příliš často. V obou případech se jedná o redukci potřebných požadavků managera na procházení MIB a tak můžeme monitorovat i vzdálenou síť přes relativně pomalý WAN spoj, který by byl normálně vlastní SNMP komunikací plně vytížen. Každá hodnota v SNMP je jednoznačně identifikována pomocí číselného identifikátoru OID - Object Identifier. OID je tvořeno posloupností čísel oddělených tečkou, tato hodnota vznikne tak, že se vezme OID nadřazeného prvku a doplní se tečka a aktuální číslo. Celá tato stromová struktura je uložena v MIB databázi. Navíc MIB databáze obsahuje jména a popisy jednotlivých hodnot (OID). MIB databáze může být doplněna o další hodnoty pomocí části struktury uložené v MIB souboru. Příkladem OID může být třeba hodnota 1.3.6.1.2.1.2.2.1.6.1, které odpovídá textová verzi z MIB databáze iso.org.dod.internet.mgmt.mib-2.interfaces.ifTable.ifEntry.ifPhysAddress.
OID … identifikator objektu OID instance … konkretni hodnota daneho prvku Příklad jednoduchého datového typu: OID.0 Příklad strukturovaného datovéhop typu: OID.x …..x je {1..n} Zjištění konce MIB sloupce: pokud narazim na konec tak se me vrati jine OID nez jsem odeslal, napr.: ja odeslu 1.1 a vrati se 1.2, 1.3, 2.1 konec MIB sloupce
OTÁZKA č. 16 http://en.wikipedia.org/wiki/Open_Shortest_Path_First http://www.abclinuxu.cz/clanky/site/ospf-dynamicke-routovani http://www.fi.muni.cz/~kas/p090/referaty/2001-podzim/routovani.1.html#rip OSPF (Open shortest path first): - interní smerovani - link-state protokol (každý uzel zna celou topologii, zaplavovy algoritmus) - overovani pravosti prenasenych zprav - vyrovnavani zateze - import RIP cest do sve DB - rozsahle smerovaci tabulky - naslednik RIP - pouziva MD5 - pouziva primo IpvX Link state protocol: Link state protokol (LSP) je určen pro rozsáhlejší sitě - pro sítě do velikosti autonomního systému. Router pracujicí v protokolu LSP testuje pomoci HALLO paketu jednou za 10s (> 40s = dead interval, linka prohlasena za mrtvou), zda-li je sousedni router ziv. V pravidelnych intervalech pak zaplavuje sit obezniky (multicast), ve kterych uvadi jake ma momentalne (zive) sousedy. Takze kazdy router obdrzi informace o vsech routerech v siti a o tom jake maji sousedy. Uklada si tyto informace do databaze. V pripade, ze prijde nejaky paket, ktery ma router routovat, tak si zjisti IP-adresu prijemce. Na databazi spusti algoritmus nejkratsi cesty, za ktereho zjisti nasledujici router k prijemci. Na tento router paket odesle. Jelikoz zaplavovani pakety by mohlo sit zatezovat, tak se rozsahlejsi site deli na oblasti. Routing se pak vyrizuje na dvou urovnich: uvnitr oblasti a mezi oblastmi. Použiva zpravy: Hello – vyhledani souseda Database Description – přenos databaze sousedovi Link State Request – požadavek na zaslani databaze (synchronizace) Link State Update – oprava topologie (router, network, network summary, ASBR summary, AS external LSA) Link State Acknowledgement – potvrzeni opravy topologie
Topologie a druhy smerovacu
Urceni ceny linky: - všechny mají stejnou cenu - prevracena hodnota kapacity - zpozdeni linky - vyuziti linky
OTÁZKA č. 17 http://www.lupa.cz/clanky/mobilni-ipv6-konecne-rfc/ Mobilní IP: určeno pro uživatele mobilních zařízení, kteří se chtějí pohybovat z jedné site do druhé při zachovani pripojeni Použití: -
wifi, wireless
Stridani IP adres, důsledky: - nezname jeho aktualni adresu - pokud on sam navazal spojeni, muze to vadit jeho vyssim vrstvam TCP Dva typy entit: - (smerovac v domaci siti) domací agent který uchovava informace o mobilnim uzlu a siti ve které je prave prihlasen - (smerovac v cizi siti) cizi agent uchovava informace o mobilnim uzlu, který je prave na navsteve
Princip -
-
-
predpoklad jedne pevne IP adresy, tam kde je pripojen pokud není mobilni (pod touto adresou je zaregistrovan v DNS) pokud je zrovna na cestach, zastupuje jej v domaci siti jeho domaci agent (to je smerovac domovske site u nejz se mobilni uzel zaregistruje a pozada ho aby ho pri jeho mobilite zastupoval a posle mu svou aktualni mobilni IP adresu site kde se prave nachazi), u domaciho agenta se vytvori vazba na mobilni uzel od tohoto okamziku se domaci agent vydava za mobilni uzel a veskere datagramy které smeruji na jeho domovskou adresu preposila sifrovanym tunelem na aktualni mobilni adresu
Vylepseni v IPv6 Nevyhody: - pakety smerovani neefektivne, zbytecne zatezovani linek, mozne selhani domaci agenta IPv6 : optimalizace smerovani
OTÁZKA č. 18 http://en.wikipedia.org/wiki/Voice_over_IP http://en.wikipedia.org/wiki/H.323 Přenos hlasu přes IP: - při přenosu hlasu IP sítí je nutno zajistit především určité časové parametry přenosu VoIP (Voice over Internet Protocol): je technologie, umožňující přenos digitalizovaného hlasu v těle paketů rodiny protokolů UDP/TCP/IP prostřednictvím počítačové sítě nebo jiného média, prostupného pro protokol IP. Využívá se pro telefonování prostřednictvím Internetu, intranetu nebo jakéhokoliv jiného datového spojení. Seznam prvku pouzivanych VoIP a jejich funkci: - koncove stanice - gate keeper - brany - MMU (konferencni hovor) H323 nabízí tyto služby: - zakodovani dat - prenos dat RTCP, RTP - navazani spojeni
Kvalita služeb (QoS) - průchodností - objem dat, která jsou přenesena za určitou dobu - ztrátovostí paketů - procentuální vyjádření počtu paketů, které nedorazí k adresátovi - zpožděním - doba potřebná k přenosu paketu od zdroje k adresátovi - změnou zpoždění - změna zpoždění jednotlivých paketů během přenosu
- přenos na třetí vrstvě IP protokolem na čtvrté vrstvě UDP službou - hlas patricne zakodovan = kodeky - dále pakety nesou informace o rizeni spojeni, telefonni signalizaci, dostupnost komunikujich zarizeni atd… - na pate vrstve se pak vyskytuje protokol RTP (real time protocol) a ten teprve ma v sobe jako naklad kousky hovoru
OTÁZKA č. 19 http://www.tcpipguide.com/free/t_SessionLayerLayer5.htm Relační úroveň: Koordinuje komunikace a udržuje relaci tak dlouho, dokud je potřebná. Dále zajišťuje zabezpečovací, přihlašovací a správní funkce. Je softwarová. Zajišťuje pravidla pro navazování a ukončování datových přenosů mezi uzly na síti. Dále zajišťuje služby typu překlad jmen na adresy nebo bezpečnost přístupu. Smyslem vrstvy je organizovat a synchronizovat dialog mezi spolupracujícími relačními vrstvami obou systémů a řídit výměnu dat mezi nimi. Umožňuje vytvoření a ukončení relačního spojení, synchronizaci a obnovení spojení, oznamovaní výjimečných stavů. Poměrně zajímavou funkcí této vrstvy je synchronizace datových přenosů. Asi máte zkušenost se stahováním velkých objemů dat z Internetu. Uprostřed přenosu se rozpojí modem a nezbude než zanadávat na telekom a zkusit to znovu. Pak jsou dvě možnosti – buď používáte software, který je schopen navázat na již staženou část (samozřejmě umí-li to i server) nebo začínáte od začátku. Navazování je zajištěno pomocí značek, které vytváří právě spojová vrstva. Hlavni synchronizacni body: potvrzovany (při zacatku vysilani posle SYN, prijemce si pakety uklada do cache pameti, teprve az si je stahne na disk, pak je mozne poslat hlavni SYN signal a na strane odesilatele se muze tento soubor smazat) Vedlejsi synchronizacni body: nepotvrzovany (po celou dobu prenosu) Příkladem protokolů spojové vrstvy jsou : • • • • •
Network File System (NFS) Structured Query Language (SQL) Remote Procedure Call (RPC) AppleTalk Session Protocol (ASP) Digital Network Architecture Session Control Protocol (DNA SCP)
Datové jednotky přenášené spojovou vrstvou jsou TPDU (Session Layer Protocol Data Unit).
OTÁZKA č. 32 viz otázka č.1 http://cs.wikipedia.org/wiki/IP_protokol http://en.wikipedia.org/wiki/Internet_protocol_suite http://www.networksorcery.com/enp/protocol/ip.htm#TOS,%20Type%20of%20Service IP-protokol je tvořen několika dílčími protokoly: • • • •
Vlastním protokolem IP. Služebním protokolem ICMP sloužícímu zejména k signalizaci mimořádných stavů. Služebním protokolem IGMP sloužícímu pro dopravu adresných oběžníků. Služební protokoly ARP a RARP, které jsou často vyčleňovány jako samostatné na IP nezávislé protokoly, protože jejich rámce nejsou předcházeny IP-záhlavím.
Data jsou od odesilatele k příjemci dopravována (směrována) přes směrovače (router). Na cestě od odesilatele k příjemci se může vyskytnout cela řada směrovačů. Každý směrovač řeší samostatně směrování k následujícímu směrovači. Data jsou tak předávána od směrovače k směrovači.
Volitelná:
1. 2. 3. 4. 5. 6.
Zaznamenávej směrovače (record route). Zaznamenávej čas (timestamp). Explicitní směrování (loose source routing). Striktní explicitní směrování (strict source routing). Upozornění pro směrovač (IP Router Alert Option). Bezpečnostní omezení dle normy RFC-1108. Jelikož zabezpečení na úrovni IP-protokolu je jen doplňkovou formou zabezpečení, tak v praxi (mimo armádu USA) nenašlo toto rozšíření uplatnění.
TTL (time to live): Doba života datagramu slouží k zamezení nekonečného toulání IP-datagramu Internetem. Každý směrovač kladnou položku TTL snižuje alespoň o jedničku. Není-li už možné hodnotu snížit, IPdatagram se zahazuje a odesilateli IP-datagramu je tato situace signalizována protokolem ICMP. Jak se hodnota položky TTL nastavuje? U příkazů ping a traceroute je ji možné explicitně nastavit. Obecně se však jedná o parametr jádra operačního systému, pokud ji tvůrci programu nenastaví explicitně).
TOS (type of service): Typ služby je položka, která v praxi nenašla svého naplnění. V normách RFC-791 a RFC-1349 lze nalézt konkrétní návrhy využití. Záměr spočíval v jistém nedostatku IP-protokolu jehož podstatou je skutečnost, že v Internetu není zaručena šíře přenosového pásma mezi účastníky. Jistého vylepšení se mělo dosáhnout právě touto položkou, pomocí které je možné označit některé IP-datagramy tak, aby byly dopravovány přednostně či aby byla zaručena rychlá odezvat atp. Fragmentace: Každý fragment tvoří samostatný IP-datagram. Při fragmentaci je nutné vytvořit pro každý fragment nové IP-záhlaví. Některé údaje (jako protokol vyšší vrstvy, či IP-adresa odesilatele a příjemce) se získají ze záhlaví původního IP-datagramu. Při fragmentaci vstupuje do hry pole “Posunutí fragmentu od počátku IPdatagramu (fragment offset)”, které vyjadřuje kolik bajtů datové části původního IP-datagramu bylo vloženo do předchozích fragmentů. Pole “Celková délka IP-datagramu (total length)” obsahuje délku fragmentu, nikoliv délku původního datagramu. Aby příjemce poznal jak je původní datagram dlouhý, tak je poslední fragment opatřen příznakem “Poslední fragment”.
OTÁZKA č. 38 viz otázka č. 8 http://www.svetsiti.cz/view.asp?rubrika=Tutorialy&temaID=1&clanekID=8 Princip řízení toku: Každý oktet v rámci segmentu je potvrzen tím, že je potvrzeno přijetí segmentu, který oktet obsahuje. Potvrzování je podobné potvrzování u navazování spojení (handshaking). Používá příznak ACK a sekvenční čísla. Zdrojový proces musí uchovávat všechna odeslaná data dokud neobdrží potvrzení jejich převzetí. Jestliže potvrzení nepřijde do určité doby (uživatelsky ovlivnitelná veličina), proces považuje data za ztracená nebo poškozená a odešle je znovu – všechna počínaje prvním nepotvrzeným bytem. Pokud nepřijde odpověď do vypršení časovače, je provedeno opětovné odeslání všech nepotvrzených dat. Počet možných opakování je uživatelsky ovlivnitelný a dojde-li k jeho překročení je pro vyšší vrstvy generována chyba a přerušeno TCP spojení. TCP proces má dvě fronty – frontu pro odesílaná data a frontu pro přijímaná data. Již bylo řečeno, že data v odesílací frontě jsou držena dokud nepřijde potvrzení jejich přijetí. Poté je fronta uvolněna a od vyšší vrstvy jsou přijata nová data k odeslání. Cílový proces si podle sekvenčních čísel ukládá přijímané segmenty do přijímací fronty (bufferu) a tím dochází ke skládání přijímané informace. Tato data postupuje ke zpracování vyšší vrstvě. Již bylo řečeno, že potvrzovací proces je založen na sekvenčních číslech. Sekvenční čísla jsou generována v první chvíli náhodně a v průběhu procesu komunikace jsou postupně zvyšována o příslušný počet již odeslaných (obdržených) oktetů (bytů). Protože potvrzování každého segmentu je neefektivní, byl zvolen specifický model řízení toku dat založený na tzv. okně (window). Tento model zefektivňuje proces potvrzování přijatých paketů. Jenom pro zajímavost si zkuste spočítat jak dlouho by trval přenos 1 MB dat po internetu za předpokladu, že by byl potvrzován každý paket, zpoždění průchodu paketu od jednoho uzlu k druhému a zpět je 100 ms a MTU je 500 byte. Uvažujme ideální síť kde nedochází ke ztrátám paketů. Pro zjednodušení nebudeme počítat skutečnou dobu, ale pouze navýšení doby přenosu. Při uvedených hodnotách by došlo k cca 2.000 potvrzením, při každém čekáme 100 ms, takže potvrzovací mechanismus zabere 200 sekund navíc. Přínos okna je v tom, že významně redukuje počet potvrzování. Okno má určitou velikost, která představuje objem dat přenesený do potvrzení. Počáteční velikost okna je určena v procesu ustavení spojení a může být v průběhu přenosu měněna. Na obrázku jsou vidět data a způsob implementace okna. Úplně vlevo jsou data, která byla již odeslána a potvrzena, dále je okno a data, která teprve čekají na zařazení do procesu. Okno má dvě části – odeslaná (ale ještě nepotvrzená data) a neodeslaná data a tři významné body: levá strana – všechna data vlevo byla odeslána a potvrzena; data vpravo jsou obsažena v okně; pravá stana – data vlevo jsou obsažena v okně, data vpravo čekají na další posun okna; nejvyšší oktet v okně je posledním, který bude v rámci tohoto okna odeslán před potvrzením z cílového uzlu; hranice – je významný bod uvnitř okna, data vlevo byla odeslána a čekají na potvrzení, data vpravo budou odeslána ještě před přijetím potvrzení. Všechny referenční body se dynamicky posunují. Hranice se posunuje v rámci okna dokud nedojde k pravé straně. Poté proces čeká na přijetí potvrzení. Jakmile potvrzení dorazí je přesunuto celé okno a proces se opakuje. V případě, že nedorazí potvrzení v době dané časovačem, je odesláno celé okno.
OTÁZKA č. 40 http://www.lupa.cz/clanky/co-potrebuje-internet-skupinove-adresovani/ http://209.85.129.104/search?q=cache:NTZYN_Xa10UJ:www.cs.cmu.edu/afs/cs.cmu.edu/project/pscicoguyb/realworld/www/multicast.ps+multicast+RPB&hl=cs&ct=clnk&cd=3&gl=cz&client=firefox-a
Skupinové směrování Problém: Unicast adresování je založeno na modelu komunikace klient/server, kdy dochází k přenosu údajů vždy pouze mezi dvěma hosty. Tento způsob adresování dat je však zcela nevhodný v případech, kdy je nutné přenést stejná data k více hostům. Taková data je totiž třeba vysílat postupně ke všem hostům, což je velice neefektivní. Pokud je počet uživatelů a objem dat malý, nepředstavuje takový způsob přenosu významnější problém. Se vzrůstajícím objemem přenášených dat a počtem uživatelů se však začala projevovat nutnost řešit celý problém podstatně efektivněji, tedy implementací skupinového adresování. Ještě výrazněji je výhoda skupinového směrování vidět v případě nasazení při vysílání internetového rozhlasu či televize. Pokud je takové vysílání zajímavé, např. přímý přenos nějaké významné události, může počet současně přijímajících uživatelů dosahovat astronomických hodnot. Pokud jde o vysílání o slušné kvalitě (80kb/s a více), dojde velice rychle k vyčerpání přenosové kapacity, kterou je vysílající server k Internetu připojen. Pokud je přenos sledován více uživateli v síti, dochází pak samozřejmě také ke zbytečnému zatěžování spojení na straně zákazníka.
OTÁZKA č. 41 viz otázka č. 4 http://cs.wikipedia.org/wiki/Domain_Name_System DNS (Domain name server): Hierarchický systém doménových jmen, který je realizován servery DNS a protokolem stejného jména, kterým si vyměňují informace. Jeho hlavním úkolem a příčinou vzniku jsou vzájemné převody doménových jmen a IP adres uzlů sítě. Jména domén umožňují lepší orientaci lidem, adresy pro stroje jsou však vyjádřeny pomocí adres 32bitových (IPv4) A záznam nebo 128bitových (IPv6) - AAAA záznam. Systém DNS umožňuje efektivně udržovat decentralizované databáze doménových jmen a jejich překlad na IP adresy. Stejně tak zajišťuje zpětný překlad IP adresy na doménové jméno. Prostor doménových jmen tvoří strom. Každý uzel tohoto stromu obsahuje informace o části jména (doméně), které je mu přiděleno a odkazy na své podřízené domény. Kořenem stromu je tzv. kořenová doména, která se zapisuje jako samotná tečka. Pod ní se v hierarchii nacházejí tzv. domény nejvyšší úrovně (Top-Level Domain, TLD). Ty jsou buď tematické (com pro komerci, edu pro vzdělávací instituce atd.) nebo státní (cz pro Českou republiku, sk pro Slovensko atd.). Výhoda tohoto uspořádání spočívá v možnosti zónu rozdělit a správu její části svěřit někomu dalšímu. Nově vzniklá zóna se tak stane autoritativní pro přidělený jmenný prostor. Právě možnost delegování pravomocí a distribuovaná správa tvoří klíčové vlastnosti DNS a jsou velmi podstatné pro jeho úspěch. DNS servery (name servery): DNS server může hrát vůči doméně (přesněji zóně, ale ve většině případů jsou tyto pojmy zaměnitelné) jednu ze tří rolí: • • •
Primární server je ten, na němž data vznikají. Pokud je třeba provést v doméně změnu, musí se editovat data na jejím primárním serveru. Každá doména má právě jeden primární server. Sekundární server je automatickou kopií primárního. Průběžně si aktualizuje data a slouží jednak jako záloha pro případ výpadku primárního serveru, jednak pro rozkládání záteže u frekventovaných domén. Každá doména musí mít alespoň jeden sekundární server. Pomocný (caching only) server slouží jako vyrovnávací paměť pro snížení záteže celého systému. Uchovává si odpovědi a poskytuje je při opakování dotazů, dokud nevyprší jejich životnost.
Odpověď pocházející přímo od primárního či sekundárního serveru je autoritativní, čili je brána za správnou. Z hlediska věrohodnosti odpovědí není mezi primárním a sekundárním serverem rozdíl, oba jsou autoritativní. Naproti tomu odpověď poskytnutá z vyrovnávací paměti není autoritativní. Klient může požádat o autoritativní odpověď, v běžných případech ale stačí jakákoli. Reseni dotazu: Každý koncový počítač má ve své konfiguraci síťových parametrů obsaženu i adresu lokálního DNS serveru, na nějž se má obracet s dotazy. V operačních systémech odvozených od Unixu je obsažena v souboru /etc/resolv.conf, v MS Windows ji najdete ve vlastnostech protokolu TCP/IP (případně můžete z příkazového řádku v XP zadat textový příkaz ipconfig /all). Adresu lokálního serveru počítač typicky obdrží prostřednictvím DHCP. Pokud počítač hledá určitou informaci v DNS (např. IP adresu k danému jménu), obrátí se s dotazem na tento lokální server. Každý DNS server má ve své konfiguraci uvedeny IP adresy kořenových serverů (autoritativních serverů pro kořenovou doménu). Obrátí se tedy s dotazem na některý z nich. Kořenové servery mají autoritativní informace o kořenové doméně. Konkrétně znají všechny existující domény nejvyšší úrovně a jejich autoritativní servery. Dotaz je tedy následně směrován na některý z autoritativních serverů domény nejvyšší úrovně, v níž se nachází cílové jméno. Ten je opět schopen poskytnout informace o své doméně a posunout řešení o jedno patro dolů v doménovém stromě. Tímto způsobem řešení postupuje po jednotlivých patrech doménové hierarchie směrem k cíli, až se dostane k serveru autoritativnímu pro hledané jméno, který pošle definitivní odpověď. Může se ale stát, že některý z oslovených serverů má hledanou informaci ve své vyrovnávací paměti, protože odpovídající dotaz nedávno řešil. V takovém případě poskytne neautoritativní odpověď z vyrovnávací paměti a další dotazování odpadá. Ve vyrovnávací paměti mohou být i mezivýsledky například lokální DNS server v ní skoro jistě bude mít informaci o autoritativních serverech pro doménu org, protože v ní pravděpodobně hledá každou chvíli.
OTÁZKA č. 43 http://cs.wikipedia.org/wiki/HTTP_cookie Cookie: (koláček, oplatka, sušenka) se v protokolu HTTP označuje malé množství dat, která WWW server pošle prohlížeči, který je uloží na počítači uživatele. Při každé další návštěvě téhož serveru pak prohlížeč tato data posílá zpět serveru. Cookies běžně slouží k rozlišování jednotlivých uživatelů, ukládá se do nich obsah „nákupního košíku“ v elektronických obchodech, uživatelské předvolby apod. Soubor cookie je textový řetězec, který je součástí požadavků a odpovědí protokolu HTTP (Hypertext Transfer Protocol). Soubory cookie slouží k uchovávání informací o stavu při procházení různých stránek na webu nebo při pozdějším návratu na web. Funkce cookies je definována v RFC 2965 pomocí HTTP hlaviček Set-Cookie (nebo její novější varianty Set-Cookie2) a Cookie. Hlavička Set-Cookie je poslána v odpovědi serveru a obsahuje jednak data cookie (omezená prohlížečem, vyžadována je podpora alespoň pro 4096 byte), jednak informace o době platnosti, adresář na serveru, pro který cookie platí apod. Cookies neznamenají žádné nebezpečí pro počítač jako takový. Přesto cookies mohou být nebezpečné pro ochranu soukromí. Navštívený web si totiž může ukládat do cookies jakékoliv informace, které o návštěvníkovi zjistí a může tak postupně zjišťovat zájmy konkrétního návštěvníka. Které stránky navštěvuje, jaké informace vyhledává, jak často daný web navštěvuje apod.
OTÁZKA č. 47 http://www.cpress.cz/knihy/tcp-ip-bezp/CD-0x/9.html Slow start is part of the congestion control strategy used by TCP, the data transmission protocol used by many Internet applications, such as HTTP and Secure Shell. Slow-start is used in conjunction with other algorithms to avoid sending more data than the network is capable of transmitting, that is, network congestion. Nejprve odešle jeden segment a vyčká na jeho potvrzení. Pokud potvrzení obdrží, pak vyšle dva segmenty. Pokud potvrzení obdrží, pak odešle čtyři atd. Jedná se o řadu 2n(která je exponenciální). Pochopitelně, že po několika krocích se odesilatel dostane do situace, kdy síť zahltí a potvrzení nedostane, tj. musí opakovat odesílání segmentů, protože se segment ztratil. V takovém okamžiku se velikost okenka (mnozstvi zprav které je mozne poslat bez nutnosti cekat na potvrzeni) zmenší na polovinu a tato hodnota se také nastaví do veličiny SSTHRESH (pokud by SSTRESH mělo být menší než dva segmenty, pak se nastaví na velikost dvou segmentů). SSTHRESH … pravdepodobnost zahlceni site Je třeba rozlišovat jakým způsobem byl zjištěn stav, že segment nebyl potvrzen. Nyní jsme předpokládali, že se segment po cestě k příjemci ztratil. Příjemce segment nedostal a tak stále potvrzuje předchozí (přijatý) segment. Po třech zopakovaných potvrzeních předchozího přijatého segmentu se segment považuje za ztracený a odesilatel jej opakuje. Může však nastat situace, že odesilatel ve stanoveném časovém intervalu nedostane vůbec žádné potvrzení (ani žádného předchozího segmentu). V takovém případě se CWND nastaví na velikost jednoho segmentu (MSS) a SSTHRESH na dvojnásobek velikosti segmentu (2x MSS) a začne se s pomalým startem od počátku.
OTÁZKA č. 48 viz otázka č. 15 MIB (Management Information Base). MIB je datová hierarchická stromová struktura, která odpovídá danému konkrétnímu zařízení. Každá řádka v tabulce MIB hodnot musí obsahovat index nebo jinou hodnotu, která jednoznačně řádek identifikuje. Např. RMON MIB host tabulka obsahuje statistiku komunikace pro všechny uzly sítě a tato tabulka je indexována pomocí jejich MAC adres. Když správní stanice nezná hodnotu tohoto indexu (např. v případě, že je na síti poprvé nalezeno v jednom prohledávacím cyklu více uzlů), musí stanice použít sérii dotazů. Použitím SNMP příkazu GetNext obdrží informace vždy jen o jednom uzlu, jeho opakováním získá celou tabulku. Každá hodnota v SNMP je jednoznačně identifikována pomocí číselného identifikátoru OID - Object Identifier. OID je tvořeno posloupností čísel oddělených tečkou, tato hodnota vznikne tak, že se vezme OID nadřazeného prvku a doplní se tečka a aktuální číslo. Celá tato stromová struktura je uložena v MIB databázi. Navíc MIB databáze obsahuje jména a popisy jednotlivých hodnot (OID). MIB databáze může být doplněna o další hodnoty pomocí části struktury uložené v MIB souboru. Příkladem OID může být třeba hodnota 1.3.6.1.2.1.2.2.1.6.1, které odpovídá textová verzi z MIB databáze iso.org.dod.internet.mgmt.mib-2.interfaces.ifTable.ifEntry.ifPhysAddress.
OID … identifikator objektu OID instance … konkretni hodnota daneho prvku Příklad jednoduchého datového typu: OID.0 Příklad strukturovaného datovéhop typu: OID.x …..x je {1..n} Zjištění konce MIB sloupce: pokud narazim na konec tak se me vrati jine OID nez jsem odeslal, napr.: ja odeslu 1.1 a vrati se 1.2, 1.3, 2.1 konec MIB sloupce
OTÁZKA č.49 http://www.svetsiti.cz/view.asp?rubrika=Tutorialy&temaID=23&clanekID=38 http://www.zvon.org/tmRFC/RFC3577/Output/chapter5.html RMON 2 Problém: Dnešní sítě jsou souhrnem mnoha segmentů, propojených přepínači a směrovači. Nedostatek agentů podle standardu RMON je v tom, že vidí komunikaci pouze na "svém" lokálním LAN segmentu a nejsou schopni identifikovat uzly a další síťové zdroje, které leží "za" směrovačem. Aby toho agent byl schopen, musí umět identifikovat komunikací na 3. (síťové) vrstvě OSI modelu a tak provádět statistiku i pro všechny uzly, přistupující k tomuto segmentu, bez závislosti na tom, kde konkrétně leží, nebo jak jsou sítě propojené. Základní rozšíření RMON2 obsahuje tyto prvky: • • • • •
tabulky uzlů na základě síťové adresy, tabulky křížové komunikace uzlů na síťové vrstvě setříděné podle uzlů, podle jednotlivých protokolů nebo podle standardních RMON atributů, jako jsou využití přenosového pásma, počet přenesených paketů, atd. tabulky uzlů a jejich křížové komunikace na základě aplikační vrstvy, setříděné podle aplikací nebo podle standardních RMON atributů; mapování síťových adres pro vytvoření agregovaných statistik, setříděných podle síťové nebo MAC adresy (pro Ethernet a Token Ring sítě); skupinu Protocol Directory and Distribution pro zobrazení vybraných protokolů a jejich distribuce pro každý LAN segment; skupinu pro historickou statistiku a analýzu, která je uživatelsky definovatelná a rozšiřuje statistiku linkové vrstvy podle RMON o statistiku podle RMON2, MIB-I a MIB-II.
Agregovaný index: slouzi k zobrazeni vybraných protokolů a jejich distribuce pro každý LAN segment (Protocol Directory and Distribution) • Indexování ProtocolDirTable – agregovaný index složený z » protocolDirID (ether2.ip.tcp.http) » protocolDirParameters
OTÁZKA č. 50 viz otázka č. 6 http://www.fi.muni.cz/~kas/p090/referaty/2001-podzim/routovani.1.html#rip RVP (Routing vector protocol) neboli DVA (Distance Vector Algorithm) Routing vector protocol (RVP) je velice jednoduchý protokol. Routery vysílají protokolem RVP do svých síťových interfaců obsah své routovací tabulky. Takže sousední routery si mohou přečíst vzájemně své routovací tabulky. Router A přijme z určitého síťového interface routovací tabulku svého souseda B. V routovací tabulce svého souseda B připočte ke všem metrikám cenu (metriku) k sousedovi a začne porovnávat, není-li v takto opravené sousedově routovací B tabulce nějaká nová cesta, aby si ji zařadil do své routovací tabulky. Také zjišťuje, neni-li tam cesta k síti, kterou sice v tabulce má, ale s nižší metrikou. Pokud v sousedově routovací tabulce najde lepší cestu, pak původní položku své routovací tabulky nahradí novou.
OTÁZKA č. 51 http://www.networksorcery.com/enp/protocol/igmp.htm http://www.lupa.cz/clanky/uvod-do-ip-multicastu-dil-ctvrty/ http://www.microsoft.com/technet/prodtechnol/windowsserver2003/cs/library/ServerHelp/ffa6231a-bf9b-4691a63d-81c9cf66a34e.mspx?mfr=true IGMP (Internet group management protocol): Princip vícesměrového vysílání IP: Data vícesměrového vysílání IP jsou odesílána na jedinou adresu, ale zpracovává je více hostitelů. Princip vícesměrového vysílání IP je podobný principu novinového předplatného. Podobně jako právě vydané noviny obdrží pouze jejich předplatitelé, data protokolu IP odeslaná na adresu IP rezervovanou pro skupinu vícesměrového vysílání přijmou a zpracují pouze hostitelské počítače, které patří do této skupiny. Skupina hostitelů, kteří přijímají zprávy odeslané na určitou adresu IP pro vícesměrové vysílání, se nazývá skupina vícesměrového vysílání. Další důležité rysy vícesměrového vysílání IP: • Členství ve skupinách je dynamické, hostitelé se mohou ke skupině kdykoli připojit a kdykoli z ní opět vystoupit. • Připojování hostitelů ke skupinám vícesměrového vysílání se provádí prostřednictvím zpráv IGMP. • Velikost skupin není omezena a jejich členové mohou být rozptýleni ve více sítích IP (pokud směrovače, kterými jsou tyto sítě propojeny, podporují šíření dat vícesměrového vysílání IP a informací o členství ve skupinách). • Hostitel, který odesílá data protokolu IP na adresu IP skupiny, nemusí do této skupiny patřit. K výměně informací o stavu členství ve skupinách mezi směrovači IP podporujícími vícesměrové vysílání a členy skupin vícesměrového vysílání se používá protokol IGMP. Informace o členství ve skupinách vícesměrového vysílání dodávají jednotliví členové těchto skupin, stav členství je v pravidelných intervalech testován směrovači vícesměrového vysílání.
Zapouzdreni dat IGMP do datagramu IP
IGMPv1: • • • • •
Version - aktuální verze protokolu (1), Type - tato verze podporuje pouze dva typy zpráv: o Membership Query, kód 1, o Membership Report, kód 2, Unused - nepoužito, při posílání by mělo být nastaveno na 0 a při příjmu ignorováno, Checksum - kontrolní součet IGMP zprávy, Group Address - u zprávy Membership Report obsahuje toto pole multicastovou adresu, jinak by mělo být nastaveno na 0.0.0.0.
IGMPv2: •
• • •
Type - hodnoty totoho pole jsou voleny tak, aby bylo možné rozeznat zprávy IGMPv1, které na tomto místě mají políčka dvě - version a type. Protokol rozeznává následující typy zpráv: o Membership Query - vlastně jsou dvě, General Query a Group-specific Query, rozlišení se dělá podle obsahu políčka Group Address, číselný kód zprávy je 11, tedy zpráva vypadá podobně jako IGMPv1 Query, o IGMPv1 Membership Report - pro zpětnou kompatibilitu, kód zprávy 12, o IGMPv2 Membership Report, kód 16, o Leave Group, kód 17, Max Resp Time - používá se u Query zprávy a označuje maximální čas na zaslání reportu v desetinách sekundy. Mechanismus je stejný jako u IGMPv1, Checksum - kontrolní součet IGMP zprávy, Group Address - u zpráv Membership Report, Leave Group a Group-specific Query obsahuje toto pole multicastovou adresu, jinak by mělo být 0.0.0.0. Z toho je vidět, že zpráva General Query u IGMPv2 je až na pole Max Resp Time shodná s Membership Query u IGMPv1.
IGMPv3: • pokud jste členem nějaké multicastové skupiny, nechcete často přijímat zprávy od všech, ale pouze od vybraných zdrojů. Proto se v IGMPv3 nepřihlašujete pouze do skupiny (*, G), ale přihlašujete se k odběru dat z konkrétního zdroje v dané skupině (S, G).
OTÁZKA č. 52 http://www.hw-group.com/support/nvt/index_cz.html http://www.freesoft.org/CIE/RFC/854/3.htm NVT (Network Virtual Terminal): Jedná se o řídící sekvence v datovém toku po TCP/IP, kdy znak „FF“ v datovém toku uvozuje následnou řídící sekvenci, která má předepsaný formát, popsaný podrobněji v kapitole o Telnetu. Je-li v datech potřeba přenést tento znak „FF“ (hodnotu bytu 255 decimálně), musí jej vysílací strana zdvojit, jinak budou data za tímto znakem považována za řídící sekvenci, a dojde ke kolizi. NVT lze proto vypnout a pokud jej používáte, musí minimálně toto zdvojení znaku „FF“ respektovat obě strany síťového spojení. The Network Virtual Terminal (NVT) is a bi-directional character device. The NVT has a printer and a keyboard. The printer responds to incoming data and the keyboard produces outgoing data which is sent over the TELNET connection and, if "echoes" are desired, to the NVT's printer as well. -
-
-
povinne minimum, které musí umet všechny terminaly odpovida jednoduchemu radkovemu terminalu o data jsou clenena na radky o prenasena po znacich (po 8 bitech, ale standartne se predpoklada prenos 7 ASCII znaku) o poloduplex o pouziva se lokalni echo o ukonceni radky, klient a server si je musí nahradit obsahuje postupy na dohodnuti se lepsich prikazech spolehlive prenosove sluzby TCP/IP ridici prikazy o editacni prikazy: umoznuji mazat radku a znak o ridici prikazy: umoznuji prerusit probihajici prenos, zastavit jeho vystup o dohadovaci prikazy: umoznuji obema stranam dohodnout se na pripadnych rozsirenich oproti NVT moznost komunikovat plnym duplexem pouzivani vzdaleneho echa k dohadovani slouzi samostane prikazy WILL (ja chci pouzivat rozsireni) a DO (chci abys pouzival tohle rozsireni, odpoved: WILL)
Příkazy: • • • • •
Interrupt Process (IP) Abort Output (AO) Are You There (AYT) Erase Character (EC) Erase Line (EL)
OTÁZKA č. 54 viz otázka č. 13 http://st.vse.cz/~XRENP01/cert.htm http://www.abclinuxu.cz/slovnik/hash http://www.ikaros.cz/node/84 Šifrování: Základní mechanizmy šifrování • Substituce: pouze nahrada některych znaků jinymi podle předem definovaneho mapovani → realizace prostředky S–box. • Transpozice: přeskupeni znaků nasledujicich za předem definovanym přiznakem (např. transpozični tabulka) → realizovano prostředky P-box. • Kombinace: kaskadni použiti S a P boxů. Pojmy, definice • Kryptoanalyza – uměni rozlomit šifru • Kryptografie – uměni vymyslet šifru (šifrovani) • Kryptologie – studium kryptoanalyzy a kryptografie • Šifrovani tajnym kličem – použiva tentyž klič pro šifrovani i dešifrovani. Klič musí byt držen v tajnosti. • Šifrovani veřejnym kličem – použiva veřejny klič pro šifrovani a tajny klič pro dešifrovani. Držen v tajnosti musi byt pouze tajny klič.
Šifrovani tajnym kličem, symetricke metody šifrovani. 1. Substitučni šifry a. Každe pismeno nebo skupina pismen je nahrazena jinym pismenem nebo skupinou pismen b. Např. Caesarova šifra – použita Caesarovymi vojsky c. Jednoduše prolomitelne 2. Transpozični šifry a. Přeuspořadani pismen, ale ne překodovani b. Sloupcove šifrovani – otevřeny text je šifrovan po sloupcich různymi kličovymi slovy c. ne tak jednoduche prolomeni jako u substitučnich šifer. 3. Jednorazova hesla a. Šifrovany text je vytvařen konverzi otevřeneho textu na bitovy řetězec a XORovan s nahodnym bitovym řetězcem. Delka přenašenych dat je omezena delkou řetězce (kliče) b. Neprolomitelna šifra c. Klič je obtižne si pamatovat – odesilatel i přijemce musi přenašet i kopii kliče d. Vyžaduje striktni synchronizaci mezi odesilatelem a přijemcem. Jeden chybějici bit může pomotat cokoliv 4. DES – Data Encryption System • Každa iterace i použiva jiny klič Ki. Složitost zavisi na komolici funkci f. • Klič Ki je odvozovan od počatečniho 56 bitoveho kliče. a. Šifrovaci algoritmus vyvinut v r. 1970 National Bureau of Standards and Technology a IBM. b. Použiva delku kliče 56 bitů a 19 různych stavů c. Velmi silny, ale prolomitelny 5. Triple DES – řeši problem přiliš kratkeho kliče DES jeho rozšiřenim na 112 bitů a. Pro šifrovani postupně použiva algoritmus šifrovani kličem K1, dešifrovani kličem K2 a šifrovani kličen K1. b. Pro dešifrovani postupně použiva algoritmus dešifrovani kličem K1, šifrovani kličem K2 a dešifrovani kličen K1. 6. AES/Rijndael a. DES je nyni přiliš slaby b. Nyni nahrazovan vitězem konkurzu o šifrovaci standard (AES – Advanced Encription Standard) – Rijndael.
7. IDEA – International Data Encription Standard a. Publikovan v r. 1990 b. Použiva klič delky 128 bitů c. Velmi silne šifrovani, nebyly publikovany žadne prakticke utoky, utok hrubou silou neni prakticky d. Pokryty různymi mezinarodnimi patenty 8. Skipjack a. Tajny algoritmus vyvinuty NSA b. Je použit v šifrovacim čipu Clipper c. Využiva klič delky 80 bitů
Metody šifrovani veřejnym kličem 6. RSA – vytvořeno pany Rivest, Shamir a Adlemin v r. 1978 a Velmi silna šifra b Podporuje proměnnou delku kličů c Delši kliče zajišťuji větši bezpečnost d Algoritmus založen na počitani s velkymi prvočisly Hash funkce: Hash funkce je transformace, která jako vstup přijímá řetězec znaků o libovolné délce a výsledkem je pak řetězec znaků s pevnou délkou, tzv. hash nebo také otisk. Hash funkce se často používají v kryptografii, kde se však na její kvalitu kladou další kritéria. Co tedy očekáváme od kvalitní hash funkce: • • • • •
vstup může být jakékoli délky výstup musí mít pevnou délku hodnota hash musí být jednoduše vypočitatelná pro jakýkoli vstupní řetězec funkce je jednosměrná (irreverzibilní) funkce je bez kolizí
Funkce je jednosměrná, pokud je nemožné jednoznačně najít k otisku původní text. Funkce je slabě bezkolizní, pokud k danému textu není výpočetně možné vymyslet jiný text, který bude mít stejný otisk. Funkce je silně bezkolizní, pokud není výpočetně možné najít dva různé texty se stejným otiskem.
OTÁZKA č. 55 http://www.lupa.cz/clanky/typy-vyuzivajici-chyb-a-vycerpani-systemovych-prostredku-2/ http://www.lupa.cz/clanky/denial-of-service-dos-utoky-zaplavove-typy/ DoS (Denial of Service): - jeden z mnoha základních forem útoků na vnitřní sítě - založen na přetížení systému - výsledkem je omezení výkonnosti serveru nebo úplný výpadek cílového systému - útok může být zaměřen na síťové komponenty nebo na hostitelské systémy
Přetížení systému • Cílem DoS je ztlumit skutečný provoz „odpadním“ provozem o Dochází k vytěsňování reálných přenosů - Klienti na základě detekce zahlcení zpomalují vysílání - Směrovače musí přebytečné pakety odstraňovat • Zahozené pakety vedou k exponenciálnímu nárůstu času opakování • Směrovače jsou přetíženy • Servery se mohou přetížit zvyšováním počtu požadavků na vytvoření spojení o Vytváření TCP spojení vyžaduje zapamatování stavu a odezvu serveru o Server požaduje odpověď na SYN od klientů o Klienti ale neodpovídají na výzvu serveru IP spoofing (navádění k nepravostem) • Navádění systému, aby vložil odlišné zdrojové IP adresy do IP záhlaví o DoS útočníci navádějí ze dvou důvodů - Nechtějí být odhaleni - Spoofing může přidat další zatížení • Jestliže navádíte s cizími ale legitimními IP adresami o Může být spuštěn Reset buď z napadeného počítače, nebo z počítače s použitou IP adresou - Okamžité uvolnění zdrojů serveru o Pečlivý výběr sekvenčních čísel na straně serveru může ukončit pokus o navázání spojení • Jestliže navádíte s náhodně vybraným IP Útoky Denial of Services 2 o Odpověď serveru na klientské SYN se ztratí o Server uvolní zdroje ale typicky až za 75 sekund Klíčové prvky DoS útoku • Převedení těžiště činnosti na jiné uzly o Princip – co je jednoduché pro mě musí být složité pro tebe o Př.: IP spoofing - Já: generuji SYN pakety jak rychle to jen jde (mikrosekundy) - Ty: timeout odstraňuje SYN každých 75 sekund
Záplavové utoky: Spočívají v zahlcení linky oběti takovým množstvím dat, že znemožní regulérní provoz. Laicky řečeno: znamená to, že pokud naše oběť bude připojena k Internetu rychlostí 128kbit/s a útočník bude připojen 512kbit/s a začne posílat oběti data, co nejrychleji může, zahltí tím linku oběti. Oběť nebude mít šanci komunikovat s okolím, jelikož kapacita linky bude vyčerpána.
ICMP záplava (ICMP Flood) Již z jména pramení, že tento útok využívá protokolu ICMP, nejčastěji se používají pakety typu ICMP Echo, což jsou pakety, které využívají ping a slouží k zjišťování, zda je vzdálené zařízení dostupné. Podle doporučení (RFC) by měla být maximální velikost ICMP Echo paketu 548 B, ovšem program ping jak pro systémy Windows, tak i pro Linux umožňuje velikost ICMP Echo paketu až 65 kB (největší možný ICMP Echo paket může být 65.535 B, tak to uvádí specifikace). ICMP Echo funguje tak, že my pošleme ICMP Echo request a cílový počítač posílá zpátky ICMP Echo reply. Přitom zachovává velikost paketu. Toho lze využít tak, že zfalšujeme adresu odesílatele a tím docílíme, že datová linka oběti bude ucpávána dvakrát. Jednou daty směrem tam a podruhé daty zpátky (která budou určena oné zfalšované adrese). Vlastnosti: obyčejný záplavový útok, výhodné je, že pokud oběť odpovídá, zahlcuje se její linka dvojnásob. Útok je velmi lehké provést. TCP záplavy (TCP Flood, SYN Flood) Útok využíval špatné implementace hanshaku. I když nelze vlastně přímo říci, že to byla špatná implementace, nikdo prostě s tímto útokem nepočítal. Chyba byla v tom, že když server obdržel paket od klienta s nastaveným příznakem SYN, tak alokoval pro toto spojení systémové zdroje (prostředky), odeslal mu paket s nastavenými příznaky SYN+ACK a čekal na odpověď. Samozřejmě že se v Internetu občas nějaký paket ztratí. Proto když odpověď stále nepřicházela, server (operační systém) si myslel, že se asi ztratila, a poslal paket s nastavenými příznaky SYN+ACK znovu. Po určité době si řekl, že už mu asi žádná odpověď nepřijde, a proto alokaci těchto systémových zdrojů (prostředků) zrušil spolu se záznamem o původní inicializaci spojení. Pokud ovšem útočník poslal paketů s příznakem SYN více, vedlo to k tomu, že se vyčerpala všechna možná spojení, která byla otevřena jenom napůl (to znamená, že byl přijat pouze paket s příznakem SYN, byl odeslán paket ACK+SYN, ale odpověď ACK nedorazila). Tím nebylo možné, aby se k dané službě připojil někdo jiný. Ještě horší na tomto útoku je velikost paketu s příznakem SYN, která činí pouhých 42 bytů. Z toho vyplývá, že u tohoto útoku nezáleželo na tom, jak rychle je útočník připojen. Další výhodou bylo, že se u útoku dala falšovat IP adresa odesílatele. Vlastnosti: obyčejné záplavové útoky (kromě SYN a RST Flood).
OTÁZKA č. 56 http://cs.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol SMTP (Simple mail transport protocol): - textove orientovany - standartne port 25 - spojovana sluzba
• • •
MUA - Mail User Agent, poštovní klient, který zpracovává zprávy u uživatele (Outlook, Thunderbird) MTA - Mail Transport Agent, server, který se stará o doručování zprávy na cílový systém adresáta MDA - Mail Delivery Agent, program pro lokální doručování, který umísťuje zprávy do uživatelských schránek
Příkazy: HELO <doména> -- zahajuje komunikaci RSET -- vyčistí obálku NOOP -- nedělá nic, obálka se nemění MAIL FROM: -- přidání odesílatele do obálky RCPT TO: -- přidání adresáta do obálky DATA -- zahajuje přenos zprávy (hlavička + tělo zprávy). Zakončí se . (tečka na samostatném řádku). QUIT ukončí spojení
OTÁZKA č. 57 http://cs.wikipedia.org/wiki/ICMP http://www.svetsiti.cz/view.asp?rubrika=Tutorialy&temaID=1&clanekID=6 ICMP (Internet Control Message Protocol): Tento protokol je vyžadovanou součástí IP protokolu. Každý uzel, který má implementovaný IP protokol jej musí podporovat. Používají ho operační systémy počítačů v síti pro odesílání chybových zpráv - například pro oznámení, že požadovaná služba není dostupná nebo že potřebný počítač nebo router není dosažitelný. ICMP zprávy se konstruují nad IP vrstvou; obvykle z IP datagramu, který ICMP reakci vyvolal. IP vrstva patřičnou ICMP zprávu zapouzdří novou IP hlavičkou (aby se ICMP zpráva dostala zpět k původnímu odesilateli) a obvyklým způsobem vzniklý datagram odešle. Každá ICMP zpráva je zapouzdřená přímo v jediném IP datagramu, a tak (jako u UDP) ICMP nezaručuje doručení. Ačkoli ICMP zprávy jsou obsažené ve standardních IP datagramech, ICMP zprávy se zpracovávají odlišně od normálního zpracování prokolů nad IP. V mnoha případech je nutné prozkoumat obsah ICMP zprávy a doručit patřičnou chybovou zprávu aplikaci, která vyslala původní IP paket, který způsobil odeslání ICMP zprávy k původci. Základním účelem ICPM je informování zdrojového uzlu o chybách při přenosu datagramů. Pro další zjednodušení jsou ICMP zprávy odesílány pouze v případě, že se vyskytl problém s nefragmentovaným datagramem nebo v případě fragmentace pouze u prvního fragmentu. Tyto chyby vznikají např. tím, že: • směrovač musí zrušit paket při překročení TTL; • směrovač nemá dostatečný buffer pro přeposlání datagramu; • směrovač musí fragmentovat datagram, ale ten má nastaven příznak "Don´t Fragment"; • směrovač nebo uzel zjistí chybu v syntaxi IP hlavičky; • směrovač nemá v tabulce záznam o cílové síti.
