Rodrigo Quiroga Challco

8264238 LP
Tarea 7
1. Incorporacin de mecanismos de seguridad en servicios web
Dos asuntos a tratar: Uno es el de la seguridad de los servicios Web integrada con
Windows y su implicacin en un entorno cliente/servidor;.y dos, el de poder extender
a nuestro gusto, el mensaje de intercambio de datos SOAP para enriquecer lo que ya
tenemos, o adaptarlo a nuestras necesidades, por ejemplo, la de la seguridad. En este
artculo, pretendo ensearos el cmo escribir aplicaciones cliente/servidor basadas
en servicios Web seguros, empleando por un lado la autenticacin de la que tanto se
ha hablado en nmero anteriores y, por el otro, una herramienta muy potente del
estndar WSDL/SOAP: la posibilidad de extender las cabeceras SOAP para extender el
protocolo en base a nuestras necesidades, por ejemplo, montar un sistema de
seguridad "extendido" para pasar algo ms que simples credenciales. Seguridad
integrada con Windows ste es el punto ms sencillo. De artculos anteriores hemos
sacado en claro que la seguridad integrada de IIS es extremadamente sencilla de
configurar. Se basa en asegurar un directorio virtual empleando los mecanismos de
autenticacin, o bien emplear el descriptor XML, web.config, para sobrescribir el
comportamiento del propio IIS cuando nos referimos a un contexto Web de aplicacin
determinado -con la ventaja de no tener que andar cacharreando con sus opciones-. Si
realizamos un sencillo servicio que ofrezca un proceso de negocio simple como, por
ejemplo, convertir de pesetas a euros, el reto ser el de garantizar que slo aquellos
clientes autenticados correctamente, puedan acceder a las funciones del servicio. Para
ello, realizaremos 3 sencillas operaciones: a) Crear el proyecto de un servicio Web -
como ya seguro que a estas alturas hemos hecho cientos de veces- al que llamaremos
ServiciosMonetarios. b) Crear un nuevo servicio Web en este proyecto al que
denominaremos WSConversor. Su misin, ofrecer diversos mecanismos de conversin
de divisas (ver fuente 1). c) Asegurar el servicio empleando el descriptor web.config
de nuestro proyecto. Configurando la autenticacin integrada de Windows, para evitar
que nadie no autenticado, pueda consumir nuestros servicios (ver fuente 2). Si todo
est bien configurado, veremos que el intento de probar el servicio desde el propio
WebServices Explorer -que cariosamente nos genera el propio IIS-, nos anima
amablemente a autenticarnos con cuentas Windows, o bien a decirnos de una forma
parca y sencilla que nos dediquemos a otras cosas, porque se nos ha denegado el
acceso. Es importante que tengamos en cuenta, que la nica autenticacin que no
podemos usar de las ofrecidas por ASP.NET, es la que est basada en WebForms. Esto
es lgico, pues estamos hablando de un modelo de servicios, en los que seguro no
cabr la posibilidad de abrir un WebForm, o mejor an, como no sabemos qu
tecnologa o framework va a acceder al servicio, no podemos presumir de obligar al
consumidor a usar ASP.NET en un navegador cuando a lo mejor, estn empleando
WinForms. Queda claro. Ahora viene la parte curiosa. La que nos lleva a consumir el
servicio desde un cliente que no tiene por qu ser Web. Vamos a utilizar un cliente
WinForm que nos ofrezca un interfaz sencillo y discreto a la par que funcional. Para
ello crearemos un nuevo proyecto y, tras una esmerada ventana como la que se ve en
la figura 2, pasaremos a importar una referencia al servicio Web remoto. Tras
autenticarnos y recoger el WSDL y haberse generado el correspondiente proxy SOAP,
ya slo nos queda implementar la funcionalidad de los eventos clic de los botones "A
Euros" y "A Pesetas", quedando tal y como se e en la figura 2 (ver tambin fuente 3).
Rodrigo Quiroga Challco
8264238 LP
Como podris observar, la autenticacin es extremadamente sencilla cuando
empleamos los objetos ICredential de .NET. Acoplando las credenciales a nuestro
consumidor, conseguiremos superar las barreras de seguridad y obtener nuestro
preciado resultado. Como veis he optado por emplear la clase
System.net.CredentialCache que nos proporciona la informacin de la cuenta activa
del usuario. Pero si alguno necesita especificarlo de un modo ms explcito, podis
usar la clase System.net.NetworkCredentials. Para probar qu pasa si no tenis
permisos de acceso, siempre podis denegar el acceso a todo quisqui desde el
web.config o bien, especificar unas credenciales a pin falsas. Al final, saltar una
pedazo de Exception que dejar muy claras las cosas. Pero hasta aqu lo sencillo. Y
seguro que lo conocido. Pero esto tiene un pequeo inconveniente: que nos limitamos
a la seguridad de credenciales de Windows y nada ms. Si queremos recoger ms
informacin acerca del usuario (grupo, mquina, rol, telfono de la hermana, etc.)
estaremos limitados a pasar dicha informacin como atributos del servicio
(parmetros, para llevarnos bien). Y eso, no es una solucin elegante. O bien comernos
el tarro para integrarnos con un Active Directory, emplear los objetos de
DirectoryServices de .NET y recoger toda la informacin de usuario de su cuenta AD.
Pero esto, que es muy interesante -y que veremos en futuros artculos- ahora se nos
sale de los lmites de los objetivos y, en muchos casos, de las necesidades reales de un
proyecto. Pero ahora viene una solucin alternativa. Cabeceras SOAP personali-zadas
Como hemos podido ver, es extremadamente sencillo y transparente asegurar un
servicio Web empleando la seguridad ASP.NET -y, por extensin, la de IIS-. Pero qu
ocurre si es requisito del proyecto el montar un sistema de seguridad de aplicacin
casero que no dependa de nadie ms que de nosotros? El problema que se nos plantea
es que sea el propio servicio Web el que valide la seguridad en su mismo cdigo. Y
para ello debemos establecer que algunos de sus parmetros especifiquen las
credenciales. Pero eso no es del todo cmodo y complica las especificaciones de los
servicios, ya que nos vemos "copiando/pegando" las definiciones en todas las
llamadas. Pero hay una alternativa muy interesante Porqu no hacer que sea el
propio protocolo de comunicaciones de los servicios web (SOAP) el que propague
unas credenciales que hemos diseado nosotros. Y que luego cada servicio recoja del
protocolo dichas credenciales, como si fueran una parte integrante ms de la clase del
servicio. Es decir, que se nos permite extender el esquema del mensaje SOAP para que
agreguemos nuevas clases, que sern recuperadas por los mismos mecanismos que
generan dicho SOAP: la serializacin automtica del propio servicio web. Muy
prctico. La idea: disear un sistema de seguridad. Necesidad: disear la clase que
representar el modelo de informacin de las credenciales de seguridad. Objetivo:
integrar ese modelo de informacin en el mensaje SOAP e integrarlo con la lgica de
negocio. La extensibilidad de SOAP en .NET es especialmente transparente. El modelo
SOAP corresponde a los interfaces que expone el servicio. Es decir, los mtodos que
establece como pblicos y bajo la directiva WebMethod. El serializador, pues, genera
el esquema WSDL y de ste el mensaje SOAP en el momento de la accin. Pues bien,
extender las cabeceras es un proceso similar. Agregamos un modelo de informacin a
la clase del servicio Web (en cristiano, un nuevo tipo de clase), y la exponemos como
extensin al mismo en los mtodos que lo requieran (en cristiano, definimos una
variable miembro que actuar de objeto cuando se requiera). Para ello emplearemos
Rodrigo Quiroga Challco
8264238 LP
la directiva SoapHeader en cada servicio Web. De esta manera, la nueva cabecera ser
serializada por el mismo proceso, evitndonos todo ese trabajo que implica.
Agregando un nuevo servicio Web a nuestro proyecto, que he llamado
WSConversorExtendido -bajo un nuevo proyecto de servicio Web, denominado
ServiciosMonetariosEx-, mirar cmo queda el cdigo, que es muy claro (fuente 4).
Como podis observar, es extremadamente fcil de implementar. En este sencillo
ejemplo, me limitar a comprobar un nombre de grupo para autenticar al usuario. Ni
qu decir tiene que no es ms que la punta del iceberg, ya que tenis la posibilidad de
utilizar estos datos a vuestro antojo (bases de datos, servicios de seguridad,
integracin con AD, etc.). En nuestro ejemplo, en este nuevo caso, nos aseguraremos
de permitir el acceso annimo al servicio Web desde el motor ASP.NET o del IIS, ya
que la responsabilidad de autenticacin recae en el propio servicio. Aunque si alguien
quiere reforzarlo, no tiene ms que dejar la seguridad como lo especificamos en el
ejemplo anterior. Pero sera redundante, no?. Antes de continuar, aprovecho para
hacer el inciso. Sera estupendo que accedierais al esquema WSDL del nuevo servicio.
Para evitar que el editor me mate mostrando el WSDL, no lo pondremos aqu. Pero si
os fijis encontrareis cmo la serializacin integra nuestra clase "cabecera SOAP" en
todos los mensajes. Muy bonito y elegante. De hecho, es impresionante ver cmo
nuestra nica misin en el desarrollo ha sido establecer el formato de los datos (clase
CredencialesSOAP) y qu servicio va a disponer de ella, empleando una sencilla
directiva para proceder a usar el objeto; ya que se nos garantiza su instancia a travs
del propio SOAP del servicio (ver figura 4). El ltimo paso es ver cmo quedara la
implementacin del cliente. Aprovechando el mismo ejemplo anterior, en este caso la
poltica no sera la de autenticarse con los objetos ICredential de .NET, sino
aprovechar los mecanismos que la clase Proxy de nuestro nuevo servicio nos
proporciona a partir del nuevo esquema WSDL. El modelo del nuevo formulario
quedar ahora, tras agregar un campo nuevo en el que pondremos el nombre del
"grupo de seguridad", como en las figuras 5. El cdigo -tras terminar las "referencias
Web" oportunas- de los eventos clic puede verlo en el fuente 6. Y funcionando. Mirar
qu pasa si lo hacemos bien o si nos equivocamos en el nombre del grupo oportuno
(se ha especificado un grupo distinto para cada operacin de conversin -ver figura 6
y 7-). Conclusiones Hemos podido ver en este artculo lo sencillo y transparente que es
disear servicios Web seguros. Bien sea a travs de los servicios que nos ofrecen los
propios sistemas de Microsoft, o bien a travs de invenciones nuestras; lo que est
claro es que se ha notado la preocupacin del desarrollo de aplicaciones seguras. Y se
demuestra que .NET de nuevo est al pie del can, ofreciendo multitud de potentes e
interesantes alternativas. Deciros que las cabeceras SOAP no se limitan slo a la
seguridad de los servicios Web, sino a otros diseos ms generales. Aprovechad esta
potencia para poder especificar reglas de enrutado, extensin de ficheros aadidos al
mensaje SOAP, informacin extra del servicio, y un largo etctera. Ya sabis en qu
mecanismos se basan los nuevos WSE de Microsoft. Ya no tenis excusa para no
asegurar vuestros servicios. El cdigo fuente lo tenis disponible en la Web de la
revista (http://www.dotnetmania.com)o en mi pgina Web personal (
http:www.heviatec.net). Para la prueba de la demo de Cabeceras SOAP, emplear para
cada botn el grupo "AccesoEuros" o "AccesoPesetas". Cualquier otra combinacin os
dar la excepcin de error de seguridad. Muy chulo, hasta la prxima.
Rodrigo Quiroga Challco
8264238 LP
2. Configuracin de opciones de seguridad:
Autenticacin de usuarios
seguridad de comunicaciones
Cmo funciona la seguridad: autenticacin y autorizacin
El sistema de seguridad de Symfony se basa en identificar primero al usuario
(autenticacin) y comprobando despus si ese usuario tiene acceso al recurso
solicitado (autorizacin).
Firewalls (autenticacin)
El sistema de seguridad de Symfony se activa cuando un usuario hace una peticin a
una URL que est protegida por un firewall o cortafuegos. El trabajo
del firewall consiste en determinar si el usuario necesita estar autenticado, y si lo
necesita, enviar una respuesta al usuario para iniciar el proceso de autenticacin.
Un firewall se activa cuando la URL de una peticin entrante concuerda con el valor de
su opcin de configuracin pattern. En este ejemplo el valor de pattern (^/) concuerda
con cualquier peticin entrante. No obstante, el hecho de que el firewall est activado
no significa que el navegador muestra la caja de login+contrasea para todas las URL.
Los usuarios pueden acceder por ejemplo a /foosin que la aplicacin les pida que se
autentiquen.

