Веру в телепатов, видимо, "не задушишь, не убьешь" (c).
1-3,5 умеет limit_conn/limit_req в nginx. Почти, так как пока только обещали
поддержку _нескольких_ директив limit_req на одном уровне. Только ограничения
работают не для "одинаковых запросов" - а на уровне location.
Таким образом, функционал _пока_ эквивалентен строчке на sh + awk (по замечанию
Himiko). Скрипт для выгребания IP ботов из error.log nginx в файервол + критерии limit_req/conn.
Польза 4 весьма сомнительна. Вами собиралась какая-то статистика по
срабатыванию правил? По ложным срабатываниям? Насколько 4 в итоге оказалось полезным?
это вопрос поддержку dle наверное? а причем этот форум?
видимо имелось ввиду:
http://en.wikipedia.org/wiki/GNU_Screen
документацию посмотреть
Ну и? Если задача типа "удалить по фтп" ("С под фтп клиента они не удаляются") - дак
и поставьте скриптом с правами апача правильные права.
А чтобы по-умолчанию создавать файлы, которые кто-то кроме апача может редактировать/удалить - см. функцию umask.
hutasl, а поставить нужные права php-скриптом (рекурсивно,
если нужно) что запрещает?
в документации chmod есть даже пример.
я тоже proxy_cache использую, но вот:
http://hll.msu.ru/item_165.html
А какие именно критерии ddos (по логам nginx, по нетстат)?
Мне представляется, что вместо netstat (SYN) - лучше жесткие
лимиты на файерволе (hashlimit,connlimit).
Вместе с простым парсером логов nginx (модули *limit) - несколько
строк на sh + awk + iptables-restore/ipset. Помимо рецепта Himiko
с кешем (кстати, proxy_store vs proxy_cache - что шустрее
получается в данном контексте?) - еще ряд эвристических
приемов: redirect+js, cookie, whitelist (рулит для сайтов со специфической
аудиторией, типа WAP).
nmarket, эта штука заполняет envelope sender address. От того, что
скрипт заполняет From некорректно - это никак не вылечит. Укажут
в "From: Вася" (почти как у ТС) - так и пойдет обратно.
т.е. как дополнительная мера это годится - но лишь как защита от кривых
скриптов - дабы баунсы получать таки, даже где From явно не указан.
