Requirements and Procedures

Desktops for Technical Consultant

• 1 Desktop/Laptop
• Standard browser
• Access to the appliance and slave
• Software installed or permission to install:
  • PuTTy (or some other tool to SSH to the BMC Atrium Discovery appliance)
  • WinSCP (or some other tool to secure transfer data to the BMC Atrium Discovery appliance)

Hosting for Virtual Appliance

• Packaged in a compressed tarball image which contains a single VMware virtual image compatible with either of the following products from the VMware suite:
  • VMware Virtual Infrastructure (ESX Server version 3.0.2 or later)
  • VMware Server (version 2.0 build 122956 or later)
• With the following configuration:
  
  • CPU: 1
  • RAM: 2048MB
  • Hard Disk: 1 x SCSI 50Gb (set to grow as necessary in 2Gb file increments)
  • CD/DVD Drive: 1 (auto detect)
  • Network Interface Cards: 1 (eth0) bridged, configured to use DHCP to obtain an IP address.

  The Network Interface Card (eth0) is configured to use DHCP however this can be changed to use a static IP.
  During the install process the following network configuration is required:

  • DHCP or static IP for eth0 interface
    If Static IP then provide the following:
    • Appliance IP Address
    • Gateway
    • Subnet Mask
    • DNS for address lookup

  Defaults For initial testing at small scale the default configuration is sufficient. For production use, or use at scale the user must increase the RAM, CPU and disk configuration. See Configuring the Virtual Appliance for more details.

Windows Slave

• Slave hosted on compatible virtual or physical Microsoft Windows system - compatibility matrix
• Admin access to the Slave Host to install and run the slave executable

Slave Specification

The following specification provides a guide to the minimum recommended specification for the External Slave hardware. This specification has been verified on Microsoft Windows 2003 Service Pack 2.

IP/Subnet details for the target Data Center

• IPs or Subnet(s) or combinations
• IPs to be excluded

Access and Permission to Scan

• Network access to all Hosts
• Change Approvals to scan

Credentials to login to each target host

• Windows:
  • Local admin account with WMI rights
  • Admin share available or tcpvcon/openports on old Win2K and NT
  • Netstat (if not available)
• UNIX:
  • sshd
    (if not available)
    • ssh key or standard user account
  • sudo
    (if not available)
    • sudoers file for privileged commands
  • lsof version 4.78 or later
• SQL Discovery
  • Database account with read access to databases in scope
  • Rights to run specified SQL queries on databases to be discovered

Credentials to discover Virtual Containers

• ESX
  • All Linux requirements
  • Privilege to run esxcfg-info
• Xenserver
  • all Linux requirements
  • Privilege to run /opt/xensource/bin/xe host-* commands
• VMware server
• AIX WPAR
• Solaris Zone container
• HP-UX VPAR

Commands available – required to discover host communications

• Netstat
• lsof
• Tcpvcon for Windows 2000 and older

Hosting Platform for ongoing data consumption of Baseline data after solution decommissioning

• Snapshot of Baseline on a view only BMC Atrium Discovery version
• Virtual Appliance for Community Edition of BMC Atrium Discovery
• Alternatively a desktop or Laptop

Additonal Information

Firewall Access

UNIX Discovery

Discovery Uses:

• Credentials
• Access Methods
• Discovery Commands

UNIX Credentials

Login via: SSH (keys) OR user name/password

The preferred method is SSH Key authentication. This is based on public-key cryptography where "encryption and decryption are done using separate keys, and it is not possible to derive the encryption key from the encryption key. The server knows the public key, and only the user knows the private key".

Our Appliance counts as the 'user' (or 'client') since it is trying to login to the target host(s) (the 'server').

• For this deployment we would access the private key that matches the public key already deployed in each target host's authorized_keys file.
• The private key will usually be contained in a file named id_dsa or id_rsa and should be put in the /usr/tideway/.ssh/ directory with 600 (rw-------) permissions.

UNIX Commands

• Standard user with non-root privileges
• Can only run commands that any standard user could run on the target Host
• sudo is used for privilege escalation
• When setting up the sudo rules on the target Host we specify the command and arguments so that only that command with the designated argument can be run.
• This prevents the risk of spawning any arbitrary commands

Windows Discovery

Windows Credentials

• Uses the Active Directory Slave.
• The AD Slave does not use any credentials entered using the BMC Atrium Discovery user interface.
• Each functional area has its own user account and dedicated Slave.
• The BMC Atrium Discovery slave is deployed on a Customer standard windows build and this can be managed by the local AD operator in each functional area.
• Multiple windows AD slaves can be connected to one BMC Atrium Discovery Appliance.
• By using this approach we reduce the exposure in each functional area to the same access level as that which an AD operator in that functional area would have. The BMC Atrium Discovery Appliance or operator would never know the Windows AD password.

AD Slave Security

• Standard Customer Windows Server Build (Windows 2003)
  • Standard Patching and Service Packs
• Two distinct accounts
  • Slave Discovery Service
  • Login to Windows Server running the Service
• The user managing the AD Slave will never have access to the account which performs discovery
• Cannot use the Slave Service account to log in to Windows servers interactively

Appliance Specification

Physical (provided by BMC Software with BMC Atrium Discovery bundled with RedHat Linux OS). The Appliance specification is sufficient for daily full discovery of at least 5000 OSI, with keeping a discovery history of 100 days (a typical configuration).

• Physical Appliance Spec
• Specification
• Physical Specification
• Power Specifications
• Environmental Specifications

lsof

• lsof(1) is a UNIX specific diagnostic tool. The name lsof stands for "LiSt Open Files" and is developed by Victor A. Abell, retired Associate Director of the Purdue University Computing Centre.
• lsof(1) is a command used in many UNIX systems that isused to report a list of all open files and the processes that opened them. It works in and supports several UNIX flavours.
• Open files in the system include disk files, pipes, network sockets and devices opened by all processes. One use for this command is when a disk cannot be unmounted because (unspecified) files are in use. The listing of open files can be consulted (suitably filtered if necessary) toidentify the process that is using the files.
• If the lsof(1) command is not used BMC Atrium Discovery will not be able to extract communications open (systemwide) by each process.
• More information is available on lsof is available at http://freshmeat.net/projects/lsof.

Microsoft Windows 2000 and older versions

For Microsoft Windows 2000 and older versions, the program to program communication dependency is not available through native Windows tools. In order to get the full dependency model, BMC Atrium Discovery requires an additional tool to be available on the Windows hosts. The following tools are currently supported by BMC Atrium Discovery:

• PSINFO utility is supplied by Sysinternals ™. More details are available on the official website: http://technet.microsoft.com/en-gb/sysinternals/bb897550.aspx
• Tcpvcon – Full details of Tcpvcon are available from the official website:
  http://technet.microsoft.com/en-gb/sysinternals/bb897437.aspx
• OpenPorts – this utility was supplied by DiamondCS but is no longer available.

If Windows NT or 2000 is to be discovered as the platforms for the business applications, one of these tools will need to have been deployed in advance of the POC commencing.