Как предотвратить взлом сервера Linux: угрозы и защита для бизнеса

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

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

Чем взлом сервера опасен для работы компании

Сервер в небольшой компании редко занят чем-то одним. На нём работают 1С, файловое хранилище, иногда почта, сайт или учётная система склада. Когда такой сервер выходит из строя, останавливаются оформление заказов, выдача документов и расчёты с поставщиками. Для сотрудников это выглядит одинаково: «ничего не работает».

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

С 30 мая 2025 года штрафы за утечку выделены в отдельные составы статьи 13.11 КоАП. Утечка данных от тысячи до десяти тысяч человек обойдётся компании в 3-5 млн рублей, от десяти до ста тысяч — в 5-10 млн, свыше ста тысяч — в 10-15 млн. За неуведомление Роскомнадзора или просрочку уведомления предусмотрен отдельный штраф: 1-3 млн рублей по части 11 той же статьи. Если компанию по этим составам уже наказали, следующий штраф считают от оборота: 1-3 процента годовой выручки, но не меньше 20 млн и не больше 500 млн рублей. Индивидуальные предприниматели отвечают здесь как организации.

Сроки при утечке короткие: 24 часа на уведомление Роскомнадзора о факте инцидента и 72 часа на сообщение о результатах внутреннего расследования. Отсчёт идёт с момента выявления инцидента, поэтому документы собирают сразу.

Следующий риск — шифровальщик. Команда реагирования BI.ZONE разбирала инциденты в компаниях, чью инфраструктуру зашифровали. По её данным за первые три квартала 2025 года минимальное время от проникновения до начала шифрования составило 12,5 минуты. Максимальное в той же выборке — 181 день. Обе цифры стоят по краям выборки, усреднять их нельзя. Рассчитывать, что атаку успеют заметить и остановить вручную, не получается. Меры настраивают заранее.

Четвёртое последствие — потеря доверия контрагентов. Она заметна не сразу. После утечки договоров и персональных данных заказчики начинают спрашивать, как у вас устроена защита. Если такие вопросы уже задавали в тендере или при проверке поставщика, пригодятся результаты проверки. Как она устроена, мы разбирали в статье про аудит ИТ-безопасности.

Пять путей, которыми чаще всего попадают на сервер

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

Подбор пароля и кража учётных данных

Автоматические попытки входа запускают сразу на тысячи адресов. Сервер с открытым доступом из интернета получает их непрерывно: проверяются типовые имена учётных записей и простые пароли, пока что-нибудь не подойдёт. Ломать шифрование не нужно, когда на сервере есть учётная запись с паролем из названия компании и года.

Пароль можно получить и от самого сотрудника. Это фишинг — поддельное письмо от «технической поддержки» со ссылкой на страницу входа. Администратор здесь такая же цель, как бухгалтер. Получив действующий пароль, атакующий входит под учётной записью сотрудника, и в журнале событий это выглядит как обычный рабочий вход.

Защита начинается с того, что вход по паролю для удалённого доступа отключают и оставляют вход по ключу. Ключ — это пара файлов, закрытая часть которой лежит на компьютере администратора. Перебрать его вычислительно нереалистично при текущих технологиях: ssh-keygen по умолчанию создаёт ключ Ed25519, а для RSA берёт 3072 бита, что по классификации NIST примерно соответствует 128 битам стойкости. Слово «нереалистично» здесь точнее слова «невозможно»: NIST прямо оговаривает, что эти оценки изменятся, когда квантовые вычисления станут практической величиной. Перебор не единственный риск — закрытый ключ можно украсть с рабочей машины, поэтому его закрывают парольной фразой.

С настройкой входа по паролю есть оговорка. В исходной конфигурации OpenSSH он разрешён: в справке по sshd_config у параметра PasswordAuthentication указано значение по умолчанию yes, и в поставляемых файлах Debian и Ubuntu эта строка закомментирована, то есть работает то же значение. Но облачные образы часто приходят уже с отключённым паролем: образы Ubuntu для облаков добавляют файл /etc/ssh/sshd_config.d/60-cloudimg-settings.conf со строкой PasswordAuthentication no, а в образах на базе RHEL пароль выключает cloud-init. Поэтому состояние входа по паролю смотрят на конкретном сервере.

