https://thesecretlivesofdata.com/raft/ а пока позалипайте в крутое объяснение рафт консенсуса

Всем привет. Похоже, длинный саббатикал не способствует часто писать в собственный канал 🙂 Как и обещал, про Hashicorp Boundary. А еще я добавил возможность комментариев, welcome!

Boundary by HashiCorp

Что это?
Относительно новая опен-сорс тула от Hashicorp для доступа к разным средам, типа Кубера, баз данных, ssh, и т.д.
Зачем, если есть опенвпн?
Основная мотивация в том, чтобы избавиться от минусов старых подходов. Делая впн внутрь периметра, вам часто нужно сильно заморачиваться с подобными сценариями:
⁃ Автоматизировать выдачу и ревоук сертификатов для каждого клиента опенвпна
⁃ Выдать клиенту IP опенвпн сервера, и выдать(не всегда) IP куда ему коннектиться
⁃ Выписать и выдать креды базы данных, или ssh, etc.

Понятно, что все автоматизируется в случае впнов, и волты прикручиваются к базам данных, и SSH к IdP, но баундари обещает всю(ну почти) эту магию брать на себя! Разве не круто?

Зачем, если можно сделать bastion/jump hosts?
Похожие проблемы, что и с впном, плюс:
⁃ Юзер оказывается внутри сети со всеми вытекающими. Дада, фаерволы, айпитейблс наше все, но вы же понимаете как они выглядят, если несколько групп должны иметь разные права внутри этой сети.
⁃ Сложность логирования подобных доступов.


Ну окок, убедил! Как выглядит типичный флоу?
⁃ С помощью предустановленного CLI, десктопного(есть Mac и Win), или веб клиента юзер аутентифицируется в самом баундари через IdP(можно просто логин-пароль). Несколько версий назад они зарелизили OpenID Connect, с помощью которого можно аутентифицироваться через Microsoft Azure Active Directory, AWS Identity, Okta, Auth0, прочих подобных провайдеров. Понятно, что если в случае каких-то причин у сотрудника отозван доступ к IdP, потенциальный злоумышленник остановится на этом первом же шаге.
⁃ Юзер теперь может посмотреть какие таргеты ему доступны: куда он может приконнектиться
⁃ Инициирует boundary connect к нужному таргету
⁃ Проходит RBAC, система проверяет, что у него есть и какие права на этот таргет
⁃ Устанавливается соединение, которое по-факту проксируется к желаемому таргету, через компонент баундари, который в их терминологии называется worker.

Это серебряная пуля, срочно в родмап инфра-тиме!
Я бы не спешил! Ключики для коннекта к ssh нужно все еще раскладывать самому, например! Но, если у вас уже те же RDS работают в связке с vault, то коннект для Postgres target будет сразу с максимальной дозой магии. А также, чтобы таргеты обновлялись динамически нужно иметь консул в инфраструктуре. В общем, зависит от того насколько плотно вы уже подсели на хаши-продукты. Также отмечу, что документация пока скудненькая

Какие таргеты поддерживаются?
Из коробки поддерживаются ssh, http, Postgres, rdp. Обещают добавлять коробочных. А пока с помощью враппера boundary connect -exec можно заюзать что угодно через TCP.

RBAC полиси руками что-ли править?
Так и было до совсем недавнего времени, но солнцеликие из хашикорпа выкатили нам терраформ провайдер для управления всем этим добром.
https://registry.terraform.io/providers/hashicorp/boundary/latest

Хашикорп изобрели что-то совсем новое?
Неа! До них это делали Teleport, StrongDM, Pritunl Zero, и другие
Нашел неплохую табличку сравнения

Продолжим тему Security и сертификатов! Поговорим про DNS CAA(Certification Authority Authorization) .

Что это такое? Зачем нужно?
Это отдельный тип записи, в котором содержится информация о том какие центры сертификации могут выпускать SSL сертификаты для определенного доменного имени или субдомена.

Как выглядит типичный flow?
- Вы(или не вы) просите у центра сертификации(СА) выписать вам новый сертификат.
- СА проверяет CAA запись вашего домена, смотрит есть ли разрешение конкретно этому центру выписывать сертификат на этот домен, либо wildcard.
- Если разрешение есть, то СА идет далее по стандартному процессу.
- Если же, такого разрешения нет, то СА отправит вам письмо на мейл, который вы указали в теге iodef в своей записи. Об этом чуть ниже.

