[CentOS] securing a remotely hosted machine

[Brunner, Brian T.]

> > 3: When you first build the system, ghost/image the boot/root/usr 
> > (bru) drive onto a spare backup, verify the backup boots 
> > the machine the same as the main drive.
> > 4: have the backup bru drive mailed to you, dupe it, and rsync the 
> > remote bru to your local copy whenever you make a change to 
> > the remote bru.
> 
> This part tends to be problematic when the system is remote 
> and you need hands-on access for the install.  It would be 
> much nicer to build locally and ship the initial drives.

Build-local-and-ship > build-remote! Agreed!  I'm not assuming the 
remote personnel are competent in Linux.  I think you are.  I suggest 
that "remote hosting security" howtos address the question of 
"what can we trust the remote people to do right?"  We had one where 
the only thing we could trust the remote folks to do was cash a check.

My comments were thinking "if you don't own the remote server hardware 
but can own/update identical disk drives"

> > 5: In the event of fire, vandalism, or other urgent cause, your 
> > cluster can appear on a new server rapidly.  Just FedEx 
> > ghosts of your locally stored bru drive rsynced from what were your 
> > remote machines, and (on similar hardware) they should turn-key boot
and run.
> 
> Try it - you won't like it.  If the MAC addresses of the NICs 
> don't match what is configured, the network won't come up.  
> Have fun with that when you've broken the local 
> keyboard/monitor.  

I do try it (as INfrequently as possible), it's to address situations 
that nobody likes.  Phone calls to establish IP/MAC numbers take care 
of most problems.  When remote people can't be bothered to know how to 
spell IP, like on some offshore oil drilling rigs, we send out a 
disk-installer.

I didn't point out the details of the unknown.  

Fire might or might not move the machines to a new ISP or IP;
Vandalism ditto;
"Other urgent causes" has (in my experience) been remote
operators who could not be relied on and therefore a new remote host was
necessary.
In some cases the old IPs work, new MACs are needed, in other cases both
change or neither changes.
So editing of your rsync'd drives before shipping them to the (new?)
ISP/IP site is maybe necessary.

If you can trust your remote operators (more than I can) then remote KVM
is an affordable risk.
*******************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom
they are addressed. If you have received this email in error please
notify the system manager. This footnote also confirms that this
email message has been swept for the presence of computer viruses.
www.Hubbell.com - Hubbell Incorporated**