Комментарии 163
А какой, собственно, смысл держать открытым 22 порт для всех внешних адресов? Какой юз кейс, так сказать?
Другой вопрос, если не использовать для SSH пароли (тем более легко подбираемые, но лучше в принципе) — в чём большая проблема?
Сейчас посмотрел свои домашне-хоббийные сервера/роутеры — открытый в инет 22 порт обнаружился на одном VPS'е. За последнюю неделю стучались на этот порт ~5000 раз, поскольку авторизация по паролю у sshd отключена в принципе — то ожидаемо получали отлуп. Если бы fail2ban был (надо поставить, кстати) — стучались бы реже, но и так на DoS не тянет, жить не мешает.
На других серверах и прочих железках SSH только из VPN, но даже не уверен, так ли уж это правильно, если внешний IP в принципе есть. Лишняя точка отказа: отвалился VPN — и не зайдёшь никак.
Посоветованный ниже port knocking — лишние телодвижения и неудобства (например, я иногда по SSH с телефона на Андроиде хожу, и как тот клиент настроить, чтобы он сначала «стучался», или другой с такой фичей найти, — вообще неочевидно).
И, опять же, зачем? Так ли уж велик в реальной жизни риск атаки через какой-нибудь 0day эксплойт sshd, который не успеет обновиться в системе раньше, чем злоумышленник использует его именно в отношении моего скромного сервера? Или страхуемся от утечки ключа ssh? Ну так кто его добудет — то с большой долей вероятности он там же подсмотрит и настройки port knocking'а или что там ещё прикручено.
— авторизации в ssh только по ключам;
— установки fail2ban для недопущения DoS'а и переполнения логов.
Два пришедших в голову сценария атаки, при которых port knocking поможет, а эти две меры сами по себе нет, я выше в комментарии привёл: атака через эксплойт sshd и утечка ключа (но без информации о настройках port knocking'а).
Мне кажется, что риск этих сценариев в реальной жизни исчезающе мал. Но было бы интересно услышать, если я ошибаюсь и ещё о чём-то не подумал.
P.S. Ну вот разве что если речь идёт о какой-то труднообновляемой железке (роутер с прошивкой от вендора, обновления которой надо мониторить и накатывать вручную), где sshd древней версии имеет шанс залежаться надолго, — тогда, может, есть смысл перестраховаться.
65к портов перебираются на раз два.
Это очень просто и быстро.
Если только одновременно не перебираются IP-адреса.
Переносишь на другой порт — находят быстро, отключаешь пинг, перестают находить. Есть сервера, несколько лет стоят, светят RDP, но не брутятся. Но, не все, конечно, некоторые находят все равно.
Но! как минимум пороль подбирает не каждый школьник.
отрезать себе пинг — это тоже прям очень "умно", в частности, когда будешь заниматься сетевой диагностикой
Типичный security through obscurity (((
В статье и в этой ветке комментов обсуждается выставленный на весь интернет SSH и раз обсуждение зашло в сторону того, как лучше этот SSH спрятать — я поделился своим опытом.
Я же не утверждаю, что применив данный способ можно забыть про фаервол или VPN, Fail2ban, авторизацию по ключам и т.д.
— port knocking (если настройки оного не утекли вместе с ключом);
— 2FA (это ещё лучше, но создаёт неудобства в повседневном использовании).
В зависимости от вероятности угрозы, тяжести возможных последствий, степени создаваемых неудобств, стадии развития собственной паранойи :) и пр. — можно выбрать для себя подходящее сочетание защитных мер.
А если используется что-то вроде https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Multiplexing#Multiplexing_HTTPS_and_SSH_Using_sslh?
Это да, но ты пойди до него еще доберись, если там стоит какой-нибудь CHAOS+tarpit и сам ссш на высоких портах. От ботов хватает даже банального правила на DROP + перевешивания на высокий порт. А не от ботов — алерт на auth логи.
В любом случае, я что-то по итогам дискуссии склоняюсь в пользу выборочного 2FA вместо port knocking…
Черт бы с ним с юзкейсом — 100500 лет как придумали port knocker. Тот же 80,21,53 пропускают все и всегда.
Или, если уж так нужно — то только по сертифткатам без паролей.
Или как всегда — пока петух не клюнет? :)
И на старуху бывает порнуха.
Я вон клиенту наворотил защит, но при очередной манипуляции в скрипт iptables закралась запятышка. И iptables свалился в default (а я не заметил и не проверил), когда почти всё почти всем.
Очнулся только когда через пару месяцев хостер тонко намекнул своим сканером, что у меня открыты уж слишком уж неприличные порты.
А так — упавшее и быстро поднятое упавшим не считается.
Просто открытые порты это еще мелочь. Вчера вот меня попросили поднять один проект из бекапа (интернет-магазин, который уже прекратил своё существование, но дабы не были нарушены права потребителей, саппорт еще осуществляется, и для этого нужен доступ к истории продаж). Так вот при попытке поднять сайт я получал некую ошибку и решил её загуглить. Как же я был удивлен, когда я в гугле нашел в открытом доступе исходники, с паролями к разным ресурсам и прочее (хостер сделал basic http-auth на порт 80, но на порту 443 по нешифрованному http-протоколу (!) было доступно содержимое всего в открытом доступе, включая папку .git и пароли). Это, к счастью, была лишь dev-версия, т.е. к продашн данным оттуда было не добраться, но показательно. Судя по всему, исходники были в открытом доступе года 3-4 и при этом постоянно актуализировались.
Может быть кто-то с хабра подскажет как снять с адреса черную метку
Скорее всего — никак.
Любой удод может настучать в DNSBL или нечто подобное — и потом запаритесь доказывать, что не верблюд (особенно если нет правильного обратного резолва (а кто ж Вам его даст)).
Есть ещё вменяемые провайдеры, которые дают возможность править записи ptr. Только из-за этого на домру и перешёл.
В общем писали заяву сами по электронке + тикет в суппорт, они тоже писали, 3 месяца ожидания и удалили подсеть из списка.
P.S. Ну и да, файрволл и fail2ban я сам иногда ленюсь сразу настраивать, да и 22 порт, грешен, иногда открытым оставляю, — но «PasswordAuthentication no» в sshd_config — это чуть ли не первый шаг для любой linux железки в домашнем хозяйстве.
Всё верно, мой почтовик раньше влипал в базы dnsbl, в результате иногда хожу по спискам этих баз, тестирую почтовик, снимаю старые баны, проверяю на возможные уязвимости типа опенрелеев. Уже много лет никпких проблем. Самописный скрипт анализирует логи нескольких программ на попытки подбора паролей и блокируе ip (скрипт писался ДО того, как узнал про fail2ban — меня мой скрипт устраивает)
Словари гуглятся легко.
В качестве теста на ~30 серверах я пробросил 22-й порт на сторонний сервер и там выставлял разного рода «словарные» пароли, наблюдая за брутфорсами.
В среднем ожидание взлома пароля из списка www.iau.org/public/themes/naming_stars занимало 1-3 недели.
Числовой, например 6227020800 (он тоже входит в словари) около суток.
1 — запрет логина в SSH по паролю
2 — настройка входа в SSH по ключам
PS Чуть спокойнее когда 22 порт светится только на IPv6, там пока «тишь и гладь», но не думаю что это надолго…
Тем что пароль передается на удаленный сервер в открытом виде и если он (сервер) скомпроментирован, будет скомпроментирован и ваш пароль при логине. Если вы его используете на нескольких серверах — будет получен доступ и к ним. Если же вы генерируете пароли для каждого сервера — то в практическом плане ключ удобнее тем что он безопасно может быть один для доступа на многие сервера.
пароль передается на удаленный сервер в открытом видеВ SSH в первую очередь поднимается защищённый канал — процесс аутентификации выполняется внутри него.
Ssh передаёт пароли в открытом виде???
А вот ключ в этом отношении безопасен. Один ключ для большого количества серверов это безопасно и хорошо.
Ну и как бы то ни было — это не защита в полном смысле этого слова, а попытка спрятаться. Т.е. работает не со 100% вероятностью, а просто с очень большой.
Но, там где важна конфиденциальность даже маленькая вероятность провала неприемлема, поэтому трудно согласиться, что IPv6 полноценная замена VPN.
Представим ботнет, состоящий из десяти миллионов зараженных компьютеров, каждый из которых сканирует за секунду сто IP-адресов; предположим, что все компьютеры, входящие в ботнет, включены постоянно и имеют доступ к интернету и по IPv4, и по IPv6. Сканирование по одному порту (например, 22) всего адресного пространства IPv4 заняло бы у такого ботнета меньше пяти секунд. Сканирование же всего адресного пространства IPv6 заняло бы у такого ботнета время, в десять с лишним тысяч раз большее, чем миллиард миллиардов лет!На IPv6 сканирование теряет смысл.Ну это пока «каналы слабые».
Итого чистый остаток, почему есть смысл использовать IPv6 вместо VPN в таких случаях: спрятаться от попыток перебора и брутфорса, во-первых это снижает нагрузку, что важно, если у вас не сервер с топовым Xeon, а дохлый MIPS на 300Мгц в роутере. Так что да, это в первую очередь удачная попытка спрятаться. Второе — любой VPN сильно снижает доступность хоста: ситуаций с NAT, проблем с кривым MTU и зарезанным ICMP в абстрактном Мухосранске — выше крыши, и вот уже ваш VPN просто не завелся или работает криво. С другой стороны, и IPv6 есть не везде и не всегда и не получится полагаться исключительно на него.
Второе — любой VPN сильно снижает доступность хоста: ситуаций с NAT, проблем с кривым MTU и зарезанным ICMP в абстрактном Мухосранске — выше крыши, и вот уже ваш VPN просто не завелся или работает криво
не преувеличивайте масштаб проблемы. L2TP/PPTP — да, могут не работать, в зависимости от провайдера. Но какой-нибудь Cisco AnyConnect — не видел еще, чтобы он не "пробивал". Ну, и VPN дополнительно решает проблему доступности сетевых ресурсов из офиса пачкой (сервера, принтеры и пр.), создавая при этом проблему маскирования ресурсов в локальной сети пользователя, если он недостаточно удачен и произошло пересечение адресов. Плюс зачастую можно запретить сплит туннелирование — это небольшой плюсик к безопасности, в первую очередь, в головах ИБшников.
Все эти fail2ban и port knocking только жить мешают. Требуется нетривиальная настройка клиента и возможны проблемы в случае неверной настроки.
С чужого планшета слазить сложно становится. А такое нужно всегда срочно и внезапно.
Приватный ключ с паролем в любом облаке по вкусу. Это надежно, безопасно и доступно всегда и с любого устройства. Понятно что пароль от облака и пароль от ключа должны быть разными.
Я бы постыдился такое на публику выносить.
Для школьника настраивающего свой первый ssh сервер это простительно. А вот для «Руководитель отдела разработки ПО» уже нет. У вас же там сервера какие-то стоят. Инфраструктура какая-то есть. На них разработчики ходят. Админы или деопсы управляют всем этим. ssh ключи должны быть везде. Или везде пароли стоят… Тогда мне страшно за ваши сервера. Я бы вышел даже на праздниках такое срочно переделать. Разломают же все. Просто потому что могут.
язвительный вы какой-то.
Я бы постыдился такое на публику выносить.-у всех свои минусы, а ТС не постыдился (;
Писать на весь мир «Я некомпетентен в своей профессиональной области». Такое себе…
Видимо поря завязывать с комментариями. Хабр становится странным. За указывание на некомпетентность человека в области которую он сам обозначил как свою профессиональную идут массовые минусы в карму. А за абсолютно неграмотную технически статью идут плюсы.
В первых 2 фразах статьи должно быть «Поставить вход по ключам. Переставить скомпрометированную систему» А дальше можно в песочнице разбираться что там наставили. На реальной скомпрометированной системе ничего чистить не в коем случае нельзя.
Подсказка — это 92 бита энтропии. Мне кажется, вероятность того что найдут уязвимость и сломают с её помощью гораздо выше, но в этом случае и ключ не поможет.
Есть у меня клиент, у него 5 серверов (там wp, crm и всё такое), от ключей отказался ибо для него это сложно (сам он далек от IT, ssh фактически нужен только для работы по sftp и на тот случай если меня трамвай переедет и нужен будет доступ кому-то ещё), файрволл не канает потому что он постоянно ездит по всему миру (да, vpn для него тоже за гранью), поэтому поставил вышеупомянутые 16-ти символьные случайные пароли (благо password manager у него есть) — и математика мне подсказывает что в ближайшее тысячелетие их не сломают (даже если получат их солёные хеши, про онлайн я уже молчу).
С другой стороны, если у него на компе троянец заведётся или кто-то ручками влезет — то и ключи не спасут.
fail2ban, кстати, почти бесполезен — по моим наблюдениям, сейчас ломятся с разных адресов на одного пользователя с разными паролями (словарными, разумеется), атакующие IP повторяются в лучшем случае через сутки и делает максимум две попытки.
На практике это реализуется генератором паролей и проверкой сложности (и словарей) при смене (или начальном выборе) пароля.
К сожалению, в мире IT есть не только ssh, так что от паролей никуда не деться, причём доступ по ssh может быть гораздо менее опасным чем доступ к другим сервисам, куда ключи ещё не доехали.
Правильный пароль сильно неудобнее ключа.
Первая и вторая части Вашего сообщения, ну, никак не связаны
Ключ к ссш — намного удобнее и безопаснее, чем пароли. Та же работа с гитом, как пример. Либо ты зашиваешь пароль в настройки Гита (и он там болтается плейн текстом), либо надо тащить системную ключницу. Единственное, что реально удобно в гитлабах и прочем — это многоразовые токены (оно по сути как пароли работают).
Безопаснее — только в описанных вами случаях (git & co, т.е. случаи когда нужно избежать shared secret на другой стороне), если же речь просто про вход терминалом — то легко сделать непробиваемый и легко запоминаемый пароль с энтропией от 100 бит и выше (фраза с модификаторами — ни словарём, ни брутом не взять, при этом её даже в блокнот можно записать практически ничем не рискуя), а с точки зрения утечки/потери или маски-шоу пароль и ключ ничем не отличаются.
Ну нет же. Ключ может храниться на неизвлекаемом носителе. Например тот же TPM. Пароль надо вводить при каждом логине на сервер, ключ может быть расшифрован один раз и храниться ssh-agent'ом. Один ключ может безопасно использоваться для входа на несколько серверов, пароль — нет. Ваш пароль передается на удаленный серевер и легко может быть извлечен рутом на сервере куда вы логинитесь (как пример — специальный pam модуль). Единственный плюс пароля — отсутствие необходимости хранить ключ.
К тому же, при условии что у каждого сервера уникальный пароль (как и должно быть) — возможность его извлечения несущественна, он не даст атакующему ровно ничего (он и так уже рут).
Для кровавого (и не очень) энтерпрайза ситуация меняется — там удобства ключа проявят себя в полную мощь, но мир состоит не только из энтерпрайзов, Васей в нём довольно много.
Есть, кстати, один интересный нюанс — с небольшой модификацией ssh-keygen ключи могут быть сгенерированы с помощью хэша от произвольного пароля (используя его как seed), таким образом позволяя всегда их «носить с собой», т.е. их можно восстановить имея только генератор (и свой супер-пароль), без необходимости хранения самих ключей.
Очень интересный комментарий по делу, спасибо.
Могу только добавить, что в кровавом Энтерпрайзе очень странные понятия об ИБ. Ключи запрещены, пароли разрешены, при этом есть правила по сложности паролей, их неповторяемости и ротации каждые хх дней. Выглядит в нынешние времена как дикость.
Либо не все Энтерпрайзе одинаково полезны )))
Впрочем, в большинстве случаев в СБ находятся вовсе не специалисты в области IT безопасности, отсюда и «дикость».
Театр безопасности какой-то. "Троянский" ключ возможен в любом случае, независимо от регламентов СБ. Вот они по-отключали ключи на серверах, а я включил и свой прописал. И кто мне помешает?
Если же за серверами следить — то внезапно оказывается, что отозвать ключ проще, чем сменить пароль: новый пароль надо ещё как-то сообщить всем, кому нужен доступ, а отозванный ключ — это просто удалённая строчка в файле.
Есть же типовой сценарий: Вот тебе ноут. Диск на нем шифрован. Ключ с ноута не не выносить. Ноут бери с собой. Потерял/украли срочно пиши/звони вот сюда в любое время.
Насчёт fail2ban согласен. Он скорее не помогает, а мешает. Плюс дополнительный компонент, в котором, внезапно, тоже бывают баги.
Всю защиту от брута можно сделать и настройками ssh демона, но тут надо не переборщить, чтобы случайно себе доступн не отрезать, когда будут ломать
Потому что пароль можно запомнить и ввести с клавиатуры, когда находишься далеко от дома, а ключ — вряд ли.
А для веб логина есть связка ключей в браузере ) или где она там обычно у вас )
"Критикуешь — предлагай", а не, как в том анекдоте, "мыши, станьте ёжиками". Вот Вам use case: нужно входить на домашний компьютер по SSH с телефона. Как Вы предлагаете "пользоваться ключами"? Запоминать многосимвольные случайные ключи? Желаю удачи. Хранить ключи на телефоне? Тогда некоторые любопытные сотрудники аэропорта автоматически имеют доступ и к Вашему компьютеру. Хранить на телефоне запароленные ключи? Тогда, когда в Вашем телефоне садится батарейка/разбивается экран/он падает в туалет, Вас ждёт ещё один неприятный сюрприз. Жду Ваших предложений.
Ничего не понимаю.
- Ничего не мешает иметь по ключу на каждое устройство, с которого заходите, — потом их так проще менеджить.
- Ничего не мешает иметь на телефоне ключ с паролем. Сперли телефон — ну, ок, ключ-то под паролем? А на рабочей машине тот же ключ без пароля или вообще другой ключ (п.1)
- Пароль — ненадёжен априори. Его могут подсмотреть через плечо, может стоять кейлоггер, или что ещё.
- Я уж не говорю, что в идеале доступ должен быть через ВПН или промежуточный хост (proxy, bastion, jumphost)
Вы специально пропустили следующий случай, или просто не обратили внимания?
- Ключ от домашнего компьютера на телефоне, под паролем.
- Вы находитесь далеко от дома (напримиер, в аэропорту) и Вам очень нужно вот прямо сейчас зайти на домашний компьютер (например, потерялся посадочный талон и нужен с него код, ну или сами придумайте зачем).
- Телефон по каким-то причинам недоступен (села батарейка, случайно уронился в унитаз и промок, украли).
Ваши действия?
Спасибо, что повторно разъяснили.
У меня попросту не возникнет такой ситуации, что СРОЧНО нужно зайти на домашний компьютер. Потому что ноут всегда с собой. А если я недоступен… То недоступен. С тем же успехом там где Вы находитесь может вообще оказаться мобильного интернета или бесплатного вайфай.
Я уж не говорю о том, что домашний компьютер напрямую по ссш из интернета — дичь какая-то. У меня так вообще дома сейчас прямого внешнего айпи нет… И я еще 10 раз подумаю — стоит ли провайдеру за него доплачивать.
Ну, и если очень надо — родственники дома есть…
Так что какой-то странный кейс.
При нормальном подходе нет никакой разницы — дома комп или на работе, меры по защите одинаковые, дома даже проще обеспечить безопасность, ибо в офисе обычно больше лиц с непонятным уровнем доверия (приходящие курьеры, ремонтники, уборщики etc).
Опередили меня. Не вижу ни одной причины, почему если у человека есть ссш, то не перекатиться на ВПН.
Если же говорить о потенциальных 0day-уязвимостях, то VPN от них тоже не застрахованы, и на них тоже долбятся.
У меня попросту не возникнет такой ситуации
Попытка съехать с темы опознана и пресечена. Возникает такая ситуация, возникает — у меня, например, постоянно. Возможно, потому, что у меня не windows. Или потому, что у меня телефон не помойка, на которую я тащу всё подряд, а карманный терминал.
Потому что ноут всегда с собой.
Предпочитаю не рисовать у себя на спине большую жирную мишень для грабителей.
С тем же успехом там где Вы находитесь может вообще оказаться мобильного интернета или бесплатного вайфай.
В Тимбукту я пока не ездил.
Ну, и если очень надо — родственники дома есть
"Что знают двое, знает и свинья".
Но тогда возвращаемся к началу дискуссии: если ключ защищен паролем, то слабое звено в цепочке — опять же пароль. Это примерно как
— ключ от квартиры, где деньги лежат, кладётся в мини-сейф, защищённый всего лишь 4-значным кодом. При определённой сноровке взломщик может код подобрать.
— так зачем вобще нужно это лишнее звено?
Я тут статью вспоминаю про то что ключ зашифрованный паролем аналогичен ключу без пароля. Не знаю насколько она актуальна, но все же лучше этот ключ зашифровать дополнительно. https://habr.com/ru/company/wirex/blog/419829/
Там не технические доводы в статье, а больше — социальные.
В общем, с чем соглашусь — обычно шифрование ключа паролем бессмысленно и реально безопасности не добавляет.
Давайте честно — то что у меня не возникает такой проблемы — не означает, что у других ее нет. И верно обратное — то что у Вас какой-то специфичный кейс — не означает, что у остальных все так же.
Как этот надуманный пример с севшим телефон. В нынешнем мире вообще очень стрёмно с разряженным телефоном. Та же 2FA для облачных сервисов
Заходишь с нового места или устройства… И приплыли.
Я уж не говорю о том, что, да, действительно, для серьезных применений нужно, наверное, иметь несколько телефонов. Один — для Фейсбуков, контактиков, а второй — для банк-клиентов, ссш, и прочего нужного и важного.
По поводу впн вместо "голого" ссш домой коллеги высказались. Действительно, как ещё один уровень защиты — почему нет? И не нужно 'отмазываться', что у вас там роутера нет или провайдер блочит — все решаемо.
"ещё один уровень защиты — почему нет? "
Ещё одна точка отказа — почему да?
У вас точка отказа ровно одна — роутер, через который интернет заведен в квартиру. Что с впном, что без.
Вот, допустим, по какой то причине упал VPN на этом вашем сервере. Диск переполнился внезапно, телеграмкомнадзор решил, что vpn без освященного им же сертификата быть негоже, 10050 причин может быть. Ваши действия? Дальняя дорога? Черный ход в обход VPN?
То же самое будет и для ssh. Кончилось место? Под непривилегированным пользователем тупо не залогиниться (на самом деле — там ещё много переменных, поэтому я не буду утверждать, что корелляция 100%). И?
"То же самое будет и для ssh."
Не совсем. Под root можно хотя бы попробовать залогиниться и разобраться с ситуацией.
Отличный бедпректис — оставлять рутовый доступ по ssh. Даже обсуждать не хочется.
Можете привести хоть один весомый аргумент «против» (не считая «случайно rm -rf /» и прочих глупостей из этой серии) для логина как рут с ключём?
Вопрос не праздный, потому что нигде в обсуждениях вопроса «Почему нельзя логиниться как рут?» не приводят никаких аргументов (кроме уже упомянутого «случайно сделаете глупость» — но глупость можно сделать и в sudo).
Из очевидных вещей:
В многопользовательской среде сложнее определить, кто заходит под рутом — персонализированные учётки намного выгоднее и ими в каком-то смысле проще управлять, чем свалкой ключей у рута в authorized_keys.
Второй аргумент в том, что если root включен, то надо подобрать только ключ/парольную фразу, а не пару имя пользователя+пароль/ключ.
Третья история, как Вы верно заметили, не всегда нужны админские права — и тогда проще сразу ходить пол юзером, а не сразу под рутом. Про принцип наименьших привилегий ведь все слышали?
Дальше думать надо )
Если мне нужно что-то сделать как рут (а в большинстве случаев это так и есть) — я логинюсь сразу как рут, в почти всех системам мне там делать нечего как обычному пользователю. Поскольку я делаю это исключительно со своего компа или vpn (как и мои коллеги) — то выяснить кто там был — не проблема (но это бывает нужно чуть чаще чем никогда).
По поводу подбора я уже не раз высказался выше — хороший пароль или ключ эту проблему решают, особенно если сервер не смотрит в мир.
Разумеется, там где у меня есть свой аккаунт, и когда мне не нужны админские права, я не логинюсь и не работаю как рут, но это всего пара моих собственных систем — остальные — клиентские (причем клиенты, как правило, не имеют рутовских прав).
Это просто иллюстрация того что bad practice не всегда bad — всё зависит от конкретных условий. Могу лишь заметить что за 20 с лишним лет это не привело ни к каким проблемам — ни у меня, ни у коллег, ни у клиентов.
"если root включен, то надо подобрать только ключ/парольную фразу"
Всего лишь подобрать ключ. Думаю, есть способы быстрее и дешевле. Например, купить датацентр вместе с сервером, куда нужно получить доступ. :D
Второй аргумент в том, что если root включен, то надо подобрать только ключ/парольную фразу, а не пару имя пользователя+пароль/ключ.
А по-нормальному — надо подобрать логин юзера + аутентификацию юзера + пароль su (подбор которого можно начать только после того, как первые два фактора уже сломаны и не для любого, а для wheel-аккаунта).
В случае в логином юзера по ключу третьим фактором может быть пароль sudo (который не подойдёт в качестве второго по причине запрета логина по паролю).
надо подобрать логин юзера
Не надо. Это публичная информация. Если даже у вас не так, то лучше все равно исходить из того что логин все знают. Он нигде особо не скрывается.
пароль su
И эта часть не работает в реальной жизни. sudo по жизни без пароля для всех у кого права на него есть. Просто из соображений удобста. Люди не любят постоянно вводить сложные пароли, а от простых толка нет.
пароль можно запомнить и ввести с клавиатурыg2857z1KkOzi78qgtyzskhseO2KY20vwgJFyeEZe6nikmSTaty2ME0FawZgeOaez
Запомните? :-)
correct battery horse stapleПодбирается по словарю.
Подбирается по словарю.
В английском языке около 1,4 миллиона слов — примем для простоты (c большим запасом), что ровно 210. Четыре слова (с сохранением порядка следования) — 240. Подбирайте!
Помогает также переключение языков — набирайте русские слова в английской раскладке (ghfdbkmyj kjiflm ,fnfhtz chrtgrf) — ещё несколько бит в сложность прямо с потолка (я надеюсь, что Вы умеете в слепой метод?)
Неудобно (особенно если надо быстро несколько сессий на разных серверах открыть — утомишься переключаться на authenticator и обратно вводить коды).
Не позволяет использовать средства автоматизации, работающие по ssh (тот же ansible).
Не очень универсально (насколько я понимаю, реализовать это, скажем, на Микротике невозможно).
Не даёт очевидных преимуществ перед просто использованием ключа в плане защиты от атак.
Хотя, наверное, в ряде случаев есть смысл перестраховаться и делать ключ + 2FA. Например, если в сохранности ключей у тех, кому они раздаются, есть обоснованные сомнения.
Не позволяет использовать средства автоматизации, работающие по ssh (тот же ansible).
ничто не мешает держать дополнительный ssh-сервер внутри периметра, который уже не будет закрыт 2fa(2fa на джамп-сервере или vpn). или, например, использовать ансибл в роли псевдоагента, т.е. на каждом хосте проливать локалхост ансиблом.
Не даёт очевидных преимуществ перед просто использованием ключа в плане защиты от атак.
в случае компрометации ключа можно получить моментально контроль над всеми хостами, где прописан ключ.
в случае с 2fa, слитые ключ или парольная фраза не такая уж и проблема, 2fa остаётся не скомпрометирован, можно неторопливо заменить пароль/ключ.
Не даёт очевидных преимуществ перед просто использованием ключа в плане защиты от атак.
даёт, например, ключ можно сфорвардить на зараженном сервере и получить доступ к другим хостам.
Например, если в сохранности ключей у тех, кому они раздаются, есть обоснованные сомнения.
напоровшись на зироудей в установленном софте даже человек, в котором нет сомнений, может запросто отдать свой ключ.
ps не пользую 2fa помимо работы(например, дома), но одобряю.
Но хотелось бы в этом варианте компромисс между удобством и безопасностью всё же немного сдвинуть в сторону удобства. Отсюда вопрос — а никто не знает работающего рецепта настройки 2FA так, чтобы он использовался только для доступа с неизвестных IP-адресов, а для один раз авторизованных — в дальнейшем хватало просто ключа? Сделать два SSH-сервера: один с 2FA, а другой — с ограничением по IP, — очевидно, но тоже неудобно.
Насколько я помню — можно даже в рамках одного sshd_config делать разные группы хостов и, возможно, что назначать на них разные алгоритмы или параметры авторизации/аутентификации
Отсюда вопрос — а никто не знает работающего рецепта настройки 2FA так, чтобы он использовался только для доступа с неизвестных IP-адресов, а для один раз авторизованных — в дальнейшем хватало просто ключа?
Это поведение по умолчанию!
То есть если вы заходите не по ключу, то у вас спрашивают пароль и код, а если по ключу — ничего.
Какие удивительные вещи происходят. Статья о том как кому-то сбрутили простой пасс и залили типовую малварь, но при этом с таким заголовком, как будто в ней проведено какое-то расследование мирового масштаба.
И комментарии под ней, на полном серьёзе что-то обсуждающие.
Надо мне наверно тоже написать статью о том как мне 12 лет назад подобрали ssh пароль "123" на пустом сервере и тоже что-то туда залили, и как я потом переустановил систему но уже не ставя таких паролей, может инвайт дадут.
— я не сразу поверил, что это относится к своему собственному NAS, а не, скажем, соседа, который попросил разобраться с неполадкой.
А заголовок статьи огненный, конечно — «веерная атака на подсистему SSH» — это внушаетъ! Я вот купился, например, и даже прочитал до конца статьи, не веря, правда, своим глазам.
> Используйте безопасные пароли для всех системных пользователей
Очень странная рекомендация. Я бы предложил «запретите любой ssh вход по паролям. требуйте наличие надежного ключа».
Сегодня мой внешний IP был заблокирован в сервисе IVI с сообщением
А зачем IVI делает такие блокировки?
как снять с адреса черную метку?
Два способа.
1) Ленивый. Ничего не делать. MaxMind периодически сканирует все хосты интернета (ха!). Скорость не раскрывается, но она в целом приемлема. Как только повторно просканируют — удалят метку из своей базы, а далее все клиенты MaxMind (включая ivi) получат обновление, и — вуаля!
2) Активный. Как уже было замечено в комментах — написать в поддержку MaxMind «Я устранил анонимный прокси, сделайте на мой IP (X.X.X.X) ускоренное сканирование». Они на такие просьбы обычно положительно реагируют. Дальше механика та же — скан, обновление БД.
И есть ещё одна проблема: MaxMind бесплатно не показывает статус IP адреса. Но можно воспользоваться чем-то другим. Например, www.ipqualityscore.com/free-ip-lookup-proxy-vpn-test/lookup
Тайная жизнь Linux сервера или веерная брутфорс атака на подсистему SSH