nftables vs fail2ban

0 views
Skip to first unread message

Maksim Dmitrichenko

unread,
Nov 21, 2022, 9:40:02 AM11/21/22
to
Всем хай!

Решил я тут значит накрутить на VPS защиту от брутфорса по ssh. Давно не брал я в руки шашек и за это время iptables оказалось на свалке истории и в моде нынче nftables.

Беглый гугл выдает, что для реализации блокировки по перебору нужно ставить fail2ban [1] или sshguard [2]. Даже если nftables. 

При этом красношапочный мануал говорит [3] о том, что nftables и сам готов справится с этой задачей без дополнительных свистоперделок.

В связи с чем вопрос: предлагают ли fail2ban или sshguard какую-то важную дополнительную функциональность, или использование nftables вполне способно самостоятельно решить эту задачу прекрасно и надежно?

--
With best regards
  Maksim Dmitrichenko

Stanislav Vlasov

unread,
Nov 21, 2022, 10:01:31 AM11/21/22
to
21.11.2022, Maksim Dmitrichenko<dmit...@gmail.com> написал(а):

> Беглый гугл выдает, что для реализации блокировки по перебору нужно ставить
> fail2ban [1] или sshguard [2]. Даже если nftables.
>
> При этом красношапочный мануал говорит [3] о том, что nftables и сам готов
> справится с этой задачей без дополнительных свистоперделок.
>
> В связи с чем вопрос: предлагают ли fail2ban или sshguard какую-то важную
> дополнительную функциональность, или использование nftables вполне способно
> самостоятельно решить эту задачу прекрасно и надежно?

Блокировка через nftables отлично заблокирует вполне легитимный
параллельный запуск чего-нибудь из скриптов. Это больше ограничение по
флуду и неприменимо, если есть вариант, что потребуется запускать
что-то типа for i in ...; do ssh $host "$command $i"; done

fail2ban же проанализирует логи и забанит только тех, кто пытается
подобрать пароль.

--
Stanislav

Maksim Dmitrichenko

unread,
Nov 21, 2022, 11:01:31 AM11/21/22
to

пн, 21 нояб. 2022 г. в 18:53, Stanislav Vlasov <stanis...@gmail.com>:
Блокировка через nftables отлично заблокирует вполне легитимный
параллельный запуск чего-нибудь из скриптов. Это больше ограничение по
флуду и неприменимо, если есть вариант, что потребуется запускать
что-то типа for i in ...; do ssh $host "$command $i"; done

Вроде бы не мой случай. Но это какое-то зло в любом случае, если там может быть один хост в нескольких командах.
 

fail2ban же проанализирует логи и забанит только тех, кто пытается
подобрать пароль.

То есть fail2ban занимается парсингом логов и зависит от того, чтобы тот или иной сервис не дай бог не изменил формат логов? Какое-то весьма себе костыльное решение, которое ко всему прочему обязывает вести локальный, а не remote, лог.

Andrey Jr. Melnikov

unread,
Nov 21, 2022, 12:30:03 PM11/21/22
to
Maksim Dmitrichenko <dmit...@gmail.com> wrote:
> [-- text/plain, encoding base64, charset: UTF-8, 25 lines --]

> пн, 21 нояб. 2022 г. в 18:53, Stanislav Vlasov <stanis...@gmail.com>:

> > Блокировка через nftables отлично заблокирует вполне легитимный
> > параллельный запуск чего-нибудь из скриптов. Это больше ограничение по
> > флуду и неприменимо, если есть вариант, что потребуется запускать
> > что-то типа for i in ...; do ssh $host "$command $i"; done
> >

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

> > fail2ban же проанализирует логи и забанит только тех, кто пытается
> > подобрать пароль.

> То есть fail2ban занимается парсингом логов и зависит от того, чтобы тот
> или иной сервис не дай бог не изменил формат логов? Какое-то весьма себе
sshguard занимается тем-же. Да и любой блокировщие будет заниматься
парсингом логов.

