Как защитить свое api от ddos-атак?

Question

[elmoreden]

Есть простое rest-api, нужно сделать защиту от ddos. Погуглил, внятного ничего не нашел. Подскажите, как защитить api?

Answer 1

[SKEPTIC]

Смотря что там за API у тебя. Вообще от самых абсурдных атак на канал берут обычно сторонний реверс прокси по типу cloudflare, ddos-guard, stormwall, qrator и прочее.

Но чаще всего это только пол беды. Остальные пол беды это уже более сложные атаки на приложение. Допустим у тебя какая-нибудь доска объявлений по продаже автомобилей, там куча фильтров, пагинация, и все прочее. Так вот на этот запрос к API и будет давить атакующий.

Вообще cloudflare дырявый в этом случае очень, он пропускает почти все. ddos-guard справляется частично, остальные вроде как тоже (слышал от людей, сам не юзал). Тут нужно понимать что на бесплатных или дешевых тарифах могут прошибать, на более дорогих тарифах защиты есть индивидуальная поддержка и фильтры, то есть инженеры почти в реалтайме будут отражать атаку на твой сервис если стандартные средства защиты не справляются.

Но также помимо защитников от атак это еще и битва сторон (атакующего и атакуемого), а еще точнее битва железом. У кого больше мощностей. Даже возьмем тот же самый случай с доской объявлений по продаже автомобилей. Есть куча способов как реализовать это, оптимизировать и все прочее. То есть если у тебя само приложение хорошо спроектировано и реализовано, есть оптимизация то атаку держать будет гораздо проще. Ну и конечно же тут играет роль твоя инфраструктура. Если сервак, на котором крутится приложение имеет ширину канала 100 мбит, 4 ядра и 4 гб RAM, то будет одна ситуация, а если ширина канала 10 гбит, 2 процессора по 32 ядра и 256 гб RAM то это уже совсем другая ситуация. Это конечно все очень образно, в реальности будет не один сервер, а несколько, а то и десятки и сотни серверов, каждый из которых состоит в группе, отвечающей за свою задачу, например за балансировку нагрузки, если нет managed балансировщика, за фронтэнд, за бекэнд, за базу, за кеш, за поиск и т. д.

Comments

[SKEPTIC]

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

Это очень странное заявление. Я со своего компьютера могу сгенирирать тысячи запросов в секунду к API, но не могу забить канал серверу. При этом чтобы положить API порой достаточно всего несколько сотен запросов в секунду, в то же время сервер находится в каком-нибудь условном селектеле, где по дефолту идет защита от атак на канал, поэтому это заявление неверно.

[SKEPTIC]

Justa Gain, это и не важно. В широком смысле атака не подразумевает уточнения DoS она или DDoS. Атака это то что приводит сервис в хреновое или вообще нерабочее положение. Как она выполняется - не важно, главное цель достигнута - приложение работает в аварийном режиме или вообще лежит.

Я могу бить по приложению со своего компьютера это будет DoS, а могу со своего компьютера и ноутбука - это будет уже DDoS. Но все мы прекрасно понимаем, что любой современный компьютер может убить на раз два неоптимизированное приложение без какой-либо защиты от атак.

По стоимости атаки не подскажу, но в здравом смысле дешевле атаковать приложение. Потому что мало мальский разработчик примерно понимает:

1) Ага, авторизация по паролю, значит там считается какой-то хеш, может быть bcrypt, который считается 150-200 ms и можно туда направить атаку.

2) Ага, есть много фильтров, значит будет поиск по базе, куча joinов и все прочее, давай туда атаку

И чтобы атаковать такой сервис тебе не нужны гигабитные каналы, а нужно мегабит 100 канала и просто обычный комп со средним процессором, чтобы генерировать хотя бы 500 rps.

[SKEPTIC]

Justa Gain, ну смотри. Я встал за cloudflare или еще куда. Пусть атакуют канал мне наздоровье))) Хоть 10к, хоть 100к ботов)

У этих защитников каналы терабитные, им похрену эти боты)

[SKEPTIC]

Justa Gain, но ты не забывай, что уже давно, а тем более сейчас ботнеты спокойно атакуют не только по каналу, но и по приложению.

Answer 2

[rPman]

Хочу напомнить - ddos это не только про сетевые атаки, а любые атаки, направленные на нарушение работы приложения,.. т.е. если злоумышленник найдет как заставить твоих операторов обрабатывать тысячи и миллионы заявок, которые никакой пользы не принесут (с них не будет получен доход) - то это тоже 'атака на отказ обслуживания', ведь операторы будут заняты фейковой работой вместо обслуживанием нормальных клиентов.

Готовых решений ты и не найдешь, кроме как от ограниченного типа атак (сетевых) и тут самому лучше не заморачиваться, а воспользоваться сервисом провайдера.

Правильная защита - это анализ твоей бизнес модели и ее процессов и тщательное тестирование на всех, включая нестандартных и необычных, ситуациях.

p.s. типовые направления атак ddos используют анонимные каналы, т.е. любые команды от анонимного пользователя, которые нельзя сгруппировать по их иннициатору (да хоть по ip адресу) - первые на проверку возможности для использования, вот их и проверяй, как можно раньше в бизнеспроцессах вводи авторизацию (пусть и прозрачную), лимитируй пользователей во всем на разумные количества действий (обычный человек не будет создавать сотню заявок на покупку унитазов, как минимум он создаст одну с пометкой количества).

p.p.s. ограничивая пользователей, всегда предлагай им действия, которые позволят этот лимит убрать, чтобы ошибочно наказанные пользователи не сидели перед экраном - 'вы забанены, идите на..й'

Answer 3

[AUser0]

Если API - то вряд ли его будут DDoS-ить, с его минимальным трафиком.

А с одного IP несколько одновременных коннектов возможны? А то можно в IPTABLES поставить лимит на коннекты.

Ну и на уровне HTTP-сервера фильтровать мусорные запросы, если это Nginx.