sudo timeout

Si bien el otro día hablábamos de las diferencias entre sudo y su, hoy quiero aclarar un tema que puede significar un problema de seguridad a corto plazo. Por defecto muchos de los sistemas traen en su configuración de sudo un, llamémosle "tiempo de gracia" desde la primera vez que has introducido tu contraseña para ejecutar un comando sudo hasta que ésta se te vuelve a pedir. Durante este tiempo, siempre que emplees sudo no se te pedirá la contraseña del usuario. Esto, que puede parecer una facility del sistema, en sistemas de producción puede provocar un gran caos si una sesión "en tiempo de gracia" queda abierta y un usuario mal intencionado ejecuta un comando.
Para evitar esto, podemos agregar en el fichero de configuración (/etc/sudoers) la siguiente línea,
Defaults: ALL timestamp_timeout=0
que garantiza que siempre se pida la contraseña.

La entrada sudo timeout la puedes leer en Puppet Linux.
Leer más

Programando tareas en GNU/Linux: cron + crontab

La gente que suele emplear habitualmente Windows conoce a la perfección las "Tareas programadas" y aunque personalmente no conozco a mucha gente que las emplee, sí que cuando menos las conocen. Pues bien, en GNU/Linux existe un planificador de tareas, que también permite ejecutar de forma periódica cosas. Según mi experiencia, incluso más potente que el de Windows, pero como siempre, para gustos...

¿Qué es cron?

cron es el planificador de procesos incluido en prácticamente todos los Unix. Es un pequeño daemon que se encarga de ejecutar los procesos descritos en el fichero crontab cuando corresponda. Por defecto, cron se ejecuta en segundo plano una vez cada minuto y revisa la tabla de tareas que debe de ejecutar (si las hay). Estas tareas se almacenan en /etc/crontab o en /var/spool/cron.
cron permite ejecutar programas como "daemons" sin serlo realmente, ya que es él el que se encarga de realizar la ejecución periódica.

¿Qué es crontab?

crontab es un pequeño fichero de texto, situado en /etc/crontab y que únicamente contiene una pequeña configuración para cada uno de los procesos que se deben de ejecutar. Dicho fichero está distribuido por líneas y cada línea tiene la fecha en la que se debe de repetir (frecuencia de ejecución), el usuario con el que hacerlo (permisos) y el comando a ejecutar.
A mayores del fichero crontab de /etc, que es el general del sistema, cualquier usuario puede tener también su propio fichero crontab. En él puede especificar los comandos que desea y la periodicidad de los mismos. La única diferencia es que no hay campo usuario, ya se se asume que es el propio usuario dueño de dicho fichero. Cualquier usuario puede generar y manejar su propio fichero con el comando crontab.

Tareas en crontab

Una de las partes más esenciales de cron, como ya dijimos es crontab y dentro de éste fichero, lo más lógico es saber cómo crear una nueva línea. Recordemos que cada línea es una tarea o trabajo, así que una nueva línea es un nuevo trabajo que se ejecutará.
Hace ya tiempo escribí una pequeña entrada sobre cron y qué significa cada posición en el fichero. Si te interesa leerla, lo puedes hacer aquí. Lo más importante de aquella entrada era la siguiente imagen,
donde se explica a la perfección cómo crear una línea de ejecución. Algunos ejemplos prácticos:
  • Actualizar sistema a las 3:15 todos los días
    15 3 * * * root apt-get update
    
  • Actualizar sistema todos los domingos a las 10:00
    00 10 * * 0 root apt-get -y update
    
  • Actualizar sistema el día 15 de cada mes a las 15:15
    15 15 15 * * root apt-get update
    
  • Actualizar sistema todos los días de la semana a las 15:15
    15 15 * * 1,2,3,4,5 root apt-get update
    
  • Actualizar sistema el día 1, 15 y 30 de cada mes
    00 00 1,15,30 * * root apt-get update
    
A mayores de poder definir las cadenas como número, cron también contiene cierto literales muy importantes para determinados eventos sumamente reconocidos o empleados. Estos son:
  • @reboot, ejecuta la tarea cuando el sistema se inicia
  • @yearly, ejecuta la tarea sólo una vez al año: 0 0 1 1 *
  • @annually, lo mismo que @yearly
  • @monthly, ejecuta la tarea el primer día del mes: 0 0 1 * *
  • @weekly, ejecuta la tarea el primer minuto de la primera hora de la semana: 0 0 * * 0
  • @daily, diario a las 12:00A.M. 0 0 * * *
  • @midnight, lo mismo que @daily
  • @hourly, ejecuta la tarea el primer minuto de cada hora: 0 * * * *
Y su uso, muy simple,
@reboot  logcheck  /usr/sbin/logcheck -R

La entrada Programando tareas en GNU/Linux: cron + crontab la puede leer en Puppet Linux.
Leer más

sudo vs. su

Primero fue su, luego llegó sudo y lo siguiente será... Desde que conozco GNU/Linux empleé su para poder acceder a una cuenta de usuario diferente a la mía y poder ejecutar o ver diferentes cosas. Con la expansión de Ubuntu, el comando sudo fue tomando cada vez más y más relevancia hasta llegar al punto de que su quedó, digámoslo así, deprecated. Sin embargo esto no es cierto y existen diferencias bastante sustanciales entre su y sudo. Vamos a verlas y en qué casos se debería usar cada uno.

su

su fue el primero de los comando que conocí para entrar en la cuenta de otro usuario, como ya dije antes. Y realmente es para lo que sirve. Permite al usuario cambiar la cuenta de usuario con la que está logueado sin tener que salir de la sesión que ya tiene. Aunque típicamente su se empleaba como comando para ascender a root, realmente permite acceder a cualquier usuario.
Al ejecutar su, éste pide la contraseña del usuario con el que queremos hacer login y no la contraseña de nuestro usuario. Si ésta es correcta, entones el proceso que se ejecute es muy similar al de login (idéntico si empleamos su - ). Carga las variables todas que le corresponden al nuevo usuario (HOME; USER; SHELL; TERM; etc.) y hasta que se cierre la sesión, todos los comandos que se ejecuten tienen los permisos del nuevo usuario.
javier@shell> su -
Contraseña:
root@shell> 
Y con su no solamente se puede acceder a un usuario root, sino también a un usuario normal, siempre que se sepa su contraseña. Por lo tanto, las contraseñas deben de ser compartidas al emplear su.
javier@shell> su - test
Contraseña:
test@shell>

sudo

sudo es un comando directamente relacionado con su y que en realidad tiene la misma función, permitir a un usuario ejecutar comandos en nombre de otro. La gran diferencia es que el comando que se ejecuta con sudo debe estar previamente autorizado por el administrador (fichero /etc/sudoers) y que la contraseña que te solicita el comando es la de tu propio usuario y no la del otro usuario. Esta es la principal ventaja, en sudo no se comparten contraseñas.
javier@shell> sudo vi file
[sudo] password for javier: 

¿Cuál debes usar?

Esto realmente depende de cada uno y de cada sistema. Por seguridad quizás lo más lógico es emplear sudo. El administrador deja únicamente permisos para ejecutar determinados comandos, por lo que el riesgo de hacer algo desastroso en el sistema se redice mucho. A mayores, también es mejor, puesto que no hay que compartir contraseñas entre los usuarios.
Sin embargo, si lo que necesitas es trabajar como otro usuario puede terminar por resultar mucho más lógico emplear su que estar constantemente llamando a sudo.

La entrada sudo vs. su la puedes leer en Puppet Linux.
Leer más

Debian 7.1.0, primera released de Wheezy

