Igor Sobrado wrote:
> Hi again.
>
> Out of this thread, Mr. Tongson pointed me to an interesting post
> from march 2005:
>
> http://archives.neohapsis.com/archives/openbsd/2005-03/2808.html
i.e., DROP IT. IT WILL NOT CHANGE. The guy in charge has spoken.
> From this post, it is difficult understanding why disabling remote
> root logins is not a good idea; but after reading the entire thread
> I see the point, though: disabling remote root logins make things
> a bit harder for an intruder, but not impossible at all. I agree
> with the idea on the thread but we must consider that:
>
> 1. Allowing remote root logins by default effectively destroys
> the security layer created by the wheel group. Even if an
> attacker is able to get a copy of the root password (something
> that cannot be underestimated for an internal employee) he
> must be in the right group or get a second password, this time
> one of a user in the wheel group.
or skip the root PW, and just get the wheel user.
That's no layer, that's a coat of stain. Pretty color, but offers no
protection.
> 2. There are a lot of brute force attacks from countries like
> Korea these days. These attacks will be less effective if
> the intruders get access to an unprivileged account (even if
> it is in the wheel group).
how's that? If the user is running sudo to allow people in the wheel
group full access (common config), when they are in wheel, they are
seven keystrokes away from root ("sudo -s")
> 3. An Unix and Unix-like system has a root account. The names
> of other accounts are difficult to guess (my account at
> string1 is guessable right now, but I can be using a mail
> alias or receiving email on a system that has no real user
> accounts). Trying brute force attacks against the root
> account is probably the best guess for an intruder.
yawn.
If your system is subject to brute-force attacks, it is subject to
brute-force attacks.
Hiding the vulnerability and calling it an improvement is just pathetic.
My favorite analogy is moving the front door of your house to the side
and painting it purple so that thieves won't be able to find it in the
usual place and color, so they won't be able to pick your sub-standard
lock. It only shows the very low level of skill on the 'net (for both
the bad guys and the good guys!) that this is actually considered a
"security measure", and could actually has some impact on the number of
boxes taken over.
Only a fool assumes their opponent is a fool. Maybe your opponent IS a
fool, but it is much safer and much more productive to assume (s)he is
at least as skilled as you, and knows all about your system.
Be worried about the skilled people who have financial motivation to get
into your systems, who will recognize a door of a different color and
location than they expected. Stop those people, the fools will be taken
care of, too.
> I must admit I did not know about that thread before Mr. Tongson
> sent me an email, and I would probably have not sent my first email
> in the case I were aware of the existence of the thread of march,
> 2005.
Hello, google!
You win no prize by thinking you are more skilled and more knowledgeable
than the people who have demonstrated they know how to build a secure
OS, or that you have come up with a brilliant idea that no one has ever
thought of before.
Posts can be offensive and not contain a single unpleasant word.
> But I think that I am right about remote root login enabled
> by default weaknessing other security schemes (like the wheel group)
> provided by the BSD systems.
And people who have demonstrated they understand REAL security think you
are not right.
...
> I admit that not allowing remote root logins is an imperfect security
> measure,
it is mostly a "Look, I did something! Isn't that great?". That's a
popular attitude, like those who put untested RAID systems on their
machines and say, "hey, now it will never go down!" but OpenBSD
developers are much more into doing things that really matter.
Personally, I just do this:
After install, I configure sudo, create my administrative user(s), and
then I log in as one of those users, and verify they have administrative
rights by altering the hash of root's pw in such a way that the root
account will not be usable for direct logins again. Local, ssh,
whatever -- no one will directly log in as root.
I do this not to "protect" myself against people who shouldn't be able
to guess my password anyway, but to limit the number of unused accounts
with administrative access that are on the box. It also makes it easy
to ensure that there are multiple capable administrators in business
systems that should not be vulnerable to the availability of one person,
and it also makes it easy to "change" administrators when it is needed.
If this is an option you want, fine, put it in an install.site file in a
siteXX.tgz file, and it will Just Happen when you do your install. But
don't advocate the crippling of systems in ways that don't change the
real security picture in the name of Just Doing Something about security.
Nick.
