Archivo etiqueta GNU/Linux

Cómo verificar la integridad de datos con Tripwire

Cada vez más, debemos tener un fuerte control sobre la integridad de nuestros datos, en especial, cuando el servidor tiene acceso a Internet. Para cubrir esta necesidad, en el mundo del software libre hay dos herramientas que se disputan el podio, una es Aide y otra es Tripwire.

Como mi amigo Alejandro García, autor del Blog RM-rf.es, ha escrito un fabuloso artículo sobre Aide. Me voy a centrar en el uso y "disfrute" de Tripwire.

 

Qué hace realmente Tripwire

Para empezar, daremos unas leves pinceladas al funcionamiento de este programa. Tripwire genera una base de datos encriptada con las propiedades de cada elemento de nuestro sistema de ficheros. Esta base de datos es empleada para comprobar los cambios acaecidos en el sistema de ficheros.  Si estas modificaciones han sido realizadas y/o autorizadas por nosotros, la base de datos será actualiza, en caso contrario, habrá que investigar qué ha sucedido.

Teniendo en cuenta lo anterior, lo ideal sería instalarlo en un servidor recién instalado ya que no ha sido comprometido por agentes externos o al menos, tiene muy pocas posibilidades de que sea así. Si el servidor lleva ya cierto tiempo prestando servicios, antes de implementarlo, sería recomendable analizarlo a través de diferentes herramientas. 

 

Instalación de Tripwire

El proceso de instalación de Tripwire, se divide en las siguientes fases:

  1. Instalación del software.
  2. Creación de la clave del site y la local.
  3. Creación e implementación del fichero de configuración y de la política.
  4. Aplicación de permisos adecuados a los ficheros de configuración y de la política.

 

Casi todas las distribuciones de GNU/Linux disponen de una versión empaquetada, así que suele ser muy fácil instalar este software. En el caso de GNU/Debian, el primer paso es el siguiente:

 # apt-get install tripwire 

El resto de pasos son facilitados gracias a los asistentes que despliega.

No os preocupéis, si vuestra distribución no cuenta con estos asistentes o no os apetece usarlos, a continuación explicamos cómo se pueden realizar estas tareas manualmente a través de la herramienta de administración twadmin.

 

Generación de claves

Las claves son importantísimas y serán solicitadas en todos los procesos que impliquen la modificación de la configuración, de la política y de la base de datos. Os recomendamos que sean diferentes entre sí.

Tenemos que generar dos, una para el site y otra para local que podrán ser almacenadas donde se quiera, por ejemplo, en mi caso será /etc/tripwire. Por convención, a la primera se la llama site.key y a la segunda HOST-local.key, siendo HOST sustituida por el nombre del servidor.

 # twadmin -m G -L /etc/tripwire/dummy-local.key -S /etc/tripwire/site.key 

 

Generación de la configuración y la política

Nos va a sorprender la forma que Tripwire tiene para generar la configuración y la política. Para empezar debemos tener siempre presente que se trata de un analizador de la integridad de los datos del sistema y por ese motivo, empieza por su propia configuración y política.

Al margen de la distribución o sistema de paquetes, existen dos ficheros twcfg.txt y twpol.txt que poseen la configuración y la política por defecto respectivamente. Son ficheros de texto plano y por tanto, editables sin esfuerzo alguno. Nosotros los vamos a utilizar de plantilla y a través de twadmin, generaremos unas versiones binarias cifradas y firmadas que Tripwire utilizará para su funcionamiento.

Os recomendamos revisar los ficheros twcfg.txt y twpol.txt para comprobar si cumplen con nuestras necesidades.

El primer fichero que debemos crear es el fichero de configuración y posteriormente, el de política. Creo que también por convención, el fichero de configuración se llama tw.cfg y el de políticas tw.pol, no obstante, si alguien desea otros nombres, deberá modificar las plantillas previamente indicadas. 

 # twadmin -m F -S /etc/tripwire/site.key -c /etc/tripwire/tw.cfg -Q "ClaveSite" twcfg.txt 

A continuación, haremos lo mismo con el fichero de la política tw.pol:

 # twadmin -m P -S /etc/tripwire/site.key -c /etc/tripwire/tw.cfg -Q "ClaveSite" twpol.txt 

 

Creación de la base de datos

El tiempo de creación de la base de datos será determinado por el número de elementos de nuestro sistema de ficheros. Debemos tener paciencia si asumimos un sistema complejo como, por ejemplo, un servidor de base de datos.

Para la creación de la base de datos inicial, debemos ejecutar:

 # tripwire -m i 

En medio del proceso, nos pedirá la clave local para poder escribir en la base de datos de Tripwire.

 

Comprobación de la integridad de datos

Para testar que Tripware está comprobando la integridad de datos, vamos a hacer una prueba muy simple que consiste en modificar una línea dentro del fichero /etc/hosts. En concreto añadiremos la línea siguiente:

 # Esto es una prueba para Tripware. 

 

Ahora vamos a verificar si detecta el cambio en la integridad de los datos.

 # tripwire -m c 

 

