Комментарии в блоге "Битрикс - Сергей Рыжиков" на "Новая версия 8.0: Проактивная защита"

Комментарии на "Новая версия 8.0: Проактивная защита" от Алексей Булгаков

Mon, 04 Jul 2011 13:32:40 +0400

====quote====
В течение времени блокировки пользователю будет выдаваться 503 ответ сервер, т.е. сервер занят и не может обрабатывать запросы. Все остальные пользователи смогут работать с сайтом совершенно нормально.
=============
Есть одна проблема - в некоторые моменты этот ответ выдается всем посетителям, при этом в логах ничего не прописывается.

А еще некоторое пожелание к настройкам - сделайте возможность создания нескольких правил, например:
1. в течении 10сек сделано более 15 хитов - блокировать на 60 сек
2. в течении 600сек сделано более 100хитов - блокировать на 120сек
3. в течении 3600сек сделано более 1000 хитов - блокировать на 24часа (или даже создать правило для стоплиста)
1 и 2 - это скорее всего слишком активные посетители, которым практически не интересно содержимое сайта, а вот 3 правило - это бот, который просто выкачивает сайт, создавая лишнюю нагрузку
и сейчас можно отсеивать только первых или только вторых, а желательно обе группы

Комментарии на "Новая версия 8.0: Проактивная защита" от Денис Воробьев

Fri, 12 Feb 2010 21:12:05 +0300

Да, отличный модуль и тема, что называется, раскрыта. Спасибо!

Но не далее как вчера я редактировал шаблон из админской панели (Малый бизнес, последние стабильные обновления) и не мог понять, почему не работают js-скрипты . Оказалось, что (без пробелов) заменился на (с пробелом) и

Причем, это случилось 1-2 раза, остальные 8 раз все сохранилось нормально и системы появлеиня ошибки я не понял. Зато, теперь понятно откуда она такая взялась

Комментарии на "Новая версия 8.0: Проактивная защита" от Лосик

Sat, 11 Apr 2009 23:49:59 +0400

Не надо завязываться на .htaccess. Кроме Apache в мире есть довольно много других серверов (у нас вот все на nginx/FastCGI). И что делать, если такое...

Комментарии на "Новая версия 8.0: Проактивная защита" от Лосик

Sat, 11 Apr 2009 23:47:26 +0400

Не, товарищи. Я эээ... было дело высказывал скепсис на тему этого модуля. Был неправ в чем публично признаюсь 8)

Кстати, у меня по статистике, твари рвутся с infobox.ru.

Комментарии на "Новая версия 8.0: Проактивная защита" от Евгений Комаров

Sat, 11 Apr 2009 20:50:53 +0400

====quote====
В течение времени блокировки пользователю будет выдаваться 503 ответ сервер, т.е. сервер занят и не может обрабатывать запросы. Все остальные пользователи смогут работать с сайтом совершенно нормально.
=============
Если параметр подобран не очень удачно, то часть живых посетителей будет видеть 503-ю.
Где-то видел более изящное решение - проверка капчи.
Правда там использовалось из-за тяжелых AJAX-интерфейсов для защиты от лишней нагрузки на сервер.

Комментарии на "Новая версия 8.0: Проактивная защита" от Сергей Рыжиков

Sat, 11 Apr 2009 10:37:07 +0400

====quote====
И другой вопрос. Смотрит ли компания в сторону защит от Ddos атак? Не только TCP, но и UDP. Я понимаю, что это выходит далеко за рамки CMS, но если бы вы предлагали некий комплекс, аудит или еще что-то для крупных проектов - это бы пользовалось спросом.
=============

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

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

Такую защиту могут обеспечить датацентры. Очень специфическая область.

Комментарии на "Новая версия 8.0: Проактивная защита" от Сергей Рыжиков

Sat, 11 Apr 2009 09:45:03 +0400

====quote====
Допустим робот интенсивно дергает сайт на наличие уязвимостей. Делает инъекции, xss и прочее. Помимо потенциальной опасности он создает существенную нагрузку.

Так вот, после того как он (робот) добавился в стоп-лист, где его отсекать будут? На каком уровне системы? И не будет ли он создавать все ту же дополнительную нагрузку?
=============

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

====quote====
Не проще ли подумать в сторону "динамического" htaccess, где бы прописывалось:
Deny from ******
И этот файлик бы подрубался в самом начале (так как в стандартный .htaccess внедриться нельзя (кстати, а почему бы и нет?).
=============

Ну по сути так и есть. Но перекладывать на Apache мы не считаем возможным, да и не всегда это возможно на хостинге.

Комментарии на "Новая версия 8.0: Проактивная защита" от Антон Долганин

Fri, 10 Apr 2009 20:26:21 +0400

И другой вопрос. Смотрит ли компания в сторону защит от Ddos атак? Не только TCP, но и UDP. Я понимаю, что это выходит далеко за рамки CMS, но если бы вы предлагали некий комплекс, аудит или еще что-то для крупных проектов - это бы пользовалось спросом.

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

Комментарии на "Новая версия 8.0: Проактивная защита" от Антон Долганин

Fri, 10 Apr 2009 20:21:14 +0400

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

Допустим робот интенсивно дергает сайт на наличие уязвимостей. Делает инъекции, xss и прочее. Помимо потенциальной опасности он создает существенную нагрузку.

Так вот, после того как он (робот) добавился в стоп-лист, где его отсекать будут? На каком уровне системы? И не будет ли он создавать все ту же дополнительную нагрузку?

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

Не проще ли подумать в сторону "динамического" htaccess, где бы прописывалось:
Deny from ******
И этот файлик бы подрубался в самом начале (так как в стандартный .htaccess внедриться нельзя (кстати, а почему бы и нет?).

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

Комментарии на "Новая версия 8.0: Проактивная защита" от Николай

Fri, 10 Apr 2009 12:29:23 +0400