Задание №5

1.

Задание №5
Файловая система,
интерфейс
командной строки

2.

В организации виртуальный сервер с двумя
ядрами стал работать с перебоями.
Команда
top вывела:

3.

Задание:
1. Определите, что произошло с сервером.
2. Укажите, что вызвало Ваши подозрения.
3. Какие меры нужно предпринять для ликвидации проблемы?
4. Какие меры нужно предпринять для предупреждения её возникновения в
дальнейшем?

4.

Команда top
Команда top выводит динамически обновляющуюся информацию о процессах и состоянии
системы в реальном времени.
1. Первая строка (системная сводка):
– Время работы системы (uptime): сколько времени система работает.
– Количество пользователей: сколько пользователей сейчас работает.
– Load average: показатель, который отражает среднее количество процессов, ожидающих или
использующих ресурсы CPU за 1, 5 и 15 минут.

5.

Вторая строка (задачи):
– Общее количество процессов (Tasks).
– Сколько из них запущено (running).
– Сколько спят (sleeping).
– Сколько остановлено (stopped).
– Сколько зомби (zombie). Прим.: чтобы процесс окончательно завершил свою работу, его
родитель обязан “узнать” его статус.

6.

Третья строка (использование CPU):
– us: процент времени CPU в пользовательских процессах.
– sy: процент времени CPU в системных процессах ядра.
– ni: процент времени CPU в процессах с измененным приоритетом.
– id: процент времени простоя CPU.
– wa: процент времени ожидания ввода/вывода.
– hi: процент времени обработки аппаратных прерываний. (для обработки сигналов от физ. устройств)
– si: процент времени обработки программных прерываний. (для выполнений функций ядра)
– st: процент времени, "украденного" виртуальной машиной у физического CPU.

7.

Четвертая и пятая строки (использование памяти):
– Mem: использование физической памяти (RAM).
– Swap: использование swap-пространства. (использование файла подкачки)

8.

Основная часть вывода – список процессов с колонками:
– PID: идентификатор процесса.
– USER: владелец процесса.
– PR/NI: приоритет процесса.
– VIRT: виртуальная память.
– RES: резидентная память (физическая).
– SHR: разделяемая память.
– %CPU: использование CPU.
– %MEM: использование памяти.
– TIME+: время работы процесса.
– COMMAND: имя команды.

9.

10.

Что произошло с системой?

11.

Найдем откуда был запущен файл
Для этого можно воспользоваться командой ls -l /proc/<PID>/exe
В данном случае команда ls не выдаст содержимое директории, так как мы работаем не с
директорией, а с симлинком (ссылкой на оригинальный файл).

12.

Убьем процесс
С помощью команды kill -9 <PID> можно убить процесс.
Переименуем и переместим вредоносный файл для дальнейшего анализа и запретим его
исполнение командой chmod.

13.

Стандартные процедуры
Заблокируем скомпрометированному пользователю vasya вход по паролю (passwd -L vasya),
переименуем его авторизованные ключи
(cp -p /home/vasya/.ssh/authorized_keys
/tmp/vasya_kswapd_keys,
rm /home/vasya/.ssh/authorized_keys),
просмотрим, а затем удалим его таблицу автоматически запускаемых задач
(crontab -l -u vasya, crontab -r -u vasya).
Для предотвращения инцидентов разрешим вход только по ключам и только из рабочей
сети (или из VPN в неё). По возможности восстановим систему из бэкапа, дата которого раньше
времени модификации вредоносного файла и authorized_keys. Задачи отправим в контейнеры с
ограничением ресурсов, также настроим с помощью ulimit ограничения отдельным пользователям.
Обновим систему, включим SELinux.

14.

Итоговый вариант ответа
Процесс kswapd должен быть запущен от пользователя root, а не vasya. Это сразу наводит
на подозрения, что это – вредоносный код, а не настоящий kswapd. К тому же, настоящему kswapd
не нужно ничего делать, так как swap в данный момент пуст, а свободной памяти хватает.
Полностью загруженный процессор (2 ядра из 2 имеющихся) наводит на мысль, что это – майнер.
Найдём, что это за исполняемый файл (ls -al /proc/1234/executable), убьём процесс (kill -9
1234), переименуем и переместим вредоносный файл для дальнейшего анализа и запретим его
исполнение командой chmod.
Заблокируем скомпрометированному пользователю vasya вход по паролю (passwd -L
vasya), переименуем его авторизованные ключи (cp -p /home/vasya/.ssh/autorized_keys
/tmp/vasya_kswapd_keys, rm /home/vasya/.ssh/autorized_keys), просмотрим, а затем удалим его
таблицу автоматически запускаемых задач (crontab -l -u vasya, crontab -r -u vasya).
Для предотвращения инцидентов разрешим вход только по ключам и только из рабочей
сети (или из VPN в неё). По возможности восстановим систему из бэкапа, дата которого раньше
времени модификации вредоносного файла и authorzed_keys. Задачи отправим в контейнеры с
ограничением ресурсов, также настроим с помощью ulimit ограничения отдельным пользователям.
Обновим систему, включим SELinux

