Перейти к содержимому
Калькуляторы

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

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

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

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

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

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

Реально?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

Реально?

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Имеет ли смысл натравливать 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 тут будет неэффективен?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Если банить не хосты, а подсети — вполне имеет смысл.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

10 минут назад, myth сказал:

на accel переехать не вариант?

У меня был вопрос не про pptp/pppoe

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

21 минуту назад, boco сказал:

уходят в бан надолго

Можно ваш фрагмент конфига для fail2ban относительно smtp?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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 =

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В 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
... 

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

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

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.