Обновить
Комментарии 60
sudo python setup.py install

уважаемый, я очень ценю ваш труд, но почему, почему вы, чёрт возьми, make install? Сколько раз твердили миру…
Почему бы не научить, как собрать пакет и поставить его — ну реально на две команды больше, а жизнь облегчится…

А если по теме — не думали об аналитике и попытке идентификации ботнетов? Ну или хотя бы логировании достаточной информации (кто, куда, с какими параметрами).
И ещё одно.

В fail2ban не хватает возможности разделить хост-блокировщик и хост-цель (другими словами, client и server могут связаться только по AF_UNIX, но не AF_INET). То есть, вот к примеру отдельно виртуалка с почтовым сервером и отдельно система с файерволлом. Приходится копировать логи с одной на другую сислогом, чтобы банить на фаерволле по данным с мэйлсервера.

Также, скажем, есть несколько серверов. Приятно было бы банить сразу на всех при пессимизации на каком-то одном. Опять же, решается пересылкой логов по сети, но это же ужасный костыль.

И в догонку про ботнеты: после нескольких последовательных банов определённого сервиса для некоего хоста, можно ещё последовательно расширять горизонт бана: банить негодника на большем числе сервисов, банить на сервисах другого типа на соседних серверах и т. д. Ведь, если хост попал в ботнет и сейчас рассылает спам, не факт, что завтра он не начнёт брутить ssh.
Вообще, на заре интернета мы пользовались для этого drbl. но система оказалась слишком сложной
Вам определенно стоит почитать как работает fil2ban. Если очень кратко, то заданные логи читаются и пропускаются через заданные фильтры (поставляются с fail2ban). Если фильтр что-то находит и при привышении заданного количества в заданное время сообщений применяются задданные действия (поставляются с fail2ban). Просто приведу названия некоторых действий чтобы вам стало более понятно:
complain
iptables
iptables-ipset-proto4
mail-whois

Эти действия можно компоновать и нет никакой проблемы изменить стандартные или написать нужные вам действия. Как раз оно в /etc/ и лежит для этого.
Так вы можете банить командой по сети сразу на вашей системе с файрволлом.
Или банить полностью, а не только порт сервиса.

вам определённо должно быть видно из активности меня в этой ветке, что я прекрасно понимаю, как он работает

я имел ввиду расширение горизонта в том же духе, как сейчас увеличиваются сроки бана и сокращается число допустимых попыток
расширять горизонт бана: банить негодника на большем числе сервисов
Вот это вот частично реализовано — bantime.overalljails = false и бутет вам счастье IP будет считаться плохим по всем jail-ам, т.е. после failure уже на любой jail и там надолго вылетает в бан.

По поводу system across сообщений — идея правда хорошая, спасибо, надо подумать. У меня сейчас в fail2ban есть event driven модуль (observer), можно после бана (и/или failure) асинхронно инкреметально синхронизировать базу на всех серверах. Где-то даже проект завалялся похожий, ака sqlite-notifier для кластера серверов (типа звезда), может и выдеру чего оттуда.
Конечно же true вместо false:
bantime.overalljails = true

уважаемый, я очень ценю ваш труд, но почему, почему вы, чёрт возьми, make install? Сколько раз твердили миру…
Почему бы не научить, как собрать пакет и поставить его — ну реально на две команды больше, а жизнь облегчится…
Вы не работали с Python. Если автор Python’овского пакета адекватен и использовал стандартные distutils, то pip install … и cd … && python setup.py install не отличаются по своему результату.

Так что не надо. python setup.py install — это далеко не make install. Но только если вы считаете, что управление системными пакетами двумя менеджерами пакетов (pip и apt или что у вас там) — хорошая идея. Учитывая, что целью данной статьи не было обучение аудитории сборке пакетов на всех 100500 дистрибутивах и пакеты с distutils собираются элементарно, то всё в порядке.
Но только если вы считаете, что управление системными пакетами двумя менеджерами пакетов (pip и apt или что у вас там) — хорошая идея.

Именно, я считаю, что это — плохая идея, менеджер пакетов должен быть один.

