Наскільки легко виявити використання VPN?

Віртуальні приватні мережі (VPN) вирішують багато проблем із конфіденційністю. Оскільки VPN зазвичай шифрує ваш трафік між вашим комп’ютером та постачальником VPN, спостерігачеві дуже важко переглядати ваш трафік, щоб побачити, що ви збираєтеся. Однак є багато людей, які хочуть приховати той факт, що вони взагалі використовують VPN; наприклад, люди в країнах, які забороняють VPN, або інші ситуації, коли використання VPN зазвичай не дозволено або заблоковано технічними засобами. У цій статті ми зупинимося на типі даних, який спостерігач може збирати із захоплення мережевого пакету, і на тому, як ці дані можуть бути використані для виявлення використання VPN.


Передумови проблеми

Пекуче питання “чому”? Кого хвилює, якщо хтось виявить, що ви користуєтесь VPN? Якщо трафік так чи інакше сильно зашифрований, у чому проблема?

Це правда, що в багатьох ситуаціях і в багатьох країнах це зовсім не має значення, чи спостерігач виявить використання VPN. Однак існує багато країн, які забороняють використовувати VPN, і тому користувачам VPN у цих країнах важливо знати, як їх можна виявити.

Щоб визначити, чи використовується VPN, спостерігач повинен мати доступ до маршрутизатора, через який проходить цільовий трафік. Що стосується цілеспрямованої жертви, зловмисник може витратити великі ресурси для визначення способу захоплення маршрутизатора, який використовує конкретна жертва. У випадку нагляду за національною державою, ефективне виявлення потребує контролю над багатьма маршрутизаторами. Коли ви поєднуєте ці дві речі – організацію, яка піклується про те, чи ви використовуєте, і VPN а також має можливість контролювати велику кількість маршрутизаторів – що зазвичай вказує на актора загрози на національному рівні.

Майте на увазі, що в цій статті йдеться про способи, якими спостереження можуть виявити використання VPN. Це не обов’язково означає, що дані, зашифровані в тунелі VPN, простіше експлуатувати.

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

Без доступу до ресурсів на державному рівні моя тестова платформа та методологія трохи менші за масштабом. Я створив невелику внутрішню мережу за допомогою трьох віртуальних машин (VM) з VirtualBox. Топологія мережі є такою:

Налаштування тестової мережі VPN

Я встановив програмне забезпечення для обнюхування пакетів на маршрутизаторі VM OpenWRT, а потім протестував різні конфігурації VPN на двох інших віртуальних машинах. Програмне забезпечення для обнюхування пакетів, tcpdump, дозволило мені захопити мережевий трафік VM для аналізу. У більш реалістичних налаштуваннях програмне забезпечення для захоплення пакетів, можливо, буде встановлене в маршрутизаторах в Інтернеті або, принаймні, в мережі провайдера. Стратегічне розміщення програмного забезпечення для аналізу потребує певних знань про точки конвергенції, що цікавлять Інтернет, де цільовий трафік, ймовірно, протікає. У своїй тестувальній мережі я знаю зі 100% впевненістю, що весь трафік до моїх віртуальних машин буде проходити через цей маршрутизатор OpenWRT. Тому для мене найкраще розмістити свої інструменти колекціонування.

Нетехнічні джерела показників VPN

Не всі джерела даних, які вказують на використання VPN, є технічними. Хоча деякі дуже технічні, такі як аналіз пакетів, деякі – дуже нетехнічні, такі як людські помилки та розпорядок дня.

Ненавмисний мережевий трафік

Більшість користувачів VPN мають клієнтське програмне забезпечення, яке необхідно запустити для встановлення VPN. Дуже важко забезпечити, щоб трафік через Інтернет не проходив до встановлення VPN, коли комп’ютер завантажується. Навіть ті VPN, що мають комутатори, не можуть зробити нічого щодо трафіку, який проходить під час завантаження системи.

vypr-vpn-autoconnect-mode

vypr-vpn-killswitch-mode

Щоб перевірити це, я встановив параметри автоматичного підключення та вбиття комутатора VyprVPN у віртуальній машині Windows. Потім я вимкнув машину Windows, запустив захоплення пакетів на маршрутизаторі OpenWRT і запустив машину Windows. Ці дві послідовності викликали велику кількість пакетів і представляють інтерес.

