Eventually I got around to installing the
lrexec module. After some minimal configuration, the module is now loaded and running very nicely, logging all system calls made by users (yes, all, who knows how big the logs will be per day!?).
The pitfalls etc are in the extended entry.
Obtained the tarball from
here.
Untarred the tarball:
CODE:
tar yxvf lrexec-1.0.tbz
Read the README file - do it, you know it makes sense. :P
Basically followed the instructions in the README - ie:
CODE:
cd /path/to/lrexec
make
make install
and:
make load
although I opted to do 'kldload lrexec' rather than 'make load' to load the lrexec module.
After installing I checked the sysctl knobs were working ok:
CODE:
[2:07:30] munk@users /home/munk/bin/cerbNG/lrexec-1.0# sysctl lrexec
lrexec.logall: 0
lrexec.logargs: 5
lrexec.exec_group: -1
lrexec.max_bin_uid: 999
lrexec.envclean: 1
(they didn't originally look like that, I changed them to those settings, see below).
Ok all looks good so far - what I did next was modify /etc/syslog.conf so output from lrexec was directed to it's own logfile:
CODE:
!lrexec
*.* /var/log/lrexec.log
and added a line to /etc/newsyslog.conf to rotate the logfile daily - it's gonnna need it I figure seeing how large it could get:
CODE:
/var/log/lrexec.log 660 10000 * @T00
After touching /var/log/lrexec.log and HUP'ing syslogd:
CODE:
touch /var/log/lrexec.log
kill -HUP `cat /var/run/syslog.pid`
I checked to verify sys exec calls were being logged to /var/log/lrexec.log - they were, great :P
At this point there was an issue with system calls failing by regular users - it turns out that by default users with UID over 666 (determined by the sysctl flag lrexec.exec_group) are not allowed to execute non-system binaries (determined to be any binary with UID over the sysctl flag lrexec.max_bin_uid). This was causing problems because a lot of eggdrop users have cronjobs to run every 10 minutes to test whether their eggdrops are still up or not - all of which were failing.
To resolve this I just modified the sysctl flag lrexec.exec_group to a negative number as indicated in the README:
CODE:
sysctl lrexec.exec_group=-1
To make this stick at reboot I added the following to /etc/sysctl.conf:
CODE:
lrexec.exec_group=-1
With this modification, all was well and non-system binaries were again executable by non-privileged users.
Now all that's left is to work out how to analyze the logfiles created by lrexec on a daily basis. I started out thinking that I'd grep for anything mentioning any of the shells listed in /etc/shells - but turns out this is problematic because cron uses /bin/sh to execute it's jobs.... no biggy really, just need to give it some thought.
UPDATE:
Here's a very simple perl script -
split_lrexec.pl - to split lrexec logfiles into individual per user logfiles:
CODE:
#!/usr/bin/perl
# Takes a logfile of lrexec output and splits it into individual logfiles, one per user.
# To use it, run it from cron as 'split_lrexec.pl /var/log/lrexec.log'
# See http://garage.freebsd.pl/lrexec.README for more info about lrexec
# Sample log line:
#Mar 18 02:21:00 users /kernel: lrexec: sh(/bin/sh) [login=hangchen pid=27220
# ruid=1046 euid=1046 groups=1046,1046,999] ->
# eggdrop-1.6.12(/home/hangchen/moppie1/eggdrop-1.6.12) [args: "./eggdrop" "m1.conf"]
# $logdir is the directory under which all user logs will be saved:
$logdir="/var/log/users";
# create $logdir if not already existing:
mkdir $logdir if ( ! -d $logdir );
# loop through each log line:
while(<>){
# find which user this line refers to:
/login=(.*?) /;
# append this logline to this user's log entries:
$users{$1} .= $_;
}
# now loop through each user and print all their log entries to an individual
# logfile:
foreach $user (keys %users) {
# this could be more sophisticated, for example using $logdir/$ymd/$user,
# where $ymd is "<year>/<month>/<day>":
open (FD, ">$logdir/$user");
print FD $users{$user};
close FD;
}
Download the script here:
split_lrexec.pl
Just read an interesting article about the addition of 'Security Event Auditing' in FreeBSD 6.2. Until now FreeBSD hasn't had any really useful security auditing other than using 'accounting' to log all syscalls which at best was confusing when it came
Tracked: Nov 14, 16:48