Lo primero que hice fue configurar los DNS, evidentemente, ya que los dominios de Directorio Activo de Windows 2000 en adelante funcionan bajo DNS. Lo configuré en Servicios de red > DNS y nombre de host del siguiente modo:

Nombre de host: nodo2
Nombre de dominio: guranet.local
Servidor de nombres 1: 192.168.0.10
Dominio de búsqueda: guranet.local

Como quería ver qué me ofrecía YaST en lo que a configuración se refiere, lo hice todo desde él. Hacía mucho que no lo utilizaba y he comprobado que los asistentes han mejorado notablemente.

Despues de utilizar el comando host para comprobar que la resolución de la zona era satisfactoria utilicé el asistente Servicios de red > Pertenencia a dominio de Windows.

Una vez se abra veremos que por defecto tiene un grupo de trabajo llamado TUX-NET (Que originales).

Escribiremos como nombre de dominio guranet.local y marcaremos dos casillas:

• Usar también la información SMB para la autentificación de Linux
• Crear directorio personal al iniciar sesión

La otra casilla, Autenticación sin conexión doy por hecho que cacheará los usuarios y contraseñas para poder iniciar sesión aunque el DC no esté disponible. Por mi parte lo desmarco.

Por último pinchamos en Finalizar. Tras hacer unas comprobaciones nos dice que esta máquina no pertenece al dominio, y si deseamos unirla al mismo. Le responderemos que Si, obviamente.

En este momento aparecerá la ventana donde introduciremos el usuario y contraseña de un usuario con permisos para añadir máquinas al dominio. En mi caso no tengo ninguna delegación, por lo que usaré la cuenta de Administrador. Tras unos segundos recibiremos el mensaje de que Se ha accesdido correctamente al dominio GURANET.

Ahora nos advertirá de que dos paquetes (samba-winbind y krb5-client) deberán ser instalados (Si nos lo están ya). Pinchamos en Continuar y introducimos los CDs que nos solicite, y a esperar se ha dicho.

Tras esperar un buen rato, podemos comprobar que ya ha creado una cuenta de equipo en el contenedor Computers del DC, pero aún no ha hecho la actualización dinámica en el DNS, y parece que no tiene intención de hacerlo.

Reiniciaremos la máquina. Con esto nos aseguramos de que todos los servicios necesarios sean reiniciados. Una vez el sistema arranque deberíamos poder iniciar sesión en SUSE con cualquier usuario del dominio.

Como comprobaréis, ahora al más puro estilo Windows, GDM en este caso, proporciona un inicio de sesión en local o en el dominio GURANET. Yo he iniciado sesión con un usuario que he creado anteriormeente en el dominio. Al iniciar sesión en Gnome aparece un error/warning algo feo informándonos de que se crearon determinados directorios y ficheros de configuración. Lo ingnoraremos. Una vez carge el escritorio abrimos un terminal, los logueamos como root y revisaremos un par de cosas.

# su -
# cd /home
# ls -la

Como podemos comprobar, el directorio personal de los usuarios locales lo crea directamente en /home, pero para los directorios personales (Léase perfiles) de los usuarios del dominio crea un directorio con el nombre del dominio NetBIOS (Al promocionar el DC podemos dejarlo por defecto o establecer uno).

# cd GURANET
# ls -la

En mi caso aparece el directorio linux que tiene como propietario a GURANET\linux y como grupo a GURANET\domain users.

Para establecer permisos, como siempre, o UGO o ACLs. Un ejemplo de permisos con los usuarios del dominio:

# cd /home/GURANET
# mkdir prueba
# chown “GURANET\administrator” prueba

Ya está. Para ver la lista de usuarios completa (Puede servir para comporbar id de usuario y de grupo, por ejemplo) podéis utilizar la siguiente orden:

# getent passwd

Ya visto el tema de los permsisos a nivel de sistema de ficheros, podemos comprobar que la política de contraseñas funciona correctamente. Por ejemplo, obligar al usuario a cambiar la contraseña en el próximo inicio de sesión. Que el usuario cumpla los requisitos de complejidad de la contraseña, el número de contraseñas recordadas (No volver a poner la misma contraseña que teníamos antes), etc. En lo referente a la política de bloqueo de cuenta tampoco se queda atrás y funciona a la perfección. No se me ocurre nada más que probar ahora mismo, y tampoco tengo muchas ganas, la verdad.

Queda un tema pendiente: Las actualizaciones dinámicas. Las actualizaciones dinámicas del DNS tienen un RFC, el RFC2136, y existe una utilidad en linux para hacer dicha actualización. Veamos…

# nsupdate
> update add nodo2.guranet.local 86400 A 192.168.0.5
> send

Es probable que a la primera no os funcione, ni a la segunda ni al tercer intento (Con un precioso REFUSED como respuesta). El problema está en las actualizaciones seguras. Por defecto, cuando una zona está integrada en Active Directory las actualizaciones son seguras en su totalidad, pero podemos degradar la seguridad temporalmente para probar, configurando la zona para que acepte actualizaciones dinámicas seguras y no seguras (Esto es una cagada, porque cualquiera podría manipular los registros DNS de la zona, con lo que ello implica). No se me ocurre a voz de pronto como solucionarlo, porque aunque hay mucha información acerca de como hacerlo con BIND generando claves y demás, no he encontrado nada para el DNS de Windows. Pero bueno, ahí os queda eso, para que penséis algo al respecto.

