Skip to content

Latest commit

 

History

History
1363 lines (1074 loc) · 54.1 KB

main.org

File metadata and controls

1363 lines (1074 loc) · 54.1 KB

Síťové aplikace a správa sítí

Architektura sítí

Vrstvový model definuje síťové vrstvy. Každá vrstva určuje obecné funkce poskytované vyšším vrstvám. Funkce dané vrstvy jsou implementovány příslušnými protokoly dané vrstvy. Pro služby vyšší vrstvy je činnost nižších vrstev transparentní.

Při komunikaci na vrstvách komunikující koncové body leží vždy ve stejné vrstvě a pro komunikaci se využívá služeb nižších vrstev.

Procesy aplikační vrstvy komunikují pomocí socketů (schránek). Ty jsou identifikovány IP adresou a číslem portu.

Model OSI

Model OSI definuje 7 vrstev:

  1. Fyzická vrstva
  2. Linková vrstva
  3. Síťová vrstva
  4. Transportní vrstva
  5. Vrstva sezení
  6. Prezentační vrstva
  7. Aplikační vrstva

Model IEEE

Model IEEE definuje 2 vrstvy:

  1. MAC vrstva
  2. LLC vrstva

Model TCP/IP

Definuje 4 vrstvy:

  1. Vrstva síťového rozhraní (fyzická a linková vrstva dle OSI)
  2. Internetová vrstva (síťová vrstva dle OSI)
  3. Transportní vrstva
  4. Aplikační vrstva

Adresování

Adresa

Adresa je způsob identifikace adresáta pomocí jednoznačné informace

Adresování a směrování v modelu TCP/IP

Každá vrstva modelu TCP/IP definuje svoje adresování a zajišťuje určitou formu směrování. Některé služby používají mapování adres mezi vrstvami.

Adresování a směrování na fyzickém rozhraní (L2)

Adresuje se konkrétní síťové rozhraní počítače. To je identifikováno 48bitovou fyzickou adresou. Ta určuje adresování v lokální síti. Prvních 24 bitů je OUI (Organizational Unique Identifier), zbylých 24 bitů je číslo síťového rozhraní přiděleného výrobcem karty. L2 rámec obsahuje:

  • 7+1B preambule (synchronizace + typ)
  • 48b source address
  • 48b destination address
  • 16b ethertype
  • … data … (max 1500 B)
  • 32b checksum

Speciální adresy L2 vrstvy

  • Broadcast: FF FF FF FF FF FF
  • IPv4 multicast 01 00 5e xx xx xx
  • IPv6 multicast 33 33 xx xx xx xx

Adresování a směrování na síťové (IP) vrstvě

Používá se 32bitová IPv4 adresa nebo 128bitová IPv6 adresa. IP adresa jednoznačně identifikuje síťové rozhraní počítače v síti. Je určena pro adresování i mimo lokální síť.

IPv4 se může adresovat s využitím tříd (A, B, C, D, E). Používá se netid + hostid. Délku části netid určuje pevná nebo proměnná maska.

Při použití variabilní délky masky se prostor IPv4 adres dá efektivněji využít, vytváří se podsítě (subnetting). Používá se beztřídní směrování.

Přidělování adres

Přidělení IP adres může být provedeno buď manuálně v operačním systému nebo dynamicky pomocí DHCP.

Pro IPv4 se používá protokol DHCPv4. Nové zařízení vyhledává DHCP server na lokální síti pomocí broadcastu.

Pro IPv6 se používá více způsobů přidělování adres. Typ přidělení oznamuje směrovač zprávou ICMPv6 RA. Typ konfigurace může být:

  1. Bezstavová konfigurace pomocí SLAAC (Stateless Autoconfiguration)
  2. Bezstavová konfigurace pomocí SLAAC a DHCPv6
  3. Stavová konfigurace pomocí DHCPv6

Adresování a směrování na transportní vrstvě

Adresuje je konkrétní služba pomocí 16b čísla portu (uvedena v /etc/services). Číslo portu jednoznačně identifiuje službu na daném počítači. Rozlišujeme spojované (TCP) a nespojované (UDP) služby.

Adresování na aplikační vrstvě

Je závislé na konkrétní aplikaci. Příklady:

Základní nástroje pro konfiguraci

Výpis aktuálního síťového nastavení

  • ifconfig, ip link, ip address (Linux)
  • ipconfig (Windows)

Testování základní konektivity

  • ping, pathping

Kontrola směrování

  • netstat -r, ip route : Vypíše směrovací tabulku
  • arp -a, ip neigh : Vypíše tabulku ARP, respektive Neighbour Cache

Testování dosažitelnosti vzdáleného počítače

  • tracert, traceroute, tcptraceroute

Testování dostupnosti služeb

  • telnet <addr> <port>

Výpis otevřených spojení

  • sockstat (FreeBSD)
  • netstat -natu (Linux)
  • netstat -a (Windows)

Sledování komunikace na síťovém rozhraní

  • tcpdump
  • tshark
  • Wireshark (GUI1)

Programování sítí TCP/IP

Komunikace klient – server

Jedná se o standardní schema komunikace mezi dvěma procesy. Komunikace je popsána protokolem. Klient posílá požadavky na zpracování serveru, ten je zpracuje a pošle odpověď. Komunikace je obvykle zahájena klientem.

Protokol je soubor syntaktických a sématnických pravidel určujících výměnu dat. Popisuje vytvoření spojení, adresování, přenos dat, řízení toku, zabezpečení. Formálně je protokol specifikován stavovými automaty, gramatikami, formálními jazyky, Petriho sítěmi, diagramy posloupnosti zpráv nebo algebraickými prostředky.

Prostředky pro meziprocesovou komunikaci

Unixové roury, Unix to Unix copy, Remote Procedure Call, BSD sockets, Winsock.

Sockety

Aplikační programové rozhraní pro komunikující procesy. Definují konečný komunikační bod. Implementovány jako abstraktní datové struktury obsahující údaje pro komunikaci. Jsou jednoznačně implementovány v síti pomocí IP adresy a čísla portu. Jsou implementovány ve většině programovacích jazyků.

Vytvářejí rozhraní na vrstvě L4 (transportní). Rozlišujeme několik typů schránek. Základní typy jsou:

  1. SOCK_STREAM (TCP komunikace)
  2. SOCK_DGRAM (UDP datagramy)
  3. SOCK_RAW (Holá schránka bez žádného protokolu. Nutno vyplnit všechny hlavičky ručně)

Funkce v BSD socketech pro vytvoření konkurentního serveru TCP

  1. socket() – Vytvoří schránku
  2. bind() – Připojení schránky na lokální port
  3. listen() – Vytrvoření fronty příchozích požadavků
  4. accept() – Přijímání požadavků
  5. fork() – Vytvoření synovského procesu
  6. read(), write() – Výměna dat v rámci synovského procesu
  7. close() – Zavření schránky synovského procesu
  8. exit() – Ukončení synovského procesu
  9. close() – Uzavření schránky rodičovského procesu

UDP schránky

Když neběží UDP server, klient pošle zprávu pomocí sendto(), čeká na odpověď pomocí recvfrom(). Dojde ale k uváznutí, protože UDP neposkytuje možnosti, jak oznámit nedostupný port. Možná řešení jsou použití timeoutu nebo spojovaných UDP schránek.

Spojované UDP schránky používají funkci connect(), nedochází ale k vytvoření TCP spojení, pouze se zpracovávají chyby. Funkce connect() zjistí aktuální stav serveru, v budoucnu však může dojít k ukončení činnosti UDP serveru a klient to nezjístí. Funkce connect() se tak může volat opakovaně.