El informe aparecerá por pantalla y también se guardará una copia en nuestro sistema de ficheros. El informe tiene un nombre normalizado que consiste en [NombreDeHost]-[Año][Mes][Día]-[Hora][Minuto][Segundo].twr lo que facilita la creación de scripts. Por cierto, estos ficheros son binarios y requieren de la herramienta twprint para mostrarse en pantalla, tal como hacemos a continuación:

 # twprint -m r -r /var/lib/tripwire/report/dummy-20120913-122534.twr 

 

Como suelen ser informes muy largos, suele ser conveniente utilizar alguna herramienta como more o pg. Existe la posibilidad de generar un informe parcial pero hasta que no estemos muy habituados a la información que se puede obtener, es mejor, obviadlo por el momento.

Volviendo a la prueba que estamos realizando, vamos a analizar el informe donde hay dos secciones que un administrador de sistemas o analista de seguridad ha de fijarse.

La primera hace mención a la sección del sistema de ficheros y este es un ejemplo:

Sección del sistemas de ficheros de Tripware

Nos debemos fijar las rules names que les antecede un asterisco ya que esta es la forma que tiene Tripware de informarnos que ha habidos cambios. Ahora bien, la rule name "Devices & Kernel information" no le prestaría mayor atención porque se trata de los directorios que monta el Kernel y que como todos sabemos, están en constante cambio. Sin embargo, las otras dos rules names marcadas por un asterisco sí vamos a estudiarlas con detalle.

 

Descripción de Rules Names

Como no, aparece nuestro fichero /etc/hosts que hemos modificado adrede y por sorpresa, muestra el /root/.viminfo. Entonces, vamos a explicar lo que debemos hacer casi de una forma matemática.

Todo fichero modificado es sospechoso siempre que:

  1. No lo hayamos modificado nosotros.
  2. No hayamos autorizado su modificación.
  3. No han sido generados los cambios por el uso de algún software de forma automática.

 

Para todo los demás casos, hay que tomar medidas y dependiendo del nivel de seguridad (Security Level) más o menos severas o drásticas.

El caso de la modificación de /etc/hosts pertenece al primer caso, lo hicimos nosotros. El caso de /root/.viminfo se debe al tercer caso. No obstante, un buen analista de seguridad (con mode paranoic ON) echaría un vistazo.

 

Cuando tenemos claro que las modificaciones han sido realizadas o autorizadas por nosotros o se trata del comportamiento normal del software instalado, debemos consolidar estos cambios en la base de datos de Tripwire. Para ello hay dos métodos a seguir, el primero consiste en volver a analizar la integridad de nuestros datos, revisar el informe posterior y si damos nuestra aprobación, insertarlos en la base de datos y el segundo, que consiste en usar un informe ya generado y que hemos aprobado.

Para el caso de querer verificar la integridad de nuestros datos, revisar el informe y posteriormente modificar la base de datos, debemos ejecutar:

 # tripwire -m c -I 

 

Para aprovechar un informe ya validado por nosotros, tenemos que teclear:

 # tripwire -m u -r fichero.twr 

 

En ambos casos, como se ha de modificar la base de datos, nos solicitará la clave local.

 

Tarea diaria

Debido a la importancia de comprobar la integridad de nuestros sistemas, recomendamos encarecidamente que se programe una tarea diaria donde se genere el informe con los cambios que haya podido sufrir el sistema.

Para ello, deberemos editar añadir una tarea en el sistema cron de nuestro servidor, por ejemplo:

 0 3 * * * /usr/sbin/tripwire -m c 

También existe la posibilidad de añadir un script a /etc/cron.daily donde se ejecute esta operación como por ejemplo:

 
#!/bin/sh 
/usr/sbin/tripwire -m c 

 

Personalmente prefiero la primera opción ya que podemos configurar el momento que se realiza y así evitamos que se solape a tareas como las copias de seguridad, parcheos u otras modificaciones generales del sistema. Es preferible realizar el análisis en un momento que sepamos que el servidor se encuentra bastante "tranquilo", no es porque cargue la máquina, que realmente no es así, sino para evitar que obtenga unos datos muy parciales.

 

Aseguramiento de Tripwire

Por último, hay una serie de pautas que debemos seguir para asegurar nuestro sistema Tripwire.

  1. Hay que eliminar todo fichero de texto con versiones de la configuración o política. Como vulgarmente se dice, hay que evitar dar pistas al enemigo.
  2. Debemos aplicar a los binarios /usr/sbin/tripwire, /usr/sbin/twadmin, /usr/sbin/twprint y /usr/sbin/siggen los permisos de sistema 0500 (-r-x------).
  3. De la misma forma, a los directorios de configuración /etc/tripwire y de informes /var/lib/tripwire y a sus contenidos deben tener los permisos de sistema 0700 (-rwx------).
  4. Por último, se ha de aplicar permisos de sistema 0600 (-rw-------) a etc/tripwire/tw.cfg y a /etc/tripwire/tw.pol.

Para facilitar, estas son las instrucciones a ejecutar:

 
# chmod 0600 etc/tripwire/tw.cfg /etc/tripwire/tw.pol 
# chmod 0500 /usr/sbin/tripwire /usr/sbin/twadmin /usr/sbin/twprint /usr/sbin/siggen 
# chmod 0700 /etc/tripwire /var/lib/tripwire 
# chmod -R u=rwX,go-rwx /var/lib/tripwire 

