[CentOS] securing a remotely hosted machine

[Brunner, Brian T.]

> I'm looking to put together a doc for the wiki.c.o on howto 
> secure a remotely hosted machine. There is always the issue of remote 
> hands, other facility users etc being able to get physical 
> access of the machines. 

1: Rebuild kernel to remove local KVM (Keyboard Video Mouse), run
headless; the only access is via ssh.
2: Log-ins through firewall allowed only from approved IPs/MACs
regardless of possession of correct password.

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.  
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.

6: Repeat 3-5 with any mission-critical applications  (think of the bru
drive as "flight critical", this is the "not flight critical but mission
critical" stuff.

> the end result, ofcourse, is to still have the option of 
> handing passwords etc to the DC ops should there be a need to 
> actually work on the machine remotely. so removing the keyb 
> and display interfaces might not be desirable.

Linux install disks in 'rescue' mode have sufficient terminal handling
in their kernel that the running system doesn't need more than ssh.  You
have more worry about the competence and trustworthiness of the host
employees than you know.  So: The remote system doesn't need KVM
(Keyboard Video Mouse), just ssh.

Headless embedded systems work fine this way... ssh only until ssh
fails, then swap out the bru drive (rsync'd spare is on-site or with
remote support personnel we send out) and mail me the junker; it gets
installed as sdb on another system and operated on until 'why did it
die' is discovered and corrected.  Then it gets mailed back and become
the on-site hot-spare that gets rsync'd when the running system changes.
*******************************************************************
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**