En esta guía se muestran algunos consejos a la hora asegurar mínimamente un servidor Tomcat. Se mostrarán también los pasos para seguir estos consejos en el servidor Tomcat que viene incluido en Jira.
Versión del servidor Tomcat: Apache-Coyote/1.1
curl -I -H "Accept-Encoding: gzip" --compressed http://jira.dominio:8080/secure/Dashboard.jspa HTTP/1.1 200 OK Server: Apache-Coyote/1.1 X-AREQUESTID: 527x823813x1 Cache-Control: no-cache, no-store, must-revalidate Pragma: no-cache Expires: Thu, 01 Jan 1970 00:00:00 GMT Content-Encoding: gzip Vary: User-Agent Set-Cookie: atlassian.xsrf.token=B1KY-AL7O-LZSL-0JX0|38de17bc1a615a953d36520e21a151747cba6331|lout; Path=/ X-AUSERNAME: anonymous X-Content-Type-Options: nosniff Set-Cookie: JSESSIONID=ADF2D54CB4F8B61BEDCD8378DED0589A; Path=/; HttpOnly Content-Type: text/html;charset=UTF-8 Transfer-Encoding: chunked Date: Wed, 19 Mar 2014 07:47:26 GMT
Para no mostrar o mostrar una falsa versión del servidor Tomcat en uso, hay que modificar el archivo “server.xml”. En nuestro ejemplo estamos utilizando el framework Jira, por lo que debemos ir a la ruta /opt/atlassian/jira/conf/ y agregar la directiva “Server”.
<Connector port="8080" maxThreads="150" minSpareThreads="25" connectionTimeout="20000" Server=" " enableLookups="false" maxHttpHeaderSize="8192" ...
El modo “Security Manager” ayuda a que los applets cargados por el cliente se ejecuten en su propia sandbox, evitando así que accedan a ficheros del sistema. Además protege al servidor de errores involuntarios, trojan servlets, JSPs, JSP beans y librerías de etiquetas.
./startup.sh -security
Información sobre Tomcat Security Manager: http://tomcat.apache.org/tomcat-6.0-doc/security-manager-howto.html
Para arrancar el servidor de Tomcat integrado en jira en modo Security Manager se puede hacer lo siguiente.
/opt/atlassian/jira/bin/catalina.sh start -security ... Existing PID file found during start. Removing/clearing stale PID file. Using Security Manager
En Tomcat no viene activado por defecto el uso de logs referentes a accesos, para activarlo se necesita hacer lo siguiente al fichero server.xml.
<Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="dominio_access_log." suffix=".txt" pattern="common" resolveHosts="false"/>
Una vez reiniciado el servicio veremos el archivo de log “localhost_access_log”.
Documentación para configurar los ficheros logs de acceso en Tomcat: Leer
En Jira esto ya viene configurado de serie en el fichero server.xml como se puede ver a continuación.
<Valve className="org.apache.catalina.valves.AccessLogValve" resolveHosts="false" pattern="%a %{jira.request.id}r %{jira.request.username}r %t "%m %U%q %H" %s %b %D "%{Referer}i" "%{User-Agent}i" "%{jira.request.assession.id}r""/>
10.0.198.143 1439x645554x1 - [15/Mar/2012:23:59:51 +0100] "GET /rest/capabilities/navigation?lang=en-US HTTP/1.0" 200 1481 4 "-" "Stash-2.6.1 (2010001)" "-"
Si se tiene configurado Tomcat para correr bajo https, lo recomendable es forzar que todas las conexiones se realicen cifradas, redirigiendo siempre solicitudes http a https.
Al final del fichero web.xml, justo antes de la etiqueta “</web-app>” se agrega el siguiente código.
<security-constraint> <web-resource-collection> <web-resource-name>Protected Context</web-resource-name> <url-pattern>/*</url-pattern> </web-resource-collection> <user-data-constraint> <transport-guarantee>CONFIDENTIAL</transport-guarantee> </user-data-constraint> </security-constraint>
Si se tiene configurado SSL bajo Http es recomendable que las cookies sean transmitidas únicamente por el canal cifrado TLS/SSL, para ello tenemos la opción “Secure-flag” en las cookies. Editamos el fichero /opt/atlassian/jira/conf/server.xml agregando la directiva “Secure”.
<Connector port="8080" maxThreads="150" minSpareThreads="25" connectionTimeout="20000" Server=" " Secure="true" enableLookups="false" maxHttpHeaderSize="8192" ...
Utilizar cookies declaras como HTTPonly protege a las mismas de lecturas y escrituras por parte de scripts del cliente. De esta forma solo el servidor y el navegador tendrán acceso a las cookies, dificultando así robos de sesión y otro tipo de problemas de seguridad. Este tipo de cookies pueden y son habitualmente definidas por parte del programador, pero es buena practica tener la directiva de obligado cumplimiento definida también en el servidor web.
Editamos el fichero /opt/atlassian/jira/conf/context.xml y editamos la etiqueta “Context”.
<Context usehttponly="true">
...
Ejecutar el servidor con un usuario que no sea root es altamente recomendable.
sudo -u jira-tomcat ${CATALINA_HOME}/bin/catalina.sh run
Tras la instalación de Jira se tiene definida la variable “$JIRA_USER” en el archivo “/opt/atlassian/jira/bin/user.sh”. En otras aplicaciones o configuraciones podemos encontrar el usuario de arranque en ficheros init script.
En producción carecen de sentido las siguientes aplicaciones que se encuentran en “${tomcat_home}/webapp”.
En Jira, si se ha instalado el paquete que viene con el servidor Tomcat incluido no es necesario eliminar nada ya que no vienen de serie esas aplicaciones.
Por defecto Tomcat utiliza el puerto 8005 y el comando shutdown para apagar el servicio.
telnet localhost 8005 Trying ::1... telnet: connect to address ::1: Connection refused Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. SHUTDOWN Connection closed by foreign host.
Para poder modificar esos parámetros tenemos qu editar el archivo de configuración server.xml donde encontrarnos esta especificación:
<Server port="8005" shutdown="SHUTDOWN">
La cambiamos por la que se crea conveniente.
<Server port="8009" shutdown="APAGARTOMCAT">
Si lo que se quiere es desactivar dicha opción (Si no se usa es lo recomendable) valdría con lo siguiente.
<Server port="-1" shutdown="SHUTDOWN">
Las páginas de error y excepciones en Tomcat, como en el resto de servidores web, han mostrado siempre información que no es necesaria mostrar en la mayoría de casos. Para poder visualizar páginas de error personalizadas editaremos los siguientes archivos.
En el directorio raíz de nuestro servidor Tomcat creamos la página de error “error.jsp”. En Jira la ruta sería /opt/atlassian/jira/atlassian-jira/.
<html> <head> <title>404-Page Not Found</title> </head> <body> <center><img src="http://robotmo.de/img/404.jpg"></center> </body> </html>
Al final del fichero web.xml, justo antes de la etiqueta “</web-app>” se agrega el siguiente código.
<error-page> <error-code>404</error-code> <location>/error.jsp</location> </error-page> <error-page> <error-code>403</error-code> <location>/error.jsp</location> </error-page> <error-page> <error-code>500</error-code> <location>/error.jsp</location> </error-page> <error-page> <exception-type>java.lang.Exception</exception-type> <location>/error.jsp</location> </error-page>
Para estblecer los minutos que dura una sesión se debe editar el fichero web.xml con el siguiente contenido.
<session-config> <session-timeout>30</session-timeout> </session-config>
En Jira por defecto está definido a 30 minutos.
A partir de la rama 7 de Tomcat es posible activar la protección contra ataques Cross-site request forgery (CSRF), solo hay que agregar estas lineas al fichero “web.xml”.
<filter-mapping> <filter-name>CSRFPreventionFilter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping>
Para saber qué versión de Tomcat utiliza nuestra instancia de Jira solo hay que buscar en los logs.
grep "Application Server" /opt/atlassian/jira/logs/catalina.out Application Server : Apache Tomcat/7.0.49 - Servlet API 3.2
Una vez comprobada la versión se editaría el archivo /opt/atlassian/jira/conf/web.xml.
Se debe editar el fichero context.xml y agregar las siguientes directrices dentro de la opción “Context”. Para el ejemplo solo se permite acceder desde “localhost” y el dominio “busindre.com”. Se soportan expresiones regulares java.util.regex.
<Valve className="org.apache.catalina.valves.RemoteAddrValve" allow="127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1|.*\.busindre\.com"/>
Más información: http://tomcat.apache.org/tomcat-6.0-doc/config/valve.html#Remote_Address_Filter
La opción “address” permite especificar la IP de la interfaz donde queremos que el servidor funcione. Se deben controlar todas las directivas “Connector” del fichero “server.xml” para no dejar nada expuesto.
<Connector port="TCP_PORT" address="LISTEN_IP_ADDRESS" maxThreads="150" ...
Si no se están usando alguno de los puertos definidos también es recomendable eliminarlos / comentarlos en el fichero de configuración
Tomcat con su configuración de serie permite la implementación automática de aplicaciones mientras se está ejecutandondo. Esta funcionalidad si no es necesaria se debe desactivar en el fichero de configuración “server.xml”.
autoDeploy="false" deployOnStartup="false"