Audisp-remote - connection refused.

[Rituraj Buddhisagar]

HI Steve,

I did the necessary,
Change in auditd.conf - log_format to ENRICHED.
write_logs set to "no" on client and "yes" on aggregating server.
name_format was already set in auditd.conf and not in audispd.conf on both
the servers.

I still do not see any logs coming in /var/log/audit/audit.log on
aggregating server.

Any debugging tools to see the queue of audisp-remote? The spool file
/var/spool/audit/remote.log is not having entries populated (btw I had to
create it manually).

Thanks!




On Wed, Oct 4, 2017 at 8:49 PM, Steve Grubb <sgrubb at redhat.com> wrote:

> On Wednesday, October 4, 2017 10:01:49 AM EDT Rituraj Buddhisagar wrote:
> > Hi Steve / List
> >
> > Now, I have built auditd from source as per the mail thread and then also
> > created a startup script.
> >
> > The auditd is starting successfully.
> >
> > The client is able to connect to the aggregating server.
> >
> >
> > *node=guslogs type=DAEMON_ACCEPT msg=audit(1507125123.240:7272):
> > addr=192.168.103.2 port=60 res=success*
> >
> >
> > I have made the necessary change in the server in /etc/audit/auditd.conf
> >
> > *log_format = NOLOG*
>
> This is a deprecated option tells it to not write anything to disk.
>
> > I do not see any logs being populated - I checked log file on client, the
> > server - also the /var/spool/audit/remote.log on the client.
> > On the server side /var/spool/audit/remote.log is empty (I am not sure if
> > this is something I should be checking at all)
> >
> > I am clueless as to what is happening. Is there some way to debug this?
>
> Did you modify auditd.conf to have the format be nolog? If so, its an
> explained condition. Nolog means no logging to disk.
>
> > Where are these logs getting lost?
> > When change the log_format back to RAW I do see the logs getting created
> on
> > the client.
>
> For remote logging, you should set the format to enriched. This resolves
> things locally so that the aggregating server can make sense of it later.
> If
> you do not want events written to disk on the remote system, set
> write_logs =
> no. You should also set name_format = hostname (or something else) in
> auditd.conf of the remote systems. This is so you can tell who is creating
> the
> events in the aggregating server.
>
> On the aggregating server, also set the format to enriched. But there you
> have
> to have write_logs = yes. Also set name_format = hostname in auditd.conf of
> the server.
>
> I would not recommend setting the name in audispd.conf for any system.
>
> -Steve
>
> > I did my best reading on net and debugging this - but no success. Please
> > help.
> >
> > On Wed, Oct 4, 2017 at 1:52 AM, Steve Grubb <sgrubb at redhat.com> wrote:
> > > On Tuesday, October 3, 2017 4:00:27 PM EDT Rituraj Buddhisagar wrote:
> > > > Steve,
> > > >
> > > > Here is the relevant discussion on disabling the tcp listener on
> Ubuntu.
> > > > https://www.redhat.com/archives/linux-audit/2012-
> September/msg00027.html
> > > >
> > > > I do not know what exactly caused change - but now I think it should
> be
> > > > enabled in distributions.
> > > >
> > > > Please let me know.
> > > >
> > > > Btw, I got auditd running (by setting LD_LIBRARY_PATH variable) from
> > >
> > > source
> > >
> > > > now. Still audispd is not started now - what is the way / sequence to
> > >
> > > start
> > >
> > > > auditd and audispd - if you can point me to some reference or a
> startup
> > > > script will help.
> > >
> > > Since you installed in a non-standard location, you probably need to
> > > adjust
> > > paths in the config files.
> > >
> > > What I would recommend is not to build and install by hand, but to use
> > > their
> > > package manager to build a new package with listening enabled. The
> > > ./configure
> > > script takes a --disable-listener parameter. So, its probably as
> simple as
> > > deleting that in the source package and rebuilding.
> > >
> > > That said, I have no idea how to build a package on Debian or Ubuntu.
> > >
> > > -Steve
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/linux-audit/attachments/20171004/3a079b59/attachment.htm>