LINUX.ORG.RU

Защита от DDoS

 ,


1

2

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

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

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

v9lij ★★★★★ ()

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

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

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

edigaryev ★★★★★ ()

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

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

Vit ★★★★★ ()
Ответ на: комментарий от v9lij

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

Booster ★★ ()
Ответ на: комментарий от Booster

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

edigaryev ★★★★★ ()
Ответ на: комментарий от edigaryev

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

Booster ★★ ()
Ответ на: комментарий от Booster

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

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

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

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

edigaryev ★★★★★ ()
Ответ на: комментарий от Booster

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

Vit ★★★★★ ()
Ответ на: комментарий от Booster

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

Память.

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

edigaryev ★★★★★ ()
Ответ на: комментарий от edigaryev

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

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

Booster ★★ ()
Ответ на: комментарий от edigaryev

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

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

Booster ★★ ()
Последнее исправление: Booster (всего исправлений: 1)

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

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

devops ()
Ответ на: комментарий от devops

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

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

Shaman007 ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.