Figura 13.2 Accediendo a una URL no restringida
Este funcionamiento es posible en primer lugar porque el firewall permite el acceso a
los usuarios annimos debido a la opcin de configuracin anonymous. En otras
palabras, el firewall no exige que todos los usuarios se autentiquen nada ms acceder
a la aplicacin. Y como en la configuracin de la seccin access_control no se indica
que los usuarios deban tener ningn role especial para acceder a /foo la peticin se
procesa sin requerir al usuario que se autentique.
Rodrigo Quiroga Challco
8264238 LP
Si eliminas la opcin anonymous, el efecto es que ahora el firewall pide autenticacin a
cualquier usuario que solicite cualquier recurso.
Control de acceso (autorizacin)
Siguiendo con el mismo ejemplo, si un usuario solicita /admin/foo, la aplicacin se
comporta de manera diferente. Esto es debido a la configuracin de la
seccin access_control, que indica que cualquier URL que coincida con la expresin
regular ^/admin (es decir, la URL /admin o cualquier otra URL que coincida
con /admin/*) requiere el rol ROLE_ADMIN. Los roles son la clave del sistema de
autorizacin: el usuario puede acceder a /admin/foo slo si cuenta con el
rol ROLE_ADMIN.

Figura 13.3 Denegando el acceso a una URL protegida
Al igual que suceda anteriormente, cuando el usuario realiza su peticin, el firewall no
solicita ningn tipo de identificacin. Sin embargo, en cuanto la capa de control de
acceso deniega el acceso al usuario (porque los usuarios annimos no cuentan con el
rol ROLE_ADMIN), el firewall toma el control de la aplicacin e inicia el proceso de
autenticacin.
El proceso de autenticacin depende del mecanismo de autenticacin que utilices. Si
ests utilizando por ejemplo el mtodo de autenticacin con formulario de acceso, el
usuario ser redirigido a la pgina de inicio de sesin. Si ests utilizando la
autenticacin HTTP, se enviar al usuario una respuesta con cdigo de estado HTTP
401 para que el usuario vea el cuadro de dilogo de login y contrasea.
Ahora el usuario tiene la oportunidad de enviar sus credenciales a la aplicacin. Si
estas credenciales son vlidas, se reintenta la peticin original.
Rodrigo Quiroga Challco
8264238 LP

Figura 13.4 Denegando el acceso a un usuario sin la autorizacin adecuada
En este ejemplo, el usuario ryan se autentica correctamente con el firewall. Pero
como ryan no cuenta con el rol ROLE_ADMIN, se le sigue negando el acceso
a /admin/foo. En la prctica esto significa que ryan ver un mensaje indicndole que
se le ha denegado el acceso.
TRUCO Cuando Symfony niega el acceso al usuario, se muestra una pantalla de error y
la respuesta enviada contiene un cdigo de estado HTTP 403 (Forbidden). Puedes
personalizar el aspecto y el contenido de las pginas de error y de acceso denegado
siguiendo las instrucciones del artculo How to customize Error Pages.
Por ltimo, si el usuario admin solicita /admin/foo, se lleva a cabo un proceso similar,
excepto que ahora, despus de haberse autenticado, la capa de control de acceso
permitir pasar a la peticin:

Figura 13.5 Accediendo a un recurso protegido
Rodrigo Quiroga Challco
8264238 LP
El flujo de la peticin cuando un usuario solicita un recurso protegido es sencillo, pero
increblemente flexible. Como vers ms adelante, la autenticacin se puede realizar
de varias maneras, desde el tpico formulario de acceso hasta los certificados X.509 o
mediante Twitter. Independientemente del mtodo de autenticacin, el flujo de la
peticin siempre es el mismo:
1. Un usuario accede a un recurso protegido.
2. La aplicacin redirige al usuario al formulario de acceso.
3. El usuario presenta sus credenciales (por ejemplo nombre de
usuario/contrasea).
4. El firewall autentica al usuario.
5. El usuario intenta de nuevo la peticin original ahora que ya est autenticado.
3. Anlisis de logs de servidores HTTP
Archivos de Registro (Log Files)
Para administrar de manera efectiva un servidor web, es necesario tener registros de
la actividad y el rendimiento del servidor as como de cualquier problema que haya
podido ocurrir durante su operacin. El servidor HTTP Apache ofrece capacidades
muy amplias de registro de este tipo de informacin. Este documento explica cmo
configurar esas capacidades de registro, y cmo comprender qu informacin
contienen los ficheros de registro.
Registro de Errores (Error Log)
Mdulos Relacionados Directivas Relacionadas
ErrorLog
LogLevel
El registro de errores del servidor, cuyo nombre y ubicacin se especifica en la
directiva ErrorLog, es el ms importante de todos los registros. Apache enviar
cualquier informacin de diagnstico y registrar cualquier error que encuentre al
procesar peticiones al archivo de registro seleccionado. Es el primer lugar donde tiene
que mirar cuando surja un problema al iniciar el servidor o durante su operacin
normal, porque con frecuencia encontrar en l informacin detallada de qu ha ido
mal y cmo solucionar el problema.
El registro de errores se escribe normalmente en un fichero (cuyo nombre suele
ser error_log en sistemas Unix y error.log en Windows y OS/2). En sistemas Unix
tambin es posible hacer que el servidor enve los mensajes de error
al syslog o pasarlos a un programa.
El formato del registro de errores es relativamente libre y descriptivo. No obstante,
hay cierta informacin que se incluye en casi todas las entradas de un registro de
errores. Por ejemplo, este es un mensaje tpico.
[Wed Oct 11 14:32:52 2000] [error] [client 127.0.0.1] client denied by server
configuration: /export/home/live/ap/htdocs/test
El primer elemento de la entrada es la fecha y la hora del mensaje. El segundo
elemento indica la gravedad del error que se ha producido. La directiva LogLevel se
usa para controlar los tipos de errores que se envan al registro de errores segn su
gravedad. La tercera parte contiene la direccin IP del cliente que gener el error.
Despus de la direccin IP est el mensaje de error propiamente dicho, que en este
caso indica que el servidor ha sido configurado para denegar el acceso a ese cliente. El
Rodrigo Quiroga Challco
8264238 LP
servidor reporta tambin la ruta en el sistema de ficheros (en vez de la ruta en el
servidor web) del documento solicitado.
En el registro de errores puede aparecer una amplia variedad de mensajes diferentes.
La mayora tienen un aspecto similar al del ejemplo de arriba. El registro de errores
tambin contiene mensaje de depuracin de scripts CGI. Cualquier informacin escrita
en el stderr por un script CGI se copiar directamente en el registro de errores.
El registro de errores no se puede personalizar aadiendo o quitando informacin. Sin
embargo, las entradas del registro de errores que se refieren a determinadas
peticiones tienen sus correspondientes entradas en el registro de acceso. El ejemplo
de arriba se corresponde con una entrada en el registro de acceso que tendr un
cdigo de estado 403. Como es posible personalizar el registro de acceso, puede
obtener ms informacin sobre los errores que se producen usando ese registro
tambin.
Si hace pruebas, suele ser de utilidad monitorizar de forma continua el registro de
errores para comprobar si ocurre algn problema. En sistemas Unix, puede hacer esto
usando:
tail -f error_log

Registro de Acceso (Access Log)
Mdulos Relacionados Directivas Relacionadas
mod_log_config
mod_setenvif
CustomLog
LogFormat
SetEnvIf
El servidor almacena en el registro de acceso informacin sobre todas las peticiones
que procesa. La ubicacin del fichero de registro y el contenido que se registra se
pueden modificar con la directiva CustomLog. Puede usar la directiva LogFormat para
simplificar la seleccin de los contenidos que quiere que se incluyan en los registros.
Esta seccin explica como configurar el servidor para que registre la informacin que
usted considere oportuno en el registro de acceso.
Por supuesto, almacenar informacin en el registro de acceso es solamente el
principio en la gestin de los registros. El siguiente paso es analizar la informacin
que contienen para producir estadsticas que le resulten de utilidad. Explicar el
anlisis de los registros en general est fuera de los propsitos de este documento, y
no es propiamente una parte del trabajo del servidor web. Para ms informacin
sobre este tema, y para aplicaciones que analizan los registros, puede visitar Open
Directoryo Yahoo.
Diferentes versiones de Apache httpd han usado otros mdulos y directivas para
controlar la informacin que se almacena en el registro de acceso, incluyendo
mod_log_referer, mod_log_agent, y la directiva TransferLog. Ahora la
directiva CustomLog asume toda la funcionalidad que antes estaba repartida.
El formato del registro de acceso es altamente configurable. El formato se especifica
usando una cadena de caracteres de formato similar a las de printf(1) en lenguaje C.
Hay algunos ejemplos en las siguientes secciones. Si quiere una lista completa de los
posibles contenidos que se pueden incluir, consulte la documentaci sobre las cadenas
de caracteres de formato del mod_log_config.
Rodrigo Quiroga Challco
8264238 LP
Formato Comn de Registro (Common Log Format)
Una configuracin tpica del registro de acceso podra tener un aspecto similar a este.
LogFormat "%h %l %u %t \"%r\" %>s %b" common
CustomLog logs/access_log common
Con esto se define el apodo (nickname) common y se le lo asocia con un determinado
formato. El formato consiste en una serie de directivas con tantos por ciento, cada una
de las cuales le dice al servidor que registre una determinada informacin en
particular. El formato tambin puede incluir caracteres literales, que se copiarn
directamente en el registro. Si usa el caracter comillas (") debe anteponerle una barra
invertida para evitar que sea interpretado como el final la cadena de caracteres a
registrar. El formato que especifique tambin puede contener los caracteres de
control especiales "\n" para salto de lnea y "\t" para tabulador.
La directiva CustomLog crea un nuevo fichero de registro usando el apodo definido. El
nombre del fichero de registro de acceso se asume que es relativo al valor
especificado en ServerRoot a no ser que empiece por una barra (/).
La configuracin de arriba escribir las entradas en el registro con el formato
conocido como Formato Comn de Registro (CLF). Este formato estndar lo pueden
generar muchos servidores web diferentes y lo pueden leer muchos de los progrmas
que analizan registros. Las entradas de un fichero de registro que respetan ese
formato comn tienen una aparariencia parecida es esta:
127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET /apache_pb.gif HTTP/1.0" 200
2326
Cada una de las partes de la entrada se explican a continuaci#243;n.
127.0.0.1 (%h)
Es la direccin IP del cliente (host remoto) que hizo la peticin al
servidor. Si la directiva HostnameLookups tiene valor On, el servidor
intentar determinar el nombre del host y registrar ese nombre en
lugar de la direccin IP. Sin embargo, no se recomienda que use esta
configuracin porque puede ralentizar significativamente las
operaciones del servidor. En su lugar, es mejor usar un programa que
realice esta tarea posteriormente sobre el registro, por
ejemplologresolve. Las direcciones IP que se registren no son
necesariamente las direcciones de las mquinas de los usuarios
finales. Si existe un servidor proxy entre el usuario final y el servidor,
la direccin que se registra es la del proxy.
- (%l)
Un "guin" siginifica que la informacin que debera ir en ese lugar no
est disponible. En este caso, esa informacin es la identidad RFC
1413 del cliente determinada por identd en la mquina del cliente.
Esta informacin es muy poco fiable y no debera ser usada nunca
excepto con clientes que estn sometidos a controles muy estrictos en
redes internas. Apache httpd ni siquiera intenta recoger esa
informacin a menos que la directiva IdentityCheck tenga valor On.
frank (%u)
Este es el identificador de usuario de la persona que solicita el
documento determinado por la autentificacin HTTP. Normalmente
Rodrigo Quiroga Challco
8264238 LP
ese mismo valor se pasa a los scripts CGI con la variable de
entorno REMOTE_USER. Si el cdigo de estado de la peticin (ver
abajo) es 401, entonces no debe confiar en la veracidad de ese dato
porque el usuario no ha sido an autentificado. Si el documento no
est protegido por contrasea, se mostrar un guin "-" en esta
entrada.
[10/Oct/2000:13:55:36 -0700] (%t)
La hora a la que el servidor recibi la peticin. El formato es:
[da/mes/ao:hora:minuto:segundo zona_horaria]
day = 2*digit
month = 3*letter
year = 4*digit
hour = 2*digit
minute = 2*digit
second = 2*digit
zone = (`+' | `-') 4*digit
Es posible mostrar la hora de otra manera especificando %{format} en
el formato a usar en el registro, donde format se sustituye como se
hara al usarstrftime(3) de la librera estndar de C.
"GET /apache_pb.gif HTTP/1.0" (\"%r\")
La lnea de la peticin del cliente se muestra entre dobles comillas. La
lnea de peticin contiene mucha informacin de utilidad. Primero, el
mtodo usado por el cliente es GET. Segundo, el cliente ha hecho una
peticin al recurso /apache_pb.gif, y tercero, el cliente uso el
protocolo HTTP/1.0. Tambin es posible registrar una o ms partes de
la lnea de peticin independientemente. Por ejemplo, el formato "%m
%U%q %H" registrar el mtodo, ruta, cadena de consulta y
protocolo, teniendo exactamente el mismo resultado que "%r".
200 (%>s)
Es el cdigo de estado que el servidor enva de vuelta al cliente. Esta
informacin es muy valiosa, porque revela si la peticin fue
respondida con xito por el servidor (los cdigos que empiezan por 2),
una redireccin (los cdigos que empiezan por 3), un error provocado
por el cliente (los cdigos que empiezan por 4), o un error en el
servidor (los cdigos que empiezan por 5). La lista completa de
cdigos de estado posibles puede consultarle en la especificacin de
HTTP(RFC2616 seccin 10).
2326 (%b)
La ltima entrada indica el tamao del objeto retornado por el cliente,
no includas las cabeceras de respuesta. Si no se respondi con ningn
contenido al cliente, este valor mostrar valor "-". Para registrar "0" en
ese caso, use %B en su lugar.
Formato de Registro Combinado (Combined Log Format)
Otro formato usado a menudo es el llamado Formato de Registro Combinado. Este
formato puede ser usado como sigue.
Rodrigo Quiroga Challco
8264238 LP
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\""
combined
CustomLog log/access_log combined
Es exactamente igual que Formato Comn de Registro, pero aade dos campos. Cada
campo adicional usa la directiva %{header}i, donde header puede ser cualquier
cabecera de peticin HTTP. El registro de acceso cuando se usa este formato tendr
este aspecto:
127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET /apache_pb.gif HTTP/1.0" 200
2326 "http://www.example.com/start.html" "Mozilla/4.08 [en] (Win98; I ;Nav)"
Los campos adicionales son:
"http://www.example.com/start.html" (\"%{Referer}i\")
La cabecera de peticin de HTTP "Referer" (sic). Muestra el servidor
del que proviene el cliente. (Esta debera ser la pgina que contiene un
enlace o que contiene a /apache_pb.gif).
"Mozilla/4.08 [en] (Win98; I ;Nav)" (\"%{User-agent}i\")
La cabecera de peticin HTTP "User-Agent". Es la informacin de
identificacin que el navegador del cliente incluye sobre s mismo.
Cmo usar varios registros de acceso
Para crear varios registros de acceso solamente tiene que especificar varias
directivas CustomLog en el fichero de configuracin. Por ejemplo, las siguientes
directivas crearn tres registros de acceso. El primero contendr la informacin
bsica en Formato Comn de Registro, mientras que el segundo y el tercero
contendrn contendrn la informacin de los "referer" y de los navegadores usados.
Las dos ltimas lneas CustomLog muestran cmo reproducir el comportamiento de
las directivas ReferLog y AgentLog.
LogFormat "%h %l %u %t \"%r\" %>s %b" common
CustomLog logs/access_log common
CustomLog logs/referer_log "%{Referer}i -> %U"
CustomLog logs/agent_log "%{User-agent}i"
Este ejemplo tambin muestra que no es necesario definir un "apodo" con la
directiva LogFormat. En lugar de esto, el formato de registro puede especificarse
directamente en la directiva CustomLog.
Registro Condicional
Algunas veces es ms conveniente excluir determinadas entradas del registro de
acceso en funcin de las caractersticas de la peticin del cliente. Puede hacer esto
fcilmente con la ayuda de variables de entorno. Primero, debe especificar una
variable de entorno que indique que la peticin cumple determinadas condiciones.
Esto se hace normalmente con SetEnvIf. Entonces puede usar la clasula env= de la
directiva CustomLog para incluir o excluir peticiones en las que est presente la
variable de entorno. Algunos ejemplos:
# Marcar las peticiones de la interfaz loop-back
SetEnvIf Remote_Addr "127\.0\.0\.1" dontlog
# Marcar las peticiones del fichero robots.txt
SetEnvIf Request_URI "^/robots\.txt$" dontlog
# Registrar lo que quede
CustomLog logs/access_log common env=!dontlog
Rodrigo Quiroga Challco
8264238 LP
Como otro ejemplo, considere registrar las peticiones de los angloparlantes en un
fichero de registro, y el resto de peticiones en un fichero de registro diferente.
SetEnvIf Accept-Language "en" english
CustomLog logs/english_log common env=english
CustomLog logs/non_english_log common env=!english
Aunque acabamos de mostar que el registro condicional es muy potente y flexible, no
es la nica manera de controlar los contenidos de los ficheros de registro. Los ficheros
de registro son ms tiles cuanta ms informacin sobre la actividad del servidor
contengan. A menudo es ms fcil eliminar las peticiones que no le interesen
procesando posteriormente los ficheros de registro originales.

4. Anlisis de rendimiento de Apache
Comando ab
La utilidad ab (Apache Benchmark) sirve para hacer pruebas de carga a un servidor
apache. Es un programa que forma parte del apaquete apache2-utils.
Veamos un ejemplo:
ab -n 1000 -c 5 -k http://localhost/
El anterior comando simula 5 usuarios al mismo tiempo ahciendo 1000 peticiones al
servidor web del localhost. La opcin -k (keep_alive) habilita la opcin de no cerrar la
sesin HTTP. Veamos los resultados de este comando:
Benchmarking localhost (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests


Server Software: Apache/2.2.16
Server Hostname: localhost
Server Port: 80

Document Path: /
Document Length: 42587 bytes

Concurrency Level: 5
Time taken for tests: 0.140 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Rodrigo Quiroga Challco
8264238 LP
Keep-Alive requests: 995
Total transferred: 42903740 bytes
HTML transferred: 42587000 bytes
Requests per second: 7124.44 [#/sec] (mean)
Time per request: 0.702 [ms] (mean)
Time per request: 0.140 [ms] (mean, across all concurrent requests)
Transfer rate: 298500.90 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.1 0 3
Processing: 0 1 0.1 1 3
Waiting: 0 0 0.2 0 2
Total: 0 1 0.2 1 3

Percentage of the requests served within a certain time (ms)
50% 1
66% 1
75% 1
80% 1
90% 1
95% 1
98% 1
99% 1
100% 3 (longest request)