La importancia de manejar los archivos de registro de sucesos HTTP

Una de las informaciones menos apreciadas de las que el desarrollador web tiene a la mano, son los archivos de registro de sucesos del servicio HTTP. Estos normalmente eran considerados la única fuente de información estadística a mano. En ellos los usuarios van dejando su huella cada vez que solicitan un recurso en nuestro servidor, bien sea Apache, IIS, WebSphere o cualquier otro.

La razón por la que han sido dejando algo de lado, es que si bien su información es valiosa, ya no son tan útiles para fines estadísticos debido al gran éxito de Google Analytics el cual permite hacer seguimiento de todos los movimientos de páginas en las que se haya agregado un pequeño "script" al final de las mismas, y para ser realmente honesto sus reportes y estadísticas son impresionantes.

Pero a nivel de seguridad Google Analytics nos sirve de poco o casi nada, ya que no lleva control más que de las páginas en las que se agrega el script y no así de los recursos como imágenes, archivos de flash y archivos de código Javascript. Además si la página en ejecución genera un error 500 de ejecución en el servidor y no se completa, tampoco será de utilidad ya que el servidor no habrá entregado la parte final de la página (desde el error en adelante) y el archivo de control de Google Analytics se encuentra siempre al final del código de la página. Tampoco detectará un escaneo de vulnerabilidades no autorizado, debido a que las maquinarias de escaneo no ejecutan los scripts de las páginas que escanean...

Sin embargo dejando esta maravillosa solución estadística para el equipo de mercadeo, por efectos de seguridad es necesario retomar el control de los archivos de sucesos del servidor HTTP. El mejor lugar para detectar un intento de escaneo de vulnerabilidades no autorizado es precisamente allí. Sin embargo, hallar la información en estos enormes archivos de texto, no es simple debido a que cada solicitud hecha al servidor HTTP generará una línea, y una página junto con sus diferentes componentes podría generar hasta 80 líneas diferentes por lo que si la página es solicitada 1000 veces, estaríamos hablando de 80.000 líneas o "hits". En un ataque de DoS (Denial of Service) comunmente podemos llegar a recibir esa cantidad de solicitudes por minuto, por lo que capturar las direcciones IP de los equipos atacantes puede ser un trabajo bastante duro.

Escarbar en un archivo de estas magnitudes sin una herramienta apropiada es difícil. Pero no hay que alarmarse, probablemente usted ya haya oido hablar de AWstats 6.95  en su última versión estable en el momento de escribir este artículo. AWstats es una solución Open Source, y por tanto la mayoría de los proveedores de alojamiento compartido la ofrecen en sus soluciones en sus paneles de control. Es 100% configurable al tipo de servidor HTTP que se esté manejando y permite obtener una serie de reportes muy importantes acerca de las peticiones recibidas.

Existen soluciones mucho más sofisticadas como Urchin 7.0. Esta solución es la matriz de código sobre la que se basa Google Analytics y al estar instalado en un servidor y analizar los archivos de registro de sucesos (a los que no puede acceder Analytics) podrá reportar muchos más detalles. En realidad es una herramienta impresionante, pero no es gratis.

Sin embargo, ni AWstats ni URCHIN 7 ni siquiera los archivos de registro HTTP pueden servirnos para rastrear los errores de ejecución en nuestra aplicación, ya que si bien los registros de sucesos HTTP pueden decirnos en qué página y que IP generó el error, no pueden darnos detalle del error en sí  y datos como el número de línea, descripción del error y otros detalles muy importantes para corregir el problema.

Para poder manejar este problema Apache tiene un registro independiente que se encuentra en /var/log/apache2/error_log (o error.log) en donde podremos detectar los errores que produce la aplicación sin necesidad de esperar a que algún usuario los reporte. En el caso de IIS también existe una solución, pero los errores 500 del servidor HTTP son considerados errores de sistema y es necesario recurrir al visor de sucesos (Herramientas Administrativas/Administración de Equipos/Visor de sucesos).

En IIS el manejo del error 500 depende de la capacidad de poder acceder a los archivos de registros de error, por lo que la mejor solución para evitar problemas especialmente en entornos de alojamiento compartido, es generar nuestra propia página de error 500, con la que primordialmente ocultaremos la información que no deseamos ofrecer al visitante, y la registraremos a gusto en un archivo de sucesos propio.

En este artículo muy interesante explica el tratamiento de los errores 500 de diferentes formas para aplicaciones en ASP.NET. Para aquellos que trabajen sobre Apache este otro artículo puede explicarles detalladamente el proceso de manejo de páginas de error personalizadas.

Por otro lado siempre es importante aclarar que el uso de páginas de error personalizadas es muy importante, inclusive para el manejo de otro tipo de errores. Por ejemplo: Los atacantes pueden obtener mucha información detectando errores 404 y 403, con la mezcla de los cuales y una buena dosis de ingenio acerca de los nombres comúnmente utilizados para nombrar directorios y páginas, logran obtener una visión bastante acertada del arbol de directorios de nuestra aplicación.

Hasta la próxima.