Проверять надо эффективную конфигурацию службы: главный файл её не показывает. Внутри /etc/ssh/sshd_config почти всегда стоит строка Include /etc/ssh/sshd_config.d/*.conf, и файл из этого каталога переопределяет то, что написано ниже в главном. Частая ситуация: администратор правит sshd_config, а вход по паролю остаётся разрешённым, потому что его включает отдельный файл облачного образа. Команда sshd -T печатает то, что служба считает своей настройкой после всех включений; её вывод и стоит просить в ответ на вопрос «пароль отключён?».

Для административного входа добавляют второй фактор — одноразовый код из приложения на телефоне, без которого ключ или пароль на сервер не пускают. Это не настройка по умолчанию ни в одном дистрибутиве: если второй фактор нужен, его включают и проверяют отдельно. Попытки перебора ограничивают другим слоем: инструменты вроде fail2ban читают журналы неудачных входов и добавляют в межсетевой экран правила, которые блокируют адрес источника на заданное время. Авторы fail2ban сами предупреждают, что это снижает интенсивность перебора и не устраняет риск слабой аутентификации. Такая блокировка не заменяет ключи и второй фактор.

Отдельная рутина — доступы уволенных. Учётная запись сотрудника и его ключ остаются на сервере, пока их не удалят вручную, и делать это нужно на каждом сервере. Украденный ключ или уже открытая сессия обходят и пароль, и второй фактор, поэтому доступы пересматривают по расписанию: раз в квартал и при каждом увольнении.

Список доступов собирается четырьмя командами только для чтения:

awk -F: '$3 >= 1000 && $7 !~ /nologin|false/ {print $1}' /etc/passwd
getent group sudo wheel
sudo ls -l /root/.ssh/authorized_keys /home/*/.ssh/authorized_keys
sudo journalctl -u ssh -u sshd --since '7 days ago' | grep -i accepted | tail -20

Первая помогает найти обычные учётные записи, под которыми можно войти. Вторая показывает состав групп с правом администратора. Третья показывает, у кого вообще лежат файлы с разрешёнными ключами; сами ключи читать не нужно, достаточно знать, где они есть. Четвёртая выбирает из журнала последние успешные входы по SSH: по ней видно, кто и откуда реально заходил. Полученный список сверяют с кадровым: каждая строка должна соответствовать работающему человеку или понятной служебной задаче.

Незакрытые уязвимости системы и приложений

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

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

Какая система стоит на сервере, видно из cat /etc/os-release: строки ID и VERSION_ID дают точный ответ, по которому срок поддержки сверяют с сайтом дистрибутива. Если обновлений для этой версии уже не выпускают, появляется отдельная задача с бюджетом и сроком: переход на поддерживаемую версию.

Защита здесь — регулярно ставить обновления безопасности и заранее планировать переход на поддерживаемую версию. Работу автоматики тоже нужно проверять. В Ubuntu Server пакет автообновлений установлен по умолчанию, но по штатной настройке ставит только обновления безопасности. В Debian он обычно есть, хотя в конкретной установке может отсутствовать. В AlmaLinux и Rocky Linux аналога из коробки нет: нужно поставить dnf-automatic и включить его таймер. Причём в штатном конфиге там стоит apply_updates = no, то есть по умолчанию обновления только скачиваются. Поэтому у администратора спрашивают не «включены ли автообновления», а когда в последний раз обновления ставились и какие остались неустановленными. Это часть регулярного обслуживания серверов, которую планируют заранее.

Чем удалённая уязвимость отличается от локального повышения прав

От этого различия зависит, насколько срочно закрывать находку.

Удалённая уязвимость живёт в сервисе, который принимает запросы по сети. Чтобы её использовать, атакующему достаточно отправить специально составленный запрос — учётная запись на сервере ему не нужна. Такие дыры закрывают первыми, особенно если сервис смотрит в интернет. Пример — ошибка в модуле обработки адресов веб-сервера nginx: обращение к сайту заставляет рабочий процесс испортить собственную память.

Локальное повышение привилегий требует, чтобы атакующий уже был внутри: имел учётную запись, оболочку или сессию в контейнере. Тогда ошибка в sudo или в ядре превращает обычного пользователя в администратора системы. Сама по себе такая уязвимость не даёт входа, но превращает мелкое проникновение — через украденный пароль одного сотрудника или дыру в веб-приложении — в полный контроль над сервером.

