IT Freek Zone

OSSIM: alertas arpwatch por mail que incluyan MAC origen y destino

noreply@blogger.com (d3m4s1@d0v1v0) — Tue, 17 Jan 2012 08:19:40 PST

Desde hace varias semanas vengo peleando con OSSIM y el plugin que utiliza para parsear logs de arpwatch. En el artículo anterior les conté cómo modifiqué el código de arpwatch para que reporte sólo el cambio de MAC de hosts específicos, y no todos los cambios de MACs. Ahora mi meta era hacer que OSSIM me envíe un mail cada vez que detecte el cambio de MAC de estos hosts.

El envío de este tipo de alertas por mail es muy simple y lo describiré luego. Primero veamos qué información brinda el plugin de arpwatch y entenderán por qué tuve que crear un nuevo plugin.

El plugin original (/etc/ossim/agent/plugins/arpwatch.cfg o /etc/ossim/agent/plugins/arpwatch_eth0.cfg) utiliza el tipo de evento host-mac-event, un tipo de evento que posee un conjunto fijo de atributos y no se pueden agregar, ni quitar, ni modificar, a menos que modifiquemos el código C del servidor OSSIM. Los atributos que brinda este tipo de evento, según la documentación oficial, son:

host: IP del host que cambio su MAC
mac: nueva dirección MAC en hexadecmal
vendor: fabricante de la placa
sensor
interface
date
plugin_id: el ID del plugin, el cual es siemrpe 1512 (arpwatch)
plugin_sid: sin importancia ya que el servidor OSSIM asignará el que corresponda
log: contiene una copia del cambio de MAC
userdata1: copia de la nueva dirección MAC nueva
userdata2: copia del nombre fabricante

Si prestan atención, pueden ver que la MAC anterior sólo figura en el atributo log. Cuál es el problema? que el atributo log no se puede utilizar en las acciones (y presupongo que tampoco en las correlaciones, pero no puedo asegurarlo).
Entonces, si no se puede utilizar en las acciones, no es posible enviar mails que incluyan la MAC de origen en ellos, algo que, al menos para mi, es de mucha utilidad.
Supongan que arman una política que les envíe una alerta por mail cada vez que un host importante cambia su MAC. Con el plugin original sólo tendrían la nueva MAC y deberían ir a revisar la larga lista de eventos SIEM para encontrar cual era la MAC anterior y ver la diferencia.

Nuevo plugin para arpwatch

En fin. Para arreglar esto, definí un nuevo plugin para arpwatch, denominado arpwatch_new.cfg (oh si, muy original):

[DEFAULT]
plugin_id=51512

[arpwatch-changed-address]
event_type=event
src_ip={resolv($1)}
host={$1}
interface={$4}
mac={$2}
userdata1={$2}
userdata3={$3}
plugin_sid=2
regexp="arpwatch.*?: changed ethernet address (\IPV4) (\MAC) $(\MAC)$ (\S+)"
vendor=unknown

[arpwatch-flipflop]
event_type=event
src_ip={resolv($1)}
host={$1}
interface={$4}
mac={$2}
userdata1={$2}
userdata3={$3}
plugin_sid=2
regexp="arpwatch.*?: flip flop (\IPV4) (\MAC) $(\MAC)$ (\S+)"
vendor=unknown

[arpwatch-new-station]
event_type=event
src_ip={resolv($1)}
host={$1}
interface={$3}
mac={$2}
plugin_sid=1
regexp="arpwatch.*?: new station (\IPV4) (\MAC) (\S+)"
vendor=unknown

[arpwatch-reused-address]
event_type=event
src_ip={resolv($1)}
host={$1}
interface={$4}
mac={$2}
userdata1={$2}
userdata3={$3}
plugin_sid=2
regexp="arpwatch.*?: reused old ethernet address (\IPV4) (\MAC) $(\MAC)$ (\S+)"
vendor=unknown

[config]
create_file=true
enable=yes
interface=eth0
location=/var/log/ossim/arpwatch-new.log
process=/usr/sbin/arpwatch_eth0
restart=no
restart_interval=\_CFG(watchdog,restart_interval)
shutdown=killall %(process)s
source=log
start=yes
startup=%(process)s -d -d -i %(interface)s -f /var/lib/arpwatch/arp-eth0.dat -N >> %(location)s 2>&1 &
stop=yes
type=detector

Como verán, cambié el identificador a 51512 para no colisionar con el anterior (1512) y utilicé el tipo de evento genérico "event", que permite flexibilidad en los atributos a utilizar. Gracias a esto, ahora puedo ver la MAC origen en el atributo userdata3, mientras que la nueva MAC está en userdata1, como antes.
Para habilitar este nuevo plugin, hay que ingresarlo en las tablas plugin y plugin_sid de la base de datos OSSIM. Esto se hace a través del siguiente archivo sql (arpwatch_new.sql):

-- uncomment the following lines to delete old arpwatch plugin
-- DELETE FROM plugin WHERE id = "1512";
-- DELETE FROM plugin_sid WHERE plugin_id="1512";
-- delete old entries of this plugin
DELETE FROM plugin WHERE id = "51512";
DELETE FROM plugin_sid WHERE plugin_id = "51512";

INSERT INTO plugin (id, type, name, description) VALUES (51512, 1, 'arpwatch_new', 'Ethernet/FDDI station monitor daemon');
INSERT INTO plugin_sid (plugin_id, sid, category_id, class_id, name) VALUES (51512, 1, NULL, NULL, 'arpwatch_new: Mac address New');
INSERT INTO plugin_sid (plugin_id, sid, category_id, class_id, name) VALUES (51512, 2, NULL, NULL, 'arpwatch_new: Mac address Change');
INSERT INTO plugin_sid (plugin_id, sid, category_id, class_id, name) VALUES (51512, 3, NULL, NULL, 'arpwatch_new: Mac address Deleted');
INSERT INTO plugin_sid (plugin_id, sid, category_id, class_id, name) VALUES (51512, 4, NULL, NULL, 'arpwatch_new: Mac address Same');
INSERT INTO plugin_sid (plugin_id, sid, category_id, class_id, name) VALUES (51512, 5, NULL, NULL, 'arpwatch_new: Mac address Event unknown');

Inluir esto en la base de datos es tan simple como ejectutar:
cat arpwatch_new.sql | mysql -u root -p ossim

Luego deben modificar la configuración del agente OSSIM para que incluya este plugin, es decir, comentar la línea del plugin de arpwatch anterior y agregar el nuevo en el archivo /etc/ossim/agent/config.cfg, en la sección plugins:
#arpwatch_eth0=/etc/ossim/agent/plugins/arpwatch_eth0.cfg
arpwatch_new=/etc/ossim/agent/plugins/arpwatch_new.cfg

Finalmente reinicien los servicios de ossim server y agent:
/etc/init.d/ossim-server restart
/etc/init.d/ossim-agent restart
y verifiquen que se encuentre cargado en la pestaña Collections de la interfaz web.

Reporte de cambios por mail

Con el nuevo plugin ya es posible crear una política que ejecute una acción que envíe mails. Las políticas y las acciones se pueden crear fácilmente desde la interfaz web. Para hacerlo, hay que dirigirse a la opción Intelligence -> Policy & Actions.

Primero crearemos la acción que ejecutará el envío de mail, para luego poder seleccionarla en la política. La acción se crea desde la pestaña Actions y dando al botón New. Una acción puede ser la creación de un ticket, o, como deseamos nosotros, el envío de un mail. Este tipo se elige en el desplegable Type. Es obligatorio colocar una descripción de la acción.
El resto de los campos son muy intuitivos, el originario del mail, el destinatario, el asunto y el mensaje. Se pueden utilizar palabras claves especiales tanto en el contenido como en el asunto del mail, las cuales OSSIM reemplazará por el valor correspondiente. En la parte superior de la acción estan los atributos elegibles, entre los que se cuenta con las IPs de orígen y destino, puertos, protocolos y varios campos más. Para el caso en cuestión, lo importante es que el reporte contenga la IP del host y las MACs anterior y nueva, las cuales se encuentran en los atributos userdata1 y userdata3, según lo definimos en el plugin.

La política se crea de forma bastante intuitiva, en la pestaña Policy, dando New y siguiendo los pasos. Los primeros pasos describen atributos que deben tener los paquetes para que esta política se aplique, como IPs orígen y destino, y Ports destino.
Uno de los pasos relevantes es la definición del "DS Groups", donde se elige el grupo de plugins a tener en cuenta a la hora de analizar los paquetes. OSSIM trae algunos grupos de plugins ya armados, pero para nuestro caso, hay que insertar uno nuevo, dandole al link "Insert new DS Group?". En este punto hay que ingresar un nombre y una descripción, acompañado por el plugin a utilizar, que se selecciona dando en el +

En el listado debería aparecer el nuevo plugin que creamos anteriormente con ID 51512. Una vez seleccionado es posible elegir que tipos de evento, del mencionado plugin, deben tenerse en cuenta. Es así como podemos reportar sólo eventos de cambio de MAC y no cuando se ve un host nuevo. El tipo de evento que nos interesa es el que tiene el identificador 2.
Cuando el grupo DS ya está ingresado, es posible seleccionarlo y continuar con la definición de la política.
El otro paso relevante es la elección de las consecuencias que tiene la política. Es decir, qué acción tomar cuando detectamos un evento que cumple con las características descriptas en la política. Para este caso, elegiremos la acción que creamos anteriormente, y además podríamos elevar la prioridad del evento a 5.

En fin

Con estos cambios ya es posible recibir por mail reportes de cambios de MACs en hosts importantes, que incluyan la MAC anterior y la nueva, gracias a la nueva definición del plugin y la política creada.

Referencias

- OSSIM Sensor - The Agent
- Creating a Custom OSSIM 3 policy

Arpwatch con seguimiento de hosts específicos

noreply@blogger.com (d3m4s1@d0v1v0) — Thu, 29 Dec 2011 11:52:09 PST

Desde que instalé arpwatch en la red de la empresa donde trabajo, me encontré con una necesidad imperiosa. Nuestra red otorga las IPs de las workstations por DHCP, pero en la misma red existen host importantes que tienen IPs fijas.
Arpwatch no se desempeña demasiado bien en redes con DHCP, dado que con este esquema las IPs de las máquinas suelen cambiar cada tanto, generando reportes sin utilidad para quien revisa los logs de seguridad. Entre tantos reportes sin utilidad pueden quedar escondidos reportes que si nos interesan, como por ejemplo ver que la IP de un proxy, gateway, server, cambió su MAC, algo que es en extremo sospechoso y muy importante para detectar intrusos.
De esta manera tenemos una herramienta muy simple y poderosa, pero que al generar tantos reportes molestos, resulta poco útil en este tipo de redes.

Para obtener lo mejor de esta herramienta contaba con dos opciones:
1) desarrollar un script que parsee los logs buscando sólo las IPs que me interesan,
2) agregar al código de arpwatch la funcionalidad necesaria para poder filtrar ciertas IPs.

La primera era más rápida y simple, pero la segunda mucho más interesante. Por fin esta semana conté con tiempo libre, así que puse manos a la obra y actualicé el código de arpwatch para que incluya esta funcionalidad. Esta es una de las grandes ventajas de utilizar software libre, si necesitas más funcionalidad, podes agregarla vos mismo!

Por lo que encontré, arpwatch no se actualiza desde 2006, pero hay parches como el de debian, que agregaron cierta funcionalidad. Como ya sabrán, utilizo debian para todo y es la base de una gran porción de distribuciones, así que decidí partir del paquete de debian. Este paquete incluye opciones como ignorar una red entera, o enviar reportes por mail, y pueden verlas marcadas con el prefijo "(Debian)" en la man page.

Yendo al grano, qué provee el código que desarrolle?
- la posibilidad de reportar cambios de MAC sólo de IPs específicas
- una nueva opción en la línea de comandos (-H <filename>) para activar esta funcionalidad e indicar el archivo donde se encuentran los hosts a seguir
- configuración simple del archivo de hosts a seguir:
- se puede especificar un host según su IP (ej: 192.168.0.2), hostname (mihost.mired.com), o red entera (192.168.0.0/24),
- es posible dejar líneas en blanco para separar grupos de host visualmente
- permite la adición de comentarios utilizando el símbolo # al comienzo de cada línea.
- man page actualizada explicando la nueva funcionalidad.

Si por ejemplo quisiéramos seguir sólo los hosts 192.168.0.2, www.miempresa.com, y la red 192.168.10.0/24, el archivo de hosts (denominado hosts.dat) podría ser:
#ip interna
192.168.0.2

#web de la empresa
www.miempresa.com

#red de compras
192.168.10.0/24

Luego bastaría con ejecutar arpwatch de la siguiente manera:
# arpwatch -H hosts.dat

La instalación de esta nueva versión debe hacerse de la siguiente manera:
1) descargar el código de arpwatch original
2) descargar el parche de debian
3) descargar mi parche
4) desomprimir el código original y los parches:
$ tar -xzvf arpwatch_2.1a15.orig.tar.gz
$ tar -xzvf arpwatch_2.1a15-1.1.diff.gz
$ tar -xzvf arpwatch-2.1a15-2-diff.diff.gz
5) parchar el código original con el parche de debian, parados en el directorio del código original:
$ cd arpwatch_2.1a15
$ patch < ../arpwatch_2.1a15-1.1.diff
6) parchar lo anterior con la extensión que programé:
$ patch < ../arpwatch-2.1a15-2-diff.diff
7) compilar:
$ ./configure
$ make
8) instalar:
$ make install

Algo a tener en cuenta es que deberán tener las fuentes de pcap para poder compilar arpwatch. En debian el paquete se denomina libpcap-dev.

Si tienen alguna duda o encuentran algún fallo en el programa, por favor reportenmelo. Contacté al maintainer del paquete en debian y espero le interese incorporar este parche para ampliar la funcionalidad de esta excelente herramienta.
Espero les resulte tan útil como a mi!

Que tengan un feliz año nuevo y arranquen el 2012 con todo. Recuerden que, según los mayas, será el último =P

Mucho boom tecnológico pero la ignorancia en seguridad sigue igual...

noreply@blogger.com (d3m4s1@d0v1v0) — Mon, 05 Dec 2011 17:00:49 PST

Una vez más me veo sorprendido por la ignorancia que existe en el mundo TI acerca de conceptos básicos de seguridad. En los casi tres años que llevo trabajando en seguridad informática, toda aplicación que audité (desktop o web) poseía vulnerabilidades críticas y muy básicas.

Cuando recién empecé a trabajar en el rubro, creía que vulnerabilidades como buffer overflow, SQL Injection, XSS, eran raras de encontrar debido a la gran difusión que poseen y lo fáciles que son de evitar, sin embargo, tres años de experiencia y trato con una cantidad considerable de desarrolladores y empresas (más de 15), me demostraron lo contrario.
Lo peor no es encontrar que toda aplicación que analizo es vulnerable a ataques simples, sino que al tratar con los desarrolladores me encuentro con una ignorancia espeluznante. Muy pocos de los programadores con los que traté conocían al menos de nombre los ataques, y la gran mayoría no tenía ni idea de cómo solucionar los problemas.
Es así como me encuentro una y otra vez explicando ataques, explicando métodos para mitigarlos, demostrando dónde están los errores. Cada proveedor de software con el que tengo contacto tengo que volver a explicar lo mismo. Lo más indignante es que la gran mayoría te termina tratando como que lo que pedís es exagerado, que controles así no se utilizan, que la seguridad no se encuentra en los requerimientos! (WTF!) La defensa de las empresas de desarrollo es atacar en lugar de reconocer su ignorancia. Pedir más dinero por lo que debería haber estado contemplado desde el principio, culpar al auditor de retrasar la puesta en producción de productos incompletos y de baja calidad, porque recuerden amigos, la seguridad forma una parte esencial del software de calidad.

Al principio creía que la falta de conocimiento era local en la ciudad donde vivo, pero luego de tratar con muchas empresas de Buenos Aires y, recientemente, extranjeras, me terminaron de demostrar que la ignorancia es general.
El catalizador de este post es que en estos días me tocó auditar una aplicación web provista por una importante empresa de Brasil. Lo raro no fue encontrar que el sitio era vulnerable a distintos ataques, sino que al entablar conversaciones con los desarrolladores encontré la mayor ignorancia en seguridad que vi en estos tres años. No tenían absolutamente idea de nada relacionado a seguridad web, no habían escuchado ni nombrar ataques de SQL Injection, XSS, XSRF, ni OWASP, ni mucho menos prepared statements o como escapar caracteres HTML, NADA! En la conferencia que tuvimos tuve que improvisar una suerte de cátedra en seguridad Web. Realmente se hace muy muy difícil que alguien entienda los riesgos de lo que estas exponiendo si no tienen idea de lo que estás tratando. Decían que yo era un genio por lo que había descubierto y que el 99.9% de la gente no podría encontrar esos errores... si bien me sentí alagado, me causó mucha gracia, dado que las técnicas que emplee eran tan simples que cualquiera siguiendo un tutorial de la web podría hacerlo.

En una era donde todo está informatizado y poco a poco todo se va moviendo hacia servicios cloud, tener tanta información en la web en manos de desarrolladores que no tienen ni idea de cómo protegerla, o peor aún, no les interesa, realmente da miedo.

Por favor, si estás leyendo esto y sos desarrollador, toma conciencia, capacitate en seguridad, como mínimo date una vuelta por la web de OWASP. La seguridad es MUY fácil de implementar, y aprender, sólo necesitas saber conceptos básicos, no necesitas ser un experto en el tema, basta con estar interesado en mejorar como programador.

Yo seguiré aportando mi granito de arena desde este blog y dando conferencias donde pueda, espero lograr aunque sea un pequeño cambio. Algo es seguro, ninguna empresa que haya desarrollado para la empresa que trabajo se olvidará de los conceptos que les enseñé y sabrán que mientras esté ahí no podrán obviar la seguridad en sus programas, así me hayan odiado por ello =)

Montar shares SMB/CIFS + Automontar shares SMB/CIFS en redes kerberizadas

noreply@blogger.com (d3m4s1@d0v1v0) — Fri, 18 Nov 2011 10:26:01 PST

Si son seguidores del blog, saben que utilizo un GNU/Linux unido a un dominio AD desde hace tiempo. Algo que siempre estuve por configurar es el automontaje de los shares para no tener que escribir las direcciones una y otra vez. Hoy llegó el momento =D
A continuación describiré un poco cómo acceder y montar shares SMB en GNU/Linux y luego les mostraré cómo hacer para que un share se monte automáticamente al inicio de sesión, utilizando el ticket kerberos que nos entrega el controlador de dominio en el login.

Montar shares

Para los que trabajan con GNU/Linux es muy común acceder sistemas de archivos Windows a través del protocolo SMB (CIFS es el nombre actual del protocolo). Samba posee una excelente compatibilidad con el protocolo y provee diversas herramientas para el acceso.
Una vez que Samba está instalado, acceder un servidor de archivos es tan simple como escribir la siguiente URL en su navegador de archivos favorito (Dolphin, Nautilus, Krusader, etc):

smb://server1.ejemplo.com/

donde server1.ejemplo.com es el nombre del servidor.
En una red hogareña, sin AD, la autenticación con el servidor se realiza utilizando el viejo NTLM, con lo cual, al tipear la URL anterior, el navegador les pedirá que ingresen las credenciales de un usuario válido (desde la visión del servidor).

Otra forma de acceder a los archivos es montar el sistema remoto en un directorio local. El paquete smbfs provee soporte para el sistema de archivos smb/cifs, el cual se puede utilizar en el comando mount de la siguiente manera:

mount -t cifs //server1.ejemplo.com /media/samba -o user=pepe

Al ejecutar el comando anterior, aparecerá un prompt solicitando el password del usuario en cuestión.
Por supuesto que también es posible agregar una entrada en /etc/fstab para hacer el montaje más rápido y/o automático. La entrada en fstab correspondiente al ejemplo anterior es la siguiente:

//server1.ejemplo.com /media/samba cifs user,auto,username=pepe 0 0

donde las opciones son:

user -> para que lo pueda montar un usuario común (sin ser root)
auto -> debe montarse automáticamente al iniciar el sistema
username=pepe -> especifica el nombre del usuario a utilizar

Claro que al intentar montar el sistema solicitará el password correspondiente. Hay dos formas de evitar que esto pase, aunque ninguna es muy atractiva:

- utilizar la opción password=
- crear un archivo (por ejemplo /home/pepe/cred.smb) que contenga las líneas:
username=pepe
password=elpassword

y luego utilizar la opción credentials=/home/pepe/cred.smb en fstab.
Digo poco atractivas porque en ambos casos es necesario colocar las credenciales en texto plano. Con la segunda opción se evita que otro usuario abra el fstab y vea el password, pero igualmente no es del todo satisfactoria.

Automontar shares en redes corporativas

