Warning: Use of undefined constant ‘xmlrpc_methods’ - assumed '‘xmlrpc_methods’' (this will throw an Error in a future version of PHP) in /var/www/html/wp-config.php on line 84
Apache Tomcat 7.0.12 / 7.0.13 Security Constraint Bypass | ShieldNow

La instancia de Apache Tomcat 7.x que escucha en el host remoto es anterior a 7.0.6. Por lo tanto, se ve afectado por una vulnerabilidad de secuencias de comandos entre sitios en su interfaz HTML Manager. Un atacante remoto puede aprovechar esto para inyectar código en el navegador de un usuario a través de una URL diseñada.

CVE: CVE-2011-1582
Factor de Riesgo: Medio
Valor CVSS Base: 5.1

Solución

Actualice Apache Tomcat a la versión 7.0.14o posterior más estable.

https://archive.apache.org/dist/tomcat/tomcat-7/v7.0.14/

Solucion Alternativa

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

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.

./startup.sh -security

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

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

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

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, antes de la etiqueta “” 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>

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

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

Cuenta de usuario no privilegiada para Tomcat

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

sudo -u jira-tomcat ${USER_PROOF}/bin/USER.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.

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.

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.

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

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

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.

<session-config>
    <session-timeout>30</session-timeout>
</session-config&gt;

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

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

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.

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

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.

<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

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

autoDeploy="false"
deployOnStartup="false"

Referencias

https://svn.apache.org/viewvc?view=revision&revision=1100832
http://www.nessus.org/u?1a1f0794
http://tomcat.apache.org/lists.html#tomcat-announce

No Comment

You can post first response comment.

Leave A Comment

Please enter your name. Please enter an valid email address. Please enter message.

You may also like