Posts Tagged ‘Tomcat’

h1

Contendores del tomcat

2 noviembre 2009

Context Container

El Context element representa una aplicación web, que se ejecuta en un host virtual. Cada aplicacion se basa en un archivo de aplicación (WAR), o un directorio que contiene los elementos descomprimidos.

Catalina decide que plicación que procesa una petición HTTP basándose en la URI comparandola con la ruta del contexto. Una vez que se seleciona el contexto, éste decidira el servlet para procesar la petición de acuerdo con los mapeos de los servlets definidos en el descriptor de la aplicación web (web.xml) que se encuentra en /WEB-INF/web.xml.

Se pueden definir tantos contextos como se quiera, teninedo en cuenta que cada contexto tiene que tener una ruta única, además, debe de existir un contexto con una ruta con una ruta cuya longitud sea cero. Este contexto es el contexto por defecto para los hosts virtuales y se usa para procesar todas las peticiones que no coinciden con ningún contexto.

A partir del Tomcat 5, no se recomienda poner elementos directamente en el server.xml. Esto es porque no es posible modificar la configuración del contexto en el fichero server.xml y recargar dicha configuración sin reiniciar el Tomcat.

Los contextos se pueden definir explicitamente en:

$CATALINA_HOME/conf/context.xml: La información del contexto se cargaran por todas las aplicaciones.
$CATALINA_HOME/conf/[enginename]/[hostname]/context.xml : La información del contexto se cargara por todas las aplicaciones en ese host virtual.

Engine Container

El Engine representa todo el proceso de peticiones asociados a un servicio del catalina en particular, recibe y procesa todas las peticiones de uno o más conectores devolciendo el response completo al conector para que se la devuelva al cliente.

Tiene que existir un engine dentro de un sericio, seguido de todos los conectores asociados al servicio.

Host Container

El elemento host representa un host virtual, que representa una asociación al dominio (por ejemplo “www.google.com”) con el servidor Catalina sobre el que se ejecuta. Para que funcione correctamente se tiene que registrar la DNS.

Para poder asociar mas de un dominio a un host se tiene que usan los alias. Se pueden asociar mas de un host a un Engine. Dentro del host se puede anidar los contextos de las aplicaciones web asociados al host virtual. Al menos uno de tiene que ser el defaultHost del Engine.

h1

Válvulas de Tomcat

2 noviembre 2009

¿Qué es una válvula del tomcat?

Las válvulas del tomcat son una técnología introducida a partir de Tomcat 4 que permite asociar una instacia de una clase Java al un contenedor Catalina.

Esta configuración permite que la clase asociada actue como un pre-procesador de las peticiones. Estas clases se llaman válvulas, y deben implementar la intefaz org.apache.catalina.Valve interface o extender la clase org.apache.catalina.valves.ValveBase. Las válvulas son propias de Tomcat y no pueden ser usadas en otros contenedores de servlet. Las válvulas disponibles son:
– Access Log
– Remote Address Filter
– Remote Host Filter
– Request Dumper
– Single Sign On
– Form Authenticator

Access Log Valve

La primera válvula por defecto del tomcat es Access Log Valve, que está implementada por la clase org.apache.catalina.valves.AccessLogValve. Crea ficheros de log para rastrear el acceso a la información de los clientes.

Alguna de la infomación que rastrea son clicks, actividad de la sesión del usuario, información de la autenticación del usuario entre otras. Esta válvula se puede asociar a un engine, host o context container del Tomcat.

Ejemplo de uso :

<Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log." suffix=".txt" pattern="common"/>

Este código indica que los logs se guardaran en el directorio /logs, con el prefijo “localhost_access_log.”, y con el sufijo “.txt”.

Remote Address Filter

El Remote Address filter lo implementa la clase org.apache.catalina.valves.RemoteAddrValve, permite comparar direcciones IP de los clientes que realizan la petición con una o varias expresiones regulares para prohibir o permitir el acceso. Esta válvula se puede asociar al Engine, Host, o Context container.

Ejemplo de uso:

<Valve className="org.apache.catalina.valves.RemoteAddrValve" deny="127.*"/>
 

