Date: Wed, 30 Jul 2003 01:54:31 +0200 From: Socketd <db@traceroute.dk> To: <lee@critesclan.com>, security@freebsd.org Subject: Re: suid bit files + securing FreeBSD (new program: LockDown) Message-ID: <20030730015431.4120c648.db@traceroute.dk> In-Reply-To: <HCEOIHDIFOIIAGKAGBCHEEHOCMAA.lee@critesclan.com> References: <20030727155239.3205a60b.db@traceroute.dk> <HCEOIHDIFOIIAGKAGBCHEEHOCMAA.lee@critesclan.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 29 Jul 2003 16:53:17 -0500 <lee@critesclan.com> wrote: > I might be willing to tinker with a lockdown type shell script to > handle that part of it. > > Another thing: the script/program/process/whatever could send an email > to root with a list of the files it found which had improper settings. > List the ones without the suid/sgid bit which were changed, and list > the ones with them which were changed. That would cover the > possibility of a port being installed and having him forget to add it > into the list - this would serve as a reminder to actually stick it > in. Yes, if LockDown finds suid/gid files not listed in the conf file, the admin should get a message/mail. > Also: perhaps those found with the bits set which were not listed as > being allowed could be moved into an obscure subdirectory, sort of the > way the PC virus protection programs do. Not only would it not have > the bits set, but it would be gone. Then the next time the process > runs, if it finds the program out there again, it might assume an > attack of some type and send warning emails stating that is the case. > > And: Since this is a security thing, perhaps we could have a separate > daemon which checks the conf file and program periodically, reporting > to root when/if either changes. If the conf file changes, then an > email might be okay. If the program changes, depending upon some > security setting, you might just send an email and you might shut down > the network interfaces or some such thing. > > Perhaps a makefile for the port could update the system so if you > installed a new version then this panic attack wouldn't happen. > > And, optionally, you could let the new unauthorized version sit for a > short while, then replace it with the last known good version and run > it. Thus if someone hacked the system and noticed the lockdown program > and made changes to the conf file, root would be notified of the conf > file change by the daemon. But then if they wanted to hack the > lockfile script itself, then root would get a message showing the > diffs and, say, 5 minutes later, the last known good version would be > put back and run - with, perhaps, the last known good version of the > conf file being used as well. That would lock out the hacker and he > wouldn't even know why or how - and would assume the sysadmin caught > him. Make sense? > > Just some ramblings that you might think about... Well again I have to say that LockDown was not meant to be an IDS. If you want a program to monitor suid files, tripwire is good. Anyway, having a daemons keeping an eye on the system is a good idea, but an attacker with root powers could just kill the process and install a rootkit. If you want a program to detect rootkits we have /usr/ports/security/chkrootkit. br socketd
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030730015431.4120c648.db>