centos 6, centos7

Как узнать, кто редактировал файлы в системах Linux

Thank you for reading this post, don't forget to subscribe!

Linux предо­став­ля­ет поль­зо­ва­тель­ские инстру­мен­ты для ауди­та без­опас­но­сти под назва­ни­ем auditd (Audit daemon). auditd отсле­жи­ва­ет все изме­не­ния, про­ис­хо­дя­щие в систе­ме, и гене­ри­ру­ет жур­на­лы, кото­рые мож­но про­ана­ли­зи­ро­вать, что­бы полу­чить пред­став­ле­ние о состо­я­нии без­опас­но­сти системы.

Как найти пользователя, который редактировал файлы в Linux

Не суще­ству­ет про­сто­го спо­со­ба узнать, кто и какие фай­лы изме­нил на Linux.

Одна­ко auditd дела­ет этот про­цесс простым.

Установка пакетов auditd на Linux

В этом руко­вод­стве мы будем исполь­зо­вать две систе­мы, на базе Debian и RHEL, что­бы пока­зать, как пакет Audit может быть исполь­зо­ван для выяс­не­ния того, кто редак­ти­ро­вал фай­лы в Linux.

Red Hat Enterprise Linux предо­став­ля­ет функ­цию пра­вил ауди­та для реги­стра­ции дей­ствий фай­лов, выпол­нен­ных поль­зо­ва­те­ля­ми или процессами.

Это может быть достиг­ну­то путем настрой­ки пра­вил аудита.

Выпол­ни­те шаги, опи­сан­ные ниже, что­бы настро­ить пра­ви­ла audd для мони­то­рин­га уда­ле­ния фай­лов в систе­ме CentOS / RHEL.

Шаги настройки правил аудита для CentOS / RHEL 4,5,6

1. Что­бы настро­ить пра­ви­ла ауди­та, добавь­те сле­ду­ю­щую стро­ку в файл /etc/audit.rules (для RHEL 5,6 исполь­зуй­те файл /etc/audit/audit.rules).

Для CentOS / RHEL 4:

2. При жела­нии вы може­те ука­зать пол­ный путь к ката­ло­гу для про­смот­ра, напри­мер, если вы хоти­те отсле­жи­вать уда­ле­ние фай­лов толь­ко в опре­де­лен­ной фай­ло­вой систе­ме, вы може­те ука­зать точ­ку мон­ти­ро­ва­ния, доба­вив сле­ду­ю­щее поле в пра­ви­ло аудита:

-F dir=[directory or mount point]

3. После напи­са­ния пра­вил пере­за­пу­сти­те служ­бу auditd и вклю­чи­те ее, что­бы сохра­нить пра­ви­ла после перезагрузки.

# /etc/init.d/auditd restart
# chkconfig auditd on

Auditd будет реги­стри­ро­вать опе­ра­ции уда­ле­ния в фай­ле /var/log/audit/audit.log, одна­ко мы можем исполь­зо­вать коман­ду ausearch с клю­чом, ука­зан­ным в пра­ви­ле ауди­та (-k), для про­смот­ра событий:

# ausearch -k delete

Шаги для CentOS / RHEL 7

1. Что­бы настро­ить пра­ви­ла ауди­та, добавь­те сле­ду­ю­щую стро­ку в файл /etc/audit/rules.d/audit.rules.

2. При жела­нии вы може­те ука­зать пол­ный путь к ката­ло­гу для про­смот­ра, напри­мер, если вы хоти­те отсле­жи­вать уда­ле­ние фай­лов толь­ко в опре­де­лен­ной фай­ло­вой систе­ме, вы може­те ука­зать точ­ку мон­ти­ро­ва­ния, доба­вив сле­ду­ю­щее поле в пра­ви­ло аудита:

-F dir=[directory or mount point]

3. После напи­са­ния пра­вил пере­за­пу­сти­те служ­бу auditd и вклю­чи­те ее, что­бы сохра­нить пра­ви­ла после перезагрузки.