En una red corporativa con servidores Windows, es muy probable que se utilice Active Directory. La autenticación en estos entornos se lleva a cabo utilizando kerberos, aunque por defecto (al menos hasta Windows 2003) los servidores de archivos soportan NTLM por compatibilidad. Incluso en redes corporativas con servicios integrados con kerberos provistos por servidores GNU/Linux se está utilizando bastante Samba como protocolo para la compartición de archivos, lo que hace doblemente atractiva la siguiente explicación.

Ahora, gracias a Samba y PAM, es posible mejorar el esquema de clientes Linux dentro de la corporación. Algo muy común es que los usuarios de workstations con Windows tengan mapeos automáticos al realizar un login, como por ejemplo el disco F:\ apuntando al servidor server1.ejemplo.com. Un cliente GNU/Linux puede tener esta misma comodidad, con mapeos automáticos de shares de red al árbol de directorios de su máquina.

La siguiente configuración tiene en cuenta que la workstation GNU/Linux autentica usuarios contra Domain Controllers (o servidores kerberos de GNU/Linux) con PAM y kerberos, como se explicó en el artículo Configurar PAM para utilizar kerberos.
Utilizando el entorno descripto en el artículo, los usuarios contarán con un ticket kerberos luego de que se autentiquen. Como Samba es compatible con kerberos, no es necesario seguir ingresando las credenciales al montar o acceder un share, Samba hará la autenticación de forma transparente utilizando el ticket correspondiente.

No existe una alternativa segura para hacer que un usuario monte un share que no figure en el fstab, sólo un administrador puede hacerlo. Claro que no sirve colocar una entrada en fstab que intente montar automáticamente un share, dado que se hará a nombre de root y root no posee un ticket kerberos... es decir, access denied!

La solución entonces consta de dos pasos. Agregar la línea en el fstab, y luego configurar kde, gnome, o el desktop que utilicen, para que realice el mount cuando el usuario se loguea.
Teniendo en cuenta el ejemplo con el que venimos trabajando, deberá agregarse la siguiente línea en fstab para utilizar kerberos:

//server1.ejemplo.com /media/samba cifs user,noauto,sec=krb5 0 0

las opciones relevantes aquí son:

noauto -> no montar automáticamente
sec=krb5 -> indica a samba que utilice kerberos en la autenticación

Para el automontaje se crea un script en bash (o su shell favorito) con el siguiente contenido:

#!/bin/bash
mount //server1.ejemplo.com

y se coloca en el directorio correspondiente (dándole ejecución con chmod +x) para que desktop lo ejecute al iniciar la sesión del usuario. Por ejemplo:

- en kde deberá colocarse en $HOME/.kde/Autostart/
- en gnome debe abrirse el "Gnome Control Center" ir a "aplicaciones al inicio" y agregar la ruta al script.

De esta forma, una vez que el usuario se validó contra kerberos, el sistema automáticamente montará sus shares en el lugar correspondiente, una verdadera comodidad, y un paso más para extender el uso de GNU/Linux en las corporaciones =)

El siguiente paso es agregar un script que desmonte los shares una vez que el usuario ejecuta logout, porque si la misma workstation es compartida por diferentes usuarios, dejar el acceso a los shares de otro usuario no es buena idea. Esta tarea debe realizarse con un script similar al anterior:

#!/bin/bash
umount //server1.ejemplo.com

y colocarlo en el directorio correspondiente al desktop que utilicen. Por ejemplo:

- en kde existe el directorio $HOME/.kde/shutdow destinado a tal fin
- en gnome ??? (avísenme si lo encuentran)

To Do

Como bien dije, no es posible que los usuarios monten los shares que no se encuentren definidos en fstab. Es decir, en fstab deben figurar todos los shares disponibles para los usuarios de una dada workstation, porque sino no podrán montarlos. Esto es un inconveniente bastante molesto, dado que si el usuario puede acceder a los shares, no tiene mucho sentido restringir para que no pueda montarlo en el árbol de directorios local.
Existe, claro, una forma indirecta y que en general es considerada insegura. La misma se basa en otorgar setuid root al ejecutable mount.cifs. Con esto, cuando un usuario ejecute el comando mount.cifs, éste se ejecuta con permisos de root, y por consiguiente puede montar los shares, aunque en este caso, probablemente no funcione el ticket kerberos (no lo probé). Queda en ustedes si se deciden por esta alternativa.

Referencia

- Samba HowTo: Mount a CIFS Network Share [Mapped Drive] in openSUSE

Migrar mails locales de Evolution a Thunderbird/Icedove

noreply@blogger.com (d3m4s1@d0v1v0) — Mon, 17 Oct 2011 02:21:00 PDT

Luego de utilizar Evolution durante un par de años en el trabajo, encontré la forma de integrar Thunderbird con Exchange, y como este cliente siempre me gustó mucho más que el primero, decidí migrar. El problema es que había acumulado miles de mails en carpetas locales de Evolution y los necesitaba en Thunderbird.
Por suerte, ambos clientes utilizan el mismo formato para almacenar los mails (formato mailbox), así que son totalmente compatibles y lo único que hay que hacer es copiar los archivos de un directorio a otro.
En Evolution, los mails locales pueden estar almacenados, dependiendo la distribución y/o versión, en:

/home/<usuario>/.evolution/mail/local

o en:

/home/<usuario>/.local/share/evolution/mail/local_mbox/

Debian almacena los mails en la segunda opción, así que mostraré los comandos en base a este directorio, aunque es lo mismo si está en el otro.
Por su parte, Thunderbird almacena los mails locales en:

/home/<usuario>/.thunderbird/<valor random>.default/Mail/Local\ Folders

o si utilizan Icedove (debian y algunos derivados):

/home/<usuario>/.icedove/<valor random>.default/Mail/Local\ Folders/

Para migrar los mails de uno a otro, simplemente basta con copiar el contenido de una carpeta en la otra:

cp -R /home/demasiadovivo/.local/share/evolution/mail/local_mbox/* /home/demasiadovivo/.icedove/3uomqof5.default/Mail/Local\ Folders/

Ahora, cada cliente almacena distintos metadatos sobre los mailboxes, así que si hacen un copy como el de recién y abren Thunderbird, verán que, además de las carpetas personales tendrán un montón de carpetas vacías con nombres que terminan en .cmeta, .data y .index. Esto se debe que son metadatos para Evolution, son interpretados por Thunderbird como directorios. Por ello hay que eliminarlos.
La forma más rápida de hacerlo es con un find que ejecute un rm:

find /home/demasiadovivo/.icedove/3uomqof5.default/Mail/Local\ Folders/ -type f $ -name '*.cmeta' -o -name '*.data' -o -name '*.index' $ -exec rm -r {} \;

El comando anterior busca todos los archivos de extensión .cmeta, .data e .index que estén en el directorio de mails de Thunderbird y luego ejecuta un rm.

Con esto, al iniciar Thunderbird verán que tienen sólo los directorios originales, con todos sus mails adentro.

Referencias

- How To Migrate From Evolution To Thunderbird In Ubuntu Intrepid
- Migrar de Evolution a Thunderbird
- Linux or Unix find and remove files with one find command on fly

Autenticar con kerberos y almacenar información de usuarios con LDAP en GNU/Linux

noreply@blogger.com (d3m4s1@d0v1v0) — Wed, 12 Oct 2011 06:28:59 PDT

En los artículos anteriores se explicaron las bases del funcionamiento y utilización de kerberos, LDAP y PAM. Además se explicó cómo autenticar usuarios de GNU/Linux utilizando kerberos. Con esta información en mente, ahora somos capaces de armar un servicio de autenticación centralizada para hosts GNU/Linux, que utilice estos ampliamente aceptados y utilizados servicios.

Para lograr que toda la información de usuarios y grupos se almacene y administre en servidores LDAP, debemos encontrar la forma de que las workstations GNU/Linux se comuniquen con LDAP para obtener los datos que comúnmente se encuentran en los archivos /etc/passwd, /etc/shadow y /etc/group.

En /etc/passwd tenemos los datos concernientes a los usuarios del sistema. Cada entrada representa un usuario y los campos almacenados son los siguientes:

credenciales (sólo el nombre de usuario se almacena en /etc/passwd, cuestiones de contraseña se encuentran en /etc/shadow)
ID, identificador de usuario
grupos a los cuales pertenece
nombre real
directorio home (ej: /home/demasiadovivo)
shell a utilizar (opcional)

Como ya adelanté en el punto anterior, /etc/shadow contiene información de contraseñas. Las contraseñas se almacenan hasheadas (o encriptadas en soluciones antiguas) utilizando un salt. Los campos que se almacenan para cada usuario son:

nombre de login
hash del password o el password encriptado.
fecha del último cambio de password.
edad mínima de un password, es decir, el número de días que el usuario debe esperar entre cambios de passwords.
edad máxima de un password. Duración del password, es decir, cuanto tiempo podemos usar un password como máximo.
período de advertencia. Cuántos días antes de que el password expire, el sistema debe avisar al usuario que esto sucederá.
período de inactividad de un password. La cantidad de días que un password debe ser aceptado para generar uno nuevo, luego de que el password expiró. Una vez que este período expira, el usuario no podrá loguearse más y deberá contactar al administrador.
fecha de expiración del usuario, en formato timestamp Unix.

Por su parte /etc/group contiene los datos de los grupos, donde para cada grupo se almacena lo siguiente:

nombre de grupo
contraseña de grupo encriptada (opcional)
GID, o identificador de grupo
lista de los usuarios que pertenecen al grupo

Cambiar el mecanismo de autenticación de usuarios en GNU/Linux es simple gracias a PAM (ver artículo anterior).
El problema con PAM, es que no permite acceder el resto de la información del usuario almacenada en un LDAP, es decir, información comúnmente almacenada en passwd, shadow y group. Para ello debemos valernos de otra herramienta, llamada NSS (Name Service Switch).
NSS permite utilizar distintas fuentes para obtener diferentes tipos de datos comunes, como los datos de usuario citados anteriormente. Es decir, agrega transparencia al resto de los programas a la hora de acceder dinstinta información. NSS es la capa que permite a un administrador configurar los sistemas para que obtengan de fuentes remotas datos que normalmente se buscarían en archivos locales en /etc (como passwd, group, hosts, etc).
Gracias a NSS, ahora podremos almacenar los datos que nos interesen, como los de usuarios y grupos, en LDAP, simplemente configurando el archivo /etc/nsswitch.conf

Creación de usuarios en kerberos

Para autenticar usuarios con kerberos, primero debemos agregar los principals correspondientes en la base de datos. Agregar un principal para un usuario es tan fácil como ejecutar addprinc utilizando kadmin:

# kadmin.local
Authenticating as principal root/admin@DEMASIADOVIVO.ORG with password.
kadmin.local: addprinc demasiadovivo
WARNING: no policy specified for demasiadovivo@DEMASIADOVIVO.ORG; defaulting to no policy
Enter password for principal "demasiadovivo@DEMASIADOVIVO.ORG":
Re-enter password for principal "demasiadovivo@DEMASIADOVIVO.ORG":
Principal "demasiadovivo@DEMASIADOVIVO.ORG" created.

Podemos checkear que el usuario se creó correctamente ejecutando kinit y klist:

# kinit demasiadovivo
Password for demasiadovivo@DEMASIADOVIVO.ORG:
# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: demasiadovivo@DEMASIADOVIVO.ORG
Valid starting Expires Service principal
06/22/11 14:07:18 06/23/11 00:07:18 krbtgt/DEMASIADOVIVO.ORG@DEMASIADOVIVO.ORG
renew until 06/23/11 14:07:14

Lo que hicimos fue obtener un ticket para el usuario demasiadovivo (con kinit), y luego listar los tickets cacheados en la máquina (klist). Como pudieron ver, /tmp/krb5cc_0 es nuestro ticket. Con klist se pueden ver varias propiedades de los tickets, como algoritmos de encripción (-e), direcciones en las credenciales (-a), etc. kinit también acepta varios parámetros, como tiempo de vida (-l), hora de inicio (-s), renovar un ticket (-R), etc.

Creación de usuarios en LDAP

Si bien podríamos utilizar la autenticación LDAP para autenticar los usuarios, lo mejor es utilizar el confiable kerberos, y dejar LDAP para almacenar los datos de usuarios, grupos y demás.
Como vimos anteriormente, debemos almacenar ciertos atributos del usuario que normalmente estarían en /etc/passwd. Dado que la autenticación la realizamos con kerberos, no es necesario almacenar el password del usuario, aunque esto podría hacerse si se quisiera autenticar con LDAP.

Existe un RFCs (RFC 2307), que describe un mecanismo para mapear entidades UNIX al estándar X.500, para que los atributos se puedan resolver utilizando LDAP. Si bien este documento es experimental, se utiliza ampliamente en el mundo UNIX.
La librería NSS-LDAP utiliza este mapeo para resolver los atributos del usuario, por lo tanto es el formato que debemos adoptar para crear las entradas en el LDAP. OpenLDAP trae esquemas predefinidos para este mapeo, los cuales pueden encontrar en /etc/ldap/schema/nis.schema. Los objectClass que utilizaremos comúnmente son posixAccount, shadowAccount y posixGroup.

Veamos cómo se mapea cada campo del /etc/passwd en atributos LDAP:

login name = uid
user ID = uidNumber
group ID = gidNumber
nombre de usuario = cn para el nombre y sn para el apellido.
directorio home = homeDirectory
shell = loginShell (opcional)

Los usuarios que deseemos autenticar con Kerberos y LDAP deberán tener definida una entrada con estos datos, en la unidad organizativa (OU) People, y con posixAccount como objectClass. El Distinguished Name (DN) de cada usuario tendrá el formato uid=,ou=People,dc=demasiadovivo,dc=org.

Por su parte, el equivalente de atributos para cada grupo es el siguiente:

nombre del grupo = cn
contraseña = userPassword (opcional)
group ID = gidNumber
lista de usuarios = memberUid

Los grupos deben situarse en la OU Group y con posixGroup como objectClass. El DN se arma utilizando cn=,ou=Group,dc=demasiadovivo,dc=org.

Ahora que contamos con los datos suficientes para crear un usuario, creemos el archivo user1.ldif donde pondremos la definición de nuestro primer usuario y grupo.

dn: cn=Administrador_Seguridad,ou=Group,dc=demasiadovivo,dc=org cn: Administrador_Seguridad gidNumber: 2000 objectClass: top objectClass: posixGroup
dn: uid:demasiadovivo,ou=People,dc=demasiadovivo,dc=org uid: demasiadovivo uidNumber: 2000 gidNumber: 2000 cn: Victor objectClass: top objectClass: person objectClass: posixAccount objectClass: shadowAccount loginShell: /bin/bash homeDirectory: /home/demasiadovivo

En la definición encontramos varios objectClass. Para el caso de grupos, utilizamos la ya mencionada posixGroup, mientras que para usuarios usamos person, posixAccount, y shadowAccount. La clase person nos permite agregar información atributos como número de teléfono y descripción. Por su parte, shadowAccount permite agregar atributos concernientes al tratamiento de passwords, como el password en si, fecha de último cambio, y resto de información que se encuentra en /etc/shadow. Si bien no almacenaremos passwords en LDAP, sí resulta útil guardar el resto de la información referente al mismo.

Para agregar el usuario, ejecutamos ldapadd de la siguiente manera:
ldapadd -c -x -D cn=admin,dc=demasiadovivo,dc=org -W -f user1.ldif
Podemos verificar los datos recien ingresados con:

ldapsearch "(uid=demasiadovivo)" -x

ldapsearch "(cn=Administrador_Seguridad)" -x

Configurar PAM para utilizar kerberos

Este paso ya se explicó en el artículo del mismo nombre que pueden encontrar aquí.

Configurar NSS para utilizar LDAP

Como ya adelante en las secciones anteriores NSS (Name Service Switch) es una funcionalidad provista por la librería GNU C para independizar a las aplicaciones de la ubicación de los servicios.
Antíguamente los datos se buscaban en archivos locales como /etc/passwd, /etc/group, /etc/hosts, etc, pero con el crecimiento de tecnologías de base de datos centralizadas como DNS, NIS, LDAP, etc, se hizo evidente la necesidad de contar con un servicio que abstraiga al programa de la ubicación de los datos. Por ello se creó NSS, basándose en un método utilizado por Sun en Solaris 2.
NSS permite al administrador configurar dónde se encontrarán los datos de diferentes bases de datos a través del archivo nsswitch.conf. Incluso se puede establecer un orden sobre qué base de datos consultar primero. El programa sólo utiliza una llamada al sistema y se olvida de donde se encuentran los datos. Gracias a esto, cambiar de base de datos es muy simple. Este caso es muy similar al de PAM.
Entre las bases de datos que podemos configurar tenemos:

password: información de usuarios. Default /etc/passwd
group: información de grupos de usuarios. Default: /etc/group
shadow: contraseñas de usuario. Default: /etc/shadow
hosts: nombres de computadoras. Default: /etc/hosts
network: nombres de redes. Default: /etc/networks

Algunas posibles fuentes de datos son:

files: archivos, por ejemplo /etc/passwd
compat: se puede usar para traer información de usuarios y grupos en archivos con nueva sitaxis como /etc/passwd, /etc/shadow, /etc/group
dns: obtener la información de hosts de servidores DNS
ldap: traer los datos del directorio LDAP

Para utilizar LDAP como base de datos de usuarios, deberemos instalar la librería NSS correspondiente. Antes de hacer este paso, es recomendable hacer un backup de los archivos /etc/pam.d/{common-auth,common-account,common-password,common-session}:
cp /etc/pam.d/{common-auth,common-account,common-password,common-session} /root/backup
Luego entenderán porque es necesario este backup.
Ahora si, instalamos la librería libnss-ldapd que provee servicios LDAP para NSS, y el demonio nslcd que es el encargado de realizar las búsquedas LDAP para los procesos que quieran información de usuarios, grupos, etc:

# apt-get install libnss-ldapd nslcd

NOTA: Algo a tener en cuenta aquí es utilizar libnss-ldapd y no libnss-ldap. Con la segunda no pude realizar autenticación de usuarios utilizando GSSAPI, a pesar de mucho intentarlo. libnss-ldapd es más nueva y mejora varias cuestiones de libnss-ldap.

En la instalación, debconf requerirá algunos datos de configuración.
Para el paquete libnss-ldapd:

Servicios a configurar para que utilicen LDAP. Los valores por defecto sirven para la mayoría de los casos: passwd, shadow, y group.

Por su parte, el paquete nslcd solicita:

URI del servidor LDAP: ldap://ldap.demasiadovivo.org/
DN base para las búsquedas ldap: dc=demasiadovivo,dc=org

El siguiente paso es configurar NSS para que utilice LDAP para buscar información de usuarios. Para esto, hay que editar el archivo /etc/nsswitch.conf para que quede de la siguiente manera:

passwd: files ldap group: files ldap shadow: files ldap
hosts: files dns networks: files
protocols: db files services: db files ethers: db files rpc: db files
netgroup: nis

Se puede observar que el sistema intentará resolver los datos de usuario localmente, y si no puede, consultará al servidor ldap.
Como el demonio nscd cachea los valores, es necesario reiniciarlo:

# /etc/init.d/nscd restart

Para testear la configuración, se puede utilizar el comando getent. Este comando permite obtener entradas de la base de datos administrativa, esto incluye passwd, group, hosts, services, protocols y networks.
La mejor forma de ver que todo está funcionando es obtener los datos de un usuario que esté declarado en el servidor LDAP, pero que no esté localmente. Si por ejemplo el usuario demasiadovivo no se encuentra declarado en el /etc/passwd local y si en el LDAP, pueden probar el siguiente comando:

$ getent passwd demasiadovivo demasiadovivo:x:2000:2000:Victor:/home/demasiadovivo:/bin/bash

Pueden corroborar que el usuario no existe localmente mirando /etc/passwd.
Si ejecutan "getent passwd" sin un nombre de usuario, pueden ver la base de datos completa de usuarios, que incluye a los locales y a los de LDAP.

Prueba de login

Bien, ya tenemos todo lo necesario para ver si nuestro sistema centralizado de usuarios está funcionando correctamente. Veamos los pasos que seguimos hasta aquí:

instalamos kerberos
instalamos LDAP
dimos de alta al usuario demasiadovivo en kerberos y configuramos un password
dimos de alta al usuario demasiadovivo en LDAP, donde pusimos toda la información necesaria del /etc/passwd
configuramos PAM en la máquina cliente para que autentique utilizando kerberos. Incluso agregamos una regla en common-session para que se cree un directorio home para los usuarios que no existan localmente.
configuramos NSS en la máquina cliente para busque los datos del usuario en LDAP

Ufff, fue mucho trabajo, pero si todo fue bien, estamos al borde de la gloria (?!). La prueba? loguearnos con el usuario demasiadovivo en la máquina cliente y ver si anda =D

machine login: demasiadovivo Password: Linux machine 2.6.32-5-amd64 #1 SMP Mon Mar 7 21:35:22 UTC 2011 x86_64
The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. Creating directory '/home/demasiadovivo' machine@demasiadovivo:~$ id uid=2000(demasiadovivo) gid=2000(Administrador_Seguridad) grupos=2000(Administrador_Seguridad)

yeah! como se puede observar, el sistema automáticamente creó el directorio home y asignó los IDs correspondientes al usuario, como se declaró en la correspondiente entrada LDAP.

CUIDADO!
Algo que hay que tener muy en cuenta es que kerberos utiliza verificación de host resolviendo el nombre de la máquina desde donde nos conectamos. Por ello es necesario tener definido el nombre de la máquina y el mapeo IP-nombre (registro PTR) en el servidor DNS. Caso contrario, pueden encontrarse con el siguiente error en /var/log/auth.log:

pam_krb5(login:auth): (user demasiadovivo) credential verification failed: Hostname cannot be canonicalized

Referencias

- Authentication against LDAP servers
- PADL Software Pty Ltd - nss_ldap
- OpenLDAP installation on Debian
- MIT Kerberos installation on Debian
- OpenLDAP provider with MIT Kerberos V on Debian squeeze
- OpenLDAPServer
- SingleSignOn
- The POSIX API
- Linux NSS (libnss) and nss_ldap problems and possible solutions
- LDAPClientAuthentication
- LDAP Implementation HOWTO - 2. LDAP authentication using pam_ldap and nss_ldap
- opensolaris - About the Name Service Switch
- NSS Wiki
- Linux Authentication Using OpenLDAP, Part One
- ZYNTRAX - Chapter 5. OpenLDAP Samples - 5.2 Securing the Directory
- SEAM Error Messages and Troubleshooting
- Kerberos and LDAP
- Replacing NIS with Kerberos and LDAP HOWTO
- LDAP System Administration - A.2 Name Service Switch (NSS)

Configurar PAM para utilizar kerberos

noreply@blogger.com (d3m4s1@d0v1v0) — Wed, 28 Sep 2011 04:55:32 PDT

En artículos anteriores se explicó cómo funciona kerberos y la forma de utilizarlo en GNU/Linux. Las workstations con Linux instalado pueden autenticar sus usuarios contra servidores de este tipo, ya sea que los mismos utilicen Linux, Windows (Active Directory), o cualquier otro SO que implemente el estándar. La configuración descripta a continuación es la misma sin importar sobre qué plataforma se implemente el servicio kerberos. Es decir, se puede utilizar, por ejemplo, para autenticar clientes Linux contra el servicio Active Directory de Windows.

Para la autenticación con kerberos, hay que instalar el módulo de PAM correspondiente, en todos los clientes. En debian, el paquete se denomina libpam-krb5:

# apt-get install krb5-{config,user} libpam-krb5

Durante la instalación, debconf requerirá algunos datos para continuar:

- el nombre del realm: DEMASIADOVIVO.ORG
- servidores kerberos para el realm, separados con espacios.
- servidor administrativo para el realm, para administrar cambio de contraseña.

Estos son los mismos datos que configuramos al instalar el servidor kerberos. Toda esta configuración se puede cambiar en el archivo /etc/krb5.conf.
En este archivo, como se explicó en la instalación del servidor, pueden eliminar todos los realms que aparecen en la instalación default (athena, mit, etc), y deberán agregar el dominio de su realm en la sección domain_realm:

[domain_realm]
.demasiadovivo.org = DEMASIADOVIVO.ORG
demasiadovivo.org = DEMASIADOVIVO.ORG

Luego de que se instala el módulo de kerberos, debian automáticamente establece en PAM que la autenticación de usuarios debe utilizar este protocolo. Si no están utilizando debian, tal vez requieran una configuración adicional para empezar a utilizarlo.

Veamos entonces cómo deberían quedar cada uno de los archivos de PAM, y el significado de cada configuración:

/etc/pam.d/common-account

account [success=1 new_authtok_reqd=done default=ignore] pam_unix.so
account requisite pam_deny.so
account required pam_permit.so
account required pam_krb5.so minimum_uid=1000

Se puede observar que este archivo es muy similar a cuando se utiliza sólo autenticación Unix. Para agregar la autenticación de kerberos, se agrega una línea final que invoca el módulo pam_krb5 con el argumento minimum_uid=1000.
En este caso, el sistema invoca tanto el módulo pam_unix como pam_krb5 como required, lo cual implica que si alguno de estos falla, la operación falla. El argumento "minimum_uid=1000" hace que la autenticación kerberos se aplique a los usuarios cuyo user ID sea mayor a 1000. Esto permite tener cuentas locales como la de root (uid=0), la cual no autentica contra kerberos.

/etc/pam.d/common-auth

auth [success=2 default=ignore] pam_krb5.so minimum_uid=1000
auth [success=1 default=ignore] pam_unix.so nullok_secure try_first_pass
auth requisite pam_deny.so
auth required pam_permit.so

En este archivo podemos ver como funciona la autenticación propiamente dicha. Primero se intenta autenticar con kerberos a los usuarios cuyo uid es mayor o igual a 1000. Si esto tiene éxito, se salta a la línea pam_permit (success=2) y el usuario puede entrar. Si la autenticación kerberos falla, se intenta con la autenticación unix tradicional, permitiendo password en blanco (nullok_secure), y utilizando el mismo password que se utilizó en la autenticación kerberos (try_first_pass). Esto último se hace para que el sistema no requiera el password dos veces cuando la autenticación kerberos falla. Si ninguna de las autenticaciones es exitosa, se niega el acceso (pam_deny).

/etc/pam.d/common-pasword

password requisite pam_krb5.so minimum_uid=1000
password [success=1 default=ignore] pam_unix.so obscure use_authtok try_first_pass sha512
password requisite pam_deny.so
password required pam_permit.so

Para el cambio de password se utiliza como requisito pam_krb5 con uid mayor igual a 1000. Si esto falla, el password no se actualiza. Si el password kerberos se actualiza correctamente, se intenta actualizar el password local, utilizando el mismo pass ingresado para kerberos (use_authtok). El resto de los argumentos de pam_unix son los mismos que cuando se utiliza autenticación tradicional, donde obscure checkea fortaleza del pass, y sha512 es el algoritmo para hashear el pass.
Algo a tener en cuenta aquí es que si la actualización del password local falla, la operación falla aunque el password kerberos no haya tenido problemas.

/etc/pam.d/common-session

session [default=1] pam_permit.so
session requisite pam_deny.so
session required pam_permit.so
session optional pam_krb5.so minimum_uid=1000
session required pam_unix.so

Finalmente en el archivo de session encontramos una regla adicional y opcional que es la de kerberos. Algo interesante que podemos hacer en este archivo es agregar una regla para la creación del directorio home del usuario.
Si creamos un usuario en kerberos y no en la máquina cliente, cuando éste intente ingresar, el sistema arrojará error si el home no existe, porque este directorio no se crea al agregar el usuario.
Para esto, existe un módulo denominado pam_mkhomedir. Este módulo crea el directorio home del usuario cuando éste se loguea por primera vez. Si el directorio ya existe, no hace nada. Un argumento interesante para este módulo es skel, que permite especificar el esqueleto del directorio home.
Podemos modificar el archivo anterior para agregar esta funcionalidad, de la siguiente manera:

session [default=1] pam_permit.so
session requisite pam_deny.so
session required pam_permit.so
session required pam_mkhomedir.so skel=/etc/skel/
session optional pam_krb5.so minimum_uid=1000
session required pam_unix.so

Con esto, la próxima vez que se autentique un usuario en el cliente configurado, éste utilizará kerberos en lugar del tradicional sistema Unix. Claro que el usuario a utilizar debe estar previamente creado en el servidor kerberos.
Una vez autenticados, se puede ver el ticket generado ejecutando klist:

$ klist
Ticket cache: FILE:/tmp/krb5cc_1000_s6uumi
Default principal: demasiadovivo@DEMASIADOVIVO.ORG

Valid starting Expires Service principal
09/24/11 08:08:07 09/24/11 18:07:57 krbtgt/DEMASIADOVIVO.ORG@DEMASIADOVIVO.ORG
renew until 09/24/11 18:08:07

Bug en script perl al intentar actualizar debian testing

noreply@blogger.com (d3m4s1@d0v1v0) — Thu, 22 Sep 2011 12:29:54 PDT

Al intentar actualizar la librería libc6 en debian testing (wheezy) encontré un problema, el cual ocasionó que todo el sistema quede inestable. apt ciclaba arrojando el error:

Use of uninitialized value $text in concatenation (.) or string at /usr/share/perl5/Text/WrapI18N.pm line 101, line 5. substr outside of string at /usr/share/perl5/Text/WrapI18N.pm line 130, line 5.

Como el proceso no se detenía, la solución fue matarlo, pero dejando varias inconsistencias en el camino.Al parecer el script en cuestión tiene un bug con una variable sin inicializar, lo que ocasiona que el proceso de actualización falle.
Al quedar libc6 roto, muchos paquetes del sistema quedaron rotos y no es posible instalar ni borrar nada hasta que el problema no se arregle. Para salvar el problema y poder terminar la instalación, mi solución fue comentar la línea problemática (101 del archivo /usr/share/perl5/Text/WrapI18N.pm):

$text = $top2 . $c . $text;

Claro que si la línea esta ahí, para algo es, pero preferí tener un problema menor a tener un sistema que posiblemente al reiniciar no arrancaría.
Una vez comentada la línea hay que reparar los paquetes rotos, lo cual se realiza con:

apt-get install --fix-broken

Al haber matado el proceso apt, puede que algún proceso haya retenido los archivos de lock y que apt se reuse a actualizar. Si este es el caso, ejecutar fuser para obtener el id de los procesos que quedaron colgados, y luego matarlos:

fuser -v /var/lib/dpkg/lock
fuser -v /var/cache/debconf/config.dat

Con esto pude terminar la instalación de libc6 sin problemas y el sistema volvió a un estado estable. Según lo que encontré en diferentes foros, este es un bug del paquete perl y varios que han intentado actualizar lo han sufrido:

http://www.linuxquestions.org/questions/debian-26/error-configuring-libc6-898757/
http://www.facepunch.com/threads/1116926-Error-when-trying-to-dist-upgrade

Por ello me pareció interesante postear mi solución, que si bien no es elegante, me salvó de una reinstalación completa. Ojalá los salve a ustedes también!

Armar servidor de logging con rsyslog y configurar dispositivos para logging remoto

noreply@blogger.com (d3m4s1@d0v1v0) — Fri, 09 Sep 2011 05:24:57 PDT

Todo sistema operativo cuenta con funcionalidad para almacenar logs del sistema, aplicaciones, dispositivos, etc. Los sistemas tipo *nix cuentan con el demonio syslog, encargado de recoger los logs y almacenarlos en el lugar indicado. El servicio syslog es tan potente que, además de realizar la tarea de logging local, permite almacenar logs de dispositivos remotos a través de un protocolo propio llamado del mismo nombre y que funciona sobre UDP y TCP. La mayoría de los sistemas operativos poseen facilidades para almacenar logs en un servidor remoto.
Centralizar los logs en un servidor facilita la tarea de análisis de logs a administradores y auditores, ya que deben acceder a sólo un repositorio.
La obvia desventaja es que si hackean el servidor de logs, pueden ver los logs de toda la red. Por ello es muy importante que el servidor de logging posea una buena configuración de seguridad. Igualmente, como se detallará al final del artículo, existen varias desventajas de seguridad adicionales al utilizar este esquema.
Los sistemas *nix modernos, utilizan una versión mejorada del antiguo syslog denominada rsyslog, más confiable que el anterior y con capacidades extendidas. La siguiente explicación muestra cómo armar un servidor de logging con rsyslog, que puede aplicarse a cualquier sistema *nix. Además se incluyen los comandos para habilitar el logging remoto en dispositivos Cisco.
Toda la configuración de rsyslog se realiza a través del archivo /etc/rsyslog.conf.

Servidor rsyslog

Para convertir el demonio rsyslog en un servidor de loggeo de red debe utilizarse el plugin imudp (si se desea utilizar UDP) y/o imtcp (para TCP). Estos plugins reemplazan la opción -r de syslog ya obsoleta. El port utilizado por defecto por este servicio es el 514 para ambos protocolos.
Las líneas que se deben agregar (o descomentar) en /etc/rsyslog.conf para habilitar el logging remoto son las siguientes:

$ModLoad imudp
$UDPServerRun 514

$ModLoad imtcp
$InputTCPServerRun 514

Para que la nueva configuración entre en vigencia, debe recargarse el demonio. Una manera de no cortar el logging de forma abrupta matando el proceso (clásico restart), lo mejor es enviar una señal HungUp:
killall -HUP rsyslogd

Con esto, cualquier dispositivo de red puede enviar sus logs al servidor recién configurado, y este los añadirá a los locales del servidor. Claro que lo mejor es no mezclar logs locales con logs remotos, por lo cual se pueden configurar distintas entradas en la configuración que redirijan estos logs a otros archivos.
Las reglas para separar logs se arman en base al facility y al nivel de criticidad que va de 0 (emergencias) a 7 (debugging). Las facilities permiten indicar el origen del mensaje, y existe un número fijo de ellas. Algunos demonios y procesos del sistema operativo tienen asignados valores de facilities (por ej: kern, mail, daemon, user, etc), y aquellos que no, deben utilizar alguna de las definidas como "uso local" (local0 a local7). El usuario puede utilizar las facilities local0 a local7 para sus logs, y estas son las que se suelen utilizar para separar logs de dispositivos remotos.
El formato de las reglas es:

<facility>.<criticidad> <archivo log destino (ej /var/log/syslog)>

Tanto el facility como la criticidad pueden ser asterisco (*), indicando que abarque todo. Por ejemplo, "kern.*" envía todos los logs del kernel al archivo especificado. En el caso de utilizar asterisco en el facility, es posible utilizar la prioridad none para indicar qué facilities no incluir. Por ejemplo, existe la siguiente regla default en la configuración de rsyslog:

*.*;auth,authpriv.none -/var/log/syslog

la cual hace que todo se envíe al archivo syslog. En esa misma regla se puede observar que se agregó auth,authpriv.none para evitar que los logs de auth y authpriv se almacenen en dicho archivo. A la regla anterior se puede agregar local4.none, para luego utilizar la facility local4 en dispositivos remotos y así separar esos logs de los locales:

*.*;auth,authpriv.none;local4.none -/var/log/syslog

Además de las reglas "facility.priority", se pueden armar reglas en base a filtros, basados en distintas propiedades como IP origen, mensaje, hostname, y varias más que se pueden ver en la sección de propiedades del manual oficial de rsyslog.
Las reglas con filtros se arman de la siguiente manera:

:<propiedad>, <operación de comparación>, "valor" <archivo log destino (ej /var/log/syslog)>

donde la operación de comparación puede ser isempty, isequal, startswith, regex y eregex, como se puede observar en el manual oficial, en la sección de filtros.
Esto permite, por ejemplo, separar los logs provenientes de la dirección IP 192.168.1.15 en un archivo propio para el host con la siguiente regla:

:fromhost-ip, isequal, "192.168.1.15" /var/log/remote/192.168.1.15.log

Una vez completadas las reglas, debe recargarse el demonio rsyslogd para que tome la nueva configuración.

Separación de logs

Conociendo las bases para la configuración del servidor, es posible armar una que reciba logs de diferentes fuentes y los separe en distintos archivos.
Dado que por defecto todo va a parar a syslog, lo mejor es eliminar las facilities local* de dicha configuración y después utilizarlas en los dispositovs de red. El primer paso es editar la regla correspondiente (en /etc/rsyslog.conf) para que quede como sigue:

*.*;auth,authpriv.none;\
local0.none;\
local1.none;\
local2.none;\
local3.none;\
local4.none;\
local5.none;\
local6.none;\
local7.none -/var/log/syslog

También hay que evitar que info, notice y warning terminen en /var/log/messages

*.=info;*.=notice;*.=warn;\
auth,authpriv.none;\
cron,daemon.none;\
mail,news.none;
local0.none;\
local1.none;\
local2.none;\
local3.none;\
local4.none;\
local5.none;\
local6.none;\
local7.none -/var/log/messages

y que los mensajes de debugging terminen en /var/log/debug

*.=debug;\
auth,authpriv.none;\
news.none;mail.none;
local0.none;\
local1.none;\
local2.none;\
local3.none;\
local4.none;\
local5.none;\
local6.none;\
local7.none -/var/log/debug

La separación se puede realizar de varias maneras, una es basándose en las facilities. Para ello, a cada tipo de dispositivo se asigna una facility de las "local use" y luego se arma la configuración en base a esto, de la siguiente manera:

local3.* /var/log/remote/firewalls.log
local4.* /var/log/remote/routers.log
local5.* /var/log/remote/APs.log
local6.* /var/log/remote/switches.log

Como se ve, se utiliza local3 para firewalls, loca4 para routers, local5 para access points y local6 para switches. A esta separación se la puede mejorar utilizando distintos archivos para diferentes prioridades, pero sigue siendo muy simple y no demasiado agradable para quien revisa los logs.

Una mejor forma de separar logs es colocar los logs de cada host en un archivo separado. En la sección anterior se mostró que es posible ver de qué dirección IP viene la información y armar un archivo en base a esto, pero es muy ineficiente colocar una regla por cada host. Una forma más simple de hacerlo es utilizar templates. Con un template es posible definir el formato del nombre del archivo log a partir de alguna propiedad del mismo, como por ejemplo el hostname o IP. Para usar una propiedad es necesario colocarla entre signos de porcentaje "%".
La siguiente línea crea un template que luego se puede utilizar para especificar el nombre del archivo:

$template LogsRemotos,"/var/log/remote/%fromhost-ip%.log"

donde fromhost-ip especifica que se utilice la IP como nombre del archivo.
Para lograr que cada dispositivo loggee en un archivo separado, sólo debe agregarse lo siguiente:

:fromhost-ip, isequal, "127.0.0.1" ~
*.* -?LogsRemotos

y con ello rsyslog generará automáticamente los nombres de archivos y almacenará los mensajes en el lugar correcto. En la primer línea se descartan los logs locales, dado que los mismos se almacenan en otros archivos y no deseamos generar uno nuevo. El descarte se realiza utilizando caracter "~" en lugar de un nombre de archivo. El signo de pregunta "?" de la segunda línea indica que se utiliza un nombre de archivo dinámico, a partir del template LogsRemotos, y el guión "-" que no escriba en el archivo inmediatamente (buffering), para mejorar la performance.

Para no "ensuciar" el archivo de configuración global, es posible crear archivos dentro de /etc/rsyslog.d/ con las configuraciones deseadas. En el último ejemplo, sería posible tener un archivo denominado remote.conf con las líneas:

$template LogsRemotos,"/var/log/remote/%fromhost-ip%.log"

:fromhost-ip, isequal, "127.0.0.1" ~
*.* -?LogsRemotos

Configuracion en dispositivos Cisco con IOS

Todos los dispositivos Cisco poseen la capacidad de loggear en un servidor remoto a través de syslog. La configuración de los mismos es muy simple, sólo debe indicarse la dirección del servidor, el nivel de información a enviar y el facility a utilizar. Esto se lleva a cabo en el modo de configuración con privilegios de administrador, ejecutando los siguientes comandos (lo que se encuentra luego del // son comentarios):

(config)#logging on
(config)#logging host <IP syslog server>
(config)#logging trap informational // es el nivel de mensajes a loguear. Cada nivel incluye a todos los niveles inferiores (informational incluye error, critical, alerts, etc).
(config)#logging facility local5 // usar el facility local5 (local0... local7 son para códigos definidos por el usuario).

Configuración de clientes *nix

Lograr que un máquina que ejecuta algún sistema *nix loggee remotamente es muy simple. Sólo debe agregarse la línea mostrada a continuación en su archivo /etc/rsyslog.conf (o /etc/syslog.conf si no posee rsyslog):

*.* @<IP remota>

El @ indica que deben enviarse los mensajes a un host remoto en lugar de almacenarlos en un archivo local. Con un sólo @ rsyslog utiliza UDP como protocolo de transporte, y si se desea utilizar el más confiable TCP deben colocarse dos:

*.* @@<IP remota>

Restringir el acceso

El protocolo no posee un mecanismo de autenticación que restrinja qué dispositivo puede almacenar logs en el servidor, permitiendo que cualquiera pueda escribir en el mismo, con el riesgo de que un atacante genere un Denial of Service si el disco se llena o la cantidad de datos transmitida satura el ancho de banda.
Una forma de limitar el acceso es utilizando un firewall y rechazar toda conexión que no venga de una dirección de red autorizada. Esta mejora no es la panacea, dado que suplantar una dirección de red es muy simple, pero al menos es algo.

Conclusiones

rsyslog es un sistema muy flexible, simple y consolidado. El protocolo se encuentra en prácticamente todo dispositivo decente, por lo cual la compatibilidad está garantizada. Lo que se describió en este artículo muestra sólo una parte de la potencia de esta herramienta, por lo cual se recomienda una atenta lectura de su manual oficial.
Probablemente su problema más grave es la pobre seguridad que provee. Entre algunos de los problemas más graves se encuentran:

Posibilidad de DoS, como se explicó en la sección anterior.
UDP es poco confiable: los paquetes se pueden perder y nadie se enteraría. syslog por TCP mejora este aspecto, pero no todos los dispositivos lo implementan.
No hay autenticación, permitiendo que cualquiera envíe logs al servidor.
No existe confidencialidad de los datos enviados.
No hay integridad de los datos (alguien podría modificarlos en el camino - MITM)

Algunos de estos problemas pueden solucionarse si se utiliza IPSec en la capa inferior, pero no es una solución que forme parte del protocolo.

Referencias

- rsyslog doc - rsyslog.conf configuration file
- Syslog Configuration and /etc/syslog.conf
- How To Set Up A Debian Linux Syslog Server
- FreeBSD Handbook - 29.11 Remote Host Logging with syslogd
- Catalyst 2950 - Configuring System Message Logging
- Practical UNIX & Internet Security - 10.5 The UNIX System Log (syslog) Facility
- Softpanorama - Centralised Syslog Server
- PIX 501 Logging to Syslog Server

Interfaz wireless desactivada al utilizar power injector en APs Cisco

noreply@blogger.com (d3m4s1@d0v1v0) — Thu, 08 Sep 2011 06:41:43 PDT

Cuando se utiliza el AP con power injector instalado, puede suceder que la interfaz wireless se encuentre deshabilitada. Esto se puede observar en los logs del dispositivo ejecutando el comando:
#show logging
El error que se encontrará será similar al siguiente:

*Feb 28 21:00:10.622 GMT-3: %LINEPROTO-5-UPDOWN: Line protocol on Interface Dot11Radio0, changed state to down
*Feb 28 21:01:09.497 GMT-3: %CDP_PD-2-POWER_LOW: All radios disabled - LOW_POWER_CLASSIC_NO_INJECTOR_CONFIGURED WS-C2924-XL (00d0.bbd6.1b4e)
*Feb 28 21:01:09.497 GMT-3: -Verify the required power-injector is installed on this port: WS-C2924-XL(Fas 0/13).
*Feb 28 21:01:09.497 GMT-3: -If a power-injector is installed, issue the command:"power inline negotiation injector installed"

En este caso, el AP indica que no cuenta con la energía necesaria y por eso deshabilita la interfaz wireless. El problema es que no detecta que se encuentra energizado mediante power injector.

Para solucionar el problema, el AP necesita que se explicite la MAC address del port del switch en el que se encuentra conectado el power injector. Dicha MAC se puede observar en el log anterior, en la línea:

%CDP_PD-2-POWER_LOW: All radios disabled - LOW_POWER_CLASSIC_NO_INJECTOR_CONFIGURED WS-C2924-XL (00d0.bbd6.1b4e)

La dirección en que el injector se encuentra conectado se debe ingresar a través de la configuración del switch, ejecutando el siguiente comando:

(config)#power inline negotiation injector 00d0.bbd6.1b4e

Luego de esperar un minuto o dos, la interfaz de radio debería encontrarse habilitada nuevamente. Para checkearlo se puede ejecutar el comando:

#show interfaces dot11Radio 0

y la respuesta debe ser:

Dot11Radio0 is up, line protocol is up

Instalar y configurar el directorio OpenLDAP

noreply@blogger.com (d3m4s1@d0v1v0) — Wed, 31 Aug 2011 16:37:51 PDT

Existe una interesante variedad de directorios LDAP disponibles en GNU/Linux, siendo algunos de los más importantes OpenLDAP, 389 Directory Server, OpenDS y Apache Directory. Si bien todos presentan características similares, elegí utilizar OpenLDAP por ser el más antiguo, existe mucha información al respecto, es muy flexible, y está disponible en los repositorios de las distribuciones más importantes.
A continuación describiré cómo instalar y configurar OpenLDAP. Si bien mi trabajo fue realizado en debian, no debería variar demasiado en otras distribuciones.

Instalación

En debian y derivados, instalar OpenLDAP es tan simple como ejecutar:

# apt-get install slapd ldap-utils

donde slapd es el demonio que provee la funcionalidad ldap, y ldap-utils contiene un set de herramientas para administrar y testear el server.

Durante el proceso de instalación, el configurador del paquete (debconf) requerirá los siguientes datos básicos:

Nombre DNS de nuestro dominio (ej: demasiadovivo.org).
Nombre de la organización a utilizar en el DN base. En general utilizarán el mismo que el nombre DNS (ej: demasiadovivo.org).
Contraseña del administrador.
Base de datos de fondo para almacenar los datos LDAP. Si bien openLDAP acepta distintas bases de datos, es recomendable utilizar la de Berkeley (BDB) que no es una BD relacional, sino una que permite almacenar varios items por cada clave y logra mejor performance en casos de muchas lecturas y pocas escrituras. Todo esto encaja perfecto con LDAP, porque son justamente estos los atributos de un directorio.
Remover la base de datos cuando el paquete slapd se purgue? es buena idea setear que no, así no borramos accidentalmente la base de datos LDAP.
Permitir el protocolo LDAPv2? esto dependerá de los clientes que estemos utilizando. Dado que LDAPv3 ya esta muy maduro e implementado en la mayoría de los sistemas, lo mejor es decir no a esta pregunta.

En debian 6 (squeeze) el archivo de configuración del demonio OpenLDAP se encuentra en /usr/share/slapd/slapd.conf. En otras distribuciones puede encontrarse en /etc/ldap/slapd.conf, /etc/openldap/slapd.conf o /usr/local/etc/openldap/slapd.conf. En dicho archivo podrán ver que se importan archivos que contienen los esquemas básicos, así como configuración de permisos para escribir y leer registros, tipo de base de datos, ubicación de la base de datos (/var/lib/ldap en debian), el nivel de logging, y varias cosas más.

Una vez instalado el paquete, podemos probar si el servidor se instaló y configuró correctamente, utilizando ldapsearch. ldapsearch es una herramienta que nos servirá mucho para testear la configuración del servidor y, como su nombre lo indica, sirve para hacer búsquedas dentro de directorio.
Para realizar la prueba, pediremos todos los objetos que se encuentren en el servidor:

ldapsearch -b dc=demasiadovivo,dc=org -H ldap://localhost -x

donde:

-b indica el DN base done iniciar la búsqueda
-H es para ingresar la URI del server
-x indica que utilice autenticación simple

Como no utilizamos ningún fitro y no indicamos qué atributos traer, ldapsearch traerá todo.

ldap.conf

Para evitar tener que ingresar los datos referentes al DN base y la URI o dirección de servidor en cada conexión con el servidor ldap, podemos almacenar esta información en el archivo /etc/ldap.conf
ldap.conf se utiliza para configuraciones default concernientes a los clientes ldap. Los dos valores más utilizados son URI y BASE, que sirven justamente para lo explicado en el párrafo anterior. Un ejemplo de este archivo es el siguiente:

URI ldap://demasiadovivo.org ldaps://demasiadovivo.org
BASE dc=demasiadovivo,dc=org

Con esto nos evitamos, por ejemplo, los parámetros -b y -H en ldapsearch =)

Agregar, modificar, y eliminar entradas del directorio

Los datos LDAP son intercambiados utilizando un formato de texto plano denominado LDIF (LDAP Data Interchange Format). Utilizando archivos LDIF podemos agregar, modificar, elminar y renombrar entradas del directorio.
Cada entrada (registro) continee un conjunto de atributos y están separadas por líneas en blanco. Ya vimos ejemplos de este formato cuando utilizamos ldapsearch para testear el servicio.
Para editar la información del directorio, simplemente creamos un archivo ldif y utilizamos la herramienta ldapadd o ldapmodify. Para eliminar entradas, se utiliza ldapdelete.

En secciones anteriores vimos que la estructura del árbol del directorio se puede armar en base a unidades organizativas (organizational units - OU), algo muy común en sistemas de usuarios centralizado (Active Directory, y GNU/Linux con NSS-LDAP y PAM). Las OU básicas de un sistema de usuarios centralizado son People y Group. Podemos crear estas OUs utilizando un archivo ou.ldif que contenga:

dn: ou=People,dc=demasiadovivo,dc=org
ou: People
objectClass: organizationalUnit

dn: ou=Group,dc=demasiadovivo,dc=org
ou: Group
objectClass: organizationalUnit

y luego ejecutando ldapadd de la siguiente forma:

$ ldapadd -c -x -D cn=admin,dc=dvpem,dc=org -W -f ou.ldif

donde:

-c indica que continúe procesando si encuentra errores
-x indica que utilice autenticación simple
-D setea el DN con el cual realizar el bind (usuario de autenticación)
-W pide el password
-f permite importar los datos del archivo

Como se observa, con -x -D cn=admin,dc=dvpem,dc=org -W realizamos la autenticación con el usuario admin, dado que con acceso anónimo no es posible modificar registros de la base de datos. Más adelante veremos cómo autenticar utilizando SASL en lugar de autenticación simple.

Podemos ver el resultado ejecutando la siguiente búsqueda:

$ ldapsearch -x ou=People
$ ldapsearch -x ou=Group

Modificar la configuración

La configuración del servicio LDAP se almacena en el archivo slapd.conf, pero si se desea hacer cambios en en la misma, una vez que se actualiza dicho archivo, es necesario reiniciar el demonio slapd, algo que es muy contraproducente en un sistema que está en producción atendiendo cientos o miles de consultas. Por suerte, desde la versión 2.3 de OpenLDAP, es posible editar la configuración online. A partir de dicha versión, la configuración se almacena una base de datos separada, con un esquema y DIT predefinidos (cuyo base DN es cn=config), y la cual se encuentra en el directorio slapd.d (en debian /etc/ldap/slapd.d/). Esta base de datos posee administración en tiempo de ejecución a través de operaciones LDAP con datos en formato LDIF y se puede acceder y editar a través del conjunto de herramientas slapacl, slapadd, slapauth, slapcat, slapdn y slaptest.
Para ver las entradas de configuración, se puede utilizar slapcat de la misma manera que se utiliza ldapsearch. Por ejemplo, para ver la configuración de la base de datos, se debe ejecutar:

# slapcat -b cn=config -a olcDatabase=*

donde -b indica el sufijo o DN base, y -a permite utilizar filtros.

De esta forma tenemos que la configuración del directorio se realiza a través de atributos en entradas del directorio, y la mayoría de estos comienzan con el prefijo "olc" (OpenLDAP configuration). Además, algunas de las entradas tienen nombres con números entre llaves ({}). Esto se debe a que ni las entradas, ni los atributos de un directorio tienen un orden específico, pero el orden es necesario para la configuración, porque existen dependencias. Los números en los nombres aseguran que la configuración se ejecute en el orden correspondiente, asegurando la consistencia. En general estos números se generan automáticamente a medida que se crean las entradas.

Control de acceso

En la configuración default de un OpenLDAP recién instalado existen dos permisos para acceder al directorio:

utilizando el usuario admin que tiene control total. Este usuario está declarado en el DN base con cn=admin (por ej: cn=admin,dc=demasiadovivo,dc=org). La contraseña de este usuario se setea durante la instalación del directorio.
acceso de lectura de cualquier entrada de forma anónima, es decir, sin ningún tipo de autenticación.

Este todo o nada no suele alcanzar para ninguna organización, por lo tanto es necesario conocer cómo se administran los permisos.
El acceso a las entradas del directorio se configura a través del atributo olcAccess, cuyo formato es:

olcAccess: <directiva acceso="" de="">
olcAccess: <directiva acceso="" de="">
<access directive=""> ::= to <what>
    [by <who> <access> <control>]+
<what> ::= * |
    [dn[.<basic-style>]=<regex> | dn.<scope-style>=<dn>]
    [filter=<ldapfilter>] [attrs=<attrlist>]
<basic-style> ::= regex | exact
<scope-style> ::= base | one | subtree | children
<attrlist> ::= <attr> [val[.<basic-style>]=<regex>] | <attr> , <attrlist>
<attr> ::= <attrname> | entry | children
<who> ::= * | [anonymous | users | self
    | dn[.<basic-style>]=<regex> | dn.<scope-style>=<dn>]
    [dnattr=<attrname>]
    [group[/<objectclass>[/<attrname>][.<basic-style>]]=<regex>]
    [peername[.<basic-style>]=<regex>]
    [sockname[.<basic-style>]=<regex>]
    [domain[.<basic-style>]=<regex>]
    [sockurl[.<basic-style>]=<regex>]
    [set=<setspec>]
    [aci=<attrname>]
<access> ::= [self]{<level>|<priv>}
<level> ::= none | auth | compare | search | read | write
<priv> ::= {=|+|-}{w|r|s|c|x|0}+
<control> ::= [stop | continue | break]

donde la parte <what> selecciona las entradas y/o atributos a los cuales se aplica el acceso, <who> especifica que entidades tienen acceso, y <access> especifica el tipo de acceso otorgado. Se soportan múltiples tripletas <who> <access> <control>, permitiendo otorgar distinto tipo de acceso a distintas entidades.
Para observar los accesos default de todas las bases de datos, basta con ejecutar:

# slapcat -b cn=config -a olcAccess=*

Por ejemplo, ejecutando slapcat con el siguiente filtro es posible observar los accesos default a la base de datos principal:

# slapcat -b cn=config -a olcDatabase={1}hdb
...
olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymous auth by dn="cn=admin,dc=demasiadovivo,dc=org" write by * none
olcAccess: {1}to dn.base="" by * read
olcAccess: {2}to * by self write by dn="cn=admin,dc=demasiadovivo,dc=org" write by * read
...

Con esta información se ve que los atributos userPassword (el password del usuario) y shadowLastChange (última fecha de modificación del password) tienen:

acceso de escritura para el propio usuario (self) y para el administrador (dn="cn=admin,dc=demasiadovivo,dc=org")
tiene acceso de lectura de forma anonima en caso de que se este realizando una autenticación (anonymous auth)
ningún acceso para el resto de los usuarios (* none).

Un punto a tener en cuenta es que en debian squeeze (al menos en mi caso) sólo el usuario root tiene permiso para modificar la configuración, utilizando el modo de autenticación externa de LDAP. Es decir, LDAP valida el usuario del sistema operativo.
El problema es que este modo de autenticación NO viene habilitado por defecto y requiere activación de TLS/SSL en el servidor LDAP. Esta tarea no resultó tan trivial como pensaba y no pude habilitarlo.
Para poder acceder a la configuración, existe un mecanismo alternativo. En la base de datos config, existe el usuario admin, pero por default no tiene password asignado. Para habilitar el uso de este usuario con autenticación simple, primero hay que crear la contraseña con slappasswd:

# slappasswd -h {SSHA}

y luego editar el archivo /etc/ldap/slapd.d/cn\=config/olcDatabase\=\{0\}config.ldif para agregar la siguiente línea debajo del nombre de usuario:

olcRootDN: cn=admin,cn=config //esta línea ya existe en el archivo
olcRootPW: {SSHA}xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Finalmente, reiniciar el servicio:

# /etc/init.d/slapd restart

y testear que funciona:

$ ldapsearch -x -D cn=admin,cn=config -W -b cn=config

Cómo armar los permisos y otorgarlos está excelentemente explicado en la sección 5.3. Access Control del manual de OpenLDAP, por lo tanto no tiene sentido que lo repita aquí.

Clientes gráficos

Si bien podemos administrar todo el directorio a través de archivos LDIF, esto puede resultar engorroso y contraproducente en el día a día. Por suerte existen herramientas gráficas que nos ayudan a administrar el directorio de manera más simple.
Algunas de estas herramientas son:

Referencias

- OpenLDAP provider on Debian squeeze
- OpenLDAP installation on Debian
- OpenLDAP - 2. A Quick-Start Guide
- Debian 5.0 y OpenLDAP con TLS
- OpenLDAP - 5. Configuring slapd
- LDAP Administration Guide
- Zarafa LDAP cn config How To
- HowTo:LDAP Debian 6 (squeeze)

LDAP: Un directorio liviano

noreply@blogger.com (d3m4s1@d0v1v0) — Mon, 22 Aug 2011 10:48:12 PDT

Un protocolo que se ha popularizado muchísimo en los últimos años es LDAP. El mismo es utilizado en la mayoría de las empresas, ya sea con Active Directory o con alguna de las múltiples soluciones para GNU/Linux como OpenLDAP, o 389 Directory Server.
Existen librerías para la mayoría de los lenguajes de programación que soportan LDAP, por lo cual existen muchos programas que lo utilizan.
Este protocolo es la base de cualquier sistema de directorio actual (Active Directory entre ellos), y es muy importante que todo administrador y/o programador conozca acerca de el.
Este artículo los introducirá en el mundo LDAP, explicando de qué trata, cómo funciona, la terminología, cómo es la autenticación y el formato de las búsquedas. El mismo forma parte del proyecto Autenticación y administración centralizada de usuarios en GNU/Linux.

Qué es?

Lightweight Directory Access Protocol (LDAP) es una base de datos especial (no relacional) que provee servicios de directorio basado en el estándar X.500, diseñada para almacenar información basada en atributos y soportar filtros sofisticados en búsquedas. A diferencia de una base de datos relacional, LDAP está optimizado para realizar búsquedas y organiza de forma distinta los datos.
Piensen en un directorio como una guía telefónica. En la guía encontramos personas con sus atributos (nompre, apellido, dirección y teléfono) organizadas en base a la letra de su apellido.
Un directorio informático que estamos acostumbrados a utilizar es la lista de direcciones de email. En la lista de emails encontramos las direcciones de email de nustros contactos, así como el nombre, teléfono, dirección física, etc. Podemos filtrar esta lista para buscar compañeros de trabajo, de universidad, por nombre, etc.
El "Light" en el nombre de LDAP se debe a que es una implementación más liviana que el anterior estandar X.500 denominado Directory Access Protocol, el cual estaba diseñado para trabajar sobre el stack OSI.

El modelo de información en LDAP está basado en entradas. Una entrada es un conjunto de atributos que tiene un nombre único (Distinguished Name - DN). El DN es utilizado para distinguir la entrada unequívocamente y se arma a partir de su RDN (Relative Distinguished Name), construido a partir de algún/os atributo/s de la entrada, y el DN de la entrada padre. Cada atributo de la entrada tiene un tipo y uno o varios valores. Los tipos suelen representarse con un string nemotécnico como 'cn' (common name), 'c' (country), 'ou' (organization unit), etc.
La información del directorio se organiza en forma de árbol y a este se lo denomina directory information tree (DIT). La jerarquía del árbol se arma a partir de información geográfica tomando como base del árbol o bien el nombre DNS. Dentro de esta jerarquía se pueden definir varias unidades organizativas, personas, dispositivos, etc.
Un ejemplo de entrada LDAP es:

dn: cn=demasiadovivo,dc=itfreekzone,dc=blogspot,dc=com
cn: demasiadovivo
givenName: demasiadovivo
mail: espameasiqueres@gmail.com
manager: cn=Javiz,dc=je-photography,dc=blogspot,dc=com
objectClass: person

En el ejemplo, el DN es "cn=demasiadovivo,dc=itfreekzone,dc=blogspot,dc=com" que está formado por el atributo common name, y los atributos domain component (dc) de las entradas padre. El resto son los atributos de la entrada. Como pueden observar, una entrada puede contener referencias a otras entradas, como es el caso del atributo manager que referencia a la entrada "cn=Javiz,dc=je-photography,dc=blogspot,dc=com".

El protocolo utiliza el port TCP 389 por defecto, en caso de no utilizar ssl, y 636 en caso de hacerlo.

Esquemas, Clases de objeto, Atributos y entradas

Como vimos, el directorio está formado por entradas, las que a su vez están formadas por un conjunto de atributos. Estos atributos se agrupan en clases de objetos (objectClass), las que a su vez se empaquetan en esquemas (schemes). Todas las objectClass y los atributos se definen dentro de esquemas. En OpenLDAP pueden encontrar la definición de los atributos y clases de objetos en el directorio /etc/ldap/schema/.

Los atributos se definen por separado y se pueden utilizar en una o varias objectClass. Para poder utilizar un atributo en una entrada, ésta debe contener alguna objectClass que contenga el atributo, y a su vez, la objectClass debe estar incluida en algún esquema reconocido por el servidor LDAP.

Las objectClass se pueden organizar jerárquicamente, en cuyo caso heredan todas las propiedades de sus padres o SUPerior. Estas objectClass pueden ser STRUCTURAL, en cuyo caso se usan para crear entradas, AUXILIARY en cuyo caso se pueden agregar en cualquier entrada, o ABSTRACT. El ejemplo más común de objectClass ABSTRACT es top, que forma el mayor nivel de cualquier jerarquía objectClass. Cada una de estas definiciones pueden tener atributos obligatorios y otros opcionales.

Las entradas agrupan conjuntos de objectClass, donde cada una debe contener obligatoriamente (y sólo puede contener una) STRUCTURAL. Además, puede contener una ABSTRACT y un número arbitrario de AUXILIARY.

Autenticación

LDAP soporta varios métodos de autenticación para acceder al directorio, existiendo dos principales que deben ser soportados (según el estándar):

Método de Autenticación Simple (Simple Authentication Method). Provee tres mecanismos de autenticación:
- Autenticación anónima de enlace simple. Conexión LDAP sin usuario ni contraseña.
- Autenticación sin autenticación de enlace simple. Se debe utilizar el nombre de usuario de un usuario válido, pero no es necesario proveer contraseña.
- Autenticación de Usuario/Contraseña de enlace simple. En este caso se utiliza usuario y password para la autenticación, pero el password se transmite de forma plana.
Autenticación Simple y Capa de Seguridad (Simple Authentication and Security Layer - SASL). SASL es un framework para proveer autenticación y servicios seguros de datos a través de mecanismos reemplazables. El estándar de SASL sólo define uno de estos mecanismos (denominado EXTERNAL) pero las implementaciones más utilizadas soportan los siguientes:
- DIGEST-MD5: provee un mecanismo para utilizar la autenticación HTTP Digest dentro del framework SASL. Este mecanismo envía un MD5 del password en lugar del password en texto plano, sobre una conexión sin encripción.
- EXTERNAL: permite al cliente requerir que el servidor use credenciales provistas por un mecanismo externo al mecanismo de autenticación del cliente. La autenticación externa puede ser a través de la información de login del sistema operativo, IPSec, TLS o algún otro medio.
- GSSAPI: permite al cliente utilizar tokens GSSAPI como credenciales para la autenticación. El token GSSAPI pueden ser Kerberos TGT o token NTLM.
- GSSAPI-SPNEGO (Active Directory): es un mecanismo GSSAPI pero que contiene una negociación cliente-servidor para elegir el mecanismo de seguridad preferido según lo soportado por el cliente y el servidor.

En todos los casos, por cuestiones de seguridad, lo mejor es utilizar una capa de encripción por debajo del proceso de autenticación, como puede ser TLS (SSL) o IPSec. El método y mécanismo de autenticación más seguro es SASL usando GSSAPI con kerberos y sobre conexión encriptada. En orden de mejor a peor, las opciones son las siguientes:

SASL usando GSSAPI con kerberos y sobre conexión encriptada.
SASL usando GSSAPI con NTLMv2 y sobre conexión encriptada (sólo en Active Directory).
SASL usando GSSAPI con kerberos.
SASL usando GSSAPI con NTLMv2 (sólo en AD).
SASL usando GSSAPI con NTLM y sobre conexión encriptada (sólo en Active Directory).
Autenticación Simple, usuando usuario/contraseña sobre conexión encriptada.
SASL usando GSSAPI con NTLM (sólo en AD).

Búsquedas en el directorio

La sintaxis para realizar búsquedas no es muy intuitiva y muy distinta a la forma en que consultamos bases de datos relacionales a través de SQL, pero con el tiempo (como todo) uno se acostumbra.
Los parámetros son los siguientes:

baseObject: el DN de la entrada donde deseamos comenzar la búsqueda (ej: dc=demasiadovivo,dc=org)
scope: qué elementos bajo el baseObject buscar.
filer: criterio para seleccionar elementos dentro del scope. Los fitros se construyen utilizando operadores de igualdad y se pueden concatenar utilizando operadores booleanos en notación prefija. Pueden encontrar una buena explicación sobre construcción de filtros en Red Hat - LDAP Search Filters, Appendix A - LDAP: Text Search Filter y MS LDAP Query Basics.
derefAliases: cuando y cómo seguir entradas que son alias.
atributos: que atributos retornar en el resultado (ej: cn mail).
sizeLimit, timeLimit: máxima cantidad de entradas a retornar y el tiempo máximo permitido para ejecutar la búsqueda.
typesOnly: retornar sólo el tipo de los atributos, sin los valores.

Una excelente herramienta para realizar búsquedas en LDAP es ldapsearch, la cual viene en el paquete ldap-utils. Un ejemplo es el siguiente:

ldapsearch -b dc=itfreekzone,dc=blogspot,dc=com "(cn=demasiadovivo)" mail

donde usamos como baseObject "dc=itfreekzone,dc=blogspot,dc=com", como filtro (cn=demasiadovivo), y el atributo que deseamos traer es "mail".

Lo que viene...

Próximamente publicaré un artículo sobre cómo instalar y configurar el servicio de directorio más utilizando en entornos *nix (principalmente GNU/Linux), denominado OpenLDAP.

Referencias

- OpenLDAP - 1. Introduction to OpenLDAP Directory Services
- LDAP Wiki
- Chapter 3. LDAP Schemas, objectClasses and Attributes
- 6. LDAP Lightweight Directory Access Protocol
- LDAP for Rocket Scientists

Hardening PHP

noreply@blogger.com (d3m4s1@d0v1v0) — Tue, 16 Aug 2011 07:11:33 PDT

PHP es el lenguaje más popular para la creación de Webs, y por lo tanto muy conocido, y a la vez atacado.
Si bien es trabajo del programador (y el mayor responsable de) tomar los recaudos necesarios para que sus aplicaciones no sean vulnerables, un administrador de sistemas puede utilizar varias opciones para que el servidor sea lo más resistente posible. PHP ofrece varias opciones que aumentan la seguridad significativamente, si se encuentran bien configuradas.

La siguiente es una lista de directivas que se pueden configurar en el archivo de configuración de php (/etc/php.ini, o /etc/php5/apache2/php.ini, dependiendo la distribución) para mejorar la seguridad del servidor:

Restringir el acceso al sistema de archivos. Dado que los sites se alojarán en /var/www, salvo casos excepcionales, los scripts PHP no necesitan acceso al resto del sistema de archivos, a excepción del directorio /tmp que es donde se alojan los archivos cuando el usuario hace un upload. Por ello, es posible restringir los directorios a los que se puede acceder, mediante la opción:

open_basedir = /var/www:/tmp
Esta configuración se puede cambiar por site en el correspondiente Virtual Host, utilizando la directiva:

php_admin_value open_basedir /var/www/[nombre site]/
Deshabilitar funciones riesgosas. Hay funciones que deben ser permitidas sólo en casos particulares, debido a que se usan raramente y representan un gran riesgo. Esta configuración se realiza con la directiva disable_functions:

disable_functions = show_source, system, shell_exec, passthru, exec, phpinfo, popen, proc_open
No revelar información de PHP en los headers. Esto le permitiría a un atacante saber que el servidor posee PHP, además de la versión instalada, y así poder realizar un ataque más específico:

expose_php = Off
No exponer errores de scripts al cliente. Los errores de programación no deben quedar expuestos a los clientes, sino que deben loggearse en archivos para que el programador los pueda depurar:

display_errors = Off
display_startup_errors = Off
Loggear errores permiten detectar cuál fue la falla que causó que el programa no funcione o lo haga de forma imprevisible:

log_errors = On
No utilizar register_globals. Esta funcionalidad se considera extremadamente peligrosa y por default viene desactivada en toda configuración actual, pero por las dudas se debe checkear que el valor sea el siguiente:

register_globals = 0
No utilizar magic_quotes. PHP provee, hasta la versión 5, de una utilidad para escapar caracteres peligrosos (', “, \, NULL), antes de ser utilizados por los scripts del servidor. Esto permite evitar algunos ataques de SQL Injection, pero tiene complicaciones con las distintas codificaciones de caracteres y además puede introducir problemas en la programación. Este tipo de controles deben estar implementados en la aplicación y no en el servidor, por lo cual a partir de PHP 5.3 se considera deprecated y en la versión 6 ya no existe.

magic_quotes_gpc = Off
magic_quotes_runtime = Off
magic_quotes_sybase = Off
Para realizar upload de archivos desde el cliente, utilizar el directorio tmp correspondiente al site, es decir /var/www/[nombre site]/tmp. Esta configuración se realiza en el virtual host con la sentencia:

php_admin_value upload_tmp_dir /var/www/[nombre site]/tmp
No tratar las URLs (como http:// o ftp://) como archivos. En caso de encontrar un error en la programación, un atacante podría realizar remote file inclusion si esto se encuentra activado.

allow_url_fopen = Off
allow_url_include = Off
Cambiar el nombre de la variable de sesión. Por defecto esta variable se llama PHPSESSID y demuestra que el servidor ejecuta PHP, y que la página actual está escrita en PHP. Si bien esto agrega poca seguridad, agrega una traba más al atacante.

session.name = SESSION_ID

Como dije, estas opciones ayudan a la seguridad, pero no evitan, por ejemplo, que un programa vulnerable a SQLi permita a un atacante romper la base de datos.
Espero que les sean de utilidad!

Referencias

- Description of core php.ini directives
- Securing PHP: Step-by-Step

Links: ACLs en GNU/Linux

noreply@blogger.com (d3m4s1@d0v1v0) — Sat, 06 Aug 2011 16:49:24 PDT

Hace años que abandoné esta sección que denominé "Links", y ahora encontré una buena razón para retomarla... mi trabajo con ACLs =)

En GNU/Linux la asignación de permisos a archivos y directorios se realizó históricamente con los permisos estándar Unix. El sistema de permisos es una de las primeras cosas que se enseñan en cualquier tutorial o manual de este sistema operativo, ya que son un concepto nuevo para casi cualquier usuario desktop Windows (donde los permisos suelen estar ocultos para el usuario...).
Los permisos Unix se administran por usuario, grupo y otros, y es posible asignar lectura, escritura y ejecución (rwx), además de algunos bits adicionales como sticky bit, set user id y set group id.
Esta forma de asociar permisos con archivos y directorios es suficiente para la gran mayoría de los casos, pero se queda corto cuando hay varios usuarios y grupos en juego, y se desea mayor granularidad.

Una forma bien conocida (al menos para cualquier estudiante de computación) de asignar permisos es utilizar listas de control de acceso (Access Control Lists - ACLs). Las ACLs permiten asignar permisos a listas de usuarios o grupos, en lugar de asignar permisos a sólo un usuario o grupo en particular, como sucede en el sistema Unix tradicional. Esta es la forma en que se asignan los permisos en la familia Windows NT.

Si bien GNU/Linux implementa POSIX ACLs desde hace años, no son tan utilizadas entre los linuxeros, y pocas veces mencionadas en los manuales introductorios. Dado que se utiliza poco, no hay muchas herramientas gráficas que lo implementen (una es eiciel), y por lo tanto la mejor manera es hacerlo por consola. Las herramientas utilizadas para setear y obtener las ACLs son setfacl y getfacl, y vienen en el paquete acl.
Para poder utilizar ACLs, el sistema de archivos debe poseer esta capacidad, y la partición debe ser montada con la opción acl. Casi todos los filesystems modernos la implementan, por lo que no deberían tener problemas con ello, sólo es cuestión de modificar el /etc/fstab para que se monte con la opción correspondiente.
Lo bueno es que si se activa el uso de POSIX ACLs, todavía es posible utilizar el sistema Unix tradicional, dado que, por compatibilidad, las mismas se crearon con esto en mente.

A continuación les dejo una interesante lista de páginas donde se explica el uso de ACLs en GNU/Linux. Anímense, que una vez que se acostumbran, son fáciles de administrar!

- POSIX Access Control Lists on Linux. Completísimo paper donde se discute el uso de ACLs en sistemas tipo Unix, describiendo el estandar POSIX ACLs, el orden en que se evalúan los permisos, ejemplos, análisis de performance, el uso en sistemas de archivos de red NFS y Samba. Es un buen punto de partida.
- Using ACLs with Fedora Core 2 (Linux Kernel 2.6.5). Muy buen artículo sobre el uso de ACLs, con varios escenarios como ejemplo para ver mejor su funcionalidad. Si bien el artículo asume el uso de Fedora, sirve para cualquier distribución.
- Linux ACL (Access Control Lists). Tutorial práctico sobre el uso de ACLs en Linux.
- Samba-3: Windows file and directory. Descripción del uso de ACLs en Samba.
- ACL(Access Control List) Configuration in Debian. Pequeño artículo sobre la configuración de ACLs en debian.

Espero que les sea de utilidad ^_^

Instalación de MIT Kerberos

noreply@blogger.com (d3m4s1@d0v1v0) — Mon, 01 Aug 2011 07:15:07 PDT

En el artículo anterior aprendimos sobre qué es kerberos, y para qué sirve. Es hora de ver cómo instalar un servidor para este servicio.
Este artículo forma parte del proyecto Autenticación y administración centralizada de usuarios en GNU/Linux (Autenticación y administración centralizada de usuarios en GNU/Linux).

Si bien existen varias implementaciones del protocolo, elegí MIT kerberos por estar desarrollado por MIT, autores del protocolo original, ser muy completa, muy soportada por librerías y la más utilizada. Otras implementaciones bastante utilizadas son Heimdal y GNU Shishi.

Antes de comenzar a instalar kerberos, es muy importante que los relojes de los hosts participantes estén sincronizados. Como se explicó, kerberos es muy dependiente del tiempo, una desincronización conlleva problemas de acceso.
También es importante tener un servidor de nombres de dominio con los registros correspondientes a cada host, incluidos los registros PTR, dado que kerberos utiliza los nombres de dominio para validar el hosts desde donde se piden los tickets.

A continuación se describe la instalación de kerberos en debian y derivados, pero en otras distribuciones es muy similar. Por su parte, la configuración del sistema es igual para todas las distribuciones.
En debian y derivados, instalar el servicio kerberos (con kdc incluido) es tan simple como ejecutar:

# apt-get install krb5-admin-server

La interfaz debconf de este paquete pregunta por parámetros básicos para el funcionamiento de kerberos:

configurar realm con el nombre del dominio, por ejemplo: demasiadovivo.org

escribir la dirección del servidor kerberos (es decir, la dirección del servidor donde estamos instalando kerberos, en este caso): kdc01.demasiadovivo.org
En este paso, obviamente necesitarán tener registrado el nombre kdc01 en el servidor de nombres. Lo mejor es tener un servidor de nombres propio para la red interna. Instalar y configurar bind es simple, por lo cual no debería implicar mayores problemas.
escribir el nombre del servidor administrativo de kerberos (cambio de contraseñas). Al igual que en el punto anterior, dado que estamos instalando el servidor kerberos, el nombre será el del mismo servidor actual: kdc01.demasiadovivo.org. El servidor administrativo es el que permite al administrador conectarse remotamente (herramienta kadmin) y trabajar sobre la base de datos de kerberos.

Al terminar la configuración inicial, tanto kadmind como kdc intentarán iniciar pero fallarán, dado que todavía no configuramos ningún realm.
Toda esta configuración inicial se puede realizar a mano, editando el archivo /etc/krb5.conf.

Para la creación de realms, poseemos la herramienta krb5_newrealm. Al ejecutar este comando, se creará la base de datos de kerberos para nuestro realm, y nos solicitará un password (master key del KDC) que se utiliza para generar la clave a almacenar en el stash (/etc/krb5kdc/stash), la cual sirve para encriptar la base de datos. Como se imaginan, este password es MUY importante y debe ser lo más fuerte posible. Aquel que posea el password, será capaz de desencriptar la base de datos y obtener todas las claves de los usuarios.

Una vez generado el realm, hace falta editar /etc/krb5.conf para agregar nuestro dominio default. Cuando abran este archivo se encontrarán que la sección [realms] cuenta con muchos realms famosos (varios del MIT, GNU.ORG, stanford.edu, etc). Si quieren tener una configuración limpia, lo mejor es eliminar todos estos realms; lo mismo para la sección [domain_realm]. Ahora, para agregar el dominio default, editen la definición del realm para que quede como lo siguiente:

[realms]
DEMASIADOVIVO.ORG = {
kdc = kdc01.demasiadovivo.org
admin_server = kdc01.demasiadovivo.org
default_domain = demasiadovivo.org
}

y agreguen el dominio a la definición de dominios:

[domain_realm]
.demasiadovivo.org = DEMASIADOVIVO.ORG
demasiadovivo.org = DEMASIADOVIVO.ORG

se colocan tanto el nombre de dominio como el nombre de dominio iniciando con punto ".", para indicar que se aplica a todos los subdominios del mismo.
Por defecto, kerberos loggea en syslog, pero si quieren tener los logs separados, pueden agregar la sección [logging] con una definición como la siguiente:

[logging]
kdc = FILE:/var/log/kerberos/kdc.log
admin_server = FILE:/var/log/kerberos/kadmin.log
default = FILE:/var/log/kerberos/krblib.log

Si utilizan el path propuesto anteriormente, deberán crear el correspondiente directorio en /var/log

# mkdir /var/log/kerberos

Para que los cambios surtan efecto, reiniciar tanto kadmin como el kdc

/etc/init.d/krb5-admin-server restart
/etc/init.d/krb5-kdc restart

Una vez instalado y configurado el servicio, podemos testear como va todo. Para esto, usamos la herramienta kadmin.local, la cual es como kadmin, pero destinada a utilizarse localmente, y por ello el usuario debe estar logueado en el servidor con una cuenta de usuario lo suficientemente privilegiada para poder abrir la base de datos de kerberos (por ej. root). A diferencia de kadmin que requiere un usuario de kerberos válido para acceder, kadmin.local no requiere password dado que el usuario que la utiliza es un administrador del servidor.
Usemos entonces kadmin.local de la siguiente forma:

# kadmin.local
Authenticating as principal root/admin@DEMASIADOVIVO.ORG with password.
kadmin.local: listprinc
K/M@DEMASIADOVIVO.ORG
kadmin/admin@DEMASIADOVIVO.ORG
kadmin/changepw@DEMASIADOVIVO.ORG
kadmin/dvpem01.demasiadovivo.org@DEMASIADOVIVO.ORG
kadmin/history@DEMASIADOVIVO.ORG
krbtgt/DEMASIADOVIVO.ORG@DEMASIADOVIVO.ORG
kadmin.local: quit

Lo que hicimos es entrar al modo administración de kerberos y listar los principals existentes con listprinc.

Los permisos para administrar kerberos se configuran en /etc/krb5kdc/kadm5.acl. Como vimos, kerberos permite utilizar roles, y en este archivo podemos utilizarlos. Por defecto vemos que figura el acl "*/admin *", el cual está deshabilitado, como comentario. Este acl permite acceso de administración full a todos los usuarios cuyo principal tenga el rol admin. Si descomentamos esta línea, podemos utilizar el rol admin en los principals para indicar qué usuarios pueden administrar kerberos.
Agregando el principal root/admin, podremos acceder con el usuario root a través de kadmin:

# kadmin.local
Authenticating as principal root/admin@DEMASIADOVIVO.ORG with password.
kadmin.local: addprinc root/admin
WARNING: no policy specified for root/admin@DEMASIADOVIVO.ORG; defaulting to no policy
Enter password for principal "root/admin@DEMASIADOVIVO.ORG":
Re-enter password for principal "root/admin@DEMASIADOVIVO.ORG":
Principal "root/admin@DEMASIADOVIVO.ORG" created.

Y podemos probar utilizando el comando:

# kadmin
Authenticating as principal root/admin@DEMASIADOVIVO.ORG with password.
Password for root/admin@DEMASIADOVIVO.ORG:
kadmin:

Si vemos el prompt de kadmin, es que todo fue bien.

Referencias

- The Kerberos protocol and its implementations
- Kerberos V5 System Administrator's Guide
- Kerberos FAQ, v2.0
- MIT Kerberos installation on Debian
- Kerberos Infrastructure HOWTO

El mítico Kerberos

noreply@blogger.com (d3m4s1@d0v1v0) — Mon, 25 Jul 2011 02:29:00 PDT

Uno de los servicios más utilizados actualmente para la autenticación en diferentes organizaciones es kerberos. Cualquiera que utilice o haya utilizado Active Directory seguramente conozca, aunque sea vagamente, kerberos, dado que este entorno lo utiliza como base. También se utiliza bastante en soluciones empresariales de Red Hat.
Dado que es un servicio de mucha importancia y uno de los que cualquier persona que trabaje en administración de sistemas o seguridad debe conocer, me parece bien dedicar un artículo para describir como funciona. En un próximo artículo veremos cómo instalarlo y configurarlo en GNU/Linux.
Este artículo forma parte del proyecto Autenticación y administración centralizada de usuarios en GNU/Linux.

Qué es?

Kerberos es un protocolo de autenticación desarrollado por el MIT e implementado en varios sistemas operativos. La principal función es permitir que dos nodos puedan autenticarse entre sí sobre una red insegura. Se utiliza principalmente en modelos cliente-servidor donde cliente y servidor pueden autenticarse mutuamente.
Kerberos funciona utilizando criptografía simétrica y requiere de una tercera parte confiable (siempre hay que confiar en alguien...).

Dato interesante: el nombre kerberos proviene del perro con tres cabezas y cola de serpiente, guardian de la entrada del templo de Hades en la mitología griega. El nombre era acertado porque la idea era proveer 3 mecanismos de seguridad: autenticación, contabilidad y auditoria. Desgraciadamente, sólo se implementó el componente de autenticación.

En el modelo kerberos contamos con dos servidores lógicos (que en la práctica suelen estar implementados en un sólo servidor físico denominado Key Distribution Center o KDC):

Authentication Server (AS): servidor encargado de autenticar al cliente y proveer un ticket para contactar al TGS. Este servidor almacena la clave de los clientes y las utiliza para autenticarlos.
Ticket Granting Server (TGS): servidor encargado de proveer tickets a los clientes para que puedan acceder al servicio deseado.

Qué servicios se puede acceder con un ticket de kerberos? cualquiera que implemente este tipo de autenticación. Por ejemplo, la autenticación de usuarios en un sistema operativo, acceso a servicios ldap, web, smtp, etc. Para poder utilizar un servicio kerberizado, el cliente debe primero contactar al AS y el TGS para obtener un ticket, que luego utiliza para acceder el servicio.
Los tickets tienen una validez de tiempo limitada, para lo cual se utilizan timestamps. Debido a esto, tanto clientes como servidores deben tener sus relojes sincronizados, porque sino el sistema no funciona. Normalmente esta sincronización se realiza utilizando el protocolo NTP.

