H3R3T1C Blog

Disminuyendo tamaño de HDD virtual de un LXC en Proxmox

Sat, 26 Jan 2019 00:00:00 +0000

Introducción

Proxmox es la plataforma de virtualización (basada en Debian) que utilizo (hasta dentro de poco, pues me mudo a Docker Swarm ;)). En un momento determinado tuve la necesidad de mover uno de los HDD virtuales de uno de mis contenedores LXC para otro espacio de almacenamiento más reducido. El HDD virtual estaba definido con un tamaño mayor al que a donde se migraría dicho HDD. Al revisar internamente el espacio ocupado de dicho HDD, era mucho menor al definido, por lo que la solución sería disminuir el HDD virtual para que pudiera ser migrado.

Reducción del HDD

Importante aclarar que los pasos siguientes son para cuando el formato del sistema de ficheros es ext2, ext3 o ext4.

Al utilizar la propia herramienta de Proxmox para ello, en la documentación define que se utiliza solamente para el aumento del tamaño, por lo que la solución fue utilizar los comandos base para dicha tarea:

Apagamos el contenedor que queremos migrar.
Accedemos por la terminal al nodo Proxmox donde se encuentra el contenedor.
- Obtenemos el HDD que queremos disminuir con:
```
$ df -h
```
Comprobamos el HDD virtual para verificar que no contenga errores:
```
  e2fsck -fy <HDD-VIRTUAL>
```
Reducimos el sistema de ficheros en sí:
```
  resize2fs <HDD-VIRTUAL> <Tamaño final - 1><Unidad>
```
Explicando un poco, cuando se reduce (o amplía) un sistema de ficheros, en realidad son varios los pasos a realizar. Primero se debe reducir el sistema de ficheros, para que la información que se encuentra esparcida por el HDD se quede en los ámbitos del nuevo espacio definido para que luego cuando se disminuya el espacio de la partición, no exista pérdida de datos. En cuanto a la expresión <Tamaño final - 1> es debido a que como se utilizan programas distintos para el cambio de tamaño del sistema de ficheros y la partición, éstos pueden tener distintas definiciones internas de la unidad de medida y por tanto se deja un espacio de seguridad. En cuanto a la expresión <Unidad> se refiere a la unidad de medida del nuevo espacio:
- M Megabyte
- G Gigabyte
- T Terabyte
- etc.

Reducimos la partición LVM:

lvreduce -L <Tamaño final><Unidad> <HDD-VIRTUAL>

Ahora aumentamos el sistema de archivos automáticamente hasta el tamaño final de la partición.
```
resize2fs <HDD-VIRTUAL>
```
Cambiamos manualmente la definición de la máquina virtual para que refleje el nuevo tamaño del HDD virtual
```
nano /etc/pve/lxc/<id>.conf
```
Una línea que contiene
```
rootfs: <id del hdd>,size=<tamaño>
```
En tamaño ponemos la misma definición que establecimos anteriormente en el comando lvreduce.

Monitorizando las máquinas virtuales de proxmox con Prometheus

Sun, 20 Jan 2019 00:00:00 +0000

Introducción

Muchos contamos con una infraestructura soportada sobre la plataforma de Proxmox y una de las necesidades que debemos tener es medir, métricamente, los diferentes aspectos de cada una de sus máquinas virtuales, ya sea LXC o KVM.

Algunos enfoques definen que se debe tener un programa colector en cada máquina virtual, pero el enfoque que traigo actualmente es el de usar un colector por nodo físico que hace uso del API de Proxmox para pedir las métricas de los nodos virtuales. En el caso de que sea un clúster, solo se necesita en un nodo, puesto que el API de Proxmox te da la información de todos los miembros del clúster.

Instalando el exporter

Podemos encontrar el exporter en

Servidor de métricas Prometheus y aplicación práctica con Node-Exporter y Grafana

Sat, 19 Jan 2019 00:00:00 +0000

Introducción

Prometheus es un sistema de monitoreo que a diferencia de sus homólogos utiliza un enfoque diferente, en lugar de que los servicios que lo soporten o los programas que obtienen las métricas se las envíen a Prometheus, éste es quien se conecta a ellos cada cierto tiempo y recopila toda la información. Las ventajas y desventajas de esta manera de trabajar pueden profundizarla más en el sitio oficial o en su blog. Está programado en Go, por lo que su instalación es sumamente sencilla y no tiene dependencia alguna, es un simple ejecutable.

Vamos a ver un ejemplo de aplicación con Node-Exporter y Grafana para levantar una mínima infraestructura de monitoreo en nuestra red.

Instalación genérica

Como comentaba anteriormente, debido a su lenguaje de programación, es simplemente ir a la página de GitHub y descargar la versión estable para el sistema operativo que querramos (incluido windows ;) ). Una vez descomprimido, es simplemente ejecutarlo como un programa más, queda fuera del ámbito del manual la creación de un servicio que lo use.

Alguno de sus argumentos básicos son:

--config.file Ubicación del fichero de configuración en YML. Por defecto es /etc/prometheus/prometheus.yml.
--web.listen-address Dirección por donde escuchará la UI, el API y la telemetría. Por defecto es 0.0.0.0:9090.
--storage.tsdb.retention Tiempo de retención de los datos de las métricas (Prometheus no está pensado para guardar un histórico largo de datos, para ello hay soluciones que se integran a Prometheus). Por defecto es 15d.
--log.level Nivel de bitácora. Por defecto es info.

Instalando en Debian

En el repositorio de Debian se encuentran los paquetes referentes a Prometheus. En mi caso uso siempre en mis servidores la versión estable de éste (que en el momento de escribir es stretch). La versión que se encuentra en los repositorios estables es la 1.x, pero Prometheus ha cambiado su modelo de almacenamiento completamente en la versión 2.x, por lo que haría incompatible los 2 modelos. En este caso tendremos que utilizar el repositorio back-ports de Debian, que no es más que ciertos programas que han sido portados para la versión estable de Debian.

Primero configuramos el repositorio para agregar al sources.list la nueva fuente:

 $ echo "deb http://ftp.debian.org/debian stable-backports main" >> /etc/apt/sources.list

Luego actualizamos los índices

 $ apt update

Y ahora instalamos Prometheus, indicando que queremos la de back-ports

 $ apt install prometheus/stable-backports
 ó
 $ apt -t stable-backports install prometheus

