How to protect the communication between the Snap Creator Server and Agents

by Occasional Contributor on ‎2013-02-28 10:35 AM

Have you ever been asked by a customer about the security of the communication between the Snap Creator Server (SCS) and the respective Snap Creator Agents (SCA)?

I was involved in a customer Situation where we needed to install Snap Creator in a PCI - DSS environment, and during the discussions with the project team we jointly came to the conclusion

that the current state of security provided by the SCS to SCA communication was not sufficient for the rather elevated requirements posed by the auditor.

There has been indications that this will be fixed by introducing https as the transport protocol between the server and the agent in further releases of Snap Creator. 

We were in the situation that we needed to increase the security now!

After some research and trial it was decided that stunnel would be used.

The rational for this was:

  • Certificate based authentication of client and server
  • FIPS-140-2 Certification 
  • Multiplatform support (Windows & Linux)
  • Ease of configuration

stunnel effectivly is a generic SSL proxy for generic arbitrary protocols. 

How was this done:


1. Snap Creator Server (4.0) setup on a Linux host 

2. The Snap Creator Agents were installed on the respective hosts

3. Stunnel binaries were installed on the SCS & SCA hosts

4. Setup a Open SSL Certificate Authority to be used to create the certificates needed for the stunnel verification

This can either be done by using certificates from an external CA if one is available. A very thorough guide is available here

Create Root CA

openssl req -config openssl.cnf -new -x509 -extensions v3_ca -keyout private/ca.key -out certs/ca.crt -days 3650

Create the certificate for the Snap Creator Server

This needs to be done once for each Snap Creator Server. In this setup I've just have one.

Start by creating a Certificate Signing Request 

openssl req -config openssl.cnf -new -nodes -keyout private/scs.key -out csr/scs.csr -days 365

Sign the CSR using the Root - cert of the CA

openssl ca -config openssl.cnf -policy policy_anything -out certs/scs.crt -infiles csr/scs.csr

This will give you the private key and the certificate for the Snap Creator Server  

Create the certificate for the Snap Creator Server

openssl req -config openssl.cnf -new -nodes -keyout private/cent-db-01.key -out csr/cent-db-01.csr -days 365

openssl ca -config openssl.cnf -policy policy_anything -out certs/cent-db-01.crt -infiles csr/cent-db-01.csr

This will give you the private key and the certificate for the Snap Creatore Agents. For each server that has an SCA installed one

certificate has to be created

5. configure stunnel

Setup for Linux

The file  /etc/stunnel/stunnel.conf  contains the configurations for the stunnel proxy. It has to be configured individually for each SCS & SCA

For security purposes the stunnel proxy will run in an chroot environment.

The stunnel(s) are to be  configured so that they will verify the validity of the other partner in the communication. For this the previously created certificates will be used.

stunnel config for the Snap Creator Server

# Run chrooted as nobody

chroot = /var/run/stunnel

setuid = nobody

setgid = nobody

pid = /stunnel

# SSL Certificates

cert = /etc/stunnel/scs.crt

key  = /etc/stunnel/scs.key

verify = 3

CAfile = /etc/stunnel/ca.crt

CApath = /certs

foreground = no

client = yes

[sca-cent-db-01]

accept = 0.0.0.0:9190

connect = 10.68.9.62:9091

stunnel config for the Snap Creator Agent

# Run chrooted as nobody

chroot = /var/run/stunnel

setuid = nobody

setgid = nobody

# SSL Certificates

cert = /etc/stunnel/cent-db-01.crt

key  = /etc/stunnel/cent-db-01.key

verify = 3

CAfile = /etc/stunnel/ca.crt

CApath = /certs

foreground = no

client = no

[sca-cent-db-01]

accept  = 10.68.9.62:9091

connect = localhost:9090

6. Create the respective Snap Creator configuration

The configuration will be setup exactly the same way as normally with the exception that the agent will not be accessed by pointing to its ip of the agent but to the

port of the local endpoint of

In this case we will point it to localhost:9190

...

##########################################################################

##############################################

#     Agent Options

                                           #

##########################################################################

##############################################

SC_AGENT_UNQUIESCE_TIMEOUT=305

SC_AGENT_WATCHDOG_ENABLE=N

SC_AGENT=localhost:9190

SC_AGENT_LOG_ENABLE=N

SC_AGENT_TIMEOUT=60

...

7. Enjoy


Comments
Frequent Contributor

This is a great post - thanks for sharing this information!

Warning!

This NetApp Community is public and open website that is indexed by search engines such as Google. Participation in the NetApp Community is voluntary. All content posted on the NetApp Community is publicly viewable and available. This includes the rich text editor which is not encrypted for https.

In accordance to our Code of Conduct and Community Terms of Use DO NOT post or attach the following:

  • Software files (compressed or uncompressed)
  • Files that require an End User License Agreement (EULA)
  • Confidential information
  • Personal data you do not want publicly available
  • Another’s personally identifiable information
  • Copyrighted materials without the permission of the copyright owner

Files and content that do not abide by the Community Terms of Use or Code of Conduct will be removed. Continued non-compliance may result in NetApp Community account restrictions or termination.