Третий тип, который легко спутать с первыми двумя, — открытый интерфейс управления. Код при этом исправен: наружу просто смотрит панель, которая по умолчанию считает всех доверенными.

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

Примеры 2026 года

Сначала три термина, которые дальше встречаются постоянно. CVE — международный номер уязвимости: по нему её описание находится и у разработчика, и в базах уязвимостей. Upstream-версия — версия от самого разработчика продукта, без правок дистрибутива. Каталог CISA KEV — перечень, в который американское агентство по кибербезопасности вносит уязвимости с подтверждённой эксплуатацией; попадание в него означает «закрывать немедленно».

Статус эксплуатации проверяют отдельно. В новостях разные стадии часто называют одинаково — «активно эксплуатируется». Различать стоит пять уровней: уязвимость известна; опубликован работающий образец атаки (его называют PoC, от proof of concept); зафиксированы попытки; подтверждена эксплуатация против реальных систем; доказана массовая эксплуатация. В таблице указан тот уровень, который подтверждается первоисточником на 6 октября 2026 года.

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

Номер версии сам по себе ничего не доказывает. Дистрибутивы переносят исправления в свои сборки, не меняя upstream-номер; такой перенос называют бэкпортом. Исправленный пакет OpenSSH для Ubuntu 24.04 LTS называется 1:9.6p1-3ubuntu13.18, и баннер службы продолжает показывать 9.6, хотя патч применён. С sudo случай ещё показательнее. Исправленный пакет для RHEL 10 имеет upstream-базу 1.9.15, которая численно ниже уязвимой 1.9.17p2. Red Hat пишет об этом прямо: по одному номеру версии нельзя сказать, уязвима система или нет, и сканеры, которые решают по номеру, дают ложные срабатывания. Сверять надо версию установленного пакета с версией из бюллетеня своего дистрибутива.

Условия важнее диапазона версий. В случае nginx из диапазона 0.6.27-1.30.0 уязвимы только серверы с подходящей конфигурацией rewrite, которой по умолчанию нет. Обновляться всё равно надо, но одного номера недостаточно для вывода о риске. После установки пакета сервис нужно перезапустить.

Номера CVE иногда отзывают. Рядом с GhostLock в публикациях встречается номер CVE-2026-53166 — по сути это была регрессия, которую внёс первый патч и которая приводила к падению ядра. 10 июля 2026 года номер отозвали, и в базе CVE у него статус «отклонён». Бюллетень Red Hat при этом по-прежнему держит отозванный номер в заголовке, так что вендор и база CVE здесь расходятся. Если встретите этот номер в отчёте сканера, отдельной задачи он не добавляет.

Пересказы искажают первоисточник. Про ошибку в nginx часть изданий вынесла в заголовок «активно эксплуатируется», хотя в тексте тех же публикаций сказано, что речь о попытках против сенсоров-приманок. Подтверждённых жертв в первоисточниках нет, и через четыре дня после раскрытия, 17 мая 2026 года, в опубликованном разборе уязвимости эксплуатация в дикой природе по-прежнему не подтверждалась. Похожая история с уязвимостью OpenSSH: сторонние базы уязвимостей озаглавили её «обход аутентификации», хотя в тексте на той же странице речь про ускорение перебора. Читать стоит бюллетень вендора и запись CVE. Не путайте и соседние номера: в той же ветке nginx есть второе переполнение в том же модуле, CVE-2026-9256, исправленное уже в 1.30.2 от 22 мая 2026 года — обновление до 1.30.1 закрывает первую уязвимость и не закрывает вторую.

Как проверить свой сервер

Команды ниже — только для чтения: они ничего не устанавливают и не меняют настроек. Выполнять их имеет смысл на своём сервере и только на нём; проверка чужих хостов — отдельная история с другими последствиями. Если вы подозреваете, что сервер уже взломан, остановитесь здесь и перейдите к разделу про первые действия: там другой порядок.

Общая часть, работает в любом дистрибутиве:

nginx -v 2>&1
sudo nginx -t
sudo nginx -T 2>&1 | less
uname -r
sudo ss -lntup
sudo sshd -T | grep -iE '^(passwordauthentication|kbdinteractiveauthentication|permitrootlogin) '

