De acuerdo a Time synchronization may not succeed when you try to synchronize with a non-Windows NTP server in Windows Server 2003. Para poder configurar el servicio de NTP en Windows server como cliente, se debe hacer el comando:
net time /setsntp:-IP DEL SERVIDOR-,0×8
Saludos!
viernes, 7 de mayo de 2010
jueves, 8 de abril de 2010
Autenticación clientes ldap - Authentication information cannot be recovered
Esta mañana me encontraba configurando un cliente LDAP, la configuración es bastante intuitiva... claro, hasta que uno se encuentra con un desagradable error...
No es posible recuperar la información de autenticación.
O en inglés
Authentication information cannot be recovered
Para solucionar esto hay que configurar nuestro sistema para que no
removiendo de /etc/pam.d/common-password
la instrucción use_authtok
Que es usada por cracklib
Hasta pronto.
No es posible recuperar la información de autenticación.
O en inglés
Authentication information cannot be recovered
Para solucionar esto hay que configurar nuestro sistema para que no
removiendo de /etc/pam.d/common-password
la instrucción use_authtok
Que es usada por cracklib
Hasta pronto.
domingo, 4 de abril de 2010
Muha sobre algunos portales cautivos
Esta semana estaba de paseo. Por supuesto, con los gozos y los rezos vino la necesidad de entrar a Internet.
Tal fue mi sorpresa que en un hotel de gran renombre en las playas de la República Dominicana no hay Internet para los huéspedes. Me parece increíble, sobretodo por la tarifa que mantienen y el tipo de turistas (de todo el mundo).
De acuerdo a Wikipedia:
" Un portal cautivo (o captivo) es un programa o máquina de una red informática que vigila el tráfico HTTP y fuerza a los usuarios a pasar por una página especial si quieren navegar por Internet de forma normal. A veces esto se hace para pedir una autenticación válida, o para informar de las condiciones de uso de un servicio wireless (que es donde más se encuentran). "
Tal fue mi sorpresa que en un hotel de gran renombre en las playas de la República Dominicana no hay Internet para los huéspedes. Me parece increíble, sobretodo por la tarifa que mantienen y el tipo de turistas (de todo el mundo).
De acuerdo a Wikipedia:
" Un portal cautivo (o captivo) es un programa o máquina de una red informática que vigila el tráfico HTTP y fuerza a los usuarios a pasar por una página especial si quieren navegar por Internet de forma normal. A veces esto se hace para pedir una autenticación válida, o para informar de las condiciones de uso de un servicio wireless (que es donde más se encuentran). "
Resulta que en nuestro hotel había uno de estos juguetes y como este tipo de atropellos (y digo atropello, por que me sigue pareciendo increíble que cobren el Internet) me parecen mas una invitación a aprender que otra cosa, me puse en la tarea de investigar un poco como funcionaba.
Resulta que la tecnología es bastante básica y consiste de unas reglas de autenticación que modifican las listas de control de acceso para el uso del enrutador. En este caso, la regla de control de acceso permite a una máquina que ha superado un reto de autenticación (el portal cautivo) navegar libremente en Internet. Ahora bien, la forma de identificar una máquina es muy simple (dirección MAC y dirección IP).
Siempre he pensado que tratar de dar seguridad a una red basándose en direcciones, lo único que brinda es un falso sentimiento de seguridad.
El pequeño programa de GNU macchanger permite cambiar una MAC a una tarjeta de red. El comando ifconfig permite cambiar la dirección IP a una tarjeta de red. Si se es muy perezoso y se esta tratando de impersonar una máquina que se encuentre usando el servicio DHCP, lo mas probable es que ante una nueva solicitud el servidor entregue la misma ip, en este caso y sólo para los débiles de corazón que quieren evitarse el esfuerzo de usar ifconfig, el comando dhclient puede ser muy provechoso.
Y después de un poco de sniffing.... voilá, a navegar por Internet.
Hata pronto!
miércoles, 24 de marzo de 2010
Squid y GOSA
La administración centralizada de cuentas de usuario ha sido una bendición para los administradores de sistemas.
Sin embargo, en ambientes donde no se dispone de un directorio activo ofrecido por Microsoft, surge la duda de que usar.
LDAP es el protocolo por excelencia para implementar un directorio de información de usuarios, y suele ser la principal opción para centralizar la gestión de los mismos.
El funcionamiento de LDAP está más allá del tiempo del cual dispongo para redactar esta entrada. Sin embargo, si alguna vez se encuentran instalando LDAP, pueden darle una mirada a GOSA.
GOSA es una interfaz WEB para controlar un directorio LDAP. Como tal ofrece muchos beneficios, el control de acceso al sistema operativo (Windows usando Samba, Linux usando PAM), el control de Asterisk (usando PostgreSQL), el control de acceso al servidor proxy cache.
Si alguna vez se encuentran desplegando un ambiente de squid + GOSA, puede venir a la mano la inclusión de cadenas de búsqueda del tipo :
(&(objectClass=person)(uid=%s)(objectClass=gosaProxyAccount))
donde van a poder administrar el acceso al cache desde la comodidad de un sistema centralizado de usuarios, como lo es GOSA.
Saludos!
Sin embargo, en ambientes donde no se dispone de un directorio activo ofrecido por Microsoft, surge la duda de que usar.
LDAP es el protocolo por excelencia para implementar un directorio de información de usuarios, y suele ser la principal opción para centralizar la gestión de los mismos.
El funcionamiento de LDAP está más allá del tiempo del cual dispongo para redactar esta entrada. Sin embargo, si alguna vez se encuentran instalando LDAP, pueden darle una mirada a GOSA.
GOSA es una interfaz WEB para controlar un directorio LDAP. Como tal ofrece muchos beneficios, el control de acceso al sistema operativo (Windows usando Samba, Linux usando PAM), el control de Asterisk (usando PostgreSQL), el control de acceso al servidor proxy cache.
Si alguna vez se encuentran desplegando un ambiente de squid + GOSA, puede venir a la mano la inclusión de cadenas de búsqueda del tipo :
(&(objectClass=person)(uid=%s)(objectClass=gosaProxyAccount))
donde van a poder administrar el acceso al cache desde la comodidad de un sistema centralizado de usuarios, como lo es GOSA.
Saludos!
jueves, 18 de marzo de 2010
Cambiar la máscara de creación de directorios home
Configurando un equipo que va a manejar multiples usuarios, he tenido la necesidad de cambiar el comportamiento por defecto (en ubuntu) para la forma en que se crean los nuevos usuarios. Ubuntu crea los directorios de usuario en /home y con una máscara 0755. Sin embargo, para mi caso es necesario utilizar la máscara 0700.
El archivo de configuración ubicado en /etc/adduser.conf permite modificar estas opciones. Haciendo la variable DIR_MODE=0700, los nuevos usuarios crearán su carpeta con dichos privilegios.
Otra de las opciones interesantes es modificar el comportamiento adduser para que no cree nuevos grupos cada vez que se crea un usuario, en mi caso (y el caso más común) los usuarios pertenecerán al grupo con GID 100 (users). Primero hay que hacer la variable "USERGROUPS=no", finalmente verificar que "USERS_GID=100" hace referencia al grupo deseado.
Hasta pronto!
El archivo de configuración ubicado en /etc/adduser.conf permite modificar estas opciones. Haciendo la variable DIR_MODE=0700, los nuevos usuarios crearán su carpeta con dichos privilegios.
Otra de las opciones interesantes es modificar el comportamiento adduser para que no cree nuevos grupos cada vez que se crea un usuario, en mi caso (y el caso más común) los usuarios pertenecerán al grupo con GID 100 (users). Primero hay que hacer la variable "USERGROUPS=no", finalmente verificar que "USERS_GID=100" hace referencia al grupo deseado.
Hasta pronto!
miércoles, 17 de marzo de 2010
KVM y multiples interfaces TUN/TAP
He estado ensayando el hipervisor KVM, una de las razones que me llevaron a probar este hipervisor, es que aprovecha las bondades de virtualización que ofrecen los procesadores modernos como mi nuevo Intel I7.
Hasta ahora ha demotrado tener un buen desempeño, y hay que destacar las innumerables opciones de administración, como la capacidad de asignar un número fijo de procesadores, el uso de imágenes qcow, etc.
Un problema con el que tuve que lidiar, es el uso de interfaces virtuales que den acceso directo a la red donde está conectada la tarjeta del equipo anfitrión.
Resulta que QEMU ofrece muchas opciones para el trabajo en red, el modo usuario (parecido a las interfaces NAT que ofrecen otros productos), el uso de dispositivos TUN/TAP, y una alternativa muy interesante llamada VDE.
Hay mucha documentación en la red sobre como hacer correr estas opciones, y me parece innecesario volver a copiar lo que otros han escrito (y de donde he aprendido).
Lo que quiero registrar es como configurar diferentes interfaces en el sistema invitado (guest) y ubicar dichas interfaces en diferentes puentes (bridges).
Bueno, lo primero que hay que hacer es configurar el puente de red.
El comando `brctl`, permite crear este tipo de dispositivos. Basta hacer algo así como:
# brctl addbr dmz
# brctl addbr internal
Hemos creado dos puentes para conectar nuestros dispositivos TUN/TAP. Ahora hay que añadir la interfaz física (eth0, eth1) a cada uno de los puentes.
# brctl addif dmz eth0
# brctl addif internal eth1
Aquí viene la parte interesante, para poder configurar KVM con un dispositivo TUN es necesario añadir la siguiente línea a la llamada a qemu.
Ahora bien, la primera definición a -net crea una interfaz virtual con los drivers de paravirtualización virtio (si esto no suena muy facil de digerir, digamos que mejoran el desempeño y el acceso desde la máquina anfitrión a los dispositivos de entrada y salida), definir la MAC de manera estática es muy importante, sobretodo si se va a correr equipos Linux donde cada nueva MAC incrementa el número de la interfaz (uno puede terminar escribiendo cosas locas como ifconfig eth45), para crear la MAC se puede usar el script definido en alguna página de RED HAT, aquí va:
#!/usr/bin/python
# macgen.py script to generate a MAC address for Red Hat Virtualization guests
#
import random
#
def randomMAC():
mac = [ 0x00, 0x16, 0x3e,
random.randint(0x00, 0x7f),
random.randint(0x00, 0xff),
random.randint(0x00, 0xff) ]
return ':'.join(map(lambda x: "%02x" % x, mac))
#
print randomMAC()
La segunda línea pide a QEmu crear un dispositivo TAP y pasarlo como el argumento $1 al script de inicialización de la interfaz. El argumento ifname además define el nombre de dicha interfaz. Aquí va una copia del script.
#!/bin/bash
set -x
switch=dmz
if [ -n "$1" ] ; then
ip link set $1 up
sleep 0.5s
brctl addif $switch $1
exit 0
else
echo "Error: no interface specified"
fi
Con esto podemos tener una máquina invitada corriendo su dispositivo de red como si estuviera conectada a la misma red del dispositivo anfitrión.
Para añadir una segunda interfaz, uno podría estar tentado a hacer algo así como:
Pero de este modo, las tarjetas quedan ubicadas en la misma interfaz, y aunque QEmu crea el segundo TAP parece que no lo conecta con la segunda interfaz definida. La solución es muy sencilla (aunque me llevó mucho tiempo encontrarla), se debe definir cada interfaz en una vlan diferente, como aparece a continuación.
Hasta pronto!
Hasta ahora ha demotrado tener un buen desempeño, y hay que destacar las innumerables opciones de administración, como la capacidad de asignar un número fijo de procesadores, el uso de imágenes qcow, etc.
Un problema con el que tuve que lidiar, es el uso de interfaces virtuales que den acceso directo a la red donde está conectada la tarjeta del equipo anfitrión.
Resulta que QEMU ofrece muchas opciones para el trabajo en red, el modo usuario (parecido a las interfaces NAT que ofrecen otros productos), el uso de dispositivos TUN/TAP, y una alternativa muy interesante llamada VDE.
Hay mucha documentación en la red sobre como hacer correr estas opciones, y me parece innecesario volver a copiar lo que otros han escrito (y de donde he aprendido).
Lo que quiero registrar es como configurar diferentes interfaces en el sistema invitado (guest) y ubicar dichas interfaces en diferentes puentes (bridges).
Bueno, lo primero que hay que hacer es configurar el puente de red.
El comando `brctl`, permite crear este tipo de dispositivos. Basta hacer algo así como:
# brctl addbr dmz
# brctl addbr internal
Hemos creado dos puentes para conectar nuestros dispositivos TUN/TAP. Ahora hay que añadir la interfaz física (eth0, eth1) a cada uno de los puentes.
# brctl addif dmz eth0
# brctl addif internal eth1
Aquí viene la parte interesante, para poder configurar KVM con un dispositivo TUN es necesario añadir la siguiente línea a la llamada a qemu.
-net nic,model=virtio,macaddr=00:16:3e:11:10:5b -net tap,ifname=internal0,script=/home/virtual/ltsp/ifup.internal
Ahora bien, la primera definición a -net crea una interfaz virtual con los drivers de paravirtualización virtio (si esto no suena muy facil de digerir, digamos que mejoran el desempeño y el acceso desde la máquina anfitrión a los dispositivos de entrada y salida), definir la MAC de manera estática es muy importante, sobretodo si se va a correr equipos Linux donde cada nueva MAC incrementa el número de la interfaz (uno puede terminar escribiendo cosas locas como ifconfig eth45), para crear la MAC se puede usar el script definido en alguna página de RED HAT, aquí va:
#!/usr/bin/python
# macgen.py script to generate a MAC address for Red Hat Virtualization guests
#
import random
#
def randomMAC():
mac = [ 0x00, 0x16, 0x3e,
random.randint(0x00, 0x7f),
random.randint(0x00, 0xff),
random.randint(0x00, 0xff) ]
return ':'.join(map(lambda x: "%02x" % x, mac))
#
print randomMAC()
La segunda línea pide a QEmu crear un dispositivo TAP y pasarlo como el argumento $1 al script de inicialización de la interfaz. El argumento ifname además define el nombre de dicha interfaz. Aquí va una copia del script.
#!/bin/bash
set -x
switch=dmz
if [ -n "$1" ] ; then
ip link set $1 up
sleep 0.5s
brctl addif $switch $1
exit 0
else
echo "Error: no interface specified"
fi
Con esto podemos tener una máquina invitada corriendo su dispositivo de red como si estuviera conectada a la misma red del dispositivo anfitrión.
Para añadir una segunda interfaz, uno podría estar tentado a hacer algo así como:
-net nic,model=virtio,macaddr=00:16:3e:11:10:5b -net tap,ifname=internal0,script=/home/virtual/ltsp/ifup.internal -net nic,model=virtio,macaddr=00:16:3e:11:10:5c -net tap,ifname=dmz0,script=/home/virtual/ltsp/ifup.dmz
Pero de este modo, las tarjetas quedan ubicadas en la misma interfaz, y aunque QEmu crea el segundo TAP parece que no lo conecta con la segunda interfaz definida. La solución es muy sencilla (aunque me llevó mucho tiempo encontrarla), se debe definir cada interfaz en una vlan diferente, como aparece a continuación.
-net nic,vlan=1,model=virtio,macaddr=00:16:3e:11:10:5b -net tap,vlan=1,ifname=internal0,script=/home/virtual/ltsp/ifup.internal -net nic,model=virtio,macaddr=00:16:3e:11:10:5c -net tap,ifname=dmz0,script=/home/virtual/ltsp/ifup.dmz
Hasta pronto!
R y los intervalos de confianza III
El ejercicio del colesterol trae mas preguntas que respuestas. Por ejemplo, como comparar las dos poblaciones?. Una buena alternativa es encontrar el intervalo de confianza para la diferencia de dos medias (x1-x2) con varianzas conocidas.
Vamos a ver como hacerlo en R, nuevamente no voy a expresar los contenidos matemáticos (aunque pueden ser extraídos directamente del código de R).
> cidiffmeanvarknown <- function(mmean1,mmean2,sd1,sd2,n1,n2,alfa=0.05) + c(mmean1-mmean2-qnorm(1-alfa/2)*sqrt((sd1*sd1/n1)+(sd2*sd2/n2)),mmean1-mmean2+qnorm(1-alfa/2)*sqrt((sd1*sd1/n1)+(sd2*sd2/n2)))
Si aplicamos esto a nuestro ejemplo del colesterol, tenemos el siguiente resultado.
> cidifffcidiffmeanvarknown(170.81,181.08,30.55,30.79,96,85,0.10)
[1] -17.785222 -2.754778
Hemos considerado que los hombres son x1, como podemos apreciar el intervalo no incluye al cero, por lo tanto podemos decir que tenemos una confianza del 90% de que el nivel de colesterol en los hombres es inferior que el nivel de colesterol de las mujeres por una cantidad que oscila entre 2.75 mg/dl y 17.78 mg/dl.
Hasta pronto!
Vamos a ver como hacerlo en R, nuevamente no voy a expresar los contenidos matemáticos (aunque pueden ser extraídos directamente del código de R).
> cidiffmeanvarknown <- function(mmean1,mmean2,sd1,sd2,n1,n2,alfa=0.05) + c(mmean1-mmean2-qnorm(1-alfa/2)*sqrt((sd1*sd1/n1)+(sd2*sd2/n2)),mmean1-mmean2+qnorm(1-alfa/2)*sqrt((sd1*sd1/n1)+(sd2*sd2/n2)))
Si aplicamos esto a nuestro ejemplo del colesterol, tenemos el siguiente resultado.
> cidifffcidiffmeanvarknown(170.81,181.08,30.55,30.79,96,85,0.10)
[1] -17.785222 -2.754778
Hemos considerado que los hombres son x1, como podemos apreciar el intervalo no incluye al cero, por lo tanto podemos decir que tenemos una confianza del 90% de que el nivel de colesterol en los hombres es inferior que el nivel de colesterol de las mujeres por una cantidad que oscila entre 2.75 mg/dl y 17.78 mg/dl.
Hasta pronto!
Suscribirse a:
Entradas (Atom)