cat_mucius

О блин. Мечтал, как бы организовать контроль исходящего трафика для удалённых виртуальных десктопов - а решение, хоть и неудобное, валялось под носом. Обыкновенный "Windows Firewall with Advanced Security", что на каждой винде стоит, умеет разрешать или запрещать открываемые соединения в зависимости от личности юзера, в том числе и по группам в Active Directory.



То есть можно приготовить GPO со всеми правилами - скажем, только группа OURDOMAIN\SQL_Admins может подключаться к серверам баз данных - приложить его к OU с машинами, входящими в пул удалённых дескпотов, и готово.

Недостатки:

- Невозможность задавать destinations, к которым открываем или закрываем доступ, иначе чем по IP-адресам или IP-диапазонам. Никаких имён или тем более групп, которых можно было бы использовать в множественных правилах, тут вам не чекпойнт и не фортигейт, всё примитивно как оглобля. Даже по именам DNS не задашь. Омерзительно. :-(

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

Кстати, идея для стартапа: сервис с графическим интерфейсом, позволяющий задавать объекты для хостов и сетей, объекты для сервисов, группы объектов с любой степенью вложенности, в общем, всё как мы любим - и генерящий на выходе такие вот GPO для Windows Firewall.

Спросили меня насчёт интервью, которое дал украинскому сайту "Гордон" какой-то бизнесмен Михаил Талан, утверждающий, что российские спецслужбы рутинно проводят массовую "man-in-the-middle" атаку на TLS-соединения российских пользователей.


– Каким образом россиянам удалось вставить туда "посредника" и считывать зашифрованный трафик?
– Подсунув подменный SSL-сертификат в веб-браузер. Подчеркиваю: именно подменный, а не поддельный. SSL-сертификат – это технология аутентификации, которая, если вы открываете Google, говорит веб-браузеру: да, это точно Google. Подделка SSL-сертификата – это, по сути, базовая хакерская атака, а вот подмена – это базовая функция того, кто этот сертификат продает. Подмена доступна исключительно официальному органу, и делается это на основании запроса и, как правило, "для борьбы с терроризмом".
...
В головах у интернетчиков бытует мнение – поддельный SSL-сертификат не сработает. А я еще раз говорю: не поддельный, а подменный, и он выдается корневым центром сертификации по запросу государства для борьбы с терроризмом. Понимаете? Они опять "продают" идею борьбы с терроризмом. Они таким образом заставили всех выдать им сертификаты, но встала вторая проблема – как их встроить в трафик.

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

Чисто технически в этом ничего невероятного нет, о чём я и писал уже давно (1, 2) - государство действительно может добиться от CA такого сертификата, такую подделку действительно тяжело засечь, поскольку практически все поля в поддельном сертификате будут идентичные настоящему, кроме публичного ключа и его хэша. Смену сайтом публичного ключа можно засечь - см. HTTP Public Key Pinning - но она может произойти и по совершенно нормальным причинам, к тому же разные сервера, на которых хостится сайт, могут одновременно иметь разные сертификаты с разными ключами, да и использовал HPKP очень мало кто.

Но вот политически звучит это невероятно. То, что ключи американских центров сертификации есть у NSA, меня не удивит нисколько - но вот какой смысл им делиться ключами с Россией? Своё же собственное государство по головке не погладит за подобную работу на потенциального противника. Далее, даже если у фирмы, скажем, Digicert от российских денег в зобу дыханье спёрло и они решили продать ФСБ сертификат с включённым флагом "CA" - это означает для них страшнейшую игру с огнём, поскольку один доказанный случай MiTM-атаки с их помощью - и вся их репутация сгорает на корню, а репутация - это в принципе единственное, чем CA торгует, без неё он нафиг никому не нужен. А уж содействовать не просто каким-то очень выборочным атакам на определённых людей, а массовому перехвату в масштабах страны - это просто чистое безумие.

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

Наконец, такой перехват очень легко сдетектировать при наличии собственного заграничного сервера - скажем, виртуальной машины в любом зарубежном облаке, что вовсе не такое уж разорительное дело. Помимо HPKP, могу назвать два способа:

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

2. А вот второй: штука под названием cryptobinding / channel binding. Идея в следующем. Допустим, мы устанавливаем с сервером соединение по TLS, и затем запускаем с ним какой-то протокол аутентификации - скажем, Kerberos, NTLM или EAP. Пускай он использует обычные пароли. Но помимо зашифрованных паролей, мы с ним обмениваемся ещё и некоторыми контрольными суммами, удостоверяющими, что мы с сервером используем общие ключи для TLS - иными словами, и клиент, и сервер соединены прямой "трубой" TLS-соединения.
Если между нами вклинится перехватчик, пускай и с самым безупречным сертификатом, это уже будут две "трубы" - от клиента до перехватчика, и от перехватчика до сервера. Суммы не сойдутся и протокол аутентификации провалится.
В обычном IIS, включённым во всякую винду, эта фича существует под названием "Extended Protection for Authentication" и включается парой движений мышкой.

Ну и добавлю, что если бы массовый перехват происходил, то Талану было бы очень легко привести пример типа "зайдите на https://mail.google.com через российского провайдера и через украинского и сравните ключи". Пользу он этим принёс бы огромную, однако ж страшные глаза он делает, а конкретикой не балует. Самая крутая конктретика там такая:

Я попросил своего друга в Карелии поучаствовать в эксперименте, а именно: он поехал в приграничную зону с ноутбуком, пересек границу, купил финскую сим-карту, вставил ее в телефон и вернулся в Россию. Дальше он взял ноутбук, подключился к интернету через российскую сим-карту, зашел в Facebook, сделал скриншот ленты. После он перегрузил компьютер, сбросил кеш в браузере и зашел в Facebook, используя интернет финской сим-карты. Опять сделал скриншот. И это оказались две абсолютно разные по содержанию ленты, хотя пользователь один и тот же.

Holy Mother of God. :-) Если я в фейсбуке на F5 нажму, то тоже получу две разные по содержанию ленты, алгоритм фейсбука так работает. :-)