Ejecutando desde Docker

Como siempre ejecutarlo desde Docker es más fácil, la imagen oficial de Prometheus la podemos encontrar tanto en Quay.io como en Docker Hub:

Quay.io

$ docker run --name prometheus -d -p 9090:9090 quay.io/prometheus/prometheus

Docker Hub

$ docker run --name prometheus -d -p 9090:9090 prom/prometheus

Opciones

--name Le asignamos el nombre prometheus a esa instancia, de manera que es más fácil encontrarla, por ejemplo, con un docker ps
-d Le decimos a Docker que lo inicie en modo demonio, de esta manera se devuelve el control a la terminal y la instancia se queda ejecutándose en el fondo.
-p Definimos que exporte el puerto 9090 de la instancia, hacia el 9090 de nuestra PC (o servidor) en http://localhost:9090.

Verificando instalación

Ahora podremos acceder por HTTP hacia el servidor Prometheus usando un navegador. En esa interfaz podremos hacer consultas para probar las gráficas y los datos, así como ver el estado de los servicios a los cuales Prometheus se conecta para obtener la información de las métricas.

Página de consultas

Página de chequeo de los clientes

Breves sobre la Configuración

El fichero de configuración de Prometheus por lo general se encuentra en /etc/prometheus/prometheus.yml y se explica por sí solo. Algunas precisiones:

scrape_interval Es el intervalo en que consulta cada servicio para obtener las métricas.
evaluation_interval Es el intervalo en que evalúa las reglas de alerta (no tratadas en el presente post).
scrape_configs Es donde va la configuración de los servicios a consultar:

Partiendo un ejemplo simple, funcional y que se explica por si solo, es simplemente ubicarlo dentro de scrape_configs:

 - job_name: 'squid'
    static_configs:
      - targets:
        - 192.168.0.128:9399
    metrics_path: /metrics

PromQL

Para terminar hablo sobre PromQL que es el lenguaje de consultas a Prometheus. Permite seleccionar y realizar operaciones sobre las series de tiempo. Puedes conocer más sobre el lenguaje en su sitio oficial. Solo mostraré algunos ejemplos rápidos (tomados de su sitio oficial):

Operaciones simples

Retornar todas las series de tiempo de la métrica http_requests_total:

 http_requests_total

Retornar todas las series de tiempo de la métrica http_requests_total, pero especificando algunas etiquetas:

 http_requests_total{job="apiserver", handler="/api/comments"}

De la anterior, retornar solamente un rango de tiempo (en este caso 5 min):

 http_requests_total{job="apiserver", handler="/api/comments"}[5m]

La búsqueda en las etiquetas se puede hacer por expresiones regulares, como subcadenas a buscar, por ejemplo, para sacar todos los datos referentes a la métrica donde el job termine en server:

 http_requests_total{job=~".*server"}

Todas las expresiones regulares en Prometheus utilizan la sintaxis R2.

Por ejemplo para excluir utilizando las etiquetas, seleccionando todo menos los que tengas status diferente a 4xx:

 http_requests_total{status!~"4.."}

Usando funciones y operadores

Retornar el ritmo(rate) de la métrica http_requests_total durante 5 min:

 rate(http_requests_total[5m])

Ahora, suponiendo que tenemos una etiqueta que define el job podemos sumar todos los rate y agruparlos por el job:

 sum(rate(http_requests_total[5m])) by (job)

Si tenemos métricas que tienen la misma definición de etiquetas podremos realizar cálculos matemáticos con ellas, por ejemplo, para calcular la memoria sin usar en MBytes por una instancia de un nodo ficticio que tendría las métricas instance_memory_limit_bytes y instance_memory_usage_bytes:

 (instance_memory_limit_bytes - instance_memory_usage_bytes) / 1024 / 1024

Lo mismo que lo anterior pero ahora sumado por aplicación y proceso:

 sum(
  instance_memory_limit_bytes - instance_memory_usage_bytes
 ) by (app, proc) / 1024 / 1024

Node-Exporter

Es un exporter de Prometheus (así son llamados los programas encargados de obtener las métricas y brindarlas en un formato que Prometheus pueda obtener, algunos programas ya la traen incluidas, en otros casos se debe usar uno externo). Con Node-Exporter, Prometheus puede consumir, entre muchas otras, las siguientes métricas:

arp Expone las estadísticas ARP de /proc/net/arp.
cpu
diskstats Expone las métricas de I/O de los discos.
entropy Expone la entropía disponible (muy importante para la criptografía).
filesystem Expone las estadísticas de los sistemas de ficheros, como el espacio en disco usado, etc.
hwmon Expone los sensores de hardware de /sys/class/hwmon/
loadavg Expone el promedio de carga del nodo.
meminfo Expone las estadísticas de la RAM.
netclass Expone la información de las interfaces de red de /sys/class/net/
netdev Más estadísticas de red, como los bytes transferidos, etc.
Entre muchas otras …

Instalación genérica

Podemos seguir el mismo procedimiento de Prometheus, pero buscando la versión estable aquí.

Instalación en Debian

Debian en su repositorio cuenta con el Node-Exporter, el paquete se llama prometheus-node-exporter, por lo que con apt:

$ apt install prometheus-node-exporter

En caso de que se quiera usar en la versión estable de Debian, hay que activar el repositorio de backports como mismo se realizó en la instalación de Prometheus.

Ejecutando desde Docker

Podemos usar la imagen de Quay.io:

docker run -d \
  --net="host" \
  --pid="host" \
  -v "/:/host:ro,rslave" \
  quay.io/prometheus/node-exporter \
  --path.rootfs /host

Lo más relevante es que del host se expone la raíz, para que Node-Exporter pueda obtener las métricas y usa la propia interfaz de red del nodo, para evitar medir solo la interfaz virtual.

Para más información ir a su sitio

Configurando Prometheus

Node-Exporter por defecto usa el puerto 9100 y /metrics para exportar las métricas, por lo que vamos a la configuración de prometheus /etc/prometheus/prometheus.yml y agregamos el (o los) nodo(s) que exponen sus métricas por debajo de scrape_configs:

- job_name: 'node_exporter'
static_configs:
  - targets:
    - ip_node_1:9100
    - ip_node_2:9100
    - ip_node_3:9100
    - ip_node_4:9100