Версии установленных пакетов в Debian и Ubuntu:

dpkg-query -W nginx openssh-server sudo
apt-cache policy nginx openssh-server sudo
apt list --upgradable

То же в системах на базе RHEL — AlmaLinux, Rocky Linux, сам RHEL:

rpm -q nginx openssh-server sudo kernel
dnf check-update

Что каждая проверка показывает и чего она не доказывает:

1. nginx -v и nginx -t. Первая печатает версию, вторая проверяет синтаксис конфигурации. Ни та, ни другая не меняют конфигурацию и не перезапускают nginx, но -t открывает файлы, перечисленные в конфиге, и пишет результат проверки в журнал ошибок — «вообще ничего не трогает» про неё сказать нельзя.
2. nginx -T. Печатает все файлы конфигурации целиком, включая подключённые через include. В вывод попадает всё, что туда положили: пути к закрытым ключам, файлы с паролями, заголовки с токенами для внутренних сервисов, адреса серверов за балансировщиком. Запускать локально; полный вывод не пересылать в тикет, чат или переписку с подрядчиком без вычитки.
3. uname -r. Показывает работающее ядро, а не самое новое установленное. До перезагрузки менеджер пакетов покажет новое ядро, а эта команда — старое. Расхождение нормально и означает, что перезагрузка ещё нужна.
4. ss -lntup. Перечисляет слушающие TCP- и UDP-сокеты этого сервера и процессы за ними. Сокет на 0.0.0.0 слушает все адреса, но это не доказывает, что порт виден из интернета: его может закрывать межсетевой экран сервера, правила сети у провайдера или трансляция адресов. Видимость снаружи проверяют отдельно и с внешней стороны. Без прав администратора команда не покажет процессы чужих пользователей.
5. sshd -T. Печатает эффективную настройку службы после всех включений — то, что надо смотреть вместо главного файла. Две оговорки. Первая: блоки Match без параметров подключения не применяются, для конкретного пользователя или адреса нужен флаг -C, например sudo sshd -T -C user=deploy,addr=203.0.113.7. Вторая: в OpenSSH 10.4 вывод перешёл на смешанный регистр, поэтому поиск по выводу делают без учёта регистра — отсюда grep -i в примере.
6. dpkg-query -W и rpm -q. Показывают, какие версии пакетов установлены. Именно эти номера сверяют с бюллетенем дистрибутива. rpm -q kernel перечислит все установленные ядра; работающее показывает только uname -r.
7. apt-cache policy, apt list --upgradable, dnf check-update. Показывают, что доступно для обновления. Данные apt берутся из локального кеша: если apt update давно не выполняли, картина устарела. apt list --upgradable годится для чтения глазами и не годится для скриптов — справка по apt сама предупреждает, что поведение команды меняется между версиями. У dnf check-update код возврата 100, когда обновления есть, и 0, когда их нет; в скрипте с set -e это выглядит как ошибка, хотя ошибки нет.

Что не следует заключать по этим проверкам. Пустой вывод, ошибка запуска или отсутствие nginx на сервере защиту не подтверждают: это повод разобраться, что именно выполнялось. Проверка версий закрывает один вопрос из пяти в таблице выше: доступы, открытые сервисы, резервные копии и шифрование каналов она не покрывает. Для ядра последовательность строгая: сначала исправленный пакет, затем перезагрузка, и только потом uname -r покажет, что система работает на новом ядре.

Лишние открытые сервисы и слишком широкие права

Серверы редко настраивают с нуля под одну задачу. Их расширяют: добавили веб-интерфейс для склада, открыли доступ к базе для внешнего отчёта, подняли тестовый сервис и забыли выключить. За каждым сервисом, доступным из интернета, нужно следить. За тестовым сервисом часто не следит никто.

Сервис особенно опасен, когда совпадают три условия: он отвечает на запросы из сети, у него слабая или отсутствующая проверка доступа, и за ним стоят права, которых достаточно для вреда. Хуже всего выглядит интерфейс управления, выставленный наружу: там за одной формой входа лежит право менять конфигурацию сервера. История с панелью Nginx UI из таблицы выше показывает, как это бывает на практике: доступ к уязвимому пути ограничивался списком разрешённых адресов, а пустой по умолчанию список трактовался как «разрешить всем». Проверять стоит и наличие ограничения по адресам, и то, что список действительно заполнен.

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

