тыц: http://www.php.net/manual/en/session.configuration.php - session.gc_probability > 0
читайте документацию уже
Моя не понимать что вы эдак заковыристо обозвали. А право гадать что Вы имели в виду - оставлю madoff. От тут часто в телепатии тренируется. Правда, без особого успеха.
PS: С последним замечанием madoff согласен - я тоже не припомню атак, от которых не получилось в итоге отбиться на уровне вебсервера (плюс отправка особо ретивых на файервол по error.log).
Я бы поостерегся делать это "для каждого типа файлов". И, к сожалению, есть еще клиенты, для которых таки нельзя это делать. Так что логика на порядок сложнее - но вы идете в нужную сторону.
"Садись, два" (с)
Ну какое это отношение имеет к тому "какие еще сейчас запросы вебсервер обрабатывает"? Сейчас, не "третьево дни".
Анализ логов никто не отменял. Но это больше уже для обновления списков IP, формирования статистических критериев и т.п.
Начнем с того, что "взаимодействия" с "клиентом" нету. Как класса. Бан - и все. Или не бан.
Я показывал сравнение со случаем, когда Ваша программа строит этот самый топ.
- но зачем делать очередной велосипед? Есть решения и для nginx, и для апача. Их тут цитировали. Интересно - поучаствуйте в разработке.
Вы только не обижайтесь, но таких "анализаторов, которые анализируют" - у каждого администратора есть в заначке. Присутствующие, уверяю, не исключение. Делиться здесь особо нечем - т.к. все подобное пишется/писалось на коленке за полчаса.
Обычный вебсервер и не досят. Досят конкретные приложения - просто используйте информацию о их работе при защите. Это и есть задача администратора.
Да что Вы к C-то привязались? На чем хотите - на том и пишите. Хоть на perl.
Еще раз - то, что Вы предлагаете далеко не так просто. Вспомните хоть, что изменение формата логов потребует reload'а веб-сервера + плюс всего, что парсит эти ваши логи. А тут все просто: на входе запрос - на выходе разрешение/запрет на его дальнейшую обработку. А в промежутке "черный ящик", ваш обработчик, которому всегда доступны параметры запроса - меняйте его логику как и когда удобно.
То, что "проще" - никто и не спорит. Во-вторых, и с капчей есть варианты.
А в-третьих, иногда лучше временно просто дать 503 для подозрительных клиентов.
А что мешает это делать на уровне веб-сервера?
Ну, например, какие еще сейчас запросы вебсервер обрабатывает.
Это применимо для расширения вебсервера, написанного на любом языке. Как минимум, в части "завалить".
Собственно, тут уже писали, что не нужно все пихать непосредственно в веб сервер. Можно поставить отдельный обработчик (например, cgi-скрипт), который будет принимать решение о пропуске/отклонении конкретного запроса.
Медленно. (Да и логи далеко не всегда оправданно вести.)
Вполне годится как костыль. Конечно, "чудо" на C ради этого городить не стоит.
Вам бенчмарк показали. Простейшие утилиты уделывают Ваш "анализатор" чуть ли не на порядок.
Кнут - это уже не совсем технические книжки. Это больше прикладная математика, а тут мне объяснили, что такое знать нинада 🚬
Нужна. Блокировать сразу на файерволе - это для джедаев (или для простого over 9000: GET /). Почему не отдать подозрительному клиенту сперва 503 или что-то подобное в сомнительном случае?
Ну, в данном примере - куцый.
А в более общем случае (когда аффтар таки осилит возможности логгирования запросов веб-сервером) - Вы, надеюсь, не будете спорить, что у самого веб сервера информации о запросе чуть поболее, чем он в принципе готов писать в логи?
Не очень понятно зачем, но помимо того как Вам объяснили ранее (/ru/forum/comment/8369646) - можно сделать буквально то, что вы просите в реальном времени.
tail -f /var/www/123/data/logs/123.access.log | awk '{ if (n>100) { print k; k=0; n=0 } else n++ } /\/123\/123\.php/ { k++ }'
Это, извините, прежде всего не "один IP", а просто незнание кем-то матчасти. Идти учить что значит 87.119.229.2*0 для grep :-)
Нужно смотреть подробнее на месте. Но раз ситуация не напрягает - можно и забить. Или пробивайте по whois IP и шлите абузы, кому полагается. Авось ответят.
В DROP?
Да меня несколько другое настораживает. Зачем это решать кого блокировать на куцом уровне парсинга лог файлов, когда самое логичное и простое - делать это с точки зрения приложения, на кое и направлен DDOS. Как нормальные люди и делают.
А уж по крону костыли там или не по крону - дело десятое.