Komunikace typu multicast

Jeden paket doručen skupině uzlů v multicastové skupině. Používá se jedna cílová adresa typu multicast. Pro IPv4 tato adresa náleží do třídy D, tedy rozsah 22.0.0.0239.255.255.255. Pro IPv6 se jedná o adresy s prefixem 0xFF00::/8.

Multicastová komunikace umožňuje dynamické připojování uzlů do multicastové skupiny, speciální směrování multicastových adres a řízení dosahu multicastového vysílání.

Pro výpis aktivních multicastových skupin existují příkazy:

  • ifmcstat (FreeBSD)
  • netstat -g, netstat -gn (Linux)
  • netsh interface ip show joins (Windows)

Směrování IP multicastu je implementováno pomocí protokolů DVMRP, PIM, MOSPF. Připojování uzlů do multicastových skupin probíhá pomocí protokolů IGMPv2, IGMPv3, MLD.

Mapování multicastové adresy IPv4 na MAC adresu

Prefix multicastové MAC adresy je 0x01 01 5e. Z multicastové adresy se použije jen posledních 23b do multicastové MAC adresy. Může docházet k překrývání adres.

Mapování multicastové adresy IPv6 na MAC adresu

Nejnižších 32b IPv6 adresy je zkopírováno do MAC adresy, prefix multicastové adresy MAC je 0x33 33.

Vlastnosti multicastové komunikace

Posílá pouze UDP pakety, negarantuje spolehlivé doručení, zachování pořadí… Multicastová adresa identifikuje skupinu síťových rozhraní. Členství ve skupině je dynamické. Počítače se připojují a odpojují.

Multicast a sockety

Podporované schránky jsou třídy AF_INET nebo AF_INET6, typu SOCK_DGRAM nebo SOCK_RAW. Multicastové datagramy mají implicitní TTL nastavenu na 1. Pro vynucení multicastu na socketu se využívá funkce setsockopt(). Konkrétně se jedná o parametry IP_MULTICAST_IF, IP_MULTICAST_TTL, IP_MULTICAST_LOOP.

Na straně klienta je třeba inicializovat rozhraní pro multicast pomocí naplnění struktury struct ip_mreq. Následně je možné se připojit do multicastové skupiny voláním funkce setsockopt() s parametrem IP_ADD_MEMBERSHIP a předáním vytvořené struktury. Pro odpojení od multicastové skupiny se používá parametr IP_DROP_MEMBERSHIP.

Analýza paketů na linkové vrstvě

Zahrnuje zachycení paketů z přenosového média, převod binárních dat do srozumitelné formy, rekonstrukci paketů, analýzu paketů, přenosů a konverzací.

Nástroje pro zpracování paketů na linkové vrstvě

  • Paketový filtr BPF (BSD Packet Filter)
  • Linuxová implementace schránekt typu SOCK_PACKET, PF_PACKET.
  • Knihovna libpcap
  • Knihovna scapy pro Python.

Tyto nástroje zajišťují přímý přístup k paketům na síťovém rozhraní. Aplikace běží jako uživatelský proces mimo jádro systému v privilegovaném režimu. Pracuje pouze s kopií paketu

BSD Packet Filter

Řadič síťové karty zavolá BPF pokaždé, když je paket přijat nebo odeslán. Aplikace nad BPF může filtrovat příchozí pakety, ty jsou uloženy v BPF bufferu. Když je buffer plný nebo vyprší časovač, data jsou předána aplikaci.

Knihovna libpcap

Vytváří API pro zachytávání dat na síťpvém rozhraní. Čte data ze síťového rozhraní nebo ze souboru ve formátu PCAP. Implementuje funkce pro zpracování rámců a jejich analýzu. Původně určena pro jazyk C/C++, následně vytvořeny wrappery pro další jazyky.

Čtení dat probíhá v následující posloupnosti:

  1. Připojení k síťovému rozhraní pcap_lookupdev().
  2. Otevření rozhraní pro čtení pcap_open_live(), pcap_open_offline() (pro PCAP)
  3. Čtení paketů pcap_dispatch(), pcap_loop(), pcap_next()
  4. Analýzu paketů provádí aplikace.

Zabezpečení počítačových sítí

V počítačových sítích existují rizika:

  • Odposlech přenášených dat
  • Neautorizovaný přístup k zařízením
  • Podvržení zprávy
  • Falšování identity
  • Útok na systém (DoS)
  • Škodlivý software

Exisutjí požadavky na bezpečnost:

  • Důvěrnost
  • Autentizace
  • Integrita dat
  • Neodmítnutelnost
  • Dostupnost, kontrola přístupu

Symetrické šifrování s tajným klíčem

Slouží pro zajištění důvěrnosti. Pro šifrování a dešifrování se používá stejný klíč. Doporučená délka klíče je 112 – 256 bitů.

Rovnice pro symetrické šifrování

Pro šifrování platí vztah:

\begin{equation} E_k(M) = C \end{equation}

Kde $E_k$ je šifrovací funkce s klíčem $K$, $M$ je vstupní zpráva.

Pro dešifrování platí vztah:

\begin{equation} D_k(C) = M \end{equation}

Kde $D_k$ je dešifrovací funkce s klíčem $K$.

Bezpečnost symetrického šifrování

Bezpečnost symetrického šifrování spočívá v klíči, nikoliv v principu algoritmu (ten je většinou zveřejněný). Šifrují se buď jednotlivé bity zprávy (proudová šifra) nebo sekvence bitů o pevné velikosti (bloková šifra).

Výhody a nevýhody

Symetrické šifrování má problém s nutností distribuce klíčů a rozšiřitelností. Naopak výhodou je rychlý výpočet.

Příklady symetrických šifrovacích algoritmů

Blokové

  • DES
  • 3DES
  • AES
  • IDEA
  • RC2/4/5/6
  • Blowfish

Proudové

  • DES
  • 3DES
  • RC4
  • SEAL

Nástroje pro symetrické šifrování

Nejpoužívanější je nástroj openssl enc. Obsahuje sadu šifrovacích a dešifrovacích algoritmů.

Asymetrické šifrování s veřejným klíčem

Slouží pro zajištění důvěrnosti a autentizaci.

Princip

Příjemce vygeneruje dva klíče:

  1. Veřejný klíč $KBpub$ pro šifrování
  2. Soukromý klíč $KBsec$ pro dešifrování

Klíč pro šifrování se liší od klíče pro dešifrování. Doporučená dékla klíče je 2048 – 4096 bitů. Soukromý klíč se nedá odvodit z veřejného.

Rovnice pro asymetrické šifrování

Šifrování

\begin{equation} EKB_{pub}(M) = C \end{equation}

Může provést kdokoliv veřejným klíčem příjemce.

Dešifrování

\begin{equation} DKB_{sec}(C) = M \end{equation}

Může provést pouze příjemce svým soukromým klíčem.

Výhody a nevýhody

Snadná rozšiřitelnost, protože veřejný klíč lze vystavit veřejně. Náročné na výpočet kvůli použití dlouhého klíče. Problém s ověřením pravosti veřejného klíče, vyžaduje certifikační autoritu.

Příklady asymetrických šifrovacích algoritmů

  • RSA
  • ElGamal
  • Eliptic curve
  • Diffie-Hellman

Nástroje pro asymetrické šifrování

Používají se nástroje openssl genpkey, openssl pkeyutl, opoenssl rsa. Soukromé klíče je možné ochránit symetrickou šifrou proti zneužití.

Zajíštění integrity dat pomocí kryptografického hashe

