Knowledge Does Not Take Place

Esta utilidad de los sistemas Unix, permite a los usuarios ejecutar programas con  privilegios de seguridad de otro usuario, normalmente de root, de forma segura. Esto es especialmente útil en entornos en los que conviven varios usuarios, a los cuales no es posible dar la contraseña de root por motivos de seguridad y necesitan ejecutar algún comando propio de root.



Con sudo podemos implementar control de acceso, en el que determinar que usuario ejecuta un determinado comando. Si un usuario necesita ejecutar un comando de root, sudo, verifica en su lista de permisos y si está permitido la ejecución de ese comando para ese usuario, entonces sudo se encarga de ejecutarlo. Esta lista de control de acceso, podemos encontrarla en el fichero /etc/sudoers. En resumidas cuentas, el escenario que presenta la utilidad sudo tiene 3 protagonistas principales.

1. Sudo: comando con permisos de SUID, que los usuarios utilizan para ejecutar comandos, que por defecto no tienen permiso para ejecutar.
2. Visudo: comando que permite al administrador modificar el fichero /etc/sudoers.
3. /etc/sudoers: Archivo que indica a sudo que permisos tiene cada usuario para ejecutar cierto comando.

Vamos a verlos un poco más en detalle.



Sudo

A continuación se detallan algunas de las opciones que presenta sudo

• sudo -l: Nos indica que comandos podemos ejecutar con el usuario en cuestión.

     $ sudo -l 

       User Pepito may run the following commands on this host: 

            (root) /sbin/ifconfig 

            (root) /sbin/lspci

• sudo -v: Por defecto, al ejecutar cualquier comando con sudo tenemos 5 minutos para, en caso de tener que volver a meter el comando, no tener que introducir la contraseña del usuario. Con -v podemos ampliar 5 minutos más este tiempo.

• sudo -u: Con el parametro -u podemos ejecutar comandos de otro usuario que no tiene porque ser root.  

      $ sudo -u peter /comando/de/peter 

• sudo -e: Permite editar un fichero de root, siempre y cuando se tengan permisos en /etc/sudoers.
  

   
  $ sudo -e /etc/inittab 

• sudo -L: Nos muestra una serie de opciones que podemos configurar en el fichero /etc/sudoers

Visudo

Permite la edición del archivo de configuración de sudo /etc/sudoers. Invoca al editor que se tenga por defecto (normalmente "vi"). Cuando se ejecuta, bloquea el fichero sudoers de manera que nadie pueda modificarlo de forma concurrente por razones de seguridad. Otra cosa a tener en cuenta, es que visudo comprueba que el archivo esté bien configurado al cerrarlo, si hay algo que no le convence, nos avisará de ello.

>>> sudoers file: syntax error, line 15 <<< 
What now?

Ante esta pregunta podemos ejecutar 3 acciones:
e: editar
x: salir sin guardar los cambios
Q: salir y guardar los cambios

Sudoers

En este fichero se establece que usuario puede ejecutar que comando y de que modo, generando una lista de control de acceso que puede ser tan detallada como se desee.

El fichero se divide en 3 partes:

1- Opciones: Permite definir ciertas características de comportamiento para los alias previamente creados. No entraremos en detalle en esta parte. Para más información visitar el enlace que aparece al final de la entrada.

2- Reglas de acceso: Mediante las reglas de acceso podemos configurar qué comandos serán ejecutados por qué usuario. El formato de las reglas, es el siguiente:

        usuario host = comando1, comando2...comandoN

     Usuario: Puede ser un usuario, un alias de usuario o un grupo
     Host: Puede ser ALL (cualquier equipo), un solo equipo, un alias de equipo, una IP/mascara.
    Comando: Cualquier comando con su ruta completa.

3- Alias: Se refiere a un usuario, un comando o un equipo. Engloba bajo un solo nombre una serie de elementos que después en la parte de definición de reglas serán aplicados bajo cierto criterio. La forma de creación de alias es la siguiente:

 tipo_alias NOMBRE_DEL_ALIAS = elemento1, elemento2, elemento3, ...

 tipo_alias define los elementos:

• Cmnd_Alias (comandos) 
• User_Alias(usuarios) 
• Runas_Alias(usuarios con privilegios)
•  Host_Alias (equipos)

  NOMBRE_DEL_ALIAS: Puede llevar letras, numeros o _ . Debe empezar por mayusculas.

  elementos: varian dependiendo del alias. Algunos ejemplos son los siguientes.

            Cmnd_Alias WEB = /etc/init.d/apache2, sudoedit /etc/httpd
            User_Alias MYSQL_USERS= Pepin, Mochilo, Gazpacho, %mysql
            Runas_Alias OPERADORES= #501, patricio
            Host_Alias LANS= 192.168.0.0/24, 192.168.0.1/255.255.255.0

