VPN: зачем и как скрывать свой IP и шифровать трафик. DNSCrypt — шифрование DNS трафика для параноиков
Широко известному в узких кругах Денису Карагодину попытались« улучшить» домашние интернет-устройства. Как написал сам Карагодин, ему позвонил томский провайдер и заявил, что из квартиры идёт« негативный трафик», после чего попросил принять дома специалиста. После беседы с этим гостем выяснилось, что провайдер хотел бы получить доступ к компьютеру Карагодина и войти в его домашнюю локальную сеть. Ещё до визита Карагодин обратил внимание, что: «несколько недель назад начались проблемы с обычным интернетом. Браузер жаловался на сертификаты, сайты не отображались корректно или не открывались вообще. Но если включаешь VPN, то становилось всё нормально».
Складывалось такое впечатление, что кто-то снифит трафик(причем еще и фильтруя его)(как будто стоит какой-то или буфер, или трестируется некая новая СОРМ-система).
Гость пытался воспользоваться компьютером Карагодина или войти в Wi-Fi, чего хозяин не разрешил, и не захотел подключить провайдерский кабель к собственному оборудованию, чтобы проверить« как идут пинги». В итоге Карагодин порекомендовал специалисту обращаться в управление« К» МВД России или ФСБ, где профессионально расследуют интернет-правонарушения. И объяснил, что с шифрованными пакетами провайдеру придётся смириться. Работать через VPN Карагодину удобнее.
сайт: 21 июля Госдума в третьем чтении закон о запрете обхода блокировок через VPN и анонимайзеры, но готовящийся к введению документ не касается абонентов. По закону анонимайзеры и VPN-сервисы должны так же как операторы связи ограничивать доступ к запрещенным в России сайтам — в этом случае никаких претензий власти к ним не возникнет. Если же сервисы не сотрудничают с РФ — доступ к ним блокируется провайдерами Рунета, а ссылки на соответствующие сайты должны быть удалены из выдачи на поисковиках.
Рассказ Дениса Карагодина полностью:
Новости такие. Позвонил интернет-провайдер. Говорит, что какой-то у вас« негативный трафик» идет. Нужно проверить. А «негативный трафик» — это мой шифрованный канал VPN. В ходе беседы выясняется, что они хотят получить доступ к моему макбуку… Ну, что ж… Посмотрим. Приезжайте говорю в назначенное время, обсудим суть вопроса. Через пару часов приедут.
Итак. Расклад такой. Утром звонок от провайдера. Якобы от вас(из одного из устройств, подключенного к интернету) идет« негативный трафик». Уточняю какое именно устройство. Выясняется, что мой макбук(хотя устройств несколько). Дальше идет попытка убедить меня, что мой компьютер взломан и с него осуществляется атака на оборудование провайдера. Рекомендуют принять сотрудника и он порекомендует какую именно следует поставить антивирусную программу. Я спрашиваю, что т.е. получается вы хотите получить доступ к моему компьютеру? Ответ — нет(откровенно смутившись), просто мы хотим, чтобы ушел негативный трафик и на нас(на наше оборудование) не было атаки. Поступает предложение продиагностировать всё удаленно. Я соглашаюсь. Через секунды 4 звонящий говорит, ой, у вас же макбук, так не получится… Давайте сотрудник приедет. Я соглашаюсь — делаю лаг времени, чтобы собрать немного данных о собственном трафике(он в полной норме, никаких ддосов и пр.). В итоге приезжает сотрудник от провайдера, говорит, что по моей заявке(но я как вы понимаете никакую заявку не оставлял). Начинает с порога просить дать доступ ко всем устройствам и сети домашней. Я переспрашиваю, а в чем собственно дело? Т.е. вы говорю хотите получить доступ ко всем устройствам моего дома, подключенных к интернету? Он говорит — да, так он сможет посмотреть все ли в порядке. Я ему говорю, что у меня всё в полном порядке и я не понимаю в чем проблема. Тут он говорит, что ему сказали, что есть некий ноутбук, и у него много пакетов и что они странные. Я ему отвечаю, что да есть в том числе и мой макбук и там много пакетов, т.к. я много им пользуюсь. И если например вы видите какие-то шифрованные пакеты, то это просто VPN. Он делает попытки получить к нему доступ, а также доступ просто в Wi-Fi сеть… Я всё на корню пресекаю. Говорю ему: если вам нужно проверить интернет(а он хотел проверить« как пинги идут»), то я сейчас просто дам вам кабель ваш который у меня в роутер идет и вы его себе воткнете и посмотрите пинги… Он начинает неврничать. Я ему говорю — вы наверное ifconfig хотите посмотреть? Он краснеет и говорит, что ну он же мой(т.е. его) покажет… В итоге я ему РАЗЪЯСНЯЮ, что если он(провайдер) считает, что с одного из устройств(в частности моего макбука) идет атака на их оборудование(хотя ее нет), то им следует подать официальное заявление в Управление« К» МВД России или ФСБ России и там разберутся(была ли атака и есть ли она). А если вы видите на своей стороне, что идут шифрованные пакеты, так это от того, что у меня стоит VPN и мне крайне это удобно. Далее идет еще минут 5 перепалка(с попыткой давления на меня). В итоге, он разворачивается и уходит. Я был вежлив и неуклонен. Если есть подозрение, что я осуществляю кибер-атаку на оборудование провайдера — пишите заявление в Управления« К» МВД или ФСБ России, а если нет, то мои устройства(компьютеры, мобильные телефоны и чайник с Wi-Fi — это моя личная собственность; включая и развернутую домашнюю сеть) и никого кому я не хочу давать к ним доступ, я его давать не намерен. Это говорю все равно, что сейчас придет человек из водоканала и попросит меня дать ему покупаться в моей ванной, т.к. ему кажется, что вода по трубе как-то не правильно идет. Человек явно не ожидал, что его в управление« К» отправят. Спросил подтвержу ли я все сказанное по телефону, если мне позвонит его начальство, я сказал что конечно и что он сам может в подробностях передать наш разговор.
В общем, держу цифровую оборону! ¡No pasarán!
Термин« негативный трафик» — терминология интернет-провайдера(озвучено при разговоре со мной); звучит красиво, до этого я никогда и нигде его не встречал и о нем не слышал(с учетом того, что в Сети я с 1993 года) {о реферальном спаме конечно же знаю, но это« оказался» не он}; век живи — век учись {ирония}.
Причем, важно отметить, что изначально(теоретически) я допускал возможность наличия некой технической проблемы, т.к. в мою локальную сеть включен и мой внешний веб-сервер [сайты: karagodin.com, stepanivanovichkaragodin.org]. Именно по этой причине я детально и пытался уточнить у провайдера, о каком именно« проблемном» устройстве идет речь? Но, когда выяснилось, что« проблема» именно в моем личном ноутбуке, то тут уже стало всё совсем интересно и интригующе!
Но, у истории есть предистория.
Несколько недель назад я начал отмечать странности с обычным интернетом. Складывалось такое впечатление, что кто-то снифит трафик(причем еще и фильтруя его)(как будто стоит какой-то или буфер, или трестируется некая новая СОРМ-система). Например, некоторые сайты не грузились(причем сегментно, тематически), либо грузились частично(битыми блоками, с потерей части.css-стилей и т. п.), почтовые программы при этом начинали жаловаться на проблемы с подлинностью сертификатов соединения и пр. Но, стоило включить VPN, как все эти непонятные технические сбои мгновенно пропадали. При этом, работа моего веб-сервера(у него свои порты) была всегда в полном порядке. Проблемы были именно на уровне рядового устройства, подключенного к роутеру и пытающегося выйти во внешний интернет.
---
// копия в телегам-канале: t.me/karagodincom/40
// тема ведется в блоге: karagodin.com/?p=4295
В версии протокола Server Message Block (SMB) 3.0 , представленном в Windows Server 2012 / Windows 8, появилась возможность шифровать данные, передаваемые по сети между файловым сервером SMB и клиентом. Шифрование SMB трафика позволяет защитить от перехвата и модификации данные, передаваемые по недоверенной или открытой сети. Шифрование данных выполняется прозрачно с точки зрения клиента и не требует существенных организационных и ресурсных затрат, как при внедрении VPN, IPSec и PKI инфраструктуры. В последней версии протокола SMB 3.1.1 (представлен в Windows 10 и Windows Server 2016) используется тип шифрования AES 128 GCM, а производительность алгоритма шифрования существенно увеличена. Кроме того осуществляется автоматическое подписывание и проверка целостности данных.
Разберемся в особенностях внедрения шифрования SMB в Windows Server 2012. В первую очередь нужно понять, что в том случае, если клиент и сервер поддерживают разные версии протокола SMB, то при установлении подключения между сервером и клиентом, для взаимодействия выбирается самая высокая версия SMB, поддерживаемая одновременно клиентом и сервером. Это означает, что все клиенты с ОС ниже Windows 8 / Server 2012, не смогут взаимодействовать с сетевым каталогом, для которого включено шифрование SMB.
На файловом сервере можно получить версию протокола SMB используемого тем или иным клиентом (версия используемого протокола выбранного в рамках соединения указаны в столбце Dialect):
По-умолчанию, на файловом сервера Windows Server 2012 шифрование для передачи SMB трафика отключено. Включить шифрование можно как индивидуально для каждой SMB шары, так и для всего сервера целиком.
Если нужно включить шифрование на конкретного каталога, на сервере откройте консоль Server Manager и перейдите в раздел File and Storage Services –> Shares . Выберите нужную общую папку и откройте ее свойства. Затем перейдите на вкладку Settings , где включите опцию Encrypt Data Access . Сохраните изменения.
Кроме того, включить SMB шифрование можно из консоли PowerShell. Включаем шифрование для одной папки:
Set-SmbShare –Name Install -EncryptData $true
Либо для всех SMB подключений к серверу (будь то общие папки или административные ресурсы):
Set-SmbServerConfiguration –EncryptData $true
После включения SMB шифрования для общей сетевой папки, все устаревшие клиенты (до Windows 8), не смогут подключаться к данному каталогу, т.к. не поддерживают версию протокола SMB 3.0. Чтобы разрешить доступ таким Windows клиентам (как правило, такой доступ организуется временно, иначе теряется смысл от включения шифрования), можно разрешить подключаться к серверу без шифрования:
Set-SmbServerConfiguration –RejectUnencryptedAccess $false
Совет
. После включения данного режима, подключающийся клиент в процессе согласования поддерживаемой версии протокола сможет переключится на совсем устаревшую версию SMB 1.0, что не безопасно (в Windows Server 2012 R2 ). В этом случае, чтобы хотя бы частично обезопасить сервер, желательно отключить поддержку SMB 1.0:
Set-SmbServerConfiguration –EnableSMB1Protocol $false
Национальный антитеррористический комитет собирается контролировать зашифрованный трафик в Сети. Представители отрасли опасаются, что это может привести к утечке персональных данных и войти в противоречие с Конституцией.
Руководитель Роскомнадзора Александр Жаров рассказал о том, что в рамках Национального антитеррористического комитета России (НАК) была создана специальная рабочая группа. Её цель - «внесение ясности в происходящее внутри шифрованного трафика» и создание мер по его регулированию.
В группу вошли представители всех силовых ведомств, Минэкономразвития, Минкомсвязи и отраслевые эксперты из Российской ассоциации электронных коммуникаций (РАЭК). Глава Роскомнадзора отметил, что немецкая корпорация (название её не разглашается в связи с коммерческой тайной) разработала метод сегментации шифрованного трафика и предоставила его на рассмотрение рабочей группе.
Группа была создана по поручению Совета безопасности России. По словам Вадима Ампелонского, представителя Роскомнадзора, она должна предоставить Совбезу отчёт о проделанной работе не позднее 1 июля 2016 года. Специальная группа при НАКе ведёт работу по регулированию сервисов, использующих для передачи данных беспроводные сети, а также тех, которые способны работать без подключения к Интернету (мессенджер FireChat, прославившийся после использования демонстрантами в Гонконге в 2014 году). Глава Роскомнадзора обеспокоен использованием подобных сервисов:
«Злоумышленники могут воспользоваться тем, что вне сети можно обмениваться информацией, и применить это для распространения наркотиков, детской порнографии и т.д.».
В феврале 2015 года Жаров говорил, что доля шифрованного трафика в России составила 15%, а в мае 2016 года она может превысить 20%. Согласно отчету компании Cisco по информационной безопасности за 2015 год, объём шифрованного трафика Рунета составляет до 50%. Карен Казарян, главный аналитик РАЭК, говорит, что большая его часть приходится на протокол HTTPS. По словам экспертов, в мире доля шифрованного трафика в сервисах корпораций превышает 75%, и 81% приходится на территорию России.
Андрей Поляков из «Ростелекома» говорит, что их сети принадлежит около 50% шифрованного трафика (представители «Ростелекома» являются участниками рабочей группе при НАКе).
По словам руководителя Роскомнадзора, речь идет о шифрованном трафике, как легальном (в браузерах и других программах), так и нелегальном (способы обхода блокировок: прокси-серверы, анонимайзеры и т.д). По его словам, обсуждается «введение единой системы шифрования, чтобы понимать, что происходит внутри шифрованного трафика». Участники группы решают вопросы, связанные с применением различных средств шифрования: их сертификацией, лицензированием, ограничением количества схем шифрования.
Мессенджер Павла Дурова Telegram уже несколько лет осуществляет шифрование данных по модели end to end (E2E - система, в рамках которой, зашифрованная информация передается от устройства к устройству напрямую, без посредников. Правила закрытого ключа не позволяют расшифровать информацию никому, кроме её получателя. Таким образом, зашифровка и расшифровка сообщений происходят без участия сервера-посредника).
В начале апреля 2016 года мессенджер WhatsApp (принадлежащий Facebook) ввел полное шифрование всех своих сервисов для всех пользователей (мессенджер шифрует сообщения, телефонные звонки, фото и видео. Теперь даже сотрудники WhatsApp не смогут расшифровать данные, передаваемые пользователями).
19 апреля мессенджер Viber усилил систему безопасности данных с помощью введения end to end шифрования для всех устройств, включая компьютеры PC и Mac, а также смартфоны и планшеты на платформах Android и iOS.
Жаров считает, что данную модель (Е2Е) можно «частично заменить» технологией, аналогичной Deep Packet Inspection (DPI — технология "глубокого анализа" трафика через накопление статистических данных, проверку и фильтрацию сетевых пакетов по их содержимому).
Чиновник упомянул, что сегментация трафика нужна и операторам связи. Так он советует отдать приоритет голосовому трафику: для извлечения денежной прибыли за платные услуги, которые он предоставляет, за счёт других видов трафика.
«Или трафик торрентов, который находится в условно легитимном поле», - говорит он.
Представитель одного из операторов связи прокомментировал это так:
«Шифрование может проводиться программными средствами, свободно распространяемыми в Интернете. Проконтролировать этот процесс представляется возможным, только если поставить на каждое конечное устройство по жучку и дистанционно постоянно мониторить работу».
Он выразил мнение о том, что само рассмотрение вопроса о контроле шифрования в сетях связи относится к области нарушения конституционных прав граждан.
Станислав Шалунов, сооснователь Open Garden (компания-разработчик FireChat) считает, что российские власти не понимают природу вещей, которую собираются контролировать. Он говорит, что смысл шифрования заключается в том, что трафик способны прочесть только отправитель и получатель. Шалунов отметил, что регулировать подобный трафик не предоставляется возможным с технической точки зрения и сравнил это с невозможностью распространения звука в космосе.
«И сей факт не сможет изменить создание рабочей группы по вакуумной акустике», - добавил он.
«Трафик приложений типа FireChat не только зашифрован - он не всегда идёт через традиционных провайдеров, поэтому пытаться его каким-то образом контролировать является абсурдом в квадрате», - заключил сооснователь Open Garden. По его мнению, контроль шифрованного трафика Интернета приведёт лишь к утечке информации и распространению махинаций, связанных с этим.
Казарян также считает, что «регулирование шифрования не требуется, более того, с большой вероятностью оно приведет к увеличению киберугроз и утечкам персональных данных граждан».
Жаров понимает, что запретить шифрованный трафик полностью невозможно, так как он абсолютно необходим, например, для хранения банковской тайны и другой личной информации. Поэтому рабочая группа не ставит перед собой цель ужесточить контроль над интернетом, а «лишь найти пути для решения проблем, связанных с его бесконтрольностью».
По его прогнозам, конкретные технологические и законодательные подходы для регулирования шифрованного трафика появятся приблизительно через два года.
Жаров приводит в пример США и страны Европы, в которых разрабатываются аналогичные подходы к регулированию шифрованного трафика. «Там происходит адаптация массового продукта под запросы конкретного потребителя путем его частичного изменения (доукомплектования товара дополнительными элементами); активно обсуждается вопрос сертификации конечного оборудования», - говорит он.
Для государства контроль шифрованного трафика является одним из способов борьбы с терроризмом, экстремизмом и киберпреступностью.
6 декабря 2008 в 17:43Безопасность (шифрование) трафика
- Информационная безопасность
Параллельно с развитием технологий защиты интернет-трафика от несанкционированного доступа развиваются и технологии перехвата защищенного трафика. Перехватить и изучить незашифрованный трафик пользователя уже давно не составляет труда даже для рядового юзера. Практически каждому известно слово «сниффер». Теоретически, защищенные SSL /TSL -соединения перехватить обычными средствами невозможно. Но так ли это?
На самом деле - не совсем так. Да, зашифрованный трафик теоретически невозможно расшифровать, хотя опять таки теоретически при очень большой необходимости и желании, и такой трафик можно расшифровать, подобрав ключ. Однако для этого нужны такие затраты ресурсов, что актуальность взлома сохраняется только, наверное, на правительственном или военном уровне:)
При работе по защищенному соединению (самый просто пример - ) весь трафик между взаимодействующими точками в сети шифруется на стороне отправителя и дешифруется на стороне получателя. Шифруется трафик, идущий в обоих направлениях. Для того, чтобы его зашифровать и расшифровать нужна пара ключей (ассиметричное шифрование). Публичный ключ служит для зашифрования и передается получателю данных, а приватный - для дешифрования, он остается у отправителя. Таким образом, узлы, между которыми устанавливается SSL-соединение, обмениваются публичными ключами. Далее, для повышения производительности формируется единый ключ, который пересылается уже в зашифрованном виде и используется как для шифрации, так и для дешифрации на обеих сторонах (симметричное шифрование).
А как они это делают? Обычно - по тому же каналу, по которому далее будет идти защищенный трафик. Причем обмен ключами происходит в открытом режиме. В случае HTTPS ключ сервера связан с сертификатом, который пользователю предлагается просмотреть и принять. И вот этот сертификат как раз и может перехватить любой промежуточный сервер, на пути которого идет сертификат в открытом виде (прокси, роутер).
Чтобы далее «читать» весь трафик пользователя, промежуточный сервер подменяет сертификат на свой. Т.е. он просто сам подключается к клиенту со своим сертификатом, и в то же время подключается к удаленному серверу. Клиенту приходит «левый» сертификат от сервера-злоумышленника, а браузер сообщает пользователю об опасности (такие сертификаты всегда не подписаны). У пользователя остается выбор: принять сертификат и работать с сайтом, либо отказаться его принимать, но и работать с сайтом тогда уже не получится. Иногда пользователи вообще игнорируют содержимое сертификатов и машинально принимают любые переданные им.
Если пользователь принимает сертификат-подделку, то трафик будет идти по следующей схеме:
клиент <= SSL-соединение => сервер-прослушка <= SSL-соединение => сервер назначения
Т.е. промежуточный сервер будет получать весь ваш «защищенный» трафик в открытом виде. Стоит также заметить, что передача сертификата происходит в начале каждой сессии HTTPS.
В случае защищенного SSH при первом соединении с сервером на клиенте сохраняется ключ сервера, а на сервере - ключ клиента. Эти ключи передаются между данными клиентом-сервером только один раз, при первом подключении. Если в этом случае SSH-трафик попытаются перехватить, то и клиент, и сервер откажут в соединении из-за несоответствия ключей. Так как ключи можно перенести между клиентом и сервером обходным путем (по защищенному каналу или на внешнем носителе), этот способ соединения является относительно безопасным. Его могут лишь заблокировать, заставив пользователя работать в открытую.
Стоит отметить, что уже давно продаются так называемые «решения по информационной безопасности предприятия», которые перехватывают весь трафик, проходящий через офисный прокси-сервер, и «читают» его. Программы ищут наличие определенных фраз или информации определенного вида в потоке данных от браузеров, почтовых программ, ftp-клиентов, мессенджеров сотрудников офиса. Причем, эти программы умеют различать и обрабатывать правильно самые разные виды информационного взаимодействия с серверами. В том числе, они проверяют и защищенный SSL-трафик путем подмены сертификатов. С разработкой одной из таких систем я сталкивался почти непосредственно.
Но пути спасения от тотальной слежки есть. Через установленное SSH-соединение можно направлять любой нужный трафик, который с SSH-сервера будет уже в открытом виде идти на конечную точку. Этот способ называется SSH-туннелинг (tunneling). Так можно обезопасить прохождение трафика по незащищенному каналу, но имеет смысл такой подход только при наличии доверенного сервера с поднятым и настроенным на туннелинг SSH-демоном. Причем организовать это достаточно просто. SSH-клиент подключается к серверу, настраивается на прослушку любого данного порта на локальной машине. Этот клиент будет предоставлять услугу SOCKS5-прокси, т.е. его использование можно настроить в любом браузере, почтовых программах, IM-ах и т.д. Через SSH-туннель пакеты попадают на сервер, а с него уходят на целевой сервер. Схема получается следующая:
<== SSH-соединение ==> сервер <=> целевой сервер
Другой способ защиты трафика - VPN -канал. В использовании он проще и удобнее SSH-туннелинга, но в первичной установке и настройке сложнее. Основное удобство этого способа в том, что в программах не нужно прописывать прокси. А некоторый софт и вовсе прокси не поддерживает, следовательно только VPN и подойдет.
На практике есть два варианта работы. Первый - покупка VPN-акканута, который продается специально для этих целей (шифрование трафика по небезопасному каналу). В этом случае продаются обычно аккаунты, соединяться с которыми надо по протоколам PPTP (обычный VPN, который реализован, например, в Windows) или L2TP.
Второй вариант - покупка VDS-сервера (виртуальный выделенный сервер) с любым дистрибутивом линукса на борту и поднятие на нем VPN-сервера. VDS может быть российским или американским (только не забывайте про заокеанские пинги), дешевым (от $5) и слабым или дорогим и помощнее. На VDS ставят OpenVPN -сервер, а на компьютере поднимается OpenVPN-клиент. Для Windows есть даже гуишная версия клиента .
Если вы решите использовать вариант с OpenVPN, то есть например эта простая пошаговая инструкция по поднятию сервера (Debian). Установить клиента еще проще, особенно под Windows. Отметить стоит только один нюанс. Если весь трафик требуется пустить по созданному VPN-соединению, то требуется прописать default gateway на шлюз VPN (параметр redirect-gateway в конфиге клиента), а если только часть трафика (на определенные хосты), то можно прописать обычные статические маршруты на данные хосты (по IP; например, route add -p 81.25.32.25 10.7.0.1).
Для соединения OpenVPN обмен ключами происходит в ручном режиме, т.е. транспортировать их от сервера на клиент можно абсолютно безопасно.
Таким образом, SSH- и VPN-соединения могут практически полностью гарантировать безопасность вашего трафика при перемещении по незащищенному каналу. Единственная проблема, которая может возникнуть в этом случае, - это запрет на SSL-трафик на корпоративном файрволе. Если SSL-трафик разрешен хотябы на один любой порт (обычно дефолтный 443), то вы уже потенциально можете поднять и SSH-тонель, и VPN-соединение, настроив соответствующего демона на вашем VDS на этот порт.
Теги:
- internet
- security
- ssl
День добрый. Сегодня я расскажу вам об одном виде паранойи, связанном с последними тенденциями в сфере защиты государством населения от информации, и методе его лечения.
Мир цензуры
Дело в том, что в последнее время началось активное распространение роскомнадзоров, СОРМов, золотых щитов, корневых сертификатов, черных фургонов ФБР и прочих методов прослушки/ограничения/подмены трафика во всеми любимой сети Интернет.
На фоне этого, у многих началась болезнь, прекрасно описываемая фразой «у стен есть уши». И было бы это без повода - но все ваши данные идут через маршруты, вам неизвестные, через черные коробки, вам не принадлежащие, сервера, вами не контролируемые, а скоро это все будет еще и сохраняться. Ну как тут не занервничать?
Говорят, шифрование всех спасет. Но так ли это? Опуская проблемы классической и современной криптографии, так или иначе, шифрованный трафик всегда можно относительно просто обнаружить и банально прикрыть канал передачи. И тут на помощь приходит стеганография.
Чтобы проникнуться и понять, зачем оно нам, посмотрим на классическую схему передачи трафика от Алисы к Бобу в интернете:
Учтем, что интернет и каналы связи в нем нам неподконтрольны и уязвимы by design. Более того, между Алисой и Бобом есть некто, контролирующие среду передачи и ( /вставьте свое слово) их обмен сообщениями.
На самом деле, передача через данных через интернет все больше напоминает проблему заключенных.
А схема выглядит так:
Где Вилли - не садовник, как кажется на первый взгляд, а охранник, ограничивающий передачу любых сообщений к Бобу. Алиса же - свободный человек (или заключенный в другой камере), с которым Боб хочет общаться в обход охранника.
Соответственно, задача стеганографии в том, чтобы охранник просто не замечал обмена сообщениями. А кто именно является охранником - ркн или фургончик фбр - частные случаи.
А при чем здесь прокси?
- Боб - это ПО на контролируемом устройстве, через которое очень хочется свободного обмена информацией, вне зависимости от его положения в мире.
- Вилли - это злые провайдеры, регулирующие органы, корпоративные прокси-сервера и прочие, желающие этому обмену помешать.
- Алиса - это шлюз, через который мы получаем информацию из внешнего (или другого внутреннего) мира.
В зависимости от ситуации, между Алисой и Бобом может быть как контролируемый Вилли канал связи, так его (канала) может и не быть в принципе. Правды ради, стоит отметить, что мало кто полностью обрезает каналы связи, и даже за великим файероволом можно при желании посидеть в фейсбуке. Так что этот случай будет первый и простой вариант.
Стеганографический канал тогда будет создаваться просто поверх заранее известного канала, подконтрольного Вилли. Рассмотрим в качестве примера реализацию с использованием обычных сокетов.
Стегоканал создается подключением Боба к Алисе через сокет на установленном заранее порту.
Получившаяся схема отличается простотой и надежностью. Но, это не совсем стеганография. Для Вилли вполне очевидно, что обмен картинками на нестандартных портах - неспроста. Частично можно снизить уровень подозрительности, используя стандартные порты и протоколы. Например, обмен файлами через FTP. В целом, один из самых быстрых и удобных вариантов. Можно пользоваться, пока градус неадеквата и подозрительности со стороны Вилли не очень высок.
А теперь представим, что Вилли запретил обмениваться Бобу сообщениями с Алисой. Вообще.
Тогда для создания стеганографического туннеля (канала без прямой связи) необходим ресурс с общим доступом. Классическим примером являются социальные сети - доступные из большинства точек мира, публичные. Идеальный вариант для обмена стеганограммами, не совсем подходит для прокси ввиду необходимости большого потока информации. Однако, секъюрность требует жертв. В данном случае, жертвой падет скорость, но об этом чуть позже. Рассмотрим реализацию с использованием ВК в качестве общедоступной среды обмена:
Эта схема полагается на сторонний сервис, а значит, полностью зависит от него. С другой стороны, обмен картинками между пользователями не вызывает никаких подозрений, даже с высокой частотой (боты, по большей части, легальны). Из минусов получаем пониженную пропускную способность и возможность оказаться без линии связи в нужный момент - если обычно запасной канал является опциональным, то тут это обязательное условие работы.
А теперь о самой реализации и том, что вышло
Боб реализован в виде обычного прокси-ретранслятора типа , слушающего определенный порт. Все данные, поступающие на него, он прячет в стегоконтейнеры с использованием заранее обговоренного алгоритма и посылает по стегоканалу Алисе. Все операции записи и извлечения проводятся с установленным заранее секретом (в стеганографии, в принципе, можно и без него, ограничений на реализацию нет).
Алиса типа принимает весь трафик от Боба по стегоканалу, извлекает его из стегоконтейнеров и перенаправляет на настоящий прокси сервер, который вы хотите использовать, выделяя для каждого экземпляра стегоканала отдельное подключение к прокси (чтобы не было путаницы). Ведь кто знает заранее, что за трафик и зачем понадобится пересылать, верно?
И как оно работает?
Для тестирования, в качестве прокси-сервера я арендовал дешевый ARM-сервер во франции, развернул на нем Ubuntu 16.10 и на ней Squid вместе с ретранслятором. Все замеры проводились из дома с интернетом на 5 Мбит/с через ADSL национальнейшего русского провайдера. Если кто-то хочет проверить на нормальной скорости - в конце оставлю ссылки на GitHub.
В качестве proof of concept я реализовал стегоканал поверх сокетов. Если будет интерес - аналогичное тестирование проведу и для реализации с VK в качестве среды обмена. В качестве алгоритма - свой собственный вариант метода LSB с максимальной емкостью примерно в четверть байт от общего числа пикселей, работающий с изображениями без сжатия, о котором, возможно, напишу позже. В качестве контейнера сначала использовалось одно единственное изображение Че Гевары в png разрешением 518х587.
Результаты тестирования в качестве прокси в firefox без каких-либо плагинов и доп. настроек:
- wikipedia.org - 1:13;
- en.wikipedia.org - 2:01, после этого общение с сервером продолжается, но контент весь уже загружен;
- google.com (.fr) - ~2м, подсказки не работают, поисковая выдача грузится по минуте;
- duckduckgo.com - так и не загрузился в течение 10 минут;
- txti.es - ~3с на страницу. И правда, fast web pages;
- garfield.vexer.ru - 1:35. Реклама при этом не загрузилась (и адблок не нужен);
- reddit.com - грузится очень долго (больше 10 минут), что-то загружает, но терпения у вас вряд ли хватит;
- bing.com - 1:45 на полную загрузку. ~50 секунд на страницу поисковой выдачи;
- jcgonzalez.com - не загрузился;
- minergate.com - 4м;
- vk.com - ~1м, изображения догружаются дольше, диалоги работают шустро;
- linkedin.com - ~50c, но громадное изображение-фон будет грузиться еще долго;
- weather.com - не загрузился;
Стоит заметить, что подобные скорости (очень скромные, особенно, если посмотреть на календарь) объясняются не только тем, что стеганография передает избыточное количество информации, но и накладными расходами на сам стеганографический алгоритм. А ожидать от ARM-сервера за 3 зеленых президента чего-то необычного в плане производительности было бы странно. Аренда болеее быстрого сервера дает сильное ускорение (раза в 2 на старом слабом х86 сервере).
Отключив изображения и медиа-элементы, включив адблок, скорость можно повысить. Переместившись таки методом на лет 10 (15?) назад, получаем соответствующую тому же времени скорость загрузки страниц. Но в целом, вывод остается тем же - такое стеганографическое прокси годится только для экстренных случаев.
Впечатления от такого интернета далеко не положительные. Возможно, с другими методами стеганографии, или просто оптимизируя мой, можно добиться больших результатов. Однако, пока что, получившийся Proof of Concept говорит лишь о том, что такое прокси годится только для экстренных случаев. Что, на самом деле, не особо удивительно. Или неожиданно. Большая часть проблем с задержками - тайминги при рукопожатии в ssl. Вот вам и повсеместное насаждение https.
Подумав, было решено заменить бедного статичного Че Гевару на случайные изображения с минимальной избыточностью. Ведь если передавать не в 16 раз больше информации, а в 4, то теоретически, получим приятный бонус к скорости. Благо, генераторов случайных изображений заданного размера в интернете полно.
Результаты при повторном тестировании:
- wikipedia.org - 21с;
- en.wikipedia.org - 21с;
- google.com (.fr) - 23с до работоспособности, 45с до полной загрузки, 3с на выдачу;
- duckduckgo.com - 45с до работоспособности, 55с до полной загрузки;
- txti.es - мгновенно;
- garfield.vexer.ru - 1:10 вместе с рекламой, последующие стрипы грузятся секунд по 10, так как все самое тяжелое уже в кеше;
- reddit.com - 44с без контента, 1:20 с его превью;
- jcgonzalez.com - упал, но 404 выдает быстро;
- minergate.com - 1м;
- vk.com - 23c, страницы с сообщениями по секунд 10 и больше, в зависимости от содержимого;
- linkedin.com - 40c;
- weather.com - не загрузился;
С таким интернетом жить уже можно, особенно, если мало альтернатив. Стеганографическая стойкость падает с повышением отношения шум/полезная информация, жертвовать или нет - решать не мне.
На этом считаю эксперимент завершенным. Исходники, бинарники, инструкции по применению и помощи находятся на гитхабе ниже. Если будут дополнительные вопросы - буду ждать в комментариях.
Last updated by at Январь 12, 2017 .
