LINUX.ORG.RU

Что есть против DDoS?


0

2

Пусть есть ботнет в 5-10 тысяч машин. И есть сайт на Rails (плюс thin-кластер и nginx во фронтенде). Такая схема хорошо держит до 80 запросов в секунду.

Что можно сделать против атаки?

Пока режу число подключений в секунду с одного ip. Но боюсь что при таком ботнете этого не хватит.

Что почитать? Сколько вообще должна держать такая система? Есть ли смысл разносить всё на несколько машин (пока всё в cpu упирается)? На сколько машин?


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

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

Мануалы прочёл. Мне не ясно как рассчитывать нагрузку и во сколько эти 5000 машин обойдутся конкурентам.

daris
() автор топика

есть чуваки, через которых можно за деньги пропускать трафик, хитро фильтруя

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

Загугли, есть такие специализированные компании, давненько приходилось пользоваться услугой одной из таких, сейчас не вспомню какой именно. Это относительно дорого и цена, наверное, зависит от трафика, тогда обошлось вроде около $2000-3000 за месяц, если мне не изменяет память.

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

Мде. Дешевле будет серверов докупить. Но всё равно спасибо, попробую пройтись по логам на предмет айпишников.

daris
() автор топика

Что есть против DDoS?

Ничего нет.

Пока режу число подключений в секунду с одного ip

А это и есть успешная атака. Отказ в обслуживании нужного пользователю числа подключений.

Сколько вообще должна держать такая система

Должна держать неограниченное число запросов.

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

Пока режу число подключений в секунду с одного ip

А это и есть успешная атака. Отказ в обслуживании нужного пользователю числа подключений.

Я режу слишком частые подключения для всех. Но мне, как юзеру, такое ограничение не мешает.

daris
() автор топика
Ответ на: комментарий от iSage

Неверно выразился, похоже. Если натравить siege, нормально отдаёт страницы при нагрузке до 900 одновременных подключений. 80 же - это среднее число обработанных за секунду подключений.

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

Вообще, тестить siege и ab - некомильфо, лучше jmeter'ом. тут еще вопрос в том, за сколько он при такой нагрузке отдает страницы.

Если таки упирается в бэкэнд - реж, кешируй, разделяй, ставь балансировщики. Если в сетевой стек и канал - тады ой, магистральное оборудование в помощь.

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

Всё упирается в проц. ВДС с более чем двумя ядрами - это дорого, дешевле выйдет несколько машин купить %)

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

Ну так в проц то по разным причинам может упираться. Из-за бекэнда, из-за базы, из-за обработки тучи сетевых пакетов.

iSage ★★★★
()

тут правильно подсказывают про кеширование

redixin ★★★★
()

Против атак такого рода обычно делают следующее. Если входной канал справляется то разрабатывается алгоритм который отделяет мух от котлет. Критериев множество: geoip, request rate, cookies, итд итп. После этого хосты банишь через ipset какой-нить. Можно сразу банить, например, Китай :).

Только вот если речь идёт о VDS то ой. А вот если выделенный сервак то у нас тачка (по современным меркам не фонтан, всего 2 проца старого поколения по 4 ядра) справлялась с почти гигабитным флудом. Увы, не помню сколько было packets per seconds.

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

Ну и кеширование тоже нужно. А точнее комплекс мер направленный на увеличение производительности сайта. Так же на время атак мы отключали некоторые особо жрущие части сайта. А ещё было такое что злоумышленники специально посылали сложные запросы которые выжирали проц (поиск там, ещё всякая фигня).

true_admin ★★★★★
()

ossec - не как панацея конечно, но как комплексная мера вполне.

anonymous_sama ★★★★★
()

80 запросов в секунду.

О боги, это все, чего достигло человечество? Я думал, что стандартная цифра на 2-3 порядка больше

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