New to Linux so please forgive me. I am using Linux 4, 64bit Enterprise and wanted to know how to setup the auditing aspect of the operating system. The items I wish to audit include failed logins, account lockouts, successful logins, policy changes, increased privlige assignments, account creation, account deletion (basically account management).

My next question is if I setup / configure the policies how do I view the security audits. Is there a interface that is easy to read or do I review a log file and if so where is the output sent?

A million thanks for any help anyone can provide.

John

Hello ans welcome to LQ. Hope you like it here.


Maybe you meant something like "Red Hat Enterprise Linux Advanced Workstation release 4" (RHEL AS 4). Being correct and complete helps. While you're at it please don't muck around with font/size unless you're nearly blind or thinking we are :-]


Most of those point to PAM which logs to syslog (also see 'auditd', 'last', 'lastb', 'faillog') except policy and role changes which point to SELinux (if applicable) which has Auditd log to audit.log or Syslog, else, w/o SELinux: none. You can get (e-mailed) reports with say Logwatch, but audit.log isn't covered by that AFAIK.

1. Although a general user was refused access to write to the hosts file it was not recorded in the Audits

2. General User attempts to kill a process; although the user was refused it was not recorded in the Audits

3. File Created in security relevant directories (/etc); although the user was refused it was not recorded in the Audits

I’m using the GUI Red Hat built in audit program and it is somewhat limited. Is there some way in Red Hat to add additional items to audit? The GUI Audit program, built into RHEL, seems to be pointing to all the logs /var/logs/ but RHEL is just not tracking the above 3 items.

Is SNARE or LAUS a third party auditing tool, I was told SNARE was best.

Thanks
John

I'm having a difficult time getting LAuS working via the auditd and auditcntrl found in my /sbin to write to the var/log/audit/audit.log.
I have a audit.rules in my /etc and that's about it. I'm considering using snare to supplment auditd not functioning as designed. I've posted my LAuS anomolies under Newbie.



Has anyone had a bad expierence with SNARE?

FYI, using Red Hat Enterprise Linux 4 Workstation 64bit Kernel 2.6.9-5.Elsmp

Thanks
John

Wrt your three questions you should show the relevant rules in /etc/audit/audit.rules to get a meaningful reply. My ESP-fu is really low today.


Please elaborate on the "weak" part?


Sure. I 'vi /etc/audit/audit.rules' or use 'auditctl' directly from the CLI.


Sorry. I don't know that "GUI Audit program".


LAuS and SNARE are not that interchangable or even comparable:
- LAuS is distribution default, SNARE is third party,
- LAuS rules act on and log in the local domain, SNARE rules act on the local domain and log to a SNARE server,
- LAuS has no concept of networking, SNARE follows the client-server paradigm,
- LAuS works with default RHEL and vanilla kernel.org kernels, SNARE needs a kernel patch,
- LAuS is GPL, SNARE agents are GPL but the necessary SNARE server is proprietary software,
- LAuS is part of SuSE and RHEL's Enterprise Linux in their CAPP/EAL4(+?) configuration and certification, AFAIK SNARE is not.


Define "best"? And at least tell us who exactly told you that and what his or her qualifications are.

I got Auditd and the auditing function working; long story short in terminal mode (connected to the internet) typed command, up2date and only updated two packages (up2date and audit). Man do I feel stupid but then I again I'm new at this and very conservative unitll I get a better feel for linux.


Now I am attempting to configure auditing and I have typed the commands:
chkconfg auditd on
chkconfig auditd start

Next I rebooted and for good measure typed auditctl -e 1 to enable audit system calls. It appears all the auditd services are running (typed ps -ef). Logged in as a user (smithers) and attempted to provoke an act I wish to monitor (users who attempt to write to /etc directory but are denied access)

In the /etc/audit.rules file I typed the below:

-w /etc -p wa

Above says report back write and atrribute change permission to /var/log/audit/audit.log?

I logged in as a user and tried to write to the /etc directory and was denied (which is good) but the logs did not reflect my attempt to write to the /etc directory; should I be using a different permission to monitor?