Donde X será el permiso de ejecución en caso de fichero y de acceso en caso de directorio.

 

Para más información

Tripware viene con algunas páginas man que proveen una información sucinta y clara, sin ejemplos…

 

TRIPWIRE(8) - Manual del programa

TWINTRO(8) - Una introducción al Tripwire

TWADMIN(8) – Manual de la herramienta de administración

TWPRINT(8) – Manual de la herramienta de visionado de informes

TWCONFIG(8) - Información sobre el fichero de configuración

TWPOLICY(8) - Información sobre el fichero de política

 

Despedida

Os puedo asegurar y ya desde un plano profesional que esta herramienta me ha ayudado muchisimo en mis tareas de administrador y se encuentra en una de las primeras herramientas que instaldo cuando implemento un nuevo servidor.

 

Espero que os sea tan útil como a mí me lo ha sido.

, , ,

No hay Comentarios

Cómo ver las fechas y horas en los logs de Squid

Como administrador del servicio proxy Squid, estoy encantado con su funcionamiento. Sin embargo, la gestión de fechas y horas en los ficheros logs suele ser un poco molesto. Sé que se puede cambiar a nivel de configuración pero, a veces, no es posible si queremos guardar la compatibilidad con otras aplicaciones. Para ellos, hay un pequeño truco en perl para convertir de timestamp a un formato leíble por un ser humano: 

 

 

# perl -pe 's/[\d\.]+/localtime($&)/e' /var/log/squid/access.log

 

 

Como podéis observar, también puede ser utilizado en otros servicios que utilicen este tipo de fecha y al ser perl, puede ser usado en casi cualquier *ix sin problemas.

Espero que os sea tan útil como a mí me ha sido.

, ,

No hay Comentarios

Cómo enviar correos desde la línea de comandos en Perl – II

Esta entrada es una continuación de la anterior entrada. En vez de escribir nosotros mismos el cuerpo del mensaje, es nuestro programa quien lo carga a través de la entrada estándar.

#!/usr/bin/perl -w

$TO = $ARGV[0];
$SUBJECT = $ARGV[1];
@auxMSG = <STDIN>;

# Extraemos el contenido de la rediccion
$MSG="";
foreach $tmpMSG (@auxMSG) {
        $MSG = $MSG . $tmpMSG;
}

# Solo debug
#print "TO: " . $TO . "\n";
#print "SUBJECT: " . $SUBJECT . "\n";
#print "MSG:\n" . $MSG . "\n";


# Enviamos el correo
open (MAIL,"|/usr/lib/sendmail -t");
        print MAIL "To: ". $TO . "\n";
        print MAIL "From: servidor\@dominio.com\n";
        print MAIL "Subject: " . $SUBJECT . "\n\n";
        print MAIL $MSG . "\n";
close(MAIL);

exit(1);

Espero que os sea de utilidad.

, , , ,

No hay Comentarios

Cómo enviar correos desde la línea de comandos en Perl – I

Siempre tenemos algún servicio que necesita poder enviar un correo para avisarnos de alguna incidencia. Lamentablemente en algunos *ix comerciales, tienen la mala costumbre de tener algunos comandos antidiluvianos cuyas interdependencias con servicios modificados por el fabricante, hace que no siempre funcione como queramos.
Como este tipo de cosas no debe detenernos en nuestra labor de administración, os propongo este simple script en Perl que espero os sea útil.

Por cierto, como estoy más que cansado que no se pueda enviar más de una línea, en especial, cuando requerimos más información para realizar un troubleshooting, el script permite enviar diferentes líneas de texto.

#!/usr/bin/perl -w

# Salgo si no me llegan todos los parametros
$num_args = $#ARGV + 1;
if ($num_args != 3) {
        print "\nUso: enviar_correo.pl TO SUBJECT MSG.\n";
        print "TO: Destinatario o destinatarios unidos por coma.\n";
        print "SUBJECT: Asunto del correo electronico entre dobles comillas.\n";
        print "MSG: Cuerpo del mensaje entre comillado doble y \\n para los retornos de carro.\n\n";
        exit;
}

# Convertimos nuestro retorno de carro en un verdadero retorno de carro
$MSG =~ s/\\n/\n/g;

# Solo debug
#print "TO: " . $TO . "\n";
#print "SUBJECT: " . $SUBJECT . "\n";
#print "MSG:\n" . $MSG . "\n";


# Enviamos el correo
open (MAIL,"|/usr/lib/sendmail -t");
        print MAIL "To: ". $TO . "\n";
        print MAIL "From: servidor\@dominio.com\n";
        print MAIL "Subject: " . $SUBJECT . "\n\n";
        print MAIL $MSG . "\n";
close(MAIL);

exit(1);

Esta es una forma de hacerlo, si tienes una mejor, compártela con nosotros y entre todos podemos aprender.

, , , ,

No hay Comentarios

DNS con vistas empleando el esquema maestro/esclavo

