miércoles, 31 de diciembre de 2008

Objetivo 2009: Gestión de Tiempo para Administradores de Sistemas

Faltan pocas horas para que el 2008 acabe. Aunque este año parece ser malo por tanta crisis para mi ha sido excepcional, tanto en lo profesional como en lo personal. Casarse, cambiar el domicilio y seguir ejerciendo como sysadmin a tope me ha llevado a diciembre con la sensación de haber sido "desbordado". ¡Mis amigos seguro que lo habrán notado por el poco tiempo que les dedico!

Los administradores de sistemas somos informáticos diferentes al resto. Habitualmente mis compañeros lidian con proyectos. Podríamos definir un proyecto como un objetivo a realizar que implica la ejecutar diferentes tareas y probablemente varias personas, pero que además (muy importante) tiene fecha inicio y fecha fin (al menos estimadas, porque lo que es en Informática...)

Los sysadmin también tenemos proyectos, aunque muchos colegas duden de ello. "Instalación de un servidor MySQL" puede llegar a tener los mismos rasgos que cualquier proyecto, sólo hay que buscar un entorno complejo para que así sea.

Nuestros proyectos además de todos los problemas que ellos sólos ya traen tienen además un enémigo que impide muchas veces su realización, según el sitio o momento del día son conocidas como "tareas del día a día", "mantenimiento/peticiones de sistemas" o simplemente algún compañero que nos llama o aparece por tu mesa para preguntarte si te suena porque falla cualquier cosa.

Por culpa de ese "día a día" el cambio de contexto (es decir, depositar en nuestra memoria estable la información suficiente para volver a recuperar una tarea que dejas en estado de espera mientras inicias una nueva) es constante. En una comida con mis compañeros, se quejaban de que al participar en 2-3 proyectos al mismo tiempo tenían que cambiar de contexto y que era muy duro. ¡Yo les repliqué que en Sistemas se cambia de contexto cada hora! (A continuación la cosa degeneró porque según ellos las tareas de sistemas suelen ser más sencillas... no comentaré mi respuesta... aunque acabé diciendo que los programadores de java no tienen ni idea!).

Bueno, para concluir lo que me ha pasado a mi este año es que entre proyectos y listas de tareas que tenían que estar listas para ayer y las del mañana que te asustan te acostumbras a ser "bombero"; es decir, estás en tu "jaula" esperando a saber dónde es el siguiente fuego que hay que apagar y pierdes la "visión de conjunto". Esto provoca aún mayores problemas porque a veces al no tener una planificación acabarás metiendo la pata o simplemente duplicando trabajo.

Como esta sensación me ha empezado a pesar mucho este diciembre me he fijado nuevo objetivo. Aprender a gestionar mi tiempo. He empezado a leer el que me parece un gran libro "Time Management for System Administrators". Me he extendido un montón así que os dejo sus premisas para empezar una buena gestión:

  • Mantener toda la información acerca de la gestión en un único sitio (outlooks, gmails, kontacts, wikis, emails, ... al final pierdes demasiado tiempo buscando las cosas y no los vas a usar todos, "usa sólo lo que vayas a usar").
  • Usa el cerebro para tu tarea actual, usa un almacenamiento persistente para el resto (en Denodo nos dan una libreta para tener siempre con nosotros, es una buenísima costumbre).
  • Crea rutinas para las cosas que haces habitualmente (los viernes hago el backup y siempre en el mismo orden y los mismos pasos)
  • Desarrolla buenos habitos ("copia cualquier fichero de configuración que vayas a tocar y añade como extensión la fecha del cambio o aún mejor usa un sistema de versiones") y mantras ("los viernes no se toca nada"). 
  • Evita los cambios de contexto (a los sysadmin nos encanta ser el septimo de caballería informático para nuestros compañeros, amigos, familiares y hasta vecinos; pero, es malo la cabecita no lo aguanta).
  • Mejora tu vida privada aplicando las mismas técnicas (esto aún no lo acabo de ver, el libro está escrito por un sysadmin a la vieja usanza y ya sabéis los tópicos acerca de los sysadmin, nos cuesta mucho relacionarnos adecuadamente tanto dentro como fuera de la empresa...)