Hace unos meses, cuando vi el proyecto OpenSuSE, decidí probar Gentoo. Aquí tienes 2 ramas, la estable y la inestable. Yo uso la estable y tengo paquetes de la inestable, como por ejemplo en KDE, interfaces gráficas, etc… También cabe destacar los GLSA (Gentoo Linux Security Advisories), que simplemente, si hay una versión vulnerable la actualiza a una superior. Es lo único que no me gusta del todo si la usase como servidor, ya que estoy acostumbrado a Debian Sarge y su política de actualizaciones.

Y a lo que iba, OpenBSD. OpenBSD no distribuye ISO de sus CD’’s, así que tendremos que hacerla nosotros mismos. Una vez instalada tenemos una OpenBSD 3.8-RELEASE, que es la que tiene los CD’’s. Pero eso no es una rama, no se actualiza, se liberó y punto. Éste es el momento en el que tenemos que elegir que rama escoger, si la -STABLE o la -CURRENT. Si queremos un sistema en producción, claramente actualizaremos a -STABLE.

Los fallos de seguridad del sistema base los tenéis aquí y los de paquetes de la rama STABLE aquí.

Como veis hay 3 fallos de seguridad. Hoy he encontrado la forma más cómoda (en mi opinión) de actualizar el sistema base.

Actualizamos las fuentes del sistema al patch brach OPENBSD_3_8:

*default host=rt.fm
*default base=/var
*default prefix=/usr
*default release=cvs
*default delete compress

OpenBSD-src tag=OPENBSD_3_8

Eso lo guardamos en, por ejemplo, ~/supfile.

Ahora montamos el CD y extraemos el paquete src.tar.gz a /usr/src y sys.tar.gz a /usr/src/sys. Una vez descomprimido ejecutaremos:

cvsup -g -L 2 ~/supfile

Nota: La ooción “-L 2″ es el nivel de debug del proceso.

Cuando termine tendremos un /usr/src actualizado.

Aún no hemos actualizado a STABLE, así que con todo ya preparado seguimos la guía. Compilamos nuevo kernel, lo cambiamos, reiniciamos con el nuevo y luego recompilamos binarios.

Nota: A la hora de compilar es imprescindible tener instalado el paquete misc.tgz que viene en el CD. Si no es así, lo descomprimís en el raíz.

Ahora tenemos la OpenBSD 3.8-STABLE. Revisamos que los paquetes estén en su última versión disponible y lo ponemos a funcionar de lo que nos dé la gana, supongamos que de cortafuegos.

Pero claro, no existe nada perfecto, y como hace unos días, un bug en la función scp de SSH. Ahora nos planteamos como actualizar…

• Ejecutar de nuevo cvsup -g -L 2 ~/supfile y recompilar todos los binarios del sistema y si es el kernel, el kernel
• O la otra opción, que como no hay muchos fallos, no será caótico. La alternativa es bajarse los .patch y aplicarlos

Yo he optado por la segunda opción:

wget patch
less 005_ssh.patch

(salida)
Apply by doing:
cd /usr/src
patch -p0 > 005_ssh.patch

And then rebuild and install ssh:
cd usr.bin/ssh
make obj
make
make install

Pues esas son las instrucciones, bien claras.

La primera opción hubiese sido una muñonada, recompilar todo el sistema a lo tonto, para que por ejemplo luego casque algo. De este modo lo único que tenemos que hacer es estar pendientes de los fallos de seguridad que aparecen, parchear el código fuente y fijarnos a qué afecta la vulnerabilidad, si a algún binario del sistema base o solo al kernel, y compilar.

Una vez recompilado en nuestro ejemplo SSH, mataremos sshd y volveremos a ejecutarlo. Si estamos en remoto lo más probable es que perdamos la conexión con el host. Se me ocurre una idea, que es programar un trabajo que se ejecute en 2 minutos, por ejemplo.

Otra cosa que me he pasado por alto es que Apache y Bien9, por ejemplo, forman parte del sistema base, es decir, si sale una vulnerabilidad tendremos que recompilarlo como hicimos ahora con ssh. Las versiones que trae OpenBSD son viejas, pero eso no es malo si cumple con tus necesidades, ya que al ser más viejas están más auditadas (Recordad que el sistema base es auditado, pero los paquetes es cosa del desarrollador no del equipo de OpenBSD). ¿Qué quiero decir con esto? Que mejor usar en lo posible lo que el sistema base nos brinda, si no es posible, los paquetes, y sino, los ports. También podemos recurrir al código fuente oficial del software en cuestión, pero bueno.

Si usáis ports, al igual que lo demás, tendréis que actualizarlos, para ello basta con añadir la linea:

OpenBSD-ports tag=OPENBSD_3_8

Entonces creamos el directorio /usr/ports (Porque no estoy seguro de si lo crea) y actualizamos.

Todo este código fuente y post ocupa espacio, así que una buena idea sería volcarlo mediante NFS en otra máquina con más capacidad de almacenamiento.

Con esto doy por concluido, cuando tenga un rato lo pondré en mi web.

Agur

Otra cosa que interesante que he leído en éste blog es el nuevo sistema de gestión de ports de FreeBSD. podéis leerlo entero aquí. Hasta tenemos un script para automatizar todo

Agur