- Регистрация
- 17 Февраль 2007
- Сообщения
- 678
- Реакции
- 1.026
- Баллы
- 93
Выбор VPN-сервиса
Возможно, вы не доверяете своему интернет-провайдеру в вопросах защиты конфиденциальности (и, как недавно заключила FTC США, вам действительно не стоит этого делать). Возможно, вы не доверяете своему правительству. Возможно, вы даже не доверяете всем правительствам и корпорациям. Как бы то ни было, если вы по натуре любите исследовать вещи, прежде чем начинать ими пользоваться, это руководство будет полезно.
Если вас особенно беспокоит конфиденциальность, вы, вероятно, захотите не делать свое исследование о VPN-провайдерах достоянием общественности. Хотя многие люди пользуются VPN, глубокие исследования могут выдать вас за человека, которому есть что скрывать. Вы можете уменьшить этот риск, используя на этом этапе бесплатные VPN (например, Calyx VPN) и веб-почту (например, VFEmail). Для еще большей конфиденциальности можете использовать реализацию VFEmail в сети Tor.
В интернете относительно мало надежной и заслуживающей доверия информации о VPN-сервисах. Рекомендуем игнорировать сайты с заголовками "лучшие VPN" и "обзоры VPN". Большинство из них содержат проплаченные обзоры, а некоторые просто размещают плохие отзывы о VPN-сервисах, которые отказываются покупать благоприятные отзывы. Даже честные сайты, как правило, просто составляют списки популярных сервисов, не задумываясь над качеством. Если вам когда-нибудь понадобится получить информацию из специализированного источника обзоров VPN, ищите те, которые не используют партнерские программы в исходящих ссылках (рефералки).
При поиске важно выбрать провайдеров VPN, которые помогут решить ваши конкретные цели по обеспечению конфиденциальности. Рекомендуем тщательно изучить веб-сайты провайдеров и внимательно прочитать их условия предоставления услуг и политику конфиденциальности. Ищите четкие и недвусмысленные формулировки и с подозрением отнеситесь к юридическому шаблону.
Например, если вы планируете обмениваться защищенными авторским правом медиафайлами через BitTorrent, лучше избегать провайдеров, которые прямо запрещают такое использование. Если для вас важна доступность многочисленных локаций, выбирайте соответствующим образом, но учитывайте противоречие между разнообразием и безопасностью. Более вероятно, что провайдеры с многочисленными IP-адресами в разных странах используют виртуальные частные серверы вместо физических выделенных.
То, как потенциальные поставщики VPN отвечают на ваши вопросы, может быть столь же информативным, как сами ответы. Вам нужны быстрые, полные, ясные и точные ответы. Неясные или неправильные ответы на технические вопросы свидетельствуют о нечестности и/или некомпетентности. Несвоевременные ответы не сулят ничего хорошего относительно будущей поддержки клиентов.
Ниже приведены некоторые вопросы, которые вы можете задать VPN-провайдеру перед покупкой , а также ожидаемые ответы и объяснения. Для технических вопросов полезными ресурсами являются руководство по OpenVPN и How-to, а также официальная страница WireGuard.
Вопросы
- Существует ли ежемесячный лимит использования полосы пропускания?
- Ограничиваете ли вы соединения, превышающие лимиты пропускной способности?
- Сколько одновременных подключений разрешено для одной учетной записи?
- Сколько хопов в ваших VPN-соединениях?
- Какой(ие) тип(ы) шифрования VPN вы используете? Почему?
- Поддерживаете ли вы perfect forward secrecy? Если да, то каким образом?
- Предоставляете ли вы пользователям файлы ключей DH?
- Как вы аутентифицируете клиентов – сертификаты и ключи или имена пользователей и пароли?
- Используете ли вы аутентификацию TLS на основе HMAC? Если да, то почему?
- Отправляете ли вы когда-нибудь имена пользователей и пароли клиентам по электронной почте?
- Имеет ли каждый клиент уникальный клиентский сертификат и ключ?
- Где размещены ваши серверы VPN-шлюзов – на хостинге, в одном месте или внутри компании?
- Работают ли какие-либо из ваших серверов VPN-шлюзов на VPS или облачных серверах?
- Как защищены ваши серверы?
- Где хранится информация об учетной записи пользователя?
- Как обеспечивается безопасность связи между серверами?
- Разрешена ли переадресация портов пользователями?
- Все ли клиентские порты переадресованы по умолчанию? Если да, то на каких серверах?
Ответы
- Существует ли ежемесячный лимит использования полосы пропускания? В последние годы это ограничение стало менее распространенным, но некоторые провайдеры используют его на бесплатных уровнях, чтобы потенциальные клиенты могли попробовать свои услуги, прежде чем переходить на платный тарифный план. Ограничения использования для платных подписок более характерны для реселлеров VPN, поэтому лучше избегать провайдеров, которые их вводят.
- Ограничиваете ли вы соединения, превышающие лимиты пропускной способности? Лучший ответ зависит от ваших целей. Вполне естественно хотеть максимально быстрого соединения. Однако, если у вас очень быстрое соединение с провайдером, вы можете передавать гораздо больше трафика, чем любой другой пользователь, пользующийся вашим VPN-выходом. А это снижает вашу анонимность.
- Сколько одновременных подключений разрешено для одной учетной записи? Используя VPN с большим количеством адресов иногда удобно одновременно работать под несколькими псевдонимами. Кроме того, вы можете захотеть одновременно подключаться с нескольких устройств. Однако это также способствует злоупотреблению совместным использованием учетных записей, что может перегрузить серверы VPN и замедлить ваше соединение.
- Сколько хопов в ваших VPN-соединениях? Большинство VPN-сервисов предлагают только однохоповое соединение. То есть вы подключаетесь к серверу VPN-шлюза, и ваш трафик выходит в Интернет с этого же сервера или, возможно, с другого сервера в той же локальной сети. При однохоповом соединении злоумышленникам легко регистрировать входящий и выходящий трафики.
- Какой(ие) тип(ы) шифрования VPN вы используете? Почему? OpenVPN может работать в двух различных режимах. В одном из них аутентификация и шифрование осуществляются с помощью общего статического ключа. Хотя такой режим очень прост в настройке, компрометация ключа позволяет противнику расшифровать весь предыдущий трафик. Ни один уважающий себя провайдер не использует такой способ. Но если вы получили от провайдера всего один файл ключей, откройте его в текстовом редакторе и посмотрите на последнюю строку. Если она включает 'CERTIFICATE', то все в порядке. Но если он содержит 'KEY', потребуйте возврата денег. Другой режим OpenVPN использует SSL/TLS в качестве канала управления и шифрует канал данных периодически меняющимися статическими ключами. Если противнику удастся скомпрометировать один из этих ключей канала данных, он сможет расшифровать только этот трафик, но не любой прошлый или будущий трафик. Другими словами, настроена "совершенная прямая секретность" (Perfect Forward Secrecy). По умолчанию OpenVPN использует 1024-битный RSA для сертификатов, удостоверяющих подлинность SSL/TLS рукопожатий канала управления, и BF-CBC (128-битный) в качестве шифра канала данных. Этого, вероятно, достаточно в большинстве случаев. Однако можно утверждать, что провайдеры, использующие 2048-битный RSA и AES-256-CBC (256-битный), в целом более внимательны к безопасности. И BF-CBC, и AES-256-CBC работают в режиме Cipher Block Chaining (CBC). Если ваш провайдер использует что-то другое (CFB, OFB и т.д.), он либо некомпетентен, либо имеет на то очень веские причины. Выясните их. Недавно появившийся на рынке VPN-протокол WireGuard получил быстрое распространение среди VPN-провайдеров. Этот протокол не был разработан с учетом коммерческих VPN-сервисов и их соображений конфиденциальности. Способные провайдеры должны продемонстрировать, что у них есть решения следующих проблем: 1. Публичные IP-адреса пиров хранятся в памяти (например, добавление управления ключами, которые удаляют/восстанавливают конфигурацию) 2. Распределение/ротация IP-адресов туннеля (например, использование обратных вызовов, генерирующих новые IP-адреса, которые распределяются между всеми серверами) 3. Отсутствие идеальной прямой секретности (например, использование автоматической регенерации пары ключей через регулярные промежутки времени).
- Поддерживаете ли вы perfect forward secrecy? Если да, то каким образом? Любой провайдер, использующий OpenVPN в режиме SSL/TLS, обеспечивает идеальную прямую секретность. Дополнительные размахивания руками, выходящие за эти рамки, должны вызвать у вас подозрения. Как отмечалось ранее, реализация WireGuard требует специальных мер для поддержки прямой секретности.
- Предоставляете ли вы пользователям файлы ключей Diffie Hellman? Это вопрос с подвохом. Это правда, что OpenVPN использует статические файлы ключей Diffie Hellman для обеспечения идеальной прямой секретности. Но этот статический файл ключей Diffie Hellman ('dh1024.pem' или 'dh2048.pem') нужен только на сервере. Любой провайдер, предоставляющий их пользователям, некомпетентен.
- Как вы аутентифицируете клиентов – сертификаты/ключи или имена пользователей/пароли? В режиме SSL/TLS клиенты OpenVPN аутентифицируют серверы, проверяя, есть ли у сервера сертификат, подписанный центром сертификации ('a.crt'), который предоставил им провайдер. OpenVPN поддерживает два метода аутентификации клиентов серверами. Один из них основывается на сертификатах и ключах (таких как 'client.crt' и 'client.key'). Другой полагается на имена пользователей и пароли (через auth-user-pass). Серверы могут использовать и то, и другое, но это уже граничит с чрезмерностью. Для p2p-соединений, где на карту может быть поставлен полный доступ к сети, очень важно, чтобы серверы аутентифицировали клиентов с помощью сертификатов и ключей. Для служб VPN это не является проблемой, поскольку клиенты просто видят интернет. Кроме того, для служб VPN предоставление каждому клиенту уникального сертификата является риском для конфиденциальности.
- Используете ли вы аутентификацию TLS на основе HMAC? Если да, то почему? При включенной аутентификации TLS (через tls-auth) серверы игнорируют пакеты рукопожатия SSL/TLS от клиентов, у которых отсутствует правильная подпись HMAC. Эта функция защищает VPN-серверы от DoS-атак, сканирования портов и других атак. Если эта функция реализована, провайдеры могут предоставлять ключ (обычно 'ta.key') или он может быть согласован на лету. Отчасти это вопрос с подвохом. Любой провайдер, утверждающий, что это необходимо для идеальной прямой секретности, либо нечестен, либо некомпетентен.
- Отправляете ли вы когда-нибудь имена пользователей и пароли клиентам по электронной почте? Это опасная практика, и в первую очередь для провайдера. Недоброжелатели, скомпрометировавшие имена пользователей и пароли во время доставки, могут получить свободный доступ или даже заблокировать платящих пользователей, изменив пароли. Существует также риск того, что злоумышленники могут вовлечь пользователей в преступную деятельность. Даже в этом случае, если вы успешно смените пароль сразу после получения, вы в безопасности. Если вы не можете войти в систему, чтобы сменить пароль, жалуйтесь и требуйте новую учетную запись. Для провайдеров, которые в остальном привлекательны, это не фатальная ошибка.
- Имеет ли каждый клиент уникальный клиентский сертификат и ключ? Это еще один вопрос с подвохом. В качестве ответа на этот вопрос можно предоставить один и тот же сертификат клиента для всех клиентов или не предоставлять его вообще и полагаться на имя пользователя и пароль для аутентификации. Может показаться хорошей идеей, что у каждого пользователя должен быть свой сертификат и ключ. И это верно в контексте предприятия. Но для служб VPN это очень опасно, поскольку потенциально может связать учетные записи пользователей с регистрируемым трафиком. Некоторые провайдеры объясняют, что они выдают уникальные клиентские сертификаты, чтобы облегчить нейтрализацию злостных клиентов. Однако это так же легко сделать и с именами пользователей, а имена пользователей более легко теряют валидность, чем сертификаты. Если для вас это ключевой вопрос, его легко проверить, купив две краткосрочные подписки, заплатив биткоинами через Tor и используя временные адреса электронной почты с anonbox и т.д.
- Где размещены ваши серверы VPN-шлюзов – на хостинге, в одном месте или внутри компании? Отчасти это также вопрос с подвохом. Мы бы с большим подозрением отнеслись к любому VPN-провайдеру, утверждающему, что его серверы управляются собственными силами. Вы можете спросить, как они покрывают расходы на содержание мощностей с высокоскоростными линиями связи в нескольких странах. Наиболее правдоподобным ответом будет то, что они строят свои собственные серверные и отправляют их в места совместного размещения. Начисляйте дополнительные баллы за защиту серверов. Типичные меры физической защиты включают в себя встраивание оперативной памяти в термоклей, а также отключение USB-портов. Наиболее вероятный приемлемый ответ – использование выделенных серверов. Начислите дополнительные баллы за такие меры укрепления сервера, как использование полнодискового шифрования и хранение краткосрочных журналов в оперативной памяти (tempfs).
- Работают ли какие-либо из ваших серверов VPN-шлюзов на VPS или облачных серверах? Провайдеры никогда не должны размещать серверы VPN-шлюзов на виртуальных частных серверах (VPS) или облачных серверах. Будучи виртуальными машинами, они полностью контролируются операционной системой хоста, и все действия и данные легко доступны через хост. Провайдеры всегда должны использовать выделенные физические серверы, которые должным образом защищены от несанкционированного доступа.
- Как защищены ваши серверы? В VPN-сервисах обычно используются серверы, играющие три роли. Существуют серверы-шлюзы, которые устанавливают VPN-соединения с клиентами, а также маршрутизируют клиентский трафик в Интернет. При однохоповом соединении все эти функции может выполнять один сервер. Есть серверы, на которых размещается веб-сайт службы. Есть также серверы, которые управляют информацией об учетной записи пользователя и предоставляют услуги аутентификации серверам-шлюзам и веб-серверам. Весь клиентский трафик направляется через серверы-шлюзы. Если эти серверы не защищены должным образом, противники могут скомпрометировать их и тем самым нарушить конфиденциальность пользователей, регистрируя их трафик. Шлюзы VPN должны быть укреплены в соответствии с отраслевыми стандартами, пример: бенчмарки CIS или базовые рекомендации АНБ. Самое главное, серверы шлюзов VPN не должны работать с другими сетевыми сервисами, такими как хостинг веб-сайтов или учет и аутентификация пользователей. Это существенно повышает риски. Проверить, какие порты и службы доступны на VPN-шлюзе, можно с помощью сканера портов, например, nmap. Однако имейте в виду, что многие провайдеры открывают VPN-серверы на нестандартных портах, таких как 80 (HTTP) и 443 (HTTPS), чтобы обойти блокировку брандмауэра.
- Где хранится информация об учетной записи пользователя? В идеале поставщики должны хранить эту информацию на собственных серверах, которые соответствующим образом зашифрованы и защищены от недоброжелателей. Кроме того, они должны отделять данные аутентификации, которые должны быть доступны серверам шлюза, от учетных данных, которые могут включать частную информацию пользователей, такую как логи, адреса электронной почты и записи о платежах.
- Как обеспечивается безопасность связи между серверами? Хорошо продуманные VPN включают в себя сети специализированных серверов с различными функциями, которые безопасно взаимодействуют друг с другом. Например, серверы шлюза должны связываться с серверами аутентификации для проверки того, что пользователи авторизованы для подключения. Существуют также внутренние системы обеспечения, которые используют данные о продажах с веб-сайтов для создания и обновления учетных записей пользователей, а затем обновляют серверы аутентификации. Учитывая чувствительность этих данных и их ценность для злоумышленников, все коммуникации между этими серверами должны быть надежно зашифрованы. Чаще всего для этого используются постоянные туннели OpenVPN или IPSec между серверами.
- Разрешена ли переадресация портов пользователями? Когда вы подключены VPN, сервер шлюза защищает ваше устройство от потенциально враждебных входящих соединений так же, как это делает маршрутизатор или брандмауэр в локальной сети. Однако разрешение входящих соединений на определенные порты необходимо для работы серверов или для участия в сетях p2p, где ваш узел должен быть виден другим узлам. Этот процесс называется пробросом портов. Когда проброс портов включен, ваше устройство напрямую выходит в Интернет через проброшенные порты, без какой-либо защиты со стороны службы VPN. Недоброжелатель может успешно использовать уязвимость в службе, которая прослушивает проброшенный порт, и скомпрометировать ваше устройство. Помимо типичных последствий, таких как участие в ботнете и кража данных, противник может нарушить ваши конфиденциальность и анонимность.
- Все ли клиентские порты переадресованы по умолчанию? Если да, то на каких серверах? Некоторые VPN-сервисы по умолчанию пробрасывают все клиентские порты. Некоторые делают это только на определенных серверах. В некоторых сервисах проброс портов на разных серверах варьируется без какой-либо схемы или документации. Хотя это можно проверить с помощью сканирования портов, проблема в том, что у разных клиентов, использующих один и тот же IP-адрес выхода, могут быть проброшены одни и те же порты.
Оригинал
Русская адаптация
Последнее редактирование:
