там вся логика: "нашли IP в error-логе N раз с момента прошлого парсинга - отправили в бан".
строчка awk + iptables/ipset/iptables-restore.
я, собственно, упомянул выше о том, что nginx - "полуфабрикат". это не
решение "искаропки", просто его легче адаптировать (на уровне конфигов а не
кода) под конкретный сайт.
для smtp/pop/imap/что-nginx-умеет-проксировать - можно пробовать его в качестве
отправной точки. а так - что-то специализированное. nginx-не панацея, ниразу.
но речь и шла о HTTP только.
iptables/ipset нужно запускать из скрипта, парсящего error.log-файл nginx (который
кидает туда ip забаненых limit_(zone|req)). просто из соображений
производительности - лучше один раз запустить iptables-restore, чем сотню
отдельных iptables на каждый найденный ip.
если не секрет, чего в nginx вам нехватает? // в контексте защиты от небольшого ddos.
там _много_ модулей. проверка cookies, рефереров, там кеширование и еще куча разных плюшек.
нет, это не "готовый" рецепт. но доведение его до рабочего состояния для каждого конкретного
сайта - задача на порядок менее безнадежная, чем написание "своего" решения.
апи нестабильный. может в этом дело. а охотники есть, на недавнем хайлоаде
был доклад достаточно большой на эту тему.
netwind, nginx и есть "своя программа". для адаптации под атаки нужны определенные усилия.
zexis, если есть время и "дурацкая черта" - аналог nginx-модуля limit_req
для апача был бы интересен, думаю, многим ;)
а если нужна конструктивная критика - покажите код. как правильно заметил
Outsourcenow, подобный алгоритм на shell пишется "наколенке" в три строчки.
myhand добавил 02.12.2009 в 19:43
с вами уже это обсуждали не так давно:
/ru/forum/410019
присутствующие здесь Outsourcenow и netwind
кстати тоже окрестили эту идею чушью :)
в том, что в почтовом демоне на сервере (postfix? sendmail? exim? что?) - прописан
ваш домен example.com. локальные настройки имеют приоритет над тем, что
прописано в MX для домена.
решение - удалить example.com из доменов, обслуживаемых вашим почтовиком.
zexis, не обижайтесь, но вы сделали велосипед. с квадратными колесами :)
советую вам обратить внимание на nginx, модули:
http://sysoev.ru/nginx/docs/http/ngx_http_limit_zone_module.html
http://sysoev.ru/nginx/docs/http/ngx_http_limit_req_module.html
+ отдельно настроенные под разные location (статика, динамика, тяжелая динамика)
+ whitelist для некоторых IP/подсетей (зависит от специфики сайта, скажем, WAP-сайт).
заинтересует - обращайтесь.
где ТС сказал про апач, настроенный по _дефолту_? Борис просто указал
на _еще одину_ логическую возможность - почему правила не работают.
первый вариант - другие правила с ACCEPT _до_ указанных ТС (см. ответ #2).
имеете к этому что-то добавить?
то, что дергая ссылки на сайте - он совершенно не обязательно откроет
новое TCP-соединение.
представляю отчетливо: человек хочет потестировать работу правил. низкий
лимит - специально, чтобы попасть в DROP.
ему указали в первом ответе, что работа правил зависит от предыдущих в цепочке.
имхо, что-то конструктивное к этому добавил только Борис.
PS: hashlimit у NC есть, естественно - иначе ядро ругалось бы при попытке добавления правил.