Zajišťuje integritu zprávy pomocí tajného klíče. Využívá kryptografickou hashovací funkci, např. MD4/5/6, SHA1/2/3. Ta vytvoří kryptografický hash MAC (Message Authentication Code) o pevné délce. Mechanismus HMAC přidává navíc do výpočtu tajný klíč.

V počítačových sítích se používá hashování pro autentizaci směrovacích zpráv, při použití TLS, PGP, SSH, IPSec nebo pro autentizaci zpráv SMMPv3.

Nástroje pro hashování

  • md5
  • sha1
  • sha256
  • sha384
  • sha512
  • shasum
  • openssl dgst

Elektronický podpis

Využívá asymetrické kryprografie pro ověření odesilatele pomocí jeho soukromého klíče.

Princip a rovnice

Odesilatel A si vygeneruje dvojici klíčů $KAsec$ a $KApub$.

Podepsání

\begin{equation} EKA_{sec}(MD) = DS \end{equation}

Kde $E$ je šifrovací funkce, $MD$ (Message Digest) je hash dokumentu a $DS$ je elektronický podpis.

Ověření podpisu

Příjemce vypočítá hash dokumentu $MD’$ a porovná s dešifrovaným podpisem:

\begin{equation} EKA_{pub}(DS) = MD \end{equation}

Příklady algoritmů

  • RSA
  • DSA
  • Elliptic Curve DSA

Používání elektronického podpisu

Pro používání elektronických podpisů je zřízen systém Public Key Infrastructure, což je systém certifikačních autorit pro správu, uložení a ověření veřejných klíčů. CA generuje, podepisuje, ukládá a ověřuje certifikáty k veřejným klíčům. Ověřuje identitu uživatelů, aplikací nebo organizací a vytváří vazbu s veřejným klíčem.

Digitální certifikát X.509

Dokument ověřující platnost pravého veřejného klíče a příslušnost k danému uživateli. Certifikát vydává a ověřuje certifikační autorita. Pro ověření podpisu CA se používá certifikát kořenové CA. K ověření slouží protokol OSCP (Online Certificate Status Protocol).

Obsah certifikátu X.509

  • Sériové číslo
  • Identifikace vydavatele (Distinguished Name: DN)
  • Datum platnosti
  • Identifikace majitele (DN)
  • Veřejný klíč majitele
  • Účel veřejného klíče (šifrování, ověřování podpisů)
  • Podpis certifikátu podepsaný soukromým klíčem CA
  • Algoritmus pro vytvoření podpisu
  • Otisk certifikátu (hash)
  • Algoritmus pro vytvoření hashe
  • Odkaz na seznam revokovaných certifikátů (CRL)

Použití digitálních certifikátů

  • Bezpečný transport SSL/TLS
  • Zapezpečení IPSec
  • HTTPS
  • S/MIME
  • Autentizace uživatelů pomocí 802.1x

Diffie-Hellman

Asymetrický algoritmus pro vytvoření sdíleného tajného klíče přes nezabezpečený kanál založený na umocňování čísel, kde $(A^B)^C = (A^C)^B$. Nevyžaduje šifrování.

Postup

  1. Uzly A a B se veřejně dohodnou na použitém modulu $m$ a základu $z$.
  2. Uzel A si zvolí tajné číslo $a$.
  3. Uzel A pošle veřejně uzlu B hodnotu $x = z^a mod m$.
  4. Uzel B si zvolí tajné číslo $b$.
  5. Uzel B pošle uzlu A hodnotu $y = z^b mod m$.
  6. Uzel A určí klíč $k = y^a mod m$.
  7. Uzel B spočítá klíč $k = x^b mod m$.
  8. Klíč $k$ se v uzlech A a B rovná.

Zabezpečení komunikace na modelu TCP/IP

Nezávislé zabezpečení dat na jednotlivých vrstvách TCP/IP. Každý mechanismus vyžaduje vytvoření a distribuci klíčů, jejich zabezpečení a ověření. Dosah zabezpečení závisí na typu vrstvy.

Transport Layer Security (TLS)

Komunikuje nad transportní vrstvou v TCP paketech. Zapezpečuje přenos dat protokolů aplikační vrstvy. Zajišťuje důvěrnost, integritu dat a autentizaci klienta či serveru.

TLS Handshake

  1. Client Hello – Klient posílá informace o podporovaných šifrách, verzi TLS
  2. Server Hello – Server posílá informace
  3. Server Certificate – Server sděluje informace o certifikátech
  4. Server Key Exchange – Server zahajuje výměnu klíčů
  5. Client Certificate – Klientský certifikát
  6. Client Key Exchange – Klient opětuje výměnu klíčů
  7. Client Certificate Verify – Klient verifikuje certifikát serveru
  8. Client Change Cipher Spec – Klient mění používanou šifru
  9. Server Change Cipher Spec – Server mění používanou šifru
  10. Encrypted application data – Tok šifrovaných aplikačních dat

Pro výměnu klíčů se používý asymetrická kryptografie (Diffie-Hellman, RSA, Elliptic Curve).

Pro šifrování dat se využívá symetrická kryptografie (je rychlejší).

Vlastnosti

  • Šifrování: obě strany majá vygenerovaný tajný klíč
  • Autentizace: obě strany si navzájem vyění a ověří certifikáty
  • Integrita dat: šifrovaná data obsahují hash
  • Šifrovaná data obsahují sekvenční číslo jako prevenci proti přehrání
  • Před zašifrováním mohou být data komprimována

Omezení TLS

TLS vyžaduje ověřený certifikát serveru, jinak je možný útok Man in the middle. Nezajišťuje autentizaci odesilatele. Problematická implementace na zařízeních s omezenými prostředky (IoT). Problém při potřebě monitorovat provoz.

IPSec

Zabezpečuje přenos pro IPv4 a IPv6. Zajišťuje autentizaci (RSA), šifrování a integritu dat. Využívá protokoly AH (Authentication Header) a ESP (Encapsulation Security Payload). Pracuje ve dvou režimech: tunelovacím a transtortním. Parametry spojení se ukládají do databáze VPN spojení SA (Security Association).

Protokol AH (Authentication Header)

Chrání datagram IP pomocí kryptografického hashe HMAC-MD nebo HMAC-SHA. Hash se počítá nad položkami hlavičky, které se během cesty nemění. Zajišťuje autentizaci, integritu dat a chrání proti přehrání. Nezajišťuje důvěrnost dat.

Protokol ESP (Encapsulation Security Protocol)

Zapouzdřuje a chrání data IP datagramu. Zajišťuje autentizaci, důvěrnost a integritu dat, chrání proti přehrátí. Nezajišťuje ochranu vnější hlavičky IP. Pro šifrování využívá DES, 3DES, AES. Pro autentizaci a integritu dat využívá HMAC.

Zabezpečení emailových zpráv pomocí PGP (Pretty Good Privacy)

Zajišťuje integritu dat (MD5), autentizaci odesilatele (RSA) i šifrování (IDEA). Zpráva je podepsána soukromým klíčem odesilatele. Zpráva je zašifrována tajným klíčem. Tajný klíč je zašifrován veřejným klíčem příjemce a připojen ke zprávě. Odesilatel musí mít přístup k veřejnému klíči přijemce pro zašifrování zprávy. Příjemce musí mít přístup k veřejnému klíči odesilatele pro ověření identity.

Autentizace zpráv směrovacího protokolu OSPF

