Configure Audit Service to Send Audit Messages to Another

Server
Posted on 23/06/2019 by Lisenet
The auditd service does not include the ability to send audit records to a centralised server for management directly.
It does include a plug-in for audit event multiplexor to pass audit records to a remote syslog server.

Homelab Setup
We have two servers in our homelab:

o server1.hl.local – a RHEL 7 server that sends audit messages.

o server2.hl.local – a RHEL 7 server that receives audit messages.

Configure the Sending Server

Configure auditd to include in the audit log file additional information as well as include the host name.
Open /etc/audit/auditd.conf for editing, and configure the following lines:
log_format = ENRICHED

name_format = HOSTNAME

Enable remote logging. Install audispd-plugins package:

# yum -y install audispd-plugins

Open /etc/audisp/plugins.d/au-remote.conf for editing and set the value for the active option to yes:
active = yes

Open /etc/audisp/audisp-remote.conf for editing and set configuration for the remote logging server:
remote_server = server2.hl.local

port = 60

Restart the auditd service:

# service auditd restart

Configure the Receiving Server

Open /etc/audit/auditd.conf for editing and configure auditd service to listen on TCP port 60:
tcp_listen_port = 60

Open TCP port 60 to enable access to the server:

# firewall-cmd --permanent --add-port=60/tcp

# firewall-cmd --reload

Log out and log back in to the server1. Check the log file on server2:

# grep server1 /var/log/audit/audit.log

node=server1.hl.local type=CRED_REFR msg=audit(1561294797.930:227): pid=2236 uid=0 auid=0 ses=4
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:setcred grantors=pam_env,pam_unix
acct="root" exe="/usr/sbin/sshd" hostname=10.11.1.10 addr=10.11.1.10 terminal=ssh res=success' UID="root"
AUID="root"

This entry was posted in Linux and tagged auditd, EX415, RHCA, RHEL. Bookmark the permalink. If you

notice any errors, please contact us.

This short note explains steps to direct audit logs to remote rsyslog server on a
CentOS/RHEL 6,7 Server.

Server Side Configuration

Perform these steps to set up the syslog server:

1. Uncomment the following lines in the ‘MODULES‘ section of /etc/rsyslog.conf:

# vi /etc/rsyslog.conf
$ModLoad imtcp
$InputTCPServerRun 514
If you are using UDP then uncomment following lines:

# vi /etc/rsyslog.conf
$ModLoad imudp
$UDPServerRun 514
2. Configure the rsyslog server to recieve rsyslog events from client. To receive
audit logs from client servers, add below lines in the /etc/rsyslog.conf file:

# vi /etc/rsyslog.conf
$template HostAudit, "/var/log/rsyslog/%HOSTNAME%/audit_log"
local6.* ?HostAudit
3. Restart the rsyslog service.
# service rsyslog restart ### CentOS/RHEL 6
# systemctl restart rsyslog ### CentOS/RHEL 7

Client Side configuration

1. Take the backup of the existing /etc/rsyslog.conf.

# cp /etc/rsyslog.conf /etc/rsyslog.conf.bkp
2. Append the following rules to the /etc/rsyslog.conf file for directing the logs to
central rsyslog server. “imfile” module has to be loaded on the rsyslogd, otherwise
the configuration for directing the auditd log won’t work.

# vi /etc/rsyslog.conf
#audit log
$ModLoad imfile
$InputFileName /var/log/audit/audit.log
$InputFileTag tag_audit_log:
$InputFileStateFile audit_log
$InputFileSeverity info
$InputFileFacility local6
$InputRunFileMonitor

*.* @[serverip] ### Add rsyslog

server IP here
Make sure you replace @[serverip] with your rsyslog server IP address.

3. Restart the rsyslog service for the changes to take effect.

# service rsyslog restart ### CentOS/RHEL 6

# systemctl restart rsyslog ### CentOS/RHEL 7

Filed Under: CentOS/RHEL 6, CentOS/RHEL 7, Linux

Logs are a critical component of any software or operating system. Logs usually

record user’s actions, system events, network activity and so much more,
depending on what they are intended for. One of the most widely used logging
systems on Linux systems is rsyslog.
Rsyslog is a powerful, secure and high-performance log processing system
which accepts data from different types of source (systems/applications) and
outputs it into multiple formats.
It has evolved from a regular syslog daemon to a fully-featured, enterprise level
logging system. It is designed in a client/server model, therefore it can be
configured as a client and/or as a central logging server for other servers,
network devices, and remote applications.
Testing Environment
For the purpose of this guide, we will use the following hosts:

 Server: 192.168.241.140
 Client: 172.31.21.58
