Compresión en LTO

A la hora de hacer backups es muy útil usar compresión para ahorrar espacio, sobre todo si se tratan de datos que no se van a usar como los archives o históricos.

Los sistemas de copias de seguridad como Bacula permiten indicar el tipo y nivel de compresión que se desea utilizar en cada copia. No obstante, si se trata de backup a cintas es muy posible que la unidad de cintas ya tenga su propio sistema de compresión; esto es, se puede hacer la compresión por hardware (unidad de cintas) en lugar de por software (Bacula). De hecho, todas las unidades de cinta LTO tienen soporte para compresión. Cuando se indica la capacidad de una cinta LTO dan 2 números, la capacidad nativa, sin comprimir y la capacidad con datos comprimidos. Aunque este valor depende de los datos que almacenará puesto que algunos tipos de datos tienen mayor tasa de compresión que otros, suelen mostrar un valor de compresión de 2:1, es decir, el doble de capacidad con datos comprimidos.

Usar ambos tipos de compresión a la vez (hardware+software) no solo consume más tiempo, sino que puede llegar a consumir más espacio que los datos originales. Comprimir algo que ya está comprimido no mejora, incluso empeora el ratio. Por esto, se recomienda usar únicamente la compresión hardware ya que es bastante buena y no supone ninguna sobrecarga.

Para comprobar si la unidad tiene la compresión activada podemos usar la utilidad tapeinfo.

# tapeinfo -f /dev/sg0 
Product Type: Tape Drive
Vendor ID: 'HP      '
Product ID: 'Ultrium 5-SCSI  '
Revision: 'Z6FS'
Attached Changer API: No
SerialNumber: 'HU1246T73R'
MinBlock: 1
MaxBlock: 16777215
SCSI ID: 3
SCSI LUN: 0
Ready: yes
BufferedMode: yes
Medium Type: Not Loaded
Density Code: 0x58
BlockSize: 0
DataCompEnabled: yes
DataCompCapable: yes
DataDeCompEnabled: yes
CompType: 0x1
DeCompType: 0x1
Block Position: 430690
Partition 0 Remaining Kbytes: 1470031
Partition 0 Size in Kbytes: 1470031
ActivePartition: 0
EarlyWarningSize: 0
NumPartitions: 0
MaxPartitions: 1

Si no estuviera activado, lo podemos activar con

# mt -f /dev/st0 compression 1

Cómo mantener un conjunto de volúmenes disponibles para cualquier pool en Bacula

En Bacula, cada volume ha de pertenecer a una determinada pool para que un trabajo la utilice. Siguiendo las reglas de Bacula y las especificaciones que indiquemos, un volume se puede reciclar, pero siempre pertenecerá a la misma pool. Se puede dar el caso de que una pool se quede sin volumes para usar, habiendo disponibles en otras pools. Hay una manera de corregir este comportamiento mediante el uso de la pool Scratch: por defecto, Bacula usa los volúmenes de la pool Scratch cuando alguna de las pools necesita un nuevo volumen. Esto es, si una pool necesita un nuevo volumen para escribir y no puede encontrar ninguno, los coge de la pool Scratch, pero no los devuelve a la pool Scratch por defecto. Para ello, tenemos que indicar la pool a la que va el volumen cuando es reciclado.

Sabiendo esto, la solución que he adoptado es asignar un par de volúmenes a cada uno de mis pools, los cuales no cambiaran de pool al reciclarse, y crear la pool Scratch a la que le he asignado los volúmenes restantes configurando la pool para que una vez sean reciclados, estos volúmenes vuelvan a esta pool y puedan ser usados por otras pools.

La configuración sería la siguiente:

Pool {
   Name = Scratch
   Pool Type = Backup
   RecyclePool = Scratch
}

LVM en rbd Ceph

Queremos usar LVM sobre un dispositivo de bloques Ceph. Por defecto, LVM ignora este tipo de dispositivos (lo primero que hemos hecho ha sido mapear la imagen a dispositivo del sistema con rbd map obteniendo el dispositivo /dev/rbd0).

Para permitirlo, hay que editar el fichero de configuración de LVM (/etc/lvm/lvm.conf)y añadir/editar estas líneas:

preferred_names = [ "^/dev/mpath/", "^/dev/mapper/mpath", "^/dev/[hs]d" , "^/dev/rbd" ]
types = ["rbd", 1024]

Mejorando la seguridad con Snort

snort-logoPara proteger la seguridad de nuestra red local y los servicios que suministramos al exterior (SSH y HTTP, principalmente), vamos a hacer una serie de modificaciones a la forma en que se puede acceder a ellos.
En primer lugar, hemos adquirido un nuevo equipo que nos servirá de gateway. Se trata del siguiente equipo:
https://www.supermicro.com/products/system/1u/5018/sys-5018a-ftn4.cfm

Tiene un procesador Atom de 8 cores, 8GB de RAM y 80GB de SSD. La placa tiene funcionalidades propias de un servidor, tales como puerto IPMI dedicado y memoria ECC, lo que facilita su gestión y nos garantiza un mejor funcionamiento.
Este equipo va centralizar las funciones de gateway, firewall y detección de intrusos.

