Apache como proxy para Grafana

Casi siempre suelo configurar Apache o Nginx como proxys para otros servicios que ejecuto de forma local. Principalmente por dos razones:

  • Cuantas menos aplicaciones tengamos escuchando en una IP accesible desde el exterior mejor, ya que reducimos la superficie de ataques y vulnerabilidades.
  • Permite centrar la configuración de seguridad en un único punto, llamémosle Apache/Nginx o un F5 o balanceador que tengamos por delante. Además podemos complementar estos componentes frontales con soluciones que mejoren la seguridad, como por ejemplo mod_security para Apache.

Sigue leyendo

Uso de puertos privilegiados con usuarios no administradores en Linux

Con un usuario normal sin permisos de administración no puedes hacer uso de puertos por debajo del 1024 por motivos de seguridad. Estos puertos son utilizados por servicios conocidos como FTP, servidores web Apache o Nginx, DNS, etc… y requieren de root o usuario con permisos adecuados.

Podemos hacer una prueba sencilla con netcat (nc) intentando abrir un socket en un puerto por debajo del 1024 con un usuario no administrativo:

[jota@jota-pc ~]$ nc -v -l 90
nc: Permission denied

Ahora en un puerto no privilegiado no habrá problemas:

[jota@jota-pc ~]$ nc -v -l 9000
Listening on [0.0.0.0] (family 0, port 9000)

Tenemos distintas opciones para conseguir que un usuario normal pueda utilizar estos puertos.

Sigue leyendo

Monitorizando el sistema con Collectd+InfluxDB+Grafana (Debian)

Ya hace tiempo que lo tengo montado y tenía pendiente escribir el artículo a modo de wiki. Ya habíamos visto anteriormente cómo utilizar Grafana como capa de presentación con Glances e InfluxDB. Donde antes utilizaba Glances para recolectar métricas ahora tengo Collectd, utilidad más madura y con más opciones de configuración.

Los distintos componentes por tanto son:

  • Collectd como recolector de métricas de sistema.
  • InfluxDB será la Base de Datos para almacenar dichas métricas.
  • Grafana como capa de presentación (dashboard) de las métricas que se vayan almacenando en InfluxDB.

Sigue leyendo

Dockerizando Wildfly

Tenía pendiente desde hace un tiempo escribir sobre dockers y contenedores en general. Le ha llegado el turno a Wildfly, versión comunitaria de Jboss. Vamos a ver cómo crear una imagen personalizada, echarla a correr y mantener persistencia de datos del contenedor guardando los logs de la instancia en nuestro host.

Descarga de la imagen del docker Wildfly

Este paso es opcional ya que al construir nuestra imagen basada en el fichero Dockerfile se descargará la imagen base si no la tenemos en nuestro repositorio. Voy a descargar en concreto la versión 12.0.0.Final de la imagen oficial, por lo que utilizo el tag correspondiente:

sudo docker pull jboss/wildfly:12.0.0.Final

Ejemplo:

jota@mid-dockers:~/dockerfiles/wildfly-example-war$ sudo docker pull jboss/wildfly:12.0.0.Final
[sudo] password for jota: 
Using default tag: latest
latest: Pulling from jboss/wildfly:12.0.0.Final
469cfcc7a4b3: Pull complete 
05677e4d61f0: Pull complete 
a9520f492457: Pull complete 
4d201219d6b1: Pull complete 
01710aba802b: Pull complete 
Digest: sha256:01c15a87ea50a9e515af9b419491bd0f45e37fdedbd7bde33485d701a74783d2
Status: Downloaded newer image for jboss/wildfly:12.0.0.Final

Sigue leyendo

Simplificando los despliegues en Jboss con Ansible

Existen diversas maneras de organizar los despliegues en Jboss como habíamos visto: fabric, interactuando con la API REST o con scripts personalizados que nos montemos al uso. Ansible dispone de un módulo para Jboss que podemos añadir a la lista de métodos.

Su uso es muy sencillo, aunque la limitación que tiene al menos de momento es que no permite desplegar en dominios, por lo que sólo nos servirá para instancias standalone.

En el entorno dispongo de:

  • Nodo central (mi máquina) desde donde voy a lanzar el despliegue. Tengo una relación de confianza con clave pública con el nodo remoto para poder conectar por SSH sin contraseña.
  • Nodo remoto con IP 192.168.1.154 donde está la instancia de Jboss EAP 7.1 en la que se realizará el despliegue. Esta instancia se ejecuta con el usuario jota y tiene el deployment-scanner habilitado (necesario para que funcione el despliegue con Ansible)

Sigue leyendo

Cómo excluir reglas de fase 1 en mod_security

Existen diversas casuísticas en la exclusión de reglas de mod_security. Un procedimiento habitual suele ser limitar el ámbito de exclusión a un determinado contexto en el que por diversas razones estamos obteniendo falsos positivos de una serie de reglas problemáticas, ejemplo:

<Location /aplicacion>
    SecRuleRemoveById 920320 942200 942330 942430 980130
</Location>

Suponemos que dicha directiva excluiría las reglas 920320, 942200, 942330, 942430 y 980130 para el contexto /aplicacion. Pues bien, si estas reglas saltan en la fase 1 de procesado de mod_security la exclusión que pretendemos no va a funcionar, ya que dicha información de request aún no habrá llegado a Apache y por tanto no podrá aplicar la directiva Location para el contexto mencionado… ¡mod_security habrá bloqueado antes la request!

Sigue leyendo