Колко лесно е да откриете, че се използва VPN?

Виртуалните частни мрежи (VPN) решават много проблеми с поверителността. Тъй като VPN обикновено криптира вашия трафик между вашия компютър и доставчика на VPN, това прави много трудно за наблюдателя да види вашия трафик, за да види какво правите. Въпреки това има много хора, които искат да могат да скрият факта, че изобщо използват VPN; като хора в държави, които забраняват VPN, или други ситуации, при които използването на VPN обикновено не е разрешено или блокирано чрез технически средства. В тази статия се фокусираме върху типа данни, които наблюдателят може да събере от улавяне на мрежови пакети и как тези данни могат да се използват за откриване на използване на VPN.

Съдържание [ Крия ]

• Предистория на проблема
• Методика на тестване
• Нетехнически източници на VPN индикатори
• Сигнални знаци от пакетни метаданни
• Несъответствия в операционната система и пакетните данни за пръстови отпечатъци
• Недостатъчни техники за обфускация от доставчиците на VPN
• в обобщение

Предистория на проблема

Горещият въпрос е „защо“? На кого му пука, ако някой открие, че използвате VPN? Ако трафикът така или иначе е силно криптиран, какъв е проблемът?

Вярно е, че в много ситуации и в много държави няма никакво значение дали наблюдателят открие използването на VPN. Има обаче много държави, които забраняват използването на VPN и затова е важно потребителите на VPN в тези страни да знаят как могат да бъдат открити.

За да определи дали се използва VPN, наблюдателят трябва да има достъп до рутер, през който преминава целевият трафик. В случай на целева жертва, нападателят може да изразходва големи ресурси, за да идентифицира начин, по който да превземе рутер, който конкретната жертва използва. В случай на наблюдение на национална държава, ефективното откриване би изисквало контрола на много рутери. Когато комбинирате тези две неща - организация, която се интересува дали използвате и VPNи същоима способността да контролира голям брой рутери - това обикновено показва заплаха на национално ниво.

Имайте предвид, че тази статия се занимава с начини, по които използването на VPN може да бъде открито от наблюдатели. Това не означава непременно, че данните, криптирани в рамките на VPN тунела, са по-лесни за използване.

Методика на тестване

Без достъп до ресурси на държавно ниво моята тестова платформа и методология са малко по-малки по мащаб. Създадох малка вътрешна мрежа, използвайки три виртуални машини (VM) с VirtualBox. Топологията на мрежата е следната:

|_+_|Инсталирах софтуер за подслушване на пакети на OpenWRT рутер VM и след това тествах различни VPN конфигурации на другите две виртуални машини. Софтуерът за подслушване на пакети, tcpdump, ми позволи да уловя мрежовия трафик на VM за анализ. При по-реалистична настройка софтуерът за улавяне на пакети вероятно ще бъде инсталиран в рутери в Интернет или поне в мрежата на доставчика на интернет услуги. Стратегическото разположение на софтуера за анализ би изисквало известни познания интересните точки на сближаване в интернет където е вероятно да тече целевият трафик. В моята тестова мрежа знам със 100% сигурност, че целият трафик към и от моите виртуални машини ще премине през този OpenWRT рутер. Следователно това е най-доброто място за мен да поставя инструментите си за събиране.

Нетехнически източници на VPN индикатори

Не всички източници на данни, които показват използването на VPN, са технически. Докато някои са много технически, като анализ на пакети, други са много нетехнически, като човешка грешка и ежедневна рутина.

Нежелан мрежов трафик

Повечето потребители на VPN имат клиентски софтуер, който трябва да бъде стартиран, за да се установи VPN. Много е трудно да се гарантира, че трафикът не преминава през интернет, преди VPN да бъде установен, когато компютърът се стартира. Дори онези VPN мрежи с превключватели за изключване може да не са в състояние да направят нищо относно трафика, който преминава по време на зареждане на системата.

За да тествам това, зададох опциите за автоматично свързване и прекъсване на VyprVPN във виртуалната машина на Windows. След това изключих машината с Windows, стартирах улавяне на пакети на рутера OpenWRT и стартирах машината с Windows. Това генерира много пакети и представляват интерес тези две последователности.

Първо, можем да видим много пингове към подобен диапазон от IP адреси. Не съм групирал нарочно тези пакети – ето как са изпратени органично:

Това предполага, че нещо се опитва да изброи сървъри. Много честа причина за този тип трафик в VPN сценарий е VPN клиент, който се опитва да определи най-бързия сървър. Един от начините да направите това е да изпратите ICMP пакет (известен като ping) към набор от сървъри, за да видите кой се връща най-бързо.

Можем да видим от първата екранна снимка, че 209.99.63.34 се върна най-бързо за 99 милисекунди. По-надолу в улавянето на пакети изведнъж виждаме, че по-голямата част от трафика от този момент нататък е криптиран и е предназначен за 209.99.63.34

Следващото парче от пъзела е да разберете какво има на тези IP адреси. Използвайки IP WHOIS, който посочва регистрирания собственик на IP, можем да видим, че всички с изключение на един от тези IP адреси принадлежат на YHC Corporation и се разрешават на сървъри в центъра за данни Data Foundry:

|_+_|

Логична следваща стъпка би била да сканирате тези IP адреси, за да видите какви услуги изпълняват. Няма да давам подробности как да направя това, но тестовете ми показват, че банерите за връзка по подразбиране, които повечето сървъри показват, са премахнати от сървърите на VyprVPN, така че няма очевиден сигнал, че тези IP адреси работят с VPN сървър.

Не можете да направите много за това как компютърът ви действа, преди да бъде стартиран. Следователно, ако искате да скриете този тип последователност за настройка, ще трябва да стартирате VPN „пред“ компютъра си. Пускането на VPN клиент на вашия рутер вместо стартиране на клиент на вашия компютър е един от начините да направите това. Все още ще се натъквате на същите стартови последователности, когато рутерът се рестартира, но това обикновено е по-рядко от вашия компютър.

Няма некриптирани пакети

Както споменах по-горе, след като ping-овете са завършени, улавянето на пакети показва криптиран трафик към най-бързия IP. Ако наблюдател вижда само криптирани пакети и нито един некриптиран пакет, това може да е знак, че се използва VPN. Въпреки че светът се движи бързо към криптиране на възможно най-много данни в мрежата, все още има някои заявки, които обикновено не са криптирани. Сред тях са заявки за търсене в DNS, заявки за NNTP (сървър за време) и някои други заявки за протоколи, като FTP и Telnet, които понякога се използват в някои от нашите приложения, но изобщо не поддържат криптиране.

Течове от небрежна човешка оперативна сигурност (OpSec)

Голямо количество смислени данни могат да бъдат получени от дадена цел чрез използване на привидно тривиална информация. Много хора прекарват много време и усилия в смекчаване на това, което възприемат като „важни“ неща, само за да бъдат идентифицирани от тривиална информация, за която не са се сетили. Някои примери включват дългата памет на интернет, която разкри, че имейл администраторът на Хилъри Клинтън най-вероятно е човек на име Пол Комбета ; Страховитият пират Робъртс, известен още като Рос Улбрихт, предполагаемият мозък на незаконния интернет пазар на Silk Road, беше преследван до голяма степен поради данни за лаптопа му, който му беше отнет физически, докато се разсейваше в обществена библиотека .

По-малко драматично, наблюдателите могат често да използват неща като цикли на активност, за да определят часовата зона на целта или наличието на специални знаци в съобщение, за да идентифицират езиково оформление, съответстващо на страната на целта. Няма пълен списък с неща, които да вземете предвид, когато обмисляте оперативна сигурност, тъй като измислянето на нови начини за кръстосано препращане на данни е най-вече упражнение за въображение и ресурси.

Има обаче някои специфични неща, които се отнасят до улавянето на пакети, които могат да идентифицират използването на VPN.

Сигнални знаци от пакетни метаданни

Повторните ключове на PFS са предвидими

Тъй като VPN трафикът обикновено е криптиран, той обикновено е скрит от любопитни очи. Шифроването работи, защото е много трудно да се „брутално принудят“ криптираните данни, за да се разкрие ясното текстово съдържание. Всъщност разбиването на криптирането е толкова трудно, че широкомащабните проекти за наблюдение понякога просто събират всички данни, които могат, с надеждата, че ще могат да разбият криптирането на някоя бъдеща дата, когато мощността на компютъра се увеличи или успеят да получат ключовете които са използвани за криптиране на данните. Perfect Forward Secrecy (PFS) е метод, който може да се използва за предотвратяване на последния сценарий.

