How to Secure GlassFish installation, Part II

In order to secure the application server you need to secure its communication ways with outside world, It means you will need to secure all ports and listeners.

There are 3 kind of listeners in Glassfish application server that you will need to take care of them

First of all make sure that you secured the administration listener, make sure that you have enabled Security for administrator listener and set an specific IP address for it to listen on. Usually we are not going to use administration console from outside of the internal network, so let it listen only on interfaces that you need it to listen perhaps the interface that connect the server to your LAN. In order to do this, open administration console and navigate to:

 Configuration> HTTP Service> HTTP Listeners> admin-listener 

Change the Network Address as appropriated, check the Security check box, and in the SSL Tab enable Client Authentication, in order to find out how you should use Client Certificate, take a look at my previous posts about SSL and securing GlassFish Application Server. You have two other Http listeners to take care of, so make sure that you change their Network Address and enable the Security facilities if required

There is another listener which you need to take care of, It is your IIOP listener. IIOP listener let you create a context to lookup into your JNDI, etc. In order to configure the IIOP listeners you should navigate to:

 Configuration> ORB> IIOP Listeners 

Here you can see that there are 3 different listeners already created and configure for different purposes. You should not allow the first non-secure listener (orb-listener-1) to listen over a public network as there is no authentication or transfer layer security for this listener, but the second one (SSL) have transport layer security and the third one (SSL_MUTUALAUTH) has mutual authentication which guarantee that listener will only process request come after a client cert authentication. make sure that you configure the listeners to listen on correct Network address and remove or disable the listeners those that you do not need. You can disable a listener by looking at listener details page which provides a check box for it.

Another listener which you need to take care of is your JMX connector listener, You can view and edit its configuration by navigating to:

 Configuration> Admin Service> system 

Here you are able to change the realm that this listener use to authenticate the users that are trying to connect to JMX listener, you can change the realm to an specific realm which you have made only for JMX users or let it use you administration realm. You can change the Network Address that this listener is using along with enabling the SSL and Client Cert Authentication in order to secure the data transfer and guarantee that only users with correct digital certification can use your JMX connector to control the application server

PS: All of the listeners that you can configure in your administration console allows you to have Mutual Authentication (Client Cert Authentication) which ensure that both parties have verify-able certifications. This certifications can come from well known providers like VeriSign or your own CA. on the other hand all listeners allows you to specify an specific alias for them, which means that each listener mutual authentication can be configured completely independent from other listeners, for example you can have two alias one for administration console and one for JMX connector in order to prevent JMX users to connect to administration console.

For more information you can take a look at my older posts related to this matter:

 

How to Secure GlassFish installation.

It is some days that I saw some posts about securing Glassfish in production environment, so I thought I write some of my experience here to let other secure the glassfish easier. There are some basic items that you will need to relay on in order to have a secure Glassfish installation.

 

  1. secure access to administration console, both web based and CLI.
  2. secure all ports and listeners that application server uses to interact with outside applications.
  3. secure your environment from GlassFish; Yes, glassfish can be evil if you have buggy software installed on you application server.
  4. secure your application server from the environment that it is operating on it.
  5. secure glassfish directories in order to prevent any accidental changes, use, etc in glassfish configuration files.
  6. Take care of all logging if you are not going to secure Glassfish on the file system.
  7. tips and tricks which are not mentioned in the above sections.
  8. firewalls, network security, clustered environment tips and tricks

 

But how you can do these, I will explain each item in as much details as I can begin with securing your administration console. As you know administration console is the main interaction point with an application server, however must of application servers let you perform all changes from a CLI or direct editing of server.xml, domain.xml and so on. But Web based administration console is the most open to access part of application server, So let’s see how we can secure it:

You will need to change administration password from the default one, do it by using the following command in CLI when your application server is running.

 change-admin-password 

 

Using this command you can change your administration password both for CLI and Web based console. The output of the command may differ from version or profile to another version and profile but it will asks you to enter old and new password, in case that it asks to accept a certificate accept it, you will change it later.

Second thing that you should change is master-password, make sure that you stop your application server before issuing the command as it will not work when the as is running. Following command in asadmin console will do it for you. Default master password value is “changeit”

 change-master-password 

 

Now you are sure that your administration console and keystore files are protected using a new password which you know.

Its time to take a closer look at application server web based console protection, you need to make sure that you have most possible protection over your administration console by limiting access to it using firewalls and after that you can add another level of protection and transmission integrity by using a mutual authentication using Digital Certificate.

By changing the administration http listener to use an a digital certificate specific for administration console and changing its setting to use client-cert authentication or mutual authentication you can ensure that your administration console will only opens in a browser which has a digital certificate signed by a CA known to your administration listener.

This way you can be sure that only the guys with that specific digital certificate will have access to your admin console and the administrator will not fool by anyone to connect to a mock server. On the other hand you have full protection of SSL over your transmitted data. To learn how you can setup your own CA and add keys to glassfish keystore take a look at some older entry of my weblog. however those entry shows how you can use digital certificate when your AS uses jks files ant certDB files.