Как эффективно управлять XDP/EBPF для лучшей защиты от DDOS

[Превью прямого эфира] Смогут ли крупные модели заменить программистов? "

Расширенный фильтр пакетов Беркли ( eBPF ) можно быстро и непрерывно обновлять, что делает его идеальным для обработки частых изменений конфигурации безопасности.

Перевод книги « Как эффективно управлять XDP/eBPF для лучшей защиты от DDoS» , автор Иван Ковешников.

Карта расширенного фильтра пакетов Беркли ( eBPF ) служит высокоуровневым интерфейсом для атомарных обновлений сегментов общей памяти, используемых в качестве общей памяти, и обеспечивает мощный интерфейс настройки для программ eBPF. Механизм чтения-копирования-обновления минимизирует издержки производительности на «горячем» пути. Кроме того, сопоставление eBPF обеспечивает монопольный доступ к сегментам общей памяти. Они могут обрабатывать смешанные типы карт (массивы, хэш-таблицы, фильтры Блума, очереди и кольцевые буферы), что делает их идеальными для сложных конфигураций, таких как безопасность .

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

Примените XDP для расширенного управления трафиком

Рассмотрим простую программу eXpress Data Path (XDP) , которая классифицирует и фильтрует трафик на основе набора правил из пяти приоритетов. Программа обрабатывает следующий пакет на основе приоритета правила и комбинации IP-адреса источника, IP-адреса назначения, протокола, а также портов источника и назначения.

Блок-схема классификации, ведущей к обработке.

Ниже приведен пример правила конфигурации сети:

Любой трафик из подсети A всегда разрешен.
Запретите клиентам в подсети C доступ к веб-серверу в подсети B.
Ограничьте доступ к веб-серверу в подсети B.
Все остальные доступы запрещены.

Эти правила требуют сохранения правил и ограничений классификации трафика в конфигурации, чего можно добиться с помощью сопоставлений eBPF.

Понимать конфигурацию программы eBPF как древовидную структуру.

Конфигурацию можно представить в виде иерархического дерева с «корнем конфигурации» в качестве основы. Этот корень (возможно, виртуальный) организует различные объекты конфигурации для формирования активной конфигурации. Сущности либо напрямую связаны с корнем для немедленного глобального доступа, либо вложены в другие сущности для структурированной организации.

Доступ к определенному объекту начинается с корня и продолжается последовательно («разыменование» каждого уровня) до тех пор, пока не будет достигнут желаемый объект. Например, чтобы получить логический флаг из структуры «options» в коллекции, вам нужно перейти к коллекции, найти структуру, а затем получить флаги.

Подход Gcore к решению сложных задач eBPF

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

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

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

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

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

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

Политика обновления конфигурации безопасности

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

Обновление Стратегии 1: Постепенный переход

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

Например, в контексте классификации и обработки уровень классификации предоставляет ключи поиска для соответствия политикам безопасности, а это означает, что операции обновления должны следовать определенному порядку:

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

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

Мы рекомендуем выполнять дополнительные обновления, а не обновлять всю карту сразу. Например, инкрементные обновления хэш-карт и массивов совершенно безопасны. Однако это не относится к инкрементальным обновлениям карты с совпадением самого длинного префикса (LPM), поскольку поиск зависит от элементов, которые уже есть на карте. Та же проблема возникает, когда для создания ключа поиска для другой таблицы требуется работать с элементами из нескольких карт.

Уровни классификации часто реализуются с использованием нескольких LPM и хеш-таблиц, что является примером такой сложности:

Поиск осуществляется от классификации к LPM и хешированию, а также от классификации к обработке и хешированию с описанием проблемы обновления сопоставления.

Стратегия обновления 2: замена сопоставления

Для сопоставлений, которые не могут быть постепенно обновлены без противоречий (например, сопоставления LPM), лучшим решением является замена всего сопоставления. Чтобы заменить сопоставление программы eBPF, вам необходимо сопоставление. Приложение пользовательского пространства может создать новую карту, заполнить ее необходимыми записями, а затем атомарно заменить старую карту.

В результате сопоставления создаются два узла с возможностями изоляции и замены ресурсов.

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

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

Стратегия обновления 3: Замена программы

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

Чтобы решить эту проблему, атомарные обновления должны происходить на более высоком уровне. Хотя в eBPF отсутствует механизм атомарной замены набора сопоставлений, сопоставления обычно связаны с конкретной программой eBPF. Эту проблему можно решить, разделив взаимосвязанные сопоставления и соответствующий код на отдельные программы eBPF, связанные хвостовыми вызовами.

Блок-схема сопоставления конвейера пакетов с программами, в результате чего создается заменяемый код и пакеты сопоставления для программ eBPF.

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

Обработка ошибок

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

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

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

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

Управляйте жизненным циклом программы eBPF для получения обновлений.

Отслеживание жизненного цикла программы eBPF имеет решающее значение для программ, которым требуется постоянство, частые обновления и сохранение состояния в различных экземплярах кода. Например, если ваша программа XDP требует частого обновления кода при сохранении существующих клиентских сеансов, эффективное управление ее жизненным циклом имеет решающее значение.

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

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

Существует два распространенных способа реализации переходов:

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

Карта сетевого интерфейса (NIC) подключается к планировщику, карте программы и карте состояний, что приводит к фактической конфигурации программы.

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

в заключение

Благодаря программированию eBPF/XDP компания Gcore расширила границы сетевой безопасности и оптимизации производительности. Наше путешествие демонстрирует нашу приверженность борьбе с возникающими угрозами с помощью расширенных возможностей eBPF/XDP. Продолжая совершенствовать ядро обработки пакетов, мы стремимся предоставлять передовые решения, которые помогают поддерживать надежность и гибкость сетей наших клиентов.

Эта статья была впервые опубликована на Yunyunzhongsheng ( https://yylives.cc/ ), приглашаем всех посетить ее.