Fail2Ban больше не нужен? Разбираем PerSourcePenalties в OpenSSH на Ubuntu 26.04

[aborouhin]

Есть (overflow:permissive)

Скорее уж overflow:deny-all плюс фиксированный IP для аварийного доступа в PerSourcePenaltyExemptList

А permissive, если я правильно понял, при достаточно мощной атаке как раз позволит пробить PerSourcePenalty и загрузить уже основной процесс sshd, так что и администратор не пробьётся.

[j_larkin]

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

[aborouhin]

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

Режим overflow включается, если количество IP (а не подключений!) превышает max-sources4 / max-sources6, которые каждый по дефолту 65536. Что-то у меня подозрения, что при атаке с такого количества адресов средний сервер действительно умрёт куда раньше, чем до этого overflow, какой бы режим ни был выбран, вообще дойдёт дело. Да и вообще, для нас простых людей гораздо реалистичнее сценарий, когда несколько сошедших с ума ботов долбятся с одних и тех же IP каждые N миллисекунд, чем когда идёт DDoS с тысяч IP, да ещё и именно на SSH. Первое у себя видел, от второго Бог пока миловал :)

А вот есть ли механизм защиты от перегрузки процесса при большом количестве одновременных соединений (а не IP)? Я такого не нашёл. Получается, что если sshd-session захлебнётся, мы теряем пациента. А захлебнётся он, IMHO, всё-таки быстрее, чем nftables, работающий в kernel space. Так что ещё один плюсик в карму fail2ban (помимо того, что он нам, конечно, и для других jail'ов всё равно нужен)

[j_larkin]

можно попробовать на тестовом стенде запустить многопоточный брутфорс при чем с нескольких IP. Но это нужно делать когда сервера физические. Намоем стенде все виртуалки, не думаю, что при таком сетапе эксперимент будет чистым. Так как брут сам по себе будет нагружать ЦПУ, и это может сказаться на подопытной ВМ.
Я, кстати, не уверен, что такую нагрузку можно сгенерировать таким способом. Хотя идея привлекательная. Было бы интересно такое реализовать.
Ну и как я писал в статье, наличие этой фичи, не означает, что f2b теперь не нужен.

[aborouhin]

У меня есть физические (собственно, только на них SSH наружу и торчит), но я не настолько заинтересовался вопросом, чтобы так заморочиться :)

[j_larkin]

Понимаю. У меня просто спортивный интерес. Я из пачнота сначала вообще не понял про что речь. Потом погуглил немного и не нашёл чего-то, что объяснило весь функционал. Решил разобраться. Так статья и появилась.

[gotch]

Если стоит как в Azure по умолчанию - аутентификация только по ключу, то всё это не актуально?

И хотел ещё уточнить - а за сколько не продаёте?

[aborouhin]

аутентификация только по ключу, то всё это не актуально?

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

[gotch]

Понял, спасибо большое

[j_larkin]

Нет, аутентификация по ключу спасает от того, что пароль всё таки подберут. Но пытаться всё равно будут, так как снаружи не видно пароль у Вас там или ключи.

Уточняю, ни за сколько не продаю =)

[gotch]

Ясно, спасибо за объяснение и за статью. Есть повод теперь её внимательно прочитать.

[firegurafiku]

Когда количество отслеживаемых источников превышает лимит, сервер переходит в «мягкий» режим: перестаёт добавлять новые IP в таблицу штрафов, но не блокирует их. Это предотвращает DoS-атаку на сам механизм защиты. Эффективность механизма при этом значительно снижается.

По-моему, у вас тут фактическая ошбка: тут утверждается, что при заполнении таблицы новые соединения автоматически разрешаются. Но давайте посмотрим документацию:

There are two operating modes: deny-all, which denies all incoming connections other than those exempted via PerSourcePenaltyExemptList until a penalty expires, and permissive, which allows new connections by removing existing penalties early (default: permissive).

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

/* Delete the soonest-to-expire penalties. */

https://github.com/openssh/openssh-portable/blob/ac4a41265a3beccba7dc6f45c657298311280f01/srclimit.c#L311

[j_larkin]

Спасибо за уточнение, поправил этот момент в статье. Карму, к сожалению, начислить не дает. По этому могу только плюсануть.

[aborouhin]

Ещё одна мысль возникла - это же дело надо как-то мониторить (и просто статистики ради, и чтобы отлавливать аномальные всплески). Для fail2ban есть экспортер, а тут что-то сходу ничего готового из коробки не нашёл. Хотя написать тривиально, если формат лога стабильный. Можно даже не полноценный экспортер, а скриптик, который пишет файл для textfile collector node-exporter'а.