- Американцы отменили 35 организациям SSL-сертификаты. Это невероятно. Я, признаться, не верил, что США отменят SSL-сертификат Федеральной службе безопасности РФ. Но они отменили. Зайдите на официальный сайт ФСБ или Кремля, например. Что вы видите рядом с адресной строкой этих сайтов?
– Надпись "Not secure".
– Во-о-от, а обычно рядом с адресом любого сайта стоит значок замочка, то есть трафик защищен. А теперь у официальных сайтов ФСБ и Кремля, например, трафик не зашифрован. То есть США отозвали сертификаты большинству сайтов, связанных с официальной российской властью. На мой взгляд, это беспрецедентная демонстрация того, на что готов пойти Вашингтон, если Москва не начнет вести себя нормально.

Грандиозно, только жаль, что никаких подтверждений тому, что какой-то CA отозвал сертификат для https://fsb.ru мне найти не удалось. :-) Оный сайт сейчас действительно доступен лишь по HTTP, но сложно поверить, что если бы это был результат отзыва, то во всём Интернете про это знал бы лишь один Талан.

Короче, гражданин трепло, выступающее перед падкой на алармистскую риторику аудиторией.

У Микрософта нашли очередную дыру, и не абы где, а в святая святых, в домен контроллере. В общем, патчим, товарищи, не ленимся.

---

Там, похоже, читают мой бложик: cтоило обругать Azure Firewall, как в нём появилась именно та фича, которой мне и не хватало. :-) То есть можно указать в качестве destination любое имя, которое резолвится DNS в IP-адрес или список адресов, и Firewall разрешит (ну или заблокирует) соединение на любой из этих адресов, независимо от аппликативного протокола.

