Комментарии 17
Вот что у меня творится (давно настроил себе):
А как fail2ban используете Вы?:)Мы используем denyhosts ;) Особенно полезно их «облако» с обменом хостами между разными серверами. Всё автоматически прилетает, в день обычно около 50-ти новых хостов банится.
П.С.: Я, правда, пользуюсь для бана по ssh, но там можно настроить на парсинг любых логов.
Не замечали, что под приличной нагрузкою (при парсинге огромных логов) fail2ban может очень надолго зависнуть, используя ваш CPU на 100%?
НЛО прилетело и опубликовало эту надпись здесь
Быть может более частый rotate логов поможет?
Хотя в данном конкретном случае (описанном в статье) речь идет о парсинге error.log'а — он априори не должен быть большим.
+ в ситуациях, если парсить приходится действительно большое логи, то быть может стоит подумать о разделении запросов на запись в разные log-файлы или каким-то другим способом оптимизировать access-логи.
Хотя в данном конкретном случае (описанном в статье) речь идет о парсинге error.log'а — он априори не должен быть большим.
+ в ситуациях, если парсить приходится действительно большое логи, то быть может стоит подумать о разделении запросов на запись в разные log-файлы или каким-то другим способом оптимизировать access-логи.
Согласен, на своём опыте при паразитном трафике более 30 мбит/сек с большого количества ip fail2ban уже работает на грани, к сожалению, это решение пригодно только для небольших нагрузок.
Fail2ban сам за милу душу уложит машину =) Сказать, что он написан отвратительно — сделать ему комплемент.
А может проще поставить http авторизацию с сумасшедшим паролем (дешево и просто — машина почти не грузится при подборе)? У меня так на WP реализовано: http-авторизация со сгенерированным паролем, а затем в WP опять сложный пароль. Если каким-то чудом пробились через 1й уровень, предстоит подбор еще и для входа в админку wp. На первом уровне все и срубаются.
Эту фишечку пришлось запускать еще с прошлого года, когда были массовые попытки подбора паролей, когда использовались взломанные распределенные серверные мощности.
Эту фишечку пришлось запускать еще с прошлого года, когда были массовые попытки подбора паролей, когда использовались взломанные распределенные серверные мощности.
У меня стоит скрипт на awk, который парсит гигабитные логи и добавляет в список блокируемых IP хосты с превышением 10 запросов в сутки.
В основном, это страницы админки вордпресса или джумлы.
В основном, это страницы админки вордпресса или джумлы.
Решил поискать на хабре и нашел таки.
Пожалуйста поправьте в статье ваш
Чем ваше выражение плохо даже обсуждать не хочу, ибо плохо оно всем — не заякорённое нигде (не спереди не сзади, парочка greedy catch-all и т.д). В общем, кто регулярки делает и так поймет.
Т.к. сильно часто в последнее время такие issue стали мелькать сделал это новым фильтром, завтра смержу и в 0.9.4 зарелизим.
Пожалуйста поправьте в статье ваш
failregex на нижний, а то будет как у человека тут — или подвиснет или обвалится (такие тоже были уже).failregex = ^\s*\[error\] \d+#\d+: \*\d+ limiting requests, excess: [\d\.]+ by zone "[^"]+", client: <HOST>
Чем ваше выражение плохо даже обсуждать не хочу, ибо плохо оно всем — не заякорённое нигде (не спереди не сзади, парочка greedy catch-all и т.д). В общем, кто регулярки делает и так поймет.
Т.к. сильно часто в последнее время такие issue стали мелькать сделал это новым фильтром, завтра смержу и в 0.9.4 зарелизим.
sebres, спасибо, поправил.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Fail2ban и nginx: блокируем нежелательный трафик к определенному URL