Perfect Forward Secrecy повторно генерира ключовете за криптиране, използвани за периодично криптиране на VPN трафика. Когато се генерира нова двойка ключове, предишната двойка се унищожава. Това означава, че всички събрани криптирани пакети не могат да бъдат декриптирани на по-късна дата, тъй като ключът, използван за криптирането им, вече не съществува.

OpenVPN поддържа PFS. Докато записвах данни за тази статия, намалих скоростта на ключов цикъл до 10 секунди, за да заснема този процес, който се случва. Открих, че когато се извърши повторно генериране на ключ, се генерира следната последователност от пакети:

|_+_|

Забележителното в тази последователност е, че размерите на пакетите са идентични при всяко повторно генериране на ключ. Ето защо, всеки път, когато видях последователност от пакети с тези размери в моето улавяне на пакети, знаех, че се извършва цикъл на ключове:

|_+_|

Вероятно всеки повтарящ се процес теоретично би генерирал повтаряща се последователност от пакети като този, но все пак може да се използва като индикатор, че PFS може да е в действие. Съчетана с други данни, тази информация може да е достатъчна за потвърждаване на VPN връзка.

Всички пакети, предназначени за един и същ IP

По време на нормалното използване на интернет хората и компютрите изискват данни от много различни сайтове. Всеки от тези сайтове има различен IP адрес. Когато използвате VPN, всеки отделен пакет е предназначен за VPN сървъра. VPN сървърът премахва VPN криптиращия слой от всеки пакет, за да разкрие истинския пакет и след това го изпраща по пътя към действителната му дестинация. VPN сървърът прави същото с отговорите. Той получава пакети с отговори, обвива ги в слой за криптиране и след това изпраща пакета до компютъра на потребителя.

Улавяне на пакет, което показва, че компютър изпраща 100% от своя трафик към единичен IP, е добър индикатор, че се използва VPN или прокси.

Psiphon е инструмент за заобикаляне на интернет цензурата . Той има интересна функция, която може да се бори с това до известна степен. То имаразделен тунелрежим, който по същество използва само тунела на Psiphon за трафик, който напуска вашата собствена страна.

За да видя как изглежда това на ниво пакет, стартирах Psiphon и тествах два сайта. Аз съм в Канада и ето извадка от трафик, който е предназначен за нашия собствен регистратор на домейни .CA. В този случай моята дестинация е ясно видима в улавянето на пакета.

|_+_|

След това посетих уебсайта Comparitech, който се хоства в Съединените щати:

|_+_|

Обърнете внимание как трафикът, предназначен за САЩ, се изпраща към сървър на Linode вместо към comparitech.com . Linode е много голяма компания за сървъри и изобщо не е необичайно да видите трафик, предназначен за сървър на Linode. Psiphon допълнително замъглява този трафик, като използва SSH тунел, за да скрие всяка следа от VPN. Освен това обратният DNS (rDNS) за Psiphon сървъра в Linode не издава връзката си с Psiphon; rDNS просто показва, че Linode притежава IP, което се очаква. Има повече за rDNS в раздела за обфускация по-късно в тази статия.

Несъответствия в операционната система и пакетните данни за пръстови отпечатъци

Въпреки че TCP мрежата е агностик на операционната система, различните операционни системи създават пакети с някои различни стойности. Например, стойността на времето за живот на пакета по подразбиране (TTL) варира в пакетите, създадени на различни системи. Повечето Windows системи ще настроят TTL на пакета на 128 по подразбиране, докато повечето Linux системи ще го настроят на 64. Тъй като TTL е видима част от заснетия пакет, е възможно да се определи коя операционна система най-вероятно е създала този пакет. Има и други сигнални знаци в конструкцията на пакета, като дължина и максимален размер на сегмента (MSS), които също варират от операционна система до операционна система.

Фрагментът по-долу е част от пакет, генериран от Windows система. Обърнете внимание наttl 127стойността на последния ред е зададена на 127. Това е така, защото TTL се изразява в брой „хопове“. Всеки път, когато пакет преминава през устройство като рутер, неговият TTL се намалява с единица. В този случай TTL започна от 128, но тъй като го заснех на рутера - след едно скачане - сега е 127. Въпреки това мога да кажа, че никога не е бил 64, така че това вероятно е пакет, създаден на система Windows.

|_+_|

Пакет, уловен от Linux машина, има TTL от 63 след първия си скок. Това е така, защото повечето Linux машини задават първоначалната стойност на TTL на пакета на 64.

|_+_|

