Есть старое правило: если можно сделать быстро и удобно, кто‑то обязательно сделает это в ущерб безопасности. В инфраструктурных командах это особенно заметно. Сетевики часто решают задачи «с лёту», и это прекрасно. Пока речь не заходит про пароли. Один из таких случаев стал для нас уроком На первый взгляд — мелочь, но последствия могли быть куда серьёзнее.
Как всё началось
Обычный рабочий день. Я проверял список процессов на сервере (ps aux) и вдруг вижу:
bash
sshpass -p 'Qwerty123' ssh admin@10.0.5.21Пароль. В открытом виде. В командной строке.
Подошёл к коллеге:
— Это что за магия?
— Скрипт для быстрого доступа, чтобы пароль не вводить каждый раз.
— Ты в курсе, что этот пароль может увидеть любой пользователь на сервере?
— Ну мы же внутри сети
— До первого
psили попадания в логи.
Через пару часов у нас уже был внеплановый аудит.
Почему это проблема:
Передача пароля в аргументах — это классический антипаттерн.
Аргументы команд видны в
ps,/proc/[PID]/cmdline, Task Manager.Они могут попасть в логи CI/CD.
Мониторинг и аудит тоже их подхватят.
Многие утилиты (
sshpass,plink,WinSCP CLI,rsync,mysql,curl,mRemoteNG) позволяют так передавать пароль — и это соблазн для быстрого «костыля».
В итоге получить пароль можно, даже не трогая сам SSH.
Как искать такие случаи
Windows (PowerShell)
powershell
$insecureProcs = Get-CimInstance Win32_Process | Where-Object {
$_.CommandLine -match '\-p\s' -or $_.CommandLine -match '\-pw\s' -or $_.CommandLine -match '--password=' -or $_.CommandLine -match '/password='
} | Select-Object ProcessId, Name, CommandLine
$insecureProcs | Format-Table -AutoSizeLinux (bash)
bash
ps -eo pid,user,command --no-header | while read PID USER CMD; do
if [[ "$CMD" =~ -p ]] || [[ "$CMD" =~ -pw ]] || [[ "$CMD" =~ --password= ]] || [[ "$CMD" =~ /password= ]]; then
echo "PID=$PID USER=$USER CMD=$CMD"
fi
doneКак мы «засветили» пароль в проде
Оказалось, что у нас крутился ночной бэкап через cron с командой:
bash
sshpass -p 'MySecret123' ssh backup@10.1.1.25На сервере работали и другие пользователи. Пароль всплыл в мониторинге процессов.
В довесок Jenkins сохранил эту же команду в логи пайплайна, доступные всем участникам проекта. Пришлось срочно менять ключи, чистить задачи и усиливать контроль.
Мини-справочник уязвимых инструментов
Инструмент |
Параметр пароля |
Где светится |
sshpass |
-p |
ps, /proc |
plink / pscp |
-pw |
Task Manager |
WinSCP CLI |
/password= |
cmdline |
rsync |
--password-file |
при доступном файле |
curl / wget |
http://user:pass@ |
аргументы |
mysql |
--password= |
предупреждение |
smbclient |
user%pass |
ps |
Jenkins |
sh "sshpass..." |
логи |
Что внедрить в процесс
Linux — cron‑сканеры, Ansible, shell‑скрипты.
Windows — PowerShell + логирование.
CI/CD — линтеры и сканеры (Checkov, KICS, Semgrep).
IDE — pre‑commit хуки, запрещающие команды с паролем в аргументах.
Пример правила для Semgrep:
yaml
pattern: sshpass -p $PASS ...
message: 'Пароль передается в командной строке — это небезопасно.'
severity: ERRORКак делать безопасно:
Использовать
ssh-agentи ключи без паролей в скриптах.Хранить секреты в Vault, AWS Secrets Manager, Ansible Vault.
Прятать учётки в
.pgpass,.my.cnf,.netrc(права 600).Разграничивать доступ: никто кроме root не должен видеть чужие процессы.
Ограничивать или удалять опасные утилиты (
sshpassи пр.).В случаях когда необходимо хранить секреты в файлах использовать кодировку
Вывод
Одна невинная оптимизация могла обернуться утечкой. Мы нашли и закрыли дыру, добавили регулярные проверки, а коллега перешёл на ключи.
Совет: проверьте свои сервера прямо сейчас. Если пароли в аргументах есть — убирайте немедленно. Такие мелочи могут стоить гораздо дороже, чем пять минут на настройку.
P. S. Был ли у вас подобный опыт? Расскажите, как находили и закрывали такие дыры. Возможно, получится собрать полезную подборку практик.
Комментарии (130)
Cyber_Griffin
12.08.2025 09:26Классика жанра:
«Зачем хранить пароли в секретах, если можно простоsshpass -p "12345"?»
Реальность: Через 5 минут этот пароль уже в логах, мониторинге и чате DevOps-ов.
volshara85
12.08.2025 09:26Реальность, сами Девопсы этот скрипт и накарябали на коленке)
gecube
12.08.2025 09:26Девопс Инженера не существует! Это МИФ
Cyber_Griffin
12.08.2025 09:26Если бы его не было, кто бы: Рвал волосы из-за
kubectl apply -f, который снова упал? Объяснял продакшн-инженерам, что «в докере не надоsudo rm -rf /»? Терпел вопросы в духе «Почему CI/CD пайплайн сломался? Мы же ничего не меняли!», проходили)))
ValdikSS
12.08.2025 09:26Использовать ssh-agent и ключи без паролей в скриптах.
Это плохой совет, потому что стандартный ssh-agent просто предоставляет доступ к ключу, без всяких ограничений и подтверждений. Любое вредоносное ПО на сервере сможет пользоваться ключом подключённого администратора и подключаться к другим серверам.
powerman
12.08.2025 09:26Ну, это всё-таки лучше, чем светить паролем. Кроме того - а какие есть доступные альтернативы?
ValdikSS
12.08.2025 09:26Для резервного копирования по 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 доступ.
powerman
12.08.2025 09:26Да нет, с бэкапом всё просто - у меня сервера его сами делают и заливают в облако, ssh тут вообще не нужна. Я в общем случае про задачу "ssh в скрипте", для которой обычно и используются беспарольные ключи - когда такая задача триггерится не на самом сервере (как возможно сделать в случае с бэкапами) а снаружи.
ValdikSS
12.08.2025 09:26Я обычно завожу уникальный ключ, которому указываю
command=…(forced command), чтобы этим ключом нельзя было сделать ничего недозволенного.
artemisia_borealis
12.08.2025 09:26Отличный способ. Издавна так делаю для специального пользователя для доступа к репам. И у этого пользователя в authorized_keys прописано для каждого ключа, куда именно владелец ключа имеет доступ. Именно через command="..."
Fedorkov
12.08.2025 09:26Приватный SSH-ключ лежит ведь в домашней директории пользователя? Чем это лучше, чем хранить его в агенте?
ValdikSS
12.08.2025 09:26В описанном сценарии это особо не принципиально. Если у вас отдельный привилегированный пользователь для создания бэкапа на машине, то нет разницы, лежит ли у него ключ файлом или добавлен в агент.
powerman
12.08.2025 09:26Но, кстати, лет 15 назад у меня было сделано подобным образом. Тогда я зачем-то решил бэкапы со всех серверов сначала собрать на одном, и уже с него заливать в облако бэкапы всех серверов. Если не путаю, изначальная идея была в том, чтобы меньше зависеть от облаков и всегда иметь бэкапы локально на выделенном под это дело сервере. Но сейчас в этом особого смысла нет (а может и тогда тоже не было).
mayorovp
12.08.2025 09:26Для домашней директории выставляем права доступа drwxr-x--x, пользователь и группа — root
А это разве работает? Обычно же выдаёт ошибку "домашняя директория пользователя должна принадлежать ему самому" и отказывает в подключении.
ValdikSS
12.08.2025 09:26Если память не изменяет, главное, чтобы у других пользователей (в смысле other) не было доступа на запись в домашнюю директорию. Мой сетап работает со
StrictModes yes.
slonopotamus
12.08.2025 09:26какие есть доступные альтернативы?
ProxyJump
powerman
12.08.2025 09:26А чем это поможет в скрипте? ProxyJump нужен чтобы пройти через периметр, но никак не поможет в скрипте обойтись без пароля или беспарольного сертификата.
slonopotamus
12.08.2025 09:26Оно помогает не создавать дыру на промежуточных хопах, через которую можно вытащить ваще все ключи с управляющей машины, предыдущий комментатор говорил именно об этом.
omaxx
12.08.2025 09:26Вот только это работает до тех пор пока особенно рьяный безопасник не поставит AllowTcpForwarding=no на сервере.
kmeaw
12.08.2025 09:26На такие случаи есть
ssh -o 'ProxyCommand=ssh jumphost nc %h %p'Если, конечно, кто-то не удалит все программы, умеющие соединять TCP и stdin/stdout.
mayorovp
12.08.2025 09:26Любое вредоносное ПО на сервере сможет пользоваться ключом подключённого администратора и подключаться к другим серверам.
Только запущенное от имени того же пользователя, потому что сокет имеет права 600.
omaxx
12.08.2025 09:26А вот это уже вопрос к ИБ, откуда на сервере вредоносное ПО, которое может получить доступ к read-only файлам пользователя...
isden
12.08.2025 09:26Semgrep
Эта та штука, которая для работы хочет логин в их SaaS, и передает данные для анализа на их сервера? Я сходу не увидел у них на сайте как задеплоить полностью локальный инстанс.
inkvizitor68sl
12.08.2025 09:26sshpass -p 'Qwerty123' ssh admin@10.0.5.21
Ну враньё же.
1729664 pts/10 S+ 0:00 sshpass -p xxxxxxxxxxxxx ssh ...И это весьма старая версия ещё.
powerman
12.08.2025 09:26Когда процесс переписывает эту инфу всегда есть промежуток времени, когда он уже запустился, но ещё не переписал - он не очень большой, но во-первых может тупо повезти, а во-вторых если мониторить запуск чужих процессов скриптом то шанс увидеть оригинальные аргументы сильно увеличивается.
inkvizitor68sl
12.08.2025 09:26м, да, моя неправда -(
думал, что они что-то хитрее делают, чем cmdline после запуска меняют
edo1h
12.08.2025 09:26это не всегда работает так, как хотелось
например, у меня есть железка с логами в cp1251, я прямо сейчас наблюдаю в ps2144581 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
Nalivai
12.08.2025 09:26sshpass может брать пароль из файла. Тоже не бог весть, но по крайней мере пароль открытым текстом нигде не светится.
Wesha
12.08.2025 09:26sshpass может брать пароль из файла. Тоже не бог весть, но по крайней мере пароль открытым текстом нигде не светится.
Эммммм... а в файле?
omaxx
12.08.2025 09:26а чем файл с паролем хуже файла с приватным ключем?
unC0Rr
12.08.2025 09:26Файл с приватным ключом может быть запаролен.
omaxx
12.08.2025 09:26может... но в статье идет речь про скрипты, запускаемые автономно через cron...
gecube
12.08.2025 09:26Файл с приватным ключом может быть запаролен.
как доказано опытом поколений - к безопасности это не добавляет.
Если файл утек (даже под паролем) - ключи надо менять
askharitonov
12.08.2025 09:26Эммммм... а в файле?
В файле лучше, чем в списке процессов, который может просмотреть другой пользователь.
MaxLK
12.08.2025 09:26Вот же гниды эти сетевики! Не то что остальные принцы в золотых доспехах на белых конях.
Видимо автору в детстве сетевик нанес глубокую травму...
gecube
12.08.2025 09:26из списка рекомендаций:
Использовать
ssh-agentи ключи без паролей в скриптах.Хранить секреты в Vault, AWS Secrets Manager, Ansible Vault.
Прятать учётки в
.pgpass,.my.cnf,.netrc(права 600).Разграничивать доступ: никто кроме root не должен видеть чужие процессы.
Ограничивать или удалять опасные утилиты (
sshpassи пр.).В случаях когда необходимо хранить секреты в файлах использовать кодировку
три откровенное говно.
ssh-agent - если он запущен, то любой процесс на хосте может к нему подцепиться.
прятать учетки в файлах конфигов - они есть на файловой системе. Вы же ее не шифруете? А любой безобидный кронтаб и пользователь уже рут и читает все файлы
кодировка - ну, типа base64? Смешно.
То есть этими рекомендациями вы не избавляетесь от основной проблемы - необходимость смены пароля в случае его компрометации. А чтобы от нее уйти - надо... внезапно... уйти от паролей. Даже короткоживущие сертификаты будут лучше. Ну, и, видимо, как я их и не люблю, но так любимые безопасниками - списки контролей доступа (ACL) или же "белые списки" доверенных IP адресов.
0xC0CAC01A
12.08.2025 09:26А безопасные и практичные способы есть?
gecube
12.08.2025 09:26в облаке проблема решается через IAM/IRSA (Amazon) и workload identity (в случае Google).
На on-premise - только костылить. Но в целом штуки вроде https://github.com/spiffe/spire именно за этим и нужны.
Вообще тут интересно засаммонить безопасников - пускай они отдуваются, как профильные специалисты. Так-то они веселые ребята - кого-то критиковать - это завсегда. А самим что-то предложить и побыть критикуемыми? Или так нельзя?
Jalart
12.08.2025 09:26А как тогда, например, настраивать бекапы для MySQL с доступом по паролю, если в строке пароль передавать нельзя или хранить в конфигах.
Можно более развёрнуто?gecube
12.08.2025 09:26если бекап с той же машины - MySQL, Pg прекрасно аутентифицируют под линукс учеткой. В этом случае Вы смещаете проблему.
Если же договориться, что брать пароль из волта или подобного - тоже норм, тоже по сути смещаем проблему. Пароль нигде в открытом виде не хранится, но чтобы сходить в волт тоже нужен токен или что-то подобное. Система действительно усложняется, но упрощается аудит и упрощается ротация паролей в случае факапа.
omaxx
12.08.2025 09:26ssh-agent - если он запущен, то любой процесс на хосте может к нему подцепиться.
может все-таки не любой, а только запущенный от рута или того же пользователя?
gecube
12.08.2025 09:26при должной степени ловкости - любой.
omaxx
12.08.2025 09:26А можно поподробнее?
А так же про "любой безобидный кронтаб и пользователь уже рут и читает все файлы"
gecube
12.08.2025 09:26например, https://snehbavarva.medium.com/privilege-escalation-techniques-series-linux-cron-jobs-a5b797b424b4
По su / sudoers - история тоже известная. В самом sudo пачка уязвимостей https://habr.com/ru/companies/kaspersky/articles/925604/
Чуточку добавьте любознательности
omaxx
12.08.2025 09:26Там не про ловкость, а про криво настроенную систему...
gecube
12.08.2025 09:26аксиома - идеально настроенных систем не бывает. Тем более в любой сколько нибудь сложной системе всегда найдутся проблемы. Уязвимые пермиссии, например, могут приехать из пакетного менеджера. Или неудачной установки, скажем, https://github.com/kubernetes-sigs/kubespray/issues/4824 https://github.com/kubernetes-sigs/kubespray/issues/6891 Жесть же. Именно поэтому контейнеризация не защищает - из нее гораздо легче выбраться, чем из виртуализации (там только штуки вроде Spectre и Meltdown, да дырки в гиперах позволяют выбраться).
omaxx
12.08.2025 09:26Ну если вы допускаете, что к вашему серверу злоумышленник может получить root доступ, то какой смысл дальше обсуждать, что надежнее: пароль, сертификат или еще что-то? Ко всему у него будет такой же доступ, как и у легитимных программ..
Ну и если так рассуждать, то в винде дыр не меньше... Может ваш ноут вирусами заражен и давно уже слил все ваши логины, пароли и ключи. Такой вариант вы не рассматриваете?
gecube
12.08.2025 09:26я не сказал, что рут. Если есть ssh под непривилегированным пользователем - как мы выяснили - можно эскалироваться до рута. Если есть сервисы, которые доступны по сети - тоже. Хотя это и сложнее.
Может ваш ноут вирусами заражен и давно уже слил все ваши логины, пароли и ключи. Такой вариант вы не рассматриваете?
я уже сто лет в обед пользуюсь менеджерами паролей вроде 1password и Proton Pass.
mayorovp
12.08.2025 09:26Если мы допускам, что любой пользователь на сервере может стать рутом если просто достаточно захочет, то единственной рабочей рекомендацией будет вообще не доверять ничего этому серверу.
Потому что от подмены бинарника ssh не защитят ни короткоживущие сертификаты, ни даже белые списки IP адресов.
omaxx
12.08.2025 09:26Все правильно. И вот здесь то служба ИБ и нужна. Раз есть некий выделенный сервер, с которого можно получить доступ на всю сеть, то нужно следить кто имеет доступ к этому серверу, а не превращать его в проходной двор. И дыры в безопасности затыкать вовремя.
gecube
12.08.2025 09:26ну, да, без аудита тут не обойтись, что еще раз доказывает, что ИБ это комплексная история.
CorruptotronicPervulator
12.08.2025 09:26Я проверял список процессов на сервере
(ps aux)и вдруг вижуhidepid=2 спасёт гиганта мысли.
trabl
12.08.2025 09:26Интересно, а автор на этот сервер тоже с паролем заходил или с ключом?) Стандартные absible роли для настройки новых серверов решают эти проблемы.
TRAPPIST
12.08.2025 09:26Как то пришлось в 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%"В итоге у охранников при включении ПК запускалось видеонаблюдение автоматически и под правами админа, ничего у них не спрашивая. Это тоже конечно утечка пароля админа, но он хотя бы не доменный а локальный для отдельно взятого ПК.
karavan_750
12.08.2025 09:26А почему не runas?
avelor
12.08.2025 09:26Runas плохой вариант, он позволяет потом запускать с правами пользователя любой бинарь с тем же именем. Тут вот пособирали вариантов https://habr.com/ru/companies/servermall/articles/485958/
Protos
12.08.2025 09:26Что внедрить в процесс
Linux — cron‑сканеры, Ansible, shell‑скрипты.
Windows — PowerShell + логирование.
CI/CD — линтеры и сканеры (Checkov, KICS, Semgrep).
IDE — pre‑commit хуки, запрещающие команды с паролем в аргументах.
Инструменты понятные, но я не понимаю как это поможет защититься от нерадивого сетевика?
lsdb
12.08.2025 09:26к слову, ansible под капотом использует этот же sshpass для подключений ssh по паролю (ansible_ssh_pass), используйте ключи
PjaniyAdmin
12.08.2025 09:26Всегда прикалываюсь с таких ситуаций. Есть специализированный сервак с скриптами, ИБ как самые умные начинают везде лезть, требовать доступ и т.д.. И начинается "ой вы делаете не так" проблема не в не вне так, проблема в том что кто-то влез в ресурс где быть никого не должно. И воспользовался для этого административным давлением. Это как сказать "вот приказ директора - дай пароль" а потом "вот видишь, я под твоим паролем, ты его плохо хранищь".
А потом начинается, вот мы крутое ИБ, глядите как мы круто добыли доступы, и не важно как мы их добыли :) гребаный цирк, вам самим над собой ржать не хочется?
profotocor
12.08.2025 09:26ИБ - центр создания проблем, а не их решений! Миллион примеров могу привести "весёлых" указаний этих чудо-специалистов по эксплуатации сканеров безопасности и другого типа ИБэшного ПО.
Chelyuk
12.08.2025 09:26У меня была куча обратных проблем. Доступы делают по 4 месяца. В целом мне норм, деньги платят, доступы ждёшь, но менеджеры нервничают.
Доступ на тестовый сервер на AWS, только из внутренней сети, никакого порта наружу. Пришлось городить ssh туннели. ХЗ, кому от этого было лучше.
Самое эпичное - докер нельзя, потому что не безопасно, используй виртуализацию. Так мне внятно и не объяснили, почему виртуализация безопасней докера. Из полезного пришлось выучить Vagrant и Terraform. Из минусов тестовый энв разворачивался 20 минут, вместо 3х ну кубере. Ну и пришлось требовать больше оперативной памяти.gecube
12.08.2025 09:26Самое эпичное - докер нельзя, потому что не безопасно, используй виртуализацию. Так мне внятно и не объяснили, почему виртуализация безопасней докера
потому что. Иди почитай матчасть, бро. Если вдруг не получится - приходи, расскажу.
Из минусов тестовый энв разворачивался 20 минут, вместо 3х ну кубере
ну, 3 vs 20 не так уж страшно. А вот 3 vs 300 - беда.
powerman
12.08.2025 09:26В докере чуть больше рисков, чем в виртуализации. Но ведь и в виртуализации больше рисков чем в использовании отдельных железных серверов. Это вопрос баланса. И в докере есть достаточно много способов ограничить контейнеры, чтобы в большинстве случаев более высокими рисками по сравнению с виртуализацией можно было спокойно пренебречь. Поэтому если у ИБ нет чёткого и здравого аргумента какие конкретно риски для бизнеса они закрывают заменой докера на виртуализацию либо соответствие каким критичным для бизнеса стандартам это обеспечивает, то вероятнее всего отдел ИБ творит фигню - обычно из-за собственной низкой квалификации или синдрома вахтёра.
gecube
12.08.2025 09:26В докере чуть больше рисков, чем в виртуализации.
не чуть больше. А значительно больше (больше деталей, движущихся компонентов, достаточно высокая степень незрелости экосистемы и самое главное - возможно тащить недоверенный код с помойки в виде докерхаба). Теоретически ограничить докер можешь. Но это куча работы. Кто ее делать будет?
Но ведь и в виртуализации больше рисков чем в использовании отдельных железных серверов
тоже правда
Это вопрос баланса
да
Поэтому если у ИБ нет чёткого и здравого аргумента какие конкретно риски для бизнеса они закрывают заменой докера на виртуализацию либо соответствие каким критичным для бизнеса стандартам это обеспечивает, то вероятнее всего отдел ИБ творит фигню - обычно из-за собственной низкой квалификации или синдрома вахтёра.
честно говоря, для большинства бизнесов докер вообще не нужен. И вообще им контейнеризация не решает ни одной задачи ) Запихать 10 разных сервисов на один сервер? Ну, камон. Смешно. 10 ВМ прекрасно работает. 10 железяк - да, может быть тупо избыточно по ресурсам (но во многих компаниях деньги на железо-то и не считают внезапно).
mayorovp
12.08.2025 09:26Теоретически ограничить докер можешь. Но это куча работы. Кто ее делать будет?
Ну да, правильно. Зачем делать работу, если можно просто всё запретить?
DMGarikk
12.08.2025 09:26чтобы делать работу за неё надо заплатить, а кто будет за это платить? никто...по этому запретить проще
powerman
12.08.2025 09:26А варианта и не делать работу и ничего не запрещать раз не платят - почему нет?
DMGarikk
12.08.2025 09:26если не делать работу и не запрещать, то сотрудники на местах самодеятельно накрутят всякой дичи бесконтрольно.
Это уже много раз пройдено
powerman
12.08.2025 09:26И почему это проблема ИБ, а не бизнеса? Если бизнесу ИБ не нужен - пусть накрутят дичь. Если бизнесу ИБ нужен, и дичь неприемлема - почему бизнес не выделяет ИБ необходимые для "сделать нормально" ресурсы? Тут где-то что-то явно не стыкуется:
или начальник ИБ не в состоянии донести до бизнеса то, что необходимо выделить ресурсы под эти задачи,
или бизнесу это на самом деле не нужно а ИБ просто удовлетворяет собственный синдром вахтёра,
или от ИБ бизнес требует создать видимость работы дёшево, но тогда не надо доказывать адекватность этой видимости работы с технической точки зрения на хабре,
или бизнес просто не осознаёт реальную цену излишних запретов ИБ.
"Решать" проблемы тупо запрещая что можно и что нельзя - этот приём активно используется в политике. Может в политике он и работает, не могу судить. Но в бизнесе этот подход совершенно точно вредит бизнесу.
isden
12.08.2025 09:26достаточно высокая степень незрелости экосистемы
Позвольте я влезу в вашу дискуссию.
Вы сейчас про докерхаб же? Тут есть варианты, например свой реп.
gecube
12.08.2025 09:26варианты есть всегда ) но это больно. Все равно базовые образы надо откуда-то брать - а они уязвимые. Вроде бы к 2025 появилось движение к базово защищенным образам. Но че-то все сильно платное - что bitnami, что cgr.dev. Да сам докерхаб в конце-концов. Посмотрим, во что это выльется.
isden
12.08.2025 09:26gecube
12.08.2025 09:26я это не отрицал, если что. Но это подобно сборке своего дистрибутива линукс - никто этим в здравом уме не занимается, если можно этим не заниматься.
isden
12.08.2025 09:26Это намного проще чем свой дистр собрать. Плюс прямая экономическая целесообразность - меньше левого в образе -> меньше ресурсов сервера занимается.
powerman
12.08.2025 09:26И чем именно базовые образы вроде ubuntu:latest более уязвимы чем ровно эта же убунта в виртуалке?
gecube
12.08.2025 09:26например, самой сутью образа - там нет кернела. Касательно сравнения именно убунту vs убунту - с точки зрения пакетного менеджера и установленных бинарников - разницы скорее не будет. И вообще выше товарищ правильно говорит - нечего это сравнивать, потому что для контейнеров надо брать контейнерные штуки вроде wolffie, from scratch, distroless etc.
powerman
12.08.2025 09:26например, самой сутью образа - там нет кернела.
И как это может навредить безопасности? Докер же крутится в той же виртуалке, безопасность которой Вас устраивает. Значит за ядром в виртуалке Вы уже следите. А в остальном разницы никакой нет, просто базовые образы тоже надо обновлять - ровно так же, как и виртуалки.
для контейнеров надо брать контейнерные штуки вроде wolffie, from scratch, distroless etc.
Что значит "нужно"? Кому нужно и для чего? Обычно эти штуки берут как раз для усиления безопасности (чем меньше в образе лишних приложений тем меньше возможных векторов для атаки). Но если ваш ИБ считает что у "контейнерных штук" безопасность хуже, то он может вместо них брать и ubuntu:latest. Размер образа будет больше, но в остальном особой разницы нет.
gecube
12.08.2025 09:26контролей и обзервабилити у контейнеров меньше - это можете даже не оспаривать. Тулинг пока не созрел до конца, увы. Условный Falco берешь - а он путь к файлу пишет не так, как надо. Сидишь и гадаешь (я утрирую) - проблема на хост машине или в контейнере. Так что проблема более широкая.
powerman
12.08.2025 09:26Это вопрос восприятия. Не нужно воспринимать контейнеры аналогом виртуалок или железных серверов - они этим не являются.
Контейнер - это обычный процесс/приложение, просто дополнительно ограниченное ядром в плане того, что это приложение видит. Грубо говоря, контейнер намного ближе к запуску бинарника в chroot чем к виртуалке.
Поэтому в плане управления и мониторинга от контейнеров нужно ждать примерно того же, что и от любых процессов - т.е. только тех возможностей, которые реализованы в самом приложении. Всё, что докер даёт сверх этого - это "дополнительная фича", а не "урезанный вариант того что доступно для виртуалок".
Как вариант, ставите на сервак netdata (можно тоже в докере), и получаете обзервабилити выше крыши, включая и для контейнеров докера.
gecube
12.08.2025 09:26Это вопрос восприятия. Не нужно воспринимать контейнеры аналогом виртуалок или железных серверов - они этим не являются.
я никогда их аналогом виртуалок и не называл
Контейнер - это обычный процесс/приложение, просто дополнительно ограниченное ядром в плане того, что это приложение видит
да
Грубо говоря, контейнер намного ближе к запуску бинарника в chroot чем к виртуалке.
да
Поэтому в плане управления и мониторинга от контейнеров нужно ждать примерно того же, что и от любых процессов - т.е. только тех возможностей, которые реализованы в самом приложении
нет. Именно за счет того, что с точки зрения докера и CRI контейнеры "существуют", а с точки зрения ядра линукс - нет - у нас возникают проблемы, связанные с тем, чтобы правильно рапортовать, например, что процесс ХХХ случился именно в контейнере YYY. Это примерно такая же проблема совместимости, как между nftables и iptables. Повторюсь - тулинг недостаточно зрелый. Хотя и двигается в этом направлении.
gecube
12.08.2025 09:26ну, или - в контейнере /etc/hosts условный. Какой-нибудь секурити тул будет верещать - Алярм, опасность, а ничего такого нет. Хотя, по-чесноку, наверняка, и с systemd-nspawm и chroot окружениями будет такая же ботва.
powerman
12.08.2025 09:26честно говоря, для большинства бизнесов докер вообще не нужен. И вообще им контейнеризация не решает ни одной задачи )
Может ни одной задачи отдела ИБ это и не решает, а вот задачи разработчиков - очень даже решает. Разработчики все дружно перешли на докер потому, что их жизнь от этого стала легче. А когда жизнь у разработчиков легче - бизнесу разработка стоит дешевле, в некоторых случаях - заметно дешевле.
Так что если ИБ не делает свою работу полноценно "потому что за это не заплатили" но при этом навязывает запреты "на всякий случай", то нужно понимать, что бизнесу эти запреты обходятся значительно дороже, чем оплата времени ИБ на придумывание и внедрение этого запрета. Безопасность и удобство обычно находятся по разные стороны, а неудобство - это лишние затраты времени, а время - деньги.
Поэтому лично я против театра безопасности. Когда что-то делается для усиления ИБ - это должно быть оправдано реальными нуждами/рисками/ситуацией текущего бизнеса и делаться это должно с пониманием - пониманием как технических аспектов так и цены для бизнеса (в которую входит и неудобство разработчиков в том числе).
gecube
12.08.2025 09:26Разработчики все дружно перешли на докер потому, что их жизнь от этого стала легче. А когда жизнь у разработчиков легче - бизнесу разработка стоит дешевле, в некоторых случаях - заметно дешевле.
то-то все фронты собирают статикой и деплояет не докерами, а напрямую на cdn.
powerman
12.08.2025 09:26Ну, статически собранные бинарники тоже можно деплоить не докерами. Докер вообще придумали не для "статики". Но в большинстве проектов есть не только статика. Впрочем, если у Вас весь проект состоит исключительно из статики фронта, то докер действительно может быть ненужен.
PantileenkoD
12.08.2025 09:26Очень часто пользователи вводят пароль в форму для логина. Далее в логах все это отображается.
Gromov32lvl
12.08.2025 09:26Важно не просто отключать доступ, а внедрять комплексный подход - аудит, мониторинг, многоуровневую аутентификацию и контроль действий. Иначе получится как с замком на двери, если ключи лежат под ковриком
Runime
12.08.2025 09:26А там ssh ключи использовать.... Открытый и закрытый ключ.... И входить вообще без паролей....
Или я чего то не понимаю?
sergmesh
12.08.2025 09:26Как еще не надо делать (из недавнего)
некоторые передают пароли в java процессы через -D параметры
и генерируют heap dump когда вылетает по OutOfMemory
потом надо же проверить почему свалилось и вытаскивают heap dump к себе на ноут и бинго -- все пароли видны
хотя продакшн защищен насколько возможно (OTP, audit, пароли никто не видит кроме того кто логинится и тд)
проблема: heap dumo содержит коммандную строку
следствие: смена паролей и головная боль на неделю
igorm01
12.08.2025 09:26Конченая структура безопасности на линухе это первая причина почему там все работают рутом. Давайте еще selinux на каждый чих настраивать
vvv1965
12.08.2025 09:26Стесняюсь спросить, а вот этот условный Вася, который передал пароль в командной строке, он же уполномочен что-то конкретное делать на сервере ? И кто эти остальные люди, которые могут просматривать логи сервера и увидеть пароль ? Если процессы на налажены, то почему по шее получил Вася а не его альтернативно одаренный руководитель, который пустил все на самотёк а теперь все вокруг виноваты ?
vasilev2407
12.08.2025 09:26А вот если по строгости закона, то почему руководство не предприняло превентивные меры к запрету входу по паролю в принципе ?
ncix
12.08.2025 09:26Мы нашли и закрыли дыру, добавили регулярные проверки, а
коллега перешёл на ключи... а коллега перешёл на другую работу
Melkij
а лучше сразу раскатить
PasswordAuthentication noLazhu
Заодно и PermitRootLogin no
powerman
Это не про усиление безопасности в контексте текущей статьи. Это скорее про аудит - при условии, что он настроен, что его логи кто-то смотрит, и что никто не использует `sudo bash` и аналоги (впрочем, помним про то, что выйти в шелл можно из многих других приложений, включая vim, так что это не панацея и желающие выполнить команды мимо аудита всё-равно смогут это сделать). В остальном большой пользы от этой настройки нет.
DMGarikk
большой пользы нет, но это усложнение атаки на сервис, одно дело когда злоумышленник попал на сервер сразу рутом и другое когда ему надо искать способ поднять привелегии, что при корректно настроенном ids с большей вероятностью алертнется
==
и вообще под рутом в принципе нечего делать на любых машинах в корпоративной инфраструктуре, никому, даже самымглавнымадминам
powerman
Это традиционный контр-аргумент. Проблема в том, что он больше теоретический, нежели практический - в теории чем больше уровней защиты тем лучше. А на практике первым возникает вопрос: а каким конкретно способом злоумышленник попал на сервер через ssh не под рутом? И дальше обычно выясняется, что в реалистичных сценариях у него в любом случае будет рут, если рут есть у владельца текущего аккаунта.
Ну так не кладите ключи в
/root/.ssh/authorized_keys2и их там не будет. А если серьёзно, то, опять же, в теории это возможно, но на практике даже при использовании IaaC изредка всё-равно нужен прямой доступ под root - когда случается что-то нештатное (железо частично поломалось, нужно отлаживать какие-то серьёзные странности в поведении ядра, нужно разобраться с идущей прямо сейчас атакой или провести расследование последствий атаки, etc.). И в таких случаяхPermitRootLogin noпросто мешается под ногами, без какой-либо пользы от него ни в этот момент ни в остальное время (потому что полноценного аудита при котором от него польза может быть на практике даже в средних компаниях почти не встречается).ValdikSS
Это решается
sudo.PermitRootLoginнужен фактически только для единственной функции: туннели (VPN) через sshd (не путать с пробросом портов).powerman
sudoрешает (частично) вопрос аудита, не более того. Если в компании полноценного аудита нет - тоPermitRootLogin yesможет быть даже безопаснее, потому чтоsudoсоздаёт дополнительный вектор атаки (напр. вот, эскалация привилегий месячной давности: CVE-2025-32463).inkelyad
Наоборот, это sudo заменяется ssh с разрешенным входом по root. Просто выполняешь соединение на localhost с нужной командой.
Преимущество - можно ssh-agent пробросить и авторизоваться ключиком с своей локальной машины, не помня и не устанавливая никаких паролей для пользователя.
Недостаток - все эти правила, что в sudo есть, теряются, но оно далеко не всегда надо.
mayorovp
…и получить дырищу в безопасности! Мало того что этот проброс by design дырявый, так ещё и были связанные с ним уязвимости.
inkelyad
Это как смотреть - это уязвимость будет только пока сессия живет. После того, как от удаленной машины отцепился - отцепится и агент.
Кроме того, если к этому сокету злодей может прицепиться - то он и к tty, через который пароль для sudo набирается, тоже может.
mayorovp
Если "повесить" троян на старт сессии - то время жизни этой сессии роли играть не будет.
Что же до пароля - вот потому пароль для sudo и должен либо быть уникальным, либо отсутствовать.
DMGarikk
реалистичные сценарии есть такие о которых вы не догадаетесь, я уже спорил со своими ИБшниками что недостаточно закрыть контур снаружи и забить на обновления серверов кторые строго внутри контура компании находятся..типа там всёравно только свои ходят...
меня отлично научили на одном из тестов проникновения как ломануть доменный контроллер просто отправкой письма на комп сотрудника с гостевыми привелегиями...15 минут хватило чтобы показать как ломануть доменный контроллер через эксплойт на который апдейт вчера вышел..зайдя туда админом от пользователя с правами "пользователь" - который априори туда доступа иметь не должен вообще никакого кроме АД-шных сервисов типа получения gpo и прочей авторизации
тут винда конечно, но линукс тут не панацея, там полно дыр такого рода бывало, взять дырищу с повышением до рута в vim например
тут конечно вопрос в изоляции контуров и ограничений доступа по портам в сочетании IP+user ...но это уже прям жирно хорошо, для этого надо чтобы инфраструктура была готова к таим приседаниям..и то не факт что дыры в фаерволле не будет
все действия должны логироваться, если в логах написано что зашел root и чёто там сделал ..как вы будете выяснять кто этот человек и как вы упустили пароль от привелигированного пользователя?
а если у вас 192.168.0.1 login root в логах, то это уже фейл
powerman
Есть. Но это не повод для карго-культа и театра безопасности. Предпринимая какие-то действия "для безопасности" стоит понимать, какие конкретно риски и сценарии атак эти действия прикрывают. Тупо механически выключать везде
PermitRootLoginпросто потому, что так 20 лет назад порекомендовали где-то в интернете плюс в директиве есть страшное слово "root" - так себе идея.Как я с самого начала говорил, если в компании настроен полноценный аудит - то
PermitRootLoginдействительно нужно отключить, иначе он этому аудиту будет мешать. Но - это далеко не единственное, что нужно сделать, потому чтоsudo bashэтому аудиту будет мешать ровно так же. И нет, надеяться на то, что "если что - что-нибудь по логам накопаем" - это и близко не эквивалент состоянию "настроен полноценный аудит".Вообще, я в эту сторону давненько не смотрел, но вроде были какие-то способы логировать все exec-и на уровне сисколов. Если аудит делать на этом уровне, а не надеяться на "непробиваемый"
/etc/sudoers, то иPermitRootLoginможет аудиту не особо мешать - кто именно зашёл под рутом видно по тому, какой из ключей использовался, а дальше к нему привязан аудит по exec-ам.DMGarikk
да всё просто, почти в любом стандарте ИБ, PCI-DSS, SOX и прочихз аббривеатурах, всегда первыми пунктами парольно-пользовательской политики идет запрет работы под анонимными привелигированными пользователями, не потому что "20 лет ктото порекомендовал, а ща всё устарело"..а потому что за этим есть смысл в виде логирования, мониторинга и контроля
не будет, в логах будет запись что pupkin.v зашел на сервак и сделал sudo bash, в результате сгенерирован автоматический инцидент ИБ и безопасник дал васе по шее
вы самостоятельно расследовали инциденты по логам? я вот да
т.е. вместо одной строчки в логе сервера, нам надо заниматся приседаниями с ключами кому какой выдан и матчить их с логами..а потом окажется что злоумышленних всё на серваке дропнул вместе с ними также как и на компе человека с которого заходил..и ой..мы забыли логировать выдаваемые ключи или поставили срок хранения логам по ним 1 год..а выдаем их на 15 лет потому что лень менять чаще
блин вы усложняете сценарии ИБ только ради того чтобы под рутом на серваки ходить напрямую? это того стоит? я очень давно не брал в руки шашку в админской сфере, но помню что там от ИБ других более серьёзных граблей больше и запрет входа под рутом самая ерундовая история
лучше давайте про selinux и прочие apparmor вспомним и динамический фаерволл зависящий от юзера и приложений которые ему разрешено запускать...или это тоже не нужно и мы всецело доверяем админам?
а это я люблю
помню такую фразу "нам не надо усиливать безопасность, нам надо только точно знать кто виноват в инциденте, мы на него в суд подадим и инцидент будет исчерпан" (с)
буквально, васян потерял ноут с ключами ssh, у банка украли 100500млн денег...ну так Васян виноват, пускай суд его покарает...а 100500млн..ну украли и украли..бывает..ВИНОВНЫЙ НАЙДЕН! (рукалицо)
главный риск такой чтобы сервис был не взломан, если взломан то минимально поврежден, если поврежден сильно то был быстро восстановлен с закрытием дырок через которые он был скомпроментирован.
я конечно говорю не про сервисы контроля за похудением где парольные политики похлеще интернет банков, а чтото посерьёзнее.
p.s. меня испортила работа в финтехе
powerman
Вы всё говорите правильно, и я с этим не спорю. В компаниях где реально внедрены любые стандарты ИБ есть адекватный аудит, и там отключать
PermitRootLoginдействительно есть смысл. Но помимо таких компаний есть те, которые до этого уровня зрелости ещё не доросли - их намного больше, и в них зачастую процветают карго-культы и театры безопасности вместо реальной ИБ.Я тоже да. Поэтому и говорю, что надеяться на это нельзя - пока процессы аудита не были поставлены и протестированы всегда есть высокая вероятность, что в логах будет что-то бесполезное вроде локального IP или вообще не будет нужного или сами логи будут удалены. Иными словами, я не против отключения
PermitRootLogin, я за то, чтобы его выключали не "по умолчанию", а при наличии понимания что конкретно это даст в текущей ситуации. Хотя бы на минимальном уровне: адекватно настроенный sudoers, наличие алертов на sudo bash сотоварищи которые кто-то реально получает и на которые обязательно реагирует, проведённый анализ логов показывающий возможность отследить кто и что делает, хоть какая-то защита логов от удаления.Это типичная точка зрения технаря. С точки зрения бизнеса всё не так однозначно - ущерб вполне может оказаться застрахован либо "лечь" на того, кого "не жалко". Концепция "нам надо только точно знать кто виноват в инциденте" тоже имеет право на жизнь, если это требование необходимо для того, чтобы обеспечить гладкое получение той же страховки, например, или просто перенос ответственности чтобы какого-нибудь топа не назначили виноватым за инцидент. Мы работаем на бизнес и для бизнеса, закрываем его потребности, и они далеко не всегда совпадают с идеальными техническими решениями - к сожалению.
gecube
чтобы избежать проблем - достаточно мыть руки перед едой и после туалета. Не просто так цветет наследие Земмельвайса. Но если этого не делать - дальше не пройдешь. Поэтому запрет
PermitRootLogin- хорошее умолчание.emink
Добра вам, но это не так. Какая сейчас существует защита в ci/cd инструментах? Вроде где-то маскируется, но работает по-разному, может в логе пайплайна мы не увидим пароль, но если отпочковаться в другую бранчу, то у любого девопса будет возможность этот пароль скинуть в свою хелло ворлд приложуху и там его сохранить, как и любую другую переменную ci. Можно ли защитить ci, конечно, ваулт апрол и т.д., только назовите компанию где настолько не доверяют своим сотрудникам (которым выдают доступ в проекты инфры ci), чтобы городить на каждый чих такие строгие меры? Вы заеб... такие пайплайна писать, а сколько времени потратят сотрудники на реализацию такой "безопасности". А теперь про permitrootlogin yes, что если вам нужен доступ к либвирту по сокету, а у пользака таких прав нет, будете колхоз городить и палки в работу вставлять? Вы меня извините, но порядочному толковому сотруднику точно нужен рут, все данные, расклад, архитектура, без этого админ не сможет грамотно научится управлять инфрой/процессами. Я работал в компаниях с такими стремными мерами безопасности, и от всего сердца шлю их подальше, порой ИБ зазнается, и, чтобы оправдать свою востребованность, вместо пользы приносят одни неудобства. При этом ещё ни разу меня такие меры не останавливали от получения всех необходимых мне секретов для комфортной работы. Короче, все это чушь, лучше занимайтесь своими сотрудниками, не проверять часы в жире, а разговаривать и понимать мотивацию людей нужно, насколько толковые, какие амбиции и какой опыт, это даёт гораздо больше чем вот эта вот снимая безопасность
lightman
А как быть с ситуацией, когда scp скриптом забираю конфиги с серверов для бекапа локально? Конфиги часто лежат в папках, доступных только под рутом
gecube
конфиги надо не бекапить, а
либо бекапим виртуалку целиком средствами облака
а еще лучше - раскладываем конфиги любимым средством puppet/salt/ansible и вместо бекапа просто имеем единую точку правды.
netch80
Лучше forced-commands-only, при этом в authorized_keys записаны команды и их легко верифицировать.
hogstaberg
Не всё сетевое железо так умеет. Далеко не всё.