Después de probar muchas distribuciones para este propósito tales como pfSense o ipfire, al final me decanté por Alpine Linux. Las funciones de gateway y firewall las he conseguido usando Shorewall, un firewall que facilita el uso de iptables. Está basado en zonas y cada interfaz de red se asocia a una zona. Se configuran las acciones por defecto y los puertos abiertos y redirecciones. Con ayuda de zenmap (interfaz gráfica de nmap) comprobamos que únicamente están disponibles los puertos que nosotros hemos permitido. No me extiendo mucho en este tema porque en esta entrada me interesa centrarme más en Snort.

Snort es el sistema de detección y prevención de intrusos de red y hosts de facto en el mundo open source. De hecho, es mejor que aplicaciones comerciales con el mismo fin. El fin de Snort es vigilar el tráfico de nuestra red o de un determinado host para detectar comportamientos extraños que puedan responder a intentos de ataques o intrusiones. Snort tiene tres funciones: sniffer al estilo de tcpdump, logger de paquetes (almacenar los paquetes a disco/BBDD) y modo de intrusión de intrusos. En este modo, analiza los paquetes que circulan por la red siguiendo las reglas que hemos definido y realizando acciones en base al tráfico identificado.
snort

Así, nuestro gateway haría de firewall e IDS, tal y como aparece en la figura. Después de pasar las reglas del cortafuegos, los paquetes son analizados por Snort antes de que se encaminen a nuestra red interna.

Veamos ahora lo que Snort es capaz de hacer con estos paquetes.
Snort se basa en el procesado de los paquetes mediante reglas definidas por el usuario. En estas reglas se definen las características que deben cumplir los paquetes para que sean considerados como peligrosos. Se pueden crear a mano estas reglas, pero también se pueden descargar reglas creadas por otros. Por ejemplo, la comunidad mantiene una serie de reglas actualizadas y que se pueden descargar gratuitamente. También se pueden descargar reglas adicionales si nos registramos en la página de la empresa de Snort. Te solicitan para ello una dirección de email. Estas reglas son las mismas que las de la edición de pago de Snort, pero con 30 días de antigüedad.

Pasemos a configurar Snort:

[bash] vi /etc/snort/snort.conf [/bash]

Es un fichero de configuración muy largo, lo principal que hay que cambiar es lo siguiente:

  • Cambiar “var HOME_NET any” a “var HOME_NET X.X.X.X/X” (rellenar con nuestra red local en la que confiemos)
  • Cambiar “var EXTERNAL_NET any” to “var EXTERNAL_NET !$HOME_NET” (esto indica que todo lo que no sea HOME_NET es red externa)
  • Ajustar “var RULE_PATH” al directorio donde vayamos a guardar las reglas (generalmente /etc/snort/rules o /var/lib/snort/rules)
  • Hacer lo mismo con “var SO_RULE_PATH” y “var PREPROC_RULE_PATH”
  • Comentar la línea que empieza con “dynamicdetection directory “
  • Añadir (o editar) la salida de datos: output unified2: filename snort.log, limit 128
  • Encontrar la línea “preprocessor http_inspect: global iis_unicode_map unicode.map 1252 compress_depth … ” y quitarle la parte del final, a partir de “compress_depth”. Debería quedar así: “preprocessor http_inspect: global iis_unicode_map unicode.map 1252”
  • Hallar “inspect_gzip” y comentarlo o eliminarlo
  • Hallar “unlimited_decompress” y comentarlo o eliminarlo

Prueba de la configuración

Podemos empezar a hacer pruebas de nuestra configuración ejecutando el programa en foreground y viendo los mensajes que nos muestra:

[bash] snort -v -c /etc/snort/snort.conf [/bash]

Vemos los mensajes de warning y errores que puedan aparecer y los resolvemos con ayuda de google. Para ayudar a resolver estos problemas y para mantener actualizada las reglas se puede usar la aplicación PulledPork

https://github.com/shirkdog/pulledpork

El programa es un script en Perl. Yo he necesitado instalar algunas dependencias para que funcione, en concreto, perl-lwp-useragent-determined, perl-lwp-protocol-https y perl-crypt-ssleay. Una vez que lo tengamos listo, podemos configurarlo usando su fichero de configuración.

Hay que cambiar <oinkcode> por el nuestro, que se puede encontrar en la página web de Snort, bajo nuestro perfil (siempre que nos hayamos registrado, claro está), corregir los path donde se almacenaran las reglas, el sid-msg.map y changelog. En mi instalación de Snort falta el programa snort_control que se usa a la hora de actualizar la blaclist de IPs, así que he tenido que volver a generar el apk con la opción –enable-control-socket.

 

http://sourceforge.net/projects/secureideas/files/BASE/base-1.4.5/base-1.4.5.tar.gz/download

Con ayuda de una máquina virtual con Alpine Linux usada para compilar programas y así mantener limpio la instalación, compilamos barnyard2. Hay que añadir la opción –with-mysql para dar soporte a esta base de datos.

El binario resultante lo copiamos en nuestra máquina de producción.

Lo siguiente a hacer es inicializar la base de datos. El script en SQL para esto se haya en el directorio schemas dentro del código fuente del programa.

 

BASE necesita php-adodb

https://ip/base/setup/