Aqui podeis encontrar un ejemplo práctico de la configuración del fichero /etc/sudoers.

Hasta aquí llegamos. En posteriores entradas entraremos más en profundidad en este tema que puede llegar a ser muy extenso :). Espero que con estas pinceladas, quede un poco más claro el funcionamiento de esta utilidad. En caso de dudas os recomiendo visitar el enlace que os dejo a continuación.

Fuente: Basado en el tutorial de Sergio Gonzalez Duran en linuxtotal.com

Nos vemos,
Víctor.

Hola de nuevo :),

hoy os traigo una herramienta opensource, que permite gestionar la configuración de vuestros elementos de red de una manera sencilla y clara.

Rancid monitoriza la configuración de los routers (y más dispositivos), incluyendo software y hardware (tarjetas, número de serie…) y usa CVS o subversión para mantener el histórico de cambios.
Rancid hace esto mediante el siguiente método:
- Se loguea en cada dispositivo encontrado en la tabla de routers (router.db).
- Corre varios comandos para conseguir la información que será guardada.
- Da formato a la salida, borra oscilaciones o incrementa los datos.
- Envía avisos por mail en caso de cambios.
- Y sube los cambios al control de versiones.



Rancid actualmente soporta Cisco routers,Juniper routers,Catalyst switches,Foundry switches, Redback NASs, ADC EZT3 muxes, MRTd, Alteon switches, and HP Procurve switches.

Una vez que hemos visto una pequeña reseña de la aplicación, podemos ponernos manos a la obra.
Instalaremos la aplicación sobre una máquina virtual con Debian6 de sistema operativo, el resto de requisitos hardware no son nada restrictivos.

Instalación