Но есть некоторая разница с Фортигейтом - для этой фичи Микрософт требуют превратить Azure Firewall в DNS proxy и настоятельно рекомендуют указать его внутренний адрес в качестве DNS-резолвера для всей живности, что будет через него свой трафик пускать. Делается это для того, чтобы минимизировать ситуации, когда Firewall резолвит то же имя в один список IP-адресов, а клиент - в другой.

Тем не менее, пока эта фича в preview и работает скорее теоретически. В моём опыте, примерно две трети соединений блокировались файерволлом даже тогда, когда он сам же клиенту список IP и резолвил. Правда, у DNS-имени, с которым я экспериментил, был очень короткий TTL, секунд в десять. Ну, будем надеяться, к запуску в продакшен её доведут до ума.

---

В связи с этими делами, стал стучаться в башку такой вопрос: поле Host в HTTP и SNI в TLS вводили, конечно, не ради файерволлов, а чтобы можно было множество сайтов на один серверный IP вешать. Но тем не менее, получилось довольно удобно, что теперь файерволл, работающий в режиме explicit / transparent proxy, может их использовать для сверки со своими правилами:
- и правила эти можно сделать гораздо более точными, чем если иметь для принятия решения лишь пару destination IP & port;
- и файерволл теперь может самостоятельно новое соединение к цели открыть, согласно собственному DNS lookup, независимо от destination IP в пакете, пришедшему от клиента;
- и заодно серверный сертификат может сверить на соответствие.

Так может стоит эту практику на прочие аппликативные протоколы распространить? Ну скажем, на NTP, IMAP, SMTP. Прописывать в явном виде "авторскую интенцию" - DNS-имя, на которое открывается соединение или посылается запрос.

В наш-то век облачных сервисов, когда то же DNS-имя переводится тем же самым DNS-сервером в разные списки IP в ответ на разные запросы, причём интервал между этими разными ответами может измеряться секундами, с традиционным файерволлом пытаться ограничивать исходящий трафик - практически безнадёжная задача, проще сразу "destination = ALL" прописать.

Из-за того иногда приходится прибегать к разным уродливым костылям, чтобы разрешить нужный исходящий трафик, не разрешая всё на свете. Ну, скажем, нужно позволить посылать письма через smtp.googlemail.com. Но поскольку даже если на файерволле можно прописать этот FQDN, по прежнему вероятна ситуация, когда клиент резолвнет этот адрес в IP1, а файерволл - в IP2 (даже используя тот же DNS-сервер!) и заблокирует соединение, то приходится идти на следующий некрасивый трюк: прописывать на внутреннем DNS-сервере (используемый ими обоими) зону smtp.googlemail.com с постоянным ограниченным набором IP-адресов - а дальше надеяться, что Гугл их в обозримом времени будет поддерживать в рабочем состоянии.

---

С другой стороны, это мне-то, решающему задачу ограничения исходящего трафика, это было бы удобно. Но вообще-то, это огромный вопрос - должен ли сетевой протокол быть дружелюбным к файерволлу или же напротив, максимально недружелюбным к нему - и вопрос этот политический. Если мы исходим из того, что государственная цензура - зло (а я так и считаю), то напротив, протокол должен быть как более непрозрачен, чтобы затруднить жизнь Великому китайскому файерволлу, Роскомнадзору и их аналогам. И тенденция идёт как раз в этом направлении - см. Encrypted SNI.

Наверное, дело решится настройкой, позволяющей клиенту запускать соответствующий протокол как в firewall-friendly, так и в unfriendly режимах. Корпоративные сети будут использовать первый, частные юзеры - второй. Серверам, по идее, должно быть всё равно.

---

Технически этот Encrypted SNI представляет собой раздражающий костыль. Давайте посылать юзеру шифровальный ключ в сертификате, а чтобы никто не догадался, какой именно сертификат (и сайт) запрашивается - разместим ещё один ключ в DNS, и пускай клиент свой запрос этим ключом шифрует. Блин, а почему б тогда сам первый ключ в DNS не разместить? А потому, что если враги его подменят, то это будет game over, а так они разве что увидят, на какой сайт юзер лезет. Хорошо, а по DNS-запросам они это не поймут? Поймут, но вот если юзер будет обращаться к заранее известным надёжным DNS-серверам, расположенным за границей, и само соединение с ними шифровать по TLS... Ну хорошо, а если враги запретят с такими серверами соединяться?...

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

