Securing communication between SDS VA and its remote DB2 DB

Transcription

1 Securing communication between SDS VA and its remote DB2 DB IBM SECURITY SUPPORT OPEN MIC PRESENTATION Ramamohan T Reddy - Senior Software Engineer / L2 Team Tech Lead - Directory Support Team Brook Heimbaugh - L3 Team Lead / Tech Lead - Directory Support Team Edward Childress - Software Engineer / L2 Team Member - Directory Support Team Juan Quema - Software Engineer / L2 Team Member - Directory Support Team Wednesday, 15 February 2017

2 Agenda

3 Agenda SDS Virtual Appliance - Remote Database - Prerequisite Presentation Configuring SSL between SDS VA and its Remote DB2 database Self-signed Certificates CA Signed Certificates DB2 SSL configuration parameters DB2 server side configuration update for SSL on Remote system SDS VA Configuration update for SSL using idscfgdb SDS VA Configuration update for SSL for an already configured Remote DB SDS VA Configuration update to switch back to TCPIP (non-ssl) Verification Troubleshooting hints Useful Links Questions for the Panel 3 IBM Security

4 SDS Virtual Appliance - Remote Database - Prerequisite Presentation

5 SDS VA - Remote Database - Prerequisite Presentation Prerequisite for the current presentation - Please refer: Configuring SDS Virtual Appliance with a remote DB2 database provides info on SDS VA Introduction, features and editions. Embedded DB vs Remote DB SDS and Remote Database system requirements Requires DB (FP8 recommended) Download GA level part numbers and Fix packs. SDS Installation DB and Fix Pack Installation on Remote system. Applying DB2 ESE License Remote system db2 instance and database config using provided tool - idscfgremotedb Remote system db2 instance and database config using custom commands Configuration on SDS VA to connect to remote database Data Import / export methods Hints for Migration / Upgrade from Directory Sever V6.* 5 IBM Security

6 Configuring SSL between SDS VA and its Remote DB2 database

7 Configuring SSL between SDS VA & Remote DB2 database Main goal of this presentation is to configure SDS VA Directory Server (with embedded DB2 client) and Remote DB2 server to use SSL (with TLSv1* secure protocol version) on TCPIP connection. 7 IBM Security

8 Self-signed Certificates

9 Self-signed Certificates Self-signed certificate is a certificate that is signed by the same entity creating it. DB2 provides an internal GSKit installation available at ~/sqllib/gskit/bin on AIX/Linux/Solaris platforms On Windows 64-bit platforms, the 64-bit GSKit is typically installed at C:\Program Files\ibm\gsk8\ On Remote DB2 server system (AIX/Linux/Solaris) - login or su into db2 instance: ==> su - db2inst1 On Remote DB2 server system (Windows) - open a DB2 command window - Administrator C:\> C:\Progra~1\IBM\SQLLIB\BIN\db2cwadmin.bat C:\Users\Administrator> cd C:\Progra~1\IBM\SQLLIB\security Update path to include gskit provided binaries 9 IBM Security For AIX/Linux/Solaris $ export PATH=~/sqllib/gskit/bin:$PATH For Windows C:\Progra~1\IBM\SQLLIB\security> set path=c:\progra~1\ibm\gsk8\bin;%path% Create a folder to hold the key databases and extracted certificate files For AIX/Linux/Solaris $ mkdir ~/sqllib/security/keystore; cd ~/sqllib/security/keystore For Windows C:\PROGRA~1\IBM\SQLLIB\security> mkdir keystore C:\PROGRA~1\IBM\SQLLIB\security> cd keystore

10 Self-signed Certificates Create key database for the DB2 server $ gsk8capicmd_64 -keydb -create -db mydbserver.kdb -pw passwd -stash Create a Self-signed certificate $ gsk8capicmd_64 -cert -create -db mydbserver.kdb -pw passwd -label myselfsigned -dn "cn=dbserverhostname" -size default_cert yes -sig_alg SHA256WithRSA Extract the server s certificate $ gsk8capicmd_64 -cert -extract -db mydbserver.kdb -pw passwd -label myselfsigned -target mydbserver.arm -format ascii Create key database for the DB2 client (SDS VA) $ gsk8capicmd_64 -keydb -create -db mydbclient.kdb -pw passwd -stash Add the extracted server s certificate into the client key database $ gsk8capicmd_64 -cert -add -db mydbclient.kdb -pw passwd -label myselfsigned -file mydbserver.arm -format ascii For detailed output for the commands mentioned above, refer to section 4 in ISDS801_RemoteDB2ConfigSSL_DetailedSteps_15Feb2017-v1.pdf (companion document) 10 IBM Security

