Changes between Initial Version and Version 1 of GENIRacksHome/ExogeniRacks/AcceptanceTestStatus/EG-ADM-2

Timestamp:

05/03/12 19:38:00 (12 years ago)

Author:

chaos@bbn.com

Comment:

--

GENIRacksHome/ExogeniRacks/AcceptanceTestStatus/EG-ADM-2

@@ +1 @@
+[[PageOutline]]
+
+= Detailed test plan for EG-ADM-2: Rack Administrator Access Test =
+
+''This page is GPO's working page for performing EG-ADM-2.  It is public for informational purposes, but it is not an official status report.  See [wiki:GENIRacksHome/ExogeniRacks/AcceptanceTestStatus] for the current status of ExoGENI acceptance tests.''
+
+''Last substantive edit of this page: 2012-05-03''
+
+== Page format ==
+
+ * The status chart summarizes the state of this test
+ * The high-level description from test plan contains text copied exactly from the public test plan and acceptance criteria pages.
+ * The steps contain things i will actually do/verify:
+   * Steps may be composed of related substeps where i find this useful for clarity 
+   * Each step is identified as either "(prep)" or "(verify)":
+     * Prep steps are just things we have to do.  They're not tests of the rack, but are prerequisites for subsequent verification steps
+     * Verify steps are steps in which we will actually look at rack output and make sure it is as expected.  They contain a '''Using:''' block, which lists the steps to run the verification, and an '''Expect:''' block which lists what outcome is expected for the test to pass.
+
+== Status of test ==
+
+Meaning of states:
+ * [[Color(green,okay)]]: Step is completed and passed (for a verification step), or is completed (for a prep step)
+ * [[Color(red,failed)]]: Step is completed and failed, and is not being revisited
+ * in progress: We are currently testing or iterating on this step
+ * [[Color(orange,waiting)]]: Step is blocked by some other step or activity
+
+|| '''Step''' || '''State''' || '''Date completed''' || '''Comments''' ||
+|| 1A         ||             ||                      ||                ||
+|| 1B         ||             ||                      ||                ||
+|| 1C         ||             ||                      ||                ||
+|| 2A         ||             ||                      ||                ||
+|| 2B         ||             ||                      ||                ||
+|| 2C         ||             ||                      ||                ||
+|| 3A         ||             ||                      ||                ||
+|| 3B         ||             ||                      ||                ||
+|| 3C         ||             ||                      ||                ||
+|| 3D         ||             ||                      ||                ||
+|| 4A         ||             ||                      ||                ||
+|| 4B         ||             ||                      ||                ||
+|| 4C         ||             ||                      ||                ||
+|| 4D         ||             ||                      ||                ||
+|| 5          ||             ||                      ||                ||
+
+== High-level description from test plan ==
+
+=== EG-ADM-2: Rack Administrator Access Test ===
+
+This test verifies local and remote administrative access to rack devices.
+
+=== Procedure ===
+
+ 1. For each type of rack infrastructure node, including the head node and a worker node configured for !OpenStack, use a site administrator account to test:
+   * Login to the node using public-key SSH.
+   * Verify that you cannot login to the node using password-based SSH, nor via any unencrypted login protocol.
+   * When logged in, run a command via sudo to verify root privileges.
+ 2. For each rack infrastructure device (switches, remote PDUs if any), use a site administrator account to test:
+   * Login via SSH.
+   * Login via a serial console (if the device has one).
+   * Verify that you cannot login to the device via an unencrypted login protocol.
+   * Use the "enable" command or equivalent to verify privileged access.
+ 3. Test that IMM (the ExoGENI remote console solution for rack hosts) can be used to access the consoles of the head node and a worker node:
+   * Login via SSH or other encrypted protocol.
+   * Verify that you cannot login via an unencrypted login protocol.
+
+=== Criteria to verify as part of this test ===
+
+ * V.01. For all rack infrastructure Unix hosts, including rack servers (both physical and VM) and experimental VM servers, site administrators should be able to login at a console (physical or virtual). (C.3.a)
+ * V.02. Site administrators can login to all rack infrastructure Unix hosts using public-key SSH. (C.3.a, C.3.b)
+ * V.03. Site administrators cannot login to any rack infrastructure Unix hosts using password-based SSH, nor via any unencrypted login protocol. (C.3.a)
+ * V.04. Site administrators can run any command with root privileges on all rack infrastructure Unix hosts. (C.3.a)
+ * V.05. Site administrators can login to all network-accessible rack infrastructure devices (network devices, remote KVMs, remote PDUs, etc) via serial console and via SSH. (C.3.a, C.3.b)
+ * V.06. Site administrators cannot login to any network-accessible rack device via an unencrypted login protocol. (C.3.a)
+
+== Step 1: verify access to rack head node ==
+
+=== Step 1A: verify that SSH to bbn-hn succeeds and allows public keys only ===
+
+'''Using:'''
+ * SSH to `chaos@bbn-hn.exogeni.gpolab.bbn.com` from outside of the rack using public-key SSH
+ * SSH to `chaos@bbn-hn.exogeni.gpolab.bbn.com` from outside of the rack using password-based SSH
+
+'''Verify:'''
+ * Public-key SSH succeeds
+ * Password-based SSH does not succeed
+
+=== Step 1B: verify the absence of common unencrypted login protocols ===
+
+'''Using:'''
+ * Use netstat to enumerate the network-listening processes running on bbn-hn
+ * Identify each process and determine whether it is a common unencrypted login protocol
+ * For any unencrypted login protocols found to be listening, try to access the relevant port remotely and determine whether login is possible
+
+'''Verify:'''
+ * No unencrypted login protocols are listening on accessible networks
+ * Login does not succeed via any unencrypted login protocol
+
+=== Step 1C: verify sudo and sudo logging ===
+
+'''Using:'''
+ * On bbn-hn, run: `sudo whoami`
+ * Look for a syslog file containing a record of the sudo command which was run
+
+'''Verify:'''
+ * The sudo command should succeed
+ * The command which was run should be recorded in a log
+
+== Step 2: verify access to rack worker node ==
+
+=== Step 2A: verify that SSH to bbn-hn succeeds and allows public keys only on public IPs ===
+
+'''Using:'''
+ * SSH to `chaos@bbn-w1` from bbn-hn using public-key SSH
+ * Determine whether any routable IP addresses are defined on bbn-w1 at the time of testing
+ * If so, SSH to `chaos@bbn-w1` using password-based SSH from outside of the rack
+
+'''Verify:'''
+ * Public-key SSH succeeds from bbn-hn
+ * Password-based SSH does not succeed from outside of the rack
+
+=== Step 2B: verify the absence of common unencrypted login protocols ===
+
+'''Using:'''
+ * Use netstat to enumerate the network-listening processes running on bbn-w1
+ * Identify each process and determine whether it is a common unencrypted login protocol
+ * For any unencrypted login protocols found to be listening, try to access the relevant port remotely and determine whether login is possible
+
+'''Verify:'''
+ * No unencrypted login protocols are listening on accessible networks
+ * Login does not succeed via any unencrypted login protocol
+
+=== Step 2C: verify sudo and sudo logging ===
+
+'''Using:'''
+ * On bbn-w1, run: `sudo whoami`
+ * Look for a syslog file containing a record of the sudo command which was run
+
+'''Verify:'''
+ * The sudo command should succeed
+ * The command which was run should be recorded in a log
+
+== Step 3: verify access to 8052 (management) switch ==
+
+=== Step 3A: verify SSH access ===
+
+'''Using:'''
+ * From bbn-hn, login to `chaos@8052` via SSH
+
+'''Verify:'''
+ * SSH login succeeds
+
+=== Step 3B: verify privileged access to the 8052 switch ===
+
+'''Using:'''
+ * On the 8052, run the enable command to enter privileged mode
+ * On the 8052, view the running configuration
+ * On the 8052, view the MAC address table
+
+'''Verify:'''
+ * Entering privileged mode should succeed
+ * Viewing the running configuration should succeed
+ * Viewing the MAC address table should succeed
+
+=== Step 3C: verify absence of unencrypted login access ===
+
+'''Using:'''
+ * From bbn-hn, attempt to connect via telnet (port 23) to the 8052
+ * From bbn-hn, attempt to connect via http (port 80) to the 8052
+ * If a port 80 connection is successful, determine whether login is allowed via that interface
+ * Look at the 8052 running configuration, and identify any configuration lines which might represent login services
+ * Determine whether any such services are encrypted or disabled
+
+'''Verify:'''
+ * The device does not allow telnet access on the standard port
+ * The device does not allow unencrypted http authentication
+ * No other services appear to allow remote unencrypted authentication
+
+=== Step 3D: verify serial console access to the device ===
+
+'''Using:'''
+ * From bbn-hn, access the 8264 via the serial console
+ * Authenticate to the 8264 if necessary
+ * Enter enable mode if necessary
+ * View the running configuration of the 8264
+
+'''Verify:'''
+ * The 8264 should be accessible via serial console
+ * It should be possible to perform privileged operations via the serial console
+ * It should be possible to view the running configuration via the serial console
+
+== Step 4: verify access to 8264 (management) switch ==
+
+=== Step 4A: verify SSH access ===
+
+'''Using:'''
+ * From bbn-hn, login to `chaos@8264` via SSH
+
+'''Verify:'''
+ * SSH login succeeds
+
+=== Step 4B: verify privileged access to the 8264 switch ===
+
+'''Using:'''
+ * On the 8264, run the enable command to enter privileged mode
+ * On the 8264, view the running configuration
+ * On the 8264, view the MAC address table
+
+'''Verify:'''
+ * Entering privileged mode should succeed
+ * Viewing the running configuration should succeed
+ * Viewing the MAC address table should succeed
+
+=== Step 4C: verify absence of unencrypted login access ===
+
+'''Using:'''
+ * From bbn-hn, attempt to connect via telnet (port 23) to the 8264
+ * From bbn-hn, attempt to connect via http (port 80) to the 8264
+ * If a port 80 connection is successful, determine whether login is allowed via that interface
+ * Look at the 8264 running configuration, and identify any configuration lines which might represent login services
+ * Determine whether any such services are encrypted or disabled
+
+'''Verify:'''
+ * The device does not allow telnet access on the standard port
+ * The device does not allow unencrypted http authentication
+ * No other services appear to allow remote unencrypted authentication
+
+=== Step 4D: verify serial console access to the device ===
+
+'''Using:'''
+ * From bbn-hn, access the 8264 via the serial console
+ * Authenticate to the 8264 if necessary
+ * Enter enable mode if necessary
+ * View the running configuration of the 8264
+
+'''Verify:'''
+ * The 8264 should be accessible via serial console
+ * It should be possible to perform privileged operations via the serial console
+ * It should be possible to view the running configuration via the serial console
+
+== Step 5: verify that IMM/IPMI is not accessible without the VPN ==
+
+'''Using:'''
+ * From bbn-hn, attempt to connect via telnet (port 23) to the bbn-w1 IMM IP
+ * From bbn-hn, attempt to connect via http (port 80) to the the bbn-w1 IMM IP
+ * If a port 80 connection is successful, determine whether login is allowed via that interface
+ * If any prospective unencrypted protocols were identified in the IMM configurations during EG-ADM-1 step 3D, attempt to connect to those ports from bbn-hn
+
+'''Verify:'''
+ * The bbn-w1 IMM does not allow telnet access on the standard port
+ * The device does not allow unencrypted http authentication
+ * No other services appear to allow remote unencrypted authentication
+