. . .

Configure Tomcat and Apache Hardening

Despite the fact that most installations of Apache Tomcat and Webserver are delivered with enabled security features, there are some settings which improve security a bit more and help preventing attacks. These actions are commonly known as service hardening. The following paragraphs will describe which settings are already active by default in ApiOmat installations and which ones can be done optionally.

Tomcat hardening

Please also take a look at the following resources:


By default, the following measures are already active:


  • All unused webapps like hostmanager or ROOT are removed

  • LockOutRealm is active which prevents brute force attacks against user passwords in Tomcat Manager

  • ErrorReportValve is used to disable verbose stacktraces and output on errors

  • AccessLogValve is used to log all incoming requests


  • Tomcat is running as its own user (aom-yambas)

  • Removed version string from HTTP error messages (by repacking lib/catalina.jar)


You can optionally secure the system even more with the following hardening measures:


  • Disable public accessibility of port 8080. Instead, requests to port 80 and specifig URL paths get forwarded to Tomcat by an Apache Webserver that acts as proxy, which is installed and configured when using the ApiOmat installer.

  • Restrict access to manager application (/manager) from outside:

    • Either completely disable access from outside - if using the above mentioned proxy attempt with closed port 8080, this is already done by default

    • Or limit the access to the manager application to known IP addresses. This can be accomplished by using either a RemoteHostValve or RemoteAddrValve component at the server.xml

  • Access to the installer (/installer) can be restricted similar to the manager.

  • Shutdown port can be set to -1 to prevent unintended shutdowns (startup/stop scripts must be modified to work properly in that case)

  • Automatic deployment is controlled by the <Host> autoDeploy and deployOnStartup attributes in server.xml. If both are false, only Contexts defined in server.xml will be deployed and any changes will require a Tomcat restart.


  • Run Tomcat as a different user. By default, Tomcat runs as "Local System account", which is considered to be insecure. You can change that in one of the following ways:

    • The "Commons Daemon Service Manager": C:\tomcat8\bin\tomcat8w.exe. The tab "Log On" lets you choose a different account.

    • Or via the Windows services snap-in (services.msc). In the services window, find the service for Tomcat. The tab "Log On" lets you choose a different account.

    This should be a user account without privileged rights. The user needs the permission "Log on as a service" though, which in case you're using Active Directory LDS, can be set as described here.
    The following permission and directory changes are necessary as well:

    • The user should also have read, execute and directory traverse privileges for the Tomcat install directory (C:\tomcat8 by default)

    • The work, temp and logs directories within the Tomcat install directoriy need write and delete access for the user.

    • Make sure it does not have permissions to change permission or take ownership.

    • Please also note that the default log path in the log4j.xml is set to a subdirectory of the user that installed Tomcat, for example if the user was called "Administrator", the path is "C:\Users\Administrator\AppData\Local\ApiOmat\logs". You need to either change this to the subdirectory of the user that's now used to run Tomcat as as service (subdirectory needs to be created manually), or set the appropriate permissions.

    • The same goes for the files in "C:\Users\Administrator\AppData\Local\ApiOmat\config" - either change permissions or directories. Please note that in case you change the location of the configuration files, you need to do the following:

      • Tell Tomcat where to find the files: By default, when installing as user "Administrator" the Tomcat service is configured with the JvmOptions "-Dapiomat.config=C:\Users\Administrator\AppData\Local\ApiOmat\config\apiomat.yaml;-Dlog4j.configurationFile=file:C:\Users\Administrator\AppData\Local\log4j.xml;-Dhazelcast.config=C:\Users\Administrator\AppData\Local\hazelcast.xml;-Djava.security.policy=C:\Users\Administrator\AppData\Local\security.policy;-server;-Djava.awt.headless=true;-XX:+UseConcMarkSweepGC;-Dhazelcast.logging.type=log4j;-Djava.net.preferIPv4Stack=true;-Djava.net.preferIPv4Addresses" among others. Note that yambas.conf gets replaced by apiomat.yaml in 2.4 and newer versions. These (only the ones mentioned here) need to be changed.

      • The dashboard also accesses the yambas.conf / apiomat.yaml. It does so by reading the user environment variable "apiomat.config". There also is a system variable with the same name. Change both.

  • In the current version you need to do some manual steps to removed the version string from HTTP error message. This will get automated in future versions. The steps are:

    • After the installation is done, open a command line and execute the following command to unpack catalina.jar:

      • jar xf "C:\tomcat7\lib\catalina.jar" "C:\tomcat7\lib\org\apache\catalina\util\ServerInfo.properties"

    • Then open the file C:\tomcat7\lib\org\apache\catalina\util\ServerInfo.properties and remove the version string from the line that contains server.info=Apache Tomcat

    • Repack cataline.jar by executing the following command:

      • jar uf "C:\tomcat7\lib\catalina.jar" "C:\tomcat7\lib\org\apache\catalina\util\ServerInfo.properties"

Apache Webserver Hardening

Please take a look at the following resources:


By default, the following measures are already active:


  • ServerSignature and ServerTokens are set in main config file to prevent verbose output of server version information

  • Directory listing is disabled in dashboard, where dashboard is running as root website

  • Only used modules are activated

  • Trace is disabled

  • The X-Powered-By section of the HTTP header is not sent (expose_php = Off in php.ini)


  • Apache is running as its own user (non-root)


You can optionally secure the system even more with the following hardening measures:


  • mod_security works as a firewall and allows to monitor traffic on a real time basis. It also helps to protect websites or web server from brute force attacks. You can simply install mod_security on your server with the help of your default package installers.

  • By default Apache has no limit on the total size of the HTTP request i.e. unlimited and when you allow large requests on a web server its possible that you could be a victim of Denial of service attacks. You can Limit the requests size of an Apache directive “LimitRequestBody” with the directory tag.


SuperAdmin Hardening

To ensure that only specific machines have access to SuperAdmin Login via cURL you are able to set allowed IPs.


curl -X PUT --header 'Content-Type: application/json' --header 'Accept: application/json' --header 'X-apiomat-system: LIVE' --header 'If-None-Match: false' --header 'Authorization: Basic <YOUR_SUPERADMIN_AUTHENTICATION>' -d '{ "customerName" : "SuperAdmin", "allowedIPs" : [ "0:0:0:0:0:0:0:1","<ALLOWED_IP_1>","<ALLOWED_IP_2>" ] }' 'http://localhost:8080/yambas/rest/customers/SuperAdmin'

cURL example

curl -X PUT --header 'Content-Type: application/json' --header 'Accept: application/json' --header 'X-apiomat-system: LIVE' --header 'If-None-Match: false' --header 'Authorization: Basic U3VwZXJBZG1pbjpzZWNyZXQ=' -d '{ "customerName" : "SuperAdmin", "allowedIPs" : [ "0:0:0:0:0:0:0:1","" ] }' 'http://localhost:8080/yambas/rest/customers/SuperAdmin'

Keep in mind that the entry "0:0:0:0:0:0:0:1" within allowedIPs is needed for communication between Dashboard and Yambas, such as local cURL request to Yambas. Alternativly leave the allowedIP List empty.

Login attempt hardening

If a malicious user tries to guess passwords or starts brute force attacks, there are several methods available on ApiOmat and system level:

  • ApiOmat provides the possibility to lock accounts after several false attempts - please see the Password Policy configuration

  • To protect your whole infrastructure against brute force or Denial of Service attacks, there exist a variety of tools and methods on a datacenter level:

    • Use a UTM firewall

    • Ban IPs manually in firewall

    • Install tools like Fail2ban

    • Set up rate limits in your API gateway