Příklady otázek ke zkoušce z předmětu PSI 1. Uveďte a

Transkript

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.
<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.
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
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.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://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
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
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.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
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 <CR><LF> 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:<adresa> -- přidání odesílatele do obálky
RCPT TO:<adresa> -- přidání adresáta do obálky
DATA -- zahajuje přenos zprávy (hlavička + tělo zprávy). Zakončí se <CR><LF>.<CR><LF> (tečka na
samostatném řádku).
QUIT ukončí spojení
OTÁZKA č. 57
http://cs.wikipedia.org/wiki/ICMP
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.

Příklady otázek ke zkoušce z předmětu PSI 1. Uveďte a

Transkript

Podobné dokumenty

Informace a Internet

MO 925H - Goddess

10. Větrné elektrárny v Krušných horách

Epson LQ-2080 značky Epson - 315B2 - Přečtěte si

PB156 – Počítačové siete: súhrn otázok 1. Definujte propustnost

Počítačové sítě a Linux

Více informací o OmniSwitch 6450

EtherHaul 1200

Co je to IBSE?

Switche pro FTTx - nasazení v sítích s IPTV

Vigor 2700VG

Netfilter

2G-10S.F Předsériový katalogový list / produkce od D