Ограничение времени или количества попыток ввода пароля в SQUID

Как сделать, чтобы он не позволял вводить кучу паролей в секунду

Решение для Linux.

блокировал пользователя

Не надо так делать.

ip после определённого числа попыток

Я уже не помню, но PAM доносит в syslog неудачные попытки логина (не помню, распространяется ли это на удалённый доступ и прочее), которые ты можешь скармливать fail2ban.

сколько ни парси access.log

Не туда копаешь, ящитаю.

В гугле не нашёл.

Я нашёл с первого раза. Но это про PAM. Про Squid не подскажу.

Решение для Linux.

Как ни странно, но pam_faildelay.so delay=2000000 уже выставлен по умолчанию, но это никак не влияет на возможность ввода пароля сколько угодно раз в секунду.

Я уже не помню, но PAM доносит в syslog неудачные попытки логина (не помню, распространяется ли это на удалённый доступ и прочее), которые ты можешь скармливать fail2ban.

Увы, на winbindd это, похоже не распространяется. Никаких следов в логах я не нашёл.

Беда как раз в том, что нет ни одного лога, куда падало бы сообщение о попытке авторизации. Сейчас копаю в сторону дебага pam, чтобы писало подробный лог. Пока не разобрался.

Не надо так делать.

Ну, почему? Нормальная практика, если после 5 неудачных попыток ввода пароля пользователь будет блокироваться на 10 минут.
И, вроде, модуль pam_tally2 как раз для этого предназначен. Только не работает. Добавляю в /etc/password-auth, никакого эффекта не вижу.

Прям проверил: при обычной аутенфикации сообщения валятся в /var/log/secure, куда и должны. Причём при неудачном вводе пароля локального пользователя туда же пишется и попытка winbindd проверить пароль пользователя.

При логине через SQUID и winbindd соответственно, туда ничего не пишется.

Нормальная практика – блокировать IP, с которого идет перебор, а не пользователя. Блокировать юзера это ССЗБ.

Да, я бы рад блокировать IP. Мне бы для начала зафиксировать попытку логина с IP.
squid, ntlm_auth, winbindd и pam дружно не пишут логов при совместной работе.

Я бы посмотрел на логи сквида если включить отладку для секции 29

section 29 Authenticator
section 29 Negotiate Authenticator
section 29 NTLM Authenticator

Но вот блокировку/задержку видимо придется тебе писать самостоятельно.

Как ни странно, но pam_faildelay.so delay=2000000 уже выставлен по умолчанию, но это никак не влияет на возможность ввода пароля сколько угодно раз в секунду.

Значит оно работает мимо PAM. На этом наши полномочия всё.

Увы, на winbindd это, похоже не распространяется. Никаких следов в логах я не нашёл.

А и не должно. winbind занимается трансляцией пользователей, а не их логином.

Беда как раз в том, что нет ни одного лога, куда падало бы сообщение о попытке авторизации.

Если у тебя логин происходит где-то в вебморде, то подозреваю что PAM вообще не при делах (не его задача).

Нормальная практика

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

И, вроде, модуль pam_tally2 как раз для этого предназначен. Только не работает.

Ох, я tally последний раз видел лет десять назад, уже не помню что там с ним делать. Но я всё равно подозреваю что у тебя всё работает мимо PAM.

Кстати мне тоже интересно

а фильтр /etc/fail2ban/filter.d/squid.conf включали?

# Fail2Ban filter for Squid attempted proxy bypasses
#
#

[Definition]

failregex = ^\s+\d\s<HOST>\s+[A-Z_]+_DENIED/403 .*$
            ^\s+\d\s<HOST>\s+NONE/405 .*$

ignoreregex =

datepattern = {^LN-BEG}Epoch
              {^LN-BEG}

# Author: Daniel Black

а фильтр /etc/fail2ban/filter.d/squid.conf включали?

Да, включал. С этого и начал.
В логи сыпяться ошибки 407. 403 и 405 появляются только, если пользователь отказывается от авторизации. А заодно, если пользователь пойдёт на запрещённые страницы, его забанит. Что нежелательно.

Значит оно работает мимо PAM. На этом наши полномочия всё.

Ну, как ни странно, оно не мешает и пароль ssh вводить чаще, чем раз в 20 минут. Или что там? Милисекунды? Тогда раз в 333,(3) минуты :)

Ох, я tally последний раз видел лет десять назад, уже не помню что там с ним делать. Но я всё равно подозреваю что у тебя всё работает мимо PAM.

Я тоже. Тем не менее, с tally2 хотелось бы разобраться. Выглядит как очень полезный модуль.

Я бы посмотрел на логи сквида если включить отладку для секции 29

Мляяяяя..... Да, там есть полезная информация. Я даже смотрел её до этого. Информация об аутентификации, там появляется только на 9 уровне отладки. Можешь представить, сколько там всего сыпется. Очень надеюсь, что удастся обойтись без этого. Хотя, этот путь кажется мне сейчас всё более и более правильным.

--
upd
На 9 уровне отладки появляется информация об IP. Информация о факте аутенфикации появляется раньше.

Также, похоже, что туда сыпятся аналоги ошибки 407. То есть, после аутенфикации пользователя, туда не перестают сыпаться ошибки, неотличимые от запроса аутенфикации. Пойду поплачу, что ли. Вдруг поможет...

Если только на 9-м уровне, то это неприемлемо.

IMHO подправить имеющийся хелпер более правильное решение. Проверять наличие файла по имени юзера + IP где-нибудь в ramfs и при наличие такого отказывать в доступе - не так сложно.

А fail2ban научить создавать/удалять такой файл.

Нормальная практика

Перебирает пароли, очевидно, злоумышленник, а блокируется доступ у честного пользователя. Получается какое-то наказание невиновных и награждение непричастных. А ещё отличный способ устроить Denial of service - просто ввести пять раз неправильно пароль неугодного юзера (злоумышленник имеет хотя бы какие-то допущения о логине жертвы, иначе бы не подбирал пароль) и парализовать его работу. Блокировать можно только IP, с которого сыпятся неверные пароли. И то лучше не навсегда, а на время (чтобы сделать перебор бессмысленным на такой скорости, но и не отстрелить себе ногу).

Если только на 9-м уровне, то это неприемлемо.

Если бы это давало нормальный результат, то не вопрос перенаправить лог сразу на обработку парсеру, а потом удалять.

Проблема в том, что в случае успешной попытки входа имя пользователя фиксируется, а в случае неуспешной — нет. Так что всё, что я могу выцепить из отладки я могу не менее успешно выцепить и из access.log.

Хоть в самом деле хелпер переписывать.

Или... Кто-нибудь может подсказать, как написать скрипт, который будет подставляться вместо ntlm_auth в squid.conf, делать свою работу, а потом передавать данные в ntlm_auth, чтобы всё шло дальше своим чередом?

auth_ntml не совсем простой (как basic_* и external acl)

Но у него есть свои хелперы, а вот протокол взаимодействия с ними текстовый. Теоретически его можно подсматривать простейшим скриптом. Главное чтоб буферизация была отключена или строчной была.

Кстати, у хелперов можно включить отладочный вывод.

Никогда не имел необходимости использовать auth_ntml, т.ч. про него более конкретно подсказать не могу.

Отладочный вывод ntlm_auth пишет имя пользователя при удачной попытке и не пишет ничего при неудачной. Вернее, пишет тоже самое, что при неавторизованных запросах. Что не позволяет выделить критерии блокировки. Увы.