С этим любая система на рынке борется, вот только называется это таки L3 - не по MAC-адресам фильтруете же.
В частности по vlan, есть еще пару интересных трюков, которые мы используем. Это все детали, я понимаю что в статье нет всего контекста. Она обзорная и будет таковой. Если вам интересно зачем мы и такое делаем, то в дальнейшем планируем описывать уже и что-то такое. Подождите. Не все сразу.
Вы же свое решение описываете, причем тут какие-то статьи из интернетов?
Мы не ставили задачу статьи сравнивать eBPF и DPDK. Информация есть в интернете, ее достаточно много, и она достаточно полная. На наш взгляд: что-то делает хорошо одно, что-то другое, а что-то лучше делать на уровне ядра, а что-то уже на L7 proxy – и оно все вполне может друг другу помогать бороться. Т.е.: за сравнением не в эту статью.
Далее, вот возьмем вполне себе типовую задачу - нужно отслеживать установленные соединения по 5-tuple (conntrack в терминах iptables), причем для разных состояний соединения - это ключевое! - иметь разный таймаут его протухания (скажем 300 секунд для проверенных, 20 секунд для еще нет). Так вот, в eBPF подход “жрите что дают” - есть только LRU-мапы, где вытесняться будет как оно там внутри захочет, а не по административному критерию. В полноценной системе решается довольно просто - в каждой записи имеем поле expire и при его обновлении просто перелинковываем запись в голову связного списка соответствующей секунды, дальше 1 (один) таймер просто ходит по ним и удаляет их. Но в eBPF-мапах никаких связных списков НЕТ. В результате надо либо городить сложные схемы с индексацией одной мапы другой, и всё равно упереться в лимит работы на одном eBPF-таймере, либо встраивать собственный таймер в каждую запись (дорого и по памяти и по шедулингу), либо отдавать чистку протухших в юзерленд - тоже дорого. Когда я в DOSGATE работал, там на каждый чих и чуть что, работа отдавалась из ядра в юзерлендный демон, потому что ну очень больно работать с ЭТИМ, слишком многое нельзя.
Насчет багов: я не знаю ПО без багов, не могу это комментировать. Технология в любом случае развивается -- в частности появляются и структуры данных и более удобные способы взаимодействия с kspace/uspace.
Конкретно в eBPF-программах мы стараемся иметь минимум стейтов (это грубый флильтр; тонкий фильтр, где достаточно много стейтов, уже другие технологии) – и его задача: где-то сделать PASS, DROP (на эйджаx), а где-то пройти более сложную логику -- например в транзите. Кстати это одно из хороших свойств технологии: можно один и тот же код использовать как для CDN Edge (на которых не охота выделять отдельные ресурсы), так же и для транзита и отдельных серверов.
Насчет структр данных: фактически все делаем по верх map (но далеко не все).
Кстати, можем подумать про статью на тему: eBPF и нюансы структур данных, я думаю она будет интересной и необычной. Насколько я знаю таковых материалов немного.
Плюс: eBPF активно развивают свои структуры (у них есть single ownership list c ЕМНП 7й версии ядра). Наверное, минус только в том, что надо иметь свежее ядро, и быть готовым его обновить. Опять же: нюансы использования структур там не являются блокером и предметом этой статьи. Простым bash-скриптом можно положить сервер, это же не означает что нужно перестать пользоваться bash?
От uspace приходят только уведомления об изменения правил фильтрации, перезагрузи программ, кое что для работы. Т.е.: синхронизации uspace/kspace происходят дозировано, под контролем (думаю понятно почему, это дорогая операция, ее нужно правильно сегментировать).
Ключевое, что делает eBPF-элемент: чистит большую часть DDoS-трафика (с минимальным стейтом и задержкой, и практически не оказывает влияния на конкретный сервера), далее уже более тонкая фильтрация, которая конечно уже более дорогая.
Я просто делаю вывод, что в вашей системе, скорее всего не более чем статические ACL по сути (пополнение/чистку мапы из юзерленда мы относим к статическим, это не динамический conntrack).
Она обзорная, а вы разбираетесь в предмете, отчего логичный вывод. Однако: далеко и не только, но и не без этого. Есть в частности сложные вещи вроде loginapp, mcr, sorb, rl и много чего с опциональным TTL. Конечно это реализовано крайне филигранно на уровне BPF tail call’ов и с учетом еще ряда нюансов. Все контрмеры мы замеряем на перформанс, не без этого.
Но опять же: eBPF и наша инфраструктура действительно может переживать (и уже передиживал) огромные атаки.
Прошу понять одну вещь: это точка входа, задача которой задешево (в пересчете на ресурсы) с минимально возможным импактом на латенси откинуть большую часть DDoS’а на конкретном сервере или группе серверов (которых у нас очень-очень много), но не все контрмеры только там (это было и в статье), работу делают и другие подсистемы – вплоть до L7 (самый дорогой в пересчете на ресурсы уровень).
Я думаю вы понимаете, что чем выше уровнь фильтрации, тем выше ее стоимость – и тем меньше пропускная способность в пересчете на железо. А заливать все отдельными серверами с DPDK-софтом, который умеет сразу все со сложной конфигурацией не выгодно, для CDN'а уже просто сложно. Отчего: мы посчитали, что логичнее условно так: eBPF <-> DPDK <-> L7 Proxy <-> origin, где каждый элемент самодостаточный и делает то, что он хорошо умеет. Фактическая формула такая: до L7 proxy должны доходить проценты DDoS, а для origin сотые проценты -- т.е. небольшой фон. Все это условно, но думаю логика понятно.
Посему: думайте об этом как о элементе большой системы, и опять же: когда мы говорим о тарабитных атаках – это не один сервер, не одна технология и не одна точка фильтрация, и конечно не один пиринг, и даже не одна страна.
Но вопросы интересные. Точно понял, что нужно описывать все уровни более детально (что кстати мы планировали делать, как появиться время). Данная статья в целом обзорная – тоже прошу это учитывать.
PS: Но на митап забегайте, мы с коллегами по цеху хотим обсудить в частности проблему шаринга информации о контрмерах и атаках между бигтехами и проблему залития стыков операторов атаками (недавно пообщались на круглом столе, кажется эти проблемы мало обсуждают открыто).
вышеописанные варианты не включаю в себя ряд компонентов и технологий, для обеспечения непрерывной работы высоконагруженной системы 24/7. Варианты описывают необходимый минимум, так сказать.
Оба подхода имеют место в современной архитектуре, какой вариант лучше — вопрос дискуссионный и, кмк, не является предметом данной дискуссии. Однако, очевидно — из сравнения выше -, что конфигов и логики во «2-м варианте» меньше.
Ну у тебя задача другая, а именно, хранить Хиты. А тут хранить консистентно запросы. У вас цели иные.
Твою задачу можно решить проксированием каждого хита в ClickHouse прям из nginx, я бы сделал так :)
Ну непропорционально — это мой тезис.
С очередью будет выглядит так: демоны который читает и пишет (возможно это сам nginx), отдельный демон очереди. Итого — большая система получается, плюс очередь не != БД, но это ты и сам заметил :)
С этим все хорошо (есть прав пользователей, соль в протоколе https://tarantool.org/doc/dev_guide/internals_index.html).
Так же можно все это пустить через ssl туннель.
Привет,
В частности по vlan, есть еще пару интересных трюков, которые мы используем. Это все детали, я понимаю что в статье нет всего контекста. Она обзорная и будет таковой. Если вам интересно зачем мы и такое делаем, то в дальнейшем планируем описывать уже и что-то такое. Подождите. Не все сразу.
Мы не ставили задачу статьи сравнивать eBPF и DPDK. Информация есть в интернете, ее достаточно много, и она достаточно полная. На наш взгляд: что-то делает хорошо одно, что-то другое, а что-то лучше делать на уровне ядра, а что-то уже на L7 proxy – и оно все вполне может друг другу помогать бороться. Т.е.: за сравнением не в эту статью.
Насчет багов: я не знаю ПО без багов, не могу это комментировать. Технология в любом случае развивается -- в частности появляются и структуры данных и более удобные способы взаимодействия с kspace/uspace.
Конкретно в eBPF-программах мы стараемся иметь минимум стейтов (это грубый флильтр; тонкий фильтр, где достаточно много стейтов, уже другие технологии) – и его задача: где-то сделать PASS, DROP (на эйджаx), а где-то пройти более сложную логику -- например в транзите. Кстати это одно из хороших свойств технологии: можно один и тот же код использовать как для CDN Edge (на которых не охота выделять отдельные ресурсы), так же и для транзита и отдельных серверов.
Насчет структр данных: фактически все делаем по верх map (но далеко не все).
Кстати, можем подумать про статью на тему: eBPF и нюансы структур данных, я думаю она будет интересной и необычной. Насколько я знаю таковых материалов немного.
Плюс: eBPF активно развивают свои структуры (у них есть single ownership list c ЕМНП 7й версии ядра). Наверное, минус только в том, что надо иметь свежее ядро, и быть готовым его обновить. Опять же: нюансы использования структур там не являются блокером и предметом этой статьи. Простым bash-скриптом можно положить сервер, это же не означает что нужно перестать пользоваться bash?
От uspace приходят только уведомления об изменения правил фильтрации, перезагрузи программ, кое что для работы. Т.е.: синхронизации uspace/kspace происходят дозировано, под контролем (думаю понятно почему, это дорогая операция, ее нужно правильно сегментировать).
Ключевое, что делает eBPF-элемент: чистит большую часть DDoS-трафика (с минимальным стейтом и задержкой, и практически не оказывает влияния на конкретный сервера), далее уже более тонкая фильтрация, которая конечно уже более дорогая.
Она обзорная, а вы разбираетесь в предмете, отчего логичный вывод. Однако: далеко и не только, но и не без этого. Есть в частности сложные вещи вроде loginapp, mcr, sorb, rl и много чего с опциональным TTL. Конечно это реализовано крайне филигранно на уровне BPF tail call’ов и с учетом еще ряда нюансов. Все контрмеры мы замеряем на перформанс, не без этого.
Но опять же: eBPF и наша инфраструктура действительно может переживать (и уже передиживал) огромные атаки.
Прошу понять одну вещь: это точка входа, задача которой задешево (в пересчете на ресурсы) с минимально возможным импактом на латенси откинуть большую часть DDoS’а на конкретном сервере или группе серверов (которых у нас очень-очень много), но не все контрмеры только там (это было и в статье), работу делают и другие подсистемы – вплоть до L7 (самый дорогой в пересчете на ресурсы уровень).
Я думаю вы понимаете, что чем выше уровнь фильтрации, тем выше ее стоимость – и тем меньше пропускная способность в пересчете на железо. А заливать все отдельными серверами с DPDK-софтом, который умеет сразу все со сложной конфигурацией не выгодно, для CDN'а уже просто сложно. Отчего: мы посчитали, что логичнее условно так: eBPF <-> DPDK <-> L7 Proxy <-> origin, где каждый элемент самодостаточный и делает то, что он хорошо умеет. Фактическая формула такая: до L7 proxy должны доходить проценты DDoS, а для origin сотые проценты -- т.е. небольшой фон. Все это условно, но думаю логика понятно.
Посему: думайте об этом как о элементе большой системы, и опять же: когда мы говорим о тарабитных атаках – это не один сервер, не одна технология и не одна точка фильтрация, и конечно не один пиринг, и даже не одна страна.
Но вопросы интересные. Точно понял, что нужно описывать все уровни более детально (что кстати мы планировали делать, как появиться время). Данная статья в целом обзорная – тоже прошу это учитывать.
PS: Но на митап забегайте, мы с коллегами по цеху хотим обсудить в частности проблему шаринга информации о контрмерах и атаках между бигтехами и проблему залития стыков операторов атаками (недавно пообщались на круглом столе, кажется эти проблемы мало обсуждают открыто).
вышеописанные варианты не включаю в себя ряд компонентов и технологий, для обеспечения непрерывной работы высоконагруженной системы 24/7. Варианты описывают необходимый минимум, так сказать.
А давайте посчитаем, на примере систем построеных на PostgreSQL.
1-й вариант:
[DNS Balancer, (?)] + Nginx (конфиги + логика) + Application (конфиги + логика) + (Тут иногда HAProxy) + pgbouncer (конфиги) + (тут иногда HAProxy и еще один pgbouncer) + pg-кластер (конфиги + иногда хранимые процедуры — логика).
2-й вариант:
[DNS Balancer, (?)] + Nginx (конфиги) + Tarantool-кластер (конфиги + логика).
Оба подхода имеют место в современной архитектуре, какой вариант лучше — вопрос дискуссионный и, кмк, не является предметом данной дискуссии. Однако, очевидно — из сравнения выше -, что конфигов и логики во «2-м варианте» меньше.
Смотря под какую ОС. Заходите в чатик (ссылку дал в первом коменте), расскажу и покажу как собрать.
Разработка ведется по Mileston'ом, они открыты, ссылка: https://github.com/tarantool/tarantool/milestones
Сырые идеи, готовые и т.п. можно глянуть на вики: https://github.com/tarantool/tarantool/wiki
Обсуждения новых идей происходит в чате: https://t.me/tarantoolru
Твою задачу можно решить проксированием каждого хита в ClickHouse прям из nginx, я бы сделал так :)
С очередью будет выглядит так: демоны который читает и пишет (возможно это сам nginx), отдельный демон очереди. Итого — большая система получается, плюс очередь не != БД, но это ты и сам заметил :)
lua garbage collector плохо переживает много lua таблиц (в твоем коде — box.space.tours:pairs()).
Проблема 1 в 1 была когда мы делали Facebook linkbech, часть хранимой пришлось переписать на C, чтобы избавиться от этих эффектов.
Как вариант rust, C или попробовать наш SQL (который в альфа)
Так же можно все это пустить через ssl туннель.
PS написал в личку свои контакты.