Linux audit file access

Monitoring Linux File access, Changes and Data Modifications

Monitoring File access, Changes and Data Modifications

Linux has several solutions to monitor what happens with your data. From changing contents to who accessed particular information, and at what time.

For our auditing toolkit Lynis, we researched and tested several solutions over the last few years. In this article we have a look at these solutions to monitor file access, changes and modifications to the data and beyond.

What is Data?

Data is a collection of bits, ordered in such a way it gives meaning to humans. The related information stored in data blocks, can be as simple as text, or become a visible representation like an image. Data is usually the most important part on a system, which means it has to be properly safeguarded.

Data versus Meta-data

Besides the information stored for us, the system needs to store a little bit of information as well. For example a data block on disk, might need some supporting information to know where it is stored. This data is usually not useful for us, but certainly for the system to retrieve the information, especially when we ask for it. This “data about data” is called meta-data. So besides protecting data, we have to take the protection of meta-data in mind as well.

Monitoring File Access

The first level of monitoring is who is accessing specific files. This helps us understand what particular files are being accessed, by what process and by whom. To accomplish this task, we can use the Linux audit framework. The framework is written by Red Hat and uses “watches” on files and directories to determine what should be monitored. Additionally it can monitor processes, including the underlying system calls which are performed by them.

Adding watches

To protect our kernel configuration, we can determine who accesses the sysctl.conf file. This file stores kernel settings, so it interesting to start with this file. To have this file monitored, we need to add a watch on the file.

auditctl -w /etc/sysctl.conf -p a -k kernel

The parameter -w sets the watch, followed by the file name. The -p defines the related permission action (a = attribute change, r = read, w = write, x = execute). It looks similar to file permissions, but actually it is slightly different. With the -k we define a custom key, which simplifies searching at a later moment. It is also helpful to categorize events.

Reporting watches

Now we have defined our watch, we can search for it with the earlier defined key.

Running this command gives us the following output:

File access monitoring with Linux audit framework

When looking at this output, you might be overwhelmed by all the fields available. Additionally some fields actually have rather strange values, like an architecture of c000003e (which actually equals x86_64).

The most important fields are the purple box, showing what object was hit and the green box revealing the process (or binary), followed by the defined key. In this case both the cat command and vim editor have opened the file

In this screenshot we can also see a failed syscall in the yellow box, with the value 89. To determine what syscall this is, we first have to look it up:

This will show all available syscalls for our particular system architecture. So in this case a call to “getrusage”, to retrieve process statistics from the kernel.

Monitoring specific functions

We can use the Linux audit framework also for monitoring specific system calls, or functions. We have to use the -S followed by the system call.

auditctl -a always,exit -S openat -F success=1

The -a always,exit defines to write out an event at exit time of the related system call.

For example when you want to monitor all successful “openat” calls, add this system call and tell auditctl only to log successful requests. In this case you might get a message that the system call is unclear, as it is found on multiple architectures. Find the related system call ID with ausyscall openat and add the ID instead. Even better is specifying the architecture together with the system call, as it is easier to read (example: -F arch=b64 -S openat).

For more tips regarding the Linux audit framework, have a look at our other article Configuring & Auditing Linux Systems with the Audit Daemon

File Integrity Monitoring

Another interesting level to monitor file changes, is by implementing file integrity tooling. Linux has several options for this, varying from simple tools up to kernel modules.

File Integrity Tools

The easiest way to verify if a file has been changed, is using tools. Simple tools like md5sum or shasum can help with detecting changes. Also specialized tools like AIDE and Samhain are a great help to set-up automatic monitoring and alerting.

Since setting up these tools are worth a blog post of their own, it will be covered in a separate post.

Integrity Measurement Architecture (IMA)

The most extensive option is monitoring files with IMA. This security module allows the system to create and monitor hashes for files and block unauthorized changes.

IMA has a few modes it can operate in, like fix and appraise. In “fix mode” the system allows the administrator to set hash values along each file. These hashes are small strings of text to help the system detect changes and are stored in extended attributes (xattrs) of the file system.

Digital signatures

Additionally IMA supports digital signing. This ensures you that the contents of the file is correct (or unaltered). Additionally because it is signed, you can validate the signature. So if a file is to be changed, it also needs proper signing.

Since IMA is a very extensive way of monitoring, we will cover more in other blogs posts. It’s a very exciting subject and a great help to protect your data.

Extended Verification Method (EVM)

Where IMA monitors the file contents, EVM performs monitoring of the file attributes. It also allows hashing and digital signing. It’s a great extension to IMA, to ensure that both contents and the attributes of a file are being unaltered.

Monitoring File Attributes

To monitor file permissions, we can also use the audit framework. File permissions and ownership are part of the file attributes. The file attributes can be monitored with “-p a“.

Additionally, we can use the earlier covered EVM to ensure attributes are not changed by an unauthorized process or person.

Conclusion

Now we have looked at some of the tools, it should be clear that a lot of areas can be monitored on Linux systems. It is up to the administrator to define what files should be monitored and to which extent. From simply logging changes to attributes with the Linux audit framework, up to fully blocking altered files with IMA and EVM.

Keep learning

So you are interested in Linux security? Join the Linux Security Expert training program, a practical and lab-based training ground. For those who want to become (or stay) a Linux security expert.

Run automated security scans and increase your defenses. Lynis is an open source security tool to perform in-depth audits. It helps with system hardening, vulnerability discovery, and compliance.

Continue reading

Linux System Integrity Explained: Ensure Data, Logging and Kernel Integrity

About Linux Audit

This blog is part of our mission: help individuals and companies, to scan and secure their systems. We simply love Linux security, system hardening, and questions regarding compliance.

Besides the blog, we have our security auditing tool Lynis. Open source, GPL, and free to use.

For those with enterprise needs, or want to audit multiple systems, there is an Enterprise version.

«One security solution to audit, harden, and secure your Linux/UNIX systems.»

Benefits:

• Perform audits within a few minutes
• Central management
• Powerful reporting
• Compliance checks (e.g. PCI DSS)
• Additional plugins and more tests

Enjoy the articles!

Linux and UNIX security automation

Lynis is a free and open source security scanner. It helps with testing the defenses of your Linux, macOS, and Unix systems. Typical use-cases for this software include system hardening, vulnerability scanning, and checking compliance with security standards (PCI-DSS, ISO27001, etc).

Recent Posts

Contact

This blog is part of our mission to share valuable tips about Linux security. We are reachable via @linuxaudit

Company details

CISOfy
De Klok 28,
5251 DN, Vlijmen, The Netherlands
+31-20-2260055

Источник

Configuring and auditing Linux systems with Audit daemon

The Linux Audit Daemon is a framework to allow auditing events on a Linux system. Within this article we will have a look at installation, configuration and using the framework to perform Linux system and security auditing.

Auditing goals

By using a powerful audit framework, the system can track many event types to monitor and audit the system. Examples include:

• Audit file access and modification
  • See who changed a particular file
  • Detect unauthorized changes
• Monitoring of system calls and functions
• Detect anomalies like crashing processes
• Set tripwires for intrusion detection purposes
• Record commands used by individual users

Components

The framework itself has several components:

Kernel:

• audit: hooks into the kernel to capture events and deliver them to auditd

Binaries:

• auditd: daemon to capture events and store them (log file)
• auditctl: client tool to configure auditd
• audispd: daemon to multiplex events
• aureport: reporting tool which reads from log file (auditd.log)
• ausearch: event viewer (auditd.log)
• autrace: using audit component in kernel to trace binaries
• aulast: similar to last, but instaed using audit framework
• aulastlog: similar to lastlog, also using audit framework instead
• ausyscall: map syscall ID and name
• auvirt: displaying audit information regarding virtual machines

Files:

• audit.rules: used by auditctl to read what rules need to be used
• auditd.conf: configuration file of auditd

Installation

Debian/Ubuntu: apt-get install auditd audispd-plugins

Red Hat/CentOS/Fedora: usually already installed (package: audit and audit-libs)

Configuration

The configuration of the audit daemon is arranged by two files, one for the daemon itself (auditd.conf) and one for the rules used by the auditctl tool (audit.rules).

auditd.conf

The file auditd.conf configures the Linux audit daemon (auditd) with focus on where and how it should log events. It also defines how to deal with full disks, log rotation and the number of logs to keep. Usually the default configuration will be appropriate for most systems.

audit.rules

To configure what events should be audited, the audit framework uses a rules file named audit.rules.

As with most things, use a clean start and without any loaded rules. Active rules can be determined by running auditctl with the -l parameter.

In case any rules are loaded, remove them with auditctl and the -D parameter.

Time to start with monitoring something, let’s say the /etc/passwd file. We put a ‘watch’ on the file by defining the path and permissions to look for:

auditctl -a exit,always -F path=/etc/passwd -F perm=wa

By defining the path option, we instruct the audit framework what directory or file to watch for. The permissions determine what kind of access will trigger an event. Although these look similar to file permissions, note that there is a important difference between the two. The four options are:

• r = read
• w = write
• x = execute
• a = attribute change

Finding the related event or access to the file can be quickly traced by using the ausearch tool.

[root@host audit]# ausearch -f /etc/passwd

time->Tue Mar 18 15:17:25 2014
type=PATH msg=audit(1395152245.230:533): item=0 name=”/etc/passwd” inode=137627 dev=fd:00 mode=0100644 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:etc_t:s0 nametype=NORMAL
type=CWD msg=audit(1395152245.230:533): cwd=”/etc/audit”
type=SYSCALL msg=audit(1395152245.230:533): arch=c000003e syscall=188 success=yes exit=0 a0=d14410 a1=7f66eec38db7 a2=d4ea60 a3=1c items=1 ppid=1109 pid=4900 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=2 comm=”vi” exe=”/bin/vi” subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)