Más de una vez, nos hemos encontrado con una red que tiene varios dominios configurados en distintos servidores DNS utilizados para diferentes usos. El caso más habitual es un dominio para uso interno y otro para externo. Además, si la red es amplia y compleja, se puede afirmar que llega a niveles donde administración resulta engorrosa e insegura en según qué casos. En este post, vamos a demostrar que esta opción es actualmente innecesaria y vamos a aportar por la racionalización y simplificación del uso del servicio DNS.

En la mayoría de los casos, lo más eficaz consiste en gestionar una misma denominación de dominio y mostrar lo que queramos según quién nos lo pida. Para ello, utilizaremos vistas que son las encargadas de mostrar una información determinada según la red o la IP que solicite la información. Suele haber dos vistas, una externa -para Internet- y otra interna para sus redes privadas. Generalmente la diferencia entre ambas, será que la primera contendrá la información justa y precisa de aquellos servicios publicados en Internet y la segunda es que añadirá a esa información, los nombres de hosts o los servicios internos.

Para el desarrollo de este post, indicaremos los datos de ejemplo con los que partimos.

  • Dominio: dominio.com.
  • idor de DNS principal: ns1.dominio.com cuya IP es x.y.1.1.
  • Servidor de DNS secundario: ns2.dominio.com cuya IP es x.y.1.2.
  • Red DMZ: x.y.1.0/27.
  • Red Interna: 192.168.1.0/24.

 

La configuración en cuento a vistas será la siguiente:

  • Vista externa: Gestiona las zonas dominio.com y el rango inverso x.y.1.0/27.
  • Vista interna: Gestiona las zonas dominio.com, el rango inverso x.y.1.0/27 y 192.168.1.0/24.

 

Con respecto a la jerarquía DNS, el servidor ns1 tendría configuradas las zonas descritas anteriormente como maestras y el servidor ns2, a su vez, las esclavas.

Parémonos a pensar un poco y centrémonos en un detalle. Si en el servidor ns1 tengo configurada la zona dominio.com en la vista interna y externa, ambas con información diferente y yo quiero tener en mi servidor ns2, que también posee ambas vistas y la configuración de la zona dominio.com, los mismos datos que en el servidor ns1, lo lógico es pensar en que la relación del servidor ns1y ns2 debe ser de maestro/esclavo. De hecho, en los casos que no hay vistas, se hace así y es una de las soluciones más cómodas y simples que hay.

Debemos recordar que las vistas ofrecen unas determinas zonas con su correspondiente configuración según la IP de origen de la petición. En este caso, el peticionario, nuestro servidor ns2 tiene la misma IP en ambas solicitudes de transferencia de la zona dominio.com de la vista interna y la misma zona por la vista externa. Por lo tanto, cuando el servidor ns1 recoge la petición de transferencia, analiza esta IP y selecciona una vista. En ambas peticiones al ser la misma IP, seleccionará la misma vista y nos encontraremos que el servidor ns2 tiene configurada la zona dominio.com en ambas vistas con los mismos datos.

Si el problema es la IP, el servidor ns2 deberá contar con una adicional, generalmente se añade un alias y en este caso, será x.y.1.3. Esta IP sólo tiene la misión de ser diferenciadora, de la habitual. Entonces, en el servidor ns1, indicaremos una vista que se encuentre la habitual y en la otra, la diferenciadora. De la misma forma, en el servidor ns2, configuraremos que una vista solicite la transferencia de datos por una IP, y la otra vista, por la IP restante. De esta forma, tendremos una jerarquía maestro/esclavo con vistas.

Y ahora vamos al lío. En mi caso, uso GNU/Debian 6.0 y su última versión de Bind 9, por lo tanto, lo que indico a continuación es propio de esta versión de GNU/Linux. Sin embargo, en otras versiones, puede estar todo en un mismo fichero o separado de otras formas. Os ruego que leáis la documentación de vuestra distribución en lo que respecta al servidor DNS.

La configuración de los servidores se vertebra de la siguiente forma:

  • Esqueleto:
    • /etc/bind/named.conf: Fichero principal donde se indica:
      • La inclusión del fichero de opciones /etc/bind/named.conf.options.
      • Las vistas y sus correspondientes ficheros locales de zonas: /etc/bind/named.conf.local.externo y /etc/bind/named.conf/local.interno.
    • /etc/bind/named.conf.options: Fichero de opciones donde se indica:
      • Las opciones del comportamiento del servidor.
      • La declaración de claves privadas.
      • La correspondencia entre los servidores y las claves privadas que han de emplear para poder transferir las zonas.
      • Las asociaciones de nombres a rangos o IP concretas.
    • /etc/bind/named.conf.local.*: Son los ficheros donde se declaran las zonas a gestionar que pueden ser maestras o esclavas.
  • Ficheros de zonas: Se encuentran en /var/cache/bind/[VISTA]/db.[ZONA]. Siendo [VISTA], el nombre de la vista, externo o interno y [ZONA] el dominio o el rango inverso en cuestión.
    Se recuerda que sólo puede modificarse el fichero de zona cuando está configurada como maestra.

He aquí el fichero /etc/bind/named.conf del servidor ns1:

 

include "/etc/bind/named.conf.options";
view interno {
    match-clients { 127.0.0.1; red_dmz; red_interna; !ns2_2; };
    recursion yes;
    include "/etc/bind/named.conf.local.interno";
};
view externo {
    match-clients { any; };
    recursion yes;
    include "/etc/bind/named.conf.local.externo";
};

