Building DMZ (Demilitrlalized-Zone) using webMethods

        Offering your services through the Internet requires a special setup to secure your servers. In this tutorial we will discuss the standard setup for the DMZ (demilitarized zone) using webmethods components. 

This tutorial will cover the following points:

  • The components to build Demilitrlalized-zone.
  • Configuring the ‘Enterprise gateway’
  • Configuring the ‘Internal server'(internal IS)

The components which will be used in building the DMZ are:

Firewall: is a network component used to allow/deny the network traffic using a set of rules.

WebMethods Enterprise gateway: is an integration server placed in the DMZ , it handles the communication between the external callers and the internal IS which will fulfill the request from inside the company’s network.  

Internal IS: is the the integration server which is the point of contact between the enterprise gateway in the DMZ and the internal network.

 

 Figure 1 : DMZ implementation 

 
As we see in figure 1:

  • The area between the two firewalls is the DMZ (demilitarized-zone). The servers in this area don’t include business logic or data, and have access to the internal server(internal IS).
  • The enterprise gateway will be in the demilitarized-zone between two firewalls. It is responsible for forwarding the request to the internal IS, and validate the credentials of the users.
  • On the network side we must apply the ‘natting’ technique which is mapping the IP of the server to another one when going outside the company’s network(to the Internet) to hide the IP from Internet users or hackers.
  • Firewall-1 will block all the traffic received except the traffic received to the port of the enterprise gateway.
  • Firewall-2 will block all the traffic expect the traffic between the enterprise gateway and the internal server.
  • The internal IS will automatically establish permanent connections with the enterprise gateway to be used in the communication. The advantage of this approach is that the connections between the DMZ (demilitarized-zone) and the internal company’s network will be initiated from the internal network by the internal server which reduce the security risks by limiting the access of the DMZ to the internal network.


Configuring the ‘Enterprise gateway’

         In this section we will go through configuring the enterprise gateway, which is an Integration server with a special configuration. It was introduced in webMethods for the first time in version 8 under the name of ‘reverse http gateway’.

Here are the step to convert an integration server to Enterprise gateway:

  1. From the Integration server administrator page choose ‘security > add port’. 
  2. Choose ‘enterprise gateway server’ as the port type, and click on ‘submit’. Note: in version 8.x the enterprise gateway was called ‘reverse http gateway server’.

  

3. After clicking the ‘submit’ button we will see the page in the below image:

  

Enterprise gateways external port:

  • ‘Enable’: possible values are ‘yes’ which means that the port will be enabled automatically after saving the configuration, or ‘No’ which means that you have to enable the port manually to activate the external port of the enterprise gateway.
  • Protocol: depending on the nature of the service, choose the protocol type http, or https. Note: using http or https decision has nothing to do with using DMZ decision, https will require configuring a security certificate. To be able to decide which protocol to use please check our ‘secured connection’ tutorial.
  • Port: the communication port between the users’s devices/browsers and the enterprise gateway. You have to configure firewall-1 to allow the traffic to this port.
  • Alias: is the port alias, and it must be unique on the level of the port aliases in the integration server. Ex: ExternalPort555.
  • Package name: the package which the port will be associated to it. Please leave the defaul value ‘wmRoot’ to make sure that the port is available as long as the integration server is up.
  • Client authentication: possible values are 1)user/password users have to provide their credentials to access the service, 2) digest, 3)request client certificate: if the customer doesn’t represent the certificate the gateway will use the user/password, 4) require client certificate: if the customer doesn’t represent the security certificate the request will be rejected.

Enterprise gateways registeration port:

  • ‘Enable’: The same above explanation as the port external port settings.
  • Protocol: The same above explanation as the external port settings.
  • Port: is the port to be available for the communication between the enterprise gateway and the internal IS. You have to allow the traffic from the internal IS to this port in firewall-2 access rules.
  • Package: The same above explanation as the external port settings. The value must match the value of pacakge field in the external port settings.
  • Client authentication: The same above explanation as the port external port settings.

4. Click on ‘save changes’ button after finalizing your configuration.


Configuring the ‘Internal server'(internal IS)

  1. From the Integration server administrator page choose ‘security > add port’. 
  2. Chose ‘Internal server’ as the port type, and click on ‘submit’.
  3. After clicking the ‘submit’ button we will see the page in the below image.


  

Internal server configuration:

  • Enable: choose ‘yes’ if you want to enable the port automatically after saving the settings, and choose ‘no’ if you want to enable it later manually from IS admin > security >ports.
  • Protocol: choose http or https depending on the nature of your service as we stated earlier in this tutorial.
  • Pacakge name: the pacakge which the port will be associated with it. Please keep the default value ‘wmRoot’.
  • Alias: the unique alias of the port on the level of the IS as explained earlier.
  • Enterprise gateway server: the host and port of the enterprise gateway to establish the permanent connection which will be used in the communication between the enterprise gateway and the internal server.
  • Client authentication: the same options explained earlier in the enterprise gateway configuration. 

4. After finalizing the configuration click ‘save changes’ button.

  Now our infrastructure is ready to receive requests from the Internet.
Thank you for visiting our website. We are looking forward reading your comments and questions.
Follow us:

on twitter: @WM_Expert

Group on LinkedIn: webmethodsExpert.com

(C) 2015 Hossam Elsharkawy. All rights reserved.


Create/Manage KeyStore and TrustStore

This tutorial will discuss how create and manage the keystore and truststore. We will be using openSSL (open source tool), and the java keytool (existing with any jvm installation).

If you are not familiar with the security certificates and how it works,It is strongly recommended to review our last articles ‘creating security certificate tutorial’, here is the link:

https://webmethodsexpert.com/2014/11/24/creating-security-certificate-tutorial/

We will discuss the following points :

  1. What is key store and trust store?
  2. Why using the key store and trust store?
  3. Create the keystore.
  4. Manage the store with the java keytool.

 

1. What is key store and trust store?

It is a password protected file which is used to store security certificates, private keys, and root security certificates. The most common types are JKS (Java ket store), and PKCS12. The key store and trust store have the same format and capabilities, the difference is in how you use them in your application.

Key store is used when your server is offering a secured connection (ex. https) to clients or servers, and it stores pair of private key, and security certificate.

Trust store is used when you receive secured calls (ex. https), it stores the following:

  1. Root security certificate (Certification authority certificate) : which is used to trust all the certificate issued by specific entity. Ex. Verisign certificate.
  2. The partner’s self-signed certificate : add the security certificate of the server calling you if you in the development or test servers and you use self-signed certificate, or if you have a partner who you trust and who uses self-signed certificate.

2. Why using keystore and truststore?

‘Security in depth’ is a concept which promotes the idea of creating layers of security, and more layers = more security. So by protecting your private key, and the certificate you trust in case of the trust store by putting them in a password protected file will add a layer of security.

To make it easier imagine the following situations :

  • Your private key file is stored in a location in your application/server (in some cases without encryption), so anyone can access your server can take a copy from it and use it to decrypt your messages, or pretend that the message is coming from you.
  • You use a specific folder to store the root security certificates, or partner security certificates you trust. So if someone copied a fake certificate in this folder your server will accept requests from untrusted server.

The two above situations can be avoided by using the keystore and truststore.

3. Create the keystore

For the keyStore you need to store your private key file, and your server certificate. You have two ways to do it:

  1. Use the openSSL to generate the keystore with the private key and the certificate in the PKCS12 fromat (and you can convert it to JKS format with the java keytool).
  2. Use the KeyTool to create the the JKS keystore, this option is not valid if you already have the certificate and private key. The only way to do it is by creating the private key, and generate the CSR (certificate signing request). This is not always practical specially in the case of the self-signed certificate. (we will not cover this way in the tutorial).

So follow these steps to create your keystore:

1. Create the key store in the PKCS12 format. by executing this command in the openSSL:

openssl pkcs12 -export -name myAlias -in myServer.crt -inkey myServer.key -out myKeyStore.p12

myServer.key : is the server’s private key
myServer.crt : is the server’s security certificate
myAlias : is the alias you will be using in your code to access the private key. The alias must be unique in each keystore, the alias is unique in this case as we are creating a new store.
myKeyStore.p12:  is the name of the new keystore generated from the command.

Note : the new keystore ‘myKeyStore.p12’ will be in the bin directory of the openSSL.

2. Converting the keystore from the PKCS12 to JKS

We will use the java keytool which is a part from the installation of the JVM, you should find it in the following bin folder :’\jvm\jvm\bin’

keytool -importkeystore -srckeystore myKeyStore.p12 -srcstoretype pkcs12 -destkeystore myKeyStore.jks -deststoretype jks

4. Manage the store with the java keytool.

Creating the truststore

The following command can be used to import the root certificate of the self-signed certificate.

keytool -import -file server.crt -alias myCertAlias -keystore myTrustStore.jks

server.crt: The security certificate you want to import to the truststore.

myCertAlias: The unique alias you will be using to access the certificate from the store

myTrustStore.jks: The name of the truststore file. If the file doesn’t exist the keytool will create a new file, and if it was existing the certificate will be added to it.

Delete certificate from the truststore

To delete a certificate from an existing truststore.

keytool -delete -alias myCertAlias -keystore myTrustStore.jks

myCertAlias: the alias of the certificate to be deleted.

myTrustStore.jks: the name of the keystore which contain the certificate ti be deleted.

List the certificates in the Store

List the items in the store, usually we use it to see what is in the truststore as it might contains more than a certificate, however you can use it to see the contents of keystore.

Keytool -list -keystore mytruststore.jks

mytruststore.jks: is the name of the store file (keystore or truststore)

Change Alias in Trust Store or key store

To change the alias of an existing entry in the store use the following command:

keytool -changealias -alias oldAlias -destalias newAlias -keystore myStore.jks

oldAlias: is the old alias name to be changed.

newAlias: is the new alias name.

myStore.jks: the JKS file name which contain the alias to be changed.

 

Thank you for visiting our website. We are looking forward reading your comments and questions.

Follow us:

on twitter: @WM_Expert

Group on LinkedIn: webmethodsExpert.com

(C) 2014 Hossam Elsharkawy. All rights reserved.