November 18, 2015 | Written by: Lionel Mace
Share this post:
This post is the second in a two part series on real-life production experience with Secure Gateway. In the previous post, we discussed the main challenges when setting up the gateway. In this post, we focus on the security challenges: How do you guaranty an end-to-end secure connection? What about certificates? Which firewall rules do I need to set up?
Q13: How do you secure an end-to-end connection with the Secure Gateway?
Destinations defined within the Secure Gateway can use HTTP/HTTPS, unencrypted TCP, TLS server-side, and TLS Mutual Auth. TLS Mutual Auth is the obvious secure option for something like a database. Those options only apply to the connection between the application and the front-side host/port of the Secure Gateway servers. In the Advanced options, you can select client-side TLS to secure the connection between the gateway client and the on-premises destination (e.g. MongoDB).
Q14: Which ports does Secure Gateway Client use?
Before you install the gateway client into your environment, ensure that both the internet and your on-premises assets are accessible and all host names are resolvable by a DNS. The client uses outbound port 443 to connect to the IBM Bluemix environment; normally this port is open since it’s secure. Ensure you check or modify additional firewall and IP Table rules that might apply. The client also uses port 9000.
Port 443 and 9000 are for outbound calls only so that the client can establish a connection to the server. If you are closing down both outbound and inbound ports using your firewall, you will need to allow ports 443 and 9000. In addition to the TLS security, we have the option to set iptable rules further restricting access to the specific ports belonging to each endpoint.
Q15: Is it possible to drain logs from Bluemix over the Secure Gateway tunnel?
Bluemix aggregates logs for all instances of your applications as well as for requests made to your applications through the Cloud Foundry Loggregator. This Loggregator is able to drain these logs using syslog, which can be configured to use the Secure Gateway cloud-side host and port to push logs down the pipe to an external log management service such as ELK. The configuration for this kind of setup is equivalent to using the Secure Gateway connection from a Bluemix application.
Cloud Foundry uses the syslog URL to route messages to the service. The syslog URL has a scheme of syslog, syslog-tls, or https, and can include a port number. For example, the syslog URL would use the Secure Gateway host/port:
Q16: How do you secure the connection between the Bluemix app and the Secure Gateway?
For the connection between the Bluemix application and the front-side cloud host/port, the options are plain TCP, TLS server-side auth, and TLS Mutual Auth. Mutual authentication is the obvious choice for any connections that handle sensitive data transfers, as each side can be sure there is no HTTPS proxy (spyware, or hacker) inspecting the traffic between the server and the client.
Q17: How does the data center’s network need to configured?
A Secure Gateway instance runs in two parts, as shown in Reaching enterprise backend with Bluemix Secure Gateway via console: the gateway server and the gateway client. The gateway server runs in Bluemix, the gateway client runs in the data center containing one or more systems of record to connect to. The gateway client needs network access to the Bluemix data center (typically via the Internet) and to the systems of record (via the data center’s internal network). The gateway client initiates the connection, so it needs to know Bluemix’s address, but Bluemix doesn’t need to know the gateway client’s address. In summary:
- The gateway and its client need direct access to each other. A proxy isn’t supported.
- The connection uses HTTPS for SSL encryption. The transport level security (TLS) options can be used to add authentication.
- Bluemix’s IP addresses aren’t published.
Q18: For security reason, our firewall is configured with a timeout when there is no traffic. Does the Secure Gateway keep the session alive or is able to reestablish it?
The tunnel connection between the Docker client and the server does send ping-pong messages back and forth. If disconnected, the client will automatically attempt to reconnect to the server every 5 seconds.
Q19: Behind a firewall network, why are the Secure Gateway details never displayed in the dashboard?
The Secure Gateway UI uses a websocket connection to provide the stats streaming and real-time updates of things like connected status, etc. The websocket connects to the
sgmanager.ng.bluemix.net proxy URL, so you would need to allow this in your firewall rules in order for the UI to function correctly inside your environment.
As for the ACL allow rule on the command line, you can provide a file with your ACLs with
--F. See how to access your files from the docker container: IBM/secure-gateway-client docker run with the –F option on Stack Overflow. Beginning with Secure Gateway version 1.3.0, acl deny all is enabled until you supply an ACL to allow access to on-premises resources.
Q20: What is the security level available between gateway client to destination end point?
The connection between the docker client on-premises and the actual endpoint can be configured to use single cert TLS.
Q21: What is recommended in terms of certificates?
IBM recommends you provide your own certificate. If you choose TLS Mutual Auth, there is the option to upload your own certificate. You can also utilize your certificate. If you have MongoDB running SSL, you can use the certificate from MongoDB on the client side. You can use two certificates, one on the server side and on the client side.<
Mutual authentication is the baseline to provide strong authentication with upload of certificates on the Secure Gateway to use our own certificates.
Q22: How do you store those certificates uploaded in the Secure Gateway?
Uploaded certificates get encoded and stored in a Cloudant DB. The communication between Secure Gateway and our Cloudant DB is TLS secured. This is not a keystore.
Q23: What is the lifecycle of the client token?
Token expiration used to authenticate the client to the Secure Gateway can be defined by the user, and a new token can be generated at any time in case of compromise.
Q24: Does the IP address of Secure Gateway server change in case of failover?
No, the IP address of the Secure Gateway server will remain the same even if there is a failover.
Q25: Can I filter IP address on my datacenter where the gateway client is running?
Secure Gateway uses static public IP to connect to the Secure Gateway server, thus enables you to filter outgoing access.
Q26: Do we need to open the firewall with the Secure Gateway IP addresses or with the application IP address? If it is the Secure Gateway IP addresses, which port do we need to open?
It is the Secure Gateway servers that the gateway client will actually be connecting out to. The first call goes to the Datapower proxy load-balancer (sgmanager.eu-gb.bluemix.net), so that will need to be allowed as well on port 443. The second call from the client goes directly to one of our server nodes on port 9000.