sebres Sep 26 2014 at 19:39

Fail2ban [incremental]: Лучше, быстрее, надежнее

9 min

157K

Information Security*

+70

Comments 60

merlin-vrn Sep 26 2014 at 20:12

sudo python setup.py install

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

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

+15

merlin-vrn Sep 26 2014 at 20:22

И ещё одно.

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

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

И в догонку про ботнеты: после нескольких последовательных банов определённого сервиса для некоего хоста, можно ещё последовательно расширять горизонт бана: банить негодника на большем числе сервисов, банить на сервисах другого типа на соседних серверах и т. д. Ведь, если хост попал в ботнет и сейчас рассылает спам, не факт, что завтра он не начнёт брутить ssh.

ivanko Sep 26 2014 at 20:50

Вообще, на заре интернета мы пользовались для этого drbl. но система оказалась слишком сложной

bes_internal Sep 27 2014 at 03:12

Вам определенно стоит почитать как работает fil2ban. Если очень кратко, то заданные логи читаются и пропускаются через заданные фильтры (поставляются с fail2ban). Если фильтр что-то находит и при привышении заданного количества в заданное время сообщений применяются задданные действия (поставляются с fail2ban). Просто приведу названия некоторых действий чтобы вам стало более понятно:

complain
iptables
iptables-ipset-proto4
mail-whois

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

merlin-vrn Sep 27 2014 at 08:20

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

я имел ввиду расширение горизонта в том же духе, как сейчас увеличиваются сроки бана и сокращается число допустимых попыток

sebres Sep 27 2014 at 03:28

расширять горизонт бана: банить негодника на большем числе сервисов

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

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

sebres Sep 27 2014 at 03:43

Конечно же true вместо false:

bantime.overalljails = true

ZyXI Sep 27 2014 at 00:10

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

Вы не работали с Python. Если автор Python’овского пакета адекватен и использовал стандартные distutils, то pip install … и cd … && python setup.py install не отличаются по своему результату.

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

merlin-vrn Sep 27 2014 at 08:21

Но только если вы считаете, что управление системными пакетами двумя менеджерами пакетов (pip и apt или что у вас там) — хорошая идея.

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

Данная статья начата с Debian. Пусть хотя бы показано было на нём. Кстати говоря, в Gentoo написать distutils-ebuild очень просто.

Zelgadis Sep 27 2014 at 08:39

Это ужасная идея. Особено в реалиях debian. Мне не редко приходится чекенить отдельный бранч для гема, чтобы работало и ждать пока вольется в master, а вы говорите еще ждать пока мэинтейнер соизволит обновить у себя? Нет, спасибо.

-1

ZyXI Sep 27 2014 at 19:08

Вообще‐то он говорит собрать свой пакет, а не полагаться на какого‐то maintainer’а. Это не так уж и сложно, тем более что для gem’ов наверняка тоже есть что‐то готовое. Я же говорю, что sudo python setup.py install не так уж и страшен, и рассказывать про сборку пакетов в статье про fail2ban совершенно не нужно.

Zelgadis Sep 27 2014 at 20:37

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

-1

ZyXI Sep 28 2014 at 17:57

И? Предложено было собирать свой пакет для дистрибутивного менеджера пакетов. Ни один такой менеджер не запрещает вам быть maintainer’ом своего же пакета. И даже собирать его в той же системе, в которой он будет использоваться.

zviryatko Sep 26 2014 at 21:07

А не подскажете случаем как можно банить адреса которые используют разные логины или банить за использование определенных логинов?

merlin-vrn Sep 26 2014 at 21:11

Первое — не понял, что значит «используют разные логины»? У вас правило — один адрес, один логин или что? А как же NAT?

Второе — тем же самым fail2ban, написать правило, которое ловит именно эти самые определённые запрещённые логины.

zviryatko Sep 26 2014 at 21:24

1) В целом да, есть пару серверов где используется только одна-две учетки
2) Уже нагуглил примеры.

merlin-vrn Sep 26 2014 at 21:26

Тогда про первое — не делать ничего. fail2ban сам подхватит n неудачных попыток зайти с несуществующими логинами и забанит.

zviryatko Sep 26 2014 at 22:19

