DataPower: How to duplicate, rename, and bulk delete objects?


Did you know that all the objects that exist in a domain are there just because of a single configuration file? Did you know that you can wipe out all the objects by simply deleting the content of this file? Did you know that you can manipulate all the objects using your favorite text editor?

If you answered yes to any of the above questions, you are done and don't need to spend any more time at this article. If not, take a seat, relax, and enjoy these tips as you become a DataPower cheater.

Understanding the case

While booting, DataPower will look for all the .cfg files spread over all the domains. These .cfg files contain instructions on what objects and configuration should be loaded to the memory for execution time. Actually, the only reason why you have the objects in place when you restart your domain or recycle the entire box is because of these .cfg files that are storing details of almost everything for you.

Take a moment to analyze any .cfg file you may have in the default or any other existing domain. Usually they are named after the domain name, so if you have a domain called Sandbox, you will have one config:///Sandbox.cfg file. The .cfg file of the default domain falls into an exception and will be called autoconfig.cfg.

Take a moment there, start reading some lines, you will soon realize that all the objects you have created using any DataPower interface will be there. Created a new Crypto Profile? It will be there. Created a new Deployment Policy? It will also be there. Defined a password for a local user? Nah, that will not be there, and honestly, I don't know where this information is stored. :-)


I particularly use this a lot. Duplicating, triplicating and sometimes quadruplicating Deployment Policies used to kill me back in the day. That was because I used to do all that using the WebGUI. If you have already done that you know what I am talking about. Imagine a scenario which you need to create one Deployment Policy for each environment, let's say one for UNIT, one for INTG, one for PERF, and one (or more) for PROD. I would imagine you would keep the one for UNIT that you supposedly created first open in one browser tab and visually refer to it when creating the others. That means a lot of eyes work from left to right and MANY clicks to add the Modified Configurations. So after dying a few times, I decided to investigate a less time consuming way to do this, and that was when I had this idea to do this through the .cfg file.

My UNIT deployment policy was the following:

deployment-policy "Service-UNIT-DeploymentPolicy"
 modify "*/*/wsm/wsm-endpointrewrite?Name=.*&Property=WSEndpointRemoteRewriteRule/RemoteEndpointHostname&Value=.*" "change" "" "unit-server.datapower.com"
 modify "*/*/wsm/wsm-endpointrewrite?Name=.*&Property=WSEndpointRemoteRewriteRule/RemoteEndpointPort&Value=.*" "change" "" "80"
 modify "*/*/services/multiprotocol-gateway?Property=DebugMode" "change" "" "off"
 modify "*/*/services/ws-proxy?Property=DebugMode" "change" "" "off"

So to duplicate something similar for my INTG environment, I just copied it and pasted it on the line below, changing the parameters pertaining to the new environment, such as name, hostname, port, etc:

deployment-policy "Service-UNIT-DeploymentPolicy"
 modify "*/*/wsm/wsm-endpointrewrite?Name=.*&Property=WSEndpointRemoteRewriteRule/RemoteEndpointHostname&Value=.*" "change" "" "unit-server.datapower.com"
 modify "*/*/wsm/wsm-endpointrewrite?Name=.*&Property=WSEndpointRemoteRewriteRule/RemoteEndpointPort&Value=.*" "change" "" "80"
 modify "*/*/services/multiprotocol-gateway?Property=DebugMode" "change" "" "off"
 modify "*/*/services/ws-proxy?Property=DebugMode" "change" "" "off"

deployment-policy "Service-INTG-DeploymentPolicy"
 modify "*/*/wsm/wsm-endpointrewrite?Name=.*&Property=WSEndpointRemoteRewriteRule/RemoteEndpointHostname&Value=.*" "change" "" "intg-server.datapower.com"
 modify "*/*/wsm/wsm-endpointrewrite?Name=.*&Property=WSEndpointRemoteRewriteRule/RemoteEndpointPort&Value=.*" "change" "" "80"
 modify "*/*/services/multiprotocol-gateway?Property=DebugMode" "change" "" "off"
 modify "*/*/services/ws-proxy?Property=DebugMode" "change" "" "off"

Once done, it was just a matter of restarting the domain and the Deployment Policies were replicated.

Other related tips...

Use it to find out the right CLI command to perform a specific action

Don't remember exactly the CLI command to create a crypto object? Just go to the .cfg file and try to find a reference for it, when you find it, that is the command you are looking for. That is because the .cfg is nothing more, nothing less than CLI commands grouped in a single place.

Use it to delete a massive amount of objects

For example, you created a bunch of Web Service Proxies or Multi Protocol Gateway. By default, when you create these objects you are rewarded with a lot of child objects that will not go away even after you remove their parents, such as matches, processing actions, slm policies, etc. Good news is that they are named after their parents, so you can sort them out easily and quickly select them for removal.

Changing object names

