🛡️ Аудит безопасности — global-prod-main

1. Сводка (Executive Summary)

2. Учётные записи пользователей

2.1 Интерактивные пользователи (могут логиниться)

• UID 0 ровно один (root) — скрытых суперпользователей нет. ✅
• Учётки UID < 1000 — стандартные системные демоны (все с nologin/false, пароли заблокированы). ✅
• Прикладные системные аккаунты: zabbix (116), ftp (114), usbmux (115) — все nologin. ✅
• Пустых паролей нет (awk по /etc/shadow ничего не вернул). ✅

# awk -F: '($3==0){print $1}' /etc/passwd
root
# единственная учётка с UID 0 — скрытых суперпользователей нет

# sudo awk -F: '($2==""){print $1}' /etc/shadow
# вывод пуст — учётных записей с пустым паролем нет

2.2 Привилегии (sudo) — детально

Конфигурация даёт root тремя путями:

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

• getent group sudo → r3ddan9 (единственный «обычный» админ, требует пароль).
• getent group admin → пусто.

# getent group sudo
sudo:x:27:r3ddan9
# в группе sudo (требует пароль) — только r3ddan9

# getent group admin
admin:x:
# группа admin пуста — членов нет

# sudo cat /etc/sudoers.d/90-cloud-init-users
y4tsun0v ALL=(ALL) NOPASSWD:ALL
# orphan-аккаунт получает полный root без запроса пароля

2.3 Политика паролей

PASS_MAX_DAYS   99999   # пароли НИКОГДА не истекают  ⚠️
PASS_MIN_DAYS   0
PASS_WARN_AGE   7

# grep '^PASS_' /etc/login.defs
PASS_MAX_DAYS   99999
PASS_MIN_DAYS   0
PASS_WARN_AGE   7
# PASS_MAX_DAYS 99999 — пароли практически никогда не истекают

3. SSH — конфигурация и доступ

3.1 Настройки демона (sshd -T)

Итог: конфигурация SSH соответствует лучшим практикам.

# sudo sshd -T | grep -Ei '^(permitrootlogin|passwordauthentication|pubkeyauthentication|permitemptypasswords|allowusers)'
permitrootlogin no
passwordauthentication no
pubkeyauthentication yes
permitemptypasswords no
allowusers r3ddan9 evrotrans

# ss -tlpn | grep sshd
LISTEN 0 128 0.0.0.0:48008 0.0.0.0:* users:(("sshd"...))
# только ключи, root запрещён, белый список, нестандартный порт 48008

3.2 Авторизованные ключи (authorized_keys)

# for u in root r3ddan9 y4tsun0v evrotrans; do echo "== $u =="; sudo cat /home/$u/.ssh/authorized_keys 2>/dev/null; done
== root ==
command="echo 'Please login as ...'" ssh-... danil@IdeaPad-3-14ALC6
== r3ddan9 ==
ssh-... danil@IdeaPad-3-14ALC6
ssh-... root@7cb276780667
== y4tsun0v ==
ssh-... danil@IdeaPad-3-14ALC6
== evrotrans ==
ssh-... danil@IdeaPad-3-14ALC6
ssh-... root@7cb276780667
# один личный ключ danil@IdeaPad-3-14ALC6 во всех 4 аккаунтах; у root — обезврежен командой-заглушкой; root@7cb276780667 = деплой-ключ GitHub Actions

4. Приватные ключи и секреты на диске

4.1 🔴 Реальные приватные ключи (требуют внимания)

# sudo find /home/evrotrans/stable -name id_rsa -o -name '*.key' 2>/dev/null
/home/evrotrans/stable/crontab/keys/id_rsa
/home/evrotrans/stable/openvpn/config/web-ssl/ca.key
/home/evrotrans/stable/openvpn/config/web-ssl/server.key
/home/evrotrans/stable/portainer/data/portainer.key
# реальные приватные ключи (SSH-деплой, CA и сервер OpenVPN, TLS Portainer) лежат в дереве приложения

4.2 🟢 Штатные сертификаты Let's Encrypt (certbot)

/home/evrotrans/stable/certbot/config/{live,archive,keys,csr}/... — сотни privkey*.pem, fullchain*.pem, cert*.pem, *_key-certbot.pem, *_csr-certbot.pem. Это нормальные TLS-сертификаты обслуживаемых доменов. Действие не требуется, но это раскрывает полный список доменов (см. §10).

5. Запущенные сервисы

systemctl — 37 активных юнитов. Значимые:

6. Сетевые порты (ss -tulpn)

6.1 Доступны извне (0.0.0.0 / * / [::])

# ss -tulpn
tcp LISTEN 0.0.0.0:48008  users:(("sshd"...))
tcp LISTEN 0.0.0.0:80     users:(("docker-proxy"...))
tcp LISTEN 0.0.0.0:443    users:(("docker-proxy"...))
tcp LISTEN 0.0.0.0:1194   users:(("docker-proxy"...))
tcp LISTEN 0.0.0.0:48080  users:(("vsftpd"...))
tcp LISTEN *:10050        users:(("zabbix_agent2"...))
tcp LISTEN *:40963        users:(("grpm-sync-unit"...))
# на всех интерфейсах: SSH, web (docker-proxy), OpenVPN, FTP, Zabbix, Acronis grpm-sync

6.2 Только localhost (127.0.0.1 / ::1) — ✅ безопасно