Protokol je zapouzdřen v IP. Využívá krypto hash MD5 a sdílený tajný klíč. Používá sekvenční číslo proti přehrání podepsaného paketu. Vstupem pro algoritmus MD5 je celý paket OSPF a tajný klíč. Pro OSPFv2 je použít pro autentizaci algoritmus HMAC-SHA

Domain Name System

DNS je globální adresář názvů počítačů a dalších identifikátorů síťových zařízení a služeb

DNS je tvořeno:

  1. Jmenným prostorem DNS adres a mapování adres na IP adresy
  2. Uložení prostoru jmen DNS a správa tohoto prostoru
  3. Přístup k datům v DNS a vyhledávání

DNS je implementováno pomocí hierarchického rozdělení prostoru doménových jmen. Globální databáze DNS jmen je distribuována na servery. Pro DNS existuje stejnojmenný protokol, který přenáší data rezolucí DNS a přenosů zón.

Hierarchické uspořádání je ve formě inverzního stromu.

Pro vyhledání doménového jména dle IP adresy je vytvořena speciální doména arpa, která uchovává mapování.

Správa domén

Globálně je DNS spravováno společností ICANN (Internet Corporation for Assigned Names and Numbers). ICANN akredituje registrátory dalších doménových jmen (Top Level Domain):

  • Národní: .cz, .uk, .de
  • Generické: .com, .edu, .org

Domény první úrovně (TLD) spravuje IANA. Registrace národních domén spravuje národní správce domény. Za ČR je to CZ-NIC.

Domény nižších úrovní spravuje vlastník domény (delegace domén).

Správa IP adres

IP adresy jsou spravovány a registrovány regionálními registrátory (RIC). Pro Evropu a část Asie je to RIPE NCC. V jednotlívých státech spravují lokální registrátoři (LIR) a poskytovatelé připojení. V případě použití Provider Independent adres může koncový uživatel mít adresu přidělenou přímo od RIR, která je nezávislá na dalších registrátorech.

Whois

Služba pro zjišťování vlastníka IP adresy.

DNS server

Prostor doménových jmen fyzicky uložen na server DNS. Servery DNS obsahují informace o stromové struktuře i datech. Každý server spravuje jen část prostoru doménových jmen – Zónu.

Typy DNS serverů:

  • Primární (Master, primary) – Obsahuje úplné (autoritativní) záznamy o doménách. Pro každou doménu existuje pouze jeden primární nameserver
  • Sekundární (Slave, secondary) – Uchovává autoritativní kopie dat od primárních serverů (přenos zón)
  • Záložní (Caching-only) – Pouze přijíma dotazy, které předává dalším serverům DNS. Ukládá odpovědi do vyrovnávací paměti. Poskytuje neautoritativni odpovědi.

Protokol DNS

Aplikační protokol nad UDP, port 53.

Struktura DNS zprávy je následující:

  • Header
  • Question
  • Answer
  • Authority
  • Additional

DNS rezoluce

Komunikace DNS je typu klient – server. Dotazy klienta vyřizuje systémová rutina OS: Resolver.

Rezoluje je proces vyhledání odpovědi v systému DNS. Využívá stromovou strukturu jmen a kořenové DNS servery. Rezoluce začíná od kořenových serverů, těch je 13 a obsahují speciální kořenovou zónu hint.

Rekurzivní dotaz

Pokud server nezná odpověď, přepošle dotaz dalším serverům. Rekurzivní dotaz si ukládá do paměti cache pro další použití.

Iterativní dotaz

Server vrátí nejlepší možnou odpověď. Pokud ale nezná přesnou odpověď, vrátí odkaz na server, který může znát odpověď.

Přenos zón

Přenos zón je komunikace mezi servery DNS. Využívá se k aktualizaci záznamů na DNS serverech. Je možný celkový přenos zón (AXFR) nebo přírůstkový přenos (IXFR), kde sekundární server posílá s výzvou záznam SOA a primární server vrátí rozdílové změny.

Mechanismus DNS notify upozorňuje o změně zóny.

Typy záznamů v DNS

Start of Authority (SOA)

Poskytuje základní informace o zóně. Každá zóna má právě jeden SOA.

Obsahuje:

  • Název primárního serveru a emailovou adresu správce
  • Sériové číslo identifikující změnu záznamu
  • Interval pro zjišťování změny (na sekundárních serverech)
  • Doba, po které se server pokusí aktualizovat zónu v případě ne)spěšného přenosu
  • Doba platnosti dat na sekundátním serveru
  • Implicitní doba TTL záznamů v zónovém souboru dané zóny

Name Server (NS)

Určuje autoritativní servery pro danou zónu. Slouží k budování hierarchické struktury DNS systému. Pro TLD jsou autoritativní servery uvedeny v seznamu root.zone na IANA.

A

Přímé mapování doménových adres na IPv4 adresy.

AAAA

Přímé mapování doménových jmen na IPv6 adresy.

Mail Exchange (MX)

Mapuje adresy poštovních serverů. Přesměrovává poštu pro danou doménu na konkrétní poštovní server. Lze mít více serverů s různou prioritou.

Canonical Name (CNAME)

Mapuje alias zařízení na kanonické jméno počítače. Síťové zařízení smí mít více aliasů. Alias ale nesmí stát na pravé staně záznamu.

Domain Name Pointer (PTR)

Mapuje IPv4 a IPv6 adresu zpětně na doménovou adresu. Využívá speciální podstrom in-addr.arpa a ip6.arpa.

Naming Autority Pointer (NAPTR)

Mapuje řetězce na data. Podporuje dynamickou konfiguraci systému. Používá regulární výrazy pro dynamické záznamy v DNS. Příklad je lokaližace VoIP serveru.

Service Record (SRV)

Loaklizuje služby (například SIP, XMPP …). Slouží také pro load balancing nebo zálohování.

Text (TXT)

Obsahuje textová data. Dodatečné informace o doméně, serveru, správci a podobně. Slouží také k ověření mailových serverů nebo ověření vlastnictví domény pro Google Apps.

Zabezpečení systému DNS

DNS je distribuovaná veřejná služba, která je potřeba k jakékoliv komunikaci na internetu. Je potřeba zajistit zejména integritu dat a autentizaci zdroje dat.

Bezpečnostní rizika

Podvržené odpovědi mohou vracet neautorizované odpovědi na dotaz klienta. Podvržená data v paměti cache mohou zneplatnit data pro mnoho klientů. Při DoS útocích může dojít k blokování jakékoliv DNS rezoluce.

DNSSEC

Zajišťuje integritu a autentizaci dat v DNS. Zabezpečuje data DNS pomocí asymetrické kryptografie (podepisování). Záznamy v DNS zónách jsou podepsány pomocí Zone Signing Key (ZSK). Klíče pro podepisování záznamů jsou dále podepsány pomocí Key Signing Key (KSK).

Při použíti DNSSEC nedochází k šifrování DNS provozu.

DNSSEC definuje nové záznamy DNS:

  • DNSKEY: Veřejný klíč pro ověření podpisů
  • RRSIG: Podpis daného záznamu
  • NSEC, NSEC3: Odkaz na další záznam při dotazu na neexistující doménu
  • DS: Záznam pro ověření záznamu DNSKEY, uležen v nadřazené doméně.

Při použití DNSSEC se využívá Chain of Trust. Jední se o mechanismus ověření pravosti klíče domény nadřazenou doménou. Pro každou zónu existuje pár klíčů (veřejný – tajný). Zabezpečení významně zvyšuje velikost paketu DNS.

Monitorování provozu DNS

Problémem DNS je velká míra informací vztahujících se k odesilateli. IP adresa lze lokalizovat. Podle meta informací lze zjistit lokální konfiguraci DNS serveru, podporu IPv6… Informace získané z dotazu DNS napovídají, co uživatel požaduje za služby, jaké stránky navštěvuje…

