cat_mucius

Разбираюсь, как работают сети в Azure Stack HCI - не потому, что собираюсь эту штуку строить (вряд ли в ближайшее время обломится такой случай, а жаль), а потому, что это проливает свет на то, как работает SDN в настоящем облаке Микрософт Лазурь.

Выясняются интересные подробности. Скажем, в Амазоне load balancer, если его раскидать по разным availability zones, создаёт по IP-адресу в каждой (то есть выделятся по виртуальной машине: HyperPlane в случае NLB, что-то более специализированное для ALB) - и далее полагается на DNS round-robin в качестве механизма HA. А Ажур при этом выделяет один адрес, и в ус не дует - и меня давно интриговало, как же при этом обеспечивается защита от падения всей зоны? Через VRRP, что ли?

Оказывается, всё просто - ажурный LB тоже состоит из множества виртуалок в разных зонах, и они разговаривают с физическими раутерами по BGP, при этом рекламируя один и тот же адрес (то, что называется anycast). Если зона падает, то трафик автоматически переключается на другую.

(Интересно, неужели вся эта туева хуча префиксов /32 попадает в BGP full view? Или Микрософт их всё же убирает из своей раздачи на выходе из своих AS?)

Это заодно и объясняет, почему для каждого Private Endpoint создаётся отдельный префикс /32 в раут-таблицах - работает-то Private Link именно через Standard Load Balancer.

Ещё два примечательных момента:

В отличие от всяких обычных LB (ну там, nginx / HAProxy/ F5 / FortiGate), ажурный LB не занимается переводом destination IP из своего в адрес конечной виртуальной машины (то есть DNAT): он отправляет на неё пакет как он есть. А как же виртуалка его принимает? А потому, что этот перевод выполняет сам гипервизор! ну то есть его виртуальный свитч. А потом выполняет обратный перевод (SNAT) для пакетов в обратном направлении - и благодаря этому эти пакеты вообще не проходят через виртуалку LB, что увеличивает её производительность. Происходит то, что называется direct server return, DSR.
(Это и объясняет, почему для ажурного LB невозможно задать отдельный network security group, NSG.)

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

Amazon NLB, подозреваю, работает так же. Всё это возможно, конечно, благодаря тому, что живут они не в обычных сетях, а в SDN, где правила пересылок программируются напрямую на физических серверах.

Это же позволяет решить проблему масштаба. В чём проблема традиционных сетей? Допустим, у нас есть датацентр о 200 серверах. На них куча виртуальных машин и сетей. Как мы позволяем виртуалке в сети А на одном сервере общаться с другими виртуалками в той же сети на любых других серверах?

Ну как, подключаем все эти сервера к соединённым промеж собой свитчам, определяем VLAN-ы. Будем простоты ради считать, что любой порт на свитче - VLAN trunk, и любой пакет с меткой A может быть доставлен любому серверу.

А как эти виртуалки друг друга находят? Ну, классика, ARP - посылаем широковещательный запрос "эй, у кого IP-адрес такой-то?" Свитчи доставляют этот broadcast на все сервера, те фильтруют по меткам своих VLAN-ов, а то и по запрошенному IP, нужная машина получает ARP-запрос и отвечает на него, дальнейший трафик идёт уже лишь по нужным портам и свитчам.

А если у нас облако и уже не 200 серверов, а 20000? Тоже каждому доставлять каждый broadcast? Проблема.

А SDN эту проблему решает. Нету broadcast-ов внутри виртуальных сетей, зато есть заранее известный SDN-контроллеру расклад, на каких серверах сидят какие виртуалки с какими адресами. И этот контроллер просто задаёт заранее правила каждому из этих серверов: если в виртуальной сети A посылается пакет на IP-адрес виртуалки X, сидящей на сервере Z - то просто запакуй его во внешний пакет с адресом Z и с меткой сети A, и пошли прямо на сервер Z. Чтобы найти сервер Z, broadcast используется, но масштаб уже совсем не тот, тем более, что эти 20000 ничто не мешает распихать по разным VLAN-ам да сабнетам.

В общем, интересное кино.

О блин. Мечтал, как бы организовать контроль исходящего трафика для удалённых виртуальных десктопов - а решение, хоть и неудобное, валялось под носом. Обыкновенный "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, но сложно поверить, что если бы это был результат отзыва, то во всём Интернете про это знал бы лишь один Талан.

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

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

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