In general, you cannot change object names in DataPower. Gave it the wrong name? Delete it and recreate it. As an alternative to this, go to the .cfg file and rename it there. Once done, restart the domain and voilà!


  • Be careful. Make sure you know what you are doing before playing with this file. Rule of thumb, always have a backup of it in case something goes wrong.
  • Some words are reserved, and the default interfaces won't be there to tell you that, so be careful. Rule of thumb, avoid naming objects that can be confused with an existing command, for example when naming an Alias object, use "xmlAlias" instead of only "xml", as it may be parsed incorrectly by the interpreter when loading the objects to the memory.
  • And last but not least, BE CAREFUL, not sure if I have already said that.


The possibilities are endless, you can optimize a lot of your time after mastering on this. Duplicating, bulk deletion, searching for commands, are just the obvious things you can do while playing with the .cfg files. The limit here is your imagination, so if you think of something cool that the knowledge present in this article enabled you to do, don't hesitate to share it with us in the comments section below. Happy .cfg'ing!


DataPower: Keeping your appliances less prone to attacks

Chances are if you have your DataPower appliances facing the Internet, you have suffered or are suffering right now brute force attacks. Don't you think so? Check your logs...

This problem becomes more evident when you have default ports open to the Internet, let's say ports 22, 80, 443, 5550, 9090, etc...

This happens because there are thousands of robots out there scanning for all IPs and ports open all around the world. They use something called brute force technique.

Brute force is a type of attack that tries to get access to servers by repeating different combinations of credentials. It may also make use of a dictionary with the most commonly used passwords out there, like 123456, password, qwerty, abc123, etc.

Let's take a look at this real case scenario:

20150213T043514Z [network][error] : tid(2): TCP connection attempt refused from to X.X.X.X port 80
20150213T043515Z [network][error] : tid(2): TCP connection attempt refused from to X.X.X.X port 80
20150213T063841Z [auth][error] : User '/etc/init.d/iptables stop' failed to log in.
20150213T063841Z [auth][error] : User 'service iptables stop' failed to log in.
20150213T063841Z [auth][error] : User '/tmp/init.d/iptables stop' failed to log in.
20150213T072620Z [auth][error] : User 'service iptables stop' failed to log in.
20150213T072628Z [auth][error] : User 'chmod 777 148080' failed to log in.
20150213T072636Z [auth][error] : User 'cd /tmp' failed to log in.
20150213T073442Z [network][error] : tid(2): TCP connection attempt refused from to X.X.X.X port 80
20150213T073443Z [network][error] : tid(2): TCP connection attempt refused from to X.X.X.X port 80
20150213T084505Z [auth][error] : User 'service iptables stop' failed to log in.
20150213T084513Z [auth][error] : User 'chmod 777 148080' failed to log in.
20150213T084521Z [auth][error] : User 'cd /tmp' failed to log in.
20150213T120039Z [network][error] : tid(2): TCP connection attempt refused from to X.X.X.X port 10000
20150213T120350Z [network][error] : tid(2): TCP connection attempt refused from to X.X.X.X port 80
20150213T124135Z [auth][error] : User '/etc/init.d/iptables stop' failed to log in.
20150213T124135Z [auth][error] : User 'service iptables stop' failed to log in.
20150213T124135Z [auth][error] : User '/tmp/init.d/iptables stop' failed to log in.

Someone trying to login with the user id "service iptables stop" or "chmod 777 148080", looks suspicious, right? LOL

By observing this behavior for a few months now, I noticed that most IPs are from China. On the connection attempts I received today however, just one is from China (, then we have one from Qatar (, one from United States (, and one from Korea ( Before you are start blaming these countries, keep in mind that it is really simple to fake an IP like that in order to hide the real source of the attacks.

What I want to say here is that blocking IPs with ACLs will barely provide a solution, even if you block huge ranges of IPs of a given country. It may work for the short term, but will fail on the long term as other IPs will rise. Trust me, I tried! :-)

The truth is you are never 100% safe, what you can do is to try to understand how these robots work and come up with a strategy to deceive or avoid them. Some robots are more intelligent than others, so they will spend some time performing a full port scan in a certain IP in order to determine what the open ports are, and then direct an specific attack for specific services. For example, if port 22 is open, it will start with user id and password, and only after it succeeds it will try actual OS commands. If port 80 is open, it will probably try to exploit some recently discovered vulnerabilities pertaining to Web Servers.

Your best bet to avoid this kind of attack is to just eliminate the default ports from your configuration, as well as limiting the number of ports open to the Internet, for example, there is hardly the need to leave the administration related services, such as SSH, SOMA, and WebGUI, open to the Internet, when most of the companies have VPN services that would allow administrators to access those interfaces from a more secured environment.

EDIT: Dan Zrobok also wrote a very interesting article about security titled Five Common Security Issues Found in DataPower Environments. We highly recommend this reading as he mentions other very important topics on Firmware Currency, Administrative Accounts, TLS Cipher Suites and Protocol Versions, and Exception Information Leaks (when you give more information in the error message than needed).

By having all this information in mind, you are not only keeping your device safer, but you are also implementing best practices that are used in the most secure enterprises around the globe.

Have other ideas to prevent attacks, share with us!