DNS byl původně navržen jako veřejná služba přenášející otevřená data.

Lze použít technologii DNS over TLS (DoT), kdy je DNS dotaz šifrován a je viditelný pouze vybranému DNS serveru. Problém je při výběru serveru a nastavéní šifrování.

Další možností je DNS over HTTPS (DoH). Dotazy jsou posílány serveru DNS, kterů je předkonfigurován ve webovém prohlížeči.

Ani jedna z těchto metod neřeší soukromí, pouze problém přesouvají. DNS server bude vždy vidět rozšifrované DNS dotazy (problém při použití například Google DNS).

Hlasové služby

Klasické telefonní sítě PTSN (Public Switched Telephone Networt) se skládá ze 4 prvků:

  1. Koncové zařízení
  2. Lokální smyčka
  3. Ústředna
  4. Páteřní spoje

Klasická telefonní síť garantuje šířku pásma a spolehlivý přenos. U digitálních ústředen je dobrá kvalita přenosu. Klasický telefon může být napájen z telefonní linky. Díky dedikovaným spojům jsou spolehlivé a bezchybné. Mají zavedené standardy a poskytují další služby.

IP telefonie musí zajišťovat služby srovnatelné s PTSN a navíc musí být integrovaná a kompatibilní s PTSN.

Funkce IP telefonie

IP telefonie musí převádět hlas na IP datagramy. Musí řídit komunikaci přes ústřednu nebo mezi telefony. Musí umožňovat registraci účastníků, adresování hovorů (telefonní číslo, URI), směrování hovorů, vytváření hovorů, udržování spojení. Důležitou vlastností je možnost připojení do klasického telefonního systému PTSN.

Kódování hlasu

  1. Vzorḱování analogového signálu
  2. Kvantifikace vzorků pomocí μ -law nebo α -law
  3. Kodování hodnot na binární čísla (PCM, ADPCM, CS-ACELP)
  4. Komprese dat

Lidská řeč se pohybuje v rozsahu 200 Hz – 9 kHz. Telefonní linky běžně přenášeji zvuk v rozsahu 300 Hz – 4 kHz.

Pro korektní kódování hlasu je potřeba vzorkovat dvojnásobnou frekvencí, než je frekvence zvuku. Například pro telefonní linku 4 kHz je třeba vzorkovat na frekvenci 8 kHz, tj. perioda 125 μ s.

Různé protokoly a algoritmy mají odlišná přenosová pásma v závislosti na počtu bitů na vzorek. Například G.711 s algoritmem PCM využívá 8 bitů na vzorek, celkové přenosové pásmo je tedy $2 × 4 kHz × 8 b/sample = 64 kb/s$.

Zapouzdření hlasu

Hlasové vzorky o určité velikosti (časové délce), jsou uloženy do protokolu RTP. Ten je zapouzdřen do UDP, IP, Ethernetu. Běžná režie je tedy 58 B.

Příklad

Vypočtěte potřebnou šířku pásma pro jeden telefonní hovor při použítí kodeku G.711. Telefon posílá hlasové rámce každých 20 ms. Režie je běžná (58 B).

G.711 vyžaduje pásmo 64 kb/s, tj. 8000 B/s. Hlasové rámce jsou posílány každých 20 ms, tj. celkem 50 za sekundu.

ŘEŠENÍ 1:

  1. Vypočteme, kolik bytů se v jednom rámci:
    • Hlasová data: $8000 / 50 = 160 B$
    • Režie: 58 B
    • Celkem> $160 + 58 = 218 B$
  2. Dopočítáme, jaká je hodnota za 1 sekundu
    • $218 × 50 = 10900 B$
  3. Řešení je tedy $10900 B/s = 87200 b/s = 87.2 kb/s$.

ŘEŠENÍ 2:

  1. Počítáme s hlasovým pásmem 8000 B/s, pouze roznásobíme nutnou režii:
    • $58 × 50 = 2900 B$
  2. A přičteme hlasová data
    • $2900 + 8000 = 10900 B$
  3. Řešení je tedy $10900 B/s = 87.2 kb/s$

Architektura systému SIP

SIP je zkratka pro Session Initiation Protocol. Jedná se o aplikační protokol nad UDP určený pro signalizaci VoIP. Provádí registraci uživatelů, navázaní spojení, směrování hovorů, adresování pomocí URI. Neprování správu relací po jejich vytvoření, nezajišťuje kvalitu přenosu, nezajišťuje přenos dat.

SIP tvoří globální distribuovanou architekturu v celém internetu. Systém umožňuje vyhledat a směrovat hovor na libovolný SIP telefon.

SIP server (User Agent Server)

  • Proxy server: analyzuje zprávy, směruje hovory
  • Lokalozační server: informace o umístění klientů
  • Server pro směrování: next-hop u alternativního SIP serveru
  • Registrační server: přijímá žádosti o registraci

Adresování a směrování SIP

Adresování probíhá pomocí SIP uri ve tvaru sip:user@domain. Směrovací inforamce jsou uloženy v SIP hlavičce> Via, Route, Record-route. Směrování provádějí servery SIP na cestě staticky nebo dynamicky pomocí DNS. Po výměně kontaktů v hlavičce Contact jsou zprávy přenášeny přímo mezi klienty.

Vytváření spojení

Registrace

Používá se metoda REGISTER. Ukládá se poloha klienta do lokalizační databáze. Klient posílá svou IP adresu a port SIP serveru ve své doméně. Klient mapuje ID uživatele na adresu zařízení. Registrační server udržuje pro svou doménu lokalizační údaje o všech aktivních klientech.

Ustavení spojení

Používá se metoda INVITE. Pokud je volaný připravený, odpoví zprávou 200 OK, volající potvrdí přijetí a začne komunikace. Metoda INVITE může vyžadovat autorizaci.

Protokol SIP

Obsahuje základní metody:

  • REGISTER – Žádost o registraci
  • INVITE, ACK, CANCEL – Vytváření spojení
  • BYE – Ukončení spojení
  • OPTIONS – Zjišťování možností přenosu
  • INFO – Přenos aplikačních informací
  • MESSAGE – Textové zprávy
  • SUBSCRIBE, NOTIFY – Zasílání upozornění na události
  • PUBLISH – Zveřejnění stavu událostí

Protokol SDP

Session Description Protocol. Přenášen ve zprávách SIP typu INVITE a OK. Přenášejí se informace potřebné pro přijímání hlasového toku.

Protokol RTP

Real-Time Transport Protocol. Používá se pro přenost hlasových či obrazových dat. Obsahuje typ přenášených dat, sekvenční číslo, časovou značku. Pro každý směr a typ médií se otevírá samostatný tok RTP. Pro monitorování kvality přenosů se používá RTP Control Protocol (RTCP).

Zabezpečení VoIP

Bezpečnostní rizika

  • Odposlech
  • Viry
  • Spam over IP Telephony (SPIT)
  • Phishing over IP Telephony (PHIT)
  • Útoky DoS, DDoS
  • Neautorizované použití služby
  • Výpadky napájení

Způsoby zabezpečení

  • Řízení přístupu k síťovému médiu technologií 802.1x
  • Oddělení hlasového provozu pomocí VLAN
  • Zabezpečení spojení pomocí IPSec nebo Secure RTP
  • Napájení Power over Ethernet

Komerční aplikace

