Comments 163

А какой, собственно, смысл держать открытым 22 порт для всех внешних адресов? Какой юз кейс, так сказать?

Юзкейс-то как раз понятен — собственно, ходить по SSH из разных мест :)

Другой вопрос, если не использовать для SSH пароли (тем более легко подбираемые, но лучше в принципе) — в чём большая проблема?

Сейчас посмотрел свои домашне-хоббийные сервера/роутеры — открытый в инет 22 порт обнаружился на одном VPS'е. За последнюю неделю стучались на этот порт ~5000 раз, поскольку авторизация по паролю у sshd отключена в принципе — то ожидаемо получали отлуп. Если бы fail2ban был (надо поставить, кстати) — стучались бы реже, но и так на DoS не тянет, жить не мешает.
На других серверах и прочих железках SSH только из VPN, но даже не уверен, так ли уж это правильно, если внешний IP в принципе есть. Лишняя точка отказа: отвалился VPN — и не зайдёшь никак.

Посоветованный ниже port knocking — лишние телодвижения и неудобства (например, я иногда по SSH с телефона на Андроиде хожу, и как тот клиент настроить, чтобы он сначала «стучался», или другой с такой фичей найти, — вообще неочевидно).
И, опять же, зачем? Так ли уж велик в реальной жизни риск атаки через какой-нибудь 0day эксплойт sshd, который не успеет обновиться в системе раньше, чем злоумышленник использует его именно в отношении моего скромного сервера? Или страхуемся от утечки ключа ssh? Ну так кто его добудет — то с большой долей вероятности он там же подсмотрит и настройки port knocking'а или что там ещё прикручено.
UFO landed and left these words here
Я JuiceSSH использую, в настройках такого нет. Но погуглил — оказывается, у него есть плагин для этой цели. Буду иметь в виду, если всё-таки пойму, что этот port knocking реально улучшает безопасность в каком-то реалистичном сценарии и стóит с ним заморочиться.
Я считаю, что такой подход может реально улучшить безопасность только если последовательность будет относительно длинная и генерированая рандомно. Если брать что-то, что первым приходит на ум, или (боже упаси) из манов в сети — воспроизвести/угадать такую последовательность можно достаточно просто
Вопрос в том, стóит ли вообще овчинка выделки (с любыми настройками) при условии:
— авторизации в ssh только по ключам;
— установки fail2ban для недопущения DoS'а и переполнения логов.

Два пришедших в голову сценария атаки, при которых port knocking поможет, а эти две меры сами по себе нет, я выше в комментарии привёл: атака через эксплойт sshd и утечка ключа (но без информации о настройках port knocking'а).
Мне кажется, что риск этих сценариев в реальной жизни исчезающе мал. Но было бы интересно услышать, если я ошибаюсь и ещё о чём-то не подумал.

P.S. Ну вот разве что если речь идёт о какой-то труднообновляемой железке (роутер с прошивкой от вендора, обновления которой надо мониторить и накатывать вручную), где sshd древней версии имеет шанс залежаться надолго, — тогда, может, есть смысл перестраховаться.
Нет, не поможет. Эта мера всего лишь оттягивает на пару недель, когда снова начнётся перебор паролей. Тоже самое относится и к другим сервисам типа RDP.
Ну его в этом случае надо сначала найти и понять действительно ли на устройстве есть сервер. Я не думаю, что все эти скрипты кроме брута паролей занимаются ещё и перебором портов

65к портов перебираются на раз два.
Это очень просто и быстро.

Сначала перебираются ip адреса, простым пингом, кто отвечает, у того потом и перебирают порты.
Переносишь на другой порт — находят быстро, отключаешь пинг, перестают находить. Есть сервера, несколько лет стоят, светят RDP, но не брутятся. Но, не все, конечно, некоторые находят все равно.
Но! как минимум пороль подбирает не каждый школьник.

отрезать себе пинг — это тоже прям очень "умно", в частности, когда будешь заниматься сетевой диагностикой

Кто-то спорит?
В статье и в этой ветке комментов обсуждается выставленный на весь интернет SSH и раз обсуждение зашло в сторону того, как лучше этот SSH спрятать — я поделился своим опытом.

Я же не утверждаю, что применив данный способ можно забыть про фаервол или VPN, Fail2ban, авторизацию по ключам и т.д.

От каких-то самых простых сканеров, может, и поможет. Но от сканеров и переход на ключи вместо паролей поможет сам по себе. А от целенаправленной атаки с использованием утекшего ключа или эксплойта — найти порт будет самой простой задачей злоумышленника.
Ну вот тут в комментах уже как минимум 2 варианта рассмотрели:
— port knocking (если настройки оного не утекли вместе с ключом);
— 2FA (это ещё лучше, но создаёт неудобства в повседневном использовании).

В зависимости от вероятности угрозы, тяжести возможных последствий, степени создаваемых неудобств, стадии развития собственной паранойи :) и пр. — можно выбрать для себя подходящее сочетание защитных мер.
Можно ещё ограничить пулл доступных адресов, но для этого нужен VPN (чтобы иметь доступ не только из домашней сети)
… а ключ для этого VPN, вероятно, лежал там же, где и ключ для SSH, и утёк вместе с ним :)
Порт ssh любым сканером портов обнаруживается т.к. ssh дает конкретный ответ при запросе к его порту. Попробуйте на порт SSH зайти telnet-ом и сами все поймете.