How to Install and Configure Rsyslog Server
Most Linux distributions come with the rsyslog package preinstalled. In case it’s
not installed, you can install it using your Linux package manager tool as shown.

$ sudo yum update && yum install rsyslog #CentOS 7

$ sudo apt update && apt install rsyslog #Ubuntu 16.04,

18.04

Once rsyslog installed, you need to start the service for now, enable it to auto-
start at boot and check it’s status with the systemctl command.

$ sudo systemctl start rsyslog

$ sudo systemctl enable rsyslog

$ sudo systemctl status rsyslog

The main rsyslog configuration file is located at /etc/rsyslog.conf, which loads

modules, defines the global directives, contains rules for processing log
messages and it also includes all config files in /etc/rsyslog.d/ for various
applications/services.

$ sudo vim /etc/rsyslog.conf

By default, rsyslog uses the imjournal and imusock modules for importing

structured log messages from systemd journal and for accepting syslog
messages from applications running on the local system via Unix sockets,
respectively.

Rsyslog Modules for Logging

To configure rsyslog as a network/central logging server, you need to set the

protocol (either UDP or TCP or both) it will use for remote syslog reception as
well as the port it listens on.
If you want to use a UDP connection, which is faster but unreliable, search and
uncomment the lines below (replace 514 with the port you want it to listen on, this
should match the port address that the clients send messages to, we will look at
this more when configuring a rsyslog client).

$ModLoad imudp

$UDPServerRun 514

To use TCP connection (which is slower but more reliable), search and

uncomment the lines below.
$ModLoad imtcp

$InputTCPServerRun 514

In this case, we want to use both UDP and TCP connections at the same time.

Configure
Rsyslog Logging Server

Next, you need to define the ruleset for processing remote logs in the following
format.

facility.severity_level destination (where to store log)

Where:

 facility: is type of process/application generating message, they include

auth, cron, daemon, kernel, local0..local7. Using * means all facilities.
 severity_level: is type of log message: emerg-0, alert-1, crit-2, err-3,
warn-4, notice-5, info-6, debug-7. Using * means all severity levels and
none implies no severity level.
 destination: is either local file or remote rsyslog server (defined in the
form IP:port).
We will use the following ruleset for collecting logs from remote hosts, using
the RemoteLogs template. Note that these rules must come before any rules for
processing local messages, as shown in the screenshot.
$template RemoteLogs,"/var/log/%HOSTNAME%/%PROGRAMNAME%.log"

*.* ?RemoteLogs

& ~

Define Ruleset for Rsyslog-Logging

Looking at the above ruleset, the first rule is “$template

RemoteLogs,”/var/log/%HOSTNAME%/%PROGRAMNAME%.log””.
The directive $template tells rsyslog daemon to gather and write all of the
received remote messages to distinct logs under /var/log, based on
the hostname (client machine name) and remote client facility
(program/application) that generated the messages as defined by the settings
present in the template RemoteLogs.
The second line “*.* ?RemoteLogs” means record messages from all facilities
at all severity levels using the RemoteLogs template configuration.
The final line “& ~” instructs rsyslog to stop processing the messages once it is
written to a file. If you don’t include “& ~”, messages will instead be be written to
the local files.
There are many other templates that you can use, for more information, see the
rsyslog configuration man page (man rsyslog.conf) or refer to the Rsyslog
online documentation.
That’s it with configuring the rsyslog server. Save and close the configuration file.
To apply the recent changes, restart rsyslog daemon with the following
command.

$ sudo systemctl restart rsyslog

Now verify the rsyslog network sockets. Use the ss command (or netstat with

the same flags) command and pipe the output to grep to filter out rsyslogd
connections.

$ sudo ss -tulnp | grep "rsyslog"

Check Rsyslog Network Status

Next, on CentOS 7, if you have SELinux enabled, run the following commands

to allow rsyslog traffic based on the network socket type.

$ sudo semanage -a -t syslogd_port_t -p udp 514

$ sudo semanage -a -t syslogd_port_t -p tcp 514

If the system has firewall enabled, you need to open port 514 to allow
both UDP/TCP connections to the rsyslog server, by running.

------------- On CentOS -------------

$ sudo firewall-cmd --permanent --add-port=514/udp
$ sudo firewall-cmd --permanent --add-port=514/tcp
$ sudo firewall-cmd --reload

------------- On Ubuntu -------------

$ sudo ufw allow 514/udp
$ sudo ufw allow 514/tcp
$ sudo ufw reload

How to Configure Rsyslog Client to Send Logs

to Rsyslog Server
Now on the client system, check if the rsyslog service is running or not with the
following command.

$ sudo systemctl status rsyslog

If it’s not installed, install it and start the service as shown earlier on.

$ sudo yum update && yum install rsyslog #CentOS 7

$ sudo apt update && apt install rsyslog #Ubuntu 16.04,

18.04

$ sudo systemctl start rsyslog

$ sudo systemctl enable rsyslog

$ sudo systemctl status rsyslog

Once the rsyslog service is up and running, open the main configuration file
where you will perform changes to the default configuration.
$ sudo vim /etc/rsyslog.conf

To force the rsyslog daemon to act as a log client and forward all locally
generated log messages to the remote rsyslog server, add this forwarding rule, at
the end of the file as shown in the following screenshot.

*. * @@192.168.100.10:514

Configure Rsyslog Client

The above rule will send messages from all facilities and at all severity levels. To
send messages from a specific facility for example auth, use the following rule.

auth. * @@192.168.100.10:514

Save the changes and close the configuration file. To apply the above settings,
restart the rsyslog daemon.
$ sudo systemctl restart rsyslog

How to Monitor Remote Logging on the

Rsyslog Server
The final step is to verify if the rsyslog is actually receiving and logging messages
from the client, under /var/log, in the form hostname/programname.log.
Run a ls command to long listing of the parent logs directory and check if there is
a directory called ip-172.31.21.58 (or whatever your client machine’s hostname
is).

$ ls -l /var/log/

Check Rsyslog Client Logging

If the directory exists, check the log files inside it, by running.

$ sudo ls -l /var/log/ip-172-31-21-58/
Check Rsyslog Client Logs

Summary
Rsyslog is a high-performance log processing system, designed in a
client/server architecture. We hope you are able to install and
configure Rsyslog as a central/network logging server and as a client as
demonstrated in this guide.

Red Hat Enterprise Linux - What Are the Log

Files That Are Located in /var/log and What Do
They Do?
Information
There are lots of log files located in /var/log/ on any Linux machine. What do they mean
and what do they log?

Details
The following log files are located in the /var/log/ directory and while this list is
comprehensive, it is by no means every possible log file that can exist in this location.
The logs are managed by the syslog facility and the various facilities can log to one or more
of the log files listed. In addition, the user can turn off logging of a specific facility.
The facilities are typically:

kern.*
*.info 
mail.*
authpriv.*
cron.*
*.emerg
These are set up, on a RHEL system in /etc/syslog.conf file.
Here are a list of the log files and what they mean or do:
/var/log/messages - This file has all the global system messages located inside,
including the messages that are logged during system startup. Depending on how the
syslog config file is sent up, there are several things that are logged in this file including
mail, cron, daemon, kern, auth, etc.
/var/log/dmesg - Contains kernel ring buffer. This file is overwritten when the system is
rebooted.
/var/log/auth.log - System authorization information is included in this file, along with
user logins and the authentication mechanism that were used.
/var/log/boot.log - Contains information that are logged when the system boots
/var/log/daemon.log - The various system background daemons that are running will log
information to this file.
/var/log/kern.log - Contains information logged by the kernel. Helpful to troubleshoot a
custom-built kernel.
/var/log/lastlog - Displays the recent login information for all the users. This is not an
ascii file. An admin can use the lastlog command to view the content of this file.
/var/log/maillog /var/log/mail.log - Logs information from the mail server that is
running on the system. For example, sendmail logs information about all the sent items to
this file.
/var/log/user.log - Contains information about all user level logs.
/var/log/Xorg.x.log - Log messages from the X server to this file.
/var/log/btmp - This file contains information about failed login attempts. Use the last
command to view the btmp file. For example, last -f /var/log/btmp | more.
/var/log/cups /var/log/spooler - All printer and printing related log messages.
/var/log/anaconda.log - While installing Linux, all installation related messages are
stored in this log file.
/var/log/yum.log - Contains information that are logged when a package is installed
using yum. This file can be referenced in the event a packages is removed that has
dependencies.
/var/log/cron - Whenever cron daemon (or anacron) starts a cron job, it logs the
information about the cron job in this file
/var/log/secure - Contains information related to authentication and authorization
privileges. For example, sshd logs all the messages here, including unsuccessful login.
/var/log/wtmp - The wtmp file records all logins and logouts.
/var/log/utmp - The utmp file allows one to discover information about who is currently
using the system.
/var/log/faillog - Contains failed user login attempts. Use faillog command to display the
content of this file.
/var/log/httpd/ - Contains the apache web server access_log and error_log and related
virtual hosts logs if set up to log here.
/var/log/apache2 - Contains the apache web server access_log and error_log and related
virtual hosts logs if set up to log here.
/var/log/conman/ - Log files for ConMan client. conman connects remote consoles that
are managed by conmand daemon.
/var/log/mail/ - This subdirectory contains additional logs from the mail server. For
example, sendmail stores the collected mail statistics in /var/log/mail/statistics file
/var/log/audit/ - Contains logs information stored by the Linux audit daemon (auditd).
/var/log/setroubleshoot/ - SELinux uses setroubleshootd (SE Trouble Shoot Daemon) to
notify about issues in the security context of files and logs those information in this log file.
/var/log/samba/ - Contains log information stored by samba, which is used to connect
Windows to Linux.
/var/log/sa/ - Contains the daily sar files that are collected by the sysstat package.