Většinou mívají nestandardní protokoly. Bývají decentralizované (peer-to-peer). Využívají proprietární správu uživatelských účtů. Nejsou garantované. Mají omezené možnosti propojení s PTSN či klasickými VoIP.

Streaming multimédií

Streamingem rozumíme přenos multimedíálních dat po síti v reálném čase rychlostí přehrávání. Vhodný mechanismus pro jednorázové doručení. Přijímajícímu stačí jen malá vyrovnávací paměť. Přehrávání začíná po načtení několika prvních sekund.

Rozdělujeme:

  1. Živý přenos – Všem přehrávačům jsou zasílána ve stejný okamžik stejná data. Přehrávání nelze řídit.
  2. Streaming na vyžádání – Klientovi je streamem zasílán předem vytvořený multimediální obsah. Přehrávání lze řídit.

Problémy streamingu

  • Omezená šířka pásma
  • Zatížení sítě
  • Rozptyl paketů
  • Zpoždění
  • Ztráta paketů
  • Nekompatibilita protokolů, formátů dat.

Často se pro řešení využívají vyrovnávací paměti. Ty mohou být buď po cestě mezi klientem a serverem nebo přímo na straně klienta. Před začátkem přehrávání je třeba počkat na načtení dat do vyrovnávací paměti.

Komprese

Při streamingu obvykle dochází ke kompresi dat. Bez použití komprese by byl objem přenesených dat přílš velký. Například při rozlišení FullHD, barevné hloubce 24 bitů, 25 snímcích za sekundu by bylo potřeba přenášet cca 1200 Mb/s.

Před odesláním audia a videa je tedy potřeba provést kompresi.

Audio formáty

G.711, G.726, G.728, MP3, WMA, AAC

Video formáty

H.261, H.263, H.263+, H.264 (MPEG-4 AVC), MPEG-1, MPEG-2, H.265

MPEG transport stream

Standard, který popisuje, jakým způsobem jsou části multimediálního toku kombinovány do jednoho datového toku (multiplexing).

Umožňuje v jednom datovém toku posílat i více multimediálních streamů.

Je vhodný pro přenosy, při kterých může dojít ke ztrátě paketu nebo poškození dat. Datový tok se skládá z paketů pevné velikosti.

Pakety mají obvykle 184 B dat a 4 B hlavičku. První B hlavičky obsahuje hodnotu 0x47, jedná se o synchronizační byte. Klíčovou položkou hlavičky je 13b Packet Identifier, který odpovídá jednotlivým elementárním streamům.

Při přijímání MPEG transport streamu musí příjemce určit, o které konkrétní pakety má zájem, tj. musí určit Packet Identifier. Pro usnadnění výběru jsou jako součást transport streamu zasílána metadata s informacemi o programu (PSI, Program Specific Information).

Real-Time Streaming Protocol, RTSP

Signalizační protokol, který navazuje a ukončuje spojení a také řídí jeden nebo více časově synchornizovaných media streamů (síťový dálkový ovladač).

Je určen pro on demand streamy.

Textový protokol, syntaxe podobná HTTP. Data jsou součástí jiného protokolu, například RTP, MPEG-TS. Je stavový, uchovává si informaci o stavu relace a sekvenční číslo.

Elektronická pošta

Poštovní služby musí zajišťovat adresování a směrování elektronické pošty, formát přenášených zpráv, protokol pro přenos elektronické pošty, přístup k emailovým schránkám, vyhledávání adresátů.

Architektura elektronické pošty se zkládá z poštovního klienta, poštovního serveru a komunikačních protokolů.

Formát zprávy byl původně 7b ASCII, následně byl rozšířen pomocí MIMe (Multipurpose Internet Mail Extension) o netextová data a přílohy.

V současné době mohou být emaily kódovány následovně:

  • 7-bit – Sedmibitové ASCII s řádky max 1000 znaků
  • 8-bit – Osmibitové ASCII, porušuje definici SMTP
  • binary – Porušuje definici SMTP, není zajištěno správné doručení
  • base64 – Kódování osmibitových znaků do 6 bitů (binárně)
  • quoted-printable – Kódování osmibitových znaků do 7 bitů (textová data)

Quoted printable je uvozen znakem =, následují dva znaky. Dle kódovací tabulky lze rozkódovat.

Simple Mail Transfer Protocol (SMTP)

Aplikační protokol nad TCP pro posílání elektronické pošty. Využívá port 25. Definuje formát příkazů a odpovědí a způsob přenosu.

Post Office Protocol (POP3)

Pouze jeden klient může přistupovat k INBOX schránce. Obsah je přenesen ke klientovi a aktualizován až při ukončení práce. Více schránek lze spravovat pouze lokálně u klienta.

Internet Message Access Protocol (IMAP)

Vícenásobný přístup ke schránkám. Je možné pracovat s více schránkami, s hlavičkami i celou zprávou. Obsahuje atributy zpráv (seen, answered, recent, deleted, flagged).

Zabezpečení elektronické pošty

Přenos emailových zpráv mezi servery je uskutečněn pomocí SMTP over SSL/TLS. Čtení emailových zpráv je zabezpečeno pomocí IMAP over SSL, HTTPS. Obsah emailových zpráv je zabezpečen pomocí PGP (Pretty Good Privacy) a S/MIME. Stejným způsobem je zajištěno i podepisování.

Pretty Good Privacy (PGP)

Zajišťuje integritu dat pomocí MD5, autentizaci odesilatele pomocí RSA i šifrování pomocí IDEA.

Zpráva je podepsána soukromým klíčem odesilatele. Zpráva je dále zašifrována tajným klíčem, ten je pak zašifrován veřejným klíčem příjemce a přidán ke zprávě.

Odesilatel musí mít přístup k veřejnému klíčí příjemce pro zašifrování zprávy. Příjemce musí mít přístup k veřejnému klíčí odesilatele pro ověření jeho identity.

Adresářové služby

Elektronická databáze pro vyhledání uživatelů. Navrženo jako podpora elektronické pošty. Je to globální distribuovaný systém s jednotným adresováním. Použivá se pro vyhledání uživatelů (email, IP telefonie), autentizaci a autorizaci (wev, unix, 802.1x), ukládání údajů (Active Directory).

Lightweight Directory Access Protocol (LDAP)

Aplikační protokol nad TCP, port 389. Navržen jako zjednodušená alternativa systému X.500. Využívá jeho koncept pro uspořádání dat – Directory Information Tree (DIT).

DIT se zkládá ze 4 částí:

  1. Informační model
  2. Jmenný model
  3. Funkční model
  4. Bezpečnostní model

Informační model

Popisuje uložení dat. Záznam je popsán třídou objektů. Obsahuje seznam atributů ve tvaru dvojice typ-hodnota. Jednoznačným identifikátorem je Distinguished Name, DN.

Adresářové schéma obsahuje:

  1. Definici třídy objektů pro daný záznam – Typ třídy, seznam atributů
  2. Definici atributů dané třídy – Typ atributu, operace
  3. Definici pravidel pro operace nad atributy – Syntax, odkaz na metodu

Jmenný model

Popisuje uspořádání záznamů v adresáři. Definuje organizaci a identifikaci záznamů v adresáři. Tvoří strukturu DIT, která je grafová. Umožňuje záznamy typu alias a referrals, což jsou speciální URL typu LDAP.

Funkční model

Popisuje komunikační protokol LDAP. Provádí komunikaci typu klient server. Klient vytvoří zprávu a server odpovídá jednou či více zprávami, které obsahují odpověď.