Хочу добавить себе CAA в DNS, как бы не ошибиться?
Формат достаточно простой и выглядит вот так

CAA <flag> <tag> <value>

Где:

- flag это так называемое битовое поле. Этот флаг влияет на то, что будет делать СА, если он не смог распарсить ваши теги. А также задуман для расширения функционала этих записей через такие флаги в будущем. Например, что-то типа CAA 128 future "value"
* 0 обозначает, что если СА не смог распознать, что вы засунули в поле tag, то может действовать по своему усмотрению.
* 1 значит, что СА должен прекратить процесс, если запись в теге не распознаваемая, либо не поддерживается этим CA.
Честно говоря, текущие флаги мягко говоря странные, наверное поэтому, я не нашел у реальных доменов что-то отличное от 0.

- tag. Тут задаются самые главные правила. В тег issue записываем СА, которому можно выписывать сертификаты для этого домена. Если выписываете wildcard-сертификаты, то используем тег issuewild. Ну, и в теге iodef указываете мейл, на который будут отправлены уведомления, в случае нарушения кем-то правил, которые указаны в вашей CAA записи.
- В value может быть разное, зависит от тега, заключается в кавычки.

Рассмотрим на примере dig cloudflare.com CAA +short:

0 issue "comodoca.com"
0 issue "digicert.com"
0 issue "letsencrypt.org"
0 issuewild "comodoca.com"
0 issuewild "digicert.com"
0 issuewild "letsencrypt.org"
0 iodef "mailto:[email protected]"

Они разрешают выписывать сертификаты comodoca, digicert, letsencrypt. И одновременно, они разрешают выписывать wildcard-сертификаты этим же центрам сертификации. С mailto понятно думаю.

Как вы могли заметить, чтобы разрешить несколько СА, нужно создать индивидуальную запись для каждого из них.

А еще можно запретить выписывать любые сертификаты на поддомен:

nocerts.example.com CAA 0 issue ";"

или wildcard

CAA 0 issuewild ";"

Стоит упомянуть, что варианты одиночных сертификатов или wildcard зависит от ваших нужд в инфраструктуре. Кто-то выписывает на каждый сабдомен отдельный сертификат, а кто-то *.example.com. В первом случае вам нужно issue, во втором - issuewild, в обоих - и то и то.

После того как вы поняли как это работает можно и генератором воспользоваться https://sslmate.com/caa/

Что произойдет с уже имеющимися сертификатами при добавлении CAA записи?
Ничего! Это относится только к выпуску, перевыпуску, либо продлению сертификатов. В общем, в тот момент, когда вы обращаетесь к центру сертификации.

А браузер проверяет?
Нет, браузер в этом механизме никак не учавствует.

Кто поддерживает эти записи?
Не уверен, что это прям полный список https://sslmate.com/caa/support, но основные центры(Let’s Encrypt, Izenpe, Comodo, GoDaddy, HARICA, GDCA, Trustwave, SwissSign, Symantec, SHECA, CFCA, SSC, GlobalSign, Cisco, Buypass, DigiCert, Disig) будут проверять! Где-то попадалась цифра, что это 94% рынка компаний, через которые можно выписать сертификаты.

Так как более мелкие СА это по-сути ресселеры крупных, то считай для большинства будет работать.

Работая в компании, софт которой стоит на каждом 5-м маке в мире, волей-неволей придется столкнуться с CI/CD для macOS. Недавно я разбирался с Anka: MacOS Container-like Virtualization. Было бы интересно почитать что это такое и чем может быть полезно, если у вас в компании есть необходимость в автоматизации macOS билдов?

macOS-около-CI-CD
Мы все давно привыкли к докеру и его экосистеме. Сделал docker image, а дальше его хоть run, хоть exec, хоть что хочешь делай, хоть в tar.gz заверни - красота! Пару лет назад я делал небольшой воркшоп по докеру внутри компании, и коллеги связанные с разработкой под мак сказали "стоп! мы также хотим с макосью". Увы, ответ их не порадовал, и ситуация забылась, все продолжили собирать свои икскоды по старинке. Однако, чем дальше, тем сложнее скейлить любые CI/CD, которые надо запускать на macOS/iOS.