How to prevent audit logs appearing in /var/log/messages

– RHEL7
Posted on December 15, 2017 by hedscratchers

Overview
For RHEL7.

This took more work than I anticipated.

My goal was this:

1. Write audit logs to /var/log/audit

2. Forward audit and syslog to central logging server
3. Audit logs to NOT appear in /var/log/messages
The items 1 and 2 were easy, number 3, not so much.

audisp, rsyslogd and journald

After using rsyslog to send logs onto a central log collector, I noticed that all the audit
logs are still going to ”/var/log/messages” as well as ”/var/log/audit”, not ideal, the only
solution that worked, out of the many I tested, is detailed below, the audit logs still go
to /var/log/audit (separate LV of course), /var/log/messages doesn’t fill up with audit
logs, and all the logs get forwarded to a central log collector. The following configs below
seem to work in general, but you may have to tweak them for your application,
specifically the rate and burst limiting for journald.

Files of interest are:

 /etc/audisp/plugins.d/syslog.conf – the plugin that forwards audit logs.
 /etc/systemd/journald.conf – journald daemon config, change default values for
rate-limiting otherwise message maybe be dropped.
 /etc/rsyslog.conf – configure forwarding and exclude local0
 /etc/auditd/rules.d/audit.rules – I needed exclude ”/var/lib/rsyslog” to stop logging
loop, you may not have to do this.
Configure syslog plugin /etc/audisp/plugins.d/syslog.conf to be like the below
active = yes
direction = out
path = builtin_syslog
type = builtin
#args = LOG_INFO
args = LOG_LOCAL0
format = string
Modify rsyslog.conf, the key change was adding the local0.none
.info;mail.none;authpriv.none;cron.none;local0.none      /var/log/messages

# Forward logs using TCP to central log collector

*.* @@xxx.xxx.xxx.xxx:10514
And now journald.conf, the default is ”RateLimitInterval=30s” and
”RateLimitBurst=1000”, I had to change this as I was seeing dropped journalctl
messages – ”journal: Suppressed 10361 messages from”. I had to exclude
”/var/lib/rsyslog” in audit.rules as it was creating thousands of messages, i.e. a logging
loop. It is possible that rsyslog can drop messages as well, they will show up as
”imjournal: begin to drop messages due to rate-limiting”, to rate-limit rsyslog you make
changes the rsyslog.conf file.
RateLimitInterval=15s
RateLimitBurst=3000
If you need to rate-limit rsyslog to can add the following, however, I’ve not tested this.

Old style syslog format

# File to store the position in the journal

$IMJournalStateFile imjournal.state
$imjournalRatelimitInterval 300
$imjournalRatelimitBurst 30000
Or if you want the new style, all one line.