Наружу должно быть открыто только то, что действительно нужно для доступа из интернета; остальное работает из офисной сети или через защищённый канал. По каждому слушающему порту из вывода ss -lntup записывают три вещи: какой процесс за ним стоит, с каких адресов он должен быть доступен и кто им пользуется. Строки, по которым ответов нет, — кандидаты на закрытие. Права выдают по минимуму, нужному для работы; административные оставляют немногим, кому они нужны.

Список открытых портов и служб за ними удобно собирать по нашему материалу для специалистов: чек-лист для проверки открытых портов на сервере Linux. Попросите этот список и спросите по каждой строке, зачем она нужна.

Вредоносное ПО и шифрование данных

Вредоносная программа попадает на сервер через те же пути: украденный пароль, незакрытую уязвимость или открытый наружу сервис. Иногда её приносит сотрудник — вложением в письме или установкой «обновления» с поддельного сайта. Дальше возможны варианты: тихая кража данных месяцами, использование сервера для чужих задач или шифрование файлов с требованием выкупа.

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

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

Перехват незашифрованных соединений

Когда сотрудник подключается к серверу или к 1С по незашифрованному каналу, его логин, пароль и документы идут по сети в открытом виде. В офисной сети их может прочитать тот, кто получил доступ к сети, в том числе через заражённый рабочий компьютер или гостевой Wi-Fi. Для удалённого доступа через домашний или публичный интернет риск выше.

Соединения защищают шифрованием. Веб-интерфейсы работают по HTTPS: это шифрованное соединение, в браузере у адреса видно замок. Административный доступ идёт по SSH, удалённые сотрудники и филиалы подключаются через VPN — защищённый канал до офисной сети, без прямого доступа к серверу из интернета.

Что шифрование не делает. HTTPS защищает данные по дороге и не влияет на уязвимости самого приложения: ошибка в веб-сервере или в панели управления работает по шифрованному соединению точно так же. VPN сокращает поверхность атаки, потому что убирает сервис из открытого интернета, и не превращает уязвимый сервис в безопасный — за каналом остаётся та же служба, которую надо обновлять. Публикация 1С или базы данных прямо в интернет без защищённого канала — отдельный риск, проверьте его первым.

Что владельцу бизнеса спросить у ответственного за сервер

1. Кто имеет доступ к серверу и кто ведёт этот список? Нормальный ответ — перечень учётных записей и ключей с фамилиями, собранный командами из раздела про доступы и сверенный с кадровым списком. Тревожный — «доступ у меня и, кажется, у прошлого подрядчика».
2. Отключён ли вход по паролю и есть ли второй фактор у административного доступа? Нормальный ответ опирается на вывод sshd -T с этого сервера: вход по ключу, пароль отключён, вход под root запрещён, для административного входа требуется второй фактор. Если в ответе звучит «у нас сложный пароль», проверьте эффективную настройку: отключение могли написать в главном файле, а включить обратно отдельным файлом из sshd_config.d.
3. Когда последний раз устанавливались обновления безопасности и до какого года наша система их получает? Нормальный ответ — дата, название версии системы и версии ключевых пакетов, сверенные с бюллетенем дистрибутива. Историю установок показывают dnf history в системах на базе RHEL и журнал /var/log/apt/history.log в Debian и Ubuntu. Если выясняется, что система уже не поддерживается, появляется отдельная задача с бюджетом и сроком: переход на поддерживаемую версию.
4. Ведётся ли журнал входов и что в нём видно? Нормальный ответ — журнал ведётся, хранится не только на самом сервере и его кто-то просматривает. Успешные входы видно по journalctl -u ssh -u sshd, неудачные попытки — по lastb, если на системе ведётся файл /var/log/btmp. Без журнала после инцидента невозможно понять, что произошло и какие данные ушли.
5. Где хранится резервный архив и когда последний раз из него восстанавливались? Нормальный ответ — архив лежит отдельно от сервера, последнее успешное тестовое восстановление было в конкретном месяце. Ответ «копирование идёт каждую ночь» без второй половины неполон.
6. Что мы делаем в первый час, если сервер взломали? Нормальный ответ — понятно, кто принимает решение, у кого телефоны подрядчика, кто сообщает сотрудникам и в какой момент уведомляют регулятора при утечке персональных данных.