metrics_path: /metrics

En mi caso lo tengo instalado en cada servidor Proxmox.

Grafana

Ahora toca visualizar todo. Uso Grafana por sus potencialidades y se ha convertido en la plataforma de visualización de facto en mi entorno, acá les dejo un dashboard específico para Node-Exporter, con una foto para que vean como queda:

Montando_infraestructura_swarm_rancheros

Wed, 15 Aug 2018 00:00:00 +0000

layout: post title: Montando una infraestuctura Docker Swarm por PXE tags: [docker, swarm, cluster, rancheros, pxe] summary: Explico como monté mi infraestructura con Swarm y arranuqe por PXE. —1

Montando devdocs.io en nuestra red (Docker incluido)

Wed, 15 Aug 2018 00:00:00 +0000

Introducción

Cuando vamos a programar un script o algo más grande, necesitamos documentarnos acerca de las bondades que nos ofrece el lenguaje que escogimos para dicha tarea, devdocs.io es un sitio que reune mucha documentación sobre disímiles tecnologías, agrupadas a veces por versiones. Es una muy buena recopilación, que permite incluso descargarla offline para el almacenamiento del navegador, para que, una vez estemos offline poder consultarla.

Lo bueno de este proyecto es que es libre, es decir, que podemos encontrar su código fuente en GitHub. De eso se trataremos, de cómo instalar en nuestra red local este servicio, incluyendo al final como hacerlo si prefieres Docker.

Instalando en Debian

Una vez bajado el proyecto

# apt install git
# git clone https://github.com/freeCodeCamp/devdocs.git
# cd devdocs

Lo primero que debemos hacer es instalar ruby y bundle para gestionar las dependencias del proyecto:

# apt install ruby bundle

Ahora procedemos a instalar algunos paquetes adicionales, para que cuando usemos bundle, que compile nativamente algunas dependencias, no de errores.

# apt install build-essential ruby-dev zlib1g-dev nodejs ruby-thor

Ahora obtenemos todas las dependencias necesarias para que funcione el proyecto

# bundle install

Ya tenemos la base del proyecto, pero no tenemos ninguna documentación descargada, para eso usaremos thor

# thor docs:download --all

Ya el proyecto está listo para ser ejecutado y empezar a brindar el servicio, el comando para arrancar el servidor es

# rackup -o 0.0.0.0 -p 80 -D

donde -o indica por que IP escuchará el servidor, definiendo el puerto con -p. El -D indica que se ejecute como un demonio.

Como generalmente pondermos esto en un servidor aparte (preferiblemente un contenedor), pudieramos modificar directamente /etc/rc.local para que ejecutara el comando, ejemplo de este fichero sería

#!/bin/bash

cd /opt/devdocs
rackup -o 0.0.0.0 -p 80 -D
cd -

exit 0

Con esto cada vez que se ejecute nuestro servidor, tendremos el servicio de devdocs.io corriendo.

Instalando con Docker

Si eres como yo, que ahora todo lo quiero dockerizar, puesto que he visto muchas ventajas en una infraestructura de contenedores con Docker, devdocs te brinda su Dockerfile para que lo construyas, los pasos son meramente sencillos

Instalamos Docker, en los repos de Debian y Ubuntu viene el paquete, en caso de que no uses ninguno de estos, remitete a su documentación para la instalación.

# apt install docker.io

Teniendo Docker instalado, procedemos a descargar devdocs de su repositorio y construirlo

# apt install git
# git clone https://github.com/freeCodeCamp/devdocs.git
# cd devdocs

# docker build -t thibaut/devdocs .

Esperamos que se construya la imágen, de alguna manera hace todo lo que hicimos en el apartado anterior, pero automatizado. Una vez que se haya construido la imagen, solo tenemos que ejecutarlo

# docker run --name devdocs --restart always -d -p 9292:9292 thibaut/devdocs

Explicando un poco, sería que corriera un contenedor nombrado con --name, que se iniciara automáticamente (por --restart always), que corra como un demonio (-d) y que el puerto con que se publicará será el 9292 (por la primera parte del par 9292:9292, la segunda parte es del servicio interno).

WireGuard, un ejemplo práctico

Thu, 24 May 2018 00:00:00 +0000

Introducción

En un artículo anterior comentaba sobre las bondades de WireGuard, así como su instalación y configuración básica. Algunos pudieran ver ese artículo y preguntarse sobre cómo usarlo realmente, no solo basta con saber el cómo, también necesitamos ver el dónde.

En este caso explicaré un ejemplo práctico para implementar WireGuard en su red. A grandes rasgos utilizaríamos a WireGuard para proteger todas las comunicaciones entre los clientes (usuarios de la red) y los servidores; además de una instancia adicional de WireGuard que le permitirá al encargado de Seguridad Informática acceder a los sistemas de monitoreo por el mismo canal de los usuarios normales, sin comprometer la seguridad de dichos servicios. Quedaría algo así:

Como podemos apreciar en la imagen anterior, tendríamos un firewall entre los usuarios de la red y los servidores. Dicho firewall brindaría los servicios de WireGuard a los usuarios, los cuales están conectados por el canal físico hacia éste. Al WireGuard crear interfaces virtuales TUN, el firewall solo permitiría la comunicación hacia los servicios a través de estas interfaces virtuales nuevas (las creadas por WireGuard), denegando toda comunicación restante. De esta manera todo dispositivo que no se encuentre como cliente del WireGuard no podrá consumir de los servicios, ni podrá ver la comunicación, debido a la encriptación brindada por WireGuard.

Si se fijan, se evidencia el ejemplo de la utilización de otro canal de WireGuard específico para los especialistas de Seguridad Informática.

Manos a la obra

Primero debemos en nuestro firewall levantar los dos servidores de WireGuard (asumo que hayan leído el artículo anterior), uno para los usuarios normales y otro para el encargado de la Seguridad Informática.

# Generando las llaves privadas de los servidores

$ wg genkey
YMbajbQrpvYHgFaMgUSYuwMBa9wnLa4JKG+lWMwrmGY=

$ wg genkey
kHv5yTgIvGzrbwf/VydqDHvEH4//88D/TDF/8i8gxF4=

