Date: Thu, 05 Oct 2000 09:12:05 -0500 From: Carroll Kong <damascus@home.com> To: dima@unixfreak.org, "Jeffrey J. Mountin" <jeff-ml@mountin.net> Cc: Dima Dorfman <dima@unixfreak.org>, security@FreeBSD.ORG Subject: Re: BSD chpass (fwd) Message-ID: <4.2.2.20001005090906.0639d560@email.eden.rutgers.edu> In-Reply-To: <20001005002410.309DF1F0A@static.unixfreak.org> References: <4.3.2.20001004173510.00afd880@207.227.119.2>
next in thread | previous in thread | raw e-mail | index | archive | help
At 05:24 PM 10/4/00 -0700, Dima Dorfman wrote: > > At 03:08 AM 10/4/00 -0700, Dima Dorfman wrote: > > > > >IMO, the bottom line is, schg can only prevent an attacker if they > > >don't have a good understanding of the system (which accounts for most > > >of the script kid population). A really clever attacker would modify > > >your securelevel settings in rc.conf, reboot the machine making it > > >look like a panic or power surge (if they know you exclusivly access > > >it remotly), fool around, then change it back. Tripwire on a r/o disk > > >would tell you about it, but you can't do that remotly unless you plan > > >on never touching any system binaries. Or am I missing something? > > > > And why wouldn't you protect /etc as well. Then one would rely on > physical > > security to change the security settings. A real PITA for remote systems, > > but even that could be worked around with some care to allow changes > > (reboot still required) and protect the system. > >You could, but your system would become almost unmanagable. Relying >on going to single user mode to do basic maintenance (say you had >fingerd on in inetd, but now you want to turn it off in light of the >recent hole) isn't such a good idea. > >In my experience, if doing something is a big hassle, it generally >doesn't get done. Say someone discovers a small local DoS in some >serivce you're running. Assuming nobody untrusted has an account, a >local DoS isn't such a big threat. Since you have to physically walk >to the machine, boot it to single user mode (causing minor downtime), >and change it, you'd probably decide to leave it alone. After a while >it builds up, and your machine slowly deteriorates(sp?). And if you >ever can't get to the machine and there's a serious remote hole, >you're in trouble. <SNIP> >Regards > >-- >Dima Dorfman <dima@unixfreak.org> >Finger dima@unixfreak.org for my public PGP key. Not sure if this is just extending the problem, but if it is going to be a reboot box, why not create a special freebsd box that uses an octopus 8-serial port card (for multiple machines) and null modem cables to hook into these "secured" boxes. Naturally we would have to treat this box as a hardened box as well. (running only sshd and firewalled and cannot accept console logging requests). I have heard (ok, sorry I did not test it yet), that the Boot Loader will automatically call up the serial port -> console drivers. So this way you COULD call a reboot and go into single user mode from your special freebsd console box by using minicom! If the most part of the annoyance is physical access, it is somewhat eliminated by my console idea. Passwords would be secured over the serial port (clear text, but no where to broadcast to), unless someone was physically tapping, but if he got that far to tap, you are dead meat anyway. I should get a null modem in my house to test for the "bootloader showing up in console" bit. If you REALLY want full console access like to the BIOS, there is the netweasel. So what do you think? Please respond if there are any flaws in this idea? -Carroll Kong 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?4.2.2.20001005090906.0639d560>