8 Replies Latest reply on Mar 19, 2012 11:21 PM by Udo

    hide glassfish server details

      accessing http://myapexhost.mydomain:myport/notexistant.html will easily yield glassfish server and version information, like

      HTTP Status 404 -

      type Status report


      descriptionThe requested resource () is not available.
      GlassFish Server Open Source Edition 3.1.1

      How could we hide this information, to enhance security a little bit?

      Regards, Tom
        • 1. Re: hide glassfish server details
          This is a glassfish question, not necessarily anything to do with the apex listener.
          You would be best asking in the glassfish forums, but what you can can be done easily:

          Edited by: mwrf on 14-Mar-2012 08:29
          1 person found this helpful
          • 2. Re: hide glassfish server details
            Thanks, that was helpful.

            What remains a question, and what is related to APEX listener is the "special" addresses like listeneradmin:


            When a user fails to authenticate, he will get a message like

            HTTP Status 401 -

            type Status report


            descriptionThis request requires HTTP authentication ().
            GlassFish Server Open Source Edition 3.1.1

            ... which reveals the application server software and version again.

            I tried the following in domain.xml:

            <property description="custom 401" name="send-error_02" value="code=401 path=${com.sun.aas.instanceRoot}/docroot/401.html reason=Unauthorized"></property>

            But this will lead to any request to listenerAdmin being turned down with displaying 401.html

            Can both be avoided?

            Regards, Tom
            • 3. Re: hide glassfish server details
              But this will lead to any request to listenerAdmin being turned down with displaying 401.html
              Which is not very surprising: GlassFish will override any additional headers in that case. "401" is a normal state if you start your authentication process if your browser doesn't send the all needed authentication information with the first request (which usually is not the case). If you catch it right away, you won't be able to use the negotiation dialogue presented by the browser.

              You could do add custom error pages at application level, as indicated as option by the blog post mwrf referenced. This will only be effective if the application itself stopped answering as expected, which will only be the case when it stops trying to negotiate (e.g. you've reached the maximum number of retries or your browser doesn't send authentication information anymore and hence stops the negotiation).

              If you want a working example for APEX Listener, read on:
              1. Add the directory error_pages to your deployment and put a file named +401.html+ in there, e.g.
              <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
              <html xmlns="http://www.w3.org/1999/xhtml">
                <title>APEX Listener</title>
                <h1>HTTP Status 401 - Unauthorized</h1>
                <p>The URL you requested requires HTTP authentication.</p>
              2. Add the following to the web.xml within the main tag ( +</web-app>+ )
              3. Reload the application.
              You can do the same with other error pages as well. If you want to make sure the changes persist a redeployment, you could also patch the apex.war , e.g.
              # create base directory for the patch
              mkdir /var/tmp/apex_listener_patch
              # create temporary directory for working in the contents of the war
              mkdir /var/tmp/apex_listener_patch/tmp
              # copy the war file to the base directory
              cp apex.war /var/tmp/apex_listener_patch
              # change into the temp directory
              cd /var/tmp/apex_listener_patch/tmp
              # unpack the war file into the temp directory
              jar -xf ../apex.war
              # remove the old war file
              rm ../apex.war
              # add the directory
              mkdir error_pages
              # create the error page with content from step 1 and save
              vi error_pages/401.html
              # add the section from step 2 above and save 
              vi WEB-INF/web.xml
              # create new war file with modifications
              jar -cf ../apex.war .
              This example assumes you have Unix/Linux environment. It'll also work with the corresponding commands and adapted paths for Windows machines.
              If you like (and didn't do so before), you could also edit the web.xml in WEB-INF before repacking the archive, so you'll have your config.dir already configured before your first deployment.

              • 4. Re: hide glassfish server details
                Udo, thanks.

                I now understand that 401 codes need to be handled at application level (web.xml). I would still think that handling 404 makes sense at server level (domain.xml).

                Do you have recommendations about other http codes like 400 (Bad Request), 405 (Method Not Allowed) 503 (Service Unavailable) and all the others: which should be cared about to reach the abovementioned aim of hiding the glassfish server details, and at which level (application or server)?

                Thanks in advance,

                • 5. Re: hide glassfish server details
                  Hello Tom,

                  I think each error (Code 4xx for Client Errors and Code 5xx for Server Errors) would qualify for your requirement, because whenever any of them occures, the user would see the information you don't want to give away. A full list with a specification of the error codes is part of the [url http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4]RFC 2616 - HTTP/1.1. [url http://en.wikipedia.org/wiki/List_of_HTTP_status_codes]Wikipedia lists some additonal status codes that are not part of the HTTP specification. Of course not all of the errors specified are very likely to happen, but I guess it doesn't hurt to take the five minutes it'll cost to catch those as well. Despite the authentication none of them would have impact on other APEX Listener features, so they could be catched globally.
                  If you want to keep it short, I'd definetly recommend to implement a catch for 500 (Internal Server Error) in addition to the ones you've named, because this usually includes a Stack Trace and you don't want end users to see that.
                  As for all other errors: Hiding the server details isn't done with just using a custom error page. GlassFish will also send response headers like Server and X-Powered-By. See the following example from a 3.1.2 running on my Laptop:
                  Server     GlassFish Server Open Source Edition 3.1.2
                  X-Powered-By     Servlet/3.0 JSP/2.2 (GlassFish Server Open Source Edition 3.1.2 Java/Sun Microsystems Inc./1.6)
                  I think anybody willing to hack your server would be able to access those headers. To diable them, you'll have to
                  1. Add a JVM option
                  2a. edit the default-web.xml, search for the following block
                  and set the param-value to false
                  2b. disable XPowered By in the HTTP tab for your http-listener-x in the Network Config.

                  I hope this answeres your question. If so, please mark this thread as answered and any helpful or correct answer accordingly.



                  P.S.: I'm not a GlassFish expert, but I guess there are a lot more things to be done to harden your GlassFish. I recommend using your favorite search engine or a GlassFish forum for further research.
                  • 6. Re: hide glassfish server details

                    thanks a lot.

                    I think that in the end the question was still relevant here, as it addressed the necessity of to handling 401 at APEX listener level.

                    Have a nice day, Tom
                    • 7. Re: hide glassfish server details

                      I found that setting xpoweredBy to false in default-web.xml had no effect.

                      What helped me was the following procedures I took from http://www.nabisoft.com/tutorials/glassfish/installing-glassfish-301-on-ubuntu:

                      asadmin> create-jvm-options -Dproduct.name=""
                      asadmin> set server.network-config.protocols.protocol.http-listener-1.http.xpowered-by=false
                      asadmin> set server.network-config.protocols.protocol.http-listener-1.http.xpowered-by=false
                      asadmin> set server.network-config.protocols.protocol.http-listener-2.http.xpowered-by=false
                      asadmin> set server.network-config.protocols.protocol.admin-listener.http.xpowered-by=false
                      +asadmin> restart-domain   --domaindir /opt/glassfish3/glassfish/domains+

                      After that, we have solved both: no HTTP headers revealing glassfish and its version, no need to adjust 401, 404 etc. HTTP code responses as they are pretty generic now, too.

                      Regards, Tom
                      • 8. Re: hide glassfish server details
                        Hi Tom,

                        the default-web.xml is the default that may be overwritten or ignored by applications/servlets. This alone is not sufficient, which is why I had mentioned 2b). Anyway it's nice to have the template for the asadmin commands here as well, I only tested using the GUI. So thanks for putting this in here as well!
                        After that, we have solved both: no HTTP headers revealing glassfish and its version, no need to adjust 401, 404 etc. HTTP code responses as they are pretty generic now, too.
                        Well, the styles used aren't that generic, but at least they just hint at the server product, not its version. A custom error message will hide that piece of information as well, or could even be used to fake a different product, e.g. by integrating the error message of a well-patched Apache HTTPD on the current Debian release instead of a GlassFish on Windows. That way it might appear as if there is some hardened proxy or similar in front of their target and people might not start to try... "security by obscurity". ;)