Luego crearíamos con algun editor de texto los ficheros /etc/wireguard/empresa.conf y /etc/wireguard/si.conf y copiaremos la siguiente configuración:

# empresa.conf
# Definición de la Interfaz
[Interface]

# Establecer el IP de la interfaz con la máscara de red
Address = 172.16.0.1/24

# Puerto UDP de escucha del servidor
ListenPort = 51820

# Llave privada generada anteriormente
PrivateKey = YMbajbQrpvYHgFaMgUSYuwMBa9wnLa4JKG+lWMwrmGY=

# Indica que cada configuración establecida a través de la interfaz de
# WireGuard sea salvada en el fichero una vez detenido el servidor
SaveConfig = false

# si.conf
# Definición de la Interfaz
[Interface]

# Establecer el IP de la interfaz con la máscara de red
Address = 172.16.1.1/24

# Puerto UDP de escucha del servidor
ListenPort = 51821

# Llave privada generada anteriormente
PrivateKey = kHv5yTgIvGzrbwf/VydqDHvEH4//88D/TDF/8i8gxF4=

# Indica que cada configuración establecida a través de la interfaz de
# WireGuard sea salvada en el fichero una vez detenido el servidor
SaveConfig = false

Ahora que tenemos las configuraciones solo falta habilitar y arrancar los servidores de WireGuard (para eso utilizaremos la ayuda de systemd y wg-quick):

# empresa.conf
$ systemctl enable wg-quick@empresa
$ systemctl start wg-quick@empresa

# si.conf
$ systemctl enable wg-quick@si
$ systemctl start wg-quick@si

Podemos asegurarnos de que todo está correcto verificando que se hayan creado 2 interfaces nuevas con el nombre del fichero de configuración, ejemplo:

$ ip a
...
5: empresa: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none
    inet 172.16.0.1/24 scope global empresa
       valid_lft forever preferred_lft forever
6: si: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1340 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none
    inet 172.16.1.1/24 scope global si
       valid_lft forever preferred_lft forever
...

Ya con esto tenemos los servidores de WireGuard listos, solo falta agregar los clientes.

Agregando clientes

Cada cliente que se requiera conectar al servidor tiene que tener su entrada correspondiente en el fichero de configuración de dicho servidor WireGuard; para ello se necesita un par de llaves pública y privada, donde la privada la tiene el cliente y el servidor solo necesita definir la pública dentro de su configuración. En este caso existen 2 variantes:

Generar el par de llaves en cada cliente y copiar la pública en el servidor.
Generar el par de llaves de cada cliente en el propio servidor.

La diferencia entre ellas es el nivel de seguridad (y paranoia) que queremos, puesto que lo más seguro es generarlo en cada cliente por separado para aumentar el principio de incertidumbre en la generación de comportamientos aleatorios de la generación de las llaves. Pero es mucho más cómodo realizarlo en el propio servidor, por lo que es a gusto del lector como lo desea hacer.

En Debian

# Se genera la privada
$ wg genkey
YKB7m15Art0Y9jcAYr/9DX6mr6cr28uUzABI7Q1TwH0=

# Se genera la pública a partir de la privada
$ echo -n "YKB7m15Art0Y9jcAYr/9DX6mr6cr28uUzABI7Q1TwH0=" | wg pubkey

En Windows

Utilizando el cliente TunSafe

Una vez que se tenga el par de llaves, se toma la pública y agregamos el siguiente fragmento a la configuración correspondiente, por ejemplo en /etc/wireguard/empresa.conf:

# empresa.conf
# Por cada cliente se establece una sección como esta
[Peer]

# Llave pública del cliente
PublicKey = JP55vfgoBIRbXuasBD0Gn5L6mb8KsVwdZiOfdi/cfCs=

# IPs (con máscara) que puede tener el cliente que se conecte con esta llave,
# pudiera usarse por ejemplo para un cliente que se conecte por 2 VPN
AllowedIPs = 172.16.0.2/32

Una vez agregados los clientes, procedemos y reiniciamos el servidor correspondiente:

$ systemctl restart wg-quick@empresa

WireGuard soporta la configuración directa en cuanto está levantado el servidor, incluso agregar nuevos clientes y que se escriba en el fichero de configuración una vez terminado el proceso, éste método no lo explico por ser un poco más complicado; además en mi opinión le veo un defecto y es que si tenemos un reinicio inesperado, toda la configuración “en caliente” que hayamos hecho se habrá perdido.

Configurando los clientes

Debian

Para configurar el cliente en Debian el procedimiento es parecido al servidor (explicado igualmente en el artículo anterior sobre WireGuard), solo basta con agregar un fichero de configuración en /etc/wireguard/empresa.conf con el siguiente contenido:

# Definición de la Interfaz
[Interface]

# IP del cliente que tiene que coincidir con el permitido en el servidor
# para este cliente
Address = 172.16.0.2/32

# Llave privada generada
PrivateKey = YKB7m15Art0Y9jcAYr/9DX6mr6cr28uUzABI7Q1TwH0=

# Si queremos establecer un DNS
DNS = 172.16.0.1

# Definición del servidor al cual conectarse
[Peer]

# Se define la llave pública de dicho servidor
PublicKey = YMbajbQrpvYHgFaMgUSYuwMBa9wnLa4JKG+lWMwrmGY=

# En este apartado se define los IPs que enrutarán por esta interfaz,
# como se puede ver en este caso son todas, es decir, sería la puerta
# de enlace por defecto, todas las conecciones externas se enrutan hacia
# el servidor de WireGuard
AllowedIPs = 0.0.0.0/0

# Dirección del servidor de WireGuard
Endpoint = 10.0.0.1:51820

# Esto define un intervalo en segundos que WireGuard envía un paquete
# nulo para "mantener viva" la conección. Esto es útil en casos de NAT
# para que el firewall mantenga el mismo IP asociado a la conección.
# Comento por defecto debido a que en nuestro caso no es NAT
# PersistentKeepalive = 25

Arrancamos el cliente de la misma manera que el servidor:

$ systemctl enable wg-quick@empresa
$ systemctl start wg-quick@empresa

Windows

En este caso utilizaremos el cliente TurnSafe

Se abre el editor por defecto para configurar el cliente (o servidor) de WireGuard

Como pueden observar la configuración es idéntica a la de Debian.

