Насколько легко обнаружить использование VPN?

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

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

Жгучий вопрос «почему»? Кого волнует, если кто-то узнает, что вы используете VPN? Если трафик все равно сильно зашифрован, в чем проблема?

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

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

Помните, что в этой статье рассматриваются способы, с помощью которых наблюдатели могут обнаружить использование VPN. Это не обязательно означает, что данные, зашифрованные в VPN-туннеле, легче использовать.

Методология тестирования

Без доступа к ресурсам на уровне государства моя платформа и методология тестирования немного меньше по масштабу. Я создал небольшую внутреннюю сеть, используя три виртуальные машины (ВМ) с VirtualBox. Топология сети такова:

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

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

Не все источники данных, которые указывают на использование VPN, являются техническими. Хотя некоторые из них очень технические, такие как анализ пакетов, некоторые из них очень нетехнические, такие как человеческие ошибки и распорядок дня.

Непреднамеренный сетевой трафик

Большинство пользователей VPN имеют клиентское программное обеспечение, которое должно быть запущено, чтобы установить VPN. Очень трудно гарантировать, что трафик не будет проходить через Интернет до того, как VPN будет установлен при загрузке компьютера. Даже те VPN с коммутаторами kill могут не иметь ничего общего с трафиком, который проходит во время загрузки системы.

Чтобы проверить это, я установил параметры автоматического подключения и отключения 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 и подключаются к серверам в центре обработки данных 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 Secrecy повторно генерирует ключи шифрования, используемые для периодического шифрования трафика 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 и протестировал два сайта. Я нахожусь в Канаде, и вот пример трафика, который предназначен нашему регистратору доменов .CA. В этом случае мой пункт назначения хорошо виден при захвате пакета.

8: 30: 14.213668 IP 192.168.1.210.58787 > www.cira.ca.https: Flags [.], ack 1026833, win 64240, длина 0
08: 30: 14.229178 IP www.cira.ca.https > 192.168.1.210.58787: Flags [.], Seq 1026833: 1028293, ack 715, win 5094, длина 1460
08: 30: 14.229427 IP www.cira.ca.https > 192.168.1.210.58787: Флаги [.], След. 1028293: 1031213, подтверждение 715, выигрыш 5094, длина 2920
08: 30: 14.229781 IP 192.168.1.210.58787 > www.cira.ca.https: Flags [.], 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, победа 1392, длина 468
08: 29: 48.029101 IP 192.168.1.210.58659 > li832-56.members.linode.com.ssh: Флаги [.], ack 108277, победа 856, длина 0
08: 29: 48.029306 IP 192.168.1.210.58659 > li832-56.members.linode.com.ssh: Flags [P.], seq 19080: 19132, ack 108277, победа 856, длина 52
08: 29: 48.108658 IP li832-56.members.linode.com.ssh > 192.168.1.210.58659: Flags [.], Ack 19132, win 1392, длина 0

Обратите внимание, как трафик, предназначенный для США, отправляется на сервер Linode, а не на сравнения. Linode – очень большая серверная компания, и совсем нередко можно увидеть трафик, предназначенный для сервера Linode. Psiphon далее запутывает этот трафик, используя туннель SSH, чтобы скрыть любые следы VPN. Кроме того, обратный DNS (rDNS) для сервера Psiphon в Linode не выдает его связь с Psiphon; rDNS просто показывает, что Linode владеет IP, который ожидается. Подробнее о rDNS в разделе обфускации далее в этой статье..

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

Хотя сеть TCP не зависит от операционной системы, разные операционные системы создают пакеты с разными значениями. Например, значение времени жизни пакета по умолчанию (TTL) варьируется в пакетах, созданных в разных системах. В большинстве систем Windows пакет TTL по умолчанию устанавливается равным 128, тогда как в большинстве систем Linux он устанавливается равным 64. Поскольку TTL является видимой частью захваченного пакета, можно определить, какая ОС, скорее всего, создала этот пакет. Существуют также другие контрольные признаки в построении пакета, такие как длина и максимальный размер сегмента (MSS), которые также варьируются от операционной системы к операционной системе..

Фрагмент ниже является частью пакета, сгенерированного из системы Windows. Обратите внимание ттл 127 значение в последней строке установлено равным 127. Это потому, что TTL выражается в количестве «прыжков». Каждый раз, когда пакет проходит через такое устройство, как маршрутизатор, его TTL уменьшается на единицу. В этом случае TTL начинался с 128, но с тех пор, как я перехватил его на маршрутизаторе – после одного прыжка – сейчас 127. Однако я все еще могу сказать, что он никогда не был 64, так что, скорее всего, это пакет, созданный в системе Windows..

08: 08: 51.657495 IP (tos 0x0, ttl 64, id 32150, смещение 0, флаги [DF], прото 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, смещение 0, флаги [DF], протокол 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 > resolver1.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-адреса может связать запись rDNS с ней. Таким образом, проверка записи IP-адреса в rDNS дает разумную уверенность в том, кто владеет им, или, по крайней мере, кто, по мнению владельца, владеет им. Обратите внимание, что rDNS не требуется, и многие IP-адреса вообще не имеют записей rDNS..

Давайте рассмотрим пример домена facebook.com. Запись DNS A, предоставленная стандартным запросом DNS, показывает этот IP-адрес:

$ dig + short facebook.com
31.13.67.35

Теперь давайте используем обратный DNS-запрос или функцию gethostnamebyaddr (), чтобы увидеть, кому принадлежит этот IP:

$ host -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 для Google IP:

$ dig + short google.com
216.58.207.46

$ host -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. По-видимому, для этого в первую очередь используется gethostbyaddress (), и поэтому иногда можно увидеть, куда направляются пакеты. Захват 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 и обфусцированное соединение.

Вышеуказанные пакеты были перехвачены во время сеанса с использованием скрытой настройки соединения OpenVPN, однако WireShark все еще может предоставить информацию о назначении.

В итоге

При определении использования VPN «серебряных пуль» очень мало. Обычно требуется ряд методов или наблюдений для составления достаточного количества индикаторов, которые указывают на использование VPN, и даже в этом случае может быть трудно быть уверенным на 100%. Компании, которые заинтересованы в запрете использования VPN, таких как Netflix и другие потоковые сервисы, имеют постоянные команды, посвященные именно этой проблеме. В других случаях многие страны Восточной Европы и Ближнего Востока) запрещают использование VPN и имеют аналогичные группы для поиска пользователей VPN.