Definuje operace nad daty:

  • Bind/Unbind – Vytvoření/ukončení spojení
  • Compare – Porovnání hodnoty atributu u zadaných záznamů
  • Abandon – Zrušení předchozí operace
  • Modify – Změna konkrétního záznamu
  • Add – Přídání nového záznamu
  • Delete – Zrušení listového záznamu ve stromu
  • ModifyDN – Změna nejlevější komponenty v DN

Správa sítě pomocí ICMP (Internet Control Message Protocol)

Monitorování pomocí ICMP

ICMP se posílá jako součást IP paketu.

ICMP implementuje několik typů zpráv, například:

  • Destination Unreachable
  • Time Exceeded Message
  • Parameter Problem Message
  • Redirect Message
  • Echo
  • Echo Reply
  • Timestamp
  • Timestamp Reply

Nástroje pro monitorování

  • Ping – Posílá ICMP echo zprávy. Cíl odpovídá ICMP echo reply.
  • Traceroute – Posílá ICMP pakety se zvyšujícím se TTL, očekává zprávy ICMP time exceeded message

Bezpečnostní rizika ICMP

Zprávy Echo mohou sloužit k prohledávání sítě. Pomocí ICMP Redirect message může dojít k podvržení implicitní brány.

Monitorování pomocí ICMPv6

ICMPv6 je zapouzdřen přímo v protokolu IPv6. Formát zprávy obsahuje typ zprávy, kód zprávy, kontrolní součet a tělo zprávy. Zprávy jsou rozděleny na chybové a informační.

Simple Network Management Protocol

Základní prvky SNMP:

  • Monitorované objekty – Definice a popis pomocí SMI, adresování pomocí OID
  • Uspořádání objektů do skupin a decentralizovaná správa – Databáze objektů MIB, stromová struktura
  • Systém monitorování – Network Management System (SNMP Server), SNMP Agent
  • Přenosový protokol SNMP

Jazyk Structure Management Information (SNM)

Definuje pravidla pro vytváření monitorovaných objektů.

Popis objektu tvoří:

  • Jméno objektu – Jednoznačný identifikátor
  • Syntax – Abstraktní datový typ spojený s přenosem
  • Kódování pro přenos po síti – Používá se Basic Encoding Rules (BER)

Uspořádání objektů v databázi MIB

Základní strukturou je hierarchický strom objektů.

Kódování objektů pomocí Basic Encoding Rules

Definuje reprezentaci hodnot objektů při přenosu po síti. Používá se struktura Type, Length, Value.

Prokokol SNMP

Aplikační protokol pro práci s monitorovanými objekty. Nestavový protokol typu dotaz-odpověď.

SNMPv3 může být navíc šifrováno a autentizováno pomocí MD5 nebo SHA-1.

Network Time Protocol (NTP)

Pro koordinaci událostí na síti, logování a spouštění skriptů je potřeba mít synchronizovaný čas. Best practice je synchronizovat hodiny na všech síťových zařízeních podle UTC.

Manuální nastavování hodin není ani přesné, ani škálovatelné. V praxi se využívá systém NTP nebo Simple NTP. Ty jsou vytvořeny pro synchronizaci času skrze celou síťovou infrastrukturu. NTP využívá port 123.

NTP vytváří hierarchii serverů mezi několik vrstev, které se nazývají stratum. Servery ve stratu 0 jsou referenční atomové nebo GPS hodiny. Servery ve stratu 1 jsou synchronizovány s odchylkou mikrosekund od stratum 0. Každý další stratum se synchronizuje na předchozí, tj. stratum 2 podle stratum 1, stratum 3 podle stratum 2 atd.

NTP se nikdy nesychronizuje podle serveru, který sám není synchronizován. NTP porovnává časy různých serverů a nesynchronizuje se podle serverů, které mají příliš velkou odchylku od ostatních.

Zařízení s NTP může pracovat ve 3 režimech:

  1. Server – Poskytuje přesný čas klientům v síti
  2. Klient – Synchronizuje čas podle NTP serveru.
  3. Peer – Pouze vyměňuje syncrhonizační informace s ostatními peery.

NTP využívá 4 časové značky:

  1. T1: Originate timestamp – Žádost o synchronizaci zaslaná klientem
  2. T2: Receive timestamp – Žádost o synchronizaci přijatá serverem
  3. T3: Transmit timestamp – Odpověď zaslaná serverem
  4. T4: Destination timestamp – Odpověď přijatá klientem

Pomocí těchto značek může klient přibližně určit zpoždění a offset času.

Syslog

Síťový protokol, který poskytuje celou řadu reportovacích mechanismů. Používá UDP port 514. Logy jsou posílány v plain textu. Syslog definuje úrověň závažnosti zpráv. Čím nižší tato úroveň je, tím závažnější situace.

Syslog zprávy mohou být uloženy do souboru nebo poslány na vzdálený stroj. Velmi často se používá pro logování aplikací jako DHCP, RADIUS, DNS, Web a Email.

Formát zprávy syslog

  • Facility – Dva nebo více znaků, které značí původ zprávy
  • Severity – Číslo závažnosti
  • Mnemonic – Kód, který jednoznačně identifikuje chybovou hlášku
  • Message-text – Text popisující chybu

Analýza logů

Z důvodů velkého množství lodovacách zpráv jsou tyto zprávy těžke na interpretaci a monitorování. Různé aplikace pomáhají ladění, monitorování a odstraňování chyb.

Primárními funkcemi jsou monitorování klientů, SNMP, grafování a notifikace. Monitorování SNMP se používá zejména pro zařízení jako sẃithce a routery. Servery častěji používají monitorování agentů.

Monitorování sítí

Sledování provozu

Deep packet inspection. Rekonstrukce protokolů L3 až L7. Analyzuje data L7 a rekonstruuje vlastní komunikaci. Např. Wireshark.

Vyhledávání známých řetězců (Intrusion Detection Systems, Intrusion Protection Systems)

Detekce malware, identifikace DoS, DDoS, filtrování komunikace.

Statistické údaje o provozu

SNMP, RMON

Statistiky toků

NetFlow, IPFIX, sFlow, OpenFlow

Síťový tok

Tok je posloupnost paketů mající společnou vlastnost a procházející bodem pozorování za určitý časový interval.

Záznam o toku je identifikován zdrojovou a cílovou IP adresou, zdrojovým a cílovým portem, typem protokolu. Dále se mohou uchovávat údaje o datu a čase zaznamenání a počtu přenesených dat toku.

Cisco NetFlow

Původně vyvinut firmou Cisco jako proprietírní standard monitorování provozu. Od verze 5 je mezinárodní standard.

Architektura NetFlow

Exportér

Sonda nebo router pro získávání statistik o tocích. Například nprobe nebo Flowmon probe. Vytváří záznamy o tocích a pak je aktualizuje ve flow cache. Data mají určitou expiraci, a jsou exportována dále pomocí UDP.

K exportu může dojít v několika případech:

  1. Detekován konec toku – U TCP příznak RST nebo FIN
  2. Neaktivita toku – Neaktivní timeout
  3. Příliš dlouhý tok – Aktivní tiemeout
  4. Zaplnění paměti flow cache

Při exportu je tok považován za ukončený a je vymazán z paměti.

V sondách mohou data být vzorkována, tj. vybírá se jen jeden z několika paketů. K vzorkování dochází z důvodu snížení nároků na hardware. Vzorkování může být deterministické (každý ntý paket), nebo náhodné (náhodně se vybere n paketů).

Může docházet k filtrování, kdy se klasifikuje provoz na základě hodnot v hlavičkách paketů. Například logování jen DNS provozu nebo rozdělení pomocí Type of Service.