Это да, но ты пойди до него еще доберись, если там стоит какой-нибудь CHAOS+tarpit и сам ссш на высоких портах. От ботов хватает даже банального правила на DROP + перевешивания на высокий порт. А не от ботов — алерт на auth логи.

И правда. В самой программе в меню «Плагины» такой плагин есть, но при попытке установить переходит в Маркет, а тот ругается «Item not found». Плагин опенсорсный (https://github.com/Sonelli/juicessh-portknocker), там в issue #4 обсуждается эта проблема и дали ссылку на APK.
В любом случае, я что-то по итогам дискуссии склоняюсь в пользу выборочного 2FA вместо port knocking…

Черт бы с ним с юзкейсом — 100500 лет как придумали port knocker. Тот же 80,21,53 пропускают все и всегда.
Или, если уж так нужно — то только по сертифткатам без паролей.

У меня сразу вопрос возникает — Вы поставили НАС и не озаботились его защитой? При том, что вы даёте в конце рекомендации, как от этого защититься и по тексту статьи становится понятно, что вы в общем то далеко не домохозяйка.
Или как всегда — пока петух не клюнет? :)

И на старуху бывает порнуха.
Я вон клиенту наворотил защит, но при очередной манипуляции в скрипт iptables закралась запятышка. И iptables свалился в default (а я не заметил и не проверил), когда почти всё почти всем.
Очнулся только когда через пару месяцев хостер тонко намекнул своим сканером, что у меня открыты уж слишком уж неприличные порты.


А так — упавшее и быстро поднятое упавшим не считается.

Просто открытые порты это еще мелочь. Вчера вот меня попросили поднять один проект из бекапа (интернет-магазин, который уже прекратил своё существование, но дабы не были нарушены права потребителей, саппорт еще осуществляется, и для этого нужен доступ к истории продаж). Так вот при попытке поднять сайт я получал некую ошибку и решил её загуглить. Как же я был удивлен, когда я в гугле нашел в открытом доступе исходники, с паролями к разным ресурсам и прочее (хостер сделал basic http-auth на порт 80, но на порту 443 по нешифрованному http-протоколу (!) было доступно содержимое всего в открытом доступе, включая папку .git и пароли). Это, к счастью, была лишь dev-версия, т.е. к продашн данным оттуда было не добраться, но показательно. Судя по всему, исходники были в открытом доступе года 3-4 и при этом постоянно актуализировались.

Да случайно напоролся. Руки не дошли заткнуть юзера после добавления timemachine на него.
Может быть кто-то с хабра подскажет как снять с адреса черную метку

Скорее всего — никак.
Любой удод может настучать в DNSBL или нечто подобное — и потом запаритесь доказывать, что не верблюд (особенно если нет правильного обратного резолва (а кто ж Вам его даст)).

Есть ещё вменяемые провайдеры, которые дают возможность править записи ptr. Только из-за этого на домру и перешёл.

с работы из dnsbl чистили. Попала аж целая подсеть хостера infobox в каком-то году.
В общем писали заяву сами по электронке + тикет в суппорт, они тоже писали, 3 месяца ожидания и удалили подсеть из списка.
По поводу как снять блокировку — в первом же сообщении статьи написано, что используется база maxmind.com. У них есть форма для коррекции сведений — support.maxmind.com/geoip-data-correction-request. Там, правда, речь про коррекцию неверной геолокации, но пишут, что рассматривают заявки вручную, так что если в комментарии кратко изложить проблему — возможно, исправят. Хотя, думаю, записи в их базе должны так или иначе сами по себе устаревать, ибо иначе половина динамических адресов рано или поздно в блэклисты попадут.

P.S. Ну и да, файрволл и fail2ban я сам иногда ленюсь сразу настраивать, да и 22 порт, грешен, иногда открытым оставляю, — но «PasswordAuthentication no» в sshd_config — это чуть ли не первый шаг для любой linux железки в домашнем хозяйстве.

Всё верно, мой почтовик раньше влипал в базы dnsbl, в результате иногда хожу по спискам этих баз, тестирую почтовик, снимаю старые баны, проверяю на возможные уязвимости типа опенрелеев. Уже много лет никпких проблем. Самописный скрипт анализирует логи нескольких программ на попытки подбора паролей и блокируе ip (скрипт писался ДО того, как узнал про fail2ban — меня мой скрипт устраивает)

В этой статье фраза «используйте вход только по ключам, запретите вход по паролям» — явно табу.
UFO landed and left these words here
Да любой из словаря. Это действительно важно какой именно?
Словари гуглятся легко.
По полному словарю обычно не перебирают, так как это слишком долго и сложно. Перебирается штук пять-десять самых популярных паролей для примерно такого же количества пользователей, после чего на эту конкретную систему ломиться смысл пропадает, и нужно переходить к следующему IP-адресу.
Перебирают намного глубже.
В качестве теста на ~30 серверах я пробросил 22-й порт на сторонний сервер и там выставлял разного рода «словарные» пароли, наблюдая за брутфорсами.
В среднем ожидание взлома пароля из списка www.iau.org/public/themes/naming_stars занимало 1-3 недели.
Числовой, например 6227020800 (он тоже входит в словари) около суток.
Самыми первыми 2-мя действиями на любом Linux торчащем 22-м портом в интернет должны быть:
1 — запрет логина в SSH по паролю
2 — настройка входа в SSH по ключам

