Защита от DDoS

Есть сервер и нужно защитить его от атак на уровне самого сервера.

Ничего у тебя не получится. Чтобы твой сервер мог дропнуть пакет, он его вначале должен принять, а это и ведет к ддосу.

Если под «атакой на уровне самого сервера» понимается то, что канал связи насыщен не полностью — то ответ зависит от типа атаки (на сетевой стек, на приложение и т.д.) и ресурсов, которые ты готов на потратить на защиту от неё.

Порой достаточно распределить между ядрами обработчики прерываний и подкрутить sysctl (только не стоит вбивать сразу все настройки из первого найденного «руководства по тюнингу», лучше сначала разобраться где bottleneck и на что влияет та или иная настройка).

Для фильтрации, скажем, 10 Gbit/s TCP-флуда скорее всего потребуется работать с кольцевыми буферами сетевой карты напрямую, из-за того, что сетевой стек большинства ОС разрабатывался для general-purpose применения.

Как-то так http://pastebin.com/3rScbRnm

Режется частота новых соединений с одного IP. От школодосов хватает за глаза. Не ловит долбежку через keep-alive, но это можно на nginx порезать.

Это на уровне самой системы, мне пока нужно на уровне приложения.

Все так, но можно тупо не принимать больше входящие пакеты если их перебор. Понятно что это не решение, но тем не менее все лучше.

Без подробностей о том, как твой демон обслуживает клиентов, и реального сценария атаки — разговор ниочем.

Протокол очень простой - отравка пакета и получение ответа на него. Между отравкой и получением может пройти много времени. Основная задача не упасть от атаки и контролировать ресурсы.

Протокол очень простой - отравка пакета и получение ответа на него. Между отравкой и получением может пройти много времени.

Это все что ты можешь сказать? Соединение все это время висит? Возможно ли убрать необходимость держать соединение открытым aka stateless protocol?

Основная задача не упасть от атаки и контролировать ресурсы.

О каких ресурсах идет речь?

О каких ресурсах идет речь?

Память.

Ну сделай все то же самое, но на уровне приложения.

Что насчет остальных вопросов? Не понимаю, почему это нужно из тебя вытягивать.

Память.

Любой пользователь интернета может расходовать эту самую память, или есть какая-то аутентификация?

Протокол stateless. Соединение должно висеть в течении одной пары отправки/приема, но клиент может не отключатся между сессиями. Не буду же я на сервере специально рвать соединение и на что это повлияет? На крайняк поставлю ограничение на общее количество входных сообщений, но интересно как это делается в грамотных приложениях.

Аутентификации пока нет, но даже если и будет, то вопрос все равно не о этом. Задосить все равно можно.

Поясню текущую проблему более развернуто, поначалу я сам ее не полностью понимал.

Меня высмеяли, что мол мой сервер ддосится. А проблема совсем не простая. Есть простой протокол: клиент послал запрос, сервер ответил. Сервер может принимать запросы пока предыдущие необработаны, так как может уйти много времени на их обработку, но сервер старается. Даже если клиент не ддосит, то количество запросов может расти по отношению к ответам и мы получим ддос. Допустим у нас есть ограничение сверху на количество запросов и в случае превышения мы отправляем клиенту ответ, что сервер сейчас занят. Это хорошо. Но это не решает проблему в случае реального ддоса. Если мы будем отсылать ответы на ддос запросы, которые не принимаются с другой стороны, то у нас проблема. Можно поставить таймаут на посылку, но это недорешение. Дать гарантию, что нас незаддосят быстрее чем пройдет таймаут довольно сложно.

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

Ты пытаешься остановить лавину с помощью маленькой лопаты?

Наличие stateful firewall, уже само по себе может стать вектором атаки.

По теме: любая атака - вопрос не столько технический, сколько экономический. Если сервис приносит доход, то надо выделять часть средств на его защиту, потому что простой ответ на вопрос «как защититься самостоятельно» - никак. Ты не занимаешься этим каждый день, а вот атакующая сторона - занимается и она всегда будет на шаг впереди, ведь заливать можно от пакетов и соединений до поиска. Если нет, то и атаки тоже скорее всего не будет, так как она стоить хоть и незначительных, но средств.

Шура Балаганов всё ещё пилит «клиент-серверное приложение в качестве теста для одной конторы» ? :))))

Шура он такой. ))))