Обсуждение статьи: VPN: плюсы и минусы - Форум по вопросам информационной безопасности

Виртуальные Защищённые Сети - это удел прошлого, это костыль и вот почему:
1. Плавающая задержка - данные должны сначала поступить на адаптер VPN, затем адаптер должен их передать по сети, затем другой адаптер должен их принять и перенаправить на программу.
2. Незащищённое звено - данные, передаваемые по сети, защищены, но когда они достигли адаптера и перенаправляются на саму программу, они уже передаются ей в расшифрованном виде. При таком подходе, любой случайный пакет, пришедший извне, может также пройти в программу. Чтобы этого не произошло, должны отбрасываться все левые пакеты "127.0.0.1", фаервол должен блокировать все левые пакеты для защищаемой программы и определять, пакеты с каким адресом пропускать, а с каким нет. Это всё трудно настроить без дыр.
3. Негарантированный порядок - порядок пакетов UDP, передаваемых по сети, контроллируется метками пакетов, но попав на адаптер, нет гарантии, что они при передачи в программу не перепутаются из-за особенностей стека IP протоколов ОС.
4. Сложность масштабируемости - VPN нужно настраивать и устанавливать на конечной точке, это приводит к тому, что сеть VPN не динамична в работе и скорее статична.
5. Лишний слой абстракций - VPN как концепция усложняет восприятие деталей работы программы по сети из-за лишнего абстрактного слоя.
6. Бесполезность в некоторых случаях - у VPN только одно преимущество - защита данных, поскольку большинство программ передают данные в сеть не защищая их, но если программа использует свою защиту данных, VPN для неё полностью бесполезен. То, что VPN используется для эмуляции одноранговой сети - этого в будущем не будет, когда придёт IPv6 и NAT будет не нужен.

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

Приветствую!
1. В эпоху наших производственных мощностей этой "задержкой" можно, зачастую, пренебречь.
2. Виртуальный адаптер = виртуальный интерфейс. Если под VPN понимать stunnel или OpenVPN, то, конечно, означенная проблема (с 127.0.0.1) теоретически возможна. Но они, благо, в чистом виде для защиты реально конфиденциальных данных не применяются. А в более-менее готовом решении (или при допустимой кривизне рук настройщика дополнительно внедренного межсетевого экрана) - данная проблема элементарно решается.
3. Каждый UDP-пакет попадает в виртуальный интерфейс - проходит дешифровку - раскрывает содержащийся внутри TCP-пакет (зачастую, конечно), который уже имеет явную метку порядкового номера -> производится "спайка" всех нужных пакетов в информационный поток. Вывод: порядок поступления UDP-шифрованного трафика не важен.
4. Решается применением УЦ. Или мы говорим о разной "статике" и "динамике"?
5. Напротив, этот "лишний слой" добавляет гибкости любой сетевой системе. Вы же против VLAN ничего не имеете?
6. Преимущество VPN не только в защите передаваемых данных, но и в явной криптостойкой идентификации абонентов между собой. Зачастую, простые VPN-решения применяются не столько для криптозащиты каналов связи, сколько для лишения нарушителей возможности подмены "доверенного" абонента в сети. При условии, конечно, частой смены ключей шифрования.
IPv6 - дальнее будущее, которое пока ожидать не приходится. В промышленных и международных средах, конечно, применяется. Но в малых компаниях по стране - нет. Ибо слишком дорого/сложно выполнить грамотный переход (большей частью из-за квалификации оконечного персонала). Так что NAT+IPv4 жил, жив и будет жить...

Забыл добавить...
Причина 3 касается только UDP трафика, который не имеет встроенных средств контроля порядка и при отправке программе может быть перепутан из-за стека IP, для TCP это и правда не важно. Хотя эта проблема не самая главная.

Можно также добавить к списку выше:
discord - сервис голосовой связи, используя всего-лишь браузер, ничего не скачивая, соединение защищено.
Социальные сети - ВК, Одноклассники, Твиттер, Фейсбук - соединение уже защищено.

