Хостинг-компания сказала «вас взломали» — какие шаги по реагированию на инцидент в первый час?

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

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

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

Когда в прошлом году мы получили похожее предупреждение, мы в панике сбросили машину и восстановились из бэкапа. Поскольку мы не нашли точку входа, через два дня столкнулись с запиской о выкупе на 45 000 SAR и были вынуждены потратить ещё 60 000 SAR на судебный анализ. Не действуйте без доказательств.

Если хостинг-провайдер говорит «вас взломали», это не всегда значит, что внутри сидит злоумышленник. Иногда такие алерты срабатывают из-за криво настроенного DNS-сервиса на сервере или открытой наружу очереди SMTP. Отключите сеть, но не спешите сразу объявлять систему виновной.

Порядок действий в первые 60 минут такой: 1) Отрезать сервер от внешнего интернета. 2) Снять дамп RAM и снапшот диска. 3) Сменить админские пароли с отдельного устройства. 4) Письменно запросить у хостинг-провайдера логи аномального трафика. 5) Официально уведомить руководство компании и юриста.

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

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

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

если напишете результат здесь это помжет и другим.

А как вы решили этот вопрос? Забытые тестовые среды становятся входом в систему чаще чем продакшн.

Оставлю как заметку, пригодится.

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

Проверено опытом.

Вы правы, я сам проходил через это. Когда пытаешься изменить всё сразу, ничего не приживается.

Если пойдете этим путем, сразу решите вот этот вопрос. Ошибка, сделанная на стороне шаги по реагированию на инцидент, обычно исправима, но дорого.

Если путь уведомления длинный, уведомление не приходит; а не пришедшее уведомление — это поздно обнаруженный инцидент. Надеюсь, это будет полезно.

Я сталкивался с тем же. Все, кто торопится с шаги по реагированию на инцидент, спотыкаются на одном и том же.

Исправьте, если я ошибаюсь.

у нас было так. при принятии решений записывайте и худший сценарий а не только лучший.

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

Удачи.

Самое упускаемое из вида в теме шаги по реагированию на инцидент: Процесс, по которому не ведется учет, не улучшается, потому что вы не знаете, что именно улучшать.

Когда пытаешься изменить всё сразу ничего не приживается. Проверено опытом.