Some highlights of this output are:

The time of the event and the name of the object, the current working path (cwd), related syscall, audit user ID (auid) and the binary (exe) performing the action upon the file. Please note that the auid defines the original user during log-in. The other user ID fields might indicate a different user, depending on the effective user being used while triggering an event.

Converting system calls

Syscalls are logged by an numeric value. Since there will be an overlap in these values between different architectures, the active architecture is also logged.

By using uname -m we can determine the architecture and use ausyscall to determine what numeric call 188 represents.

[root@host audit]# ausyscall x86_64 188
setxattr

We now know it was a change in attribute, which makes sense as we defined our watch to trigger an event on an attribute change (perm=a).

Used a temporary rule and want to use the old rules again? Refresh the audit rules from a file:

Auditing of processes under Linux

Similiar to using strace, the audit framework has a tool named autrace. It uses the audit framework and adds the right rules to capture information and log it. Using ausearch the gathered information can be displayed.

Perform a trace:

# autrace /bin/ls /tmp
autrace cannot be run with rules loaded.
Please delete all rules using ‘auditctl -D’ if you really wanted to
run this command.
root@host:

# auditctl -D
No rules
root@host:

# autrace /bin/ls /tmp
Waiting to execute: /bin/ls
atop.d mc-root mongodb-27017.sock suds
Cleaning up…
Trace complete. You can locate the records with ‘ausearch -i -p 20314’

Display related files via ausearch:

# ausearch –start recent -p 21023 –raw | aureport –file –summary

File Summary Report
===========================
total file
===========================
1 /bin/ls
1 (null) inode=1975164 dev=08:02 mode=0100755 ouid=0 ogid=0 rdev=00:00
1 /etc/ld.so.cache
1 /lib/x86_64-linux-gnu/libselinux.so.1
1 /lib/x86_64-linux-gnu/librt.so.1
1 /lib/x86_64-linux-gnu/libacl.so.1
1 /lib/x86_64-linux-gnu/libc.so.6
1 /lib/x86_64-linux-gnu/libdl.so.2
1 /lib/x86_64-linux-gnu/libpthread.so.0
1 /lib/x86_64-linux-gnu/libattr.so.1
1 /proc/filesystems
1 /usr/lib/locale/locale-archive
1 /tmp

Audit file access per user

The audit framework can be used to monitor syscalls, including access to files. If you want to know what files a particular user ID accessed, use a rule like this:

auditctl -a exit,always -F arch=x86_64 -S open -F auid=80

-F arch=x86_64 Define what architecture is used (uname -m), to monitor the right syscall (some system calls are ambiguous between archtectures).

-S open Select the “open” syscall

-F auid=80 The related user ID

This kind of information is really useful for intrusion detection, but also when performing forensics on a Linux system.

Automation

Since the Linux audit daemon can provide valuable auditing data, Lynis will check for the presence of the framework. If not available, it will advice you to install. Additionally Lynis will perform several tests to determine the log file, available rules and more.

For proper intrusion detection, integration with an Intrusion Detection System (IDS) is key in discover events when they occur and take appropriate actions.

The audit daemon has more possibilities. Other examples will be listed in separated articles in the future of this blog. If you are serious about auditing the Linux platform, the Linux audit framework will definitely be a good friend!

Keep learning

So you are interested in Linux security? Join the Linux Security Expert training program, a practical and lab-based training ground. For those who want to become (or stay) a Linux security expert.

Run automated security scans and increase your defenses. Lynis is an open source security tool to perform in-depth audits. It helps with system hardening, vulnerability discovery, and compliance.

Continue reading

How to secure a Linux system

The Difference Between Auditing and Vulnerability Scanning

Find Differences Between Two Daily Lynis Audits

The ultimate strace cheat sheet

About Linux Audit

This blog is part of our mission: help individuals and companies, to scan and secure their systems. We simply love Linux security, system hardening, and questions regarding compliance.

Besides the blog, we have our security auditing tool Lynis. Open source, GPL, and free to use.

For those with enterprise needs, or want to audit multiple systems, there is an Enterprise version.

«One security solution to audit, harden, and secure your Linux/UNIX systems.»

Benefits:

• Perform audits within a few minutes
• Central management
• Powerful reporting
• Compliance checks (e.g. PCI DSS)
• Additional plugins and more tests

Enjoy the articles!

Linux and UNIX security automation

Lynis is a free and open source security scanner. It helps with testing the defenses of your Linux, macOS, and Unix systems. Typical use-cases for this software include system hardening, vulnerability scanning, and checking compliance with security standards (PCI-DSS, ISO27001, etc).

Recent Posts

Contact

This blog is part of our mission to share valuable tips about Linux security. We are reachable via @linuxaudit

Company details

CISOfy
De Klok 28,
5251 DN, Vlijmen, The Netherlands
+31-20-2260055

Источник