From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: Offline audit trail analysis Date: Tue, 11 Sep 2007 16:22:22 -0400 Message-ID: <200709111622.23459.sgrubb@redhat.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: linux-audit@redhat.com Cc: "Todd, Charles" List-Id: linux-audit@redhat.com On Tuesday 11 September 2007 15:31:53 Todd, Charles wrote: > Has anyone talked about sane ways to do offline analysis of Linux audit > logs? Presumably, this would be on another Linux system, but maybe not > the same host, and probably not on the same release or with the same > username/IP address access. Conceptually, ausearch would save and > optionally read a system's "configuration" to be saved for > interpretation later. ausearch uses getpw* and getgr* calls to resolve the uid & gid. Aside from that, I believe it is self contained. (I haven't dug too deep in answering this question.) > My goal is central logging, but doing the reporting/analysis on the > central host. That way, I can see a user across the Enterprise (or at > least in the Linux hosts), but with all the power of ausearch for > refining the report. That is in the works... > Ideally, I would do an ausearch -ts -te --raw --config-to= and it would do > things like saving the syscall lookup table, This is actually inside libaudit for all arches. > lookup users referenced in the reported audit trail, uid & gid are based on the host's /etc/nsswitch.conf settings. If file, then its the local passwd/group files. If not, you have a central uid database. > and resolve IP addresses references in the reported audit trail. Hmm. As long as systems don't get changed too much, this should be resolvable from anything that has DNS access. > Maybe one config file could be written for each data type in an existing > format (e.g. users in /etc/passwd format, hosts in /etc/hosts format, etc.). > I'm mainly after whether or not anyone has considered extending ausearch for > this kind of processing? Sort of. I am working towards central logging. Getting the new event dispatcher completed is the first step. But I haven't looked at storing user and gid away yet. The calls that I'm using don't really allow substituting a new passwd or group file. So, I'd have to change all that code. But if you have an enterprise setup, you shouldn't be deleting user IDs to keep from having a collision down the road. > This way, an archive of raw logs could be kept along with the exact > system configuration which allows offloading the audit trail analysis to > a trusted location, rather than risk side effects from a rootkit. Yep. -Steve