From owner-freebsd-security@FreeBSD.ORG Tue Jul 29 16:45:04 2003 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3E24D37B401 for ; Tue, 29 Jul 2003 16:45:04 -0700 (PDT) Received: from cicero2.cybercity.dk (cicero2.cybercity.dk [212.242.40.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4BFC943F85 for ; Tue, 29 Jul 2003 16:45:03 -0700 (PDT) (envelope-from db@traceroute.dk) Received: from user3.cybercity.dk (fxp0.user3.ip.cybercity.dk [212.242.41.36]) by cicero2.cybercity.dk (Postfix) with ESMTP id C469818F64C; Wed, 30 Jul 2003 01:45:00 +0200 (CEST) Received: from main (port132.ds1-arsy.adsl.cybercity.dk [212.242.239.73]) by user3.cybercity.dk (Postfix) with SMTP id B36E193C11; Wed, 30 Jul 2003 01:44:59 +0200 (CEST) Date: Wed, 30 Jul 2003 01:54:31 +0200 From: Socketd To: , security@freebsd.org Message-Id: <20030730015431.4120c648.db@traceroute.dk> In-Reply-To: References: <20030727155239.3205a60b.db@traceroute.dk> X-Mailer: Sylpheed version 0.8.10claws (GTK+ 1.2.10; i386-portbld-freebsd4.8) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: suid bit files + securing FreeBSD (new program: LockDown) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2003 23:45:04 -0000 On Tue, 29 Jul 2003 16:53:17 -0500 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