Значит по логике, остальные программы снабдить защитой и больше уже ничего не надо)

Что-то вы все в одну кучу сложили. Все приведенные выше программы используют "обертки" сетевого трафика. В целом, идеалогия VPN - встраивание криптозащиты в передаваемый трафик с последующей его дешифровкой на приемной части. И для них (на уровне ПО) абсолютно подходят все указанные вами ранее для VPN "недостатки". А уж на уровне пользователей... особенно тех, кого не интересует организация сети...
VPN - решение, позволяющее обеспечить защиту передаваемых данных и "доверенность" отправляющей-принимающей сторон для любого объекта, использующего сети на основе стека TCP/IPv4. Главное - для любого типа трафика из указанных условий. Универсальность - главный плюс. А программы... с позиции встраивания - это не решение. С позиции же немого вопроса "почему меня заставляют ставить VPN-маршрутизаторы, когда мой Skype прекрасно защищает мои данные?" - ответ чисто риторический в стиле "а от кого он защищает и защищает ли?"...

Вот всё дело в самой обёртке, одно дело, когда данные поступают на сам сокет программы, и другое дело, когда они приходят в открытом виде от сокета адаптера VPN, вот между адаптером и программой образуется незащищённый промежуток, который отсутствует, когда данные приходят непосредственно на сам сокет программы, и уже расшифровываются там же.

VPN имеет плюсы, потому что программы имеют недостатки, VPN выигрывает на недостатках самих программ, и этот недостаток - отсутствие защиты данных в самой программе.

Согласитесь, одно дело, когда программа подключает программный модуль защиты данных, и совсем другое, когда защиту данных обеспечивает отдельная программа в виде адаптера VPN и затем передаёт данные в открытом виде сокету самой программы. Вот это главная проблема. Мне например, чтобы отгородить программу, пришлось настраивать несколько правил, чтобы отгородиться от 0.0.0.0, 127.0.0.1, выделить диапазон 10.0.0.0 - 10.255.255.255 и другое... Однако потом оказалось, что пакет с моего внешнего адреса спокойно прошёл через фаервол COMODO 5.x и достиг программы, потому что фаервол почему-то фильтрует Loopback, но разрешает подключаться к самому себе через внешний адрес, который висит на моём интерфейсе (у меня кабель от провайдера напрямую подключается к ПК, без роутера).
И я уверен, что есть и другие дыры, которые я не обнаружил, поэтому я и решил перейти на Mumble вместо TeamSpeak, потому что в последнем нет шифрования.

Как решить проблему с этим незащищённым промежутком, кроме как не внедрить защиту непосредственно в саму программу?

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

Смотрите, каждая программа открывает сокет на 0.0.0.0 - т.е. принимает пакеты со всех интерфейсов, значит если в программе нет нормальной фильтрации, то нужно огораживать программу фаерволом - это первый геморрой.

Далее, допустим у клиента нет фаервола, или он отключён или настроен неверно, вот что получается теоретически:
Я могу послать ему поддельный пакет (сырые сокеты C++ RAW), который например содержит его собственный IP адрес отправителя и такой же адрес получается (допустим маршрутизаторы пропустят такой пакет), COMODO 5.x например его пропустит, или поддельный пакет из диапазона защищённых адресов например адреса 10.1.1.1, и он скорее всего пройдёт мимо VPN и достигнет программы, или например у клиента есть другой интерфейс, например 3G модем или другая сеть WiFi, я могу послать пакет через них, и всё, программа получит поддельные данные или команды.
Нереально это всё настроить на стороне клиента без дыр. Вот этот незащищённый промежуток - это слабое звено всей защиты и решения этой проблемы в рамках концепции VPN я не вижу.

Покажите что я не прав)

Опечатка:
Написано - "Я могу послать ему поддельный пакет (сырые сокеты C++ RAW), который например содержит его собственный IP адрес отправителя и такой же адрес получается (допустим маршрутизаторы пропустят такой пакет), ...",
следует читать - "Я могу послать ему поддельный пакет (сырые сокеты C++ RAW), который например содержит его собственный IP адрес отправителя и такой же адрес получаТЕЛЯ (допустим маршрутизаторы пропустят такой пакет), ...".

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

