Date: Thu, 7 Feb 2002 11:39:05 +1100 From: Greg Lane <gregory.lane@anu.edu.au> To: Weldon S Godfrey 3 <weldon@excelsus.com> Cc: Brett Glass <brett@lariat.org>, Trevor Johnson <trevor@jpj.net>, Victor Grey <victor@customdynamic.net>, freebsd-security@FreeBSD.ORG Subject: Re: Is this evidence of a break-in attempt? Message-ID: <20020207113905.A31674@nucl03.anu.edu.au> In-Reply-To: <Pine.BSF.4.44.0202061105140.56746-100000@joule.excelsus.com>; from weldon@excelsus.com on Wed, Feb 06, 2002 at 11:12:02AM -0500 References: <20020207024804.A28463@nucl03.anu.edu.au> <Pine.BSF.4.44.0202061105140.56746-100000@joule.excelsus.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I absolutely agree. Security in layers... I was not being critical, note the "as you no doubt know". I was only pointing out for the unititiated security-wise that this is not enough, as you point out also. If I have a publically accessible box, I mark everything insecure in /etc/ttys and usually go the whole hog, disconnecting the floppy and the cdrom, changing the boot order in the bios in case they do reconnect them, then password protect the bios. It only takes a minute or two to reverse if I ever need access, but will take quite a bit longer if you have to defeat each thing one at a time as you find it. I usually set some flags (like schg) on important files as well. If someone gets through that, they generally have enough knowledge that I'm screwed anyway. At that point as Trevor Johnson mentioned, encryption is your friend. Even then, however, you have to get some sort of key to the box to read the encrypted files and if someone has root already... In case you haven't noticed already, I am somewhat paranoid. I don't think I'd ever be able to trust a colocated box. Greg On Wed, Feb 06, 2002 at 11:12:02AM -0500, Weldon S Godfrey 3 <weldon@excelsus.com> wrote: > > But isn't slowing down the name of the game? If someone is good enough > and they want to break in bad enough, they are going to get in. Nothing > replaces consistent security monitoring and investigation. > > The more hoops you put up, the greater the likelihood you will be able to > catch it, stop it before it goes too far, or discourage them, > and/or circumvent the less knowledgeable (which accounts for more attempts > than the knowledgeable). > > It is the same as your car and house. If a thief is bold enough, no > matter how many alarms you have, that won't stop them. It doesn't mean > you should give up and leave keys in the ignition :) > > If memory serves me right, sometime around Tomorrow, Greg Lane told me: > > > > I recommend that any box placed into a colo or a location that the > > > security isn't under your direct control to mark your console as > > > "insecure" in /etc/ttys so that root password will be asked when someone > > > boots into single user mode. > > > > > > Weldon > > > > It will slow someone down, but as you no doubt know, if a box is not under > > your direct control and someone has a clue then that doesn't help much. All > > it takes is the fixit floppy. Mount / and /usr, edit the passwd file, > > pwd_mkdb, instant root. > > > > We've had to do this to an embarrassingly large number of boxes where > > we've forgotten the root passwords. > > > > Bios passwords, disabled floppy drives and other tricks might slow you > > down, but in the end, physical access to the box and the game is > > pretty much already over... > > > > Greg > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message -- ================================================================== Dept of Nuclear Physics Email: Gregory.Lane@anu.edu.au Australian National University Phone: +61-2-6125 0375 Canberra ACT 0200 AUSTRALIA Fax: +61-2-6125 0748 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020207113905.A31674>