module(load="imjournal" StateFile="/var/lib/rsyslog/imjournal.state" ratelimit.interval="300"

ratelimit.burst="30000
Testing rate-limiting
Tail your log file

tail -f /var/log/messages
From a second shell

journalctl -f
From a third shell generate some traffic

seq 1 3000 | logger

Why Linux is better than windows?

From an Operating system research point of view, Windows is not certainly old
stuff, and it’s clear that people should be looking beyond it. After the launch of
Linux, which is expected to govern the world in a few years, a sudden shift
occurred. Because Linux OS is free, it is used by the majority of businesses.
Even small businesses are adapting the Linux operating system.

The Linux Audit system is a useful feature for tracking security-related

information. All the behavior of the machines/servers can be monitored by
implementing Linux Auditing. It will be suitable for the organization in terms of
security because the attackers are as cunning as a fox.

Use Cases of Linux Audit system:

 Watching file access

 Monitoring system calls
 Recording commands run by a user
 Recording security events
 Searching for events
 Running summary reports
 Monitoring network access
Analysts should be aware of the audit logs while implementing the Linux
auditing service. Organizations will be defining more custom rules to track the
activities and audit services, which depends on the organization. In SIEM, there
are 10 pre-defined audit rules. So, simply implementing audit services will not
suffice. We must understand how to analyze the alerts. To analyze the alerts,
we must be familiar with the log fields and directories.

List of Linux directories:

Directories Details inside the directory

Displays system-wide messages and information.

Essentially, it’s a data log of every activities across the
entire global system. Everything occurs on Redhat-based
/var/log/syslog or /var/log/messages
systems, such as CentOS or Rhel, will be recorded in
messages. They go into Syslog on Ubuntu and other Debian
systems.

Keep track of successful and unsuccessful logins, as well as

authentication processes. The amount of storage available is
/var/log/auth.log or /var/log/secure
determined by the system type. Look at /var/log/auth.log for
Debian/Ubuntu. Go to /var/log/secure on Redhat/CentrOS.

/var/log/boot.log Keep track of start-up messages and boot information.

It’s for mail server logs, which can be useful for postfix,
/var/log/maillog or var/log/mail.log
smtpd, or other email-related services on your server.

Kernel logs and warning information are saved. Also

/var/log/kern
important for resolving issues with custom kernels.

It serves as a central location for device driver

/var/log/dmesg communications. To view the messages in this file, use
dmesg.

It will keep track of failed login attempts. As a result, it’s

/var/log/faillog useful for investigating suspected security breaches like
credential hacks and brute-force attacks.

It will maintain a log of Crond-related messages (cron jobs).

/var/log/cron For example, it will keep the record of like When the cron
daemon started a job.

Keeps track of background services that are operating but

/var/log/daemon.log
does not display them graphically.
 /var/log/btmp keeps a note of all failed login attempts.

/var/log/utmp Keeps track of current login state by the user

/var/log/wtmp Keeps track of every login and logout.

/var/log/lastlog Each login/logout is tracked in this log. 

It contains information about any yum command-based

/var/log/yum.log package installations. So you can see if everything went
smoothly.

It is a directory holding the Apache httpd daemon’s error log

and access log files. The error log file records every error
/var/log/httpd/ that httpd encounters. Consider memory issues and other
system-related issues. All requests that come in via HTTP
are logged by access_log.

Every debug, failure, and success message, as well as the

starting, stopping, and restarting of the MySQL daemon
mysqld, is recorded in the MySQL log file. The directory is
/var/log/mysqld.log or /var/log/
chosen by the system. /var/log/mariadb/mariadb.log is used
mysql.log
by RedHat, CentOS, Fedora, and other RedHat-based
systems. Debian/Ubuntu, on the other hand, uses the
/var/log/mysql/error.log directory.

Using the pureftp process, it keeps track of FTP

/var/log/pureftp.log connections. Here you may find information about every
connection, FTP login, and authentication failure.

Except for a few USENET mails, it usually contains

/var/log/spooler
nothing.

Keeps track of FTP file transfers. File names and user-

/var/log/xferlog
initiated FTP transfer information are included.

Before implementing the audit rules, familiarize yourself with the following
fields.

Cheatsheet for analyzing Linux audit logs:

Field Name Description Example Example Description

 The type: syscall conveys
message, that there was a
system call to the kernel.
The type: the path will b
logged to display file nam
type=Syscall
path information.
The type field contains type=Path
type The type: user_auth will
the type of the record. type=user_auth
logged if there is an
type=service_stop
authentication attempt is
detected.
The type: service_stop w
logged if any services are
stopped.

The msg field will

provide a timestamp and a In the log, the time is cap
unique ID of the record in in Unix epoch time. The
the form is 13 digits with a period
“audit(time_stamp: ID)”. the last three (millisecond
Multiple records can digits: 1623564119.769.
msg msg=audit(1623564119.769:179143)
share the same timestamp 1623564119.769=Time o
and ID if they were activity. We can convert
generated as part of the time using
same Audit event. epochconverter.com. And
Various event-specific 179143=ID of the event.
name=value pairs, pro

The hexadecimal notation

Records information
c000003e is converted as
about the CPU
human-readable format a
arch architecture of the system arch=c000003e
x86_64, which is an amd
encoded in hexadecimal
also known as Intel 64, i.
notation.
bit capable

syscall Records the type of Syscall=59 59 means “execve” i.e, sy

system call that was sent Syscall=2 call executes the program
to the kernel. referred to by pathname.
2 means “Open” i.e, syste
opens the file specified b
pathname.
There are more website in
source to find the relevan
syscall name/description
 each number.

The success field records

whether the system call
Records whether a system
success=yes recorded in that particula
success call was successful or
success=no succeeded or failed. No m
failed.
the call did not succeed. Y
means the call got to succ

Every Linux command

executed by the shell scri
user, has an exit status. 0
status means the comman
Records the exit code
successful without any er
returned by a system call.
exit exit=0 A non-zero (1-255 values
This value varies by a
status means the comman
system call.
a failure.
There are few websites
available to find the Linu
codes.

The a0 to a3 fields record

the first four arguments,
encoded in hexadecimal
notation, of the system
Hexadecimal form: a0=a4567
call in this event. These
a1=aa9680 a2=b858f0 a4=6cc Here the command is exe
a0, a1, a2 a3 arguments depend on the
Text Form: a0=curl a2=-L a3=-s to get the public IP of the
system call that is used
a4=http://ipecho.net/plain
and in the event logs,
hexadecimal will be
converted as text and
shown along with it.

Records the number of

2 describes, there are 2 pa
item path records that are item=2
the event.
attached to this record.

The parent process id refe

Records the Parent
ppid ppid=18996 an owner who gave a com
Process ID (PPID).
for initiating the activity.

pid The pid field records the pid=765 Here the above-mentione
Process ID (PID). orders some child to do th
activity. The activity don
 the child process is menti
in the pid. PID is the sam
threat id.

The auid field records the

Audit user ID, which is
the login uid. This ID is
assigned to a user upon The auid number represen
login and is inherited by unique id of the user who
auid every process even when auid=5645678934 done the activity. Search
the user’s identity auid=*, the exact user wi
changes (for example, by displayed in the user field
switching user accounts
with the su – perk
command).

uid 1) The uid records the real type=PATH msg=audit(12/22/2010 We need to track a user,
gid user ID of the user who 11:36:37.357:23) : item=3 whether it’s a real person
euid started the analyzed name=/etc/group~ system the user, so that w
suid process. 1) don’t lose track. For exam
fsuid 2) The gid field records type=SYSCALL by using “sudo” or “su” t
egid the group ID of the user msg=audit(12/22/2010 user will change their
sgid who started the analyzed 11:36:37.357:23) : arch=i386 previlege. In this situation
fsgid process. syscall=rename need one more sub-uid to
3) The euid field records success=yes exit=0 a0=9164890 the activity. This is
the effective user ID of a1=91cf6f8 a2=9164890 a3=91cf6f8 accomplished by assignin
the user who started the items=4 ppid=2026 extra UID. The AUID, w
analyzed process. pid=2168 auid=rainer uid=root different from the “norma
4) The suid field records gid=root euid=root suid=root UID of the user, and is
the set user ID of the user fsuid=root egid=root supposed to remain uncha
who started the analyzed sgid=root fsgid=root tty=pts0 ses=1 whatever the user does.
process. comm=vi exe=/usr/bin/vim.basic Here we have 3 groups of
5) The fsgid field records key=mykey events. Each group conta
the file system group ID 2) single type=SYSCALL it
of the user who started the type=SYSCALL which describes what bas
analyzed process. msg=audit(12/22/2010 system call has been exec
6) The egid field records 11:36:37.357:25) : arch=i386 and several other items
the effective group ID of syscall=open describing pertinent detai
the user who started the success=yes exit=3 a0=9164890 1) Action done on the pat
analyzed process. a1=241 a2=1a4 a3=0 items=2 name=/etc/group,
7) The sgid field records ppid=2026 pid=2168 2) they all refer to the
the set group ID of the auid=rainer uid=root gid=root executable
user who started the euid=root suid=root fsuid=root exe=/usr/bin/vim.basic, w
analyzed process. egid=root is the program used by th
8) The fsgid field records sgid=root fsgid=root tty=pts0 ses=1 person editing that file.
the file system group ID comm=vi exe=/usr/bin/vim.basic 3) they all point out that t
 user editing the file was