> костыльное решение, которое ко всему прочему обязывает вести локальный, а
> не remote, лог.
ты что, это fail2ban... там модулей на любой чих понаписанно. Можно
поставить на сервер с логами, а рулить фарволом в совершенно другом месте.
Можно поставить mysql и сделать через это "централизованную базу"
блокировок.

А так, для своих задач демон пишется на perl за 2 часа с перерывами на кофе.

Victor Wagner

unread,
Nov 21, 2022, 4:00:03 PM11/21/22
to
В Mon, 21 Nov 2022 18:36:43 +0400
Maksim Dmitrichenko <dmit...@gmail.com> пишет:

> Всем хай!
>
> Решил я тут значит накрутить на VPS защиту от брутфорса по ssh. Давно

Самая лучшая защита от брутфораса паролей это PasswordAuthentication no
в /etc/sshd_config. Пользуйтесь только авторизацией по ключам и все
будет хорошо.




--
Victor Wagner <vi...@wagner.pp.ru>

Stanislav Vlasov

unread,
Nov 21, 2022, 9:51:23 PM11/21/22
to
22.11.2022, li...@mail.ru<li...@mail.ru> написал(а):
> 21.11.2022 23:48, Victor Wagner пишет:
>
>> Самая лучшая защита от брутфораса паролей это PasswordAuthentication no
>> в /etc/sshd_config. Пользуйтесь только авторизацией по ключам и все
>> будет хорошо.
>
> По моему опыту это лишь спасает от результативного брутфорса, но не от
> постоянных попыток подобрать пароль ботами. Мне всегда было интересно:
> это что, так сложно написать бот, который понимает, что у пользователя
> на хосте авторизация по ключу и исключить ip/username из своей базы по
> перебору паролей? Или ботоводы надеются, что через пару минут я внезапно
> сменю авторизацию по ключу на авторизацию по паролю?

Со стороны клиента не видно, какая там авторизация по ssh.
Точно так же, как не видно, какие пользователи есть на сервере.

--
Stanislav

Victor Wagner

unread,
Nov 21, 2022, 11:40:02 PM11/21/22
to
В Tue, 22 Nov 2022 07:48:29 +0500
Stanislav Vlasov <stanis...@gmail.com> пишет:


> > интересно: это что, так сложно написать бот, который понимает, что
> > у пользователя на хосте авторизация по ключу и исключить
> > ip/username из своей базы по перебору паролей? Или ботоводы
> > надеются, что через пару минут я внезапно сменю авторизацию по
> > ключу на авторизацию по паролю?
>
> Со стороны клиента не видно, какая там авторизация по ssh.
> Точно так же, как не видно, какие пользователи есть на сервере.
>

запустите ssh -v и увидите что клиенту видно, что нет.


--
Victor Wagner <vi...@wagner.pp.ru>

Stanislav Vlasov

unread,
Nov 22, 2022, 12:21:39 AM11/22/22
to
вт, 22 нояб. 2022 г. в 09:35, Victor Wagner <vi...@wagner.pp.ru>:
> > > интересно: это что, так сложно написать бот, который понимает, что
> > > у пользователя на хосте авторизация по ключу и исключить
> > > ip/username из своей базы по перебору паролей? Или ботоводы
> > > надеются, что через пару минут я внезапно сменю авторизацию по
> > > ключу на авторизацию по паролю?
> >
> > Со стороны клиента не видно, какая там авторизация по ssh.
> > Точно так же, как не видно, какие пользователи есть на сервере.
> >
>
> запустите ssh -v и увидите что клиенту видно, что нет.

Запустил.
Непосредственно перед приглашением ввести пароль после неудачных
попыток авторизоваться ключом:
debug1: Next authentication method: password
После ввода пароля:
debug1: Authentications that can continue: publickey,password

Доступ руту с паролем запрещён (PermitRootLogin without-password), но
это не видно со стороны клиента.
Точно такое же поведение - при попытке зайти несуществующим пользователем.

Вот именно под этим я и понимаю "не определить". То есть для
конкретного юзера, а не общесистемно.

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

--
Stanislav
Reply all
Reply to author
Forward
0 new messages