11 Self-signed Certificates Transfer / Download client key database and stash files to a system from where you can access SDS VA Web LMI using browser. Transfer client key database and stash file over to SDS VA Web LMI using browser ( Login as admin and its password Click on Configure Directory suite on top menu bar and click on Custom File Management Under All Files tab, click on Certificates folder Click on Upload button in main panel, click on Browse button and select kdb file. Click on Save configuration button to complete upload. Similarly upload the sth file also. For details on the procedure mentioned above, refer to section 6 in ISDS801_RemoteDB2ConfigSSL_DetailedSteps_15Feb2017-v1.pdf (companion document) 11 IBM Security

12 CA Signed Certificates

13 CA Signed Certificates CA Signed Certificates are those signed by a known Certification Authority (cab be Internal / External) DB2 provides an internal GSKit installation available at ~/sqllib/gskit/bin on AIX/Linux/Solaris platforms On Windows 64-bit platforms, the 64-bit GSKit is typically installed at C:\Program Files\ibm\gsk8\ On Remote DB2 server system (AIX/Linux/Solaris) - login or su into db2 instance: ==> su - db2inst1 On Remote DB2 server system (Windows) - open a DB2 command window - Administrator > C:\Progra~1\IBM\SQLLIB\BIN\db2cwadmin.bat C:\Users\Administrator> cd C:\Progra~1\IBM\SQLLIB\security Update path to include gskit provided binaries 13 IBM Security For AIX/Linux/Solaris $ export PATH=~/sqllib/gskit/bin:$PATH For Windows C:\Progra~1\IBM\SQLLIB\security> set path=c:\progra~1\ibm\gsk8\bin;%path% Create a folder to hold the key databases and extracted certificate files For AIX/Linux/Solaris $ mkdir ~/sqllib/security/cacert_server; cd ~/sqllib/security/cacert_server For Windows C:\PROGRA~1\IBM\SQLLIB\security> mkdir cacert_server C:\PROGRA~1\IBM\SQLLIB\security> cd cacert_server

14 CA Signed Certificates Create key database for the DB2 server $ gsk8capicmd_64 -keydb -create -db mydbserver.kdb -pw passwd -stash Create a Certificate Signing Request (CSR) for the DB2 Server $ gsk8capicmd_64 -certreq -create -db mydbserver.kdb -stashed -label "mydbservercert" -dn "cn=mydbserver,ou=divisiona,o=acompany" -file mydbservercertreq.arm -sigalg SHA256WithRSA Transfer the CSR mydbservercertreq.arm file to the CA system and get it signed by a CA Download signed certificate and also download the Root and any intermediate signer certificate(s). Add Root Signer Certificate to DB2 Server key database $ gsk8capicmd_64 -cert -add -db mydbserver.kdb -stashed -label "Root CA cert" -file rootca.arm -format ascii -trust enable Add Intermediate Signer Certificates to DB2 Server key database $ gsk8capicmd_64 -cert -add -db mydbserver.kdb -stashed -label "Intermediate CA cert" -file interca.arm -format ascii -trust enable Receive signed db2 server certificate $ gsk8capicmd_64 -cert -receive -db mydbserver.kdb -stashed -file mydbservercert.arm -default_cert yes 14 IBM Security

15 CA Signed Certificates Create a folder to hold the key databases and extracted certificate files For AIX/Linux/Solaris $ mkdir ~/sqllib/security/cacert_client; cd ~/sqllib/security/cacert_client For Windows C:\PROGRA~1\IBM\SQLLIB\security> mkdir cacert_client C:\PROGRA~1\IBM\SQLLIB\security> cd cacert_client Create key database for the DB2 client $ gsk8capicmd_64 -keydb -create -db mydbclient.kdb -pw passwd -stash Create a Certificate Signing Request (CSR) for the DB2 Server $ gsk8capicmd_64 -certreq -create -db mydbclient.kdb -stashed -label "mydbclientcert" -dn "cn=mydbclient,ou=divisiona,o=acompany" -file mydbclientcertreq.arm -sigalg SHA256WithRSA Transfer the CSR mydbclientcertreq.arm file to the CA system and get it singned by a CA Download signed certificate and also download the Root and any intermediate signer certificate(s). 15 IBM Security

16 CA Signed Certificates Add Root Signer Certificate to DB2 client key database $ gsk8capicmd_64 -cert -add -db mydbclient.kdb -stashed -label "Root CA cert" -file rootca.arm -format ascii -trust enable Add Intermediate Signer Certificates to DB2 Client key database $ gsk8capicmd_64 -cert -add -db mydbclient.kdb -stashed -label "Intermediate CA cert" -file interca.arm -format ascii -trust enable Receive signed db2 server certificate $ gsk8capicmd_64 -cert -receive -db mydbclient.kdb -stashed -file mydbclientcert.arm -default_cert yes For detailed output for the commands mentioned above, refer to section 5 in ISDS801_RemoteDB2ConfigSSL_DetailedSteps_15Feb2017-v1.pdf (companion document) Transfer client key database and stash files to a system from where you can access SDS VA Web LMI using browser. Transfer client key database and stash file over to SDS VA Web LMI using browser ( Login as admin and its password Click on Configure Directory suite on top menu bar and click on Custom File Management Under All Files tab, click on Certificates folder Click on Upload button in main panel, click on Browse button and select kdb file. Click on Save configuration button to complete upload. Similarly upload the sth file also. 16 IBM Security

17 DB2 SSL configuration parameters

18 DB2 SSL configuration parameters SSL key file path for DB2 server (for incoming ssl connections) - ssl_svr_keydb 18 IBM Security Fully qualified path and name of the kdb file. e.g.: /home/db2inst1/sqllib/security/cacert_server/mydbserver.kdb SSL key stash file path for DB2 server - ssl_svr_stash Fully qualified path and name of the stash file. e.g.: /home/db2inst1/sqllib/security/cacert_server/mydbserver.sth Personal certificate label in key file - ssl_svr_label Name of the personal certificate OR if the value is null, the default certificate is used SSL service name - ssl_svcename Name or port that DB2 server uses to await communications from remote client nodes using SSL protocol Name is defined in /etc/services with a dedicated unused port number Supported SSL versions - ssl_versions Specifies Secure Sockets Layer (SSL) and Transport Layer Security (TLS) versions: TLSv12 and TLSv1 When both TLSv12 and TLSv1 are set, TLS v1.2 is enabled with option to fall back on TLS v1.1 or TLS v1.0 Supported cipher specifications at the server - ssl_cipherspecs SSL key file path for DB2 client (for outbound SSL connections) - ssl_clnt_keydb Fully qualified path and name of the kdb file. e.g.: /userdata/directory/certificates/mydbclient.kdb SSL stash file path for DB2 client - ssl_clnt_stash Fully qualified path and name of the stash file. e.g.: /userdata/directory/certificates/mydbclient.sth

19 DB2 server side configuration update for SSL on Remote system

20 DB2 server side configuration update for SSL on Remote system On Remote DB2 server system - At this point you should have already created and configured db2 instance and its database, refer: Configuring SDS Virtual Appliance with a remote DB2 database On AIX/Linux/Solaris Remote DB2 server as root user find the current DB2 instance s service port ==> grep db2inst1svc /etc/services db2inst1svc 6512/tcp Find and add / assign an unused port for the purpose of DB2 instance s SSL service port ==> grep -i 6516 /etc/services # No results expected. ==> echo "db2inst1svcssl 6516/tcp" >> /etc/services ==> grep db2inst1svc /etc/services db2inst1svc 6512/tcp db2inst1svcssl 6516/tcp On Windows Remote DB2 server system - open a DB2 command window - Administrator C:\> C:\Progra~1\IBM\SQLLIB\BIN\db2cwadmin.bat C:\> findstr db2inst1svc C:\Windows\System32\drivers\etc\services db2inst1svc 6512/tcp On Windows Find and add / assign an unused port for the purpose of DB2 instance s SSL service port C:\> findstr 6516 C:\Windows\System32\drivers\etc\services C:\> echo db2inst1svcssl 6516/tcp >> C:\Windows\System32\drivers\etc\services C:\> findstr db2inst1svc C:\Windows\System32\drivers\etc\services db2inst1svc 6512/tcp db2inst1svcssl 6516/tcp 20 IBM Security

21 DB2 server side configuration update for SSL on Remote system On AIX/Linux/Solaris - Login or su into db2 instance: ==> su - db2inst1 On Windows Remote DB2 server system - continue on DB2 command window - Administrator C:\> set db2instance=db2inst1 Update DBM CFG configuration SSL key file path parameter for DB2 server - ssl_svr_keydb $ db2 update dbm cfg using ssl_svr_keydb /home/db2inst1/sqllib/security/keystore/mydbserver.kdb For CA signed certificates use corresponding kdb file with full path. On Windows use file with full path such as C:\PROGRA~1\IBM\SQLLIB\security\keystore\mydbserver.kdb Update DBM CFG configuration SSL key stash file path parameter for DB2 server - ssl_svr_stash $ db2 update dbm cfg using ssl_svr_stash /home/db2inst1/sqllib/security/keystore/mydbserver.sth When using CA signed certificates use corresponding sth file with full path. On Windows use file with full path such as C:\PROGRA~1\IBM\SQLLIB\security\keystore\mydbserver.sth Update DBM CFG configuration certificate label parameter - ssl_svr_label $ db2 update dbm cfg using ssl_svr_label myselfsigned When using CA signed certificates use corresponding certificate label. Update DBM CFG configuration SSL service name parameter - ssl_svcename $ db2 update dbm cfg using ssl_svcename db2inst1svcssl 21 IBM Security

22 DB2 server side configuration update for SSL on Remote system Update DBM CFG configuration Supported SSL versions parameter - ssl_versions $ db2 update dbm cfg using ssl_versions "TLSV12,TLSV1" Set DB2 registry variable DB2COMM value to either SSL (or to include SSL along with TCPIP) $ db2set -i db2inst1 DB2COMM=SSL $ db2set -all grep DB2COMM [i] DB2COMM=SSL Restart DB2 $ db2stop $ db2start Verify if the SSL port is listening ==> netstat -an egrep "(Local 6516)" Proto Recv-Q Send-Q Local Address Foreign Address (state) tcp4 0 0 *.6516 *.* LISTEN For detailed output for the commands mentioned above, refer to section 7 in ISDS801_RemoteDB2ConfigSSL_DetailedSteps_15Feb2017-v1.pdf (companion document) 22 IBM Security

23 SDS VA Configuration update for SSL using idscfgdb

24 SDS VA Configuration update for SSL using idscfgdb On the SDS VA system - by this time you should have already uploaded the kdb and sth files over to Custom File Management -> Certificates folder, for the use with DB2 client. Login to the SDS VA system on CLI using putty or SSH as admin Assuming you are using a newly configured SDS VA currently configured to use local embedded database(default configuration) Configure the SDS Directory Server to use remote database along with SSL parameters using idscfgdb tool: sds801va1> sds server_tools idscfgdb -I sdsinst1 -a sdsinst1 -t ldapdb -w sdsinst1 -Y -S l /home/sdsinst1 -P sdsp8aix72 -u db2inst1 -p passwd -L -B mydbclient.kdb -H mydbclient.sth -n In the command above SSL options are: -L : Setup SSL communication with Remote Database. -B : kdb file name - uploaded to Certificates folder -H : stash file name - uploaded to Certificates folder Note: Provide file name(s) that are in Certificates folder without any path just as shown above. Proceed to start Directory Server. sds801va1> sds server_tools ibmslapd -n For detailed output for the commands mentioned above, refer to section 8 in ISDS801_RemoteDB2ConfigSSL_DetailedSteps_15Feb2017-v1.pdf (companion document) 24 IBM Security

25 SDS VA Configuration update for SSL for an already configured Remote DB

26 SDS VA Configuration update for SSL for an already configured Remote DB For an already configured/working SDS VA system with remote DB using TCPIP (non-ssl) follow the procedure below to use SSL connectivity between SDS VA and Remote DB2. Login to SDS VA using CLI (via putty / ssh) logging in as admin and stop Directory Server sds801va1> sds server_tools ibmslapd -k Unconfigure existing remote db config using idsucfgdb tool (these options leave the data in database intact - refer to the link above for details on idsucfgdb) sds801va1> sds server_tools idsucfgdb -I sdsinst1 -Y -n On the Remote DB2 server system perform all the steps mentioned in Section DB2 server side configuration update for SSL on Remote system Back to SDS VA configure remote database along with SSL parameters using idscfgdb tool: sds801va1> sds server_tools idscfgdb -I sdsinst1 -a sdsinst1 -t ldapdb -w sdsinst1 -Y -S l /home/sdsinst1 -P sdsp8aix72 -u db2inst1 -p passwd -L -B mydbclient.kdb -H mydbclient.sth -n Proceed to start Directory Server. sds801va1> sds server_tools ibmslapd -n For detailed output for the commands mentioned above, refer to section 9 in ISDS801_RemoteDB2ConfigSSL_DetailedSteps_15Feb2017-v1.pdf (companion document) 26 IBM Security

27 SDS VA Configuration update to switch back to TCPIP (non-ssl)

28 SDS VA Configuration update to switch back to TCPIP (non-ssl) For an already configured/working SDS VA system with remote DB using SSL follow the procedure below to use TCPIP (non-ssl) connectivity between SDS VA and Remote DB2. Login to SDS VA using CLI (via putty / ssh) logging in as admin and stop Directory Server sds801va1> sds server_tools ibmslapd -k Unconfigure existing remote db config using idsucfgdb tool (these options leave the data in database intact - refer to the link above for details on idsucfgdb) sds801va1> sds server_tools idsucfgdb -I sdsinst1 -Y -n On the Remote DB2 server system login as db2inst1 and Set DB2 registry variable DB2COMM to TCPIP $ db2set -i db2inst1 DB2COMM=TCPIP $ db2set -all grep DB2COMM [i] DB2COMM=TCPIP Restart DB2 $ db2stop; db2start Back to SDS VA configure remote database along without SSL parameters using idscfgdb tool: sds801va1> sds server_tools idscfgdb -I sdsinst1 -a sdsinst1 -t ldapdb -w sdsinst1 -Y -S l /home/sdsinst1 -P sdsp8aix72 -u db2inst1 -p passwd -n For detailed output for the commands mentioned above, refer to section 10 in ISDS801_RemoteDB2ConfigSSL_DetailedSteps_15Feb2017-v1.pdf (companion document) 28 IBM Security

29 Verification

30 Verification On the remote db system use commands below to verify if SDS VA directory server is connecting to it: (From the command output below, is the IP Address of the SDS VA system.) $ db2 list applications Auth Id Application Appl. Application Id DB # of Name Handle Name Agents DB2INST1 ibmslapd LDAPDB 1... <many more lines as above> $ netstat -an egrep "Local 6516" Proto Recv-Q Send-Q Local Address Foreign Address State tcp : :* LISTEN tcp : :50097 ESTABLISHED... <many more lines as above> $ db2 get dbm cfg grep -i ssl server keydb file (SSL_SVR_KEYDB) = /home/db2inst1/sqllib/security/keystore/mydbserver.kdb SSL server stash file (SSL_SVR_STASH) = /home/db2inst1/sqllib/security/keystore/mydbserver.sth SSL server certificate label (SSL_SVR_LABEL) = myselfsigned SSL service name (SSL_SVCENAME) = db2inst1svcssl SSL cipher specs (SSL_CIPHERSPECS) = SSL versions (SSL_VERSIONS) = TLSV12,TLSV1 SSL client keydb file (SSL_CLNT_KEYDB) = SSL client stash file (SSL_CLNT_STASH) = For detailed output for the commands mentioned above, refer to section 11 in ISDS801_RemoteDB2ConfigSSL_DetailedSteps_15Feb2017-v1.pdf (companion document) 30 IBM Security

31 Troubleshooting hints

32 Troubleshooting hints During idscfgdb step on SDS VA system you may observe the following error message: GLPCTL020I Updating the database manager: 'sdsinst1'. Failed to attach to database instance or node: 'idsrnode GLPCTL022E Failed to update the database manager: 'sdsinst1'. Double check the kdb/sth files and the certificate validity and then retry the failing idscfgdb. Update DBM CFG config parameter DIAGLEVEL to get more info and reattempt failing operation to see more information in db2diag.log file. $ db2 update dbm cfg using DIAGLEVEL 4 Do not use idsgetfile from SDS VA CLI (via putty/ssh) to download the kdb and sth files, This will get the files into CustomIn folder instead of Certificates folder. Use Web LMI interface via browser and upload using Custom File Management panel over to Certificates folder. When the connection is broken between SDS VA Directory Server and its Remote DB2 Server, due to network issues or db2 restart, Connection error will be seen by ldap client applications. ibmslapd.log shows: GLPRDB001E Error code -1 from function:" SQLExecute " T10:49: :00 GLPRDB001E Error code -1 from function:" SQLFreeStmt". GLPRDB045E Unable to connect to database; program terminating. db2cli.log shows: "[IBM][CLI Driver] CLI0108E Communication link failure. SQLSTATE=40003 "[IBM][CLI Driver] SQL30081N A communication error has been detected. Communication protocol being used: "TCP/IP". Communication API being used: "SOCKETS". Location where the error was detected: " ". Communication function detecting the error: "recv". Protocol specific error code(s): "2", "*", "*". SQLSTATE=08001 Current design of Directory Server (ibmslapd) is to have long running connections Restart ibmslapd to reconnect with db2. Do not stop DB2 when Directory Server (ibmslapd) is still running. 32 IBM Security

33 Useful Links

34 Useful Links Upcoming Open Mic: Upgrade from SDS 6.4 to SDS 8.01 VA to use existing remote DB2 Database SDS Knowledge Center SDS Support Portal SDS Download Document SDS Known Issues DB Knowledge Center DB2 Recommended Fix Packs Updating expired default certificates on the SDS Virtual Appliance Ask a question in either ISDS -DW Answers Forum OR Directory Suite - DW Answers Forum Passport Advantage (full product downloads) Directory Server Support Lifecycle Sign up for My Notifications Follow IBM Security support on: 34 IBM Security

35 Questions for the Panel Now is your opportunity to ask questions of our panelists. To ask a question now: Raise your hand by clicking Raise Hand. The Raise Hand icon appears next to your name in the Attendees panel on the right in the WebEx Event. The host will announce your name and unmute your line. or Type your question in the box below Ask drop-down menu in the Q&A panel. Select All Panelists from the Ask drop-down-menu. Click Send. Your message is sent and appears in the Q&A panel To ask a question after this presentation: You are encouraged to participate in our dw Answers Forums: Ask a question in either ISDS -DW Answers Forum OR Directory Suite - DW Answers Forum 35 IBM Security

36 THANK YOU FOLLOW US ON: ibm.com/security securityintelligence.com youtube/user/ibmsecuritysolutions Copyright IBM Corporation All rights reserved. The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of any kind, express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, these materials. Nothing contained in these materials is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software. References in these materials to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and / or capabilities referenced in these materials may change at any time at IBM s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way. IBM, the IBM logo, and other IBM products and services are trademarks of the International Business Machines Corporation, in the United States, other countries or both. Other company, product, or service names may be trademarks or service marks of others. Statement of Good Security Practices: IT system security involves protecting systems and information through prevention, detection and response to improper access from within and outside your enterprise. Improper access can result in information being altered, destroyed, misappropriated or misused or can result in damage to or misuse of your systems, including for use in attacks on others. No IT system or product should be considered completely secure and no single product, service or security measure can be completely effective in preventing improper use or access. IBM systems, products and services are designed to be part of a lawful, comprehensive security approach, which will necessarily involve additional operational procedures, and may require other systems, products or services to be most effective. IBM DOES NOT WARRANT THAT ANYSYSTEMS, PRODUCTS OR SERVICES ARE IMMUNE FROM, OR WILL MAKE YOUR ENTERPRISE IMMUNE FROM, THE MALICIOUS OR ILLEGAL CONDUCT OF ANY PARTY.