А ведь надо заметить, что при всей устарелости и неудобстве паролей, они как раз являются оптимальным методом аутентификации в случае wetware virtualization юзера (см. случай Билли Миллигана и фильм "Split").

Остальные либо вовсе непригодны (биометрия, асимметричные ключи, генераторы одноразовых паролей, SMS), либо не масштабируются (асимметричные ключи с парольной защитой). А ведь мы знаем, что где сегодня два инстанса, там завтра тридцать, надо быть готовым к внезапной популярности этой технологии, work is never over.

Есть ли лучшие решения?

Azure Key Vault - очей разочарованье. Читаешь - вау, круто, хардверная защита, неэкспортируемые ключи, файерволлы, managed identities, access control!
Вникаешь в детали - и тут же выясняется, что для SSL защита ключей нерелевантна. Потому что то, что реально происходит, это:
- сертификаты с секретными ключами просто сохраняются где-то на диске,
- ажурные виртуалки, на которых бегают App Services или App Gateways, попросту переписывают их себе - вместе с ключами - и используют локально.

Таким образом:
- HSM вообще не при делах,
- да и импортировать ключ в этот HSM тоже нельзя - только сгенерировать внутри (поправка: не точно, но для того требуется исходный HSM, так что один хрен),
- да и просто сохраняемый на диске software-protected key тоже экспортируемым быть обязан - иначе для SSL он неприменим. То есть любой, имеющий доступ к Key Vault, его скачает без проблем.

Умом, впрочем, и так понимаешь, что не могёт того быть, чтобы для любой новой SSL-сессии к HSM обращаться - а всё одно обидно.

А накатите, товарищи, Windows Updates, не поленитесь. Тут у Микрософта уязвимость обнаружилась, потенциально могущая все механизмы безопасности на сертификатах - что проверки подписей запускаемых файлов, что HTTPS - в тыкву превратить.

Причём благодарность за обнаружение они выносли никому иному, как No Such Agency, что на серьёзность ситуации как бы намекает.

Патч для соответственной версии винды можно по ссылке скачать, а можно просто поставить апдейты сниматься.

Кстати, семёрка с сегодняшнего дня всё. Для восьмёрки и Win2012 Микрософт патч не выкатил, так что можно предполагать, что и семёрку эта проблема не затрагивает, но в любом случае лучше с неё на другую ось переползти.

Громкие вопли услышав, сбежались они отовсюду,
Вход обступили в пещеру и спрашивать начали, что с ним:
- Что за беда приключилась с тобой, Полифем, что кричишь ты
Чрез амвросийную ночь и сладкого сна нас лишаешь?
Иль кто из смертных людей насильно угнал твое стадо?
Иль самого тебя кто-нибудь губит обманом иль силой? -
Им из пещеры в ответ закричал Полифем многомощный:
- Други, Никто! Не насилье меня убивает, а хитрость! -
Те, отвечая, к нему обратились со словом крылатым:
- Раз ты один и насилья никто над тобой не свершает,
Кто тебя может спасти от болезни великого Зевса?
Тут уж родителю только молись, Посейдону-владыке! -
Так сказавши, ушли.

А ведь перед нами, товарищи, наверное, наиболее древнее описание успешной атаки наподобие SQL-иньекции.

К этому посту: по-моему, эту задачку сегодня вполне несложно решить с помощью on-demand overlay network, типа всяких SDN или FortiGate ADVPN.

То есть, допустим, таким вот образом:

0. У нас есть сеть со множеством файерволлов, которые находятся под управлением разных людей, но принадлежат одной организации и потому доверяют друг другу.