Descripción del protocolo

El handshake de autorización para acceder a un servicio es la siguiente:

Cliente C contacta al AS requieriendo acceso a un servicio del Service Server (SS).
AS utiliza la clave que tiene almacenada del usuario (user master key) para encriptar la clave de sesión necesaria para encriptar los mensajes con el TGS (TGSsk). Además, AS envía al cliente otra tupla (denominada Ticket Granting Ticket - TGT) pero encriptada con la clave del TGS, la cual contiene el ID del cliente, la dirección de red del mismo, el tiempo de validez del ticket y la clave de sesión (TGSsk).
Cuando el cliente recibe los mensajes, desencripta el primero para obtener la clave de sesión TGSsk. Al desencriptar este mensaje, prueba quién es, dado que otro cliente no tendrá la clave necesaria para desencriptar el mensaje. El TGT no lo desencripta porque está encriptado con la clave del TGS.
El cliente ahora envía el TGT al TGS y un mensaje autenticador, compuesto por el ID del cliente y el timestamp, encriptado con la clave de sesión TGSsk.
Una vez que el TGS recibe los mensajes del cliente, desencripta el TGT para obtener la clave de sesión TGSsk, y con esta clave desencripta el otro mensaje (el autenticador) y responde al cliente enviando un nuevo ticket, muy similar al TGT, pero para ser utilizado con el Service Server, que provee el servicio deseado (por ejemplo ldap). Este mensaje contiene el ID del cliente, la dirección de red, el período de validez y una nueva clave de sesión para utilizar con el servidor (SSsk). Además, envía otro mensaje que contiene el SSsk, encriptado con la clave de sesión del TGS (TGSsk).
Finalmente el cliente tiene todo lo necesario para acceder el servicio que desea, por lo que contacta al SS enviando el ticket que recibió del TGS y un nuevo autenticador encriptado con la SSsk.
SS desencripta el ticket recibido para obtener la clave de sesión SSsk, con la cual desencripta el autenticador del cliente. SS responde con el último mensaje del handshake inicial que contiene el timestamp encontrado en el autenticador del cliente más 1, encriptado con la clave de sesión SSsk.
Con el último mensaje el cliente puede comprobar la autenticidad del servidor.

Resumiendo, obtenemos el siguiente flujo:

C ---- pedido de servicio -----> AS
AS ---- TGSsk encriptada con clave del cliente ----> C
AS ---- TGT ----> C
C ---- TGT ----> TGS
C ---- autenticador encriptado con TGSsk ----> TGS
TGS ---- ticket para acceder servicio ----> C
TGS ---- SSsk encriptado con clave del cliente ----> C
C ----> ticket para acceder servicio ----> SS
C ----> autenticador encriptado con SSsk ----> SS
SS ----> timestamp +1 encriptado con la clave de sesión SSsk ----> C

Sí, parece (o es) tremendo lío el sistema de autenticación, pero es efectivo y seguro, y prestando atención llega a entenderse bien (aunque con el tiempo uno se vuelve a olvidar =P).
Gracias a que la autenticación con usuario y contraseña genera el TGT, para acceder a distintos servicios sólo necesitamos este ticket, por lo cual no es necesario cargar las credenciales por cada servicio accedido. Esto permite que sistemas como el single sign-on funcionen. Además el TGT puede ser renovable dentro de un dado período de tiempo, lo que da flexibilidad a servicios que necesitan mucho tiempo para completarse.

Se desprende de la explicación anterior que el KDC contiene todas las credenciales de todos sus usuarios. Obviamente estas credenciales no se almacenan de forma plana en la base de datos. La base de datos se encripta utilizando una master key que el administrador debe elegir al momento de configurar el KDC. Pero esta master key también debe estar almacenada en algún lugar si se desea que el servicio se cargue automáticamente! En el kerberos de MIT la master key se almacena en el archivo stash. En AD existe un usuario denominado kbrtgt cuya contraseña es la utilizada como master key del KDC, este usuario no puede loguearse y está deshabilitado.

Limitaciones y desventajas

La obvia desventaja de un sistema de autenticación centralizado es el único punto de falla. Si se cae el AS o el TGS, nadie puede acceder a ningún servicio. Esto se soluciona utilizando más de un servidor y replicando los datos.
Todos los participantes deben tener coordinados sus relojes, porque sino, los tickets no funcionan.
Dado que todas las claves se almacenan en un servidor, si un atacante logra hackearlo, podrá acceder como cualquier usuario!
Otro problema es el replay attack, un ataque que no simple, pero tampoco imposible como se demuestra en el paper Replay Attack on Kerberos V and SMB.

Terminología

En el mundo kerberos existen ciertas definiciones que es necesario conocer para poder configurarlo correctamente. Veamos entonces los términos utilizados:

Realm (reino, interesante nombre): indica el dominio de autenticación. El realm establece los límites en los cuales un servidor de autenticación tiene autoridad para autenticar usuarios, hosts o servicios. Es posible, sin embargo, realizar autenticaciones cross-realm entre, por ejemplo, un usuario de un realm y un servicio de otro. Esto se lleva a cabo a través de una relación de confianza entre los realms que debe ser establecida previamente.
Principal: es el nombre utilizado para referirse a las entradas en la base de datos del servidor de autenticación. Cada usuario/host/servicio del realm tiene asociado un principal (string) que lo identifica. Ejemplos de principals son el nombre de usuario, el nombre de un host, etc. Cada principal puede tener varios componentes, pero generalmente se usan 3:

primary: la primera parte del principal. En el caso de un usuario, este es su nombre de usuario. En el caso de un servicio, es el nombre del servicio.
instance: la segunda parte de principal. Da información que califica al primary y puede ser null. En el caso de un usuario, el instance suele usarse para describir el uso para el cual están destinadas las credenciales. En el caso de un host, el instance es el hostname.
realm: el nombre del realm en mayúsculas.

Ticket: en la explicación anterior se describió el concepto de tickets en kerberos. Un ticket permite demostrar la autenticidad de un cliente. Los tickets caducan luego de un cierto tiempo, y es necesario obtener uno nuevo cuando esto sucede, o bien renovarlo si esto es posible.
Keytab: es un archivo que contiene pares principal -> clave. Este archivo se puede utilizar para obtener tickets sin que el sistema pida password en el proceso de autenticación. El uso más común es en scripts que necesitan utilizar kerberos sin interacción humana. Los archivos keytab son muy importantes y deben mantenerse seguros.

Referencias

- Kerberos protocol wik
- The Kerberos protocol and its implementation
- Kerberos FAQ, v2.0

Sincronicemos relojes con NTP

noreply@blogger.com (d3m4s1@d0v1v0) — Thu, 14 Jul 2011 05:15:02 PDT

En el artículo Configurar NTP en GNU/Linux se explicó como instalar y configurar NTP en una máquina cliente, pero faltaron detalles concernientes al protocolo y la instalación de servidores. El protocolo NTP es el más conocido y utilizado para sincronización de relojes, por lo cual es importante conocer las bases del mismo antes de instalar el servicio.

De la teoría de sistemas distribuidos sabemos que existen varios algoritmos para esta tarea. NTP emplea el algoritmo de Marzullo para la estimación, y usa un sistema jerárquico de niveles de fuentes horarias. Cada nivel se denomina stratum, y comienzan en el valor 0. Este valor se utiliza para indicar la distancia desde la fuente horaria, y no es un indicador de calidad o confiabilidad, dado que hay fuentes de stratum 3 de mejor calidad que algunos stratum 2.
Los stratum se definen de la siguiente manera:
- stratum 0 son dispositivos como relojes atómicos (por ejemplo de cesio), GPS, u otros relojes de radio. En general, estos dispositivos no están conectados a la red, sino conectados a computadoras (por ej, por RS-232).
- stratum 1 son computadoras conectadas a dispositivos stratum 0. Normalmente actúan de servidores NTP para servidores de stratum 2.
- stratum 2 son computadoras que envían solicitudes a servidores stratum 1. Estas computadoras suelen utilizar varias fuentes stratum 1 y utilizan el algoritmo NTP para obtener la mejor muestra. Las computadoras de este stratum se comunican entre sí en modalidad peer-to-peer para proveer tiempos más estables y robustos.
- stratum 3 son computadoras que emplean las mismas funciones que las de stratum 2, y pueden actuar de servidores de capas inferiores. NTP soporta hasta el stratum 256.
De esta organización jerárquica, tenemos que un cliente NTP puede operar en modelo cliente-servidor (donde el stratum del cliente es 1 más que el del servidor), o peer-to-peer (clientes con el mismo stratum). Además de estas dos, un servidor NTP puede funcionar enviando la hora en forma broadcast o multicast, y los clientes se configuran para sincronizarse con estas señales.

El proceso comienza cuendo un cliente NTP envía un paquete conteniendo su timestamp a un servidor. Cuando el servidor recibe el paquete, este almacena su propio timestamp y un timestamp de transmisión en el paquete, y lo envía de regreso al cliente. Una vez que el cliente recibe la respuesta, logguea la hora a la que lo recibió para estimar el tiempo de transmisión del paquete.
Teniendo varias fuentes horarias, el algoritmo de Marzullo selecciona las fuentes que se consideren confiables (en base a ciertos parámetros) para encontrar la hora precisa. De los intervalos retornados por las fuentes, se calcula el menor intervalo que sea consistente con el mayor número de fuentes (intersección). Si por ejemplo, los intervalos son [8,12], [11,13] y [10,12], la intersección de todos da [11,12]. Si en cambio, los intervalos son [8,12], [11,13] y [14,15], no existe un intervalo consistente con todos los valores, pero [11,12] es consistente con el mayor número de fuentes.
En el algoritmo original de Marzullo, el mejor valor se toma como el centro del intervalo. Un acercamiento más sofisticado (y utilizado en NTP) es reconocer que esto puede desperdiciar información valiosa de los intervalos confiables, y por ello es mejor utilizar un modelo probabilístico, que puede retornar un valor distinto al centro.

En GNU/Linux se instala un demonio que puede actuar como servidor y cliente, permitiendo sincronizar relojes con servidores de stratums superiores o entre pares del mismo nivel. La diferencia entre un servidor y un cliente está dada por los comandos de control de acceso.

En una configuración estándar, un host que trabaje de servidor puede configurarse teniendo en cuenta lo siguiente:
- debe contener al menos una fuente horaria superior (por ejemplo relojes stratum 2 o 1), o bien deben existir otros servidores del mismo nivel (peers) para calcular la hora, o ambos.
- debe utilizar una fuente horaria local, para el caso en que no se pueda conectar con otros servidores.
- debe permitir que hosts de la red consulten la hora, pero que no participen en el cálculo de la hora, o modifiquen la configuración.
Por su parte, un host cliente debera configurarse teniendo en cuenta que:
- debe sincronizar su hora con uno o más servidores NTP superiores
- no debe permitir que otros hosts consulten su hora, ni alteren la configuración.

Como se vió en el artículo anterior, la instalación del demonio NTP es tan simple como:
# apt-get install ntpd

Los comandos más utilizados dentro de la configuración (/etc/ntp.conf) son:
* server define servidor superior con el cual conectarse para obtener información horaria
+ iburst envía una ráfaga de ocho paquetes en lugar de uno en caso que el servidor esté inalcanzable
* peer define un servidor NTP que se encuentra al mismo nivel
* fudge permite establecer el stratum de un servidor
* restrict establece el control de acceso para una dada red o host:
+ kod envía un paquete "kiss of death" si el flag limited está presente y un paquete viola el límite de rate establecido
+ notrap niega el uso del servicio trap
+ nomodify niega consultas que intenten modificar el estado del servidor
+ nopeer evita que el host sea utilizado como servidor de hora
+ noquery previene consultas por el estado del ntpd

Teniendo en cuenta lo descripto líneas atrás, la configuración (/etc/ntp.conf) debe contener lo siguiente:
- En servidores NTP:
# servidores default debian, cambiar por los deseados
server 0.debian.pool.ntp.org iburst
server 1.debian.pool.ntp.org iburst
server 2.debian.pool.ntp.org iburst
server 3.debian.pool.ntp.org iburst

# configurar un servidor del mismo nivel (opcional)
# peer 192.168.1.10

# reloj local como fuente en caso que la conexión a internet se corte (esto lo asegura el stratum 10)
server 127.127.1.0
fudge 127.127.1.0 stratum 10

# acceso completo para localhost
restrict 127.0.0.1

# permitir a los hosts de la red 192.168.1.0/24 realizar consultas, pero no modificar nada
restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap

# restringir el acceso a todo el resto
restrict default kod notrap nomodify nopeer noquery

- Los hosts clientes, por su parte, deberán contar con las líneas:
# direccion del servidor configurado anteriormente (ej 192.168.1.56)
server 192.168.1.56

# restringir consultas para que otros hosts no lo utilicen como servidor
restrict default kod notrap nomodify nopeer noquery

Una vez terminada la configuración, reiniciar el demonio en clientes y servidores:
# /etc/init.d/ntp restart

Para testear la configuración, se puede ejecutar:
# ntpq -p
# ntpdc -p

Referencias

- Network Time Protocol wiki
- Marzullo's algorithm wiki
- Introduction to NTP
- Network Time Protocol daemon
- Access Control Commands and Options
- 6.5. ntpd access restrictions

Autenticación y administración centralizada de usuarios en GNU/Linux

noreply@blogger.com (d3m4s1@d0v1v0) — Wed, 12 Oct 2011 06:31:24 PDT

Desde que estoy en mi actual trabajo, me vi forzado a utilizar Active Directory (AD), a aprender de qué trata, cómo funciona, y cómo administrarlo.

Realmente este servicio me parece una buena idea por parte de MS, y a nivel empresa es muy útil. La experiencia en el trabajo me enseñó que cuando la cantidad de usuarios supera un cierto número, administrarlos por workstation y/o por servicio es muy complejo, inaceptable. Además, la facilidad de independizar al usuario de la workstation en la que se encuentra, es muy importante para muchas empresas.

El problema, claro está, es que AD es de MS, con todo lo que ello representa:

- código cerrado
- licencias caras y limitantes
- poco flexible
- software malo (si, la idea de AD es buena, pero el soft de MS es malo)
- hay que utilizar Windows
- fuerza a utilizar más software MS, gracias a su política "incompatible con el mundo no MS"
- no se puede aprender de él
- mientras todo anda, es fácil, pero cuando algo falla, arreglarlo es extremadamente difícil
- etc, etc

No es ningún secreto que MS no me cae bien, y creo que las razones anteriores son suficientes para ello.

Por eso me di a la tarea de buscar una alternativa libre que brinde capacidades similares. El objetivo es tener un sistema centralizado de usuarios, donde los usuarios tienen una identidad única para utilizar el sistema operativo (y las aplicaciones que utilicen autenticación integrada) desde cualquier máquina.

MS no inventó nada nuevo con Active Directory, sino que supo combinar protocolos que ya se utilizaban desde hace años y que mayoritariamente nacieron como protocolos libres, por lo cual existen alternativas para cada componente. El problema es unir estos componentes para que trabajen en conjunto.

Los componentes básicos para lograr la funcionalidad deseada son:

- Autenticación con Kerberos.
- NTP para mantener sincronizados los relojes (requerimiento importante para kerberos).
- Servicio de directorio LDAP para almacenar datos de usuarios, grupos, hosts, etc.
- DNS para asignar nombres de dominio.
- DHCP para distribuir direcciones IPs (opcional pero muy útil).
- Replicación de los datos entre múltiples servidores (multi-master replication).
- Administración de seguridad a través de políticas de grupo (GPOs).

Es claro que AD no se queda ahí y gracias al la integración con el resto del soft MS, es posible tener integrado servicio de email (Exchange), y servicio de archivos (SMB), entre otros.

Sacando las GPOs, todo el resto se puede lograr utilizando software libre, por ejemplo:

- MIT Kerberos
- NTP
- OpenLDAP
- Bind (DNS)
- Samba
- Postfix

La tarea entonces es configurar los servicios para que trabajen en conjunto.

Existe mucha información en internet sobre cómo lograr que las herramientas interactúen, pero poco sobre proyectos que integren todo.

El más notable al respecto es la distribución Calculate Linux. Si bien todavía no probé esta distribución, la descripción de la misma es muy alentadora, ya que hasta permite integrar hosts Windows para que interactúen con los servidores Linux.

En base a lo expuesto, desde hace un par de meses estoy trabajando en armar una infraestructura como la de Active Directory, pero utilizando software libre y documentando todo al respecto, desde la definición de kerberos y LDAP, hasta la instalación y configuración de los diferentes servicios en servidores y clientes para lograr la funcionalidad deseada.

Como la información es mucha, decidí repartirla en varios artículos que iré publicando a lo largo del próximo mes (o tal vez dos meses). Uno de estos artículos ya lo publiqué hace un par de semanas, y trata sobre PAM.

La lista de artículos es la siguiente:

- Sincronicemos relojes con NTP
- Un servicio básico, el DNS: breve descripción y cómo utilizar bind
- El mítico Kerberos
- Instalación de MIT Kerberos
- LDAP: Un directorio liviano
- Instalar y configurar el directorio OpenLDAP
- Autenticación en GNU/Linux con PAM
- Autenticar con kerberos y almacenar información de usuarios con LDAP en GNU/Linux
- OpenLDAP kerberizado

A medida que los vaya publicando, volveré a este artículo para actualizar los links y tener así todo integrado.

De los citados, sólo me falta escribir el de DNS, y puede que alguno lo termine partiendo en 2 por ser muy largos, pero básicamente no cambiará mucho a lo planteado.

También espero tener tiempo de armar un sistema de archivos y montar un servidor de mail con postfix, pero como viene la mano en el trabajo, puede que eso quede para más adelante.

Mi recomendación es que si les interesa la idea, vayan armando sus propios proyectos y compartan dudas, mejoras o lo que se les ocurra. Pueden utilizar comentarios en el blog o en la página de IT Freek Zone en facebook.

Les recomiendo utilizar máquinas virtuales para poder probar servidores y clientes con una sola máquina de forma rápida. Además clonando discos virtuales es fácil deshacer y volver a empezar.

Autenticación en GNU/Linux con PAM

noreply@blogger.com (d3m4s1@d0v1v0) — Wed, 28 Sep 2011 04:53:14 PDT

Antiguamente, la autenticación en sistemas UNIX estaba ligada al que hoy conocemos como "sistema tradicional UNIX", el cual verifica usuario y contraseña contra los valores almacenados en el archivo /etc/passwd (en versiones modernas el password se movió al archivo /etc/shadow por cuestiones de seguridad).
Dado que con los años se fueron desarrollando distintos métodos de autenticación más seguros, seguir clavados utilizando el método tradicional era poco flexible y sin sentido.
A partir de la necesidad de poder cambiar fácilmente entre métodos de autenticación y utilizar distintos métodos, Sun diseñó PAM (Pluggable Authentication Modules). PAM es un conjunto de librerías que permiten una gran variedad de mecanismos de autenticación, entre los cuales contamos con Kerberos, LDAP, y RADIUS (además del tradicional /etc/passwd). Gracias a esto, actualmente es posible autenticar usuarios GNU/Linux contra bases centralizadas de usuarios como el citado kerberos.
PAM no sólo permite utilizar distintos métodos de autenticación, sino que permite utilizar varios al mismo tiempo. Además agrega la posibilidad de utilizar otros medios de autenticación (más allá del clásico usuario/password), como ser smartcards, tockens, etc.

En este artículo les explicaré cómo se configura la autenticación utiliando PAM, y sobre el final podremos entender la configuración de un debian default.

Configuración

PAM divide la tarea de autenticación en cuatro grupos de administración separados:

- account provee verificación de tipos de servicio para la cuenta: el password expiro? tiene permitido acceder el servicio requerido? root puede loguearse por consola?
- authentication autentica el usuario, y luego otorga los privilegios correspondientes (como membresía de grupo). Este módulo permite setear distintos requerimientos para autenticar al usuario, como passwords, smartcards, tockens, etc.
- password es responsable de actualizar los mecanismos de autenticación. Estos servicios están fuertemente acoplados con los del grupo authentication.
- session cubre las acciones que se deben hacer antes de que se otorgue un servicio y luego de que el servicio haya sido retirado. En el caso de login, las acciones pueden ser logging y montado de directorios.

La configuración de PAM se realiza a través de reglas y el archivo principal es /etc/pam.conf, aunque en general se prefiere dividir las reglas en diferentes archivos del directorio /etc/pam.d/.
Cada regla tiene cinco campos, separados por espacios:

servicio tipo control path-modulo argumentos-modulo

donde:

- servicio es el nombre familiar que corresponde a la aplicación (ej: login, su, sshd). Este campo no se incluye en los archivos de /etc/pam.d, dado que el servicio está indicado por el nombre del archivo en minúscula. El servicio correspondiente a login utiliza a los archivos common-account, common-auth, common-password y common-session para configurar cada uno de los grupos.

- tipo: es el grupo de administración al que se aplica la regla (account, auth, password o session).

- control indica el comportamiento que PAM debe seguir en caso de que el módulo asociado tenga éxito o falle. Este campo permite dos notaciones. En la notación simple, se utiliza una palabra clave, y en la compleja se encierran pares valor=acción entre corchetes [valor1=acción1, valor2=acción2, ....]
Una característica importante de PAM es que las reglas se pueden "apilar" para combinar los servicios de varios PAMs para una dada autenticación. Los valores de retorno de cada módulo se guardan en una pila. Gracias a esto, es posible, por ejemplo, intentar autenticar primero con kerberos, y si esto falla, intentar autenticar localmente con autenticación unix.

Las palabras claves más comúnmente utilizadas en la notación simple, son:

- required: indica que la ejecución del módulo debe ser exitosa para que la operación sea exitosa. Sin embargo, si el módulo falla, la operación fallará recién luego de que se invoque al resto de los módulos que vienen después.
- requisite: igual que required, pero si el módulo falla, se retorna el control directamente a la aplicación. Es decir, no se continua invocando módulos como sucede con required.
- sufficient: el éxito del módulo es requerimiento suficiente para la operación, esto es, no se continúa procesando los siguientes módulos. Si falla, el proceso continúa en la siguiente regla.
- optional: el resultado de este módulo es importante sólo si es el único en el stack.
En la notación compleja, los valores son códigos de retorno. Los más vistos comúnmente son:

- success: la función retornó ok
- ignore: ignorar el módulo en cuestión, sin importar si el flag de control es required, optional o sufficient.
- new_authtok_reqd: se requiere un nuevo token de autenticación. Utilizado generalmente cuando el password debe ser cambiado.
- default: implica todos los valores que no se mencionan explícitamente.
Las posibles acciones en esta notación pueden ser un entero n sin signo, que indica la cantidad de módulos a saltar en el stack, o tomar alguna de las siguientes formas:
- ignore: el estado de retorno del módulo no influenciará el resultado final, a menos que no haya otro módulo en el stack.
- bad: el estado de retorno debe indicar el fallo del módulo. Si esta es la primer falla, este estatus se usará para todo el stack.
- die: idem a bad, excepto que el stack termina y se retorna el control a la aplicación inmediatamente.
- ok: el código de retorno sobreescribirá un valor previo de éxito, pero no un estado previo de falla.
- done: idem a ok, excepto que el stack termina y el control se retorna inmediatamente a la aplicación.
- reset: se limpia el stack y se comienza de nuevo con el próximo modulo.
Como se puede observar, en la notación compleja se permite mucha más granularidad que utilizando palabras claves. Por ello, es posible representar los mismos valores que las palabras claves con notación compleja:

required = [success=ok new_authtok_reqd=ok ignore=ignore default=bad]
requisite = [success=ok new_authtok_reqd=ok ignore=ignore default=die]
sufficient = [success=done new_authtok_reqd=done default=ignore]
optional = [success=ok new_authtok_reqd=ok default=ignore]
- path-modulo es el path al módulo, o la dirección relativa al directorio donde se ubican los módulos por default, el cual es /lib/security en debian.

- argumentos-modulo son los argumentos, separados por espacios, que se envían al módulo.

Ejemplo práctico

Para entender mejor cómo funciona PAM, veamos el contenido de los archivos en la configuración de un sistema debian default.
/etc/pam.d/common-account (verificación de tipos de servicio)

account [success=1 new_authtok_reqd=done default=ignore] pam_unix.so
account requisite pam_deny.so
account required pam_permit.so

De la explicación anterior, podemos entender que el sistema utilizará el módulo pam_unix. Si esta autenticación tiene éxito (success=1), se saltea la siguiente regla y se ejecuta el módulo pam_permit, permitiendo el acceso.
En caso de fallar, se ejecuta el módulo pam_deny, el cual siempre retorna un valor de fallo; y como el parámetro de control es "requisite", la operación termina inmediatamente.

/etc/pam.d/common-auth (autenticación de usuario y seteo de credenciales)

auth [success=1 default=ignore] pam_unix.so nullok_secure
auth requisite pam_deny.so
auth required pam_permit.so

Este caso es casi igual al anterior, sólo que se utiliza el parámetro nullok_secure al llamar al módulo. En la acción default del módulo no se permite el acceso a un servicio si su password oficial es nulo. Lo que hace este parámetro es sobreescribir este comportamiento y permitir usuarios con password en blanco.

/etc/pam.d/common-password (actualización de passwords)

password [success=1 default=ignore] pam_unix.so obscure sha512
password requisite pam_deny.so
password required pam_permit.so
password optional pam_gnome_keyring.so

En este archivo el cambio es que se agregan los parámetros obscure y sha512 al módulo pam_unix. obscure fuerza el checkeo de la fortaleza del password y sha512 hace que los passwords se almacenen hasheados con sha512.
El módulo pam_gnome_keyring permite el desbloqueo del archivo donde Gnome almacena credenciales del usuario (viene con Gnome). Como ven, el resultado de la ejecución de este módulo no afecta el resultado final de la operación.

/etc/pam.d/common-session (acciones a realizar antes de login y luego de logout)

session [default=1] pam_permit.so
session requisite pam_deny.so
session required pam_permit.so
session required pam_unix.so

En este último archivo no encontramos nada especial, sólo que se ejecuta el módulo pam_unix. El formato de este archivo no tiene mucho sentido, porque dado que pam_permit siempre termina bien, lo siguiente a ejecutar es nuevamente pam_permit, con lo cual se continúa hasta la ejecución de pam_unix. La razón de que esto esté así es por compatibilidad con los archivos anteriores, ya que si observan bien, la estructura es similar.

Referencias

- PAM configuration guide for Debian
- The Linux-PAM System Administrators' Guide - 4. The Linux-PAM configuration file
- Understanding PAM

Metiendo mano en el hardware

noreply@blogger.com (emilio) — Sun, 19 Jun 2011 07:07:30 PDT

En este artículo voy a relatar una de las experiencias más satisfactorias que he tenido lidiando con hardware.

Este viernes encendí mi computadora de escritorio y al poco tiempo mi monitor lamentablemente se "murió". ~~Era~~ Es un monitor Samsung modelo SyncMaster740N LCD de 17" 4:3. Se trata de un modelo bastante común, ya que es usado generalmente en cibercafés, oficinas, etc.

Al poco tiempo de encender la computadora, la pantalla se volvió negra, como cuando se activa el ahorro de energía, pero la luz de power permaneció encendida (cuando está en ahorro de energía se mantiene parpadeando). Primero pensé en un problema de video por lo que reinicié la computadora sin éxito. Luego apagué y encendí el monitor repetidas veces y tampoco tuve éxito.

En ese momento me sentí frustrado al pensar en tener que afrontar un gasto de aproximadamente U$S 250, sobretodo teniendo en cuenta que el monitor tiene sólo 5 años de vida. Pero pensé que tal vez podría tener arreglo y, tocando botones de configuración y mirando detenidamente la pantalla, me dí cuenta que se veía una ventana muy pero muy tenuemente (con buena luz ambiente y prestando mucha atención). Parecía como si el monitor funcionara correctamente, aunque sin brillo o iluminación (la pantalla se veía opaca como la de una calculadora de bolsillo, aunque mucho más tenue).

