also sprach Adam Warner <lists@consulting.net.nz> [2002.01.21.1444 +0100]:
> Martin, it's a server in my spare room :-) The only person installing a
> backdoor on the server would be an unlawful intruder. Or a cat who can
> type ;-) Your points are well taken and I would follow the same security
> practices as you.
as sad as it sounds, unlawful intruders happen. this being a true story,
i have 11 machines in my spare room, and my house was broken in once.
the *only* thing the intruder did was reboot one of the machines (that
was his mistake) and install a backdoor via init=/bin/sh at the boot
prompt. my logs screamed (i have redundant logging), i found the
backdoor, had a honeypot on, and didn't have to wait 3 hours for the
intruder to try to login. he didn't have to wait 3 hours for the police
to show up.
> Martin, I'm only an individual writing from one of my "servers". And if
> I can save resources by using a server for a workstation as well I think
> that's OK.
okay. but your "server" has a permanent internet connection, and though
you might not have mission-critical and confidential data, it is a prime
target for hackers because of distributed denial of service attacks. so
it needs to be secured, and you are on track.
what's your server serving?
> > i don't have the time to research and present an escalation exploit at
> > this moment, but i do want you to accept one point, which in itself will
> > already flaw your approach of handling login and usage of the
> > workstation. YOU DON'T LOGIN AS ROOT. period. it's a security matter and
> > it's an accounting thing. there's a reason why the group "wheel" exists
> > on traditional UNIX systems (*why* does Linux *not* have it); noone
> > without a local account should be allowed root, and it's good to know
> > who became root when; to become root, you have to know two passwords
> > *and* an account name.
>
> I do not see that there is any significant security issue in logging in
> as root from a LOCAL console.
it depends on the environment, how many admins there are, and the
physical security around you. with several tens of admins, it's
important to keep track of every usage of root privileges with names and
outside of those admins' control.
> > you have it backwards. usually, you login as user and su to root.
> > logging in as root and su'ing to a user is the wrong way around. i even
> > think it's wrong to allow password-less su and suggest to disable it.
>
> Whenever I use a remote login procedure like SSH I log in as a user and
> then su to root when necessary.
good.
> Since you "even think it's wrong to allow password-less su and suggest
> to disable it" you're really going to like trying to refute this
> "heretical" scenario I created:
why post it then?
> This indicates to me that the increased risks of using su - to log in as
> a user may be offset by the decreased risks of a superior user password
> that you actually have to write down and consult to remember.
there's no excuse. enforce strong passwords. period. libpam-cracklib for
a start, regular password cracking by john, account expiration etc.
--
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:"; net@madduck
"it is the mark of an educated mind
to be able to entertain a thought
without accepting it."
-- aristoteles
Attachment:
pgpjhO9wZNHMi.pgp
Description: PGP signature