В чем проблема то? Купил mac mini, настроил ось, xcode и билди себе, и коллегам за печеньки в аренду!

А проблем в общем-то много: такой миник можно зашарить максимум с парой коллег с вашей команды, никакого параллелизма, один кто-то сделал изменения пакетов, версий - все сломалось, сиди разбирайся. А теперь представьте, если команд у вас 5(с потолка), и людей них по 10-15 в каждой, и таких миников тоже десяток?

Как-то люди же выживали то до 2021?

Перечислю самые стандартные способы выживания, причем это также будет справедливо даже к таким компаниям-монстрам как Shopify или Uber:

- Куча mac mini/pro + Chef/Puppet, позже Ansible. Все более-менее работает, пока не прилетает апдейт, меняет поведение каких-то внутренних команд и все поламалось, иди найди и запили в кукбук, плейбук, может твой PR примут быстро, недели за 3-4! C мажорными апгрейдами все ломалось еще масштабнее. Версии руби, пайтона зависимостей, и вот этот вот адок вокруг этого.
- Вручную настраивать каждый билд-агент, мак мини. Это утопия, треш и содомия. Хотя, на старте и для мелких команд может быть вполне себе.
- macOS агенты на крупных CI/CD платформы. Тут многие выдохнули и быстро туда переехали когда они появились и начали освоение рынка. Конечно же, CI/CD saas'ы у себя страдали также как и остальные, только помножьте еще на количество клиентов и их хотелок. У CircleCI одно время статус-борд по macOS агентам был чаще красным, чем зеленым, Github Actions до сих пор не могут предоставить клиентам BigSur после почти года официального релиза это версии в GA. Еще есть Azure Pipelines, GitlabCI(используют чужую платформу), Semaphoreci, TraviCI. У каждого свои особенности, но не сомневайтесь, что все они снимут с вас прилично $$$, за то, что вам не приходится в это залазить по локоть!
- VMware ESXi - дорого-богато, медленно, заморочки с лицензиями! Вы можете запускать гипервизор только на Apple hardware, что накладывает немало ограничений. Существуют какие-то "серые" патчи от энтузиастов, на ваш страх и риск, но они работают, и как минимум в наших краях их активно используют! Apple для своих внутренних ферм использовало VMware до 2015, потом они не договорились и контракты не продлились, но сам факт.
- Orka by MacStadium (Orchestration with Kubernetes on Apple). Долго этот рынок оставаться пустым не мог, и крупный хостинг-провайдер выкатил Орку. Это такой себе дикий микс из докера, макоси, квм, и какого-то модифицированного Linux. Соотвественно, можно использовать только на их железе и в их датацентрах. Выглядит поверхностно и правда круто, т.к. вы получаете по-сути тот же кубер, только внутри подов у вас макось! Однако и доступа ко всем компонентам конечно не получите. Сильно глубоко я еще туда не погружался, т.к. ~кровавый энтерпрайз~ демо дают всего на пару часов, дальше общайся с сейлзами. Помните я писал про GitlabCI выше? Так вот они под капотом юзают эту самую Orka
- Все более прозрачно с Veertu Anka, который построен поверх нативного Apple hypervisor. Их явно вдохновлял докер, поэтому тут есть реджистри для имеджей, run команда для запуска команд в уже запущенной вмке и всякое подобное. Тоже не бесплатное решение, цены закрытые.
- Xcode Cloud. Выпустили недавно, выглядит пока еще сыровато, да и не похоже на решение для больших команд. Будем наблюдать.

Обещал вам рассказать про Veertu Anka, но вышло такое себе длинное интро в тему 🙂 В следующем посте точно про нее!

Пока компилится много текста про Anka MacOS Container-like Virtualization распишу почему вчера анонсированный сторедж от CloudFlare - это 💣! Речь пойдет исключительно про передачу исходящих данных из Amazon S3 в Интернет, или от CDN в Интернет.

Как работает ценообразование очень популярной связки S3+CloudFront?

