59 - Virtuální privátní sítě (IPSec, GRE, L2TP, PPP, OpenVPN).
úterý 30. května 2017
21:55
VPN automaticky neznamená šifrování
Problematická implementace na jednodlivých klientech - různé systémy podporují různé protokoly
GRE
Jedná se o tunelovací protokol, který umí zapouzdřit jeden paket L3 vrstvy uvnitř jiného paketu L3 vrstvy. 
Na konci je paket rozbalen a cílová stanice může zpracovat zapouzdřený paket
Slouží pro přenos paketů uvnitř P2P tunelu
Mohl bych klidně dát například IP hlavičku hned za IP hlavičku, ale musel by pro to existovat standard (v RFCču) (IP za IP zrovna je standardizováno)
Když ale použiju GRE tak za GRE hlavičku můžu dát jakýkoliv svůj proprietální protokol
Neřeší bezpečnost
PPP
Prokol pro přímé spojení 2 síťových uzlů (bez meziprvků mezi nimi)
Používá se pro tunelování. Obsahuje pole pro označení zapouzdřeného protokolu
Jak je to naskládané za sebou: IP (tím to jde přes internet) | GRE (tam je řečeno že bude následovat PPP) | PPP | Zapouzdřená data
Může řešit formu autentizace (přístupů) například pomocí jména a hesla - bonus navíc oproti GRE
Provoz ale pořád nemusí být šifrovaný
Je to flexibilní a můžu za to zapouzdřit téměř cokoliv (generická hlavička, která umožňuje uvnitř nést cokoliv)
Ethernet - Ethernet over PPP
PPP over ATM - PPPOA
Problém průchodu skrz NAT
Když se NAT nedívá na ID (identifikátor tunelu) v hlavičce v protokolu, tak může veškerý provoz směrovat na jednoho uživatele
Například: Z počítače A v sítě 1 chci komunikovat s počítači B a C ze sítě 2 - provoz pro C bude chodit na B
NAT to musí podporavat, aby to fungovalo psrávně
Bezpečnost 
Heslo nemusím posílat v otevřené podobě ale můžu ho například hashovat pomocí MS-CHAP
PAP je plaintext
CHAP, MS-CHAP už jsou nějakým způsobem hashované - nicméně dnes stejně nejsou považovány za bezpečné - v dnešní době už není příliš podporovaná - poslední MAC už je nepodporuje
L2TP
Tunelovací prokol (vytvoří tunel mezi dvěma místy). Tunel obvykle umožní uživateli přístup k funkcím, které daná síť neumí poskytnou přímo. Jako například přepojení externího uživatele do lokální sítě. 
Přenášen v UDP
Často využívá PPP pro spojení v rámci tunelu
The two endpoints of an L2TP tunnel are called the LAC (L2TP Access Concentrator) and the LNS (L2TP Network Server). An L2TP session (or 'call') is established within the tunnel for each higher-level protocol such as PPP. Either the LAC or LNS may initiate sessions. The traffic for each session is isolated by L2TP, so it is possible to set up multiple virtual networks across a single tunnel
Ve verzi 2 nepodporuje šifrování a spoléhá se například na IPSec
Ve verzi 3
Podporuje šifrování
Snižuje overhead - lze bez UDP a PPP
L2TP v kombinaci s IPSec je vdnešní době asi nejrozšířenější typ klientské VPNky - podporován napříč výrobci a napříč implementacemi koncových systémů
IPSec (IP Security)
Standardy umožňující vytvoření bezpečného tunelu
Je modulární a je možné celou řadu věcí změnit
Používá dva páteřní protokoly
AH - Authentication header
ESP - Encapsulating security payload
Problémem je že možností jak poskládat jednotlivé moduly je obrovské množství
Například se mi nelíbí DES, tak tam dám něco jiného
Délka klíčů…
Je problematické všechno naimplementovat správně
Authentication header
Poskytuje autenticitu a ochranu proti znovupoužití
Neposkytuje důvěrnost - nezašifrovaná data
Jsem schopen říct, že po cestě nebyla data změněna
Obecně problém s NATem
Přepíše IP adresu a kontrolní součet potom nesedí
Encapsulation security payload
Používá se více než AH
Umí to samé jako AH + poskytuje důvěrnost (zašifruje data)
Poskytuje skoro všechno jako AH + něco navíc -> AH se skoro nepoužívá
Transportní vs tunelový provoz
AH I ESP umí oba režimy
Tunelový režim
Původní paket vezmu I s IP hlavičkou a celý ho zapouzdřím a vložím ho do nového - tím vytvořím tunel
Před samotným spojením musí proběhnout vyjednávání o způsobu spojení
Zařízení si vymění informace o tom, které protokoly podporují
Problémem je velká složitost kvůli velkému množství možností
IKEv2 
Zjednodušení
Zrychlení vyjednávání - ve vteřině jsme připojeni
Mobilita - s mobilem mohu přecházet mezi WiFi sítěmi
Rozdílná podpora na koncových klientech
Problém dostat všechny konfigurační parametry na koncové zařízení napříč operačnímy systémy
Z pohledu aplikace je to transparentní
Pokud nastavím IPSec tak se pro aplikace nic nezmění, akorát budou komunikovat šifrovaně a nikdo je nemůže odposlouchávat
OpenVPN
VPN založená na SSL přes UDP nebo TCP protokol
Nutná instalace klienta na koncové zařízení, protože to nebývá integrováno do operačního systému
Je považováno za bezpečné, protože se používá AES
Typicky se šifruje nad UDP
Je vcelku zbytečné používat jako nosný protokol TCP, protože uvnitř se přenáší také TCP, které si výpadky a sliding windows řeší samo. Pokud by se používal jako nosný TCP, řešilo by se to zbytečně dvakrát.
Z pohledu trouble shootingu my vidíme tuto VPN jako nový interface s nějakýma interníma IP adresama, které se používají v rámci tunelu. Jsme schopni nad tím spustit TCP dump a odposlouchávat provoz, který v tom teče. Vydím data dřív, než jsou zašifrována. Pokud by byl použit IPSec, tak nic neuvidím, protože je to v rámci kernelu.