Archive for the ‘Servidores de aplicaciones’ Category

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.

Anuncios
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

Instalación del tomcat

25 agosto 2009

bin – arranque, cierre, y otros scripts y ejecutables
temp – archivos temporales
conf – archivos XML y los correspondientes DTD para la configuración de apache-tomcat el mas importante es server.xml.
logs – archivos de registro (log) de apache-tomcat.
webapps – directorio que contiene las aplicaciones web
work – almacenamiento temporal de ficheros y directorios

  • Creación de la variable de entorno JAVA_HOME apuntando al directorio del JDK
  • vblentornoParada y arranque del tomcat:
    $CATALINA_HOME/bin/startup = arrancar
    $CATALINA_HOME/bin/shutdown = detener
    Seguidamente abrimos un navegador web y escribimos la URL
    http://{host}:{port}/ = donde {host}{port} representa el hostname y el puerto donde corre apache-tomcat, entonces quedaría http://localhost:8080/.
  • Para poder acceder a las aplicaciones de gestión y administración de apache-tomcat es necesario crear un usuario accediendo al siguiente directorio:    $CATALINA_HOME/conf/tomcat-users.xml
    <?xml version=’1.0′ encoding=’utf-8′?>
    <tomcat-users>
    <role rolename=”tomcat”/>
    <role rolename=”role1″/>
    <role rolename=”manager”/>
    <role rolename=”admin”/>
    <user username=”tomcat” password=”tomcat” roles=”tomcat”/>
  • <user username=”both” password=”tomcat” roles=”tomcat,role1″/>

    <user username=”role1″ password=”tomcat” roles=”role1″/>
    <user username=”TomcatAdmin” password=”tcpass“  roles=”admin,manager”/>

    </tomcat-users>
    Para acceder al manager la url es: localhost:8080/manager/html y para acceder a la administración es: localhost:8080/admin/

bin – arranque, cierre, y otros scripts y ejecutables
temp – archivos temporales
conf – archivos XML y los correspondientes DTD para la configuración de apache-tomcat el mas importante es server.xml.
logs – archivos de registro (log) de apache-tomcat.
webapps – directorio que contiene las aplicaciones web
work – almacenamiento temporal de ficheros y directorios