Archive for the 'GNU/Linux' Category

SysRq trigger

Hace mucho tiempo hice unas menciones a SysRq (Aquí la documentación oficial), pero gracias a un compañero de trabajo he descubierto el SysRq trigger, que nos permitirá ejecutar las acciones de SysRq en remoto mediante escrituras en el /proc.

echo h > /proc/sysrq-trigger; dmesg | tail -n 1
SysRq : HELP : loglevel0-8 reBoot tErm Full kIll saK showMem Nice powerOff showPc show-all-timers(Q) unRaw Sync showTasks Unmount shoW-blocked-tasks

Veamos un ejemplo de cómo reiniciar el servidor:

echo s > /proc/sysrq-trigger; echo b > /proc/sysrq-trigger

Esto sincronizará los sistemas de ficheros montados y reiniciará el servidor. Útil cuando sabes que el estado del servidor es irrecuperable sin un botonazo, y un reboot de toda la vida  no solventa nada.

Un saludo,

Sin vida

Ultimamente no paro, ando un poco hasta los huevos. Entre el curro por el día y luego de 19:00 a 22:00 dar clase, llego a casa que no me apetece ni cenar, ni preparar la cena, ni nada. Además los Sábados por la mañana he sustituido a una amistad en unas clases del MCSA, siendo este Sábado en teoría el último fin de semana que haré la sustitución. En resumidas cuentas, ahora solo tengo tiempo libre los Viernes y Sábados de tarde, y el Domingo. La verdad es que no me arrepiento ya que al fin y al cabo se aprende mucho dando clase, ya sea porque repasas cosas que tenías un poco olvidadas, porque mejoras la técnica o bien por el hecho de conocer a otros profesionales que siempre tienen algo que aportar.

Las clases que estoy dando son de la certificación LPIC2 (LPIC201 y LPIC202). Churros está dando la LPIC1 y finalmente Coto el MCSA, pero en vez de Lunes a Jueves como nosotros, los Sábados. Ahí andamos los tres, en mi caso y en el de Churros gracias a Coto que se acordó de nosotros cuando le preguntaron si conocía a alguien para dar clases.

Por lo que veo ha salido la LPIC3. Habrá que mirar el temario y ver qué se da en cada tema, ya que se habla de virtualización, seguridad, alta disponibilidad, pero ningún nombre en concreto. ¿Se dará VMWare o OpenVZ? ¿Se dará heartbeat, DRBD, LVS?

Bueno, tiempo al tiempo.

Copias de seguridad en sistemas Linux con Dar

Una decisión a la que nos enfrentamos a la hora de tener los datos respaldados es a la de qué herramienta utilizar para dicha tarea. Hasta ahora siempre he utilizado tar en mis máquinas para hacer las copias de seguridad, pero cuando el volumen de datos no son 500 MB, sino 12 GB, la cosa casca. El principal problema es que parece que tar no fue pensado para esto. El segundo es que tar es secuancial (¿Me permitís compararlo con una cinta de backup?) por lo que para descomprimir un fichero recorrerá todo el fichero hasta que lo encuentre. Este proceso son 2 horas y algo como mínimo, algo impensable a la hora de recuperar algo.

  • Dar utiliza un catálogo que incluye información como el CRC, compresión, etc de cada fichero.
  • Permite aplicar máscaras a los diferentes ficheros de la copia de seguridad permitiendo que los mp3, avi y zip, por ejemplo, no se compriman, ahorrándonos tiempo a la hora de hacer backups.
  • Hacer backups diferenciales e incrementales es muy sencillo.
  • Permite cifrar las backups con Blowfish.
  • Permite segmentar la copia de seguridad en varios trozos con el fin de grabarlos en DVD a posteriori.
  • El acceso no es secuancial, es directo, por lo que es muy rápido y cómodo extraer un fichero de la copia de seguridad.
  • Soporta ACL y atributos extendidos. Tar no lo soporta y hay que recurrir a utilidades como star.

Por lo tanto, como me ha gustado tanto esta herramienta me dedicaré a explicar un poco como hacer unas copias de seguridad y como restaurar ficheros desde la misma, así como cifrar backups.

# dar -c /mnt/Backup/Backup_Completa -R /datos -s 4400M -D -P Temporal -y9 -Z “*.gz” -Z “*.zip”

La línea anterior llamará a dar para hacer una copia de seguridad del directorio /datos y guardando el fichero de backup como /mnt/Backup/Backup_Completa en trozos de 4400 MB. La backup estará comprimida con bzip2 con un índice de compresión de 9 (-y9), excluyendo de la compresión los ficheros zip y gz (Los ficheros serán incluidos pero no comprimidos). De esta backup se excluirá completamente el directorio /datos/Temporal, pero gracias a la opción -D se creará el directorio en la copia de seguridad, aunque este esté vacio.

La copia de seguridad tardará un buen tiempo, y una vez haya finalizado podemos comprobar que se ha creado correctamente utilizando el flag -t que se ocupa de comprobar el CRC de los ficheros.

# dar -t /mnt/Backup/Backup_Completa

Ahora que tenemos la copia de seguridad completa podemos continuar haciendo copias de seguridad diferenciales o incrementales. Yo, por mi parte, prefiero las diferenciales, que aunque ocupen más espacio, son más fáciles de restaurar pues tan solo necesitamos una copia de seguridad completa y la última diferencial. Dar nos facilita la tarea a la hora de hacer backups diferenciales con el flag -A que sirve para comparar los archivos originales con una copia de seguridad ya hecha con el fin de salvar solamente los ficheros modificados desde esa copia de seguridad.

# dar -c /mnt/Backup/Backup_Lunes -R /datos -s 4400M -D -P Temporal -y9 -Z “*.gz” -Z “*.zip” -A /mnt/Backup/Backup_Completa

Con esta línea hacemos lo mismo que lo que he explicado con la línea anterior, pero almacenando la copia diferencial con otro nombre y utilizando como copia de seguridad de referencia el fichero /mnt/Backup/Backup_Completa.

Hasta ahora si una copia de seguridad cae en malas manos la información sensible de la misma puede ser extraída por cualquiera, con lo que esto implica, por lo que cifraremos las copias de seguridad con Blowfish para curarnos en salud además de poder cumplir con la LOPD (Si no me equivoco, exige cifrar las backup). Aquí se nos presenta un problema, y es que si le pasamos a dar como parámetro el flag -K bf:Password cualquier usuario en la mayoría de las distribuciones podrá ver en plano la contraseña con tan solo ejecutar ps. Para no caer en este error sin renunciar al cifrado de las copias de seguridad automatizadas utilizaremos el fichero /root/.darrc que solo podrá ser leído por el usuario root y contendrá dos líneas:

-K bf:Password
-J bf:Password

La opción -K se ocupará de utilizar cifrado con Blowfish como algoritmo, y Password como contraseña cuando cree backups y descomprimamos backups. Por otro lado, la opción -J se ocupa de lo mismo, pero a la hora de comparar la backup. De hecho, recibiremos un aviso siempre que hagamos una copia de seguridad completa diciendonos que la opción -J solamente es útil si se utiliza con la opción -A, algo que en una copia de seguridad completa no se utiliza. Si deseamos en algún momento que estas opciones no se utilicen de forma implícita podemos utilizar la opción -N en la línea de comandos.

Hasta ahora hemos visto como crear copias de seguridad completas y diferenciales con determinadas opciones muy interesantes. Ahora explicaré como extraer ficheros de la copia de seguridad.

# dar -x /mnt/Backup/Backup_Completa -I Cadiz.avi -R /root/RESTORE

Esto extraerá de la backup /mnt/Backup/Backup_Completa el fichero que se llame Cadiz.avi en el directorio /root/RESTORE. Será muy rápido, pero existe un inconveniente y es que mediante este método se creará en el directorio /root/RESTORE todo el arbol de directorios vacío ensuciando el proceso de restauración. Es una buna opción si queremos recuperar todo tras un desastre, pero cuando queremos extraer solamente determinado fichero de una copia de seguridad a un directorio en concreto usaremos la opción -f que nos servirá para que el fichero Cadiz.avi se guarde directamente en /root/RESTORE. Por supuesto, si tenemos dos ficheros iguales en la copia de seguridad en diferentes directorios, nos preguntará si deseamos sobreescribirlo, ya que se extraerá en el mismo directorio con el mismo nombre. ¿Y si queremos extraer un directorio completo? Utilizaremos la opción -g indicándole como valor la ruta relativa de lo que queremos extraer. Imaginemos que queremos restaurar el directorio /datos/usuarios/manuel al completo, con todo su contenido. Como la backup se hace del directorio /datos utilizaremos la opción -g usuarios/manuel, por ejemplo. Se entiende ¿no?

