Достаточно перейти на авторизацию по ключам и поставить Fail2ban и это уже будет гарантией безопасности. К сожалению, мы живем в реальном и мире, который постоянно меняется и предложенные меры безопасности уже не являются всегда достаточными.
Давайте разберем — авторизация по ключам остались два относительно безопасных ssh-ключа это RSA-4096 и ED25519, DSA ключи уже не включаются в последние версии OpenSSH. При этом нужно учитывать наличие в Интернете некоторых сомнений по поводу надежности ED25519, гугл в помощь, если кому интересно.
Кроме ключей рекомендована, достаточно длинная кодовая фраза для Ваших ключей из случайных символов в разном регистре и цифр, как минимум.
Brute force attacks — давайте кратко посмотрим, что происходят, если Ваш хост атакуется целенаправленно.
1 этап — сбор информации о хосте, в том числе и открытых портах
Этот сбор информации далеко не всегда отражается в Ваших логах, например, сканирование портов может идти без установления соединения. Fail2ban здесь бесполезен, он работает только по записям в логах. На первом этапе могут также отслеживаться установленные системы защиты. Например, определяется количество попыток авторизации до блокировки, время блокировки.
2 этап — попытки получить доступ к системе через взлом SSH
Для взлома используются ботнеты с тысячами адресов и сканирование в простом случае идет, чтобы обходить установки по умолчанию Fail2ban с сотен и тысяч адресов, при серьезном сканировании с учетом настроек системы защиты жертвы. Fail2Ban здесь также бесполезен, особенно если SSH находится на 22 порту и настройки Fail2Ban оставлены по дефолту.
У меня на внешнем периметре одного из серверов все порты закрыты, но за пару дней набирается до нескольких тысяч хостов, которые пытаются установить соединение на стандартные порты. Причем сканирование идет с учетом возможных защит, пакеты с одного адреса идут, как правило, с интервалом в несколько минут.
Конечно, Fail2ban может быть эффективен, для защиты некоторых других сервисов при нестандартных настройках под Ваши хосты и сервисы.
Почему-то всегда, кажется, что второй этап самый опасный, на самом деле на первом этапе ищутся возможные уязвимости на хосте, они могут быть гораздо опаснее, простого Brute force SSH. Зачем ломать SSH, когда рядом находится открытая дверь с уязвимостью.
Что касается смены стандартного порта, есть свежий обзор BestPractic по обеспечению безопасности SSH, там смена стандартного порта стоит 8 пунктом, авторизация по ключам стоит первым пунктом и установка Fail2ban или аналогов 10 пункт. Top 20 OpenSSH Server Best Security Practices.
Перевод порта SSH на нестандартный позволяет использовать стандартные порты как ловушку для отслеживания попыток сканирования, и блокировать полученные IP адреса на длительное время и по всем портам, это 11 пункт, в статье BestPractic. Естественно необходимо указывать белые адреса чтобы не получить случайную блокировку это 7 и 8 пункты в статье BestPractic.
Таким образом мы повышаем стоимость сбора информации о нашей системе. Информация о открытых портах будет стоить несколько тысяч IP адресов или месяцы на сканирование нашей системы. Если для потенциального взломщика неизвестен мой порт SSH, даже при появлении уязвимости он не сможет ей воспользоваться.
Комментарии (95)
geher
10.11.2018 23:49+3Кстати, идея кажется хорошей. ssh повесить на другой порт, а на стандартном порту повесить ловушку-имитатор. И пусть ломают.
lioncub
11.11.2018 08:19+3Ловушка TARPIT на 22. А другой порт SSH открывается только после port knoking. Вход по ключам, если кто-то отправил учётные данные, то бан. Что бы ещё придумать…
gag_fenix
12.11.2018 02:44Чтобы ещё придумать…
Нужно чтобы это был вход не на настоящий сервер, а просто на шлюз без bash_history, с которого уже можно соединиться с настоящим в приватной сети… по паролю. Пароль должен включать управляющие ASCII-коды, символы нотной азбуки и мертвых языков
Sadler
11.11.2018 14:02Можно просто зарезать фаерволлом доступ ко всему, кроме нескольких публичных сервисов, а открывать админский доступ только с конкретного IP после аутентификации через https. Это и отсеивает всех желающих халявного ssh, и не приводит к потере доступа откуда угодно даже в случае нескольких ошибок при вводе пароля.
andvgal
10.11.2018 23:53Откройте для себя "Single Packet Authorization" как первый барьер, к примеру описан тут.
Открытый SSH — это безусловное зло. При первом же DoS вам не дадут зайти на сервер.
FSA
11.11.2018 02:21Так и от целевой атаки на сервер защититься сложнее, чем от простого сканирования в поисках уязвимых хостов. DoS та же целевая атака.
andvgal
11.11.2018 12:33+1Поставьте сервер в какой-нибудь крупный DC, который не сильно печётся о безопасности клиентов. Такие сканеры сразу забьют максимальное количество соединений по умолчанию в SSH даже без целевой атаки.
BugM
11.11.2018 00:28+1За пароли из случайных символов в разных регистрах пора уже помидорами кидаться начинать. Пароль это любая фраза лишенная смысла для незнакомого с этой фразой.
«40 тысяч обезьян в… сунули банан» Классика!
Cмена порта это мертвому припарка. Security through obscurity в чистом виде.
Авторизации по ключам с запретом всего остального достаточно для 99.999% серверов. Актуальный бекап kdbx со всеми ключами в облаке спасет от седых волос при смерти диска.AlexTest
11.11.2018 07:41А еще есть модуль hashlimit для iptables — прекрасно защищает SSH от брутфорса на любом порту!
AllexIn
11.11.2018 09:37+1Я вам открою страшную тайну(только никому не говорите!):
Пароль или ключ — это тоже «Security through obscurity в чистом виде.»
Вот эта вот мантра «Security through obscurity — это плохо потому что плохо», идиотская, потому что любая мантра идиотская без понимания сути.
Security through obscurity — это не плохо и не хорошо. Вопрос всегда в том, насколько сложно получить сакральное знание и насколько сложно поставить воглаву угла еще более сакральное(ну и насколько это оправданно).gecube
11.11.2018 10:49+1Security through obscurity — это скорее про детали реализации.
А пароль/ключ/токен — это скорее о физическом владении чем-то для входа.
bromium
11.11.2018 11:32+3Неправильно, security through obscurity — это когда вместо применения ключей для доступа просто меняют стандартный порт.
Поэтому, если злоумышленник узнает номер порта, что несложно, то он получает доступ к серверу
А вот защита ключами, даже если злоумышленнику извстен порт и протокол, предотвратит доступ к серверу
Очень важно это понимать и не путать.
Закрывать дверь на ключ и класть его под коврик в надежде, что никто не узнает — вот пример бытовой security through obscurity
AllexIn
11.11.2018 12:53+1Неправильно
что несложно
А я что написал?
Вопрос всегда в том, насколько сложно получить сакральное знание и насколько сложно поставить воглаву угла еще более сакральное
P.S.
Про не сложность определения порта — отдельный ЛОЛ. Учитывая, что:
1) Порт не отзывается никак.
2) Любая попытка сканирования блочит IP на первом же обращении к закрытому порту.iig
11.11.2018 22:47Я где-то читал про такой сценарий: доступ к супер-защищенному серверу был получен через уязвимость в IRC клиенте. Получили доступ к его домашнему компу, через туннель к рабочему компу получили доступ к серверу.
Jouretz
12.11.2018 20:25Не путайте тёплое с мягким.
Security through obscurity — это расчёт на то что атакующий идиот и не знаком с методами защиты.
«угадай число от 1 до 65535 чтоб зайти на сервер»
либо
«подбери комбинацию из 20-50 символов чтоб зайти на сервер»
Какая-то минимальная разница таки есть в задачах.
И как вам уже говорили смену порта по степени усиления защиты можно приравнять к добавлению 2-3 символов в пароль.
А Security through obscurity в 2018 это однозначно плохо.
Было приемлимо при цезаре, когда многие реально не догадывались поменять символ на рядом стоящий для расшифровки текста.
Но сейчас надежда на то что нападающий идиот только вредит защите.
SirEdvin
11.11.2018 01:44Вы так и не поняли, сюда по всему, почему говорят, что смена порта не имеет смысла. Она защищает только от тупых скриптов, которые даже не пытаются найти ssh у вас на сервере, а просто бьют по 22 порту.
Найти ssh не так сложно, правда. Разве что если еще запускать несколько ssh в контейнерах и один настоящий, но можно тогда и самому запутаться.forcam
11.11.2018 05:35Перенос порта это не так уж и плохо
Статистика обращения по портам за 4ро суток:
19, c:17
21, c:19
23, c:1520
25, c:29
53, c:33
69, c:13
80, c:372
81, c:153
88, c:11
111, c:13
123, c:34
139, c:24
слева порт, справа количество попыток коннекта с отдельного IP, т.е. за 4ро суток с разных 1520 IP хотя бы 1 раз попытались стукнуться на 23 порт (все повторения убраны, т.е. если даже IP стукнулся 10 раз, в данном счетчике это будет единица)
22ой видимо зарезан на стороне провайдера, думаю там совсем была бы беда) но на нем 0 обращений). Остальные порты привел как пример и только те на которые больше 10 обращений ну и до 140го порта, полную выборку по портам можно глянуть тут: pastebin.com/BtMyfgcS (детальная статистика с обращанеием хотя бы 1 раз)
pastebin.com/91NYnEw8 (статистика где убраны обращения менее 4х раз, дабы убрать часть сканов)
(это за 4ро суток)
Московский провайдер.xenon
11.11.2018 22:57Ну стукаются, и чего? Стукаются же не те, кто готов посвятить месяц-два, с 0-day эксплойтами чтобы взломать именно вас. Стукаются те, кто хочет попробовать пароль password или 123456 на рута (вдруг да сработает! срабатывает же в 1 случае из тысячи).
Если у вас хоть как-то защищен сервер хоть чуть-чуть — они вам не страшны. (а если даже так не защищен — то вас наверняка УЖЕ взломали :-) ). А уж те кто готов серьезнее ломать — они умеют nmap запускать. Номер порта — это легко проверяемый секрет из 16 бит.
Все равно что использовать крем «Дэта» от наемного убийцы. От комаров же помогает! :-)
pansa
11.11.2018 02:20О, вечная тема. И слишком многогранная, как почти любая тема по безопасности.
Конечно, мало смысла делать тотальный hardering ssh, когда, к примеру, на хосте крутится вордпресс с плагинами из нипойми откуда (правда, опять же, если WP хорошо упрятан в контейнер, то уже не так страшно).
Лично я тоже крайне скептичен к переносу на другой порт. Хоть какой-то смысл это имеет только при одновременной настройке бана за попытки скана портов, иначе… ну ёлки, просканить порты это дело пары секунд.
Вообще, давно думаю, что концептуально все подобные атаки живы только засчет одной вещи — они дешевые (по ресурсам) для стороны атакующего. Вот если бы сделать так, что для прохождения аутентификации клиентская сторона должна выполнить набор относительно тяжелых вычислительных операций — эти атаки бы ушли сами собой. То же самое можно было бы применить к спаму. Как только такие операции будут «убивать» машины по CPU (а лучше еще и по памяти) — даже большие ботнеты не смогут создать проблем.
Да, и совсем забыл! Почему-то в качестве защиты не упомянута банальная 2FA.
TOTP с googleauth настраивается элементарно, и проломить ботнетом её нереально в принципе.
tuxi
11.11.2018 02:27Дык не надо мешать спамерам спамить в песочницу. Мы, после того как создали видимость для спамботов и ребят из «Индии», что их попытки удачны, теперь пасем вполне компактное стадо этих спам-товарищией. Их число не растет, они счастливы. Мы тоже :) Живем без капчи, клиенты счастливы.
pansa
11.11.2018 03:39Вы именно про почту сейчас? А как вы их загнали в песочницу, а обычных юзеров оставили, расскажите? =)
В целом, ханипоты да ловушки — тоже хорошая вещь, но они уже требуют некоторой осторожности и подготовки.tuxi
11.11.2018 15:55Нет, не про почту. Я говорил про всякие формы фидбеков/отзывов/запросов в вебе и тому подобное. Рассказать можно, но это не готовые рецепты. Это некая система, строилась годами (наш продуктовый веб-проект с 2004 года живет). Это скорей некий набор концепций (например анализ поведения на ресурсе), а уж как их реализовывать, это дело десятое. Но факт такой, что проникновение массового спама в CRM мы отсекли практически на корню.
psycho-coder
11.11.2018 16:10Хотелось бы почитать про чужой опыт в этой области. Не напишете статью, если время будет?
CaptainFlint
11.11.2018 12:50+4Вот если бы сделать так, что для прохождения аутентификации клиентская сторона должна выполнить набор относительно тяжелых вычислительных операций…
При коннекте посылать атакующему произведение двух больших простых чисел и не пускать, пока он не ответит одним из сомножителей. Oh, wait…pansa
11.11.2018 18:15-1Главное, аккуратнее с выбором числа =)
Нет, что-нибудь более полезное. Те же задачи, которые решаются добровольным предоставлением своих вычислительных ресурсов. Двух зайцев бы убили.
tuxi
11.11.2018 02:21На середине статьи, мне в голову пришла бредовая мысль «а если на 22-м порту сделать проброс на другую машину, „жертву“, вот пусть ее ломают. А она нам статистику будет присылать. Потом дочитал до конца и понял, что не такая уж и бредовая мысль :)
JerleShannara
11.11.2018 04:57Я так проброс сделал на SunFire (non x86, UltraSPARC) с установленной мега-кастрированной Solaris 10 и ограничением канала и портов от этой машины, было забавно читать логи и попытки ксакепов там что-то запустить/собрать.
kalininmr
11.11.2018 03:37а чем плохо отключение ssh пока не стукнешься в специальный урл?
bugdesigner
11.11.2018 06:42Ничем не плохо — только нужно не просто стукнуться, а авторизоваться, тогда получится такая себе 2FA. Port knocking тоже хорошо помогает. Я себе настроил доступ с некоторых своих ip + knocking. Чтоб порт открылся нужно пингануть пакетиками определённого размера не менее n раз. После чего нужно залогиниться в течении 1 минуты.
Zettabyte
11.11.2018 03:42Я как-то об этом уже писал, но повторюсь:
Есть ещё один не самый очевидный (и не для всех актуальный) момент — мне как-то не то за две, не то за три недели набрутфорсили паролей на 9 ГБ трафика. Прямо такой аккуратный длинный прямоугольник на графике bandwidth.
У многих безлимит, но на маленьких VPS нередко бывают ограничения, и когда вот так впустую съели девять ГБ из ста, мне это пришлось не по нраву. Остатка всё равно хватило с лихвой, но после этого порт поменял.
Кто-то скажет, что этот трафик всё равно бы пришёл, но я считаю, что намного вероятнее нет, чем да. На мой взгляд, перебор продолжался из-за того, что от сервера шли ответы.
Думаю, что также с подобными вещами можно бороться, давая ответы DROP вместо REJECT, но я не настолько хорош в настройке удалённых серверов, чтобы сразу сказать можно ли это сделать и как.
codecity
11.11.2018 06:05Сейчас у всех уважающих себя хостеров есть облачный фаервол. Уже ничего мудрить не нужно — просто запрещаете доступ по SSH для всех, кроме вашего IP.
bugdesigner
11.11.2018 06:34+1Вариант не подходит для тех, у кого нет постоянного ip. Например человек не сидит на месте, а много путешествует, например. К тому же есть ещё ватианты, когда достаточно большое число людей сидят за NAT. Поэтому "ваш ip" — это мало кому подойдёт.
savostin
11.11.2018 20:43Кто много путешествует, особенно по кафешкам сидит, давно уже использует VPN. Вот его ip и считается белым.
gecube
11.11.2018 20:57Кто много путешествует, особенно по кафешкам сидит, давно уже использует VPN. Вот его ip и считается белым.
не понял, каким образом использование VPN соотносится с «белым IP». За IP VPN'а легко так же может оказаться сотня-другая ботов.Meklon
11.11.2018 21:28+1Это маловероятно. И часто у людей свой VPN. На виртуалке или на домашнем роутере.
gecube
11.11.2018 21:45С тем же успехом, можно сразу впниться до сети с конечным узлом. Делать промежуточные хопы смысла нет
bugdesigner
12.11.2018 06:02Банально просто. Вы поехали в Тайланд отдохнуть, а дома у Вас отключили свет/ интернет. Может авария у провайдера — причин может быть много. А Вам срочно нужно поправить что-то на одном из серверов. И Вам прийдётся, вместо отдыха, кому то звонить, нервничать, думать даже о срочной покупке билетов на самолёт. Я просто всё это проходил однажды…
Jouretz
12.11.2018 12:541-3 бакса в месяц обходится vps-ка с поднятым vpn и белым статичным ip. Взять 2 у разных хостеров и нервы на 100% защищены.
gecube
12.11.2018 13:05А потом эта VPSка попадает под бан РКНа… (такое случилось с моими VPS на Scaleway и DO)…
Jouretz
12.11.2018 14:07Ну это проблемы текущего законодательства. О которых все ноют, но молчаливо принимают.
Во вторых поэтому 2 у разных хостеров. Шансы одновременного бана очень малы.
В третьих даже если их забанят проблемой будет только пробиться к своей VPS. Управлять сервером с неё вы всё так же сможете. Ибо каналы на которых висят даже российские хостеры, как показывает практика, блокировкам не подвержены.
bugdesigner
11.11.2018 22:02Что Вы будете делать, если "ляжет" VPN?
Mitch
11.11.2018 22:56На этот случай я обычно держу 2 впн на своих серверах в разных странах и оба эти ip в вайтлисты.
bugdesigner
12.11.2018 05:47-1То есть, вместо простых мероприятий в виде port knocking и смены порта ssh, Вы должны держать 2 vpn сервера в разных странах? Уверен, Вы это только сейчас придумали.
Mitch
12.11.2018 16:35Вообще основная цель 2х своих впн чтобы ходить на финансовые сервисы со своих 2х постоянных ip, чисто ради ssh вы правы наверное это излишество.
Ну и чтоб антифрод не парил мозг на разных сервисах.bugdesigner
12.11.2018 16:54Все способы имеют свои плюсы и минусы. Каждый может выбрать тот вариант, который ему больше всего подходит. Вот так, в комментариях, кто то найдёт для себя ещё один способ, о котором он не знал раньше.
savostin
11.11.2018 23:05Быстро поднять другой, это дело 5 минут и 5 баксов.
bugdesigner
12.11.2018 05:50Да, только вот файрволл ничего не знает о новом ip vpn сервера, будь он хоть за миллион баксов. Похоже на ситуацию с бронированной дверью, когда ключ только один и он утерян.
Lelik13a
11.11.2018 06:53Стандартный порт SSH — лишний трафик и срачь в логах. Смена порта эту проблему прекрастно решает минимальными усилиями.
dormin Автор
11.11.2018 09:52Никто не будет спорить ключи, Fail2ban, двухфакторня авторизация, сложные и длинные пароли все это нужно и прекрасно работает в своем сегменте защиты. Но почему то некоторые забывают, что защищаться нужно с момента сбора информации о Вашей системе. Чем сложнее будет собрать информацию о открытых портах тем сложнее будет организовать атаку. Часто сканирование портов идет на ограниченный набор портов, использовать их как ловушку в iptables, второй пакет с этого же адреса на любой порт в течении 1 часа и блокируем на сутки или больше этот IP адрес. Модулями iptables это реализуется просто. Отслеживание сканирования идет на уровне пакетов, а не лог файлов.
gecube
11.11.2018 10:53Первое. В общем случае, для публичных сервисов это не работает. Там попросту не построить «белый» список, откуда можно ходить.
Второе. fail2ban такое себе решение. Меня он уже один раз из-за недоработки в нем подвёл. К тому же, если кто-то нальет трафика в сервер, то цепочки fail2ban очень сильно снизят скорость работы. Ядро только и будет, что гонять трафик по правилам файрволла. Это ограничивает применение fail2ban pet-проектами.
В третьих — что будете делать, если злоумышленники DDoS нальют в сервис?setevoy4
11.11.2018 10:58Я всё ждал — когда же в посте или комментариях появится упоминание PSAD и иже с ним…
demfloro
11.11.2018 11:49Достаточно сделать аутентификацию по ключам, отключить аутентификацию по паролю и выставить LogLevel ERROR в /etc/ssh/sshd_config, чтобы флуд перебора не шёл в логи. В итоге только для ssh уже не нужно оставлять fail2ban.
titbit
11.11.2018 12:26А не подскажете, бывает динамический port knocking? Просто статический плох тем, что подслушав траффик один раз становится ясно как открывать порт. Под динамическим я имею ввиду ситуацию, когда номера портов в которые надо постучаться зависят от даты, IP и много чего еще и алгоритм известен только владельцу сервера и самому серверу естественно.
Gasaraki
11.11.2018 13:56+2Вы представляете себе уровень подготовки людей, которые могут слушать ваш трафик? Если вы серьезно с такими столкнетесь, то динамическая блокировка будет у вас наименьшей проблемой.
titbit
11.11.2018 14:29Да сейчас все подряд слушают траффик, если могут — то весь. Или даже при подключении по ssh через wi-fi ближайшей кафешки надо оборачиваться в vpn? Вроде ж технически не должно быть очень сложно, вот и подумалось, что решения есть. Нагуглил: cryptknock.sourceforge.net и github.com/ashemery/tariq
psycho-coder
11.11.2018 14:47Скрипт на bash + cron могут решить данную проблему.
Например от дня месяца зависит номер порта по определенному алгоритму, а от дня недели размеры пакетов или еще что-нибудь.
#убирает старые правила и ставит новые, делает iptables-save
0 0 * * * /bin/bash ~/new-rules.sh
Ну и на локальном компе, аналогичный скрипт, который делает пинги.
Vindicar
11.11.2018 13:38+3Честно говоря, не понимаю о чем тут спорить. Атаки с целью взлома (не DoS) можно разделить на две большие категории.
1. «сеть» или атака по площадям: ткнулись на стандартные порты, попробовали стандартные пароли, не получилось, побежали дальше. Неважно, какой хост будет взломан. Главный и единственный критерий — цена атаки в пересчете на один хост.
2. «крючок», или направленная атака: целевая система заранее известна, и нужно подобрать подход именно к ней. Критерии — успешность атаки на заданную систему и её цена.
Теоретически...их можно совместить — построить автоматизированный анализатор уязвимостей, способный более-менее тщательно простучать целевой хост, и натравить его на весь диапазон IPv4. На практике — стоимость создания и время работы (в расчете на один хост) будут высоки, что сделает атаку непрактичной для большинства злоумышленников. Так что такие гипотетические атаки можно отнести ко второй категории.hzs
11.11.2018 15:52Лично я ssh перевешиваю на другой порт, а всех, кто ломится на 22 сразу в баню.
Свой айпишник в белый лист, чтобы случайно себя не кикнуть.
ivlad
11.11.2018 19:04+4Давайте разберем
Я подумал, что да, неплохо бы разобрать некоторые тезисы этой статьи.
авторизация по ключам остались два относительно безопасных ssh-ключа это RSA-4096 и ED25519
На https://www.keylength.com/ есть сравнения рекомендаций относительно выбора длины ключей. Например, NIST в публикации 800-57 части 1 говорит, что ключи RSA длиной 2048 бит являются приемлемыми и примерно квивалентными по стойкости 112 битному симметричному шифрованию (которое тоже считается приемлемым). Стандарт BSI от 2018 года говорит, что до 2022 года RSA с размером ключа до 2048 бит безопасен. Другие стандарты (например, рекомендации NSA IAD) предлагают использовать RSA с длиной ключа 3072 бита. В среднем, консенсус состоит в том, что их применение безопасно до 2030 года. Итого, тезис про RSA4096 неверен.
нужно учитывать наличие в Интернете некоторых сомнений по поводу надежности ED25519
Я внимательно погуглил и не нашёл каких-то особенных беспокойств относительно безопасности конкретно Ed25519, отличающиеся от общих соображений по генерации подписи на ECDSA. Мне кажется, это экстраординарное по силе утверждение требует экстраординарных доказательств, на не предложения погуглить. Итого, тезис про Ed25519 выглядит, как FUD.
Кроме ключей рекомендована, достаточно длинная кодовая фраза для Ваших ключей из случайных символов в разном регистре и цифр, как минимум.
"Кодовая фраза" не участвует в процессе аутентификации, а используется только для генерации локального ключа шифрования. Не важно, есть в ней буквы разного регистра и символы, важно, чтобы пространство ключей было достаточно большим, больше ~100 бит. Итого, рекомендация про ключевую фразу бесполезна в лучшем случае.
давайте кратко посмотрим, что происходят, если Ваш хост атакуется целенаправленно.
Если ваш хост атакуется целенаправленно, перенос ssh на случайный порт просто даёт +16 бит энтропии. 16 бит энтропии — это меньше, чем 3 символа пароля, если тот сгенерирован случайно, log(26+26+10)(216)?2,69.
Для взлома используются ботнеты с тысячами адресов и сканирование в простом случае идет, чтобы обходить установки по умолчанию Fail2ban с сотен и тысяч адресов, при серьезном сканировании с учетом настроек системы защиты жертвы.
Поскольку речь идёт о +16 битах, сканирование с "сотен и тысяч адресов" позволит тривиально найти нестандартный порт в случае целенаправленной атаки, о которой вы говорите. Итого, нестандартный порт не добавляет значимой защиты при целенаправленных атаках.
обзор BestPractic по обеспечению безопасности SSH
Во-первых, Best practice. Не потому, что я граммар-наци, а потому, что глаз царапает. Во-вторых, эти рекомендации составлены непонятно кем и непонятно с какой целью. Такая аппеляция к случайной статье в интернете вообще смысла не имеет.
Резюмируя, а активе смены порта на нестандартный:
- защита, соответствующая примерно +3 символам в пароле;
- меньше логов от нецелевых сканирований интернета;
В пассиве:
- увеличенная административная нагрузка, если вы администрируете больше 5 хостов (надо где-то хранить знание про нестандартный порт, например, поддерживать ssh_config), особенно для больших команд;
- ложная иллюзия безопасности;
- необходимость гармонизации с другими элементами конфигурации (например, с файрволом), не обязательно находящимися под управлением тех же людей (см. снова первый пунк в пассиве) или той же системы управления конфигурациями (например, речь о сетевом файрволе, а не о iptables);
Рекомендация: выключить парольную аутентификацию, использовать только аутентификацию по ключам, настроить ротацию логов. Если очень хочется — использовать схемы с SPA (но надо тщательно взвесить достоинства и недостатки).
gecube
11.11.2018 19:21+1Очень грамотный ответ!
Дополнительно хочу добавить, что концептуально при использовании ssh-agent (что является достаточно популярным решением) парольная защита ключей ssh абсолютно бесполезна. Разбор этого производился неоднократно. Например, rabexc.org/posts/pitfalls-of-ssh-agents
Тем более, что есть куча софта, которое не умеет работать с зашифрованными ssh ключами (ansible, salt etc.).
Отдельный вопрос — это именно случайность при генерации ключевых пар, но я предполагаю, что в современных дистрибутивах даже с настройками по умолчанию все должно быть хорошо.
kt97679
11.11.2018 19:59Я использую sslh на порту 443, за которым прячется ssh и nginx с пустым индексом и живым сертификатом от let's encrypt. Это, безусловно, тоже security by obscurity, но в логах удивительно чисто. Видимо такие комбинации мало кто пытается ломать плюс я лично никому не интересен.
BugM
11.11.2018 20:54А вам не пофиг что там в логах? Ну хочет кто сканить пусть сканит. При сканировании всего Интернета нагрузка на вас смешная выходит. При целевом ломании именно вас с такими мелочами быстро разберутся. При ДДОС что именно ддосить найдут. И смысл прятать ssh?
В плюсах меньше записей в логах. Ротацию вы ведь умеете настраивать? Значит это сомнительный плюс.
В минусах более сложная схема про которую надо помнить, надо администрировать и надо документировать.
barbos6
11.11.2018 21:32Однозначно нестандартный порт, как выше писалось — TARPIT, и, если позволяет бизнес-концепция, DROP пакистанов, гондурасов, кетаев и прочих нежелательных через iptables/ipset
Scf
11.11.2018 22:27Выше писали, что смена порта ssh неудобна для больших организаций, т.к. сложно администрировать. Так вот, в приличных организациях ssh вообще не должен быть доступен из интернета — только через сетевой интерфейс локальной сети и впн.
ivlad
12.11.2018 05:42Так вот, в приличных организациях ssh вообще не должен быть доступен из интернета — только через сетевой интерфейс локальной сети и впн.
Rant: очевидно, Google — неприличная организация. :) Я думаю, вам полезно будет почитать их статьи из цикла BeyondCorp, много интересного для себя откроете.
Если серьезно, то во-первых, большие организации давно осознали, что периметра не существует, а во-вторых с точки зрения качества аутентификации и криптографической защиты ssh принципиально не отличается, скажем, от OpenVPN.
Jouretz
12.11.2018 14:43+1Кто-то продумывает 2048-битные ключи и шифрование на элиптических кривых, а кто-то меняет значение двух байт данных и думает что защитился.
Извините, конечно, но смена порта это сесурити какое-то. Даже стыдно о таких методах говорить в современном мире.
А для использующих Fail2Ban в аду есть отдельный Jail. «Чтобы избежать нагрузки на сервер от попыток брутфорса, мы повесим внутри отдельный демон который будет постоянно парсить логи регулярками и рисовать правила с баном по IP, ведь авторизация по ключу и правила в iptables это так сложно и не эффективно»
John_SC
Изменил одну настройку fail2ban. А именно, бан на месяц тех, кто трижды ошибся. Пароль 19 символов, буквы разного регистра, плюс цифры и символы. Я в опасности?
dmxrand
Мы все умрем…
anonymous
да
jehy
В опасности. Легко трижды опечататься и потерять доступ к серверу.
John_SC
Но я хожу по rsa, а вход по паролю оставил на всякий случай, вдруг потеряю ключи.
Что до ошибок, то после первой ошибки начинаешь набирать очень внимательно.
isden
> Но я хожу по rsa, а вход по паролю оставил на всякий случай, вдруг потеряю ключи.
Но вход по паролю вы же все равно оставили — значит остается возможность брутфорса.
f2b может быть неэффективен в случае использования большого ботнета. И, насколько помню, там были какие-то проблемы с ipv6. Возможно тут лучше еще добавить ufw limit 22/tcp или аналогично через iptables.
На случай потери всех копий зашифрованного бэкапа ключей можно загрузить сервер с livecd / rescue и поставить новый ключ.
John_SC
Но пароль же 19 символов (на самом деле больше, конспирация), буквы разных регистров, цифры и знаки. Чтобы его сбрутить, из расчета три попытки в месяц с пары тысяч ip, времени понадобится ну очень много же.
isden
Но все равно вероятность больше, чем при удачном бруте rsa 4096.
Плюс если пароль не уникальный и не случайный, то шансы еще повышаются.
gecube
Пароль нужен только для локального входа на сервер.
По ipmi/kvm/iLo/любая консоль облачного провайдера.
Вообще по уму — смена пароля root должна делаться через автоматизированную систему управления конфигурацией.
По паролям. Ещё очень частая история — синхронизация учеток через LDAP/ActiveDirectory. В этом случае успешный Брут пароля пользователя даёт возможность беспрепятственного использования любого Корп.сервиса под его учеткой. Лучше уж по ключам ходить.
9660
Совсем не проблема — просто зайти на него через другой сервер, или через прокси.
gecube
и запросто таким образом отсечь пулы провайдеров, которые не дают «белый» айпи (всякие мобильные интернеты).
Да, можно возразить, что пользуйтесь ВПН, но это такое себе…
dmxrand
IPv6? Не?
gecube
К сожалению, не в России. К тому же, таблица блокировок по ipv6 в худшем случае будет… огромной.
saipr
Это так. Но в России есть SSH на ГОСТ-ах.
solalex
Переборщиков паролей много, если использовать стандартный 22 порт то благодаря f2b таблица записей блокировок за месяц будет примерно 2k, если использовать нестандартный порт, то все равно будут попадать переборщики. Я бы просто закрыл порт от всех, добавив пару своих подсетей в доверенные.
gecube
А ещё лучше — строить доступ через «бастионные» хосты
xenon
Если бы все вопросы безопасности решались просто ужесточением политик…
В реальности — это всегда компромисс, и неверно определив его, вы теряете в безопасности.
1) Длинный и сложный пароль? Значит он наверняка записан где-то на бумажке или каком-нибудь сайте-блокноте. И может потеряться. А может и «подглядеться».
2) Жесткая политика банов — раз в год и палка стреляет. Например, неудобно решать проблему на сервере с телефона, значит, может быть сядете за чужой комп (доверенный, хорошего человека). Но там нет ключей и с трех попыток и сами ошибетесь.
3) Непредвиденные проблемы — у них есть гадкое свойство — они непредвиденные. Например, какой-то кривой пакет SSH в обновлении, или уязвимость в алгоритме генерации ключей, из-за которой после обновления ssh сервер перестанет опознавать ваши ключи (да, дурное решение, но программист вот не подумал и сделал). И вот вы сами входите по паролю снова и делаете 3 ошибки.
Но можно с другой стороны идти. Не от шаблона своего поведения, а от шаблона атаки. Блокировка на один час — уже достаточно, чтобы предотвратить большинство брутфорса. Есть ли разница, подберут пароль за время в триста миллиардов раз больше времени жизни вселенной или всего лишь за 50 лет? Короткая блокировка безопаснее при ложном срабатывании, но дает достаточную (50 лет) защиту от брутфорса.
И еще такой момент — если у сервера есть альтернативный доступ (например, для VPS — это консоль сервера из админки у хостера, или просто ваш аккаунт у хостера, через который можно заказать визит в ДатаЦентр вплоть до того чтоб вытащить сервер из рэка и увезти домой) — то самые параноидальные методы дадут только побочные минусы, но прочность цепи по прежнему будет равна прочности самого слабого звена.
awsswa59
Вы знаете как приятно вбивать пароль из 19 знаков полученный от клиента по СМС.
А там весь набор символов, где много 0 или О или I или l — меня прям гордость берет за параноиков.
John_SC
Конкретно в вашем случае совершенно не проблема скопипастить пароль, например в «Telegram->Saved Message». Открыть десктоп клент и снова копипаст. Не в 90-ые же живем. Если же у вас не смартфон, то вам целесообразно апгрейднуться. Вы как-никак it-шник.