Wheezy!
Si todavía no nos hemos recuperado ni actualizado todos los equipos a la última versión estable de Debian (Wheezy - 7.0), este fin de semana el equipo Debian trabajó para sacar la nueva released, 7.1.0. Así que ya sabéis , toca actualizar nuevamente.
El por qué de esta actualización mayor es muy simple, numerosos fallos de seguridad graves y bug's que aparecieron en muy poco tiempo. Debian decidió sacar la nueva released para solucionarlos y ofrecer un sistema estable y lo más seguro posible.
Por supuesto, todo sigue siendo perfectamente compatible y los procesos siguen funcionando igual. Simplemente agradecer públicamente el trabajo y esfuerzo de la comunidad por mantenernos actualizados.

Noticia de la publicación oficial de Debian Wheezy hace prácticamente mes y medio.

La noticia la puedes leer en la web oficial.
Leer más

Auto-completar comandos sudo

Si sois usuarios habituales de Ubuntu o derivadas de ésta distro, lo más probable es que este truco la os funcione y por lo tanto no os sirva para mucho. Sino, terminar de leer el post que quizás os pueda ser de gran ayuda.
Por defecto, la shell de GNU/Linux te ayuda a autocompletar los comandos que escribes simplemente con presionar la tecla "Tab", pero esto no sucede así si lo precedes del comando sudo. En ese caso, el autocompletado ya desaparece y si no sabemos el comando exacto a escribir la cosa se complica. Para poder tener el autocompletado con sudo, simplemente debéis de agregar la siguiente condición a vuestro fichero ~/.bashrc.
if [ "$PS1" ]; then 
   complete -cf sudo 
fi
Y disfrutar del autocompletado para sudo.

La entrada Auto-completar comandos sudo la puedes leer en Puppet Linux.
Leer más

Detalles de Zabbix "more than X minutes"

Hacía ya un tiempo que no hablaba nada de Zabbix y no por que no esté trabajando bastante a menudo con él. Así que hoy os voy a enseñar un pequeño truco que realmente puede resultar muy interesante, especialmente para entornos grandes, donde el número de item's que se están a monitorizar es muy grande.
Como supongo que sí sabréis, desde el interfaz web de Zabbix, en la pestaña Administración/Cola (Administration/Queue) podemos ver el estado de monitorización de los item's. Aunque desde aquí no nos dice nada, sí podemos ver ciertos detalles muy importantes, como la cantidad de item's que hay con un retraso en recepción de datos. Esto, que de base puede parecer una tontería, nos puede resultar a la larga muy útil, por que si tenemos algunos item's que tardan más de 10 minutos, puede ser que el equipo tenga algún fallo, o que el item en cuestión tenga algún fallo.
Zabbix - More than 10 minutes
Lo malo de esta pestaña es que no nos da una información demasiado útil, y aunque podemos tener una vista de detalles, sacar y corregir los fallos en más de 1500 item's, puede ser complicado. Para solucionarlo, os dejo una query para MySQL que os dará los detalles que necesitáis, y así lo podréis intentar solucionar. Siempre que los errores sean realmente errores.
mysql> SELECT 
         h.STATUS AS "status (host)",
         i.hostid AS hostid,
         h.name AS host,
         i.name AS item,
         i.STATUS AS status
       FROM items i
       LEFT JOIN hosts h
         ON h.hostid=i.hostid
       WHERE
           UNIX_TIMESTAMP()-lastclock > delay+(10*60)
         AND
           (h.STATUS = 0 AND i.STATUS = 0);
Por supuesto, si lo que os interesa es sacar el resto de información, donde yo hice la multiplicación (10*60), podéis poner (5*60) y sacareis los detalles de los item's de más de 5 minutos.

La entrada Detalles de Zabbix "more than X minutes" la puedes leer en Puppet Linux.
Leer más

Recuperación de GRUB sin Live-CD