# dar -x /mnt/Backup/Backup_Completa -g usuarios/manuel -R /root/RESTORE

Por último, si os ponéis a automatizar las copias de seguridad no olvidéis utilizar la opción -w, ya que si se desea sobreescribir las copias de seguridad diarias (conocidas como copias de seguridad hijo) nos preguntará si deseamos sobreescribir el fichero existente y no continuará hasta que no le facilitemos una respuesta.

Con lo explicado y un poco de bash podemos automatizar un proceso de backups creando una copia mensual completa, una completa semanal y diferenciales diarias basadas en la última semanal. Las copias una vez cifradas se pueden sacar de la empresa por si se incendiase o inundase, y aunque están cifradas y supuestamente están protegidas, la contraseña que utilicemos es lo único que las protege, por lo que debe ser fuerte.

Os recomiendo probarlo y que saquéis conclusiones vosotros mismos. Para más información

Instalación de VMWare Server en Debian Etch sin X

En el curro hemos preparado una modesta máquina para virtualizar las máquinas failover que tenían poca carga. Mi sorpresa es que VMWare Server pedía librerías que no tenía instaladas, todas referentes a las X. Busqué por Google y como no, llegué a un foro de Ubuntu donde el tio se instalaba todo el sistema gráfico. Yo como soy algo maniático en estos aspectos estuve indagando hasta que instalé todo lo necesario para la configuración correcta de VMWare Server y utilización de la consola remota.

# apt-get install libx11-6 libxtst6 libxt6 libxrender1

Eso debería servir. Luego hace falta bajarse el cliente para conectar al servidor remotamente desde máquinas que no tienen el VMWare Server instalado, y que el servidor tenga inetd corriendo para que vmware-authd funcione y autentifique.

Lo único que queda es instalar VMWare Server en la máquina, pero eso está tan documentado que me da palo escribirlo. Espero que os sirva para no ensuciar el sistema (¿Qué narices hacen unas X y las respectivas fuentes en un servidor dedicado a la virtualización?).

Ahora busco una utilidad de backup para vmdk… y económica.

Un saludo.

ROUTE target en IPTables

Se trata de un módulo no oficial para IPTables que hace más fácil y centralizada la gestión de rutas a host en un sistema linux. Una vez configurado nos permitirá reglas del tipo:

# iptables -A PREROUTING -t mangle -d 193.110.10.58 -j ROUTE –gw 10.0.0.257

Para echarlo a funcionar tendremos que parchear el kernel con patch-o-matic. Como los sources de Debian utilizan otra numeración al aplicar el parche nos fallará. La idea es bajarse los sources de la misma versión de iptables que nos ofrece debian y utilizando para el parcheo.

Instalamos las fuentes oficiales de Debian desde apt-get, que hará que sean más fáciles de mantener que las que nos bajemos de kernel.org, y alguna herramienta de compilación:

# apt-get install linux-source-2.6.18 gcc make ncurses-dev
# cd /usr/src
# tar -xjpf linux-source-2.6.18.tar.bz2
# ln -s linux-source-2.6.18 linux

Bajamos y descomprimimos las fuentes de IPTables:

# wget iptables-1.3.6.tar.bz2
# tar -xjpf iptables-1.3.6.tar.bz2

Bajamos y descomprimimos patch-o-matic:

# wget patch-o-matic-ng-20070728.tar.bz2
# tar -xjpf patch-o-matic-ng-20070728.tar.bz2
# cd /usr/src/patch-o-matic-ng-20070728

Si, es cierto, no es la versión más nueva que existe, pero el que las más nuevas no incluyen el módulo ROUTE. Es sospechoso y me preocupa algo (¿Por qué lo habrán quitado?), pero como ejemplo sirve.

Aplicamos el parche ROUTE indicandole que los sources de IPTables están en determinado directorio.

# IPTABLES_DIR=/usr/src/iptables-1.3.6 ./runme ROUTE

Ahora contestamos y. Nos dirá que el parche ha sido aplicado satisfactoriamente y que ahora es necesario compilar el kernel y los módulos.

Para ahorrar tiempo y desplegarlo más rápido en diferentes máquinas haremos un paquete deb del kernel.

Copiamos la antigua configuración del kernel precompilado de Debian

# cd /usr/src/linux
# make oldconfig

Instalamos las herramientas necesarias:

# apt-get install kernel-package

Desinstalamos el viejo kernel de Debian:

# apt-get remove –purge linux-image-2.6.18-5-686

Limpiamos el directorio de compilaciones previas si las hubiese:

# make-kpkg clean

Ahora compilamos de dos formas. La primera si necesitamos un paquete con los headers para algun driver como el de nVidia y demás. El segundo es el que he utilizado y servirá en la mayoría de los casos.

# make-kpkg –initrd kernel_image kernel_headers

o

# make-kpkg –initrd kernel_image

Podemos ahora desplegar este kernel precompilado por todas las debian que queramos utilizando dpkg:

# dpkg -i Kernel.deb

Como dije antes el target ROUTE parece que no ha sido incluido en versiones más nuevas de patch-o-matic. Quizá por estar descontinuado, fallar o por alguna otra razón. La verdad que no conozco la causa, pero lo que se puede hacer es utilizar iproute e iptables, para marcar los paquetes y darles salida por la puerta de enlace deseada.

Un saludo.

Comparando SELinux con OpenBSD…

Estaba el otro día leyendo los feeds mientras veía los entrenamientos de F1 del gran premio de China y leí un título interesante: SELinux vs. OpenBSD se titulaba el artículo. Coño, a ver que cuentan…

Pues quieren comparar SELinux que es lo que es con OpenBSD que también es lo que es. Los argumentos son de lo mejorcito:

  • Es complejo: Vale, no es fácil, aunque distros como Fedora y RedHat creo que tienen asistentes. ¿Tiene OpenBSD algo tan potente? ¿Hasta dónde llega TrustedBSD? Solo hay que buscar un poco por internet para leer preguntas como Does OpenBSD have something similar to the NSA`s SELinux, RSBAC, PaX stack smashing protection, Grsecurity etc? y leer esta joya de respuesta: OpenBSD has a “secure-by-default” approach with focus on security and code correctness. There`s no need for extra addons like SELinux and grsec kernel patches.
  • Insinuan, o me lo parece a mi, que APPArmor es mejor que SELinux cuando APPArmor tiene al menos que yo conozca, limitaciones, como que no permite controlar sockets, o que se referencia a los ficheros por su ruta y no mediante labels en el sistema de ficheros (Como si de una ACL o atributo extendido se tratase). Aquí una comparación de ambos.

Os dejo un artículo que me gusta mucho ya que explica muy bien como funciona PaX (Parte de la suite GRSecurity para Linux, que aunque no tenga nada que ver con SELinux, es un elemento más en la fortificación de un sistemas Linux) y W^X de OpenBSD.

Vamos, que en mi opinión no es solamente qué se usa, sino cómo se usa y como de implementa, y en mi opinión Linux ofrece más herramientas para fortificar el sistema que un sistema OpenBSD y quien no quiera ver más allá de la calidad del código en mi opinión no está haciendo una buena evaluación de todo el rol. OpenBSD todos sabemos que tiene fallos. Pocos, pero ahí están y sus paquetes tambien tienen fallos, y los paquetes no son parte del core, luego no son auditados, luego la misma cagada que comete el devel de determinada aplicación de lo que sea en Linux, puede cometerlo en el paquete de OpenBSD (Si lo incluye, claro, y si tiene esa misma versión). Y digo yo… de que sirve tener un sistema base con un muy buen código si luego tu aplicación que escupe html o correo es vulnerable? Creo que es ahí donde entra PaX, SELinux, RSBAC, etc intentando que la explotación de la vulnerabilidad no sea tan fácil de llevar a cabo…

Esa es mi opinión. Un saludo.

Listas de control de acceso en Linux

Hace tiempo que tenía pensado escribir algo al respecto y hoy ha sido el día que me sentía con ganas. Hay veces que me resulta incómodo manejar un sistema linux con multiples usuarios en lo que a permisos de fichero se refiere. En resumidas cuentas, el método UGO (User Group Other) está bien si tenemos un sistema monousuario, pero cuando tienes varios usuarios se hace insostenible, además de degradar la seguridad. Explicaré un poco, sin extenderme, como las ACL pueden solucionarnos el día a día, o al menos hacernosla más cómoda.

Comenzaremos preparando el sistema de ficheros, que en mi caso es ext3 (Todo sistema de ficheros que soporte ACL servirá). Necesitaremos meter en el fichero /etc/fstab la opción acl y luego remontar la partición:

# mount -o remount /dev/hdx

