GatewayScript is what is called a new capability that will be available in the upcoming DataPower firmware version 7.0. A lot of attention has been put into this topic recently and it will be present in at least four different presentations at Impact 2014 by the end of this month.
The GatewayScript expands the number of programming languages currently available in DataPower. GatewayScript is completely based on JavaScript language and brings to the table all the power that its base language has to offer.
It does not mean that the available programming languages, such as XSLT and XQuery, were lacking power. The main idea on bringing a new programming language to the table is to leverage common programming skills, speeding up DataPower adoption and making it even more popular.
New ways to debug code have also been made available for the GatewayScript functionality, making it possible to add break points, print variable values, explore stack trace, etc.
Performance is not supposed to be an issue with the new available language, as the code will be compiled, cached and reused on demand. IBM keeps promising wire-speed for processing.
Examples will be provided with the new firmware in order to give us a better idea on what exactly can be accomplished with this new capability. They will be located under store:///gatewayscript/example-*.js.
In the morning of April 15th, Tony Ffrench (STSM DataPower Architect), Tim Smith (DataPower Architect) and Ozair Sheikh (DataPower Product Line Manager), gave a very rich presentation at the WebSphere User Group website, about the new capabilities that will be available on the new firmware version. If you did not have a chance to attend to this webinar, you can download the presentation used by them right here.
To see the official IBM announcement of the new firmware version 7.0, click here.
EDIT: On April 17th, the replay of the above presentation has been made available by the WebSphere User Group website. To watch it, just click here.
4/15/2014
The IBM Integration Middleware and the Heartbleed exploit
Wondering if the IBM Integration Middleware is affected by the Heartbleed exploit? Good news for you! In general the answer is no, but there are exceptions...
According to the official IBM Security Bulletins released so far, Cast Iron version 7.x and two MQ Support Pacs are affected. The recommendation for people who work with any of these tools is to keep watching the IBM Support Portal as well as the IBM Product Security Incident Response Team (PSIRT) for more security bulletin updates.
See the official IBM Security Bulletins for each technology:
Besides the need of reissuing certificates that may have been compromised, there should also be an effort to revoke them. Imagine revoking and reissuing new certificates for 66% of the Internet... The Certificate Authorities might be laughing really loud by now with this unforeseen profit about to enter their books...
According to the official IBM Security Bulletins released so far, Cast Iron version 7.x and two MQ Support Pacs are affected. The recommendation for people who work with any of these tools is to keep watching the IBM Support Portal as well as the IBM Product Security Incident Response Team (PSIRT) for more security bulletin updates.
See the official IBM Security Bulletins for each technology:
- IBM WebSphere DataPower
http://www-304.ibm.com/support/docview.wss?uid=swg21669672 - IBM WebSphere MQ
http://www-01.ibm.com/support/docview.wss?uid=swg21669839 - IBM WebSphere Message Broker and IBM Integration Bus
http://www-01.ibm.com/support/docview.wss?uid=swg21670215 - IBM WebSphere Cast Iron
http://www-01.ibm.com/support/docview.wss?uid=swg21669994
Besides the need of reissuing certificates that may have been compromised, there should also be an effort to revoke them. Imagine revoking and reissuing new certificates for 66% of the Internet... The Certificate Authorities might be laughing really loud by now with this unforeseen profit about to enter their books...
4/06/2014
DataPower: How to configure SSL mutual authentication?
That should be a mandatory question when interviewing a
DataPower candidate if you want to give him/her a hard time. I can say that
most of them will fail to answer it correctly based on my experience in the
field.
If DataPower is acting as the server and you want it to
authenticate the client certificate, you can set the direction parameter of the
SSL Proxy Profile to “Reverse”, and then on the Reverse Crypto Profile, you
have to set up a Validation Credential that will contain a copy of the client
certificate (or root CA) to be validated against.
Ah, now it starts to make sense on why the Validation Credential is not a required parameter on the Reverse Crypto Profile, and it is just because mutual authentication is not always required for SSL traffic.
08/25/2015 UPDATE: This is actually the most basic way to configure the Reverse Crypto Profile to authenticate its clients. There are many variations to this configuration and depending on your requirement, you can make your mutual authentication scenario mandatory or optional.
See below some variations of all the possible configurations and an explanation of each scenario:
Scenario 1:
Reverse Crypto Profile WITH ValCreds
Client Authentication is Optional OFF
Always Request Client Authentication OFF
Results:
Client certificate is required because of the ValCreds configured in the Reverse Crypto Profile. Authentication is performed by the ValCreds. If certificate is not provided, the SSL handshake will fail because the option Client Authentication is Optional is set to OFF.
Mutual Authentication is mandatory.
Scenario 2:
Reverse Crypto Profile WITH ValCreds
Client Authentication is Optional OFF
Always Request Client Authentication ON
Results:
Client Certificate is required because of the ValCreds configured in the Reverse Crypto Profile. Authentication is performed by the ValCreds. If certificate is not provided, the SSL handshake will fail because the option Client Authentication is Optional is set to OFF.
Mutual Authentication is mandatory.
Scenario 3:
Reverse Crypto Profile WITH ValCreds
Client Authentication is Optional ON
Always Request Client Authentication OFF
Results:
Client certificate will be asked because of the ValCreds configured in the Reverse Crypto Profile. If provided, authentication will be performed by the ValCreds. If certificate is not provided, the connection will still be established because the option Client Authentication is Optional is set to ON.
Mutual Authentication is optional.
Scenario 4:
Reverse Crypto Profile WITH ValCreds
Client Authentication is Optional ON
Always Request Client Authentication ON
Results:
Client certificate will be asked because of the ValCreds configured in the Reverse Crypto Profile. If provided, authentication will be performed by the ValCreds. If certificate is not provided, the connection will still be established because the option Client Authentication is Optional is set to ON.
Mutual Authentication is optional.
Scenario 5:
Reverse Crypto Profile WITHOUT ValCreds
Client Authentication is Optional OFF
Always Request Client Authentication OFF
Results:
Client certificate is not required because there is no ValCred set in the Reverse Crypto Profile and the option Always Request Client Authentication is set to OFF.
Mutual Authentication is not enabled.
Scenario 6:
Reverse Crypto Profile WITHOUT ValCreds
Client Authentication is Optional OFF
Always Request Client Authentication ON
Results:
Client Certificate is required because the option Always Request Client Authentication is set to ON. Authentication will be performed by the Processing Policy. If certificate is not provided, the SSL handshake will fail because the option Client Authentication is Optional is set to OFF.
Mutual Authentication is mandatory.
Scenario 7:
Reverse Crypto Profile WITHOUT ValCreds
Client Authentication is Optional ON
Always Request Client Authentication OFF
Results:Client certificate is not required because there is no ValCred set in the Reverse Crypto Profile and the option Always Request Client Authentication is set to OFF.
Mutual Authentication is not enabled.
Scenario 8:
Reverse Crypto Profile WITHOUT ValCreds
Client Authentication is Optional ON
Always Request Client Authentication ON
Results:Client certificate will be asked because the option Always Request Client Authentication is set to ON. Authentication will be performed by the Processing Policy. If certificate is not provided, the SSL connection will be established as the option Client Authentication is Optional is set to ON, however the authentication may fail during the Processing Policy.
Mutual Authentication is optional.
Now, when DataPower is acting as Client, it is a different story… For this case, you are going to choose the direction “Forward” on the SSL Proxy Profile and then on the Forward Crypto Profile you will have to set an Identification Credential object to force DataPower to identify itself to the backend it is calling. Simple like that!
At this point, you might also have noticed that in the Forward Crypto Profile, the Identification Credential parameter is not required, once again because mutual authentication is not always required to SSL traffic.
06/23/2015 UPDATE: As of firmware version 7.2, DataPower is deprecating the Proxy Profile object. This object must be replaced by the SSL Server Profile or the SSL Client Profile, depending on whether DataPower is acting as a server or as a client. In addition to these two objects, there is a new object called SSL SNI Server Profile, which enables the SNI (Server Name Indication) feature. In short, the SNI feature on the SSL Client Profile will send the intended host name as part of the SSL handshake process with the server, so that the SNI-enabled server can select which certificate it should return to the client, given that the server is hosting multiple domains in the same IP and port combination.
For more information on the SNI feature, go to https://en.wikipedia.org/wiki/Server_Name_Indication.
For more information on the new SSL Client Profile, go to https://www.youtube.com/watch?v=nMud8cnd56w.
For more information on the new SSL Server Profile and the new SSL SNI Server Profile, go to https://www.youtube.com/watch?v=14DPPjl4u5w.
It is not entirely their fault though. The way that
DataPower presents the objects responsible for configuring mutual
authentication can be tricky if you are trying to learn it by yourself.
The main reason that could lead us, DataPower professionals,
to a confusion is the fact that the SSL Proxy Profile object has a parameter
called “Direction” that can be set as “Forward”, “Reverse” and “two-way”.
Is “two-way” and mutual authentication the same thing?
The first impression is that the “two-way” option could be a
representation of mutual authentication, it is because the definition of mutual
authentication suggests that both
client and server authenticate to each other, or in other words, they perform two-way
authentication.
Although it could make sense, setting the direction to “two-way” has nothing to do with the set up of mutual authentication. SSL mutual authentication is independent of the SSL Proxy Profile direction parameter. You can perfectly have mutual authentication using Forward or Reverse as the direction, there is nothing wrong with that.
The “two-way” direction simply enables DataPower to act as a client or server using a single SSL Proxy Profile. And that is all, no mutual authentication here!
But then how to configure mutual authentication in the box, device, appliance (or whatever you may call it)? The answer is, as usual: it depends…
Although it could make sense, setting the direction to “two-way” has nothing to do with the set up of mutual authentication. SSL mutual authentication is independent of the SSL Proxy Profile direction parameter. You can perfectly have mutual authentication using Forward or Reverse as the direction, there is nothing wrong with that.
The “two-way” direction simply enables DataPower to act as a client or server using a single SSL Proxy Profile. And that is all, no mutual authentication here!
But then how to configure mutual authentication in the box, device, appliance (or whatever you may call it)? The answer is, as usual: it depends…
DataPower acting as Server
Ah, now it starts to make sense on why the Validation Credential is not a required parameter on the Reverse Crypto Profile, and it is just because mutual authentication is not always required for SSL traffic.
08/25/2015 UPDATE: This is actually the most basic way to configure the Reverse Crypto Profile to authenticate its clients. There are many variations to this configuration and depending on your requirement, you can make your mutual authentication scenario mandatory or optional.
See below some variations of all the possible configurations and an explanation of each scenario:
Scenario 1:
Reverse Crypto Profile WITH ValCreds
Client Authentication is Optional OFF
Always Request Client Authentication OFF
Results:
Client certificate is required because of the ValCreds configured in the Reverse Crypto Profile. Authentication is performed by the ValCreds. If certificate is not provided, the SSL handshake will fail because the option Client Authentication is Optional is set to OFF.
Mutual Authentication is mandatory.
Scenario 2:
Reverse Crypto Profile WITH ValCreds
Client Authentication is Optional OFF
Always Request Client Authentication ON
Results:
Client Certificate is required because of the ValCreds configured in the Reverse Crypto Profile. Authentication is performed by the ValCreds. If certificate is not provided, the SSL handshake will fail because the option Client Authentication is Optional is set to OFF.
Mutual Authentication is mandatory.
Scenario 3:
Reverse Crypto Profile WITH ValCreds
Client Authentication is Optional ON
Always Request Client Authentication OFF
Results:
Client certificate will be asked because of the ValCreds configured in the Reverse Crypto Profile. If provided, authentication will be performed by the ValCreds. If certificate is not provided, the connection will still be established because the option Client Authentication is Optional is set to ON.
Mutual Authentication is optional.
Scenario 4:
Reverse Crypto Profile WITH ValCreds
Client Authentication is Optional ON
Always Request Client Authentication ON
Results:
Client certificate will be asked because of the ValCreds configured in the Reverse Crypto Profile. If provided, authentication will be performed by the ValCreds. If certificate is not provided, the connection will still be established because the option Client Authentication is Optional is set to ON.
Mutual Authentication is optional.
Scenario 5:
Reverse Crypto Profile WITHOUT ValCreds
Client Authentication is Optional OFF
Always Request Client Authentication OFF
Results:
Client certificate is not required because there is no ValCred set in the Reverse Crypto Profile and the option Always Request Client Authentication is set to OFF.
Mutual Authentication is not enabled.
Scenario 6:
Reverse Crypto Profile WITHOUT ValCreds
Client Authentication is Optional OFF
Always Request Client Authentication ON
Results:
Client Certificate is required because the option Always Request Client Authentication is set to ON. Authentication will be performed by the Processing Policy. If certificate is not provided, the SSL handshake will fail because the option Client Authentication is Optional is set to OFF.
Mutual Authentication is mandatory.
Scenario 7:
Reverse Crypto Profile WITHOUT ValCreds
Client Authentication is Optional ON
Always Request Client Authentication OFF
Results:Client certificate is not required because there is no ValCred set in the Reverse Crypto Profile and the option Always Request Client Authentication is set to OFF.
Mutual Authentication is not enabled.
Scenario 8:
Reverse Crypto Profile WITHOUT ValCreds
Client Authentication is Optional ON
Always Request Client Authentication ON
Results:Client certificate will be asked because the option Always Request Client Authentication is set to ON. Authentication will be performed by the Processing Policy. If certificate is not provided, the SSL connection will be established as the option Client Authentication is Optional is set to ON, however the authentication may fail during the Processing Policy.
Mutual Authentication is optional.
DataPower acting as Client
Now, when DataPower is acting as Client, it is a different story… For this case, you are going to choose the direction “Forward” on the SSL Proxy Profile and then on the Forward Crypto Profile you will have to set an Identification Credential object to force DataPower to identify itself to the backend it is calling. Simple like that!
At this point, you might also have noticed that in the Forward Crypto Profile, the Identification Credential parameter is not required, once again because mutual authentication is not always required to SSL traffic.
Why then SSL Proxy Profile “two-way”?
So, you could be asking yourself now, why in earth do we
have the option of “two-way” direction in the SSL Proxy Profile, is it just to
confuse us?
Well, there is actually a plausible reason for that… Some of us fight everyday to keep our DataPower configuration as simple as we can, having this “two-way” option allow us to have a single SSL Proxy Profile referring to one Reverse Crypto Profile and one Forward Crypto Profile at the same time. It basically means less objects to be configured, yay!
Once all of them are configured correctly, you will never have to worry about which crypto object to select in order to allow a front or backside connection to be established properly, as the “two-way” object will automatically select the correct Crypto Profile (Forward or Reverse) to use according to the direction of the transaction.
So now, if you had a chance to give a different name for the “two-way” direction of the SSL Proxy Profile, what would that be?
Well, there is actually a plausible reason for that… Some of us fight everyday to keep our DataPower configuration as simple as we can, having this “two-way” option allow us to have a single SSL Proxy Profile referring to one Reverse Crypto Profile and one Forward Crypto Profile at the same time. It basically means less objects to be configured, yay!
Once all of them are configured correctly, you will never have to worry about which crypto object to select in order to allow a front or backside connection to be established properly, as the “two-way” object will automatically select the correct Crypto Profile (Forward or Reverse) to use according to the direction of the transaction.
So now, if you had a chance to give a different name for the “two-way” direction of the SSL Proxy Profile, what would that be?
06/23/2015 UPDATE: As of firmware version 7.2, DataPower is deprecating the Proxy Profile object. This object must be replaced by the SSL Server Profile or the SSL Client Profile, depending on whether DataPower is acting as a server or as a client. In addition to these two objects, there is a new object called SSL SNI Server Profile, which enables the SNI (Server Name Indication) feature. In short, the SNI feature on the SSL Client Profile will send the intended host name as part of the SSL handshake process with the server, so that the SNI-enabled server can select which certificate it should return to the client, given that the server is hosting multiple domains in the same IP and port combination.
For more information on the SNI feature, go to https://en.wikipedia.org/wiki/Server_Name_Indication.
For more information on the new SSL Client Profile, go to https://www.youtube.com/watch?v=nMud8cnd56w.
For more information on the new SSL Server Profile and the new SSL SNI Server Profile, go to https://www.youtube.com/watch?v=14DPPjl4u5w.
DataPower: Testing SNMP using ManageEngine MibBrowser
Not sure if you are already aware of this tool, but it helped me a lot to prove whether DataPower was correctly configured for both SNMP Polling and Trap. The name of this tool is MibBrowser from the company ManageEngine, it is free and can be used to browse the DataPower MIB files, extract any information from the box (SNMP Polling) as well as can be used as a lightweight SNMP server to listen to the SNMP traps sent by the device. See the images below for details:
To download it, just go to http://www.manageengine.com/products/mibbrowser-free-tool/index.html
This company seems to have some other interesting free networking tools, see the link below for the full list:
http://www.manageengine.com/free-software-download.html?plink=mibB
By the way, talking about other free tools, I have been using other two that have helped me in some matters, one of them is for keys/certificates management and the other is for LDAP browsing:
Portecle - Extracts and converts keys and certificates - http://portecle.sourceforge.net/
ADExplorer - Connects to a LDAP server so you can verify every single LDAP object - http://technet.microsoft.com/en-us/sysinternals/bb963907.aspx
Do you guys use any other tools to help somehow performing your day to day work?
1. SNMP Polling
2. SNMP Traps
To download it, just go to http://www.manageengine.com/products/mibbrowser-free-tool/index.html
This company seems to have some other interesting free networking tools, see the link below for the full list:
http://www.manageengine.com/free-software-download.html?plink=mibB
By the way, talking about other free tools, I have been using other two that have helped me in some matters, one of them is for keys/certificates management and the other is for LDAP browsing:
Portecle - Extracts and converts keys and certificates - http://portecle.sourceforge.net/
ADExplorer - Connects to a LDAP server so you can verify every single LDAP object - http://technet.microsoft.com/en-us/sysinternals/bb963907.aspx
Do you guys use any other tools to help somehow performing your day to day work?
DataPower: Static routes and management interface
(Read the whole article before making any changes to your environment)
I wanted to share with you some of my experience when configuring the DataPower appliances from scratch.
As you know, during the DataPower initialization process, there is a wizard available that will make the initial configuration a lot easier. That wizard asks you a few questions about your network and then directs you to the WebGUI, so you can accept the license terms. Most of the times, since the WebGUI is already up and running, people will never come back to the configuration of the management interface to adjust it as they should, in order to avoid unexpected behaviors in the future. But what adjustment am I talking about here?
The static route of course! Right, you do not need to configure it in order to make the WebGUI or any other management service, such as SSH and SOMA, to work fine, however you do need to adjust it in order to prevent DataPower from using such interface for application data traffic.
I wanted to share with you some of my experience when configuring the DataPower appliances from scratch.
As you know, during the DataPower initialization process, there is a wizard available that will make the initial configuration a lot easier. That wizard asks you a few questions about your network and then directs you to the WebGUI, so you can accept the license terms. Most of the times, since the WebGUI is already up and running, people will never come back to the configuration of the management interface to adjust it as they should, in order to avoid unexpected behaviors in the future. But what adjustment am I talking about here?
The static route of course! Right, you do not need to configure it in order to make the WebGUI or any other management service, such as SSH and SOMA, to work fine, however you do need to adjust it in order to prevent DataPower from using such interface for application data traffic.
The trick here is the following, whenever you see a default route configured for the management interface, you may be under the risk of DataPower not behaving the way you are expecting it to. For example in this case:
xg45# show route
Destination Device Int Type Device Int Gateway Metric Route Type Route Protocol
----------- --------------- ---------- ------- ------ ---------- --------------
0.0.0.0/0 Ethernet mgt0 10.206.137.1 0 remote netmgmt
0.0.0.0/0 Ethernet eth11 10.206.137.1 0 remote netmgmt
10.206.137.0/24 Ethernet mgt0 0.0.0.0 0 local local
10.206.137.0/24 Ethernet eth11 0.0.0.0 0 local local
----------- --------------- ---------- ------- ------ ---------- --------------
0.0.0.0/0 Ethernet mgt0 10.206.137.1 0 remote netmgmt
0.0.0.0/0 Ethernet eth11 10.206.137.1 0 remote netmgmt
10.206.137.0/24 Ethernet mgt0 0.0.0.0 0 local local
10.206.137.0/24 Ethernet eth11 0.0.0.0 0 local local
The destination 0.0.0.0/0 is the default route. As you can see, there are two default routes in the example above, one being used by the mgt0 interface and the other being used by the eth11. The default route is added to the routing table every time that there is a default gateway defined in the interface. So as soon as you remove the default gateway, the default route will disappear from the route table:
xg45# show route
Destination Device Int Type Device Int Gateway Metric Route Type Route Protocol
----------- --------------- ---------- ------- ------ ---------- --------------
Destination Device Int Type Device Int Gateway Metric Route Type Route Protocol
----------- --------------- ---------- ------- ------ ---------- --------------
0.0.0.0/0 Ethernet eth11 10.206.137.1 0 remote netmgmt
10.206.137.0/24 Ethernet mgt0 0.0.0.0 0 local local
10.206.137.0/24 Ethernet eth11 0.0.0.0 0 local local
10.206.137.0/24 Ethernet mgt0 0.0.0.0 0 local local
10.206.137.0/24 Ethernet eth11 0.0.0.0 0 local local
By removing that, you are explicitly telling DataPower to never use the management interface for any outbound traffic. It also means that, as soon as you remove the default gateway, you *may* lose access to the box, as it will not know how to reply back to you [if you are not on the same subnet of the device (/24) or the management service is not configured for all network interfaces (0.0.0.0)]. Technically you are not really losing access, your requests are reaching the box, but the box does not know how to get back to you.
So, how to fix that? By adding a static route is the answer. Before removing the default gateway details from the management interface configuration, make sure to configure a static route that will teach the box how to reach you back.
If your terminal is configured with static IP address and you want to restrict the DataPower management interface to talk only to you, the following command should do the trick:
xg45(config-if[mgt0])# ip route 10.206.14.160/32 10.206.137.1
<ip route> invokes the command to create the static route
<10.206.14.160/32> is the final destination of the responses, or the IP address of your terminal
<10.206.137.1> is the network gateway to be used to reach the final destination
And the final result:
xg45(config-if[mgt0])# show route
Destination Device Int Type Device Int Gateway Metric Route Type Route Protocol
----------- --------------- ---------- ------- ------ ---------- --------------
Destination Device Int Type Device Int Gateway Metric Route Type Route Protocol
----------- --------------- ---------- ------- ------ ---------- --------------
0.0.0.0/0 Ethernet eth11 10.206.137.1 0 remote netmgmt
10.206.14.160/32 Ethernet mgt0 10.206.137.1 0 remote netmgmt
10.206.137.0/24 Ethernet mgt0 0.0.0.0 0 local local
10.206.137.0/24 Ethernet eth11 0.0.0.0 0 local local
10.206.14.160/32 Ethernet mgt0 10.206.137.1 0 remote netmgmt
10.206.137.0/24 Ethernet mgt0 0.0.0.0 0 local local
10.206.137.0/24 Ethernet eth11 0.0.0.0 0 local local
As you can see above, the configuration of the final destination uses the CIDR notation. The /32 means that such static route will only work for such specific IP address (subnet mask 255.255.255.255). If you want to configure a static route to reach an specific subnet, you can use different CIDRs to accomplish it. For example, you know that a specific subnet is safe and want to allow all terminals on that subnet to manage the box, you could use 10.206.14.0/24 (subnet mask 255.255.255.0).
Now going back to the unexpected behaviors we mentioned earlier, when there is more than one default route, there is no default route, makes sense? :-) With that said, if no static route is configured, DataPower will randomly select any ethernet interface that has a default route set up and you will start seeing application data traffic coming out of the management interface, and management traffic coming out of the application data interface at random basis. Sometimes you are going to experience intermittent connectivity issues, as the gateway configured for the management interface may not know how to route the request to the application backend and vice-versa.
In addition to what has been discussed so far, static routes can do much more! For example, you may want to use one of the various ethernet interfaces available in the appliance to segment traffic to different networks, but this a topic for another post. :-)
Reference: IBM WebSphere DataPower SOA Appliance Handbook - http://www.amazon.com/IBM-WebSphere-DataPower-Appliance-Handbook/dp/0137148194
Subscribe to:
Posts (Atom)