Из свеженького - в HTTP-запросах типа "multipart/form-data" эта сволочь попросту не пересылает последние два байта.

В продолжение мечтаний:

Вот интересно, существует ли на белом свете сетевая хреновина типа файерволла, умеющая обрабатывать исходящий HTTPS-трафик следующим образом:
1. Ответить на попытку установить TCP-соединение на любой адрес - от имени этого адреса.
2. Получить от юзера пакет "Client Hello", прочесть оттуда хостнейм из поля SNI - сегодня его посылают практически все.
3. Проверить по DNS, на какие IP-адреса резолвится этот хостнейм.
4. И лишь после этого искать подходящую firewall policy и проверять:

соответствует ли хостнейм из SNI тому адресу, на который было запрошено соединение,

или тому, что указано как destination в этой полиси - а это могут быть как и диапазоны адресов (в таком случае надо проверить, попадает ли адрес, используемый юзером - или же адреса, полученные от DNS - в эти диапазоны), или же текстовые правила типа регулярных выражений (тогда надо на них проверить хостнейм),

соответствует ли сертификат, посланный сервером, этому хостнейму - по полям CN и SAN.

Ну и в качестве вишенки на торте, чтобы проверяла полученный сертификат по ограниченному списку CA и чтоб deep inspection умела делать. Ну ещё и заголовками HTTP манипулировала, мечтать так мечтать.

Фортигейтов Explicit Proxy умеет многое из этого, но это прокси. Клиентов надо настраивать к нему обращаться. Но вообще-то без малого 2020-й год на дворе, было бы неплохо уметь делать умную обработку трафика и прозрачным для юзеров образом.

Если нет такого - так выпьем же за то, чтобы в наступающем новом году!..

К этому посту: по-моему, эту задачку сегодня вполне несложно решить с помощью 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-клиента мы можем привязать к юзерской личности.


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

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

За последнее время много вожусь с IaaS-облаком; хочется излить несколько наблюдений, как подходы, принятые в обычных, невиртуализированных системах некритически переносятся в облачную среду:

1. Неоднократно наблюдал, как на облачных серверах баз данных или там Exchange люди привычно ставят диск для баз, и отдельно - диск на transaction logs, думая, что это улучшит производительность. Да с чего бы? На обычном железе в этом был простой, понятный смысл: на диске баз данных считывающая головка может прыгать между секторами как угодно, а на диске логов будет большую часть времени просто записывать в хвост. Соответственно, лучше, чтобы диски были разные.
Но зачем это делать в облаке, где все эти диски - всего лишь файлы на датасторе? Если они хранятся на одном и том же физическом хард-диске - ну так значит, он обречён крутиться псевдорандомально. Но даже если мы разнесём их на разные хранилища - один чёрт каждое из них используется тучей прочего народу. Предсказать, как реально будут крутиться хард-диски в этих хранилищах - абсолютно невозможно.

Впрочем, по мере ухода магнитных дисков этот вопрос отпадёт окончательно. Хотя и тогда по инерции админы будут разносить базы и логи - у нас так заведено.


2. Продолжая тему дисков - объясните мне кто-нибудь, а какой смысл в локальных дисках в облаке? Почему не определить любой, или хотя бы любой data disk как shared? (Шишков, прости...) Это в физическом мире у нас есть либо SAN, либо просто SCSI-кабель к дискам, который больше чем в один компьютер не воткнёшь. А в виртуальном какая разница, какое устройство эмулировать - SCSI-контроллер или HBA какой-нибудь? Один чёрт наши диски - просто файлы на каком-то датасторе.

Сегодня облака shared disks обычно не предоставляют, и поэтому, чтобы завести какой-нибудь кластер на виртуалках, который их требует (да хотя бы файлсервер на микрософтовском Failover Cluster) нужно сооружать дикие турусы на колёсах. А как было бы просто: кликаешь в облачном портале мышкой пару раз - вот тебе виртуалка с диском. Кликаешь ещё - вот тебе вторая, третья, восьмая виртуалка, и все видят тот же диск. А дальше дело твоё, как их координировать: либо только главный сервер кластера юзает диск, либо ставь файловую систему, поддерживающую доступ со многих, типа VMFS или GFS2.