Para la instalación de la aplicación, se ha recurrido a la versión compilada de las fuentes, que podemos obtener a través de la página (http://www.shrubbery.net/rancid/). La versión instalada es la 2.3.8 que a fecha de hoy es la última estable.
 

Hay algunos prerrequisitos que debemos tener en cuenta:
- Crear usuario rancid: adduser rancid –-home /home/rancid
- Paquetes necesarios antes de la instalación, se pueden encontrar todos en los repositorios de debian sin problema.
        o Build-essential
        o Expect
        o Subversión o CVS
        o Postfix

Descomprimimos el .tar.gz
root@rancid:~/rancid-2.3.8# tar -xvf rancid-2.3.8.tar.gz
Dentro de la carpeta resultante, encontramos los ficheros necesarios para la configuración e instalación. Para instalar ejecutamos los siguiente:

cd /home/rancid/rancid-2.3.8
./configure –prefix =/home/rancid
Make install
Nota: En nuestro caso hemos descomprimido el tar en /home/rancid
 

Este proceso nos crea el árbol de directorios necesarios para manejar la herramienta.
/home/rancid/var -> aqui encontraremos los grupos de rancid y los logs
/home/rancid/bin -> en este directorio están los binarios
/home/rancid/etc -> Aquí encontramos el fichero de configuración de rancid

 

Configuración

Editamos el fichero rancid.conf en /home/rancid/etc:
  CVSROOT=$BASEDIR/CVS
  RCSSYS=svn
Cambiamos el control de versions de cvs a svn y
  LIST_OF_GROUPS = “grupo1 grupo2”
Donde “grupo1 grupo2” son los nombres de los grupos de elementos de red que vamos a crear. Podemos crear un grupo que sea SwitchesPlanta1, con los Switches de la planta 1, o cualquier agrupación que se nos ocurra.
 

Del fichero de configuración principal no tenemos que tocar nada más. Ahora pasamos a crear los usuarios (user/pass) de los switches/routers que vamos a gestionar. Para ello:

  - En /home/rancid/share/rancid encontramos un ejemplo de fichero de autenticación, llamado .cloginrc.sample. Lo copiamos directamente en nuestra carpeta /home/rancid quitándole la extensión .sample.
cp /home/rancid/share/rancid/cloginrc.sample /home/rancid/.cloginrc
 

En este fichero añadimos los switches/routers que queramos gestionar con su usuario y password. Nos fijamos que la información se guarda en texto plano y por lo tanto hay que tener cuidado extremo con el contenido de este fichero. Lo preferible es guardarlo con unos permisos restrictivos (600) y cambiando el owner al propio usuario rancid. Las líneas del fichero, tendrán una forma tal que así.
add user switch0 root
add password switch0 *Password* {*Password enable*}
add autoenable switch0 1
add method switch0 telnet
add cyphertype switch0 3des
root -> Usuario del switch
*Password* -> Password de root
*Password enable* -> En caso de ser necesario hacerse superusuario para ejecutar ciertos comandos.
Method -> telnet o ssh
Cyphertype -> tipo de encriptación.

Una vez modificados los ficheros rancid.conf y .cloginrc ya estamos en disposición de crear el control de versiones que incluirá la información una vez ejecutemos rancid. Para ello ejecutamos el binario rancid-cvs como usuario rancid que nos creará el árbol de subdirectorios para svn.
Una vez hecho esto nos aparecerá un directorio /home/rancid/var/*grupo* donde encontraremos el fichero router.db, en el cual podemos añadir los switches que gestionaremos. El formato de este fichero será:

10.156.1.1:cisco:up

siendo:
10.156.1.1 -> Ip o nombre del switch a gestionar.
Cisco -> marca del switch
Up-> estado del switch

 
Podemos comprobar si las credenciales por acceso remoto funcionan mediante el binario clogin:

/bin$ /home/rancid/bin/clogin 10.156.1.1

10.156.1.1
spawn telnet 10.156.1.1
Trying 10.156.1.1...
Connected to 10.156.1.1.
Escape character is '^]'.

User Access Verification

Password:
Router>enable
Password:
Router#

 
Si la configuración en el fichero .cloginrc es correcta, debería conectarse automaticamente por telnet al switch.

Si la prueba anterior es satisfactoria, podemos proceder a crear el control de versiones, para ello ejecutamos:
/home/rancid/bin/rancid-cvs

 
Este comando creará el árbol de directorios necesario para mantener el control de versiones. Nos aparecerán los siguientes directorios.
/home/rancid/var/CVS. Directorio raíz del repositorio configurado a través de la variable CVSROOT en el fichero rancid.conf
/home/rancid/var/logs. Directorio de los logs de la aplicación, también configurable a través del fichero de configuración rancid.conf. En cada ejecución de rancid, se alamacena un log con el proceso realizado por la aplicación y el estado del mismo.
/home/rancid/var/<NombreGrupo>. Rancid generará un directorio con el nombre de cada grupo que hayamos incluido en el fichero rancid.conf. En este directorio encontramos la siguiente distribución:
          o Directorio configs: aquí almacenará la información de los elementos que estén dados de alta en el fichero router.db, está información será la que muestre el control de versiones.
          o Router.db: en este fichero daremos de alta los elementos que gestionaremos a través de rancid. El formato del fichero es:
          switch0:hp:up
         o Switch0: Nombre o ip del elemento a gestionar
         o Hp: marca del switch
         o Up: estado del switch
         o routers.all: Una vez ejecutado rancid, aquí se mostrará la información de los elementos gestionados, del mismo modo que en router.db, pero sin el estado.
         o routers.down: En caso de no poder conectar con algún elemento rancid lo pondrá como down hasta nueva comprobación.
        o routers.up: en este fichero irá el caso contrario, los elementos que detecte como levandado los almacenará en este fichero.

Ahora ya estamos en disposición de ejecutar rancid. Para ello ejecutamos el binario rancid-run que encontraremos en /home/rancid/bin/
/home/rancid/bin/rancid-run

 
Una vez acabe podemos ver el correcto funcionamiento, mediante los logs y comprobando si en el directorio /home/rancid/var/<NombreGrupo>/config se ha creado el correspondiente fichero con la información buscada. 

Opcionalmente podemos configurar rancid para enviar un mail cuando una configuración ha sido cambiada después de correr el script de rancid. Para hacer esto, instalamos postfix:

apt-get install postfix

Para permitir el envio de correos desde rancid a nuestro servidor de SMTP, configuramos el archivo /etc/postfix/main.cf, modificando la siguiente entrada:
relayhost= FQDN_or_IP_addresse_of_your_smtp_server
reiniciamos postfix:
/etc/init.d/postfix restart

Podemos probar si los correos llegan, de la siguiente manera.

#telnet localhost 25
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 localhost ESMTP Postfix (Ubuntu)
ehlo mail
250-localhost
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-STARTTLS
250 8BITMIME
mail from: <test@test.com>
250 Ok
rcpt to: <your_email@yourcompany.com>
250 Ok
data
354 End data with .
Subject: This is a test !
Wake up please!
.
250 Ok: queued as BD8261C01D4
quitConnection closed by foreign host.  

Si comprobamos los logs de correo deberiamos ver nuestro correo.

Por último programamos el crontab para que rancid se ejecute cuando sea necesario.

 crontab -e -u rancid

# run ranid-run script every day at 00:30
30 00 * * * /home/rancid/bin/rancid-run

 Listo!.Con esto tendriamos configurado rancid.

Espero que sea de utilidad.

Saludos,

Víctor.