Map de imágenes RBD de Ceph con kernels antiguos

Al intentar mapear una imagen rbd de la última versión de ceph (jewel) en el kernel que incluye la distribución de centos 7, da un error como el siguiente:

[bash]

rbd: sysfs write failed
RBD image feature set mismatch. You can disable features unsupported by the kernel with "rbd feature disable".
In some cases useful info is found in syslog – try "dmesg | tail" or so.
rbd: map failed: (6) No such device or address

[/bash]

Esto sucede porque el módulo del kernel (krbd) no soporta las nuevas funciones de jewel. He intentado desactivar esas funciones con rbd feature disable, pero tampoco me ha dejado. Así que he tenido que volver a crear la imagen indicando a la hora de la creación las features que nos interesan:

[bash]rbd create -s 100G –image-feature layering one/almacen[/bash]

He sido bastante restrictivo y sólo he dejado la funcionalidad básica de layering.

Parece ser que esto se debe a que ahora por defecto la imágenes rbd se crean con el formato versión 2 (antes 1).

NFS en alta redundancia

Queremos compartir un punto de montaje NFS con alta disponibilidad para evitar que la caída del server provoque que el servicio se detenga. Para evitar cualquier punto de fallo, para almacenar los datos se va a utilizar ceph. El sistema de replicación que hace ceph permite que se puedan seguir accediendo a los datos a pesar de sufrir la caída de parte de los servidores que conforman el cluster. Con la alta disponibilidad, conseguimos que si cae el servidor NFS, otro nodo del cluster asuma ese rol.

Partimos de un escenario en el que tenemos un cluster ceph funcionando y un cluster de alta disponibilidad con corosync, pacemaker y pcs.

En resumen, haremos lo siguiente: usaremos una imagen rbd de ceph para albergar los archivos que queremos compartir por NFS. Usando el cluster de alta disponibilidad, montaremos ese dispositivo de bloques e iniciaremos el servidor NFS que usará una IP virtual.

Pasemos a detallar paso a paso ese proceso:

  1. Creamos una imagen en ceph

    [bash] rbd create –size 100000 pool/nombreimagen # el tamaño se expresa en megabytes, así pues, crearíamos un disposivito de 100GB [/bash]

  2. Mapear la imagen a dispositivo de bloques. Con esto, la imagen se puede utilizar como cualquier otro dispositivo de bloques, como un disco duro.

    [bash] rbd map pool/nombreimagen [/bash]

    Se crea un dispositivo /dev/rbdX y un enlace simbólico en /dev/rbd/pool/nombreimagen a ese dispositivo. Este proceso se puede automatizar añadiendo al fichero /etc/ceph/rbdmap la imagen que queramos mapear y el usuario a usar:

    [bash] poolname/imagename     id=client,keyring=/etc/ceph/ceph.client.keyring [/bash]

    y llamar directamente al script

    [bash] rbdmap map [/bash]

    ó

    [bash] systemctl start rbdmap [/bash]

  3. Le damos formato a la imagen
    [bash] mkfs.ext4 /dev/rbd0 [/bash]
    y la montamos
    [bash] mount /dev/rbd0 /mountpoint [/bash]
    . Ahora ya podemos copiar o sincronizar los datos que queremos compartir

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/