uid=root, and had logged
auid=rainer.
key=mykey
4) they describe a sequen
3)
three events happening to
type=SYSCALL
edited path name=/etc/gro
msg=audit(12/22/2010
ordered by time:
11:36:37.393:26) : arch=i386
—– at 11:36:37.357:23, t
syscall=chmod
path was renamed
success=yes exit=0 a0=9164890
of the user who started the (syscall=rename) to
a1=81a4 a2=1 a3=0 items=1
analyzed process. name=/etc/group~
ppid=2026 pid=2168
—– at 11:36:37.357:25, i
auid=rainer uid=root gid=root
opened (syscall=open),
euid=root suid=root fsuid=root
presumably to write the n
egid=root
version, and finally
sgid=root fsgid=root tty=pts0 ses=1
—– at 11:36:37.393:26, t
comm=vi exe=/usr/bin/vim.basic
permissions were change
key=mykey
(syscall=chmod), most lik
reset them to the previous
value.

The tty field records the The pts/0 is telling you w

terminal from which the “pseudo terminal” the use
analyzed process was logged in on. In this case
invoked. Records the terminal #0. The “(:0.0)”
tty name of the controlling tty=pts0 you which hostname and
terminal. The value displays what we are usin
(none) is used if the A tty is a native terminal
process has no controlling device, the backend is eit
terminal. hardware or kernel emula