Inmediatamente me puse a investigar en Internet y descubrí que a alguien ya le había sucedido exactamente lo mismo (http://www.fixya.com/support/t4636238-samsung_740n_blank_screen). Desde hace un tiempo el monitor emitía un zumbido extraño pero funcionaba correctamente, hasta que un día la pantalla se puso negra. Aparentemente los zumbidos se deben a capacitores en mal estado.

En otro sitio descubrí que cuando la pantalla se vuelve oscura pero se pueden ver las ventanas, significa que el problema son las backlights. Las backlights son una especie de pequeños tubos fluorescentes que se ubican detrás (o al costado) del panel LCD para darle iluminación y brillo a la pantalla y así producir una imagen visible. Esto se debe porque, a diferencia de las pantallas CRT, los paneles LCD no producen luz por sí mismos (http://en.wikipedia.org/wiki/Backlight). Entonces el problema podía estar en las backlights mismas o en el circuito que las alimenta. Aunque el zumbido que emitía el monitor hasta el momento de apagarse indicaba que el problema era algún capacitor en mal estado.

En un foro que me resultó extremadamente útil (http://www.yoreparo.com/foros/plasma_lcd/falla-lcd-samsung-740n-t259814.html) encontré la respuesta a mi problema:

Atención reparadores de monitores SAMSUNG 740 N, 17 pulgadas. Al cabo de tres años de funcionamiento, estos monitores fallan debido a la temperatura que alcanza la fuente de alimentación, por cierto muy mal ventilada.

Deja de funcionar la fuente de la lámpara del panel, sin embargo, el monitor sigue trabajando normalmente (se comprueba al abrir el menu de ajustes, porque se puede ver muy tenuemente)

Los primeros en fallar son tres capacitores de 820 uF/25v que filtran la etapa previa a los exitadores de la fuente de 650 v, 17 mA
(c112, c111, c301) extrañamente de un color distinto a los demas (marrones), se ve que son de inferior calidad. Con la temperatura se inchan y se desvalorizan. Tambien salta un pico fusible de 3A (ubicado entre medio de una pegamento blanco entre el disipador de D105 y los capacitores nombrados. Reemplazando estos se soluciona. [sic]

A eso se resume básicamente mi experiencia, podría cerrar el artículo en este punto pero voy a continuar explicando los detalles.

Esperanzado me puse a desensamblar el monitor y en un principio me resultó imposible ya que no tiene tornillos. Me puse a buscar en Google y encontré un manual (http://www.eserviceinfo.com/downloadsm/28685/Samsung_740N.html) del fabricante donde explica paso a paso como desarmar y armar el monitor con fotos (muy bueno, asombrosa la calidad de los manuales de Samsung). De forma increíble todo el monitor es sostenido por la carcasa de plástico, la cual se mantiene unida con unas pequeñas trabitas de plástico (afortunadamente no se rompió ninguna al desarmarlo, como me ha sucedido otras veces al tratar de desarmar otros dispositivos como radios, controles remotos, etc.).

En la foto se observa el monitor completamente destripado. Al examinar los componentes de la plaqueta rápidamente me dí cuenta que los tres capacitores indicados en el post del foro yoreparo.com estaban "inflados", incluso uno tenía un sedimento en la parte superior. Esto es algo que aprendí cuando cursaba taller de electrónica en la secundaria: si un capacitor está inflado significa que está roto. Por eso es uno de los componentes más fáciles de detectar.

En la foto se ve claramente la parte superior inflada (notar la diferencia con los otros capacitores).

El siguiente paso fue retirar del circuito los capacitores dañados. Esto se debe realizar cuidadosamente para no dañar el resto de los componentes. Con un soldador de estaño (si se dispone uno de baja potencia, por ejemplo 15W, mejor) se calientan las patas y se va tirando del capacitor suavemente y alternando entre patas hasta removerlo completamente.

Con uno de los capacitores me dirigí a la casa de electrónica más cercana (ninguna realmente cercana así que tuve que patear bastante) para buscar los recambios. Estos capacitores son de 820uF y son difíciles de conseguir, entonces tuve que comprar de 1000uF. Además no conseguí de 105º, los que compré son de 85º (espero que aguanten la temperatura elevada hasta que pueda conseguir de 105º).

Procedí entonces a instalar los nuevos capacitores. Primero se debe eliminar el estaño de la pista (sería ideal disponer de un removedor de soldadura) y luego colocar la pieza. Se debe prestar extrema atención al colocar los capacitores electrolíticos, ya que estos poseen polaridad. Si se conectan de forma inversa van a, literalmente, explotar (lo cual por cierto es muy divertido http://www.youtube.com/watch?v=ipiyP6Cph9M). En la plaqueta y en el capacitor se indica claramente el polo negativo. De todas formas hay que revisar la polaridad antes de soldar y antes de conectar.

La forma adecuada de soldar es calentar con la punta del soldador la pista y la pata al mismo tiempo y luego aplicar la cantidad suficiente de estaño. Si la pista o la pieza están frías la soldadura será defectuosa y seguramente no hará contacto, por lo que hay que tener cuidado al realizar la unión. Luego se corta el excedente de pata y se revisa cuidadosamente la pista para que no queden puentes de estaño entre pistas contiguas.

Bien, lo que quedaba era ensamblar precariamente el monitor para poder comprobar el correcto funcionamiento. En la primera prueba que hice el monitor no encendió, por ello tuve que volver al post encontrado en yoreparo.com para darme cuenta que también el picofusible podía estar quemado. De hecho lo estaba, para darme cuenta simplemente hice un puente en el fusible y el monitor encendió, para mi alegría.

Dado que no conseguí hasta el momento un picofusible de repuesto, lo reemplacé con un fusible común de 3A y probé continuidad con el tester para comprobar que estuviera todo OK.
Luego de terminada la reparación, ensamblé el monitor y lo probé con la notebook.

Perfetto!

El costo total de la reparación fue de aproximadamente U$S 2.

Conclusión: vale la pena intentar reparar las cosas :)

Espero que les haya gustado.

Administrar proyectos libres con Launchpad y Bazaar

noreply@blogger.com (d3m4s1@d0v1v0) — Tue, 07 Jun 2011 07:37:41 PDT

En los últimos días estuve ocupado creando una herramienta que me permitiera realizar consultas sobre un servicio LDAP para obtener información de los usuarios de un dominio. La herramienta en cuestión la realicé en Python y me pareció que era lo suficientemente interesante como para compartirla con la comunidad libre para que cualquiera pueda utilizarla y/o modificarla.
Esto me llevó a la búsqueda de un servicio de versionado y hosting libre donde subir el proyecto. Algunos años atrás hubiera utilizado SourceForge sin pensarlo, pero gracias a su cambio de política hacia una censurista y asquerosamente repudiable (que raro que provenga de una ley yankee "defensores de la libertad"...) que deja afuera a los países Iran, Corea del Norte, Cuba, Siria, Libia y Sudan, decidí buscar una alternativa que sea realmente libre. La idea es compartir código entre comunidades sin importar estatus social, país de orígen, color de piel, etc, etc, y SourceForge no cumple con este importantísimo requisito. Lo mismo sucede con Google Code, lo cual elimina al segundo gran proveedor de software open source.
Por ello, utilizando la muy completa entrada de wikipedia Comparison of open source software hosting facilities, revisé cuál de los servicios se adaptaba mejor a lo que quería. Por orden de popularidad tenemos SourceForge (descartado), Launchpad, Google Code (descartado), GitHub y Assembla. De entre estos elegí Launchpad porque los términos de servicio de GitHub y Assembla no me terminaban de agradar. Increíblemente GitHub impone copyright sobre el código html/javascript/css de SU propia página... un site que promulga el hosting de aplicaciones open source y no es libre, no me agrada. Además, los mencionados servicios están hosteados en USA y aplican sus leyes, con lo cual corremos el riesgo que suceda lo mismo que con SourceForge.
Launchpad es de Canonical Ltd. (la gente detrás de Ubuntu) y esto también me genera dudas, dado que desconfío de las intenciones de dicha compañía... pero no encontré nada malo en sus términos de servicio (es más, no encontré términos de servicio para hosting de proyectos...), es una comunidad muy grande con proyectos importantes (MySQL, Ubuntu, Enlightenment, Bazaar, entre otros), no está hosteado en USA (por lo que vi, los servidores son de Gran Bretaña) y el administrador de proyectos me parece bueno.

A continuación describiré los pasos necesarios desde la creación hasta la publicación de una versión descargable de nuestro proyecto, utilizando Launchpad y Bazaar.

Creación del proyecto en Launchpad

Para crear un proyecto en Launchpad, primero debemos registrar una cuenta, si es que no poseemos una. La registración es simple y no requiere muchos datos.
Una vez que estamos registrados y logueados, nos dirigimos a https://launchpad.net/projects/+new para registrar nuestro proyecto.
Para tener una idea sobre cómo se administran los proyectos en Launchpad, les recomiendo leer la ayuda oficial.

Creación del proyecto en Bazaar

Launchpad utiliza Bazaar para el versionado de proyectos, por lo que necesitaremos conocer una lista de comandos básicos de este sistema. Es posible importar branchs de otros manejadores de versionado como Git, Mercurial, Subversion y CVS, pero si recién están comenzando, o si nunca utilizaron un manejador de versiones, por qué no probar con Bazaar?

Instalar Bazaar en debian y derivados es tan simple como ejecutar:

# apt-get install bzr

Una vez instalado, configuramos nuestro nombre de usuario:

$ bzr whoami "demasiadovivo <demasiadovivo@spameame.com>"

y verificamos que el nombre se registró correctamente:

$ bzr whoami
demasiadovivo <demasiadovivo@spameame.com>

Luego del simple setup inicial, nos metemos con la creación y administración de proyectos utilizando este sistema de versionado.
El primer paso es inicializar el proyecto:

- dirigirse al directorio donde se encuentra el código del proyecto:
$ cd /path/mi-proyecto
- inicializar:
$ bzr init

Al hacer esto, Bazaar crea el primer branch y almacena los datos en un directorio denominado ".bzr". Un branch es un registro de todos los commits que se han hecho. Pueden existir varios branches en paralelo, los cuales luego se pueden combinar (merge).
Para agregar los archivos que deseamos seguir, se utiliza el comando bzr add . Para agregar todos los archivos del directorio del proyecto, podemos simplemente ejecutar:

$ bzr add
adding README.txt
adding useraudit.cfg
adding useraudit.py
adding useraudit_cli.py

Ahora, cuando tenemos código sobre el cual deseamos crear un snapshot, realizamos un commit. En el commit es posible agregar un comentario, indicando la razón del mismo:

$ bzr commit -m "Primer commit"
Committing to: /ruta/mi-proyecto/
added README.txt
added useraudit.cfg
added useraudit.py
added useraudit_cli.py
Committed revision 1.

Podemos ver el historial de commits con:

$ bzr log
------------------------------------------------------------
revno: 1
committer: demasiadovivo

branch nick: mi-proyecto
timestamp: Sun 2011-06-05 16:20:03 -0300
message:
Primer commit

Subir el código a Launchpad

Para poder subir código a Launchpad, primero deberán generar un par de claves SSH, para lo cual pueden seguir el artículo Automatización de transferencias por SFTP, y a continuación publicar la clave pública en https://launchpad.net/~<usuario>/+editsshkeys
Recuerden que la clave pública se encuentra en /home/<usuario>/.ssh/id_rsa.pub, si es que no eligieron otro path al generar el par de claves.
Con esta clave podremos autenticarnos ante Launchpad y así subir código.

Una vez que registramos nuestra clave SSH, podemos subir el commit a Launchpad ejecutando:

$ bzr push sftp://<usuario>@bazaar.launchpad.net/~<usuario>/<mi-proyecto>/<branch>

donde:

bazaar.launchpad.net es la dirección de Bazaar en Launchpad
<usuario> es nuestro usuario en Launchpad
<mi-proyecto> es el proyecto que registramos en Launchpad
<branch> es el branch que deseamos crear

Si queremos hacer un commit a un branch que ya existe, deberemos ejecutar el mismo comando pero con un parámetro adicional:

$ bzr push --use-existing sftp://@bazaar.launchpad.net/~<usuario>/<mi-proyecto>/<branch>

Luego de crear el branch, es posible (al menos a mi me sucedió), que Launchpad nos diga que el proyecto todavía no tiene un branch. Esto es que Launchpad no sabe cuál es el branch principal, por lo cual nos dirigimos a https://launchpad.net//trunk/+setbranch y elegimos la opción "Link to a Bazaar branch already on Launchpad", y en el textbox donde indicamos el branch ponemos la dirección del branch recién creado:

~<usuario>/<mi-proyecto>/<branch>

Generar un release

Una vez que estamos lo suficientemente conformes con nuestro código y queremos que usuarios finales descarguen el programa, debemos generar un release y para generar un release, necesitamos un milestone.

Los milestones son puntos específicos en la vida de una serie (series en inglés), y una "serie" representa la serie de lanzamientos de una versión mayor. Los puntos representados por un milestone pueden ser beta tests, release candidates, o puntos menor y mayor de lanzamiento. Pueden leer más sobre series, milestones y releases en Projects/SeriesMilestonesReleases.
En fin, para crear un milestone, nos dirigimos a la sección "Milestones and releases" de la página principal del proyecto y le damos al link "Create milestone" (https://launchpad.net//trunk/+addrelease).
Entre la información que debemos proveer, el único campo obligatorio es el nombre, el cual se toma como la versión.

Una vez que tenemos el milestone creado, podemos proceder a realizar el release. Hacerlo es tan simple como darle al link "Create release" que se encuentra en el milestone bajo el título "Expected" y setear una fecha.

Cuando terminamos de crear el release, el site nos regresa al milestone, donde podemos ver que la fecha del release se actualizó. Ahora sí podemos agregar un archivo tarball descargable que contenga el programa completo.
Pueden generar el tarball de diferentes formas, pero si lo van a hacer desde la consola, deberán dirigirse al directorio padre del proyecto y ejecutar lo siguiente:

$ tar -czvf mi-proyecto_v0.1.tar.gz --exclude-vcs mi-proyecto/

donde la opción --exclude-vcs evita que tar incluya el directorio que utiliza Bazaar para sus datos (es decir, el ".bzr").
Ya tenemos todo lo necesario para subir el tarball con el programa completo y que se pueda descargar. Para ello, en el milestone seleccionamos "Add download file". En la interfaz de upload debemos proveer tanto el archivo como una descripción de lo que contiene el mismo (por ejemplo "mi-proyecto 0.1 tarball"). También es posible proveer una firma GPG, lo cual brinda mayor seguridad al cliente que descarga, ya que puede confiar que el archivo ha sido creado por nosotros. Para poder firmar el archivo debemos poseer una un par de claves GPG (o PGP), y la clave pública debe estar publicada en algún lugar de confianza.
El mismo site da la ayuda de cómo crear la firma digital del archivo:

gpg --armor --sign --detach-sig

lo cual crea el archivo filename.asc que después debemos subir utilizando el campo "GPG signature".

Trabajo Terminado

Si quieren ver el resultado final, pueden ingresar al site de mi proyecto. También están invitados a descargar, testear, recomendar, compartir, etc, etc, el programa. Ya escribiré algún post sobre la herramienta =)

Referencias

- Launchpad Projects
- Bazaar in five minutes
- Hosting your code on launchpad and bazaar

Estadísticas sobre uso de recursos en GNU/Linux

noreply@blogger.com (d3m4s1@d0v1v0) — Tue, 17 May 2011 12:15:24 PDT

Si son sysadmins, necesitarán alguna forma de ver cómo se utilizan los recursos de nuestros sistemas, sobre todo cuando las cosas andan mal. Ver estadísticas sobre el uso de recursos permite tomar varias decisiones, como comprar hardware, separar servicios, virtualizar, o para solucionar errores en caso de procesos glotones, entre otras cosas.
Si bien en GNU/Linux todas las estadísticas se almacenan en el /proc, es necesario contar con alguna herramienta que las interprete y las haga más amigables. Para ello, contamos con sysstat, un paquete que provee varias herramientas para monitorear la performance del sistema y el uso de recursos.
Los componentes más interesantes de sysstat son:

- sar: reúne, reporta y almacena información de actividad del sistema (CPU, memoria, discos, interrupciones, interfaces de red, TTY, tablas del kernel, etc). Esta herramienta provee muchas opciones para filtrar los datos que deseamos obtener, y permite almacenar los resultados en archivos binarios que luego se pueden visualizar con el mismo sar. Es posible indicar la cantidad de muestras a tomar y el intervalo de tiempo entre muestras.

- sadc (system activity data collector): se encarga de recoger información del sistema una dada cantidad de veces, a intervalos específicos de tiempo, y se utiliza como backend de sar. Escribe en formato binario en un dado archivo o en la standar output. Si no se especifica la cantidad de muestras a tomar, éste escribe infinitamente.

- sa1: un shell script que utiliza sadc para generar el archivo binario /var/log/sa/sadd o /var/log/sysstat/sadd (donde dd es el día del mes, por ejemplo sa16 indica el día 16). Este script está designado para utilizarse con cron (ver /etc/cron.d/sysstat).

- sa2: otro shell script que utiliza sadc para generar reportes diarios en el archivo binario /var/log/sa/sardd o /var/log/sysstat/sardd (donde dd es el día del mes). Este script también está designado para utilizarse con cron (ver /etc/cron.daily/sysstat).

- sadf: permite mostrar el contenido de archivos binarios sar en diferentes formatos (CSV, XML, etc). El formato de salida default es uno fácilmente parseable por diferentes herramientas shell como grep, awk, sed, etc.

- pidstat: reporta estadísticas de procesos como uso de CPU, memoria, I/O, etc. Como en sar, es posible indicar la cantidad de muestras y el intervalo de tiempo entre muestras.

Si deseamos medir la utilización de recursos en el server, lo mejor es dejar que sa1 y sa2 generen los correspondientes logs durante un día, una semana, un mes o el tiempo que quieran, y luego visualizarlos con sar. Por defecto las muestras se toman cada 10 minutos, lo cual provee un buena visión sobre como se utilizan los recursos.
Otra posibilidad es ejecutar sar con el parámetro "-o archivo" para almacenar los datos en un archivo binario, e indicarle el intervalo de segundos entre muestras y la cantidad de muestras a tomar. Por ejemplo, el siguiente comando almacena todos los datos de utilización de recursos en el archivo "revision" cada 5 minutos:

sar -A -o revision 300

Para poder parsear el archivo recién generado con sar, es necesario utilizar el parámetro -f, por ejemplo:

sar -A -f revision

En la mayoría de los casos lo que necesitamos visualizar es uso de memoria, CPU, disco, swap y red. Todo esto se puede hacer con el siguiente comando:

sar -rudpW -n DEV,SOCK

donde:

-r muestra uso de memoria
-u muestra uso de CPU
-d muestra uso de disco
-p imprime el nombre de los dispositivos de forma agradable (usado con -d)
-W muestra estadísticas de swap
-n DEV,SOCK muestra estadísticas de las interfaces de red y cantidad de sockets utilizados.

Si no se utiliza el parámetro -f, sar toma los datos de los logs generados por sa1 y sa2. En caso de utilizar un archivo binario generado con sar (por ejemplo revision), pueden usar el siguiente comando:

sar -rudpW -n DEV,SOCK -f revision

Como podrán observar, la salida de sar no es muy amigable para ser filtrada y/o graficada y/o almacenada en una base de datos, así que lo mejor es utilizar sadf. sadf provee un set de opciones propias y permite utilizar las opciones de sar luego de dos giones (--). Entre las opciones propias de sadf, son interesantes:

-d imprime la salida con los campos separados con punto y coma (;)
-D igual a -d pero utiliza timestamp en lugar de fechas human friendly
-h para imprimir los resultados en una sola línea
-p salida default, amigable para los parsers
-x imprime la salida en formato XML

El comando del ejemplo anterior, utilizando sadf para ser parseado fácilmente, quedaría:

sadf -- -rudpW -n DEV,SOCK

o con -h para separar fácilmente los campos en una planilla (Calc, Excel, etc)

sadf -h -- -rudpW -n DEV,SOCK

Además de las estadísticas anteriores, para hilar más fino a la hora de ver quién gasta los recursos, es necesario tener estadísticas de los procesos que se están ejecutando. Para ello contamos con pidstat, cuyos datos arrojados son similares a los de sar, pero por proceso. pidstat acepta varios argumentos para mostrar distintas estadísticas, pero para una vista básica, me alcanza la siguiente configuración:

pidstat -ru -h 300 | sed '1,2d'

donde:

-r muestra uso de memoria
-u muestra uso de CPU
-h muestra las estadísticas horizontalmente (todo en una sola tabla).
300 es el intervalo de tiempo (en segundos) para tomar muestras
sed '1,2d' elimina las primeras dos líneas de la salida (son un comentario y una línea en blanco)

pidstat no ofrece la opción de crear un archivo binario para almacenar los datos, por lo cual debemos redirigir la salida a un archivo para poder filtrarla luego.

Si lo que quieren son gráficos de utilización (siempre algo visual ayuda a captar mejor los datos), podemos utilizar la salida de sadf y graficar con Calc (o Excel), con gnuplot, o con la interesante Sysstat Graph. No tuve la oportunidad de probar esta última, pero aparenta ser muy útil. Está escrita en PHP, por lo cual es fácil de instalar.

Referencias

- Sysstat man
- How do I Find Out Linux CPU Utilization?

Configuración inicial de un PacketShaper

noreply@blogger.com (d3m4s1@d0v1v0) — Mon, 09 May 2011 05:49:36 PDT

Un nuevo reto en redes se me presenta y felizmente afronto. Esta vez toca configurar un dispositivo denominado BlueCoat PacketShaper que permite medir la performance de aplicaciones que utilizan la red, categorizar y administrar el tráfico Web basándose en el contenido, garantizar calidad de servicio (QoS) y contener el impacto del tráfico indeseable. Realmente no había sentido nombrar este dispositivo, así que me sentía ansioso por ponerle las manos encima.
Como no hay mucha información en español (bah, en inglés tampoco...), me parece interesante comentarles cómo configurar uno de estos "bichos", por si les toca hacerlo en algún momento.

El dispositivo presenta tanto una interfaz Web como una por línea de comandos (CLI). Como es costumbre en este tipo de dispositivos, presenta un port serie a través del cual es posible accederlo para la configuración inicial.
En este artículo describiré cómo realizar la configuración inicial, necesaria para comenzar a analizar tráfico y crear reglas. Más adelante espero escribir al menos un artículo (espero sean más) sobre la creación de reglas para priorizar y analizar tráfico.

Como ya les comenté en los artículos sobre configuración de switchs y APs, necesitarán algún programa como minicom que se comunique a través del port serie, con una configuración 9600 bps - 8bits - sin paridad - 1 stop bit - sin control de flujo. Si están perdidos en este punto, lean el artículo Acceder dispositivos Cisco desde GNU/Linux con minicom.

Al revisar el aparato nos encontramos básicamente con 3 ports RJ45, uno denominado INSIDE, otro OUTSIDE y el último MGMT (Management). Dependiendo la estructura de nustra red y de lo que deseemos hacer con el PacketShaper, variará la forma en que conecten la entrada y la salida, pero en general se aplica la regla "placa INSIDE conectada a nuestra red y OUTSIDE al router/firewall que sale a la WAN (posiblemente Internet)". Esto es, si deseamos administrar el tráfico de internet, colocamos el PacketShaper entre nuestra red e internet de la siguiente forma:

RED Interna <----> INSIDE
       OUTSIDE <----> firewall <----> router <----> Internet

La placa MGMT la utilizaremos para configurar el dispositivo una vez que le hayamos seteado una IP. Es conveniente que conectemos esta placa a una red segura porque es la puerta de entrada al dispositivo.
El dispositivo es "transparente" para nuestra red, no se necesita configurar IPs para las placas INSIDE y OUTSIDE. Es como si pincháramos el cable de red que conecta la red interna con el router y viéramos el tráfico que pasa. Incluso si el PacketShaper está apagado, la red funciona normalmente dado que se puentean las interfaces INSIDE y OUTSIDE.

Ahora si, nos conectamos al dispositivo a través de la conexión serie y abrimos minicom, gtkterm, cutecom, o HyperTerminal (si son Windowseros), y comenzamos la configuración.
Por suerte el software para realizar la configuración inicial es bastante amigable y nos va guiando a través de diferentes preguntas con breves explicaciones para que podamos entender qué estamos haciendo. La configuración que les propondré es para utilizar un PacketShaper sin PolicyCenter en una red Gigabit, aunque es lo suficiente genérica para poder utilizarla en otras configuraciones. La versión de PacketWise (soft del PacketShaper) que estoy utilizando es de la rama 8.4. A modo de itemizado, los primeros pasos de la configuración son:
- Elegir el modo local (standalone) porque vamos a configurar el PacketShaper de forma independiente, y no a través del software PolicyCenter (modo shared). Esto, claro está, cambiará si poseen PolicyCenter. En mi caso sólo poseo un PacketShaper y no es necesario.
- Setear una dirección IP (ej: 192.168.1.250), para poder acceder el dispositivo remotamente a través de la interfaz Web o ssh.
- Configurar la velocidad de las interfaces INSIDE y OUTSIDE (10bt, 100bt, auto) en auto, para que negocie la velocidad (aparentemente la única forma de funcionar en Gigabit es eligiendo auto).
- Setear el gateway de la red donde se encuentra conectado el dispositivo.
- Si se desea, en el siguiente paso es posible (y muy recomendable) configurar un servidor de DNS para resolver las direcciones.
- Tambiés es posible configurar el nombre de dominio, para ser agregado en lookups de nombres non-fully-qualified.

Passwords:
Luego de la configuración básica, el PacketShaper nos permite configurar dos passwords. Uno para "mirar" (look) el estado, reglas, reportes, etc, del PacketShaper, y otro para "tocar" (touch) que además de "mirar" permite configurar el aparato. Como siempre, es conveniente configurar ambos passwords.
En este punto encontré que (increíblemente) el sistema limita el largo del password a 19 caracteres. Todavía no puedo creer como sigue existiendo software que limite el largo de los passwords...

Data rates:
A continuación el software nos permite configurar las velocidades de entrada y salida, ya sea mediante números en bytes o a través de los valores simbólicos "T1","E1","10BT","Ethernet". Si elegimos "Ethernet", PacketShaper descubrirá cuál es la velocidad del link. En cualquier caso, luego el dispositivo nos recomendará valores, los cuales podemos aceptar o cambiar. Creo que lo mejor es utilizar "Ethernet" y a continuación acomodar los valores. Estos valores serán el Inbound y Outbound rate y son los que utilizaremos como ancho de banda máximo "garantizado". En general (dependiendo donde ubiquen el PacketShaper), estos valores son los de nuestra conexión a internet. Si poseemos una conexión de 3Mbps, lo máximo que entrará son 3Mbps, esto es el Inbound o datos entrantes desde internet a nuestra red. El caso del Outbound es el ancho de banda que tenemos de upload. Si poseemos una línea simétrica, el Outbound será igual al Inbound, es decir, 3Mbps.

Packet Shaping:
En el siguiente paso, es posible configurar si deseamos que el dispositivo aplique políticas de clasificación de tráfico o si simplemente deseamos ver el tráfico pasar (útil para monitorear). En mi caso, deseamos aplicar políticas, por lo cual utilizamos la opción "on".
También es posible que PacketShaper descubra aplicaciones y arme un árbol con clases basándose en en el tráfico observado. Esto es muy útil cuando no estamos del todo seguros cuál es el tráfico que existe, cuál filtrar y cuál priorizar. Mi recomendación es activar esta opción y luego agrupar/mover/eliminar las clases de acorde a la configuración que deseemos.

Configuración del horario:
El último paso de esta configuración inicial es configurar la zona horaria y la hora del dispositivo. Para la zona horaria existen strings que las identifican, los cuales pueden observar tecleando "?". En mi caso, la zona horaria es BuenosAires.
Para configurar la hora, debemos colocar un string con el formato yyyymmddhhmmss (es decir, el año con cuatro dígitos, seguido del mes, el día, la hora, y los segundos con sólo dos).

Con esto finalizamos la configuración inicial, y aceptamos salvarla en el almacenamiento. Ahora podrán acceder al dispositivo a través de la interfaz Web o ssh con la IP que configuraron anteriormente, utilizando la conexión de red al port denominado "MGMT".

Como instalar impresoras HP en Slackware 13.1

noreply@blogger.com (emilio) — Sun, 01 May 2011 17:33:23 PDT

En este artículo voy a explicar el procedimiento, extremadamente sencillo, para instalar una impresora HP en un sistema Linux. A pesar de que el título indica que utilicé Slackware 13.1, el tutorial sirve para cualquier otra distribución.

La impresora que utilicé es una multifunción HP Deskjet F4480. Para las impresoras HP se dispone de los drivers libres HPLIP (HP Linux Imaging and Printing). En la mayoría de las distribuciones (como en Slackware 13.1) estos driver vienen incluidos, por lo que no es necesario instalar nada.

Para comenzar se debe conectar la impresora al puerto USB y encenderla. Luego se debe verificar que el servicio cupsd esté en ejecución (es necesario para crear al menos una cola de impresión). Para comprobarlo se puede ejecutar:

bash-4.1$ ps -lA | grep cupsd
4 S     0  2044     1  0  80   0 -  1452 epoll_ ?        00:00:00 cupsd

Si el servicio cupsd no se encuentra en ejecución, es necesario activarlo. En Slackware 13.1 se debe otorgar permiso de ejecución al script /etc/rc.d/rc.cups para que CUPS se ejecute automáticamente al iniciar el sistema. Para permitir la ejecución de CUPS se utiliza el comando:

bash-4.1# chmod +x /etc/rc.d/rc.cups

Y luego iniciamos cupsd:

bash-4.1# /etc/rc.d/rc.cups start
cups: started scheduler.                                   [  OK  ]

Teniendo CUPS en ejecución se procede a instalar el driver HPLIP correspondiente a la impresora, para esto se utiliza:

bash-4.1# hp-setup

Esto inicia un instalador gráfico muy amigable que permite instalar el driver de la impresora en tres simples pasos:

1) Seleccionar el tipo de conexión:

2) Seleccionar el dispositivo detectado:

3) Configurar el dispositivo:

Luego, desde KDE, seleccionamos K > Applications > System > Printing para editar las propiedades de la impresora.

La siguiente vez que iniciemos el sistema, veremos el ícono de HPLIP en la barra de notificaciones:

Feliz día del trabajador!

Compilar fuentes Java online

noreply@blogger.com (emilio) — Tue, 26 Apr 2011 07:40:32 PDT

Pregunta: ¿Qué pasa si necesitamos compilar un fuente Java y no disponemos de un JDK en la workstation donde estamos trabajando?
Respuesta: Buscá en Google.

"En Internet está todo"

Esa fue la frase que solté cuando encontré esta herramienta muy útil, que nos puede sacar de un apuro. Leyendo un libro sobre programación en Java me surgieron dudas y necesité probar un ejemplo rápido. El problema era que no disponía de javac en la máquina donde estaba trabajando, y no tenía ganas de descargar e instalar el JDK.
Buscando en Google encontré este servicio muy útil que nos permite compilar fuentes java: JXXX Compiler Service.

El mismo permite subir archivos fuente y librerías y compilar el código. Si hubo errores durante el proceso de compilación, el servicio devuelve la salida de javac. Lo más interesante que tiene, es que si estamos compilando un applet lo incluirá directamente en la página para probar su funcionamiento.
Aunque el servicio es realmente útil, no lo utilizaría para compilar código propietario ya que estamos enviando nuestro código a terceros y no sabemos que harán con él (además de compilarlo). Pero nos sirve perfectamente para compilar código de prueba y sacarnos de un apuro.

Veamos un ejemplo utilizando el siguiente código:

class A {
}

class B extends A {
}

class C {
}

class test {
public static void main(String[] args) {
  A a = new A();
  B b = new B();
  if (b instanceof A) {
    System.out.println("b is an A");
  }
  else {
    System.out.println("b is NOT an A");
  }
}
}

Si compilamos el código anterior introduciendo un error, obtenemos lo siguiente:

Luego, corregimos el error y podemos descargar el código fuente Java compilado .class:

Ahora podemos descargar y ejecutar el .class:

Espero que les sirva!