Chapter 6 | Audits and Ownership

Audits

Audits are often required by regulations or industry standards, as they create records of security events that can be critical in both providing information for forensic analysis after an incident to find out where the holes in your security are, and in preventing attacks from ever taking place. Possible items included in this audit includes time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, filenames involved, and access control or flow control rules invoked.

Despite their obvious importance, audits are not necessarily in place by default. In order to keep an audit log of all additions, deletions, alterations, and other changes, you’ll need to make sure you have an auditing service running.

Check the status of your auditing service with the following command:

#systemctl is-active auditd.service

 

 

Enable the auditd service with the following command:

# chkconfig auditd on

Monitoring Logins

A full audit of the environment can provide invaluable information, but it may take some time to get through. One quick way to check for suspicious activity is to monitor logins. 

Using the last command will provide a list of the last ten login attempts. 

 

 

 

 

 

 

 

Since you can see both successful and unsuccessful logins, you can determine if unusual activity has been occurring and warrants additional investigation. For instance, repeated unsuccessful logins can indicate an attempt to breach the system. For a more thorough analysis of login attempts, look at /var/log/authlog.

This logging activity can also be directed to a syslog system to allow for consistent monitoring. Using a monitoring solution like a security information and event management (SIEM) can ensure that suspicious activity is flagged and instantly sent to the appropriate security team member for immediate action.

Unowned Files

Unowned files and directories are typically the result of a user leaving the organization. Their user id is deleted, creating files that have no owner listed. They are problematic for a number of reasons. 

Though typically an oversight or a mistake, unowned files and directories may be a sign that something is wrong, and should be investigated. Depending on the outcome, these files should be either dangerous, which should prompt a report and deletion, or unnecessary, in which case they should also be deleted. 

Additionally, if a new or existing user is assigned the same user id as the un-owned files, these files will be inherited. This ownership may give the user rights and privileges they should not have.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Either remove all files and directories from the system that do not have a valid user, or assign a valid user to all unowned files and directories on the system with the following commands:

#find / -xdev -fstype xfs -nouser

# chown <user><file>

 

 

 

 

 

 

 

 

 

Shared Accounts

Shared accounts occur when two or more people use the same user id to interact with a system. While this is seen in the case of many user ids, such as guest ids or departmental ids, it most commonly occurs in the case of root. Shared accounts are strongly discouraged for a number of reasons. 

First, while a shared account requires a login, it is still insecure, as it doesn’t provide identification. Anyone with the user id and password can use the account, and there is no way to track who exactly has access, eliminating accountability. If an incident occurs, you may be able to audit the system and see that a shared account was responsible, but it would be very difficult or impossible to tell who exactly was using the account at that time. 

 

 

 

 

 

 

In order to ensure accountability and accurate auditing, every user should have a dedicated account. Generic accounts should be removed where appropriate, or at least have direct login capabilities removed.

There are cases, like root, where shared accounts remain necessary, typically because they provide escalated privileges to a typical user account. When usage of these accounts is necessary, you can use sudo to temporarily run a command as the shared account, as it still logs activity as coming from the individual user. Since root and other shared accounts have such highly escalated privileges and can do a significant amount of damage if misused, Privileged Access Management (PAM) solutions are also recommended to more securely distribute and monitor access to them.