Enabling AT-TLS encrypted communication between z/os and IBM Guardium Appliance

Transcription

1 Enabling AT-TLS encrypted communication between z/os and IBM Guardium Appliance Purpose of this document: This document is an example of how to configure encrypted communication between z/os using AT-TLS and the Guardium collector appliance. This process is applicable for configuring all three Guardium STAPs for z/os (DB2 for z/os, IMS, and Data Sets). This document is not intended to replace the more complete information you can find in the IBM Redbooks - refer to Appendix C. Naming Convention: The STAP for z/os is referred to as STAP. And the appliance is referred to as Guardium collector or simply as collector. The terms appliance, collector, and Guardium collector are used interchangeably. The following instructions and supporting files are based on a reference installation and need to be adjusted to suit your configuration. Therefore, the scenario and files should be considered as examples only. They are applicable to Guardium v9.5 and v10 collector appliance and z/os v9.1 and v10 STAPs. Please note that these directions are for RACF. If you are using another vendor product such as CA s ACF2 or Top Secret, please contact your vendor for product specific information for certificate generation and configuration processes. Appendix C contains links to additional information that may be helpful. Notice: The information contained in this document has not been submitted to any formal IBM test and is distributed AS IS. The use of this information or the implementation of any of these techniques is a customer responsibility and depends on the customer s ability to evaluate and integrate them into the customer s operational environment. While IBM may have reviewed each item for accuracy in a specific situation, there is no guarantee that the same or similar results will be obtained elsewhere. Anyone attempting to adapt these techniques to their own environments does so at their own risk and should tailor these examples to their own environments. IBM Security Guardium Page 1 of 9

2 1.1 Prerequisites 1. Configure IBM z/os Communications Server (Comm.Serv) on your system. Comm.Serv is part of the standard z/os 2.1x installation and provides the Policy Agent (pagent) and attls Enable the z/os ICSF Cryptographic Services. (Note: As of this writing, Guardium supports TLS 1.0, 1.1 and 1.2 for the z/os STAPs) 3. Verify the STAP for z/os v9.1 or STAP v10 is installed, and the Guardium collector appliance is configured and communicating with the S-TAP. 4. A Certificate Authority (CA) is available to issue the required signed certificates. In this example, the signed certificates are obtained by following the steps in Appendix A. 5. Network port is open across any firewall(s) between the STAP and collector. The collector listens on and connections are initiated from the STAP. 6. The following example files are referenced and are attached to this tech note: ATTLS01 RACFKEY3 RACFTTLS PA_SEARCH.txt 1.2 General Certificates note The collector has to prove its identity to the STAP (actually the AT-TLS component) but not vice-versa; therefore, the STAP must be able to independently verify the collector s certificate chain, including the CA. IBM Security Guardium Page 2 of 9

3 1.3 z/os Configuration Copy the CA certificate to z/os (from prerequisites section step 4 above) The original certificate authority (CA) certificate with format X.509 needs to be copied to z/os 1. Create a dataset in z/os with record format as 'VB' (e.g. SYSADM.CA.CERT is used in the test) 2. FTP the CA certificate (in this example, ca.crt) file, in ASCII format, to the dataset created above e.g. SYSADM.CA.CERT Configuring AT-TLS on z/os Note that there is one Policy Agent (pagent) per LPAR. Modify z/os dataset and member names according to your configuration. In the examples below datasets are enclosed in single brackets <> and members in double <<>> z/os Communications Server Policy Agent (PAGENT) setup. Refer to attached file ATTLS01: <SYS1.TCPPARMS> <<ATTLS01>>: functions as the link between the SSL and STAP; <<RemotePortRange = 16023>> <<Direction = Outbound>> <<HandShakeRole=Client>> Certificate and Keyring Refer to attached file RACFTTLS for RACF authorizations, and attached file RACFKEY3 for creating certificates: <USER.PRIVATE.PROCLIB> <<PAGENT>> : This is the PAGENT proc. <<RACFTTLS>>: Initializes the PAGENT (see attached example file) <<RACKEY3>> : Adds and attaches the certificate received PROCESS to generate z/os server certificates: Note: all jobs must return 0 1. Submit RACFTTLS 2. Submit RACFKEY3 - this adds the new user to his KEYRING **** Verify the CA and certificates are defined: From TSO, type: RACDCERT LISTRING(ADHCKEYRING) ID(SYSADM). Output should be similar to: IBM Security Guardium Page 3 of 9

4 Digital ring information for user SYSADM: Ring: >ADHCKEYRING< Certificate Label Name Cert Owner USAGE DEFAULT LABEC247 RBC CA Test CERTAUTH CERTAUTH NO 3. Ensure the ICSF Cryptographic services are started. 4. In G.S.LOG, type: /VARY TCPIP,,O,DSN=SYS1.TCPPARMS(TTLSON) 5. Verify AT-TLS works: Start PAGENT: /S PAGENT (note: can also do an update) To verify or display the policy rules are active go to OMVS and type pasearch t. Refer to attached file pasearch_output.txt for an output example 6. Now, use the appropriate line for the STAP being configured: a. DB2 STAP: In STAP samplib <DB2TOOLS.STAPV10.SADHSAMP>, in member <<ADHCFGP>>, add the following line: APPLIANCE_PORT (16023) - b. Data Set STAP: In Data Set STAP CONTROL file <GUARDIUM.AUV91.CONTROL>, in member <<OPTIONS>>, add the following line: PORT(16023) c. IMS STAP: In IMS STAP SAMPLIB <GUARDIUM.AUI91.SAUISAMP>, in member <<AUICONFG>>, add the following line: APPLIANCE_PORT(16023) 1.4 Guardium Collector Configuration Generate a CSR (certificate signing request) for the collector, including any failover collector(s), and provide to the CA. Then Install the CA signed certificate on the collector(s). Note: Skip this section if the steps in Appendix A were used. 1. Log into the collector s cli and run the following command to generate a csr: create csr sniffer Fill out the signing request (note: the CN field is mandatory) and then copy and paste all the lines between and including -----BEGIN CERTIFICATE REQUEST----- to -----END CERTIFICATE REQUEST Provide output of step 1 to the CA, requesting a signed certificate in PEM format IBM Security Guardium Page 4 of 9