# service auditd restart ### use of command service instead of systemctl is intentional here.
# systemctl enable auditd

Auditd будет реги­стри­ро­вать опе­ра­ции уда­ле­ния фай­ла в фай­ле /var/log/audit/audit.log, одна­ко мы можем исполь­зо­вать коман­ду ausearch с клю­чом, ука­зан­ным в пра­ви­ле ауди­та (-k), для про­смот­ра событий:

# ausearch -k delete

===============================================

В дис­три­бу­ти­вах на базе Debian;

apt install auditd -y

Инструменты пакета Audit

Пакет Audit постав­ля­ет­ся с несколь­ки­ми инстру­мен­та­ми с раз­лич­ны­ми функ­ци­о­наль­ны­ми возможностями.

К ним относятся:

  • auditd – ком­по­нент поль­зо­ва­тель­ско­го про­стран­ства, кото­рый отве­ча­ет за запись запи­сей ауди­та на диск.
  • ausearch – поль­зо­ва­тель­ский ком­по­нент для запро­са логов демо­на аудита.
  • aureport – поль­зо­ва­тель­ский ком­по­нент, созда­ю­щий свод­ные отче­ты по логам аудита.
  • auditctl – про­грам­ма, исполь­зу­е­мая для настрой­ки пара­мет­ров ядра, свя­зан­ных с ауди­том, про­смот­ра состо­я­ния кон­фи­гу­ра­ции и загруз­ки дис­кре­ци­он­ных пра­вил ауди­та. При загруз­ке систе­мы auditctl счи­ты­ва­ет пра­ви­ла в фай­ле /etc/audit/audit.rules и загру­жа­ет их в ядро.

Что­бы про­ве­рить состояние;

systemctl status auditd

Узнаем, кто отредактировал файлы в Linux с помощью Auditd

Для того что­бы узнать, кто редак­ти­ро­вал фай­лы в Linux с помо­щью Auditd, необ­хо­ди­мо настро­ить пра­ви­ла ауди­та фай­ло­вой системы.

Обра­ти­те вни­ма­ние, что суще­ству­ют раз­лич­ные пра­ви­ла ауди­та, кото­рые опре­де­ля­ют, как отсле­жи­вать изме­не­ния в систе­ме. К ним относятся:

Control rules: Поз­во­ля­ют изме­нять пове­де­ние систе­мы ауди­та и неко­то­рые ее конфигурации.
File system rules:поз­во­ля­ют про­во­дить аудит досту­па к опре­де­лен­но­му фай­лу или ката­ло­гу. Они так­же извест­ны как “фай­ло­вые часы”.
System call rules: Поз­во­ля­ют вести жур­нал систем­ных вызо­вов, кото­рые выпол­ня­ет любая ука­зан­ная программа.

Нас инте­ре­су­ют толь­ко file system rules, посколь­ку они поз­во­ля­ют нам узнать, кто редак­ти­ро­вал фай­лы в Linux.

Как было ска­за­но выше, ути­ли­та auditctl может быть исполь­зо­ва­на для настрой­ки пра­вил аудита.

Настройка правил аудита файловой системы

Вы може­те настро­ить пра­ви­ла ауди­та фай­ло­вой систе­мы в команд­ной стро­ке с помо­щью коман­ды auditctl.

Син­так­сис коман­ды следующий;

auditctl -w path_to_file -p access_permissions -k filter_key

