Продолжу начатую недавно тему про заметание следов своей деятельности в системе на базе 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