Анализатор логов ddosViewer вебсервера для поиска ддос флуда

zexis, ну. а я, что, возражаю? это лишь подтверждает, что со временем логика проверок усложняется и потребуется нормальный удобный для быстрой разработки язык программирования.

В чем сложность анализировать логи постфактумно раз в минуту?

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

Моим анализатором 10 000 строк анализируется около секунды, 80 000 строк около 8 секунд. Анализатор загружает лишь одно ядро процессора. На современном сервере ядер несколько, так что остальные ядра при работе анализатора свободны.

При мощном HTTP-флуде с лог пишется максимум 100 000 – 200 000 запросов в минуту.

При среднем HTTP-флуде не более 10 000-30 000 запросов в минуту.

Анализа 5 000 - 80 000 строк обычно хватает что бы найти большую часть ботов.

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

То, что "проще" - никто и не спорит. Во-вторых, и с капчей есть варианты.

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

А что мешает это делать на уровне веб-сервера?

Ну, например, какие еще сейчас запросы вебсервер обрабатывает.

Это применимо для расширения вебсервера, написанного на любом языке. Как минимум, в части "завалить".

Собственно, тут уже писали, что не нужно все пихать непосредственно в веб сервер. Можно поставить отдельный обработчик (например, cgi-скрипт), который будет принимать решение о пропуске/отклонении конкретного запроса.

Медленно. (Да и логи далеко не всегда оправданно вести.)

Вполне годится как костыль. Конечно, "чудо" на C ради этого городить не стоит.

Вам бенчмарк показали. Простейшие утилиты уделывают Ваш "анализатор" чуть ли не на порядок.

обычно веб-сервер ничего не знает о php-приложении.

Почти бесполезно. Если обычные запросы не завершаются хотя бы за 5-10 секунд - сайт уже в жопе. Все остальное в логах.

Ну и где взять такое решение? опять писать на C ?

Тут вам предлагают одновременно и просто и безопасно.

Обычный вебсервер и не досят. Досят конкретные приложения - просто используйте информацию о их работе при защите. Это и есть задача администратора.

Да что Вы к C-то привязались? На чем хотите - на том и пишите. Хоть на perl.

Еще раз - то, что Вы предлагаете далеко не так просто. Вспомните хоть, что изменение формата логов потребует reload'а веб-сервера + плюс всего, что парсит эти ваши логи. А тут все просто: на входе запрос - на выходе разрешение/запрет на его дальнейшую обработку. А в промежутке "черный ящик", ваш обработчик, которому всегда доступны параметры запроса - меняйте его логику как и когда удобно.

Отдать временно ошибку 503 подозрительному клиенту можно настроив limit_zone и limit_req_zone в конфигурации NGINX для каждого типа файлов. Тут и изобретать нечего не надо, лишь вставить 4-6 строк в файл конфигурации NGINX.

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

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

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

Вы показали сравнение со скриптом, находящим топ быстрых IP.

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

zexis добавил 18.01.2011 в 16:33

myhand, вы уже написали модуль для вебсервера, принимающий решения кто бот, а кто нет?

Или это только на словах из серии, что можно написать, если постараться?

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

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

"Садись, два" (с)

Ну какое это отношение имеет к тому "какие еще сейчас запросы вебсервер обрабатывает"? Сейчас, не "третьево дни".

Анализ логов никто не отменял. Но это больше уже для обновления списков IP, формирования статистических критериев и т.п.

Начнем с того, что "взаимодействия" с "клиентом" нету. Как класса. Бан - и все. Или не бан.

Я показывал сравнение со случаем, когда Ваша программа строит этот самый топ.

- но зачем делать очередной велосипед? Есть решения и для nginx, и для апача. Их тут цитировали. Интересно - поучаствуйте в разработке.

Вы только не обижайтесь, но таких "анализаторов, которые анализируют" - у каждого администратора есть в заначке. Присутствующие, уверяю, не исключение. Делиться здесь особо нечем - т.к. все подобное пишется/писалось на коленке за полчаса.

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

В конце концов, никто не отменяет блокировку на FW. Но если, например, за 4 часа пришло 10% ддос-запросов и 90% нормальных, то такой ip нельзя блокировать.

С DDOS по IP не встречался?

Если я думаю за http - ip - , то статика разгружает все эти запросы, nginx в этом плане на высоте.

P.s я почти всегда справляюсь без парсеров, штатные средства пока работали, nginx спасает почти в 70% случаях, ну может и есть скрипты не большие, и то они для nginx-ерор-лог что бы лимиты выгребать. хотя атака-атаке рознь.