Hace ya un tiempo hablamos de cómo poder recuperar grub en caso de que éste haya desaparecido. La forma que vimos en aquel caso era la de arrancar con una Live-CD y entrar en nuestro sistema para restaurar el grub. Esa forma está muy bien, pero tiene el problema de que cuando lo necesitamos, a lo mejor no tenemos una Live a mano. En ese caso, ¿cómo hacemos para restaurar el sistema de arranque?
Pues bien, por suerte, grub tiene un pequeño prompt que permite, entre otras muchas cosas, arrancar el sistema en caso de emergencia. Así que vamos a ver cómo hacerlo.




  1. Listamos las particiones disponibles
    Esta es la parte más complicada, puesto que es necesario saber donde está la partición /boot. Si no os acordáis, no pasa nada, en dicho prompt existe en comando ls, que lista las particiones del disco y a la vez, el contenido del mismo. En mi caso tengo esto,
    grub> ls
    (hd0) (hd0,msdos5) (hd0,msdos1)
    
    De las particiones disponibles, tenemos que saber cual es la de arranque. En mi caso, yo sabía que era la (hd0,msdos1), sino, lo que tenemos que hacer es listar los ficheros de cada una, para descubrir dónde está /boot
    grub> ls (hd0,msdos1)/
    /etc  /media /boot /usr /var ...
    
    Es MUY importante la barra final y que el nombre sea exacto, sin espacio ni nada.
  2. Configuramos dinámicamente grub
    Una vez sepamos la partición en cuestión, debemos de añadir todos los datos que grub no sabe de forma dinámica. En caso de que alguno de estos datos no lo sepamos, simplemente empleamos ls para listar el contenido que deseemos.
    grub> set prefix=(hd0,msdos1)/boot/grub1
    grub> set root=(hd0,msdos1)
    grub> linux /boot/vmlinuz-3.2.0-29-generic-pae2 root=/dev/sda13
    grub> initrd /initrd.img
    
  3. Arrancamos
    Finalmente, cuando ya todo esté configurado, simplemente arrancamos el sistema.
    grub> boot
Una vez dentro, simplemente debemos de corregir el fallo del grub que impidió que arrancase el sistema correctamente y volver a instalarlo como es debido. Este método de arranque no es para todos los días ;-)

1 Debemos de encontrar la carpeta donde está localizado el grub. Por defecto está bajo /boot, así que ésta sería una buena configuración.
2 Aquí tenemos que poner el kernel de nuestro sistema! Si no lo sabemos, podemos optar por emplear, en mi caso, ls (hd0,msdos1)/boot y nos listará los disponibles y ya copiamos el nombre.
3 También debemos en este caso poner el disco. Puesto que en mi caso, es (hd0,msdos1), hd0, significa /dev/sda y el msdos1, la primera partición, de ahí /dev/sda1. Debéis ajustar esto a vuestro sistema, aunque esto es lo más habitual
La entrada Recuperación de GRUB sin Live-CD la puedes leer en Puppet Linux.
Leer más

Matar procesos por usuario

En post anteriores vimos cómo poder matar los procesos SSH de un usuario y ahí hicimos ya uso del comando pkill. Hoy vamos a ver otro truco de dicho comando, que no es otro que poder matar todos los procesos de un usuario.
Sí, efectivamente, si un usuario está haciendo un uso muy abusivo de CPU o memoria y queremos matar todos sus procesos de forma rápida y eficaz lo podemos hacer tal que así,
shell> pkill -u user
Aunque ojo! Matará TODOS los procesos de dicho usuario, sin contemplaciones y sin previo aviso, así que antes de hacerlo, pensar en qué vais a hacer ;-)
Leer más

Cisco NO Password Recovery

Fijo que a muchos de los que me leen alguna vez se les pasó por la cabeza saber cómo proteger un router o switch de acceso físico. Si estos dispositivos no están perfectamente aislados, y dependiendo del modelo, el acceso a la consola puede ser bastante sencillo y por lo tanto, averiguar la configuración e incluso alterarla, más todavía.
Para evitar este tipo de problemas de acceso físico a los dispositivos, podemos establecer unas contraseña seguras, lo cual dificultará mucho que alguien acceda por la consola, pero como prácticamente todo aparato físico, existe un método de recuperación de contraseña, o "password recovery", lo cual puede ser un problema.
Los equipos Cisco tienen una opción, muy interesante para habilitar, que permite que en caso de que alguien intente resetear la contraseña se borre toda la configuración. Aunque puede resultar un método un poco drástico, es sin duda bastante eficaz, ya que conseguimos que nadie que no tenga acceso sepa la configuración de red del equipo. Para habilitarlo,
Switch# conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Switch(config)# no service password-recovery
Switch(config)# end