Continuaremos con las ACL sobre el directorio /var/www, por ejemplo. Los ficheros que contiene ya han sido creados con anterioridad, por lo que tendremos que aplicar la ACL recursivamente, dándole al usuario www-data permisos de lectura y ejecución sobre los ficheros/directorios recursivamente.

# setfacl -R -m u:www-data:r-x /var/www

Esto es como utilizar chmod, por lo que estamos en las mismas. Lo bonito, lo que más me gusta, son las Default ACL, que podemos decir que es una especie de heredar permisos del directorio padre. Imprescindibles. La idea será que todo elemento nuevo creado dentro de /var/www herede determinados permisos. Las ACL por defecto solamente se pueden aplicar a directorios, y si intentáis aplicársela a un fichero os mandará a tomar por el saco sutilmente.

# setfacl -d -m u:www-data:r-x /var/www

Lo que acabamos de hacer está bien si comenzamos a crear el arbol de directorios, pero imaginemos que tenemos el directorio /var/www/web1/upload. Ese directorio no se verá afectado por la ACL por defecto, por lo que haremos una cosilla, buscaremos todos los directorios y le aplicaremos la ACL:

# find /var/www -type d -exec setfacl -d -m u:www-data:r-x {} ;

Ahora vamos a comprobar que las ACL se han aplicado bien, algo muy importante. El comando es getfacl y su uso es bien sencillo para lo que vamos a hacer:

# getfacl /var/www
getfacl: Removing leading “/” from absolute path names
# file: var/www
# owner: root
# group: root
user::rwx
user:www-data:r-x
group::r-x
mask::r-x
other::r-x
default:user::rwx
default:user:www-data:r-x
default:group::r-x
default:mask::r-x
default:other::r-x

Vaya! other tiene permiso de lectura y ejecución en ese directorio. No me gusta eso…

# setfacl -R -m other::— /var/www
# find /var/www -type d -exec setfacl -d -m other::— {} ;

Ahora queda utilizar getfacl como hicimos antes para comprobar que los permisos son correctos.

Al igual que hemos utilizado other:: podríamos utilizar user:: o group::, que son elementos especiales.

Antes he puesto un ejemplo en el que aplicaba determinados permisos a un usuario sobre un fichero/directorio. Para hacer lo mismo pero con un grupo, se utilizará:

# setfacl -m g:NombreGrupo:permisos /var/www

Hasta ahora hemos aplicado nuevos permisos, pero por si existe la duda, modificarlos es idéntico, utilizando el flag -m y modificando el penúltimo elemento. Supongamos que queremos que el usuario www-data tenga permisos de escritura en determinado directorio:

# setfacl -R -m u:www-data:rwx /var/www/web1/upload

Ese directorio y todos los existentes podrán ser modificados por ese usuario, pero… ¿Y los ficheros nuevos? No, podrán ser creados, pero no modificados posteriormente, pues no hemos establecido una ACL por defecto para ese usuario con permisos de escritura para los ficheros/directorios nuevos que se vayan a crear en ese directorio, o si existe, puede que sea incorrecta, por lo que lo estableceremos como necesitemos:

# find /var/www/web1/upload -type d -exec setfacl -d -m u:www-data:rwx {} ;

También puede ocurrir algo muy común, que nos equivoquemos e introdujamos un usuario/grupo incorrecto en la ACL, ensuciando esta. Pana ACL usaremos el flag -x.

# setfacl -x u:www-data /directorio/secreto
# setfacl -d -x u:www-data /directorio/secreto

Existen otras opciones interesantes de setfacl como eliminar solamente las ACL por defecto con el flag -k o eliminar todas las ACL normales y por defecto con el flag -b.

Me queda decir que al igual que podéis establecer los permisos con letras, lo podéis hacer en octal, de 0 a 7:

# setfacl -m u:www-data:5 /elemento2

Tenéis algunos ejemplos interesantes que no he ilustrado como copiar las ACL de un elemento a otro en el manual, man setfacl.


Las opiniones reflejadas en este blog son personales o ni siquiera son opiniones, y bajo ningún concepto representan las estrategias, opiniones o posturas de mi empresa actual, ni de ninguna en las que he trabajado, así como tampoco de ninguno de los clientes o proveedores de todas ellas.
La información se proporciona como está, sin garantías de ninguna clase, y no otorga ningún derecho. Los comentarios pertenecen a sus autores y bajo ningún concepto el autor del blog se hará responsable de los mismos.

Categorías

Archivos