- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Разумеется в /tmp создается скрипт из под пользователя apache как и результат работы всех остальных скриптов или, например, модуля mod_evasive.
до того, как ТС упомянул про mod_evasive - это было не очевидно.
ведь можно себе представить другой способ формирования списка IP для бана,
работающий в итоге от root и создающий файлик соответствующий, нет? :)
PS:
тут sudo _в_принципе_ все-равно не поможет (ежели апач файлик создает). ибо
очевидные race conditions имеются налицо.
до того, как ТС упомянул про mod_evasive - это было не очевидно.
Если кто-то хочет формировать команды для iptables из под рута, не имея рута - скорее всего, что он делает это из под apache. Иначе их можно просто запустить. В простых решениях вообще не делают разграничений. Есть root и пользователь_для_php - вот и все.
ведь можно себе представить другой способ формирования списка IP для бана,
работающий в итоге от root и создающий файлик соответствующий, нет?
На практике такое не нужно - скрипт от рута может (и должен) уже сразу по обнаружении запускать команды iptables и блокировать гораздо быстрее чем по cron.
В mod_evasive прописывается реакция на атаку в виде программы. Обычно это sudo +iptables с аргументами. Аргумент командной строки переданный в программу перебить нельзя и никаких race conditions не возникает.
На практике такое не нужно - скрипт от рута может (и должен) уже сразу по обнаружении запускать команды iptables и блокировать гораздо быстрее чем по cron.
не всегда может и не всегда должен. "пачками" (iptables-restore, например) отправлять
на бан IP/подсети обычно гораздо лучше, чем дергать на каждый чих iptables
В mod_evasive прописывается реакция на атаку в виде программы. Обычно это sudo +iptables с аргументами. Аргумент командной строки переданный в программу перебить нельзя и никаких race conditions не возникает.
я с этим и не спорю. я писал о race conditions в контексте работы с файлом.
PS: ТС стоило бы начать nginx-а и забыть iptables как страшный сон. отправить
1k ботов на статику для nginx-а особых проблем нет. а вот добавить 1k
iptables правил - обычно на VPS не дадут ;)
не всегда может и не всегда должен. "пачками" (iptables-restore, например) отправлять
на бан IP/подсети обычно гораздо лучше, чем дергать на каждый чих iptables
iptables-restore не добавляет правила, а перезаписывает всю таблицу. Ро мере роста списка придется постоянно перезаписывать одни и те же IP. Выгоднее запустить одну команду iptables. На больших объемах уже выгоднее ipset.
ТС уже признал, что просто не осилил sudo. Откуда у вас это стремление оставить за собой последнее слово?
iptables-restore не добавляет правила, а перезаписывает всю таблицу. Ро мере роста списка придется постоянно перезаписывать одни и те же IP. Выгоднее запустить одну команду iptables.
неа. ключик -n есть. man iptables-restore. про ipset - согласен.