Опубликован релиз OpenSSH 9.9, открытой реализации клиента и сервера для работы по протоколам SSH 2.0 и SFTP. Основные...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=61899
> работающая в OpenBSD, Linux и FreeBSDNetBSD как всегда ничего не умеет?
Умеет тосты.
Посмотрите документацию на mmap(), там должен быть флаг MAP_NOCORE или типа того, он то и используется чтобы память выборочно не дампить.
А можно просто поменять порт.
Все равно находят.
Кстати, всегда удивляло, как они узнают порт без скана. Или я проглядел? В порядке эксперимента посадил сурикату мониторить. Это очень подозрительно, что у кого-то есть доступ к трафику.
Сканят же с других машин.
Уже давным давно сети ботнетов разделены на "сканируещие" и "подбирающие вход",
при чем выявить зависимость можно, только если они оперативно данные друг другу перекидывают, например в течении минуты к тебе постучались с одного айпишника по портам, а логины-пароли тут же на этот порт начали кидать с другой подсети.
И да, обходить от бана различные IDS с дефолтовыми настройками - тоже умеют - ну дураки там чай сидят.И да, банить сканирующий ботнет - эффективность защиты от взлома из второй ботсети близка к нулю.
(А не банить - глупость).
На черта их банить? Парольный вход отключается, и пусть ботнеты перебирают пароли сколько хотят.
Зачем парольный вход отключать да ещё рутом входить запрещать?
Делается хостовый RSA ключ на 16к бит, и настраивается автобан который появился в одной из прошлых версий и этого достаточно.
В итоге боты на слабых железках улетают в бан на минуту (или сколько поставишь, но не рекомендую много) даже до попытки ввода пароля, а те что по сильнее - целый раз в минуту могут пробовать.
Port knocking?
Для извращенцев у которых много свободного времени.
> Port knocking?Это круто и прикольно. Но увы манипуляция с фаером и потому высокорисковое занятие. Ибо если случайно сам себя файрвольнуть с своего хоста - энное количество неудобств на ровном месте, что не прикольно.
>Все равно находят.детектор твоей неуловимости. роботам лениво. только люди находят ssh на портах 40-60к
"Оставайтесь!
Будете у нас главным инженером!"
(с) оттуда
Это называется «security through obscurity», и помогает приблизительно никак. Если есть подозрения в уязвимости SSH, то надо закрывать фаерволлом от всех кроме доверенных адресов. А если подозрений нет, то чем тебе мешают неудачные попытки аутентификации? В логах неаккуратненько?
> Это называется «security through obscurity», и помогает приблизительно никак.Это сильно снижает спам от ботов в логах и общую нагрузку на сервер - потому что большая часть ботов долбится на 22 порт - и если это не оно, они просто отваливают искать кого попроще. Делать полный портскан им ессно лень, реурсы ботнета не резиновые. И чем тратить на меня в 65535 раз больше времени - лучше опробовать 65К других хостов с тем же ресурсом.
Нагрузку в циферках покажешь? У меня был один джамп-хост, на котором в пике трафик от ботов генерировал в районе 70Mbps, и почему-то проблем не было: ни Спланк логами не давился, ни он-колл инженеры на латенси не жаловались. Так и стоял с 22 портом в публичный интернет, пока всё в облака не переехало и мы не отказались от SSH вообще.
> Нагрузку в циферках покажешь? У меня был один джамп-хост, на котором в пике трафик
> от ботов генерировал в районе 70Mbps, и почему-то проблем не было:А у меня был как-то VDS куда я однажды зайти не смог - ибо счет RSA на толпу ботов выжрал проц настолько, что сессия дохла по таймауту ДО того как до меня вообще очередь дойдет. Или как полюбить кастомные порты а потом и 25519, а заодно и port knock, да...
А на левые порты - боты почти не забредают. Они возможно вообще избегают кастомных портов, прикинув что владелец выше среднего и тратить на него ресурсы ботнета нафиг надо когда там вон толпа дефолтных серваков с такими же паролями на хостерском диапазоне. Ботнетчики же бизнес делают и заинтересованы в максимизации профита. А не выносе особо строптивого анона.
> ни Спланк логами не давился, ни он-колл инженеры на латенси не жаловались.
> Так и стоял с 22 портом в публичный интернет, пока всё в облака не переехало
> и мы не отказались от SSH вообще.Это не мои проблемы и мне не интересно куда вы там пошли. Хотя если настаиваете, могу пару интересных направлений на и в - подкинуть.
запрети логины с пасвордом, логинься по ключубудет тебе меньше спама
Может хоть ты знаешь как правильное отслеживание и ротацию ключей использовать? Где не искал - разложите ключ и будет безопасно. Как отозвать ключ, как найти где он лежит и вытереть, как отслеживать изменение состава ключей в профиле - пусто. Никто не пишет как грамотно обеспечить безопасность при ключевом заходе.
Может быть просто поменять рриватные ключи на сервере без предупреждения. И ловить лузлы по второму каналу связи с лузерами? ;)
Так дело не в этом. Вот человечек взял и ушёл из организации. Как отключить действие его ключа? Как найти на каких системах и в каких профилях ключ остался? Ок, если он на крон повесил задачку вкинуть ключ через месяц, как это найти?
Где вообще почитать как работать с ключами от выпуска до отзыва?
А у вас что, все юзеры ходят под одним пользователем на сервера? Или их публичные ключи хранятся не в их папке профиля?А вообще да, если нужен отзыв - то pki и танцы вокруг сертификатов. Я для дома поленился изучать, а организации это немного иной случай
> Ок, если он на крон повесил задачку вкинуть ключ через месяц, как это найти?а если он туда команду с обратным ssh закинул, как будешь искать?
почему вообще пользователь активен, если человечек взял и ушёл из организации?
В удаленных читай проблему. Почему-то там мат видите ли был.Обычный передерг пользователей локалхоста. Сразу про обратный ссш ересь и прочие взломы.
Мы говорим про правильную выдачу и отзыв прав. Такое могут делать только централизованные системы. Керберос, сертификационный центр. Расскажи как с сгенернированными ключами ссш получить туже функциональностьЕсли вкратце то нам надо быть уверенным что пользователь неактивен. Вот сервер где он был админом. Выключение локальной учетки этого ушедшего пользователя поможет ему больше никогда не получить доступ?
> Обычный передерг пользователей локалхоста.
> Вот сервер где он был админомЧто на локалхосте делают какие-то мутные админы?
С каких пор удаление админа стало "обычным передергом"?
Особенно если мы подозреваем, что этот админ мог насовать тайм-бомб с раскладыванием ключей по разным профилям?
Почему обратный ссх в этом случае ересь? Зачем ему вообще страдать с тайм-бомбами, если у него было возможностей от патчинга sshd до установки руткитов?С такими вводными про вредного админа вам опенид, оауф и пляски вокруг сертификатов для ссш не особо помогут, т.к. он уже вполне мог и нужные конфиги поправить
Есть как минимум коммерческий софт который умеет ходить по хостам и составлять список ктого где какие ключи есть и куда оно может подключится.
Зачем?? Есть разные системы где уже это продумали в архитектуре. Вплоть до idp.
> Так дело не в этом. Вот человечек взял и ушёл из организации.
> Как отключить действие его ключа? Как найти на каких системах и
> в каких профилях ключ остался? Ок, если он на крон повесил
> задачку вкинуть ключ через месяц, как это найти?
> Где вообще почитать как работать с ключами от выпуска до отзыва?у тебя есть список серверов к которым у него был доступ и authorized_keys откуда надо выкинуть его
идентифицируется по той самой публичной части в authorized_keys
взял и выкинул
нужна автоматизация процесса - это другая задача, но решаемая
а сказки про недоверие уволенному пользователю - ну тогда ищи трояна и перенастраивай сервера и данные
и это если он в UEFI не залез, или в какой-нибудь Intel ME
в общем ты бред написал, без аргументации
passwd, shadow, group - где искать или блокировать пользвоателя. Где стандартизированный список одного-двух файлов откуда можно выкинуть ключи.
Если ты не имел дело с иб и выдачей раскладов кто откуда и куда может ходить - это твои проблемы. Вот им будешь про бред рассказывать когда тебя спросят: а где приватные ключики лежат от этого пользователя что бы их поконтролировать, а?
> passwd, shadow, group - где искать или блокировать пользвоателя. Где стандартизированный
> список одного-двух файлов откуда можно выкинуть ключи.
> Если ты не имел дело с иб и выдачей раскладов кто откуда
> и куда может ходить - это твои проблемы. Вот им будешь
> про бред рассказывать когда тебя спросят: а где приватные ключики лежат
> от этого пользователя что бы их поконтролировать, а?т.е. в "passwd, shadow, group" у нас уже ключи хранятся?
вот это ыксперт подъехал
Ты совсем что ли дурч0к?
Обычный вход по паролю, стандартный подход дедов - passwd, shadow, group.
Вход по ключу список двух файлов где все их найти - ...
> Ты совсем что ли дурч0к?
> Обычный вход по паролю, стандартный подход дедов - passwd, shadow, group.
> Вход по ключу список двух файлов где все их найти - ...долпаеп мы про ключи говорили, ветку перечитай, passwd, shadow, group приплел ты в тему с ключами, дословно:
"passwd, shadow, group - где искать или блокировать пользвоателя. Где стандартизированный список одного-двух файлов откуда можно выкинуть ключи."
ты бы перечитывал что пишешь, глядишь бы сошел за менее неадекватного
Дружочек, да ты ни то что в ключи, ты в смысл обсуждения не можешь.
Начни с 5.15 сообщения, может получится.
Тебе прямо пытались узнать как с безопасностью в твоей локалхостовой схеме. Как её масштабировать можно на компании. и чем ключ лучше нормального пароля. Но ты же как голубь - улятел.> долпаеп мы про ключи говорили, ветку перечитай, passwd, shadow, group приплел ты в тему с ключами, дословно:
Да, да. Это именно про то что обычный пароль в конечном итоге, при соблюдении правил, в большой корпе выгодней ключа.
> ты бы перечитывал что пишешь, глядишь бы сошел за менее неадекватного
ну ты же не понимаешь про что речь дятел. Попробуй наморщить свой верхний мозжечок, а не нижний. Тут речь как обеспечить комплексную безопасность при ключевом доступе и парольном. А ты не можешь это рассказать.
потому что правильный ответ - никак же ж.И остается только адов гемор с сертификатами. У кого уже есть своя pki и все танцы вокруг например для vpn - тому в общем просто (потому что он уже по самые уши в навозе). А если у тебя сотня мелких клиентов - тебе неповезло.
Bingo. Только openid + ssh сертификаты. Вот и всё что я нашёл. Потребностей в колбасе у линуксоидов нет.
Ротация что ключей что паролей примерно бесполезна, используй второй фактор или аппаратное хранилище ключей ssh типа гугл титана или юбикея.
> Ротация что ключей что паролей примерно бесполезна, используй второй фактор или аппаратное
> хранилище ключей ssh типа гугл титана или юбикея.вы понимаете зачем нужна ротация паролей? и почему она ненужна для ключей?
ротация паролей изначально преследует цель смены относительно ненадежного пароля на новый с течением времени
чтобы подбирать пароль не было смысла, чтобы у атакующего не хватило времени на перебор
в случае с ключом, перебор будет занимать вечность, нужна только соотвествующая длина ключа, а иначе нет смысла заниматься ключами вообще
это конечно не означает, что нет места автоматизации, но предпосылки другие
> вы понимаете зачем нужна ротация паролей? и почему она ненужна для ключей?Конечно и утечек ключа не бывает, и отзывать их не нужно. В комитет по сертификатам подай свои гениальные идеи. А то там архитектуру пки придумывали, списки отзыва, время жизни и всё остальное ненужно.
>> вы понимаете зачем нужна ротация паролей? и почему она ненужна для ключей?
> Конечно и утечек ключа не бывает, и отзывать их не нужно. В
> комитет по сертификатам подай свои гениальные идеи. А то там архитектуру
> пки придумывали, списки отзыва, время жизни и всё остальное ненужно.тебе известен смысл слова "ротация"? и почему оно произошло от слова вращать? при чем тут отзыв из-за компрометации? совсем не видишь разницы?
Так я ещё слушаю как с ключами сделать список отзыва, блокировку, протухание по времени и прочие стандартные вещи из других способов авторизации.
Хотя где у тебя на локалхосте ибшники то, эксперт, йоэсс.> ротация паролей изначально преследует цель смены относительно ненадежного пароля на новый с течением времени
Ротация уже не используется во многих местах, начни с статьи https://en.wikipedia.org/wiki/Password_strength и дальше документы nist и обсуждения
> при чем тут отзыв из-за компрометации? совсем не видишь разницы?
Если ты не понимаешь в безопасности и только вращать на чём-то можешь кто тебе лекарь.
В nist примерно такой список, и это всё по паролям:
Check passwords against breached password lists
Block passwords contained in password dictionaries
Prevent the use of repetitive or incremental passwords
Disallow context-specific words as passwords
Increase the length of passwordsНикакого протухания тут нет. А проверки есть.
Жду рассказов какие пункты нужны при работе с ключами для безопасности.И что делать при компрометации ключа.
Джастин Крюгер и Дэвид Даннинг апплодируют тебе стоя за отличное подтверждение их теорий.А я устраняюсь от коментирования этого потока субстанции.
где-то скучает sssd
И зачем, если есть домен, туда запихивать ещё и ключи как отдельную сущность? У тебя уже есть керберос.
вдруг это не домен, а что-то с LDAP-совместимым интерфейсом?
> вдруг это не домен, а что-то с LDAP-совместимым интерфейсом?Теоретически возможно. Но вменяемо как обеспечить прозрачность, как в том же керберос, я не представляю. Даже не встречался с таким. Где-то есть описание как поверх лдап это организовывают? Что бы автоматическая и принудительная ротация ключиков была доступна, зашифровано и прозрачно для пользователя? Сдается мне с приватной частью ключа будут большие проблемы в этой схеме.
Мой домашний хост на фряхе с 2009 года в сети доступен по ссш, ни разу это не было проблемой или даже чем то заметным, даже когда я начинал на п3.
Есть же NTRU Prime.
Вот ты они работу по udp реализовали.Хоть по quic или как-то так.
Quic работает медленней tls.
Существуют ли постквантовые алгоритмы ГОСТ?
Нет, они ещё шильдик переклеить не успели :)
Как только соберут квантовый компьютер, так сразу.