Cambiar disco fallido en RAID software (mdadm)

mdadm es un método de implementar a nivel software las facilidades del RAID a nivel hardware. Aunque en la actualidad, especialmente los servidores de producción, suelen traer todos consigo la posibilidad de crear diferentes tipos de RAID hardware, es cierto que pueden no traerlo. En ese caso y como proteger nuestros datos (y por lo tanto la disponibilidad de los mismos) debería de estar por encima de todo, la opción de tener disponible una solución de RAID puede resultar francamente útil y para hacerlo está mdadm.

mdadm crea el RAID, pero no evita que un disco pueda fallar. Sí tenéis una salida similar a la siguiente,

shell> mdadm -D /dev/md0
/dev/md0:
        Version : 00.90.00
  Creation Time : Thu Ene  2 12:27:05 2014
     Raid Level : raid1
     Array Size : 64128 (62.63 MiB 65.67 MB)
    Device Size : 64128 (62.63 MiB 65.67 MB)
   Raid Devices : 2
  Total Devices : 1
Preferred Minor : 0
    Persistence : Superblock is persistent

    Update Time : Tue Ene  2 18:54:59 2014
          State : active, degraded
 Active Devices : 1
Working Devices : 1
 Failed Devices : 0
  Spare Devices : 0

           UUID : 40e3ae0f:fd3ef12a...
         Events : 0.91

Number  Major  Minor  RaidDevice  State
0       0      0      0           faulty removed
1       8      1      1           active sync   /dev/sda1

querrá decir que uno de los discos que compone el RAID ha fallado. Como se puede observar, hay dos discos en el RAID y uno de ellos ya no está presente (/dev/sdb1).

La solución ahora pasa por marcar el RAID como fallido, cambiar el disco y volver a reconstruir el RAID nuevamente. Para hacerlo, os dejo aquí los pasos.

• Indicamos al RAID que la partición ha fallado

  shell> mdadm --manage /dev/md0 --fail /dev/sdb1
  

• Eliminamos la partición de RAID

  shell> mdadm --manage /dev/md0 --remove /dev/sdb1
  

• Apagamos el equipo y cambiamos el disco
• Replicamos estructura del disco sda al nuevo disco sdb

  shell> sfdisk -d /dev/sda | sfdisk /dev/sdb
  

• Incluimos en nuevo disco en el RAID

  shell> mdadm --manage /dev/md0 --add /dev/sdb1
  

• Esperamos a que sincronicen los datos (según el tipo de RAID)
  
  Durante este tiempo se puede trabajar perfectamente con el equipo, aunque irá un poco más lento, probablemente.

Si algún día lo tenéis que usar, espero que os sea de ayuda y sino, mejor que mejor.

Leer más

Comandos interesantes, netstat I

netstat es una herramienta de red que todo el mundo debería de conocer más o menos en profundidad. Aunque es simple de entender y de usar, la verdad es que nos puede dar una cantidad importante de información sobre el estado de la red en nuestro equipo.

Gracias a netstat se pueden imprimir desde estadísticas de red a tablas de rutas, pasando por todas aquellas conexiones de red activas que tiene el equipos. Aunque, por ejemplo, en sistemas GNU/Linux hay comandos específicos que hacen  dichas tareas de forma aislada, netstat es multiplataforma (Windows, Linux y MAC) y permite, variando las opciones, también extraer dicha información.

• Estadísticas e interfaces

  shell> netstat -i
  Kernel Interface table
  Iface  MTU  Met  RX-OK RX-ERR RX-DRP RX-OVR  TX-OK TX-ERR TX-DRP...
  eth0  1500    0  10262      0      0      0  79922      0      0...
  lo    5536    0   1392      0      0      0  10392      0      0...
  

  El significado de cada una de estas columnas es el siguiente:
• Iface: Representa el interfaz de red conocido por el sistema para el que se presentan las estadísticas.
• MTU: Unidad Máxima de Transmisión que el interfaz puede enviar de una sola vez.
• RX: Representan las estadísticas sobre los paquetes recibidos en el interfaz.
• TX: Representan las estadísticas sobre los paquetes recibidos en el interfaz.
• OK: Recibido/enviado correctamente
• ERR: Recibido/enviado con error
• DRP: Eliminado por que el buffer estaba lleno.
  Esto sucede si se envían/reciben muchos paquetes en muy poco tiempo.
• OVR: Eliminado por que el paquete no pudo ser manejado por el kernel.
  
  Si hay paquetes aquí significa que la máquina tuvo mucha carga.
