Tomcat Web Hosting Blog - Java, JSP, EJB, Hibernate

Chapter 14: Tomcat Security Removing JSP and Servlet Examples While neither of these JSP or servlet examples presents any known security risks (other than providing obvious targets for Denial of Service attacks), it s a good idea to delete them. They provide no useful functionality, and the possibility exists that attackers can exploit them. They are located in the following location: $CATALINA_HOME/webapps/examples Deleting the examples application is as simple as removing the examples directory and everything under it. Changing the SHUTDOWN Command By default, the Tomcat SHUTDOWN command works by connecting to a special Tomcat socket on port 8005 and sending the following character sequence: SHUTDOWN Tomcat provides no authentication mechanism to restrict clients from connecting to Tomcat, sending these characters, and shutting down Tomcat. You can try it yourself by using Telnet. The easiest way to prevent unauthorized use of this functionality is by blocking port 8005 with a firewall. If this is not possible for whatever reason, the system administrator should change the port and the SHUTDOWNcharacter sequence by editing the following line of the TOMCAT_INSTALLATION/conf/ server.xmlfile: In this example, the port has been changed to 8098and the character sequence to downbaby. Running Tomcat with a Special Account Despite the best efforts of Tomcat s authors, application developers, and system administrators, there is a chance that Tomcat can be exploited. Thus, it is prudent to consider mechanisms that prevent the amount of damage that an attacker could inflict by gaining control of Tomcat. Perhaps the most effective damage-control mechanism is running Tomcat under its own account, an account with only those privileges necessary to run Tomcat and nothing more. If this strategy is used, hackers who gain control of Tomcat are presented with few ways to wreak havoc. The following sections describe the process of running Tomcat with its own account. Note that when running Tomcat with its own (non-root) account on Linux systems, the Tomcat server instance will not be able to bind to the privileged port 80. Binding to port 80 is desirable because users can access the server without specifying the port in the URL (for example, http://www.wrox.com/ instead of http://www.wrox.com:8080/). This can be readily solved by redirecting incoming port 80 traffic of a hardware firewall/router to the Tomcat host s port 8080. Other solutions exist and are fully explored in Chapter 3 .

For high quality website hosting services please check tomcat web hosting website.