PS Чуть спокойнее когда 22 порт светится только на IPv6, там пока «тишь и гладь», но не думаю что это надолго…
Чем ключи лучше случайно сгенерированного 20-30 символьного пароля в практическом плане?
Как раз в практическом смысле использование ключей удобней указанием файла, в котором содержится ключ.

Тем что пароль передается на удаленный сервер в открытом виде и если он (сервер) скомпроментирован, будет скомпроментирован и ваш пароль при логине. Если вы его используете на нескольких серверах — будет получен доступ и к ним. Если же вы генерируете пароли для каждого сервера — то в практическом плане ключ удобнее тем что он безопасно может быть один для доступа на многие сервера.

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

А вот ключ в этом отношении безопасен. Один ключ для большого количества серверов это безопасно и хорошо.
Ключ через агента не утекает никак. Хотя авторизоваться можно.

Тот кто ставит * для форварда в конфиге сам виноват. Насколько я помню в дефолтном конфиге даже коммент соответвующий есть.
IPv6 тоже не панацея. Единственное, если дублировать на интерфейс еще один IPv6-адрес, на который повесить только SSH и ничего более.
На IPv6 сканирование теряет смысл. Когда каждой домохозяйке по сути выделяют в подсеть ровно столько же бит, сколько выделено на весь остальной интернет. Отыскать в подсети /64 один единственный адрес, полученный по SLAAC или RFC4941 и который отвечает по порту 22 — слаборешаемая при нынешних скоростях в каналах задача. Будут типичными скорости десятки гигабит в секунду до массового потребителя, тогда может — да. Так что использование IPv6 везде где можно — вполне себе альтернатива VPN.
Ну это пока «каналы слабые».

Ну и как бы то ни было — это не защита в полном смысле этого слова, а попытка спрятаться. Т.е. работает не со 100% вероятностью, а просто с очень большой.
Но, там где важна конфиденциальность даже маленькая вероятность провала неприемлема, поэтому трудно согласиться, что IPv6 полноценная замена VPN.
habr.com/ru/post/482784/#comment_21105180
На IPv6 сканирование теряет смысл.
Ну это пока «каналы слабые».
Представим ботнет, состоящий из десяти миллионов зараженных компьютеров, каждый из которых сканирует за секунду сто IP-адресов; предположим, что все компьютеры, входящие в ботнет, включены постоянно и имеют доступ к интернету и по IPv4, и по IPv6. Сканирование по одному порту (например, 22) всего адресного пространства IPv4 заняло бы у такого ботнета меньше пяти секунд. Сканирование же всего адресного пространства IPv6 заняло бы у такого ботнета время, в десять с лишним тысяч раз большее, чем миллиард миллиардов лет!
Для SSH сам по себе VPN имеет мало смысла — мы ведь постулируем, что данные в сети в SSH передаются в зашифрованном виде и мы этой шифрации доверяем. Поскольку для VPN и для SSH весьма часто используются одни и те же алгоритмы, то считать что абстрактный VPN по имени XYZ дает большую безопасность по сравнению с чистым SSH некорректно. Опять таки, если мы защищаемся от ошибок сисадмина, у которого в SSH используются логины, ломаемые брутфорсом, то где гарантия того, что VPN «XYZ» у этого же админа будет настроен более правильно?
Итого чистый остаток, почему есть смысл использовать IPv6 вместо VPN в таких случаях: спрятаться от попыток перебора и брутфорса, во-первых это снижает нагрузку, что важно, если у вас не сервер с топовым Xeon, а дохлый MIPS на 300Мгц в роутере. Так что да, это в первую очередь удачная попытка спрятаться. Второе — любой VPN сильно снижает доступность хоста: ситуаций с NAT, проблем с кривым MTU и зарезанным ICMP в абстрактном Мухосранске — выше крыши, и вот уже ваш VPN просто не завелся или работает криво. С другой стороны, и IPv6 есть не везде и не всегда и не получится полагаться исключительно на него.
Второе — любой VPN сильно снижает доступность хоста: ситуаций с NAT, проблем с кривым MTU и зарезанным ICMP в абстрактном Мухосранске — выше крыши, и вот уже ваш VPN просто не завелся или работает криво

не преувеличивайте масштаб проблемы. L2TP/PPTP — да, могут не работать, в зависимости от провайдера. Но какой-нибудь Cisco AnyConnect — не видел еще, чтобы он не "пробивал". Ну, и VPN дополнительно решает проблему доступности сетевых ресурсов из офиса пачкой (сервера, принтеры и пр.), создавая при этом проблему маскирования ресурсов в локальной сети пользователя, если он недостаточно удачен и произошло пересечение адресов. Плюс зачастую можно запретить сплит туннелирование — это небольшой плюсик к безопасности, в первую очередь, в головах ИБшников.

В 2020 году ssh с доступом по паролю? Вы где были все последние годы? А еще «Руководитель отдела разработки ПО»

Все эти fail2ban и port knocking только жить мешают. Требуется нетривиальная настройка клиента и возможны проблемы в случае неверной настроки.
С чужого планшета слазить сложно становится. А такое нужно всегда срочно и внезапно.

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

