Jump to content
Калькуляторы

Freeradius - ограничить кол-во неудачных попыток авторизации Возможно ли?

Возможно ли ограничить кол-во неудачных попыток авторизации в минуту во freeradius 1.1.8?

Например, клиент заблокирован, у него установлен роутер, который каждые 3-4 секунды отправляет запрос на авторизацию.

При этом радиус каждый раз дёргает MySQL. Если таких клиентов много, системе становится грустно..

Хотелка такая - например, 10 неудачных попыток авторизации в минуту - "бан" на 30 мин.

"Бан" - это в течении 30 мин. давать отлуп забаненой связке логин/пароль "на входе", лучше бы даже непосредственно на NAS-е (mpd5), ну или хотя бы не обращаясь к базе данных.

Реально?

Share this post


Link to post
Share on other sites

Возможно ли ограничить кол-во неудачных попыток авторизации в минуту во freeradius 1.1.8?

Например, клиент заблокирован, у него установлен роутер, который каждые 3-4 секунды отправляет запрос на авторизацию.

При этом радиус каждый раз дёргает MySQL. Если таких клиентов много, системе становится грустно..

Хотелка такая - например, 10 неудачных попыток авторизации в минуту - "бан" на 30 мин.

"Бан" - это в течении 30 мин. давать отлуп забаненой связке логин/пароль "на входе", лучше бы даже непосредственно на NAS-е (mpd5), ну или хотя бы не обращаясь к базе данных.

Реально?

МуSQL маньяки разгоняли до десятков тысяч запросов в секунду. У вас такие серьезные потребности?

Может быть просто MySQL потюнить? Проверить, что там вообще, почему спотыкается, память добавить, количество сетевых соединений, индексы проверить, еще что...

Share this post


Link to post
Share on other sites

Мне кажется, начать с разгона query cache в MySQL.

Можно еще rlm_cache навесить на Reject-ы.

 

О, гениальные варианты:

1) Навесить на mpd5 fail2ban, банить PPTP/PPPoE/чтотамувас.

2) Отвечать вместо Reject-а Accept-ом с левым IP и, скажем, максимальным временем сессии 10 минут.

Share this post


Link to post
Share on other sites

Мне кажется, начать с разгона query cache в MySQL.

MySQL "разогнан". Дело не конкретно в нём. Проблема в кривом древнем модуле радиуса (rlm_nibs).

В нём автор конкретно накосячил в плане работы с базой.

В результате процесс radius-а в определённые моменты начинает жрать память, не освобождая её, распухая до неимоверных размеров.

В итоге он переползает в своп, съедает его, ну а дальше - аварийный останов в самое неподходящее время..

Ошибки кое-где удалось найти и исправить, результат есть, но полной уверенности нет.

Поэтому и появилась "хотелка" дополнительно подстраховаться проверенными средствами самого радиуса.

Можно еще rlm_cache навесить на Reject-ы.

Каким образом, и что это даст??

 

О, гениальные варианты:

1) Навесить на mpd5 fail2ban, банить PPTP/PPPoE/чтотамувас.

Гм.. ИМХО, чушь какая-то. Учитывая, что в большинстве своём используется PPPoE.

2) Отвечать вместо Reject-а Accept-ом с левым IP и, скажем, максимальным временем сессии 10 минут.

Собственно уже реализовано, но не совсем устраивает. Особенно для тех клиентов, которые "позабыли" выключить роутер три-четыре месяца тому назад.

Share this post


Link to post
Share on other sites

Учитывая, что в большинстве своём используется PPPoE.

А если попробовать подумать в сторону ebtables.

Не использовал его, но если им можно отлимитировать 0x8863 кадры, по типу модуля xt_recent,

и допустим банить на 30 минут такой мак.

Share this post


Link to post
Share on other sites

rlm_cache будет сразу давать отлуп, не вызывая rlm_nibs.

Собственно уже реализовано, но не совсем устраивает. Особенно для тех клиентов, которые "позабыли" выключить роутер три-четыре месяца тому назад.

Ну так выдавайте с Max-Session-Time минут на 30. Будет спрашивать авторизацию раз в 30 минут.

В чем проблема с роутерами?

Share this post


Link to post
Share on other sites

Не заметил относительно Access-Accept для заблоченных, так если оно реализовано то в чём проблема,

