Les comento que hace aproximadamente 15 se publico una vulnerabilidad en la mayoría de implementaciones de servidores DNS incluyendo ISC bind, esta vulnerabilidad permite el envenenamiento del cache (Cache poisoning) del servidor DNS.

Explotando esta vulnerabilidad un atacante podría envenenar el cache para edirigir los navegadores a sitios web maliciosos.

Si aun no han actualizado/parchado su servidor DNS es importante hacer una rueba para comprobarlo.

Supongamos que estamos logeados en nuestro servidor DNS, usaremos el programa dig para hacer la prueba:

root@ns1:~# dig +short @127.0.0.1 porttest.dns-oarc.net TXT
porttest.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
"203.124.85.41 is POOR: 26 queries in 2.6 seconds from 1 ports with std dev 0″

El resultado nos muestra: 203.124.85.41 is POOR

203.124.85.41 es la dirección IP externa del servidor DNS y nos dice que somos vulneables al cache poisoning.

Para actualizar servidores basados en Debian como Ubuntu, primero hay que bajar la lista de paquetes con apt-get update.

root@ns1:~# apt-get update

Despues debemos de actualizar el paquete bind9

root@ns1:~# apt-get install bind9

Despues de actualizar el paquete debemos de reiniciar nuestro servidor DNS, pero antes hacemos una revisión sintactica del archivo named.conf para verificar que no haya algo mal.

root@ns1:~# named-checkconf

Si el comando anterior no regresa mensaje alguno significa que el archivo esta bien.

Ahora si reiniciamos nuestro servidor DNS, así:

root@ns1:~# /etc/init.d/bind9 restart

Y por último hacemos de nuevo la prueba:

root@ns1:~# dig +short @127.0.0.1 porttest.dns-oarc.net TXT
porttest.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
"203.124.85.41 is GREAT: 26 queries in 2.1 seconds from 26 ports with std dev 20875″

Ahora ya nos dice: 203.124.85.41 is GREAT, lo cual significa que nuestro servidor ya no es vulnerable y no responde utilizando un puerto fijo.

Es sumamente importante actualizar sus servidores DNS para evitar esta vulnerabilidad ya que ya se hizo publico el exploit para aprovechar la vulnerabilidad y los ataques ya comenzaron a hacerse notar a partir de hoy.

El reporte del CERT:

Múltiples implementaciones de DNS vulnerables a ataque de cache poisoning:
http://www.cert.org.mx/boletin/?vulne=5631

Debian:
http://www.debian.org/security/2008/dsa-1603

Muchas veces actualizo el kernel de servidores linux que están en sitios remotos, todo lo hago por medio de una sesión ssh, el proceso de la actualización depende de la distribución que use, muchas son por medio de las fuentes originales del kernel linux, otras usando las fuentes que provee Gentoo en el paquete gentoo-sources, paquetes dpkg, rpm, etc. Cualquiera que sea el caso algunas veces no se estará seguro si el nuevo kernel instalado arrancara correctamente o no.

Aqui el problema viene cuando pones tu bootloader para que de manera predeterminada arranque el nuevo kernel instalado, y si por alguna razón este kernel da algún error de kernel panic, ya sea porque no se incluyo el sistema de archivos dentro de el kernel, no se creo una imagen initrd, o se pusieron mal las entradas en el archivo de configuracion de el boot loader. Si esto llegara a pasar por, default el sistema se quedará ahí con el mensaje de kernel panic y no se podrá hacer nada a menos que alguien presione el boton de reiniciar o lo apague y lo vuelva a prender, y para que tengamos de nuevo el sistema funcionando tendra que elegir el kernel correcto dentro de el menu de nuestro boot loader (ya sea grub o lilo).

Esto es un gran problema porque muchas de las veces la tarea de mantenimiento es realizada en horas de la noche donde no se podra afectar la produccion  o el funcionamiento de alguna operación, regularmente a estas horas no hay quien pueda ir hasta el servidor, reiniciar la maquina y elegir otro kernel de el menu de el boot loader. La buena noticia es que grub puede hacer todo esto automatico.

continue reading "GRUB Reinicio automático después de un kernel panic."

Para ver los recursos compartidos (shares) en un servidor NFS remoto se puede hacer con el comando:

$ /usr/sbin/showmount -a 192.168.0.2
All mount points on 192.168.0.2:
jamedina.dominio.com.mx:/home/jmedina
jamedina.dominio.com.mx:/home/public/Linux/SlackwareEspero que este tip les sirva de algo.

Saludos.