Ну про это понятно, хочется более интуитивной выборки, вот например в auth.log попадали баны за попытки войти с логином wbcLogonUser, а это то ли дефолтный логин для cpanel, то ли еще что-то, так вот суть в том что максимум попыток у меня равно 3 и в логах длинный список попыток с разных адресов зайти с этим логином. Вот и интересуюсь нет ли фильтра который анализировал бы часто используемые неудачные логины и банил бы сразу без вопросов?

foxmuldercp Sep 27 2014 at 15:27

Если хочется более интуитивной выборки — возьмите и напиши сами под себя.
На среднем сервере веб хостинга как правило живёт вагон сервисов + вагон всякого клиентского хлама, вроде вордпрессов, джумл, прочих cms, которые перебираются, подбираются и ломаются раз в день. Так что «какие логины» для каких «дефолтных логинов» перебирают у Вас, вряд ли перебирают у меня.
Именно потому, что «часто используемые неудачные логины» меняются от сервиса к сервису, а их неисчислимое количество, надо понимать, что есть количество попыток с одного хоста. а что там уже конкретно — дело десятое.

Xakki Sep 26 2014 at 21:09

Я эту проблему решил ещё одним правилом, сканирующий лог самого fail2ban. Те я банил на большее время тех, кто часто светится и навсегда — самых наглых.
Но есть одна идея, проблемная в реализации. Всех забаненных, обращающихся на 80 порт, перенаправлять на статическую страницу (где не банят), с информацией о том, что «ваш IP заблокирован, возможно выш компьютер заражен и является частью ботнета итп». Как это сделать в iptables я не представляю.

merlin-vrn Sep 26 2014 at 21:10

да элементарно, -j REDIRECT их на другой порт, где другой вебсервер показывает эту вашу страницу.

Xakki Sep 26 2014 at 22:36

Нехороший IP банится на весь сервер(по все портам). Получается нужно чтоб iptables игнорировал определённый порт? Как?

merlin-vrn Sep 26 2014 at 23:04

добавить непосредственно перед полным баном разрешение для этого конкретного порта. Примерно так:
-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»
не проверял правила, может и ошибся где-то, но идея видна

merlin-vrn Sep 26 2014 at 23:13

да, правила неправильные в смысле синтаксиса match-set; читайте ман и легко поправите. Там должно быть что-то вроде -m set --match-set banned-ips src

сам по себе список banned-ips подразумевается типа hash:ip или что угодно другое :ip, сообразно ситуации

UUSER Sep 26 2014 at 23:48

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

Хорошая утилита, жаль только ipv6 не умеет пока

sebres Jan 9 2015 at 13:24

У 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 чтобы разбанить себя любимого под рукой нет возможности.

Поэтому формулы и еще раз формулы :)

lexore Sep 26 2014 at 21:42

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

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

friday Sep 26 2014 at 22:35

Оставить только аутентификацию по ключу и банить за любые попытки логина по паролю.

sergey-b Apr 18 2020 at 22:08

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

lexore Apr 18 2020 at 22:13

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

sergey-b Apr 18 2020 at 22:18

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

UFO just landed and posted this here

UUSER Sep 27 2014 at 01:12

Нужны ещё Banned4Spam и Burned4Fun (рандомный наказатель).

UFO just landed and posted this here

bes_internal Sep 27 2014 at 03:37

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

beho1der Sep 27 2014 at 10:19

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

UUSER Sep 27 2014 at 11:27

функционал межсерверного взаимодействия.

github.com/uu/bango
Централизованный забанятор/разбанятор.

UFO just landed and posted this here

soko1 Sep 27 2014 at 20:54

Отличное решение, спасибо за работу.

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

J_o_k_e_R Sep 28 2014 at 10:19

Голосую за полноценную поддержку ipv6. Готов вложиться некоторым количеством рублей.

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

sebres Jun 29 2015 at 16:59

Вот тут ребята баунти для IPv6 открыли, кто готов вложится — деньги кидать здесь: https://www.bountysource.com/issues/1089051-ipv6-support :)

-1

sebres May 17 2016 at 17:03

done, см. https://habrahabr.ru/post/283540/

Konkase Oct 3 2014 at 11:37

На 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

Konkase Oct 3 2014 at 11:47

Заработало на python 2.7

Konkase Oct 3 2014 at 13:05

Всё конечно работает, но работает кривовато. Не работает bantime.increment, в лог валится:

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

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