Вы кладете на S3 свои объекты, сверху настраиваете CloudFront и платите только за трафик от CDN к юзеру, и не платите ничего за трафик между S3<->CloudFront. Далее, в зависимости от "PriceClass" и региона, в котором у вас юзеры, вы будете платить от 0,085USD до 0,114USD за Гб. Если вы раздаете десятками или сотнями гигабайт, цены будут в конечном счете падать, но все равно будут внушительными.

Да ну нафик ваш CloudFront, у CloudFlare за 20 баксов раздавай - гигабайты не считай!

Думаю у многих такая мысль хоть раз, да проскакивала! Ведь CloudFlare не снимает с вас дополнительных денег, если вы раздали случайно лишних 10-20 терабайт. Однако сюрприз - с вас начнет снимать деньги AWS S3(или AWS EC2)! Причем довольно стабильно будет вам насчитывать 0,09USD за Гигабайт, и чуть ниже, например 0,085USD, если ваши объемы раздачи от 40Тб. А так как CloudFlare в глазах Амазона и есть "Интернет", то у вас сразу возникнет вопрос как бы нам теперь почаще кешировать на CloudFlare, чтобы реже бегать в S3. И вроде бы не такая и большая проблема накрутить побольше TTL, но когда у вас миллионы+ статики, разные проекты, то под каждый надо подумать как будет удобно и юзерам, и чтобы не попасть на деньги по S3.

И что же, никто с этим ничего не делал, просто заносили 💰💰💰 Безосу?

Думаю ребятам из CloudFlare надоело обьяснять AWS кастомерам, что они ничего не могут с этим поделать, и они создали Bandwidth Alliance https://www.cloudflare.com/bandwidth-alliance. Такой себе кружок провайдеров и хостингов, где трафик в сторону CloudFlare будет бесплатным, либо с дискаунтом(Azure, GCP).

Ну, думаю вы понимаете теперь, что хранилище от CloudFlare было лишь вопросом времени! Платить нужно будет только за место в их Cloudflare R2 Storage, и ничего за трафик.

P.S. Не забывайте, что в тарифных планах у CloudFlare Free/Pro на вас будут тестировать всякие кенери и любые даунтаймовые нововведения, а также могут и отключить, при аномальных пиках трафика. Поэтому, халява халявой, но мозг и совесть нужно иметь выбирая на каком плане вы будете жить.

macOS виртуализация с криповым именем. Anka. Часть 1

Что это еще за Анка такая?

Если вы вдруг пропустили пост выше https://t.iss.one/devops_easy/18, то там предыстория, почитайте. Сам продукт называет себя "macOS Container-like Virtualization" или "macOS cloud for iOS CI and DevOps". И первый и второй слоган правдивы, но как всегда, со своей спецификой. Построено все это поверх Apple hypervisor, что большой плюс, т.к. это нативный гипервизор macOS, и там всякий scheduling, прочий низкоуровневый management ложится на плечи блекбокса от Apple.

Это как VirtualBox что-ли?
Скорее нет, чем да, ну, т.е. это тоже ПО для виртуализации, но работает только с macOS и заточено на CI/CD. А также у Anka есть свои киллер-фичи! Давайте пройдемся по компонентам, чтобы понять, что оно из себя представляет:

• Anka Develop. Ограниченная, но бесплатная тула для разработчиков, используется на своем макбучке или iMac. Это похоже как раз на виртуалбокс, где вы раните свои виртуалки. В данном случае, на бесплатной версии вам доступна только одна VM at a time, и вы не можете взаимодействовать с Image Registry(об этом позже). Т.е. что вы можете сделать - создать виртуалку с нужной macos, попробовать что-то туда поставить, поэкспериментировать. Выглядит будет примерно так:

$ anka create --ram-size 8G --cpu-count 4 --disk-size 80G --app ~/Install\ macOS\ Mojave.app Mojave

$ anka run Mojave sw_vers
ProductName: Mac OS X
ProductVersion: 10.14.5


Ну, или запустить в графическом интерфейсе как обычную виртуалку, получив что-то типа vnc.

• Anka Flow. Все тоже самое, что и Anka Develop, только платная, плюс такие фичи: Run Multiple VMs, State Snapshot/Suspend VM, USB Device Support, Ability to communicate with Anka Build Cloud (Controller & Registry). За Flow нужно заплатить $360 в год за каждый девелоперский макбук, независимо от его железа.