Switch# show version | include recovery
The password-recovery mechanism is disabled.

La entrada Cisco NO Password Recovery la puedes leer en Puppet Linux.
Leer más

Clave GPG extras.ubuntu.com

Recién instalada la versión de Ubuntu 12.04 LTS del CD original, cambio los repositorios por lo de la distribución y me encuentro con un ya más que sabido fallo de clave GPG: "Las firmas siguientes no se pudieron verificar...". Aunque sí resulta cuando menos curioso, supongo que hace ya tiempo que dicho CD fue grabado y que no hay nada extraño en los servidores de Ubuntu, así que os explico paso a paso cómo solucionar el fallo.
No tiene mayor complicación, pero buscando por Internet vi a gente que recomendaba borrar carpetas esenciales del sistema apt para luego volver a copiarlas. Es mucho más simple y rápido. Ahí os lo dejo,
shell> apt-get update
...
Descargados 1.363 kB en 2seg. (601 kB/s)             
Leyendo lista de paquetes... Hecho
W: Error de GPG: http://extras.ubuntu.com precise Release: Las firmas siguientes no se pudieron verificar porque su llave pública no está disponible: NO_PUBKEY 16126D3A3E5C1192
shell> gpg --keyserver hkp://subkeys.pgp.net --recv-keys 16126D3A3E5C1192
...
gpg: key 3E5C1192: public key "Ubuntu Extras Archive Automatic Signing Key ftpmaster@ubuntu.com" imported
gpg: no ultimately trusted keys found
gpg: Total number processed: 1
gpg:               imported: 1
shell> gpg --export --armor 16126D3A3E5C1192 | sudo apt-key add -
OK
shell> apt-get update
...
Descargados 72 B en 0seg. (103 B/s)
Leyendo lista de paquetes... Hecho

La entrada Clave GPG extras.ubuntu.com la puede leer en Puppet Linux.
Leer más

Deshabilitar IPv6 en Ubuntu

Las redes IPv6 están ya cada vez más implantadas entre nosotros, sin embargo todavía no han llegado al gran público, por lo que no es necesario tener habilitado el soporte IPv6 en los equipos que no lo van a necesitar. En este caso, vamos a ver cómo deshabilitar dicho soporte en Ubuntu.
Lo primero es saber si tenemos el soporte IPv6 habilitado. Por defecto sí, pero para comprobarlo,
shell> cat /proc/sys/net/ipv6/conf/all/disable_ipv6
0
Este 0 de salida indica que sí está habilitado el soporte. Necesitamos tener un 1, que indicará lo contrario, que está deshabilitado IPv6. Para conseguirlo, editamos el fichero /etc/sysctl.conf y agregamos las siguiente líneas,
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1
Tras ello, reiniciamos nuestro sistema y al volver comprobamos que el cambio surgió efecto.
shell> cat /proc/sys/net/ipv6/conf/all/disable_ipv6
1

La entrada Deshabilitar IPv6 en Ubuntu la puedes leer en Puppet Linux.
Leer más

Permisos especiales: Sticky bit, SetUID y SetGID

El tema de permisos en los sistemas GNU/Linux es un referente. Aunque se suele decir que estos permisos son algo especial, en realidad se establecen en el sistema de ficheros, que así lo soporta. Y esto, lógicamente ofrece una gran ventaja respecto de sistemas de archivos en Windows. NTFS lo intentó, pero no consiguió lo que ext3/ext4, entre otros, tiene.
Para definir los permisos en GNU/Linux se suele emplear el comando chmod con un número octal (0..7) y en este número se hace la agrupación para definir si un fichero tiene permisos de lectura, escritura y/o ejecuciónrwx (y sus permutaciones) es la combinación más típica de permisos que se suele dar, pero a mayores de esos permisos, hay otros más ocultos que permiten hacer cosas completamente diferentes. Estos permisos son los que vamos a ver a continuación: el sticky bit, el bit SGID y el bit SGUID y su representación octal es la que sigue,
Sticky bit --> 1000
Bit setgid --> 2000
Bit setuid --> 4000