Буду благодарен, если подскажите в чём дело, у меня к сожалению знания питона на нуле

sebres Oct 6 2014 at 13:05

Observer и новый функционал работают только если в fail2ban.local (или fail2ban.conf) включен банк данных:

dbfile = /var/lib/fail2ban/fail2ban.sqlite3

Я так понимаю у вас оно либо откомментировано, либо не может туда писать.
P.S. По ссылке заглянуть немогу (корпоративные политики, будь они не ладны), но думаю это все же DB.

FireWind Jan 9 2015 at 09:29

А вы в курсе, что файла ./debian/fail2ban.init для выполнения sudo cp ./debian/fail2ban.init /etc/init.d/fail2ban у вас просто нет? Может по этому автоматически не будет стартовать?

sebres Jan 9 2015 at 11:21

Блин, детский сад честное слово… Ну возьмите его из дистрибутива fail2ban_0.9.1-1.debian.tar.xz, в чем проблема то.

Не знаю что там с веткой debian в исходниках на github случилось, был готов поклясться — он там был…

sebres Jan 9 2015 at 11:47

Ну да — он там и был, просто коллега yarikoptic убрал его коммитом 67e79a14624c496f740ed3c63ae28788c6e3b346: now we will use upstream's init for debian
В общем лежит оно теперь в /files/debian-initd. Статью сейчас поправлю.

FireWind Jan 9 2015 at 13:09

Спасибо за помощь!
Я и в правду детский сад — не очень хорошо умею работать с unix, поэтому непонятные сложности ставят в тупик и когда решение не очевидно становится очень грустно.
Еще раз — большое спасибо за помощь — поменяю сейчас дефолтный 0.8.6-3wheezy на ваш (даром что ли столько времени с ним разбирался:))

FireWind Jan 9 2015 at 09:55

Да, и как теперь удалить ваш вариант fail2ban? Скрипт setup.py ни чего, кроме install не предусматривает. Мне на будущее будет уроком не устанавливать на рабочие сервера не проверенные решения.

sebres Jan 9 2015 at 10:56

А его и не надо удалять. Просто ставте родной сверху — если вы fail2ban уже запускали, нужно будет удалить /var/lib/fail2ban/fail2ban.sqlite3, т.к. не совместим.

foxnetwork Jul 30 2015 at 21:40

Стесняюсь спросить, а как сия утилита «работает» с динамическими адресами? То есть ботнет из 10к машин — понятно, но это не означает автоматически 10к фиксированных IP-адресов.

sebres Jul 30 2015 at 21:59

Не хуже чем со статикой (в чем-то лучше, например в том смысле, что плохие адреса не забивают базу на долгие годы). Выглядит как-то так:

динамический IP улетает в бан (например сначала после 3-х failure на 15 мин, затем после 2-х на 45 мин, затем сразу на 3 часа, и в итоге уже на сутки);
грубо говоря, такой IP сделает максимум 5 — 10 попыток в сутки (зависит от настроек)
провайдер как правило меняет адрес раз в сутки (иногда реже)
завтра все повторится опять, а из базы улетит «вчерашняя» динамика (с разницей за минусом purgeage)

Конечно у такой бот-сети подобрать шансы выше, чем у «статичной», но не намного (кроме того провайдеры тоже бдят).
И оно однозначно лучше, чем совсем без «инкремента».

-1

foxnetwork Jul 30 2015 at 22:17

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

sebres Jul 30 2015 at 22:25

Небольшой кусок ботнета, сидящего в сети провайдера с динамическими адресами медленно, но верно, выкосит весь операторский пул

Как вы думаете, сколь долго провайдер будет «терпеть» таких абонентов? Им просто позакрывают порты (например smtp, если подбирает мыло) + письмо счастья (поздравляю у вас вирус).

-1

crossfire Mar 6 2016 at 13:58

Поставил на убунту. По логу работает

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 =

Скажите в чем проблема?

sebres Mar 6 2016 at 15:30

По факту нет...

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

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

[sshd]
enabled = true

[nginx-http-auth]
enabled = true

...

crossfire Mar 6 2016 at 22:55

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

sebres Jul 15 2016 at 12:49

Только-что выкатил пре-релиз 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;
Еще много — много чего другого...

Show the best of all time