From mboxrd@z Thu Jan 1 00:00:00 1970 From: DJ Delorie Subject: Re: [PATCH] Add auditd listener and remote audit protocol Date: Thu, 14 Aug 2008 18:16:18 -0400 Message-ID: <200808142216.m7EMGILI029666@greed.delorie.com> References: <200808142143.m7ELh0MP028560@greed.delorie.com> <1218751136.7022.206.camel@homeserver> Return-path: In-reply-to: <1218751136.7022.206.camel@homeserver> (message from LC Bruzenak on Thu, 14 Aug 2008 16:58:56 -0500) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: LC Bruzenak Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com > What I'm getting is that in addition to kernel-generated local events > the auditd would also receive signals as well as tcp-based events from > other sources. Would this be the way of implementing multi-source audit > aggregation or is it something different? The net result is to aggregate audit logs from many systems onto one central audit server. Remote audit messages have the new "node=" tag on them so you know where they came from. I.e. you configure audisp-remote.conf like this: remote_server = 10.2.3.4 port = 1237 And the central server (10.2.3.4 in this example) like this: tcp_listen_port = 1237 And then the client sends all audit messages to the server, where they're logged to disk. This is similar to centralized syslog logging. The event loop change I linked to is a neccessary design change prerequisite to this one, since the listener adds (potentially) many descriptors which will need to be serviced. The loop now services four types of events: local signals, local netlink, the listen socket (for new connections), and client sockets (for incoming audit messages).