I agree with Mr. Ball.  Having service settings on the master disk replicated 
to clones creates a single point of compromise in all of the machines.  I would 
recommend eliminating service settings from the master copy and replacing 
scripts to generate the settings info from a trusted source (new keygens for 
every server and sshd settings from a trusted source, for instance).  This will 
accomplish three goals:


1) Servers that don't run SSH won't have the configs to make it happen.  Thus 
SSH won't start and will not be a service available for attack.  This meets the 
'least services' principle.


2) For servers that do run SSH, the scripts will gather common config data from 
a trusted source, maintaining consistency.  This allows the SSH service to be 
maintainable on individual servers across a large farm.


3) The SSH setup scripts should then fork off to generate their own keysets.  
This creates an additional layer to penetrate for each server and eliminates 
the common point of failure issue.  This limits the common vulnerabilities to 
application/protocol level attacks.  These are addressed by a patching/maint 
infrastructure or process, which hopefully is already set up.

Reply via email to