Использовал я OpenVPN, когда я его настроил мне показалось, что я совершил какой-то подвиг)
OpenVPN был лишь дополнением для клиентов, т. е. через него не проходил интернет клиентов, поэтому всегда оставалась уязвимость, что в программу может прийти трафик с "другого интерфейса".

Как Вы правильно заметили, доступ в сегментную часть оперативной памяти конкретной программы со стороны практически невозможен, она защищена и отделена, поэтому я и указал на то, что только если программа будет защищать свой трафик, то все слабые места исчезнут (ну если только сам ключ не утечёт).
Зато согласитесь, как просто было бы установить соединение с программой - передал клиенту ссылку на программу, адрес сервера + порт, идентификатор пользователя и ключ, и всё, клиент может пользоваться сервисом.

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

Да, речь явно шла о светлом будущем) Спасибо за дискуссию)

И ещё добавить забыл:
В принципе, как Вы правильно сказали, если только VPN полностью фильтрует весь трафик на ПК монолитно, тогда да, пакет извне не придёт, но в таком случае интернет пользователю должен предоставляться только через VPN, т. е. каждый клиент должен быть подключён к VPN серверу провайдера и выходить в интернет через VPN сервер провайдера.
Но в таком случае клиент не может даже обмениваться данными со своими устройствами дома по сети WiFi например.
Но даже если это не учитывать, то в любом случае для безопасного обмена трафиком удалённый клиент должен быть подключен к сети VPN, а если он уже подключён к другой сети VPN, то нужно прокладывать мосты между этими двумя сетями, потому что клиенту можно иметь только одну сеть VPN монолитно...
Вообщем, защитить слабое звено между адаптером и программой путём полной изоляции клиента от внешних каналов - гм... я даже не знаю, правильно ли это, может быть...

Ну и последний важный вопрос, который бы я хотел спросить:
Сейчас многие провайдеры постепенно отказываются от VPN сервера для своих клиентов, как мне кажется, это связано с повышением производительности сети, смотрите:
Провайдеры стремяться сбросить с себя несвойственные им функции, а именно:
1. Трансляция адресов, из-за нехватки белых адресов IPv4.
2. Фрагментация пакетов.
3. Шифрование трафика.

Это основные три причины, которые сильно понижают производительности сети, поэтому:
1. Провайдеры переходят на IPoE, чтобы не шифровать трафик и избавиться от VPN, PPPoE и других туннельных технологий.
2. Провайдеры стараются переходить на IPv6 (статистика 6lab.cisco.com), чтобы избавиться от NAT и просто маршрутизировать трафик, ничего не транслируя.
3. IPv6 запрещает маршрутизаторам фрагментацию трафика, поэтому вся функция маршрутизатора сводится только к маршрутизации пакетов, без шифрования, трансляции и фрагментации.

Поскольку речь идёт в основном о проводном интернете, а в будущем я думаю скорость 10 Гбит/сек станет достаточно распространённой, то такой огромной скорости достичь не получиться, не решив вышеизложенные проблемы.

Поэтому предполагается, что защищать свои данные должны конечные точки. Смотрите, допустим у нас 1000 клиентов, и каждый подключается к своим серверам, ВК, Одноклассники, Яндекс, Фейсбук, Гугл, и др.
Получается провайдер должен один шифровать весь этот трафик как со стороны всех клиентов, так и со стороны всех этих сервисов, но если шифрование будет возложено на конечные точки, то каждый клиент сам защищает только свои данные и каждый сервер обрабатывает только свои данные, что очень похоже на "распараллеливание".

Т. е. функция провайдера сводится к "трубе (например водопроводной)" - просто маршрутизировать сетевые пакеты, не обрабатывая их.

Как Вы считаете, я не ошибаюсь?