En la línea 1, se indica que ha de incluir la configuración del fichero /etc/bind/named.conf.options.

En las líneas 2 y 7, la directiva view declara la nueva vista. Dentro de la cual, hay tres partes que se han definido, dos obligatorias y una opción.

De las obligatorias, en la línea 3 y 8, la directiva match-clients indica para qué IP y rangos mostrará la vista. El servidor DNS usa la IP del cliente DNS para identificar en qué vista ha de mostrarse. Hay que tener en cuenta que la oferta de vistas irá desde la más restrictiva a la más general. Por ello, la vista interna tiene configurada todos los rangos de red y la externa, cualquier cosa.

En este caso, en la línea 3, además, aparece !ns2_2. La aparición del símbolo ! antes de una IP o un rango, indica su negación. Tal como se mencionó en el método de transferencia de zonas cuando existen vistas, tiene que haber una IP determinada que haga responder a cada vista para cuando el servidor ns2 solicite la transferencia de las zonas, el servidor ns1 sepa diferenciar las zonas por vistas.

En las líneas 5 y 10, aparecen los ficheros donde estarán declaradas las zonas y su naturaleza dentro del DNS.

El fichero /etc/bind/named.conf.options del servidor ns1:

options { 
    directory "/var/cache/bind"; 
    auth-nxdomain no; # conform to RFC1035 
    recursion no; 
    dnssec-enable yes; 
    dnssec-validation yes; 
    version "null"; 
    allow-transfer { none; }; 
    allow-query { any; }; 
}; 

key ns1-ns2 { 
    algorithm hmac-md5; 
    secret "20dlLuH1GRpUb3uPttvRlA=="; 
}; 

server x.y.1.2 { 
    keys { ns1-ns2; }; 
}; 

acl red_dmz { 
    x.y.1.0/27; 
}; 

acl red_interna { 
    192.168.1.0/24; 
}; 

acl ns2_2 { 
    x.y.1.3/32; 
}; 

En la línea 1, la directiva options encierra en su ámbito –hasta la línea 10- la configuración general de comportamiento del servidor DNS.

En la línea 12, la directiva key define una clave privada que será usada para la encriptación de la transferencia de zona.

En la línea 17, la directiva server vincula a cada servidor con la clave privada previamente definida. Esto se debe realizar en cada servidor que vaya a recibir una transferencia de zona vía encriptación.

En la línea 21, 25 y 29, la directiva acl permite asociar un nombre a un rango de IP o IP concretas. Sólo aporta mayor claridad en la configuración y mejora su documentación.

He aquí el fichero /etc/bind/named.conf.local.externo concerniente a la vista externa del servidor ns1:

zone "dominio.com" in { 
    type master; 
    file "externo/db.dominio.com"; 
    allow-transfer { key ns1-ns2; }; 
}; 

zone "1.y.x.in-addr.arpa" in { 
    type master; 
    file "externo/db.x.y.1"; 
    allow-transfer { key ns1-ns2; }; 
};

En la línea 1 y 7, la directiva zone declara la zona.

En las líneas 2 y 8, la directiva type indica la naturaleza de la zona, siendo en este caso de tipo maestra. Al ser así, podemos modificarla y se transmitirán los cambios al resto de servidores DNS.

En las líneas 3 y 9, la directiva file indicará donde está ubicado el fichero de la zona. Tal como se vio anteriormente, el directorio base se ha establecido en /var/cache/bind.

En las líneas 4 y 10, la directiva allow-transfer indica a qué servidores y qué claves utilizar para la transferencia de zona. En este caso, al servidor ns2 y se emitirá encriptado.

He aquí el fichero /etc/bind/named.conf.local.interno concerniente a la vista interna del servidor ns1:

zone "." { 
    type hint; 
    file "/etc/bind/db.root"; 
}; 

zone "dominio.com" in { 
    type master; 
    file "interno/db.dominio.com"; 
    allow-transfer { key ns1-ns2; }; 
}; 

zone "1.y.x.in-addr.arpa" in { 
    type master; 
    file "interno/db.x.y.1"; 
    allow-transfer { key ns1-ns2; }; 
}; 

zone "1.168.192.in-addr.arpa" in { 
    type master; 
    file "interno/db.192.168.1"; 
    allow-transfer { key ns1-ns2; }; 
}; 

En la línea 1 y 2, aparece la zone “.” y el tipo hint. Esta declaración de zona permite al servidor DNS buscar otros dominios ajenos a los que gestiona en Internet.

He aquí el fichero /etc/bind/named.conf del servidor ns2:

include "/etc/bind/named.conf.options"; 
view interno { 
    match-clients { 127.0.0.1; red_dmz; red_interna; }; 
    recursion yes; 
    transfer-source x.y.1.2; 
    include "/etc/bind/named.conf.local.interno"; 
}; 
view externo { 
    match-clients { any; }; 
    recursion yes; 
    transfer-source x.y.1.3; 
    include "/etc/bind/named.conf.local.externo"; 
};

