Minimum Requirements

Linux SSH-based Event Manager collection technology

In order to use the Event Manager collection technology, you need to provide a user profile that has the following permissions:

A Linux kernel capable of audit syscalls. This is supported by default on Kernels 2.6.x, but some distributions might disable the feature for custom purposes, although most modern distributions come with this enabled. Please refer to your Linux vendor documentation in order to check if auditing is supported.
A Linux package called audit is required. This tool allows you to configure audit rules and query the audit logs with some powerful features such as fine grained filtering. The Linux Audit collectors depend directly on just one application that comes with this package: ausearch, so it is a requirement to have it properly installed on the Linux host. Another application called auditctl is required to create your audit data.
A remote connection from ThinkServer by using SSH or TELNET (not recommended).

Connections Type

The Connection Type option allows you to define the protocol you want to use to connect to the remote Linux/UNIX host. At this moment, SSHv2 and TELNET are supported. TELNET is provided as a compatibility option for legacy systems, although it’s not recommended because it’s not secure and it is very slow compared to SSH.

Private Key

The Private Key option gives you the possibility to use the private key authentication method available in OpenSSH-based daemons. This kind of authentication uses a public and private key pair of files that are used when connecting to the server. You only need the private one, as the public is “deduced” in runtime by the connections engine. Once you have your private key stored in Event Manager server, put the full path to the file inside the PKI field into the SSH (public key) credential.

The private key must be a cryptographic RSA or DSA key that’s compatible with OpenSSH and associated with the remote host. There are several tools for generating and associating key pairs for authentication. The most common one is ssh-keygen, which should be available in your remote host. If you have a private key in .ppk format (from the popular tool PuTTY), you can export it to OpenSSH format by using the PuTTY Key Generator.

Remember that private key authentication is just an option, not a requirement for the data retrieval.

Linux Syslog-based Event Manager collection technology

Syslog-based collection technology within Event Manager requires the syslog trail to be re-directed to the Event Manager collection node.

See Configuring_Remote_Syslog_-_Unix_and_BSD-OSX for information on how to configure this setting.

Audit Daemon Installation

The following Audit Daemons can be used with Event Manager. Use the instructions to install the daemon of your choice:

Debian/Ubuntu - apt-get install auditd audispd-plugins
Red Hat/Cent OS/Fedora: usually already installed (package: audit and audit-libs)

Activating the auditd daemon

Enabling System Call auditing for one session only:

Enable with auditctl -e 1 and disable with auditctl -e 0. These settings are not persistent, so they will not survive a system reboot.

Server Configuration

The configuration of the audit daemon is covered 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 audit.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 log files to be kept.

The configuration of the audit daemon is specified in the /etc/audit/auditd.conf configuration file. Each Linux distribution comes with its own default configuration. For example, SUSE Linux uses the following configuration by default:

log_file = /var/log/audit/audit.log

 log_format = RAW

 log_group = root 

priority boost = 4

 flush = INCREMENTAL

 freq = 20 

num logs = 4

 disp_qps lossy

 dispatcher = /usr/sbin/audispd

 name_format = NONE

 # name = mydomain

 max log_file = 5 

max_log_file_action = ROTATE

 space_left = 75

 space_left_action = SYSLOG

 action_mail_acct = root 

admin_space_left = 50 

admin_space_left_action = SUSPEND 

disk_full_action = SUSPEND 

disk_error_action = SUSPEND

 #tcp_listen_port =

 tcp_listen_queue =5 

#tcp_client_ports = 1024.65535 

tcp_client_max_idle = 0

Most of the settings in this file concern the audit log files and how the logging is completed. The most important settings concern the actions the daemon should take when encountering certain critical conditions or errors (system low on disk space, system out of disk space, or disk error) and when to warn the administrator about these conditions. Usually, the default configuration will be appropriate for most systems.

Audit.rules

Audit rules are used to specify which components of your system are audited. There are three basic types of audit rules:

Basic audit system parameters
File and directory watches
System call audits

Before creating an audit rule set and prior to rolling it out to the system, carefully determine which components to audit. Extensive auditing causes a substantial logging load. Make sure that your system provides enough disk space to store large audit logs and test your audit rules set extensively before rolling it out to a production system.

