Is there some documentation on how tty auditing works? I've got it
enabled, but I can't tell when something is going to be logged. It's not
immediate. (Also, on ubuntu 12.04, our older kernel apparently doesn't
support the feature in the pam module that does *not* log passwords. So
that's fun. Maybe not the end of the world, if we get kerberos running for
the log transfer, but ... yuck.)
On Wed, Jul 13, 2016 at 9:32 AM, Steve Grubb <sgrubb(a)redhat.com> wrote:
On Wednesday, July 13, 2016 9:22:57 AM EDT Chris Nandor wrote:
> Secondary question: the reason for what I'm working on is that we want to
> be able to audit what folks do as root on our production hosts. We're
not
> a bank, and a perfect solution is not required, but we do need to be able
> to take reasonable steps to find out if people with access are doing bad
> things.
>
> Is this setup reasonable for that purpose?
Yes. You would want to do two things, first enable tty auditing. This is
done
by the pam_tty_audit module. Second consider adding the
32-power-abuse.rules
to your rules.
> I know that's a loaded question
> and I can answer any questions anyone has that are necessary to figure
this
> out. I am not asking so much about rules, but about architecture:
logging
> according to whatever rules we set up, to the local audit.log and
> immediately to a remote using audisp-remote, so the log can't be easily
> manipulated.
Remote logging is the defence against local log manipulation.
-Steve
> On Wed, Jul 13, 2016 at 8:57 AM, Steve Grubb <sgrubb(a)redhat.com> wrote:
> > On Wednesday, July 13, 2016 8:47:58 AM EDT Chris Nandor wrote:
> > > Hi, I had some odd behavior to report.
> > >
> > > I am running ubuntu 12.04. Using the default auditd and
audispd-plugins
> > > packages for my release, I was able to get logs sent to local syslog
and
> >
> > to
> >
> > > a remote auditd server (same basic configuration), but the entries
were
> > > being buffered somewhere (I think on the client side), and if the
server
> > > died reconnections didn't happen.
> > >
> > > So, I wanted a more recent version, so I compiled audit-userspace
from
> >
> > the
> >
> > > github src mirror,* trunk@1341.
> >
> > The github repo is a mirror of svn and is not always up to date. The
issue
> > you
> > are seeing is fixed in the next commit after the mirror stops.
> >
> >
https://fedorahosted.org/audit/changeset/1342
> >
> > if you want the lastest you can:
> >
> > svn co
http://svn.fedorahosted.org/svn/audit/trunk
> >
> > and then generate from there. I am planning to release audit-2.6.5
> > tomorrow.
> > So, if anyone can test the current code, I'd really appreciate it. I'm
> > hoping
> > the next release settles down the audit code.
> >
> > > When I did, I got some weird results. For example, I expected got
> > >
> > > something like this in my audit.log:
> > >
node=host.example.com type=CWD msg=audit(1468363871.644:3279856):
> > > cwd="/etc/audisp"
> > >
> > > And that was as expected. In syslog, I expected to get:
> > > Jul 13 08:34:53 host audispd:
node=host.loc.example.com type=CWD
> > >
> > > msg=audit(1468363871.644:3279856): cwd="/etc/audisp"
> > >
> > > But instead, I got:
> > > Jul 13 08:34:53 host audispd: type=CWD msg=node=
host.loc.example.com
> > >
> > > type=CWD msg=audit(1468363871.644
> > >
> > > As you can see, the whole thing was prepended with "type=CWD
msg=",
and
> >
> > the
> >
> > > line was truncated. Similarly, on the remote host, I got the same
thing:
> > > type=CWD
msg=node=host.loc.example.com type=CWD
> >
> > msg=audit(1468363871.644
> >
> > > I noticed that the most recent version of the src for ubuntu was
2.4.5,
> >
> > so
> >
> > > I grabbed the src tarball from packages.ubuntu and built it, and now
> > > everything looks fine. The exact same line I see in my audit.log
shows
> >
> > up
> >
> > > in the remote audit.log, with no buffering. When I restart the
remote
> > > auditd server or client, it reconnects. syslog has same entry
> > > (prepended
> > > with the timestamp etc.). Everything seems happy now.
> > >
> > >
> > > *For some reason I had to define `CC_FOR_BUILD=gcc` in my shell when
I
> >
> > ran
> >
> > > `make` from the svn/git src. I did not require this when building
2.4.5
> > > from the ubuntu src.
> >
> > I think that should have been detected during configure.
> >
> > -Steve