unisys Unisys Stealth(cloud) for Amazon Web Services Advanced Concepts and Operations Guide Release 2.0 May

Transcription

1 unisys Unisys Stealth(cloud) for Amazon Web Services Advanced Concepts and Operations Guide Release 2.0 May

2 NO WARRANTIES OF ANY NATURE ARE EXTENDED BY THIS DOCUMENT. Any product or related information described herein is only furnished pursuant and subject to the terms and conditions of a duly executed agreement to purchase or lease equipment or to license software. The only warranties made by Unisys, if any, with respect to the products described in this document are set forth in such agreement. Unisys cannot accept any financial or other responsibility that may be the result of your use of the information in this document or software material, including direct, special, or consequential damages. You should be very careful to ensure that the use of this information and/or software material complies with the laws, rules, and regulations of the jurisdictions with respect to which it is used. Unisys Stealth contains encryption features and is subject to, and certain information pertaining to Unisys Stealth may be subject to, limitations imposed by the United States, the European Union and other governments on encryption technology. Information about these U.S. government limitations may currently be found at For more information about your obligations, please see the agreement entered by your company and Unisys. The information contained herein is subject to change without notice. Revisions may be issued to advise of such changes and/or additions. Notice to U.S. Government End Users: This software and any accompanying documentation are commercial items which have been developed entirely at private expense. They are delivered and licensed as commercial computer software and commercial computer software documentation within the meaning of the applicable acquisition regulations. Use, reproduction, or disclosure by the Government is subject to the terms of Unisys standard commercial license for the products, and where applicable, the restricted/limited rights provisions of the contract data rights clauses. Unisys and other Unisys product and service names mentioned herein, as well as their respective logos, are trademarks or registered trademarks of Unisys Corporation. Amazon Web Services and AWS are trademarks of Amazon.com, Inc. or its affiliates in the United States and/or other countries. All other trademarks referenced herein are the property of their respective owners.

3 Contents Section 1. Introduction to Stealth(cloud) for AWS 1.1. Documentation Updates What s New? Guidelines for Using this Document Understanding the Enterprise Manager Interface and Supported Features Understanding Differences with Stealth Deployed in a Data Center Understanding the Initial Stealth(cloud) for AWS Environment Understanding the Default Configurations Understanding the Default Roles, COIs, and Users Understanding Filters for Stealth(cloud) for AWS Configuration Examples Section 2. Modifying the Stealth(cloud) for AWS Environment 2.1. Accessing the Enterprise Manager Interface Copying the Initial Configuration as a Backup Creating New Filters and Applying Them to User Roles Updating Existing User Roles Creating New User Roles and Updating Endpoint Instances Deploying a New Endpoint Package for Updated Service Roles, Assigning an Endpoint to Use a Different Configuration, or Changing the Default Certificate Common Name Restoring a Backup Configuration Section 3. General Stealth Feature Overview 3.1. Management Server Authorization Service Authorization Service Responses Certificates Overview Signing Certificate Authorization Certificates Management Certificate iii

4 Contents SSL Certificates Import/Export Certificates Certificate-Based Authorization Certificates License Certificates COIs and Endpoint Security COI Overview Service COIs and Service Roles COI Guidelines to Enable Communication Between the Authorization Service and Endpoints Stealth Endpoint Processing SCIP/IPsec Session Source IP Address Filtering Filters Applied to COIs or Roles Allow and Deny Filters Local and Remote Port Filtering Filter Qualifiers Filter Flow Diagrams COI Filter-Based Selection COI Filter-Based Selection Overview COI Selection Filter Flow Stealth Roles Endpoint Users and Enterprise Manager Users Enterprise Manager Database Supported Characters and Length Restrictions in the Enterprise Manager Interface Interface Time Outs Section 4. General Stealth Configuration Procedures 4.1. Building the Stealth Network Creating a Configuration Configuring Roles Configuring COIs Configuring Users Setting Up Filtering Adding and Configuring Filter Lists Adding Filter Rules and Qualifiers Adding and Configuring Filter Sets Changing the Priority of Filters and Filter Lists Assigning COIs, Users, and Filters to Roles Assigning COIs Assigning Users Applying Filter Sets to COIs and Roles Provisioning or Reprovisioning the Authorization and Licensing Services iv

5 Contents Section 5. Administering the Environment 5.1. Understanding Reprovisioning Backing Up the Enterprise Manager Database Database Backup Overview Certificate Backup Overview Backing up the Database and Saving Certificates Restoring the Database Change Password Dialog Box (Changing the Enterprise Manager Interface User Account Password) Working with Certificates (Importing and Exporting) Importing a Certificate to the Personal Store Exporting a Certificate Administering Linux Endpoints Linux Multiple IPv4 Address Configurations Linux Multiple Network Interface Configurations Enabling or Disabling Stealth Modes and Stealth for Linux Endpoints Configuring Syslog for Linux Endpoints Accessing the Linux man Pages Section 6. Troubleshooting 6.1. Resolving Common Problems Configuring Clear Text Filters to Allow Applications Blocked by Stealth Enterprise Manager Interface Requirements Updating Firewall Settings Troubleshooting the Management Server Restoring the License Service Changing the Stealth Logo, the Unisys Logo, or the Unisys Name in the Enterprise Manager Interface Troubleshooting Stealth Endpoints Troubleshooting the Stealth Applet Connection to the Unisys Stealth Logon Service on Windows Endpoints Troubleshooting Ubuntu Linux Endpoints Troubleshooting Windows Endpoints with Mapped Network Drives Protocol Transit Information Enterprise Manager Interface Log Files Obtaining Services and Support from Unisys Collecting Diagnostics from the Management Server and Endpoint Instances Deleting the Management Server or Endpoint Instances v

6 Contents vi

7 Figures 1 1. Enterprise Manager Interface Default Segmented Configuration Sample Expanded Segmented Configuration Default Tiered Configuration Clear Text COIs First Full Match Clear Text COIs First Full Match (with Protocol and Port) Stealth COIs First Full Match Stealth COIs First Full Match (with Protocol and Port) Filter Flow vii

8 Figures viii

9 Tables 3 1. Certificate Summary Firewall Ports, IP Addresses, and Programs ix

10 Tables x

11 Section 1 Introduction to Stealth(cloud) for AWS Unisys Stealth(cloud) for Amazon Web Services (AWS) enables you to secure an AWS virtual private cloud (VPC) environment using Unisys Stealth technology. After you deploy your environment using the Unisys Stealth(cloud) for Amazon Web Services Deployment Guide, refer to this document to learn more about Stealth features and for information on making updates to your configuration Documentation Updates This document contains all the information that was available at the time of publication. Changes identified after release of this document are included in problem list entry (PLE) To obtain a copy of the PLE, access the following URL: path2= What s New? The following is new in this release: In the previous release, you could create up to three user roles in one configuration, and those user roles were completely segmented by default (meaning that only endpoints that shared the same user role could communicate). In this release, you can create up to three additional user roles in a tiered configuration. See Understanding Filters for Stealth(cloud) for AWS and Understanding the Default Roles, COIs, and Users for more information. The list of automatically generated filters for Amazon services has been updated to include a more descriptive name and now provides regular polling services. This ensures that the filter list is up-to-date if Amazon changes the IP addresses of its services. See Understanding Filters for Stealth(cloud) for AWS for more information. A new troubleshooting topic is available to explain how to search for IP addresses that require clear text communication but are being blocked by Stealth so that you can create required filters. See 6.2 Configuring Clear Text Filters to Allow Applications Blocked by Stealth for more information

12 Introduction to Stealth(cloud) for AWS 1.3. Guidelines for Using this Document After you deploy your environment using the Unisys Stealth(cloud) for Amazon Web Services Deployment Guide, you can use this document to Learn more about Stealth features Make changes to your configuration If you are using the Enterprise Manager interface to make changes to your configuration, you should consider carefully before deleting or reassigning any components in the Enterprise Manager interface. To make any changes to your environment especially when reassigning and deleting components you must closely follow all of the steps in this document. Caution Be very careful when deleting or reassigning any components in the Enterprise Manager interface. If you delete any configurations, roles, users, certificates, or if you reassign components to different roles or configurations, you could disrupt all Stealth communications in your environment

13 Introduction to Stealth(cloud) for AWS 1.4. Understanding the Enterprise Manager Interface and Supported Features The Enterprise Manager interface enables you to manage all of the components of your Stealth environment. After you log in, the Enterprise Manager interface appears like the following: Figure 1 1. Enterprise Manager Interface This topic provides a summary of the Enterprise Manager interface and lists any pages, tabs, and features that do not apply to Stealth(cloud) for AWS. Configure Page Use this page to create and manage additional components for your Stealth environment, as follows: - System Tab This tab is not supported for Stealth(cloud) for AWS. - Configuration Tab Create and manage configurations. - Role Tab Create and manage roles. - COI Tab Create and manage Communities of Interest (COIs). - Group Tab This tab is not supported for Stealth(cloud) for AWS. - User Tab Create and manage Stealth users and Enterprise Manager users. Filters Page Use this page to configure filters, which you can later apply to COIs and roles. Filters enable more precise control of your Stealth communications and allow communication with non-stealth-enabled components in your environment as required

14 Introduction to Stealth(cloud) for AWS Provision Page Use this page to assign relationships between COIs and users, as they pertain to roles and their associated configurations. Also use this page to assign authorization and licensing URLs and to create and distribute provisioning XML files, as follows: - COI Tab Assign COIs to roles. - Group Tab This tab is not supported for Stealth(cloud) for AWS. - User Tab Assign users to roles. - Filter Tab Assign filters to COIs and roles. - Provision Service Tab Update the Authorization Service when you make changes to your configuration. Manage Page Use this page to manage your certificates and licenses, import and export COIs, and create endpoint packages, as follows: - Package Tab View base endpoint packages and create and manage endpoint software installation packages. See 2.6 Deploying a New Endpoint Package for Updated Service Roles, Assigning an Endpoint to Use a Different Configuration, or Changing the Default Certificate Common Name for more information. - Certificate Tab View various types of certificates and create new CBA or Management certificates, if needed. Caution For this release of Stealth(cloud) for AWS, you should not attempt to delete, import, or create new certificates using the Authorization or Signing subtabs. These actions are not supported, and attempting to delete, import, or create new Authorization or Signing certificates could halt all Stealth communications in your environment. See 3.3 Certificates Overview for more information on certificates. - License Tab This tab is not supported for Stealth(cloud) for AWS. - Export COI Tab Export COIs from Enterprise Manager to import to another configuration in your environment. - Import COI Tab Import COIs from another configuration in your environment. Settings Page Use this page to view information and settings for the Enterprise Manager services, as follows: - Management Tab View the settings for the Stealth Management Service. - Authorization Tab View the settings for the Stealth Authorization Service

15 Introduction to Stealth(cloud) for AWS - License Tab This tab is not supported for Stealth(cloud) for AWS. - Monitor Tab View the settings for the Stealth Monitor Service. Monitoring Page Use this page to view the Stealth Network Dashboard and see an overall status of your environment. For more information, select the name of your Management Server instance in the left pane (under the Management Server heading). Note: In the tree view, the Authorization Servers, Gateways, and Appliances headings do not apply to Stealth(cloud) for AWS. Logs Page Use this page to view the logs and alerts for Enterprise Manager, including authorization attempts, license data, tunnel data, and log information from endpoints. Administration Page Use this page to create and administer Enterprise Manager user accounts and settings (that is, to control which users can access which parts of the interface) and to configure advanced settings, as follows: - User Tab Add additional users who can log on to the Enterprise Manager interface to administer or operate the environment. - Role Tab Add these users to specific roles. - Setting Tab Configure advanced settings for the Enterprise Manager interface. Help Note: The LDAP subtab is not supported for Stealth(cloud) for AWS. Use this button to access the Stealth Enterprise Manager user documentation. In addition, the following two windows can be expanded from the bottom of the interface: Job Use this window to view details about all recent actions you have performed in the portal. Jobs remain in the window for up to 15 minutes after they have been completed. Alert Use this window to view information about log messages in the alerts category Understanding Differences with Stealth Deployed in a Data Center In addition to the Stealth(cloud) for AWS, the Stealth Solution can be purchased from Unisys and deployed directly in your data center. The following are the differences between the Stealth(cloud) for AWS and when Stealth is deployed in a data center:

16 Introduction to Stealth(cloud) for AWS Stealth(cloud) for AWS supports the following operating systems running on endpoint instances: - Windows Server 2008 R2 - Windows Server 2012 R2 - Red Hat Enterprise Linux 6.x and 7.x - SUSE Linux Enterprise Server 11.x - Ubuntu LTS When Stealth is deployed in a data center, the following additional operating systems are supported: - Windows 7 - Windows 8 and Windows Windows Server Ubuntu LTS - IBM AIX V6.1 and V7.1 Windows endpoint instances are configured to run with Stealth Always On. Stealth Always On for Windows endpoints means that Stealth is always enabled on running Windows endpoints (and cannot be disabled by users). In contrast, Windows endpoints in the data center can run Stealth On Demand, which means that users can enable and disable the Stealth service if they need to communicate with other resources in the environment. Note: Stealth can be enabled and disabled for Linux endpoints. Stealth deployed in a data center can provide redundant authorization through the use of standalone Authorization Servers. This component is not supported in this release of Stealth(cloud) for AWS. Stealth deployed in a data center supports IPv6 addressing. IPv6 addressing is not supported in Stealth(cloud) for AWS, because IPv6 addressing is not supported by AWS. Stealth deployed in a data center can support mobile users through a feature known as Secure Remote Access. This feature is not supported in Stealth(cloud) for AWS. Stealth deployed in a data center can enable systems and servers running operating systems that are not supported by Stealth to connect to the network and participate in Stealth COIs through a feature known as Secure Virtual Gateway. This feature is not supported in Stealth(cloud) for AWS. If you want to use any of the features that are not supported in Stealth(cloud) for AWS, contact Unisys at for more information about deploying Stealth in your data center

17 Introduction to Stealth(cloud) for AWS 1.6. Understanding the Initial Stealth(cloud) for AWS Environment When you launch the Stealth(cloud) for AWS Management Server, your initial environment includes default configurations, roles, COIs, and filters that are preconfigured to enable you to secure endpoint communications using Stealth user roles Understanding the Default Configurations A configuration is defined by a group of roles, users, and associated COIs and filters for a particular set of Stealth communications. By default, your Stealth environment includes the following configurations: Management This is a default configuration for Stealth deployed in the data center, and it is not impacted by the CloudFormation templates in this release of Stealth(cloud) for AWS. StealthAdmin This configuration includes the Stealth Service roles and associated COIs and filters that are required for the Management Server instance to communicate with your endpoint instances and for the Stealth Authorization service to authorize your endpoint instances. Although you can update the StealthAdmin configuration, this is not recommended unless you are a knowledgeable Stealth user. Updating the StealthAdmin configuration is not required if you want to make updates to your user roles. However, if you choose to update this configuration, you should also copy it before making any changes. See 2.2 Copying the Initial Configuration as a Backup for more information. Segmented This configuration includes the Stealth user roles and the associated roles, COIs, users, and filters for your endpoint instances in a segmented configuration. This configuration provides up to three secure Stealth user roles to segment your endpoint communications. These user roles are completely segmented, meaning that endpoints in different roles cannot communicate with one another. (Only endpoints that share the same user role can communicate.) If the Segmented configuration is adequate for your environment, then no manual configuration is required; however, you might want to modify this configuration or the Stealth user roles. If you plan to modify this configuration, it is highly recommended that you make a copy of this configuration as a backup before you make any changes. See 2.2 Copying the Initial Configuration as a Backup for more information. Tiered This configuration includes the Stealth user roles and the associated roles, COIs, users, and filters for your endpoint instances in a tiered configuration. This configuration provides up to three tiered, secure Stealth user roles. These user roles are tiered, meaning that endpoints in the Tier2 user role can communicate with endpoints in the Tier1 user role and the Tier3 user role. For example, in a standard Web Server, Application Server, and Database Server configuration, the Application Servers can communicate with the Web Servers and Database Servers, but the Web Servers and Database Servers cannot communicate with one another

18 Introduction to Stealth(cloud) for AWS If the Tiered configuration is adequate for your environment, then no manual configuration is required; however, you might want to modify this configuration or the Stealth user roles. If you plan to modify this configuration, it is highly recommended that you make a copy of this configuration as a backup before you make any changes. See 2.2 Copying the Initial Configuration as a Backup for more information Understanding the Default Roles, COIs, and Users Your initial configuration includes the Stealth user roles that you configured to control endpoint communications, as well as preconfigured Service roles used to authorize endpoint instances. For more general information on COIs see 3.4 COIs and Endpoint Security, and for general information on roles, see 3.6 Stealth Roles. Stealth User Roles A Stealth user role created for Stealth(cloud) for AWS consists of a role, an associated user, and an associated COI. When you launched the Management Server instance using the CloudFormation template, you specified up to three Stealth user roles in the Segmented configuration and up to three Stealth user roles in the Tiered configuration. When you launch an endpoint instance using the CloudFormation templates, you specify the Stealth user role that you want to assign to the endpoint. In the Segmented configuration, endpoint instances can only communicate with other endpoint instances that share the same Stealth user role. In the Tiered configuration, endpoint instances can communicate with other endpoint instances that share the same Stealth user role and with endpoint instances in the adjacent user roles. For example, for the Segmented configuration, if you specified three Stealth user roles named Red, Blue, and Yellow when you initially configured and launched the Management Server instance, the following users, roles, and COIs are automatically generated: StealthUser<n> Parameter Value Red Blue Yellow User Name Red Blue Yellow Role Name RedRole BlueRole YellowRole COI Name RedCOI BlueCOI YellowCOI For the Tiered configuration, if you specified three Stealth user roles named Upper, Middle, Lower when you initially configured and launched the Management Server instance, the following users, roles, and COIs are automatically generated: StealthUser<n> Parameter Value Upper Middle Lower User Name Upper Middle Lower

19 Introduction to Stealth(cloud) for AWS Role Name UpperRole MiddleRole LowerRole COI Name UpperCOI, Tier1Tier2COI MiddleCOI, Tier1Tier2COI, Tier2Tier3COI LowerCOI, Tier2Tier3COI In addition, every Stealth user role includes the StealthAdminLicenseCOI, which is used by endpoint instances to obtain a license from the Management Server instance. Service Roles and the StealthAdmin Role In addition to the Stealth user roles, your environment includes roles that are used by endpoint instances to retrieve licenses and endpoint credentials from the Authorization Service. The Service role and StealthAdmin role enable the Management Server instance and endpoint instances to communicate with the Stealth services running on the Management Server instance. By default, your environment includes the following Service roles and associated COIs: StealthAdmin This role includes the StealthAdminLicenseCOI and the StealthAdminServiceCOI, and it is used by the Management Server instance to license endpoint instances. StealthAdminServiceRole This Service role includes the StealthAdminServiceCOI, and it is used by the Management Server instance to retrieve endpoint credentials from the Authorization Service. SegmentedServiceRole This Service role includes the StealthAdminServiceCOI, and it is used by the endpoint instances in the Segmented configuration to retrieve endpoint credentials from the Authorization Service. TieredServiceRole This Service role includes the StealthAdminServiceCOI, and it is used by the endpoint instances in the Tiered configuration to retrieve endpoint credentials from the Authorization Service. This following default roles are included in the Management configuration and are not impacted by the CloudFormation templates in this release of Stealth(cloud) for AWS: Management This role includes the Management COI for the default Management configuration. Management Service This Service role includes the Management Service COI for the default Management configuration Understanding Filters for Stealth(cloud) for AWS By default, your configuration includes clear text filters to enable the Management Server instance and endpoint instances to communicate with required Amazon services and with the Administration and Diagnostics System or Systems, as well as Stealth filters to allow the Authorization Service to communicate with endpoint instances

20 Introduction to Stealth(cloud) for AWS Caution Be very careful not to delete any of these preconfigured filters. Deleting these filters can disrupt communications within your Stealth environment and prevent endpoints from accessing Amazon services; for example, your instances might not be able to resolve their names. Understanding the Default Filters The following Stealth filter sets and corresponding filter lists are created when you launch the Management Server instance and endpoint instances: StealthAdminAuthFilterSet This Stealth filter set is applied to the StealthAdminLicenseCOI, which is added to each Stealth user role in the Segmented and Tiered configurations. This filter set includes the StealthAdminAuthFilterList filter list, which specifies the IP address for the Management Server instance to allow endpoint instances to communicate with the Authorization Service. StealthAdminAuthPortFilterSet This Stealth filter set is applied to the StealthAdminLicenseCOI, which is added to the StealthAdmin role in the StealthAdmin configuration. This filter set includes the StealthAdminAuthPortFilterList, which specifies the port and protocol used by the Authorization Service on the Management Server instance. In addition, the following clear text filter sets are created when you launch the Management Server instance and endpoint instances: StealthAdminClearTextFilterSet in the StealthAdmin configuration SegmentedClearTextFilterSet in the Segmented configuration TieredClearTextFilterSet in the Tiered configuration

21 Introduction to Stealth(cloud) for AWS These clear text filter sets are applied to every role in the StealthAdmin configuration and the Segmented or Tiered configuration, respectively. By default, each clear text filter set includes the ADSAccessClearTextFilter list. This parent filter list that contains the following preconfigured filter lists: ADSAccessList This filter list enables the Management Server instance and endpoint instances to communicate with the Administration and Diagnostics System or Systems. When you initially configure the Management Server instance, you can enter IP addresses for up to three Administration and Diagnostics Systems, or you can have the CloudFormation template automatically generate an Administration and Diagnostics System. A clear text filter for the Administration and Diagnostics Systems is automatically generated for the Administration and Diagnostics System or Systems. In addition, the ADSAccessList filter list includes a filter qualifier named ADSAccessPorts. By default, this filter qualifier is configured to allow communications over TCP ports 22 and 3389 to allow SSH and RDP communication with the Administration and Diagnostics System or System. When you initially configured the Management Server instance, you might have specified additional port and protocol values. AWS Services This is the parent filter list that includes the current AWS Services <timestamp> filter list. This filter list enables access to required Amazon services (for example, Amazon Route 53 and AmazonProvidedDNS). When you initially configure a Management Server instance or an endpoint instance using the CloudFormation templates, you specify the subnet that the instance is located on within the VPC. Clear text filters are automatically generated and applied to Stealth user roles to allow communication with the required Amazon services in the Global region and the region that you selected when you created your VPC. Understanding AWS Services Filter List Updates Amazon periodically publishes a revised list of IP addresses used for Amazon services. To ensure that your endpoint instances can access the Amazon services, Enterprise Manager checks for updates to Amazon services IP addresses every 24 hours. If Enterprise Manager detects a change, it creates a new, time-stamped AWS Services filter list containing the updated filters. In addition, when a new AWS Services filter list is created, you see the following alert on the Alert tab or on the Logs page Alerts tab: A new AWS services filter list (AWS Services <timestamp>) was created because Amazon changed the list of AWS service IP addresses. To use this updated list, reprovision the Authorization Service (for every configuration that uses this list) using the Provision page, Provision Service tab. The updated filter list automatically replaces the existing filter list in the parent AWS Services filter list, and it is also added to the Filter List page. The timestamp included in the name of the new AWS Services filter list indicates the time and date when the new list was created. In addition, the description includes a timestamp that indicates when the Amazon address change occurred. To update your endpoint instances with the new filter list, you must reprovision the Authorization Service for each configuration in your environment. See 5.1 Understanding Reprovisioning for more information

22 Introduction to Stealth(cloud) for AWS Note: If the AWS Services filter list is updated and you do not reprovision the Authorization Service, your endpoint instances might not be able to communicate with one or more of the Amazon services until you reprovision. The following are best practices to ensure that you always have the current AWS Services filter list: Periodically check the Alerts tab on the Logs page to see if an alert has been generated to notify you of an AWS Services filter list change. To search the list of alerts for AWS Services filter list alerts, do the following: 1. On the Alerts tab, click Show Search. 2. At the bottom of the Search dialog box, click Add Search Filter. 3. Select Event ID from the list of parameters, retain the default operator Equals, and type 317 in the search box. 4. Click Search. Periodically check the Filter List page on the Filters tab to see if the AWS Services filter list has been updated, and reprovision your endpoint instances, if necessary Configuration Examples When you deploy Stealth(cloud) for AWS, you configure your Stealth user roles to communicate in either a Segmented or a Tiered configuration, as described in 1.6 Understanding the Initial Stealth(cloud) for AWS Environment. The following examples illustrate sample Segmented and Tiered configurations. Expanding a configuration or creating a new configuration requires you to manually create new Stealth user roles and assign endpoint instances to these roles. Even after you create new roles, you cannot configure new endpoint instances to automatically participate in them. When you create new endpoint instances, you must specify one of the user roles you created when you launched the Management Server instance, and then you must manually change the user role by substituting the existing CBA certificate for a new CBA certificate and then rebooting the endpoint instance. If you want to modify your initial configuration, see Section 2, Modifying the Stealth(cloud) for AWS Environment, for more information. Stealth(cloud) for AWS in an Initial Segmented Configuration Figure 1 2 illustrates a sample Segmented configuration with six endpoint instances launched using the CloudFormation templates

23 Introduction to Stealth(cloud) for AWS Figure 1 2. Default Segmented Configuration In this example, endpoint instances are launched using the CloudFormation templates with the Stealth user roles that were created when the Management Server instance was launched. No manual configuration is required in this configuration. In this configuration, you see three Segmented user roles, each of which includes one SegmentCOI that enables communication with other endpoints in the same user role and the StealthAdminLicenseCOI that enables communication with the Management Server. For security, Stealth filters are applied to the StealthAdminLicenseCOI so that endpoints can only use this COI to communicate with the Management Server (and cannot use this COI to communicate between user roles). Finally, each Segmented user role includes the ADSAccessClearTextFilter, which enables endpoint communication with the Administration and Diagnostics System or Systems and with Amazon services. See 1.6 Understanding the Initial Stealth(cloud) for AWS Environment for more information

24 Introduction to Stealth(cloud) for AWS Stealth(cloud) for AWS in an Expanded Segmented Configuration You might want to create additional Stealth user roles to allow additional segmented endpoint communications in your environment. Figure 1 3 illustrates an environment using an expanded Segmented configuration. Figure 1 3. Sample Expanded Segmented Configuration In this example, two additional Stealth user roles, called CustomUser1 and CustomUser2 have been added to the environment after the initial deployment, using the Enterprise Manager interface. If you want to modify your configuration to include additional Stealth user roles, and to assign new roles to existing endpoint instances, see 2.5 Creating New User Roles and Updating Endpoint Instances

25 Introduction to Stealth(cloud) for AWS Stealth(cloud) for AWS in a Tiered Configuration In a tiered configuration, you can also create up to three user roles. These user roles are tiered, meaning that endpoints in the Tier2 user role can communicate with endpoints in the Tier1 user role and endpoints in the Tier3 user role. For example, in a standard Web Server, Application Server, and Database Server configuration, the Application Servers can communicate with the Web Servers and Database Servers, but the Web Servers and Database Servers cannot communicate with one another.figure 1 4 illustrates a sample three-tier configuration. Figure 1 4. Default Tiered Configuration

26 Introduction to Stealth(cloud) for AWS In this example, you see three Tiered user roles, each of which includes one TierCOI that enables communication with other endpoints in the same user role and the StealthAdminLicenseCOI that enables communication with the Management Server. (As stated previously, Stealth filters are applied to the StealthAdminLicenseCOI so that endpoints can only use this COI to communicate with the Management Server and never with other endpoints.) In addition, a shared COI enables communication between endpoints assigned to Tier1 and Tier2 (green colored Tier1Tier2COI) and a shared COI enables communication between endpoints assigned to Tier2 and Tier3 (pink colored Tier2Tier3COI). Finally, each Tiered user role includes the ADSAccessClearTextFilter, which enables endpoint communication with the Administration and Diagnostics System or Systems and with Amazon services. If you want to modify your configuration to change your user roles, see 2.4 Updating Existing User Roles

27 Section 2 Modifying the Stealth(cloud) for AWS Environment This section provides detailed information for modifying your Stealth configuration. Caution Be very careful when deleting or reassigning any components in the Enterprise Manager interface. If you delete any configurations, roles, users, or certificates, or if you reassign components to different roles or configurations, you could disrupt all Stealth communications in your environment. Carefully follow the procedures in this section to ensure that you update your environment successfully Accessing the Enterprise Manager Interface You use the Enterprise Manager interface, running on the Management Server instance, to manage your Stealth configuration. To log on to the Management Server instance and access the Enterprise Manager interface, perform the following procedure: 1. From the AWS Management Console, select EC2 under Compute. 2. On the EC2 Dashboard, select Instances in the left pane (under Instances). 3. Right-click the Administration and Diagnostics System instance, and select Connect

28 Modifying the Stealth(cloud) for AWS Environment 4. If your Administration and Diagnostics System was automatically generated by the Management Server CloudFormation template, do the following to obtain the Administrator user account password to log on to the Administration and Diagnostics System: a. On the Connect to Your Instance dialog box click Get Password. b. Click Browse, and then select the EC2 key pair that you selected when you initially configured the Management Server instance. c. Click Decrypt Password to obtain the Administrator user account password for the Administration and Diagnostics System. Make a note of this password or copy it to the clipboard. 5. On the Connect to Your Instance dialog box, if required, download and open the Remote Desktop File. 6. Log on to the Administration and Diagnostics System using the user name and password. 7. On the Administration and Diagnostics System, use Remote Desktop Connection (RDP) or another connection software (if you selected a Linux operating system for your Administration and Diagnostics System), and connect to the Management Server instance using its private IP address. 8. If you receive a warning that the identity of the remote computer cannot be verified, click Yes to continue. 9. Log on to the Management Server instance using the EMAdmin user name and the password that you set for the EMAdminPassword in the Unisys Stealth(cloud) for Amazon Web Services Deployment Guide. 10. On the Management Server instance desktop, double-click the Unisys Enterprise Manager Portal icon. Note: Alternatively, you can enter Server private IP address>:29080/ in a browser window. 11. If you see a warning that there is a problem with the website security certificate, click Continue to this website (not recommended). 12. Log on to the Enterprise Manager interface using the portaladmin user name and the password that you set for the Interface Administrator Password in the Unisys Stealth(cloud) for Amazon Web Services Deployment Guide. The Enterprise Manager interface displays the Stealth Network Dashboard, which provides an overview of your configuration. For more information on using the Enterprise Manager interface, select Help from the menu bar to launch the Unisys Stealth Solution Enterprise Manager Interface Help. To access context-sensitive help information for a specific interface element, click the question mark (?) help icon for that element

29 Modifying the Stealth(cloud) for AWS Environment 2.2. Copying the Initial Configuration as a Backup Caution Before you make any changes to your Stealth environment, it is highly recommended that you make a copy of the configuration you intend to change. When you launch the Management Server instance, you see up to four configurations by default: StealthAdmin Used for Stealth administration Segmented Used for segmented user roles (if you created segmented user roles when you initially subscribed to the Management Server instance) Tiered Used for tiered user roles (if you created tiered user roles when you initially subscribed to the Management Server instance) Management A default configuration used for Stealth in the datacenter; it does not apply to Stealth(cloud) for AWS If you want to update your user roles, you should make changes to the Segmented or Tiered configuration. It is highly recommended that you make a copy of the configuration as a backup before you make any changes. Note: Although you can update the StealthAdmin configuration, this is not recommended unless you are a knowledgeable Stealth user. Updating the StealthAdmin configuration is not required if you want to make updates to your user roles. However, if you choose to update this configuration, you should also copy it before making any changes. To copy the Segmented or Tiered configuration, do the following: 1. Select Configure in the menu bar. 2. Select the Configuration tab. 3. Select the default Segmented or Tiered configuration, and then click Copy at the bottom of the page. 4. Click Yes when you are asked if you want to copy the configuration. The configuration is copied, and the copy is labeled with the original configuration name appended with a timestamp. 5. If you want to give the copy a unique name, do the following: a. Select the new configuration. b. Click Edit at the bottom of the page

30 Modifying the Stealth(cloud) for AWS Environment c. Enter the new name in the Configuration box. For example, enter SegmentedOriginal or TieredOriginal. d. Click Save. Repeat this procedure if you want to copy another configuration before you make changes to it. If you need to use this copied configuration, see 2.7 Restoring a Backup Configuration Creating New Filters and Applying Them to User Roles By default, your configuration includes preconfigured filters to enable required Stealth communications and access to Amazon services, as described in Understanding Filters for Stealth(cloud) for AWS. If these default filters are adequate for your configuration, then no further action is required; however, if you want to allow communications with other non-stealth-enabled instances or services, you can create additional filters and apply them to user roles. Caution Be very careful not to delete any of these preconfigured filters. Deleting these filters can disrupt communications within your Stealth environment and prevent access to Amazon services; for example, your instances might not be able to resolve their names. Deleting filters can also disrupt communications with the Administration and Diagnostics System or Systems, which might prevent you from accessing your Management Server and endpoints, and therefore could irreparably damage your Stealth environment. For example if you want to allow users to access a Stealth-enabled endpoint instance from a non-stealth-enabled workstation, you can create a clear text filter to allow communication with the IP address for that workstation, and assign that filter to the Stealth user role associated with the endpoint instance. Best Practice: Because a role can include only one filter set, it is a best practice that you create a new filter set and include the default clear text filter list (ADSAccessClearTextFilter, which includes the AWS Services and ADSAccessList filter lists) in addition to the new filter lists that you create. This enables you to assign the new filter set to individual roles as well as to maintain the functionality of the default clear text filters, which are required in your Stealth environment

31 Modifying the Stealth(cloud) for AWS Environment Notes: The following procedure is an example that illustrates the general process for configuring a simple clear text filter to allow communication with a specific IP address. For more detailed information on configuring more complex filters, including Stealth filters, see 4.2 Setting Up Filtering. For more information on how filters are used to control network communications, see 3.5 Filtering. If you are unsure about which IP addresses you need to create clear text filters for, or if you created clear text filters but clear text communications are still being blocked by Stealth, see 6.2 Configuring Clear Text Filters to Allow Applications Blocked by Stealth for more information on finding which IP addresses are being blocked. To create and assign a new clear text filter, do the following: 1. On the Enterprise Manager interface, select the Filters page. The Filters page appears and displays the Filter List page. 2. Click Add at the bottom of the page. 3. Enter a name for the new filter list in the Name box, optionally enter a description in the Description box, and click Save. The new filter list is added to the table. 4. Select the link for the new filter list. 5. On the Filter List Page, click Add Qualified Filter at the bottom of the table. 6. On the Create Qualified Filter dialog box, do the following: a. Select Range or IP from the Type list to specify whether the filter applies to a range of IP addresses, or a single address. b. Select 4 from the IP Version list. Note: IPv6 addresses are not supported in the Stealth(cloud) for AWS environment. c. Specify the IP address or range to filter, as follows: If you selected IP from the Type list, enter the address to filter in the IP Address box in dot-decimal notation. Optionally, specify a subnet range by entering the IP address and subnet mask in CIDR notation in the IP Address box or by entering a subnet mask for the IP address in the Mask box. If you enter the subnet mask in the IP Address box, the Mask box is dimmed. (If you selected Range from the Type list, the IP Address box and Mask box are dimmed.) If you selected Range from the Type list, enter the first address in the range in the IP Start box, and enter the last value in the range in the IP End box. (If you selected IP Address in the Type list, the IP Start box and IP End boxes are dimmed.)

32 Modifying the Stealth(cloud) for AWS Environment 7. If you want to specify a protocol and port to include or exclude from the filter rule, click Next and do the following, otherwise, click Save. a. On the Qualifier(s) for IP <IP address> dialog box, click New to create a new filter qualifier. b. On the Add Qualifier(s) for IP <IP address> dialog box, enter a name for the filter qualifier in the Name box and optionally enter a description in the Description box. c. Click Add at the bottom of the table. d. From the Include/Exclude list, select Include to include the network protocol. Select the desired protocol or protocols from the Protocol list. Note: You can select * from the Protocol list to include all protocols. e. If you selected the TCP or UDP protocol, you can specify local and remote ports to filter inbound and outbound traffic in the Local Port box and Remote Port box. In the Local Port and Remote Port boxes, you can enter a wildcard (*), a single port between 1 and 65535, or a range of ports (separated by a hyphen). If you specified a range of ports or a wildcard, and you want to specify ports to exclude from that range, select the Except option, and specify the ports to exclude. f. Click Save Qualifier to add the protocol/port qualifier to the filter list, and then click Back to return to the Qualifiers for IP dialog box. g. Click Save to save the filter list with the qualifier that you created. 8. Optionally, repeat the previous steps to create additional filter lists and qualifiers, as necessary. 9. On the Filters page, select Filter Set from the Filters Tree in the left pane. 10. On the Filter Set page click Add at the bottom of the page. 11. On the Create/Modify Filter Set dialog box, enter a name for the new filter set in the Name box and optionally enter a description in the Description box. 12. Click Select Filter List. 13. On the Add Allowed and Denied List dialog box, ensure that the Allow option is selected. 14. Select the check box next to each filter list that you created. 15. In addition, select the check box next to the ADSAccessClearTextFilter filter list

33 Modifying the Stealth(cloud) for AWS Environment Caution Ensure that you include the ADSAccessClearTextFilter; this clear text filter lists includes the ADSAccessList and AWS Services filter lists, which are required. If you do not include the ADSAccessClearTextFilter in the filter set, you will lose access to the instances that use the role that you assign this filter set to. 16. Click Save to save the new filter set. 17. Do the following to assign the new filter set to one or more Stealth user roles: a. On the Enterprise Manager interface, select the Provision page. b. On the Provision page, select the Filter tab. c. From the Configuration drop-down list (next to the Validate button), select the configuration that includes the role or roles that you want to assign the filter set to (for example, select the Segmented configuration). d. In the left pane, select the arrow next to the configuration name and select the arrow next to Roles to see the roles in the configuration. e. Expand each role that you want to assign the new filter set to. f. Under each role, select the arrow next to Filter Set to see the filter set that is currently assigned to each role. g. For each role that you want to assign the new filter set to, right-click the Stealth clear text filter set (for example right-click SegmentedClearTextFilterSet for a Segmented configuration) under the role and select Remove. h. Select the check box next to each role that you want to apply the new filter set to. You can select a maximum of two roles to apply a filter set to at one time. i. In the Filter table, in the right pane, select the filter set that you created. j. Click the arrow between the left pane and the Filter table to assign the filter set to the selected roles. The filter set appears under the role in the left pane. k. Click Save at the bottom of the page. Note: On this page, you can click the Validate button to validate your configuration, including: The configuration includes at least one Authorization Service URL. The configuration includes a License Service URL

34 Modifying the Stealth(cloud) for AWS Environment The configuration includes a Service Role. All other roles associated with the configuration include at least one user or group. However, for Management Server instances running in a Stealth(cloud) environment, there is no License Service URL, and so you should ignore any warnings you receive that a license server is not specified. If you receive any other errors or warnings, resolve them before continuing. 18. Do the following to reprovision the Stealth user roles to include the filter set that you created. a. Select the Provision Service tab. b. In the left pane, click the arrow next to the configuration name, and then click the arrow next to the Authorization Service heading to view the Authorization Service (Auth Web) URL. c. Right-click the Authorization Service URL, and select Provision Updating Existing User Roles When you launched the Management Server, you created up to three Segmented user roles and up to three Tiered user roles. If required for your environment, you can update these user roles. Alternatively, you could create new user roles by performing the procedure in 2.5 Creating New User Roles and Updating Endpoint Instances. There are many ways to update roles based on the requirements of your environment. For example, you might have created three Segmented user roles, but you might need to convert those Segmented user roles to Tiered user roles. In this example, none of the Segmented user roles share a COI; therefore, none of these user roles can communicate with one another. However, in a three-tier configuration, you would want the endpoints in the Tier 2 role to communicate with the endpoints in both the Tier 1 and the Tier 3 roles (but you would not want the Tier 1 and Tier 3 endpoints to communicate with one another). These tiers might be a web server, application server, and database server named (for example) WebServer for Tier 1, AppServer for Tier 2, and DBServer for Tier 3. This procedure explains the steps required to update the user roles in a configuration, using the example of converting from a segmented environment to a three-tiered environment. You can adapt these steps for your specific requirements (for example, you could reverse and adapt these steps to convert from a three-tiered environment to a segmented environment). Do the following: 1. Create two new COIs to enable the AppServer to communicate with the WebServer and with the DBServer by doing the following. Note: It is recommended that you create new COIs so that you can use the Stealth Applet to easily view which COIs the endpoints are using to communicate and

35 Modifying the Stealth(cloud) for AWS Environment validate your updated configuration. Alternatively, you could skip this step and reassign existing COIs (which were created when you launched the Management Server instance). a. On the Enterprise Manager interface, select Configure in the menu bar. b. On the Configure page, select the COI tab. c. Click Add at the bottom of the page. d. In the Add/Edit COI dialog box, enter a unique name for the new COI in the COI box. For example, name the first COI WebAppCOI to indicate that it enables communication between the WebServer and AppServer roles. Note: For a list of supported characters in COI names and COI name length restrictions, see 3.9 Supported Characters and Length Restrictions in the Enterprise Manager Interface. e. Optionally, enter a description for the new COI in the Description box. For example, type WebServer and AppServer communication. f. Under COI Type, select Workgroup COI (used for normal endpoint communication). g. Click Save. h. Enter a unique name for the second new COI in the COI box. For example, name the second COI DBAppCOI to indicate that it enables communication between the DBServer and AppServer roles. i. Optionally, enter a description for the new COI in the Description box. For example, type DBServer and AppServer communication. j. Under COI Type, select Workgroup COI (used for normal endpoint communication). k. Click Save. l. When you are finished adding COIs, click Close. 2. Assign the COIs you created to the roles by doing the following: a. Select Provision in the menu bar. b. From the Configuration drop-down list (next to the Validate button), select the Segmented configuration. c. Select the COI tab. d. In the left pane, select the arrow next to the Segmented configuration name and select the arrow next to Roles so that you can see the roles created for the configuration (in this example, WebServerRole, AppServerRole, and DBServerRole). e. In the left pane, select the check box for the role that you want to assign the COIs to; that is, select the AppServerRole. Note that you can select a maximum of two roles at one time

36 Modifying the Stealth(cloud) for AWS Environment f. In the COI table, select the workgroup COIs that you want to assign to the role; that is, select the WebAppCOI and the DBAppCOI. You can select multiple COIs at one time by holding down the Ctrl button and selecting multiple COIs. g. Click the arrow between the left pane and the COI table to copy the COIs under the role name. h. Sort the COIs in the order in which they should be used. To re-sort the COIs, in the left pane (under the role name), drag the COIs into the appropriate order. Note: COIs are processed in the order in which they are listed, so you might want to sort them in a specific order. For example, you might want to sort them in the order AppServerCOI, WebAppCOI, and DBAppCOI. i. In the left pane, clear the AppServerRole check box. j. In the left pane, select the DBServerRole check box. k. In the COI table, select the DBAppCOI. l. Click the arrow between the left pane and the COI table to copy the COI under the role name. m. In the left pane, clear the DBServerRole check box. n. In the left pane, select the WebServerRole check box. o. In the COI table, select the WebAppCOI. p. Click the arrow between the left pane and the COI table to copy the COI under the role name. q. Click Save. Note: On this page, you can click the Validate button to validate your configuration, including: The configuration includes at least one Authorization Service URL. The configuration includes a License Service URL. The configuration includes a Service Role. All other roles associated with the configuration include at least one user or group. However, for Management Server instances running in a Stealth(cloud) environment, there is no License Service URL, and so you should ignore any warnings you receive that a license server is not specified. If you receive any other errors or warnings, resolve them before continuing. 3. If you need to create any new filters, perform the procedure in 2.3 Creating New Filters and Applying Them to User Roles to create the filters and assign them to COIs

37 Modifying the Stealth(cloud) for AWS Environment 4. Reprovision the Authorization Service associated with the Segmented configuration so that it recognizes the new user roles by doing the following: a. Select the Provision Service tab. b. Select the arrow next to the Authorization Service heading so that you can see the Authorization Service URL. c. Right-click the Authorization Service URL, and then select Provision. The Authorization Service running on the Management Server is provisioned with the information for the configuration. The endpoint roles are automatically updated through an Authorization Service session rekey the next time the Authorization Service replies to a keep alive event from the endpoint (which occurs every two minutes). In this example, the following communication can now occur: AppServer endpoints should continue to communicate with other AppServer endpoints using the AppServerCOI (which is the COI that was created when the Management Server was launched) AppServer endpoints should now be able to communicate with the WebServer endpoints using the WebAppCOI (which is the first new COI you created) AppServer endpoints should now be able to communicate with the DBServer using the DBAppCOI (which is the second new COI you created)