15.

Второй тип задания №5
В организации виртуальный сервер с 100-гигабайтным жёстким диском стал работать с
перебоями.
Команда df вывела:

16.

Команда mount вывела:
Команда du -h -s /home/*/*| grep G вывела:

17.

Команда df, mount | grep sd
Команда df -h выводит информацию о свободном месте на всех подключенных файловых
системах в удобном для человека (human-readable) формате.
mount | grep sd – поиск конкретных дисков, чтобы увидеть только физические диски, а не
виртуальные файловые системы

18.

du -h -s /home/*/* | grep G
du (disk usage) — показывает использование дискового пространства
-h — human-readable (размеры в Гб, Мб и т.д.)
-s — summary (суммарный размер, без детализации по подкаталогам)
/home/*/* — проверяет каталоги второго уровня внутри /home/
Например: /home/user1/documents/, /home/user2/downloads/
| grep G
Фильтрует вывод, оставляя только строки, содержащие букву G. То есть покажет только каталоги,
размер которых измеряется в Гигабайтах

19.

20.

Видим, что закончилось место на 100-гигабайтном жестком диске, но видим только 95 Гб
на файловой системе ext4. Значит, есть стандартные 5 Гб, зарезервированные для
суперпользователя. По занятому месту видим, что дисковое пространство потребляет
пользователь vasya, причём в каталоге PoS. Это сразу наводит на подозрения, что это – майнер
на базе предоставления жёсткого диска как места хранения.
Чтобы система была управляемой, разблокируем зарезервированные 5%:
tune2fs -m 0 /dev/sda7

21.

tune2s -m 0 /dev/sda7
Утилита для настройки параметров файловых систем ext2, ext3, ext4.
-m устанавливает % зарезервированного места.

22.

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

23.

Стандартные процедуры
Заблокируем скомпрометированному пользователю vasya вход по паролю (passwd -L vasya),
переименуем его авторизованные ключи
(cp -p /home/vasya/.ssh/authorized_keys
/tmp/vasya_kswapd_keys,
rm /home/vasya/.ssh/authorized_keys),
просмотрим, а затем удалим его таблицу автоматически запускаемых задач
(crontab -l -u vasya, crontab -r -u vasya).
Для предотвращения инцидентов разрешим вход только по ключам и только из рабочей
сети (или из VPN в неё). По возможности восстановим систему из бэкапа, дата которого раньше
времени модификации вредоносного файла и authorized_keys. Задачи отправим в контейнеры с
ограничением ресурсов, также настроим с помощью ulimit ограничения отдельным пользователям.
Обновим систему, включим SELinux.

24.

Итоговый варинат ответа
Видим, что закончилось место на 100-гигабайтном жёстком диске, но видим только 95 Гб
на файловой системе ext4. Значит, есть стандартные 5 Гб, зарезервированные для
суперпользователя. По занятому месту видим, что дисковое пространство потребляет
пользователь vasya, причём в каталоге PoS. Это сразу наводит на подозрения, что это – майнер на
базе предоставления жёсткого диска как места хранения.
Чтобы система была управляемой, разблокируем зарезервированные 5%.
tune2s -m 0 /dev/sda7
Смонтируем резервный накопитель, перенесём на него PoS, поинтересуемся у Васи, с какой
целью он майнит криптовалюту на рабочем сервере и предупредим об ответственности.
Заблокируем скомпрометированному пользователю vasya вход по паролю (passwd -L
vasya), переименуем его авторизованные ключи (cp -p /home/vasya/.ssh/autorized_keys
/tmp/vasya_kswapd_keys, rm /home/vasya/.ssh/autorized_keys), просмотрим, а затем удалим его
таблицу автоматически запускаемых задач (crontab -l -u vasya, crontab -r -u vasya).
Для предотвращения инцидентов разрешим вход только по ключам и только из рабочей
сети (или из VPN в неё). По возможности восстановим систему из бэкапа, дата которого раньше
времени модификации вредоносного файла и authorzed_keys. Задачи отправим в контейнеры с
ограничением ресурсов, также настроим с помощью ulimit ограничения отдельным пользователям.
Обновим систему, включим SELinux.