пусть висят себе с серыми айпишниками.

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

килять сессию, чтобы реконнектнулся с нормальным ip.

Share this post


Link to post
Share on other sites

Имеет ли смысл натравливать fail2ban на smtp-попытки , которые сыпятся постоянно:

Mar  2 06:27:25 mail postfix/smtpd[13548]: warning: unknown[141.98.10.76]: SASL LOGIN authentication failed: authentication failure
Mar  2 06:27:25 mail postfix/smtpd[5680]: warning: unknown[46.148.40.136]: SASL LOGIN authentication failed: authentication failure
Mar  2 06:27:26 mail postfix/smtpd[13548]: disconnect from unknown[141.98.10.76]
Mar  2 06:27:26 mail postfix/smtpd[7124]: warning: unknown[46.148.40.199]: SASL LOGIN authentication failed: authentication failure
Mar  2 06:27:26 mail postfix/smtpd[11008]: connect from unknown[141.98.10.151]
Mar  2 06:27:27 mail postfix/smtpd[430]: connect from unknown[46.148.40.143]
Mar  2 06:27:27 mail postfix/smtpd[5680]: lost connection after AUTH from unknown[46.148.40.136]
Mar  2 06:27:27 mail postfix/smtpd[5680]: disconnect from unknown[46.148.40.136]
Mar  2 06:27:27 mail postfix/smtpd[9444]: warning: unknown[141.98.10.151]: SASL LOGIN authentication failed: authentication failure
Mar  2 06:27:27 mail postfix/smtpd[32642]: connect from unknown[46.148.40.146]
Mar  2 06:27:27 mail postfix/smtpd[2417]: warning: unknown[46.148.40.13]: SASL LOGIN authentication failed: authentication failure
Mar  2 06:27:27 mail postfix/smtpd[2407]: connect from unknown[46.148.40.199]
Mar  2 06:27:27 mail postfix/smtpd[9444]: disconnect from unknown[141.98.10.151]

Или эти тычки идут постоянно с разных подсеток и fail2ban тут будет неэффективен?

Share this post


Link to post
Share on other sites

в моем случае эти редиски выжирали весь лимит процессов exim. после применения fail2ban кардинально полегчало. адреса, конечно, появляются новые, но довольно быстро уходят в бан надолго.

# fail2ban-client status exim | egrep '(Currently|Total) banned'
   |- Currently banned: 7700
   |- Total banned:     109029

 

Share this post


Link to post
Share on other sites

root@mail:~ # egrep -v '^[[:space:]]*(|#.*)$' /usr/local/etc/fail2ban/jail.local
[INCLUDES]
before = paths-freebsd.conf
[DEFAULT]
ignoreip = 127.0.0.1/8 ::1 192.168.0.0/16
ignorecommand =
bantime  = 1h
bantime.increment = true
findtime  = 1h
maxretry = 5
maxmatches = %(maxretry)s
backend = auto
usedns = warn
logencoding = auto
enabled = false
mode = normal
filter = %(__name__)s[mode=%(mode)s]
destemail = xxx@xxx.ru
sender = root@mail.xxx.ru
mta = sendmail
protocol = tcp
chain = <known/chain>
port = 0:65535
fail2ban_agent = Fail2Ban/%(fail2ban_version)s
banaction = iptables-multiport
banaction_allports = iptables-allports
action_ = %(banaction)s[port="%(port)s", protocol="%(protocol)s", chain="%(chain)s"]
action_mw = %(action_)s
            %(mta)s-whois[sender="%(sender)s", dest="%(destemail)s", protocol="%(protocol)s", chain="%(chain)s"]
action_mwl = %(action_)s
             %(mta)s-whois-lines[sender="%(sender)s", dest="%(destemail)s", logpath="%(logpath)s", chain="%(chain)s"]
action_xarf = %(action_)s
             xarf-login-attack[service=%(__name__)s, sender="%(sender)s", logpath="%(logpath)s", port="%(port)s"]
action_cf_mwl = cloudflare[cfuser="%(cfemail)s", cftoken="%(cfapikey)s"]
                %(mta)s-whois-lines[sender="%(sender)s", dest="%(destemail)s", logpath="%(logpath)s", chain="%(chain)s"]
