LXC: limitar recursos de CPU

 

Traducción del siguiente articulo 

La administración de contenedores Linux (LXC) ahora se maneja a menudo con LXD, el proyecto principal de Canonical construido sobre LXC. LXD ofrece un conjunto de opciones para controlar los recursos de los contenedores Linux y establecer límites cuando sea apropiado. Esta publicación hablará sobre cómo establecer restricciones en la CPU, sin embargo, hay otras opciones disponibles para limitar casi cualquier tipo de recurso, como red, E/S de disco, memoria, etc.

Límites disponibles

La administración de la CPU se realiza de 1 de 4 maneras, según su carga de trabajo esperada y el régimen de administración de la CPU del host.

• Número de CPU: define la cantidad de núcleos de CPU que LXC puede usar con este contenedor y distribuye automáticamente el tiempo de CPU entre los invitados cuando hay competencia por el tiempo de CPU. El valor utilizado es un número entero, por ejemplo 2.
• Núcleos específicos: especifica núcleos físicos específicos para que los use el contenedor y distribuye el tiempo de CPU disponible entre contenedores cuando varios contenedores usan los mismos núcleos. El valor utilizado es un número entero o rango y puede estar separado por comas, por ejemplo 2, 0-1 o 0-1,3,5-9.
• Participación limitada: permite un porcentaje específico de tiempo de CPU para el contenedor, o más si está disponible. Cuando el host no está bajo carga, un contenedor puede usar cualquier CPU disponible, pero cuando hay contención por la CPU, el contenedor se limitará a la cantidad especificada. El contenedor verá todos los núcleos de CPU del host (en TOP, por ejemplo).
• Comparte de tiempo limitado: limitará el tiempo de CPU del contenedor a lo que se especifique de cada 200ms. Incluso si hay más CPU disponible, solo se permite lo que se especifica por porción de 200ms. El contenedor verá todos los núcleos de CPU del host (en TOP, por ejemplo).

Establecimiento de límites

El establecimiento de límites se realiza con el comando lxc. Luego hay dos opciones; limits.cpu para los puntos anteriores 1 y 2, o limit.cpu.allowance para los puntos 3 y 4.

lxc config set [CONTENEDOR] limits.cpu [VALOR]

• [CONTENEDOR] es el nombre del contenedor; se puede obtener de lxc list si no está seguro.
• [VALOR] es un valor válido del punto 1 o 2 anterior.

O

lxc config set [CONTENEDOR] limits.cpu.allowance [VALOR]

• [CONTENEDOR] es el nombre del contenedor; se puede obtener de lxc list si no está seguro.
• [VALOR] es un valor válido del punto 3 o 4 anterior.

Ejemplos de límite de CPU

• Configure el contenedor nginx-proxy para que use cualquiera de las 2 CPU en el host.

lxc config set nginx-proxy limits.cpu 2

• Configure el contenedor nginx-proxy para que use las CPU físicas 0, 3, 7, 8 y 9 en el host.

lxc config set nginx-proxy limits.cpu 0,3,7-9

• Configure el contenedor nginx-proxy para que use el 20% de la CPU disponible en el host o más si está disponible.

lxc config set nginx-proxy limits.cpu.allowance 20%

• Configure el contenedor nginx-proxy para que use no más del 50% de la CPU disponible en el host, o 100 ms por cada 200 ms de tiempo de CPU disponible.

lxc config set nginx-proxy limits.cpu.allowance 100ms/200ms

Puede ver /proc/cpuinfo para ver los núcleos disponibles en su contenedor, sin embargo, no incluirá ningún límite de programación o prioridad adicional.

cat /proc/cpuinfo | grep processor
processor: 0
processor: 1

Prioridad de CPU

La última opción relacionada con la limitación de CPU es la prioridad del tiempo de CPU. Esta opción solo se activa cuando el host está sobrecargado en recursos de CPU y los contenedores están luchando por el tiempo de CPU. Esto puede ocurrir en un solo núcleo (si se usan los puntos anteriores 1 o 2) o en todo el sistema (si no hay limitación de CPU en uso o si se usan los puntos anteriores 3 o 4).

Los valores disponibles van de 0 a 10 (inclusive). Los números más bajos significan una prioridad más baja, mientras que un número más alto significa que la máquina obtendrá tiempo de CPU antes que los números más bajos.

El siguiente comando establece una prioridad de CPU de 5 para el contenedor nginx-proxy:

lxc config set nginx-proxy limits.cpu.priority 5

El siguiente comando establece una prioridad de CPU de 2 para el contenedor php-backend, por lo que obtendría menos tiempo de CPU que el contenedor nginx-proxy cuando la CPU esté en contención.

