* Juha J?ykk? (juolja@utu.fi) [011019 07:57]:
> 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.
Check out the command="" option in the authorized_keys{2,} file. This
info is given in sshd(8). This will allow you to connect with a certain
key and execute a certain command, and no more. This means that even if
someone does steal your unencrypted key somehow, the worst they can do
is run your update script -- never get a login shell. This also saves
you from having to type your sudo password for this purpose, and from
having to keep any suid binaries on your system. Make sure you also set
"PermitRootLogin=forced-commands-only" in sshd_config. This feature is
very useful for exactly this sort of purpose, when you need a
{semi-,}automated process to run for updates, backups, etc.
I also recommend you use a from="" option in the authorized_keys2 file,
as this will require not only retrieval of the secret key, but also
breaking the nameserver/router to spoof the source address (or that the
attacker tries to connect from your admin console). Most likely, someone
trying to abuse your secret key will have gotten your key from the admin
console and will try to abuse it from elsewhere. USe logwatch or
something similar on the target machines to throw up Red Flags if anyone
tries to connect as root from anywhere else.
For added security: no-port-forwarding, no-X11-forwarding,
no-agent-forwarding, and (assuming your script can get away with it)
no-pty.
> 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.
This is difficult, especially if you use a very difficult passphrase!
> 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.
If this is a concern, don't use ssh-agent. Also, With the setup I
suggest, even compromising this key only gives the attacker the ability
to run your update script; nothing more. I'd be worried more about him
exploiting the target machines in the same way your admin console was
compromised, since, in theory, the admin console should be the most
difficult to crack!
> 3. Break into one of the other machines, use the suided script to
> trojan the system and propagate to the other machines that way.
I suggest tripwire to help manage the risk of the update script on the
target machines being trojaned/replaced.
good times,
--
Vineet http://www.anti-dmca.org
Unauthorized use of this .sig may constitute violation of US law.
echo Qba\'g gernq ba zr\! |tr 'a-zA-Z' 'n-za-mN-ZA-M'
Attachment:
pgpI97kqzkC8V.pgp
Description: PGP signature