security best practices for informix

48
© 2015 IBM Corporation Security Best Practices for Informix 2050A Jonathan Leffler [email protected]

Upload: ibminfomanagement

Post on 11-Jan-2017

2.932 views

Category:

Technology


5 download

TRANSCRIPT

Page 1: Security best practices for informix

© 2015 IBM Corporation

Security Best Practices for Informix 2050A

Jonathan Leffler

[email protected]

Page 2: Security best practices for informix

• IBM‘s statements regarding its plans, directions, and intent are subject to change or withdrawal

without notice at IBM‘s sole discretion.

• Information regarding potential future products is intended to outline our general product direction

and it should not be relied on in making a purchasing decision.

• The information mentioned regarding potential future products is not a commitment, promise, or

legal obligation to deliver any material, code or functionality. Information about potential future

products may not be incorporated into any contract.

• The development, release, and timing of any future features or functionality described for our

products remains at our sole discretion.

Performance is based on measurements and projections using standard IBM benchmarks in a

controlled environment. The actual throughput or performance that any user will experience will vary

depending upon many factors, including considerations such as the amount of multiprogramming in the

user‘s job stream, the I/O configuration, the storage configuration, and the workload processed.

Therefore, no assurance can be given that an individual user will achieve results similar to those stated

here.

Please Note:

2

Page 3: Security best practices for informix

2

Agenda

• Server Administration

• Access to Server Files

• Connection Security

• Access to Server Data

• Audit

• Server Log

Page 4: Security best practices for informix

3

Users root and informix

• The root user can ultimately do anything

Who knows the root password?

How do users become root?

• The informix user is omnipotent on the IDS server

Who knows the informix password?

How do administrators become informix?

• sudo

• Use Role Separation as an alternative

Page 5: Security best practices for informix

4

Role Separation

• Alternative to all administrators using user informix

• Do not add users to group informix

• DBSA depends on group of INFORMIXDIR/etc

• DBSSO group depends on group of INFORMIXDIR/dbssodir

• AAO group depends on group of INFORMIXDIR/aaodir

• Backup and Recovery group — bargroup

Page 6: Security best practices for informix

5

How to Enable Role Separation

• On Windows, role separation is enabled during install

Re-install IDS if necessary

No other supported way of doing it

• On Unix, role separation can be set during install

Choose the option (AAO and DBSSO only)

Page 7: Security best practices for informix

6

How to Enable Role Separation

• On Unix, role separation can be changed after install

DBSA etc

AAO aaodir

DBSSO dbssodir

Change group that owns relevant directory

• Set SGID bit on directory

• Restart IDS

Fix permissions on oninit for the DBSA group

• chmod o+x $INFORMIXDIR/bin/oninit

Fix group permissions on $ONCONFIG (dbsa group)

Fix group permissions on aaodir/adtcfg (aao group)

Page 8: Security best practices for informix

7

Server File Access

• IDS depends on several files

Server installation

Configuration files

Data files — chunks

• Required owner, group, mode

World access – NO

• onsecurity utility

Page 9: Security best practices for informix

8

Server Installation and Setup

• Isolate the Data Server

Place the data server on its own machine

• Use appropriate controls on who can access the server machine

• Use firewalls as appropriate

• Don‘t let arbitrary users on arbitrary machines access the server ports

Separate the data server from application servers

• Especially web servers

When not possible to use separate hardware

• Split client INFORMIXDIR from server

Page 10: Security best practices for informix

9

Insulate Servers from Change

• Always install new versions in a new directory

This limits downtime

And provides safe backout strategy

• Make sure INFORMIXDIR is a symbolic link

• Standardize the ONCONFIG file

• If you have multiple instances on a single machine

Keep each one in a separate INFORMIXDIR

• Always deny public write access

• Usually deny public read access

Page 11: Security best practices for informix

10

Insulate Servers from Change

• Keep things that stay constant out of INFORMIXDIR

Device files

Log files

• Think of INFORMIXDIR as ‗long-term temporary‘

It will be removed after next upgrade

Page 12: Security best practices for informix

11

Insulate Servers from Change

• DUMPDIR should not point to /tmp