1. Юзер коннектится на файерволл-А по VPN. Файерволл-А проверяет его identity, список групп Active Directory и т.д., и даёт подключиться.

2. Юзер посылает пакет, который, как определяет файерволл-A, предназначен для сети за файерволлом-Б. Файерволл-A строит туннель (GRE, VXLAN, IPsec - неважно) к файерволлу-Б, и как часть метаинформации передаёт детали identity юзера - имя, SID, список групп и т.д. Инкапсулирует пакет и передаёт по этому туннелю.

3. Файерволл-Б проделывает свои проверки этой identity (если нужно; запрашивает сам список групп по LDAP, например), принимает пакет по туннелю и дальше сам решает, что с ним делать, на основе собственных политик.

4. Если пакет передан и на него пришёл ответ, то файерволл-Б отсылает ответ по тому же туннелю.

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

Таким образом:
- каждый файерволл может выстраивать свои собственные политики на основе групп или другой юзерской информации, а не IP-адресов;
- каждый файерволл может быть VPN-гейтом; любой юзер может подключаться на любой из них или на несколько сразу (см. чекпойнтовый Secondary Connect, к примеру).
- каждый пакет от VPN-клиента мы можем привязать к юзерской личности.


Недостатки:
- первые пакеты могут потеряться или прийти с большой задержкой.
- ещё?..

Интересно, уже имплементировал кто?

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

Работает так:
* клиент хочет сертификат для сайта example.org;
* пускай он разместит нечто по адресу http://example.org/some/path - мы это нечто проверим, и если оно окажется тем, что мы ожидаем увидеть, то это послужит доказательством того, что юзер - законный владелец этого имени хоста и вправе получить на него сертификат.

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

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

И если ни личный ключ, ни запрос на сайт не доказывают ничего, то как может являться доказательством их гибрид?

Для того, чтобы оценить маразм идеи, достаточно знать следующее: в новой версии Google Sites при создании сайта с custom domain Гугл автоматически выписывает ему сертификат от LetsEncrypt. Автоматически. LetsEncrypt у держателя домена не проверяет ничего. Сразу выдаёт сертификат Гуглу. Всё. Совершенно не нужно ничего понимать в криптографии, чтобы понять, какая это профанация.

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

Да, более традиционные процедуры domain validation тоже не лишены слабых мест: и создание DNS-записей с рандомальными значениями, и уж тем более получение мейла на адрес вида admin@example.org. Но то, что позволяет LetsEncrypt - это man-in-the-middle как он есть. Это не безопасность, это сапоги всмятку.

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

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

Я об этом писал раньше, но так, чисто to hammer it home, повторю: такой и только такой мессенджер можно считать безопасным, который не предоставляет шифрования. Точнее, который позволяет построить систему шифрования на своей основе, самому не вмешиваясь в её работу. Который будет просто передавать сообщения, оставляя вопросы создания ключей, хранения ключей, обмена ключами, доверия к ключам и шифрования самих сообщений вне своей компетенции.

Именно так работает обыкновенная электронная почта. Я могу использовать для шифрования PGP, S/MIME или хоть WinRAR; хранить ключи на хард-диске или на смарт-карте; использовать сертификаты, которым доверяет весь мир, или наштамповать их для себя и для друга Васи на коленке; обменяться ими по скайпу, через FTP или с почтовыми голубями - это всё вне ведения серверов электронной почты. Протоколам SMTP, POP и IMAP всё равно, шифрованные ли они сообщения передают или нет. Поэтому e-mail безопаснее любых воцапов и телеграмов - если использовать все эти фичи правильно.

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

(Откуда же такая разница между e-mail и мессенджерами? Да оттуда, что e-mail создавалась как децентрализованная система, с открытыми для всех протоколами, не принадлежащая никому конкретно. Любой может поставить себе сервер и обмениваться по этим протоколам письмами с другими. А в случае мессенждеров десятки миллионов людей радостно отдались на милость фирм-феодалов, по выражению Брюса Шнайера. Очень жаль, что получилось так.)