Como se puede ver, resulta similar al mismo fichero ubicado en el servidor ns1. Las dos únicas diferencias y que están relacionadas entre sí, se van a señalar a continuación:

  1. En la línea 3, no aparece !ns2_2  y se debe a dos razones. La primera es que interesa que la vista interna tenga alcance a todas las redes. La segunda, es que en el servidor ns1, se ha excluido dicha IP para poder transferir las zonas coincidentes de ambas vistas entre ambos servidores.
  2. En la línea 5 y 11, aparecen las IP desde las cuales invocarán al servidor ns1 para recibir una copia de las zonas. La IP x.y.1.2 es la IP de gestión y se utiliza para recibir las peticiones DNS y la transferencia de las zonas internas. La IP x.y.1.3 es la IP adicional (alias) mencionada al principio del documento, que se ha denominado ns2_2 y que se ha excluido en el servidor ns1 como IP interna. De esta forma, podrá recibir la transferencia de las zonas externas.

 

El resto de los ficheros de configuración son iguales al servidor ns1 exceptuando los ficheros de configuración de zonas, que todas serán del tipo esclavas -líneas 2, 8 y 14, tal como aparecen a continuación:

zone "dominio.com" in { 
    type slave; 
    file "interno/db.dominio.com"; 
    masters { x.y.1.1; }; 
}; 

zone "1.y.x.in-addr.arpa" in { 
    type slave; 
    file "interno/db.x.y.1"; 
    masters { x.y.1.1; }; 
}; 

zone "1.168.192.in-addr.arpa" in { 
    type slave; 
    file "interno/db.192.168.1"; 
    masters { x.y.1.1; }; 
};

Como se puede ver, en las líneas 4, 10 y 16, el emisor de la transferencia de la zona es el servidor ns1.

 

Esta es una solución que he aplicado pero seguramente haya más, espero vuestros comentarios a fin de que aprendamos todos.

, , , , ,

No hay Comentarios

Uso del Mondo Rescue para una recuperación tras desastre

Tal como comentaba en la anterior entrada, Mondo Rescue es una herramienta fantástica para realizar una copia de cara a una recuperación tras desastre o simplemente para clonar la máquina. El problema de esto es como todo, su automatización y de eso voy a hablar en esta entrada.

Antes de hacerlo, quisiera dar un par de pinceladas sobre la implementación de Mondo Rescue. Debo afirmar que su instalación es verdaderamente sencilla. De hecho sólo hay que entrar en su página principal y bajarse los paquetes para nuestra distribución o el Tarball si nuestro interés es compilarlo.

Que sea sencilla la instalación, no significa que no esté exento de problemas el uso de la herramienta. En el caso de Debian, no hay mantenedor oficial dentro de la distribución y no es la primera vez que el paquete de Mondo Rescue no cumple o no tiene recogidos los últimos cambios aparecidos. Menos mal que tienen unas buenas listas de distribución en su página de soporte y que nos puede ayudar a salvar las dificultades que nos pasen.

Ahora vamos al lio. Por motivos laborales, yo tengo automatizadas las copias de seguridad de Mondo Rescue. Dichas copias quedan almacenadas en un sistema de ficheros del cual realizo copia de seguridad con otro producto (un servicio centralizado y global de copias de seguridad). Cuando debo restaurar una máquina, lo único que hago es recuperar la imagen en cuestión en otro servidor GNU/Linux, subir esa imagen a mi datastore y en 15 a 20 minutos tengo otra vez el servidor en producción. Además, ese es el motivo que justifica que cree imágenes DVD y no un fichero con toda la información del sistema a copiar. En ese caso, mi software de virtualización chirria bastante y le cuesta reconocerlo como DVD válido.

Lo primero que hago en cada servidor que voy a poner en producción es crear los siguientes directorios:

/etc/mondo que estará destinado a albergar automondo.conf, el fichero de configuración de Mondo Rescue.

/opt/mondo/images donde se almacenarán las copias de seguridad.

/opt/mondo/temp que será empleada en la creación de los ficheros temporales de los cuales Mondo Rescue generará las imágenes del sistema.

Una pequeña nota informativa, el nombre y ubicación de estos directorios los he decidido yo, podéis cambiarlos sin mayor problema para ajustarlo a vuestras necesidades o gustos.

Quiero advertiros que tengáis en cuenta el espacio a la hora de determinar las unidades donde almacenaréis las copias de seguridad y donde se generarán los temporales. La copia de seguridad se hace de la información que tenga los sistemas de ficheros en vivo. Dicho de otra forma, podéis tener 100 Gb de disco duro pero si tenéis 5 Gb de información, vuestra copia de seguridad será de 5 Gb. Ahora bien, si vuestra partición tiene en uso 5 Gb y su tamaño global es de 8 Gb, no tendréis espacio suficiente para realizar la copia de seguridad y lo más probable es que colapséis el sistema por ocupar todo el sistema de ficheros. No es exacta pero la regla que empleo es la siguiente, la partición donde almaceno los temporales y las imágenes debe ser un 120% el tamaño de la totalidad de la información a realizar la copia de seguridad. Os puedo asegurar que no es para nada trivial y que os libraréis de más de un susto.

 

El fichero de configuración es /etc/mondo/automondo.conf. Este es su contenido:

# Destino para las imagenes
#
IMG_DESTINATION="/opt/mondo/images"
# Prefijo en el nombre de las imagenes
#
IMG_PREFIX=`hostname`
# Tamaño de los iso
#
IMG_SIZE=4350m
# Directorios a excluir (proc y tal lo excluye mondo automáticamente)
#
BCK_EXCLUDE="/opt/mondo/images|/opt/mondo/temp|/tmp|/var/tmp|/lost+found"
# Directorio temporal
#
TMP_DIR="/opt/mondo/temp"

Como podéis observar, el fichero contiene diferentes variables que emplearemos para invocar el ejecutable de Mondo Rescue, mondoarchive. Las dos únicas variables que quiero comentar, son las siguientes: IMG_PREFIX y BCK_EXCLUDE. La primera determina cómo habrán de llamarse los ficheros que genere Mondo Rescue. Personalmente prefiero que se llamen como el nombre de la máquina. Hay gente que aparte de eso, le añade la fecha de cuando realiza la copia de seguridad. Todas las opciones son válidas pero lo que sí recomiendo y aunque parezca una peregrullada, no es lo habitual, que quede perfectamente distinguida la máquina en cuestión. La segunda variable indica los directorios que serán excluidos de la copia de seguridad. Personalmente excluyo los directorios temporales tanto del sistema operativo como de Mondo Rescue así como también donde almacena sus imágenes. A esos directorios, siempre añado aquellos directorios de logs proveniente de aplicaciones que por su naturaleza sean voluminosos y no aporten nada. Tened en cuenta que es espacio que deberéis almacenar y tiempo empleado para copiar y restaurar una copia que no os servirá de nada.

En vez de usar el ejecutable mondoarchive, creo el script automondo. Este es su contenido:

#!/bin/bash
# Cargamos la configuracion (si existe)
#
CONFIG_FILE=/etc/mondo/automondo.conf
if [ -e $CONFIG_FILE ]
then
    . $CONFIG_FILE
fi

# Cargamos valores por defecto (en caso de que no exista CFG o falten parametros)
if [ -z "$IMG_DESTINATION" ]
then
    IMG_DESTINATION=/opt/mondo/images
fi

if [ -z "$IMG_PREFIX" ]
then
    IMG_PREFIX=`hostname`
fi

if [ -z "$IMG_SIZE" ]
then
    IMG_SIZE=4350m
fi

if [ -z "$BCK_EXCLUDE" ]
then
    BCK_EXCLUDE="/opt/mondo/images|/opt/mondo/temp/|/tmp|/var/tmp|/lost+found&quot"
fi

if [ -z "$TMP_DIR" ]
then
    TMP_DIR="/tmp"
fi

# Creamos el destino si no existe
if [ ! -d $IMG_DESTINATION ]
then
    mkdir $IMG_DESTINATION
fi

# Creamos el temporal si no existe
if [ ! -d $TMP_DIR ]
then
    mkdir $TMP_DIR
fi

