NOPASSWD-sudo у orphan-аккаунта y4tsun0v, firewall выключен, открытый незашифрованный FTP (vsftpd + ftp-proxy), лишний десктоп-стек (LightDM/Xorg/VNC/CUPS/Avahi) на сервере
🟠 Средняя
Члены группы docker = root-эквивалент, %google-sudoers NOPASSWD, Zabbix/Acronis на всех интерфейсах, mDNS/CUPS-broadcast в сеть, пароли без срока, X11Forwarding yes, образы FTP-стека 4 месяца без пересборки
🟢 Хорошо
SSH: запрет root, только ключи, AllowUsers, нестандартный порт, MaxAuthTries 3; вход только из внутренней сети; нет публичного брутфорса; контейнеры непривилегированные; root-пароль заблокирован; .env без секретов; один UID 0
Главный вывод: SSH настроен так же грамотно, как на первом сервере, и доступ идёт только из внутренней сети (10.128.0.0/24 через ViPNet) — это плюс. Но у этого узла гораздо шире локальная поверхность атаки: полноценное графическое окружение с VNC, печатью и mDNS-вещанием, отключённый firewall и открытый FTP в открытом виде. Плюс повторяется проблема первого сервера — orphan-аккаунт y4tsun0v с беспарольным root.
UID 0 ровно один (root) — скрытых суперпользователей нет ✅ · Пустых паролей нет ✅
2.2 🔴/🟠 sudo и группа docker — детально
root ALL=(ALL:ALL) ALL # /etc/sudoers
%admin ALL=(ALL) ALL # группа admin — ПУСТАЯ
%sudo ALL=(ALL:ALL) ALL # группа sudo — только r3ddan9
y4tsun0v ALL=(ALL) NOPASSWD:ALL # /etc/sudoers.d/90-cloud-init-users 🔴
%google-sudoers ALL=(ALL:ALL) NOPASSWD:ALL # /etc/sudoers.d/google_sudoers 🟠
getent group sudo → r3ddan9 (требует пароль).
getent group admin → пусто.
getent group docker → r3ddan9, evrotrans.
🔴 y4tsun0v имеет полный root БЕЗ пароля через cloud-init drop-in. Зайти по SSH он не может (нет в AllowUsers), но любой, кто получит локальную сессию под этим пользователем (через su/cron/эксплойт сервиса/локальную консоль десктопа), сразу становится root без пароля. Это та же проблема, что и на первом сервере.
🟠 Группа docker = root без пароля. И r3ddan9, и evrotrans состоят в группе docker. Любой член этой группы может смонтировать / в контейнер и получить полный root (docker run -v /:/host ...). Для evrotrans (сервисный аккаунт без sudo) это фактически обходной путь к root в обход политики паролей.
🟠 %google-sudoers NOPASSWD:ALL — стандартный механизм Yandex Cloud: пользователи, попавшие в эту группу через метаданные/OS Login проекта, получают беспарольный root. Это альтернативный канал привилегий, управляемый из облачной консоли.
# sudo cat /etc/sudoers.d/google_sudoers
%google-sudoers ALL=(ALL:ALL) NOPASSWD:ALL
# любой член группы google-sudoers (из метаданных Yandex Cloud) — беспарольный root
🔍 Доказательство — getent group docker
# getent group docker
docker:x:998:r3ddan9,evrotrans
# член группы docker монтирует / в контейнер → root-эквивалент
🔍 Доказательство — getent group sudo / admin
# getent group sudo
sudo:x:27:r3ddan9
# getent group admin# группа admin — пустая (вывода нет)
2.3 Политика паролей
PASS_MAX_DAYS 99999 # пароли НИКОГДА не истекают ⚠️
PASS_MIN_DAYS 0
PASS_WARN_AGE 7
🟠 Пароли бессрочные. Влияет на локальный вход / su / графическую консоль (LightDM).
3. SSH — конфигурация и доступ
3.1 Настройки демона (sshd -T)
Параметр
Значение
Оценка
port
48008 (нестандартный)
✅
permitrootlogin
no
✅
passwordauthentication
no
✅ только ключи
pubkeyauthentication
yes
✅
permitemptypasswords
no
✅
maxauthtries
3
✅
allowusers
r3ddan9 evrotrans
✅ белый список
x11forwarding
yes
🟠 без необходимости расширяет поверхность
🔍 Доказательство — sshd -T
# sudo sshd -T | grep -Ei '^(port|permitrootlogin|passwordauthentication|pubkeyauthentication|maxauthtries|x11forwarding|allowusers)'
port 48008
permitrootlogin no
passwordauthentication no
pubkeyauthentication yes
maxauthtries 3
x11forwarding yes
allowusers r3ddan9 evrotrans
# только ключи, root запрещён, белый список — но x11forwarding лишний
Итог: конфигурация SSH соответствует лучшим практикам. Единственная придирка — X11Forwarding yes (на этом узле есть GUI, но проброс X11 по SSH обычно не нужен — лучше no).
3.2 Авторизованные ключи (authorized_keys)
Файл
Ключи
Комментарий
/root/.ssh/authorized_keys
danil@IdeaPad-3-14ALC6
⚠️ С форсированной командой-заглушкой (command="echo 'Please login as ...'") — вход под root заблокирован. ✅ Хорошая практика.
/home/y4tsun0v/.ssh/authorized_keys
danil@IdeaPad-3-14ALC6 («Added by Google»)
Тот же личный ключ
🟠 Тот же переиспользуемый ключ. Личный ключ danil@IdeaPad-3-14ALC6 (один и тот же, что и на первом сервере!) прописан у root (заглушка) и у y4tsun0v. Компрометация этого приватного ключа на ноутбуке IdeaPad-3-14ALC6 = доступ сразу к обоим серверам.
⚠️ Незавершённая проверка: в выводе аудита есть authorized_keys только для root и y4tsun0v, хотя в AllowUsers указаны r3ddan9 и evrotrans. Их ключи, вероятно, инжектируются google-guest-agent из метаданных Yandex Cloud (механизм google_authorized_keys) и не попали в выборку. Нужно перепроверить ключи r3ddan9/evrotrans и метаданные проекта (см. §12).
🔍 Доказательство — cat .../authorized_keys
# sudo cat /root/.ssh/authorized_keys /home/y4tsun0v/.ssh/authorized_keys
command="echo 'Please login as ...'" ssh-rsa AAAA... danil@IdeaPad-3-14ALC6
ssh-rsa AAAA... danil@IdeaPad-3-14ALC6
# оба — один ключ danil@IdeaPad-3-14ALC6 (у root с командой-заглушкой);# ключи r3ddan9/evrotrans в выводе отсутствуют — вероятно из метаданных Yandex Cloud, перепроверить
4. Приватные ключи и секреты на диске
На этом узле, в отличие от первого, прикладных приватных ключей в дереве приложения почти нет. Большинство найденного — штатные системные файлы. Ниже разделено на значимое и шум.
Приватный ключ и сертификат сервера VNC (TigerVNC)
🟢 Уточнено: VNC не запущен, systemd-юнита нет. По логам слушал только localhost:5903, пароль задан (~/.vnc/passwd, права 600). Доступ возможен лишь через SSH-туннель — риск низкий.
/home/evrotrans/.vipnet/.../for_rand.key (×2)
Файлы инициализации ГПСЧ ViPNet CSP
🟠 Часть криптоядра ViPNet. Должны быть с правами 600 и недоступны другим пользователям. Не «секрет приложения», но компонент сертифицированной криптозащиты.
./ftp-*/config/*.conf
Конфиги ftp-proxy с адресами upstream-серверов
🟠 Монтируются в контейнеры :ro. Содержат адреса/учётки вышестоящих FTP (цели — *.import.inet.egis-otb.local:21021).
✅ /home/evrotrans/stable/.env проверен — секретов нет (только TZ/ENV_TIMEZONE/DOCKER_CONTENT_TRUST=1).
# cat /home/evrotrans/stable/.env
TZ="Europe/Moscow"
ENV_TIMEZONE="Europe/Moscow"
DOCKER_CONTENT_TRUST=1
# паролей/токенов нет ✅
🔍 Доказательство — cat .vnc/*.log (состояние VNC)
# ss -tlpn | grep -E ':590[0-9]'# вывод пуст — VNC сейчас не слушает# из ~/.vnc/*.log:
Listening for VNC connections on 127.0.0.1 port 5903
# слушал только localhost:5903 → доступ возможен лишь через SSH-туннель
🔍 Доказательство — cat ./ftp-*/config/*.conf
# cat /home/evrotrans/stable/ftp-*/config/*.conf
DestinationAddress auto.pdp.import.inet.egis-otb.local
DestinationAddress auto.onsi.import.inet.egis-otb.local
DestinationAddress auto.timetable.import.inet.egis-otb.local
DestinationAddress auto.ack.import.inet.egis-otb.local
DestinationPort 21021
User nobody
# цели прокси — ЕГИС ОТБ, монтируются в контейнеры :ro, прокси под nobody
tun0 7.1.39.7, udp 41034/55781, dns на 7.1.39.7:53
google-guest-agent.service
Yandex Cloud гостевой агент
управляет SSH-ключами/sudo через метаданные (см. §3.2, §12)
unattended-upgrades.service
Автообновления безопасности
✅
🔴 Десктоп-стек на сервере. LightDM/Xorg, CUPS, Avahi, colord, upower, switcheroo, rtkit — это набор рабочей станции. Каждый из них — лишний код с историей уязвимостей и сетевым вещанием. Если графика реально нужна для работы с ViPNet/АРМ — это объяснимо, но тогда узел стоит трактовать как рабочую станцию, а не сервер, и соответственно изолировать.
# systemctl list-units --type=service --state=running | grep -E 'lightdm|cups|avahi|colord|switcheroo|rtkit'
lightdm.service
cups.service
cups-browsed.service
avahi-daemon.service
colord.service
switcheroo-control.service
rtkit-daemon.service
# набор рабочей станции на сервере — лишняя поверхность атаки
⚠️ google-guest-agent может автоматически добавлять SSH-ключи/пользователей и членство в google-sudoers из метаданных проекта. Контроль над метаданными в облаке = контроль над доступом к VM.
6. Сетевые порты (ss -tulpn)
6.1 Доступны извне (0.0.0.0 / * / [::])
Порт
Протокол
Процесс
Оценка
48008
tcp
sshd
✅ SSH (ключи)
48080
tcp
vsftpd
🔴 FTP, ssl_enable=NO — открытый текст, вход локальных юзеров
21001–21004
tcp
ftp-proxy (контейнеры)
🔴 FTP-прокси к контрагентам через ViPNet, на 0.0.0.0
10050
tcp (*)
zabbix_agent2
🟠 Должен видеть только сервер Zabbix
41765
tcp (*)
grpm-sync-unit (Acronis)
🟠 Слушает на всех интерфейсах
5353 / 38317 / 39398
udp
avahi-daemon
🟠 mDNS-вещание в сеть
41034 / 55781
udp
vipnetclient
ViPNet (ожидаемо) ✅
6.2 Только localhost (127.0.0.1 / ::1) — ✅ безопасно
🔴 FTP (vsftpd 48080): подтверждено по /etc/vsftpd.conf — ssl_enable=NO, логины/пароли и файлы идут открытым текстом. Пускает в свой $HOME (chroot) только r3ddan9 и evrotrans (/etc/vsftpd.userlist). Это те же учётки, что и для SSH/sudo/docker — то есть по открытому FTP по сети ходит пароль администратора и оператора узла; перехват = доступ к привилегированным аккаунтам.
Действие: включить FTPS (ssl_enable=YES, нормальный сертификат) или перейти на SFTP; ограничить источники firewall'ом.
🔴 ftp-proxy (21001–21004): четыре прокси ftp-proxy (proxy-suite, под nobody ✅) на 0.0.0.0. Проксируют FTP в ЕГИС ОТБ — {pdp,onsi,timetable,ack}.import.inet.egis-otb.local:21021 через ViPNet (карта сетей — в ARCHITECTURE §2.3, поток данных — §9). Сам FTP незашифрован, но канал защищён ViPNet; ограничить источники подключения к прокси firewall'ом.
🔍 Доказательство — ss -tlpn | grep '2100[1-4]'
# ss -tlpn | grep -E '2100[1-4]'
LISTEN 0.0.0.0:21001 users:(("ftp-proxy",...))
LISTEN 0.0.0.0:21002 users:(("ftp-proxy",...))
LISTEN 0.0.0.0:21003 users:(("ftp-proxy",...))
LISTEN 0.0.0.0:21004 users:(("ftp-proxy",...))
# четыре прокси к ЕГИС ОТБ слушают на всех интерфейсах (0.0.0.0)
🟠 Zabbix (10050), Acronis grpm-sync (41765), Avahi (5353) слушают все интерфейсы — ограничить firewall'ом доверенными IP. Avahi на серверном узле лучше выключить.
✅ CUPS (631) слушает только localhost — хорошо (печать не выставлена в сеть), хотя сам сервис на сервере избыточен.
7. Активность входов
7.1 Текущие/недавние сессии (who, last)
Сейчас в системе:r3ddan9 с 10.128.0.20 (pts/0, с 6 июня 00:08).
Все входы — из внутренней сети10.128.0.x (.15, .20): r3ddan9 и evrotrans, с января по июнь. ✅
Внешних/резидентных IP в истории нет — доступ к узлу идёт изнутри периметра (через bastion/ViPNet), что заметно лучше, чем прямой вход с интернет-адресов.
7.2 Неудачные входы (lastb)
Практически пусто: 2 попытки с 10.128.0.15 (внутренний). ✅
Публичного брутфорса нет — подтверждает, что SSH-порт не торчит в открытый интернет (или закрыт security-group). Это существенно лучше первого сервера.
🔍 Доказательство — last / lastb
# last | head
r3ddan9 pts/0 10.128.0.20 ...still logged in
r3ddan9 pts/0 10.128.0.20 ...
evrotrans pts/1 10.128.0.15 ...
# все входы — только из внутренней сети 10.128.0.x# sudo lastb | head
... 10.128.0.15 ...
# почти пусто (2 попытки с 10.128.0.15) — публичного брутфорса нет ✅
8. Задачи по расписанию (cron / timers) — ✅ в норме
/etc/crontab, /etc/cron.d/* — только штатные системные задачи (apt, e2scrub, popularity-contest). Посторонних записей нет. ✅
Персональных crontab нет ни у одного пользователя. ✅
🔴 Локальный firewall выключен. Политика INPUT ACCEPT, никаких пользовательских правил — фильтрации входящего трафика на хосте нет вообще. Всё, что слушает на 0.0.0.0 (FTP, Zabbix, Acronis, Avahi), доступно с любого узла, который дотянется по сети. Единственная защита сейчас — облачные security-groups Yandex Cloud и периметр ViPNet (их состояние из этого аудита не видно).
Действие: включить ufw/nftables с дефолтным deny incoming, явно разрешить только нужное (SSH 48008, FTP-порты — с доверенных подсетей, Zabbix/Acronis — с IP мониторинга). И/или убедиться, что облачные security-groups жёстко ограничивают вход.
10. Docker (FTP-стек)
По docker-compose.yml + docker inspect. Это не FTP-серверы, а проксиftp-proxy (proxy-suite, /usr/sbin/ftp-proxy -n -d). Compose-проект stable, образы на базе ubuntu:20.04.
🟠 network_mode: host — контейнеры в сетевом пространстве хоста (без bridge-изоляции; docker0 поэтому DOWN). Осознанный выбор из-за FTP (active/passive, диапазоны портов данных), но сетевая изоляция между контейнером и хостом отсутствует. Секции ports:/expose: в этом режиме не действуют.
⚠️ Образы крутятся 4 месяца без пересборки — внутри могут быть непропатченные пакеты. Стоит пересобрать/обновить базовые образы.
⚠️ SUID-бинарники в выводе из /var/lib/docker/overlay2/.../diff/... — это содержимое образа (стандартные mount/su/passwd внутри FTP-образа), не отдельный риск хоста.
⚠️ Что проксируют контейнеры (upstream-адреса контрагентов) — в ./ftp-*/config/*.conf (цели — ЕГИС ОТБ).
11. SUID/SGID (хост)
Список штатный — аномалий нет ✅: sudo, su, mount/umount, passwd, chsh/chfn, gpasswd, newgrp, pkexec, fusermount, at, crontab, ssh-keysign, ssh-agent, chage/expiry, pppd (группа dip), а также десктоп-хелперы Xorg.wrap, dbus-daemon-launch-helper, polkit-agent-helper-1, mc/cons.saver.
pkexec (Polkit) присутствует — убедитесь, что система пропатчена от CVE-2021-4034 (на актуальном 20.04.6 с unattended-upgrades — должно быть закрыто).
Десктоп-SUID (Xorg.wrap и пр.) — следствие графического окружения; ещё один аргумент убрать GUI, если он не нужен.
12. Незавершённые проверки (повторить)
Проверка
Что сделать
Команда
Ключи r3ddan9/evrotrans
В выводе только root и y4tsun0v; проверить реальные authorized_keys админов и сервисного аккаунта
for u in r3ddan9 evrotrans; do echo "== $u =="; cat /home/$u/.ssh/authorized_keys; done
Метаданные Yandex Cloud / OS Login
Альтернативный канал доступа в обход authorized_keys
проверить enable-oslogin, ключи проекта/инстанса в облачной консоли
✅ .env приложения
Проверено — секретов нет (TZ/DOCKER_CONTENT_TRUST=1)
—
✅ Конфиги ftp-proxy
Цели — *.import.inet.egis-otb.local:21021 (ЕГИС ОТБ), прокси под nobody
—
✅ /etc/vsftpd.userlist
Только r3ddan9, evrotrans
—
✅ Роль vsftpd
Локальные юзеры в $HOME, chroot, whitelist, SSL выключен
—
✅ Состояние VNC
Не запущен; слушал только localhost:5903, пароль задан
—
Облачные security-groups
Раз локальный firewall выключен — фильтрация только на уровне облака
проверить firewall-rules в консоли Yandex Cloud
Целостность/история (опц.)
Не входило в audit.sh: capabilities, world-writable, bash_history, ошибки журнала
getcap -r / 2>/dev/null; journalctl -p err -b
13. План действий (приоритизированный)
🔴 Высокий приоритет
Включить firewall (ufw/nftables, default deny incoming) и/или жёстко настроить облачные security-groups: разрешить SSH 48008, FTP-порты — только из доверенных подсетей, Zabbix/Acronis — с IP мониторинга.
Разобраться с y4tsun0v: удалить аккаунт или убрать NOPASSWD:ALL из /etc/sudoers.d/90-cloud-init-users (orphan от первичной настройки, как и на первом сервере).
Закрыть/защитить FTP: ограничить источники firewall'ом, перейти на FTPS/SFTP, убедиться, что vsftpd (48080) и ftp-proxy (21001–21004) недоступны за пределами доверенного периметра.
Сократить десктоп-стек: если GUI не нужен — отключить lightdm, cups/cups-browsed, avahi-daemon, colord, switcheroo-control. Если нужен (АРМ ViPNet) — трактовать узел как рабочую станцию и изолировать соответственно.
🟠 Средний приоритет
Группа docker: пересмотреть членство r3ddan9/evrotrans — это root-эквивалент в обход паролей. Минимум для evrotrans (сервисный аккаунт) рассмотреть отказ от прямого доступа к Docker.
%google-sudoers / метаданные Yandex Cloud: проверить, кто реально попадает в эту группу через облако; ограничить OS Login.
Avahi/mDNS: выключить на серверном узле (systemctl disable --now avahi-daemon).
X11Forwarding no в sshd_config, если проброс X11 не используется.
Установить fail2ban (на будущее) и/или продолжать держать SSH вне публичного интернета.
Политика паролей: задать PASS_MAX_DAYS (напр. 365) — важно из-за локального входа через LightDM.
Пересобрать Docker-образы FTP (крутятся 4 месяца) для получения свежих патчей.
🟢 Дополнительно
Перепроверить ключи r3ddan9/evrotrans и состояние VNC (см. §12).
Проверить права на ~/.vnc/*SrvKey.pem и .vipnet/.../for_rand.key (600, владелец evrotrans).
Проаудировать .env и docker-compose.yml FTP-стека на хранение паролей в открытом виде.
Развести переиспользуемый ключ danil@IdeaPad на отдельные ключи по ролям/хостам.
14. Что настроено хорошо (сохранить)
✅ SSH: запрет root-логина, только ключи, AllowUsers, нестандартный порт 48008, MaxAuthTries 3.
✅ Нет пустых паролей; ровно один UID 0; персональных crontab нет; системный cron чист.
✅ Доступ только из внутренней сети (10.128.0.0/24 / ViPNet) — нет входов с публичных IP.
✅ Публичного брутфорса практически нет (lastb почти пуст).
✅ Docker-контейнеры непривилегированные, Docker-сокет внутрь не проброшен.
✅ Включены автообновления безопасности; развёрнут Acronis Cyber Protect; .env без секретов.
15. Сравнение с первым сервером (...-global-...)
Аспект
Сервер 1 (web/global)
Сервер 2 (vipnet)
Роль
Веб/ERP + OpenVPN + Portainer
FTP-стек + ViPNet + десктоп (GUI)
Публичные сервисы
80/443/1194/FTP/SSH
FTP/SSH (web нет)
Вход извне
С публичных резидентных IP + брутфорс
Только внутренняя сеть, брутфорса нет ✅
Firewall
(не подтверждён)
🔴 выключен
Десктоп-стек
нет
🔴 LightDM/Xorg/VNC/CUPS/Avahi
y4tsun0v NOPASSWD
🔴 есть
🔴 есть (та же проблема)
Группа docker
—
🟠 r3ddan9 + evrotrans
Приватные ключи в дереве приложения
🔴 id_rsa, OpenVPN CA/server, Portainer
почти нет (VNC/ViPNet системные)
Переиспользуемый ключ danil@IdeaPad
да
да (тот же ключ — связывает оба узла)
Общие системные проблемы обоих узлов: orphan y4tsun0v с беспарольным root и один и тот же личный SSH-ключ danil@IdeaPad-3-14ALC6. Их стоит исправлять централизованно на всём парке (см. общую карту).