Исполь­зу­ют­ся сле­ду­ю­щие опции:

  • -w path_to_file: опре­де­ля­ет путь к объ­ек­ту фай­ло­вой систе­мы, за кото­рым ведет­ся наблюдение.
  • -p access_permissions: (-p [r|w|x|a]) Опи­сы­ва­ет тип раз­ре­ше­ния досту­па, на кото­рый будет сра­ба­ты­вать наблю­де­ние за фай­ло­вой систе­мой. r=чтение, w=запись, x=выполнение, a=изменение атри­бу­тов. Обра­ти­те вни­ма­ние, что это не стан­дарт­ные раз­ре­ше­ния фай­лов, а ско­рее систем­ный вызов, кото­рый будет выпол­нять подоб­ные действия.
  • -k filter_key: опре­де­ля­ет про­из­воль­ную стро­ку тек­ста, дли­на кото­рой может дости­гать 31 бай­та. Она может одно­знач­но иден­ти­фи­ци­ро­вать запи­си ауди­та, создан­ные правилом.

Напри­мер, мы хотим сле­дить за изме­не­ни­я­ми чтения/записи и атри­бу­тов фай­ла /etc/ssh/sshd_config, тогда мы опре­де­лим пра­ви­ло сле­ду­ю­щим образом;

auditctl -w /etc/ssh/sshd_config -p wax -k monitor_sshd_conf

Обра­зец вывода;

 

Что­бы про­ве­рить это пра­ви­ло, попро­буй­те изме­нить файл /etc/ssh/sshd_config.

От име­ни поль­зо­ва­те­ля (не root) выпол­ни­те коман­ду сле­ду­ю­щим образом;

echo "AllowUsers itsecforu root" | sudo tee -a /etc/ssh/sshd_config

Если вы хоти­те пре­кра­тить мони­то­ринг фай­ла с помо­щью auditctl;

auditctl -W /etc/ssh/sshd_config -p wax -k monitor_sshd_conf

Настройка правил аудита файловой системы

Что­бы настро­ить посто­ян­ные пра­ви­ла, сохра­ня­ю­щи­е­ся при пере­за­груз­ке систе­мы, вы може­те раз­ме­стить пра­ви­ла в ката­ло­ге /etc/audit/audit.rules или в ката­ло­ге /etc/audit/rules.d/.

Пра­ви­ла в фай­ле /etc/audit/audit.rules созда­ют­ся на осно­ве пра­вил, опре­де­лен­ных в ката­ло­ге /etc/audit/rules.d/.

Если пра­ви­ла раз­ме­ще­ны в ката­ло­ге /etc/audit/rules.d/, их необ­хо­ди­мо загру­зить с помо­щью ути­ли­ты augenrules.

Напри­мер:

echo "-w /etc/ssh/sshd_config -p wxa -k monitor_sshd_conf" > /etc/audit/rules.d/sshd.rules

Про­верь­те, обна­ру­же­ны ли изменения;

augenrules --check

Загру­зи­те правила;

augenrules --load

Это долж­но обно­вить файл /etc/audit/audit.rules.

Пере­за­пу­сти­те служ­бу auditd;

systemctl restart auditd

Про­верь­те правила;

auditctl -l

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

Чте­ние фай­ла  логов ауди­та, /var/log/audit/audit.log.

grep --color monitor_sshd_conf /var/log/audit/audit.log

 

Созда­ние отче­та с помо­щью aureport (подроб­нее читай­те в man aureport)

aureport -i -k

Key Report

Выпол­ним поиск в логах с помо­щью коман­ды ausearch (подроб­нее читай­те в man ausearch).

ausearch -i -k monitor_sshd_conf

Из выво­да отче­та ausearch попро­бу­ем интер­пре­ти­ро­вать поля записей.

  • type=PROCTITLE: Тип запи­си, кото­рый дает пол­ную команд­ную стро­ку, вызвав­шую это собы­тие аудита.
  • msg=audit(12/08/2021 20:24:38.290:13): Опре­де­ля­ет мет­ку вре­ме­ни и уни­каль­ный ID запи­си в фор­ме audit(time_stamp:ID). Вре­мя обыч­но отоб­ра­жа­ет­ся в EPOCH, если вы не исполь­зу­е­те опцию -i.
    Если вре­мя в EPOCH, напри­мер, 1638984357.760, то пре­об­ра­зуй­те его с помо­щью коман­ды date;

