Re: central administration techniques
On Fri, Oct 19, 2001 at 05:54:28PM +0300, Juha J?ykk? wrote:
> I was wondering if there are any secure methods of centrally
> managing the versions of certain files on Debian machines. I currently
> have a woody, two sids and several potatos which need to be kept up to
> date. The security patches are not much of a concern since they are
> quite infrequent (except for woody and sid where I do not discriminate
> between security, bug and other fixes) but certain configuration files
> change often, like the files /etc/ssh/ssh_known_hosts*.
> Every time a new host is added into the network, I need to add its
> host key into the others' known_hosts and copy the all default
> configuration files into the new host as well. There are quite a few
> of these that are easily forgotten. Forgetting to copy some files
> like /etc/printcap is soon noticed and fixed, no harm done, but files
> like /etc/pam.d/* are not. And results in decreased security!
> I am now considering different possibilities of doing these updates
> by simply saying "update-debian-machines" on one of the computers. It
> would require some shell scripts and asking the relevant passwords it
> would keep me waiting at my console. I do circumvent the login
> passwords with ssh/DSA auth, but resenting root logins over the net, I
> would still need to type sudo's passwords.
> Now, is there a package to do this or which could be easily
> converted to do this? Otherwise I will fall back to scripting. In that
maybe have a look at cfengine?
or apt-cache search / freshmeat / google for other options
> case, which is the safest option? Currently I am considering
> configuring sudo to enable the admin user to execute a single script
> (mods 0700) without a password or just chmod that script 4700. I am not
> certain about the first, but the latter would be as secure as my
> connection (ssh2) and my real password. The real password being broken
> would mean unlimited access to sudo (it is the admin, after all) so I
> am not worried by that part. Also, the ssh connection part worries me
> a little: I would basically be giving root access to all our machines
> to anyone who can steal/spoof/abuse my ssh private key.
> I can think of three scenarios to compromise the network:
> 1. To break into my admin console, so as to get my DSA private
> key (mod 0600) and break its passphrase.
AFAIK, breaking the passphrase is really difficult, with these ~1024bit
RSA/DSA keys.
> 2. To break into my admin machine (Getting on any machine would not do
> - the DSA key only exists on one, so the cracker would need to break
> into my admin console.) and steal my DSA key while it is being used.
> Ssh-agent keeps the key (or does it keep the passphrase?
> in this case it does not matter) in memory so this should be possible
> at least for root on a machine with /dev/mem.
Use a separate DSA key, and don't add that to ssh-agent, just type your
passphrase every time (they could still trojan your ssh, but hey, the
could also install a keyboard logger to sniff passwords then)
BTW: ssh-agent keeps the decrypted private key (private key decrypted
using the passphrase).
Be sure to use strict host key checking, and _never_ agree with an
unexpected host key change.
> 3. Break into one of the other machines, use the suided script to
> trojan the system and propagate to the other machines that way.
> The last one might prove difficult: the admin user on
> non-admin-console machines does not have any DSA keys used for
> password-less authentication - so this basically means breaking into a
> single machine which I am not concerned of here. Breaking into a single
> machine should be about equally difficult for all machines, since I
> doubt my little scheme would be the weakest link in security. The only
> problem I can see is in 1. and 2. - could the DSA key be abused to
> automatically root all the machines?
> Ideas?
Be sure to * out the password of admin, so it can _only_ login via DSA
keys.
IMHO, it's more difficult to steal a private DSA key _and_ the
passphrase (as long as you don't use ssh-agent), than to steal a
password (DSA keys are less sensitive for social engineering and stuff).
You should really close _all_ incoming ports on your admin machine, including
ssh. Then it will be quite difficult to break in as long as they don't
have physical access).
Just be sure your admin console is as secure as possible, don't run any
foreign programs, etc. As long as they don't break root on your admin
box, and you don't run anything unecessary under the admin account, i.e.
no games and other 'funny' programs, I don't think the security will be
weakened. They can of course still break root on a server if it runs a
vulnarable daemon (if you're paranoid, read bugtraq & friends, since
debian security advisories are sometimes issued a short time after
it was reported on bugtraq.
The FreeBSD security manpage:
http://www.freebsd.org/cgi/man.cgi?query=security&apropos=0&sektion=0&manpath=FreeBSD+5.0-current&format=html
contains some useful info that applies to Debian too.
HTH,
Alson
--
,-------------------------------------------.
> Name: Alson van der Meulen <
> Personal: alson@flutnet.org <
> School: alson@gymnasiumleiden.nl <
`-------------------------------------------'
What do you mean that wasn't a copy?
---------------------------------------------
Reply to: