Cisco WCS Server Hardening

Transcription

1 APPENDIXD This appendix provides an instructional checklist for hardening a WCS server. Ideally, the goal of a hardened server is to leave it exposed on the Internet without any other form of protection. This appendix describes the hardening of WCS, which requires some services and processes exposed to function properly. Think of it as WCS Best Practices. Hardening of WCS will involve disabling unnecessary services, removing and modifying registrykey entries, and applying appropriate restrictive permissions to files, services, and end points. This appendix contains the following sections:, page D-1 Tomcat Shutdown Prevention, page D-10 WCS Password Handling, page D-10 Setting Up SSL Certification, page D-11 Web servers provide data through an externally or publicly exposed interface, this is a well-known target for exploitation. Unprotected web servers provide an avenue for malicious activity, such as theft or the denial of service to an organization's resources. A Non-Privileged account allows you to work as a normal account and launching applications or tools using the credentials of a different account (most likely your administrator account). In Linux, you need not run WCS as a Non-Privileged Account as Linux starts as root to port 80 and then switches effective userid to nobody. Creating a Non-Privileged User To create a Non-Privileged User, follow these steps: Step 1 Create a new user by choosing Administrator Tools > Computer Management or right-click My Computer > Manage from the drop-down list. You will see the Computer Management window. (See Figure D-1) D-1

2 Figure D-1 Computer Management Step 2 Click Local users and Groups and click the Users folder. Right-click in the right pane and click "New User". (See Figure D-2) D-2

3 Figure D-2 Local Users and Groups Step 3 In the New User dialog box, type in your preferences for a new user name and password (this will be your secondary Administrator account). For example, use wcsuser is the username and wcsuser is the password. Click Create. (See Figure D-3) Figure D-3 New User D-3

4 Step 4 You need to add the new user to a group. Expand the Local Users and Groups option, right-click the groups and select the New Group option. Use wcsgroup as the groupname, and click Add, and select wcsuser.(see Figure D-4) Figure D-4 New Group Step 5 To provide permission for wcs group, you need to go to specific WCS installation path, add wcsgroup on the Security tab, and select permissions for wcsgroup. D-4

5 Figure D-5 Adding a group into security Step 6 Add Log on service rights for wcsgroup by running secpol.msc from start run command-line. That is, In the Local Security Settings window, select Local Policies > User Rights Assignment and double-click the Log on as as service policy. Add wcsgroup to this policy. (See Figure D-6) D-5

6 Figure D-6 Local Security Settings Step 7 Step 8 Edit the wrapper.conf file located at C:\Program Files\WCSx.xx.x\webnms\conf in your machine or appropriate directory in your setup: wrapper.ntservice.account=wcs-nms-1\wcsuser wrapper.ntservice.password=wcsuser Execute the below scripts for install services with new wcsuser account settings. (See Figure D-7): C:\Program Files\WCS \bin\UninstallService.bat C:\Program Files\WCS \bin\InstallService.bat D-6

7 Figure D-7 Install Services Step 9 Change the Properties of WCS Installation directories and files under it to wcsgroup on the Security tab for read, execute, and modify (See Figure D-8): Figure D-8 Security Tab for WCS Installation Folder D-7

8 Step 10 Open the registry editor from the run command-line and provide the permission for Javasoft directory to wcsgroup users to the read execute and write Javasoft directory (See Figure D-9): Figure D-9 Registry Editor Step 11 Open PackagingResources.properties file in <WCS_HOME>\webnms\classes\com\cisco\packaging directory, search for "NonPrivUser" attribute,and change it to true (See Figure D-11): D-8

9 Figure D-10 PackagingResources.properties Step 12 Restart the WCS server again from the services window (See Figure D-11): Figure D-11 Starting WCS Service D-9

10 Tomcat Shutdown Prevention Tomcat Shutdown Prevention On Windows, the file which controls the web service is the Server.xml file. Read and Write or Full Control access to this file is to be limited to the SA, Web Manager or Web Manager's designees. Tomcat can be shut down maliciously by any user with a browser. Tomcat uses port 8005 for its remote shutdown sequence command. So, the line Server port="8005" shutdown="shutdown" debug="0" in server.xml should be modified to have some other string than "SHUTDOWN". This string must be modifed to C15C0WC5. The File permissions for server.xml is the full control, read/write access is given to Administrator only. Others have only read and read/execute permissions. WCS Password Handling You can configure additional authentication by configuring the Local Password Policy parameters. Select the check boxes if you want the configurations to be enabled. Figure D-12 Local PAssword Policy D-10

11 Setting Up SSL Certification The following configurations are added for additional authentication: You can configure that the password cannot be reused until N number of new passwords are used. This figure is configurable. You can configure that the passoword cannot be changed for a minimum interval of 24 hours from last change. You can configure locking of an account if X number of attempts failed. The X figure is configurable. You can configure whether you want the account to be disabled or not if it is unused for 30 days. You can configure the expiry time of the password. This is confiurable and the unit is in days. You can configiure to enforce a user to change the password on first login. Setting Up SSL Certification The Secure Sockets Layer (SSL) Certification is to ensure secure transactions between a web server and the browsers. Installing the DoD Certificates will allow your Web browser to trust the identity and provide secure communications which are authenticated by Department of Defense (DoD). These certificates are used to validate the identity of the server or web site and are used to generate the encryption key used in the SSL. This encryption protects the information being passed between the server and the client. This section describes the SSL Certification and contains the following topics: Setting Up SSL Client Certification, page D-11 Setting Up SSL Server Certification, page D-12 Setting Up SSL Client Certification To setup the SSL Client Certificate Authentication using DoD certificates, follow these steps: As a prerequisite, to create the SSL Certificates, you would require KeyTool available in JDK. KeyTool is a command line tool to manage keystores and the certificates. Step 1 Create SSL Client Certificate using the following command: % keytool -genkey -keystore nmsclientkeystore -storetype pkcs12 -keyalg RSA -keysize alias nmsclient -dname "CN=nmsclient, OU=WNBU, O=Cisco, L=San Jose, ST=CA, C=US" -storepass nmskeystore Provide the Key Algorithm as RSA and KeySize as 1024 or Step 2 Generate the Certificate Signing Request (CSR) using the following command: % keytool -certreq -keyalg RSA -keysize alias nmsclient -keystore nmsclientkeystore -storetype pkcs12 -file <csrfilename> Provide the Key Algorithm as RSA and KeySize as 1024 or 2048 and provide a certificate file name. D-11

12 Setting Up SSL Certification Step 3 Send the generated CSR file to DoD. The DoD will issue the corresponding signed certificates. The CSR reply is through dod.p7b file. In addition you should also receive the root CA certificates. Please makes sure to retrieve the PKCS7 encoded certificates; Certificate Authorities provide an option to get the PKCS7 encoded certificates. Step 4 Step 5 Import the CSR reply in the Keystore using the command: % keytool -import dod.p7b -keystore nmsclientkeystore -storetype pkcs12 -storepass nmskeystore Check the formats of root CA certificates recieved, they must be base 64 encoded. If they are not base 64 encoded, use the OpenSSL command to convert them to base 64 encoded format. % openssl x509 -in rootca.cer -inform DER -outform PEM -outfile rootca.crt % openssl x509 -in DoD-sub.cer -inform DER -outform PEM -outfile rootca.crt Convert both root CA certificate and sub-ordinate certificates recieved. In case you recieved both root CA certificate and the sub-ordinate certificate, you must bundle them together using the below command: % cat DoD-sub.crt > ca-bundle.crt % cat DoD-rootCA.crt >> ca-bundle.crt Step 6 To setup SSL Client Authentication using these certificates, enable SSL Client Authentication in Apache in the ssl.conf file located in <WCS_Home>/webnms/apache/ssl/backup/ folder. SSLCACertificationPath conf/ssl.crt SSLCACertificationFile conf/ssl.crt/ca-bundle.crt SSLVerifyClient require SSLVerifyDepth 2 SSLVerifyDepth will depend of the level of Certificate Chain. In case you have only 1 root CA certificate, this should be set to 1. In case you have a certificate chain (root CA and subordinate CA), this should be set to 2. Step 7 Step 8 Install the DoD root CA certificates in WCS. Import the nmsclientkeystore in your browser. Setting Up SSL Server Certification To setup the SSL Server Certificate using DoD certificates, follow these steps: Step 1 Generate the Certificate Signing Request (CSR). % keyadmin -newdn genkey <csrfilename> D-12

13 Setting Up SSL Certification Step 2 Send the generated CSR file to DoD. The DoD will issue the corresponding signed certificates. The CSR reply is through dod.p7b file. In addition you should also receive the root CA certificates. Please makes sure to retrieve the PKCS7 encoded certificates; Certificate Authorities provide an option to get the PKCS7 encoded certificates. Step 3 Import the Signed Certificate using the below command in the Keytool: % keyadmin -importsignedcert <dod.p7> The certificate and the key are stored at <WCS_Home>/webnms/apache/conf/ssl.crt. D-13

14 Setting Up SSL Certification D-14