Комментарии 122
а лучше сразу раскатить PasswordAuthentication no
Заодно и PermitRootLogin no
Это не про усиление безопасности в контексте текущей статьи. Это скорее про аудит - при условии, что он настроен, что его логи кто-то смотрит, и что никто не использует `sudo bash` и аналоги (впрочем, помним про то, что выйти в шелл можно из многих других приложений, включая vim, так что это не панацея и желающие выполнить команды мимо аудита всё-равно смогут это сделать). В остальном большой пользы от этой настройки нет.
большой пользы нет, но это усложнение атаки на сервис, одно дело когда злоумышленник попал на сервер сразу рутом и другое когда ему надо искать способ поднять привелегии, что при корректно настроенном ids с большей вероятностью алертнется
==
и вообще под рутом в принципе нечего делать на любых машинах в корпоративной инфраструктуре, никому, даже самымглавнымадминам
это усложнение атаки на сервис, одно дело когда злоумышленник попал на сервер сразу рутом и другое когда ему надо искать способ поднять привелегии
Это традиционный контр-аргумент. Проблема в том, что он больше теоретический, нежели практический - в теории чем больше уровней защиты тем лучше. А на практике первым возникает вопрос: а каким конкретно способом злоумышленник попал на сервер через ssh не под рутом? И дальше обычно выясняется, что в реалистичных сценариях у него в любом случае будет рут, если рут есть у владельца текущего аккаунта.
и вообще под рутом в принципе нечего делать на любых машинах в корпоративной инфраструктуре, никому, даже самымглавнымадминам
Ну так не кладите ключи в /root/.ssh/authorized_keys2 и их там не будет. А если серьёзно, то, опять же, в теории это возможно, но на практике даже при использовании IaaC изредка всё-равно нужен прямой доступ под root - когда случается что-то нештатное (железо частично поломалось, нужно отлаживать какие-то серьёзные странности в поведении ядра, нужно разобраться с идущей прямо сейчас атакой или провести расследование последствий атаки, etc.). И в таких случаях PermitRootLogin no просто мешается под ногами, без какой-либо пользы от него ни в этот момент ни в остальное время (потому что полноценного аудита при котором от него польза может быть на практике даже в средних компаниях почти не встречается).
И в таких случаях PermitRootLogin no просто мешается под ногами
Это решается sudo. PermitRootLogin нужен фактически только для единственной функции: туннели (VPN) через sshd (не путать с пробросом портов).
sudo решает (частично) вопрос аудита, не более того. Если в компании полноценного аудита нет - то PermitRootLogin yes может быть даже безопаснее, потому что sudo создаёт дополнительный вектор атаки (напр. вот, эскалация привилегий месячной давности: CVE-2025-32463).
Это решается
sudo
Наоборот, это sudo заменяется ssh с разрешенным входом по root. Просто выполняешь соединение на localhost с нужной командой.
Преимущество - можно ssh-agent пробросить и авторизоваться ключиком с своей локальной машины, не помня и не устанавливая никаких паролей для пользователя.
Недостаток - все эти правила, что в sudo есть, теряются, но оно далеко не всегда надо.
Преимущество - можно ssh-agent пробросить...
…и получить дырищу в безопасности! Мало того что этот проброс by design дырявый, так ещё и были связанные с ним уязвимости.
И дальше обычно выясняется, что в реалистичных сценариях у него в любом случае будет рут, если рут есть у владельца текущего аккаунта.
реалистичные сценарии есть такие о которых вы не догадаетесь, я уже спорил со своими ИБшниками что недостаточно закрыть контур снаружи и забить на обновления серверов кторые строго внутри контура компании находятся..типа там всёравно только свои ходят...
меня отлично научили на одном из тестов проникновения как ломануть доменный контроллер просто отправкой письма на комп сотрудника с гостевыми привелегиями...15 минут хватило чтобы показать как ломануть доменный контроллер через эксплойт на который апдейт вчера вышел..зайдя туда админом от пользователя с правами "пользователь" - который априори туда доступа иметь не должен вообще никакого кроме АД-шных сервисов типа получения gpo и прочей авторизации
тут винда конечно, но линукс тут не панацея, там полно дыр такого рода бывало, взять дырищу с повышением до рута в vim например
тут конечно вопрос в изоляции контуров и ограничений доступа по портам в сочетании IP+user ...но это уже прям жирно хорошо, для этого надо чтобы инфраструктура была готова к таим приседаниям..и то не факт что дыры в фаерволле не будет
И в таких случаях
PermitRootLogin noпросто мешается под ногами, без какой-либо пользы от него ни в этот момент ни в остальное время (потому что полноценного аудита при котором от него польза может быть на практике даже в средних компаниях почти не встречается).
все действия должны логироваться, если в логах написано что зашел root и чёто там сделал ..как вы будете выяснять кто этот человек и как вы упустили пароль от привелигированного пользователя?
а если у вас 192.168.0.1 login root в логах, то это уже фейл
реалистичные сценарии есть такие о которых вы не догадаетесь
Есть. Но это не повод для карго-культа и театра безопасности. Предпринимая какие-то действия "для безопасности" стоит понимать, какие конкретно риски и сценарии атак эти действия прикрывают. Тупо механически выключать везде PermitRootLogin просто потому, что так 20 лет назад порекомендовали где-то в интернете плюс в директиве есть страшное слово "root" - так себе идея.
если в логах написано
Как я с самого начала говорил, если в компании настроен полноценный аудит - то PermitRootLogin действительно нужно отключить, иначе он этому аудиту будет мешать. Но - это далеко не единственное, что нужно сделать, потому что sudo bash этому аудиту будет мешать ровно так же. И нет, надеяться на то, что "если что - что-нибудь по логам накопаем" - это и близко не эквивалент состоянию "настроен полноценный аудит".
Вообще, я в эту сторону давненько не смотрел, но вроде были какие-то способы логировать все exec-и на уровне сисколов. Если аудит делать на этом уровне, а не надеяться на "непробиваемый" /etc/sudoers, то и PermitRootLogin может аудиту не особо мешать - кто именно зашёл под рутом видно по тому, какой из ключей использовался, а дальше к нему привязан аудит по exec-ам.
упо механически выключать везде
PermitRootLoginпросто потому, что так 20 лет назад порекомендовали где-то в интернете плюс в директиве есть страшное слово "root" - так себе идея.
да всё просто, почти в любом стандарте ИБ, PCI-DSS, SOX и прочихз аббривеатурах, всегда первыми пунктами парольно-пользовательской политики идет запрет работы под анонимными привелигированными пользователями, не потому что "20 лет ктото порекомендовал, а ща всё устарело"..а потому что за этим есть смысл в виде логирования, мониторинга и контроля
sudo bashэтому аудиту будет мешать ровно так же.
не будет, в логах будет запись что pupkin.v зашел на сервак и сделал sudo bash, в результате сгенерирован автоматический инцидент ИБ и безопасник дал васе по шее
И нет, надеяться на то, что "если что - что-нибудь по логам накопаем" - это и близко не эквивалент состоянию "настроен полноценный аудит".
вы самостоятельно расследовали инциденты по логам? я вот да
кто именно зашёл под рутом видно по тому, какой из ключей использовался, а дальше к нему привязан аудит по exec-ам.
т.е. вместо одной строчки в логе сервера, нам надо заниматся приседаниями с ключами кому какой выдан и матчить их с логами..а потом окажется что злоумышленних всё на серваке дропнул вместе с ними также как и на компе человека с которого заходил..и ой..мы забыли логировать выдаваемые ключи или поставили срок хранения логам по ним 1 год..а выдаем их на 15 лет потому что лень менять чаще
блин вы усложняете сценарии ИБ только ради того чтобы под рутом на серваки ходить напрямую? это того стоит? я очень давно не брал в руки шашку в админской сфере, но помню что там от ИБ других более серьёзных граблей больше и запрет входа под рутом самая ерундовая история
лучше давайте про selinux и прочие apparmor вспомним и динамический фаерволл зависящий от юзера и приложений которые ему разрешено запускать...или это тоже не нужно и мы всецело доверяем админам?
стоит понимать, какие конкретно риски и сценарии атак эти действия прикрывают.
а это я люблю
помню такую фразу "нам не надо усиливать безопасность, нам надо только точно знать кто виноват в инциденте, мы на него в суд подадим и инцидент будет исчерпан" (с)
буквально, васян потерял ноут с ключами ssh, у банка украли 100500млн денег...ну так Васян виноват, пускай суд его покарает...а 100500млн..ну украли и украли..бывает..ВИНОВНЫЙ НАЙДЕН! (рукалицо)
главный риск такой чтобы сервис был не взломан, если взломан то минимально поврежден, если поврежден сильно то был быстро восстановлен с закрытием дырок через которые он был скомпроментирован.
я конечно говорю не про сервисы контроля за похудением где парольные политики похлеще интернет банков, а чтото посерьёзнее.
p.s. меня испортила работа в финтехе
Вы всё говорите правильно, и я с этим не спорю. В компаниях где реально внедрены любые стандарты ИБ есть адекватный аудит, и там отключать PermitRootLogin действительно есть смысл. Но помимо таких компаний есть те, которые до этого уровня зрелости ещё не доросли - их намного больше, и в них зачастую процветают карго-культы и театры безопасности вместо реальной ИБ.
вы самостоятельно расследовали инциденты по логам? я вот да
Я тоже да. Поэтому и говорю, что надеяться на это нельзя - пока процессы аудита не были поставлены и протестированы всегда есть высокая вероятность, что в логах будет что-то бесполезное вроде локального IP или вообще не будет нужного или сами логи будут удалены. Иными словами, я не против отключения PermitRootLogin, я за то, чтобы его выключали не "по умолчанию", а при наличии понимания что конкретно это даст в текущей ситуации. Хотя бы на минимальном уровне: адекватно настроенный sudoers, наличие алертов на sudo bash сотоварищи которые кто-то реально получает и на которые обязательно реагирует, проведённый анализ логов показывающий возможность отследить кто и что делает, хоть какая-то защита логов от удаления.
главный риск такой чтобы сервис был не взломан, если взломан то минимально поврежден, если поврежден сильно то был быстро восстановлен с закрытием дырок через которые он был скомпроментирован.
Это типичная точка зрения технаря. С точки зрения бизнеса всё не так однозначно - ущерб вполне может оказаться застрахован либо "лечь" на того, кого "не жалко". Концепция "нам надо только точно знать кто виноват в инциденте" тоже имеет право на жизнь, если это требование необходимо для того, чтобы обеспечить гладкое получение той же страховки, например, или просто перенос ответственности чтобы какого-нибудь топа не назначили виноватым за инцидент. Мы работаем на бизнес и для бизнеса, закрываем его потребности, и они далеко не всегда совпадают с идеальными техническими решениями - к сожалению.
Иными словами, я не против отключения
PermitRootLogin, я за то, чтобы его выключали не "по умолчанию", а при наличии понимания что конкретно это даст в текущей ситуации.
чтобы избежать проблем - достаточно мыть руки перед едой и после туалета. Не просто так цветет наследие Земмельвайса. Но если этого не делать - дальше не пройдешь. Поэтому запрет PermitRootLogin- хорошее умолчание.
А как быть с ситуацией, когда scp скриптом забираю конфиги с серверов для бекапа локально? Конфиги часто лежат в папках, доступных только под рутом
Не всё сетевое железо так умеет. Далеко не всё.
Классика жанра:
«Зачем хранить пароли в секретах, если можно просто sshpass -p "12345"?»
Реальность: Через 5 минут этот пароль уже в логах, мониторинге и чате DevOps-ов.
Использовать ssh-agent и ключи без паролей в скриптах.
Это плохой совет, потому что стандартный ssh-agent просто предоставляет доступ к ключу, без всяких ограничений и подтверждений. Любое вредоносное ПО на сервере сможет пользоваться ключом подключённого администратора и подключаться к другим серверам.
Ну, это всё-таки лучше, чем светить паролем. Кроме того - а какие есть доступные альтернативы?
Для резервного копирования по SSH?
На сервере, где хранятся копии, создаём отдельного пользователя с домашней директорией, и добавляем его в группу chrooted
Для домашней директории выставляем права доступа
drwxr-x--x, пользователь и группа — rootВ домашней директории создаём каталоги
backupс правамиdrwxr-x-wxиbackup-backupсdrwx-----, оба такжеroot:root.В crond на сервере добавляем
mv /home/backup-user/backup/* /home/backup-user/backup-backup/На клиенте, который делает резервное копирование, генерируем уникальный ssh-ключ для этой задачи, добавляем его на сервер
В sshd_config добавляем то, что ниже
Match Group chrooted
ChrootDirectory %h
ForceCommand internal-sftp
AllowTcpForwarding no
GatewayPorts no
X11Forwarding no
PermitUserRC no
Получили в итоге:
Доступ к SSH-консоли отключён, работает только SFTP
По SFTP клиент может зайти только в директорию backup внутри собственной домашней директории, при этом не может сделать листинг файлов в ней (нет
+r, есть только+x), а может только «вслепую» загрузить (или прочитать) файл бэкапа. Создание файлов и директорий внеbackupневозможно.Сервер по cron'у перемещает загруженные в
backupбэкапы в директориюbackup-backup, куда доступа у SSH-клиента нет никакого, чтобы нельзя было изменить или удалить загруженные файлы даже вслепую
Это костыль, но рабочий. Лучше, конечно, применять специализированные решения, изначально рассчитанные на write-only доступ.
Да нет, с бэкапом всё просто - у меня сервера его сами делают и заливают в облако, ssh тут вообще не нужна. Я в общем случае про задачу "ssh в скрипте", для которой обычно и используются беспарольные ключи - когда такая задача триггерится не на самом сервере (как возможно сделать в случае с бэкапами) а снаружи.
Я обычно завожу уникальный ключ, которому указываю command=… (forced command), чтобы этим ключом нельзя было сделать ничего недозволенного.
Приватный SSH-ключ лежит ведь в домашней директории пользователя? Чем это лучше, чем хранить его в агенте?
Но, кстати, лет 15 назад у меня было сделано подобным образом. Тогда я зачем-то решил бэкапы со всех серверов сначала собрать на одном, и уже с него заливать в облако бэкапы всех серверов. Если не путаю, изначальная идея была в том, чтобы меньше зависеть от облаков и всегда иметь бэкапы локально на выделенном под это дело сервере. Но сейчас в этом особого смысла нет (а может и тогда тоже не было).
Для домашней директории выставляем права доступа drwxr-x--x, пользователь и группа — root
А это разве работает? Обычно же выдаёт ошибку "домашняя директория пользователя должна принадлежать ему самому" и отказывает в подключении.
какие есть доступные альтернативы?
ProxyJump
А чем это поможет в скрипте? ProxyJump нужен чтобы пройти через периметр, но никак не поможет в скрипте обойтись без пароля или беспарольного сертификата.
Любое вредоносное ПО на сервере сможет пользоваться ключом подключённого администратора и подключаться к другим серверам.
Только запущенное от имени того же пользователя, потому что сокет имеет права 600.
А вот это уже вопрос к ИБ, откуда на сервере вредоносное ПО, которое может получить доступ к read-only файлам пользователя...
Semgrep
Эта та штука, которая для работы хочет логин в их SaaS, и передает данные для анализа на их сервера? Я сходу не увидел у них на сайте как задеплоить полностью локальный инстанс.
sshpass -p 'Qwerty123' ssh admin@10.0.5.21
Ну враньё же. 1729664 pts/10 S+ 0:00 sshpass -p xxxxxxxxxxxxx ssh ...
И это весьма старая версия ещё.
Когда процесс переписывает эту инфу всегда есть промежуток времени, когда он уже запустился, но ещё не переписал - он не очень большой, но во-первых может тупо повезти, а во-вторых если мониторить запуск чужих процессов скриптом то шанс увидеть оригинальные аргументы сильно увеличивается.
это не всегда работает так, как хотелось
например, у меня есть железка с логами в cp1251, я прямо сейчас наблюдаю в ps
2144581 pts/54 S+ 0:00 \_ luit -encoding cp1251 sshpass -p 123 ssh root@10.20.240.36
2144582 pts/102 Ss+ 0:00 \_ sshpass -p ssh root@10.20.240.36
sshpass может брать пароль из файла. Тоже не бог весть, но по крайней мере пароль открытым текстом нигде не светится.
sshpass может брать пароль из файла. Тоже не бог весть, но по крайней мере пароль открытым текстом нигде не светится.
Эммммм... а в файле?
Вот же гниды эти сетевики! Не то что остальные принцы в золотых доспехах на белых конях.
Видимо автору в детстве сетевик нанес глубокую травму...
Видел похожее, только пароль в curl через user:pass@ гоняли
из списка рекомендаций:
Использовать
ssh-agentи ключи без паролей в скриптах.Хранить секреты в Vault, AWS Secrets Manager, Ansible Vault.
Прятать учётки в
.pgpass,.my.cnf,.netrc(права 600).Разграничивать доступ: никто кроме root не должен видеть чужие процессы.
Ограничивать или удалять опасные утилиты (
sshpassи пр.).В случаях когда необходимо хранить секреты в файлах использовать кодировку
три откровенное говно.
ssh-agent - если он запущен, то любой процесс на хосте может к нему подцепиться.
прятать учетки в файлах конфигов - они есть на файловой системе. Вы же ее не шифруете? А любой безобидный кронтаб и пользователь уже рут и читает все файлы
кодировка - ну, типа base64? Смешно.
То есть этими рекомендациями вы не избавляетесь от основной проблемы - необходимость смены пароля в случае его компрометации. А чтобы от нее уйти - надо... внезапно... уйти от паролей. Даже короткоживущие сертификаты будут лучше. Ну, и, видимо, как я их и не люблю, но так любимые безопасниками - списки контролей доступа (ACL) или же "белые списки" доверенных IP адресов.
А безопасные и практичные способы есть?
в облаке проблема решается через IAM/IRSA (Amazon) и workload identity (в случае Google).
На on-premise - только костылить. Но в целом штуки вроде https://github.com/spiffe/spire именно за этим и нужны.
Вообще тут интересно засаммонить безопасников - пускай они отдуваются, как профильные специалисты. Так-то они веселые ребята - кого-то критиковать - это завсегда. А самим что-то предложить и побыть критикуемыми? Или так нельзя?
А как тогда, например, настраивать бекапы для MySQL с доступом по паролю, если в строке пароль передавать нельзя или хранить в конфигах.
Можно более развёрнуто?
если бекап с той же машины - MySQL, Pg прекрасно аутентифицируют под линукс учеткой. В этом случае Вы смещаете проблему.
Если же договориться, что брать пароль из волта или подобного - тоже норм, тоже по сути смещаем проблему. Пароль нигде в открытом виде не хранится, но чтобы сходить в волт тоже нужен токен или что-то подобное. Система действительно усложняется, но упрощается аудит и упрощается ротация паролей в случае факапа.
ssh-agent - если он запущен, то любой процесс на хосте может к нему подцепиться.
может все-таки не любой, а только запущенный от рута или того же пользователя?
при должной степени ловкости - любой.
А можно поподробнее?
А так же про "любой безобидный кронтаб и пользователь уже рут и читает все файлы"
например, https://snehbavarva.medium.com/privilege-escalation-techniques-series-linux-cron-jobs-a5b797b424b4
По su / sudoers - история тоже известная. В самом sudo пачка уязвимостей https://habr.com/ru/companies/kaspersky/articles/925604/
Чуточку добавьте любознательности
Там не про ловкость, а про криво настроенную систему...
аксиома - идеально настроенных систем не бывает. Тем более в любой сколько нибудь сложной системе всегда найдутся проблемы. Уязвимые пермиссии, например, могут приехать из пакетного менеджера. Или неудачной установки, скажем, https://github.com/kubernetes-sigs/kubespray/issues/4824 https://github.com/kubernetes-sigs/kubespray/issues/6891 Жесть же. Именно поэтому контейнеризация не защищает - из нее гораздо легче выбраться, чем из виртуализации (там только штуки вроде Spectre и Meltdown, да дырки в гиперах позволяют выбраться).
Ну если вы допускаете, что к вашему серверу злоумышленник может получить root доступ, то какой смысл дальше обсуждать, что надежнее: пароль, сертификат или еще что-то? Ко всему у него будет такой же доступ, как и у легитимных программ..
Ну и если так рассуждать, то в винде дыр не меньше... Может ваш ноут вирусами заражен и давно уже слил все ваши логины, пароли и ключи. Такой вариант вы не рассматриваете?
я не сказал, что рут. Если есть ssh под непривилегированным пользователем - как мы выяснили - можно эскалироваться до рута. Если есть сервисы, которые доступны по сети - тоже. Хотя это и сложнее.
Может ваш ноут вирусами заражен и давно уже слил все ваши логины, пароли и ключи. Такой вариант вы не рассматриваете?
я уже сто лет в обед пользуюсь менеджерами паролей вроде 1password и Proton Pass.
Если мы допускам, что любой пользователь на сервере может стать рутом если просто достаточно захочет, то единственной рабочей рекомендацией будет вообще не доверять ничего этому серверу.
Потому что от подмены бинарника ssh не защитят ни короткоживущие сертификаты, ни даже белые списки IP адресов.
Я проверял список процессов на сервере
(ps aux)и вдруг вижу
hidepid=2 спасёт гиганта мысли.
Интересно, а автор на этот сервер тоже с паролем заходил или с ключом?) Стандартные absible роли для настройки новых серверов решают эти проблемы.
Как то пришлось в windows прописывать пароль админа в текстовую команду чтобы запускать ПО IVMS-4200 на компьютере охраны. Была проблема ,что ПО видеонаблюдения от Hikvision IVMS-4200 не стартует без прав администратора, а у охранников на КПП таких прав нет конечно же, а камеры смотреть нужно. Пришлось такую сложную схему городить, запуск задачи в планировщике при старте Windows Эта задача запускает PsExec.exe ( из пакета Sysinternals) а ключами будут логин пароль и запуск батника. Примерно так в планировщике Сценарий: "C:\Program Files (x86)\Processadm\PSTools\PsExec.exe"
Аргумент: -i -u username -p password "C:\Program Files (x86)\Processadm\ivms_start.bat"
А в батнике ivms_start.bat такая строка Set ApplicationPath="C:\Program Files (x86)\iVMS-4200 VS\iVMS-4200 VS Client\Client\iVMS-4200.Framework.C.exe"
cmd /min /C "set __COMPAT_LAYER=RUNASINVOKER && start "" %ApplicationPath%"
В итоге у охранников при включении ПК запускалось видеонаблюдение автоматически и под правами админа, ничего у них не спрашивая. Это тоже конечно утечка пароля админа, но он хотя бы не доменный а локальный для отдельно взятого ПК.
А почему не runas?
Runas плохой вариант, он позволяет потом запускать с правами пользователя любой бинарь с тем же именем. Тут вот пособирали вариантов https://habr.com/ru/companies/servermall/articles/485958/
Что внедрить в процесс
Linux — cron‑сканеры, Ansible, shell‑скрипты.
Windows — PowerShell + логирование.
CI/CD — линтеры и сканеры (Checkov, KICS, Semgrep).
IDE — pre‑commit хуки, запрещающие команды с паролем в аргументах.
Инструменты понятные, но я не понимаю как это поможет защититься от нерадивого сетевика?
к слову, ansible под капотом использует этот же sshpass для подключений ssh по паролю (ansible_ssh_pass), используйте ключи
Всегда прикалываюсь с таких ситуаций. Есть специализированный сервак с скриптами, ИБ как самые умные начинают везде лезть, требовать доступ и т.д.. И начинается "ой вы делаете не так" проблема не в не вне так, проблема в том что кто-то влез в ресурс где быть никого не должно. И воспользовался для этого административным давлением. Это как сказать "вот приказ директора - дай пароль" а потом "вот видишь, я под твоим паролем, ты его плохо хранищь".
А потом начинается, вот мы крутое ИБ, глядите как мы круто добыли доступы, и не важно как мы их добыли :) гребаный цирк, вам самим над собой ржать не хочется?
У меня была куча обратных проблем. Доступы делают по 4 месяца. В целом мне норм, деньги платят, доступы ждёшь, но менеджеры нервничают.
Доступ на тестовый сервер на AWS, только из внутренней сети, никакого порта наружу. Пришлось городить ssh туннели. ХЗ, кому от этого было лучше.
Самое эпичное - докер нельзя, потому что не безопасно, используй виртуализацию. Так мне внятно и не объяснили, почему виртуализация безопасней докера. Из полезного пришлось выучить Vagrant и Terraform. Из минусов тестовый энв разворачивался 20 минут, вместо 3х ну кубере. Ну и пришлось требовать больше оперативной памяти.
Самое эпичное - докер нельзя, потому что не безопасно, используй виртуализацию. Так мне внятно и не объяснили, почему виртуализация безопасней докера
потому что. Иди почитай матчасть, бро. Если вдруг не получится - приходи, расскажу.
Из минусов тестовый энв разворачивался 20 минут, вместо 3х ну кубере
ну, 3 vs 20 не так уж страшно. А вот 3 vs 300 - беда.
В докере чуть больше рисков, чем в виртуализации. Но ведь и в виртуализации больше рисков чем в использовании отдельных железных серверов. Это вопрос баланса. И в докере есть достаточно много способов ограничить контейнеры, чтобы в большинстве случаев более высокими рисками по сравнению с виртуализацией можно было спокойно пренебречь. Поэтому если у ИБ нет чёткого и здравого аргумента какие конкретно риски для бизнеса они закрывают заменой докера на виртуализацию либо соответствие каким критичным для бизнеса стандартам это обеспечивает, то вероятнее всего отдел ИБ творит фигню - обычно из-за собственной низкой квалификации или синдрома вахтёра.
В докере чуть больше рисков, чем в виртуализации.
не чуть больше. А значительно больше (больше деталей, движущихся компонентов, достаточно высокая степень незрелости экосистемы и самое главное - возможно тащить недоверенный код с помойки в виде докерхаба). Теоретически ограничить докер можешь. Но это куча работы. Кто ее делать будет?
Но ведь и в виртуализации больше рисков чем в использовании отдельных железных серверов
тоже правда
Это вопрос баланса
да
Поэтому если у ИБ нет чёткого и здравого аргумента какие конкретно риски для бизнеса они закрывают заменой докера на виртуализацию либо соответствие каким критичным для бизнеса стандартам это обеспечивает, то вероятнее всего отдел ИБ творит фигню - обычно из-за собственной низкой квалификации или синдрома вахтёра.
честно говоря, для большинства бизнесов докер вообще не нужен. И вообще им контейнеризация не решает ни одной задачи ) Запихать 10 разных сервисов на один сервер? Ну, камон. Смешно. 10 ВМ прекрасно работает. 10 железяк - да, может быть тупо избыточно по ресурсам (но во многих компаниях деньги на железо-то и не считают внезапно).
Теоретически ограничить докер можешь. Но это куча работы. Кто ее делать будет?
Ну да, правильно. Зачем делать работу, если можно просто всё запретить?
чтобы делать работу за неё надо заплатить, а кто будет за это платить? никто...по этому запретить проще
А варианта и не делать работу и ничего не запрещать раз не платят - почему нет?
если не делать работу и не запрещать, то сотрудники на местах самодеятельно накрутят всякой дичи бесконтрольно.
Это уже много раз пройдено
И почему это проблема ИБ, а не бизнеса? Если бизнесу ИБ не нужен - пусть накрутят дичь. Если бизнесу ИБ нужен, и дичь неприемлема - почему бизнес не выделяет ИБ необходимые для "сделать нормально" ресурсы? Тут где-то что-то явно не стыкуется:
или начальник ИБ не в состоянии донести до бизнеса то, что необходимо выделить ресурсы под эти задачи,
или бизнесу это на самом деле не нужно а ИБ просто удовлетворяет собственный синдром вахтёра,
или от ИБ бизнес требует создать видимость работы дёшево, но тогда не надо доказывать адекватность этой видимости работы с технической точки зрения на хабре,
или бизнес просто не осознаёт реальную цену излишних запретов ИБ.
"Решать" проблемы тупо запрещая что можно и что нельзя - этот приём активно используется в политике. Может в политике он и работает, не могу судить. Но в бизнесе этот подход совершенно точно вредит бизнесу.
достаточно высокая степень незрелости экосистемы
Позвольте я влезу в вашу дискуссию.
Вы сейчас про докерхаб же? Тут есть варианты, например свой реп.
варианты есть всегда ) но это больно. Все равно базовые образы надо откуда-то брать - а они уязвимые. Вроде бы к 2025 появилось движение к базово защищенным образам. Но че-то все сильно платное - что bitnami, что cgr.dev. Да сам докерхаб в конце-концов. Посмотрим, во что это выльется.
И чем именно базовые образы вроде ubuntu:latest более уязвимы чем ровно эта же убунта в виртуалке?
например, самой сутью образа - там нет кернела. Касательно сравнения именно убунту vs убунту - с точки зрения пакетного менеджера и установленных бинарников - разницы скорее не будет. И вообще выше товарищ правильно говорит - нечего это сравнивать, потому что для контейнеров надо брать контейнерные штуки вроде wolffie, from scratch, distroless etc.
например, самой сутью образа - там нет кернела.
И как это может навредить безопасности? Докер же крутится в той же виртуалке, безопасность которой Вас устраивает. Значит за ядром в виртуалке Вы уже следите. А в остальном разницы никакой нет, просто базовые образы тоже надо обновлять - ровно так же, как и виртуалки.
для контейнеров надо брать контейнерные штуки вроде wolffie, from scratch, distroless etc.
Что значит "нужно"? Кому нужно и для чего? Обычно эти штуки берут как раз для усиления безопасности (чем меньше в образе лишних приложений тем меньше возможных векторов для атаки). Но если ваш ИБ считает что у "контейнерных штук" безопасность хуже, то он может вместо них брать и ubuntu:latest. Размер образа будет больше, но в остальном особой разницы нет.
контролей и обзервабилити у контейнеров меньше - это можете даже не оспаривать. Тулинг пока не созрел до конца, увы. Условный Falco берешь - а он путь к файлу пишет не так, как надо. Сидишь и гадаешь (я утрирую) - проблема на хост машине или в контейнере. Так что проблема более широкая.
Это вопрос восприятия. Не нужно воспринимать контейнеры аналогом виртуалок или железных серверов - они этим не являются.
Контейнер - это обычный процесс/приложение, просто дополнительно ограниченное ядром в плане того, что это приложение видит. Грубо говоря, контейнер намного ближе к запуску бинарника в chroot чем к виртуалке.
Поэтому в плане управления и мониторинга от контейнеров нужно ждать примерно того же, что и от любых процессов - т.е. только тех возможностей, которые реализованы в самом приложении. Всё, что докер даёт сверх этого - это "дополнительная фича", а не "урезанный вариант того что доступно для виртуалок".
Как вариант, ставите на сервак netdata (можно тоже в докере), и получаете обзервабилити выше крыши, включая и для контейнеров докера.
Это вопрос восприятия. Не нужно воспринимать контейнеры аналогом виртуалок или железных серверов - они этим не являются.
я никогда их аналогом виртуалок и не называл
Контейнер - это обычный процесс/приложение, просто дополнительно ограниченное ядром в плане того, что это приложение видит
да
Грубо говоря, контейнер намного ближе к запуску бинарника в chroot чем к виртуалке.
да
Поэтому в плане управления и мониторинга от контейнеров нужно ждать примерно того же, что и от любых процессов - т.е. только тех возможностей, которые реализованы в самом приложении
нет. Именно за счет того, что с точки зрения докера и CRI контейнеры "существуют", а с точки зрения ядра линукс - нет - у нас возникают проблемы, связанные с тем, чтобы правильно рапортовать, например, что процесс ХХХ случился именно в контейнере YYY. Это примерно такая же проблема совместимости, как между nftables и iptables. Повторюсь - тулинг недостаточно зрелый. Хотя и двигается в этом направлении.
честно говоря, для большинства бизнесов докер вообще не нужен. И вообще им контейнеризация не решает ни одной задачи )
Может ни одной задачи отдела ИБ это и не решает, а вот задачи разработчиков - очень даже решает. Разработчики все дружно перешли на докер потому, что их жизнь от этого стала легче. А когда жизнь у разработчиков легче - бизнесу разработка стоит дешевле, в некоторых случаях - заметно дешевле.
Так что если ИБ не делает свою работу полноценно "потому что за это не заплатили" но при этом навязывает запреты "на всякий случай", то нужно понимать, что бизнесу эти запреты обходятся значительно дороже, чем оплата времени ИБ на придумывание и внедрение этого запрета. Безопасность и удобство обычно находятся по разные стороны, а неудобство - это лишние затраты времени, а время - деньги.
Поэтому лично я против театра безопасности. Когда что-то делается для усиления ИБ - это должно быть оправдано реальными нуждами/рисками/ситуацией текущего бизнеса и делаться это должно с пониманием - пониманием как технических аспектов так и цены для бизнеса (в которую входит и неудобство разработчиков в том числе).
А ещё можно дураков не брать на работу.
Очень часто пользователи вводят пароль в форму для логина. Далее в логах все это отображается.
Важно не просто отключать доступ, а внедрять комплексный подход - аудит, мониторинг, многоуровневую аутентификацию и контроль действий. Иначе получится как с замком на двери, если ключи лежат под ковриком
А там ssh ключи использовать.... Открытый и закрытый ключ.... И входить вообще без паролей....
Или я чего то не понимаю?
Как еще не надо делать (из недавнего)
некоторые передают пароли в java процессы через -D параметры
и генерируют heap dump когда вылетает по OutOfMemory
потом надо же проверить почему свалилось и вытаскивают heap dump к себе на ноут и бинго -- все пароли видны
хотя продакшн защищен насколько возможно (OTP, audit, пароли никто не видит кроме того кто логинится и тд)
проблема: heap dumo содержит коммандную строку
следствие: смена паролей и головная боль на неделю
...
Как я поймал сетевика на передаче пароля в SSH и чем это закончилось