info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
nftables vs fail2ban
2 views
Skip to first unread message
Maksim Dmitrichenko
Nov 21, 2022, 9:40:02 AM11/21/22
to
Всем хай!
Решил я тут значит накрутить на VPS защиту от брутфорса по ssh. Давно не брал я в руки шашек и за это время iptables оказалось на свалке истории и в моде нынче nftables.
Беглый гугл выдает, что для реализации блокировки по перебору нужно ставить fail2ban [1] или sshguard [2]. Даже если nftables.
При этом красношапочный мануал говорит [3] о том, что nftables и сам готов справится с этой задачей без дополнительных свистоперделок.
В связи с чем вопрос: предлагают ли fail2ban или sshguard какую-то важную дополнительную функциональность, или использование nftables вполне способно самостоятельно решить эту задачу прекрасно и надежно?
Решил я тут значит накрутить на VPS защиту от брутфорса по ssh. Давно не брал я в руки шашек и за это время iptables оказалось на свалке истории и в моде нынче nftables.
Беглый гугл выдает, что для реализации блокировки по перебору нужно ставить fail2ban [1] или sshguard [2]. Даже если nftables.
При этом красношапочный мануал говорит [3] о том, что nftables и сам готов справится с этой задачей без дополнительных свистоперделок.
В связи с чем вопрос: предлагают ли fail2ban или sshguard какую-то важную дополнительную функциональность, или использование nftables вполне способно самостоятельно решить эту задачу прекрасно и надежно?
[1] https://workaround.org/buster/firewalling-and-brute-force-mitigation/
[2] https://wiki.archlinux.org/title/nftables#Prevent_brute-force_attacks
-- [2] https://wiki.archlinux.org/title/nftables#Prevent_brute-force_attacks
With best regards
Maksim Dmitrichenko
Maksim Dmitrichenko
Stanislav Vlasov
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
> Беглый гугл выдает, что для реализации блокировки по перебору нужно ставить
> fail2ban [1] или sshguard [2]. Даже если nftables.
>
> При этом красношапочный мануал говорит [3] о том, что nftables и сам готов
> справится с этой задачей без дополнительных свистоперделок.
>
> В связи с чем вопрос: предлагают ли fail2ban или sshguard какую-то важную
> дополнительную функциональность, или использование nftables вполне способно
> самостоятельно решить эту задачу прекрасно и надежно?
параллельный запуск чего-нибудь из скриптов. Это больше ограничение по
флуду и неприменимо, если есть вариант, что потребуется запускать
что-то типа for i in ...; do ssh $host "$command $i"; done
fail2ban же проанализирует логи и забанит только тех, кто пытается
подобрать пароль.
--
Stanislav
Maksim Dmitrichenko
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
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 часа с перерывами на кофе.
> [-- 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 занимается парсингом логов и зависит от того, чтобы тот
> или иной сервис не дай бог не изменил формат логов? Какое-то весьма себе
парсингом логов.
> костыльное решение, которое ко всему прочему обязывает вести локальный, а
> не remote, лог.
поставить на сервер с логами, а рулить фарволом в совершенно другом месте.
Можно поставить mysql и сделать через это "централизованную базу"
блокировок.
А так, для своих задач демон пишется на perl за 2 часа с перерывами на кофе.
Victor Wagner
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>
Maksim Dmitrichenko <dmit...@gmail.com> пишет:
> Всем хай!
>
> Решил я тут значит накрутить на VPS защиту от брутфорса по ssh. Давно
в /etc/sshd_config. Пользуйтесь только авторизацией по ключам и все
будет хорошо.
--
Victor Wagner <vi...@wagner.pp.ru>
Stanislav Vlasov
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 пишет:
> постоянных попыток подобрать пароль ботами. Мне всегда было интересно:
> это что, так сложно написать бот, который понимает, что у пользователя
> на хосте авторизация по ключу и исключить ip/username из своей базы по
> перебору паролей? Или ботоводы надеются, что через пару минут я внезапно
> сменю авторизацию по ключу на авторизацию по паролю?
Со стороны клиента не видно, какая там авторизация по ssh.
Точно так же, как не видно, какие пользователи есть на сервере.
--
Stanislav
> 21.11.2022 23:48, Victor Wagner пишет:
>
>> Самая лучшая защита от брутфораса паролей это PasswordAuthentication no
>> в /etc/sshd_config. Пользуйтесь только авторизацией по ключам и все
>> будет хорошо.
>
> По моему опыту это лишь спасает от результативного брутфорса, но не от
>> Самая лучшая защита от брутфораса паролей это PasswordAuthentication no
>> в /etc/sshd_config. Пользуйтесь только авторизацией по ключам и все
>> будет хорошо.
>
> постоянных попыток подобрать пароль ботами. Мне всегда было интересно:
> это что, так сложно написать бот, который понимает, что у пользователя
> на хосте авторизация по ключу и исключить ip/username из своей базы по
> перебору паролей? Или ботоводы надеются, что через пару минут я внезапно
> сменю авторизацию по ключу на авторизацию по паролю?
Со стороны клиента не видно, какая там авторизация по ssh.
Точно так же, как не видно, какие пользователи есть на сервере.
--
Stanislav
Victor Wagner
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 <stanis...@gmail.com> пишет:
> > интересно: это что, так сложно написать бот, который понимает, что
> > у пользователя на хосте авторизация по ключу и исключить
> > ip/username из своей базы по перебору паролей? Или ботоводы
> > надеются, что через пару минут я внезапно сменю авторизацию по
> > ключу на авторизацию по паролю?
>
> Со стороны клиента не видно, какая там авторизация по ssh.
> Точно так же, как не видно, какие пользователи есть на сервере.
>
--
Victor Wagner <vi...@wagner.pp.ru>
Stanislav Vlasov
Nov 22, 2022, 12:21:39 AM11/22/22
to
вт, 22 нояб. 2022 г. в 09:35, Victor Wagner <vi...@wagner.pp.ru>:
Непосредственно перед приглашением ввести пароль после неудачных
попыток авторизоваться ключом:
debug1: Next authentication method: password
После ввода пароля:
debug1: Authentications that can continue: publickey,password
Доступ руту с паролем запрещён (PermitRootLogin without-password), но
это не видно со стороны клиента.
Точно такое же поведение - при попытке зайти несуществующим пользователем.
Вот именно под этим я и понимаю "не определить". То есть для
конкретного юзера, а не общесистемно.
Полностью перекрывать доступ по паролю представляется несколько
чрезмерным - исключить возможность утери устройства с ключом без
доступа к бекапу не могу.
--
Stanislav
> > > интересно: это что, так сложно написать бот, который понимает, что
> > > у пользователя на хосте авторизация по ключу и исключить
> > > ip/username из своей базы по перебору паролей? Или ботоводы
> > > надеются, что через пару минут я внезапно сменю авторизацию по
> > > ключу на авторизацию по паролю?
> >
> > Со стороны клиента не видно, какая там авторизация по ssh.
> > Точно так же, как не видно, какие пользователи есть на сервере.
> >
>
> запустите ssh -v и увидите что клиенту видно, что нет.
Запустил.
> > > у пользователя на хосте авторизация по ключу и исключить
> > > ip/username из своей базы по перебору паролей? Или ботоводы
> > > надеются, что через пару минут я внезапно сменю авторизацию по
> > > ключу на авторизацию по паролю?
> >
> > Со стороны клиента не видно, какая там авторизация по ssh.
> > Точно так же, как не видно, какие пользователи есть на сервере.
> >
>
> запустите ssh -v и увидите что клиенту видно, что нет.
Непосредственно перед приглашением ввести пароль после неудачных
попыток авторизоваться ключом:
debug1: Next authentication method: password
После ввода пароля:
debug1: Authentications that can continue: publickey,password
Доступ руту с паролем запрещён (PermitRootLogin without-password), но
это не видно со стороны клиента.
Точно такое же поведение - при попытке зайти несуществующим пользователем.
Вот именно под этим я и понимаю "не определить". То есть для
конкретного юзера, а не общесистемно.
Полностью перекрывать доступ по паролю представляется несколько
чрезмерным - исключить возможность утери устройства с ключом без
доступа к бекапу не могу.
--
Stanislav
0 new messages