По-перше, ми можемо побачити безліч пінгів для аналогічного діапазону IP-адрес. Я цілеспрямовано не групував ці пакети – ось як їх органічно надсилали:

vypr-vpn-windows-boot-ICMP-пакети

Це говорить про те, що щось намагається перелічити сервери. Дуже поширеною причиною такого типу трафіку в сценарії VPN є клієнт VPN, який намагається визначити найшвидший сервер. Один із способів зробити це – надіслати пакет ICMP (відомий як ping) на набір серверів, щоб побачити, який з них повертається найшвидше.

З першого знімка ми бачимо, що 209,99.63,34 найшвидше повернулося за 99 мілісекунд. Далі вниз при захопленні пакетів ми раптом бачимо, що більша частина трафіку з цього моменту зашифрована і призначена на 209,99.63,34

vypr-vpn-windows-boot-QUIC-пакети

Наступний фрагмент головоломки – з’ясувати, що є на цих ІС. Використовуючи IP WHOIS, який заявляє про зареєстрованого власника IP, ми можемо бачити, що всі, крім одного з цих IP-адрес, належать корпорації YHC і мають доступ до серверів у центрі обробки даних Data Foundry:

209.99.108.46
OrgName: Корпорація YHC
OrgTechEmail: [email protected]
209.99.109.167
OrgName: Корпорація YHC
OrgTechEmail: [email protected]
209.99.113.70
OrgName: Корпорація YHC
OrgTechEmail: [email protected]
209-99-115-97
209.99.117.82
OrgName: Корпорація YHC
OrgTechEmail: [email protected]
209.99.21.36
OrgName: Корпорація YHC
OrgTechEmail: [email protected]
OrgTechEmail: [email protected]
209.99.22.46
OrgName: Корпорація YHC
OrgTechEmail: [email protected]
209.99.60.34
OrgName: Корпорація YHC
OrgTechEmail: [email protected]
209.99.61.42
OrgName: Корпорація YHC
OrgTechEmail: [email protected]
209.99.62.34
OrgName: Корпорація YHC
OrgTechEmail: [email protected]
OrgName: Powerhouse Management, Inc.
OrgTechEmail: [email protected]
209.99.63.34
OrgName: Корпорація YHC
OrgTechEmail: [email protected]
209.99.63.34
OrgName: Корпорація YHC
OrgTechEmail: [email protected]
209.99.67.41
OrgName: Корпорація YHC
OrgTechEmail: [email protected]
209.99.72.70
OrgName: Корпорація YHC
OrgTechEmail: [email protected]
209.99.75.70
OrgName: Корпорація YHC
OrgTechEmail: [email protected]
209.99.93.34
OrgName: Корпорація YHC
OrgTechEmail: [email protected]
209.99.94.37
OrgName: Корпорація YHC
OrgTechEmail: [email protected]
209.99.95.40
OrgName: Корпорація YHC
OrgTechEmail: [email protected]

Наступним логічним кроком буде сканування цих IP-адрес, щоб побачити, які сервіси вони запущені. Я не буду надавати детальну інформацію про те, як це зробити, але моє тестування показує, що банери підключення за замовчуванням, які відображаються на більшості серверів, були видалені з серверів VyprVPN, тому немає очевидної розповіді про те, що ці IP-адреси працюють із сервером VPN.

Ви не можете багато зробити того, як діє ваш комп’ютер до його завантаження. Тому, якщо ви хочете придушити цей тип послідовності налаштування, вам потрібно буде запустити VPN “перед” свого комп’ютера. Запуск клієнта VPN на маршрутизаторі замість запуску клієнта на комп’ютері – це один із способів зробити це. Ви все одно будете наштовхуватися на ті самі послідовності запуску, коли роутер перезапуститься, але це зазвичай рідше, ніж ваш комп’ютер.

Ніяких незашифрованих пакетів