Для школьника настраивающего свой первый ssh сервер это простительно. А вот для «Руководитель отдела разработки ПО» уже нет. У вас же там сервера какие-то стоят. Инфраструктура какая-то есть. На них разработчики ходят. Админы или деопсы управляют всем этим. ssh ключи должны быть везде. Или везде пароли стоят… Тогда мне страшно за ваши сервера. Я бы вышел даже на праздниках такое срочно переделать. Разломают же все. Просто потому что могут.
Дома он тоже руководитель разработки ПО?
язвительный вы какой-то.
Я бы постыдился такое на публику выносить.-у всех свои минусы, а ТС не постыдился (;
Да. Или при выходе с работы память стирают?
Писать на весь мир «Я некомпетентен в своей профессиональной области». Такое себе…

Видимо поря завязывать с комментариями. Хабр становится странным. За указывание на некомпетентность человека в области которую он сам обозначил как свою профессиональную идут массовые минусы в карму. А за абсолютно неграмотную технически статью идут плюсы.
В первых 2 фразах статьи должно быть «Поставить вход по ключам. Переставить скомпрометированную систему» А дальше можно в песочнице разбираться что там наставили. На реальной скомпрометированной системе ничего чистить не в коем случае нельзя.
Ну меня честно говоря это шокирует, что есть люди в IT, которые оставляют сервер с открытым всему миру 22 портом с паролем. Это просто вопрос времени когда его вскроют.
Так же как и передача паролей по мылу в clear text, авторизация с http и clear test smtp, шифрование WEP на вайфайе или вообще без шифрования, плата карточкой без cvc кода и прочие вещи из времен «дикого интернета». Я бы все таки постыдился.
Хотя может это профессиональная деформация.
Может расскажете за какое время взломают систему в которой 16-символьный случайный пароль (из набора в 54 — это [a-zA-Z0-9] минус похожие) на ssh?

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

Есть у меня клиент, у него 5 серверов (там wp, crm и всё такое), от ключей отказался ибо для него это сложно (сам он далек от IT, ssh фактически нужен только для работы по sftp и на тот случай если меня трамвай переедет и нужен будет доступ кому-то ещё), файрволл не канает потому что он постоянно ездит по всему миру (да, vpn для него тоже за гранью), поэтому поставил вышеупомянутые 16-ти символьные случайные пароли (благо password manager у него есть) — и математика мне подсказывает что в ближайшее тысячелетие их не сломают (даже если получат их солёные хеши, про онлайн я уже молчу).

С другой стороны, если у него на компе троянец заведётся или кто-то ручками влезет — то и ключи не спасут.

fail2ban, кстати, почти бесполезен — по моим наблюдениям, сейчас ломятся с разных адресов на одного пользователя с разными паролями (словарными, разумеется), атакующие IP повторяются в лучшем случае через сутки и делает максимум две попытки.
Может расскажете за какое время взломают систему в которой 16-символьный случайный пароль (из набора в 54 — это [a-zA-Z0-9] минус похожие) на ssh?
Может подскажете сколько пользователей ставят такие пароли? Все это хорошо в теории, на практике выходит то, что у ТС случилось. Можно и пароль из миллиона симолов придумать, удачи в использовании.
То есть вы всё-таки согласны что правильный пароль не хуже чем ключ?

На практике это реализуется генератором паролей и проверкой сложности (и словарей) при смене (или начальном выборе) пароля.

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

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

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

Первая и вторая части Вашего сообщения, ну, никак не связаны


Ключ к ссш — намного удобнее и безопаснее, чем пароли. Та же работа с гитом, как пример. Либо ты зашиваешь пароль в настройки Гита (и он там болтается плейн текстом), либо надо тащить системную ключницу. Единственное, что реально удобно в гитлабах и прочем — это многоразовые токены (оно по сути как пароли работают).

Удобнее — кому как, моему клиенту нет, например, хотя я сам как раз использую ключи (для всех смотрящих наружу ssh, по крайней мере).

Безопаснее — только в описанных вами случаях (git & co, т.е. случаи когда нужно избежать shared secret на другой стороне), если же речь просто про вход терминалом — то легко сделать непробиваемый и легко запоминаемый пароль с энтропией от 100 бит и выше (фраза с модификаторами — ни словарём, ни брутом не взять, при этом её даже в блокнот можно записать практически ничем не рискуя), а с точки зрения утечки/потери или маски-шоу пароль и ключ ничем не отличаются.

Ну нет же. Ключ может храниться на неизвлекаемом носителе. Например тот же TPM. Пароль надо вводить при каждом логине на сервер, ключ может быть расшифрован один раз и храниться ssh-agent'ом. Один ключ может безопасно использоваться для входа на несколько серверов, пароль — нет. Ваш пароль передается на удаленный серевер и легко может быть извлечен рутом на сервере куда вы логинитесь (как пример — специальный pam модуль). Единственный плюс пароля — отсутствие необходимости хранить ключ.

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

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

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

Есть, кстати, один интересный нюанс — с небольшой модификацией ssh-keygen ключи могут быть сгенерированы с помощью хэша от произвольного пароля (используя его как seed), таким образом позволяя всегда их «носить с собой», т.е. их можно восстановить имея только генератор (и свой супер-пароль), без необходимости хранения самих ключей.

Очень интересный комментарий по делу, спасибо.
Могу только добавить, что в кровавом Энтерпрайзе очень странные понятия об ИБ. Ключи запрещены, пароли разрешены, при этом есть правила по сложности паролей, их неповторяемости и ротации каждые хх дней. Выглядит в нынешние времена как дикость.
Либо не все Энтерпрайзе одинаково полезны )))