Seguiré contando lo que leo!

miércoles, 27 de agosto de 2008

HTTPS vulnerable por ataques "Surf jacking"

Original: http://blogs.techrepublic.com.com/networking/?p=634

Un buen consejo si se va a usar https es no usar el mismo navegador para consultar sitios web normales con http. En redes donde un posible atacante pueda interceptar la conexión es posible el ataque "surf jacking". Consiste en:

  • Navegador de la victima abre sesión https con sitio web (pongamos un banco para hacerlo interesante).
  • Navegador de la victima abre a continuación una página web normal (hace un GET con HTTP).
  • El atacante observa los paquetes anteriores y falsifica la respuesta de un sitio normal. A la segunda petición (un GET HTTP) el atacante crea un paquete de respuesta con código 302 que redirija a cualquier URL del banco y se lo manda a la víctima.
  • El navegador de la victima al recibir el redirect hace un nuevo GET con la URL que ha introducido el atacante. La clave es que en ese segundo GET se incluyen las cookies de sesión no cifradas de la conexión con el sitio HTTPS (es decir, el banco). Si las cookies tienen información privilegiada el ataque ha triunfado.

Las soluciones son dos:
  • Si desconfía de los desarrolladores web, sea paranóico y cuando abra una sesión https no reutilice el navegador web para otras cosas (nada de abrir pestañas o nuevas ventanas). Arranque un segundo navegador para navegar por otros sitios.
  • El desarrollador web debe usar cookies con flag secure activado (un navegador nunca las debería transmitir por un protocolo distinto a https).

El hecho de usar estas cookies es una buena práctica que los desarrolladores deberían usar; pero antes de mentar a la madre de los que no las usan se ha de saber que para sitios como google es muy difícil hacerlo. Al compartir la sesión https entre múltiples dominios (gmail, googleloquesea) es muy difícil usarlas y escalar a millones de usuarios. ¿Será esa la razón por la que existen quejas de gente que ha perdido sus cuentas en gmail?

martes, 26 de agosto de 2008

Como solucionar vulnerabilidad Kaminsky en Bind

Original: http://www.howtoforge.com/how-to-patch-bind-to-avoid-cache-poisoning-fedora-centos.

Una de las vulnerabilidades más graves de Internet de los últimos tiempos ha sido la que ha afectado a todos los servidores DNS. El problema consistía en que conociendo alguna consulta del servidor DNS se podían enviar respuestas falsificadas ya que tanto el número de puerto como el id de las siguientes consultas se hacían predecibles. Una vez que alguna de esas respuestas falsificadas entraba en el servidor se corrompía su cache con registros introducidos por el atacante.

La actualización consiste simplemente en realizar yum update bind. En el enlace recomiendan además activar dnssec. Ningún problema con Centos 5 y 4; aunque en este último caso la opción dnssec-enable on no es aplicable (bind 9.2).

Un detalle muy curioso es que si nuestro DNS está detrás de un NAT el parche no resuelve mucho debido a que las implementaciones habituales de NAT (por ejemplo, iptables) no sólo traducen las ips sino que también los puertos (alguno de los libres en la ip pública). Esto hace que vuelva a ser predecible. Habrá que pensar que los servidores de DNS también se merecen su ip pública.

Se pueden testear los servidores DNS en las siguientes direcciones:

Bug en perl (redhat)

Original: http://blog.vipul.net/2008/08/24/redhat-perl-what-a-tragedy/

Un fallo en los paquetes perl Red Hat 5 (Centos, Fedora) hace que la llamada para crear objetos sea muy costosa. Un código como:

#!/usr/bin/perl
use overload q(<) => sub {};
my %h;
for (my $i=0; $i<50000; $i++) {
$h{$i} = bless [ ] => 'main';
print STDERR '.' if $i % 1000 == 0;
}


Ejecutado en una de nuestras máquinas Centos 4 tarda 0.2 s, en las nuevas Centos 5 pasa a 12-14 s.