No, permissions look OK. (What I do is always supply a tag with "-k", easier to grep log for.) Wrt logging, IIRC audit.rules is read TTB so rules higher up could block a log lower down. If you've got lotsa rules maybe post your audit.rules and excerpt from audit.log? BTW, also do not forget to react on questions and issues above.

Below is my audit log /var/log/audit/audit.log:

type=DAEMON_START msg=audit(1211315963.855:5339) auditd start, ver=1.0.15, format=raw, auid=4294967295 res=success, auditd pid=2891
type=KERNEL msg=audit(1211315963.854:0): audit_enabled=1 old=0
type=KERNEL msg=audit(1211372699.654:10387609): audit_enabled=1 old=1
type=KERNEL msg=audit(1211372699.654:10387609): syscall=44 exit=48 a0=3 a1=7fbfff8850 a2=30 a3=0 items=0 pid=6307 loginuid=-1 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0

Below is my Audit rule /etc/audit.rules:
# This file contains the auditctl rules that are loaded
# whenever the audit daemon is started via the initscripts.
# The rules are simply the parameters that would be passed
# to auditctl.

# First rule - delete all
-D

# Increase the buffers to survive stress events
# Make this bigger for busy systems
-b 256

# Feel free to add below this line. See auditctl man page

# Increase the buffers to survive stress events
-b 256
#
-w /var/log/audit/audit.log -p wa -k LOG_audit
-w /etc/ -p wa
-w /etc/shadow -p wa
-w /var/log -p wa

Below is my auditd.conf /etc/auditd.conf:

#
# This file controls the configuration of the audit daemon
#

log_file = /var/log/audit/audit.log
log_format = RAW
priority_boost = 3
flush = INCREMENTAL
freq = 20
num_logs = 4
#dispatcher = /sbin/audispd
#disp_qos = lossy
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


UnSpawn special note in file directly above:
#dispatcher = /sbin/audispd

Should this be commented out and FYI I do not have a audispd located in /sbin/

Thanks
John

Your auditd.conf looks like default. AFAIK audisp isn't crucial, since it's a python script that dispatches audit events to 3rd parties like Prelude, but why you have none in your audit package is beyond me. Your rules file doesn't show any glaring errors except the absence of a trailing slash for the /var/log/ directoryname. I wonder what requirements you followed to get a ruleset like that? Audit packaged CAPP rules says about anything /var/:
and I wonder if there's something to say for monitoring the /var/log inode itself or even the *whole* of /var/log/ in terms of performance and false alerts...
BTW, what rules and requirements do you follow to secure this machine?

Per your comment "Your rules file doesn't show any glaring errors except the absence of a trailing slash for the /var/log/ directoryname." good catch and I will correct. As a matter of fact I will remove the reference all together. My main concern is for user activity on the /etc/ directory ensuring they do not attempt to write files to the log and if they attempt to I need to audit this. Maybe explaining that need will help?

Thanks
John

Here is what I got after typing Save the file and do auditctl -R /etc/audit.rules

[root@localhost ~]# auditctl -R /etc/audit.rules

No rules

File system watches not supported

There was an error in line 4 of /etc/audit.rules

Below is the actual audit.rules file


# This file contains the auditctl rules that are loaded
# whenever the audit daemon is started via the initscripts.
# First rule - delete all
-D
# Feel free to add below this line. See auditctl man page
# Increase the buffers to survive stress events
-b 256
-w /etc/shadow -p wa




My concern is it says File system watches not supported. Is this a Kernel issue?

Fix error, then try again.

BTW, also do not forget to react on questions and issues above.

I'm not sure if this is still active. I noticed it while looking for something else.

We use a python program/script to read and format our audit logs daily. We have the cron run it and mail the report to root. You can find it at:

http://www.g-loaded.eu/2006/12/20/se...eports-script/

It reports AVC, logins, and account mods by date/time, auid, term and more. I'm not sure if this meets your needs but though that I would suggest it.