• FLG: Flags activos en el interfaz. Pueden ser:
• B: Presenta capacidad de broadcast
• M: Presenta capacidad de multicast
• L: Interfaz de loopback
• U: UP/Activa
• R: Running/Ejecutándose
• Tabla de rutas

  shell> netstat -r
  Kernel IP routing table
  Destination      Gateway    Genmask Flags  MSS Window  irtt Iface
  default      192.168.0.1    0.0.0.0    UG    0      0     0 eth0
  10.0.0.15    *        255.255.255.0     U    0      0     0 eth0
  192.168.1.32 *        255.255.255.0     U    0      0     0 eth1
  

  Y a continuación una breve explicación de qué significa cada una de las columnas que componen la salida.
• Destination: Indica el destino, o la ruta que cogerá este paquete. Cada vez que se envía un paquete se examina esta tabla y se decide por donde enviar el paquete con aquella ruta que cumpla la condición. En caso de que no haya una más específica, se envía por la 'ruta por defecto'.
• Gateway: Indica a dónde mandar el paquete, o lo que es lo mismo, el siguiente salto del paquete.
  Un '*' significa que queda dentro de la misma red.
• Genmask: Máscara de red.
• Flags: Los flags que se van a aplicar.
• U: UP
• G: Gateway
• H: Dirección de host completa.
• MSS: Maximum Segment Size.
  
  Parámetro TCP usado para dividir los paquetes en partes más pequeñas, en caso de que el destino no sea capaz de trabajar con tamaños estándar.
  En la actualidad casi no se emplea y está prefijado a 0.
• Window: Al igual que MSS, permite alterar un parámetro TCP Default Windows Size, que indica el número de paquete máximo a enviar antes de que uno de ellos sea de ACK.
• irtt: Initial Round Trip Time.
  Lo puede usar el kernel para adivinar la mejor configuración de parámetros TCP.
• Iface: Indica el interfaz por el que se envían los paquetes

Leer más

Zimbra: INFECTED: Heuristics.Encrypted.PDF

Si a vuestra cuenta de administración de Zaimbra llegan correos similares a este:

VIRUS (Heuristics.Encrypted.PDF) in mail FROM ...

o como este otro,

A virus was found: Heuristics.Encrypted.PDF
Scanner detecting a virus: ClamAV-clamd

Eso significa que algunos de los correos entrantes llevan adjuntos que el sistema no puede abrir para escanear. Por ejemplo, un PDF con clave de acceso o un fichero tipo RAR. Puesto que el antivirus no puede analizar el contenido, directamente se opta por no dejarlo pasar.

Si esto os pasa, pero es algo conocido, hay forma de solucionarlo. Lo primero es editar el fichero /opt/zimbra/conf/clamd.conf y cambiar la configuración de la variable ArchiveBlockEncrypted, estableciéndola a no

ArchiveBlockEncrypted no

y en el archivo /opt/zimbra/conf/clamd.conf.in cambiar la línea zimbraVirusBlockEncryptedArchive dejándola como sigue,

%%uncomment VAR:zimbraVirusBlockEncryptedArchive%%ArchiveBlockEncrypted no

Tras hacer esto, simplemente reiniciamos el servicio antivirus del sistema.

shell> zmclamdctl stop
shell> zmclamdctl start

Y ya no debería de volver a pasarnos lo aquí comentando.

Leer más

Actualización de seguridad para el núcleo de Drupal

Descripción:

Vulnerabilidad crítica en el Core de Drupal
Versiones afectadas: < 6.30 y < 7.26

Fecha:

16/01/2014

Detalles:

• Suplantación (módulo OpenID) (Muy crítico)
  
  Vulnerabilidad que afecta al módulo OpenID y que permite a un usuario malicioso entrar como otros usuarios en el sitio, incluyendo administradores.
  Para poder explotar esta vulnerabilidad el usuario debe tener una cuenta en el sitio, y la víctima debe tener una cuenta con una o más identidades OpenID asociadas.
• Bypass de acceso (módulo Taxonomy) (Moderadamente crítico)
  
  El módulo Taxonomy proporciona varias páginas del listado que muestran contenido etiquetado con un término particular de taxonomía.
  Bajo ciertas circunstancias, el contenido inédito puede aparecer en estas páginas y estará visible para los usuarios que no deben tener permiso para verlo.
  Esta vulnerabilidad sólo afecta a sitios de Drupal 7 que fueran actualizados desde Drupal 6 o anteriores.