date -d @1638984357.760

Wed 08 Dec 2021 08:25:57 PM EAT

 

  • proctitle=tee -a /etc/ssh/sshd_config: В поле запи­сы­ва­ет­ся пол­ная стро­ка коман­ды, кото­рая была исполь­зо­ва­на для вызо­ва ана­ли­зи­ру­е­мо­го про­цес­са. Без опции -i она была бы отоб­ра­же­на в шест­на­дца­те­рич­ном виде.
  • type=PATH: тип запи­си PATH запи­сы­ва­ет путь, кото­рый пере­да­ет­ся систем­но­му вызо­ву в каче­стве аргу­мен­та, в дан­ном слу­чае путь – /etc/ssh/sshd_config.
  • item=1: поле item ука­зы­ва­ет, какой эле­мент из обще­го чис­ла эле­мен­тов, на кото­рые ссы­ла­ет­ся запись типа SYSCALL, явля­ет­ся теку­щим. зна­че­ние 1 озна­ча­ет, что это вто­рой элемент.
  • name=/etc/ssh/sshd_config: Запи­сы­ва­ет путь к фай­лу или ката­ло­гу, кото­рый был пере­дан систем­но­му вызо­ву в каче­стве аргу­мен­та. В дан­ном слу­чае это был файл /etc/ssh/sshd_config.
  • inode=526305: поле inode содер­жит номер inode, свя­зан­ный с фай­лом или ката­ло­гом, запи­сан­ным в этом собы­тии. Сле­ду­ю­щая коман­да отоб­ра­жа­ет файл или ката­лог, свя­зан­ный с номе­ром inode 526305:

find / -inum 526305 -print

