Комментарии 8
Нафига?
Для низких нагрузок всё можно сделать обычным способом в юзерспейсе.
Для высоких всё равно в итоге понадобится отдельная железка если хотите делать какие-то сложные фильтрации (ну сами подумайте: если у вас допустим даже 10 серверов и на каждом эти фильтры вперемежку с полезной нагрузкой — выгоднее будет сделать один сервер специально под фильтры а остальные 9 под нагрузку). И на этой железке незачем поднимать громоздкую ОС общего назначения.
От ddos-атак нужны в первую очередь не фильтры а широкий канал, потому что если вам заспамят весь канал то ничего вы с этим не поделаете вне зависимости от серверного софта/железа.
Нафига?
Именно этот проект — про XDP, защита от DDoS в нем как типовая задача.
И на этой железке незачем поднимать громоздкую ОС общего назначения.
Есть зачем: управлять защитой — mgmt, логи, обновления. ОС требуется убрать только от обработки пакетов, что позволяют техники kernel bypass: DPDK, netmap, ef_vi (Solarflare). Да, на них можно реализовать более навроченную логику, но и сделать это сложнее, чтом с XDP, потому что надо думать о распределении ядер, NUMA, конкурентных структурах данных, возможно, реализовывать или прикручивать стек TCP/IP (либо доставлять пакеты в ядро, типа DPDK KNI).
От ddos-атак нужны в первую очередь не фильтры а широкий канал
Ниже уже написали про канал, а вообще, от DDoS-атак нужно сочетание средств с сигнализацией между ними: 1) по максимуму срезать "облаком" и грубой очисткой у провайдера; 2) если атака дошла и каналы забиваются — сообщать аплинку сигнатуры/FlowSpec/сам факт.
Низкие нагрузки, отсутствие специфичной фильтрации — это в общем совсем не тот юзкейс, когда вам понадобится XDP, netmap, DPDK и остальные технологии обработки трафика. Они дают большие результаты, когда для вашего трафика вы можете придумать какие-то свои хитрые application-specific функции фильтрации трафика.
Вы действительно можете скинуть все функции фильтрации и балансировки на отдельную железку и освободить таким образом серверы приложений от паразитного трафика. Но с ростом нагрузки опять встанет вопрос с нехваткой производительности. Дальше либо наращиваем мощность сервера(-ов) фильтрации, либо оптимизируем софт. Либо вкладываем деньги в сервера и их обслуживание, либо платим программистам за оптимизацию и экономим на серверах. Банальный вопрос денег.
И вот если решили, что выгоднее оптимизировать софт, то как. Сейчас тут много вариантов, у каждого из которых свои плюсы и минусы, серебряной пули нет.
Вы можете использовать в качестве балансирощика и фильтратора специализированные железки типа cisco, juniper, whatever. Какие-то из них даже позволяют добавлять свои функции обработки трафика. Но это далеко не всегда гибко по возможностям, дорого само по себе и вероятность встретить такую железку у хостера, где вы держите свои сервера не очень высока.
Или использовать самое дешевое оборудование, которое есть у любого хостера — самые обычные X86 машины. Отказаться от ОС общего назначения на них вы все равно не сможете, поскольку кроме фильтрации вам все равно надо думать и об управлении аппаратным обеспечением, и о мониторинге, и об управлении, и о резервировании и еще о куче всего, как уже заметили. Даже специализированные коробки — это уже большей частью та же ОС общего назначения (те же cisco уже давно на Linux) плюс какая-то коммутационная фабрика. Как бы не был хорош сетевой стек ядра Linux, обработка трафика все равно выходит достаточно дорогой, и очень хочется ее оптимизировать. Один из популярных вариантов — вообще исключить ядро из обработки (kernel-bypass), но тут проблема в том, что весь сетевой стек вам надо реализовать теперь в юзерспейсе. Очень гибко, очень производительно, но чем больше фич стека вам надо поддерживать, тем жирнее и тяжелее становится ваш обработчик трафика. Тут можно наступить на две грабли: повязнуть в разработке стека или получить производительность, меньшую, чем у ядра.
Но зачем тащить второй сетевой стек, когда у нас уже есть один в ядре, и он хорошо поддерживается большим сообществом. Поэтому другой подход — оптимизировать стек ядра, и хотелось бы это делать так, чтобы не модифицировать код ядра самим. Логично, что если решение по блокировке трафика принимать как можно раньше, то накладные расходы можно значительно снизить. Или наоборот, если добавить свои функции обработки пакетов на ранних стадиях, но это может дать гораздо большую пользу на более поздних этапах обработки. Вдобавок XDP-программы могут взаимодействовать как друг с другом, так и с вашим юзерспейс-приложением. И практические результаты говорят о том, что XDP-программы пишутся не сложнее юзер-спейс приложений, но и в некоторых случаях не уступают DPDK.
Но с ростом нагрузки опять встанет вопрос с нехваткой производительности. Дальше либо наращиваем мощность сервера(-ов) фильтрации, либо оптимизируем софт.
Ну от этого никуда не деться, но в случае с отдельной железкой мы оптимизируем именно функцию фильтрации в ней (а уж софт это или железо — не всегда есть чёткая граница, в хороших железках есть спец. чипы для обработки пакетов без участия обычного проца и кстати никакой код в ядре ОС их не догонит по эффективности) и не думаем о том, как всё это отразится на остальном, потому что остальным эта железка не занимается. А на серверах приложений — оптимизируем выполнение юзерспейса и не думаем о фильтрациях (шлём фильтр-железке управляющие команды перенастройки фильтров если нало на лету это делать). По-моему это намного удобнее чем поддерживать комбайн который умеет всё.
вероятность встретить такую железку у хостера, где вы держите свои сервера не очень высока
Ну речь же не про домашнюю страницу на пхп на шаред хостинге. А чем больше нагрузка (и соответственно цена услуг) тем больше вероятность что у хостера по вашему заказу найдётся всё что вам требуется. А хоститься у тех кто даже крупному клиенту не может предложить индивидуальные условия я бы не стал с крупным проектом.
те же cisco уже давно на Linux
Не знал. Ну, видимо, финансовый аспект перекрывает всё остальное и воспользоваться не совсем подходящим решением но почти бесплатно — выгоднее чем делать подходящее, но вкладываясь.
eBPF вообще очень занятный механизм, сам ковырял правда несколько в ином применении — www.brendangregg.com/blog/2019-01-01/learn-ebpf-tracing.html.
Пишем защиту от DDoS-атак на XDP. Ядерная часть