WildFly 8-10 and JBoss EAP 7 verbose HTTP headers

As a developer I am really happy to have an easy way to determine which version of a software I’m running. But I do not like it if my software tells everyone its name and version, as this gives important fingerprinting information to possible attackers.

If you use WildFly versions 8 through 10 or JBoss EAP version 7 the default configuration includes some HTTP headers that are too verbose in my opinion. JBoss EAP 6 is not affected by the way. The headers you get look like this

Server: JBoss-EAP/7
X-Powered-By: Undertow/1

Getting rid of these headers is really easy. So I think the tiny effort to remove these headers should be put into any project even if the probability of getting attacked and the possible impact are really small.

To fix the problem let’s have a look at the default configuration in the standalone.xml:

Continue reading

commons-fileupload 1.3.3 resolves deserialisation vulnerability CVE-2016-1000031

CVE-2016-1000031 is a vulnerabilty in the extremely widely used Apache Commons library commons-fileupload – you might not even know you’re having it on your class path. It has a very nasty Remote Code Execution vulnerability with easy to use exploits publicly available up to version 1.3.2. What makes it even worse is that you do not even need to use the library – you only need to have it on your class path and to deserialise some data. The data is the attack vector. You can find a good in detail explanation of the vulnerability here.

It did take a while but with version 1.3.3 this vulnerability is finally closed (by default).

There is some stuff that you should know about the fix though:

Continue reading

ActiveMQ Confusion and What comes with your JBoss EAP / WildFly

Oftentimes people talk to each other about using ActiveMQ, but they’re actually referring to different brokers. That is because there are 3 different message brokers with ‘ActiveMQ’ in their name and this turns out to be pretty confusing when a project as big as WildFly starts to use a broker with ‘ActiveMQ’ in its name that is not the broker that was known for years under the name ‘ActiveMQ’.

So there are 3 projects:

Continue reading

Fight the POODLE in JBoss 4 and 5, JON 3 and more

The POODLE bug (CVE-2014-3566) affects nearly everything and everybody is trying to secure all of their systems. That includes your JBoss servers. Securing your JBoss 4 or 5 has one pitfall, which I am going to explain in this post. Apart from that it’s easy.

I stumbled on this issue when securing the web interface of a customer’s JON server. (Important note: the following snippet will not work around POODLE for communication from JON server to JON agent!) JON is by default configured to use TLS, so there is a poodle protection installed by default.

Yeahh, well… let’s verify that:

echo "" | openssl s_client -ssl3 -connect  your.server.dns.or.ip:7443

Surprise, surprise: Even with TLS configured the SSL-Session using SSLv3 was established successfuly!

SSL-Session:
    Protocol  : SSLv3
    Cipher    : DHE-RSA-AES256-SHA
    Session-ID: XXX
    Session-ID-ctx:
    Master-Key: XXX
    Key-Arg   : None
    Krb5 Principal: None
    Start Time: 1413471616
    Timeout   : 7200 (sec)
    Verify return code: 21 (unable to verify the first certificate)

The cause for that is that the tomcat configuration doesn’t work as I would expect it. The following configuration does NOT do the trick (server.xml of the deployed tomcat):

<!-- Does NOT work! -->
<Connector port="7443"
    address="0.0.0.0"
    protocol="HTTP/1.1"
    scheme="https"
    ...
    secure="true"
    SSLEnabled="true"
    sslProtocol="TLS"
    ... >
<!-- Does NOT work! -->

The RedHat guys actually posted the solution but it’s easy to mistake the important point. The following configuration bans your evil poodle:

<Connector port="7443"
    address="0.0.0.0"
    protocol="HTTP/1.1"
    scheme="https"
    ...
    secure="true"
    SSLEnabled="true"
    sslProtocols="TLSv1,TLSv1.1,TLSv1.2"
    ... >

Ok there is one obvious (and also important!) difference and one subtle difference. The obvious one is that it is "TLSv1,TLSv1.1,TLSv1.2" and not "TLS". By the way TLSv1.2 is only available from JDK 1.7 on.

But there is also the subtle difference of a single “s” which is very important, because without it it does NOT work. To make it clear, it will only work with "sslProtocols" and will NOT work with "sslProtocol".

That is confusing for me because I have never seen that option documented but the documented option seems to have no effect at all. So I suspect there is a typo in either the code or the documentation.

Hope I could help you somehow! If you’ve got any questions feel free to comment on this post. Good luck on your poodle fighting!

JGroups & Cloud issues when clustering the EAP 6 – AS 7

As announced this is the last post of our series about clustering of the Redhat EAP 6 and JBoss AS 7. The other posts of this series were

Overview

This post will dig deeper into the clustering mechanisms of the EAP 6 and JBoss AS 7. We will show different solutions to multicast problems you will get in most cloud networks as well as some other networks. Infinispan uses JGroups to do its cluster communication. Cluster communication here means multiple things: finding other cluster nodes, providing a reliable transfer, implementing multicast communication even if there is no IP multicast available, identifying dead cluster nodes and a little bit more. In fact JGroups is able to do a lot more but Infinispan does not need all of the opportunities JGroups offers. The upcoming HornetQ version 2.3 which will be included in the EAP 6.1 will use JGroups for server discovery too. This post will explain the basic principles of JGroups and how to configure it in different network setups, especially most cloud networks.

Continue reading

Clustering of the messaging subsystem HornetQ in JBoss AS7 and EAP 6

In the recent posts of this series we talked about many different aspects of clustering for the JBoss AS 7 and its quality assured version EAP 6, such as:

Until now, there is one important thing we have not covered yet: clustering of the messaging subsystem. The EAP 6 as well as the AS 7 uses HornetQ as default messaging provider. In this post we want to give an overview about the clustering abilities of HornetQ and explain how to use the various clustering features in combination with the EAP 6 or respectively the JBoss AS 7. We implemented a simple JMS client application to demonstrate the HornetQ clustering abilities.

Continue reading

Scalable HA Clustering with JBoss AS 7 / EAP 6

Overview

In a recent blog-post Clustering in JBoss AS7/EAP 6 we showed how basic clustering in the new EAP 6 and JBoss AS 7 can be used. The EAP 6 is basically an AS 7 with official RedHat-support. Our cluster we described in that post was small and simple. This post will cover much more complex cluster structures, how to build them and how we can utilize the new domain-mode for our clusters. There are multiple ways to build and manage bigger JBoss cluster environments. We will describe two ways to do so: One using separating techniques also applicable to older JBoss versions and the other way using an Infinispan feature called distribution.

Scalability vs. Availability

The main challenge when building a cluster is to make it both highly available and scalable.

Availability for a cluster means: If one node fails, all the sessions on that node will be seamlessly served by another node. This can be achieved through session-replication. Session-replication is preconfigured and enabled in the ha profile in the domain.xml. Flat replication means that all sessions are copied to all other nodes: If you have got four nodes with 1GB memory for each of them, your cluster can only use 1GB of memory because basically all nodes store copies from each other. I. e. your cluster will not have 4*1GB=4GB memory. If you would add more nodes to this cluster you would not get more memory, you will even lose some memory due to overhead for replication. But you will get more availability and more important more network traffic due to replication overhead (all changes need to be redistributed to all other nodes). Let us call this cluster topology full-replication.
Continue reading