Solo queda por último las reglas de firewall para el correcto enrutado de los paquetes que vienen solo por las interfaces virtuales, pero este proceso queda fuera del ejemplo debido a la gran variedad de vías por la cual hacerlo.

Usando el cliente de OpenVPN a través de un proxy

Wed, 25 Apr 2018 00:00:00 +0000

Disclaimer: Solo para uso educacional, no me hago responsable por el uso que se le de al presente manual.

Introducción

En esta ocasión no explicaré como se instala, configura y despliega un servidor de OpenVPN, pues eso es para otro post, o de alguien más. En este caso mostraré como usar el cliente de OpenVPN cuando nos encontramos detrás de un proxy (la mayoría de los sysadmin que conozco).

A veces como sysadmin nos encontramos con la necesidad de acceder a un servicio, por ejemplo el de actualizar las llaves públicas de nuestro sistema con GPG, que necesita hacer uso de algunos puertos bloqueados por nuestro proxy (varios en muchos casos) padre; o que tengamos que clonar un repositorio GIT con el último parche de algun servicio crítico de nuestra red (y los desarrolladores solo lo brinden por protocolo GIT, no HTTP o HTTPs). Son muchos los casos en que por la propia seguridad y actualización de sistemas debemos acceder por puertos diferentes al 80 o 443 y aquí es donde nos enfrentamos a los proxy padre muy restrictivos.

Me centraré en el cliente para Debian, pues es la distribución de Linux que utilizo; pero para los demás sistemas operativos es análogo, pues el fichero de configuración es común.

Diferencia entre proxy HTTP y SOCKS

Seguro han visto esta diferenciación en alguna que otra configuración de los programas a la hora de definir el proxy, pues estos 2 tipos de proxy son muy diferentes:

Proxy HTTP

Este tipo como su nombre lo indica, es pensado para la navegación web, pues en realidad lo que se hace es enviar la solicitud de la página a navegar (o acceder) al servidor proxy y éste es quien realiza la petición, cacheando o no la respuesta, para luego retornarla al cliente.

Proxy SOCKS

Este tipo de proxy es más directo, en el sentido que, como su nombre lo indica, conecta directamente el cliente con el servidor, sirviendo simplemente de pasarela, es ampliamente utilizado para simular una conección directa. Por ejemplo, la aplicación TOR es un proxy SOCKS.

Este es de los proxy que menos se instalan en la infraestructura, puesto que el otro tipo (HTTP) es más enfocado a la navegación.

Caso HTTPS

En el caso del protocolo HTTPS (generalmente puerto TCP 443), un proxy SOCKS no tiene problemas, puesto que comunica directamente los dos nodos (como se definía anteriormente); pero un proxy HTTP, al hacer de puente, no pudiera en teoría funcionar, puesto que tendría que recibir las peticiones para poder resolverlas, caso en que el HTTPS por ser un protocolo cifrado entre el servidor remoto y el cliente no lo permitiría sin un ataque de MITM.

Para este caso los proxy HTTP (y los navegadores o programas clientes) utilizan un método llamado CONNECT que no es más que pedirle una comunicación directa (tipo SOCKS) entre los 2 nodos. Una vez establecida la comunicación, es un enlace directo entre el cliente y el servidor, por lo que todo lo que se transmite entre los extremos es cifrado y ajeno al proxy.

Manos a la obra

Para que OpenVPN se pueda comunicar a través de un proxy HTTP, éste debe permitir el método CONNECT, por lo que debemos tener un servidor remoto que esté escuchando por un puerto por el cuál el proxy permita la comunicación directa (como el TCP 443).

Hay muchos sitios en Internet que muestran listas de servidores de OpenVPN libres, como

solo bastaría descargar su fichero de configuración y debajo de remote vpn_hostname 443 tcp adicionarle:

http-proxy 1.2.3.4 8080
http-proxy-retry

en caso de necesidad de autenticación:

http-proxy 1.2.3.4 8080 auto
<http-proxy-user-pass>
username
password
</http-proxy-user-pass>
http-proxy-retry

De esta manera solo quedaría ejecutar nuestro cliente OpenVPN con la configuración

$ openvpn config.ovpn

Asegurando nuestras comunicaciones con WireGuard

Sat, 21 Apr 2018 00:00:00 +0000

Introducción

En muchos casos como SysAdmins debemos o queremos mantener comunicación con algún servidor desde un punto donde el canal de comunicación puede ser revisado (con sniffers) por otras personas o sistemas. Algunos ejemplos serían:

Administrar nuestros servidores desde Internet.
Darle acceso a usuarios a servicios sobre un canal inseguro.
Brindar seguridad ante sniffer en un canal independientemente de la seguridad de los servicios que brinde.
Queremos darle acceso a algún servicio de monitoreo al encargado de Seguridad que se encuentra fuera de la red de administración.
Entre otros…

Una de las soluciones que se presenta para este tipo de problema son las VPN (Virtual Private Network), que permiten crear una red dentro de otra y generalmente cifrada, por lo que los datos que se transmiten se ocultan a los ojos de los interesados, no importa que sean a servicios no seguros, pues se comunican a través del túnel creado por este servicio.

En la actualidad hay 2 herramientas que son ampliamente para este menester:

IPSec
OpenVPN

Ambos son muy buenos en esa tarea y gozan de un gran soporte por todos los equipamientos de red (IPSec más al ser el estándar de facto en muchos routers, como los de CISCO o HUAWEI). El problema a veces con éstos es que su instalación, configuración y puesta en marcha puede resultar un poco tediosa.

Hoy vengo con una propuesta que está ganando mucho terreno a pesar de ser un producto en desarrollo, pero que muchos le han puesto el ojo, es WireGuard y supone una ventaja con respecto a los anteriores por:

Extremadamente fácil en su instalación y despliegue, ellos indican que “(…) aims to be easy to configure and deploy as SSH (…)”.
Usan criptografía state-of-the-art que no es más que la utilización de los algoritmos más modernos de éstos menesteres.
Al igual que IPSec es compilado como módulo del kernel a través de DKMS. Lo que logra un rendimiento mucho mayor que OpenVPN (pues este es user-space).
Usa los algoritmos de cifrado Noise Protocol Framework, Curve25519, ChaCha20, Poly1305, BLAKE2, SipHash24, HKDF.
Se ha implementado teniendo en cuenta menor cantidad de código, lo que permite una mejor auditoría de código y una menor área de ataque. Está pensado para que una persona pueda auditar todo el código sin complicaciones.
Entre otras ….