В ряде энтерпрайзов с которыми я имел дело СБшники мотивировали отказ от ключей сложностью отъема доступа в случае необходимости (это чуток сложнее чем сменить пароль), а также опасались «троянского» ключа — всё же в случае ssh это не так красиво как в случае «полновесной» системы с CA (хотя и он это поддерживает).

Впрочем, в большинстве случаев в СБ находятся вовсе не специалисты в области IT безопасности, отсюда и «дикость».

Театр безопасности какой-то. "Троянский" ключ возможен в любом случае, независимо от регламентов СБ. Вот они по-отключали ключи на серверах, а я включил и свой прописал. И кто мне помешает?


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

Бежать надо от такого Энтерпрайза. Они данные потеряют и тебя виновным сделают.

Есть же типовой сценарий: Вот тебе ноут. Диск на нем шифрован. Ключ с ноута не не выносить. Ноут бери с собой. Потерял/украли срочно пиши/звони вот сюда в любое время.

Насчёт fail2ban согласен. Он скорее не помогает, а мешает. Плюс дополнительный компонент, в котором, внезапно, тоже бывают баги.
Всю защиту от брута можно сделать и настройками ssh демона, но тут надо не переборщить, чтобы случайно себе доступн не отрезать, когда будут ломать

А почему бы не запретить доступ по поролям, и не использовать ключи?
Это должно быть не последней рекомендацией, а самым первым правилом. Все остальное может быть рекомендациями, а запрет логина по паролю — закон.

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


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

А для веб логина есть связка ключей в браузере ) или где она там обычно у вас )

"Критикуешь — предлагай", а не, как в том анекдоте, "мыши, станьте ёжиками". Вот Вам use case: нужно входить на домашний компьютер по SSH с телефона. Как Вы предлагаете "пользоваться ключами"? Запоминать многосимвольные случайные ключи? Желаю удачи. Хранить ключи на телефоне? Тогда некоторые любопытные сотрудники аэропорта автоматически имеют доступ и к Вашему компьютеру. Хранить на телефоне запароленные ключи? Тогда, когда в Вашем телефоне садится батарейка/разбивается экран/он падает в туалет, Вас ждёт ещё один неприятный сюрприз. Жду Ваших предложений.

Ничего не понимаю.


  1. Ничего не мешает иметь по ключу на каждое устройство, с которого заходите, — потом их так проще менеджить.
  2. Ничего не мешает иметь на телефоне ключ с паролем. Сперли телефон — ну, ок, ключ-то под паролем? А на рабочей машине тот же ключ без пароля или вообще другой ключ (п.1)
  3. Пароль — ненадёжен априори. Его могут подсмотреть через плечо, может стоять кейлоггер, или что ещё.
  4. Я уж не говорю, что в идеале доступ должен быть через ВПН или промежуточный хост (proxy, bastion, jumphost)

Вы специально пропустили следующий случай, или просто не обратили внимания?


  • Ключ от домашнего компьютера на телефоне, под паролем.
  • Вы находитесь далеко от дома (напримиер, в аэропорту) и Вам очень нужно вот прямо сейчас зайти на домашний компьютер (например, потерялся посадочный талон и нужен с него код, ну или сами придумайте зачем).
  • Телефон по каким-то причинам недоступен (села батарейка, случайно уронился в унитаз и промок, украли).

Ваши действия?

Спасибо, что повторно разъяснили.
У меня попросту не возникнет такой ситуации, что СРОЧНО нужно зайти на домашний компьютер. Потому что ноут всегда с собой. А если я недоступен… То недоступен. С тем же успехом там где Вы находитесь может вообще оказаться мобильного интернета или бесплатного вайфай.
Я уж не говорю о том, что домашний компьютер напрямую по ссш из интернета — дичь какая-то. У меня так вообще дома сейчас прямого внешнего айпи нет… И я еще 10 раз подумаю — стоит ли провайдеру за него доплачивать.
Ну, и если очень надо — родственники дома есть…
Так что какой-то странный кейс.

Некоторые работают дома, и у них на домашнем компе (сервере) всё что имеет отношение к работе (при этом не всё можно и нужно носить на ноуте), так что доступ нужен на случай выезда.

При нормальном подходе нет никакой разницы — дома комп или на работе, меры по защите одинаковые, дома даже проще обеспечить безопасность, ибо в офисе обычно больше лиц с непонятным уровнем доверия (приходящие курьеры, ремонтники, уборщики etc).

Опередили меня. Не вижу ни одной причины, почему если у человека есть ссш, то не перекатиться на ВПН.

А я не вижу ни одной зачем перекатываться на VPN (если не нужен доступ ко всей сети) — с точки зрения безопасности VPN ничуть не лучше SSH с ключём или даже адекватным паролем, к тому же, с версии 4.3 он сам может выступать как VPN (через tun).

Если же говорить о потенциальных 0day-уязвимостях, то VPN от них тоже не застрахованы, и на них тоже долбятся.

Вероятность взлома и vpn, и ssh одновременно ниже, чем вероятность взлома одного лишь ssh. Ну, и вопрос в том — что мы подразумеваем под 0day — эскалацию до рута или просто обход аутентификации/авторизации.

Что-то мне подказывает что уязвимость в sshd позволяющая вход без верного ключа будет стоить столько… что нам беспокоится о ней не надо. Я даже не уверен что Гугл о таком беспокоится.
У меня попросту не возникнет такой ситуации