• Anka Build Cloud. Самый интересный для нас компонент, за который и придется платить от $600 per core per year за Basic tier. Разбивку по планам можете посмотреть тут https://docs.veertu.com/anka/intel/licensing/#anka-build-cloud.
Если проводить аналогии, то Build Cloud - эдакий микс Docker Hub(Registry), и Docker Engine API(Cloud Controller with REST APIs).

1) Registry в который можно пушить темплейты(имеджи) с макосью, и тегами, и соответственно пуллить их со стороны ваших макмиников. Тут все плюс-минус просто и понятно, кроме странной работы тегирования, т.к. это сделано не так удобно, как с докером.

2) Cloud Controller with REST APIs. Центральная точка для управления: нодами макоси, с предварительно установленной Anka и джоином их в кластер, самими виртуалками(start/stop/delete) на разных нодах, предварительного раскатывания имеджей на ноды, а также имеджами в реджистри, и много чего еще. Все это можно делать через наколеночно выглядящий интерфейс, либо понятно через API. CLI или sdk пока не имеется, поэтому писать обвязку нужно будет самостоятельно. Однако, у них достаточно разных плагинов под известные CI, возможно для вас все заработает и без танцев вокруг. Также там есть разные интересные плюшки в планах Enterprise и выше, типа Priority scheduling of VMs through controller или Clustering (Grouping) of Nodes, но туда еще не добрался, рассказывать нечего.

Ну, и кому это интересно, если это нельзя съесть, тр...или засунуть в Кубер?

Их доки немного вводят в заблуждение пунктами "High Availability With Kubernetes"! Однако в докеры/куберы можно будет запихнуть только реджистри и контроллер, и хоть за это спасибо! Представьте как вам надо было бы извращаться с сетевыми хранилищами на мак-миниках, чтобы хранить всю эту кучу разных имеджей под все случаи жизни. Оно выглядит еще немного в зачаточном состоянии, в плане манифестов, но, мучаться с Кубером это ж как раз наше, правда?) Не так страшно в общем.

macOS виртуализация с криповым именем. Anka. Часть 2

CI/CD integration

Как и писал выше, есть плагины под разные системы CI/CD, посмотреть и попробовать поиграться можно тут https://docs.veertu.com/anka/intel/ci-plugins-and-integrations/. Триал на 30 дней можно получить просто зарегавшись, на этапе скачивания! Поэтому я сразу побежал посмотреть пример с Github Actions. И вот как это поверхностно работает:

GHA Agent + Anka on Host:

- Ставим Anka на self-hosted мак-мини
- Туда же ставим GHA агента
- Добавлям .github/workflows/{whatever}.yml с их action, туда же внутрь команды, которые хотите отправить в виртуалку, и через GHA агента, они прилетят через anka run дальше. Живой пример https://github.com/veertuinc/github-actions-examples/actions

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

Anka on Host + GHA Agent inside VM:

Берем виртуалки, ставим туда GHA агента, и когда виртуалка поднимается, то у вас джобы автоматически подхватывают такого агента из пула. Здесь нет никакого anka run, сам GHA агент ранит команды так, как-будто бы он просто стоит на self-hosted чем угодно. Удобнее? Да, но также имеет свой минус: кто-то должен снаружи на хосте уметь тушить и поднимать ваши виртуалки. Но, это попроще первого варианта, имхо, и уже больше похоже на cloud что-ли.

Damn it API:

Самый жирный, но придуманный не Anka девелоперами, а моим коллегой! 😎 Вся эта связка умеет работать через API контроллера, кроме anka run на произвольную машину. Эту фичу они обещают в ближ месяцы запилить, и тогда управление всем процессом можно производить на контроллере, через API и забыть про агенты на стороне макоси.

Performance

Начитавшись разного в интернетах, я побаивался, что несмотря на кучу плюшек виртуализации, реджистри и прочего, производительность будет сильно проседать. Я провел Geebench тесты, которые показали что страдает в основном Multi-Core. За результатами сходите в комменты к посту.