# Eliminamos viejas imagenes
rm $IMG_DESTINATION/*.iso

# Invocamos el asunto...
echo -e \n | /usr/sbin/mondoarchive -O -d $IMG_DESTINATION -p $IMG_PREFIX -i -E "$BCK_EXCLUDE" -N -s $IMG_SIZE -9 -T "TMP_DIR" -S "$TMP_DIR" -I "/"

El script es muy sencillo, en realidad lanzamos el ejecutable mondoarchive con los parámetros designados en el fichero de configuración automondo.conf, como dije antes. Sin embargo, si por lo que sea, no lo encontrarse, este script cargaría una configuración básica para realizar la copia de seguridad. La versión original del script fue localizada en una de las listas de correo de Mondo Rescue, obviamente se le han cambiado cosas, entre ellas que cada vez que se ejecuta, elimina las imágenes anteriores para evitar sobrecargar el servidor.

Por último, creo una entrada en el crontab de mi sistema para que se ejecute una vez al mes. Por ejemplo como esta:

05 25 * * /usr/sbin/automondo

En otras palabras, se ejecutará a las cinco de la mañana todos los 25 de cada mes. Esta es la configuración idónea para mí. Otra cosa es que vosotros deberéis ajustarla a vuestras ventanas de backup y jornadas de trabajo.

En resumen, así es cómo realizo las copias de seguridad automáticas. De hecho estos scripts me sirven para cuando debo parchear el servidor y hay cambios importantes o cuando quiero clonar una máquina, lo lanzo cuando quiero y obtengo una imagen muy cercana al original.

 

Espero que os sea tan útil como a mí me ha sido.

 

P.d.:

Los scripts han sido bajados de páginas de foros de Mondo Rescue y debidamente modificados para ser usados en mi plataforma. No puedo citar exactamente sus urls, pero quiero agradecer a todos aquellos usuarios de Mondo Rescue que han contribuido en que todos podamos usar esta magnífica herramienta.

, , ,

No hay Comentarios

Recuperación tras desastre en GNU/Linux

Hay herramientas que te salvan la vida, al menos la profesional. Son gratuitas, funcionales y especialmente útiles por su versatilidad. Mondo Rescue pertenece a ese grupo. Con ella, he recuperado servidores en producción que bien por una actualización indebidamente instalada, bien por un fallo físico en el disco duro, bien porque las meigas haberlas haylas… murieron prematuramente. Y como más de un sufridor administrador de sistemas, parece que basta con que se caiga un servidor para que todos los usuarios necesiten de él, por lo que es importante tener un procedimiento de recuperación fiable, garantizable y en especial, rápido. Antes he dicho que se trata de una herramienta muy versátil y os explicaré por qué. La he utilizado para clonar servidores de producción y crear maquetas donde probar actualizaciones radicales o instalarle servicios de los que no me encontraba seguro de cómo quedarían.

Hay más de uno que dirá, ¿por qué no usar un software privativo del tipo Networker? La verdad sea dicha, un sistema no excluye a otro. Al contrario, cuantas más alternativas haya, mejor. Sin embargo mi experiencia con este tipo de software es muy particular. Para datos de usuario y base de datos, los recomiendo y utilizo a diario. Para preparar un sistema de recuperación tras desastre, muchos de ellos se han mostrado muy lentos. De hecho, casi se podría decir que la única ventaja que veo, consiste en que hay una gran empresa cuyo soporte garantiza la recuperación de la copia de seguridad siempre que se haya seguido sus procedimientos y se realicen sobre productos certificados. Lo que en otras palabras significa mucho dinero. Así que Mondo Rescue me permite realizar copias de seguridad destinadas a recuperar un servidor en caso de desastre gratuitamente.

He de admitir que siempre me preocupan los tiempos de recuperación pero en la mayoría de los software que he utilizado, siempre he debido realizar los siguientes pasos:

  1. Preparación del nuevo servidor.
  2. Formateo del disco duro donde irá ubicado el sistema operativo.
  3. Instalación del sistema operativo del servidor caído.
  4. Elevar el nivel de actualización hasta donde se encontraba el servidor caído. Lo que exige una buena política de actualizaciones y de inventario de software.
  5. Instalación del agente del software de backup donde tengamos una copia del servidor con la correspondiente política.
  6. Restaurar el sistema operativo. Esta operación puede ser muy lenta dependiendo del medio que se emplee en la copia de seguridad.

El punto 1, en la mayoría de las ocasiones, no está en nuestras manos. El punto 2, dependiendo del tamaño, del tipo de sistema de ficheros y del tipo de formateo, puede resultar eterno. Eterno puede parecer una exageración, pero Einstein tenía razón y el tiempo es relativo, sobre todo lo que se alarga cuando la presión de jefes y compañeros actúa. El resto de puntos, dependerá del sistema operativo, las actualizaciones, los anchos de banda, la velocidad del hardware y cierta dosis de suerte para que no falle nada de los servicios y sistemas implicados. Os contaré un secreto, los Reyes Magos no existen, pero Murphy es íntimo de todo CPD que se precie.

Mondo Rescue facilita, simplifica y garantiza la recuperación en una ventana más corta. Mucho más corta ya que substituye los puntos 3 al 6, por uno: La restauración del sistema operativo tal como se encontraba en el momento de la copia. Y a pruebas me remito, un servidor GNU/Debian 6.0 con servicio proxy web Squid 3 y de DNS Bind 9 que ocupaba en el disco duro cerca de 12 Gb, utilizando un software privativo he tardado ocho horas, con Mondo Rescue una hora.

Mondo Rescue emplea un método de sistema de copia de seguridad simple pero eficaz. Crea unos ficheros ISO (dependiendo de la información a copiar) que contendrá lo siguiente:

  • Un sistema operativo GNU/Linux con la configuración del servidor en cuestión. Se puede adaptar perfectamente a nuestro hardware y configuración, no obstante, en la mayoría de los servidores, la configuración por defecto es más que válida.
  • Una copia de la geometría de los discos duros. Es verdaderamente importante porque si recuperamos en los mismos discos duros, la restauración es automática y no debemos preocuparnos más que de cambiar los CD o DVD cuando nos lo pida. En caso de un leve cambio, caso muy normal si substituimos un disco duro dañado por otro, nos obligará a adaptar los tamaños de las diferentes particiones.
  • Una copia de los datos de los discos duros de nuestro servidor. Emplea diferentes herramientas para crear unos ficheros contenedores con las aplicaciones y datos de una forma optimizada y comprimida (opcionalmente).

Estos archivos ISO puede ser grabados en CD, en DVD, almacenados vía NFS o en el disco duro. Personalmente, yo lo que hago es generar estos ficheros ISO sobre el disco duro y llevarlos a un repositorio. Si tienes servidores físicos, lo grabarás en CD o DVD cuando sea preciso y si usas un software de virtualización como VMware, lo subirás al correspondiente datastore.

Estas copias, además de poder ser utilizadas para recuperar un servidor en producción, como decia antes, podia ser utilizados para crear maquetas para probar software o planificar migraciones.

En esta entrada, he pretendido realizar una presentación de la herramienta, los usos que le doy, sus ventajas con respecto a software de copia de seguridad más centralizados y globales y por último, cómo procede a realizar las copias de seguridad. En futuras entradas, os mostraré cómo realizar copias de seguridad e incluso automatizarlas.

 

, , ,

No hay Comentarios