Date: Sat, 18 Dec 2004 11:08:34 -0500 From: Bill Vermillion <bv@wjv.com> To: freebsd-security@freebsd.org Subject: Re: Strange command histories in hacked shell history Message-ID: <20041218160834.GA76897@wjv.com> In-Reply-To: <20041218120130.C67DC16A4D1@hub.freebsd.org> References: <20041218120130.C67DC16A4D1@hub.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Let me just comment on two items that are in the thread which I seem to have caused to get a bit long. On Sat, Dec 18, 2004 at 12:01 , while impersonating an expert on the internet, freebsd-security-request@freebsd.org sent this to stdout: > ------------------------------ > Message: 4 > Date: Fri, 17 Dec 2004 10:51:35 -0500 (EST) > From: "Jerry Bell" <jerry@syslog.org> > Subject: re: Strange command histories in hacked shell server > Did I understand correctly, that anyone can connect to the shell server > and create an account for themselves? > I have a somewhat rudimentry hardening guide for FreeBSD at > http://www.syslog.org/Content-5-4.phtml > I've tried to keep it up-to-date, but I have yet to incorporate > IMAC, which think will help out a good bit more. > I hope you find this a useful. I do agree with that, espeically the first paragraph " ... no matter how paranoid your philsophy ..." I have had one instance of an attempt was I had missed one machine out of about 8 applying one security patch. All were patched within hours, the one that got hit was 2 days later. You have to get to any patches as soon as the hole becomes known. And my machines are pretty accessable to the world being on a backbone. One machine was getting about 300,000 spams/day until I finally took off all MX for that domain. If anyone has problems they need to perform a whois and use those contacts. It's one of those domains whose name alone drives it up the list. I haven't set the security levels high as that means that any problems would require driving to the colo - and that's about 1/2 hour at 3AM - and two to three times higher during the daylight hours. ... > Message: 9 > Date: Fri, 17 Dec 2004 22:13:47 -0600 > From: Elvedin Trnjanin <mnsan11@earthlink.net> And Elvedin wrote in reply to my post where I wrote: > >This means that the 'wheel' security really is nothing more > >than a 2 password method to get to root. > Precisely. If you don't like this then the way around is to only > allow a certain group access to su and none for everyone else. That thought had not crossed my mind. Craig also mentinoed that. [his comment follows]. > >If the EUID of the orignal invoker is checked, even if they su'ed > >to a person in wheel, then they should not be able to su to root. > >I'm asking why is this permitted, or alternatively why is putting a > >user in the wheel group supposed to make things secure, when in > >reality it just makes it seem more secure - as there is only one > >more password to crack. > One more password to crack is more time which means a better > chance of catching the cracker in the act. Although I don't know > why exactly the authors of su did that the way they did but my > first and best guess would be convenience. The two password > method is better than a new login session each time you want > to get to root. Second best guess would be is that they didn't > figure out that issue or at least think much of it. One more password to hack does make it harder, but in a paranoid mode if someone did break a password of a wheel user, then they have a root password to break. I'd just as soon them not have that ability at all. I'm concerned about some application turning out to have an unknown hole and someone wandering around before they are found. It seems there are tons of attempts on sshd logins in the past few months, but I'm thinking that if some app breaks then that person could perhaps su to a local person that is in wheel. Your idea of changing su to be only executeable root and user in group wheel may be just what I need. I may be overly paranoid, but in this day and age you can't be too secure. The one penetration that I had three years ago on one non-critical machine was one more than I'd have like to have had. There are a total of 4 people who have wheel accounts, and one person has a set of sudo command so he can edit his own private set of sendmail aliases, primarly for a large mailing list he maintains, but other than that it's locked down pretty well. As above I'm concerned about some unknown hole in an app giving someone a chance locally. > ------------------------------ > Message: 12 > Date: Sat, 18 Dec 2004 11:45:45 +0000 > From: Craig Edwards <brain@winbot.co.uk> > You could change the permissions on the su binary, so that only > users in the wheel group can even execute su. that way, when a > non-wheel user attempts to su to a user in the wheel group, they > simply get permission denied. That's one that had not crossed my mind. I will probably do that. > The idea of chmod'ing your suid binaries is always good in my > opinion, and will stop this from happening simply and easily > without having to change any code. Which is very good. The fewer things modified the fewer things to get missed on system upgrades. Thanks to all who responded. Now my only unanswered question has to do with why su was designed like this originally. Those reasons are probably lost somewhere in history. But now I can ease some of my paranoic worries at least by changing su. Bill -- Bill Vermillion - bv @ wjv . com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041218160834.GA76897>