• Endurecimiento de Seguridad (API Form) (No es crítico)
  
  El API proporciona un método para que los desarrolladores puedan crear formularios de envío utilizando la función drupal_form_submit() más segura. Este parche no soluciona un problema de seguridad en sí, pero proporciona un extra de seguridad que serían difíciles o imposibles de resolver de otra manera.

Solución:

Actualizar a las versión 6.30 o 7.26, según la versión de drupal empleada.

Referencias:

Drupal security

Leer más

DIG - guía básica

Hace un tiempo expliqué algunos usos básicos de dig como herramienta de visualización y comprobación de entradas DNS.

Hoy voy a dejar aquí una pequeña guía o chuleta básica de dig, opciones y salidas que vamos a poder obtener para comprobar si un servidor DNS está correctamente configurado o incluso para averiguar información interesante sobre dominios.

Por defecto, y siempre que sea posible voy a emplear la opción "+short" ya que así la salida es mucho más simple y legible.

También, dig incluye la posibilidad de preguntar directamente a un servidor DNS concreto. Para ello empleamos el "@DNS-Server".

1. Información básica

   shell> dig google.com +short
   74.125.24.101
   74.125.24.102
   74.125.24.113
   74.125.24.138
   74.125.24.139
   74.125.24.100
   

2. Registros DNS

   shell> dig @8.8.8.8 google.com A +short
   173.194.116.101
   173.194.116.105
   173.194.116.99
   173.194.116.97
   173.194.116.100
   173.194.116.103
   173.194.116.102
   173.194.116.98
   173.194.116.96
   173.194.116.110
   173.194.116.104
   

1. Registros NS
   
   Hace referencia a los servidores DNS que emplear el dominio consultado.

   shell> dig @8.8.8.8 google.com NS +short
   ns1.google.com.
   ns2.google.com.
   ns3.google.com.
   ns4.google.com.
   

2. Registros MX
   
   Hace referencia a los nombre de los servidores de correo que existen en el dominio consultado.

   shell> dig @8.8.8.8 google.com MX +short
   40 alt3.aspmx.l.google.com.
   30 alt2.aspmx.l.google.com.
   10 aspmx.l.google.com.
   50 alt4.aspmx.l.google.com.
   20 alt1.aspmx.l.google.com.
   

3. Registros TXT

   shell> dig @8.8.8.8 google.com TXT +short
   "v=spf1 include:_spf.google.com ip4:216.73.93.70/31 ..."



3. Consulta inversa
   
   Sirve para saber el nombre que al que resuelve una IP concreta y por lo tanto poder buscar un dominio únicamente teniendo como información una IP.

   shell> dig -x 173.194.116.96
   ...
   ;; AUTHORITY SECTION:
   116.194.173.in-addr.arpa. 60  IN  SOA  ns1.google.com. ...
   ...

Leer más

Cómo averiguar la versión de BIND

Hoy os quiero presentar un pequeño truco para averiguar la versión de bind que está empleando un servidor DNS aunque éste la tenga oculta. Hace un tiempo publiqué cómo poder ocultar la versión de bind que estábamos empleando y hoy vamos a ver cómo ese método no sirve de nada.

Para hacer la prueba, vamos a necesitar instalar el comando fpdns, que no es más que un pequeño script que se emplear para realizar un  'fingeprinting' a servidores DNS y averiguar así la versión que están ejecutando.

El paquete esté disponible en los repositorios de las principales distribuciones y en Debian/Ubuntu, la instalación es muy sencilla,

shell> apt-get install fpdns

Una vez está instalado, tenemos el siguiente resultado, en comparativa entre una petición vía dig,

shell> dig -c CH -t txt version.bind @ns1.miempresa.com
...
;; QUESTION SECTION:
;version.bind.                  CH      TXT
...

a un petición con el nuevo comando,

shell> fpdns -D miempresa.com
fingerprint (miempresa.com, 212.244.X.X): ISC BIND 9.2.3rc1 -- 9.6.1-P1 

Como podéis observar, la versión del servidor bind9 que se está ejecutando nos dice que que es la 9.2.3rc1 -- 9.6.1. Puesto que tengo acceso al servidor, compruebo y corroboro lo que fpdns dice y efectivamente la versión instalada es la 9.7.3. Como se puede ver, no acertó exactamente pero sí no dio una idea muy próxima de qué versión se está empleando.

Leer más