Данная статья начата с Debian. Пусть хотя бы показано было на нём. Кстати говоря, в Gentoo написать distutils-ebuild очень просто.
Это ужасная идея. Особено в реалиях debian. Мне не редко приходится чекенить отдельный бранч для гема, чтобы работало и ждать пока вольется в master, а вы говорите еще ждать пока мэинтейнер соизволит обновить у себя? Нет, спасибо.
Вообще‐то он говорит собрать свой пакет, а не полагаться на какого‐то maintainer’а. Это не так уж и сложно, тем более что для gem’ов наверняка тоже есть что‐то готовое. Я же говорю, что sudo python setup.py install не так уж и страшен, и рассказывать про сборку пакетов в статье про fail2ban совершенно не нужно.
>Именно, я считаю, что это — плохая идея, менеджер пакетов должен быть один.
И? Предложено было собирать свой пакет для дистрибутивного менеджера пакетов. Ни один такой менеджер не запрещает вам быть maintainer’ом своего же пакета. И даже собирать его в той же системе, в которой он будет использоваться.
А не подскажете случаем как можно банить адреса которые используют разные логины или банить за использование определенных логинов?
Первое — не понял, что значит «используют разные логины»? У вас правило — один адрес, один логин или что? А как же NAT?

Второе — тем же самым fail2ban, написать правило, которое ловит именно эти самые определённые запрещённые логины.
1) В целом да, есть пару серверов где используется только одна-две учетки
2) Уже нагуглил примеры.
Тогда про первое — не делать ничего. fail2ban сам подхватит n неудачных попыток зайти с несуществующими логинами и забанит.
Ну про это понятно, хочется более интуитивной выборки, вот например в auth.log попадали баны за попытки войти с логином wbcLogonUser, а это то ли дефолтный логин для cpanel, то ли еще что-то, так вот суть в том что максимум попыток у меня равно 3 и в логах длинный список попыток с разных адресов зайти с этим логином. Вот и интересуюсь нет ли фильтра который анализировал бы часто используемые неудачные логины и банил бы сразу без вопросов?
Если хочется более интуитивной выборки — возьмите и напиши сами под себя.
На среднем сервере веб хостинга как правило живёт вагон сервисов + вагон всякого клиентского хлама, вроде вордпрессов, джумл, прочих cms, которые перебираются, подбираются и ломаются раз в день. Так что «какие логины» для каких «дефолтных логинов» перебирают у Вас, вряд ли перебирают у меня.
Именно потому, что «часто используемые неудачные логины» меняются от сервиса к сервису, а их неисчислимое количество, надо понимать, что есть количество попыток с одного хоста. а что там уже конкретно — дело десятое.
Я эту проблему решил ещё одним правилом, сканирующий лог самого fail2ban. Те я банил на большее время тех, кто часто светится и навсегда — самых наглых.
Но есть одна идея, проблемная в реализации. Всех забаненных, обращающихся на 80 порт, перенаправлять на статическую страницу (где не банят), с информацией о том, что «ваш IP заблокирован, возможно выш компьютер заражен и является частью ботнета итп». Как это сделать в iptables я не представляю.
да элементарно, -j REDIRECT их на другой порт, где другой вебсервер показывает эту вашу страницу.
Нехороший IP банится на весь сервер(по все портам). Получается нужно чтоб iptables игнорировал определённый порт? Как?
добавить непосредственно перед полным баном разрешение для этого конкретного порта. Примерно так:
-t nat -A PREROUTING --match-set banned-ips --p tcp --dport 80 j REDIRECT --to-ports 8888 -m comment --comment «banned IPs going to 80 will be served by web-service hanging on 8888 instead»
-t filter -A INPUT --match-set banned-ips -p tcp --dport 8888 -j ACCEPT -m comment --comment «on a port 8888 will listen our web server with a static page — allow our banned hosts to access this port»
-t filter -A INPUT --match-set banned-ips -j REJECT --reject-with icmp-port-unreachable -m comment --comment «everything else will be rejected»
не проверял правила, может и ошибся где-то, но идея видна
да, правила неправильные в смысле синтаксиса match-set; читайте ман и легко поправите. Там должно быть что-то вроде -m set --match-set banned-ips src