Audit rules can be either passed to the audit system by the command line using auditctl or bundled into a rules file located under /etc/audit/audit.rules that is read during the start of the audit daemon:

# basic audit system parameters

-D

-b 8192

-f 1

-e 1

# some file and directory watches-w /var/log/audit/

 -w /etc/audit/auditd.coni -p rxwa

 -w /etc/audit/audit.rules -p rxwa

 -w /etc/passwd -p rwxa

 -w /etc/sysconfig/

# an example system call rule

 -a entry,always -5 mkdir -5 rmdir

The basic audit system parameters include a rule to delete any pre-existing rules (-D) to avoid clashes with the new rules, a rule that sets the number of outstanding audit buffers (-b), the failure flag (-f), and the enable flag (-e):

-b: depending on the audit load of your system, increase or decrease the number of outstanding audit buffers. If there are no more buffers left, the kernel checks the failure flag for action.
-f: the failure flag controls the kernel’s reaction to critical errors. Possible values are 0 (silent), 1 (print a failure message), and 2 (panic, bring the system down - no clean shutdown and risk of data loss or corruption).
-e: if set to 1, this enables audit and audit contexts for system calls. Setting it to 2 does the same, but also locks down the configuration. Set to 0, audit is disabled. This flag is used to enable or disable audit temporarily.

File system watches can be added whenever you want to track files or directories for unauthorized access. Typical examples would include watching the audit configuration, logs, user and security databases. Use permission filtering to focus on those system calls requesting the permissions in which you are interested:

-w /etc/audit/audit,rules -p rxwa

The -p flag enables permission filtering. This example has permission filtering turned on for read, write, execute and attribute change permissions.

Note the following limitations to file system watches:

Directory watches produce less verbose logs than exact file watches. When in need of detailed file-related records, enable separate file watches for all files of interest.
Pathname globbing of any kind is not supported by audit. Always use the exact pathnames.
Auditing can only be performed on existing files. Any files added while the audit daemon is already running are ignored until the audit rule set is updated to watch the new files.

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

Use a clean start and without any loaded rules. Active rules can be determined by running auditctl with the -l parameter:

[root@host ~]# auditctl -l

No rules

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

Examples of Audit monitoring in Linux

Monitoring the creation and deletion of directories with the Linux Directory Created/Deleted Collector:

auditctl -a entry,always -S mkdir -S rmdir

Monitoring the file attributes operations with the Linux File/Directory Attribute Accessed/Modified Collector:

Auditctl -a entry,always -S chmod -S fchmod -S chown -S chown32 -S fchown -S fchown32 -S lchown -S lchown32

Monitoring the file link and rename operations with the Linux File/Directory Linked/Renamed Collectors:

auditctl -a entry,always -S unlink -S rename -S link -S symlink

Monitoring the mount/unmount operations with the Linux Device mounted/unmounted Collector:

auditctl -a entry,always -S mount -S unmount -S unmount2

Adding watches to individual files and directories to be used with the Linux File Content Accessed/Modified Collector:

auditctl -w /var/log/audit

auditctl -w /var/log/audit/audit.log

auditctl -w /etc/audit.rules -p wa

auditctl -w /etc/libaudit.conf -p wa

auditctl -w /etc/sysconfig/auditd -p wa

For an example of how the monitoring works, we can use the /etc/passwd file. We can put a ‘watch’ on the file by defining the path and permissions to look out 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 an important difference between the two. The four options are:

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

To audit all the actions required for the Event Manager actions collection, execute the following commands:

sudo pico /etc/sudoers

Add the following line at the end of the file:

my_user_name ALL=(ALL:ALL) NOPASSWD:ALL

Execute:

auditctl -a exit;always -S execve

service auditd restart

To audit the changes on the test file in /home/helpsystems folder

auditctl -w /home/helpsystems -p wa -k test

service auditd restart

To audit the permissions changes in the files of the folder /home/helpsystems

auditctl -a exit, always -S fchmodat -S chmod -S fchmod

auditctl -w /home/helpsystems/test -p a

service auditd restart