Exportér může provádět agregaci podle různých prvků, například podle zdrojové IP adresy. To sloučí záznamy v tzv. aggregation cache do méně záznamů.

Kolektor

Přijíme pakety protokolu NetFlow z jednoho nebo více exportérů. Rovněž může probíhat vzorkování, filtrování a agregace. Záznamy o tocích se zpracovávají a statistiky se ukládají na disk nebo do databáze.

Kolektor může poskytovat grafickou prezentaci dat a dotazování nad daty pomocí skriptů nebo webových rozhraní.

Protkol NetFlow verze 5

Obsahuje hlavičku:

  • Počet záznamů
  • Čas odeslání paketu NetFlow
  • Identifikace sondy
  • Typ sondy
  • Nastavení sondy

A strukturovaná data ve formě množiny záznamů o tocích, kde každý záznam obsahuje statistiku o jednom toku.

Data:

  • Zdrojová IP
  • Cílová IP
  • Zdrojový port
  • Cílový port
  • Next hop router
  • Počet paketů
  • Počet bytů
  • Příznaky u TCP
  • Protokol
  • Type of service

Protokol NetFlow verze 9

Hlavička je podobná. Data jsou však rozděleny podle šablon a jsou dynamická. Rozšířeníá o L2 informace, například VLAN, BGP, IPv6, MPLS, Multicast

Zajištění kvality služeb

Service Level Agreement

Popisuje požadavky na kvalitu připojení mezi zákazníkem a ISP. Obsahuje požadavky na dostupnost sítě, povolenou ztrátovost, zpoždění jitter apod.

Rozložení provozu, Traffic Shaping

Reguluje rychlost a objem provozu. Řeší problém shlukování a lépe využívá přenosové pásmo. Může do přenosu vložit zpoždění.

Provádí se na výstupních bodech sítě.

Ořezání provozu, Traffic Policing

Řídí maximální rychlost. Cokoliv ji překročí, je ořezáno. Nemá vliv na zpoždění provozu.

Provádí se na vstupních i výstupních bodech sítě.

Řízení toku dat pomocí front

Fronta typu FIFO

Řadí vstupní pakety v pořadí v jakém přicházejí. Neřeší priority provozu. Jedná se o implicitní způsob zpracování dat na výstupu zařízení.

Má předvídatelné zpoždění:

\begin{equation} D \leq \frac{B (velikost fronty)}{R (rychlost linky)} \end{equation}

Prioritní fronty

Více front s různou prioritou zpracování. Obsahuje klasifikátor, který řadí pakety do front. Klasifikace například podle Type of Service. Nejprve se zpracovávají data ve frontě z vyšší prioritou. Může vést k vyhladovění.

Cyklické fronty Round Robin

Každý tok paketů tvoří nezávislou frontu pro zpracování. Počet toků se dynamicky mění. Cyklická obsluha všech front vede ke stejnému objemu přenesených dat.

Váhové fronty WFQ (Weighted Fair Queues)

Pro každý tok se vytváří jedna fronta. Váha určuje počet odebraných bytů z jedné fronty.

Rychlost obsluhy fronty $i$ při rychlosti linky $R$:

\begin{equation} R_i = \frac{w_i}{w_1 + w_2 + w_3 + … + w_n} × R \end{equation}

Kde $w$ je váha fronty.

Model tekoucího vědra (Leaky Bucket)

Používá se pro zajištění rozložení i ořezání provozu. Mechanismus vnustí vstupnímu toku konstantní rychlost $r$. Vědro se implementuje jako FIFO s počitadlem bytů $X$. Počitadlo se inkrementuje každou sekundu o hodnotu $r: X’ := (X + r)$.

Pakety o délce $P$ se odešlou, pokud $P &lt; X$ a počitadlo se upravi $X’ := X - P$

Pokud dékla paketu $P &gt; X$, paket čeká, dokud se $X$ nezvětší.

Pokud se paket nevejde do fronty, je zahozen.

Po odeslání paketů se čítač $X$ resetuje.

Model zásobníku žetonů (Token Bucket)

Zásobník žetonů obsahuje paměť pro uložení nevyužitých oprávnění k odeslání dat. Vstupní rychlost se může krátkodobě zvýšit až do hodnoty $CBS$.

Jsou definovány:

  1. Průměrná rychlost CIR (Committed Information Rate)
  2. Rychlost ve špičce PIR (Peak Rate)
  3. Maximální velikost shluků (Committed Burst Size)

Implementace u integrovaných služeb

Definujeme:

  • Maximální délka trvání špičky $T$
  • Token rate $r = CIR$
  • Bucket size $b = CBS$, omezuje špičky na maximum bytů v toku za čas T

Pak:

  • Maximální počet bytů na vstupu je: \begin{equation} A(t) = b + t × r = CBS + t × CIR = CBS + t × \frac{CBS}{T} \end{equation}
  • Maximální rychlost ve špičce bude: \begin{equation} PIR = \frac{CBS}{T} + CIR \end{equation}

Integrované služby

Implementují podporu QoS v IP síti formou rezervace zdrojů. Poskytují společnou (integrovanou) službu množině provozních požadavků.

Integrované služby alokují zdroje pro jednotlivé toky. To je výpočetně náročné, ale garntuje kvalitu přenosu pro jednotlivý tok.

Jsou nevýhodné pro páteřní směrovače.

Integrované služby podporují třídy služeb:

  1. Garantované služby – Striktní omezení zpoždění ve frontách
  2. Kontrolovaná zátěž – Kvalita provozu se blíží nezatíženému prvku
  3. Best-effort – Běžná kvalita nad IP

Resource Reservation Protoco (RSVP)

Signalizační protokol pro rezervaci zdrojů na síťových prvcích. Žádost o rezervaci provádí koncová stanice.

Diferenciované služby

Implementují QoS pomocí značení paketů a prioritního přeposílání. Snadná rozšiřitelnost a flexibilita, je možné definovat nové třídy.

Označení paketů probíhá podle filtrovacích pravidel. Nastavují se hodnoty ToS nebo DS v hlavičce IP.

Základní třídy provozu:

  1. Expedity Forwarding (EF) – přednostní přeposílání
  2. Assured Forwarding (AF) – garantované přeposílání
  3. Best Effort (BE) – Největší úsilí

Zajištění kvality služeb v praxi

  1. Identifikace provozu a definice požadavků na provoz
  2. Klasifikace provozu podle požadavků do různých tříd
  3. Definice politiky na zpracování každé třídy provozu
  4. Implementace politiky na síťových prvcích

Prevence zahlcení RED a WRED

TCP se v případě zahlcení linky chová tak, že zužuje sliding window, dokud není linka volná. Dochází tak k periodickému přetížení a uvolnění linky, tento jev je globální z důvodu globální synchronizace TCP. Může kvůli tomu docházet k vyhladovění TCP.

Mechanismus prevence zahlcení Random Early Detection (RED)

Náhodně zahazuje pakety ve vstupní frontě.

Zpracování dat ve frontě může být ve třech stavech:

  1. Nezahazování
  2. Náhodné zahazování
  3. Úplné zahazování

Pravděpodobnost zahození $P_a$ závisí na aktuálním zaplnění fronty $Qavg$:

\begin{equation} P_a = Pmax × \frac{Qavg - Qmin}{Qmax - Qmin} \end{equation}

Díky mechanismu RED sice stále dochází k periodickému přetížení a uvolnění linky, průměrné využití linky se ale zvýší.

Mechanismus Weighted RED

Rozšiřuje RED o priority. Pravděpodobnost zahození závisí navíc na IP precedenci (ToS) nebo DSCP (DS).