сам по себе список banned-ips подразумевается типа hash:ip или что угодно другое :ip, сообразно ситуации
Какие нафик формулы и сканирование собственного лога? Fail2ban давно этой умеет сам и для этого есть jail — recidive. Туда и складывать всех на недельку. А если что-то совсем под ударом стоит, то portnocking в помощь.

Хорошая утилита, жаль только ipv6 не умеет пока
У recidive есть к сожалению несколько нехороших недостатков:
  • recidive jail довольно просто обойти, т.к. считаются уже состоявшиеся баны других jail (maxRetry за промежуток времени findTime);
  • recidive jail считает только ban-ы, и ему совершенно наплевать на failure — в результате умные бот-сети подстраивают перебор под параметры maxRetry/findTime, чтобы просто тупо не слетать в бан. recidive в этом случае абсолютно бесполезен.
  • recidive фильтр сканирует собственный fail2ban.log, что чревато: совершенно никудышный performance, падающий нелинейно с ростом нагрузки, затрудненная отладка и поиск ошибок и т.д и т.п.).
  • неудачный logrotate на fail2ban.log иногда приводит к тому, что jail «recidive» падает в idle (т.е. совсем отключается).
  • recidive jail блокирует все порты и прото, что иногда не есть гуд. Как минимум когда сам после неудачных попыток зайти в почту (случайно) улетишь в бан, а залезть с другого IP чтобы разбанить себя любимого под рукой нет возможности.

Поэтому формулы и еще раз формулы :)
К fail2ban отлично подходит logwatch.
Эта программа парсит логи и присылает на почту письмо с выжимкой раз в сутки.
Сообщения fail2ban она тоже видит.
Если бы ваш знакомый админ получал письма, то давно бы заметил такую атаку.

Ну и простой способ защититься от левых подборов — поменять порт ssh.
Естественно, от целенаправленной атаки это не защита, но от постоянного сканирования всея интернета помогает.
Например, за пару лет на сервере хостинга было всего несколько попыток подключения по ssh.
Оставить только аутентификацию по ключу и банить за любые попытки логина по паролю.

Мне не помогло. Поменял порт sshd. Где-то 2 месяца было тихо, а потом постоянные попытки проломиться по ssh возобновились с той же интенсивностью.

Значит, к вам кто-то целенаправленно долбится.
Но всякие левые сканирования из китая обходят вас стороной.

Может быть. Поэтому я их теперь баню сразу по подсетям. Я просто подумал, что за 6 лет с момента написания поста возможности злоумышленников по поиску сервисов для взлома возросли, поэтому старые техники стали уже неактуальны.

НЛО прилетело и опубликовало эту надпись здесь
Нужны ещё Banned4Spam и Burned4Fun (рандомный наказатель).
НЛО прилетело и опубликовало эту надпись здесь
Это будет хорошее развитие filter.d/recidive.conf.
После того как я заметил, что Slow Brute Force стал массовым (в плане размера ботнетов) и очень умным, то проспонсировал добавление в fail2ban ignorecommand (позволяет внешнему скрипту указать fail2ban, что ip не нужно банить) и сделал retry=1. Т.е всех банить сразу и надолго, но не банить доверенные ip. Например, которые где-то уже аутентифицировались, известные сети, местная страна и т.д. до 10 попыток, например. Если оно всё еще стучится, то filter.d/recidive его добивает.

Спасибо за работу, очень полезный функционал! Недавно как раз в asterisk 11 появилась опция security в loger.conf, и гораздо проще стало банить всяких переборщиков. Как писали выше очень был бы полезен функционал межсерверного взаимодействия. Возможно даже сервис где люди синхронизируют свои fail2ban блокировки с другими по определенным критериям или сообществам.
функционал межсерверного взаимодействия.

github.com/uu/bango
Централизованный забанятор/разбанятор.
НЛО прилетело и опубликовало эту надпись здесь
Отличное решение, спасибо за работу.