Шесть ответов с датами, фамилиями и номерами версий покажут состояние защиты. Если ответов нет, нужно выяснить, кто отвечает за эти участки.

Не уверены, какие доступы и сервисы открыты на сервере? Оставьте заявку на аудит информационной безопасности. Аудит ИТ-системы в ИИС бесплатный: при записи вы получаете оценку текущего состояния с рекомендациями, диагностику уязвимостей и проверку защиты и резервных копий.

Что делать, если есть признаки взлома

Признаки, при которых стоит поднимать тревогу: сервер работает под полной нагрузкой без видимой причины, появились незнакомые учётные записи или задания по расписанию, часть файлов не открывается или сменила расширение. В том же списке — успешные входы в журнале ночью или из чужих стран, пропавшие файлы архива и записка с требованием выкупа на рабочем столе. Любого одного пункта достаточно, чтобы позвать специалиста.

Порядок первых действий:

1. Сохраните следы. Не удаляйте подозрительные файлы и не ставьте систему заново: журналы и образ диска нужны, чтобы понять, как зашли и что успели забрать. Запишите время обнаружения и то, что именно увидели. Обновление пакетов и перезагрузка сервера здесь тоже под запретом: обновление перепишет файлы, а перезагрузка уничтожит то, что живёт только в памяти работающей системы. Патчи ставят потом, по плану, который составят вместе со специалистом.
2. Привлеките специалиста. Это работа для того, кто разбирал инциденты: своего администратора, подрядчика или внешней команды. Самостоятельные эксперименты на работающем сервере обычно уничтожают следы.
3. Ограничьте доступ, не уничтожая следы. Сервер отключают от интернета и закрывают удалённый доступ, оставляя его доступным для специалиста в локальной сети. Решение о выключении питания принимает специалист: часть следов живёт только в памяти работающей системы.
4. Смените доступы там, где они могли утечь. Пароли и ключи администраторов, доступы к 1С, к панели хостинга, к почте. Делать это нужно с заведомо чистой машины: смена пароля на взломанном сервере до его проверки смысла не имеет, новый пароль уйдёт тем же путём.
5. Проверьте архив до восстановления. Нужно убедиться, что копии целы, что в них нет уже заражённых файлов и что хранилище не подключено к пострадавшей инфраструктуре. Подключать изолированный архив «просто посмотреть» на этом шаге нельзя: так теряют последнюю чистую копию.
6. Разберитесь с персональными данными. Если утекли данные клиентов или сотрудников, у компании как у оператора персональных данных есть 24 часа на уведомление Роскомнадзора об инциденте и 72 часа на сообщение о результатах внутреннего расследования. Сроки идут с момента выявления инцидента, поэтому юридическую часть ведут параллельно с техническими работами.

Инцидент стоит зафиксировать документально. Неправомерный доступ к охраняемой законом компьютерной информации — состав статьи 272 Уголовного кодекса; ответственность по ней наступает, если доступ повлёк уничтожение, блокирование, изменение или копирование информации, поэтому зафиксированные следы и оценка ущерба нужны и для заявления. Порядок обращения в полицию лучше обсудить с юристом компании. Переговоры с вымогателями и оплата выкупа не гарантируют возврата данных: ключ могут не прислать, а компания покажет готовность платить.

Когда нужен аудит защищённости

Пять ситуаций, когда проверку стоит поставить в план:

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

Проверка показывает текущее состояние: доступы, уязвимости, открытые сервисы, резервные копии — и даёт рекомендации по итогам. Дальше нужны обновления, контроль доступов, проверка копий и журналов, реакция на предупреждения мониторинга. Эту часть закрывает регулярное обслуживание — своими силами, если в компании есть администратор, или на стороне ИИС, если держать своего невыгодно.

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

Об авторе статьи

Алексей Блок

Технический эксперт компании «Инновационные Информационные Системы». Специализируется на построении, модернизации и сопровождении корпоративной IT-инфраструктуры.

Профессиональные интересы: DevOps, контейнеризация, Kubernetes, информационная безопасность, IT-аудит, обслуживание серверов, системное администрирование, настройка сетей.

Больше информации.