Esta sentencia prohibe el acceso a todos los clientes cuya IP empiecen por 127.

Remote Host Filter

El Remote Host filter está implementado por org.apache.catalina.valves.RemoteHostValve es muy parecido al RemoteAddrValve, con la diferencia que te permite comparar al nombre del host en vez de la IP. Se puede asociar al Engine, Host, o Context container.

Ejemplo de uso:

<Valve className="org.apache.catalina.valves.RemoteHostValve" deny="virtuas*"/>

Con esta sentencia prohibimos el acceso a todos los host con que incluyan en su nombre virtuas.

Request Dumper Valve

ElRequest Dumper valve lo implenta la clase org.apache.catalina.valves.RequestDumperValve es una herramienta de depuración que escribe en el log el detalle de cada petición realizada. Se puede asociar al Engine, Host, o Context container.

Ejemplo de uso:

<Valve className="org.apache.catalina.valves.RequestDumperValve"/>

Si accedemos a cualquier aplicación en localhost:8080 y accedemos al log, veremos unas cuantas entradas realizadas por el RequestDumperValve.

Single Sing On

Esta válvula se utiliza cuando queremos que los usuarios puedan identificarse en cualquier aplicacion en nuestro virtual host, y que su identidad sea reconocida por cualquier aplicación que esté en ese host.

Ejemplo de uso:

<Valve className="org.apache.catalina.authenticator.SingleSignOn" />

Form Authenticator Valve

Se añade automáticamente al Context cuando este se configura para usar autenticación mediante FORM.

h1

Control de accesos por IP a Tomcat

9 octubre 2009

Hace poco tuve que capar el acceso a una aplicación por IP, barajamos varias opciones y al final el personal de sistemas tomó una decisión. De todas formas me pareció muy interesante usar las valve o válvulas de Tomcat para hacerlo. Nunca lo había hecho, ni sabía que se podía hacer con el propio Tomcat, siempre había pensado en firewalls o apache, o cualquier otra cosa. La verdad es que nunca tuve que ver como se hacía hasta ahora.

Para hacerlo hay que hacer lo siguiente:

En el fichero server.xml, dentro del Host localhost, ponemos lo siguiente:

<Valve lassName="org.apache.catalina.valves.RemoteAddrValve" deny="192.164.1.*">

En este caso prohibimos el acceso a todas las direcciones IP que concuerden con 192.164.1.*, se pueden poner más si separamos las IPs con “,”. También se puede definir el parámetro “allow”  que se usa de la misma forma, en este caso todas las IPs que no concuerden con nuestra expresión, no podrán tener acceso.

h1

Vulnerabilidades en Tomcat

9 octubre 2009

Se han encontrado varios dos fallos de seguridad en las siguientes versiones de tomcat:

Tomcat 4.1.0 al 4.1.37

Tomcat 5.5.0 al 5.5.26

Tomcat 6.0.0 al 6.0.16

Estas vulnerabilidades son:

1)En el RequestDispatcher la ruta de destino se normalizó antes de que la cadena de consulta se ha retirado. Por lo tanto si se pone un parámetro malicioso en la consulta se puede conseguir acceder a información restringida o información que se encuentre en el WEB-IND

Ejemplo:

Una página que tenga:

<%

pageContext.forward("/page2.jsp?somepar=someval&par="+request.getParamet

er("blah"));

%>

El hacker puede usar:

http://host/page.jsp?blah=/../WEB-INF/web.xml

2) HttpServletResponse.sendError () no es sólo aparece en la página de error, también se utiliza en el HTTP response. Esto puede incluir caracteres que son ilegales en las cabeceras HTTP. Con un esto se puede conseguir un ataque XSS, al inyectar contenido arbitrario en la respuesta HTTP.

Por ejemplo:

<%@page contentType=”text/html”%>

<%

final String CRLF = "\u010D\u010A";

final String payload = CRLF + CRLF + "<script

type='text/javascript'>document.write('Hi, there!')</script><div style='display:none'>";

final String message = "Authorization is required to access " + payload;

response.sendError(403, message);

%>
h1

Comunicación entre contextos

