Jak snadné je zjistit, že se používá VPN?
Virtuální privátní sítě (VPN) řeší spoustu problémů s ochranou soukromí. Vzhledem k tomu, že VPN obvykle šifruje váš provoz mezi vaším počítačem a poskytovatelem VPN, je pro pozorovatele velmi obtížné sledovat váš provoz a zjistit, co děláte. Existuje však mnoho lidí, kteří chtějí mít možnost skrýt skutečnost, že vůbec používají VPN; například lidé v zemích, které zakazují VPN, nebo v jiných situacích, kde používání VPN není obecně povoleno nebo blokováno technickými prostředky. V tomto článku se zaměřujeme na typ dat, která může pozorovatel shromažďovat ze zachycování síťových paketů, a na to, jak lze tato data použít k detekci použití VPN.
Obsah [ skrýt ]
- Pozadí problému
- Metodika testování
- Netechnické zdroje indikátorů VPN
- Sdělovací znaky z metadat paketů
- Nekonzistence v operačním systému a datech otisku paketů
- Nedostatečné obfuskační techniky od poskytovatelů VPN
- celkem
Pozadí problému
Palčivou otázkou je „proč“? Koho zajímá, když někdo zjistí, že provozujete VPN? Pokud je provoz přesto silně zašifrován, v čem je problém?
Je pravda, že v mnoha situacích a v mnoha zemích vůbec nezáleží na tom, zda pozorovatel zjistí použití VPN. Existuje však mnoho zemí, které zakazují používání VPN, a proto je důležité, aby uživatelé VPN v těchto zemích věděli, jak je lze objevit.
Aby mohl pozorovatel určit, zda se používá VPN, musí mít přístup ke směrovači, kterým prochází cílový provoz. V případě cílené oběti může útočník vynaložit velké prostředky na identifikaci způsobu, jak převzít směrovač, který konkrétní oběť používá. V případě dohledu národního státu by účinná detekce vyžadovala kontrolu mnoha směrovačů. Když tyto dvě věci zkombinujete – organizace, která se stará o to, zda používáte a VPNa takémá schopnost ovládat velký počet směrovačů – což obvykle označuje aktéra hrozby na národní úrovni.
Mějte na paměti, že tento článek se zabývá způsoby, jak mohou pozorovatelé objevit použití VPN. Nemusí to nutně znamenat, že data zašifrovaná v tunelu VPN lze snáze zneužít.
Metodika testování
Bez přístupu ke zdrojům na státní úrovni je moje testovací platforma a metodika o něco menší. Vytvořil jsem malou interní síť pomocí tří virtuálních strojů (VM) s VirtualBoxem. Topologie sítě je taková:
|_+_|Nainstaloval jsem software pro čichání paketů na virtuální počítač routeru OpenWRT a poté jsem otestoval různé konfigurace VPN na dalších dvou virtuálních počítačích. Software pro čichání paketů, tcpdump, mi umožnil zachytit síťový provoz virtuálních počítačů pro analýzu. V realističtějším nastavení by byl software pro zachytávání paketů pravděpodobně instalován do routerů na internetu nebo alespoň v síti poskytovatele internetových služeb. Strategické umístění analytického softwaru by vyžadovalo určité znalosti konvergenční body zájmu na internetu kde pravděpodobně bude proudit cílový provoz. V mé testovací síti vím se 100% jistotou, že veškerý provoz do az mých virtuálních strojů bude procházet tímto routerem OpenWRT. Je to pro mě proto nejlepší místo, kam umístit své sbírkové nástroje.
Netechnické zdroje indikátorů VPN
Ne všechny zdroje dat, které naznačují využití VPN, jsou technické. Zatímco některé jsou velmi technické, jako je analýza paketů, některé jsou velmi netechnické, jako je lidská chyba a každodenní rutina.
Nezamýšlený síťový provoz
Většina uživatelů VPN má klientský software, který musí být spuštěn, aby bylo možné vytvořit VPN. Je velmi obtížné zajistit, aby přes internet neprocházel žádný provoz před zřízením VPN při spuštění počítače. Dokonce ani ty VPN s přepínači kill nemusí být schopny nic udělat s provozem, který prochází během spouštění systému.
Abych to otestoval, nastavil jsem možnosti automatického připojení a vypnutí přepínače VyprVPN ve virtuálním počítači Windows. Potom jsem vypnul počítač s Windows, spustil zachytávání paketů na routeru OpenWRT a spustil počítač s Windows. To vygenerovalo spoustu paketů a zajímavé jsou tyto dvě sekvence.
Za prvé, můžeme vidět spoustu pingů na podobný rozsah IP adres. Tyto pakety jsem záměrně neseskupoval – takto byly odeslány organicky:
To naznačuje, že se něco pokouší vytvořit výčet serverů. Velmi častou příčinou tohoto typu provozu ve scénáři VPN je klient VPN, který se pokouší určit nejrychlejší server. Jedním ze způsobů, jak toho dosáhnout, je poslat ICMP paket (známý jako ping) na sadu serverů, abyste viděli, který z nich se vrací nejrychleji.
Z prvního snímku obrazovky můžeme vidět, že 209.99.63.34 se vrátil nejrychleji za 99 milisekund. Dále v zachycování paketů najednou vidíme, že většina provozu od tohoto bodu je šifrována a je určena pro 209.99.63.34
Dalším kouskem skládačky je zjistit, co je na těch IP. Pomocí IP WHOIS, která uvádí registrovaného vlastníka IP adresy, můžeme vidět, že všechny tyto IP adresy kromě jedné patří společnosti YHC Corporation a přenášejí se na servery v datovém centru Data Foundry:
|_+_|Logickým dalším krokem by bylo prohledat tyto IP adresy a zjistit, jaké služby běží. Neposkytnu podrobnosti o tom, jak to udělat, ale mé testování ukazuje, že výchozí bannery připojení, které zobrazuje většina serverů, byly ze serverů VyprVPN odstraněny, takže není zřejmé, že tyto IP adresy provozují server VPN.
S tím, jak se váš počítač chová před spuštěním, nemůžete mnoho udělat. Pokud tedy chcete zatemnit tento typ sekvence nastavení, budete muset spustit VPN „před“ počítačem. Jedním ze způsobů, jak toho dosáhnout, je spuštění klienta VPN na směrovači namísto spuštění klienta na počítači. Při restartování routeru budete stále narážet na stejné spouštěcí sekvence, ale to je obvykle méně často než váš počítač.
Žádné nešifrované pakety
Jak jsem zmínil výše, jakmile byly pingy dokončeny, zachycení paketů ukazuje šifrovaný provoz na nejrychlejší IP. Pokud pozorovatel vidí pouze šifrované pakety a ne jediný nezašifrovaný paket, může to být známkou toho, že se používá VPN. Zatímco se svět rychle posouvá k šifrování co největšího množství dat na webu, stále existují některé požadavky, které obvykle šifrovány nejsou. Mezi ně patří vyhledávací dotazy DNS, dotazy NNTP (časový server) a řada dalších protokolových požadavků, jako je FTP a Telnet, které se někdy používají v některých našich aplikacích, ale vůbec nepodporují šifrování.
Úniky z nedbalého lidského provozního zabezpečení (OpSec)
Pomocí zdánlivě triviálních informací lze od cíle získat velké množství smysluplných dat. Mnoho lidí tráví spoustu času a úsilí zmírňováním toho, co vnímají jako „důležité“, aby byli identifikováni podle triviálních informací, na které nepomysleli. Některé příklady zahrnují dlouhou paměť internetu, která odhalila, že správcem e-mailu Hillary Clintonové byl s největší pravděpodobností muž jménem Paul Combetta ; Dread Pirate Roberts, známý také jako Ross Ulbricht, údajný strůjce nelegálního internetového tržiště Hedvábná stezka, byl stíhán z velké části kvůli údajům o jeho laptop, který mu byl fyzicky odebrán, když byl rozptýlen ve veřejné knihovně .
Méně dramaticky mohou pozorovatelé často používat věci, jako jsou cykly aktivit k určení časového pásma cíle nebo přítomnost speciálních znaků ve zprávě k identifikaci jazykového rozvržení odpovídající zemi cíle. Neexistuje úplný seznam věcí, které je třeba vzít v úvahu při zvažování provozní bezpečnosti, protože vymýšlení nových způsobů křížových odkazů na data je většinou cvičením představivosti a zdrojů.
Existují však některé specifické věci, které se týkají zachycování paketů, které mohou identifikovat použití VPN.
Sdělovací znaky z metadat paketů
Opětovné klíče PFS jsou předvídatelné
Vzhledem k tomu, že provoz VPN je obvykle šifrován, je obecně skrytý před zvědavýma očima. Šifrování funguje, protože je velmi těžké „hrubou silou“ zašifrovaná data odhalit jejich čistý textový obsah. Ve skutečnosti je prolomení šifrování tak těžké, že rozsáhlé sledovací projekty někdy jen shromáždí všechna data, která mohou, v naději, že budou moci šifrování prolomit někdy v budoucnu, až se výkon počítače zvýší, nebo budou schopni získat klíče. které byly použity k šifrování dat. Perfect Forward Secrecy (PFS) je metoda, kterou lze použít k zabránění druhému scénáři.
Perfect Forward Secrecy pravidelně znovu generuje šifrovací klíče používané k šifrování provozu VPN. Když je vygenerován nový pár klíčů, předchozí pár je zničen. To znamená, že jakékoli shromážděné šifrované pakety nelze později dešifrovat, protože klíč použitý k jejich šifrování již neexistuje.
OpenVPN podporuje PFS. Při zachycování dat pro tento článek jsem snížil klíčovou rychlost cyklování na 10 sekund, abych zachytil probíhající proces. Zjistil jsem, že když došlo k regeneraci klíče, vygenerovala se následující sekvence paketů:
|_+_|Pozoruhodná věc na této sekvenci je, že velikosti paketů jsou identické pokaždé, když došlo k regeneraci klíče. Proto kdykoli jsem v zachycení paketů viděl sekvenci paketů s těmito velikostmi, věděl jsem, že dochází k cyklování klíčů:
|_+_|Pravděpodobně jakýkoli opakující se proces by teoreticky generoval opakovanou sekvenci paketů, jako je tento, ale stále může být použit jako indikátor, že PFS může být ve hře. Ve spojení s dalšími údaji by tyto informace mohly stačit k potvrzení připojení VPN.
Všechny pakety směřují na stejnou IP
Při běžném používání internetu lidé a počítače požadují data z mnoha různých stránek. Každá z těchto stránek má jinou IP adresu. Při použití VPN je každý jednotlivý paket určen na server VPN. Server VPN odloupne šifrovací vrstvu VPN z každého paketu, aby odhalil skutečný paket, a poté jej odešle na cestu k jeho skutečnému cíli. Server VPN dělá totéž s odpověďmi. Přijímá pakety s odpovědí, zabalí je do šifrovací vrstvy a paket odešle do počítače uživatele.
Zachycení paketů, které ukazuje, že počítač posílá 100 % svého provozu na jednu IP, je dobrým indikátorem toho, že se používá VPN nebo proxy.
Psiphon je nástroj pro obcházení internetové cenzury . Má zajímavou funkci, která s tím do určité míry dokáže bojovat. Má todělený tunelrežim, který v podstatě používá pouze tunel Psiphon pro provoz, který opouští vaši zemi.
Abych viděl, jak to vypadá na úrovni paketů, spustil jsem Psiphon a otestoval dva weby. Jsem v Kanadě a zde je ukázka provozu, který směřuje k našemu vlastnímu registrátorovi domény .CA. V tomto případě je můj cíl jasně viditelný v zachycení paketů.
|_+_|Poté jsem navštívil web Comparitech, který je hostován ve Spojených státech:
|_+_|Všimněte si, jak je provoz určený pro USA odesílán na server Linode místo na comparitech.com . Linode je velmi velká serverová společnost a není vůbec neobvyklé vidět provoz určený pro server Linode. Psiphon dále zatemňuje tento provoz pomocí tunelu SSH ke skrytí jakékoli stopy VPN. Stejně tak reverzní DNS (rDNS) pro server Psiphon na Linode nezradí jeho spojení s Psiphon; rDNS jen ukazuje, že Linode vlastní IP, což se očekává. Více o rDNS je v části zamlžení dále v tomto článku.
Nekonzistence v operačním systému a datech otisku paketů
Ačkoli TCP networking je operační systém agnostický, různé operační systémy vytvářejí pakety s různými hodnotami. Například výchozí hodnota paketu Time-To-Live (TTL) se liší v paketech vytvořených na různých systémech. Většina systémů Windows nastaví TTL paketu ve výchozím nastavení na 128, zatímco většina systémů Linux jej nastaví na 64. Vzhledem k tomu, že TTL je viditelná část zachyceného paketu, je možné určit, který OS tento paket s největší pravděpodobností vytvořil. V konstrukci paketů existují také další sdělovací znaky, jako je délka a maximální velikost segmentu (MSS), které se také liší operační systém od operačního systému.
Níže uvedený úryvek je součástí paketu generovaného ze systému Windows. Všimněte sittl 127hodnota na posledním řádku je nastavena na 127. Je to proto, že TTL je vyjádřen v počtu „skoků“. Pokaždé, když paket prochází zařízením, jako je router, jeho TTL se sníží o jednu. V tomto případě TTL začínalo na 128, ale protože jsem ho zachytil na routeru – po jednom skoku – je nyní 127. Stále však mohu říci, že to nikdy nebylo 64, takže se pravděpodobně jedná o paket vytvořený v systému Windows.
|_+_|Paket zachycený z linuxového stroje má po prvním přeskoku TTL 63. Je to proto, že většina počítačů se systémem Linux nastavuje počáteční hodnotu TTL paketu na 64.
|_+_|Ale, tak co? Proč může být důležité vědět, jaký operační systém vytvořil paket?
Pokud má pozorovatel specializované znalosti o cíli, může na tom hodně záležet. Pokud je známo, že cíl používá Windows – možná jako člen velké organizace, která používá Windows napříč – ale pakety zachycené z tohoto cíle ukazují, že byly pravděpodobně vytvořeny na počítači se systémem Linux, je to dobrý indikátor toho, že VPN nebo proxy druh se používá. Stojí za zmínku, že prakticky všechny servery VPN běží na serverech typu Linux nebo Unix.
Na většině systémů je možné upravit parametry paketů, ale jen velmi málo lidí jde do této délky.
Nedostatečné obfuskační techniky od poskytovatelů VPN
Analýza sítě zahrnuje více než jen shromažďování paketů. Svou roli mohou hrát pomocné procesy, jako je DNS. Mnoho uživatelů VPN si je vědomo DNS, protože jasné odesílání dotazů DNS je pro pozorovatele jedním ze způsobů, jak určit, kde jste na návštěvě nebo se chystáte navštívit. Méně uživatelů však zná reverzní DNS (rDNS). Podobně jako DNS přiřazuje název domény k IP adrese, rDNS přidružuje IP adresu k názvu hostitele a název hostitelského názvu obvykle identifikuje vlastníka IP adresy. Většina programovacích knihoven a operačních systémů navíc přichází s nějakou verzí standardních funkcí gethostnameby*(), které rozšiřují schopnost systému přiřazovat IP adresy a názvy hostitelů.
Reverzní DNS není tak zásadní jako „normální“ DNS, protože rDNS nehraje žádnou roli ve směrování provozu. Spíše se používá především jako prostředek k identifikaci vlastnictví IP. Záznam rDNS k ní může přiřadit pouze vlastník IP adresy. Kontrola záznamu rDNS IP adresy proto poskytuje přiměřenou jistotu, kdo ji vlastní, nebo alespoň o kom vlastník chce, abyste si mysleli, že ji vlastní. Všimněte si, že rDNS není vyžadováno a mnoho IP adres nemá položky rDNS vůbec.
Podívejme se na příklad domény facebook.com . DNS A záznam poskytnutý standardním DNS dotazem ukazuje tuto IP adresu:
|_+_|Nyní pomocí reverzního dotazu DNS nebo funkce gethostnamebyaddr() zjistíme, kdo tuto IP adresu vlastní:
|_+_|Z toho můžeme vidět, že Facebook skutečně vlastní tuto IP adresu. Většina webů však nevlastní své vlastní IP adresy; jsou pronajaté a patří libovolným organizacím nebo možná vlastněné méně zřejmými subjekty. Amazon je příkladem velkého poskytovatele výpočetní techniky, který využívá mnoho společností. Dotaz rDNS na IP adresu mnoha internetových služeb jednoduše ukazuje, že Amazon vlastní IP, a proto jsou tyto informace málo užitečné při určování toho, kdo IP provozuje. Dalším příkladem je Google. Google je ve svých záznamech rDNS trochu jemnější, ale stále uchovává informace o vlastnictví. Zde je návod, jak reverzní DNS hledá Google IP:
|_+_|Google vlastní doménu 1e100.net , takže můžeme vidět, že tato IP ve skutečnosti patří společnosti Google.
Ve světě VPN mohou být nástroje pro rozlišení adres potenciálně použity ke zjištění, zda IP adresa, pro kterou je váš provoz určen, patří do VPN. Například výchozí příkaz tcpdump na routeru OpenWRT se pokusí vyřešit adresy IP, které vidí v paketech TCP. Zdá se, že k tomu primárně používá gethostbyaddress(), a proto je někdy možné vidět, kam jsou pakety určeny. Výchozí zachycení tcpdump relace IPVanish to ilustruje:
|_+_|Klient IPVanish pro Windows poskytuje tři konfigurace: standardní připojení OpenVPN, připojení OpenVPN pomocí HTTPS a zatemněné připojení.
Výše uvedené pakety byly zachyceny během relace pomocí zatemněného nastavení připojení OpenVPN, ale WireShark je stále schopen poskytnout informace o cíli.
celkem
Při určování využití VPN existuje jen velmi málo „stříbrných odrážek“. Sestavení dostatečného množství indikátorů, které naznačují, že se VPN používá, obvykle vyžaduje řadu technik nebo pozorování, a i tak může být těžké si být 100% jistý. Společnosti, které mají zájem zakázat používání VPN, jako je Netflix a další streamovací služby mají týmy na plný úvazek věnované právě tomuto problému. V jiných případech mnoho východoevropských a středovýchodních zemí zakazuje používání VPN a má podobné týmy, které odhalují uživatele VPN.