Попытка съехать с темы опознана и пресечена. Возникает такая ситуация, возникает — у меня, например, постоянно. Возможно, потому, что у меня не windows. Или потому, что у меня телефон не помойка, на которую я тащу всё подряд, а карманный терминал.


Потому что ноут всегда с собой.

Предпочитаю не рисовать у себя на спине большую жирную мишень для грабителей.


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

В Тимбукту я пока не ездил.


Ну, и если очень надо — родственники дома есть

"Что знают двое, знает и свинья".

Для ключа под паролем нестрашно иметь копию на внешнем хранилище доступном из интернетов.

Но тогда возвращаемся к началу дискуссии: если ключ защищен паролем, то слабое звено в цепочке — опять же пароль. Это примерно как


Вот такая штука

image


— ключ от квартиры, где деньги лежат, кладётся в мини-сейф, защищённый всего лишь 4-значным кодом. При определённой сноровке взломщик может код подобрать.


— так зачем вобще нужно это лишнее звено?

Копию ключа, нужную чуть чаще чем никогда, можно закрыть паролем любой длины.

Я тут статью вспоминаю про то что ключ зашифрованный паролем аналогичен ключу без пароля. Не знаю насколько она актуальна, но все же лучше этот ключ зашифровать дополнительно. https://habr.com/ru/company/wirex/blog/419829/

Там не технические доводы в статье, а больше — социальные.
В общем, с чем соглашусь — обычно шифрование ключа паролем бессмысленно и реально безопасности не добавляет.

Ноуты с tpm это удобно. Нативное прозрачное шифрование диска из коробки.


Телефоны аналогично. Любой нормальный телефон воровать бесполезно.

Ноуты с tpm это удобно.
Не только ноуты. У больших братьев тоже есть, правда выключено в биосе по дефолту.

В случае кражи — там надо про FDE думать и удаленное стирание инфы (antitheft, computrace), а не про пароли на ключи

Давайте честно — то что у меня не возникает такой проблемы — не означает, что у других ее нет. И верно обратное — то что у Вас какой-то специфичный кейс — не означает, что у остальных все так же.
Как этот надуманный пример с севшим телефон. В нынешнем мире вообще очень стрёмно с разряженным телефоном. Та же 2FA для облачных сервисов
Заходишь с нового места или устройства… И приплыли.
Я уж не говорю о том, что, да, действительно, для серьезных применений нужно, наверное, иметь несколько телефонов. Один — для Фейсбуков, контактиков, а второй — для банк-клиентов, ссш, и прочего нужного и важного.


По поводу впн вместо "голого" ссш домой коллеги высказались. Действительно, как ещё один уровень защиты — почему нет? И не нужно 'отмазываться', что у вас там роутера нет или провайдер блочит — все решаемо.

"ещё один уровень защиты — почему нет? "


Ещё одна точка отказа — почему да?

У вас точка отказа ровно одна — роутер, через который интернет заведен в квартиру. Что с впном, что без.

Вот, допустим, по какой то причине упал VPN на этом вашем сервере. Диск переполнился внезапно, телеграмкомнадзор решил, что vpn без освященного им же сертификата быть негоже, 10050 причин может быть. Ваши действия? Дальняя дорога? Черный ход в обход VPN?

То же самое будет и для ssh. Кончилось место? Под непривилегированным пользователем тупо не залогиниться (на самом деле — там ещё много переменных, поэтому я не буду утверждать, что корелляция 100%). И?

"То же самое будет и для ssh."


Не совсем. Под root можно хотя бы попробовать залогиниться и разобраться с ситуацией.

Отличный бедпректис — оставлять рутовый доступ по ssh. Даже обсуждать не хочется.

А в чём, собственно, проблема? Эту мантру все повторяют ещё со времен telnet, единственное весомое «против» — это то что случайно можно дел натворить, забыв что залогинился как рут, всё остальное потеряло смысл со времен изобретения ssh.

Можете привести хоть один весомый аргумент «против» (не считая «случайно rm -rf /» и прочих глупостей из этой серии) для логина как рут с ключём?

Вопрос не праздный, потому что нигде в обсуждениях вопроса «Почему нельзя логиниться как рут?» не приводят никаких аргументов (кроме уже упомянутого «случайно сделаете глупость» — но глупость можно сделать и в sudo).

Из очевидных вещей:
В многопользовательской среде сложнее определить, кто заходит под рутом — персонализированные учётки намного выгоднее и ими в каком-то смысле проще управлять, чем свалкой ключей у рута в authorized_keys.
Второй аргумент в том, что если root включен, то надо подобрать только ключ/парольную фразу, а не пару имя пользователя+пароль/ключ.
Третья история, как Вы верно заметили, не всегда нужны админские права — и тогда проще сразу ходить пол юзером, а не сразу под рутом. Про принцип наименьших привилегий ведь все слышали?
Дальше думать надо )

Это всё валидные аргументы, но всё же из той же серии — «как бы чего не вышло».

Если мне нужно что-то сделать как рут (а в большинстве случаев это так и есть) — я логинюсь сразу как рут, в почти всех системам мне там делать нечего как обычному пользователю. Поскольку я делаю это исключительно со своего компа или vpn (как и мои коллеги) — то выяснить кто там был — не проблема (но это бывает нужно чуть чаще чем никогда).

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

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

Это просто иллюстрация того что bad practice не всегда bad — всё зависит от конкретных условий. Могу лишь заметить что за 20 с лишним лет это не привело ни к каким проблемам — ни у меня, ни у коллег, ни у клиентов.

