Apache

  • Un pregunta de un lector en la entrada Hardening de SSL/TLS en servidores HTTPS me llevó a buscar y probar una solución para este problema: cómo predecir el impacto, en los clientes de un sitio Web, al deshabilitar un protocolo inseguro dentro de la configuración de suites de cifrado de TLS.

    Este lector en particular, necesitaba saber si alguno de sus clientes se verían afectados al deshabilitar el algoritmo criptográfico de encriptación de flujo RC4, el cual es inseguro (vulnerable a un amplio abanico de ataques y ya sin soporte por los principales navegadores). La solución consiste en lograr que el servidor Web registre en el log de accesos el protocolo y suite de cifrado elegidas durante la negociación (handshake) para cada acceso. De esta forma es posible, luego de un tiempo, determinar si existen cliente que aún utilizan el protocolo/suite de cifrado que deseamos deshabilitar (para mejorar la seguridad).

  • A veces hay que aplicar alguna configuración de emergencia para resolver un problema urgente, pero la misma puede afectar a los usuarios que están conectados actualmente a un servidor. Existe una variedad de causas diferentes que pueden perjudicar a los usuarios actuales de un servicio. Por ejemplo puede hace falta reiniciar Apache, o directamente detenerlo porque es necesario reiniciar un servidor de bases de datos. También podría ser necesario reiniciar directamente el sistema operativo por un problema de hardware (se llenó un disco y hay que ampliar su capacidad, o agregar más memoria RAM). Sea como sea, los Sysadmins en general buscamos un horario fuera de oficina para este tipo de "actividades", pero en caso de emergencias, no queda otra alternativa que hacerlo en horarios de oficina. En este caso puede ser útil saber si hay usuarios actualmente conectados al servidor, para afectar a la menor cantidad de gente posible.

  • Transport Layer Security (TLS) y Secure Sockets Layer (SSL) son protocolos criptográficos que proveen una conexión segura a través de Internet. Utilizan criptografía asimétrica para autenticar claves de intercambio, criptografía simétrica para lograr confidencialidad y funciones hash llamadas MAC para verificar integridad.

    Los servidores Web, por ejemplo Apache, utilizan TLS y SSL para implementar el protocolo HTTPS (Hypertext Transfer Protocol Secure). A través de este protocolo los clientes pueden navegar sitios de forma segura garantizando confidencialidad (los pedidos sólo pueden ser interpretados por el cliente y el servidor), integridad (los pedidos no han sido alterados durante el tránsito) y autenticidad (el servidor es quien dice ser). De esta forma se evita: 1- Que un tercero sea capaz de "ver" el tráfico entre cliente y servidor, y obtener información confidencial o sensible en la comunicación; 2- Que un tercero sea capaz de interponerse entre cliente y servidor para alterar pedidos o respuestas (ataque man-in-the-middle); 3- Que un servidor de un tercero se haga pasar por otro (por ejemplo: un servidor atacante que se hace pasar por el servidor del banco, generalmente involucra un ataque DNS previo o algún tipo de XSS).

    Gracias a HTTPS podemos navegar tranquilos por portales de bancos, correo electrónico, etc. En la actualidad debería ser un estándar de facto en la industria, pero lamentablemente existen muchos sitios Web que aún no lo utilizan, y a veces nuestras credenciales e información sensible viajan por la red en formato "plano", es decir sin codificar, al alcance de cualquier atacante.

    Este artículo explica cómo instalar y configurar SSL en Apache, utilizando un servidor CentOS 6.4 como ejemplo.

  • En uno de los servidores Web que administro, una nueva aplicación requirió proteger el acceso a un directorio mediante autenticación Digest. En el artículo Proteger con contraseña un directorio Web expliqué cómo configurar la autenticación Basic en Apache. Pero para el caso de Digest, el procedimiento es levemente diferente ya que se debe configurar correctamente el Realm de cada usuario y directorio.

  • Hoy tuve la necesidad de obtener el número total de bytes transferidos por mi servidor Web, para tener una noción del volumen de tráfico saliente. Esta información es útil para estimar el consumo de ancho de banda mensual requerido por un servidor, dato de suma importancia cuando se trata de servidores en la nube, donde los servicios suelen utilizar la metodología de pago por uso.

  • Necesitaba saber cuál era la mejor hora para correr un script de mantenimiento en un servidor Web, y se me ocurrió desarrollar un script Bash que muestre una estadística de accesos por hora a partir de los archivos de log de Apache.

    Lo que me interesaba era conocer con exactitud la cantidad de accesos para cada hora según la información que se encuentra en los archivos de log de Apache (access_log y error_log). No me interesaban los días (ya que la tarea de mantenimiento necesitaba ejecutarla todos los días) y necesitaba leer de varios archivos de log simultáneamente, para tener datos fidedignos.

    Se trataba de una tarea simple, que seguramente implementen muchísimas herramientas diferentes. Pero no tenía tiempo para ponerme a instalar y testear una aplicación, y mucho menos para esperar que se llene una base de datos de accesos. Tenía que ser sí o sí a partir de los archivos de log ya existentes. Por esta razón, la solución más rápida para mi fue escribir un pequeño script Bash, el cual comparto en este artículo.

  • Muchas veces suele ocurrir que errores de programación de PHP (por ejemplo, falta de validación de variables o comprobación de límites en estructuras) llenan los logs del servidor Apache con mensajes PHP Notice. Si estos errores se repiten muy frecuentemente, pueden ocasionar un problema de espacio en disco (ya que los archivos de log crecen en forma desmedida). Sin contar con que llenan los logs con mensajes irrelevantes para el administrador de sistemas. Por lo tanto, puede ser necesario deshabilitarlos para que directamente no se guarde registro de los mismos en los logs de Apache.

  • Se me ocurrió buscar intentos de acceso fallidos a paneles de control de diversos CMSs y no creerás lo que sucederá...

  • En este breve artículo comparto una experiencia con un servidor Apache retornando "503 Service Unavailable":

  • En este artículo explico cómo separar los reportes del servicio httpd en logwatch. Esto es útil para discriminar desde qué sitio se produjo una alerta en un resumen enviado por mail. La idea es tener un resumen por cada VirtualHost, en lugar de un resumen para todo el servicio httpd.

  • Al hacer debugging de scripts PHP es posible que necesitemos enviar mensajes de error a Apache si las tradicionales "banderitas" no funcionan. Puede ser el caso en el que un script entre en un bucle infinito y no alcance a mostrar por salida estándard sentencias "echo" o "print" (a pesar de que estén antes de la ejecución del bucle o ejecución problemática)

  • Este breve artículo explica cómo redireccionar todo el tráfico HTTP a HTTPS para todos los VirtualHost de un servidor Apache. El objetivo es forzar HTTPS para todos los sitios alojados en nuestro servidor Apache.

  • Se me ocurrió bloquear intentos de acceso a ciertas URLs en mi servidor Web. Al buscar alternativas para realizar esta tarea, lo primero que surge es fail2ban. Pero me pareció que, para este caso en particular, era como matar una mosca con una bazooka. Por ello decidí implementar un pequeño script bash que corra periódicamente desde cron.

  • Una de las muchas formas de "vender humo" en este mundo consiste en ofrecer soluciones a problemas inexistentes. Entre los tantos requisitos para certificar la norma ISO 9001:2015, una empresa debe contar con un sistema de registro y gestión de no conformidades. Como dentro de mi organización se está buscando certificar dicha norma, se solicitó al área de sistemas evaluar alternativas de software para implementar dicha herramienta.

    A simple vista, el cuento de la certificación ISO parece un gran negocio para las empresas consultoras. Esto se hace evidente cuando uno descubre que la mayoría de las herramientas de software para la gestión de calidad son de licencia propietaria. Es decir, hay empresas que se dedican exclusivamente a desarrollar soluciones cerradas para requerimientos impuestos por terceros (el consultor cobra una suma importante por venderte el problema y su socio por venderte la solución). Aunque, afortunadamente, investigando un largo rato en Internet, surgió la oportunidad de instalar y probar KMKey Quality, gracias al Catálogo de Software Libre de la Universidad de La Laguna.

    KMKey Quality es un software de gestión de calidad ideal para la implantación y mantenimiento de un Sistema de Gestión de calidad (SGC) de cualquier tipo: ISO 9001, ISO 14001, OHSAS 18001, etc, o de una combinación de los mismos, facilitando la gestión de un sistema integrado.

    KMKey es liberado bajo la licencia GPLv2, pero su creador y principal impulsor es la empresa Earcon, quien hace lo mínimo indispensable para cumplir con dicha licencia.

    En el mundo existe software libre y open source de todo tipo. Hay proyectos importantes desarrollados por grandes comunidades, proyectos medianos desarrollados por grupos más pequeños, y proyectos chicos desarrollados por individuos. Pero a pesar de las diferencias en cuestiones de importancia/magnitud, en general todos cultivan los valores del software libre hablando en términos de calidad de software. El software comunitario en general está cuidadosamente documentado, tanto en forma de manuales como a nivel de comentarios en el código fuente. Además se cuida mucho la limpieza del código, ya que se piensa desde el día cero en que el código fuente estará a la vista de todo el mundo. Así sea un solo individuo quien desarrolle/mantenga una pieza de software libre, si es un miembro de la comunidad open source, muy posiblemente respete y promulgue estas ideas. Pienso que más aún siendo el caso de un individuo, pues si su intención es sumar desarrolladores a su proyecto, debe saber que probablemente pocos sientan deseos de aportar código o soluciones a un proyecto cuyo código fuente es desprolijo y/o pobremente documentado.

    En el software privado es diferente, porque los desarrolladores tienen la certeza de que nadie fuera de la empresa verá su código fuente. Entonces la calidad del software se reduce a las políticas de calidad de software de la empresa.

    Pero hay otra clase de proyectos libres u open source, y son aquellos desarrollados y mantenidos por una única empresa de software comercial. Y digo comercial porque el código fuente se libera bajo licencias libres u open source, sólo que la empresa detrás del "producto" es quien lucra con el mismo. Esto no está mal, por supuesto. Si estuviese prohibido hacer dinero con el software libre, éste simplemente no existiría.

    El problema surge cuando la empresa que mantiene una pieza de software libre hace todo lo posible para monopolizar su soporte. Por ejemplo, libera todo su código fuente sin comentarios (quien haya examinado código fuente de systemd puede comprobarlo), hace todo lo posible por ofuscar su configuración, y peor aún no provee documentación alguna. Es decir, hace lo mínimo indispensable para cumplir con la licencia.

    Tal vez uno se pregunte por qué entonces estas empresas liberan el código bajo una licencia libre u open source, si no tienen deseos de sus productos de software sean en esencia libre. Esto ocurre porque en muchos países, notablemente en la Unión Europea, han tomado al sabia decisión de forzar el uso de software libre en entidades gubernamentales. La consecuencia de esta decisión, es que las empresas proveedoras de software para el estado se vieron obligadas a liberar sus productos bajo licencias abiertas. Incluso puede ser que hayan tenido que abrir el código de productos antes cerrados, lo cual pone en evidencia lo ordinario que es el software de código cerrado.

    A ésto se reduce mi experiencia con KMkey y por ello que decidí compartir este artículo. Tanto la arquitectura de KMKey como el proceso de instalación y configuración, carecen de una documentación mínima. A causa de esto es necesario realizar un trabajo de ingeniería inversa, a partir de un appliance disponible en Internet, e invertir largas horas, sólo para entender cómo funciona, cómo se relacionan sus diferentes componentes, y cómo lograr ponerlo en funcionamiento en uno de nuestros servidores.

  • Mientras realizaba unas tareas de reconfiguración de un servidor Web Apache, me topé con los siguientes errores al momento de reiniciar el servicio:

    Address already in use: make_sock: could not bind to address
    

    Este error indica que el socket está en uso, es decir, no se puede ligar al puerto 80 en la dirección especificada porque está ocupado por otro proceso.

    Unable to open logs
    Action 'start' failed.
    

    Y este error indica que no puede abrir los archivos de log, por la misma razón.

  • CKAN es un poderoso sistema de gestión de datos que permite hacer la información accesible, agilizando la publicación, y proveyendo herramientas para compartir, encontrar y utilizar datos. CKAN apunta a entidades (gobiernos, compañías y organizaciones) que desean hacer sus datos abiertos y públicos.

    Este artículo explica la instalación completa de CKAN desde sus fuentes en un sistema Debian 7, incluyendo la configuración del DataStore, FileStore, DataPusher, y el plugin "ckanext-basiccharts" (para gráficos de torta, barra y otros).

  • Este artículo explica cómo instalar Apache con soporte para la ejecución de scripts Perl en modo CGI en Debian y derivados.

  • Este artículo explica cómo montar un servidor LAMP utilizando la combinación Linux+Apache+Python+MySQL sobre distribuciones Debian y derivadas.

  • En el artículo anterior expliqué cómo instalar un servidor Linux con Apache, Python y MySQL. Ahora voy a explicar cómo lograr la misma combinación pero reemplazando MySQL con PostgreSQL, el motor de bases de datos open source más avanzado.

  • LAMP es un modelo de arquitectura pila de servidor Web nombrado como acrónimo de cuatro componentes open-source: Linux, Apache, MySQL, PHP. La definición "arquitectura pila" surge a partir de cómo se organiza el software en capas, cada una dando soporte a las capas superiores. LAMP se organiza con Linux como sistema operativo (¡a la hoguera! se escribe GNU/Linux y el término debería ser GLAMP), Apache como servidor HTTP/HTTPS, MySQL/MariaDB como servidor de bases de datos, y PHP/Perl/Python como lenguaje de programación/CGI scripting. LAMP es el modelo más popular para crear y dar soporte a aplicaciones Web en Internet desde hace tiempo.

    Este breve artículo muestra cómo instalar y configurar rápidamente un stack LAMP sobre sistemas operativos Debian/Devuan y derivados basado en MySQL y PHP.