• DUMPDIR big enough for 2 shared memory dumps

• Use standard names and locations for chunks

Always use symbolic links to the actual chunks

• Ensure security of sub-directories of $INFORMIXDIR

Also security of directories to device (chunk) directory

• Use a separate directory for user informix‘s home

Do not use $INFORMIXDIR

Page 13: Security best practices for informix

12

The onsecurity Utility (UNIX and Linux)

• onsecurity utility checks the security of a file, directory, or path

• Troubleshoots security problems if any are detected

• Use the onsecurity command to:

Check the security of the path leading to a directory or a file

Generate diagnostic output to explain the security problems

Generate a script that can be run by root to fix the problems

• You can use the script as generated

• Or modify it to your environment‘s security needs

Page 14: Security best practices for informix

13

The onsecurity Utility (UNIX and Linux)

• For special circumstances only:

• Specify that particular users, groups, or directories can be trusted:

Add the information to files in the /etc/informix directory

• trusted.users

• trusted.groups

• trusted.insecure.directories

• Normally, you will be told that the path is secure

• If the path is secure, you do not need to do anything more

Page 15: Security best practices for informix

14

An example of onsecurity at work

$ onsecurity /work/informix/ids-11

# !!! SECURITY PROBLEM !!!

# /work/informix/ids-11 (path is not trusted)

# Analysis:

# User Group Mode Type Secure Name

# 0 root 0 root 0755 DIR YES /

# 0 root 0 root 0755 DIR YES /work

# 203 unknown 8714 ccusers 0777 DIR NO /work/informix

# 200 informix 102 informix 0755 DIR NO /work/informix/ids-11

# Name: /work/informix

# Problem: owner <unknown> (uid 203) is not trusted

# Problem: group ccusers (gid 8714) is not trusted but can modify the directory

# Problem: the permissions 0777 include public write access

Page 16: Security best practices for informix

• The informix directory of the path /work/informix has problems:

the owner of this directory is not a trusted user

the group that controls the directory is not trusted

the directory has public write access

• Possible fixes:

Change the owner to root or informix

Change the group to a system group or informix

Remove public write access

• Or grant exemptions

Dangerous, in general!

The onsecurity Utility example

15

Page 17: Security best practices for informix

16

• At server startup, oninit checks the security of key directories:

Subdirectory Owner Group Permissions

INFORMIXDIR informix informix 755

bin informix informix 755

lib informix informix 755

gls informix informix 755

msg informix informix 755

etc informix DBSA 775

aaodir informix AAO 775

dbssodir informix DBSSO 775

tmp informix informix 770

Security checking at server startup

Page 18: Security best practices for informix

17

INFORMIXDIR permissions

• Many Informix utilities check file permissions at startup

• Errors detected at this point will be reported

And the program will exit

• Run onsecurity with appropriate options

• Refer to Chapter 1, IBM Informix Security Guide

Page 19: Security best practices for informix

18

Backup and Restore (BAR)

• Members of bargroup are allowed to do backup and restore

bargroup is a Unix group with a fixed name

• Backup is just as sensitive as live data

Data has been compromised by loss of backup media

Protect the backup copy

Page 20: Security best practices for informix

19

Connection Security

• Control who can connect to the server

by default anyone with login access to machine

or a ―trusted‖ machine (hosts.equiv, .rhosts)

• Think about using PAM

even for UNIX type access

can be used to deny access to certain accounts

• e.g. Linux pam_access.so

• Encrypted connections to server

Without encryption, passwords are sent in plain text.

ENCCSM

SPWDCSM

SSL

Page 21: Security best practices for informix

• Avoid using the old r-command configuration files

• Use new configuration parameters

REMOTE_SERVER_CONFIG

• Which remote machines should be trusted

REMOTE_USERS_CONFIG

• Which remote users should be trusted

• Instead of /etc/hosts.equiv and ~/.rhosts

Connection Security

20

Page 22: Security best practices for informix

21

Enabling Encrypted Communications

• Create or modify server entry in sqlhosts file

server_1_enc olsoctcp host 9089 csm=(s1_enc)

• Create or modify concsm.cfg file