/etc/ssh/sshd_config

  • dev=08:01: Поле опре­де­ля­ет минор­ный и мажор­ный иден­ти­фи­ка­тор устрой­ства, кото­рое содер­жит файл или ката­лог, запи­сан­ный в этом событии.
  • mode=file,644: Поле mode запи­сы­ва­ет раз­ре­ше­ния на файл или ката­лог, 644 озна­ча­ет -rw-r-r- для фай­ла /etc/ssh/sshd_config.
  • ouid=root: В поле ouid запи­сы­ва­ет­ся иден­ти­фи­ка­тор пользователя/имя поль­зо­ва­те­ля вла­дель­ца объекта.
  • ogid=root: В поле ogid запи­сы­ва­ет­ся иден­ти­фи­ка­тор группы/имя поль­зо­ва­те­ля вла­дель­ца объекта.
  • rdev=00:00: Поле rdev содер­жит запи­сан­ный иден­ти­фи­ка­тор устрой­ства толь­ко для спе­ци­аль­ных фай­лов. В дан­ном слу­чае оно не исполь­зу­ет­ся, так как запи­сан­ный файл явля­ет­ся обыч­ным файлом.
  • nametype=NORMAL: запи­сы­ва­ет наме­ре­ние опе­ра­ции каж­дой запи­си пути в кон­тек­сте дан­но­го систем­но­го вызова.
  • cap_fp=none: Поле cap_fp запи­сы­ва­ет дан­ные, свя­зан­ные с уста­нов­кой раз­ре­шен­ной воз­мож­но­сти объ­ек­та фай­ла или ката­ло­га на осно­ве фай­ло­вой системы.
  • cap_fi=none: В поле cap_fi запи­сы­ва­ют­ся дан­ные, свя­зан­ные с уста­нов­кой уна­сле­до­ван­ной воз­мож­но­сти фай­ло­вой систе­мы объ­ек­та фай­ла или каталога.
  • cap_fe=0: В поле cap_fe запи­сы­ва­ет­ся уста­нов­ка эффек­тив­но­го бита воз­мож­но­сти объ­ек­та фай­ла или ката­ло­га на осно­ве фай­ло­вой системы.
  • cap_fver=0: В поле cap_fver запи­сы­ва­ет­ся вер­сия воз­мож­но­сти объ­ек­та фай­ла или ката­ло­га на осно­ве фай­ло­вой системы.
  • type=CWD: запи­сы­ва­ет рабо­чий ката­лог, из кото­ро­го выпол­нял­ся про­цесс, вызвав­ший систем­ный вызов.
  • cwd=/home/kifarunix: ука­зы­ва­ет ката­лог, в кото­ром был вызван систем­ный вызов.
  • type=SYSCALL: ука­зы­ва­ет, что запись была вызва­на систем­ным вызо­вом ядра.
  • arch=x86_64: Поле содер­жит инфор­ма­цию об архи­тек­ту­ре про­цес­со­ра систе­мы. Если опция -i не исполь­зу­ет­ся с auseardh, зна­че­ние отоб­ра­жа­ет­ся в шест­на­дца­те­рич­ной систе­ме счисления.
  • syscall=openat: В поле syscall запи­сы­ва­ет­ся тип систем­но­го вызо­ва, кото­рый был послан ядру. Если с ausearch исполь­зу­ет­ся опция -i, зна­че­ния интер­пре­ти­ру­ют­ся, в про­тив­ном слу­чае пока­зы­ва­ют­ся чис­ло­вые зна­че­ния. Исполь­зуй­те коман­ду ausyscall –dump, что­бы выве­сти спи­сок всех систем­ных вызо­вов вме­сте с их номе­ра­ми. Для полу­че­ния допол­ни­тель­ной инфор­ма­ции см. man ausyscall.
  • success=yes: В поле success запи­сы­ва­ет­ся, был ли систем­ный вызов, запи­сан­ный в дан­ном собы­тии, успеш­ным или неудач­ным. В дан­ном слу­чае вызов про­шел успешно.
  • exit=3: Поле содер­жит зна­че­ние, опре­де­ля­ю­щее код завер­ше­ния, воз­вра­щен­ный систем­ным вызо­вом. Для раз­ных систем­ных вызо­вов это зна­че­ние различно.
  • a0=0xffffff9c a1=0x7fffe54487de a2=O_WRONLY|O_CREAT|O_APPEND a3=0x1b6: Поля a0 – a3 запи­сы­ва­ют пер­вые четы­ре аргу­мен­та, зако­ди­ро­ван­ные в шест­на­дца­те­рич­ной систе­ме счис­ле­ния, систем­но­го вызо­ва в дан­ном собы­тии. Эти аргу­мен­ты зави­сят от исполь­зу­е­мо­го систем­но­го вызова.
  • items=2: Поле items содер­жит коли­че­ство вспо­мо­га­тель­ных запи­сей PATH, кото­рые сле­ду­ют за запи­сью систем­но­го вызова.
  • ppid=987: В поле ppid запи­сы­ва­ет­ся иден­ти­фи­ка­тор роди­тель­ско­го про­цес­са (PPID).
  • pid=988: В поле pid запи­сы­ва­ет­ся иден­ти­фи­ка­тор про­цес­са (PID).
  • auid=itsecforu: В поле auid запи­сы­ва­ет­ся иден­ти­фи­ка­тор поль­зо­ва­те­ля ауди­та, то есть loginuid. Этот иден­ти­фи­ка­тор при­сва­и­ва­ет­ся поль­зо­ва­те­лю при вхо­де в систе­му и насле­ду­ет­ся каж­дым про­цес­сом, даже если лич­ность поль­зо­ва­те­ля меня­ет­ся, напри­мер, при смене учет­ной записи.
  • uid=root: В поле uid запи­сы­ва­ет­ся иден­ти­фи­ка­тор поль­зо­ва­те­ля, кото­рый запу­стил ана­ли­зи­ру­е­мый про­цесс. Иден­ти­фи­ка­тор поль­зо­ва­те­ля может быть интер­пре­ти­ро­ван в име­на поль­зо­ва­те­лей при исполь­зо­ва­нии опции -i с ausearch. Вы так­же може­те интер­пре­ти­ро­вать с помо­щью сле­ду­ю­щей коман­ды: ausearch -i -uid UID.
  • gid=root: В поле gid запи­сы­ва­ет­ся иден­ти­фи­ка­тор груп­пы поль­зо­ва­те­ля, кото­рый запу­стил ана­ли­зи­ру­е­мый процесс.
  • euid=root: В поле euid запи­сы­ва­ет­ся эффек­тив­ный иден­ти­фи­ка­тор поль­зо­ва­те­ля, запу­стив­ше­го ана­ли­зи­ру­е­мый процесс.
  • suid=root: В поле suid запи­сы­ва­ет­ся уста­нов­лен­ный иден­ти­фи­ка­тор поль­зо­ва­те­ля, запу­стив­ше­го ана­ли­зи­ру­е­мый процесс.
  • fsuid=root: В поле fsuid запи­сы­ва­ет­ся иден­ти­фи­ка­тор поль­зо­ва­те­ля фай­ло­вой систе­мы поль­зо­ва­те­ля, запу­стив­ше­го ана­ли­зи­ру­е­мый процесс.
  • egid=root: В поле egid запи­сы­ва­ет­ся иден­ти­фи­ка­тор эффек­тив­ной груп­пы поль­зо­ва­те­ля, запу­стив­ше­го ана­ли­зи­ру­е­мый процесс.
  • sgid=root: В поле sgid запи­сы­ва­ет­ся иден­ти­фи­ка­тор уста­нов­лен­ной груп­пы поль­зо­ва­те­ля, запу­стив­ше­го ана­ли­зи­ру­е­мый процесс.
  • fsgid=root: В поле fsgid запи­сы­ва­ет­ся иден­ти­фи­ка­тор груп­пы фай­ло­вой систе­мы поль­зо­ва­те­ля, запу­стив­ше­го ана­ли­зи­ру­е­мый процесс.
  • tty=pts1: В поле tty запи­сы­ва­ет­ся тер­ми­нал, с кото­ро­го был вызван ана­ли­зи­ру­е­мый процесс.
  • ses=5: В поле ses запи­сы­ва­ет­ся иден­ти­фи­ка­тор сес­сии, из кото­рой был вызван ана­ли­зи­ру­е­мый процесс.
  • comm=tee: В поле comm запи­сы­ва­ет­ся имя команд­ной стро­ки коман­ды, кото­рая была исполь­зо­ва­на для вызо­ва ана­ли­зи­ру­е­мо­го процесса.
  • exe=/usr/bin/tee: В поле exe запи­сы­ва­ет­ся путь к испол­ня­е­мо­му фай­лу, кото­рый был исполь­зо­ван для вызо­ва ана­ли­зи­ру­е­мо­го процесса.
  • subj=unconfined: В поле subj запи­сы­ва­ет­ся кон­текст SELinux, кото­рым был поме­чен ана­ли­зи­ру­е­мый про­цесс во вре­мя выполнения.
  • key=monitor_sshd_conf: В поле key запи­сы­ва­ет­ся опре­де­ля­е­мая адми­ни­стра­то­ром стро­ка, свя­зан­ная с пра­ви­лом, кото­рое поро­ди­ло это собы­тие в логах аудита.

Вид­но, что:

  • файл кон­фи­гу­ра­ции SSH-сер­ве­ра, /etc/ssh/sshd_config, был обнов­лен с помо­щью коман­ды tee.
  • Коман­да была выпол­не­на из ката­ло­га /home/itsecforu.
  • Изме­не­ния были вне­се­ны поль­зо­ва­те­лем itsecforu от поль­зо­ва­те­ля root (с помо­щью sudo).