Hello,
I have solved my problems about auditing under DECUNIX 4.0B.
Thanks to scott_at_zk3.dec.com who greatly helped me.
There were two questions in my first post (see after the signature
message).
I quickly sent a SUMMARY about the first question with the subject:
SUMMARY (partial): auditing under DECUNIX 4.0B.
About the second question regarding auditing: the solution to allow
all the clients to successfully send their logs to the 'audit hub'
is to put the short name and the full qualified host name of each
auditd client in the file /etc/sec/auditd_clients on the audit hub. Why ?
Because the name service is not always well configured. For example the
files /etc/hosts and /var/yp/src/hosts are not always very 'clean'
because edited by hand.
For a client 'clientX' (with IP addressi a.a.a.a) in the domain
'.x.y.z', if hosts file contains the line
<a.a.a.a> clientX clientX.x.y.z
authorising 'clientX.x.y.z' in /etc/sec/auditd_clients will not work
(the audit hub will refuse the access) but authorising 'clientX' will work.
Now if hosts contains
<a.a.a.a> clientX.x.y.z clientX
authorising clientX.x.y.z in /etc/sec/auditd_clients will work.
The best solution as suggested by scott_at_zk3.dec.com is to put the short
and long name of each host in /etc/sec/auditd_clients on the audit hub.
I had a second point about auditd -x. It is solved too.
When using an audit hub, 'auditd -x' doesn't work when running from the
client. scott_at_zk3.dec.co suggested to use 'auditd -x -p <id>' on the audit
hub to increment the log number. See 'Mail 3' bellow.
Following are very interesting messages extracted from his mails:
Mail 1
-------
> christophe,
>
> > First I tried to have an audit HUB but without any succes:
> > 1) audit -x does not work in this case
> > 2) some clients are unable to send audilogs to the audit hub
> > without any raisons and then store auditlogs in /var/adm.
>
> The "audit -x" increments the index of the logfile. When routing data to
> a remote host, there is no index (no local logfile), so the "-x" when
> going across the net or to a device is a no-op.
>
> As some clients are able to send data to the hub, then the server is
> willing to listen to the net.
>
> Is the /etc/sec/auditd_clients entry correct? I've had problems in the
> past due to misconfigured BIND. It's not necessary, but I frequently add
> the hostname with and without the fully qualified bind suffix.
>
> What versions are the server and clients? V4.0D and later uses data
> acknowledgement. If your client is running V4.0D and is shipping data
> to a server which is before V4.0D, then use the "-u" flag. If the server
> is V4.0D and the client is before V4.0D, then no problem.
>
> -u Instructs the client audit daemon to not require acknowledgement from
> the server (machine collecting audit data) for the receipt of audit
> data sent over the network. The -u option is used for compatibility
> with servers that are running versions of DIGITAL UNIX prior to
> Version 4.0D.
>
> If neither of the above ideas help, one of the auditd console logs should
> show a message indicating a failed connection. That might provide some
> clue.
>
> Hope this helps.
>
> -- lrs
Mail 2
------
> christophe,
>
> > I would prefer to have audit -x working. This way, each midnight
> > I could run 'audit -x' in the crontab and then run audit_tool
> > to make a summary, save auditlogs and 'rm' old auditlogs.
>
> Each auditlog file is written by a local auditd. As long as the local
> auditd performs the "auditd -x", you should get what you want.
>
> auditd 1 >----net-------------> auditd 2 (hub)
> ^-- shipping across net ^-- storing data locally
>
> So in the above, "auditd -x" by auditd #1 is a no-op, but if auditd #2
> performs the "auditd -x", then the log will get incremented.
>
<<< ........ truncated here ........ >>>
> -- lrs (at scott_at_zk3.dec.com)
Mail 3
------
> christophe,
>
> Glad I was able to help out.
>
> > About auditd -x and audit stop/start, I will do auditd -x on the audit hub
> > each midnight to switch to an new auditlog and on each client I will use
> > audit stop/start. 'auditd -x' on the audit hub affects only it's local
> > auditlog not the remote clients auditlogs.
>
> I think I see why you stop/start audit on each client. On the server, you
> wish to change log for each client connection, but you don't know the
> client connection id's ahead of time. Using stop/start, you force a new
> connection, with a new logfile index. Instead, you could try the
> following:
>
> auditd -w | grep SERVING | cut -f 3 -d " " | sed s/^#/"auditd -x -p "/ | sh
>
> which will get the auditd to tell you the connection id's, then construct
> the command line to increment each log (and no reason to turn off audit).
>
> (I'm sure some shell wizards can come up with something fancier, but this
> works.)
>
> Hope this helps.
>
> -- lrs (at scott_at_zk3.dec.com)
Christophe DIARRA.
***
Christophe DIARRA
Institut de Physique Nucleaire
Bat 100 - S2I
91406 ORSAY Cedex
Tel: (33) 01 69 15 65 60
Fax: (33) 01 69 15 64 70
E-mail: diarra_at_ipno.in2p3.fr
***
> Hello,
>
> I have started auditing on all my DECUNIX machines.
>
> First I tried to have an audit HUB but without any succes:
> 1) audit -x does not work in this case
> 2) some clients are unable to send audilogs to the audit hub
> without any raisons and then store auditlogs in /var/adm.
>
> I abandonned the audit HUB and now I am using NFS to write auditlogs
> in mounted directories.
>
> THE PROBLEM NOW:
>
> After a crash and the reboot of the NFS sever, all the clients hangs.
> ping works, telnet takes many many minutes before asking for the
> password.The computers are to slow and are unusable. I am obliged to
> reboot.
>
> THE QUESTIONS:
>
> 1) Is it possible to use NFS with audit on DECUNIX ?
> What happens when the NFS server crashes ?
> Is it possible to stop auditing when NFS is not working ?
>
> Following is my auditd options from /etc/rc.config:
>
> AUDITD_FLAG="-l /import/admin/audit/decunix/files/ipnosb/auditlog -c
> /var/audit/auditd_cons -o kill "
> export AUDITD_FLAG
> AUDITMASK_FLAG=" -s exec_argp -s login_uname < /etc/sec/audit_events"
>
> 2) Why the audit hub functionality works for only for some clients ?
> I am sure there is no authorisation problems. Some times it stops
> working for a client after /sbin/init.d/audit stop then
> /sbin/init.d/audit start.
Received on Wed Dec 17 1997 - 16:20:53 NZDT