53 (systemd-resolved), 24100-24102/43234/9850 (Acronis mms), 9772 (adp-agent), 41421 (task-manager), 9775 (acp-update), 39611 (aakore), 6109 (active-protection).

# ss -tlpn | grep 48080
LISTEN 0 32 0.0.0.0:48080 0.0.0.0:* users:(("vsftpd"...))
# FTP открыт на 0.0.0.0 (в интернет), протокол незашифрованный

7. Активность входов

7.1 Текущие/недавние сессии (who, last)

• Сейчас в системе: r3ddan9 с 77.233.215.97 (pts/0, с 4 июня 23:00); evrotrans на консоли ttyS0 (с 3 июня).
• evrotrans регулярно входит с российских резидентных IP: 95.25.x.x, 31.129.102.227, 95.140.157.52.
• r3ddan9 — с 178.34.150.110, 95.140.157.52, 77.233.215.97.
• История с 14 июня 2025 — выглядит как обычная работа администраторов, аномалий не видно.

7.2 Неудачные входы (lastb) — массовый перебор

# sudo lastb | head
huawei   ssh:notty   77.83.39.x      ...
admin    ssh:notty   130.12.181.x    ...
user     ssh:notty   45.144.212.54   ...
# массовый перебор имён с ботнет-подсетей; обречён — парольный вход отключён

8. Задачи по расписанию (cron)

• /etc/crontab и /etc/cron.{d,daily,hourly,weekly,monthly} — только штатные системные задачи (apt, logrotate, man-db, popularity-contest и т.п.). Посторонних записей нет. ✅
• Персональных crontab нет ни у одного пользователя (вывод crontab -l пуст для всех). ✅

# cat /etc/crontab
# только штатные системные задачи (apt, logrotate, man-db, popularity-contest)

# for u in root r3ddan9 evrotrans; do crontab -l -u $u; done
no crontab for root
no crontab for r3ddan9
no crontab for evrotrans
# системный cron чист, персональных нет — но есть .../crontab/keys/id_rsa: расписание внутри Docker-контейнера

9. Незавершённые проверки (требуют повторного прогона)

# sudo find / -perm -4000 -type f 2>/dev/null




# 4 пустые строки вместо ожидаемых sudo/su/passwd/mount — аномалия, проверку повторить

10. Перечень обслуживаемых доменов (из certbot)

Из путей certbot/config/archive/ видно, что сервер (или его reverse-proxy) обслуживает домены *.evrotrans.net:

evrotrans.net, www, api, api3, sales, doz, pma, pma1, ptr, erp, erp2, erp3,
old, mde, test, p, v3, vpn, wld, partnerstickets, sakai3, monofront3,
плюс wildcard wildcard.evrotrans.net

# ls /home/evrotrans/stable/certbot/config/archive/
evrotrans.net  www  api  api3  sales  erp  erp2  erp3
pma  pma1  ptr  mde  doz  test  p  vpn  partnerstickets
... wildcard.evrotrans.net
# каталоги certbot раскрывают полный список обслуживаемых поддоменов (карта поверхности атаки)

Это карта поверхности атаки веб-уровня (поддомены ERP, API, phpMyAdmin pma, VPN, test).

11. План действий (приоритизированный)

🔴 Высокий приоритет (сделать в первую очередь)

1. Разобраться с y4tsun0v: если аккаунт не используется — удалить (userdel) или как минимум убрать NOPASSWD:ALL из /etc/sudoers.d/90-cloud-init-users. Это orphan от первичной настройки VM.
2. Убрать приватный ключ из дерева приложения: перенести /home/evrotrans/stable/crontab/keys/id_rsa за пределы публикуемого/бэкапируемого каталога, выставить chmod 600, убедиться, что он не попадает в git/архивы. Рассмотреть ротацию ключа.
3. Защитить ключи OpenVPN: ca.key/server.key — проверить права (600, владелец root/контейнер), убедиться, что каталог не доступен по web. ca.key в идеале хранить offline.
4. Закрыть/заменить FTP (vsftpd, 48080): отключить, если не используется (systemctl disable --now vsftpd); иначе перейти на SFTP/FTPS + firewall.

🟠 Средний приоритет

5. Firewall на сервисные порты: ограничить 10050 (Zabbix) и 40963 (Acronis) доступом только с доверенных IP. Использовать облачные security-groups + локальный ufw/nftables.
6. Установить fail2ban для гашения SSH-перебора и роста логов.
7. Проверить метаданные Yandex Cloud (SSH-ключи проекта/инстанса, OS Login) — это альтернативный канал доступа в обход authorized_keys.
8. Политика паролей: задать PASS_MAX_DAYS (напр. 365) для интерактивных аккаунтов.
9. Разделить переиспользуемый ключ: по возможности завести отдельные ключи на каждого администратора/каждую роль вместо одного danil@IdeaPad.

🟢 Дополнительно

10. Повторить аудит SUID/SGID (см. §9) — текущий результат недостоверен.
11. Проаудировать Docker-контейнеры: docker ps, секреты в .env/compose, привилегированные контейнеры, проброс сокета Docker.
12. Проверить systemd timers и cron внутри контейнеров (системный cron пуст, но расписание где-то есть).
13. Закрыть/ограничить доступ к pma* (phpMyAdmin) и test поддоменам.

12. Что настроено хорошо (сохранить)