Link to home
Start Free TrialLog in
Avatar of CSIA AN
CSIA ANFlag for Andorra

asked on

Audit HISTFILE for all users on AIX

Here we go again ;)

In order to audit KSH history for all users, we have configured HISTFILE on /etc/profile this way:

# Configurando las variables HISTORY
# HISTFILE
d=`date "+%H%M.%m%d%y"`
t=`tty | cut -c6-`
u=`ps -ef|grep "$t "|grep "\-ksh"|sort -k5|head -1|awk '{print $1}'`
w=`who -ms | awk '{print $NF}' | sed "s/(//g" | sed "s/)//g"`
y=`tty | cut -c6- | sed "s/\//-/g"`
mkdir $HOME/.history.$LOGIN 2>/dev/null
export HISTFILE=$HOME/.history.$LOGIN/.sh_history.$LOGIN.$u.$w.$y.$d
readonly HISTFILE

Open in new window


Everything works fine, but any user can delete its HISTFILE files. for example: ".sh_history.israels.israel.aixhost.pts-12.0832.042316" so audit will not work anymore in this case.

The question is, (I could not find a solution so far):
 - It's possible to protect/keep HISTFILE file for all users, even if the user delete it?  

We need to keep some way, if it's possible, all HISTFILEs for auditors.

Thanks in advance.
Avatar of woolmilkporc
woolmilkporc
Flag of Germany image

Hi again,

Normally, this should be a case for NFS4 ACLs.
AIX supports these ACLs with jfs2 and extended attributes version 2.

But there are heavy drawbacks. First I'll describe how  NFS4 ACL could work, then comes the bad stuff.

First thing to do is converting the concerned filesystem to eav2:

chfs -a ea=v2 /homefs

Next, you'll have to create the concerned history file ("touch" will suffice) and apply a new ACL to it.

mkdir $HOME/.history.$LOGIN 2>/dev/null
export HISTFILE=$HOME/.history.$LOGIN/.sh_history.$LOGIN.$u.$w.$y.$d
readonly HISTFILE
# now:
touch $HISTFILE
aclput -i /etc/history_acl $HISTFILE

Now for the ACL itself.
I called the new ACL file "/etc/history_acl",  name it according to your needs.

It should contain something like this:

*
* ACL_type   NFS4
*
s:(OWNER@):     a       rwp
s:(OWNER@):     d       xod
s:(GROUP@):     a       r
s:(GROUP@):     d       wpWxACod
s:(EVERYONE@):  a       r
s:(EVERYONE@):  d       wpWxACod


Now for the drawbacks.

1) This ACL allows for reading/writing and appending but not for deleting. "rm"against the file doesn't work, but it's still possible to empty it by means of a simple redirection:

cat /dev/null > $HISTFILE
or even
>$HISTFILE

2) The user can modify the ACL by means of the "acledit" command. They can remove the "d" mask from the "d eny" line and add it to the "a llow" line. Moreover, a simple "chmod" against that file will revert the ACLs to the old AIXC format, where we don't have a "deny delete" flag.

I didn't yet find a method to circumvent this.
There seems to be no way to have "append" without "write".
The docs sound as if denying ACL/attribute modification should be possible (here "s:(USER@)" must be replaced with "u:real_username"), but  I couldn't get it to work.

So far, so bad. I think this rudimentary protection could also be achieved by removing "write" from the parent directory.
Alas AIX doesn't have something like Linux's "chattr -a".

Still researching ...
One simple solutiion could be to "hide" the rm command. Change it's name and only tell the system/programmer types what the new name is. Or, make it password protected, where it prompts for a password before it deletes the file. You could get even more sophisticated by having it prompt only when the name is .sh_history*, otherwise just do it.
how important for you to keep copy of history files?

You may try to copy continuously these files. I would try running below command for each user:

tail -f /path/to/user1/home/.bash_history >> /path/to/commonlogs/user1_hist

as background job

This is not the best way, but I think works
ASKER CERTIFIED SOLUTION
Avatar of woolmilkporc
woolmilkporc
Flag of Germany image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Please consider following scenario:

- user logs in
- all commands used by user in that session are buffered
- user nullify his / her history file
- user exit
- shell writes commands run / used to history file
- tail -f copies these command to different file

smart user can also unset history, can run different shell, etc.
Avatar of CSIA AN

ASKER

Hi, although I'm out  of office right now, but just want to  make a couple of thoughts..

@wmp, au-ksh93 was the only solution, from a previous PMR with IBM,  to audit ksh history for all users...but IBM does does not any support for this au-ksh93.  This was the answer from IBM:

I could not find anyway to enable ksh history in audit subsystem. However I found the below article which can be used to achieve your purpose..
http://www.ibm.com/developerworks/aix/library/au-korn93/

Unfortunately, the version of Korn Shell 93 (/usr/bin/ksh93) provided  with IBM AIX does not provide the SHOPT_AUDIT feature. Implementing Korn Shell 93 auditing features on an AIX system requires the system  administrator to download and compile the latest version of Korn Shell 93 from AT&T.

 Please note that IBM does not provide such a ksh fileset, and should you compile the software yourself, you lose support for ksh in this particular instance; the quoted article is informative, not official documentation for best practices etc.


@omarfarid,
KSH history audit is not a bad idea for sys admins. Also, it's mandatory for auditors.
About ksh shell, ksh is the only shell on all AIX. Only root can change shell for users.
Also, users can not unset HISTFILE because this variable is readonly, see the code we use on /etc/profile here in this thread.  
We thought to use tail, but we have more than 300 users logged at the same time...  

Thanks to both.
What I meant by saying user can change shell, is when logged in, the login shell will be ksh but he/she can always run e.g. sh or other shell and continue working.
If there's no technical solution, then you have to push it back to the Auditors; Ask what other organisations have done, and what they are trying to achieve with this. If NIST or PCI don't mandate it explicitly, it's probably not necessary.

Shell history is fairly unsuitable to know what's really changed or when - Alternative mechanisms include:
- "teeing" the shell input and output to `script` so _everything_ is captured (though that still leaves the issue of being able to delete the record). Centrify DirectAudit is pretty powerful :-)
- setting up system-wide auditing on sensitive commands and files to detect when "interesting" incidents occur. That would provide timestamps as well.
- File Integrity Monitoring and/or Configuration Management.

I'm assuming you are already following good practices such as making Admins log in with their own userid and then using `su` or `sudo` to become a Privileged  user.
Avatar of CSIA AN

ASKER

Thanks wmp!