9 octubre 2009
En uno de los proyectos en los que trabajo, tengo la necesidad de compartir variables entre dos contextos que se encuentran en el mismo Tomcat y descubrí el CrossContext que es un atributo de configuración de tomcat que sirve para que las diferentes aplicaciones en el servidor compartan el contexto.
Se tiene que modificar el fichero conf/server.xml del tomcat añadiendo las siguientes líneas dentro del tag <host>:
<Context path=”/miapiclicacion1″ debug=”0″ reloadable=”true” crossContext=”true” />
<Context path=”/miaplicicacion2″ debug=”0″ reloadable=”true” crossContext=”true” />
Con el “crossContext = true” indicamos a los dos proyectos que van a compartir información.

En uno de los proyectos en los que trabajo, tengo la necesidad de compartir variables entre dos contextos que se encuentran en el mismo Tomcat y descubrí el CrossContext que es un atributo de configuración de tomcat que sirve para que las diferentes aplicaciones en el servidor compartan el contexto.

Se tiene que modificar el fichero conf/server.xml del tomcat añadiendo las siguientes líneas dentro del tag <host>:

<Context path=”/miapiclicacion1″ debug=”0″ reloadable=”true” crossContext=”true” />

<Context path=”/miaplicicacion2″ debug=”0″ reloadable=”true” crossContext=”true” />

Con el “crossContext = true” indicamos a los dos proyectos que van a compartir información.

Ahora en una de las aplicaciones podemos poner algo así:

application.setAttribute(”variable”,”hola”);

En la otra ponemos

ServletContext sc = pageContext.getServletContext().getContext(”/miaplicacion2″); //inicializa el servlerContext con el nombre de la aplicación de la que queremos //obtener el contexto

out.println(sc.getAttribute(”variable”));

h1

¿Cuál es la diferencia entre common/lib y shared/lib en Tomcat?

8 octubre 2009

En common/lib están los archivos jar que se por las aplicaciones web y el propio servidor, mientras que en shared/lib tenemos las librerías que son accesibles sólo para las aplicaciones web.

h1

El log de Tomcat

22 enero 2009

Hoy he tenido un problema, me he dado cuenta de que mi log del tomcat era demasiado grande, 6 Gb; Lo cual me llamo la atención, ya que sabía, que por defecto el log de tomcat se define como “rotable” es decir, que se rotan los logs una vez al día. Miré si era problema de premisos y no, era problema de configuración. Así que desempolve mi libro de tomcat y lo configuré bien. De ahí, que hoy haya decidido explicar un poco este tema.

Desde el Tomcat 4, existe un concepto que se conoce como “valve” que permite asociar una instancia de una clase java a un contenedor Catalina. De esta forma, asociando el nombre de la clase, podemos hacer que esta actue como un preprocesador de cada solicitud. Estas clases deben implementar la clase org.apache.catalina.Valve o extender la org.apache.catalina.valves.ValveBase clase. Tomcat viene configurado con cuatro válvulas:

– Access Log

– Remote Address Filter

– Remote Host Filter

– Request Dumper

Me voy a centrar en la primera, la válvula del log o LogAccessValve, la clase es org.apache.catalina.valves.AccessLogValve. Cuya misión es crear archivos de log para seguir el seguimiento de la aplicación del servidor de aplicaciones o de la aplicación si deseamos usar este log y no uno propio para ello. Algunos de las seguimientos que hace esta válvula es hit counts, actividad de la sesión del usuario, la autenticación de los usuarios, entre otros.

El siguiente fragmento de código es un ejemplo usando la entrada org.apache.catalina.valves.AccessLogValve:

<Valve className=”org.apache.catalina.valves.AccessLogValve” directory=”logs” prefix=”localhost_access_log.” suffix=”.txt” pattern=”common”/>

Este fragmento de código establece que los archivos de log se colocarán en la <CATALINA_HOME> /, con el sufijo localhost_access_log, con el sufijo txt.

El atributo que me dio a mi el quebradero de cabeza era rotable, que en mi caso estaba a false y con esto hay que tener mucho cuidado. Por defecto está a true.