Единственное что хотел уточнить. Я везде где можно использую denyhosts, скажите пожалуйста в чём его слабые места и почему следовало бы перейти на fail2ban. Мне в denyhosts нравится в первую очередь потому что там есть механизм, который умеет с удалённых серверов скачивать чёрные списки, которые постоянно обновляются (в их числе и многочисленные ботнеты).
Хотелось бы услышать и ваше мнение поэтому поводу (если есть что сказать конечно). Благодарю!
Голосую за полноценную поддержку ipv6. Готов вложиться некоторым количеством рублей.

Я пытался доработать самостоятельно патч выложенный в вики, но не хватает питон-скила и времени.
На freebsd ваша сборка не работает. Python 2.4.3

root@server:/home/admin/fail2ban-ban-time-incr# /usr/local/etc/rc.d/fail2ban start
Traceback (most recent call last):
  File "/usr/local/bin/fail2ban-client", line 28, in ?
    from fail2ban.version import version
  File "/usr/local/lib/python2.4/site-packages/fail2ban/__init__.py", line 70, in ?
    logging.handlers.SysLogHandler.priority_map['NOTICE'] = 'notice'
AttributeError: class SysLogHandler has no attribute 'priority_map
Всё конечно работает, но работает кривовато. Не работает bantime.increment, в лог валится:

fail2ban.observer       [30309]: ERROR   'NoneType' object has no attribute 'getBan'

Если в fail2ban.conf включить loglevel = DEBUG, то при рестарте fail2ban вываливается громадная куча ошибок — pastebin.com/23ScC602

Буду благодарен, если подскажите в чём дело, у меня к сожалению знания питона на нуле
Observer и новый функционал работают только если в fail2ban.local (или fail2ban.conf) включен банк данных:
dbfile = /var/lib/fail2ban/fail2ban.sqlite3
Я так понимаю у вас оно либо откомментировано, либо не может туда писать.
P.S. По ссылке заглянуть немогу (корпоративные политики, будь они не ладны), но думаю это все же DB.
А вы в курсе, что файла ./debian/fail2ban.init для выполнения sudo cp ./debian/fail2ban.init /etc/init.d/fail2ban у вас просто нет? Может по этому автоматически не будет стартовать?
Блин, детский сад честное слово… Ну возьмите его из дистрибутива fail2ban_0.9.1-1.debian.tar.xz, в чем проблема то.

Не знаю что там с веткой debian в исходниках на github случилось, был готов поклясться — он там был…
Ну да — он там и был, просто коллега yarikoptic убрал его коммитом 67e79a14624c496f740ed3c63ae28788c6e3b346: now we will use upstream's init for debian
В общем лежит оно теперь в /files/debian-initd. Статью сейчас поправлю.
Спасибо за помощь!
Я и в правду детский сад — не очень хорошо умею работать с unix, поэтому непонятные сложности ставят в тупик и когда решение не очевидно становится очень грустно.
Еще раз — большое спасибо за помощь — поменяю сейчас дефолтный 0.8.6-3wheezy на ваш (даром что ли столько времени с ним разбирался:))
Да, и как теперь удалить ваш вариант fail2ban? Скрипт setup.py ни чего, кроме install не предусматривает. Мне на будущее будет уроком не устанавливать на рабочие сервера не проверенные решения.
А его и не надо удалять. Просто ставте родной сверху — если вы fail2ban уже запускали, нужно будет удалить /var/lib/fail2ban/fail2ban.sqlite3, т.к. не совместим.
Стесняюсь спросить, а как сия утилита «работает» с динамическими адресами? То есть ботнет из 10к машин — понятно, но это не означает автоматически 10к фиксированных IP-адресов.
Не хуже чем со статикой (в чем-то лучше, например в том смысле, что плохие адреса не забивают базу на долгие годы). Выглядит как-то так:
  • динамический IP улетает в бан (например сначала после 3-х failure на 15 мин, затем после 2-х на 45 мин, затем сразу на 3 часа, и в итоге уже на сутки);
  • грубо говоря, такой IP сделает максимум 5 — 10 попыток в сутки (зависит от настроек)
  • провайдер как правило меняет адрес раз в сутки (иногда реже)
  • завтра все повторится опять, а из базы улетит «вчерашняя» динамика (с разницей за минусом purgeage)

