Příklady otázek ke zkoušce z předmětu PSI

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 ne- ASCII 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. <network number><subnet number><host 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: <host>.<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. 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. 2. 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. 3. 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. 4. 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. 5. 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). 6. Lokální server opět jeden z nich vybere a pošle mu dotaz na IP adresu ke jménu www.wikipedia.org. 7. 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 8. 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. Ethernet Statistic : statistika provozu Group 2.2. Ethernet History : historický pohled na RMON statistiku Group 3. Alarms : nastavení prahové úrovně a vzorkovací intervaly Group 4. Hosts : poskytuje prenosovou statistku pro každý sitovy uzel v tabulkovem formatu Group 5. Host Top N : setridene tabulky podle statistik v zavislosti na MAC adrese Group 6. Traffic Matrix: zobrazuje vzajemnou komunikaci mezi jednotlivymi uzly Group 7. Filters : Group 8. Packet Capture : vytvoreni vicenasobnych buferu pro zachycene pakety Group 9. 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: TFTP: 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 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 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 Screened Subnet 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. ARP request 2. ARP reply 3. RARP request 4. 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