Як я вже згадував вище, як тільки пінг завершився, захоплення пакетів показує зашифрований трафік до найшвидшого IP. Якщо спостерігач бачить лише зашифровані пакети, а не один незашифрований пакет, це може бути ознакою використання VPN. Хоча світ швидко рухається до шифрування якомога більшої кількості даних в Інтернеті, все ж є деякі запити, які зазвичай не шифруються. Серед них запити пошуку DNS, запити NNTP (сервер часу) та випробування інших протокольних запитів, таких як FTP та Telnet, які іноді використовуються в деяких наших програмах, але не підтримують шифрування взагалі..

Витоки від неохайної оперативної безпеки людини (OpSec)

Значну кількість значущих даних можна отримати з цілі, використовуючи, здавалося б, тривіальну інформацію. Багато людей витрачають багато часу і зусиль на пом’якшення того, що вони сприймають як “важливий” матеріал, лише щоб його визначити за тривіальною інформацією, про яку вони не думали. Деякі приклади включають довгу пам’ять в Інтернеті, яка виявила, що адміністратор електронної пошти Гілларі Клінтон був, швидше за все, хлопцем на ім’я Пол Комбетта; Пірат Робертс (Dread Pirate Roberts), AKA Ross Ulbricht, передбачуваний натхненник нелегальної інтернет-ринку “Шовковий шлях”, був притягнутий до кримінальної відповідальності за рахунок даних про його ноутбук, які фізично були забрані у нього під час відволікання в публічну бібліотеку.

Менш драматично, спостерігачі можуть часто використовувати такі речі, як цикли діяльності, щоб закріпити часовий пояс цілі або наявність спеціальних символів у повідомленні для ідентифікації мовного мовлення, що відповідає країні цілі. Немає повного переліку речей, які слід враховувати під час розгляду оперативної безпеки, оскільки придумувати нові способи перехресних посилань на дані є переважно вправою уяви та ресурсів.

Однак є деякі конкретні речі, які стосуються захоплення пакетів, які можуть ідентифікувати використання VPN.

Знаки довідників з метаданих пакетів

Повторні клавіші PFS передбачувані

Оскільки трафік VPN зазвичай шифрується, він, як правило, захований від сторонніх очей. Шифрування працює тому, що дуже важко “грубо примусити” зашифровані дані, щоб викрити його чіткий текстовий вміст. Насправді, зламати шифрування настільки важко, що масштабні проекти спостереження іноді просто збирають усі дані, які вони можуть, сподіваючись, що вони зможуть зламати шифрування в якусь майбутню дату, коли потужність комп’ютера зросте, або вони зможуть отримати ключі які були використані для шифрування даних. Perfect Forward Secrecy (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-mode

Щоб побачити, як це виглядає на рівні пакетів, я запустив 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: Прапори [.], Seq 1026833: 1028293, ack 715, win 5094, довжина 1460
08: 30: 14,229427 IP www.cira.ca.https > 192.168.1.210.58787: Прапори [.], Seq 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.], seq 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.], seq 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, прапори [DF], протокол UDP (17), довжина 177)
google-public-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. А 104,94,35,212 (149)
08: 08: 51,659278 IP (tos 0x0, ttl 127, id 3890, offset 0, прапори [DF], протокол TCP (6), довжина 52)

Пакет, захоплений з машини Linux, має TTL 63 після першого переходу. Це тому, що більшість машин Linux встановлюють початкове значення пакету TTL в 64.

08: 15: 55,913493 IP (tos 0x0, ttl 63, id 41443, offset 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 вказівник доменного імені edge-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-адреса, для якої призначений ваш трафік Наприклад, команда 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-mode

Пакети вище були захоплені під час сеансу за допомогою прихованого налаштування з’єднання OpenVPN, але WireShark все ще може надати інформацію про призначення.

Підводячи підсумок

При визначенні використання VPN дуже мало «срібних куль». Зазвичай потрібно декілька методів чи спостережень, щоб скласти достатню кількість показників, які вказують на те, що VPN використовується, і навіть тоді це може бути важко бути на 100% впевненим. Компанії, які зацікавлені у забороні використання VPN, таких як Netflix та інші потокові послуги, мають штатні команди, присвячені саме цій проблемі. В інших випадках багато країн Східної Європи та Близького Сходу забороняють використання VPN та мають подібні команди для викриття користувачів VPN.

Kim Martin Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map