Конечно у такой бот-сети подобрать шансы выше, чем у «статичной», но не намного (кроме того провайдеры тоже бдят).
И оно однозначно лучше, чем совсем без «инкремента».
Если адрес меняется раз в сутки, то, да, пожалуй, проблемы особой не видно. Ну, кроме, конечно же, большей эффективности такой сети. Но это с точки зрения защищающегося, когда стоит только одна цель — защититься от подбора пароля (или похожие). Но! Но могут начать наблюдаться проблемы с доступностью сервиса через определённых провайдеров. Небольшой кусок ботнета, сидящего в сети провайдера с динамическими адресами медленно, но верно, выкосит весь операторский пул, то есть простые (чистые) пользователи, получив адрес после заражённой машины будут сидеть в бане и, возможно, даже в вечном.
P.S. Не наезжаю, просто, хочу взглянуть с другой стороны.
P.P.S. Сорри, что написал не в ответ, а как новый коммент, — сплю в одном ботинке уже.
Небольшой кусок ботнета, сидящего в сети провайдера с динамическими адресами медленно, но верно, выкосит весь операторский пул
Как вы думаете, сколь долго провайдер будет «терпеть» таких абонентов? Им просто позакрывают порты (например smtp, если подбирает мыло) + письмо счастья (поздравляю у вас вирус).
Поставил на убунту. По логу работает

2016-03-06 13:49:58,300 fail2ban.server [24872]: INFO Changed logging target to /var/log/fail2ban.log for Fail2ban v0.9.2.dev0
2016-03-06 13:49:58,300 fail2ban.transmitter [24872]: DEBUG Command: ['set', 'syslogsocket', 'auto']
2016-03-06 13:49:58,301 fail2ban.transmitter [24872]: DEBUG Command: ['set', 'dbfile', '/var/lib/fail2ban/fail2ban.sqlite3']
2016-03-06 13:49:58,301 fail2ban.transmitter [24872]: DEBUG Command: ['set', 'dbpurgeage', '1d']

По факту нет.

Конфиг включен.

# «bantime.increment» allows to use database for searching of previously banned ip's to increase a
# default ban time using special formula, default it is banTime * 1, 2, 4, 8, 16, 32…
bantime.increment = true

# «bantime.rndtime» is the max number of seconds using for mixing with random time
# to prevent «clever» botnets calculate exact time IP can be unbanned again:
bantime.rndtime = 10m

# «bantime.maxtime» is the max number of seconds using the ban time can reach (don't grows further)
#bantime.maxtime =

Скажите в чем проблема?
По факту нет...

Глупый вопрос: а вы хоть одну jail включили (enable = true)?

Обычно создается файл jail.local:

[sshd]
enabled = true

[nginx-http-auth]
enabled = true

...
Сказывается моя неопытность. Теперь разобрался и завел его, спасибо!

Только-что выкатил пре-релиз 0.10-ветки для ban-time-incrподдержкой ipv6 и другими вкусностями)...


Pre-release: 0.10.0-ban-time-incr-1 (2016/07/15) — ipv6-support meets ban-time-incr


https://github.com/sebres/fail2ban/releases/tag/0.10.0-bti1


PS. Про другие вкусности:


  • Рост скорости и снижение нагрузки: 10-я версия гораздо быстрее предыдущей и в разы меньше нагружает CPU и IO:
    • Максимальное время до блокировки (задержка блокировки от нахождения failure до ban) уменьшена практически в 1000 раз;
    • Средняя скорость блокировки выросла в десятки раз (порядка 200-300 IP/сек);
    • Рост задержки блокировки (регрессия при увеличении количества failure / ban) упал с 100 мс до 5 мс на каждую 1000 IPs.
  • Полностью переработанный клиент-сервер;
  • Возможность блокировки не только IP адресов: например использовать имена в качестве failureid и банить пользователей. Или использовать пару IP:port или другой идентификатор в качестве failure id, а банить IP адрес. Подробности см. https://github.com/fail2ban/fail2ban/pull/1459;
  • Еще много — много чего другого...
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.