Синтетические тесты хорошо, но я пошел проверять на наших реальных билдах, с юнит-тестами и сборкой разных пакетов. Итог меня честно говоря удивил, т.к. результат на Bare-Metal и в внутри одиночной виртуалки практически не отличались между собой. И даже больше - если запускать 2 виртуалки в параллель поделив пополам CPU и RAM на них, то они будут быстрее на 33% по скорости билда, по сравнению с последовательными шагами на Bare-Metal.

VM Templates automation
Следуюшим вызовом будет тема автоматизации самих виртуалок и базовых темплейтов/имеджей. Но, думаю, это врядли будет так интересно, т.к. packer+ansible известен всем, и мне кажется, многим понятно как это будет выглядеть, учитывая, что у Anka есть плагин под Packer.

RUM DNS Traffic Steering. Часть 1

Что такое RUM?
Думаю многие знакомы с RUM, он же Real User Monitoring. Но, если нет, то существует два типа замеров производительности вашего сайта:
• Synthetic. Этот функционал делают миллион разных “пингалок”: Pingdom, site24x7, StatusCake, Pingdom, Uptimerobot, etc. Они C разных локаций заходят к вам на сайт, и условно через
curl -H 'Cache-Control: no-cache' -Lw "DNS Lookup: %{time_namelookup} seconds \nRedirects: %{time_redirect} seconds with %{num_redirects} redirects \nFirst Byte: %{time_starttransfer} seconds \nConnect Time: %{time_connect} seconds \nTotal Time: %{time_total} seconds\n" -so /dev/null https://apple.com/
рисуют вам эти же значения в красивый UI. Все ок, но локации как правило статические, так же они находятся в датацентрах, что совсем не тоже самое, что юзерский интернет.
• RUM. Это подключаемая к вам на сайт js-библиотека, которая при каждой загрузке страницы отправляет кучу перфоманс данных в сторону коллектора, и вам рисуют красивые данные в UI. Только точность тут гораздо выше, т.к. собирается все это прямо в браузере клиента, со всеми его особенностями той самой Last mile.

Вроде понятно. Причем тут DNS?
Зайдем издалека, и поговорим с желтой 🦆 о вот какой проблеме.

- Уточка, хочу стать поближе и побыстрее к своим клиентам? Что посоветуешь?
- Уточка: конечно же подключить CDN!
- А какой CDN подключаем? Akamai, CloudFront, Google, CloudFlare? Кто из них будет лучше для всех регионов сразу и даже стран?
- Уточка: а давай подключим все сразу?
- А давай! Правда все еще непонятно какой CDN для какой страны использовать! Кто там у нас лучше всех перформит в Индии?
- Уточка: но CDN же крутые, они используют Anycast, он все сам разрулит!
- Хм, но меньшее количество хопов ≠ лучшее latency!
- Уточка: ....ладно, что же делать?

И вот тут в игру вступает DNS Traffic Steering based on RUM. В свой(не обязательно) сайт ставляем js-ку, но, очень обрезанную по-сравнению с классическим RUM. Меряем мы только latency и какие-то еще performance штуки до ближайших точек PoP ваших CDN в этом регионе, берем эти цифры и отправляем в сторону вашего коллектора, условного хадупа. Обрабатываем данные, и постоянно перестраиваем “таблицу маршрутизации” на основании того, кто лучше перформит конкретно в этой локации, соотвественно, кого и в какую точку отправлять с помощью наших днсов. Как пример, для Ирландии мы выставили использовать Akamai и CloudFlare, и вот флара взяла и отправила точку на обслуживание, и весь трафик у них начал ходить через Лондон, latency увеличилась, и все органически перетечет в Akamai. Причем настолько быстро насколько низкие у вас TTL. Тоже самое сработает при полном отказе одного из CDN, да такое тоже бывает 😉

Самые внимательные спросят: так ведь мы уже зашли на сайт, резолвы где-то там позади?
По-факту замер RUM и клиентские резолвы не обязательно связаны. В целом, есть всего два сценария:

- Клиент использует EDNS, и присылает вместе с днс реквестом свою сабнет сеть, а значит и Autonomous System (AS). В базе резолвера за счет других клиентов уже есть перфоманс информация о вашей AS, и вам сразу же отдают правильные ip адреса PoP, CDN и прочее, используя т.н. “таблицу маршрутизации”, которая обновляется постоянно, практически реал-тайм.
- Клиент не использует EDNS, тогда берется IP резолвера например и отдается лучший вариант из агрегированной статистики для клиентов, которые находятся за этим резолвером и уже присылали какую-то статистику. Не редко крупные провайдеры могут шарить между собой обезличенные базы, чтобы лучше покрывать такие кейсы. А также вы можете принести свои данные, или community-sourced, чтобы лучше управлять своим трафиком.

Пруфов не предоставлю, т.к. давно было, но тот же AWS CloudFront на заре своего запуска использовал данные RUM, которые они собирали с Amazon.com, и таким образом сильно повысили качество своего CDN.

RUM DNS Traffic Steering. Часть 2

Ха, да я такое на nginx+GeoIP построю, и надо мне вот это заморачиваться?
Построите, вопросов нет. Но, будут вопросы к аккуратности определения геолокации вашего юзера по этим базам.
В общем, это слабенько будет коррелировать с самым коротким путем к вашем контенту.

А что делают когда из одной точки два CDN провайдера отдают приблизительно одинаковые результаты?
Такое вполне реально учитывая распространенность точек крупных CDN. В таком случае на клиент ставят cookies, которые говорят о том, что для него есть какой-то primary CDN, secondary и т.д. Это в том числе позволяет не нагружать только одну ближайшую точку присутствия всеми клиентами сразу.

Ок, мои сайты не такие крупные, но завтра мы получим миллиард $ инвестиций и нужно срочно сделать всем хорошо, куда бежать?
Есть несколько топ-компаний, которые на этом строят свой бизнес:
NS1, Constellix, Dyn, Cedexis. Ну, если и без чужих SaaS круты, то можно и самому, например на базе https://github.com/akamai/boomerang

Cache-Poisoned Denial-of-Service (CPDoS). Часть 1

Что это за вид атаки и как работает?
Если атакующий нашел у вас такую уязвимость, то вы в какой-то момент заходя на свой сайт, вместо 200ОК увидите, что-то из 4xx-5xx. Пойдете проверить свой бекенд, и увидите, что с ним все в порядке. Однако проблема есть, рассмотрим разные варианты этой атаки ниже.

Стандартный способ использовать данную атаку против ваших сайтов предполагает, что перед вашим сайтом стоит какой-то кеширующий сервер: CDN, либо CDN+Varnish(или подобный). Например, у всех сайтов на популярном сайтбилдере WebFlow перед их серверами стоит Varnish.

curl -I https://somesite.webflow.com/
HTTP/2 200
server: openresty
via: 1.1 varnish, 1.1 varnish
x-served-by: cache-iad-kjyo7100124-IAD, cache-dub4350-DUB
...

Это значит, что клиент открывая их страницу обращается к Varnish, который в свою очередь идет на условный Origin бекенд somesite-backend.example.com и запрашивает у него страницу, отдает вам, и складывает себе в кеш. Далее все клиенты получают эту страницу из кеша.

Но что, если, Origin вернет не нормальную страницу, а скажем 400 Bad Request? Правильно - Varnish сохранит ее у себя в кеше, и будет отдавать дальше всем клиентам!

Ок, разобрались как работает. Правда мой сайт живет в Хецнере на огромном серваке всегда отдает 200ОК, у нас 99,9999% аптайм вообще-то, нам то что?
Как заставить ваш бекенд отдать НЕ 200ОК:

- HTTP Header Oversize (HHO)
Атака HHO заключается в том, что вы посылаете GET запрос с заведомо большим HTTP header. И тут важный момент: промежуточный кеш должен пропускать такие хедеры по размеру больше, чем может принять ваш бекенд. Как это выглядит на пальцах:

Client: HTTP GET with X-Bad-Header: "Very-Big Value-01123581321345589144233377610987"
↓↓↓
Cache: Looks good to my internal headers limits
↓↓↓
Origin: Oh, too big header for me. 400 Bad Request
↓↓↓
Cache: 400 Bad Request saved into Cache

Дело сделано, все следующие после этого трюка клиенты получают от кеша 400-й ответ.

