Рекомендации по безопасности серверов после инцидента в московском дата-центре

Почему важно проверить безопасность сервера

Инциденты информационной безопасности могут затрагивать не только отдельный сервер, но и связанные с ним приложения, базы данных, облачные сервисы и другие компоненты IT-инфраструктуры.

17 октября был выявлен инцидент, связанный с уязвимостью в программном обеспечении системы виртуализации московского дата-центра. По имеющимся данным, в период с 12:27 до 22:34 по московскому времени злоумышленники могли получить возможность читать файлы на затронутом сервере.

На момент подготовки информации полный перечень потенциально доступных файлов и возможное использование содержащихся в них данных не установлены.

Поэтому владельцам серверов рекомендуется не ограничиваться проверкой работоспособности сайта или приложения, а провести комплексную оценку безопасности.

1. Какие данные могут оказаться под угрозой

На серверах часто хранятся данные, необходимые для автоматизации, администрирования и взаимодействия с внешними сервисами.

• SSH-ключи и пароли: учётные данные администратора, приватные ключи, файлы authorized_keys и пароли сервисных аккаунтов.
• Конфигурации приложений: файлы .env, docker-compose.yml, конфигурации CMS и строки подключения к базам данных.
• Базы данных: пароли PostgreSQL, MySQL, MongoDB и Redis, а также данные пользователей и клиентов.
• Облачные сервисы: ключи AWS, Google Cloud, Azure, OpenStack и других платформ.
• DevOps-инструменты: токены GitHub, GitLab, Docker, Kubernetes, Terraform и CI/CD-систем.
• Внешние API: ключи OpenAI, Anthropic, платёжных систем, почтовых сервисов и других поставщиков.
• Резервное копирование: пароли и ключи доступа к Restic, Borg и другим системам хранения резервных копий.
• Криптовалютные активы: seed-фразы, приватные ключи кошельков и API-ключи бирж.

2. Первые действия: защита наиболее важных доступов

Приоритетом должна стать защита активов и учётных записей, компрометация которых может привести к наиболее серьёзным последствиям.

3. Проверьте конфигурации приложений и баз данных

Секреты часто сохраняются в конфигурационных файлах, которые используются для подключения к базам данных, почтовым серверам и внешним API.

В первую очередь следует проверить:

• .env и другие файлы с переменными окружения;
• конфигурации Docker и Docker Compose;
• настройки CMS и веб-приложений;
• строки подключения к базам данных;
• учётные данные SMTP, FTP/SFTP и внешних сервисов;
• историю команд, в которой могли остаться пароли и токены.

После замены секретов обновите конфигурации и проверьте работоспособность приложений. Если один пароль или ключ использовался на нескольких серверах, оцените риски для каждого из них. Повторное использование секретов может превратить локальную проблему в инцидент, затрагивающий всю инфраструктуру.

4. Проверьте сервер на признаки несанкционированного доступа

Смена паролей сама по себе не гарантирует, что сервер снова безопасен. Если злоумышленники получили возможность выполнять команды или изменять настройки, они могли создать дополнительные механизмы доступа.

При проверке обратите внимание на:

• неизвестные учётные записи и SSH-ключи;
• подозрительные изменения системных файлов и конфигураций;
• необычные процессы и службы;
• задания cron и другие механизмы автоматического запуска;
• необычные сетевые соединения;
• неизвестные входы в систему и административные операции;
• изменения настроек безопасности и прав доступа.

Проверяйте журналы операционной системы, приложений, баз данных и внешних сервисов. Отсутствие очевидных признаков компрометации не доказывает, что сервер не был затронут. Если есть основания подозревать полноценное проникновение, может потребоваться профессиональное расследование.

5. Проверьте резервные копии

Резервные копии помогают восстановить работу после инцидента, но сами могут оказаться под угрозой, если доступ к ним осуществляется с помощью скомпрометированных учётных данных.

1. Проверьте доступность и целостность резервных копий.
2. Смените потенциально скомпрометированные пароли и ключи доступа к системам резервного копирования.
3. Проверьте журналы операций с резервными копиями.
4. Убедитесь, что посторонние не могли изменить или удалить данные.
5. При необходимости восстановите систему из проверенной копии в чистой среде.

Не переносите потенциально скомпрометированные ключи, пароли и конфигурации в восстановленную систему. Для дополнительной защиты используйте отдельные учётные записи для резервного копирования, ограниченные права доступа и, где возможно, неизменяемое или изолированное хранение копий.

6. Защитите связанные серверы и сервисы

Если затронутый сервер использовался для управления другими системами, необходимо проверить всю связанную инфраструктуру.

• другие VDS/VPS и физические серверы;
• облачные аккаунты и виртуальные сети;
• сайты, CMS и базы данных;
• DNS и регистрацию доменов;
• почтовые сервисы;
• системы развёртывания приложений;
• репозитории кода и CI/CD;
• панели управления хостингом.

Особое внимание уделите системам, к которым сервер имел административный доступ. Если один и тот же секрет применялся в нескольких местах, его следует заменить во всех соответствующих системах.

7. Усильте защиту после восстановления

8. Что делать, если вы подозреваете компрометацию

Если обнаружены неизвестные учётные записи, подозрительные процессы, несанкционированные изменения или другие признаки проникновения, не следует просто удалять подозрительные файлы и продолжать работу.

1. Ограничьте доступ к затронутой системе, насколько это возможно без создания дополнительных рисков.
2. Сохраните необходимые журналы и материалы для расследования.
3. Отзовите потенциально скомпрометированные учётные данные через доверенную систему.
4. Оцените масштаб инцидента и связанные с сервером системы.
5. При необходимости восстановите инфраструктуру из проверенных источников в чистой среде.
6. Проверьте безопасность восстановленной системы перед возвращением в эксплуатацию.

Если сервер содержит персональные данные, оцените применимые требования законодательства к уведомлению регуляторов и заинтересованных лиц. Обязанности и сроки зависят от юрисдикции и обстоятельств инцидента.