Apache

  • En esta oportunidad voy a demostrar cómo recuperar valores de variables en una cookie HTTP, desde mod_rewrite, para rescribir URLs. Esto permite crear redirecciones basándose en un valor almacenado en una variable de la cookie con Apache.

    Como probablemente la mayoría de los lectores sepan, las cookies HTTP son pequeñas porciones de datos enviados desde un servidor Web al cliente para mantener información relacionada a la sesión de navegación. Esto permite recordar accesos, mantener tickets y preferencias del usuario, seguir hábitos de navegación, etc.

    Las cookies son transmitidas desde el servidor al cliente en formato de texto plano a través de la cabecera HTTP Set-Cookie, y enviadas de vuelta al servidor (en cada subsiguiente solicitud) mediante la cabecera Cookie. De esta forma, las cookies son mantenidas y almacenadas en disco en el lado cliente y como tal, son pasibles de ser manipuladas por el mismo. Con lo cual no es posible mantener información sensible a ser alterada en las mismas, como por ejemplo roles, privilegios, etc. Sin embargo son útiles para hacer seguimiento de hábitos de navegación, mantener preferencias del sitio, etc.

  • 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.

  • Cuando veo cosas como estas me saco el sombrero ante los rusos, son genios del spam, verdaderos maestros artistas del spam, virus, botnets, etc. El hecho es que desde hace algunos meses linuxito.com está siendo víctima de una nueva técnica de spam en los referals HTTP.

  • Este artículo explica cómo crear reglas de reescritura para ocultar nombres de archivos en un directorio Web, ya sea para ocultar información o para crear URLs amigables, utilizando archivos .htaccess y mod_rewrite.

    Los archivos .htaccess (hypertext access) son archivos de configuración distribuida que permiten definir diferentes directivas de configuración para cada directorio (junto con sus respectivos subdirectorios) sin necesidad de editar el archivo de configuración principal de Apache.

    Entre sus usos más frecuentes, los archivos .htaccess permiten: autorizar y autenticar usuarios; especificar restricciones de seguridad para un directorio en particular; crear URLs amigables o semánticas (reescribir URLs largas y complejas, en otras más simples y fácil de recordar); bloquear usuarios por su dirección IP y/o dominio e ISP utilizando directivas allow/deny; permitir o denegar el listado de directorios Web; crear redirecciones estáticas; crear respuestas de error personalizadas; controlar la caché por medio de los navegadores y servidores proxy para reducir el uso del ancho de banda, la carga en el servidor, y los tiempos de acceso; evitar hotlink; y mucho más...

  • Este artículo explica cómo proteger el acceso a un directorio en un servidor Web Apache utilizando archivos .htaccess

  • Este artículo explica cómo configurar Apache y collectd en un servidor Debian/Devuan o derivado para recolectar estadísticas y monitorear el servidor Web mediante el uso del módulo mod_status.

    En la serie de artículos anteriores he explicado cómo compilar y configurar collectd en Debian para almacenar métricas en una base de datos InfluxDB y cómo graficar métricas desde una base InfluxDB en Grafana. Este esquema me permite generar gráficas de monitoreo de actividad de servidores Nginx. Veamos ahora cómo configurar collectd para generar estas mismas gráficas pero a fin de monitorear la actividad sobre un servidor Web Apache.

  • Anteriormente expliqué cómo forzar HTTPS en Apache y cómo redirigir al dominio con www. para HTTP y HTTPS en Nginx. Esta vez es el turno de implementar la redirección hacia el dominio con www. por delante sobre HTTPS en Apache.

    Cabe recordar que, a fin de evitar problemas con Google a causa de contenido duplicado, es altamente recomendable que todos los dominios asociados a un sitio redirijan a uno por defecto. Por ejemplo si los dominios "linuxito.com" y "www.linuxito.com" resuelven ambos a un mismo sitio Web, es necesario seleccionar uno predilecto, y el resto deberán implementar redirecciones permanentes (HTTP 301) hacia el mismo. En mi caso "www.linuxito.com" es el dominio preferido y "linuxito.com" es una redirección permanente hacia "www.linuxito.com".

    De esta forma, si un usuario ingresa a la URL:

    http://linuxito.com/seguridad/180-forzar-https-en-apache

    Será redireccionado inmediatamente hacia la siguiente:

    http://www.linuxito.com/seguridad/180-forzar-https-en-apache

    Si además se ha forzado el uso de HTTPS (mediante una redirección permanente hacia "https://"), la URL será la siguiente:

    https://www.linuxito.com/seguridad/180-forzar-https-en-apache

  • Luego de migrar un sitio MediaWiki a un nuevo servidor, me encontré con el siguiente error al tratar de cargar las imágenes incrustadas en las páginas:

    [Wed Dec 07 20:05:40 2016] [alert] [client 192.168.85.159] /var/www/wiki/images/.htaccess: RewriteEngine not allowed here, referer: http://wiki.linuxito.com/index.php/Manuales
    
  • Mi recientemente publicado script GTFO lleva ya dos días corriendo cada dos minutos. Estos son los resultados.

  • El mes pasado expliqué detalladamente cómo instalar y configurar ModSecurity en Apache sobre servidores Debian. En este artículo voy a compartir un muy útil script Bash para generar un resumen del log de auditoría de ModSecurity.

  • Una de las premisas básicas en el proceso de hardening de un servidor Web consiste en minimizar la cantidad de directorios donde el mismo tiene escritura. De esta forma se minimizan la cantidad de directorios donde un atacante pueda explotar una vulnerabilidad que le permita subir archivos (los cuales pueden ser shells, backdoors, etc.) Para ello, es necesario determinar todos los directorios donde el usuario bajo el que corre el demonio del servidor Web tiene acceso de escritura a nivel filesystem.

    En este artículo presento un script Bash que realiza dicha tarea en servidores GNU/Linux. Tal vez los usuarios avanzados se preguntarán por qué no usar directamente find, el cual es capaz de examinar y testear los atributos de los archivos tales como permisos UNIX, usuario (UID) y grupo (GID). Esto estaría bien cuando se tiene un filesystem que utiliza los permisos UNIX tradicionales, pero si utilizamos ACLs, find se queda "corto", ya que no posee la funcionalidad necesaria para examinarlas.

  • Actualmente, IPv6 es el tema que me resulta más interesante para investigar (siempre contando con la ayuda de VirtualBox). Hace un tiempo investigué los protocolos de bajo nivel: configuración estática de direcciones IPv6; Neighbor Discovery; Autoconfiguración de direcciones IPv6 de ámbito global tanto en routers (i.e. PC's funcionando como routers, se instala el demonio radvd) como en clientes (trivial); RIPng con zebra; y DNS utilizando bind9.

    En este artículo voy a explicar HTTP sobre IPv6 y cómo levantar un servidor web Apache que funcione sobre IPv6. Debido a que las tecnologías libres incentivan y motivan la investigación y el desarrollo, siempre trabajo con sistemas operativos y software libre.