Любая катастрофа — это совокупность факторов и обстоятельств. Возможность доступа к руту по ссш — может быть таковым фактором, а может не быть.

"если root включен, то надо подобрать только ключ/парольную фразу"


Всего лишь подобрать ключ. Думаю, есть способы быстрее и дешевле. Например, купить датацентр вместе с сервером, куда нужно получить доступ. :D

Второй аргумент в том, что если root включен, то надо подобрать только ключ/парольную фразу, а не пару имя пользователя+пароль/ключ.

А по-нормальному — надо подобрать логин юзера + аутентификацию юзера + пароль su (подбор которого можно начать только после того, как первые два фактора уже сломаны и не для любого, а для wheel-аккаунта).
В случае в логином юзера по ключу третьим фактором может быть пароль sudo (который не подойдёт в качестве второго по причине запрета логина по паролю).

надо подобрать логин юзера

Не надо. Это публичная информация. Если даже у вас не так, то лучше все равно исходить из того что логин все знают. Он нигде особо не скрывается.

пароль su

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

Вынужден согласиться с обоими пунктами. Но хочу заметить, что логин все-таки имеет чуточку больше энтропии, чем попросту фамилия-имя юзера (т.к. могут быть разные варианты + необходимость различения полных тезок, если у нас прям кровавый энтерпрайз).

Хранить на телефоне ключи. Память телефона шифровать. Любопытных сотрудников аэропорта с требованием расшифровки посылать подальше (вежливо, «сам забыл пароль, приеду — придётся всё стирать и заново настраивать»). В те не столь многочисленные страны, где это не прокатит, въезжать с чистым телефоном без данных и предусматривать какой-то разовый механизм загрузки оных после въезда (тут уже можно придумывать варианты, как это реализовать — но это не повод менять обычный способ работы).
Подбирается по словарю.

В английском языке около 1,4 миллиона слов — примем для простоты (c большим запасом), что ровно 210. Четыре слова (с сохранением порядка следования) — 240. Подбирайте!


Помогает также переключение языков — набирайте русские слова в английской раскладке (ghfdbkmyj kjiflm ,fnfhtz chrtgrf) — ещё несколько бит в сложность прямо с потолка (я надеюсь, что Вы умеете в слепой метод?)

Речь про Google Authenticator?

Неудобно (особенно если надо быстро несколько сессий на разных серверах открыть — утомишься переключаться на authenticator и обратно вводить коды).
Не позволяет использовать средства автоматизации, работающие по ssh (тот же ansible).
Не очень универсально (насколько я понимаю, реализовать это, скажем, на Микротике невозможно).
Не даёт очевидных преимуществ перед просто использованием ключа в плане защиты от атак.

Хотя, наверное, в ряде случаев есть смысл перестраховаться и делать ключ + 2FA. Например, если в сохранности ключей у тех, кому они раздаются, есть обоснованные сомнения.
Не позволяет использовать средства автоматизации, работающие по ssh (тот же ansible).

ничто не мешает держать дополнительный ssh-сервер внутри периметра, который уже не будет закрыт 2fa(2fa на джамп-сервере или vpn). или, например, использовать ансибл в роли псевдоагента, т.е. на каждом хосте проливать локалхост ансиблом.

Не даёт очевидных преимуществ перед просто использованием ключа в плане защиты от атак.

в случае компрометации ключа можно получить моментально контроль над всеми хостами, где прописан ключ.
в случае с 2fa, слитые ключ или парольная фраза не такая уж и проблема, 2fa остаётся не скомпрометирован, можно неторопливо заменить пароль/ключ.

Не даёт очевидных преимуществ перед просто использованием ключа в плане защиты от атак.

даёт, например, ключ можно сфорвардить на зараженном сервере и получить доступ к другим хостам.

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

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

ps не пользую 2fa помимо работы(например, дома), но одобряю.
Вообще да, в этом что-то есть. У меня единственный держатель ключей — это я сам, так что вопрос доверия не стоит, но сценариев утечки ключа можно придумать достаточно много.

Но хотелось бы в этом варианте компромисс между удобством и безопасностью всё же немного сдвинуть в сторону удобства. Отсюда вопрос — а никто не знает работающего рецепта настройки 2FA так, чтобы он использовался только для доступа с неизвестных IP-адресов, а для один раз авторизованных — в дальнейшем хватало просто ключа? Сделать два SSH-сервера: один с 2FA, а другой — с ограничением по IP, — очевидно, но тоже неудобно.

Насколько я помню — можно даже в рамках одного sshd_config делать разные группы хостов и, возможно, что назначать на них разные алгоритмы или параметры авторизации/аутентификации

Спасибо за наводку, надо погуглить. Если так можно — то написать скрипт, парсящий auth.log, чтобы добавлять один раз успешно авторизовавшиеся адреса в группу, которой не нужна 2FA, — дело простое.
Отсюда вопрос — а никто не знает работающего рецепта настройки 2FA так, чтобы он использовался только для доступа с неизвестных IP-адресов, а для один раз авторизованных — в дальнейшем хватало просто ключа?

