Nginx

  • Las opciones de configuración con las cuales fue compilado un servidor Nginx quedan almacenadas en el propio binario.

  • El objetivo de utilizar un servidor Nginx como front-end a Grafana es implementar soporte para HTTP/S.

  • En este artículo voy a describir técnicas y herramientas para llevar a cabo un análisis forense de un archivo (o archivos) de log de un servidor Web Apache o Nginx.

  • Este artículo explica cómo implementar autenticación Basic con Nginx en Debian/Devuan o Ubuntu.

  • Este artículo explica cómo instalar logwatch en Debian y habilitar el resumen de logs de Nginx en la salida del mismo.

    Logwatch es una poderosa y versátil herramienta de análisis forense de logs de servicios (Web, correo, sistema, etc.) Está diseñado para elaborar un reporte unificado de toda la actividad en el servidor para un período determinado (típicamente el último día), el cual puede ser enviado por mail. De esta forma podemos recibir a diario, en nuestra casilla de correo electrónico, un resumen de la actividad sospechosa/anormal del día anterior.

  • Este artículo explica brevemente cómo compilar Nginx desde sus fuentes con soporte para SSL (HTTPS) en Debian y derivados.

  • Un certificado autofirmado puede ser útil para implementar SSL en entornos de desarrollo/testeo, o para el caso en que no se cuente con presupuesto suficiente para comprar uno firmado por una autoridad certificante de confianza (aunque algunas autoridades certificantes como namecheap ofrecen certificados económicos). Un certificado autofirmado no sirve para garantizar la identidad de un servidor, pero al menos provee un canal de comunicación seguro. Generar un certificado autofirmado también sirve para entender el proceso de creación y firma de un certificado y sus diferentes componentes.

  • Anteriormente demostré cómo forzar el uso de HTTPS (HTTP sobre SSL/TLS) en Apache. Esta vez voy a demostrar cómo implementarlo en un servidor Web Nginx.

  • Este artículo explica cómo generar un certificado SSL con certbot versión 0.10.02 (Debian 9.4) instalado de paquete. certbot es la herramienta provista por la EFF (Electronic Frontier Foundation) para generar certificados SSL gratuitos de Let's Encrypt.

  • Por culpa del referral spam, ya no es posible confiar en los datos relacionados a fuentes de tráfico provistos por Google Analytics. Al menos ya no es una fuente de datos confiable y precisa, pues nuestras cuentas de Analytics están plagadas de spam.

    Cabe recordar que el referral spam en cuentas de Google Analytics no afecta al sitio Web, es decir no se trata de tráfico hacia nuestro sitio, sino que es tráfico malicioso hacia los servidores de Google que recopilan datos para Analytics. Por ello, si necesitamos datos confiables acerca del tráfico efectivo hacia nuestro sitio Web, no queda otra alternativa que extraerlos desde los logs de acceso del servidor Web, ya sea Apache, Nginx u otro.

  • Anteriormente demostré cómo permitir y denegar el listado de directorios en un servidor Apache. Este artículo explica cómo permitir que Nginx muestre un listado de los archivos dentro de cierto directorio Web.

  • En este artículo voy a explicar cómo habilitar el soporte para el protocolo HTTP versión 2 en Nginx. HTTP/2 es la nueva versión del protocolo HTTP que utilizamos a diario para navegar páginas y sitios Web. Está basado en el protocolo experimental SPDY (desarrollado originalmente por Google) y se trata de la primera actualización mayor de la versión en casi dos décadas (HTTP/1.1 fue lanzado en 1999).

    Las meta de desarrollo de esta nueva versión fue reducir la latencia, para mejorar la velocidad de carga de páginas en los navegadores. Para ello, se agregó compresión en los headers HTTP (a fin de reducir el tamaño de los mismos); un mecanismo de push para que los servidores puedan enviar datos a los navegadores de manera asincrónica (sin necesidad de un request); pipeline de solicitudes (para mejorar el ancho de banda) y multiplexado de solicitudes a través de una misma conexión TCP (para reducir la sobrecarga del mismo); entre otros. A su vez, se agregó un mecanismo de negociación para que los clientes puedan escoger entre HTTP/1.1, HTTP/2 u otro.

    Todo esto, manteniendo compatibilidad con la versión 1.1. HTTP/2 mantiene la sintaxis de alto nivel de HTTP/1.1 casi intacta, al igual que los códigos de estado, cabeceras, etc. Lo que cambia (mejora) es la forma en que los datos e información son transferidos.

  • En estos últimos artículos expliqué cómo montar una caché local de paquetes implementada a través de un proxy con Nginx, tanto para Debian como para CentOS. Para mejorar el esquema se me ocurrió balancear la carga de red entre varios mirrors. De esta forma, nuestro proxy repartirá los accesos entre varios mirrors, en lugar de utilizar un único mirror.

    El balanceo de carga es un problema común en la actualidad, especialmente cuando se manejan cientos o miles de solicitudes/accesos desde varios clientes al mismo tiempo. Este artículo apunta a demostrar cómo es posible implementar un balanceador de carga de manera extremadamente simple utilizando los módulos de Nginx ngx_http_upstream_module y ngx_http_proxy_module.

  • Este artículo explica cómo implementar una lista negra de dominios, provenientes como referers en las cabeceras de las peticiones HTTP, para los cuales no se servirán imágenes y así evitar el maldito hotlinking.

    ¿Por qué usar una blacklist en vez de una lista blanca (es decir, permitir la carga de imágenes sólo desde nuestro dominio, Google, Facebook y algún otro más)? Ya lo expliqué anteriormente en el artículo Cómo prevenir el hotlink de imágenes (en esa oportunidad expliqué cómo implementarlo en Apache). En resumen, implementar una lista blanca puede perjudicar seriamente la experiencia de navegación de nuestros usuarios (sobre todo al momento de compartir nuestros artículos en redes sociales, utilizar lectores RSS, buscar imágenes , etc.)

  • A medida que pasa el tiempo, los archivos de log (registro de errores y eventos) aumentan su tamaño considerablemente, con lo cual es recomendable implementar su rotación. Esto es, cada cierto tiempo o tamaño de archivo, guardar una copia comprimida del log y comenzar con un archivo nuevo (vacío). Ya que los archivos de log utilizan el formato de texto plano (con excepciones ridículas como los logs de eventos de Windows y journald), éstos ocupan mucho espacio. Sin embargo el formato de texto plano se puede comprimir considerablemente (se logran grandes tasas de compresión). De esta forma se ahorra espacio en disco sin perder información. Y, como efecto secundario, se organizan mejor los datos presentes en los logs, pues quedan separados por rangos de fechas.

    Esta tarea se denomina rotación porque en general se guarda un número máximo de copias (no una sola copia) del archivo de log original. Una vez que se alcanza el número máximo de copias a guardar, en cada rotación se crea un nuevo archivo comprimido y se elimina el más antiguo. Efectivamente se están eliminando los datos más antiguos, aunque es la única solución posible para mantener el uso de disco acotado. Sin embargo es altamente probable que los archivos de log se hayan enviado ya a un sistema de backup (los logs deben ser una de las principales cosas a resguardar en una copia de seguridad después de los datos propiamente dichos).

  • Los recientes artículos dedicados a FreeBSD publicados en este blog, fueron una suerte de preámbulo para llegar al objetivo final: implementar una nube personal utilizando ownCloud sobre un servidor FreeBSD con las siguientes características: Nginx como servidor HTTP; PHP-FPM como servidor de aplicación (PHP en modo FastCGI); Postgres como motor de bases de datos; y ZFS como sistema de archivos. Una combinación muy ambiciosa que, a pesar de no estar soportada oficialmente por ownCloud, pretende utilizar la mejor alternativa disponible para implementar cada componente, con el fin de alcanzar la máxima eficiencia y rendimiento posible. En términos futboleros sería una especie de "selección", poner el mejor jugador disponible para cada posición: ownCloud+FreeBSD+Nginx+PHP-FPM+Postgres+ZFS.

  • Thinger.io es una infraestructura en la nube escalable que permite conectar millones de dispositivos conectados a Internet (Internet of Things). Esto permite controlarlos a través de una consola de administración simple de utilizar, o integrarlos en la lógica de nuestro negocio mediante una API REST.

    A su vez, Thinger.io es un proyecto open source que permite instalar el servidor en nuestra propia nube y utilizar las librerías (también open source) para conectar nuestros dispositivos. Thinger.io soporta todo tipo de dispositivos como Arduino, ESP8266, Raspberry Pi, Intel Edison y muchos otros.

    Veamos entonces cómo montar nuestro propio servidor Thinger.io en un servidor corriendo Debian Stretch (9).

  • En el artículo de ayer expliqué cómo implementar una lista negra de dominios para evitar el hotlinking. Pido disculpas por no explicar detalladamente de qué se trata esto del "hotlinking", pero no tengo ganas de explicarlo y existe una entrada en Wikipedia que lo explica claramente. Ya expuse mi opinión acerca de por qué no es conveniente utilizar una lista blanca. Pero para reforzar la idea, está el caso de las redes sociales descentralizadas (por ejemplo Diaspora*). Las redes sociales descentralizadas no poseen un único dominio, sino cientos (o miles). Esto hace que sea imposible determinar ni predecir desde qué dominios se hará hotlinking "válido". Válido porque no queremos impedir el hotlinking desde redes sociales, para lograr que nuestros artículos se vean de forma correcta (la imagen de nuestro sitio artículo que agregan las redes sociales al momento de compartir un link).

    Ahora bien, implementar una lista negra es simple, lo difícil es determinar quiénes son los ladrones que nos están robando (además de contenido) ancho de banda. Para ello, sólo se puede recurrir a los logs de acceso del servidor Web.

  • Finalmente Let's Encrypt ha entrado en su fase Beta de acceso público, por lo que ya no se necesita una invitación para obtener un certificado SSL de forma gratuita. Para aquellos desprevenidos, Let's Encrypt es una nueva autoridad certificante libre, abierta, automática y (lo mejor de todo) gratuita. Esperemos que este proyecto tenga éxito (seguramente lo tendrá pues está patrocinado por la Linux Foundation), y así se termine con el curro de los certificados. No puede ser que grandes empresas se hayan hecho millonarias simplemente emitiendo certificados SSL de confianza, cuando éstos deberían ser un recurso básico de acceso universal. HTTPS tiene que ser el estándar por defecto, y la seguridad tiene que ser un derecho de acceso público y gratuito para todos los sitios de Internet. De otra forma, al tener que pagar para acceder a la seguridad (como sucede actualmente), nunca llegaremos a una Internet segura y confiable.

    En este artículo voy a explicar cómo obtener e instalar un certificado gratuito de Let's Encrypt, sobre un servidor Debian con Nginx.

  • En este artículo voy a demostrar cómo es posible pasar variables de entorno desde Nginx a PHP5-FPM para que estén accesibles en el arreglo $_SERVER de PHP.