===== Seguridad básica en servidores Tomcat =====

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.

==== Enmascarar / Ocultar versión de Tomcat ====

**Versión del servidor Tomcat**: Apache-Coyote/1.1

<code bash>
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
</code>

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//".

<code xml>
<Connector port="8080"
           maxThreads="150"
           minSpareThreads="25"
           connectionTimeout="20000"
           Server=" "
           enableLookups="false"
           maxHttpHeaderSize="8192"
                   ...
</code>

==== Arrancar el servicio Tomcat activando Security Manager ====

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.

<code bash>./startup.sh -security</code>

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.

<code>
/opt/atlassian/jira/bin/catalina.sh start -security

...
Existing PID file found during start.
Removing/clearing stale PID file.
Using Security Manager
</code>

==== Habilitar logs de acceso en Tomcat ====

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//.

<code xml>
<Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
               prefix="dominio_access_log." suffix=".txt" pattern="common" resolveHosts="false"/>
</code>

Una vez reiniciado el servicio veremos el archivo de log "//localhost_access_log//".

Documentación para configurar los ficheros logs de acceso en Tomcat: [[http://tomcat.apache.org/tomcat-6.0-doc/config/valve.html|Leer]]

En Jira esto ya viene configurado de serie en el fichero //server.xml// como se puede ver a continuación.

<code xml>
<Valve className="org.apache.catalina.valves.AccessLogValve" resolveHosts="false"
                   pattern="%a %{jira.request.id}r %{jira.request.username}r %t &quot;%m %U%q %H&quot; %s %b %D &quot;%{Referer}i&quot; &quot;%{User-Agent}i&quot; &quot;%{jira.request.assession.id}r&quot;"/>
</code>                   

<code>
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)" "-"
</code>

==== Uso de SSL (HTTPS) obligado ====

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.

<code xml>
  <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>
</code>

==== Cookies con etiquetas seguras (Secure flag) y HttpOnly ====

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//".

<code xml>
<Connector port="8080"
           maxThreads="150"
           minSpareThreads="25"
           connectionTimeout="20000"
           Server=" "
           Secure="true"
           enableLookups="false"
           maxHttpHeaderSize="8192"
           ...
</code>

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//".

<code xml>
<Context usehttponly="true">
   ...
</code>

==== Cuenta de usuario no privilegiada para Tomcat ====

Ejecutar el servidor con un usuario que no sea root es altamente recomendable.

<code bash>sudo -u jira-tomcat ${CATALINA_HOME}/bin/catalina.sh run</code>

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//.

==== Eliminar aplicaciones predeterminadas ====

En producción carecen de sentido las siguientes aplicaciones que se encuentran en "//${tomcat_home}/webapp//".

  * ROOT: Página de bienvenida.
  * Docs: Documentación de Tomcat.
  * Examples: Ejemplos de JSP y servlets.
  * Manager, host-manager: Administración de Tomcat.

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.

==== Modificar el puerto y comando para realizar shutdown del servidor ====

Por defecto Tomcat utiliza el puerto 8005 y el comando shutdown para apagar el servicio.

<code bash>
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.
</code>

Para poder modificar esos parámetros tenemos qu editar el archivo de configuración //server.xml// donde encontrarnos esta especificación:

<code xml><Server port="8005" shutdown="SHUTDOWN"></code>

La cambiamos por la que se crea conveniente.

<code xml><Server port="8009" shutdown="APAGARTOMCAT"></code>

Si lo que se quiere es desactivar dicha opción (Si no se usa es lo recomendable) valdría con lo siguiente.

<code xml><Server port="-1" shutdown="SHUTDOWN"></code>


==== Modificar las paginas de error 404, 403 y 500 ====

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///.

<code html error.jsp>
<html>
<head>
    <title>404-Page Not Found</title>
</head>
<body>
    <center><img src="http://robotmo.de/img/404.jpg"></center>
</body>
</html>
</code>

Al final del fichero //web.xml//, justo antes de la etiqueta "//</web-app>//" se agrega el siguiente código.
<code xml>
<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>
</code>

==== Tiempo de la sesión en Tomcat ====

Para estblecer los minutos que dura una sesión se debe editar el fichero web.xml con el siguiente contenido.
<code xml>
<session-config>
    <session-timeout>30</session-timeout>
</session-config>
</code>

En Jira por defecto está definido a 30 minutos.

==== Protección frente a la falsificación de petición en sitios cruzados (CSRF) ====

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//".

<code xml>
<filter-mapping>
<filter-name>CSRFPreventionFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
</code>

Para saber qué versión de Tomcat utiliza nuestra instancia de Jira solo hay que buscar en los logs.

<code bash>
grep "Application Server" /opt/atlassian/jira/logs/catalina.out
     Application Server                            : Apache Tomcat/7.0.49 - Servlet API 3.2
</code>

Una vez comprobada la versión se editaría el archivo ///opt/atlassian/jira/conf/web.xml//.

==== Restringir IPs / redes ====

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//.

<code xml>
<Valve className="org.apache.catalina.valves.RemoteAddrValve"
       allow="127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1|.*\.busindre\.com"/>
</code>

Más información: [[http://tomcat.apache.org/tomcat-6.0-doc/config/valve.html#Remote_Address_Filter]]

==== Restringir las interfaces de red donde escucha Tomcat ====

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.

<code xml>
<Connector port="TCP_PORT"
       address="LISTEN_IP_ADDRESS"
       maxThreads="150"
       ...
</code>

Si no se están usando alguno de los puertos definidos también es recomendable eliminarlos / comentarlos en el fichero de configuración

==== Desactivar implantaciones automáticas (Automatic deployment) ====

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".

<code>
autoDeploy="false"
deployOnStartup="false"
</code>



==== Enlaces de interés ====

[[http://tomcat.apache.org/lists.html#tomcat-announce|Lista de correo oficial sobre problemas de seguridad en tomcat.]]