Но какво от това? Защо може да е важно да знаете коя операционна система е създала пакет?

Ако наблюдателят има специализирани познания за целта, това може да има голямо значение. Ако е известно, че целта използва Windows — може би като член на голяма организация, която използва Windows навсякъде — но пакетите, заснети от тази цел, показват, че вероятно са създадени на Linux машина, това е добър индикатор, че VPN или прокси на някои вид се използва. Струва си да се отбележи, че почти всички VPN сървъри работят на Linux или Unix-подобни сървъри.

Възможно е да се коригират параметрите на пакета на повечето системи, но много малко хора стигат до тази дължина.

Недостатъчни техники за обфускация от доставчиците на VPN

Мрежовият анализ включва повече от просто събиране на пакети. Спомагателни процеси като DNS могат да играят роля. Много потребители на VPN знаят за DNS, тъй като изпращането на DNS заявки в чист вид е един от начините наблюдателят да определи къде посещавате или се каните да посетите. Въпреки това, по-малко потребители знаят за обратния DNS (rDNS). Подобно на DNS свързва име на домейн с IP адрес, rDNS свързва IP адрес с име на хост и името на името на хост обикновено идентифицира собственика на IP. В допълнение, повечето програмни библиотеки и операционни системи идват с някои версии на стандартните функции gethostnameby*(), които разширяват способността на системата да свързва IP адреси и имена на хостове.

Обратният DNS не е толкова критичен, колкото „нормалният“ DNS, тъй като rDNS не играе роля в маршрутизирането на трафика. По-скоро се използва предимно като средство за идентифициране на собственост върху IP. Само собственикът на IP адрес може да асоциира rDNS запис към него. Следователно проверката на rDNS записа на IP адрес осигурява разумна увереност кой го притежава или поне кого собственикът иска да мислите, че го притежава. Имайте предвид, че rDNS не се изисква и много IP адреси изобщо нямат rDNS записи.

Нека да разгледаме примера на домейна facebook.com . DNS A записът, предоставен от стандартна DNS заявка, показва този IP адрес:

|_+_|

Сега нека използваме обратна DNS заявка или функцията gethostnamebyaddr(), за да видим кой притежава този IP:

|_+_|

Можем да видим от това, че Facebook всъщност притежава този IP адрес. Повечето сайтове обаче не притежават собствени IP адреси; те са наети и принадлежат на произволни организации или може би са собственост на по-малко очевидни субекти. Amazon е пример за голям компютърен доставчик, който се използва от много компании. Заявка за rDNS за IP адреса на много интернет услуги просто показва, че Amazon притежава IP и следователно информацията е от малка полза при определяне кой управлява IP. Друг пример е Google. Google е малко по-фин в своите rDNS записи, но все още поддържа информация за собствеността. Ето как изглежда обратният DNS за IP на Google:

|_+_|

Google притежава домейна 1e100.net , така че можем да видим, че този IP адрес всъщност принадлежи на Google.

В света на VPN, инструментите за разрешаване на адреси потенциално могат да се използват, за да видите дали IP адресът, към който е предназначен вашият трафик, принадлежи на VPN. Например, команда tcpdump по подразбиране на маршрутизатора OpenWRT ще се опита да разреши IP адресите, които вижда в TCP пакетите. Изглежда, че използва основно gethostbyaddress(), за да направи това и затова понякога е възможно да се види къде са предназначени пакетите. Улавянето на tcpdump по подразбиране на IPVanish сесия илюстрира това:

|_+_|

Клиентът IPVanish за Windows предоставя три конфигурации: стандартна OpenVPN връзка, OpenVPN връзка, използваща HTTPS, и обфусцирана връзка.

Пакетите по-горе бяха уловени по време на сесия с помощта на обфусцирана настройка за връзка OpenVPN, но WireShark все още може да предостави информация за дестинацията.

в обобщение

Когато определяте използването на VPN, има много малко „сребърни куршуми“. Обикновено са необходими редица техники или наблюдения, за да се съставят достатъчно индикатори, които показват, че VPN се използва, и дори тогава може да е трудно да бъдете 100% сигурни. Компании, които имат пряк интерес към забрана на използване на VPN като Netflix и други стрийминг услуги имат екипи на пълен работен ден, посветени точно на този проблем. В други случаи много източноевропейски и близкоизточни страни забраняват използването на VPN и имат подобни екипи за откриване на VPN потребители.