Информация

Дата основания
Местоположение
Россия
Сайт
cleantalk.org
Численность
2–10 человек
Дата регистрации

Блог на Хабре

Обновить
Комментарии 21
Навскидку глядя на схему — что мешает получить куку ct_anti_ddos_key, а потом атаковать сайт, подставляя ее в запросы?
Ничего не мешает, но это усложняет техническую реализацию атаки, т.к. есть привязка куки к IP адресу атакующего.

Приведенную выше схему можно рассматривать как один из элементов защиты от DDoS, если включить в начале атаки, то выиграете время на усиления анти DDoS защиты.
привязка к IP адресу очень упрощает техническую реализацию. У вас для запросов с одного IP отдается одна и та же кука!
Вы поди за отражение атак ещё и деньги берете?
Коллега, все что сложнее потребует поддержку систем хранения данных, а это уже будет не универсально и гораздо менее производительно чем сейчас.

И никто не мешает усложнить JavaScript код под конкретный сайт.
добавьте хотя бы TTL в метку, что бы она жила не более пары минут
TTL для tcp? Если так, то не вижу способов влиять на TCP пакеты из PHP/JavaScript кода.
Время жизни ключа. Не время жизни куки. Кроме IP добавляете к ключу время создания, в PHP при проверке определяете время создания ключа, если с момента его создания прошло некоторое время — считаете его не действительным.
Теперь идея понятна, в принципе реализуема там же в куках! Возьму на заметку.
1. ab это очень синтетика, как минимум потому что без keep-alive, если нападающий будет держать соединение, бекэнд у вас очень быстро закончится
2. кука в JS ставится так топорно что с парсером справится даже начинающий, и нет больше вашей защиты
3. зачем пользователя задерживают на 3 секунды? только для того что бы он прочитал о вашей крутой системе?
4. в описанном вами случае достаточно было настроить кеширование на несколько минут на стороне nginx по любой статье из поисковика. На той странице нет персонализированных данных, данные обновляются относительно редко, нет смысла дергать бекэнд на каждый запрос.
1. В случаи небольших DDoS атак возможности веб-серверов по количеству одновременных соединений выше количества атакуемых.
2. Не спорю, этот вариант с JS кодом не сложен. Но тем не менее позволит выиграть время.
3. 1 секунду и менее показывать не правильно с точки зрения посетителя сайта, т.к. он не успеет понять почему он вдруг мельком увидел какую-то другую страницу вместо ожидаемой.
4. Одно другому не мешает.
боты участвующие в DDoS атаках не способны выполнить JavaScript код
Ну, это вам повезло так. Не факт, что каждый раз будет везти.
Выполнение JavaScript затратная и не дешевая операция. Есть реальные примеры таких атак? Не поделитесь кейсами?

Был опыт преднамеренного усложнения JavaScript кода в целях исчерпать ресурсы атакующих?
В современном браузере поверх Javascript можно Windows 98 запустить. Так что тезис про затратность — он, конечно, в некотором смысле справедлив, но всё относительно.

Идея в том, что исполнитель DDoS-атаки за потребляемые ботами ресурсы не платит, так как бот — это просто malware на компьютере какого-нибудь незадачливого пакистанского — или же рязанского — гражданина. Поэтому переживать насчёт пары JS-редиректов никто не будет. Даже вот Хабр и тот больше JS выполняет, как я посмотрю, не говоря уже о Facebook и Gmail (которые вообще обычно у людей просто резидентно в фоновых вкладках работают, и никто на этот счёт не переживает).
Не у всех Nginx веб-сервером и не все имеют доступ к его настройкам (shared hosting).

Решение с 1 include в index.php проше и универсальнее.
Выглядит, скорее, как костыль, чем как решение :-\
Но мне вообще сложно представить себе сколь либо сорьёзный сайт, который пытается защититься от DDOS сидя на shared хостинге и не будучи прикрытым nginx — видимо я мало знаю жизнь :)
Решение в принципе просто и лучше чем ничего. Могу указать на сопутсвующие проблемы.
Защита должна отсеять ботов но пропустить нормальных клиентов.
Ваше решение будет отсеивать все запросы Ajax и не GET после смены клиентом IP-адреса. Это довольно частое явление, т.к. клиент может перейти их одной сети Wi-Fi в другую сеть или же перейти на мобильный интернет и вернуться отять в Wi-Fi. При некотроых настройках эта ошибка появляетя и в том модуле на С++ на который есть ссылка выше в комментариях. Приходилось снимать IP из анализа чтобы ее избежать. Но это ослабляет защиту.
Кстати показывать страницу с текстом совсем не обязательно. Можно закрузить пустую страницу со скриптом в котором вызвать перегрузку через скажам 0,2 с.

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

Наиболее оптимально делать то же примерно самое но на скриптовом движке Lua, который уже встроен в nginx и в собранном виде доступен при инсталляции nginx-extras или же openresty.
Смена IP адреса приведет к повторной выдачи стоп-страницы, что не приятно, но не критично для посетителя.

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

Статичные ресурсы отдаются веб-сервером, а его производительность на порядки выше чем PHP бекенда. Т.е. в условия DDoS атаки менее 1к пакетов в секунду, это не будет проблемой.

Опять же Nginx хорошо, но не все его используют, либо не все имеют доступ к его настройкам.
Это не совсем так. Код API на php могут вызывать по Ajax которые не пергружают страницу. И прегрузка reload() страницы по запросу POST приведет к потере тела запроса. Т.к. reload() делает запрос GET.
Я не спорю что такое решение как у Вас лучше чем ничего. Но по опыту работы с клиентами знаю что когда Ваша зщита отразила атку никто не будет входить в подробности о том что сервис отразил атаку. Это остается за кадром. Но начинаются вопросы о том что наш клиент написал в поддрежку что сайт не работает, сделайте наконец что нибудь.
У реальных посетителей, стоп-страница будет 1 раз за посещение сайта, время показа можно варьировать по необходимости.

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