VmAdmin

WikiHomePage | RecentChanges | Preferences

Xen-based VM Administration (AP3)

This page contains information and policies for (customer/user-side) administrators who are running with their collaborative application(s) deployed on the CIM3 virtualized infrastructure, and, in particular, CIM3 hosted xen-based virtual machines. (AP4)

Policies on the use of CIM3 supported Virtual Machines: (AP5)

Collaborator/Customer/User must warrant that their use of the CIM3 VM would be: (APF)

for applications that they would have properly notified CIM3 on (APG)
legal (in the US and in the jurisdiction that they operate under) (APH)
will not disseminate spam, virus or any kind of malware (API)
*and* that they indemnify and hold CIM3 harmless from all claims, causes of action, damages and judgments arising out of their use of the CIM3 VM. (APJ)
that they take full responsibility on the consequences of their access, in case the server or certain applications become unavailable after their access (whether or not their action has directly caused the vm or those application to go down.) (AR4)

(while it may be unavoidable because of the application design) as much as possible, DO NOT PROVIDE UNIX LEVEL ACCESS to users, limit application users to application level access, please (APK)

Certain vulnerable applications should NOT be enabled on the vm (APL)

for example (but not limited to): (APM)

ftp (i.e. no ftp support for anyone, please) (APN)
telnet (i.e. no telnet support for anyone, please) (AQL)

VM will be accessible by (registered) trusted user administrators only (AP6)

hosts.allow restriction shall apply (AP7)
ssh2 access only (AP8)
using public-private key pairs (2048-bit keys are recommended; one should have keys that are of, at least, 1024-bit strength) (AQA)
vm-admin's should *not* share their access credentials or encryption keys - accounts are individual-based and not role-based (APO)

unless otherwise waived (and even that, this should only be temporary), each vm-admin account and the related credentials should be provided to one individual (APP)

ssh(2) access should be limited to (user) vm-admin's only (APQ)

VM admins will log all changes to configuration files (as well as other pertinent files) with RCS - ref. http://www.gnu.org/s/rcs/ (ASN)

please absolutely remember to go through the "co -u" (check-out and unlock) ... "modify" ... "ci -l" (check-in and lock) process whenever such file(s) is(are) modified (ASO)

(user) vm-admin registration requirements: (APR)

please provide the following: (APS)

VM to be accessed: (AQC)
(preferred) user account name (AQ1)
user's real name (AQ2)
affiliation (AQ3)
role (AQ4)
phone (AQ5)
email address (AQ6)
IP(s) [or hostname(s)] from which you will be accessing the server from (AQ7)
your public key (from your, say, 2048-bit rsa key-pair) [ ref. ] (AQ8)
sudo access: [ y / n ] (to be confirmed by CIM3-sysadmin after consultation with client principal) (AQD)

(unless otherwise arranged) the information should emailed by the customer-organization Admin-Contact or project lead to the CIM3 Admin-Contact (APT)
personnel not directly affiliated with the organization licensing the vm will have to be guaranteed by an officer of that organization (AQ9)

All vm users (including the vm-admin's) who are given unix (linux) level access to the vm: (APU)

must use strong passwords (ref. http://en.wikipedia.org/wiki/Password_strength) ... the passwords used: (APV)

Is at least 8 characters long, and longer if possible (APW)
Contains a mix of upper and lower case letters (APX)
Includes numerals, special characters, and punctuation (APY)
Is not based on any personal information (APZ)
Is not based on any dictionary word (AQ0)
one can have a strong password generated at: http://strongpasswordgenerator.com/ (AQB)

Sudo access will be provided to a (very small number) of (registered) trusted user administrators only (AP9)

(despite the fact that sudoers are empowered) all setup of new sudoers *must* be done by a CIM3 SysAdmin (APA)
(despite the fact that sudoers are empowered) do not modify the root password (APE)

if and when a database system (e.g. mysql) is installed: (AQM)

From a security standpoint, it is considered an application deployment architecture best practice to only allow database connections: (AQN)

a) from the same machine or VM (i.e. loopback interface) in applications that run on a single machine, and (AQO)
b) from other internal machines (i.e. internal-facing network interface) in applications that are deployed using a multi-machine architecture. (AQP)

databases should in general not allow access of any kind from an external interface. (AQQ)
if explicitly requested by a VM's Customer/User's vm-admin, CIM3 will allow database connections on an external interface for non-programmatic remote access by a db-admin. However, all connections to the database must come from registered IP's or hosts (iptables need to be configured accordingly to ensure that access from anywhere else will be refused). CIM3 is not liable for any security breaches to the database due to spoofed IP addresses or other similar attacks. (AQR)

if the db-admin is a different person from the Customer/User's vm-admin, he/she will need to register with CIM3 by providing the information enumerated above too. (AQS)

it is highly recommended that all user data - the database tables (especially), as well as those from other applications - be put under a /data directory, so that a backup strategy that allows for more frequent backup of just the data can be applied, if so desire. (AQT)

Hints on generating your key-pair: (ASQ)

here is a instruction snippet to generate your key pair: (ASS)

On Windows: use puttygen.exe to generate the key pair (AST)
On a Unix/ Linux/OSX: (ASU)

                 $ /usr/bin/ssh-keygen -t rsa    (ASV)

                 default: private key -> ~/.ssh/id_rsa
                 default: public key -> ~/.ssh/id_rsa.pub    (ASW)

refer also to: http://theillustratednetwork.mvps.org/Ssh/copSSH-WinSCP-KeyPair.html or http://ekkescorner.wordpress.com/blog-series/git-mercurial/step-by-step-ssh-on-osx-ubuntu-and-windows/ (ASX)
please send your public key (say "id_rsa.pub" or "id_dsa.pub") as an attachment (ASR)

if you are using puttygen, highlight and copy the text in the "Public key for pasting into OpenSSH? authorized_keys" file window into a Notepad text file. Name the file with a descriptive file name with a .pub extension, like "myname-20110907_id_rsa.pub" and then email that public key file to the CIM3 SysAdmin. (ASZ)
it should look something like the following (all in one line, i.e. without the line breaks) (AT0)

                  ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEAj+qbqXFct/jgeOY/q8VY0Ji5N5V7L4P
                  ya7PEwT8SGC3Z6RatW96N1ul41pX3XrDOiaemCEcdOnxXBG7HcA2NT1jmxBPb+bp
                  BeLK6VaasdqV4pKPn3qSknDyGQdPJzHQnrtj4o4YkDtvNafCbJT2uAL8ICDzURgy
                  HUiz7nw6HA/zHzZiuKQgcm0LtFg2idTXsFD1YS/RJO3WrR+hYrGuERuHTDiI26F1
                  4oYA+AfUYbmiDqQFPaIjcdymCwehbc805GXZt8tSerPKY9G474oIASD3HFDHW/j0
                  3jUuEwY/awwHN3FGyLwU+FEt1oo/q4xotwDlttJzxGISYAhaKUvxyew== rsa-key-20110907    (AT1)

DO NOT SHARE your private key - keep them inaccessible to anyone else except yourself! If this has been compromised, inform the CIM3 SysAdmin, and re-generate a new pair of keys and have those put in place immediately! (ASY)

(more coming ...) (APB)