Считается что будет полезным настроить виртуальную машину Ubuntu. Одна из причин заключается в том, что можно иметь доступ к хосту Linux, который очень похож на различные системы Linux, которые просматриваются во время поиска угроз и расследований. Этот пост поможет вам настроить и включить ведение журнала, котороесчитается чрезвычайно полезным не только для работы в компании, но и для проектов и игр. В частности, мы рассмотрим настройку включение ведение журнала временных меток файла истории Linux.
В своей работе люди часто думают о команде, которую нужно было запустить из терминала в режиме командной строки, и о том, была ли она полезна, сложна, состояла ли из множества шагов и т. д. Итак, если эти команды нужно было напомню, мы можем сделать это, используя известное средство, которое существует со времен BSD-версий Unix: History. Они, как правило, очень полезны, чтобы вспомнить, какие введенные пользователем команды записывала ОС. Для тех из нас, кто расследует подозрительные компьютерные действия, вспышки вредоносного ПО или взломы, история фиксирует множество ключевых артефактов и действий. Однако определить, когда это произошло, может быть сложнее, если система настроена по умолчанию (https://par.nsf.gov/servlets/purl/10213652).
tmillar@HP8200:/dev/shm$ cd /dev/shm
tmillar@HP8200:/dev/shm$ touch altair deneb vega
tmillar@HP8200:/dev/shm$ history
1 cd /dev/shm
2 touch altair deneb vega
3 history
Глядя на другие примеры, мы можем сделать выводы о том, когда команды были отправлены в систему лицом, контролирующим идентификатор пользователя. Пожалуйста, имейте в виду, что временные метки файлов подобны загрузочным отпечаткам в грязи: самые последние — это те, которые вы, скорее всего, разглядите с хорошей степенью уверенности для каждого, измененного (mtime), доступного (atime) или измененного (ctime). Также важно отметить, что файловая система Linux ext2/3 не будет создана (btime); однако с тех пор это было реализовано в ext4. Кроме того, важно понимать, что временные метки файлов можно манипулировать или изменять. Когда это происходит, это может сбить экзаменатора с толку, если он не знает, где еще посмотреть или проверить заявленные им значения времени.
Ниже приведен пример такой ситуации. Содержимое файла /etc/passwd отображается, перенаправляется в папку /dev/shm и переименовывается в mycopy_passwd. Затем права доступа к файлу изменяются с помощью команды chmod, и можно проверить статистику файла, чтобы проверить эти разрешения и временные метки.
$ cat /etc/passwd >> /dev/shm/mycopy_passwd
$ chmod 744 /dev/shm/mycopy_passwd
$ stat /dev/shm/mycopy_passwd
File: '/dev/shm/mycopy_passwd'
Size: 2418 Blocks: 8 IO Block: 4096 regular file
Device: 18h/24d Inode: 3 Links: 1
Access: (0744/-rwxr--r--) Uid: ( 1000/ tmillar) Gid: ( 1000/ tmillar)
Access: 2022-10-07 08:20:41.091102055 -0700
Modify: 2022-10-07 08:20:41.091102055 -0700
Change: 2022-10-07 08:24:45.491107440 -0700
Birth: -
Запись истории выглядит так:
tmillar@HP8200:~$ history |tail -n4
859 cat /etc/passwd >> /dev/shm/mycopy_passwd
860 chmod 744 /dev/shm/mycopy_passwd
861 stat /dev/shm/mycopy_passwd
862 history |tail -n4
Затем мы можем использовать команду cat для нового файла, чтобы увидеть его содержимое. Повторный запуск команды stat для файлового артефакта позволяет нам увидеть, что отметка времени доступа была обновлена. Отсюда мы можем получить историю, чтобы убедиться, что мы получили полный список соответствующих записей. Из того, что мы видим, все, что было введено в командную строку, присутствует в этом листинге. Но имейте в виду, что список истории показывает только то, что они произошли последовательно, и хотя это создает у нас впечатление, что каждая команда выполнялась сразу после другой, вывод статистики говорит нам, что между моментами обработки или обработки была задержка в несколько минут. доступ к файлу. Дополнительный контекст, предоставляемый командой stat, дает нам ценную перспективу, особенно в сочетании с этим содержимым списка истории, которое содержит фактические вовлеченные файлы. Ниже вы можете увидеть вывод статистики, за которым следует вывод истории.
$ stat /dev/shm/mycopy_passwd
File: '/dev/shm/mycopy_passwd'
Size: 2418 Blocks: 8 IO Block: 4096 regular file
Device: 18h/24d Inode: 3 Links: 1
Access: (0744/-rwxr--r--) Uid: ( 1000/ tmillar) Gid: ( 1000/ tmillar)
Access: 2022-10-07 08:27:18.515110812 -0700
Modify: 2022-10-07 08:20:41.091102055 -0700
Change: 2022-10-07 08:24:45.491107440 -0700
Birth: -
tmillar@HP8200:~$ history |tail -n8
859 cat /etc/passwd >> /dev/shm/mycopy_passwd
860 chmod 744 /dev/shm/mycopy_passwd
861 stat /dev/shm/mycopy_passwd
862 history |tail -n4
863 cat /dev/shm/mycopy_passwd
864 stat /dev/shm/mycopy_passwd
865 history |tail -n7
Теперь у нас есть представление о том, когда что-то произошло, на основе временных меток метаданных, которые показывают, когда произошел доступ, в 08:27 по местному времени, и когда запись в папке /dev/shm произошла с chmod, происходящим в 08:24. местное время.
Но какие варианты доступны, когда у вас нет командной активности, которая могла бы сказать вам, когда действительно выполнялись команды, помимо выводов или изучения записей журнала? Что вы можете сделать, если кто-то преднамеренно уничтожил файлы, которые вы хотели просмотреть, после того, как они были упомянуты в файле .bash_history, который вам нужен, чтобы понять, как они вписываются в временную шкалу? Это лежит в основе того, о чем мы поговорим дальше.
Современный хост Linux может отслеживать не только фактические параметры команды, введенные в командную строку, но также отслеживать время, за которое это делается. Системное значение, называемое $HISTTIMEFORMAT, определяет, КАК ОС отображает команды и время их выполнения. Однако это доступно только в том случае, если файл сохраняется на диск. Если по стечению обстоятельств, когда была введена серия команд, и внезапно отключилось питание, есть большая вероятность, что редакция файла .bash_history не будет записана на диск и сохранена. Это означает, что при повторном включении системы будет присутствовать только предыдущий сеанс и его содержимое. Однако случайные происшествия, такие как отключение электроэнергии или другие незапланированные бедствия, таковы: случайность. В противном случае у исследователя может появиться шанс обнаружить исторические артефакты и время, когда они имели место. Одно из ключевых соображений относительно $HISTTIMEFORMAT заключается в том, что после указания фактической строки формата (например, %F – %Z) операционная система Linux будет записывать значения времени каждой команды, введенной в этом профиле пользователя, максимально эффективным для машины способом. . Обычно это означает время эпохи Unix. Это значение времени в секундах с полуночи 1 января 1970 года по Гринвичу. Это эффективно для отслеживания времени с точностью до одной секунды, но также предлагает нам еще одну функцию, которую мы обсудим позже.
Здесь мы можем установить строку формата временной метки нашей истории, чтобы дать нам дату и время в терминах местного времени:
%F -%R
Я лично предпочитаю, чтобы мои списки истории включали время эпохи Unix, местное время и часовой пояс, потому что это удобно, чтобы иметь возможность вспоминать полезные или сложные команды. Удобочитаемый вывод полезен, так как позволяет «собирать» вывод из истории по дням или месяцам, что особенно удобно. Наличие времени Unix в списке помогает мне понять, какое релевантное время в секундах было, когда были выданы команды.
Следующая история команд показывает порядок команд, используемых для установки TimeSketch на новый хост Ubuntu. В нем вы можете увидеть время эпохи Unix, а также удобочитаемое для человека обозначение TZ, предшествующее каждой команде.
10 1665081386 2022-10-06 11:36-PDT curl -s -O https://raw.githubusercontent.com/google/timesketch/master/contrib/deploy_timesketch.sh
11 1665081407 2022-10-06 11:36-PDT chmod 755 deploy_timesketch.sh
12 1665081428 2022-10-06 11:37-PDT ls
13 1665081441 2022-10-06 11:37-PDT mkdir Tools/installers
14 1665081518 2022-10-06 11:38-PDT mkdir Tools/installers/timesketch
15 1665081528 2022-10-06 11:38-PDT mv deploy_timesketch.sh Tools/installers/timesketch/
16 1665081532 2022-10-06 11:38-PDT cd /opt
17 1665081542 2022-10-06 11:39-PDT pwd
18 1665081556 2022-10-06 11:39-PDT sudo ~/Tools/installers/timesketch/deploy_timesketch.sh
19 1665082385 2022-10-06 11:53-PDT sudo docker-compose exec timesketch-web tsctl create-user parallels
20 1665082913 2022-10-06 12:01-PDT sudo docker-compose down
21 1665082936 2022-10-06 12:02-PDT ls
22 1665082939 2022-10-06 12:02-PDT cd timesketch/
23 1665082940 2022-10-06 12:02-PDT ls
24 1665082946 2022-10-06 12:02-PDT sudo docker-compose down
25 1665082953 2022-10-06 12:02-PDT sudo docker-compose up -d
26 1665082961 2022-10-06 12:02-PDT history
26 1665082961 2022-10-06 12:02-PDT history
Независимо от выбранного стиля формата, формат времени эпохи Unix и разделители, зависящие от ОС Linux (например, #), будут записываться на диск. Даже если история будет очищена злонамеренно или иным образом, те, что были записаны, оставят после себя заметный и полезный шаблон в структурах данных: символ пробела, за которым следует знак решетки (#), а затем время эпохи Unix. Исходя из этого, можно сформулировать поиск по регулярному выражению для идентификации совпадающих данных на диске. Снова и снова они всплывали на поверхность при вырезании элементов из нераспределенного пространства и очень помогли мне понять, что произошло в инциденте.
На приведенном ниже рисунке показана часть файла истории, записанного на диск, как в шестнадцатеричном формате, так и в виде строк ASCII открытого текста справа.
$xxd .bash_history
00000000: 2331 3636 3530 3831 3137 370a 6869 7374 #1665081177.hist
00000010: 6f72 790a 2331 3636 3530 3831 3238 360a ory.#1665081286.
00000020: 7375 646f 2061 7074 2069 6e73 7461 6c6c sudo apt install
00000030: 2064 6f63 6b65 722d 636f 6d70 6f73 650a docker-compose.
00000040: 2331 3636 3530 3831 3331 300a 6869 7374 #1665081310.hist
00000050: 6f72 790a 2331 3636 3530 3831 3333 360a ory.#1665081336.
00000060: 1b5b 3230 307e 6375 726c 202d 7320 2d4f .[200~curl -s -O
00000070: 2068 7474 7073 3a2f 2f72 6177 2e67 6974 https://raw.git
00000080: 6875 6275 7365 7263 6f6e 7465 6e74 2e63 hubusercontent.c
00000090: 6f6d 2f67 6f6f 676c 652f 7469 6d65 736b om/google/timesk
000000a0: 6574 6368 2f6d 6173 7465 722f 636f 6e74 etch/master/cont
000000b0: 7269 622f 6465 706c 6f79 5f74 696d 6573 rib/deploy_times
000000c0: 6b65 7463 682e 7368 0a23 3136 3635 3038 ketch.sh.#166508
000000d0: 3133 3634 0a77 6869 6368 2063 7572 6c0a 1364.which curl.
000000e0: 2331 3636 3530 3831 3338 360a 6375 726c #1665081386.curl
000000f0: 202d 7320 2d4f 2068 7474 7073 3a2f 2f72 -s -O https://r
00000100: 6177 2e67 6974 6875 6275 7365 7263 6f6e aw.githubusercon
00000110: 7465 6e74 2e63 6f6d 2f67 6f6f 676c 652f tent.com/google/
00000120: 7469 6d65 736b 6574 6368 2f6d 6173 7465 timesketch/maste
00000130: 722f 636f 6e74 7269 622f 6465 706c 6f79 r/contrib/deploy
00000140: 5f74 696d 6573 6b65 7463 682e 7368 0a23 _timesketch.sh.
Это показывает связь между предыдущим показом на основе времени, поскольку он записан в секундах с 1 января 1970 года по Гринвичу. Вы также можете четко разобрать структуру для каждой записи, касающуюся времени и записанной команды.
Это было сделано, когда следующие строки Bash были добавлены в файл /etc/profile системы Ubuntu.
HISTSIZE=7000000
HISTTIMEFORMAT="%s %F %R-%Z "
if [ "$HISTCONTROL" = "ignorespace" ] ; then
export HISTCONTROL=ignoreboth
else
export HISTCONTROL=ignoredups
fi
Описание этих опций начинается с %s, обозначающего время эпохи Unix в секундах, за которым следует строка, которая печатает числовую форму год-месяц-дата, за которой следует пробел. Время сообщается в 24-часовом формате часы-минуты-секунды по отношению к местному времени хоста. Обозначение часового пояса (TZ) идет почти последним с дефисом между временем и TZ. Для удобочитаемости я намеренно добавил символ пробела, чтобы термин TZ и начало записанной командной строки были немного разделены между собой. Индивидуальный вкус строк и переменных формата можно найти на главных страницах используемых вами интерпретаторов (SYS V, csh, bash и т. д.). Вы также можете добавить их в отдельные файлы профиля для учетной записи суперпользователя «root».
Прежде чем добавлять это в файл .bash_profile или в глобальный файл /etc/profile, следует отметить, что в первый раз, когда пользователь выполняет перезагрузку или выходит из системы, снова входит в систему и проверяет историю, что-то необычное. и путаница появляется в списке. Может показаться, что все записи истории до того времени, когда они определили значение $HISTTIMEFORMAT, имеют одинаковое точное время. Это известная проблема, и ее можно решить путем резервного копирования содержимого предыдущего файла истории. Следующим шагом будет очистка истории после установки $HISTTIMEFORMAT. Таким образом, вы можете иметь запись всех примененных командных событий, и они будут иметь свои собственные значения времени с точностью до секунды. Обязательно проверьте это, если вы применяете его после использования хоста. Вот почему мне нравится настраивать его сразу после настройки новой системы Linux/Unix или виртуальной машины.
Заключение
В этой статье мы обсудили это, несмотря на то, что история Linux может быть не совсем достоверной и может не сообщать вам специфики, когда что-то выполнялось в сеансе командной строки. Тем не менее, мы рассмотрели несколько способов добавления временных меток к записям истории и обсудили способы использования данных во время инцидентов, связанных с компьютерной безопасностью, или при криминалистических обстоятельствах. Я надеюсь, что вам понравилось читать это, и вы решили, что вы можете использовать, чтобы помочь с вашими потребностями в журналировании истории команд.