5 3. Import the signed sniffer certificate provided by the CA: store certificate sniffer console Paste the content of pem file including the BEGIN and END lines, then type CTRL-D to submit **** Verify cursor is at the end of the -----END CERTIFICATE----- line BEFORE typing CTRL-D 4. Use the following command to display/verify the certificate: show certificate sniffer 5. Re-start the sniffer process using the following command: restart inspection-core 1.5 Verify Communication between STAP and Collector On z/os, restart PAGENT, if necessary: /S PAGENT On z/os, restart the STAP *** There should be no errors/exceptions, and numerous handshaking messages in syslog On the collector s GUI, verify the STAP (ASC process for DB2) is active (green) and TLS is listed in the encrypted column. Generate database activity you expect to be captured by the STAP policy, and verify it was captured on the appliance Troubleshooting: a. Capture tcpdump from z/os to show encrypted traffic. b. netstat commands are helpful for setup and debugging, and can be run from TSO. c. View the snif.log on the appliance to check for any errors and exceptions (requires root access) IBM Security Guardium Page 5 of 9

6 APPENDIX A example using an internal CA Example certificate creation steps if using an internal CA to generate self signed certificates see previous sections for process to apply: On the CA server generate the CA certificate for z/os a. openssl genrsa -out ca.key 2048 b. openssl req -new -x509 -key ca.key -days out ca.crt -sha256 Note: The inputs (responses) used here must be different than used on the collector during the create csr sniffer' step below. If the responses are the same, there will be an error in the test. c. Ftp the ca.crt to z/os as described in the previous section Copy CA certificate to z/os On the collector generate a CSR a. Generate a csr sniffer using the CLI command 'create csr sniffer' (Note: the CN field is mandatory) b. Copy the CSR to a text file for use in next step On the CA server generate a host certificate for the collector a. Edit (vi) host.csr on the CA machine and paste/add the CSR from step 2 b. openssl x509 -req -days in host.csr -out host.crt -CAkey ca.key -CA ca.crt -sha256 - set_serial c. copy host.crt (including headers) from -----BEGIN CERTIFICATE----- to -----END CERTIFICATE----- Back on the appliance use the CLI to upload the signed certificate: a. store certificate sniffer console and paste the contents of host.crt from step 3.iii above. b. **** verify the certificate using the following command to display/verify the certificate: show certificate sniffer c. restart inspection-core IBM Security Guardium Page 6 of 9

7 APPENDIX B syslogd logging on z/os by AT-TLS The STAP is not configured to write to syslogd. AT-TLS is typically configured to write to SYSLOGD via the RACFTTLS configuration see the sample RACFTTLS file. The type and volume of messages are configured via the trace level set in the AT-TLS policy, usually called ATTLS01 see the sample ATTLS01 file. Below is a description of the Trace parameter used in the TTLSGroupAction statement of the AT-TLS policy: Note: error messages may be generated during the TLS handshake as well as during the processing of TLS records after the handshake successfully completes, but the most common case is that most errors occur during handshakes. Trace Specifies the level of AT-TLS tracing. The valid values for n are in the range The sum of the numbers associated with each level of tracing selected is the value that should be specified as n. If n is an odd number, errors are written to joblog and all other configured traces are sent to syslogd. The trace parameter can be specified on multiple actions referenced by a common TTLSRule statement. The value specified on the TTLSGroupAction statement can be overridden for a particular AT-TLS environment by specifying it on the TTLSEnvironmentAction statement or for particular connections by specifying it on the TTLSConnectionAction statement. 0 No tracing is enabled. 1 (Error) Errors are traced to the TCP/IP joblog. 2 (Error) Errors are traced to syslogd. This is the default. The messages are issued with syslogd priority code err. 4 (Info) Tracing of instances when a connection is mapped to an AT-TLS rule and when a secure connection is successfully initiated is enabled. The messages are issued with syslogd priority code info. 8 (Event) Tracing of major events is enabled. The messages are issued with syslogd priority code debug. 16 (Flow) Tracing of system SSL calls is enabled. The messages are issued with syslogd priority code debug. IBM Security Guardium Page 7 of 9

8 32 (Data) Tracing of encrypted negotiation and headers is enabled. This traces the negotiation of secure sessions. The messages are issued with syslogd priority code debug. 64, 128 Reserved 255 All tracing is enabled. IBM Security Guardium Page 8 of 9

9 APPENDIX C Useful links 1. AT-TLS presentation 2. IBM Redbook for DB2 for z/os setup with AT-TLS 3. ACF2 how to make it very similar to RACF process 4. HOW TO: Put in the TLS/SSL Certificate Pathname for ACF2, RACF, or Top Secret certificate facilities 2017-January-06 IBM Guardium Licensed Materials - Property of IBM. Copyright IBM Corp U.S. Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business Machines Corp., registered in many jurisdictions worldwide. Other product and service names might be trademarks of IBM or other companies. A current list of IBM trademarks is available on the Web at Copyright and trademark information ( IBM Security Guardium Page 9 of 9