{"id":11065,"date":"2021-12-08T23:59:07","date_gmt":"2021-12-08T20:59:07","guid":{"rendered":"https:\/\/kifarunix.com\/?p=11065"},"modified":"2024-03-18T07:52:38","modified_gmt":"2024-03-18T04:52:38","slug":"find-out-who-edited-files-in-linux","status":"publish","type":"post","link":"https:\/\/kifarunix.com\/find-out-who-edited-files-in-linux\/","title":{"rendered":"Find out who Edited Files in Linux"},"content":{"rendered":"\n<p>In this tutorial, you will learn how to find out who edited files in Linux. Linux provides user space tools for security auditing called <strong><code><a href=\"https:\/\/linux.die.net\/man\/8\/auditd\" target=\"_blank\" rel=\"noreferrer noopener\">auditd<\/a><\/code><\/strong> (Audit daemon). auditd keeps track of all the changes happening on the system and generate logs that can be analyzed so as to get an insight into system security posture. This include finding out who edit what files at what specific time.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Finding out who Edited Files in Linux<\/h2>\n\n\n\n<p>There is no easy way of finding out who made changes to what files in Linux. However, auditd makes this process a simple one.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Install Audit Packages in Linux<\/h3>\n\n\n\n<p>To begin with, install audit packages in Linux.<\/p>\n\n\n\n<p>On RHEL-based distribution:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>yum install audit -y<\/code><\/pre>\n\n\n\n<p>On Debian-based distros;<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>apt install auditd -y<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Audit User-space Tools<\/h3>\n\n\n\n<p>Audit Package ships with different user-space tools with different functionalities. These include:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong><code>auditd<\/code><\/strong> is the user-space component which is responsible for writing audit records to the disk.<\/li>\n\n\n\n<li><strong><code>ausearch<\/code><\/strong> which is the user-space component for querying audit daemon logs.<\/li>\n\n\n\n<li><strong><code>aureport<\/code><\/strong> which is the user-space component that produces summary reports of the audit system logs.<\/li>\n\n\n\n<li><strong><code>auditctl<\/code><\/strong> which is the program is used to configure kernel options related to auditing, to see status of the configuration, and to load discretionary audit rules. When system boots, <strong><code>auditctl<\/code><\/strong> reads the rules in \/etc\/audit\/audit.rules and load them into the kernel.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Running Auditd Service in Linux<\/h3>\n\n\n\n<p>When installed, Audit daemon service is started and enabled to run on system boot;<\/p>\n\n\n\n<p>To check the status;<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>systemctl status auditd<\/code><\/pre>\n\n\n\n<pre class=\"scroll-box\"><code>\u25cf auditd.service - Security Auditing Service\n     Loaded: loaded (\/lib\/systemd\/system\/auditd.service; enabled; vendor preset: enabled)\n     Active: active (running) since Wed 2021-12-08 17:52:49 EAT; 25min ago\n       Docs: man:auditd(8)\n             https:\/\/github.com\/linux-audit\/audit-documentation\n    Process: 1336 ExecStart=\/sbin\/auditd (code=exited, status=0\/SUCCESS)\n    Process: 1340 ExecStartPost=\/sbin\/augenrules --load (code=exited, status=0\/SUCCESS)\n   Main PID: 1337 (auditd)\n      Tasks: 2 (limit: 5902)\n     Memory: 616.0K\n        CPU: 25ms\n     CGroup: \/system.slice\/auditd.service\n             \u2514\u25001337 \/sbin\/auditd\n\nDec 08 17:52:49 debian11 augenrules[1350]: enabled 1\nDec 08 17:52:49 debian11 augenrules[1350]: failure 1\nDec 08 17:52:49 debian11 augenrules[1350]: pid 1337\nDec 08 17:52:49 debian11 augenrules[1350]: rate_limit 0\nDec 08 17:52:49 debian11 augenrules[1350]: backlog_limit 8192\nDec 08 17:52:49 debian11 augenrules[1350]: lost 0\nDec 08 17:52:49 debian11 augenrules[1350]: backlog 0\nDec 08 17:52:49 debian11 augenrules[1350]: backlog_wait_time 60000\nDec 08 17:52:49 debian11 augenrules[1350]: backlog_wait_time_actual 0\nDec 08 17:52:49 debian11 systemd[1]: Started Security Auditing Service.\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Monitor File Changes in Linux using Auditd<\/h3>\n\n\n\n<p>Note that there are various audit rules that defines how to track system changes. These include:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong><code>Control rules<\/code><\/strong>: Allow the modification of the audit system&#8217;s behavior and some of its configuration.<\/li>\n\n\n\n<li><code><strong>File system rules<\/strong><\/code>: allow the auditing of access to a particular file or a directory. These are also known as file watches.<\/li>\n\n\n\n<li><code><strong>System call rules<\/strong><\/code>: Allow logging of system calls that any specified program makes.<\/li>\n<\/ul>\n\n\n\n<p>We are only interested in file system audit rules as these enables us to monitor file changes in Linux<\/p>\n\n\n\n<p>As stated above, <code><strong>auditctl<\/strong><\/code> utility can be used to configure audit rules.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">Configure Runtime File system Audit Rules<\/h4>\n\n\n\n<p>You can configure runtime File system audit rules on command line using <strong><code>auditctl<\/code><\/strong> command. The syntax is;<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>auditctl -w <strong><em>path_to_file<\/em><\/strong> -p <strong><em>access_permissions<\/em><\/strong> -k <strong><em>filter_key<\/em><\/strong><\/code><\/pre>\n\n\n\n<p>The options used are:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong><code>-w <em>path_to_file<\/em><\/code><\/strong>: defines a path to file system object being monitored.<\/li>\n\n\n\n<li><code>-p <strong><em>access_permissions<\/em><\/strong><\/code>: (<strong><code>-p [r|w|x|a]<\/code><\/strong>) Describe the permission access type that a file system watch will trigger on. r=read, w=write, x=execute, a=attribute change. Note that these are not the standard file permissions, but rather the kind of syscall that would do this kind of thing.<\/li>\n\n\n\n<li><code>-k <strong><em>filter_key<\/em><\/strong><\/code>: defines an arbitrary string of text that can be up to 31 bytes long. It can uniquely identify the audit records produced by a rule.<\/li>\n<\/ul>\n\n\n\n<p>Take for example we want to watch read\/write and attribute changes to the file, <code>\/etc\/ssh\/sshd_config<\/code>, then you would define a rule like;<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>auditctl -w \/etc\/ssh\/sshd_config -p wax -k monitor_sshd_conf<\/code><\/pre>\n\n\n\n<p>To list the rules;<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>auditctl -l<\/code><\/pre>\n\n\n\n<p>Sample output;<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>-w \/etc\/ssh\/sshd_config -p wxa -k monitor_sshd_conf<\/code><\/pre>\n\n\n\n<p>To test this rule, try to modify the <strong><code>\/etc\/ssh\/sshd_config<\/code><\/strong> file. As non root user, run the command like this;<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>echo \"AllowUsers kifarunix root\" | sudo tee -a \/etc\/ssh\/sshd_config<\/code><\/pre>\n\n\n\n<p>If you want to stop monitoring the file using auditctl;<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>auditctl <strong>-W<\/strong> \/etc\/ssh\/sshd_config -p wax -k monitor_sshd_conf<\/code><\/pre>\n\n\n\n<h4 class=\"wp-block-heading\">Configure Persistent File system Audit Rules<\/h4>\n\n\n\n<p>To configure permanent rules that persists across system reboots, you can place the rules under <code><strong>\/etc\/audit\/audit.rules<\/strong><\/code> or place them under <code><strong>\/etc\/audit\/rules.d\/<\/strong><\/code>.<\/p>\n\n\n\n<p>Rules on the file, <code><strong>\/etc\/audit\/audit.rules<\/strong><\/code>, are generated from the rules defined under the <code><strong>\/etc\/audit\/rules.d\/<\/strong><\/code> directory.<\/p>\n\n\n\n<p>If the rules are placed under <code>\/etc\/audit\/rules.d\/<\/code>, you need to load them using the <strong><code>augenrules<\/code><\/strong> utility.<\/p>\n\n\n\n<p>For example;<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>echo \"-w \/etc\/ssh\/sshd_config -p wxa -k monitor_sshd_conf\" &gt; \/etc\/audit\/rules.d\/sshd.rules<\/code><\/pre>\n\n\n\n<p>Check the if the changes are detected;<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>augenrules --check<\/code><\/pre>\n\n\n\n<p>The load the rules;<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>augenrules --load<\/code><\/pre>\n\n\n\n<p>This should update the file, <code><strong>\/etc\/audit\/audit.rules<\/strong><\/code>.<\/p>\n\n\n\n<p>Restart auditd service;<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>systemctl restart auditd<\/code><\/pre>\n\n\n\n<p>Listing the rules;<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>auditctl -l<\/code><\/pre>\n\n\n\n<pre class=\"wp-block-code\"><code>-w \/etc\/ssh\/sshd_config -p wxa -k monitor_sshd_conf<\/code><\/pre>\n\n\n\n<h4 class=\"wp-block-heading\">Viewing Audit Rule Logs<\/h4>\n\n\n\n<p>There are various ways in which you can view Audit log records.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Reading the Audit log file, <code><strong>\/var\/log\/audit\/audit.log<\/strong><\/code>.<\/li>\n<\/ul>\n\n\n\n<pre class=\"wp-block-code\"><code>grep --color monitor_sshd_conf \/var\/log\/audit\/audit.log<\/code><\/pre>\n\n\n\n<pre class=\"scroll-box\"><code>type=CONFIG_CHANGE msg=audit(1638984278.290:13): auid=1000 ses=3 subj==unconfined op=add_rule key=\"monitor_sshd_conf\" list=4 res=1AUID=\"kifarunix\"\ntype=SYSCALL msg=audit(1638984357.760:38): arch=c000003e syscall=257 success=yes exit=3 a0=ffffff9c a1=7fffe54487de a2=441 a3=1b6 items=2 ppid=987 pid=988 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=5 comm=\"tee\" exe=\"\/usr\/bin\/tee\" subj==unconfined key=\"monitor_sshd_conf\"ARCH=x86_64 SYSCALL=openat AUID=\"kifarunix\" UID=\"root\" GID=\"root\" EUID=\"root\" SUID=\"root\" FSUID=\"root\" EGID=\"root\" SGID=\"root\" FSGID=\"root\"\n<\/code><\/pre>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Generate a report using aureport (read more on <code><strong>man aureport<\/strong><\/code>)<\/li>\n<\/ul>\n\n\n\n<pre class=\"wp-block-code\"><code>aureport -i -k<\/code><\/pre>\n\n\n\n<pre class=\"scroll-box\"><code>\nKey Report\n===============================================\n# date time key success exe auid event\n===============================================\n1. 12\/08\/2021 20:24:38 monitor_sshd_conf yes ? kifarunix 13\n2. 12\/08\/2021 20:25:57 monitor_sshd_conf yes \/usr\/bin\/tee kifarunix 38\n<\/code><\/pre>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Search the logs with ausearch command (read more on <strong><code>man ausearch<\/code><\/strong>).<\/li>\n<\/ul>\n\n\n\n<pre class=\"wp-block-code\"><code>ausearch -i -k monitor_sshd_conf<\/code><\/pre>\n\n\n\n<pre class=\"scroll-box\"><code>----\ntype=CONFIG_CHANGE msg=audit(12\/08\/2021 20:24:38.290:13) : auid=kifarunix ses=3 subj==unconfined op=add_rule key=monitor_sshd_conf list=exit res=yes \n----\ntype=PROCTITLE msg=audit(12\/08\/2021 20:25:57.760:38) : proctitle=tee -a \/etc\/ssh\/sshd_config \ntype=PATH msg=audit(12\/08\/2021 20:25:57.760:38) : item=1 name=\/etc\/ssh\/sshd_config inode=526305 dev=08:01 mode=file,644 ouid=root ogid=root rdev=00:00 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 \ntype=PATH msg=audit(12\/08\/2021 20:25:57.760:38) : item=0 name=\/etc\/ssh\/ inode=523877 dev=08:01 mode=dir,755 ouid=root ogid=root rdev=00:00 nametype=PARENT cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 \ntype=CWD msg=audit(12\/08\/2021 20:25:57.760:38) : cwd=\/home\/kifarunix \ntype=SYSCALL msg=audit(12\/08\/2021 20:25:57.760:38) : arch=x86_64 syscall=openat success=yes exit=3 a0=0xffffff9c a1=0x7fffe54487de a2=O_WRONLY|O_CREAT|O_APPEND a3=0x1b6 items=2 ppid=987 pid=988 auid=kifarunix uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts1 ses=5 comm=tee exe=\/usr\/bin\/tee subj==unconfined key=monitor_sshd_conf \n<\/code><\/pre>\n\n\n\n<p>From the ausearch report output, let&#8217;s try to interpret the records fields.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>type=PROCTITLE<\/strong>: Record type which gives the full command-line that triggered this Audit event.<\/li>\n\n\n\n<li><strong>msg=audit(12\/08\/2021 20:24:38.290:13)<\/strong>: Defines a timestamp and a unique ID of the record in the form&nbsp;<code>audit(<em>time_stamp<\/em>:<em>ID<\/em>)<\/code>. Time usually shows in EPOCH unless you use option <strong>-i<\/strong>.<\/li>\n<\/ul>\n\n\n\n<p>If time is in EPOCH, e.g <code>1638984357.760<\/code>. then convert using date command;<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>date -d @1638984357.760<\/code><\/pre>\n\n\n\n<pre class=\"wp-block-code\"><code>Wed 08 Dec 2021 08:25:57 PM EAT<\/code><\/pre>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>proctitle=tee -a \/etc\/ssh\/sshd_config<\/strong>: The field records the full command-line of the command that was used to invoke the analyzed process. Without option -i, this would have been displayed in hexadecimal.<\/li>\n\n\n\n<li><strong>type=PATH<\/strong>: record type PATH records the path that is passed to the system call as an argument, in this case the path is \/etc\/ssh\/sshd_config.<\/li>\n\n\n\n<li><code><strong>item=1<\/strong><\/code>: The&nbsp;<code>item<\/code>&nbsp;field indicates which item, of the total number of items referenced in the&nbsp;<code>SYSCALL<\/code>&nbsp;type record, the current record is. a value of&nbsp;1&nbsp;means it is the second item.<\/li>\n\n\n\n<li><code><strong>name=\/etc\/ssh\/sshd_config<\/strong><\/code>: The&nbsp;records the path of the file or directory that was passed to the system call as an argument. In this case, it was the&nbsp;<code>\/etc\/ssh\/sshd_config<\/code>&nbsp;file.<\/li>\n\n\n\n<li><code><strong>inode=526305<\/strong><\/code>: The&nbsp;<code>inode<\/code>&nbsp;field contains the inode number associated with the file or directory recorded in this event. The following command displays the file or directory that is associated with the&nbsp;526305 inode number:<\/li>\n<\/ul>\n\n\n\n<pre class=\"wp-block-code\"><code>find \/ -inum 526305 -print<\/code><\/pre>\n\n\n\n<pre class=\"wp-block-code\"><code>\/etc\/ssh\/sshd_config<\/code><\/pre>\n\n\n\n<ul class=\"wp-block-list\">\n<li><code><strong>dev=08:01<\/strong><\/code>: The field specifies the minor and major ID of the device that contains the file or directory recorded in this event.<\/li>\n\n\n\n<li><strong>mode=file,644<\/strong>: The mode field records the file or directory permissions, 644 means -rw-r&#8211;r&#8211; for the \/etc\/ssh\/sshd_config file.<\/li>\n\n\n\n<li><strong><code>ouid=root<\/code><\/strong>: The ouid field records the object owner&#8217;s user ID\/username.<\/li>\n\n\n\n<li><strong><code>ogid=root<\/code><\/strong>: The ogid field records the object owner&#8217;s group ID\/username.<\/li>\n\n\n\n<li><strong><code>rdev=00:00<\/code><\/strong>: The rdev field contains a recorded device identifier for special files only. In this case, it is not used as the recorded file is a regular file.<\/li>\n\n\n\n<li><strong><code>nametype=NORMAL<\/code><\/strong>: records the intent of each path record&#8217;s operation in the context of a given syscall.<\/li>\n\n\n\n<li><strong><code>cap_fp=none<\/code><\/strong>: The cap_fp field records data related to the setting of a permitted file system-based capability of the file or directory object.<\/li>\n\n\n\n<li><strong><code>cap_fi=none<\/code><\/strong>: The cap_fi field records data related to the setting of an inherited file system-based capability of the file or directory object.<\/li>\n\n\n\n<li><strong><code>cap_fe=0<\/code><\/strong>: The cap_fe field records the setting of the effective bit of the file system-based capability of the file or directory object.<\/li>\n\n\n\n<li><strong><code>cap_fver=0<\/code><\/strong>: The cap_fver field records the version of the file system-based capability of the file or directory object.<\/li>\n\n\n\n<li><code><strong>type=CWD<\/strong><\/code>: records the working directory from which the process that invoked the system call was executed.<\/li>\n\n\n\n<li><code><strong>cwd=\/home\/kifarunix<\/strong><\/code>: specifies directory in which the system call was invoked.<\/li>\n\n\n\n<li><strong><code>type=SYSCALL<\/code><\/strong>: specifies that the record was triggered by a system call to the kernel.<\/li>\n\n\n\n<li><strong><code>arch=x86_64<\/code><\/strong>: The field contains information about the CPU architecture of the system. Unless option -i is used with auseardh, the value is shown hexadecimal notation.<\/li>\n\n\n\n<li><strong><code>syscall=openat<\/code><\/strong>: The syscall field records the type of the system call that was sent to the kernel. When option -i is used with ausearch, the values are interpreted, otherwise numeric values are shown. Use the <strong><code>ausyscall --dump<\/code><\/strong> command to display a listing of all system calls along with their numbers. For more information, see <strong>man ausyscall<\/strong>.<\/li>\n\n\n\n<li><strong><code>success=yes<\/code><\/strong>: The success field records whether the system call recorded in that particular event succeeded or failed. In this case, the call succeeded.<\/li>\n\n\n\n<li><strong>exit=3<\/strong>: The field contains a value that specifies the exit code returned by the system call. This value varies for different system call.<\/li>\n\n\n\n<li><strong><code>a0=0xffffff9c a1=0x7fffe54487de a2=O_WRONLY|O_CREAT|O_APPEND a3=0x1b6<\/code><\/strong>: The a0 to a3 fields record the first four arguments, encoded in hexadecimal notation, of the system call in this event. These arguments depend on the system call that is used.<\/li>\n\n\n\n<li><strong><code>items=2<\/code><\/strong>: The items field contains the number of PATH auxiliary records that follow the syscall record.<\/li>\n\n\n\n<li><strong><code>ppid=987<\/code><\/strong>: The ppid field records the Parent Process ID (PPID).<\/li>\n\n\n\n<li><strong><code>pid=988<\/code><\/strong>: The pid field records the Process ID (PID).<\/li>\n\n\n\n<li><strong><code>auid=kifarunix<\/code><\/strong>: The auid field records the Audit user ID, that is the loginuid. This ID is assigned to a user upon login and is inherited by every process even when the user&#8217;s identity changes, for example, by switching user accounts.<\/li>\n\n\n\n<li><strong><code>uid=root<\/code><\/strong>: The uid field records the user ID of the user who started the analyzed process. The user ID can be interpreted into user names when -i option is used with ausearch. You can also interpret with the following command: ausearch -i &#8211;uid UID.<\/li>\n\n\n\n<li><strong><code>gid=root<\/code><\/strong>: The gid field records the group ID of the user who started the analyzed process.<\/li>\n\n\n\n<li><code><strong>euid=root<\/strong><\/code>: The euid field records the effective user ID of the user who started the analyzed process.<\/li>\n\n\n\n<li><code><strong>suid=root<\/strong><\/code>: The suid field records the set user ID of the user who started the analyzed process.<\/li>\n\n\n\n<li><strong><code>fsuid=root<\/code><\/strong>: The fsuid field records the file system user ID of the user who started the analyzed process.<\/li>\n\n\n\n<li><strong><code>egid=root<\/code><\/strong>: The egid field records the effective group ID of the user who started the analyzed process.<\/li>\n\n\n\n<li><strong><code>sgid=root<\/code><\/strong>: The sgid field records the set group ID of the user who started the analyzed process.<\/li>\n\n\n\n<li><strong><code>fsgid=root<\/code><\/strong>: The fsgid field records the file system group ID of the user who started the analyzed process.<\/li>\n\n\n\n<li><strong><code>tty=pts1<\/code><\/strong>: The tty field records the terminal from which the analyzed process was invoked.<\/li>\n\n\n\n<li><strong><code>ses=5<\/code><\/strong>: The ses field records the session ID of the session from which the analyzed process was invoked.<\/li>\n\n\n\n<li><strong><code>comm=tee<\/code><\/strong>: The comm field records the command-line name of the command that was used to invoke the analyzed process.<\/li>\n\n\n\n<li><strong><code>exe=\/usr\/bin\/tee<\/code><\/strong>: The exe field records the path to the executable that was used to invoke the analyzed process.<\/li>\n\n\n\n<li><strong><code>subj=unconfined<\/code><\/strong>: The subj field records the SELinux context with which the analyzed process was labeled at the time of execution.<\/li>\n\n\n\n<li><strong><code>key=monitor_sshd_conf<\/code><\/strong>: The key field records the administrator-defined string associated with the rule that generated this event in the audit log.<\/li>\n<\/ul>\n\n\n\n<p>From the report;<\/p>\n\n\n\n<pre class=\"scroll-box\"><code>----\ntype=CONFIG_CHANGE msg=audit(12\/08\/2021 20:24:38.290:13) : auid=kifarunix ses=3 subj==unconfined op=add_rule key=monitor_sshd_conf list=exit res=yes \n----\ntype=PROCTITLE msg=audit(12\/08\/2021 20:25:57.760:38) : proctitle=tee -a \/etc\/ssh\/sshd_config \ntype=PATH msg=audit(12\/08\/2021 20:25:57.760:38) : item=1 name=\/etc\/ssh\/sshd_config inode=526305 dev=08:01 mode=file,644 ouid=root ogid=root rdev=00:00 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 \ntype=PATH msg=audit(12\/08\/2021 20:25:57.760:38) : item=0 name=\/etc\/ssh\/ inode=523877 dev=08:01 mode=dir,755 ouid=root ogid=root rdev=00:00 nametype=PARENT cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 \ntype=CWD msg=audit(12\/08\/2021 20:25:57.760:38) : cwd=\/home\/kifarunix \ntype=SYSCALL msg=audit(12\/08\/2021 20:25:57.760:38) : arch=x86_64 syscall=openat success=yes exit=3 a0=0xffffff9c a1=0x7fffe54487de a2=O_WRONLY|O_CREAT|O_APPEND a3=0x1b6 items=2 ppid=987 pid=988 auid=kifarunix uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts1 ses=5 comm=tee exe=\/usr\/bin\/tee subj==unconfined key=monitor_sshd_conf \n<\/code><\/pre>\n\n\n\n<p>It can be seen that:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>the SSH server configuration file, <code><strong>\/etc\/ssh\/sshd_config<\/strong><\/code>, was updated using the <strong><code>tee<\/code><\/strong> command.<\/li>\n\n\n\n<li>The command was executed from the directory, <strong><code>\/home\/kifarunix<\/code><\/strong>.<\/li>\n\n\n\n<li>The changes were made by the user, <code><strong>kifarunix<\/strong><\/code> as root user (using sudo).<\/li>\n<\/ul>\n\n\n\n<p>If you want to use Auditbeat and ELK instead, check the guide below;<\/p>\n\n\n\n<p><a href=\"https:\/\/kifarunix.com\/detect-changes-to-critical-files-in-linux-using-auditbeat-and-elk\/\" target=\"_blank\" rel=\"noreferrer noopener\">Detect Changes to Critical Files in Linux using Auditbeat and ELK<\/a><\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Other Tutorials<\/h3>\n\n\n\n<p><a href=\"https:\/\/kifarunix.com\/install-and-configure-aide-on-debian-10\/\" target=\"_blank\" rel=\"noreferrer noopener\">Install and Configure AIDE on Debian 10<\/a><\/p>\n\n\n\n<p><a href=\"https:\/\/kifarunix.com\/install-ossec-agent-on-rocky-linux-8\/\" target=\"_blank\" rel=\"noreferrer noopener\">Install OSSEC Agent on Rocky Linux 8<\/a><\/p>\n\n\n\n<p><a href=\"https:\/\/kifarunix.com\/install-arkime-moloch-full-packet-capture-tool-on-debian\/\" target=\"_blank\" rel=\"noreferrer noopener\">Install Arkime (Moloch) Full Packet Capture tool on Debian 11<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"<p>In this tutorial, you will learn how to find out who edited files in Linux. Linux provides user space tools for security auditing called auditd<\/p>\n","protected":false},"author":3,"featured_media":11077,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"rank_math_lock_modified_date":false,"footnotes":""},"categories":[121],"tags":[4328,4332,4327,4331,4330,4329,4333,4323,4326,4324,4325],"class_list":["post-11065","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-howtos","tag-auditctl","tag-auditd","tag-auditd-linux","tag-augenrules","tag-aureport","tag-ausearch","tag-configure-persistent-auditd-rules","tag-find-out-who-edited-files-in-linux","tag-monitor-file-edits-using-auditd","tag-track-any-file-changes-using-auditd","tag-track-file-changes-using-auditd","generate-columns","tablet-grid-50","mobile-grid-100","grid-parent","grid-50","resize-featured-image"],"_links":{"self":[{"href":"https:\/\/kifarunix.com\/wp-json\/wp\/v2\/posts\/11065"}],"collection":[{"href":"https:\/\/kifarunix.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/kifarunix.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/kifarunix.com\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/kifarunix.com\/wp-json\/wp\/v2\/comments?post=11065"}],"version-history":[{"count":14,"href":"https:\/\/kifarunix.com\/wp-json\/wp\/v2\/posts\/11065\/revisions"}],"predecessor-version":[{"id":21595,"href":"https:\/\/kifarunix.com\/wp-json\/wp\/v2\/posts\/11065\/revisions\/21595"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/kifarunix.com\/wp-json\/wp\/v2\/media\/11077"}],"wp:attachment":[{"href":"https:\/\/kifarunix.com\/wp-json\/wp\/v2\/media?parent=11065"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/kifarunix.com\/wp-json\/wp\/v2\/categories?post=11065"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/kifarunix.com\/wp-json\/wp\/v2\/tags?post=11065"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}