Comments 42
Я подведу итог обсуждения по этой ветке:
Вы сформулировали вопрос (сомнение в полезности port knocking при использовании ключей, в т.ч. для авторизации по ssh) в очень общем виде. Далее заявили, что ключи не ломаются в принципе. И хотели доказательств успешного взлома ключей. Когда я предоставил доказательства взлома ключей при определённых условиях - вдруг изменили позицию, заявив, что любой ключик стоит менять хотя бы раз в год (зачем, если ключи не ломаются в принципе - не ответили). Также сказали, что в современной Убунте RSA deprecated уже как много лет - отказавшись уточнять сколько именно лет и проигнорировав факт, что в ssh-keygen на Ubuntu 22.04.5 по-умолчанию генерит RSA ключи. И моё предложение доказать фактами, что ключи не взламываются в принципе проигнорировали.
Отказались сообщить о своём опыте организации безопасной ИТ-инфраструктуры
Знаете , как устроены внутренние сети у Гугла и у Яндекса и у неких "больших ребят". Но, отказываетесь сообщить источник своей информации.
Заявили, что port knocking от 0day не спасет точно и защита от такого выглядит по другому. Отказавшись представить: как по-вашему должна выглядеть эта защита и аргументировать свою позицию.
Обладаете знаниями о стоимости и наличии 0day уязвимостей (1, 2). Но, неоднократно, отказываясь предоставить источник и подтверждение своим словам (1, 2, 3)
Считаете port knocking - Security through obscurity, хороший признак провального решения. Которое нельзя использовать. Проигнорировав довод, что port knocking сам по себе не ослабляет других видов защиты.
Стандартный вопрос к таким статьям.
Есть типичный ssh или vpn. Открытый на весь мир. Софт обновляется своевременно. С доступом по ключикам. Вы можете объяснить как хоть что-то может повысить его защищенность? Зачем что-то кроме этого стандартного, известного всем и совместимого со всем решения с доступом по ключу что-то еще делать?
Какой из двух вариантов безопаснее?
Злоумышленник знает, что у вас что-то есть, причем знает конкретно что именно, но не имеет доступа. Аналогия реальной жизни: вы олигарх с 10 млрд долларов, потенциальные злоумышленники (а то и широкий неопределенный круг лиц) знают кто вы, сколько у вас денег, где они лежат и где вы живете. Но деньги в безопасности, потому что у вас надежная охрана, заборы и тд.
Злоумышленник не знает, есть у вас что-то или нет. Аналогия с реальной жизнью: у вас есть 10 млрд долларов, но об этом никто не знает и как следствие никому вы не интересны.
В случае с п.1 злоумышленнику остается решить конкретную задачу, пусть даже на нее уйдет время.
В случае с п.2 злоумышленник не знает, что делать, и не понимает, а нужно ли что-то делать и стоит ли игра свеч.
Можно без аналогий? Котенку с дверцей они не нравятся.
Пусть знает что вот тут есть ssh с доступом по ключикам и решает. Не возражаю. По вашей оценке это сколько у него времени займёт?
Security through obscurity это хороший признак провального решения. Которое нельзя использовать.
А что, если...
в виду человеческого фактора в какой-то момент авторизация по ключу слетит и превратится в стандартную по паролю (с конфигом что-то накосячили и не заметили)
в ssh появится 0-day уязвимость, которой воспользуются злоумышленники, а обновление, которое могло бы закрыть ее, вам прилетит с опозданием
мало ли чего еще произойдет
Security through obscurity это хороший признак провального решения
Признак провального решения - полагаться только на один-единственный уровень безопасности (в данном случае только на механизм который есть в самом ssh)
Простите, но вы не пробовали тестировать свои конфиги? Без тестирования можно такого натворить что страшно становится. На тестовом окружении, например. И катать на прод через какой-нибудь Salt (или что там сейчас модно) без ручных действий вообще?
0-day в ssh я помню одну. И та была очень сложна в реализации и практических взломов через нее я не помню. Вероятность что тому у кого есть доступ дадут по голове и заберут ключи-скрипты и все что надо гораздо выше.
мало ли чего еще произойдет
Оценить вектора атак это разумно. От неверного конфига можно защититься процессом выкладки конфигов через Salt с двойным или даже тройным аппрувом. Конфиги катают настолько редко, что это работе не помешает.
От 0day полноценной защиты нет. Есть всякие анализаторы паттернов поведения всех в вашей сети. Но это сложно и нужно далеко не всем. Плюс такие 0day стоят таких денег что хватит мало у какого атакующего. Следим за публикуемыми уязвимостями, своевременно обновляемся. Защита выходит нормальная.
Что так еще по векторам атаки?
Признак провального решения - полагаться только на один-единственный уровень безопасности (в данном случае только на механизм который есть в самом ssh)
Вы же знаете что и у Гугла и у Яндекса доступна вся внутренняя сеть через VPN? По ключику, конечно. Я не могу их назвать глупыми или ничего не понимающими в безопасности.
Аргумент не принимается.
Вы же знаете что и у Гугла и у Яндекса доступна вся внутренняя сеть через VPN?
Полагаю там VPN +еще что-то (авторизация в конкретных сервисах например) - это уже не то же самое что только один VPN.
Кроме того, везде где я работал например, доступ к VPN идет строго через 2FA, а это уже не то же самое что просто VPN с ключом, торчащий на весь мир. Плюс доступ к машинам внутренней сети был разрешен только по белым спискам адресов (в т.ч IP адреса сервера VPN). Кажется это совсем не то же самое о чем вы писали в своем первом комменте (голый ssh порт на весь мир).
То есть получаем:
Сам VPN доступен с любого IP (имеется в виду входной сервер, к которому подключается сотрудник со своего рабочего компа)
В VPN настроена 2-факторная авторизация
Доступ к самим машинам внутренней сети есть только c IP-адреса(ов) VPN-сервера(ов)
В одной конторе помню по шапке давали одному девопсу, когда он просил разрешения на одной машинке открыть 22 порт на весь мир, то есть чтобы был доступен даже без VPN. И правильно делали))
Простите, но вы не пробовали тестировать свои конфиги? Без тестирования можно такого натворить что страшно становится. На тестовом окружении, например.
В вашем случае это получается security by correctness. То есть вы полностью полагаетесь на то, что ваша конкретная софтина настроена и работает корректно.
Полагаю там VPN +еще что-то (авторизация в конкретных сервисах например) - это уже не то же самое что только один VPN.
Это в любой схеме так. Я именно про доступ в сеть. Дальше все как обычно.
Кроме того, везде где я работал например, доступ к VPN идет строго через 2FA
Это так не работает.
В теории можно привязать сертификат к ноуту. Но на практике он оттуда вытаскивается в пару кликов. Защита чисто административная. Считайте что доступ просто по сертификату.
В одной конторе помню по шапке давали одному девопсу, когда он просил разрешения на одной машинке открыть 22 порт на весь мир, то есть чтобы был доступен даже без VPN. И правильно делали))
А зря. Если эта машинка нужна для починки упавшего VPN, то логично ее открыть на весь мир по SSH. Чтобы потом двери не ломать как в недавней истории.
Естественно с полным логированием сессий и объяснениями с безопасниками после каждого логина на нее. Если можно, то и доступы в сети ей порезать.
В вашем случае это получается security by correctness. То есть вы полностью полагаетесь на то, что ваша конкретная софтина настроена и работает корректно.
Это вроде нормально? Что VPN что SSH специально вынесены отдельно и перенастраиваются максимально редко и максимально аккуратно. Аналогично их код смотрят уже десятилетия, вероятно что там что-то не так мизерная.
Это вроде нормально?
Ненормально полагаться только на один механизм.
Поэтому везде реализуют путем миксования/наслоения нескольких вариантов безопасности. Каждый имеет свои плюсы и минусы, в совокупности риски снижаются.
То что VPN торчит на весь мир - это компромисс, необходимый для удаленной работы. Там где совсем нет удаленки, там и этого компромисса нет.
А так - не бывает на 100% безопасного инструмента. А во сколько слоев оборачивать доступы - каждый решает сам, в зависимости от конкретных рисков, ценности защищаемого, удобства пользования и тд.
Кто использует? Я вам совершенно уверенно говорю как работают доступы у больших ребят. Против них могут и 0day и все что угодно использовать. Миллион долларов это приемлемая цена.
У них кроме этого есть анализаторы поведения и административные методы привязки ключика к ноуту.
Привязать ключик к железке вы тоже можете примерно таким же способом как они. Зашифруйте диск на ноуте и поставьте пароль/отпечаток на вход. И не копируйте ключ никуда. Бекап ключика можете хранить в архиве с длинющим паролем в облаках по вкусу. Оно так же не ломаемо. Будет прямо как у больших.
А так - не бывает на 100% безопасного инструмент
Поделитесь кейсами успешного взлома ключей? Раз там не 100 процентов, значит есть способ который вы знаете.
У них кроме этого есть анализаторы поведения и административные методы привязки ключика к ноуту.
Ну то есть кроме самого VPN у них еще что-то есть - в данном случае анализаторы поведения, которые среагируют на аномалии соответстующим образом. Соответственно они не полагаются только на сам vpn. У них защита впна ПЛЮС еще что-то.
У кого-то анализаторы поведения, кому-то может быть проще fail2ban поставить, а кому-то может показаться приемлемым метод указанный в этой статье. Кто-то обмазывается всем этим добром по-максимуму и еще алерты себе ставит и/или нанимает целый отдел мониторинга и дежурных) А кому-то ничего этого не нужно.
Поделитесь кейсами успешного взлома ключей?
Соц инженерия, не?
У кого-то анализаторы поведения, кому-то может быть проще fail2ban поставить, а кому-то может показаться приемлемым метод указанный в этой статье. А кому-то ничего этого не нужно.
Безопасность так не работает.
Есть типовое решение - ключик. Он не ломаем техническими методами в принципе. Вот прямо вообще никак. Если считаете что это не так, прошу пруфы. Иначе про технические методы атаки на сервер забываем.
Можно ломать людей. Это как раз социнженерия.
Соц инженерия, не?
Вот от социнженерии анализаторы и могут помочь. При этом ваш скрипттик лежащий плейнтекстом на каждом ноуте не поможет никак. Его сольют моментально, быстрее ключа.
Атаковать можно ноут еще. Тут ваш скриптик не поможет вообще никак. Он плейнтекстом лежит блин. Ключики хотя бы защитить можно как-то.
Тем не менее: ключик + еще что-то. Я про что и говорю.
Нет ресурсов на анализ поведения - ограничиваем доступ по IP или ставим всякие штуки, которые снизят риски того что кто-то воспользуется украденным ключиком. О том и речь же.
Я привожу рассуждения в общем, а не защищаю конкретный способ из этой статьи. А так, плейнтекст скриптик это нехорошо, да. В голове держать тоже неудобно - но это все частности. Я лишь говорю общую идею: ключ плюс еще что-то. Это "еще что-то" разумеется тоже должно иметь достаточный уровень безопасности
Боже, о чем вы. Какое ограничение по IP в современном мире? С мобильного интернета люди ходят. Непойми откуда.
снизят риски того что кто-то воспользуется украденным ключиком
А почему вы считаете что плейнтекст скрипт украсть сложнее чем ключ? Считаем что ключ лежит в стандартном Кейчейне Макос. И как вы можете доказать что плейнтекст скрипт более защищен чем этот ключ?
Ага, безопасность она такая. Все доказывать надо. На авось ничего уже давно не работает.
Я привожу рассуждения в общем
Безопасность опять так не работает. Нет ничего в общем. Есть конкретные действия с конкретными аргументированными доводами от чего они помогут и в каких случаях. Вектор атаки, образ нарушителя, риски. Много скучных документов.
Вектор атаки сервер - неатакуемо техническими методами.
Вектор атаки ноут пользователя - скриптик украсть проще чем ключ. Бесполезно.
Вектор атаки пользователь - скрипт сольет быстрее ключа. Бесполезно.
Что я еще забыл?
Какое ограничение по IP в современном мире? С мобильного интернета люди ходят. Непойми откуда.
Где-то ходят, а где-то не ходят)
Нет ничего в общем. Есть конкретные действия с конкретными аргументированными доводами от чего они помогут и в каких случаях.
Вы сами привели один из общих принципов: security by obscurity. Есть еще два общих. Значит что-то общее есть?) И еще далее оно делится на конкретные действия, векторы и атак и прочее. От общего к частному.
А я вот про это, тоже абстрактно:
Multi-layered security refers to securing your organization’s data using a variety of security measures. The idea is that if hackers want to access the data, they have to break through multiple layers of security (e.g., physical, administrative, and technical), making it much more difficult to gain access
Что касается более конкретных примеров с описанием векторов атак и тд - это уже не ко мне, а к соответствующим спецам. Я лишь пришел сюда высказать свое мнение на вопрос "зачем что-то еще придумывать если есть ssh-ключ"
Везде ходят. Во всем крупном с хотя бы сотнями удаленных юзеров ходят.
Про ограничения по IP в таком контексте пора забыть уже несколько лет назад.
Вы сами привели один из общих принципов: security by obscurity. Есть еще два общих. Значит что-то общее есть?) И еще далее оно делится на конкретные действия, векторы и атак и прочее. От общего к частному.
Конечно есть. Но они не такие как вам кажется.
Второй известный принцип: "Я слишком туп чтобы писать или тем более изобретать криптографию"
Есть типовое решение - ключик. Он не ломаем техническими методами в принципе. Вот прямо вообще никак. Если считаете что это не так, прошу пруфы. Иначе про технические методы атаки на сервер забываем.
Я в комментарии привёл навскидку пруфы взлома ключей. Теперь давайте поменяемся ролями: с Вас - пруфы по 100% невзламываемости ключей. А то странно, что Вы ждёте доказательств, а сами ничего не доказываете.
Поделитесь кейсами успешного взлома ключей? Раз там не 100 процентов, значит есть способ который вы знаете.
А можно больше конретики? Или ожидаете развёрнутого анализа по всем существующим разновидностям ключей? Навскидку:
о возможности получения некоторых закрытых ключей для RSA и DSA (в т.ч. SSH и TLS) путём сканирования сертификатов TLS и ключей хостов SSH по всему Интернету;
о возможности встроить бэкдор в публичный ключ RSA (т.е. вопрос доверия к источнику генерации ключа).
P.S. И говоря о криптографии в целом - не стоит забывать о различных закладках, информация о которых периодически всплывает [1, 2]
Вы же ходили по своим ссылкам? А ключи пробовали генерить? На современной Убунте, чтобы далеко не ходить. Я думаю что нет, иначе вы бы знали что RSA deprecated уже как много лет. Насколько я помню он без специальных приседаний вообще не запустится на современный операционках (тут могу ошибаться).
Не доверять своему серверу это странно, бекдор встраивать в свой сервере еще более странно.
Закладки в современных Линуксах это такое себе. Требуется прямо пальцем в исходники показать чтобы в их существование кто-то поверил.
Вот как-то так выглядит дефолт генерация ключей. Стоит проверять как оно там сейчас перед тем как постить.
lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 24.04.1
LTSRelease: 24.04Codename: noble
ssh-keygen
Generating public/private ed25519 key pair.
Любой ключик стоит менять хотя бы раз в год. Если смена автоматизирована (что крайне рекомендую) то лучше раз в квартал. Новый ключик надо делать по свежим рекомендациям, а не скриптами которые отцы написали.
Другими словами: Вы в курсе о хотя бы некоторых вполне реальных угрозах относительно ассиметричного шифрования. Но, Вам очень лениво сформулировать сразу чёткий вопрос, на который ждёте ответ.
Любой ключик стоит менять хотя бы раз в год
А зачем? Вы ж ранее писали, что "ключи не ломаемы техническими методами в принципе." Передумали?
А ключи пробовали генерить? На современной Убунте, чтобы далеко не ходить. Я думаю что нет, иначе вы бы знали что RSA deprecated уже как много лет.
Много лет - это сколько?
Что скажете насчёт вывода команд ниже?
ssh-keygen на Ubuntu 22.04.5
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 22.04.5 LTS
Release: 22.04
Codename: jammy
$ ssh-keygen
Generating public/private rsa key pair.
+---[RSA 3072]----+
бекдор встраивать в свой сервере еще более странно.
Можете своими словами объяснить: какая модель угроз возможна по статье о бекдоре в ключе, которую я привёл? Побольше вариантов
В теории можно привязать сертификат к ноуту. Но на практике он оттуда вытаскивается в пару кликов. Защита чисто административная. Считайте что доступ просто по сертификату.
Хм, а из TPM разве серт и приватный подписанный ключ за пару кликов извлекаются?
Вы же знаете что и у Гугла и у Яндекса доступна вся внутренняя сеть через VPN? По ключику, конечно.
Откуда у Вас данные, что у них всё на ключах и больше ничего в плане безопасности нет? Раз знаете - расскажите: что там за ключи? С какими параметрами? Откуда данные, что "доступна вся внутренняя сеть"? Есть пруфы? Или предлагаете на слово Вам верить?
Плюс такие 0day стоят таких денег что хватит мало у какого атакующего
Во-первых: почему разработчик 0day и его пользователь - обязательно разные личности, связанные финансовыми обязательствами? Во-вторых, защитаться от могущественных организаций с целым арсеналом 0day уже не нужно?
От 0day полноценной защиты нет.
Поэтому не нужна никакая минимизация рисков, модели угроз... главное - ключик сгенерировать и порт наружу для всего интернета выставить, да?
0-day в ssh я помню одну.
А Вы прям про все 0-day в ssh осведомлены? Какой-то доступ ко всем появляющимся 0-day имеете? Можете гарантировать, что прям сейчас нет ни одного 0-day?
Поверьте от 0day в ssh ваш скриптик не спасет точно. Такая уязвимость стоит сильно за миллион долларов. Она дает доступ ко всему миру примерно. И защита от такого выглядит по другому. И то там скорее не защита, а минимизация последствий.
Кто будет использовать не важно. Он этим использованием сожжет эти миллионы долларов. Такое только один раз работает. Потом все бегом обновятся.
Минимизация угроз это важно. Но сервер у нас все еще неуязвим. Его не защищаем. Защищаем человека и ноут. Тут риски видны.
Поверьте от 0day в ssh ваш скриптик не спасет точно
Аргументы - не Ваша сильная сторона? Может, всё же попробуете аргументировать?
И защита от такого выглядит по другому. И то там скорее не защита, а минимизация последствий.
Ну, не томите уж, поделитесь! А то приходится всё из Вас как из партизана выпытывать.
Такая уязвимость стоит сильно за миллион долларов.
Я прям удивляюсь: так уверенно говорите некую конкретику, но зачем-то опять скрываете источник Ваших познаний. Опять предлагаете Вам на слово верить?
Вы точно понимаете что такое RCE 0day в ssh? Это доступ ко всему миру и полное всевластие над всем интернетом.
Как минимум на один раз. После использования вычислят и закроют. Но один раз можно вообще все.
Это доступ ко всему миру и полное всевластие над всем интернетом.
Не по этой ли причине так много попыток внести уязвимости в криптографию, о чём я тут писал?
Вы точно понимаете что такое RCE 0day в ssh?
Как уровень моего понимания связан с конкретными фактами стоимости эксплоита? И другими вопросами из этого поста? Может, ответите по существу, а не вопросом на вопрос?
Вообще про Яндекс из 2018 и Мейл из 2020 я точно знаю, что далеко не вся.
Security through obscurity это хороший признак провального решения. Которое нельзя использовать.
По-вашему, если у железной двери (аналогия сервиса) есть замки (авторизация по ключу и др. средства защиты), то установка в дополнение к ним кодового замка, никак не влияющего на другие замки (аналогия port knocking) - это Security through obscurity, которое нельзя использовать? Серьёзно?
Пусть знает что вот тут есть ssh с доступом по ключикам и решает. Не возражаю. По вашей оценке это сколько у него времени займёт?
Не слишком ли много неизвестных в уравнении, в котором хотите знать точный ответ? Или Вам график параметрической функции составлять для всех возможных переменных (которых Вы, вдобавок, даже не назвали)? Всё равно, что спросить: "сколько времени займёт перебор пароля (неизвестной длины, неизвестого набора возможных символов - вообще ничего не известно, кроме того, что пароль к некоему сервису)?"
Софт обновляется своевременно
Статью полностью прочитали? В заключении - ссылка, согласно которой "...среднее время устранения критически опасных уязвимостей в 2022 году составляло 65 дней". А Вы про своевременность обновления пишите. Учитывая это - начинаю сомневаться, что действительно знаете как в крупных компаниях что устроено (о чём пишите в комментариях).
Зачем что-то кроме этого стандартного, известного всем и совместимого со всем решения с доступом по ключу что-то еще делать?
Так Вам не только port knocking кажется лишним, а всё остальное тоже (ACL, fail2ban и т.д.)? Не знаете: зачем SOC\SIEM придумали, когда есть ключики? Поделитесь своим опытом организации безопасной ИТ-инфраструктуры: что там за проекты были, какая модель угроз, как достигалось повышение безопасности Вашими знаниями (с конкретикой)?
Когда уязвимость была по настоящему критической все обновились как бы не за сутки. log4j помните? Паника жесткая была. Так нелюбимый на Хабре российский вендор Джавы хотфикс джава машины предложил всем клиентам как бы не за 15 минут. И тем самым он окупил стоимость лицензий на десятилетие вперед минимум.
ACL, fail2ban и т.д.)
Что вы подразумеваете под ACL в контексте соединения из интерена я не знаю.
fail2ban глупости конечно же. Причем строго вредные глупости.
Я подведу итог обсуждения по этой ветке:
Вы сформулировали вопрос (сомнение в полезности port knocking при использовании ключей, в т.ч. для авторизации по ssh) в очень общем виде. Далее заявили, что ключи не ломаются в принципе. И хотели доказательств успешного взлома ключей. Когда я предоставил доказательства взлома ключей при определённых условиях - вдруг изменили позицию, заявив, что любой ключик стоит менять хотя бы раз в год (зачем, если ключи не ломаются в принципе - не ответили). Также сказали, что в современной Убунте RSA deprecated уже как много лет - отказавшись уточнять сколько именно лет и проигнорировав факт, что в ssh-keygen на Ubuntu 22.04.5 по-умолчанию генерит RSA ключи. И моё предложение доказать фактами, что ключи не взламываются в принципе проигнорировали.
Отказались сообщить о своём опыте организации безопасной ИТ-инфраструктуры
Знаете , как устроены внутренние сети у Гугла и у Яндекса и у неких "больших ребят". Но, отказываетесь сообщить источник своей информации.
Заявили, что port knocking от 0day не спасет точно и защита от такого выглядит по другому. Отказавшись представить: как по-вашему должна выглядеть эта защита и аргументировать свою позицию.
Обладаете знаниями о стоимости и наличии 0day уязвимостей (1, 2). Но, неоднократно, отказываясь предоставить источник и подтверждение своим словам (1, 2, 3)
Считаете port knocking - Security through obscurity, хороший признак провального решения. Которое нельзя использовать. Проигнорировав довод, что port knocking сам по себе не ослабляет других видов защиты.
iptables, ipset...
Пора бы уже на nftables переползать
А точно стоит? Всякоразные дырки в BPF находят чуть ли не несколько раз в год.
А когда последние дырки там находили? А то я аналогичное думал про io_uring, а оказалось, что последние уязвимости датируются летом 2023 года
Если вы используете не iptables-legacy, то по факту вы уже пишите правила под nft, только с ограничениями и местами кривой адаптацией, когда в "новом" iptables параметры командной строки отрабатывают не так, как в legacy варианте.
Хм, поговорили про порт-кнокинг и не упомянули SPA?
Согласен, технология похожая. Действительно, стоило бы упомянуть. Наверняка своего пользователя найдёт. Если я правильно понял, то довольно долго существовала ошибка, приводящая к DoS атаке пользователем без авторизации (отправить пакет с неверной длинной подписи). Что могло бы привести к невозможности доступа к защищаемому сервису.
Из иных нюансов могу предположить:
отсутствие поддержки роутерами "из коробки": в openwrt встроить, вроде, можно. А с другими роутерами - вряд ли;
необходимость пользователям адаптироваться к технологии (т.е. дополнительные телодвижения для пользователей, в т.ч. установлка доп софта);
потенциальная проблема с SOC\SIEM: если они не в курсе используемости технологии - могут сработать правила - какой-то странный пакет прилетел (а он для авторизации).
Практические варианты использования port knocking