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

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

Напомню, что у файла есть несколько меток времени:

▪️Birth (crtime) - время создания айноды файла, то есть самого файла.
▪️Access (atime) - время последнего доступа к файлу.
▪️Modify (mtime) - время последнего изменения содержимого файла.
▪️Change (ctime) - время последнего изменения метаданных файла в файловой системе.

Посмотреть указанные метки можно командой stat:

# stat testfile

Поменять значения atime и mtime крайне просто. Можно взять банальную утилиту touch:

# touch -m -a -t 202501010000 testfile
# stat testfile
Access: 2025-01-01 00:00:00.000000000 +0300
Modify: 2025-01-01 00:00:00.000000000 +0300

То же самое можно сделать напрямую в файловой системе через debugfs:

# debugfs -w -R 'set_inode_field /var/www/testfile crtime 202501010000' /dev/sda1
# debugfs -w -R 'set_inode_field /var/www/testfile atime 202501010000' /dev/sda1
# debugfs -w -R 'set_inode_field /var/www/testfile mtime 202501010000' /dev/sda1
# debugfs -w -R 'set_inode_field /var/www/testfile ctime 202501010000' /dev/sda1
# echo 2 > /proc/sys/vm/drop_caches
# stat /var/www/testfile
Access: 2025-01-01 03:00:00.881765992 +0300
Modify: 2025-01-01 03:00:00.881765992 +0300
Change: 2025-01-01 03:00:00.881765992 +0300
Birth: 2025-01-01 03:00:00.881765992 +0300

В конце для проверки надо обязательно сбросить кэш, иначе изменений не увидите. Важно понимать, что для изменения atime и mtime достаточно обычных прав доступа к файлу. То есть любой червь, который залез через исходники сайта, может у него менять эти параметры. А вот для изменения crtime уже нужны права root, так как надо лезть в файловую систему.

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

# apt install auditd
# auditctl -w /var/www/testfile -p rwa -k testfile_rule

◽️rwa - чтение (r), запись (w), изменение атрибута (a)
◽️testfile_rule - название правила аудита

Смотрим список правил:

# auditctl -l
-w /var/www/testfile -p rwa -k testfile_rule

После изменения файла смотрим записи аудита:

# aureport -f -i | grep /var/www/testfile
# ausearch -i -k testfile_rule

Лог аудита хранится в директории /var/log/audit. Поддерживается работа через syslog, так что при желании этот лог выносится на внешний сервер, как я уже рассказывал в предыдущих заметках. Подобный аудит больше актуален для конфигурационных файлов служб, в том числе системных, а не исходников сайтов. Я просто показал пример.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#linux #terminal

Прочитал интересную статью про Linux IOWait в блоге компании Percona. У автора оказались подозрительно русские имя и фамилия - Peter Zaitsev. Навёл справки. Оказалось, что это Пётр Зайцев - сооснователь компании Percona. Я и не знал, что эта компания основана русскими, хотя пользуюсь её бесплатными продуктами много лет.

⇨ Understanding Linux IOWait

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

# sysbench --threads=8 --time=0 --max-requests=0 fileio --file-num=1 --file-total-size=10G --file-io-mode=sync --file-extra-flags=direct --file-test-mode=rndrd run

Используется утилита sysbench. Я, кстати, писал про неё. У неё есть встроенные тесты для СУБД. Приведённая выше команда жёстко нагрузит метрику cpu iowait. Проверить можно через vmstat, колонка wa.

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

# sysbench --threads=8 --time=0 cpu run

Снова смотрим на vmstat и видим, что нагрузка IOWait куда-то пропала. Как так? Первый тест продолжает нагружать диски, но мы уже этого не видим в привычной метрике.

Смысл тут вот в чём. Когда мы долго ждём ответа от дисков, процессор простаивает. Растёт метрика cpu idle. Простой процессора из-за ожидания I/O засчитывается в метрику IOWait. Но как только мы нагружаем процессор другой работой, метрика idle падает, а за ней и IOWait. Это особенность подсчёта этих метрик.

Теперь вместо первого теста в 8 потоков, запустим только один на виртуалке с 4-мя ядрами:

# sysbench --threads=1 --time=0 --max-requests=0 fileio --file-num=1 --file-total-size=10G --file-io-mode=sync --file-extra-flags=direct --file-test-mode=rndrd run

Несмотря на то, что этот тест тоже полностью нагрузит дисковую подсистему, мы увидим IOWait в районе 20-25%. А на виртуальных машинах с большим числом ядер (32-64) цифра будет настолько незначительна, что мы можем вообще не заметить её. Но при этом дисковая подсистема будет полностью загружена.

Таким образом, высокая метрика IOWait показывает, что процессор ожидает операции I/O. Но при этом низкий показатель не гарантирует, что у вас не загружены диски. Надо уточнять.

Как же узнать, что у нас есть проблемы с нагрузкой по I/O? Можно посмотреть на столбец b в vmstat. Он показывает количество процессов, которые заблокированы в ожидании I/O для завершения. Соседний столбец r покажет суммарное число запущенных процессов.

В продукте Percona Monitoring and Management есть плагин, который в том числе показывает статистику по процессам. Там будут видны процессы, ожидающие I/O. Указанный мониторинг бесплатен, это open source.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#linux #perfomance