On Tue, 29 Jul 1997, Robert Watson wrote:

=)On Mon, 28 Jul 1997, Vincent Poy wrote: =) =)> On Mon, 28 Jul 1997, Brian Buchanan wrote: =)> =)> =)Uh, that would defeat the purpose of securelevel. It's not supposed to be =)> =)possible to ever lower it, except when dropping into single-user mode, and =)> =)even allowing init to do so in that instance is risky IMHO - a few months =)> =)ago I reported a hole, which I believe was fixed, that made it possible to =)> =)lower the securelevel by attaching a debugger to init. Even though that's =)> =)plugged now, it's still possible that there's another way to fool the =)> =)kernel into thinking that process 1 is requesting that securelevel be =)> =)lowered. =)> =)> Anything is possible since nothing is unhackable. Would running =)> init at securelevel 2 and then have it reboot multi-user at a lower level =)> be possible? =) =)I disagree with the assertation that nothing is unhackable. My toaster is =)unhackable. :) Depending on how you define hack, of course. But in a =)similar vein: you say you have been carefully following the latest version =)releases, and patching all known bugs. That is not sufficient. A site =)needs a good security policy as well as patching known bugs. For example, =)you should have been using ssh the entire time, and have copied the public =)keys for the hosts to your client machine using sneaker-net. Sending any =)unencrypted data to/from a host, especially sensitive information like the =)root password, is an extremely bad idea.

You would think your toaster is unhackable. So is a Leica camera lens but they still have ways to hack it. Also, just for your information, the root password isn't even used that often. It is only used every time the machine boots up since I run screen and I am connected 24 x7 and reattach the screen session when necessary.

=)Similarly, careful analysis of the trust relationships between the =)machines and accounts on the machines is important -- constructing a bad =)DNS structure can invalidate your whole security design, as if DNS is =)corrupted, all the .rhosts stuff is vulnerable. Ideally, you would only =)use .rhosts in combination with SSH, and then make sure that the =)appropriate keys are in /etc/ssh_whatever, and deny connections that did =)not match the predefined keys of all hosts. Key distribution is one of =)the big downsides to SSH, but floppy disks can help here.

I was considering installing ssh but there is only one problem. I use Win95 from my own side at times for various reasons as well as the other remote admins. So a ssh client does cost money. We're volunteers and are not getting paid in any shape or form.

=)Applications like web servers may themselves represent no immediate or =)known security problems, but often-times web servers use third party CGI =)programs, available publicly in source, or written by a third party for =)the web server. Many web programs are notoriously sloppy (or ignorant), =)and this has not been helped by the release of a number of CGI programming =)books that haven't even touched on the issue of security. It has been =)shown time and time again that greater access for an attacker increases =)risk, and most CGI bugs allow shell access to the host, albeit as www or =)nobody. Even those are problematic. And once someone is in to the =)system, they can get around simple solutions like disabling inetd. In 15 =)seconds, I can compile and run a daemon that lets me back into an account =)on a higher port number, and unless you know your tools are good, and how =)to use them, you won't be able to tell. I certainly won't appear in the =)logs. :)

That's true but I am logged on 10 times also and you would only see me logged in for once idled 4 days when I wasn't even idle for 2 seconds. Those aren't in the logs either. That's why when this hacker was talking to jbhunt, he deleted netstat but I managed to get it from another machine and tracked him down and killed his connection. jbhunt was running a portscanner to check for any daemons running on a higher port number but didn't find any.

=)In the case of someone else's machine, you probably can't do anything to =)get rid of the CGI problems, so that really leaves you with just =)minimizing the risks in the OS. You've already touched on SUID programs =)-- as many as possible should be disabled. If you have console access, =)just disable root also, as you can login as root directly. Most programs =)do not require suid, if you don't mind administrating as root. Su'ing to =)root is clearly a risky activity, especially if you're logged in =)unencrypted. Setting a high secure-level, as well as mounting all file =)systems w/o setuid support, can make a big difference. Mount all file =)systems but root as nodev, and things should move along some also.

True but the problem is we wished we had console access. If we did, none of this would even happened I think.

Cheers, Vince - vin...@MCESTATE.COM - vin...@GAIANET.NET ________ __ ____ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M & C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[____]