The “ses” field records

the session ID of the
The number represents th
ses session from which the ses=14567
of the current session.
analyzed process was
started.

comm This field records the comm=curl 1) curl is used to transfer

command that is comm=chmod from or to a server via HT
executed. HTTPS, SCP , SFTP , an
2) chmod is used to chang
access mode of the file.
These are few examples.
command can be anythin
which describes the exact
 activity executed on the
machine.

Here the curl command w

This field will display the
executed in the path “usr/
path of the execution
exe exe=”usr/bin/curl” This is the same as windo
from where the activity
logs, but here the director
was done.
names are different.

The keyword depends up

This field will display
rule. For each rule, there
keyword associated with
Key Key=”recon” be different keywords. H
the rule which was the
keyword recon means
cause of the alert/event.
reconnaissance activity.

The cwd contains the path

to the directory in which Here, the syscall was requ
cwd cwd=”/home/perk”
the system call was from the path “home/perk
invoked

The name field the path of

the file or directory that Here, the syscall was tow
name name=”bin/chmod”
was passed to the system the path “bin/chmod”
call as an argument.

Files written to Linux

filesystems are assigned
an inode. The inode field
contains the inode number The following command
associated with the file or displays the file or directo
inode inode=657456
directory recorded in this that is associated with the
event. These unique IDs 657456 inode number
are used by the
filesystem’s database to
keep track of files.

mode The mode field records mode=0100755 Here, the first 4 octets rep
the file or directory the fie type & the last 3 o
permissions, encoded in represent the permission
numerical notation. file set by the user.
Permission numbers are:
0=—
1 = –x
2 = -w-
 3 = -wx
4 = r-
5 = r-x
6 = rw-
7 = rwx
So, here 755 means -rwxr

The proctitle field records

the full command-line of
the command that was
used to invoke the
We can convert the proct
analyzed process. The
proctitle= human readable text to kn
field is encoded in
PROCTITLE 636174002F6574632F7373682 the executed command. H
hexadecimal notation to
F737368645F636F6E666967 the converted text is
not allow the user to
cat/etc/ssh/sshd_config
influence the Audit log
parser. The text decodes
to the command that
triggered this Audit event.

Conclusion:

Linux audit logs are not as difficult as we believe. It will be even more simple
when we go through the log fields before progressing with the analysis.