action_blocklist_de  = blocklist_de[email="%(sender)s", service="%(__name__)s", apikey="%(blocklist_de_apikey)s", agent="%(fail2ban_agent)s"]
action_badips = badips.py[category="%(__name__)s", banaction="%(banaction)s", agent="%(fail2ban_agent)s"]
action_badips_report = badips[category="%(__name__)s", agent="%(fail2ban_agent)s"]
action_abuseipdb = abuseipdb
action = %(action_)s
[exim]
enabled = true
action = exim-ipfw[table=3]
logpath = %(exim_main_log)s
root@mail:~ # egrep -v '^[[:space:]]*(|#.*)$' /usr/local/etc/fail2ban/action.d/exim-ipfw.conf
[Definition]
actionstart =
actionstop =
actioncheck =
actionban = /sbin/ipfw table <table> add <ip>
actionunban = /sbin/ipfw table <table> delete <ip>
[Init]
localhost = 127.0.0.1
root@mail:~ # egrep -v '^[[:space:]]*(|#.*)$' /usr/local/etc/fail2ban/filter.d/exim.local
[INCLUDES]
before = exim-common.conf
[Definition]
failregex = ^%(pid)s \w+ authenticator failed for (?:[^\[\( ]* )?(?:\(\S*\) )?\[<HOST>\](?::\d+)?(?: I=\[\S+\](:\d+)?)?: 535 Incorrect authentication data( \(set_id=.*\)|: \d+ Time\(s\))?\s*$
            <mdre-<mode>>
mdre-aggressive = ^%(pid)s no host name found for IP address <HOST>$
                  ^%(pid)s no IP address found for host \S+ \(during SMTP connection from \[<HOST>\]\)$
mdre-normal =
mode = normal
ignoreregex =

 

Share this post


Link to post
Share on other sites

В 04.03.2023 в 16:50, Andrei сказал:

Или эти тычки идут постоянно с разных подсеток и fail2ban тут будет неэффективен?

 

Если поставить findtime побольше - где-то час-два - и количество попыток снизить до 2, то тыкальщики достаточно оперативно залетают в банлист. Ну и время нахождения в бане тоже надо полнять от дефолтного часа хотя бы до суток, можно и больше.

Share this post


Link to post
Share on other sites

В 04.03.2023 в 11:50, Andrei сказал:

натравливать fail2ban на smtp-попытки

 

В 04.03.2023 в 12:54, boco сказал:

после применения fail2ban кардинально полегчало. адреса, конечно, появляются новые, но довольно быстро уходят в бан надолго.

 

А для Sendmail примеры адаптации fail2ban есть?

Возможность прохождения SMTP-аутентификации требуется не более 10% пользователей, прописываю их в отдельной базе sasldb2.

После перехода на FreeBSD 13.2 с Sendmail 8.17.1 эти записи очень перенасыщают maillog мусором.

На более старых системах с Sendmail 8.14.6, 8.15.2 понятно тычки были, но хотя бы без дополнительного логирования в основной журнал работы сервера.

Банить подсетями, как выше предлагалось, возможно слишком радикально, вшивая овца может подставить и оградить надолго вполне честный диапазон.

Думал уменьшить уровень логирования или разделить его вывод в разные файлы (если возможно), но вариант с fail2ban более верный.

В общем полезно услышать мнения и как решали схожий вопрос.

...

...
Jan 13 18:44:38 sm-mta[11029]: 40DFiXAC011029: AUTH failure (CRAM-MD5): user not found (-20) SASL(-13): user not found: user: sed@mydomain.com property: cmusaslsecretCRAM-MD5 not found in sasldb /usr/local/etc/sasldb2, user=sed, relay=[121.162.147.204]
Jan 13 18:44:40 sm-mta[11029]: 40DFiXAC011029: [121.162.147.204] did not issue MAIL/EXPN/VRFY/ETRN during connection to MSA

Jan 13 18:44:53 sm-mta[11038]: 40DFioDX011038: AUTH failure (CRAM-MD5): user not found (-20) SASL(-13): user not found: user: usenet@mydomain.com property: cmusaslsecretCRAM-MD5 not found in sasldb /usr/local/etc/sasldb2, user=usenet@mydomain.com, relay=[216.126.65.186]
Jan 13 18:44:54 sm-mta[11038]: 40DFioDX011038: [216.126.65.186] did not issue MAIL/EXPN/VRFY/ETRN during connection to MSA
... 

 

 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.