WireGuard por ahora no soporta la asignación dinámica de IP, por lo que cada cliente que tengamos se le debe establecer el ip en su configuración. Además que WireGuard no permite la comunicación de un cliente que no tenga el IP especificado en su fichero de configuración.

Algunas gráficas sobre el rendimiento de WireGuard con respecto a IPSec y OpenVPN pueden verse en Performance of WireGuard

Instalación

Me voy a centrar en la instalación sobre Debian, pues es lo que uso en mis servidores gg. Debido a que WireGuard es un proyecto en desarrollo, encontrarás los paquetes de su instalación en el repositorio de sid que es el repositorio “intestable”:

Luego de haber bajado los paquetes .deb solo debemos instalarlos, además de los headers del kernel para la compilación de los módulos del kernel, por ej:

# apt install dkms
# dpkg -i wireguard-dkms.deb wireguard-tools.deb

Luego de haberse instalado, el módulo se compila y se integra al kernel actual. Ahora sólo basta configurarlo e iniciar el servidor.

Configuración y despliegue

Hay 2 vías por donde configurar WireGuard, una manual y otra a través de ficheros de configuración que utilizaría la utilidad wg-quick para levantarla. La última es la que utilizaré en este manual por ser la más rápida y cómoda.

Lo primero que debemos hacer es generar una llave privada del servidor

# wg genkey
iBAnhqypjo6detnodQiHUEL/Wzg/OO5e4IXef6TOnGw=

Esa sería la llave privada del servidor, una duda que me surgió en su momento fue acerca del por qué una llave privada tan pequeña con respecto a las que utilizaba en OpenVPN y en las investigaciones y correos de la lista, esto es debido a que los algoritmos de cifrado que utilizan que es ECC (Elliptic Curve Cryptography) utilizan menos bits para llegar a la misma complejidad criptográfica que RSA a un nivel superior de bits. Una tabla descriptiva sería:

En WireGuard no se define el tamaño de la llave, puesto que WireGuard define ese tamaño para evitar una mala configuración por parte del usuario. WireGuard se asegura que el tamaño de la llave sea lo suficientemente segura para evitar un ataque en intento de descifrar la llave privada desde la pública.

Los ficheros de configuración residen en /etc/wireguard/ por lo que crearemos nuestro fichero de configuración con el nombre de la interfaz virtual que queremos que tenga, en nuestro ejemplo será empresa.conf

# Definición de la Interfaz
[Interface]

# Establecer el IP de la interfaz con la máscara de red
Address = 172.16.0.1/24

# Puerto UDP de escucha del servidor
ListenPort = 51820

# Llave privada generada anteriormente
PrivateKey = iBAnhqypjo6detnodQiHUEL/Wzg/OO5e4IXef6TOnGw=

# Indica que cada configuración establecida a través de la interfaz de
# WireGuard sea salvada en el fichero una vez detenido el servidor
SaveConfig = false


# Por cada cliente se establece una sección como esta
[Peer]

# Llave pública del cliente
PublicKey = R2G89C5dpuEOrU9IEzVuuoP3liQzsdnsUyY+cQ+IZQQ=

# IPs (con máscara) que puede tener el cliente que se conecte con esta llave,
# pudiera usarse por ejemplo para un cliente que se conecte por 2 VPN
AllowedIPs = 172.16.0.2/32

Ahora apoyándonos en systemd y wg-quick podemos habilitar el servidor e iniciarlo:

# systemctl enable wg-quick@empresa
# systemctl start wg-quick@empresa

Podemos ver que se ha creado la interfaz con:

# ip a
...
12: empresa: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none
    inet 10.11.2.1/24 scope global empresa
       valid_lft forever preferred_lft forever
...

O mejor aun para ver todas las interfaces de WireGuard con sus clientes:

# wg
interface: empresa
  public key: teRk63YIGMHoaDCxS6xxwRd91oek2e378a+X6zunTy8=
  private key: (hidden)
  listening port: 51820

peer: R2G89C5dpuEOrU9IEzVuuoP3liQzsdnsUyY+cQ+IZQQ=
  allowed ips: 172.16.0.2/32

Ahora vamos a configurar a un cliente. Importante decir que WireGuard por ahora no tiene soporte en algo que no sea Linux (la implementación oficial) o Windows (por un port en user-space). Esto es debido a que para otras plataformas habría que implementar el driver en el kernel-space por el rendimiento superior, ver más.

Para configurar un cliente en Debian, instalamos los mismos paquetes y creamos un fichero de configuración en el mismo lugar:

# Definición de la Interfaz
[Interface]

# IP de cliente que tiene que coincidir con el permitido en el servidor
Address = 172.16.0.2/32

# Llave privada generada al igual que la del servidor con 'wg genkey'
PrivateKey = 2EHAW9zRKq8OH9Nq7ljF+QiIXPF3WlIs4mF6PFj6In4=

# Si queremos establecer un DNS
DNS = 172.16.0.1

# Definición del servidor al cual conectarse
[Peer]

# Se define la llave pública de dicho servidor
PublicKey = teRk63YIGMHoaDCxS6xxwRd91oek2e378a+X6zunTy8=

# En este apartado se define los IPs que enrutarán por esta interfaz,
# como se puede ver en este caso son todas, es decir, sería la puerta
# de enlace por defecto
AllowedIPs = 0.0.0.0/0

# Dirección del servidor de WireGuard
Endpoint = 10.0.0.1:51820

# Esto define un intervalo en segundos que WireGuard envía un paquete
# nulo para "mantener viva" la conección. Esto es útil en casos de NAT
# para que el firewall mantenga el mismo IP asociado a la conección.
PersistentKeepalive = 25

y el procedimiento es el mismo que para el servidor. Ya con esto tenemos un buen servidor de VPN, como pueden observar, el procedimiento es extremadamente sencillo comparado con las otras 2 propuestas.

IP & ARP spoofing

Sun, 15 Nov 2015 00:00:00 +0000

Disclaimer: This is for educational use only.

Introduction