3. VLANs и, шире говоря, Ethernet вообще. Как-то упускается из виду, что в обычных локальных сетях broadcast domains существуют не от хорошей жизни, а оттого, что каждый компьютер в порт файерволла не воткнёшь. Хотелось бы инспектировать трафик между любыми двумя хостами - но что делать, свитчи функциональностью современного файерволла не обладают, а если такие и есть, то цена у них заоблачная, pun intended. Поэтому, если не хочется угробить производительность, приходится разбивать сеть на какие-то секьюрити-зоны, отказываться от возможности фильтровать трафик внутри них и удолетворяться фильтрацией между ними. Кроме того, VLAN-ы позволяют с лёгкостью гонять групповой и широковещательный трафик.

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

Пример: допустим, у меня классический расклад - 20 вебных фронтэндов, за ними SQL Server. По логике секьюрити-зон, мне надо засунуть фронтэнды в один VLAN, SQL - в другой, и контролировать трафик между ними. Но тогда фронтэнды могут между собой неограниченно общаться - а зачем мне это надо? Им нужно говорить с HTTP-клиентами и с SQL-сервером, а друг дружке им что-либо передавать незачем.

Тут пригодился бы Private VLAN, но облако такое не предоставляет. Наштамповать отдельный VLAN под каждый фронтэнд можно, но мы упрёмся в иные ограничения. Приходится сажать их в общий, а это лишний риск.

Надо сказать, что Микрософт это как раз осознали - в Azure классического Ethernet-а нету, они там наворотили что-то своё на Layer2 (апдейт - таки да). В результате можно фильтровать трафик между любыми машинами, даже если они сидят в одном сабнете - но любой неюникастовый и, шире, любой не-IP трафик не поддерживается. По-моему, выбор в правильную сторону.


А у вас какие наблюдения?

Накатал в технобложик о своих приключениях с load balancer'ом в FortiGate - авось другим бедолагам пригодится.

Кроме того, вопрос назрел. Допустим, есть у нас куча файерволлов, между собой соединённых, каждый защищает свой участок сети. Допустим, один или несколько из них служат также VPN-гейтом - что позволяет в качестве источника указывать не IP-адреса и порты, а личности подключённых по VPN юзеров, или группы к которым те принадлежат (насколько я знаю, первой такой рецепт придумала израильская CheckPoint). Но вот что обидно - после VPN-гейта эта информация теряется. К IP-пакету информация, что за юзер его послал, не пришпандорена - и следующий файерволл, что будет его обрабатывать, уже не будет знать ни юзерскую личность, ни группы, ни nesting группы, а будет видеть лишь IP-адрес источника - адрес, выданный клиенту VPN-гейтом.

Что ведёт к неприятному следствию - если мы хотим учитывать группы в правилах доступа (чего очень бы хотелось), то приходится либо:
- Концентрировать все такие правила на VPN-гейте. Что просто не масштабируется и неудобно: надо, чтобы этот гейт знал все объекты в сети, к которым VPN-клиентам потребуется доступ. Во-первых, их может быть очень много, а во-вторых, это мешает нормальному распределению ответственности - вместо того, чтобы админ какого-то отдельного сегмента задавал правила на своём файерволле по своему разумению, он должен добиваться, чтобы их задал админ VPN-гейта. Хорошо, если это один и тот же чувак, а если разные?
- Искать пути обхода - например, настроить гейт так, чтобы разным группам клиентов выдавались адреса из разных пулов. Тогда на дальнейших файерволлах можно эти пулы использовать как заменители групп. Что тоже не фонтан - не факт, что гейт такую возможность вообще поддерживает, да и опять таки излишняя зависимость между админами и неудобняк. А если группы между собой ещё и частично пересекаются?

Хотелось бы иметь технологию, позволяющую разным файерволлам (в идеале - ещё и от разных производителей) распространять соседям информацию о подключённых VPN-клиентах, чтобы те могла строить свою политику о группах самостоятельно. Кто-нибудь знает о чём-то подобном? Вроде бы у Cisco есть что-то под названием TrustSec, но с их оборудованием мне работать как раз не доводилось. Интересно, есть ли такое у других вендоров? Какой-нибудь open-source проект?

Ого. Вот это штука поистине революционная: cloudpaging. Молодцы.

Правда, любителям взломанного софта типа меня жизнь усложнит неимоверно. :-)

P.S. А доводилось ли вам когда-нибудь ставить дорогущий 10-гигабитовый свитч в серверную стойку при помощи автомобильного домкрата?