Sticky bit

Aunque en la actualidad no es muy empleado, en los antiguos sistemas Unix este bit activado le indicaba al sistema operativo que mantuviese a dicho programa en memoria, con el fin de facilitar su ejecución. Puesto que estaba en memoria no es necesario volver a cargarlo y su ejecución es mucho más rápida. Con la evolución de la tecnología este bit ya no tiene esa funcionalidad, ya que la carga de programas actualmente es mucho más rápida.
Actualmente se emplea este Sticky bit para definir aquellos ficheros o directorios que interesa que sólo el propietario los pueda cambiar. Este bit prevalece sobre el resto de permisos, por lo que sólo el propietario tendrá acceso al fichero.
Un ejemplo de uso es el directorio /tmp, que presenta los siguientes permisos,
shell> ls -l /
...
drwxrwxrwt  10 root root  4096 jun  3 08:42 tmp
...
Para establecer un fichero o directorio con esta propiedad hay que elegir una de ambas opciones,
shell> chmod 1755 /tmp
shell> chmod a+t /tmp

Bit suid

Bit SUID es uno de los permisos más peligrosos que se pueda establecer, ya que permite al usuario que ejecute dicho fichero tener los mismos permisos durante toda la ejecución que el usuario que ha creado el fichero. De forma más clara, si el usuario root crea un fichero y le da permisos de setuid, todo aquel que lo ejecute tendrá permisos de root durante la ejecución de dicho binario. La forma de activarlo (una de las dos),
shell> chmod 4775 /usr/local/bin-ls
shell> chmod u+s /usr/local/bin-ls
La representación octal es 4000, como ya se dijo anteriormente y cuando se establece también hay que establecer los permisos de ejecución pertinentes. Cuando tengamos el setuid establecido, los permisos aparecerán con una 's' o una 'S', según el permiso de ejecución esté o no establecido.

Bit sgid

Es lo mismo que lo que acabamos de explicar para el setuid, pero aplicable al grupo. Si estableciendo el bit anterior conseguíamos establecer los permisos como un EUID (Efective UID) en este caso lo que vamos a lograr es lo mismo, pero a nivel de grupo EGID (Efective GID). La forma de establecer dichos permisos es con 2000, en su representación octal.
shell> chmod 2770 /usr/local/sbin

La entrada Permisos especiales: Sticky bit, SUID Y SGID la puedes leer en El mundo en bits.
Leer más

No refs in common and none specified

Hoy trabajando con git me apareció el siguiente mensaje de error,
shell> git push
Enter passphrase for key '/home/javier/.ssh/public_key': 
No refs in common and none specified; doing nothing.
Perhaps you should specify a branch such as 'master'.
fatal: The remote end hung up unexpectedly
error: failed to push some refs to 'git@git.domain.com:secretProyect'
Hay que decir, que cuando comencé a trabajar con el proyecto, hice un "git clone" del repositorio vacío, por lo tanto cuando ejecuté el "git push" obtuve ese maravilloso error.
Por suerte la solución fue sencilla,
shell> git push origin master
Enter passphrase for key '/home/javier/.ssh/public_key': 
Counting objects: 12, done.
Compressing objects: 100% (11/11), done.
Writing objects: 100% (12/12), 8.01 KiB, done.
Total 12 (delta 4), reused 0 (delta 0)
To git@git.domain.com:secretProyect
 * [new branch]      master -> master

Más acerca de git en este blog.
Leer más

Formulario de contacto

Nombre

Correo electrónico *

Mensaje *

Últimos comentarios