In the post ARP Spofing i was spoke about the ARP spoofing and how use it to get the network packages sended to another PC. In this post now, i will speak about the same thing, but with the IP, in others words, how to change the source IP of a package.

IP Spoofing

Into the IP layer of network, as is explained into this image

Here, will can see the Source Address field, so when a network packet (by default ;)) leave our computer, the operating system set the ip address of the output interface into that field, that is because the remote computer need response to us.

So, for example, we use cntlm proxy program with the gateway option filter by IP, the configuration

1
2
3
4
5
Gateway        yes

Allow          127.0.0.1
Allow          192.168.12.3
Deny           0/0

In this example, there are 2 ips allowed to enter 127.0.0.1 for local purpose and 192.168.12.3, for example for our cellphone or another PC. Now, the atacker PC has the IP 192.168.12.4 and sniffing the network (in another post i will take about this 8)) detect what IP has access to that proxy. Our pc (has cntlm) use the IP 192.168.12.1.

Now, an atacker can do this with iptables that is the standard firewall of linux and can manipulate the network packets:

1
iptables -t nat -A POSTROUTING -p tcp --destination-port 3128 -d 192.168.12.1 -j SNAT --to-source 192.168.12.3

Explaining:

-t nat Use the table nat of iptables, this is the table of routing.
-A POSTROUTING Apply this rule to that packets that’s are already routed.
-p tcp Use TCP protocol.
--destination-port 3128 The port of the proxy.
-d 192.168.12.1 Apply this rule to the packets that’s go to that ip 192.168.12.1, if not, all the packets that will exit from our pc will change the source IP.
-j SNAT This is the acction to apply, in this case, change the source of the packet.
--to-source 192.168.12.3 No comments :).

Ok, with this line all the packets change their source IP, but… when the remote PC respond to that request, the packet is send to that spoofed IP 192.168.12.3, so how catch the packet? Here is when is needed read the post ARP Spofing to known how tell to the PC objetive 192.168.12.1 that send the packets to 192.168.12.3 to our PC, in a short example (arpspoof we can found into the distribution repository, i use Debian -testing-):

1
arpspoof -i eth0 -t 192.168.12.1 192.168.12.3

Explaining:

-i eth0 This is the network interface (can be wlan0, mon0, eth1, etc).
-t 192.168.12.1 This is the tarjet machine, the PC that will be apply the arp spoofing.
192.168.12.13 This is the address that will be spoofed.

Well and that’s all, with this all the communication is around the attacker PC and the attacked PC, even when the real IP 192.168.12.3 exists or not.

ARP Spoofing

Mon, 20 Apr 2015 00:00:00 +0000

Introducción

Hoy en día el uso de las tecnología ha tenido un auge importantísimo en el día a día nuestro, automatizándonos y por ende facilitándonos la mayoría de las recurrentes tareas que realizamos. En nuestro país cada vez más se ve inundada por nuevos elementos, ya sean de software como de hardware y vamos sin querer haciendo a un lado un aspecto muy importante dentro de ellos… la seguridad. Hoy la mayoría de nosotros subvaloramos la seguridad que determinado dispositivo debe tener, por lo que no nos preocupamos mucho de esto y por tanto dejamos siempre todas las configuraciones por defecto de como viene, ejemplo? instalamos un servidor de base de datos y no cambiamos la contraseña maestra, instalamos un router inalámbrico en la casa y no lo configuramos con una contraseña ni con filtro para permitir que solo el dueño sea el que lo administre, entre otros elementos.

En este blog comentaré acerca de todo tipo de elementos de la tecnología, en este caso comentaré acerca de algunos elementos de seguridad, principalmente hablaré acerca de una técnica utilizada para “mirar” (analizar en buenos términos) toda la información que circula entre dos dispositivos. Aclaro que lo que aquí expreso, aunque nunca diré explícitamente como se realizan estos ataques, es solo para que las personas tengan el conocimiento de cómo funciona y por ende como protegerse de estas técnicas, no me responsabilizo de la falta de seguridad de sistemas donde estos ataques puedan ser cometidos por los conocimientos aquí adquiridos.

ARP Spoof

Nombrando el ataque que hoy comentaré, se trata del “ARP Spoof” o envenenamiento por ARP, existen disímiles técnicas de “envenenamiento”, como DHCP, ICMP, DNS, etc. Primeramente decir que ARP (Protocolo de resolución de nombres o Address Resolution Protocol) es un protocolo encargado de buscar en la red la correspondencia de una dirección de hadware (las famosas MAC) con respecto a su dirección IP. Para un ejemplo más práctico hagamos un “ping” a un ip cualquiera, en este ejemplo al 192.168.0.15:

1
ping 192.168.0.15

que es lo que sucede a manera de resumen y teniendo en cuenta el ARP (evitando muchos elementos que trabajan en su conjunto). Los sistemas operativos que conozco (Microsoft(R) Windows(TM), Apple(R) MacOS(R) o GNU/Linux) cuentan, para un óptimo trabajo con los paquetes ARP, con una tabla interna que relaciona los IP con las MAC, de esta manera no tienen que buscar una MAC si ya las tienen. Bien, volviendo al comando “ping”, el paquete de ICMP (el paquete que se envía realmente con el “ping”) no se direcciona por el IP, sino por la MAC de destino, y como se conoce esa MAC? aquí es donde entra el ARP, si el SO (Sistema Operativo) no contiene esa relación dentro de su “tabla arp” (la cual se puede ver con “arp -a”) entonces envía al broadcast (toda la red) un paquete ARP especial que contiene el IP que requiere, cuando ese paquete llega a la PC directamente o través de varios routers, este responde con su dirección de MAC con un paquete de respuesta de ARP. Cuando éste último arriba a la PC entonces el SO ubica una nueva entrada en la tabla arp y comienza a comunicarse directamente con esa MAC. No es solamente el comando “ping” el que realiza esta tarea, sino todos los programas que requieran del protocolo IP para su comunicación, de hecho la mayoría de ellos. Bien una vez que la PC tiene la MAC correspondiente a una PC remota, cada vez que se requiera comunicar con ella, no realiza todo el proceso de pedido de MAC a través de su IP, sino que consulta en su tabla arp y se comunica directamente; claro, cada cierto tiempo se vuelve a pedir la MAC, para casos de cambios de IP, etc. Ahora, hablando más concretamente del ataque de “ARP Spoof”, supongamos que tenemos el siguiente escenario:

Una PC que se conecta a un servidor utilizando para utilizar un servicio determinado, dígase XMPP (Jabber, chat), HTTP, IMAP (Correo), POP3 (Correo), etc. Además existe una persona (Atacante), la cual, en este caso se encuentra en la misma red que usted y quiere espiar dicha conexión entre el servidor y el cliente. Aquí también hay que dar un ligero detalle acerca del dispositivo que contiene todas las conexiones, ya sea un “Switch” o un HUB, la principal diferencia entre estos es que el “Switch” es orientado a conexiones directas, es decir lo que envíe una PC hacia otra, solo se transmite por los puertos requeridos para dicha conexión, mientras que el HUB lo replica todo; existen muchas diferencias adicionales, pero no es objetivo de este post. Para nuestro caso, estamos en una red interna administrada por un “switch”, por lo que los paquetes entre el cliente y el servidor no llegan a nuestra PC. Adentrándonos en el ataque como tal, consiste en que el atacante envía un paquete de respuesta ARP hacia ambas direcciones, dígase el cliente y el servidor, informando acerca de una nueva dirección MAC para un IP determinado (en caso del cliente, informando que el IP del servidor tiene otra MAC y para el caso del servidor que el IP del cliente se encuentra en otra MAC), dicha MAC nueva corresponde a la dirección física del atacante, estos paquetes se mantienen emitiendo desde la PC del atacante por intervalos de tiempos cortos, para de una manera forzar al SO de que cambie su tabla arp. Habiendo logrado esto, el escenario se transformaría de la siguiente forma:

En este caso quedaría que a manera de ver del cliente se está comunicando correctamente con el IP del servidor, igualmente para el servidor con el IP del cliente, pero a nivel de paquetes, toda la comunicación se realiza a través del equipo del atacante. Esto puede volcarse en disímiles sub-ataques, díganse denegación de servicio (DoS), extración de usuarios y contraseñas, suplantación de sitios Web, etc. Mostraré a través de capturas de pantalla lo que sucede en el ataque, un ejemplo antes de aplicar el ataque y luego de realizarlo, en este caso el cliente es una PC Virtual y el servidor es la puerta de enlace, el atacante, yo.

Aquí se evidencia viendo la tabla arp en el cliente cual es la dirección de .254, la puerta de enlace en este caso, el ip del atacante es el .168 el cual tiene un mac determinado. A la hora de realizar el ataque quedaría:

Ahora podemos observar como en la tabla de arp la mac de la puerta de enlace (.254) es igual a la del atacante (.168).

Ahora bien, ya se entiende como funciona dicho ataque, como protegernos es lo importante. Bien, la manera más eficaz de determinar cuando nos encontramos ante un ataque de este tipo es verificar nuestra tabla arp utilizando los comandos definidos por el SO:

1
arp -a

de esta manera revisaremos de forma manual en cuanto a que todas las MAC de las PCs deben ser diferentes, prestando principal atención cuando nos encontramos en redes que cuentan con puertas de enlace a que su MAC se encuentre “clonada” por otra PC. Existen herramientas para automatizar dichos procesos, como lo son los Firewalls, además de otros especializados en este campo, como “arpwatch”, “arpalert”, etc.

De manera general las maneras de defendernos serían:

Establecer de una manera determinada por el SO o por el dispositivo hardware las tablas ARP de manera manual y eliminar la posibilidad de que se actualicen automáticamente, así se evitan los paquetes autogenerados por el atacante para confundir las tablas ARP. La desventaja de este método es que para redes medianamente grandes es una ardua tarea, pues se tendría que configurar todos los puntos de red para cada actualización de IP nueva, o la inclusión de nuevos dispositivos.
En cuanto a GNU/Linux se puede utilizar una opción del kernel que impide que sean aceptadas los pedidos de ARP “gratuitos”, es decir que lleguen respuestas de paquetes ARP si haberlo solicitado. Importante aclarar que esta opción por defecto viene activada, pero para comprobación de los lectores pueden verlo con el comando en la consola:

1
cat /proc/sys/net/ipv4/conf/all/arp_accept

En caso de que el resultado no sea “0” es un riesgo de seguridad y deberían establecerlo a “0”, de esta manera y desde una terminal con acceso de administración “root”:

1
echo "0" > /proc/sys/net/ipv4/conf/all/arp_accept

En Microsoft(R) Windows(TM) esto lo logramos con el propio firewall que trae por defecto. Muy importante aclarar que esto evita solamente aquellos paquetes respuesta de ARP que no hayan sido solicitados, pero si el atacante a la hora de analizar un pedido que se haya realizado y responde a dicho pedido, no se bloqueará, pues se tomará como una respuesta esperada.

H3R3T1C Blog

Disminuyendo tamaño de HDD virtual de un LXC en Proxmox

Introducción

Reducción del HDD

Monitorizando las máquinas virtuales de proxmox con Prometheus

Introducción

Instalando el exporter

Servidor de métricas Prometheus y aplicación práctica con Node-Exporter y Grafana

Introducción

Instalación genérica

Instalando en Debian

Ejecutando desde Docker

Quay.io

Docker Hub

Opciones

Verificando instalación

Página de consultas

Página de chequeo de los clientes

Breves sobre la Configuración

PromQL

Operaciones simples

Usando funciones y operadores

Node-Exporter

Instalación genérica

Instalación en Debian

Ejecutando desde Docker

Configurando Prometheus

Grafana

Montando_infraestructura_swarm_rancheros

Montando devdocs.io en nuestra red (Docker incluido)

Introducción

Instalando en Debian

Instalando con Docker

WireGuard, un ejemplo práctico

Introducción

Manos a la obra

Agregando clientes

En Debian

En Windows

Configurando los clientes

Debian

Windows

Usando el cliente de OpenVPN a través de un proxy

Introducción

Diferencia entre proxy HTTP y SOCKS

Proxy HTTP

Proxy SOCKS

Caso HTTPS

Manos a la obra

Asegurando nuestras comunicaciones con WireGuard

Introducción

Instalación

Configuración y despliegue

IP & ARP spoofing

Introduction

IP Spoofing

ARP Spoofing

Introducción

ARP Spoof

Ver: