OpenSSL y cómo utilizarlo para la transformación de certificados.

Trabajar con OpenSSL suele ser complejo por su abundancia de parámetros y, a veces, necesitamos saber solamente cómo conseguir diferentes operaciones.

He aquí algunas operaciones simples que espero puedan ser útiles para vosotros:

 

Pasar de DER a PEM:

openssl x509 -in Certificado.der.cer -inform der -outform pem -out Certificado.pem.cer

 

Ver certificado DER:

openssl x509 -in Certificado.cer -text -noout -inform der

 

Ver certificado PEM:

openssl x509 -in Certificado.pem.cer -text -noout

 

Extraer el certificado:

openssl pkcs12 -in Certificado.p12 -out Certificado_Publica.pem -clcerts -nokeys

 

Extraer la clave privada:

openssl pkcs12 -in Certificado.p12 -out Certificado_Privada.pem -nocerts -nodes

 

Exportar PKCS#12 a PEM (ambas partes) y añade contraseña:

openssl pkcs12 -in Certificado.p12 -out Certificado_Ambas_con_Clave.pem -passout pass:Clave1

 

Generar PKCS#12 con CA y con clave:

openssl pkcs12 -export -in Certificado_Publica.pem -inkey Certificado_Privada.pem -CAfile FNMT.ca  -name "CCA" -passout pass:Clave1 -out Certificado_Todo_con_clave.p12

 

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

Comparte:
  • Print
  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • LinkedIn
  • Meneame
  • Twitter
  • PDF
  • email
  • RSS
  • Add to favorites

SFTP Enjaulado

Tenemos que desterrar el servicio de FTP en favor de SFTP. Por eso, aquí describo cómo montar un servicio SFTP enjaulado donde los usuarios puedan subir y bajar su información exclusivamente.

Primeramente creamos una estructura de directorios para alojar a los usuarios de SFTP y fijamos los permisos tal como aparece a continuación:

mkdir /home/sftponly
chown root.root /home/sftponly
chmod 755 /home/sftponly/

Después creamos un grupo donde cobijaremos a los usuarios.

groupadd sftponly

Seguidamente, crearemos un usuario, que cumpla las siguientes características:

  • El directorio home debe encontrarse dentro de la estructura /home/sftponly, seguido del nombre del usuario 'usuario1' y un directorio que emplearemos para intercambiar ficheros, en este caso 'informacion'.
  • El grupo debe ser sftponly.
  • La shell debe ser /bin/false, de forma que no pueda acceder directamente a consola.

mkdir /home/sftponly/usuario1
useradd -d /home/sftponly/usuario1/informacion -m -g sftponly -s /bin/false usuario1
passwd usuario1

A continuación, editaremos el fichero /etc/ssh/sshd_config y añadiremos si lo queremos enjaular por grupo:

Match Group sftponly
        ChrootDirectory /home/sftponly/usuario
        ForceCommand internal-sftp
        AllowTcpForwarding no
        X11Forwarding no

En caso de quererlo enjaular por usuario:

Match Group usuario1
        ChrootDirectory /home/sftponly/usuario1
        ForceCommand internal-sftp
        AllowTcpForwarding no
        X11Forwarding no

Debemos reiniciar el servicio después de añadir estas opciones de configuración:

/etc/init.d/sshd restart

El usuario cuando acceda, subirá y bajará documentos de su carpeta de datos en /home/sftponly/usuario1/datos sin poder subir de nivel.

Comparte:
  • Print
  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • LinkedIn
  • Meneame
  • Twitter
  • PDF
  • email
  • RSS
  • Add to favorites

VMware: ¿Cómo añadir un disco duro a una máquina virtual Linux sin reiniciar?

 

Más de una vez tenemos que añadir un disco duro "en caliente" a una máquina virtual creada por nuestro hipervisor. En nuestro caso usamos VMware, pero esto es aplicable a otros productos.

El problema que nos surge es, ¿cómo podemos hacerlo sin reiniciar un servidor en producción?

La solución reside en volver a escanear el bus SCSI.

Para ello, primero localizaremos qué host tenemos disponible.

ls /sys/class/scsi_host

Acto seguido, elegiremos el host donde está el disco duro y ejecutaremos:

echo "- - -" > /sys/class/scsi_host/host1/scan

De esta forma, ya tendremos disponible el disco duro sin reiniciar.

 

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

Comparte:
  • Print
  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • LinkedIn
  • Meneame
  • Twitter
  • PDF
  • email
  • RSS
  • Add to favorites

MySQL: Trabajando con ficheros CSV

Hace tiempo publicamos una entrada sobre la recolección de registros –logs– de todos los servidores en una base de datos de MySQL, cosa que le vino bien a más de un lector de este blog. Sin embargo, pronto apareció la otra cara de la moneda, ¿qué hacer con una tabla cuyos contenidos son quilométricos?

Hemos empezado con dando un contexto pero lo importante es cómo vamos a responder a la pregunta. Existen muchas formas de encarar el problema así que espero que os pueda servir la mía. En la tabla en cuestión, tengo almacenada la fecha y hora de inserción en uno de los campos, por lo tanto, me creo una condición en la cual indico que si en este campo contiene cierta parte de la fecha, me exporte los datos a un fichero CSV y luego los elimino de la tabla de MySQL. De esta forma, conseguimos "adelgazar" la tabla de registros históricos que no voy a necesitar a corto plazo y si luego quiero procesar el contenido, pueda emplear la herramienta que me sea más útil.

El enfoque que le hemos dado ha sido el de crear un script en vuestra shell preferida en aras de automatizar el proceso, sin embargo, si a alguien no le gusta, también ponemos un ejemplo de cómo ejecutar instrucciones empleando el comando mysql.

Por otro lado, también con ánimo de aclarar qué es nomenclatura de SQL y cuáles son los parámetros, estos últimos aparecen entre llaves.

 

El primer paso, es cómo exportar los registros que cumplan una determinada condición a un fichero CSV.

Caso general:

/usr/bin/mysql -u{USUARIO} -p{CLAVE} {BASE DE DATOS} -e "SELECT * INTO OUTFILE '{FICHERO}' FIELDS TERMINATED BY ';' LINES TERMINATED BY '\n' FROM {TABLA} WHERE {CONDICIÓN}"

Caso particular:

/usr/bin/mysql -usyslog_export -pclave Syslog -e "SELECT * INTO OUTFILE registros_logs_junio.csv FIELDS TERMINATED BY ';' LINES TERMINATED BY '\n' FROM SystemEvents WHERE ReceivedAt LIKE '2012-06%'

Para evitar problemas de seguridad, es preferible crear un usuario con los permisos restringidos. El usuario que empleo en cuestión, sólo tiene permisos de SELECT, INSERT, UPDATE y FILE sobre la tabla a trabajar. De la misma forma, el script que creemos ha de tener los permisos justos y necesarios para poder ser ejecutado por el usuario de sistema designado sin que el resto vea su contenido.

 

El segundo paso consiste en eliminar los registros que hemos exportado al fichero CSV:

Caso general:

/usr/bin/mysql -u{USUARIO} -p{CLAVE} {BASE DE DATOS} -e "DELETE FROM SystemEvents WHERE {CONDICIÓN}"

Caso particular:

/usr/bin/mysql -usyslog_export -pclave Syslog -e "DELETE FROM SystemEvents WHERE ReceivedAt LIKE '2012-06%'"

Como podemos observar, hemos cambiado SELECT por DELETE y hemos empleado la misma condición.

 

El tercer paso es opcional, si como en nuestro caso, eliminamos cerca de cinco millones de registros, debemos optimizar la tabla para evitar la fragmentación y que siga siendo ágil cuando necesitemos hacer consultas.

Caso general:

/usr/bin/mysql -u{USUARIO} -p{CLAVE} {BASE DE DATOS} -e 'OPTIMIZE TABLE {TABLA}'

Caso particular:

/usr/bin/mysql -u{USUARIO} -p{CLAVE} {BASE DE DATOS} -e 'OPTIMIZE TABLE SystemEvents'

 

Ahora bien, ¿qué pasa si debemos cargar los datos que hemos exportado? Pues debemos importarlos desde el fichero CSV de esta forma:

# mysql -u{USUARIO} -p{CLAVE} {BASE DE DATOS}

> LOAD DATA INFILE ' registros_logs_junio.csv' INTO TABLE SystemEvents FIELDS TERMINATED BY ';' LINES TERMINATED BY '\n';

Si la carga de registros es voluminosa, volvemos a recomendar optimizar la tabla tal como hicimos antes.

 

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

Comparte:
  • Print
  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • LinkedIn
  • Meneame
  • Twitter
  • PDF
  • email
  • RSS
  • Add to favorites

Cómo saber el tamaño de tu datastore en VMware ESX(i)

A modo de apéndice de las anteriores entradas, si necesitamos saber el tamaño real de los discos duros virtuales alojados en un datastore concreto a través de la línea de comandos, deberemos acceder al hipervisor de VMware a través del protocolo SSH y a partir de ahí, debemos ir a la ubicación de nuestro datastore.

cd /vmfs/volumes/[DATASTORE]

 

Y ahí ejecutaremos:

find . -name "*-flat.vmdk" -print0 | xargs -0 du -h -c | tail -1

Que arrojará la siguiente respuesta:

1.2T    total

 

De esta forma, podéis realizar una contabilidad exacta de lo que ocupan los discos duros virtuales en vuestro datastore.

Comparte:
  • Print
  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • LinkedIn
  • Meneame
  • Twitter
  • PDF
  • email
  • RSS
  • Add to favorites

Cómo saber los tamaños reales de las máquinas virtuales en VMware ESX(i)

A raíz de la entrada anterior, un lector me ha preguntado cómo se puede saber el tamaño de los discos duros virtuales teniendo en cuenta que algunos están provisionados en thick y otros en thin.

La pregunta no es trivial ya que cuando utilizamos el comando ls sobre el fichero que contiene los datos del disco duro virtual -aquel que contiene la palabra flat en el nombre- siempre aparece el tamaño "en thick" sea éste thick o thin. Por lo que nos interesa saber el tamaño realmente ocupado, en especial, si hemos provisionado más espacio del existente.

Lo primero de todo es acceder al hipervisor de VMware a través del protocolo SSH. Una vez allí, debemos ir al directorio donde se encuentra nuestra máquina virtual.

 

cd /vmfs/volumes/[DATASTORE]/[MAQUINA_VIRTUAL]

 

Ahí vamos a obtener el tamaño "en thick" de los discos duros, para ello escribiremos:

ls -lah *flat.vmdk

Que nos mostraría algo así:

-rw------- 1 root root 10.0G Sep 26 11:57 PLANTILLA-flat.vmdk

 

Por lo que podemos saber que la provisión en thick son 10 G y para saber exactamente cuánto está ocupado, debemos hacer:

du -hc *-flat.vmdk

Cuya respuesta sería:

1.7G PLANTILLA-flat.vmdk

1.7G total

 

De esta forma, vemos que tenemos ocupados 1,7 Gb de los 10 Gb totales que está provisionado este disco duro virtual.

 

Si tenéis una versión 4.0 de ESXi, por ejemplo, puede ser que no tengáis el comando du, así que os diré un truco muy particular para tenerlo. VMware utiliza busybox para tener todos los comandos de uso de administración frecuente, me imagino que el motivo será por ocupar menos espacio y poder controlar mejor el comportamiento de los mismos. Entonces, en el directorio /opt/ nos bajamos el binario de la url de Busybox.

Si el hipervisor tiene salida a Internet, yo recomiendo ejecutar:

wget http://www.busybox.net/downloads/binaries/latest/busybox-i686

En caso contrario, deberás bajártelo y pasarlo a través de WinSCP.

Cuando ya tengamos el binario en /opt, debemos aplicar los permisos pertinentes:

chmod 755 busybox-686

chmod +s busybox-686

 

Para evitar incomodidades, debemos aplicar el siguiente enlace simbólico:

ln -s /opt/busybox-686 /bin/du

 

De esta forma, tendríamos el comando du habilitado para realizar correctamente los cálculos de los discos duros virtuales en thin.

 

Ruego que si alguien conoce otro método para obtener los valores desde la línea de comandos me lo haga saber para compartirlo con todos vosotros.

 

Espero que os haya sido tan útil como para mí.

Comparte:
  • Print
  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • LinkedIn
  • Meneame
  • Twitter
  • PDF
  • email
  • RSS
  • Add to favorites

VMware: Reducir el espacio migrando de Thick a Thin

En época de crisis, toca economía de guerra y eso consiste en ahorrar en licencias y en espacio. Por eso os planteo un problema real, ¿qué podemos hacer si tenemos que ahorrar espacios en nuestras máquinas virtuales dentro de un VMware con las licencias mínimas? La opción de llorar o gritar no es válida así que una de las opciones puede ser migrar los discos duros de estar provisionados de forma thick a thin.

Antes que nada, ¿qué es thick y qué es thin? A la hora de crear discos virtuales podemos optar por dos opciones:

·         Thick: Donde se creará un fichero -equivalente a nuestro disco duro virtual- con todo el tamaño indicado. En otras palabras, si decidimos tener un disco duro de 50 Gb, generará un fichero de 50 Gb.

·         Thin: Implantará un fichero con el volumen de la información que contiene y que irá creciendo hasta el tamaño indicado. Dicho de otra forma, si queremos tener un disco duro de 50 Gb pero sólo tenemos ocupado 14 Gb, el fichero sólo tendrá 14 Gb.

Estas definiciones son más "prácticas" que académicas, si se desea más información sobre ellas, os recomiendo consultar el Blog de José María González.

Hay otras recetas para ahorrar espacio, sin embargo, me he inclinado por esta, debido a que suele ser frecuente provisionar un espacio y más cuando no se conoce el crecimiento que puede tener el espacio y luego, cuando se ha consolidado, comprobar que tenemos un 40% de espacio sin usar por ejemplo.

 

El primer paso consiste en apagar la máquina virtual. Para ello, deberéis usar vSphere Client por ejemplo. Esta es una de las pocas pegas que tiene este procedimiento. Sí debemos avisaros que la velocidad con la que realicemos todo el proceso depende en gran medida del tamaño de los discos duros en cuestión y del hardware del que dispongamos.

Después de apagada la máquina virtual, debemos acceder vía protocolo SSH al hipervisor ya que actuaremos directamente en él.

Una vez en la shell, debemos acceder a nuestro datastore y al directorio donde se encuentra nuestra máquina virtual:

 
cd /vmfs/volumes/[DATASTORE]/[MAQUINA] 

Inciso: El nombre de nuestro datastore aparece en la configuración de la máquina virtual, si vemos las propiedades del disco virtual -a través del vSphere Cliente- como también podemos leer el directorio donde está ubicada la máquina. Generalmente si el servidor se llama server, el directorio se llamará SERVER.

 

Ahora lo que vamos es a clonar los discos duros actuales en sus equivalentes en formato thin para ello ejecutaremos:

 
for i in `ls | grep -v flat | grep vmdk`; 
do 
    echo "Pasando de Thick a Thin el disco virtual $i"; 
    vmkfstools -i $i -d thin thin_$i; 
done 

 

Terminada esta operación, renombraremos los discos duros virtuales originales -esos que están en formato thick– de forma que si la operación no sale como queremos, podamos volverlos a usar.

 
for i in `ls | grep -v flat | grep vmdk | grep -v thin_`; 
do 
    echo "Realizando una copia de seguridad del disco virtual thick $i"; 
    vmkfstools -E $i bckp_$i; 
done 

 

Como ya tenemos una copia de los discos virtuales originales y su versión en thin, vamos a renombrar estos últimos para que asuman el papel de los primeros:

 
for i in `ls | grep -v flat | grep thin_`; 
do 
    j=`echo $i | sed -e "s/thin_//g"`; 
    echo "Renombrando el disco virtual thin $i al original $j"; 
    vmkfstools -E $i $j; 
done 

 

En este momento, lo mejor será arrancar la máquina virtual y comprobar que el proceso ha sido correcto. En caso contrario, deberemos ejecutar:

 
for i in `ls | grep -v flat | grep bckp_`; 
do 
    j=`echo $i | sed -e "s/ bckp_//g"`; 
    echo "Renombrando el disco virtual thick $i al actual $j"; 
    vmkfstools -E $i $j; 
done 

 

Una nota para que nadie le dé un susto, dependiendo de la versión de nuestro VMware ESX(i), este cambio puede parecer que no queda reflejado en el hipervisor. Si tal es el caso, podéis eliminar la máquina virtual del inventario de VMware y volverlo a añadir.

Por cierto, si queremos ver de forma visual qué tamaños tienen los discos duros tanto los thick como los thin que se están generando, recomendamos que empleen la opción Browse Datastore de vSphere Client donde se mostrará perfectamente los tamaños.

 

Si todo hay ido correctamente, deberemos borrar los discos duros virtuales originales, aquellos que empiezan por bckp_ ya que no son necesarios y ocupan espacio:

 
for i in `ls | grep -v flat | grep bckp_`; 
do 
    echo "Eliminando el disco virtual thick $i"; 
    vmkfstools -U $i; 
done 

 

Espero que esto os sea tan útil como ha sido para mí.

Comparte:
  • Print
  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • LinkedIn
  • Meneame
  • Twitter
  • PDF
  • email
  • RSS
  • Add to favorites

Repositorios online en GNU/Debian

Al hilo de nuestra entrada "Cómo añadir repositorios públicos a Oracle Enterprise Linux", un lector nos ha realizado una serie de preguntas acerca de los repositorios de GNU/Debian. Debido a su interés general, hemos decidido publicarlas junto con nuestras respuestas.

 

Lector:¿Cuál podría ser un buen mirror para nuestros servidores?

Autor: La respuesta a esta pregunta no es sencilla porque depende de varios aspectos como son la cercanía geográfica, el tiempo de acceso y la estabilidad. En mi caso, al vivir en el sur de España, un mirror que cumplía estas características era CICA y durante estos años me ha demostrado que funcionan especialmente bien.

Otro aspecto a tener en cuenta es si accedemos a él vía el protocolo http o el protocolo ftp. Aunque no debieran de diferir mucho, el protocolo http suele ir más rápido y da menos problemas para configurar los cortafuegos, etc.

 

Lector: ¿Cómo se configura la herramienta apt-get para que obtenga los paquetes vía proxy http?

Autor: En el fichero /etc/apt/apt.conf debemos añadir la siguiente línea:

Acquire::http::Proxy "http://ProxyHTTP:Puerto";

 

Lector: ¿Qué es el fichero source.list y qué contiene?

Autor: Tal como indica el nombre, contiene una lista de fuentes –source.list– donde se proveen paquetes deb para nuestra GNU/Debian y tiene un formato característico que explicamos a continuación:

1.       Tipo de paquete: Puede haber dos opciones, deb para binarios y deb-src para fuentes.

2.       URL: Para acceder a los paquetes, debemos indicar una url servida bajo protocolo http o ftp.

3.       Distribución: Generalmente hay tres distribuciones:

a.       Estable (stable). Esta versión siempre será la vigente y está destinada a producción. Se puede substituir la palabra stable por el nombre de la versión actual de GNU/Debian. Por cierto, puede haber variantes para indicar que se tratan de paquetes de la rama estable que han sido aplicados parches de seguridad.

b.      En pruebas (testing). Normalmente se trata de versiones de paquetes a medio camino entre la versión estable y la última. Se suele utilizar para probar nuevas características en algún paquete en que estemos interesados o para uso domestico.

c.       Inestable (unstable). Está destinada a la experimentación y a conocer qué novedades o cambios puede tener la nueva versión que nos espera en GNU/Debian, por lo tanto, no tiene garantía alguna de funcionar. Como ene l caso de la distribución estable, puede ser substituida la palabra unstable por el nombre de la versión futura de GNU/Debian.

4.       Áreas que, en otras palabras, serían grupos determinados de paquetes. Suele haber tres:

a.       Main: Paquetes bajo licencia libre y que emplean otros paquetes con licencias de la misma naturaleza.

b.      Contrib: Paquetes bajo licencia libre pero que necesitan paquetes que tienen licencias privativas.

c.       Non-free: Paquetes que tienen alguna condición onerosa que restringe su uso o distribución.

 

Lector: ¿Puedes mostrar tu source.list?

Autor: Sin problemas, he aquí:

deb http://ftp.cica.es/debian/ stable main non-free contrib

deb-src http://ftp.cica.es/debian/ stable main non-free contrib

 

deb http://security.debian.org/ stable/updates main non-free contrib

deb-src http://security.debian.org/ stable/updates main non-free contrib

 

deb http://ftp.cica.es/debian/ stable-updates main non-free contrib

deb-src http://ftp.cica.es/debian/ stable-updates main non-free contrib

 

Lector: ¿Dónde puedo incluir otros repositorios como en el caso del software OpenVAS?

Autor: Lo recomendable sería crear el fichero en cuestión en /etc/apt/sources.list.d/ con un fichero que tenga el formato descrito para source.list.

 

Lector: Si añado los repositorios, ¿cómo puedo acceder a ellos y actualizar mi base de datos de paquetes?

Autor: Debes ejecutar:

# apt-get update

Si el resultado es correcto, entonces tendrás actualizada tu base de datos con todos los paquetes de tus repositorios. Si da fallo en uno de ellos, no podrás contar con sus paquetes y suele ser una situación peliaguda porque pueden ser necesarios para cumplir las dependencias de otros.

 

Lector: ¿Cómo puedo ir actualizando mi versión GNU/Debian sin problemas?

Autor: Garantías no existen pero si cada cierto tiempo vas ejecutando el comando que te indicaré más adelante, conseguirás dos objetivos. El primero es tener la distribución con todas las actualizaciones de seguridad aplicadas y el segundo es poder tener la última release de GNU/Debian. Esto último facilita y mucho el salto de una versión a otra.

# apt-get dist-upgrade

 

Espero que las respuestas a estas preguntas, os sean tan útiles como me han sido a mí.

Comparte:
  • Print
  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • LinkedIn
  • Meneame
  • Twitter
  • PDF
  • email
  • RSS
  • Add to favorites

Cómo añadir repositorios públicos a Oracle Enterprise Linux

Lo que venimos de GNU/Debian, estamos acostumbrados a utilizar los repositorios en Internet para:

1.       Instalar paquetes

2.       Actualizar paquetes (o la distribución entera)

3.       Aplicar las actualizaciones de seguridad, mejoras o algunos patch.

 

Sin embargo, Oracle Enterprise Linux (OEL) utiliza como medio de instalación de paquetes, por defecto, su DVD de instalación. Lo cual, resulta bastante engorroso cuando queremos actualizar o aplicar las actualizaciones de seguridad, etc. Por tanto, ¿cómo podemos configurar los repositorios online en OEL? y ¿qué alcance tienen?

Permitidnos contestar la segunda pregunta primero. Salvo que se adquiera una licencia y te acojas a Unbreakable Linux Network (ULN), no tendrás acceso a las actualizaciones de seguridad, mejoras y etc. Para configurar repositorios públicos que permitan instalar y actualizar paquetes, explicamos los pasos a continuación.

 

Configuración de los repositorios públicos

 # cd /etc/yum.repos.d 

# wget http://public-yum.oracle.com/public-yum-ol6.repo 

Inciso: El número que aparece el nombre del fichero indica la versión.

Por último, debemos abrir el fichero public-yum-ol6.repo y modificar el valor de enabled=0  a enabled=1 en todos aquellos que deseemos utilizar.

Con esto ya estaría preparado el sistema para usar los repositorios online.

 

Instrucciones útiles de YUM

Para comprobar qué repositorios tenemos activos:

 # yum repolist 

 

Para instalar un paquete que nos interese:

 # yum install paquete 

 

Para buscar un paquete entre los repositorios:

 # yum search paquete 

 

Para comprobar si existen actualizaciones:

 # yum check-update 

 

Para actualizar los paquetes instalados en nuestro sistema operativo:

 # yum update 

 

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

Comparte:
  • Print
  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • LinkedIn
  • Meneame
  • Twitter
  • PDF
  • email
  • RSS
  • Add to favorites

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.

Comparte:
  • Print
  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • LinkedIn
  • Meneame
  • Twitter
  • PDF
  • email
  • RSS
  • Add to favorites

En silencio, actuamos.