38 Modifying the Stealth(cloud) for AWS Environment 2.5. Creating New User Roles and Updating Endpoint Instances Cautions You can only update an endpoint instance that you created using the Stealth CloudFormation templates, which are configured to run the Stealth endpoint software. You cannot apply a new role to a non- Stealth AMI. Even after you create new roles, you cannot configure new endpoint instances to automatically participate in them. When you create new endpoint instances, you must specify one of the user roles you created when you launched the Management Server instance, and then you must manually change the user role by substituting the existing CBA certificate for a new CBA certificate and then rebooting the endpoint instance, as described in this procedure. Users associated with endpoint instances can only be assigned to one role. Do not assign more than one role to a user. (You can assign multiple COIs to one role.) When instances are launched using the CloudFormation templates, they are assigned an IAM instance profile that has access to the previous role s folder in the Stealth S3 bucket (which contains the user CBA certificate and other sensitive information). If you change the user role for an instance, a best practice is to change the policy attached to the instance profile so that the instance can no longer access the previous role s folder in the Stealth S3 bucket. (If you do not change the policy, this represents a security risk.) The instance profile can be found in the CloudFormation console when you view a stack s resources or in the EC2 console when you view the details of the instance. Note that if you specified a custom instance profile when you launched the endpoint instance, (you entered a value for the optional InstanceProfile parameter), that instance profile could be assigned to multiple instances, and changing it could have undesired effects on other instances. More details about instance profiles and policies can be found in AWS Identity and Access Management documentation ( To create new user roles and manually assign endpoint instances to participate in the new user roles, do the following. 1. Create new roles by doing the following: a. Select Configure in the menu bar. b. Select the Role tab

39 Modifying the Stealth(cloud) for AWS Environment c. Click Add at the bottom of the page. d. In the Add/Edit Role dialog box, enter a unique name for the new role in the Role box. Note: For a list of supported characters in role names, see 3.9 Supported Characters and Length Restrictions in the Enterprise Manager Interface. e. Optionally, enter a description for the new role in the Description box. f. For a new user role for AWS, ensure that the Service Role check box is not selected. (The Service Role enables initial communication with the Authorization Service so the endpoint can retrieve its user profile, so that users can be authorized and receive their COIs. Your existing configuration should already include a Service role.) g. In the Configuration list, select the configuration that you want to associate the role with. For AWS, you should generally select the Segmented or Tiered configuration. h. Click Save. i. Add any additional roles as required. When you are finished adding roles, click Close. 2. Create new COIs by doing the following. Note: When you launched the Management Server instance, the user roles that you created based on the StealthUser parameters resulted in one user role and one COI for each user. For example, if you created a TopSecret user role in the CloudFormation template, a TopSecretRole and a TopSecretCOI appears in the Enterprise Manager interface. It is recommended that you create one COI for each user role; however, you can create additional COIs for each role or use existing COIs, depending on your needs. The simplest use case is to create one COI for each user role. a. On the Configure page, select the COI tab. b. Click Add at the bottom of the page. c. In the Add/Edit COI dialog box, enter a unique name for the new COI in the COI box. Note: For a list of supported characters in COI names and COI name length restrictions, see 3.9 Supported Characters and Length Restrictions in the Enterprise Manager Interface. d. Optionally, enter a description for the new COI in the Description box. e. Under COI Type, select Workgroup COI (used for normal endpoint communication). f. Click Save. g. Add any additional COIs as required. When you are finished adding COIs, click Close

40 Modifying the Stealth(cloud) for AWS Environment 3. Create new users by doing the following: a. From the Configure page, select the User tab. b. Click Add at the bottom of the page. c. In the Add/Edit User dialog box, select the Set Password check box. This field is required for Stealth(cloud) for AWS so that endpoint instances can be configured with the appropriate credentials. The password is used when creating the file for the Certificate-based authorization (CBA) certificate associated with the user role. d. Enter a unique display name for the new user in the Name box. e. Enter a unique user ID in the User ID box. Note: This user ID must not match an existing Stealth endpoint user ID or Enterprise Manager user ID. f. Optionally, enter a description for the new user in the Description box. g. Enter a password for the user in the Password box, and then reenter the password in the Confirm Password box. Note: These fields are required for Stealth(cloud) for AWS. They only appear if you select the Set Password check box. The password must be between six and 50 characters, and it must include all of the following: At least one uppercase letter At least one lowercase letter At least one number At least one of the following special characters: h. Click # $ % ^ & * ( ) _ + = i. Repeat the previous steps to add one user for each role that you created earlier in this procedure. (There must be a one-to-one correlation between users and roles.) j. Click Close. 4. Create a new CBA certificate for each user you created by doing the following: a. Select Manage from the menu bar. b. Select the Certificate tab, and then select the CBA subtab. c. On the CBA certificate subtab, click Create at the bottom of the page. d. On the Create CBA Certificate dialog box, it is highly recommended that you use the default value StealthAuthentication in the Common Name/Subject box

41 Modifying the Stealth(cloud) for AWS Environment Caution The Stealth software endpoint package that runs on each endpoint instance is configured to use the StealthAuthentication certificate common name. If you change this value, you must create a new endpoint package and redeploy it to each endpoint instance that you want to use this new role. Therefore, it is highly recommended that you use the default value. If you do not use the default value, you can perform the procedure in 2.6 Deploying a New Endpoint Package for Updated Service Roles, Assigning an Endpoint to Use a Different Configuration, or Changing the Default Certificate Common Name. e. Do one of the following to enter a user role to be associated with the CBA certificate: Enter the user ID in the UPN box. You must enter the exact user ID of a user that exists on the Configure page, User tab. Click the ellipses (...) next to the UPN box to see the Select User heading. You can then browse and select a UPN (user ID) from a list of all users on the Configure page, User tab. After you select a user, click OK. f. Click Create. The CBA certificate is created. 5. Assign the COIs you created to the roles you created by doing the following: a. Select Provision in the menu bar. b. From the Configuration drop-down list (next to the Validate button), select the configuration that includes the role that you want to assign a COI to. For AWS, you should generally select the Segmented or Tiered configuration. c. Select the COI tab. d. In the left pane, select the arrow next to the configuration name and select the arrow next to Roles so that you can see the roles you created for the configuration. e. In the left pane, select the check box for the role or roles that you want to assign the COI or COIs to. You can select a maximum of two roles at one time. f. In the COI table, select the workgroup COI or COIs that you want to assign to the role, and also select the StealthAdminLicenseCOI. You can select multiple COIs at one time by holding down the Ctrl button and selecting multiple COIs. You must add the StealthAdminLicenseCOI (which is used to license the endpoint instance) to each role. If you do not add this COI to each role, the endpoint cannot obtain a license and cannot use Stealth

42 Modifying the Stealth(cloud) for AWS Environment g. Click the arrow between the left pane and the COI table to copy the COIs under the role name. h. Sort the COIs in the order in which they should be used. To re-sort the COIs, in the left pane (under the role name), drag the COIs into the appropriate order. Note: COIs are processed in the order in which they are listed, so you might want to sort them in a specific order. For example, an endpoint in the Finance department might include a COI named FinanceCOI and a COI to maintain communication with the Authorization Service named AuthCOI. In that case, you probably want to sort the FinanceCOI above the AuthCOI. i. Click Save. Note: On this page, you can click the Validate button to validate your configuration, including: The configuration includes at least one Authorization Service URL. The configuration includes a License Service URL. The configuration includes a Service Role. All other roles associated with the configuration include at least one user or group. However, for Management Server instances running in a Stealth(cloud) environment, there is no License Service URL, and so you should ignore any warnings you receive that a license server is not specified. If you receive any other errors or warnings, resolve them before continuing. 6. Assign each new user you created to the appropriate role by doing the following: a. Select the User tab. b. In the left pane, select the arrow next to the configuration name and select the arrow next to Roles so that you can see the roles you created for the configuration. c. In the left pane, select the check box next to the role that you want to assign the user to. Notes: Users associated with endpoint instances can only be assigned to one role. Do not assign more than one role to a user. You cannot add users to a Service Role. d. In the User table, select the user that you want to assign to the role. e. Click the arrow between the left pane and the User table to copy the user under the selected role. f. Click Save. 7. Apply the StealthAdminAuthFilterSet to the StealthAdminLicenseCOI for each new role by doing the following. Note: You must apply this filter to the StealthAdminLicenseCOI for each new role you created to ensure the security of your environment. If you do not apply this filter

43 Modifying the Stealth(cloud) for AWS Environment (which limits communication to the Management Server so that endpoints can obtain their licenses), then endpoints could use this StealthAdminLicenseCOI to communicate with one another. a. Select the Filter tab. b. In the left pane, select the arrow next to the configuration name and select the arrow next to Roles so that you can see the roles you created for the configuration. Select the arrow next to the role check boxes and select the arrow next to COIs so that you can see the COIs you added to the roles. c. In the left pane, select the StealthAdminLicenseCOI for a new role. d. In the right pane, select the StealthAdminAuthFilterSet filter set from the filter table. e. Click the arrow between the left pane and the filter table to assign the StealthAdminAuthFilterSet filter set to the StealthAdminLicenseCOI. The filter set appears under the Filter Set heading for the COI in the left pane. f. Repeat the previous two steps until you have assigned the StealthAdminAuthFilterSet filter set to the StealthAdminLicenseCOI for each new role you created. g. Click Save. 8. Depending on which configuration the new role is in, apply either the SegmentedClearTextFilterSet or the TieredClearTextFilterSet to each new role you created by doing the following. Note: You must apply this filter to each new role you created to ensure that your endpoint instances can communicate with Stealth services. If you do not apply this filter, then endpoints cannot use S3 for storage, Route53 for DNS, and other Amazon services. a. In the left pane, select the check box for a new role. b. In the right pane, select either the SegmentedClearTextFilterSet or the TieredClearTextFilterSet from the filter table. c. Click the arrow between the left pane and the filter table to assign the filter set to each new role. The filter set appears under the Filter Set heading for the role in the left pane. d. Repeat the previous two steps until you have assigned the appropriate clear text filter set to each new role you created. e. Click Save. 9. If you created any additional filter sets that you want to apply to workgroup COIs, assign those at this time using the same procedure. You can assign one filter set to each workgroup COI included in each role

44 Modifying the Stealth(cloud) for AWS Environment 10. Reprovision the Authorization Service running on the Management Server so that it recognizes the new user roles by doing the following: a. Select the Provision Service tab. b. Select the arrow next to the Authorization Service heading so that you can see the Authorization Service URL. c. Right-click the Authorization Service URL, and then select Provision. The Authorization Service is provisioned with the information for the configuration. The configuration in the Enterprise Manager interface is complete. You can minimize the browser window or sign out of the Enterprise Manager interface. 11. Do the following to copy the new CBA certificate that you created from the Management Server so that you can import it to any endpoint that you want to be included in the new user role: a. Using Windows Explorer, navigate to C:\Stealth Files\Certificates. b. Copy the.pfx file for any new user you created. c. Using any method you choose, access the endpoint instance whose user role you want to update, and paste the new.pfx file to any location on the endpoint. Note: The endpoints are Stealth-enabled; therefore, you must connect to the Administrative and Diagnostics System and transfer the.pfx file there before connecting to the endpoints and pasting the.pfx file. 12. Do the following to delete the current user certificate from the endpoint based on whether the endpoint is running a Windows or Linux operating system: For Windows endpoints, do the following: a. From the Start menu, enter mmc in the Search box to launch the Microsoft Management Console. b. Click Yes when you are prompted to allow the program to make changes to this computer. c. On the File menu, select Add/Remove Snap-in. d. In the left pane, select Certificates, and click Add. e. On the Certificates snap-in dialog box, select Computer account, and then click Next. f. Ensure that Local computer is selected, and then click Finish. g. On the Add or Remove Snap-ins dialog box, click OK. h. In the left pane of the MMC snap-in, expand Certificates (Local Computer), expand Personal, and then select Certificates

45 Modifying the Stealth(cloud) for AWS Environment i. Locate the certificate whose common name is StealthAuthentication. (This is the certificate associated with the user role you assigned to the endpoint instance when you launched the instance. To view the associated user name, double-click the certificate, select the Details tab, and then select Subject Alternative Name.) j. Right-click the certificate, and click Delete. For Linux endpoints, do the following using sudo: a. Navigate to the ssl-client-certs directory relative to the Stealth endpoint base directory; for example, navigate to /etc/stealth/ssl-client-certs. b. Delete the certificate file for the user role you assigned to the endpoint instance when you launched the instance; that is, delete <user_name>.pfx. 13. Do the following to import the certificate for the new user role, based on whether the endpoint is running a Windows or Linux operating system: For Windows endpoints, do the following: a. In the left pane, ensure that you selected Certificates (Local Computer), expand Personal, and then selected Certificates. b. In the Actions pane (on the far right), click More Actions, point to All Tasks, and then click Import. The Certificate Import Wizard appears. c. On the Welcome screen, click Next. d. Browse to the location of the certificate file you want to import. e. Ensure that the file type is set to Personal Information Exchange. f. Select the.pfx file from the location where you saved it on the endpoint, and then click Open. g. Click Next. h. When prompted, enter the password you entered when you created the user in the Enterprise Manager interface. i. Select the Include all extended properties check box. j. Ensure that the select the Mark this key exportable check box is not selected. k. Click Next. l. Select the Automatically select the certificate store based on the type of certificate check box, and then click Next. m. Click Finish, and then click OK to close Certificate Import Wizard. For Linux endpoints, do the following using sudo: a. Navigate to the ssl-client-certs directory relative to the Stealth endpoint base directory; for example, navigate to /etc/stealth/ssl-client-certs. b. Copy the new certificate file to this directory. c. Using an editor such as vi, open /etc/stealth/system.ini

46 Modifying the Stealth(cloud) for AWS Environment d. Modify the following two values in the system.ini file to include the details for the new.pfx certificate you copied to the ssl-client-certs directory: - ssl_cert = <certificate name>.pfx - passphrase = <password you entered when you created the user> e. Save the changes to the system.ini file. 14. Manually reboot the endpoint instance so that it uses the new certificate to be authorized by the Management Server and be included in its new roles. 15. Optionally, to prevent endpoints from being authorized using any outdated certificates, you can delete any outdated certificates from the Management Server. (CBA certificates are validated on the Management Server by checking their trust chain and verifying that the certificates exist in the Management Server Local Computer Personal certificates store. Removing the certificate from the Management Server certificate store revokes the certificate and it can no longer be used in the Stealth environment) Caution This is an optional step. Only perform this step if you have created a user role and associated certificate that you do not want to use for Stealth authorization. If you delete the wrong certificate, you could prevent valid endpoint instances from using Stealth for communication. Do the following on the Management Server: a. From the Start menu, enter mmc in the Search box to launch the Microsoft Management Console. b. Click Yes when you are prompted to allow the program to make changes to this computer. c. On the File menu, select Add/Remove Snap-in. d. In the left pane, select Certificates, and click Add. e. On the Certificates snap-in dialog box, select Computer account, and then click Next. f. Ensure that Local computer is selected, and then click Finish. g. On the Add or Remove Snap-ins dialog box, click OK. h. In the left pane of the MMC snap-in, expand Certificates (Local Computer), expand Personal, and then select Certificates

47 Modifying the Stealth(cloud) for AWS Environment i. Locate the certificate that you want to delete by selecting a certificate with the common name StealthAuthentication and viewing the user name by doubleclicking the certificate, selecting the Details tab, and then selecting Subject Alternative Name. Caution All Stealth certificates will have the same common name StealthAuthentication, and you should be very careful to locate the certificate with the Subject Alternative Name that you want to revoke. j. Only after you locate the correct certificate, right-click that certificate, and then click Delete. 16. Only if you updated an endpoint so that it is assigned to a different configuration (for example, an endpoint that used to participate in the Tiered configuration should now participate in the Segmented configuration), or if you changed the default value (StealthAuthentication) for the CBA certificate common name to use another value, then you must perform the procedure in 2.6 Deploying a New Endpoint Package for Updated Service Roles, Assigning an Endpoint to Use a Different Configuration, or Changing the Default Certificate Common Name Deploying a New Endpoint Package for Updated Service Roles, Assigning an Endpoint to Use a Different Configuration, or Changing the Default Certificate Common Name This procedure describes how to create a new Stealth endpoint package and deploy it on endpoints. This procedure is required if you do any of the following: Update Service Roles Service Roles are specialized roles that are used by endpoints to access the Authorization Service (running on the Management Server) and retrieve its appropriate credentials. COIs that are added to Service Roles are known as Service COIs. You must perform this procedure if you do any of the following for Service Roles: - Create a new Service Role for your configuration - Add or change Service COIs assigned to a Service Role - Update the filters applied to a Service Role or Service COIs

48 Modifying the Stealth(cloud) for AWS Environment Caution You should be very careful before updating the Service Role. If you incorrectly update the Service Role for the Segmented and Tiered configurations, you could halt all communications for endpoints that use those configurations. If you incorrectly update the Service Role for the StealthAdmin, you could irreparably halt all communication for your entire Stealth environment. Assigning an endpoint to use a different configuration If you update an endpoint so that it is assigned to a different configuration (for example, an endpoint that used to participate in the Tiered configuration should now participate in the Segmented configuration), you must perform this procedure. Changing the default CBA Certificate common name If you change the default value (StealthAuthentication) for the CBA certificate common name to use another value, you must perform this procedure. Prerequisites Before you begin this procedure, you should make the required changes to your environment. For example: If you are updating a Service Role, you should make the required changes to that Service Role or associated Service COIs and filters. For information about updating and applying filters, see 2.3 Creating New Filters and Applying Them to User Roles. For information about updating existing user roles, adapt the procedure in 2.4 Updating Existing User Roles, or refer to the help that is available in the Enterprise Manager interface. If you are assigning an endpoint to use a different configuration, first perform the procedure in 2.5 Creating New User Roles and Updating Endpoint Instances. If you have changed the CBA Certificate common name, you should have already performed the procedure in 2.5 Creating New User Roles and Updating Endpoint Instances. Procedure Do the following: 1. To create a new endpoint installation package, do the following: a. Select Manage in the menu bar. b. Select the Package tab. c. Select the Endpoint Package subtab. d. Click Create at the bottom of the page

49 Modifying the Stealth(cloud) for AWS Environment e. In the Create Endpoint Package dialog box, optionally enter a unique name for the new endpoint package in the Endpoint Package box, or leave this box blank (and a default name is entered). Note: If you enter the name of an existing endpoint package, the creation of the new package will fail. f. Optionally, enter a description in the Description box. g. Select one of the following base endpoint packages from the Base Package list: Base Unisys Stealth Solution <Stealth software level> for AWS Linux To create an endpoint package for a Stealth-enabled Linux instance Base Unisys Stealth Solution <Stealth software level> for AWS Windows To create an endpoint package for a Stealth-enabled Windows instance h. Select AWS Marketplace from the Endpoint Mode list. i. Ensure that the Use Certificate-Based Authorization check box is selected, and enter the certificate name for the user role that you want to create the endpoint package for in the Certificate Name box. By default, CBA Certificates use the name StealthAuthentication, and you should enter this value, unless you specified another CBA Certificate common name. j. Click Select Configuration. k. Under Available Configuration, select the check box for the configuration or configurations that you want to use to create a new endpoint package. In general, for Stealth for AWS, you should select either Segmented or Tiered. l. Click the single right arrow to move the configuration or configurations under the Selected Configuration heading. Notes: After you move the configuration under the Selected Configuration list, the check box is cleared. You only need to select the check box next to the configuration if you want to move it back to the Available Configuration list. (You do not have to select the check box for a configuration to create an endpoint package.) You can use the double right arrow to move all configurations under the Selected Configuration list or use the double left arrow to move all configurations back to the Available Configuration list. Select a configuration check box and then click the single left arrow to move selected configurations back to the Available Configuration list. m. As needed, drag the configurations into the order in which you want the endpoints to try to connect to the associated Authorization Service URLs. n. Click Create. o. Review the summary of your configurations, and then click Proceed. The new endpoint package is created and added to the table on the Endpoint Package subtab. The executable endpoint packages are saved in the following directory:

50 Modifying the Stealth(cloud) for AWS Environment C:\Stealth Files\SoftwareInstalls\Packages If you entered a name in the Endpoint Package box earlier in this procedure, the.exe (for Windows endpoints) or.sh file (for Linux endpoints) appears in the Packages directory with that name. If you did not enter a name in the Endpoint Package box, you see a new folder in the Packages directory named with the software level, and the.exe or.sh file appears in the C:\Stealth Files\SoftwareInstalls\Packages\<software level> directory. 2. Using any method you choose, copy the.exe or.sh file from the Management Server to any location on the affected endpoint that requires the new endpoint package. Note: The endpoints are Stealth-enabled; therefore, you must connect to the Administrative and Diagnostics System and transfer the.exe or.sh file there before connecting to the endpoints and pasting the file. 3. Do the following to install the new endpoint package, depending on the endpoint operating system: For Windows endpoints, do the following: a. On the Windows endpoint, right-click the endpoint package.exe file, and select Run as administrator. Note: You must run this executable file as an administrator for the installation to be successful. b. Wait approximately 10 seconds while the new software is installed. You might see a pop-up appear and disappear; no action is required. c. After the software is installed, reboot the endpoint. d. When the endpoint is rebooted, reconnect to endpoint, and use the Stealth Applet to verify that the endpoint is Stealth enabled. Depending on your change to the Service Role, the Stealth Applet Status Messages might display updated filters, Service COIs, or a new Service Role. For Linux endpoints, do the following: a. Open a terminal window, and change to the directory where you saved the.sh file. b. On the Linux endpoint, enter the following command to change the mode: chmod +x <Linux endpoint installation file name>.sh c. Enter the following command to install the software:./<linux endpoint installation file name>.sh The software is installed. When the installation is complete, you see a message that reads Stealth configured. d. Enter the following command to restart the Stealth software: service stealthd restart e. Enter the following command to verify that the endpoint is Stealth-enabled: stconfig -S

51 Modifying the Stealth(cloud) for AWS Environment 2.7. Restoring a Backup Configuration If you backed up an existing configuration as described in 2.2 Copying the Initial Configuration as a Backup you can restore that configuration in your environment. For example, if you copied the Segmented configuration and provisioned your environment to use a modified copy of that configuration, and you encountered problems with your endpoint communications in the copied configuration, you can revert to the Segmented configuration to use the unmodified user roles for that configuration. To restore a backed up configuration, do the following: 1. On the Enterprise Manager interface, select Provision from the menu bar. 2. On the Provision page, select the Provision Service tab. 3. From the Configuration drop-down list (next to the Validate button), select the configuration that you want to restore. 4. In the left pane, select the arrow next to the Authorization Service heading so that you can see the Authorization Service URL. 5. Right-click the Authorization Service URL and select Provision. The Authorization Service is provisioned with the information for the configuration. Note: On this page, you can click the Validate button to validate your configuration, including: The configuration includes at least one Authorization Service URL. The configuration includes a License Service URL. The configuration includes a Service Role. All other roles associated with the configuration include at least one user or group. However, for Management Server instances running in a Stealth(cloud) environment, there is no License Service URL, and so you should ignore any warnings you receive that a license server is not specified. If you receive any other errors or warnings, resolve them before continuing

52 Modifying the Stealth(cloud) for AWS Environment

53 Section 3 General Stealth Feature Overview This section provides an overview of general Stealth components and functionality 3.1. Management Server The Management Server runs the Enterprise Manager software, which provides a web interface and is responsible for authorizing users COI memberships, managing licensing, and supporting the Stealth logging functions. It enables you to configure the Stealth Solution and create endpoint packages that can be deployed to your endpoints. The following services are provided by the Enterprise Manager software: Authorization Each user is authenticated and authorized when he or she logs on to an endpoint. Each endpoint receives an Authorization Token (AuthToken) that identifies the COI membership status of each user. Note: All Management Server users and endpoint users must be authorized. Logging Stealth endpoints transmit logging and alert information to the Enterprise Manager software so that it can be displayed and sorted in the Enterprise interface. Licensing Licensing is controlled by Enterprise Manager, which means that the authorization, COI security, and licensing are all efficiently managed together. Certificate management Enterprise Manager performs certificate management to create and maintain the certificates used for authentication and encryption. Administration Portal administrators use the Enterprise Manager interface to control account management and role-based authorization to the portal for certificate management and for other administrative tasks. Software updates Enterprise Manager identifies levels of installed software and provides for software updates. This includes updates for endpoints as well as for the Management service Authorization Service The Authorization Service authorizes endpoints and distributes the COIs you define for users. The Authorization Service is installed on the Management Server

54 General Stealth Feature Overview The Management Server should be a dedicated server so that administrators in your environment cannot accidentally corrupt or delete keys or certificates. Each instance of the Authorization Service can support up to 40 AuthGroups. AuthGroups consist of a unique URL and an Authentication Scheme that are used to authorize endpoints Authorization Service Responses Responses from an Authorization Service can contain elements that dictate behavior of endpoints. These responses function as follows: End Session Response An Authorization Service can send a response indicating that the endpoint should terminate the Authorization Service session. For example, the Enterprise Manager sends the Authorization Service a notification to end the session; the Authorization Service then responds to the endpoint. When the endpoint receives the response, it does the following: - Closes the Authorization Service session and removes any internal session state - Closes all open tunnels - Changes the endpoint operating mode from Workgroup mode to Service mode - Continues based on the endpoint mode setting Rekey Response An Authorization Service can send a response indicating that the endpoint should refresh its COI information by sending the Authorization Service a tuples request. When the endpoint receives the rekey response, it does the following: - Closes all open tunnels - Changes the endpoint operating mode from Workgroup mode to Service mode - Sends a tuples request to the Authorization Service Error Response An Authorization Service can send a response containing an errorcode attribute, with a numeric value indicating the Authorization Service could not successfully process the endpoint request. When the endpoint receives the error response, it does the following: - Terminates the Authorization Service session - Closes all open tunnels - Changes the endpoint operating mode from Workgroup mode to Service mode - Sends a tuples request to the Authorization Service

55 General Stealth Feature Overview 3.3. Certificates Overview Stealth uses various certificates to guarantee security, including for encryption, signing, and authorization. It is important to protect the private keys of your certificates, because they are the foundation for the security of your environment. Certificates should be protected from unauthorized usage and protected from loss. (See Exporting a Certificate for more information on exporting certificates so that they can be backed up in a secure location.) In some cases, loss of a certificate will cause loss of data. The following table provides a summary of all certificates used by Stealth. See the following topics for more information. Table 3 1. Certificate Summary Name and Topic Required or Optional Autogenerated by Stealth? Location New Certificate Requirement Signing Certificate Required Yes Management Server Signing certificate private key and trust chain Endpoints Trust chain Creating new certificates is not supported in this release of Stealth(cloud) for AWS Authorization Certificates Required Yes Created on the Management Server; automatically imported to the Management Server key store On the system on which it is created, stored in the Local Machine Trusted Root Certification Authorities store; when automatically imported onto the Management Server store, stored in the Personal store of the user account used to install Enterprise Manager Creating new certificates is not supported in this release of Stealth(cloud) for AWS

56 General Stealth Feature Overview Table 3 1. Certificate Summary (cont.) Name and Topic Required or Optional Autogenerated by Stealth? Location New Certificate Requirement Management Certificate Required Yes Management Server Stored in the Personal store of the user account used to install Enterprise Manager New certificates must be added to the Management certificate subtab. (Sensitive information in the Enterprise Manager database is automatically rewrapped with the new certificate.) SSL Certificates Required Yes Management Server Creating new certificates is not supported in this release of Stealth(cloud) for AWS Import/Export Certificates Optional No; can be generated as required Management Server Stored in the Personal store of the user account used to install Enterprise Manager No action required. (These are temporary certificates used for transfer of COI information.) Certificate-Based Authorization Certificates Required Yes, for the user roles you create when you launch the Management Server instance Authorization Service used by the endpoint Trust chain Server endpoints Certificate and trust chain (These certificates are used for certificatebased authorization.) If you create a new certificate for a new user role, you must install that certificate on all endpoints that you want to use the new role License Certificates Required Yes; cannot be replaced Management Server License certificates are managed automatically and cannot be changed or replaced Signing Certificate A signing certificate is used to protect the integrity of the settings.xml and crypto.xml files, which are included in the endpoint software package. It is important to use a signing certificate to sign the endpoint package, because the endpoint package contains the IP addresses and certificates of the Authorization Services. If that information is corrupted, security of the COI information could be compromised. The signing certificate private key resides on the Management Server

57 General Stealth Feature Overview A signing certificate and associated trusted root certificate are automatically generated by the Stealth software, and these certificates cannot be replaced in this release. The signing certificate must be authorized by a trusted root certificate. This is known as the trust chain. The XML files in the endpoint software package are signed as well as any certificates created for use with Certificate-Based Authorization. The signature is verified by the signing certificate, and in turn, the signing certificate is verified by the trust chain. This certificate security is automatically managed by the Stealth(cloud) automation Authorization Certificates Authorization certificates are used to secure COI information between the Authorization Service and the endpoints. Once you configure Stealth authorization, Enterprise Manager uses a collection of certificates to identify different entities (such as users, endpoints, COIs, Certificate Authorities (CAs), and so on) and to authenticate the identity of those various entities. Enterprise Manager also validates the contents of the certificates and other blocks of data exchanged between entities. Stealth uses the following types of asymmetric key pairs for authorization: 3072-bit RSA keys This key pair is used for encrypting and decrypting data. 256-bit Elliptic Curve (EC) keys This key pair is used for signing and validating blocks of data that use the SCIP/IPsec protocol. (The signing algorithm used is the EC Digital Signing Algorithm.) Management Certificate The Management certificate is used to secure the configuration of the Management Server. Sensitive configuration data is encrypted before it is stored in the configuration database. When the Management Server software is installed, a self-signed certificate is created automatically. The private key resides on the Management Server. After a period of time (for example, every six months) you might want to replace the certificate for security reasons. Sensitive information in the Enterprise Manager database is automatically rewrapped with the new certificate (that is, information is decrypted using the old certificate and then re-encrypted using the new certificate in one secure operation). It can take several minutes to perform this rewrapping, because all of the protected information in the database must be re-encrypted. This certificate is required to restore the database in case of a critical failure. If this certificate is lost, your sensitive data (passwords and COIs) will need to be recreated, and so you should back up this certificate. See 5.2 Backing Up the Enterprise Manager Database for more information

58 General Stealth Feature Overview SSL Certificates SSL certificates are used to enable the security of HTTPS communications to a server. Different certificates are used for messages between the following: Administrators and the Enterprise Manager interface Endpoints and the Authorization Service that authorizes them The Management Server and the systems it monitors Stealth services running on the Management Server SSL certificates are created automatically by the service providing the HTTPS server, and the private key resides on that server. SSL is automatically configured during the software installation Import/Export Certificates Import/export certificates are temporary certificates that can be used to transfer COI information between Management Servers (that reside in separate VPCs) or between a Management Server in the AWS environment and a Management Server in the data center. Note: A Stealth network can include only one Management Server. However, if you have multiple, separate networks (for example, one production environment and one test environment or multiple test environments), you could configure multiple Management Servers. These certificates are created on the destination server (and the private key resides on the destination server), and the certificate is imported on the sending server. The private key resides on the destination server Certificate-Based Authorization Certificates Certificate-based authorization (CBA) certificates are used to authorize endpoint instances. By default, when a new Management Server instance is launched, a new CBA certificate is created for each Stealth user that you specify. These CBA certificates are saved in the Local Machine Personal certificate store for the Management Server instance. When a new endpoint instance is launched, the CBA certificate associated with the user name you selected is saved in the Local Machine Personal certificate store of the endpoint. If you create additional users using the Enterprise Manager interface, you must create an additional CBA certificate for each user. To stop using a certificate for authentication, you must explicitly remove it from the store. If you create a CBA certificate, it is signed by the current valid root certificate on the Signing subtab. See Signing Certificate

59 General Stealth Feature Overview License Certificates License certificates are used to secure license information between Unisys and the server on which the license file is installed (the Management Server) COIs and Endpoint Security Stealth enables multiple secure communities to share the same network without fear of another group accessing their data or their workstations and servers. These are referred to as Communities of Interest (COIs) COI Overview COIs enable secure, logical separation of network users and data instead of configuring multiple physical networks. The result is a much simpler network infrastructure, increased agility to react to new requirements, and enhanced security of your network data. COIs are created using the Enterprise Manager interface and then encrypted and stored in the associated database for Enterprise Manager. You can create as many COIs as are required to secure your environment. COIs enable different COI data to share the same network. For example, when a user is working in a Top Secret security level, all traffic could be encrypted using a Top Secret COI. If the user wants to change to the Secret security level, he or she logs off, and the endpoint closes all tunnels established with the Top Secret COI. When the user logs on using the Secret security level user name and password, the endpoint establishes tunnels as necessary with the Secret COI. As this example demonstrates, the COI is associated with a user, not with a physical system. The COI is configured on the endpoint when a particular user logs on. The user authorization determines the set of COIs assigned within the enclave. When you create COIs, you designate them as either Workgroup COIs or Service COIs. Workgroup COIs are used for general communication between endpoints. See the following topic, Service COIs and Service Roles, for more information about Service COIs Service COIs and Service Roles Service COIs are used by an endpoint to access the Authorization Service and retrieve the endpoint credentials. After you create one or more Service COIs, you can add those COIs to a role that you designate as a Service Role. The endpoints associated with the configuration communicate with the Authorization Service using the Service Role and its associated Service COI or COIs. The Service Role cannot be associated with any accounts (that is, you cannot add any users to that Service Role)

60 General Stealth Feature Overview To create an endpoint package, your configuration must include a Service Role, and that Service Role must include at least one COI. In addition, you must add the same COI that is associated with the Service Role to the role associated with the Management Server user so that endpoints can be authorized. Note: Any COI that is not included in a Service Role and is used for regular communication between endpoints is known as a Workgroup COI. When you create a role, you specify which configuration it should be included in. You must create one Service Role for each configuration that you want to use to create an endpoint package. However, you do not have to create additional Service COIs (unless required for your environment), because multiple Service Roles can share the same Service COI or COIs COI Guidelines to Enable Communication Between the Authorization Service and Endpoints Use the following guidelines when creating COIs to enable communication between the Authorization Service and endpoints: Any Authorization Service in the environment must share a Service COI with the endpoints it is authorizing. This enables the endpoints to be authorized and obtain their COIs. In addition, the Authorization Service must share a Workgroup COI with the endpoints it authorized for licensing and logging purposes, so that the Authorization Service can monitor activity and ensure that the endpoint is still active. The Service COI for the Management Server must also be a COI in a non-service Role. That is, if you create ServiceRole and ServiceCOI, and you create AuthRole, then ServiceCOI must be saved in both ServiceRole and AuthRole. For the Service COI in the Service Role, you should create a filter that enables access only to the IP address of the Management Server to restrict communication to the port used for authorization access (the AuthGroup URL port). Do not apply this filter to the Service COI in the AuthRole; doing so prevents the Authorization Service from communicating with endpoints. COIs are processed in the order in which they are listed, so you might want to sort them in a specific order. For example, an endpoint in the Finance department might include a COI named FinanceCOI and a COI to maintain communication with the Authorization Service named AuthCOI. In that case, you probably want to sort the FinanceCOI above the AuthCOI, because the communication between endpoints uses the FinanceCOI, which means that it will be used most frequently. COIs are processed about ten at a time (varying slightly, based on the configuration), and so the order of COIs is especially important for any endpoint that includes ten or more COIs

61 General Stealth Feature Overview Stealth Endpoint Processing Stealth processing uses the SCIP/IPsec protocol and involves authorization and session processing phases. These phases occur automatically and seamlessly in a Stealth environment managed by the Enterprise Manager, as follows: Authorization Phase Once authenticated by the local identity management system, the user logged onto the endpoint is assigned COI access and policies during the authorization phase of processing. The Stealth tuples contain a set of certificates representing the COIs for which the user is authorized, plus an authorization token that can be used during the tunnel initiation to negotiate COI usage. Enterprise Manager generates an install or runtime XML file for the endpoint software, which contains the information necessary to initiate and maintain a successful session; it also identifies the set of Authorization Services to which the endpoint can possibly connect and the order in which the connection should be attempted. The endpoint sequentially iterates among identified Authorization Services until a session is established. If the attempt to connect for a session fails (you receive a no HTTP response received message or the XML response indicates an error), then the endpoint retries three times before stopping the attempt to connect with that Authorization Service. Enterprise Manager uses the signing certificate to protect the integrity of the settings.xml and crypto.xml files, which are included in the endpoint software package. The endpoint uses the corresponding root and intermediate certificates to validate these XML files before enabling Stealth. Note: While the system is trying to connect with an Authorization Service, it remains in Service mode. See the remainder of this topic for more information on Service mode. Because of a persistent connection between the endpoint and the Authorization Service, the following capabilities are possible: - During the connection, the endpoint consumes a license. If the endpoint detects that the connection is down, it enters a grace period of approximately one hour. If the grace period expires, the endpoint closes its tunnels, enters Service mode and attempts to find another connection to an Authorization Service. - During the connection, the endpoint sends audit information (for example, log ons, log offs, number of tunnels open or closed or failed, configuration changes) to the Authorization Service. The Authorization Service can then, optionally, send the audit information to a Syslog server or integrate it into some other Security Incident and Event Management (SIEM) system, as needed. - The Authorization Service provides real-time monitoring of the endpoint through the Enterprise Manager interface. The portal administrator can initiate control functions (such as tunnel termination or reset) using this interface. - Additional optional functions are available, including endpoint software and configuration changes. That is, the Authorization Service can use the connection to alert the endpoint of significant events. The endpoint can take action,

62 General Stealth Feature Overview depending on the event. For example, the Authorization Service might alert the endpoint that it has been re-provisioned. In that case, the endpoint can reauthorize with the new provisioning file. On log on notification, the endpoint generates a public or private key pair that is unique to that particular log on session. The endpoint sends the public key plus identification and authorization information to the Authorization Service. It determines the COI memberships of the user and returns specific information about the user s credentials. Session Phase Once authorized, the endpoint can open data transfer tunnels to other endpoints. The activity of opening tunnels by an authorized endpoint constitutes a session. All traffic between the endpoints with a data transfer tunnel operating is protected (subject to filtering processing). Note: The use of tunnels (and potentially using explicit COIs for those tunnels) is controlled by the filtering policies distributed to the endpoints by the Authorization Service. Filters are critical to proper operation of Stealth. See 3.5 Filtering for more information. - Session Initiation When an endpoint opens a tunnel to another endpoint, it sends the authorization token that it received during the authorization phase. When the target endpoint receives the authorization token, it attempts to validate the signatures against its list of available COI certificates received from the Authorization Service during the authorization phase. If no match is found, then the endpoint does not honor the request. If a match is found, then the target endpoint responds positively to the initiating endpoint. After the endpoint is authorized and successfully starts communication with the environment, it acquires its license and receives its Workgroup COIs and any associated filters from the Authorization Service. Both sides log the successful initiation of a tunnel, including the identification of the users. - Session Termination When the Stealth software is installed on an endpoint, a minimal set of infrastructure information is also included that provides registration information to the Authorization Service. Using policies established during session initiation, the tunnels are created and terminated as needed. If the Authorization Service detects that the connection is down for approximately 10 minutes, then the Authorization Service assumes the endpoint is offline and removes its session information and reclaims its license. If the endpoint reconnects after this happens, then it is re-provisioned and its tunnels are closed and restarted. In addition, the endpoint operating mode changes from Workgroup mode (which enables the endpoint to communicate with other endpoints that share COIs) to Service mode (using the Service Role). In Service mode, the endpoint attempts to retrieve its workgroup COI information from an Authorization Service using its Service Role COIs and filters. The endpoint remains in service mode until the COI information is retrieved

63 General Stealth Feature Overview SCIP/IPsec Session Source IP Address Stealth does not arbitrarily choose the source IP address for the SCIP/IPsec sessions. Instead, the source and destination IP addresses are established by the IP address of the frame that triggered the creation of the SCIP/IPsec session. The source IP address of an outbound frame can be determined by an application, or it can be determined by the IPv4 stack when the application does not explicitly set the source IP address. Note that when there are multiple IP addresses per NIC in a configuration, the source IP address of an outbound frame may not necessarily be the primary (or first) IP address configured on the NIC Filtering Notes: Using ambiguous filters or filter rules can lead to unpredictable results. (An ambiguous filter is one whose rules overlap or contradict one another.) For example, you should not create a filter that both allows and denies the same TCP port (such as Allow IP range=<ip address>, TCP Port=* Except=20, TCP Port=20). In another example, you should not create a filter where there is overlap between the exception list and the allowed ports (such as Allow IP range=<ip address>, TCP Port=10-20:20-30 Except=20:24-27, TCP Port=*:25-28). You cannot filter UDP ports that are used for Stealth communications. See 6.4 Updating Firewall Settings for more information about the ports and protocols used by Stealth. After you configure COIs and roles, you can configure filters to refine the networking endpoint traffic that is allowed or denied using that COI or for that role. You can apply filters and qualifiers to individual IPv4 addresses or to address ranges. To configure filters, you can specify the following: Filter Qualifier A filter qualifier specifies a list of IP address exceptions and the port or protocol ranges allowed for a qualified filter. Filter List A filter list is a list of qualified filters (IPv4addresses or ranges, with optional qualifiers), a list of filter lists, or a mix of qualified filters and filter lists. Filter Set A filter set is a group of filter lists, with each list configured in a certain order and each set defined as either Allow or Deny. (The order of filter lists in the filter set determines the order in which the filter lists are processed.) You apply filter sets to COIs and roles. Note: You can apply only one filter set to each role as a clear text filter, and you can apply only one filter set to each COI (that is used in each role) as a Stealth filter. You

64 General Stealth Feature Overview can apply different filter sets to different roles as clear text filters, and if a COI is used in multiple roles, you can apply different filter sets as Stealth filters to the COI in each role where it is used. However, if the same user or group is assigned to multiple roles, you must apply the same filter set as a clear text filter to each role. (If you apply different filter sets, and if those filters conflict, this can result in unpredictable behavior as to which clear text filter is applied.) Filters Applied to COIs or Roles Filter sets work differently, depending on whether they are applied to COIs or roles, as follows: Stealth filters are filter sets that are applied to COIs. You use Stealth filters to control Stealth-enabled network traffic, allowing or denying information passed between Stealth endpoints that share COIs. You can apply only one filter set to a COI (that is used in each role). Note: If a COI is used in multiple roles, you can apply different filter sets to the COI in each role where it is used; however, it is a best practice to always apply the same filter set to the COI, regardless of which roles it is used in. You can add as many filter lists to a filter set of one type (either Allow or Deny) as are required. Clear text filters are filter sets that are applied to roles. You use clear text filters to control clear text network traffic, allowing or denying information passed between Stealth endpoints and non-stealth-enabled (clear text) components. You can apply only one filter set to a role. You might need to apply filter sets to roles if you have infrastructure servers that are not running Stealth endpoint software, but that your Stealth endpoints need to communicate with. For example, if you have an Active Directory (AD) server that is not running Stealth endpoint software, create a filter set that includes a filter list with the IP address of that AD server, and apply it to the roles that include users who must be allowed to communicate with the AD server. In this case, the clear text filter enables network traffic to pass between the Stealth-enabled endpoint and the AD server using the specified IP address. You can add as many IP addresses to the filter lists (which are included in one filter set) as are required to ensure that the users in the role can communicate with the infrastructure servers that are not running Stealth endpoint software

65 General Stealth Feature Overview Allow and Deny Filters Filter sets are categorized as Allow or Deny filters, and you can apply either Allow filter sets or Deny filter sets to a COI or role. Filter sets applied to roles are checked before filter sets applied to COIs. Allow Filter When you apply an Allow filter set to a COI, (Stealth filter), you specify rules for filtering the network traffic to be allowed. Messages that meet the filter criteria are transmitted using a Stealth tunnel. If the filter criteria are not met, then the data is discarded. When you apply an Allow filter set to a role (clear text filter), you specify rules for filtering the network traffic to be allowed. Messages that meet the filter criteria are transmitted to or from the clear text network. If the filter criteria are not met, then the data is transmitted using a Stealth tunnel. No frames are discarded. Deny Filter When you apply a Deny filter set to a COI (Stealth filter), you specify rules to filter network traffic to be denied. Messages that meet the filter criteria are discarded. All other traffic is sent using a Stealth tunnel. When you apply a Deny filter set to a role (clear text filter), you specify rules to filter network traffic to be denied. Messages that meet the filter criteria (that match the deny filter) are transmitted using a Stealth tunnel. All others are transmitted to or from the clear text network. Caution An Allow filter set has a default behavior of deny; that is, any condition that does not match the allow filter is denied by default. In the same way, a Deny filter set has a default behavior of allow, so that any condition that does not match the deny filter is allowed. A filter match is made in the context of the message direction. From the endpoint perspective, the filter is applied against the IP address source of the incoming messages and against the IP destination of outgoing messages Local and Remote Port Filtering Stealth uses Local and Remote port filtering, which means that filters are managed for both the source and destination ports. You use Local and Remote port filtering for both Stealth filters (which are applied to COIs) and clear text filters (which are applied to roles). Local and Remote port filtering works as follows: Local - Outbound Source port

66 General Stealth Feature Overview - Inbound Destination port Remote - Outbound Destination port - Inbound Source port You enter Local and Remote port filters like the following: Include/Exclude: Select whether to Include or Exclude the ports. Protocol: Enter a wildcard (*), TCP, UDP, or a value between 1 and 254. Local Port: Enter a wildcard (*), a single port between 1 and 65535, or a range of ports (separated by a hyphen). Remote Port: Enter a wildcard (*), a single port between 1 and 65535, or a range of ports (separated by a hyphen). Excepts: Create exceptions within a valid port range. When you enter a local and remote port (or range) in one filter, it is treated as an and condition (that is, the filter matches if both the local and remote ports match). For example, if you create an Include filter with a local port value of 80 and a remote port value of , the filter will match if the local port is equal to 80 and the remote port is in the range between 100 and Filter Qualifiers In addition to the Allow and Deny behavior, you can use filter qualifiers to specify individual protocols and ports to include or exclude from a filter. A filter qualifier specifies a list of IP address exceptions and the port or protocol ranges allowed for a qualified filter. The qualifiers you enter depend on the type of Local and Remote port filters you entered. That is, if you enter a wildcard value for both the local and remote port, then you can enter any of the following: A qualifier for the local port and the remote port A qualifier for the local port only A qualifier for the remote port only The same is true if you enter a local port range and a remote port range. If you enter a wild card or range for either the local port or the remote port (and an individual value for the other port), then you can enter a qualifier for the local port only or for the remote port only. If you enter an individual value for both the local port and the remote port, you cannot enter any qualifiers. When you enter a qualifier for both the local port and the remote port, it is treated as an and condition (that is, the qualifier matches if both the local and remote ports match). The and condition is demonstrated because the ports are entered together. (See the following example.)

67 General Stealth Feature Overview In contrast, when you enter additional qualifiers, they are treated as an or condition. The or condition is demonstrated because each qualifier is entered separately. The following is an example of a Local and Remote port filter that uses multiple exceptions: TCP Local Port = *, Remote Port =* Exclude Local Port = 20, Remote Port = 8080 Exclude Local Port = 40, Remote Port = 9090 Exclude Local Port = Exclude Remote Port = In the previous example, the Exclude Local Port = 20, Remote Port = 8080 is treated as an and condition. In addition, the Exclude Local Port = 40, Remote Port = 9090 is treated as an and condition. All four lines are treated as or conditions when valued against one another. Alternatively, you could create filters that allow traffic rather than denying it. You can create filter qualifiers depending on your needs Filter Flow Diagrams See the following diagrams to understand the flow of Allow and Deny filter verification when sending data and receiving data for both Clear Text COIs and Stealth COIs. Figure 3 1. Clear Text COIs First Full Match

68 General Stealth Feature Overview Figure 3 2. Clear Text COIs First Full Match (with Protocol and Port) Figure 3 3. Stealth COIs First Full Match

69 General Stealth Feature Overview Figure 3 4. Stealth COIs First Full Match (with Protocol and Port) COI Filter-Based Selection You can use filters to prevent specific Stealth COIs from opening tunnels between endpoints that share this COI by creating a filter that denies an endpoint s IP address. You might want to do this if endpoints share multiple COIs, but you want them to communicate using a specific COI. See the following topics for more information. COI Filter-Based Selection Overview To prevent a specific COI from opening tunnels to specific IP addresses, subnets, or IP address ranges, enter a Deny filter, without any port or protocol qualifier. Alternatively, enter an Allow filter with an IP address qualifier. This results in the COI being excluded from the COI negotiation process for the specified endpoint IP addresses, subnets, or IP address range denied by the filter. Conversely, to restrict a specific COI to only open tunnels to specific IP addresses, subnets, or IP address ranges, enter an Allow filter with an IP address qualifier. Alternatively, enter a Deny filter with an IP address qualifier. This results in the COI being restricted in the COI negotiation process to the specified endpoint IP addresses, subnets, or IP address range allowed by the filter. Note: The COI negotiation process attempts to establish a tunnel with another endpoint using the COIs in the order in which they are ordered. Unfiltered COIs have an implicit Allow All filter. A Stealth COI with one of the following filters would be excluded for all endpoints in the /24 subnet and included for all other endpoints. Deny IP Range= /24 Allow IP Range= /

70 General Stealth Feature Overview Exclude= /24 A Stealth COI with the following filter would be included for all endpoints in the /24 subnet as well as for other endpoints, because it includes a protocol qualifier: Deny IP Range= /24 Protocol=* Note that even though the filter has a protocol qualifier that is meaningless (that is, a wildcard) so that the filter denies access to the IP addresses for all traffic, the fact that a protocol qualifier is included means that the Stealth software will open a tunnel to endpoints in the subnet using the COI. If you want to exclude this COI for the subnet, the protocol wildcard qualifier must be removed from the filter. A Stealth COI with the following filter would be excluded for but included for all other endpoints in the /24 subnet as well as all endpoints outside of the subnet. This is because the Stealth software uses the first matching IP address, subnet, or wildcard filter during COI selection. Deny IP Range= Deny IP Range= /24 Protocol=* In contrast, changing the order of the filter in the filter list results in the inclusion of because the Stealth software matches the subnet and finds the protocol qualifier. (The Deny IP Range= is never found because the first filter is a match.) Deny IP Range= /24 Protocol=* Deny IP Range= COI Selection Filter Flow The following topic and diagram describes the flow of Allow and Deny filter verification when sending data and receiving data for both Clear Text COIs and Stealth COIs. Deny Filter List Processing As shown in this diagram, deny filter lists are examined first. If a Deny filter list is defined, the list is examined for any filter with a matching IP address (that is, a wildcard, subnet, or specific match). When a matching filter is found, the filter is examined for a qualifier. If a qualifier is available, the list is examined for a match to the remote endpoint. If a match is found in the qualifier, the COI is included in COI negotiation as the filter explicitly Allows access to the endpoint

71 General Stealth Feature Overview If there is no qualifier or no match is found in the qualifier, the filter is examined for a protocol or port filter rule. If there are no protocol or port filter rules, the endpoint is explicitly denied access, and the COI is excluded from COI negotiation. If the filter does include a protocol or port rule, the endpoint is allowed access and the COI is included in the COI negotiation. If no other filters are found to match the remote IP address, the COI is included in the COI negotiation (because the Deny filter allows access to at least some protocols or ports on the remote endpoint). Allow Access List Processing Allow filter lists are examined if there is no Deny filter list, or if no match is found in the Deny filter list. The Allow filter list is examined for a filter matching the remote IP address (that is, a wildcard, subnet, or specific match). If a match is found, the filter is further examined for a qualifier to determine if the filter denies access to the remote IP address. If a match is found in the qualifier, the COI is excluded from COI negotiation. Any other match in the Allow filter list results in the COI being included in the COI negotiation. If no match is found, and if there was no Deny filter list, the COI is excluded from COI negotiation as the Allow filter implicitly denies access to the endpoint. Note: If both a Deny list and an Allow list are present, and if no match is found in either list for the remote IP address, then the COI is included for COI negotiation. This is because the filter lists are ambiguous and cannot be used to clearly determine access to the remote endpoint

72 General Stealth Feature Overview Figure 3 5. Filter Flow 3.6. Stealth Roles Each role is an association of users and COIs. For example, you can set up roles based on department (that is, Accounting and Human Resources) or security clearance level (that is, Secure and Top Secret). Users can belong to multiple roles; however, users should not belong to multiple roles that include different Clear Text COIs or that include the same Stealth COI with different filters. This is because of the following: Each endpoint user can use only one Clear Text COI In the Enterprise Manager interface, each role can support only one Clear Text COI. Even if you add an endpoint user to multiple roles (each with different Clear Text COIs), only one Clear Text COI can be used at one time for that endpoint user. The endpoint uses the last Clear Text COI it receives, and depending on the communication state between endpoints, the Clear Text COI that is used might differ. Stealth COIs applied to roles are not combined If a user is included in two different roles, and if those roles include the same Stealth COI with different filters, the behavior is unpredictable. Again, depending on the communication state between the endpoints, and the filters that are applied, the behavior might differ. To manage these issues, you can do any or all of the following:

73 General Stealth Feature Overview Include users in only one role. Ensure that users included in multiple roles have only one Clear Text COI (or identical Clear Text COIs). Use the same filter definition on each occurrence of a Stealth COI. Note: If you define a filter on a Stealth COI, it is highly recommended that you use the same filter definition on each occurrence of the Stealth COI. For example, you could create a Stealth COI named StealthCOIHR and include it in the HR role and in the Management role; in both occurrences of the StealthCOIHR, you should include the same filter content. This ensures that there is no ambiguity when the endpoints associated with the HR and Management roles communicate Endpoint Users and Enterprise Manager Users You can add two different categories of users to the Enterprise Manager interface: Enterprise Manager users, who are responsible for administering and operating the Enterprise Manager interface These users have privileges to access different pages within the Enterprise Manager interface, enabling them to perform various configuration or monitoring tasks. For example, you assign one or more users to the Portal Administrator role to grant administrator privileges to those users and enable users in that role to see all pages in the interface. In contrast, assigning a user to the Audit Administrator role grants access only to the Monitor and Logs pages. See the Administration page for information about adding Enterprise Manager users. Endpoint users, who participate in COIs These are Stealth users who do not interact directly with the Enterprise Manager interface. Each user name and each role name must be unique. See Configuring Users for more information. These users exist in the same database, and so each user ID must be unique Enterprise Manager Database You should back up the Enterprise Manager database on a regular schedule or after a significant configuration change. Full backups are critical to maintaining the integrity of your Management Server and Stealth network configuration in catastrophic failures, such as storage unit failure or server hardware failure. See 5.2 Backing Up the Enterprise Manager Database for more information. In the event of an Enterprise Manager database failure, the Enterprise Manager interface keeps running, but you cannot make configuration changes. How long the interface continues to run is dependent on the exact nature of the database failure. In general, when the database fails, the following occurs:

74 General Stealth Feature Overview You cannot complete any actions on open Enterprise Manager interface sessions (for example, you cannot add or delete users from roles.) New sessions to the Enterprise Manager interface cannot be established. However, endpoints are not affected. That is, existing Stealth sessions are not interrupted, and new sessions can be established. Once the Enterprise Manager database is available again, you can continue with normal activity. After your initial configuration is complete, you should be sure to backup your database as described in 5.2 Backing Up the Enterprise Manager Database Supported Characters and Length Restrictions in the Enterprise Manager Interface When you are creating components in the Enterprise Manager interface including configuration, COI, role, user, and endpoint software file names the following characters are supported: Upper and lowercase letters Note: The first character in a name must be a letter. Numbers (0-9) Space ( ) Note: A space cannot be the first character or last character in a name. Underscore (_) Hyphen (-) Comma (,) Period (.) Note: Multiple periods in a row are not supported. Exclamation point (!) Dollar sign ($) Percent sign (%) Ampersand (&) Single quotation mark ( ) Parentheses ( ) Equal sign (=) At sign (@) Square brackets ([ ]) Caret (^)

75 General Stealth Feature Overview Curly brackets ({ }) Tilde (~) In addition, COI names and filter set names must be 28 characters or fewer Interface Time Outs For security purposes, all of the pages on the Enterprise Manager interface time out after 30 minutes of inactivity, except for the Monitoring page, which does not time out. To avoid a time out, you can do any of the following: Navigate between pages using the menu bar (for example, moving from the Configure page to the Provision page) Navigate between tabs on a page (for example, on the Configure page, moving from the Role tab to the User tab) Perform an action (for example, adding a component or clicking Save) Navigate in the tree view (if the page includes a left-pane tree view) Note: Moving the mouse around the screen or typing input does not reset the time out process. In addition, starting and cancelling an action (for example, clicking Add to add a component and then closing the Add dialog box) does not reset the time out process. After 29 minutes of inactivity, you see a warning at the top of the interface that Enterprise Manager will time out in one minute, and you can click Extend to extend your session. If you do not extend the session, you are logged out of the interface and must log in again

76 General Stealth Feature Overview

77 Section 4 General Stealth Configuration Procedures The procedures in this section explain how to generally configure Stealth components in your environment. See Section 2, Modifying the Stealth(cloud) for AWS Environment, for more information about specific procedures for modifying your Stelath(cloud) for AWS deployment Building the Stealth Network You use the Configure page to create or update a configuration for your Stealth communications. A configuration includes a set of COIs, roles, users, endpoints, and filters for a particular set of Stealth communications. You can create multiple configurations in your environment. For example, if you have a separate development and production environment, you might want to create a configuration for each. You can do the following using the Configure page: Create one or more configurations. Create roles to define participation in your Stealth environment. Create COIs to enable security Creating a Configuration You can create one configuration for your entire environment, or you could create multiple smaller configurations. Your environment can include as many configurations as necessary, but it must include at least one configuration. In most environments, you will create multiple configurations; see the following subtopics for more information about creating different configurations. You then use these multiple configurations to create as many endpoint packages as are required for your Stealth endpoints. Creating Configurations Enterprise Manager includes a sample configuration, called the Management configuration, which you can copy and use to build your environment

78 General Stealth Configuration Procedures To add a new configuration, do the following: 1. Select Configure in the menu bar. 2. Select the Configuration tab. 3. Click Add at the bottom of the page. 4. In the Add/Edit Configuration dialog box, enter a unique name for the new configuration in the Configuration box. Note: For a list of supported characters in configuration names, see 3.9 Supported Characters and Length Restrictions in the Enterprise Manager Interface. 5. Optionally, enter a description for the new configuration in the Description box. 6. Click Save. 7. When you are finished adding configurations, click Close. Alternatively, to copy an existing configuration, do the following. Note: The Copy configuration function copies a configuration and its associated roles. Both the original and copied roles reference the same associated COIsand users. You can use the copy function to make a backup of your existing configuration. If you are creating a brand new configuration, you should use the Add configuration function. 1. Select Configure in the menu bar. 2. Select the Configuration tab. 3. Select the default Management configuration, or select another existing configuration in your environment, and then click Copy at the bottom of the page. 4. Click Yes when you are asked if you want to copy the configuration. The configuration is copied, and the copy is labeled with the original configuration name amended with a timestamp. 5. If you want to give the new configuration a unique name or new description, select the new configuration, and click Edit at the bottom of the page. Then, enter the new name in the Configuration box, update the description in the Description box, and then click Save Configuring Roles A role is a collection of users that share COIs. Users can belong to multiple roles. For example, you can set up roles based on department (such as Accounting and Human Resources) or security clearance level (such as Secure and Top Secret). To add a new role, do the following: 1. Select Configure in the menu bar. 2. Select the Role tab. 3. Click Add at the bottom of the page. 4. In the Add/Edit Role dialog box, enter a unique name for the new role in the Role box

79 General Stealth Configuration Procedures Note: For a list of supported characters in role names, see 3.9 Supported Characters and Length Restrictions in the Enterprise Manager Interface. 5. Optionally, enter a description for the new role in the Description box. 6. If you want the role to act as a Service Role, select the Service Role check box. The Service Role enables initial communication with the Authorization Service so the endpoint can retrieve its user profile. (This enables users to be authorized and receive their COIs.) Each configuration can include only one Service Role. You can select the Service Role check box to create a Service Role for a new configuration or if you deleted the Service Role and want to create a new one. 7. In the Configuration list, select the configuration that you want to associate the role with. 8. Click Save. 9. Add any additional roles as required. When you are finished adding roles, click Close Configuring COIs Communities of Interest (COIs) are used to enable Stealth-secured communications. COIs enable secure, logical separation of network users and data, and COI participants are users assigned to certain roles. All participants in a COI use wrapped (encrypted) keys to secure data for transmission on the network; the data is therefore cloaked from others also using the network. The data can only be accessed by another participant in the same COI. Create as many COIs as are necessary for communications in the environment (including in all of the configurations you created). To create a new COI, do the following: 1. Select Configure in the menu bar. 2. Select the COI tab. 3. Click Add at the bottom of the page. 4. In the Add/Edit COI dialog box, enter a unique name for the new COI in the COI box. Note: For a list of supported characters in COI names and COI name length restrictions, see 3.9 Supported Characters and Length Restrictions in the Enterprise Manager Interface. 5. Optionally, enter a description for the new COI in the Description box. 6. Under COI Type, select whether the COI is a Workgroup COI (used for normal endpoint communication) or a Service COI (used for communication with the Authorization Service so that the endpoint can obtain its COIs). 7. Click Save. 8. Add any additional COIs as required

80 General Stealth Configuration Procedures When you are finished adding COIs, click Close. You should create an adequate number of COIs so that you can secure your communication across your environment and enable endpoints to be authorized. Any Authorization Service in the environment must share a Service COI with the endpoints it is authorizing. This enables the endpoints to be authorized and obtain their COIs. In addition, the Authorization Service must share a Workgroup COI with the endpoints it authorizes, so that the Authorization Service can perform licensing and logging activities, monitor activity, and ensure that the endpoint is still active. Also, all Authorization Services must share a Service COI and non-service COI Configuring Users You can create accounts for additional users, and then add those user accounts to roles. (Creating groups is not supported for Stealth(cloud) for AWS environments.) To add a new user, do the following: 1. Select Configure in the menu bar. 2. Select the User tab. 3. Click Add at the bottom of the page. 4. In the Add/Edit User dialog box, if the user is a Stealth(cloud) for AWS user, select the Set Password check box. This field is required for Stealth(cloud) for AWS so that endpoint instances can be configured with the appropriate credentials. The password is used when creating the file for the Certificate-Based Authorization (CBA) certificate associated with the user role. 5. Enter a unique display name for the new user in the Name box. Notes: For a list of supported characters in user names, see 3.9 Supported Characters and Length Restrictions in the Enterprise Manager Interface. 6. Enter a unique user ID in the User ID box. Notes: This user ID must not match an existing Stealth endpoint user ID or Enterprise Manager user ID. 7. Optionally, enter a description for the new user in the Description box. 8. For Stealth(cloud) for AWS, enter a password for the user in the Password box, and then reenter the password in the Confirm Password box. Note: The password fields are required for Stealth(cloud) for AWS. They only appear if you select the Set Password check box

81 General Stealth Configuration Procedures The password must be between six and 50 characters, and it must include all of the following: At least one uppercase letter At least one lowercase letter At least one number At least one of the following special characters: 9. Click # $ % ^ & * ( ) _ + = 10. Repeat the previous steps to add as many users as needed. 11. Click Close Setting Up Filtering Note: Using ambiguous filters or filter rules can lead to unpredictable results. (An ambiguous filter is one whose rules overlap or contradict one another.) For example, you should not create a filter that both allows and denies the same TCP port (such as Allow IP range=<ip address>, TCP Port=* Except=20, TCP Port=20). In another example, you should not create a filter where there is overlap between the exception list and the allowed ports (such as Allow IP range=<ip address>, TCP Port=10-20:20-30 Except=20:24-27, TCP Port=*:25-28). You can use filters to restrict network traffic between endpoints. To use filters, you do the following: Create one or more filter lists. Create one or more qualified filters (with one or more qualifiers) and add them to your filter lists. Create one or more filter sets and populate them with one or more filter lists. Apply filter sets to COIs to allow or deny Stealth communications with specified endpoints. Filter sets applied to COIs are called Stealth filters. Apply filter sets to roles to allow or deny clear text communications with non-stealthenabled endpoints. Filter sets applied to roles are called clear text filters. Note: You can apply only one filter set to each role as a clear text filter, and you can apply only one filter set to each COI (that is used in each role) as a Stealth filter. You can apply different filter sets to different roles as clear text filters, and if a COI is used in multiple roles, you can apply different filter sets as Stealth filters to the COI in each role where it is used. However, if the same user or group is assigned to multiple roles, you must apply the same filter set as a clear text filter to each role. (If you apply different filter sets, and if those filters conflict, this can result in unpredictable behavior as to which clear text filter is applied.) See 3.5 Filtering for more information about understanding filters

82 General Stealth Configuration Procedures Before you begin to add and apply filters, ensure that you are familiar with your network configuration, including IP address information for your endpoints Adding and Configuring Filter Lists A filter list is a list of qualified filters used to allow or deny communication in your Stealthenabled network. A filter list can also contain other filter lists. You can add a filter list in either of the following ways: As a new filter list To an existing filter list Adding a Filter List To add a new filter list, do the following: 1. Select Filters in the menu bar. 2. On the Filters page, select the Filter List heading in the Filters Tree. 3. Click Add at the bottom of the page. 4. On the Create Filter List dialog box, enter a unique name for the filter list in the Name box. 5. Optionally, enter a description for the filter list in the Description box. 6. Click Save to save the new filter list. Adding a Filter List to an Existing Filter List To add a filter list to an existing filter list, do the following: 1. Select Filters in the menu bar. 2. On the Filters page, select the Filter List heading in the Filters Tree. 3. On the Filter Lists page, select the link for the filter list that you want to add a filter list to. 4. On the Filter List page, click Add Filter List at the bottom of the page. 5. On the Create Filter List dialog box, select the New option to create a new filter list, or select the Existing option to add an existing filter list, and then do the following: If you selected New, enter a unique name in the Name box and enter an optional description in the Description box, and then click Save. The new filter list is added as a child of the selected filter list. If you selected Existing, select the check box next to the filter list or lists that you want to add as child lists, and then click Save. Note: You cannot add a filter list to itself as a child filter list. The filter list that you are adding a list to is dimmed and cannot be selected

83 General Stealth Configuration Procedures The existing filter list is added as a child of the selected filter list Adding Filter Rules and Qualifiers A filter includes an IP address or range to restrict communications. A qualifier is an exception to the filter rule that specifies a protocol/port or IP address or range. Qualifiers are listed in a qualifier set, which can be added to a filter. A filter that includes one or more qualifier sets is called a qualified filter. You can add new or existing qualifier sets to a filter, and new qualifier sets that you add can be saved so that you can add them to additional filters. To add a qualified filter to a filter list, do the following: 1. On the Filters page, select the Filter List heading in the Filters Tree. 2. On the Filter Lists page, select the link for the filter list that you want to add a qualified filter to. 3. On the Filter List page, click Add Qualified Filter at the bottom of the page. 4. On the Create Qualified Filter dialog box, select Range or IP from the Type list to specify whether the filter applies to a range of IP addresses, or a single address. 5. Select the appropriate IP version (where 4 is used for IPv4) from the IP Version list. Note: If you select Both, the wildcard value is entered, and you cannot enter any other values on this page. 6. Specify the IP address or range to filter, as follows: If you selected IP from the Type list, enter the address to filter in the IP Address box using dot-decimal notation for an IPv4 address. Optionally, specify a subnet range by entering the IP address and subnet mask in CIDR notation in the IP Address box or by entering a subnet mask for the IP address in the Mask box. If you enter the subnet mask in the IP Address box, the Mask box is dimmed. (If you selected Range from the Type list, the IP Address box and Mask box are dimmed.) If you selected Range from the Type list, enter the first address in the range in the IP Start box, and enter the last value in the range in the IP End box. (If you selected IP Address in the Type list, the IP Start box and IP End box are dimmed.) 7. Click Save to save the filter, or click Next and do the following to add one or more qualifier sets to the filter (for example, specific protocols or port numbers): a. On the Qualifier(s) for IP dialog box, click New to create a new qualifier set. b. On the Qualifiers List>>New screen, select the Protocol/Port tab to add an include or exclude protocol/port qualifier set, or select the IP tab to add an exclude IP address or range qualifier set, and then click Add. Note: A qualifier set can only include Protocol/Port qualifiers or IP qualifiers. To include both Protocol/Port qualifiers and IP qualifiers in a filter, you must create more than one qualifier set. c. Enter a unique name for the qualifier set in the Name box

84 General Stealth Configuration Procedures Note: You can create a qualifier set without entering a name; however you can only use this qualifier set with the filter list that you are creating it for. Unnamed qualifier sets will not appear in the list of available qualifier sets for filter lists other than the one they were created for. d. Optionally, enter a description for the qualifier set in the Description box. e. If you are adding a Protocol or Port qualifier, do the following: Select Include or Exclude from the Include/Exclude list. Select the desired protocol or protocols from the Protocol list. If you select Include, you can select * from the Protocol list to include all protocols. If you select Exclude, you can select multiple protocols to exclude. To select more than one protocol to exclude, hold the Ctrl key and click the desired protocols in the list. If you selected Include, and you selected the TCP or UDP protocol, specify local and remote ports to filter inbound and outbound traffic in the Local Port box and Remote Port box. In the Local Port and Remote Port boxes, you can enter a wildcard (*), a single port between 1 and 65535, or a range of ports (separated by a hyphen). If you specified a range of ports or a wildcard, and you want to specify ports to exclude from that range, select the Except option, and specify the ports to exclude. Note: UPD protocol is not supported by Stealth(cloud) for AWS. See Local and Remote Port Filtering for more information. f. If you are adding an IP qualifier, select IP or Range from the Type list, select 4 from the Version list, enter the desired IP Address and optionally enter a valid subnet mask in the Mask box, or IP Start and IP End (if you selected Range). Notes: IP qualifiers within the qualifier set cannot overlap, and each must be valid within the address range specified for the filter list. g. If you added more than one qualifier to the qualifier set, you can use the arrow buttons on the right side of the dialog box to specify the priority order of the qualifiers in the set. To clear all of the qualifiers in the set, click Clear. To delete a single qualifier from the set, select it and click Delete. h. When you have finished adding and ordering the qualifiers, click Save Qualifier to save the qualifier set. i. Click Back at the bottom of the dialog box to return to the Qualifiers List. The new qualifier sets that you added to the filter display on the Qualifier(s) List for IP dialog box. Qualifier sets are used in the order that they appear in this list

85 General Stealth Configuration Procedures j. To change the priority ordering of the qualifier sets, click Next; otherwise, click Save to save the filter list, including all filters and qualifiers that you added. k. If you clicked Next, on the Change priority for IP dialog box, select and drag the qualifier sets in the desired order, and then click Save to save the filter list including all filters and qualifiers that you added, or click Back to make additional changes to the qualified filter. To view and modify your qualifiers, or to create additional qualifiers that you can assign to qualified filters, select the Qualifier heading in the Filters Tree Adding and Configuring Filter Sets A filter set is a group of filter lists that you apply to a COI or to a role to control network traffic with specific endpoints. Adding a Filter Set To add a new filter set, do the following: 1. On the Filters page, in the Filters Tree, select the Filter Set heading. 2. On the Filter Sets page, click Add at the bottom of the page. 3. On the Create/Modify Filter Set dialog box, enter a name for the filter set in the Name box. 4. Optionally, enter a description for the filter set in the Description box. 5. To add filter lists to the new filter set, click Select Filter List. The Add Allowed and Denied List dialog box appears, and displays all available filter lists. 6. On the Add Allowed and Denied List dialog box, select the Allow or Deny option to set the filter lists within this set to either allow or deny traffic. Note: All filter lists must be set to either allow or deny; you cannot mix allow and deny filter lists within the filter set. 7. Select the check box next to each filter list that you want to include in this filter set. If you selected the Allow option, the filter list is included in the filter set with the behavior set to allow communication with the addresses specified in the list. If you selected the Deny option, then the filter list is included in the set with the behavior set to deny communication with the addresses specified in the list. Filter lists are processed in the order in which they appear within the filter set. 8. To reorder the filter lists, ensure that the lists that you want to include in the filter set are selected, and then click Change Priority. 9. On the Change Priority dialog box, drag the filter lists into the order in which you want them to be used, and click Save. 10. Click Save to add the filter list or lists and create the filter set

86 General Stealth Configuration Procedures Adding Filter Lists to an Existing Filter Set To add additional filter lists to a filter set, or to change the allow and deny settings of the filter lists within a filter set, do the following: 1. On the Filters page, in the Filters Tree, select the Filter Set heading. 2. In the right pane, select the row for the filter set that you want to modify. Note: Do not click the link for the filter set. 3. Click Modify at the bottom of the page. 4. On the Create/Modify Filter Set dialog box, click Select Filter List. The Add Allowed and Denied List dialog box appears, and displays all available filter lists. 5. On the Add Allowed and Denied List dialog box, select the Allow or Deny option to set the filter lists within this set to either allow or deny traffic. Note: All filter lists must be set to either allow or deny; you cannot mix allow and deny filter lists within the filter set. 6. Select the check box next to each filter list that you want to include in this filter set. If you selected the Allow option, the filter list is included in the filter set with the behavior set to allow communication with the addresses specified in the list. If you selected the Deny option, then the filter list is included in the set with the behavior set to deny communication with the addresses specified in the list. Filter lists are processed in the order in which they appear within the filter set. 7. To reorder the filter lists, ensure that the lists that you want to include in the filter set are selected, and click Change Priority. 8. On the Change Priority dialog box, drag the filter lists into the order in which you want them to be used, and click Save. 9. Click Save to add the filter list or lists and update the filter set. To remove a filter list from a filter set, do the following: 1. On the Filters Tree, select the Filter Set heading. 2. In the right pane, select the filter set that you want to modify by clicking the table row that includes the filter set. Note: Do not click the filter set link. 3. Click Modify at the bottom of the page. 4. On the Create/Modify Filter Set dialog box, click Select Filter List. The Add Allowed and Denied List dialog box appears, and displays all available filter lists. 5. Clear the check box next to each filter list that you want to remove from the filter set, and click Save

87 General Stealth Configuration Procedures Changing the Priority of Filters and Filter Lists Filters and filter lists are processed in the order in which they are arranged within a filter list. To rearrange filters or filter lists, do the following: 1. Select Filters in the menu bar. 2. In the Filters Tree, select the Filter List heading. 3. In the right pane, select the link for the filter list that includes the filters and filter lists that you want to reorder. 4. On the Filter List page, click Change Priority at the bottom of the page. 5. On the Change Priority dialog box, drag the filter lists or filters in the order in which you want them to be processed. 6. Click Save Assigning COIs, Users, and Filters to Roles After you have added roles, COIs, and users on the Configure page, and added filters on the Filters page, you use the Provision page to assign these components. Note: On this page, you can click the Validate button to validate your configuration, including: The configuration includes at least one Authorization Service URL. The configuration includes a License Service URL. The configuration includes a Service Role. All other roles associated with the configuration include at least one user or group. However, for Management Server instances running in a Stealth(cloud) environment, there is no License Service URL, and so you should ignore any warnings you receive that a license server is not specified. If you receive any other errors or warnings, resolve them before continuing Assigning COIs To assign a COI to a role, do the following: 1. Select Provision in the menu bar. 2. From the Configuration drop-down list (next to the Validate button), select the configuration that includes the role that you want to assign a COI to. 3. Select the COI tab. 4. In the left pane, select the arrow next to the configuration name and select the arrow next to Roles so that you can see the roles you created for the configuration. 5. In the left pane, select the check box for the role or roles that you want to assign the COI or COIs to. You can select a maximum of two roles at one time

88 General Stealth Configuration Procedures 6. In the COI table, select the COI or COIs that you want to assign to the role. You can select multiple COIs at one time by holding down the Ctrl button and selecting multiple COIs. 7. Click the arrow between the left pane and the COI table to copy the COI under the role name. 8. Sort the COIs in the order in which they should be used. To re-sort the COIs, in the left pane (under the role name), drag the COIs into the appropriate order. Note: COIs are processed in the order in which they are listed, so you might want to sort them in a specific order. For example, an endpoint in the Finance department might include a COI named FinanceCOI and a COI to maintain communication with the Authorization Service named AuthCOI. In that case, you probably want to sort the FinanceCOI above the AuthCOI. 9. Click Save. To remove a COI from a role, under the role name, right-click the COI name, and then click Remove Assigning Users To assign users to a role, do the following: 1. Select Provision in the menu bar. 2. From the Configuration drop-down list (next to the Validate button), select the configuration that includes the role that you want to assign the user to. 3. Select the User tab. 4. In the left pane, select the arrow next to the configuration name and select the arrow next to Roles so that you can see the roles you created for the configuration. 5. In the left pane, select the check box next to the role that you want to assign the user to. Notes: For Stealth(cloud), endpoint instances can only be assigned to one role. Do not assign more than one role to an endpoint instance. You cannot add users to a Service Role. 6. In the User table, select the user that you want to assign to the role. You can select multiple users at one time by holding down the Ctrl button and selecting multiple users. 7. Click the arrow between the left pane and the User table to copy the user under the selected role. 8. Click Save. To remove a user from a role, under the role name, right-click the user name, and then click Remove

89 General Stealth Configuration Procedures Applying Filter Sets to COIs and Roles After you have created your filter sets, you can apply them to COIs and roles in your Stealth network to control communications between your endpoints. Note: You can apply only one filter set to each role as a clear text filter, and you can apply only one filter set to each COI (that is used in each role) as a Stealth filter. You can apply different filter sets to different roles as clear text filters, and if a COI is used in multiple roles, you can apply different filter sets as Stealth filters to the COI in each role where it is used. However, if the same user or group is assigned to multiple roles, you must apply the same filter set as a clear text filter to each role. (If you apply different filter sets, and if those filters conflict, this can result in unpredictable behavior as to which clear text filter is applied.) See 3.5 Filtering for more information on how filters work when applied to COIs and roles. To assign a filter set to a COI or role, do the following: 1. Select Provision in the menu bar. 2. From the Configuration drop-down list (next to the Validate button), select the configuration that includes the COIs or roles to which you want to apply filters. 3. Select the Filter tab. 4. In the left pane, select the arrow next to the configuration name and select the arrow next to Roles so that you can see the roles you created for the configuration. Select the arrow next to the role check boxes and select the arrow next to COIs so that you can see the COIs you added to the roles. 5. In the left pane, select the COI or role that you want to apply the filter set to. You can select a maximum of two COIs and two roles at one time. Filters work differently, depending on whether they are applied to COIs or roles, as follows: When filter sets are applied to COIs, they filter the Stealth-enabled network traffic, allowing or denying information passed between Stealth endpoints that share COIs. Filter sets applied to COIs are called Stealth filters. You can apply only one filter set to each COI (that is used in each role). When filter sets are applied to roles, they filter clear text network traffic, allowing or denying information passed between Stealth endpoints and non-stealthenabled (clear text) components. Filter sets applied to roles are called clear text filters. You can apply only one filter set to each role. 6. In the right pane, select the filter set from the filter table

90 General Stealth Configuration Procedures 7. Click the arrow between the left pane and the filter table to assign the filter set to the selected COI or role. The filter set appears under the Filter Set heading for the COI or role in the left pane. 8. Click Save. To remove a filter set from a COI or role, right-click the filter set in the left pane, and select Remove Provisioning or Reprovisioning the Authorization and Licensing Services You use the Provision Service tab on the Provision page to add an Authorization Service or License Service to a configuration so that endpoints can be authorized and licensed. You then provision the Authorization Service and License Service URLs for a configuration. When you make any other changes to the configuration, including updating COIs, filters, and roles, you must reprovision the Authorization Service. Note: On this page, you can click the Validate button to validate your configuration, including: The configuration includes at least one Authorization Service URL. The configuration includes a License Service URL. The configuration includes a Service Role. All other roles associated with the configuration include at least one user or group. However, for Management Server instances running in a Stealth(cloud) environment, there is no License Service URL, and so you should ignore any warnings you receive that a license server is not specified. If you receive any other errors or warnings, resolve them before continuing. To provision the Authorization Service and License Service, do the following: 1. Select Provision in the menu bar. 2. From the Configuration drop-down list (next to the Validate button), select the configuration that you want to provision. 3. Select the Provision Service tab. 4. If an arrow appears next to the Authorization Service heading, select the arrow next to that heading so that you can see any URLs that are currently assigned. 5. In the Configuration list, right-click each Authorization Service URL, and then click Provision. The Authorization Service is provisioned with the information for the configuration

91 Section 5 Administering the Environment See the topics in this section for help with administering the Stealth environment Understanding Reprovisioning When you make any other changes to the configuration including updating COIs, filters, and roles, or changing an AuthGroup name or IP address then you should reprovision the Authorization Services by performing the following procedure. Note: If you update COIs, filters, or roles but do not reprovision the Authorization Services, the endpoints will use the previous configuration. If you update the AuthGroup name or IP address but do not reprovision the Authorization Services, the endpoints will fail to connect. Therefore, you should always be sure to reprovision after making changes to the configuration or AuthGroup. (Depending on the requirements of your network environment, you might want to delay configuration changes and reprovisioning until non-business hours, or you might want to update the configuration for various Authorization Services and reprovision them at different times to control when endpoints are reauthorized.) 1. Select Provision in the menu bar. 2. Select the Provision Service tab. 3. In the Configuration drop-down list (next to the Validate button), select the appropriate configuration. 4. In the left pane, click the arrow next to the configuration name, and then click the arrow next to the Authorization Service heading to view the list of Authorization Service (Auth Web) URLs. 5. Select the first Authorization Service URL in the list. Right-click the URL, and select Provision. 6. Repeat the previous step to provision any additional Authorization Service URLs in the list. 7. Click Save at the bottom of the page. Note: On this page, you can click the Validate button to validate your configuration, including: The configuration includes at least one Authorization Service URL. The configuration includes a License Service URL

92 Administering the Environment The configuration includes a Service Role. All other roles associated with the configuration include at least one user or group. However, for Management Server instances running in a Stealth(cloud) environment, there is no License Service URL, and so you should ignore any warnings you receive that a license server is not specified. If you receive any other errors or warnings, resolve them before continuing Backing Up the Enterprise Manager Database You should back up the Enterprise Manager database on a regular schedule or after a significant configuration change. The backup can be used in case of a problem with the Management Server. In that case, you can install the Management Server software on the new system, restore the database, and restart the Enterprise Manager services. For the Enterprise Manager database, some maintenance is performed automatically by the software installation process, but additional manual maintenance is required Database Backup Overview During initial software installation, the following databases are created: Event Log (emdb) Stores event records that can be viewed from the Enterprise Manager portal Portal Configuration (liferaydb) Stores portal accounts, privileges and other settings CIM Server repository (pegasusroot, rootcimv2, rootpginternal, rootpginterop) Stores information required by the Pegasus CIM Object Manager Stealth Configuration repository (rootuisstealth2) Stores Stealth configuration information, including static items (such as COIs, roles, and systems) and dynamic items (such as Management Server statistics) When you upgrade the version of Enterprise Manager software, the content of the databases is automatically maintained. The Event Log and Portal Configuration databases are unchanged. However if required due to a repository definition change the other two databases change as follows: The CIM Server repository database is replaced (the old definition is no longer needed). The Stealth Configuration repository database is recreated. Note: Before removing existing software, the repository is backed up to the folder C:\ProgramData\Unisys\Stealth\EnterpriseMgmt\RepositoryBackups\rootuisstealth2. When the updated software is installed, the backup file is processed to restore content of the repository. Note that these backups do not replace the need for manual full database backups

93 Administering the Environment Certificate Backup Overview During the software installation, the Management Certificate is created, which is used to encrypt sensitive data stored in the repository. A copy of this certificate is required if it is necessary to restore the repository. You should save both the public and private keys for the certificate to a secure location, and if needed, you can reinstall the certificate in the Windows Certificates Personal store for the Management Server administrator user. See Backing up the Database and Saving Certificates for information about saving the certificate Backing up the Database and Saving Certificates As with any database, full backups are critical to maintaining the integrity of your Management Server and Stealth network configuration in catastrophic failures, such as storage unit failure or server hardware failure. These backups must be stored safely so that they are available, should recovery be necessary. All repository backup files generated during the software upgrade process must also be safely backed up for possible future use. These might be needed to restore content during software installation. Full backups of all databases should be performed Before and after an Enterprise Manager Software upgrade Before and after any significant configuration changes On a regular periodic schedule It is recommended that backups be organized by software level. (For more information, see Restoring the Database.) Stealth Management services that access the databases must be temporarily stopped during backup or recovery. Database backup or recovery can be performed using any tools or mechanisms you have in place. If you choose to, you can use the MySQL utilities installed with the Enterprise Manager software to perform a backup, as follows: 1. Access Computer Management and access Services. 2. Stop the Pegasus CIM Object Manager service. 3. Verify that the Unisys Stealth COI Management service also stopped, and if it did not, stop that service as well. 4. Open a command prompt using the Run as administrator option. 5. Change to the C:\Program Files\MySQL\MySQL Server 5.6\bin directory. 6. Execute the following commands using appropriate MySQL user name and password, and the file name of your choice for the output file. (For example, for the Event Log database backup, you could name the output file emdbbackup. )

94 Administering the Environment Notes: Be sure to use two hyphens before the user, password, and database entries. (For example, type - -user, rather than -user.) The MySQL root password might be the same password that you used to log on to the Management Server, or it might be a unique password. You created this password when you launched the Management Server instance. In the following commands, italicized text designates a variable, such as MySQL root password and output-file-name-1. Enter the following commands: mysqldump --user=root --password=mysql root password --databases pegasusroot rootcimv2 rootpginternal rootpginterop rootuisstealth2 > output-file-name-1 mysqldump --user=root --password=mysql root password --databases emdb > output-file-name-2 mysqldump --user=root --password=mysql root password --databases liferaydb > output-file-name-3 7. Restart the Pegasus CIM Object Manager and Unisys Stealth COI Management services. 8. Store the output files in an appropriate location. 9. Export the Management Certificate, including the public and private keys, and store it with the output files. The Management Certificate is located in the store for the user name that you used to log on to the Management Server when you installed the software (the user account that the Stealth Enterprise Manager services run under). See Exporting a Certificate for more information about how to export certificates. Note: You can back up other certificates, if you choose to; however, only the Management certificate is used to encrypt data in the repository and must be backed up. (Other certificates can be recreated if needed.) See 3.3 Certificates Overview for more information on certificates Restoring the Database Note: Databases should only be restored from backups generated from the current level of Enterprise Manager software. The following procedure describes how to restore your database and your existing configurations. In the event that your database needs to be restored, do the following: 1. If you are installing the Management Server software on a new system, install the saved certificate in the Windows Certificates Personal store for the Management Server administrator user. 2. When you are asked Do you want to restore a previously saved Stealth Enterprise Manager configuration database? select No (nothing to restore)

95 Administering the Environment Note: After you complete this procedure, both the database and configuration will be restored, which is why you should not restore the configuration during the installation process. 3. On the Management Server, stop the Pegasus CIM Object Manager and Unisys Stealth COI Management services. Note: If the database is being restored on a new system, you must import the Management Certificate you created during the initial installation and saved during the Backup Procedure. See 5.4 Working with Certificates (Importing and Exporting) for more information on how to import this certificate. 4. Open a command prompt, and browse to the C:\Program Files\MySQL\MySQL Server 5.6\bin directory. 5. For each database that you need to restore, execute the following command using appropriate user name, password, and file name values (using the files you created during the Backup Procedure). Note: Be sure to use two hyphens before the user and password entries. (For example, type - -user, rather than -user.) mysql.exe --user=mysql user name --password=mysql root password < output-file-name 6. Start the Pegasus CIM Object Manager and Unisys Stealth COI Management services Change Password Dialog Box (Changing the Enterprise Manager Interface User Account Password) You use the Change Password dialog box to change the password for the Enterprise Manager interface user account that is currently logged on to the Enterprise Manager interface. To access the Change Password dialog box, click Change Password at the top of the Enterprise Manager interface. To change the password for the Enterprise Manager user account that is currently logged on to the Enterprise Manager interface, do the following: 1. On the Change Password dialog box, enter the current password in the Old Password box. 2. Enter the new password in the New Password and Confirm New Password boxes. 3. Click Save. 4. Click Sign Out to log out of the Enterprise Manager interface, and then log on again using the new password

96 Administering the Environment 5.4. Working with Certificates (Importing and Exporting) Importing a Certificate to the Personal Store If you need to import a certificate to the personal store, do the following: 1. Log on to the system to which you want to import the certificate. 2. Launch Certificates Manager. To do so, from the Start menu, enter certmgr.msc in the Search box. 3. In the left pane of Certificates Manager, click the Personal folder, right-click the Certificates folder, point to All Tasks, and then click Import. 4. On the Welcome screen, click Next. 5. Browse to the location of the certificate file you want to import, select it, and click Open. Note: If you do not see the file, ensure that the file type is set to Personal Information Exchange. 6. When prompted, enter the password that you used when you exported the certificate. 7. Select the Include all extended properties check box. 8. If you want to back up this key in another location, select the Mark this key exportable check box. 9. Click Next, and then click Next. By default, the certificate is imported into the Personal store. 10. Click Finish, and then click OK to close the Certificate Import Wizard Exporting a Certificate If you need to export a certificate, do the following: 1. Log on to the system from which you want to export the certificate (using the credentials for the user associated with that certificate). 2. Launch Certificates Manager. To do so, from the Start menu, enter certmgr.msc in the Search box. 3. In the left pane of Certificates Manager, click the Personal folder, and then click the Certificates folder. 4. Right-click the certificate that you want to export, point to All Tasks, and then click Export. The Certificate Export Wizard appears. 5. On the Welcome screen, click Next. 6. Select Yes, export the private key, and then click Next

97 Administering the Environment 7. Under Personal Information Exchange, select the Export all extended properties check box, and then click Next. 8. When prompted to enter a password, enter a password for the certificate and make a note of it. 9. Enter a name and location where you want to save the file. For example, if you have multiple administrators who are sharing certificates and you are exporting the AdminUser certificate, save the file as AdminUser.pfx in a file location that can be accessed by multiple user accounts. 10. Click Finish, and then click OK to close the Certificate Import Wizard. 11. Ensure that the certificate file is saved in a location that is accessible to the user account or system to which you want to import it Administering Linux Endpoints See the following topics for information on administering Linux endpoints Linux Multiple IPv4 Address Configurations Linux Stealth endpoints support multiple IPv4 addresses configured on a Stealth-enabled interface. This topic includes considerations and configuration examples if you want to configure multiple Linux IPv4 addresses. Considerations Note the following considerations when implementing multiple Linux IPv4 addresses: All configured addresses on a Linux Stealth-enabled interface (for example, eth0). Dynamic addition and removal of IP addresses is supported. Modifying the primary or first address on a Linux Stealth-enabled interface will result in all tunnels being reset. Additional IP addresses configured for a Linux Stealth-enabled interface can be configured as alias adapters. For Linux network adapters managed by Network Manager, only a single IP address per interface is supported. Configuration Examples Dynamically Adding and Removing IP Addresses For all supported Linux operating systems, IP addresses can be temporarily added or removed with the ip addr command. For example, to add an IP address to a Linux Stealth virtual adapter, enter the following command:

98 Administering the Environment ip addr add /24 dev eth0 For example, to delete an IP address from a Linux Stealth virtual adapter, enter the following command: ip addr del /24 dev eth0 Permanent Configuration Using Alias IP Address Note: The following information provides basic examples of how alias IP addresses can be configured. For all supported Linux operating systems, alias IP addresses can be defined and individually started and stopped once Stealth is running. Each Linux operating system configures alias IP addresses differently. Linux operating systems follow the convention of defining alias adapters with the primary adapter name and a number delimited by a colon (for example, eth0:1). Although the alias adapters are started with the primary adapter, each alias adapter can then be started and stopped by the standard ifconfig commands ifup and ifdown, respectively. For example, to start an alias adapter for Linux, enter the following command: ifup eth0:1 For example, to stop an alias adapter, enter the following command: ifdown eth0:1 Configuration Details by Operating System (for Alias IP Addresses) There are several configuration details that are dependent on the specific operating system (Ubuntu, Red Hat Enterprise Linux, SUSE Enterprise Linux), as follows: Ubuntu Edit the /etc/network/interfaces file and add alias adapter statements in addition to the primary Stealth-enabled interface. To start and stop the alias adapters when the primary interface is started, the post-up and post-down directives must be used. The following is an example of /etc/network/interfaces when three alias adapters are configured: iface eth0 inet static address netmask post-up ifup eth0:1; ifup eth0:2;ifup eth0:3 post-down ifdown eth0:1;ifdown eth0:2; ifdown eth0:3 iface eth0:1 inet static address netmask iface eth0:2 inet static

99 Administering the Environment address netmask iface eth0:3 inet static address netmask Red Hat Enterprise Linux Alias adapters on Red Hat Enterprise Linux are automatically started when the primary adapter is started. Alias adapters can be configured by adding alias named ifcfg configuration files to the /etc/sysconfig/network-scripts directory. The adapter name should be given the name of the primary Stealth-enabled interface and the alias suffix (for example, ifcfg-eth0:1). The primary adapter configuration (that is, ifcfg-eth0) should be configured normally. Additional alias adapter configurations can then be added. The following are example contents of the standard ifcfg-eth0 file: DEVICE=eth0 TYPE=Ethernet ONBOOT=no NM_CONTROLLED=no BOOTPROTO=none IPADDR= NETMASK= The following are example contents of an alias ifcfg-eth0:1 file: DEVICE=eth0:1 TYPE=Ethernet ONBOOT=no HWADDR= NM_CONTROLLED=no BOOTPROTO=static IPADDR= NETMASK= The following are example contents of an alias ifcfg-eth0:2 file: DEVICE=eth0:2 TYPE=Ethernet ONBOOT=no HWADDR= NM_CONTROLLED=no BOOTPROTO=static IPADDR= NETMASK= SUSE Linux Enterprise Server Alias adapters on SUSE Linux Enterprise Server are automatically started when the primary adapter is started. Alias adapters are configured by adding parameters in the Stealth-enabled interface configuration file (that is, /etc/sysconfig/network/ifcfg-eth0) that define additional aliases. The original parameters used to define the Stealthenabled interface do not need to change. These additional alias parameters are

100 Administering the Environment named the same as the parameters for the primary adapter, except with a numeric extension. Alias adapter names are specified with LABELn parameter. The following are example contents of the /etc/sysconfig/network/ifcfg-eth0 file with three alias adapters defined: BOOTPROTO= static IPADDR= NETMASK= STARTMODE= manual USERCONTROL= no LABEL1= 1 IPADDR1= NETMASK1= LABEL2= 2 IPADDR2= NETMASK2= LABEL3= 3 IPADDR3= NETMASK3= Linux Multiple Network Interface Configurations Linux Stealth endpoints support binding to multiple interfaces. This enables Linux endpoints to run a single Stealth service to secure multiple interfaces. These interfaces can be either physical adapters or virtual interfaces (for example, bonded interfaces). Note: When a virtual interface is Stealth-enabled, all associated physical adapters are automatically Stealth-enabled; there is no need to specify those physical adapters separately. Configuration Updates In the system.ini file, the adapter_list parameter can be used to select interfaces that should be Stealth-enabled. To specify a list of interfaces that should be Stealth-enabled, you must list the interface names in a comma-separated list. Interfaces that do not appear in the list will not be Stealth-enabled and will allow all traffic to pass in clear text. To Stealth-enable all interfaces, use the special character asterisk (*) or leave the default value in the adapter_list parameter. Note: These parameters must not include any spaces separating or following the list. The adapter_list parameter identifies which physical adapters or virtual interfaces should be Stealth-enabled. This parameter appears like either of the following: adapter_list=eth0,eth1,eth2 (for three physical adapters) or adapter_list=bond0 (for a virtual bonded interface made up of two physical adapters) adapter_list=*

101 Administering the Environment Call-Out Script Updates Note: Normally these scripts do not require modification, but you can use them if necessary to customize the start and stop procedures of Stealth virtual adapters. The endpoint call-out scripts use a new environment variable named STEALTHD_ADAPTER_LIST. This is a comma-separated string that lists the interfaces that are Stealth-enabled. For example, if the administrator configures adapter_list=* and the system has interfaces eth0 and eth1, the environment variable STEALTHD_ADAPTER_LIST is set to eth0,eth1. In contrast, if no interfaces are configured as Stealth-enabled, the STEALTHD_ADAPTER_LIST is set to NONE. Restrictions The multiple network interface feature is not supported in Stealth SRA mode. If you want an interface to be Stealth-enabled, that interface must exist when the Stealth endpoint software is started. If you add an interface later, you must verify that the interface is configured to be Stealth-enabled (as described previously in this topic), and then you must restart the Stealth software Enabling or Disabling Stealth Modes and Stealth for Linux Endpoints Enabling or Disabling Stealth on Boot The Stealth service is configured to start when the system boots. To prevent the service from starting at boot, enter the following command: For Red Hat Enterprise Linux and SUSE Linux Enterprise Server, enter the following command: chkconfig stealthd off For Ubuntu Linux, enter the following command: update-rc.d stealthd disable Enabling or Disabling the Stealth Service To disable Stealth on a Linux system, enter the following command: service stealthd stop To enable Stealth, enter the following command: service stealthd start

102 Administering the Environment Configuring Syslog for Linux Endpoints You can configure Linux endpoints for logging using syslog software. The syslog software configuration depends on the version of Linux running on the endpoint. For Red Hat Enterprise Linux endpoints, you use syslog or rsyslog. For SUSE Linux Enterprise Server endpoints, you use syslog-ng. For Ubuntu Linux endpoints, you use rsyslog. Configuring syslog or rsyslog for Red Hat Enterprise To configure syslog or rsyslog, do the following: Note: For more information on installing or configuring rsyslog, refer to 1. Edit the /etc/stealth/system.ini file, as follows: a. Set syslog=true. b. Set syslog_facility=daemon. 2. Edit the /etc/syslog.conf file, the /etc/rsyslog.conf file, or one of the included rsyslog files in /etc/rsyslog.d/ to define logging for the daemon facility, as follows: a. For rsyslog only, ensure that the imuxsocket module is loaded to enable Unisys socket input. For example: $ModLoad imuxsock.so b. Configure a syslog style selector (or rule) for the daemon facility to specify the logging priority and action. For example: daemon.info /var/log/messages Note: The *.info /var/log/messages entry might already be configured. If it is configured, it will include the daemon facility, but only at info priority. In this example, the source, daemon, logs from daemons. The suffix.info specifies logging at the info priority and higher. The style selector specifies that the daemon takes the action of logging to the file /var/log/messages. To capture all debug messages generated by the stealthd daemon, change the configuration to include all messages directed to the facility. For example: daemon.* /var/log/messages In this example, all messages that the stealthd directs to the daemon facility will be captured in /var/log/messages. Note: For rsyslog only, it is recommended that you disable message rate limiting when generating a large number of log messages (for example, if you set the logging priority to debug) to prevent messages from not being logged. To disable message rate limiting, specify the following after each $ModLoad line:

103 Administering the Environment $SystemLogRateLimitInterval 0 For endpoints running Red Hat Enterprise Linux 7.x, you must also disable rate limiting by adding the following line to the /etc/systemd/journald.conf file: RateLimitInterval=0 3. Enter the following command to restart the syslog or rsyslog service: service <service name> restart That is, enter service syslog restart, or enter service rsyslog restart. 4. Enter the following command to restart the Stealth service: Configuring syslog-ng for SUSE Linux Enterprise Server To configure syslog-ng, do the following: Note: For more information for configuring syslog-ng, refer to 1. Edit the /etc/stealth/system.ini file, as follows: a. Set syslog=true. b. Set syslog_facility=daemon. 2. Edit the /etc/syslog-ng/syslog-ng.conf file to define logging for the daemon facility, as follows: a. Ensure that a source statement includes a UNIX socket source for the/dev/log filename. For example: source src { unix-dgram("/dev/log"); }; b. Ensure that there is a filter statement that includes the daemon facility For example: filter f_messages { not facility (news, mail); }; c. Define a destination statement that specifies the file /var/log/messages. For example: destination messages { file("/var/log/messages"); }; d. Define a log statement to associate the log source, filter, and destination. For example: log { source(src); filter(f_messages); destination(messages); }; In this example, all facilities, except for the news and mail facilities, are logged to the file /var/log/messages.. 3. Enter the following command to restart the syslog-ng service: service syslog restart 4. Enter the following command to restart the Stealth service:

104 Administering the Environment service stealthd restart Configuring rsyslog for Ubuntu Linux To configure rsyslog, do the following: Note: For more information on installing or configuring rsyslog, refer to 1. Edit the /etc/stealth/system.ini file, as follows: a. Set syslog=true. b. Set syslog_facility=daemon. 2. Edit the /etc/rsyslog.conf file or one of its included files in /etc/rsyslog.d/ to define logging for the daemon facility, as follows: a. Ensure that the imuxsocket module is loaded to enable Unisys socket input. For example: $ModLoad imuxsock.so b. Configure a syslog style selector (or rule) for the daemon facility to specify the logging priority and action. For example: daemon.info /var/log/syslog In this example, the source, daemon, logs from daemons. The suffix.info specifies logging at the info priority and higher. The style selector specifies that the daemon takes the action of logging to the file /var/log/syslog. To capture all debug messages generated by the stealthd daemon, change the configuration to include all messages directed to the facility. For example: daemon.* /var/log/syslog In this example, all messages that the stealthd directs to the daemon facility will be captured in /var/log/syslog. Note: It is recommended that you disable message rate limiting when generating a large number of log messages (for example, if you set the logging priority to debug) to prevent messages from not being logged. To disable message rate limiting, specify the following after each $ModLoad line: $SystemLogRateLimitInterval 0 3. Enter the following command to restart the rsyslog service: service rsyslog restart 4. Enter the following command to restart the Stealth service:

105 Administering the Environment Accessing the Linux man Pages The man pages are included in the installation package and readable from your system. To access these pages, do the following: To access the man pages for the program, from a terminal window enter man stealthd To access the man pages for the stconfig program, from a terminal window enter man stconfig In addition, the installation package includes a default system-wide configuration file named etc/stealth/system.ini.example. This is a reference document for all configuration options which can be set in that file, with explanations of each option and default value

106 Administering the Environment

107 Section 6 Troubleshooting This section provides troubleshooting information for your Stealth environment. Review this section for information on diagnosing and resolving problems in your environment Resolving Common Problems If you are having trouble launching or connecting to your instances, or problems authorizing or communicating with Stealth-enabled endpoints, do the following: Ensure that instances launched from your VPC are able to access the AWS CloudFormation services. In order to launch your Management Server instance and endpoint instances, these instances must be able to access the CloudFormation services using either a public IP address or NAT. If your instances do not have a method to access the CloudFormation services, they will fail to launch after about an hour. For general information on configuring IP addressing for your VPC and instances, see For specific information about modifying the IP addressing for your instances, see Ensure that you created an Administrative and Diagnostics System, and ensure that you can connect to it. Ensure that you created a Management Server instance. Ensure that the endpoint instances that you want to communicate include the same COI. See 1.6 Understanding the Initial Stealth(cloud) for AWS Environment for information about user roles and their communication based on the configuration (Segmented or Tiered). Ensure that your Management Server instances and your endpoint instances are running. If your instances are not running and cannot be started, contact Amazon AWS support. If you have problems using the Enterprise Manager interface on the Management Server instance, ensure that you meet all of the requirements in 6.3 Enterprise Manager Interface Requirements. Depending on your operating system, review the Windows application and system event logs or the Linux Syslog for warning and informational messages that can provide guidance and suggestions

108 Troubleshooting For Windows endpoints, view the status of the Stealth connection using the Stealth Applet. For Linux endpoints, view the status of the Stealth connection using the stconfig -S command. Verify that there are no firewalls blocking communication. For more information about configuring firewall settings to enable communications for Windows endpoint instances, see 6.4 Updating Firewall Settings. Web proxy servers (HTTP proxy servers) can interfere with Stealth authorization; ensure that there are no web proxy servers between Stealth endpoints and the Management Server instance. Verify the status of the Stealth services. If any of the Stealth services are not in a Running state, do the following: - For Windows: Verify that the Unisys Stealth Logon Service, Unisys Stealth PreLogon Service, and Unisys Stealth Protocol Service are running. If any service status is paused, restart the Unisys Stealth Protocol Service, which automatically restarts the other two services. - For Linux: Log on with root privileges, and enter the following to see the state of the stealthd daemon: service stealthd status If the services are in the process of connecting, wait a few minutes, then try to verify the status of the services again. Examine your configuration and provisioning information using the Enterprise Manager interface, and verify all of the following: - On the Configure page, on the User tab, ensure that the user name is spelled correctly. - On the Filters page, verify that your filters are configured correctly and are up to date. On the Filter List page, select the AWS Services filter list, and check the timestamp on the child filter list to see if the filter list was recently updated. If the AWS Services filter list has been updated, you must reprovision the Authorization Service for each configuration in your environment to update your endpoint instances and Management Server instance with the new filter list. See Understanding Filters for Stealth(cloud) for AWS for more information. - On the Provision page, on the Filter tab, verify that the appropriate filters have been included in each role or COI. - On the Provision page, on the COI tab, ensure that the correct COIs are assigned to each role. Ensure that each endpoint includes a Service COI and a Workgroup COI. Note: The Management Server must share a Service COI with the endpoints it is authorizing. This enables the endpoints to be authorized and obtain their COIs. In addition, the Management Server must share a Workgroup COI with the endpoints it authorized for licensing and logging purposes, so that the Authorization Service can monitor activity and ensure that the endpoint is still active

109 Troubleshooting - On the Provision page, on the Provision Service tab, ensure that you provisioned the Authorization Service (by right-clicking the Authorization Service and selecting Provision). Verify that your environment includes enough licenses for your endpoints (and verify that there are no license errors in your log files). Reboot the Management Server instance Configuring Clear Text Filters to Allow Applications Blocked by Stealth By default, Stealth(cloud) for AWS prevents all clear text communication to and from a Stealth-enabled endpoint instance, except for IP addresses associated with the Amazon services and the Administration and Diagnostics System or Systems. If your endpoint instances include applications that communicate using clear text, you can add filters to allow that communication. Stealth clear text filters use IP addresses, so you must determine which IP addresses need to be allowed using clear text filters. You can then create the required filters and apply the filter set to the appropriate endpoint role. Do the following: 1. Using the AWS EC2 console, identify an endpoint instance that is running an application that is being blocked. Make a note of the private IP address of this endpoint instance. 2. Log on to the Management Server instance. 3. On the Enterprise Manager interface, select Logs in the menu bar. 4. On the Logs tab, at the bottom of the page, click Show Search. 5. Do the following to add two required search filters: a. At the bottom of the Search dialog box, click Add Search Filter. b. In the first drop-down list, select Event ID. c. In the second drop-down list, ensure that the value is set to Equals. d. In the text box, enter 303. e. At the bottom of the Search dialog box, click Add Search Filter to add a second filter. f. In the first drop-down list, select Message. Note: Be sure to select Message rather than Message Type. g. In the second drop-down list, select Contains. h. In the text box, enter the private IP address of the endpoint instance that you noted at the beginning of this procedure. i. Ensure that the value in the final list box is set to AND (so that both search filters are used). j. At the bottom of the Search dialog box, click Search

110 Troubleshooting The Search dialog box closes, and the Logs page shows the results of the two search filters you entered. In the Message column, you should see results that look like the following: Stealth Tunnel <endpoint instance private IP address> failed to <application IP address> with INITRetry For example, you might see the following: [IP-AB1C2345:StealthAdmin: : ] Stealth Tunnel failed to with INITRetry 6. Make a note of the application IP addresses or IP address range listed in the messages. In the previous example, you would make a note of the IP address Caution As you create additional clear text filters to additional IP addresses and IP address ranges, you reduce the communications that are being protected by Stealth. Therefore, you should only add IP addresses you trust to clear text filters, and you should add the minimum number of IP addresses and IP address ranges required to enable communication with your applications. 7. Create a new filter list that includes the IP addresses or IP address ranges by performing the steps in 2.3 Creating New Filters and Applying Them to User Roles Enterprise Manager Interface Requirements If you have any problems viewing the Enterprise Manager interface, ensure that you meet the following requirements. Resolution and Browser Requirements The Enterprise Manager interface was tested using a resolution in the following range, and you should configure a screen resolution in this range: Minimum resolution: Maximum resolution: You must run one of the following browsers: Internet Explorer 11.x Firefox 35 or later

111 Troubleshooting Note: Stealth Enterprise Manager was qualified using Internet Explorer 11.x and Firefox 35. Because Mozilla regularly releases new versions of Firefox, if you experience any problems with a later version of Firefox, it is recommended that you use Internet Explorer 11.x. In addition, configure the following browser settings: Ensure that the pop-up blocker is disabled. Set the browser zoom level to 100%. If you are using Internet Explorer 11.x, do the following: - Ensure that Active Scripting is enabled Do the following: 1. Open Internet Explorer and select Internet options. 2. On the Internet Options dialog box, select the Security tab, and then select Custom Level. 3. Under Scripting, ensure that Active scripting is enabled. - Ensure that the Document Mode is set to Edge Do the following: 1. Open Internet Explorer, and press F On the menu that appears at the bottom of the screen, select the icon on the far right (the Document Mode icon), and then select Edge. If you are using Firefox, do the following: - Set the browser cache to 15 MB or higher. Do the following: 1. Open Firefox, and enter about:config into the address bar. 2. If you see a warning, click I ll be careful, I promise. 3. In the Search box, enter browser.cache.disk.capacity. 4. Ensure that the value is at least If the value is less than 15360, double-click browser.cache.disk.capacity, and enter a new value that is at least Ensure that JavaScript is enabled. Do the following: 1. In the Firefox about:config Search box, enter javascript.enabled. 2. Verify that javascript.enabled is set to true. If it is set to false, right-click it, and click Toggle. 3. Close the Firefox window

112 Troubleshooting TLS 1.2 Requirement The Management Server is required to use TLS 1.2. If you use Firefox, do the following: 1. Open Firefox. 2. Enter about:config into the address bar, and press Enter. 3. If a warning appears, click I ll be careful, I promise! 4. In the Search box above the list, enter TLS, and wait while the list is filtered. 5. Double-click security.tls.version.min, enter 1, and then click OK. 6. Double-click security.tls.version.max, enter 3, and then click OK. 7. Close Firefox. If you use Internet Explorer, do the following: 1. Open Internet Explorer. 2. On the Tools menu, select Internet options. 3. On the Internet Options dialog box, select the Advanced tab. 4. Under Security, verify that the Use TLS 1.2 is selected. Verify that all other Use SSL and Use TLS checkboxes are cleared. 5. Click OK to close the Internet Options dialog box Updating Firewall Settings Note: There are no client-configured firewall rules for Stealth endpoints running Linux operating systems. The following procedure applies to the Stealth Management Server instance and endpoints instances running Windows operating systems. Overview If you enable firewall protection on the Management Server instance or other Windows Stealth endpoint instances, the firewall might block the ports, IP addresses, and programs used by Stealth. If this occurs, you must add the following to the firewall and configure it to enable Stealth communication. The following table describes the required inbound and outbound ports, IP address, and programs used by Stealth

113 Troubleshooting Table 6 1. Firewall Ports, IP Addresses, and Programs Type Use Value Endpoint Direction TCP port Stealth Monitor Service Default is 443 Management Server Inbound and outbound TCP port Dynamic License Service Default is Management Server Inbound and outbound TCP port Tomcat for Enterprise Manager Default is Management Server and any endpoints used for portal administration Inbound and outbound TCP port Authorization Service configuration Port defined for the URL in the AuthService.config file (no default value) All endpoints Inbound and outbound UDP port DHCP Server 67 All endpoints Inbound and outbound UDP port DHCP Client 68 All endpoints Inbound and outbound UDP port IKE 500 All endpoints Inbound and outbound UDP port DHCPv6 Client 546 All endpoints Inbound and outbound UDP port DHCPv6 Server 547 All endpoints Inbound and outbound UDP port IKE NAT 4500 All endpoints Inbound and outbound UDP port STEALTH SCIP All endpoints Inbound and outbound UDP port STEALTH IDLE All endpoints Inbound and outbound IP address Local loopback Note: Ensure that any protocol or port is allowed for this IP address. Management Server Inbound and outbound, local and remote

114 Troubleshooting Table 6 1. Firewall Ports, IP Addresses, and Programs (cont.) Type Use Value Endpoint Direction Program Stealth Logon Service Unisys Stealth Logon (USSL_Logon) Service in C:\Program Files\Unisys\Stealth Solution All endpoints N/A Program Stealth Protocol Service Unisys Stealth Protocol (USSL_Protocol) Service in C:\Program Files\Unisys\Stealth Solution All endpoints N/A After you finish configuring these settings, if you are unable to communicate between Stealth endpoints (that is, you can ping only in one direction), check for a firewall on the Stealth endpoint that cannot receive the ping request. If a firewall is turned on, turn off the firewall. Example Configuration Instructions For example, do the following for endpoints running the Windows Firewall. (Adapt these directions for your specific firewall software.) 1. Access Windows Firewall with Advanced Security. 2. Do the following to configure a new Inbound rule for TCP ports: a. In the left menu, right-click Inbound Rules, and then click New Rule. b. On the New Inbound Rule Wizard Rule Type page, select Port, and then click Next. c. On the Protocol and Ports page, select TCP, and in the Specific local ports box, enter the following ports in a comma separated list: For the Management Server, enter the port used by the Stealth Monitor Service. For all endpoints, enter the port defined for the URL in the AuthService.config file. For example, if the AuthService.config file includes port 9200, then you must enable traffic to pass through that port. d. When you have added all required ports, click Next. e. On the Action page, select Allow the connection, and then click Next. f. On the Profile page, verify that the Domain, Private, and Public check boxes are selected, and then click Next. g. On the Name page, enter a name and optional description for your new rule, and then click Finish

115 Troubleshooting 3. Do the following to configure a new Inbound rule for UDP ports: a. In the left menu, right-click Inbound Rules, and then click New Rule. b. On the New Inbound Rule Wizard Rule Type page, select Port, and then click Next. c. On the Protocol and Ports page, select UDP, and in the Specific local ports box, enter the following ports in a comma separated list: 67 DHCP Server 68 DHCP Client 500 IKE 546 DHCPv6 Client 547 DHCPv6 Server 4500 IKE NAT STEALTH SCIP STEALTH IDLE d. When you have added all required ports, click Next. e. On the Action page, select Allow the connection, and then click Next. f. On the Profile page, verify that the Domain, Private, and Public check boxes are selected, and then click Next. g. On the Name page, enter a name and optional description for your new rule, and then click Finish. 4. Do the following to configure a new Inbound rule for the IP address: a. In the left menu, right-click Inbound Rules, and then click New Rule. b. On the New Inbound Rule Wizard Rule Type page, select Custom, and then click Next. c. On the Program page, select All programs, and then click Next. d. On the Protocol and Ports page, in the Protocol type list, ensure that Any is selected, and then click Next. e. On the Scope page, select These IP addresses for the local IP address, and then click Add. f. On the IP Address dialog box, select This IP address or subnet, and enter , and then click OK. g. Repeat the previous two steps for the remote IP address to add IP address h. Click Next. i. On the Action page, ensure that Allow the connection is selected, and then click Next

116 Troubleshooting j. On the Profile page, verify that the Domain, Private, and Public check boxes are selected, and then click Next. k. On the Name page, enter a name and optional description for your new rule, and then click Finish. 5. Do the following to configure a new Outbound rule for TCP ports: a. In the left menu, right-click Outbound Rules, and then click New Rule. b. On the New Outbound Rule Wizard Rule Type page, select Port, and then click Next. c. On the Protocol and Ports page, select TCP, and in the Specific local ports box, enter the following ports in a comma separated list: For the Management Server, enter the port used by the Stealth Monitor Service. For all endpoints, enter the port defined for the URL in the AuthService.config file. For example, if the AuthService.config file includes port 9200, then you must enable traffic to pass through that port. d. When you have finished adding all required ports, click Next. e. On the Action page, select Allow the connection, and then click Next. f. On the Profile page, verify that the Domain, Private, and Public check boxes are selected, and then click Next. g. On the Name page, enter a name and optional description for your new rule, and then click Finish. 6. Do the following to configure a new Outbound rule for UDP ports: a. In the left menu, right-click Outbound Rules, and then click New Rule. b. On the New Outbound Rule Wizard Rule Type page, select Port, and then click Next. c. On the Protocol and Ports page, select UDP, and in the Specific local ports box, enter the following ports in a comma separated list: 67 DHCP Server 68 DHCP Client 500 IKE 546 DHCPv6 Client 547 DHCPv6 Server 4500 IKE NAT STEALTH SCIP STEALTH IDLE d. When you have finished adding all required ports, click Next. e. On the Action page, select Allow the connection, and then click Next

117 Troubleshooting f. On the Profile page, verify that the Domain, Private, and Public check boxes are selected, and then click Next. g. On the Name page, enter a name and optional description for your new rule, and then click Finish. 7. Do the following to configure a new Outbound rule for the IP address for the Management Server only: a. In the left menu, right-click Outbound Rules, and then click New Rule. b. On the New Outbound Rule Wizard Rule Type page, select Custom, and then click Next. c. On the Program page, select All programs, and then click Next. d. On the Protocol and Ports page, in the Protocol type list, ensure that Any is selected, and then click Next. e. On the Scope page, select These IP addresses for the local IP address, and then click Add. f. On the IP Address dialog box, select This IP address or subnet, and enter , and then click OK. g. Repeat the previous two steps for the remote IP address to add IP address h. Click Next. i. On the Action page, ensure that Allow the connection is selected, and then click Next. j. On the Profile page, verify that the Domain, Private, and Public check boxes are selected, and then click Next. k. On the Name page, enter a name and optional description for your new rule, and then click Finish. 8. Exit the Windows Firewall with Advanced Security window, and access the regular Windows Firewall window. 9. In the left pane, select Allow a program or feature through Windows Firewall. 10. At the bottom of the Allowed programs and features list, select Allow another program. Note: If required, click Change settings at the top of the window to allow another program. 11. Browse and add the Unisys Stealth Logon (USSL_Logon) Service and Unisys Stealth Protocol (USSL_Protocol) Service. 12. Once these programs are added to the Allowed programs and features list, select all check boxes for each program, and then click OK

118 Troubleshooting 6.5. Troubleshooting the Management Server Perform one or more of the following procedures to troubleshoot issues with the Management Server and Enterprise Manager software Restoring the License Service If the License Service is not available (for example, if the Authorization Service cannot communicate with the License Service), the Authorization Service opens a temporary session and continues to attempt to communicate with the License Service. If the License Service remains unavailable, the Authorization Service does not authorize new sessions until the connection with the License Service is restored. To restore the License Service, do the following: 1. On the Enterprise Manager interface, select Monitoring in the menu bar. 2. On the Stealth Network Dashboard page, check the status of the License Service. 3. If the License Service status is Normal, and the Authorization Service is unable to contact it, restart the License Service on the license host (the Management Server). To restart the License Service, do the following on the license host: a. From the Start menu, enter services.msc in the Search box to access the Services console. b. On the Services console, right-click Unisys Stealth Dynamic Licensing and select Restart. c. Monitor the status of the License Service on the Stealth Network Dashboard. 4. If the License Service does not restart successfully, reboot the Management Server Changing the Stealth Logo, the Unisys Logo, or the Unisys Name in the Enterprise Manager Interface Perform the following procedures to change the Stealth logo that appears in the upper-left corner of the Enterprise Manager interface, the Unisys logo that appears in the lower-left corner of the Enterprise Manager interface, or the Unisys name that appears in the Monitoring page tree view. Changing the Stealth Logo The Stealth logo appears in the upper-left corner of the Enterprise Manager interface. If required, you can change the Stealth logo to another graphic or logo (for example, your company logo). The Stealth logo size is pixels, and you should use a replacement image of the same size

119 Troubleshooting To change the Stealth logo, do the following: 1. Save the replacement image using the name stealth-logo. Note: The replacement image can be any type of image file, but the size of the image should be pixels. 2. On the Management Server, browse to the C:\Program Files\Unisys\EnterpriseMgmt\StealthEM\tomcat \webapps\Stealth_Enterprise_Manager-theme\images\logo directory. 3. Copy the new stealth-logo file to this directory. 4. From the Start menu, enter services.msc in the Search box to access the Services console. 5. Restart the Stealth Enterprise Manager service. Changing the Unisys Logo The Unisys logo appears in the lower-left corner of the Enterprise Manager interface. If required, you can change the Unisys logo to another graphic or logo (for example, your company logo). The Stealth logo size is pixels, and you should use a replacement image of the same size. To change the Unisys logo, do the following: 1. Save the replacement image using the name unisys_logo. Note: The replacement image can be any type of image file, but the size of the image should be pixels. 2. On the Management Server, browse to C:\Program Files\Unisys\EnterpriseMgmt\StealthEM\tomcat \webapps\Stealth_Enterprise_Manager-theme\images\logo. 3. Copy the new unisys_logo file to this directory. 4. From the Start menu, enter services.msc in the Search box to access the Services console. 5. Restart the Stealth Enterprise Manager service. Changing the Unisys Name in the Monitor Stealth Network Tree View The Unisys name appears in the Monitoring page tree view. To change the Unisys name to a new value (for example, your company name), do the following: 1. On the Management Server, browse to C:\Program Files\Unisys\EnterpriseMgmt\StealthEM\tomcat \webapps\Stealth-Enterprise- Manager\WEB-INF\classes. 2. Open the Language.properties file using a text editor such as Notepad. 3. Locate the line that reads TV.Root=Unisys, and then replace Unisys with the new value

120 Troubleshooting 4. Save and close the file. Note: Ensure that you do not save the file with any extension, such as a.txt extension. 5. In the same directory, open the Language_en_IN.properties file using a text editor such as Notepad. 6. Locate the line that reads TV.Root=Unisys, and then replace Unisys with the new value. 7. Save and close the file. Note: Ensure that you do not save the file with any extension, such as a.txt extension. 8. From the Start menu, enter services.msc in the Search box to access the Services console. 9. Restart the Stealth Enterprise Manager service Troubleshooting Stealth Endpoints Perform one or more of the following procedures to troubleshoot issues with Stealth endpoints. Note: DHCP and ARP are the only protocols that are transmitted in clear text by Stealth endpoints. See 6.7 Protocol Transit Information for more information Troubleshooting the Stealth Applet Connection to the Unisys Stealth Logon Service on Windows Endpoints If a user is logged on to a Windows endpoint (including the Management Server), and closes the Remote Desktop window without logging off of the endpoint, the Stealth Applet running in that session does not terminate the connection to the Unisys Stealth Logon Service. If another user logs on to the endpoint, the Stealth Applet in the new session cannot open a new connection to the Unisys Stealth Logon Service. In this case, the Stealth Applet enters an Error state (indicated by a yellow Stealth Shield icon in the taskbar), and you receive a message that states that the Unisys Stealth Logon Service is not available. If the Stealth Applet cannot connect to the Unisys Stealth Logon Service, do the following to log off a user that disconnected from the endpoint without logging off: 1. On the endpoint, access Windows Task Manager and select the Users tab. 2. Select the user that you want to log off of the endpoint, and then click Logoff or Sign out (depending on the version of Windows running on the endpoint). The user is logged off of the endpoint, and the associated connection is terminated. 3. Verify that the Stealth Applet is successfully connected to the Unisys Stealth Logon Service (indicated by a blue Stealth Shield icon in the taskbar)

121 Troubleshooting If the Stealth Applet remains in an Error state, do the following to reboot the endpoint and verify that it can connect to the Unisys Stealth Logon Service: 1. Reboot the endpoint and wait several minutes for the endpoint to restart. 2. Log on to the endpoint. 3. Verify that the Stealth Applet is successfully connected to the Unisys Stealth Logon Service (indicated by a blue Stealth Shield icon in the taskbar) Troubleshooting Ubuntu Linux Endpoints For 64-bit Ubuntu operating systems to operate with Stealth, the AES-NI Kernel module must be disabled. During the endpoint software installation on 64-bit Ubuntu operating systems, the Stealth installer automatically creates the /etc/modprobe.d/blacklist-stealth.conf file, which includes the line blacklist aesni_intel to disable AES-NI Kernel module. If Stealth is uninstalled, this file is removed. If you are experiencing any problems with 64-bit Ubuntu endpoints, verify that the Kernel module has been disabled by entering the following command: lsmod grep aesni_intel If entering this command displays any output, the kernel extension is not disabled, and you can do one of the following: Enter the following command to unload the module: modprobe -r aesni_intel Manually create the /etc/modprobe.d/blacklist-stealth.conf file with the line blacklist aesni_intel and then enter the following command: modprobe -r aesni_intel Completely uninstall and reinstall the software endpoint package Troubleshooting Windows Endpoints with Mapped Network Drives For any Stealth endpoint running a Windows operating system that has one or more mapped network drives, either the associated system must be Stealth-enabled (and share a COI with the endpoint) or you must create clear text filters that enable communication with that system. If a Windows Stealth endpoint is configured to use Always On mode, and if you have mapped a drive to a non-stealth-enabled system (and you have not created a clear text filter to enable access to that system), you might not be able to start or restart the endpoint normally. In that case, you must start the endpoint in safe mode and disconnect

122 Troubleshooting the mapped drive. Alternatively, you can update the configuration using the Provision page, Filter tab to add a clear text filter on both the Service Role and the role that includes the workgroup COIs used for communication between the endpoint and the system that hosts the mapped drive Protocol Transit Information Note the following information about various protocols and how they transit endpoints: DHCP and ARP are transmitted in clear text by Stealth endpoints. (The other routing protocols listed are not directed to endpoints.) IGMP is transmitted in clear text, only if multicast is enabled in the Stealth configuration. Otherwise, IGMP is suppressed by Stealth. In addition, applications that generate raw Ethernet frames will not function properly on Stealth-enabled endpoints, because outbound frames sent directly to the Ethernet layer will not be Stealth-enabled, and inbound frames that are not Stealth-enabled will be discarded Enterprise Manager Interface Log Files Log files for the Enterprise Manager interface are saved on the Management Server in the C:\Program Files\Unisys\EnterpriseMgmt\StealthEM\tomcat \logs\ directory. If there is a problem in your environment, these files can help you with debugging. When each of these files reaches 5 MB, the files are wrapped, and older entries are overwritten by newer entries. When you run the Collect Diagnostics command on the Management Server, these log files are collected. See 6.10 Collecting Diagnostics from the Management Server and Endpoint Instances for more information about collecting diagnostics Obtaining Services and Support from Unisys Unisys provides support and optional services for your Stealth(cloud) for AWS environment. Obtaining Support To obtain support, do the following, depending on whether you have a technical question or non-technical question: For technical questions about your Stealth(cloud) for AWS environment including installation and configuration questions or if you need to report a Stealth product issue, call one of the following numbers: (toll-free) (charges apply)

123 Troubleshooting When you call the Unisys User Support Desk, you will be asked to provide your valid AWS Account ID, a description of your issue, and any diagnostics you have collected. A ticket will be created for your reference, and then you will be transferred to a Unisys Stealth(cloud) for AWS Support Analyst. The Support Analyst will work with you to answer your questions and verify that you have met all of the requirements for deploying the Stealth(cloud) for AWS environment. If your instances cannot be launched, or if your properly configured endpoints cannot communicate with other endpoints in the same user role or with other components for which they have filters configured, Unisys will help to diagnose and resolve your issues. For non-technical questions including questions about Test Drive experiences, licensing options, and professional services call one of the following numbers, depending on the time: - During the hours of 9:00 a.m. to 9:00 p.m. Eastern Standard Time, call During the hours of 9:00 p.m to 9:00 a.m. Eastern Standard Time, call (toll-free) or (charges apply). We make the best possible effort to respond to calls within the same business day. Calls received on weekends and Unisys holidays will be returned the next business day. Be sure to review our documentation, which is available at This page includes informational articles, product alerts, and answers to frequently asked questions. Optional Professional Services Unisys offers the following professional services which are available for an additional fee to help you optimize your Stealth(cloud) for AWS environment. We can assist you with creating a detailed Stealth architecture that meets your needs, including setting up additional user roles and filters to further segment your endpoints and manage detailed control over communications in your environment. Our services include the following: 1. Discovery Service: The Discovery Service is a hosted, four hour participant-driven activity that introduces you to Stealth solutions and the uses of Stealth(cloud) for Amazon Web Services. 2. Design Service: With the Design Service, Unisys works with you to identify changes you might want to make in your AWS environment, such as adding or modifying existing roles, filters, Communities of Interest (COIs) or endpoints within your Stealthenabled Virtual Private Cloud (VPC). If desired, Unisys can work with you to define the parameters for integrating your network elements to connect the Stealth-enabled AWS VPC using a defined AWS gateway. 3. Integration Service: The Integration Service is based on the outcome of the Design Service. Unisys assists you in making the changes you have defined, which could include the expansion of the existing Stealth-enabled VPC (roles, filters, or adding COIs) or integrating your network elements to connect the Stealth-enabled AWS VPC using a defined AWS gateway. In addition to aiding in the network configuration,

124 Troubleshooting Unisys can update your Stealth-enabled VPC with the necessary security filters or changes as defined as part of the Design Service. Note: Although Unisys supports client creation of new filters and user roles, in complex environments, you might find it necessary to leverage Unisys expertise in security and micro-segmentation to ensure that your environment is properly configured and secured. If you create, change, or delete multiple roles and filters using the Enterprise Manager interface but your environment is not performing as you intended, Unisys consultants can provide the services you need to implement your design Collecting Diagnostics from the Management Server and Endpoint Instances If you are directed to collect diagnostics by Unisys Support personnel, perform the procedures in this topic. Collecting Diagnostics from the Management Server The Management Server software includes the Collect Diagnostics utility. To use the Collect Diagnostics utility on the Management Server instance, do the following: 1. From the Start menu, enter Collect Diagnostics in the Search box. 2. Double-click Collect Diagnostics. The Collect Diagnostics utility collects diagnostic information for your configuration, and stores the information in the C:\Stealth directory on the Management Server, in the following subfolders: The Management Server endpoint software diagnostics are collected in the folder C:\Stealth\Diag-<Computer Name>-<Date>, where <Computer Name> is the computer name of the Management Server, and <Date> is the date when the diagnostics were collected. The Enterprise Manager diagnostics are collected in the subfolder DiagEM- <Computer Name>-<Date>, where <Computer Name> is the computer name of the Management Server, and <Date> is the date when the diagnostics were collected. Collecting Diagnostics from Windows Endpoints You can collect the diagnostic information from a Windows Stealth endpoint by running the collectdiags.cmd script, which is provided with the Stealth endpoint software. You can run this script on any Windows endpoint. To run this script, do the following: 1. From the Start menu, enter Collect Diagnostics in the Search box. 2. Right-click Collect Diagnostics and select Run as administrator

125 Troubleshooting The diagnostic output files are collected in the C:\Stealth\<day MMDDYYYY> directory on the Stealth endpoint. (For example, the folder is named C:\Stealth\Fri ) Note: If you run this script multiple times in one day, all diagnostic files collected on the same day are stored in the same folder. The diagnostic files include: Stealth driver diagnostics file Diag_<date-time>-xxx.txt Network and Stealth query output and log files Diag_<date-time>-xxx.log Stealth installation log files Diag_<date-time>-xxx.evtx Windows system and application event log files Diag_cfg-msinfo32.txt Windows system information Diag_cfg-xxx.reg Selected Windows registry exports Note: The Diag_cfg files are not time-stamped and are collected only once each day. To collect the latest data, delete the old files first. Collecting Diagnostics from Linux Endpoints You can collect diagnostic information from a Linux Stealth endpoint by executing the collectdiags.sh script, which is installed as part of the Stealth endpoint software. This script file is located in the /etc/stealth/admin-scripts directory. You can run this script on any Linux endpoint. Execute the collectdiags.sh script by entering the following commands as root: cd /etc/stealth/admin-scripts./collectdiags.sh The collectdiags.sh script collects several log and configuration files and archives the files in a single file with a name in the format stealth-diags<mmddyyyy-hhmm>.tar.gz. All diagnostic archive files are stored in the /var/tmp/stealth directory. (An example file is /var/tmp/stealth/stealth-diags tar.gz.) From a remote session, you must establish a secure method to transfer the file. (You can use any method for copying secure files that is allowed in your environment.) For example, if your server includes the appropriate software packages, you could use SSH and enter the following SCP command: scp <source_file_name> <username>@<destination_host>:<destination_folder> Note: Before attempting to transfer this file remotely, you must ensure that the Linux endpoint and the destination server share a COI, or that the Linux endpoint has an appropriate filter to communicate with the destination server. You might find it useful to increase the logging level when diagnosing an issue. Do the following

126 Troubleshooting Note: The logging level you set determines the level of diagnostics that are collected by the collectdiags.sh script. 1. Open the /etc/stealth/system.ini file using an editor such as vi. 2. Locate the [global] section, and make the following changes: Ensure that the verbose line appears (and is uncommented) and set the value to 1. This line should appear like the following: verbose=1 Ensure that the trace_flags line appears (and is uncommented) and set the value to all. This line should appear like the following: trace_flags=all 3. Save and close the system.ini file Deleting the Management Server or Endpoint Instances If you want to delete the Management Server instance, you must first empty the associated S3 bucket. You can delete the files in the bucket, or you can copy these files to another location. Note: Before deleting any files in the S3 bucket, you should ensure that you do not want to retain this data, because it is not backed up in any other location. After the bucket is empty, you can use the standard Amazon method of deleting stacks to delete the associated Management Server stack. If you want to delete an endpoint instance, use the standard Amazon method of deleting stacks to delete the associated endpoint stack

127 .

128 Copyright 2016 Unisys Corporation. All rights reserved. * *