Пишем защиту от DDoS-атак на XDP. Ядерная часть

Нафига?

Именно этот проект — про 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.