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

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


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

Горещият въпрос е "защо"? Кой се интересува, ако някой открие, че имате VPN? Ако трафикът е силно кодиран така или иначе, какъв е проблемът?

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

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

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

Методология на изпитване

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

Настройка на VPN тестовата мрежа

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

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

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

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

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

vypr-VPN-AutoConnect режим

vypr-VPN-Killswitch режим

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

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

vypr-VPN витрини-ботуши ICMP-пакети

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

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

vypr-VPN витрини-ботуши QUIC-пакети

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

209.99.108.46
OrgName: YHC Corporation
OrgTechEmail: [email protected]
209.99.109.167
OrgName: YHC Corporation
OrgTechEmail: [email protected]
209.99.113.70
OrgName: YHC Corporation
OrgTechEmail: [email protected]
209-99-115-97
209.99.117.82
OrgName: YHC Corporation
OrgTechEmail: [email protected]
209.99.21.36
OrgName: YHC Corporation
OrgTechEmail: [email protected]
OrgTechEmail: [email protected]
209.99.22.46
OrgName: YHC Corporation
OrgTechEmail: [email protected]
209.99.60.34
OrgName: YHC Corporation
OrgTechEmail: [email protected]
209.99.61.42
OrgName: YHC Corporation
OrgTechEmail: [email protected]
209.99.62.34
OrgName: YHC Corporation
OrgTechEmail: [email protected]
OrgName: Powerhouse Management, Inc.
OrgTechEmail: [email protected]
209.99.63.34
OrgName: YHC Corporation
OrgTechEmail: [email protected]
209.99.63.34
OrgName: YHC Corporation
OrgTechEmail: [email protected]
209.99.67.41
OrgName: YHC Corporation
OrgTechEmail: [email protected]
209.99.72.70
OrgName: YHC Corporation
OrgTechEmail: [email protected]
209.99.75.70
OrgName: YHC Corporation
OrgTechEmail: [email protected]
209.99.93.34
OrgName: YHC Corporation
OrgTechEmail: [email protected]
209.99.94.37
OrgName: YHC Corporation
OrgTechEmail: [email protected]
209.99.95.40
OrgName: YHC Corporation
OrgTechEmail: [email protected]

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

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

Без некодирани пакети

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

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

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

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

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

Знаци за разказване от метаданни на пакети

PFS повторните клавиши са предвидими

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

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

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

09: 01: 48.461276 IP 192.168.1.204.openvpn > 104.254.92.61.openvpn: UDP, дължина 94
09: 01: 54.749114 IP 192.168.1.204.openvpn > 104.254.92.61.openvpn: UDP, дължина 65
09: 01: 58.895381 IP 192.168.1.204.openvpn > 104.254.92.61.openvpn: UDP, дължина 86
09: 01: 58.951091 IP 192.168.1.204.openvpn > 104.254.92.61.openvpn: UDP, дължина 94
09: 01: 58.951614 IP 192.168.1.204.openvpn > 104.254.92.61.openvpn: UDP, дължина 259
09: 01: 59.007916 IP 192.168.1.204.openvpn > 104.254.92.61.openvpn: UDP, дължина 94
09: 01: 59.008027 IP 192.168.1.204.openvpn > 104.254.92.61.openvpn: UDP, дължина 94
09: 01: 59.008265 IP 192.168.1.204.openvpn > 104.254.92.61.openvpn: UDP, дължина 94
09: 01: 59.008300 IP 192.168.1.204.openvpn > 104.254.92.61.openvpn: UDP, дължина 94
09: 01: 59.062927 IP 192.168.1.204.openvpn > 104.254.92.61.openvpn: UDP, дължина 256
09: 01: 59.106521 IP 192.168.1.204.openvpn > 104.254.92.61.openvpn: UDP, дължина 575

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

94
65
86
94
259
94
94
94
94
256
575

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

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

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

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

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

comparitech-psiphon-splittunnel режим

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

8: 30: 14.213668 IP 192.168.1.210.58787 > www.cira.ca.https: Флагове [.], ack 1026833, win 64240, дължина 0
08: 30: 14.229178 IP www.cira.ca.https > 192.168.1.210.58787: Флагове [.], Сл. 1026833: 1028293, ack 715, win 5094, дължина 1460
08: 30: 14.229427 IP www.cira.ca.https > 192.168.1.210.58787: Флагове [.], Сл. 1028293: 1031213, ack 715, win 5094, дължина 2920
08: 30: 14.229781 IP 192.168.1.210.58787 > www.cira.ca.https: Флагове [.], ack 1031213, win 64240, дължина 0

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

8: 29: 48.028789 IP li832-56.members.linode.com.ssh > 192.168.1.210.58659: Флагове [P.], сл. 107809: 108277, ack 19080, win 1392, дължина 468
08: 29: 48.029101 IP 192.168.1.210.58659 > li832-56.members.linode.com.ssh: Флагове [.], ack 108277, win 856, дължина 0
08: 29: 48.029306 IP 192.168.1.210.58659 > li832-56.members.linode.com.ssh: Флагове [P.], последователност 19080: 19132, ack 108277, win 856, дължина 52
08: 29: 48.108658 IP li832-56.members.linode.com.ssh > 192.168.1.210.58659: Флагове [.], Ack 19132, win 1392, дължина 0

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

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

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

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

08: 08: 51.657495 IP (tos 0x0, ttl 64, id 32150, offset 0, flags [DF], proto UDP (17), дължина 177)
Google-публични-DNS-a.google.com.domain > 192.168.2.139.59414: 40501 3/0/0 cdn-3.convertexperiment.com. CNAME cdn-3.convertexperiment.com.edgekey.net., Cdn-3.convertexperiment.com.edgekey.net. CNAME e5289.g.akamaiedge.net., E5289.g.akamaiedge.net. A 104.94.35.212 (149)
08: 08: 51.659278 IP (tos 0x0, ttl 127, id 3890, offset 0, flags [DF], proto TCP (6), дължина 52)

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

08: 15: 55.913493 IP (tos 0x0, ttl 63, id 41443, офсет 0, флагове [DF], прото UDP (17), дължина 56)
192.168.2.139.48635 > resolutionver1.ihgip.net.domain: 47200+ A? google.com. (28)

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

Ако наблюдател има специализирани познания за дадена цел, това може да има голямо значение. Ако се знае, че целта използва 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 Записът, предоставен от стандартна DNS заявка, показва този IP адрес:

$ dig + кратък facebook.com
31.13.67.35

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

$ домакин -n 31.13.67.35
35.67.13.31.in-addr.arpa указател за име на домен ръб-star-mini-shv-01-mia3.facebook.com

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

$ dig + кратка google.com
216.58.207.46

$ хост -n 216.58.207.46
46.207.58.216.in-addr.arpa указател на име на домейн fra16s24-in-f14.1e100.net.

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

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

08: 23: 14.485768 IP 216-151-184-30.ipvanish.com.3074 > 192.168.1.210.51061: UDP, дължина 1441
08: 23: 14.485847 IP 216-151-184-30.ipvanish.com.3074 > 192.168.1.210.51061: UDP, дължина 1441
08: 23: 14.486144 IP 216-151-184-30.ipvanish.com.3074 > 192.168.1.210.51061: UDP, дължина 1441
08: 23: 14.486186 IP 216-151-184-30.ipvanish.com.3074 > 192.168.1.210.51061: UDP, дължина 385

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

ipvanish-VPN-OpenVPN режим

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

в обобщение

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

Brayan Jackson Administrator
Sorry! The Author has not filled his profile.
follow me

About the author

Leave a Reply

Your email address will not be published. Required fields are marked *

33 + = 43