lxc config set php-backend limits.cpu.priority 5 

Activar Telnet y SSH en equipos Cisco

 Lo primero es crear un usuario dentro del equipo:

 username nombre_usuario privilege 15 secret clave_usuario.

 Ya realizado esto activaremos los servicios

 

Telnet

line vty 0 15
  transport input telnet
  login local

 

SSH

Para activar SSH es requisito tener nombre de host, nombre de dominio y generar una clave rsa para la encriptacion de la conexion

 
hostname nombre_equipo
ip domain-name dominio.algo
crypto key generate rsa
ip ssh version 2
line vty 0 15
  transport input ssh
  login local

Bloqueo con GeoIP en Ubuntu 20.04

Para algunos servicios que solo es necesario que estén disponibles, merece la pena utilizar el bloqueo geográfico a nivel IP, permitiendo aumentar el nivel seguridad sin afectar a los usuarios de este.

Para esto utilizaremos la base de datos de GeoIP de db-ip en conjunto con el paquete xtables-addons

 Instalación de requisitos

sudo apt-get update; sudo apt-get -y upgrade
sudo apt-get install curl unzip perl 
sudo apt-get install xtables-addons-common
sudo apt-get install libtext-csv-xs-perl libmoosex-types-netaddr-ip-perl

Script de actualización

Debemos crear un script que periódicamente este descargando la actualización de la bases de datos de GeoIP para esto realizamos primero crear una carpeta:

sudo mkdir /usr/share/xt_geoip

 Después creamos el script la siguiente ubicación /usr/local/bin/geo-update.sh

#!/bin/bash

MON=$(date +"%m")
YR=$(date +"%Y")

wget https://download.db-ip.com/free/dbip-country-lite-${YR}-${MON}.csv.gz -O /usr/share/xt_geoip/dbip-country-lite.csv.gz
gunzip /usr/share/xt_geoip/dbip-country-lite.csv.gz
/usr/lib/xtables-addons/xt_geoip_build -D /usr/share/xt_geoip/ -S /usr/share/xt_geoip/
rm /usr/share/xt_geoip/dbip-country-lite.csv

Al ejecutar este script se poblara la base de datos de GeoIP para su uso. Recuerde crear una tarea en cron para actualizar la base de manera pediodica.

Creacion de reglas

Antes de crear la regla debemos cargar  el modulo para que opere. Ejecutamos el siguiente comando:

modprobe xt_geoip
lsmod | grep ^xt_geoip

Si todo va esta bien, podemos aplicar la siguiente regla:

iptables -A INPUT -m geoip -p tcp --dport 22 --src-cc RU,CN -j DROP

Esto bloqueara el acceso SSH desde Rusia y China.

Si quieres permiter el acceso desde un pais en ese caso la regla seria la siguiente:

iptables -A INPUT -m geoip -p tcp --dport 22 --src-cc CL -j ACCEPT

 Aqui permitimos el acceso SSH solo desde Chile

Aplicando de manera permanente

Estas reglas que recien aplicamos se borrar si reiniciamos la maquina. Para que las reglas sean permanentes, te recomiendo usar el servicio ufw. Para esto edita el archivo  /etc/ufw/before.rules y agregan reglas antes del COMMIT, como esta:

-A ufw-before-input -m geoip -p tcp --dport --dport 22 --src-cc CL -j ACCEPT

Esta regla permite el acceso SSH desde Chile, recuerda que ufw por defecto deniega todo el trafico

Publicación en ingles

Utilizar modulos SFP de terceros en swtiches Cisco

 API DNA Center a traves de Python

 

Diagramas automaticos Python y CDP 

 

 Notificaciones a traves de Telegram con Python

 

 

Aunque SFP no es un estándar, si se construye en base a un multi-source agreement (MSA) el cual permite que los módulos SFP sean compatibles entre múltiples fabricantes. 

Esto permite que uno pueda instalar módulos de distintas marcas en equipamiento Huawei, Cisco SMB, Juniper, etc. Pero en los switches Cisco de la linea Catalyst esto no es posible por que al instalar un modulo el switch arroga el siguiente error:

%GBIC_SECURITY_CRYPT-4-VN_DATA_CRC_ERROR: GBIC in port 65586 has bad crc
%PM-4-ERR_DISABLE: gbic-invalid error detected on Gi1/0/50, putting Gi1/0/50 in err-disable state

Lo cual bloquea la puerta y no la permite utilizar. Pero esto tiene solucion con los siguientes comandos:

service unsupported-transceiver
no errdisable detect cause gbic-invalid

El primer comando permite agregar módulos SFP de terceros o no soportados, y el segundo deshabilita el error por modulo invalido. Despues esto es necesario es reiniciar la puerta del switch que quedo con error para que esta funcione.

VRRP en Vyos/UBNT EdgeRouter

VRRP (Virtual Router Redundancy Protocol) es un protocolo de redundancia a nivel IP definido en el RFC3768. Fue diseña para permitir alta disponibilidad en la puerta de enlace por defecto en una subred, aunque se puede utilizar tambien para permitir alta disponibilidad de servicios (servidores web, Telefonía, etc). 

En este ejemplo revisaremos la funcionalidad original, alta disponibilidad de la puerta de enlace. Se presupone que ambos Vyos ya tienen acceso a internet, tienen configuradas interfaces, rutas, regla de NAT y de filtrado. El diagrama es el siguiente:

Los datos relevantes son:

Subred: 10.0.0./24

IP virtual: 10.0.0.10

IP router1: 10.0.0.11

IP router2: 10.0.0.12

El router1 sera el principal, tendrá mayor prioridad, y ademas tendra configurado el comando preempt que le permitira recuperar la IP virtual luego de una caida o reinicio.

Router1

set interfaces ethernet eth0 vrrp vrrp‐group 10
set interfaces ethernet eth0 vrrp vrrp‐group 10 virtual‐address 10.0.0.10/24
set interfaces ethernet eth0 vrrp vrrp‐group 10 preempt true
set interfaces ethernet eth0 vrrp vrrp‐group 10 priority 150
commit
save
#
show interfaces ethernet eth0 vrrp 
vrrp‐group 10 {
  preempt true
  priority 150
  virtual‐address 10.0.0.10/24
}

Router2

set interfaces ethernet eth0 vrrp vrrp‐group 10
set interfaces ethernet eth0 vrrp vrrp‐group 10 virtual‐address 10.0.0.10/24
set interfaces ethernet eth0 vrrp vrrp‐group 10 priority 100
commit
save
#
show interfaces ethernet eth0 vrrp 
vrrp‐group 10 {
  priority 100
  virtual‐address 10.0.0.10/24
}

Con esta configuración ya tendremos corriendo VRRP entre nuestro routers. Router1 en modo normal recibirá el trafico desde la subred, ante una caida de este Router2 obtendrá la IP virtual y permitira que el flujo de trafico a internet no se interrumpa.

Las opciones del comando VRRP en Vyos son las siguientes:

interfaces ethernet eth0 vrrp 
   vrrp-group <1-255> #VRRP group number
      advertise-interval <1-255> #Advertise interval (default 1)
      authentication
      description  #Description
      disable  #VRRP group disabled
      hello-source-address  #Source address for vrrp hello packets (optional)
      preempt  #Preempt mode
      preempt-delay <0-1000> #Preempt Delay in seconds
      priority <1-255> #Priority
      rfc3768-compatibility
      run-transition-scripts  #Scripts for VRRP state-transitions
      sync-group  #Add this vrrp group to a sync group
      virtual-address  #Virtual IP address (up to 20 per group)

Como bloquear paginas en HTTPS en Zentyal

Sincroniza configuraciones con Unison

Crea tu propia nube de almacenamiento

Este problema es recurrente para los administradores de redes que utilizan proxys con Squid para controlar las paginas que se acceden a Internet. Normalmente uno bloquea una pagina vía las reglas del proxy, pero esto no aplica a paginas https como facebook, gmail y otras, ya que el proxy no puede bloquear en https, debido a que este va encriptado y no lo puede diferenciar. Además de lo expuesto anteriormente no podemos bloquear todo el trafico https por el tema de acceso a paginas importantes como Bancos, servicios publicos, etc. Aqui explicare como bloquear en especifico facebook vía el firewall de Zentyal.

Obtener IPs de Facebook y creando objeto facebook

Para obtener las ips de facebook es necesario realizar un ping a las direcciones:

facebook.com
www.facebook.com
login.facebook.com

De esto se obtienen 3 ips de las cuales debemos obtener sus rangos, para eso existe http://whois.arin.net/ui, y creamos un objeto llamado facebook con estos rangos como vemos en la siguiente imagen.

Creando servicio HTTPS

En la seccion de servicios creamos el servicio https como se ve en la siguiente imagen.

Creando la regla de firewall

En el firewall de Zentyal, en la zona filtro para reglas internas, creamos una regla como la siguiente:

Y con esto facebook via https no debería esta permitido, verifica esto en el logs de firewall.