К сожалению, всё это звучит как "делайте хорошо, а плохо - не делайте".
В целом, конечно, идеология нужна и важна. Западу в этом качестве хватает бабок, но у нас другой менталитет. Но и Китай абсолютно не похож на что-то, что хочется скопировать себе. И обратно в СССР совершенно не хочется. Хочется в "Мир Полу́дня" Стругацких.
В Gentoo прекрасно работает Steam, и лично я ещё не сталкивался на https://www.protondb.com/ с какими-то виндовыми играми которые не идут под линухом (хотя, конечно, они наверняка существуют, просто их явно не так много, как можно подумать). Зачем вообще держать винду для игр?
А я думаю, что подстава в совершенно другом месте. Теперь станет очень просто давить (на) мелкий/средний бизнес: достаточно иметь заранее открытое дело, в котором внезапно всплывают новые улики (анонимка, скриншот, etc.), по которым счета этого бизнеса внезапно блокируются. Да, потом выяснится, что где-то закралась ошибка, но за это время у бизнеса могут образоваться просто капитальные проблемы. А это открывает кучу возможностей в конкурентной борьбе, достаточно "занести" следователю - и нет больше конкурента.
Это было грубо и с переходом на личности, не надо так.
В том, что принято относить к конспирологии, действительно хватает странных личностей, которые очень помогают дискредитировать всю тему. Но, тем не менее, считать что любые заговоры это фикция - тоже довольно глупо. В детском саду заговоры есть, в школе есть, на работе внутри коллектива есть, а в большом бизнесе и политике они внезапно куда-то деваются и остаются только "поехавшие конспирологи"? Так не бывает, люди - везде люди.
Это вопрос восприятия. Не нужно воспринимать контейнеры аналогом виртуалок или железных серверов - они этим не являются.
Контейнер - это обычный процесс/приложение, просто дополнительно ограниченное ядром в плане того, что это приложение видит. Грубо говоря, контейнер намного ближе к запуску бинарника в chroot чем к виртуалке.
Поэтому в плане управления и мониторинга от контейнеров нужно ждать примерно того же, что и от любых процессов - т.е. только тех возможностей, которые реализованы в самом приложении. Всё, что докер даёт сверх этого - это "дополнительная фича", а не "урезанный вариант того что доступно для виртуалок".
Как вариант, ставите на сервак netdata (можно тоже в докере), и получаете обзервабилити выше крыши, включая и для контейнеров докера.
И как это может навредить безопасности? Докер же крутится в той же виртуалке, безопасность которой Вас устраивает. Значит за ядром в виртуалке Вы уже следите. А в остальном разницы никакой нет, просто базовые образы тоже надо обновлять - ровно так же, как и виртуалки.
для контейнеров надо брать контейнерные штуки вроде wolffie, from scratch, distroless etc.
Что значит "нужно"? Кому нужно и для чего? Обычно эти штуки берут как раз для усиления безопасности (чем меньше в образе лишних приложений тем меньше возможных векторов для атаки). Но если ваш ИБ считает что у "контейнерных штук" безопасность хуже, то он может вместо них брать и ubuntu:latest. Размер образа будет больше, но в остальном особой разницы нет.
Ну, статически собранные бинарники тоже можно деплоить не докерами. Докер вообще придумали не для "статики". Но в большинстве проектов есть не только статика. Впрочем, если у Вас весь проект состоит исключительно из статики фронта, то докер действительно может быть ненужен.
И почему это проблема ИБ, а не бизнеса? Если бизнесу ИБ не нужен - пусть накрутят дичь. Если бизнесу ИБ нужен, и дичь неприемлема - почему бизнес не выделяет ИБ необходимые для "сделать нормально" ресурсы? Тут где-то что-то явно не стыкуется:
или начальник ИБ не в состоянии донести до бизнеса то, что необходимо выделить ресурсы под эти задачи,
или бизнесу это на самом деле не нужно а ИБ просто удовлетворяет собственный синдром вахтёра,
или от ИБ бизнес требует создать видимость работы дёшево, но тогда не надо доказывать адекватность этой видимости работы с технической точки зрения на хабре,
или бизнес просто не осознаёт реальную цену излишних запретов ИБ.
"Решать" проблемы тупо запрещая что можно и что нельзя - этот приём активно используется в политике. Может в политике он и работает, не могу судить. Но в бизнесе этот подход совершенно точно вредит бизнесу.
честно говоря, для большинства бизнесов докер вообще не нужен. И вообще им контейнеризация не решает ни одной задачи )
Может ни одной задачи отдела ИБ это и не решает, а вот задачи разработчиков - очень даже решает. Разработчики все дружно перешли на докер потому, что их жизнь от этого стала легче. А когда жизнь у разработчиков легче - бизнесу разработка стоит дешевле, в некоторых случаях - заметно дешевле.
Так что если ИБ не делает свою работу полноценно "потому что за это не заплатили" но при этом навязывает запреты "на всякий случай", то нужно понимать, что бизнесу эти запреты обходятся значительно дороже, чем оплата времени ИБ на придумывание и внедрение этого запрета. Безопасность и удобство обычно находятся по разные стороны, а неудобство - это лишние затраты времени, а время - деньги.
Поэтому лично я против театра безопасности. Когда что-то делается для усиления ИБ - это должно быть оправдано реальными нуждами/рисками/ситуацией текущего бизнеса и делаться это должно с пониманием - пониманием как технических аспектов так и цены для бизнеса (в которую входит и неудобство разработчиков в том числе).
В докере чуть больше рисков, чем в виртуализации. Но ведь и в виртуализации больше рисков чем в использовании отдельных железных серверов. Это вопрос баланса. И в докере есть достаточно много способов ограничить контейнеры, чтобы в большинстве случаев более высокими рисками по сравнению с виртуализацией можно было спокойно пренебречь. Поэтому если у ИБ нет чёткого и здравого аргумента какие конкретно риски для бизнеса они закрывают заменой докера на виртуализацию либо соответствие каким критичным для бизнеса стандартам это обеспечивает, то вероятнее всего отдел ИБ творит фигню - обычно из-за собственной низкой квалификации или синдрома вахтёра.
Вы всё говорите правильно, и я с этим не спорю. В компаниях где реально внедрены любые стандарты ИБ есть адекватный аудит, и там отключать PermitRootLogin действительно есть смысл. Но помимо таких компаний есть те, которые до этого уровня зрелости ещё не доросли - их намного больше, и в них зачастую процветают карго-культы и театры безопасности вместо реальной ИБ.
вы самостоятельно расследовали инциденты по логам? я вот да
Я тоже да. Поэтому и говорю, что надеяться на это нельзя - пока процессы аудита не были поставлены и протестированы всегда есть высокая вероятность, что в логах будет что-то бесполезное вроде локального IP или вообще не будет нужного или сами логи будут удалены. Иными словами, я не против отключения PermitRootLogin, я за то, чтобы его выключали не "по умолчанию", а при наличии понимания что конкретно это даст в текущей ситуации. Хотя бы на минимальном уровне: адекватно настроенный sudoers, наличие алертов на sudo bash сотоварищи которые кто-то реально получает и на которые обязательно реагирует, проведённый анализ логов показывающий возможность отследить кто и что делает, хоть какая-то защита логов от удаления.
главный риск такой чтобы сервис был не взломан, если взломан то минимально поврежден, если поврежден сильно то был быстро восстановлен с закрытием дырок через которые он был скомпроментирован.
Это типичная точка зрения технаря. С точки зрения бизнеса всё не так однозначно - ущерб вполне может оказаться застрахован либо "лечь" на того, кого "не жалко". Концепция "нам надо только точно знать кто виноват в инциденте" тоже имеет право на жизнь, если это требование необходимо для того, чтобы обеспечить гладкое получение той же страховки, например, или просто перенос ответственности чтобы какого-нибудь топа не назначили виноватым за инцидент. Мы работаем на бизнес и для бизнеса, закрываем его потребности, и они далеко не всегда совпадают с идеальными техническими решениями - к сожалению.
А чем это поможет в скрипте? ProxyJump нужен чтобы пройти через периметр, но никак не поможет в скрипте обойтись без пароля или беспарольного сертификата.
Когда процесс переписывает эту инфу всегда есть промежуток времени, когда он уже запустился, но ещё не переписал - он не очень большой, но во-первых может тупо повезти, а во-вторых если мониторить запуск чужих процессов скриптом то шанс увидеть оригинальные аргументы сильно увеличивается.
реалистичные сценарии есть такие о которых вы не догадаетесь
Есть. Но это не повод для карго-культа и театра безопасности. Предпринимая какие-то действия "для безопасности" стоит понимать, какие конкретно риски и сценарии атак эти действия прикрывают. Тупо механически выключать везде PermitRootLogin просто потому, что так 20 лет назад порекомендовали где-то в интернете плюс в директиве есть страшное слово "root" - так себе идея.
если в логах написано
Как я с самого начала говорил, если в компании настроен полноценный аудит - то PermitRootLogin действительно нужно отключить, иначе он этому аудиту будет мешать. Но - это далеко не единственное, что нужно сделать, потому что sudo bash этому аудиту будет мешать ровно так же. И нет, надеяться на то, что "если что - что-нибудь по логам накопаем" - это и близко не эквивалент состоянию "настроен полноценный аудит".
Вообще, я в эту сторону давненько не смотрел, но вроде были какие-то способы логировать все exec-и на уровне сисколов. Если аудит делать на этом уровне, а не надеяться на "непробиваемый" /etc/sudoers, то и PermitRootLogin может аудиту не особо мешать - кто именно зашёл под рутом видно по тому, какой из ключей использовался, а дальше к нему привязан аудит по exec-ам.
sudo решает (частично) вопрос аудита, не более того. Если в компании полноценного аудита нет - то PermitRootLogin yes может быть даже безопаснее, потому что sudo создаёт дополнительный вектор атаки (напр. вот, эскалация привилегий месячной давности: CVE-2025-32463).
Но, кстати, лет 15 назад у меня было сделано подобным образом. Тогда я зачем-то решил бэкапы со всех серверов сначала собрать на одном, и уже с него заливать в облако бэкапы всех серверов. Если не путаю, изначальная идея была в том, чтобы меньше зависеть от облаков и всегда иметь бэкапы локально на выделенном под это дело сервере. Но сейчас в этом особого смысла нет (а может и тогда тоже не было).
Очевидно же, скроллить табы зажав Ctrl-PgDown на 60fps. Это прям первое видео по Zed гордо демонстрирует!
Не очевидно?! Мне тоже. Но кому-то это нужно, наверное.
Впрочем, сам редактор неплохой. Не Neovim, конечно, :) но неплохой.
К сожалению, всё это звучит как "делайте хорошо, а плохо - не делайте".
В целом, конечно, идеология нужна и важна. Западу в этом качестве хватает бабок, но у нас другой менталитет. Но и Китай абсолютно не похож на что-то, что хочется скопировать себе. И обратно в СССР совершенно не хочется. Хочется в "Мир Полу́дня" Стругацких.
В Gentoo прекрасно работает Steam, и лично я ещё не сталкивался на https://www.protondb.com/ с какими-то виндовыми играми которые не идут под линухом (хотя, конечно, они наверняка существуют, просто их явно не так много, как можно подумать). Зачем вообще держать винду для игр?
А я думаю, что подстава в совершенно другом месте. Теперь станет очень просто давить (на) мелкий/средний бизнес: достаточно иметь заранее открытое дело, в котором внезапно всплывают новые улики (анонимка, скриншот, etc.), по которым счета этого бизнеса внезапно блокируются. Да, потом выяснится, что где-то закралась ошибка, но за это время у бизнеса могут образоваться просто капитальные проблемы. А это открывает кучу возможностей в конкурентной борьбе, достаточно "занести" следователю - и нет больше конкурента.
А вот и продолжение банкета подвезли: У проекта ядра Linux нет формального плана преемственности на случай ухода Линуса Торвальдса.
Это было грубо и с переходом на личности, не надо так.
В том, что принято относить к конспирологии, действительно хватает странных личностей, которые очень помогают дискредитировать всю тему. Но, тем не менее, считать что любые заговоры это фикция - тоже довольно глупо. В детском саду заговоры есть, в школе есть, на работе внутри коллектива есть, а в большом бизнесе и политике они внезапно куда-то деваются и остаются только "поехавшие конспирологи"? Так не бывает, люди - везде люди.
Это вопрос восприятия. Не нужно воспринимать контейнеры аналогом виртуалок или железных серверов - они этим не являются.
Контейнер - это обычный процесс/приложение, просто дополнительно ограниченное ядром в плане того, что это приложение видит. Грубо говоря, контейнер намного ближе к запуску бинарника в chroot чем к виртуалке.
Поэтому в плане управления и мониторинга от контейнеров нужно ждать примерно того же, что и от любых процессов - т.е. только тех возможностей, которые реализованы в самом приложении. Всё, что докер даёт сверх этого - это "дополнительная фича", а не "урезанный вариант того что доступно для виртуалок".
Как вариант, ставите на сервак netdata (можно тоже в докере), и получаете обзервабилити выше крыши, включая и для контейнеров докера.
И как это может навредить безопасности? Докер же крутится в той же виртуалке, безопасность которой Вас устраивает. Значит за ядром в виртуалке Вы уже следите. А в остальном разницы никакой нет, просто базовые образы тоже надо обновлять - ровно так же, как и виртуалки.
Что значит "нужно"? Кому нужно и для чего? Обычно эти штуки берут как раз для усиления безопасности (чем меньше в образе лишних приложений тем меньше возможных векторов для атаки). Но если ваш ИБ считает что у "контейнерных штук" безопасность хуже, то он может вместо них брать и ubuntu:latest. Размер образа будет больше, но в остальном особой разницы нет.
Ну, статически собранные бинарники тоже можно деплоить не докерами. Докер вообще придумали не для "статики". Но в большинстве проектов есть не только статика. Впрочем, если у Вас весь проект состоит исключительно из статики фронта, то докер действительно может быть ненужен.
И чем именно базовые образы вроде ubuntu:latest более уязвимы чем ровно эта же убунта в виртуалке?
И почему это проблема ИБ, а не бизнеса? Если бизнесу ИБ не нужен - пусть накрутят дичь. Если бизнесу ИБ нужен, и дичь неприемлема - почему бизнес не выделяет ИБ необходимые для "сделать нормально" ресурсы? Тут где-то что-то явно не стыкуется:
или начальник ИБ не в состоянии донести до бизнеса то, что необходимо выделить ресурсы под эти задачи,
или бизнесу это на самом деле не нужно а ИБ просто удовлетворяет собственный синдром вахтёра,
или от ИБ бизнес требует создать видимость работы дёшево, но тогда не надо доказывать адекватность этой видимости работы с технической точки зрения на хабре,
или бизнес просто не осознаёт реальную цену излишних запретов ИБ.
"Решать" проблемы тупо запрещая что можно и что нельзя - этот приём активно используется в политике. Может в политике он и работает, не могу судить. Но в бизнесе этот подход совершенно точно вредит бизнесу.
Может ни одной задачи отдела ИБ это и не решает, а вот задачи разработчиков - очень даже решает. Разработчики все дружно перешли на докер потому, что их жизнь от этого стала легче. А когда жизнь у разработчиков легче - бизнесу разработка стоит дешевле, в некоторых случаях - заметно дешевле.
Так что если ИБ не делает свою работу полноценно "потому что за это не заплатили" но при этом навязывает запреты "на всякий случай", то нужно понимать, что бизнесу эти запреты обходятся значительно дороже, чем оплата времени ИБ на придумывание и внедрение этого запрета. Безопасность и удобство обычно находятся по разные стороны, а неудобство - это лишние затраты времени, а время - деньги.
Поэтому лично я против театра безопасности. Когда что-то делается для усиления ИБ - это должно быть оправдано реальными нуждами/рисками/ситуацией текущего бизнеса и делаться это должно с пониманием - пониманием как технических аспектов так и цены для бизнеса (в которую входит и неудобство разработчиков в том числе).
А варианта и не делать работу и ничего не запрещать раз не платят - почему нет?
В докере чуть больше рисков, чем в виртуализации. Но ведь и в виртуализации больше рисков чем в использовании отдельных железных серверов. Это вопрос баланса. И в докере есть достаточно много способов ограничить контейнеры, чтобы в большинстве случаев более высокими рисками по сравнению с виртуализацией можно было спокойно пренебречь. Поэтому если у ИБ нет чёткого и здравого аргумента какие конкретно риски для бизнеса они закрывают заменой докера на виртуализацию либо соответствие каким критичным для бизнеса стандартам это обеспечивает, то вероятнее всего отдел ИБ творит фигню - обычно из-за собственной низкой квалификации или синдрома вахтёра.
Вы всё говорите правильно, и я с этим не спорю. В компаниях где реально внедрены любые стандарты ИБ есть адекватный аудит, и там отключать
PermitRootLoginдействительно есть смысл. Но помимо таких компаний есть те, которые до этого уровня зрелости ещё не доросли - их намного больше, и в них зачастую процветают карго-культы и театры безопасности вместо реальной ИБ.Я тоже да. Поэтому и говорю, что надеяться на это нельзя - пока процессы аудита не были поставлены и протестированы всегда есть высокая вероятность, что в логах будет что-то бесполезное вроде локального IP или вообще не будет нужного или сами логи будут удалены. Иными словами, я не против отключения
PermitRootLogin, я за то, чтобы его выключали не "по умолчанию", а при наличии понимания что конкретно это даст в текущей ситуации. Хотя бы на минимальном уровне: адекватно настроенный sudoers, наличие алертов на sudo bash сотоварищи которые кто-то реально получает и на которые обязательно реагирует, проведённый анализ логов показывающий возможность отследить кто и что делает, хоть какая-то защита логов от удаления.Это типичная точка зрения технаря. С точки зрения бизнеса всё не так однозначно - ущерб вполне может оказаться застрахован либо "лечь" на того, кого "не жалко". Концепция "нам надо только точно знать кто виноват в инциденте" тоже имеет право на жизнь, если это требование необходимо для того, чтобы обеспечить гладкое получение той же страховки, например, или просто перенос ответственности чтобы какого-нибудь топа не назначили виноватым за инцидент. Мы работаем на бизнес и для бизнеса, закрываем его потребности, и они далеко не всегда совпадают с идеальными техническими решениями - к сожалению.
А чем это поможет в скрипте? ProxyJump нужен чтобы пройти через периметр, но никак не поможет в скрипте обойтись без пароля или беспарольного сертификата.
Когда процесс переписывает эту инфу всегда есть промежуток времени, когда он уже запустился, но ещё не переписал - он не очень большой, но во-первых может тупо повезти, а во-вторых если мониторить запуск чужих процессов скриптом то шанс увидеть оригинальные аргументы сильно увеличивается.
Есть. Но это не повод для карго-культа и театра безопасности. Предпринимая какие-то действия "для безопасности" стоит понимать, какие конкретно риски и сценарии атак эти действия прикрывают. Тупо механически выключать везде
PermitRootLoginпросто потому, что так 20 лет назад порекомендовали где-то в интернете плюс в директиве есть страшное слово "root" - так себе идея.Как я с самого начала говорил, если в компании настроен полноценный аудит - то
PermitRootLoginдействительно нужно отключить, иначе он этому аудиту будет мешать. Но - это далеко не единственное, что нужно сделать, потому чтоsudo bashэтому аудиту будет мешать ровно так же. И нет, надеяться на то, что "если что - что-нибудь по логам накопаем" - это и близко не эквивалент состоянию "настроен полноценный аудит".Вообще, я в эту сторону давненько не смотрел, но вроде были какие-то способы логировать все exec-и на уровне сисколов. Если аудит делать на этом уровне, а не надеяться на "непробиваемый"
/etc/sudoers, то иPermitRootLoginможет аудиту не особо мешать - кто именно зашёл под рутом видно по тому, какой из ключей использовался, а дальше к нему привязан аудит по exec-ам.sudoрешает (частично) вопрос аудита, не более того. Если в компании полноценного аудита нет - тоPermitRootLogin yesможет быть даже безопаснее, потому чтоsudoсоздаёт дополнительный вектор атаки (напр. вот, эскалация привилегий месячной давности: CVE-2025-32463).О, точно, есть же такая фича! Спасибо.
Но, кстати, лет 15 назад у меня было сделано подобным образом. Тогда я зачем-то решил бэкапы со всех серверов сначала собрать на одном, и уже с него заливать в облако бэкапы всех серверов. Если не путаю, изначальная идея была в том, чтобы меньше зависеть от облаков и всегда иметь бэкапы локально на выделенном под это дело сервере. Но сейчас в этом особого смысла нет (а может и тогда тоже не было).