On Mon, Dec 20, 2004 at 10:13:58PM +0000, Steve Kemp wrote:
On Mon, Dec 20, 2004 at 10:45:55AM -0800, Raymond Lillard wrote:
This should fail for at least these reasons:
1. "ssh" should be configured to prohibit root logins
Reinforce and strengthen... "ssh" should always be configured
to prohibit root logins.
Sometimes not an option. It's useful to backup machines
with rsync, or push updates out as root. Having a different
named account but still with UID isn't gaining much.
Always an option. If you don't think it's an option, then
you aren't thinking about it very intently or very clearly.
Backups? No problem. Simple user id that is permitted one
command that does a "sudo" for the server side of the backup. Two layers
of protection. You only allow that specific "sudo backup_command" on
connection (which you can do in the ssh configuration) AND you only
allow "backup_command" in sudoers for that user id. Problem solved.
Works great with rsync.
I'm not sure what you mean by "Having a different named account
but still with UID isn't gaining much". Did you mean "with UID 0"?
Then I agree. That's bad practice. Have a named account with a simple
UID and restrict the commands it can execute to only those commands you
want for that account, which can include "sudo" accounts to provide the
root access you need. Obviously pay attention to any application with
shell escapes. :-(
It may still be challenging to insure that the "rsync" is a backup
direction and not a "restore" direction which can overwrite your config
files, but it's still a barrier for the ankle bitters that are doing
this kind of scanning. A little scripting goes a lllooonnnggg way here.
"Pushing updates out as root" should be similarly marshalled but
presents more challenge because you are performing updates to the system.
Why not configure a "yum" repository back to your own site (and only your
site) and then only allow that "update" to do a "yum update". That way
you initiate the request but the remote system is still limited to where
those updates can come from. You don't need arbitrary or summary update
capability over that direct channel. There are much better ways to do it.
(Apt-get for the debian-heads in the audience).
2. All machines should be configured to prohibit
direct root logins except on the physical console
That seems a bit excessive. I usually setup controls by
IP address in /etc/hosts.allow, and /etc/hosts.deny. Then
limit incoming SSH connections via something like:
Nope... With sudo available to you, the only time you should
ever need a direct root login is for maintenance when you can't even
reach multiuser mode. My biggest problem is that, after a few years
(NO JOKE HERE), I forget what the root password is when I run into an
fsck unexpected error and I HAVE to have the root password.
AllowUsers skx mp3 foo bar ...
That way even if there is a user called 'test' with
password 'test' (Extremely unlikely!) they cannot login.
3. Proper attention to passwords
Agreed. Backup with `john the ripper` if you don't think that
your users are following whatever password policy you have in
place.
Yes. John the Ripper and Crack are your friends. As are
cracklib in PAM. Turn on and enforce good password complexity checking.
This is currently a soapbox for me as we are about to burn someone
at the stake at my office for failing to conform to the above guidelines.
If he survives, he won't be making that mistake again!
Steve
--
# Debian System Administration
www.debian-administration.org/
Another option... I prohibit all outside network access to
ssh over IPv4. Since all IPv4 addresses have entire IPv6 networks assigned
to them, you can always use 6to4 except over NAT (just don't use the
default EUI of ::1 - bad choice there). If you have to deal with NAT,
Freenet6 and SixXS both have clients that work over NAT. I have yet
to find anywhere in the world where I could not get back to my IPv6
access points and they can not be scanned for. Even ICMP "unreachables"
come back from false addresses so they can't even be scanned for error
return addresses. Some of them change their IPv6 address every 15 minutes
and update DNS using TSIG signed dynamic updates (zone transfers are
blocked). There is no where on IPv4 where you can stop IPv6 (Teredo
rolls over firewalls like they weren't even there) so my access
is better, more reliable, and more secure, over IPv6 than it ever
was on IPv4.
Mike
--
Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com
/\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!
pgpPfe8WnGsHM.pgp
Description: PGP signature
