Защита от брутфорса ssh

knock? и вообще сделай так чтоб не сбрутили

Ёлы-палы...

http://g.zeos.in/?q=iptables ssh вторая ссылка, третья ссылка, в конце концов Nmap 5.0 (комментарий)

fail2ban не получится использовать ?

Почему? Очень даже получится

с помощью iptables проброшен 22 порт на гостевую машину
В логах при не правильном пароле отображается ip хостовой машины

Интересно ты пробросил, iptables-save в студию!

_.
_.
_.
_?
_?
_.

Вот скажи, зачем так жить?

Запретить вход по паролям и юзать ключи. Ожидаемое время перебора чуть больше времени существования человечества при 1000 попытках в секунду. Перевешивать и банить не обязательно. Можешь снизить детализацию логов.

А ещё fail2ban — прекрасный способ организовать DoS самому себе. Атакующему достаточно знать твой IP-адрес.

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

смена дефолтного порта - простое и эффективное средство от ботов.

ключи сгенерь и дело в шляпе
кстати в самом sshd_config есть количество попыток и глобальная настройка по количеству логинов/попыток за день, вроде

смена дефолтного порта - простое и эффективное средство от ботов.

# cat messages.0 | grep "dropbear.*bad password attempt for 'root'" | wc -l
117
# cat messages* | grep "nonexistent user from" | wc -l         
26

Ладно.

А на какой порт повесил ssh?

sshguard

Если перевешивать, то на порт >20000

2200:

# grep "bad password attempt" /var/log/auth.log.1|wc -l
0
# grep "nonexistent" /var/log/auth.log.1|wc -l
0

22:

# grep "bad password attempt" /var/log/auth.log.1|wc -l
12567
# grep "nonexistent" /var/log/auth.log.1|wc -l
3680

Ладно

man zmap. IPv4 можно просканировать за 45 минут. Все IPv4.

security through obscurity перевешиванием порта не работает и даёт чувство ложной защищённости.

Брутфорс SSH через интернет — это не проблема, а явление. Проблема — плохие пароли, позволяющие получить доступ к системе. Играть в прятки с брутфорсерами — не решение. Банить брутфорсеров — опять же не решение. Решение — хорошие пароли у всех пользователей либо (гораздо проще на практике) авторизация по ключам.

Дополнительная проблема — разрастание логов, но с ней можно и нужно бороться отдельно (если она вообще возникает).

zgrep -c 'Failed' /var/log/authlog*
/var/log/authlog:1788
/var/log/authlog.0.gz:1451
/var/log/authlog.1.gz:1263
/var/log/authlog.2.gz:1190
/var/log/authlog.3.gz:1655
/var/log/authlog.4.gz:1147
/var/log/authlog.5.gz:1293
/var/log/authlog.6.gz:1808

И кого это чешит? o_O Меня точно нет. Ну пусть себе боты бъются головой об стенку. И что?

Может ещё и индейца перевесить? Не дай макоронный монстр шальной бот 404 сгенерирует?

А на какой порт повесил ssh?

На 31173.

sudo zgrep -c 'Failed' /var/log/auth*
/var/log/auth.log:1
/var/log/auth.log.1:0
/var/log/auth.log.2.gz:0
/var/log/auth.log.3.gz:0
/var/log/auth.log.4.gz:0

Статик ип, домен второго уровня, ssh не на дефолтном порту.

И то: Apr 14 18:40:57 debian sudo: pam_unix(sudo:auth): conversation failed

Два чаю, только вот 45 минут — это всего лишь один TCP порт, к тому же требуется 1 Gbps аплинк.

Сменить порт/запретить руту коннектится/нормальный пароль.

тыц (lmgtfy.com)

А почему бы не заюзать ключи? Это и удобнее, пароль вводить не надо. (Если, конечно, на сам ключ не стоит пасс-фраза, но её один раз ввёл, и дальше она до разлогина запомниалсь).

даёт чувство ложной защищённости

мне не дает, я прекрасно понимаю, что остаюсь уязвим для таргетированной атаки

Решение — хорошие пароли у всех пользователей либо (гораздо проще на практике) авторизация по ключам.

расскажи, как это сделать на шаредном хостинге

Дополнительная проблема — разрастание логов

не просто разрастание. Когда тебя брутят со скоростью ~1000 паролей/мин, это уже неплохо загружает IO.