s1_enc("/usr/informix/lib/csm/libixenc.so", "cipher[aes:cbc],timeout[cipher:1440,key=60], mac[levels:<high,medium>,files:<builtin>]”)

• Add new server alias to ONCONFIG

• Restart IDS

Page 23: Security best practices for informix

22

Enabling Encrypted Communications

• ODBC can use ENCCSM

• JDBC can use an equivalent of ENCCSM

String Url = "jdbc:informix-

sqli://host:9089/sysmaster:informixserver=serve

r_1_enc;user=bob;password=bobpass;csm=(classnam

e=com.informix.jdbc.Crypto,config=concsm.cfg";

• For more details, see Informix Security Guide

Page 24: Security best practices for informix

23

JCC and JDBC

• Java Common Client (JCC) provides encryption

Using GSKit and SSL

• http://tinyurl.com/467gpr

• http://tinyurl.com/4jr4yu

• Legacy JDBC type IV driver provides encryption

Password encryption

• SPWDCSM

Full encryption

• ENCCSM

Page 25: Security best practices for informix

• New communication protocol

drsocssl — SSL for DRDA clients

olsocssl — SSL for SQLI client

• Also supported for server to server communications

• I-Star, HDR, ER, RSS, SDS

• Example sqlhosts file entries

horus_31_ol_ssl olsocssl horus horus_ol_ssl

horus_31_dr_ssl drsocssl horus horus_dr_ssl

Setting up SSL — sqlhosts

24

Page 26: Security best practices for informix

• SSL_KEYSTORE_LABEL

Specifies label of server digital certificate in keystore

• If not specified in ONCONFIG, uses default label in keystore

• But default label is officially deprecated — be explicit

• SSL_KEYSTORE_LABEL ids_ssl_label

• Extra options for NETTYPE

NETTYPE protocol, poll threads, connections, VP class

• Specify the protocol as iiippp

• Where:

– iii=[ipc||soc|tlli]

– ppp=[shm|str|tcp|spx|ssl]

• NETTYPE socssl, 3, 50, NET

Setting up SSL — onconfig

25

Page 27: Security best practices for informix

• All encryption/decryption options performed on encrypt VPs

• Encrypt VPs configured via VPCLASS

VPCLASS encrypt,num=5

• Support encrypted and non-encrypted connections

DBSERVERNAME horus_31

DBSERVERALIASES horus_31_ol_ssl,horus_31_dr_ssl

Setting up SSL — onconfig

26

Page 28: Security best practices for informix

• IBM‘s Global Security Kit, GSKit, is installed with Informix

Server

ClientSDK and Connect

• GSKit contains gsk8capicmd_64 utility

Used to create keystores and manage digital certificates

Needed for SSL communication

• More information on gsk8capicmd_64 at

http://www-01.ibm.com/support/knowledgecenter/SSVJJU_6.2.0/com.ibm.IBMDS.doc/admin_gd174.htm

Keystores and Digital Certificates

27

Page 29: Security best practices for informix

• The keystore for server is password protected

• Password is stored encrypted in stash file

Also created by gsk8capicmd_64 utility

• One keystore per server instance.

It stores server‘s digital certificate

And root CA certificates of other servers it connects to

• As in I-STAR, HDR, ER, SDS, RSS

Keystores and Digital Certificates

28

Page 30: Security best practices for informix

• The location and name of the files are fixed

Server keystore

• $INFORMIXDIR/ssl/server.kdb

Server password stash

• $INFORMIXDIR/ssl/server.sth

Based on value of DBSERVERNAME

• Ownership and permissions must be correct

User informix, group informix, 660

Keystores and Digital Certificates

29

Page 31: Security best practices for informix

• Client keystore stores root CA certificates

For all servers the client connects to

• SQLI and DRDA clients can share same keystore

• Password is optional for client keystore

• Location and name of client keystore and its password stash file can be configured via new configuration file:

$INFORMIXDIR/etc/conssl.cfg

• Note you need to set the permissions on client files correctly

Setting up SSL — Client

30

Page 32: Security best practices for informix

• Configuration parameters in conssl.cfg

SSL_KEYSTORE_FILE

• Absolute path name for client keystore file

SSL_KEYSTORE_STH

• Absolute path name for client stash file

• If conssl.cfg does not exist, defaults to

$INFORMIXDIR/etc/client.kdb

$INFORMIXDIR/etc/client.sth

• Permissions on these files should be:

User informix, group informix, permissions 664

Setting up SSL — Client

31

Page 33: Security best practices for informix

32

Access to Data

• Who creates databases?

DBCREATE_PERMISSION

Add a DBCREATE_PERMISSION entry

• For each user who needs to create databases

• Discretionary Access Control

Users should be granted appropriate level of access to databases and database objects.

Use roles for ease of administration

• GRANT privilege to role

• GRANT role to user

• GRANT default role

Privileges can be granted at DATABASE and TABLE level

Page 34: Security best practices for informix

33

Other ONCONFIG parameters

• IFX_EXTEND_ROLE

Controls whether administrators can use the EXTEND role to specify which users can register external routines.

• 0 Any user can register external routines

• 1 Only users granted the EXTEND role can register external routines (Default)

• DB_LIBRARY_PATH

Specifies the locations from which Informix can use UDR or UDT shared libraries.

Page 35: Security best practices for informix

34

Other ONCONFIG parameters

• SECURITY_LOCALCONNECTION

Specifies whether IDS performs security checking for local connections.

• 0 Off

• 1 Validate userid

• 2 Validate userid and port

• UNSECURE_ONSTAT

Controls whether non-DBSA users are allowed to run all onstat commands.

• 0 Disabled (Default)

• 1 Enabled

Page 36: Security best practices for informix

35

Other ONCONFIG parameters

• ADMIN_USER_MODE_WITH_DBSA

Controls who can connect to IDS in administrative mode

• 0 Only informix user (Default)

• 1 DBSAs, users specified by ADMIN_MODE_USERS, and user informix

• ADMIN_MODE_USERS

Specifies the user names who can connect to IDS in administrative mode,

• SSL_KEYSTORE_LABEL

The label, up to 512 characters, of the IDS certificate used in Secure Sockets Layer (SSL) protocol communications.

Page 37: Security best practices for informix

36

Column Level Encryption (CLE)

• Column-level encryption stores sensitive data as encrypted strings

• Use it to selectively encrypt sensitive data

Such as credit card numbers

• Only users who can provide the password can decrypt the data

• Use the ENCRYPT_AES() and ENCRYPT_TDES() functions to encrypt data in columns

• You can sometimes use SET ENCRYPTION PASSWORD

To set an encryption password for a session

• INSERT INTO tab1(ssn) VALUES

(ENCRYPT_AES("111-22-3333", "password"));

• SELECT DECRYPT(ssn, "password") from tab1;

Page 38: Security best practices for informix

37

Label Based Access Control – LBAC

• Label-based access control (LBAC)

Enterprise Edition only

An implementation of multi-level security (MLS)

You control who has read access and who has write access

• To individual rows and columns of data

• MLS systems process information with different security levels

Permit simultaneous access by users with different security clearances

Allow users access only to information for which they have authorization

Page 39: Security best practices for informix

38

Label Based Access Control – LBAC

• Create Security Policy and attach it to a table

• Create Security Labels and attach labels to data

• Grant labels to users

• Users can only access data with labels that ―match‖ theirs

Page 40: Security best practices for informix

39

Audit

• Audit allows you to keep a log of important server events

• You should enable IDS auditing

Decide which events need to be audited

Decide which users need to be audited

• Audit the DBSA

Setup Appropriate Audit Masks

• Examine the audit logs for unexpected events

onshowaudit

• Save the audit logs

Easily compressible

Event generated when change to next audit log file

• Protect the audit logs carefully

Page 41: Security best practices for informix

40

IDS Server Log

• Lots of valuable information is written to the server log

Failed login attempts

Audit Mode changes

Audit log file changes

• But you have to look!

Be sure to monitor its contents

Page 42: Security best practices for informix

41

IBM Data Server Security Blueprint

Page 43: Security best practices for informix

42

IDS Security Guide

• Read and follow the IDS Security Guide

Page 44: Security best practices for informix

© 2015 IBM Corporation

Questions?

Best Security Practices for Informix

43

Page 45: Security best practices for informix

We Value Your Feedback!

Don‘t forget to submit your Insight session and speaker

feedback! Your feedback is very important to us – we use it

to continually improve the conference.

Access the Insight Conference Connect tool at

insight2015survey.com to quickly submit your surveys from

your smartphone, laptop or conference kiosk.

44

Page 46: Security best practices for informix

45

Notices and Disclaimers

Copyright © 2015 by International Business Machines Corporation (IBM). No part of this document may be reproduced or transmitted in any form

without written permission from IBM.

U.S. Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM.

Information in these presentations (including information relating to products that have not yet been announced by IBM) has been reviewed for

accuracy as of the date of initial publication and could include unintentional technical or typographical errors. IBM shall have no responsibility to

update this information. THIS DOCUMENT IS DISTRIBUTED "AS IS" WITHOUT ANY WARRANTY, EITHER EXPRESS OR IMPLIED. IN NO

EVENT SHALL IBM BE LIABLE FOR ANY DAMAGE ARISING FROM THE USE OF THIS INFORMATION, INCLUDING BUT NOT LIMITED TO,

LOSS OF DATA, BUSINESS INTERRUPTION, LOSS OF PROFIT OR LOSS OF OPPORTUNITY. IBM products and services are warranted

according to the terms and conditions of the agreements under which they are provided.

Any statements regarding IBM's future direction, intent or product plans are subject to change or withdrawal without notice.

Performance data contained herein was generally obtained in a controlled, isolated environments. Customer examples are presented as

illustrations of how those customers have used IBM products and the results they may have achieved. Actual performance, cost, savings or other

results in other operating environments may vary.

References in this document to IBM products, programs, or services does not imply that IBM intends to make such products, programs or services

available in all countries in which IBM operates or does business.

Workshops, sessions and associated materials may have been prepared by independent session speakers, and do not necessarily reflect the

views of IBM. All materials and discussions are provided for informational purposes only, and are neither intended to, nor shall constitute legal or

other guidance or advice to any individual participant or their specific situation.

It is the customer‘s responsibility to insure its own compliance with legal requirements and to obtain advice of competent legal counsel as to the

identification and interpretation of any relevant laws and regulatory requirements that may affect the customer‘s business and any actions the

customer may need to take to comply with such laws. IBM does not provide legal advice or represent or warrant that its services or products will

ensure that the customer is in compliance with any law.

Page 47: Security best practices for informix

46

Notices and Disclaimers (con‘t)

Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly

available sources. IBM has not tested those products in connection with this publication and cannot confirm the accuracy of performance,

compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the

suppliers of those products. IBM does not warrant the quality of any third-party products, or the ability of any such third-party products to

interoperate with IBM‘s products. IBM EXPRESSLY DISCLAIMS ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING BUT NOT

LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.

The provision of the information contained herein is not intended to, and does not, grant any right or license under any IBM patents, copyrights,

trademarks or other intellectual property right.

• IBM, the IBM logo, ibm.com, Aspera®, Bluemix, Blueworks Live, CICS, Clearcase, Cognos®, DOORS®, Emptoris®, Enterprise Document

Management System™, FASP®, FileNet®, Global Business Services ®, Global Technology Services ®, IBM ExperienceOne™, IBM

SmartCloud®, IBM Social Business®, Information on Demand, ILOG, Maximo®, MQIntegrator®, MQSeries®, Netcool®, OMEGAMON,

OpenPower, PureAnalytics™, PureApplication®, pureCluster™, PureCoverage®, PureData®, PureExperience®, PureFlex®, pureQuery®,

pureScale®, PureSystems®, QRadar®, Rational®, Rhapsody®, Smarter Commerce®, SoDA, SPSS, Sterling Commerce®, StoredIQ,

Tealeaf®, Tivoli®, Trusteer®, Unica®, urban{code}®, Watson, WebSphere®, Worklight®, X-Force® and System z® Z/OS, are trademarks of

International Business Machines Corporation, 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" at:

www.ibm.com/legal/copytrade.shtml.

Page 48: Security best practices for informix

© 2015 IBM Corporation

Thank You