Showing posts with label Security. Show all posts
Showing posts with label Security. Show all posts

2/13/2015

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 159.226.43.96 to X.X.X.X port 80
20150213T043515Z [network][error] : tid(2): TCP connection attempt refused from 159.226.43.96 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 78.101.49.77 to X.X.X.X port 80
20150213T073443Z [network][error] : tid(2): TCP connection attempt refused from 78.101.49.77 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 199.217.118.79 to X.X.X.X port 10000
20150213T120350Z [network][error] : tid(2): TCP connection attempt refused from 112.221.251.221 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 (159.226.43.96), then we have one from Qatar (78.101.49.77), one from United States (199.217.118.79), and one from Korea (112.221.251.221). 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!

5/08/2014

DataPower: 5 secrets that you may not have known

Okay, let's go straight to the point, starting with a few questions:
  1. Is it possible to disable a Multi-Protocol Gateway or a Web Service Proxy?
  2. Is it possible to export a certificate from the cert: directory?
  3. Is it possible to increase the number of transactions in the probe history?
  4. Can a Front Side Handler object be created automatically when creating a Web Service Proxy?
  5. Can a service have higher priority over others?

You might have answered yes to at least one of these questions, but would you be surprised if I told you that the answer for every single one is yes?

Follow the link below to see more details about each of the secrets above.

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...

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.

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…

DataPower acting as Server


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.


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?

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.