Re: nftables vs fail2ban
вт, 22 нояб. 2022 г. в 09:35, Victor Wagner : > > > интересно: это что, так сложно написать бот, который понимает, что > > > у пользователя на хосте авторизация по ключу и исключить > > > ip/username из своей базы по перебору паролей? Или ботоводы > > > надеются, что через пару минут я внезапно сменю авторизацию по > > > ключу на авторизацию по паролю? > > > > Со стороны клиента не видно, какая там авторизация по ssh. > > Точно так же, как не видно, какие пользователи есть на сервере. > > > > запустите ssh -v и увидите что клиенту видно, что нет. Запустил. Непосредственно перед приглашением ввести пароль после неудачных попыток авторизоваться ключом: debug1: Next authentication method: password После ввода пароля: debug1: Authentications that can continue: publickey,password Доступ руту с паролем запрещён (PermitRootLogin without-password), но это не видно со стороны клиента. Точно такое же поведение - при попытке зайти несуществующим пользователем. Вот именно под этим я и понимаю "не определить". То есть для конкретного юзера, а не общесистемно. Полностью перекрывать доступ по паролю представляется несколько чрезмерным - исключить возможность утери устройства с ключом без доступа к бекапу не могу. -- Stanislav
Re: nftables vs fail2ban
В Tue, 22 Nov 2022 07:48:29 +0500 Stanislav Vlasov пишет: > > интересно: это что, так сложно написать бот, который понимает, что > > у пользователя на хосте авторизация по ключу и исключить > > ip/username из своей базы по перебору паролей? Или ботоводы > > надеются, что через пару минут я внезапно сменю авторизацию по > > ключу на авторизацию по паролю? > > Со стороны клиента не видно, какая там авторизация по ssh. > Точно так же, как не видно, какие пользователи есть на сервере. > запустите ssh -v и увидите что клиенту видно, что нет. -- Victor Wagner
Re: nftables vs fail2ban
22.11.2022, li...@mail.ru написал(а): > 21.11.2022 23:48, Victor Wagner пишет: > >> Самая лучшая защита от брутфораса паролей это PasswordAuthentication no >> в /etc/sshd_config. Пользуйтесь только авторизацией по ключам и все >> будет хорошо. > > По моему опыту это лишь спасает от результативного брутфорса, но не от > постоянных попыток подобрать пароль ботами. Мне всегда было интересно: > это что, так сложно написать бот, который понимает, что у пользователя > на хосте авторизация по ключу и исключить ip/username из своей базы по > перебору паролей? Или ботоводы надеются, что через пару минут я внезапно > сменю авторизацию по ключу на авторизацию по паролю? Со стороны клиента не видно, какая там авторизация по ssh. Точно так же, как не видно, какие пользователи есть на сервере. -- Stanislav
Re: nftables vs fail2ban
21.11.2022 23:48, Victor Wagner пишет: Самая лучшая защита от брутфораса паролей это PasswordAuthentication no в /etc/sshd_config. Пользуйтесь только авторизацией по ключам и все будет хорошо. По моему опыту это лишь спасает от результативного брутфорса, но не от постоянных попыток подобрать пароль ботами. Мне всегда было интересно: это что, так сложно написать бот, который понимает, что у пользователя на хосте авторизация по ключу и исключить ip/username из своей базы по перебору паролей? Или ботоводы надеются, что через пару минут я внезапно сменю авторизацию по ключу на авторизацию по паролю?
Re: nftables vs fail2ban
В Mon, 21 Nov 2022 18:36:43 +0400 Maksim Dmitrichenko пишет: > Всем хай! > > Решил я тут значит накрутить на VPS защиту от брутфорса по ssh. Давно Самая лучшая защита от брутфораса паролей это PasswordAuthentication no в /etc/sshd_config. Пользуйтесь только авторизацией по ключам и все будет хорошо. -- Victor Wagner
Re: nftables vs fail2ban
Maksim Dmitrichenko wrote: > [-- text/plain, encoding base64, charset: UTF-8, 25 lines --] > пн, 21 нояб. 2022 г. в 18:53, Stanislav Vlasov : > > Блокировка через nftables отлично заблокирует вполне легитимный > > параллельный запуск чего-нибудь из скриптов. Это больше ограничение по > > флуду и неприменимо, если есть вариант, что потребуется запускать > > что-то типа for i in ...; do ssh $host "$command $i"; done > > > Вроде бы не мой случай. Но это какое-то зло в любом случае, если там может > быть один хост в нескольких командах. Он резко может стать твоим, если ты быстро зашел-вышел на хост несколько раз. Но для этого, можно свои сеточки отдельно пускать, мимо резалки. Только этот метод другую проблему не решает - медленный подбор паролей, когда в рамках одного соединения (ещё и с задержкой) подбираются пароли до лимита. А следующее соединение с этого адреса будет через 5 минут - ботнет большой, адресов много. > > fail2ban же проанализирует логи и забанит только тех, кто пытается > > подобрать пароль. > То есть fail2ban занимается парсингом логов и зависит от того, чтобы тот > или иной сервис не дай бог не изменил формат логов? Какое-то весьма себе sshguard занимается тем-же. Да и любой блокировщие будет заниматься парсингом логов. > костыльное решение, которое ко всему прочему обязывает вести локальный, а > не remote, лог. ты что, это fail2ban... там модулей на любой чих понаписанно. Можно поставить на сервер с логами, а рулить фарволом в совершенно другом месте. Можно поставить mysql и сделать через это "централизованную базу" блокировок. А так, для своих задач демон пишется на perl за 2 часа с перерывами на кофе.
Re: nftables vs fail2ban
пн, 21 нояб. 2022 г. в 18:53, Stanislav Vlasov : > Блокировка через nftables отлично заблокирует вполне легитимный > параллельный запуск чего-нибудь из скриптов. Это больше ограничение по > флуду и неприменимо, если есть вариант, что потребуется запускать > что-то типа for i in ...; do ssh $host "$command $i"; done > Вроде бы не мой случай. Но это какое-то зло в любом случае, если там может быть один хост в нескольких командах. > > fail2ban же проанализирует логи и забанит только тех, кто пытается > подобрать пароль. > То есть fail2ban занимается парсингом логов и зависит от того, чтобы тот или иной сервис не дай бог не изменил формат логов? Какое-то весьма себе костыльное решение, которое ко всему прочему обязывает вести локальный, а не remote, лог. -- With best regards Maksim Dmitrichenko
Re: nftables vs fail2ban
21.11.2022, Maksim Dmitrichenko написал(а): > Беглый гугл выдает, что для реализации блокировки по перебору нужно ставить > fail2ban [1] или sshguard [2]. Даже если nftables. > > При этом красношапочный мануал говорит [3] о том, что nftables и сам готов > справится с этой задачей без дополнительных свистоперделок. > > В связи с чем вопрос: предлагают ли fail2ban или sshguard какую-то важную > дополнительную функциональность, или использование nftables вполне способно > самостоятельно решить эту задачу прекрасно и надежно? Блокировка через nftables отлично заблокирует вполне легитимный параллельный запуск чего-нибудь из скриптов. Это больше ограничение по флуду и неприменимо, если есть вариант, что потребуется запускать что-то типа for i in ...; do ssh $host "$command $i"; done fail2ban же проанализирует логи и забанит только тех, кто пытается подобрать пароль. -- Stanislav
nftables vs fail2ban
Всем хай! Решил я тут значит накрутить на 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 [3] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/sec-using_nftables_to_limit_the_amount_of_connections#sec-Blocking_IP_addresses_that_attempt_more_than_ten -- With best regards Maksim Dmitrichenko