- HTTP Meta Character (HMC)
Подобный к HHO вид, только в хедере вы добавляете мета символ, вроде \n, \r, \a. Кеш пропускает этот хедер на бекенд, который не может это обработать, и отвечает что-то типа Character not allowed и 400 Bad Request, все, кеш отравлен!

- HTTP Method Override Attack (HMO)
Этот метод как вы могли догадаться направлен на переопределение заголовка X-HTTP-Method. Далеко не все фреймворки/бекенды поддерживают X-HTTP-Method-Override, однако для тех кто поддерживают вы можете переопределить HTTP метод, проскочив кеш, например так:

curl -H "X-HTTP-Method-Override: POST" https://somesite.example.com/index.html получив в ответ "404 Not Found, POST on /index.html not found". Кеш опять отравлен, все остальные клиенты как и в примерах выше будут получать 404, вместо вашей стандартной страницы.

Будет справедливым вопрос: но, ведь на всех PoP(Point of Presence) наверняка уже лежат правильные ответы с 200ОК?
Все верно! Поэтому, злоумышленнику нужно проскочить со своим вредоносным реквестом в тот момент, когда на PoP закончился TTL обьекта, и PoP пойдет за ним на Origin сервер. Здесь просто пишется довольно незадачливый код, который в условном loop пытается отслылать свои реквесты на точку, в надежде на то, что вредоносный реквест будет первым после окончания TTL и отравит таким образом кеш. Это может занять не так много времени, как могло бы показаться.

Что происходит, если отравить одну точку CDN такими методами?
В зависимости от того как работает система внутреннего распространения кеша у того или иного провайдера, такой отравленный кеш как минимум расползется по ближайшим точкам присутствия в регионе, как максимум по всем PoP в мире. Но, теоретически, атакеру не сложно будет обнаружить все PoP провайдера и пройтись по каждой, чтобы отравить наибольшее количество точек.

Cache-Poisoned Denial-of-Service (CPDoS). Часть 2

Так, ну сейчас все используют CDNы! Мне бояться такого на продакшне или нет?
Хорошая новость тут в том, что атака известна с 2019 года, и многие крупные CDN научились с ней бороться.
Несмотря на то, что должно совпасть несколько условий со стороны ориджин сервера и CDN провайдера, наиболее уязвимым оказался AWS CloudFront, т.к. их настройки позволяли укладывать на лопатки в основном с помощью HHO и HMC огромную часть фреймворков и веб-серверов, включая S3 🙃. В итоге, они просто запретили кешировать ошибочные ответы от ориджина. Впрочем, большинство провайдеров начали делать тоже самое, либо выставляют очень маленькое время кеширования ошибочных ответов. Также были уязвимы Cloudflare, Akamai, CDN77, Fastly, но только в связке с IIS, ASP.NET, Flask и Play 1.

Еще один способ бороться с этим самостоятельно - это выставлять на все свои ошибочные ответы/страницы хедер Cache-Control: no-store.

Третий способ - выставить WAF перед вашим бекендом.

Так, ну мы вообще не используем никаких кешей перед бекендом, мне эти ваши CPDoSы побоку!
А вот и нет! Например известная опенсорс CMS Drupal имеет внутренний кеш, который подвержен подобным атакам. Только там все игрища происходят вокруг X-Forwarded-Host и Host хедеров, в которые можно вставить как свой хост, так и JS скрипты. Ресерчеры также накопали всякие более извращенные отравления типа DOM, CORS и прочих.

Тримаємося разом, зберігаємо спокій, віримо в ЗСУ!🇺🇦

Ban Russia from the Cloudflare

Repost + vote + comment 👇

Давайте девопсовые войска, погнали

https://www.linkedin.com/posts/bukovskyi-kostiantyn_cloudflare-and-lets-encrypt-josh-aas-and-activity-6904022489488601088-eNDM

Join DevOpsDays #StandWithUkraine on May 17-18!

During the conference, we would love to talk about DevOps during the crisis, incident, and business continuity management with our friends – Patrick Debois, Kris Nova, Kelsey Hightower, Lena Hall, Andrew Clay Shafer, and others.

18 talks from the world DevOps community are in the program and you’re welcome to Open Space Discussions as well, to share experience on complex cases with your peers.

When? May 17-18
Where? Online
👉 Sign up for free & find out the agenda here: https://devopsdays.com.ua