LINUX.ORG.RU

Как можно защитится от Ddos с помощью перебора пароля через ssh?

Значит так, находишь айпи дудосера и начинаешь перебирать ему пароли пока он не перестанет.

anonymous
()
Ответ на: комментарий от anonymous

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

bl ★★★
()

Надо быть на шаг впереди взломщика, тут без вариантов
Поэтому поставь пароль, который он уже проверил

zolden ★★★★★
()

Порт поменяй. Ну и пароль отключи.

emulek
()

Зачем ssh на улице то..?

DALDON ★★★★★
()
Ответ на: комментарий от AS

Да ничем. Тут серьёзно только один человек ответил на самом то деле, это был: zolden.

DALDON ★★★★★
()
Ответ на: комментарий от anonymous

китаеботы

закрывать их нафиг фаерволом. в интернетах куча готовых блок-листов с готовыми правилами iptables/ipfw.

Komintern ★★★★★
()

Ddos ... перебора пароля ... ssh

У тебя каша в голове.

Забить и не обращать внимания.

beastie ★★★★★
()

Очень просто, включить вход без пароля.

Пока боты будет перебирать пароли, ты спокойно будешь логиниться без пароля. Шах и мат для ботов!

invokercd ★★★★
()

Есть еще вариант через iptables сделать ловушку. Если чел в течении 30 секунд инициализирует больше чем 10 коннектов в 22 порт - то банить навечно. Гугулить по ключевым словам: ssh iptables bruteforce

iron ★★★★★
()
Ответ на: комментарий от AS

Очевидно же - потеряется всякий смысл подбора пароля. А подбирать ключи RSA длиной от 4096 бит - задача на несколько лет, тем более что настраивается SSH под такие задачи за пару минут. Я в своё время даже статейку накатал. Там, конечно, ни слова про то, что ключ сервера надо удлиннить, но т.к. я об этом только что сказал, загуглить и за 5 минут сделать это не составит труда.

Насчёт fail2ban была на хабре статья от одного отечественного участника проекта. Проблема в том, что брутфорсеры тоже не лыком шиты и знают, какие дефолтные настройки в fail2ban на таймауты для одного IP. Посему при взломе с помощью ботнета время между запросами увеличивается таким образом, чтобы не попасть на кукан к fail2ban. Разработчик уже добавил новый код, который позволит с этим бороться, но пока нет точной информации, вошли изменения в основную ветку, или нет.

Я не призываю отказываться от fail2ban полностью, тем не менее, одним только им не обойтись, а не использовать вход по ключам в 2015 году считаю моветоном.

dunmaksim
()
Ответ на: комментарий от dunmaksim

Очевидно же - потеряется всякий смысл подбора пароля.

А бот что, это поймёт ? У ТС беда не в факте подбора, а в том, что десятка два одновременно подбирающих ставят раком хост.

AS ★★★★★
()

А как смотреть какие пароли перебирают? В auth.log такого нет.

Deleted
()

ddos и перебор пароля както не вяжется, но вот стандартные схемы от попыток входа в твой ссх:
1) сменить стандартный порт - этим ты урежешь 99,9% попыток входа
2) fail2ban - постоянно обновляемая утилита, злосная школота тебя тревожит не будет
3) отключить авторизацию рута
4) используй директиву AllowUsers

CHIPOK ★★★
()
Ответ на: комментарий от CHIPOK

ddos и перебор пароля както не вяжется

Очень вяжется. ddos - следствие этого перебора. То есть, ddos, в данном случае, не цель, но такой вот эффект присутствует, когда количество одновременно перебирающих становится заметно больше одного. От этого, на раз, спасает iptables recent.

AS ★★★★★
()
Ответ на: комментарий от AS

одновременно перебирающих становится заметно больше одного

отчасти согласен, но думаю самая голимая машинка выдержит пару тыщ таких переборов. Как по мне то ddos атака по протоколу ssh крайне маловероятна.

CHIPOK ★★★
()

Не использовать ssh. Серьезно.

int13h ★★★★★
()
Ответ на: комментарий от CHIPOK

но думаю самая голимая машинка выдержит пару тыщ таких переборов.

Нет, проверял лично. Celeron CPU 3.20GHz уже десяток напрягает заметно. На 2 x E5320 непорядок становится заметен ближе к сотне (учитывая, что ломятся в контейнеры).

AS ★★★★★
()
Ответ на: комментарий от AS

А бот что, это поймёт ? У ТС беда не в факте подбора, а в том, что десятка два одновременно подбирающих ставят раком хост.

Да. SSH его будет банально посылать в лес даже ещё не получив пароль.

anonymous
()
Ответ на: комментарий от anonymous

Да. SSH его будет банально посылать в лес даже ещё не получив пароль.

Логина уже достаточно. Самое страшное с точки зрения нагрузки, форк процесса, происходит в момент коннекта. До логинов и ключей.

AS ★★★★★
()
Ответ на: комментарий от AS

Логина уже достаточно. Самое страшное с точки зрения нагрузки, форк процесса, происходит в момент коннекта. До логинов и ключей.

Боты отвалят, не будет логинов.

anonymous
()

poweroff, halt, shutdown, init0 - обеспечат гарантированную защиту

axelroot
()

конечно, используй нестандартный порт

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.