Это поведение по умолчанию!
То есть если вы заходите не по ключу, то у вас спрашивают пароль и код, а если по ключу — ничего.
Речь шла про то, чтобы заходить всегда по ключу, но если адрес не входит в белый список и ранее ни разу не был авторизован с помощью 2FA — то дополнительно к ключу требовать код 2FA. Как защита от утечки ключа.
Есть такая вещь как требование безопасников. Если указали использовать составной пароль и выдали RSA-ключи значит будешь каждую консоль открывать ожидая смены RSA-пароля и если раз ошибся с вводом или не успел то опять ждать.
Ну тут статья изначально была про домашний NAS, так что я комментирую из предположения, что мы обсуждаем те случаи, когда мы сами себе политики безопасности определяем. Понятно, что если есть спущенный сверху стандарт, который не обсуждается — то как бы крив и неудобен он ни был, придётся соблюдать.

Какие удивительные вещи происходят. Статья о том как кому-то сбрутили простой пасс и залили типовую малварь, но при этом с таким заголовком, как будто в ней проведено какое-то расследование мирового масштаба.
И комментарии под ней, на полном серьёзе что-то обсуждающие.
Надо мне наверно тоже написать статью о том как мне 12 лет назад подобрали ssh пароль "123" на пустом сервере и тоже что-то туда залили, и как я потом переустановил систему но уже не ставя таких паролей, может инвайт дадут.

«Я зашел на NAS и первым делом посмотрел стоит ли на нем fail2ban и активирован ли ufw. Ни того ни другого я не обнаружил, а auth.log был внушительного размера.»

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

А заголовок статьи огненный, конечно — «веерная атака на подсистему SSH» — это внушаетъ! Я вот купился, например, и даже прочитал до конца статьи, не веря, правда, своим глазам.
Ну при всей, мягко говоря, недальновидности автора, такой пост — прекрасный повод обсудить необходимые и достаточные меры защиты SSH-сервера и баланс между удобством и паранойей в данном вопросе. Что тут и происходит в комментах :)
1. Скомпрометированная ОС не лечится, а уничтожается с переустановкой. Это тикающая бомба. Я могу столько всего на машину насадить, что замаетесь обнаруживать. И для отвода глаз наследить.

2. Или пароль с 2fa или ключи
Скомпрометированная ОС не лечится, а уничтожается с переустановкой.
Но не следует торопиться с уничтожением.
Эта система становится интересна для анализа причин произошедшего и осознания своих ошибок в плоскости администрирования и настроек, чтоб в новой инсталяции не повторять глупостей.
+1

Добавлю только, что машинка тушится и клонится. А затем уже или потрошится файловая неактивной системы или изолируется от сети и потрошится активная система.

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

Очень странная рекомендация. Я бы предложил «запретите любой ssh вход по паролям. требуйте наличие надежного ключа».
Я во всей статье не понял лишь одного, а на кой, простите, вы ваш nas засунули в dmz? Т.е. на мой взгляд проблема даже не в том, что словарный пароль на ssh и не выключен вход по паролю, а именно dmz.

Да тоже стало интересно, что именно заставило ТС засунуть нас в dmz.

Ну если сервер светит голым 22 с паролем в интернет, то лучше его в дмз держать, конечно.
это не тот dmz, о котором вы подумали. это dmz в терминологии бытовых роутеров, просто перенаправление всего несматченного трафика на один айпи из домашней сети. т.е. отдельного изолированного сегмента сети в этом случае не создаётся.
Сегодня мой внешний IP был заблокирован в сервисе IVI с сообщением

А зачем IVI делает такие блокировки?
Можно отключать только сам счетчик, а не сервис целиком.
Чтобы через прокси/VPN/TOR не получали доступ к контенту из тех регионов, на которые не распространяются лицензионные соглашения с правообладателями. Не удивлюсь, если это требование таких лицензионных соглашений («принимать меры к недопущению… бла-бла-бла»), а не собственная инициатива кинотеатра.
на мой сервак пару лет назад тоже часто были атаки, подбирали пароль, тупо сменил порт и все прекратиловь, а так на 21 подключались и подбирали.
А можно все-таки выложить архивчик с директорией .lwp в публичное место?
Заголовок звучит как страшный кликбейт, хотя по сути — пробрутфорсили плохой пароль.
как снять с адреса черную метку?

Два способа.
1) Ленивый. Ничего не делать. MaxMind периодически сканирует все хосты интернета (ха!). Скорость не раскрывается, но она в целом приемлема. Как только повторно просканируют — удалят метку из своей базы, а далее все клиенты MaxMind (включая ivi) получат обновление, и — вуаля!
2) Активный. Как уже было замечено в комментах — написать в поддержку MaxMind «Я устранил анонимный прокси, сделайте на мой IP (X.X.X.X) ускоренное сканирование». Они на такие просьбы обычно положительно реагируют. Дальше механика та же — скан, обновление БД.

И есть ещё одна проблема: MaxMind бесплатно не показывает статус IP адреса. Но можно воспользоваться чем-то другим. Например, www.ipqualityscore.com/free-ip-lookup-proxy-vpn-test/lookup
А как быть если на домашнем роутере приходится держать открытый VPN? Например для доступа к домашним компьютерам.
Опять-таки, MaxMind не разглашает алгоритм, но выглядит так, что персональные VPN они не маркируют. У меня вот на домашнем адресе есть VPN, но в чёрные списки не попал.
Что в IT творится на сегодняшний день?!.. Модно стало залезть в дерьмо по собственной глупости, потом как-то костыльно-велосипедно решить это, а потом ещё и на конференции рассказать. Где остальные такие же в зале будут сидеть и хлопать восторгаясь.
Only those users with full accounts are able to leave comments. Log in, please.