En marzo del 2007 estaba yo en un limbo laboral. Estaba recién vuelto de un viaje infructuoso por Europa, en el que no había conseguido trabajo y me había gastado todos los ahorros salvo USD200, y terminando un laburo horrible con un WordPress. Había alcanzado a volver a ahorrar unos mangos pero estaba de nuevo en un depto y esa guita iba a desaparecer rápidamente si no conseguía algo estable. Y aún desesperado como pude haber estado, tenía una cosa muy clara: quería entrar a laburar en Except.
Los motivos eran múltiples: muchos amigos míos ya laburaban en ella, sabía que la gente que laburaba allí no estaba muy estresada, que eran flexibles en los horarios y en la vestimenta (cuenta la leyenda que uno de los jefes alguna vez fue a visitar a un cliente en ojotas), se trabajaba en Software Libre, eran responsables con sus empleados, sus clientes y sus proveedores y muchos detalles menores que con suerte iré contando en este post.
Recuerdo que la entrevista fue por IRC, me la hizo John en unos pocos minutos. Recuerdo el 28 de Marzo que fui por primera vez a trabajar, a pesar que mi legajo decía el 1 de Abril; realmente estaba ansioso. Ese día y toda esa semana el Javi Mansilla estuvo contandome de cómo se movía la empresa, mientras Perrito me pasaba la posta de SysAdmin. No recuerdo cuál fue mi primer tarea, pero estoy seguro que la hice con toda el alma puesta en ella.
Muchas cosas pasaron dentro de esa empresa, algunas buenas, otras malas. Recuerdo la época en la que hacía una especie de chiste de que era el janitor de la misma, pues me tocaban un montón de laburos no técnicos como colgar percheros, cambiar cueritos de canillas, perseguir carpinteros y otros detalles.
Recuerdo que mi primer quilombo grande fue cuando quisimos cambiar el hardware del servidor, no funcionó de una, y luego el RAID no quiso andar. Estuve un par de días restaurando los datos a mano. Luego de un segundo intento el hw fallaba misteriosamente.
Recuerdo mi primer laburo para afuera, una empresa a la que se le había caído un servidor RedHat del año del ñaupa y el departamente de IT estaba en Buenos Aires. Recuerdo los viajes a Agua de Oro para ajustar detalles con un servidor en la cooperativa. También trabjar remotamente contra otros servers en sendas cooperativas en Cañada Rosquín y Carlos Pellegrini, Santa Fe.
Ufff, sanitizar el LDAP, poner scripts de backup que funcionaran, instalar varios puestos de trabajo nuevos, pues la empresa crecía rápido, hacer upgrades masivos de release de Ubuntu, sanitizar la configuración de Apache, renegar con Cups y Ubuntu, y tantas, tantas otras tareas mínimas.
Recuerdo la crudeza del invierno en esta oficina nueva que nos obligó a usar mantas de polar y guantes; a comprar leña para el hogar, pues lo único que había para calentarnos era un calefactorcito diminuto en uno de los pasillos y una estufita de cuarzo; convertirme en Jesús del Fuego por esto mismo. Recuerdo la dureza del verano, todos laburando en lompas cortos y sentados en la punta de la silla; la muerte de dos ventiladores.
Recuerdo los comidas comunitarias, en particular la lasagna de Perrito, los ñoquis para su cumple, unos cuantos asados hechos por mí y por él. Recuerdo el día que llegaron los escritorios nuevos, ergonómicos y con alzada para monitor a medida, para Laura y para mí. Recuerdo los PyWeeks de Corp y Ventus Virginis, y hasta el último, en el que al final no producimos nada. PyCamp, una fantástica iniciativa de Except que llevó 24 geeks a Los Cocos y que el año que viene se va a repetir. Las cervecitas los viernes a la tarde, algún que otro vino en los almuerzos, los postres de La Postrería por cualquier excusa. Los concursos literarios, los refuerzos positivos de Waldo y luego Perrito, el juego de rol truncado, los Teg y otros juegos de mesa y por red. Recuerdo las tarjetas de presentación de cada uno, en las que en vez de hablar de puestos como "Administrador de Sistemas" o "Desarrllador", nos inventamos nuestras propias carreras; yo en mi carrera a ser Shogun estaba en la etapa de [ 浪人 - ronin ]. Recuerdo los hackergotchi que nos hizo Laura para la entonces nueva versión del sitio, y que muchos adoptamos para todo tipo de representación de nosotros mismos.
Recuerdo toda la gente que pasó por la oficina: Ra que se fue, toda una sorpresa para los que quedamos; la llegada y luego partida de Marcos Espontón, su reemplazo, que me volvía loco con Quique Iglesias y Luis Miguel y que compartía con Perrito su gusto casi morboso por Sergio Denis; el Pablo Moisset, que hacía experimentos con cohetes y unos postres de la hostia; Martín Gaitán, el pasante que le apretó las tuercas a Beppo y lo liberó.
Recuerdo Xarope, un proyecto con el que pensábamos abrir el mercado de hosting de Zope/Plone, una de las tecnologías que más dominábamos, con el cual aprendí mucho de Xen y muchas cosas de redes. Recuerdo dar una charla del proyecto en la 7JRSL, y que tuvo muy buena aceptación. Recuerdo que entramos en un programa de financiamiento del gobierno con el cual pensábamos ponerle mas pila al proyecto. Lamentablemente el programa requería que Except hiciera una inversión que no pudo hacer. Recuerdo cuando casi me voy a Sudáfrica a hacer una capacitación con unos ya casi casi clientes, pero que luego compraron indios por la tercera parte del presupuesto que nosotros les pasamos.
Luego los golpes duros. Ra ya se había ido hace rato ya, y entonces le tocó a Laura, mi entonces compañera de oficina. Poco tiempo mas tarde otra noticia bomba: John, el que todos considerábamos el padre de todos nosotros dentro de la empresa, luego de varios intentos de no llegar a un extremo tal, dejaba de trabajar en apenas un mes. Pero el resto de los jefes nos dieron un mensaje claro: "Except sigue", y eso es lo que ocurrió. Vinieron clientes de Holanda a conocer a Anthony y a mi, pues hacía ya varios meses que venía haciendo laburos de SysAdmin para ellos en forma regular. Inclusive cuando se fue ya teníamos planteado un proyecto de migración de servidores. Except seguía.
Entonces Anthony también decidió irse. Daniel y Javi, los dos socios que quedaban, tiraron la toalla: "A partir del 31 de Diciembre Except va a cerrar". Yo no voy a explicar los motivos de esto, no me toca a mí decirlo. Sólo voy a aclarar que no es consecuencia directa de la partida de los Lenton.
Revuelo. Desazón. Incertidumbre. Tristeza.
Este último mes y piquito nos hemos dedicado a seguir laburando como se podía y en lo que se podía. Al mismo tiempo estuvimos catalogando, poniendo precio y vendiendo todo el activo de la empresa: máquinas, escritorios, hasta el rallador de queso. A mi también me tocó desarmar la red, destruir los discos de las máquinas a medida que las vendíamos, apagar el servidor... Duro, muy duro.
Para terminar, voy a decir que hay futuro. Capaz no es la última vez que escuchan hablar de un proyecto llamado Except, un proyecto donde es un placer trabajar, donde la gente involucrada tiene una visión de cómo se tiene que hacer las cosas: tratar bien al cliente, tratar bien al empleado, tratar bien al proveedor, hacer Software Libre, tener un ámbito de trabajo donde el empleado es una persona y no un recurso, donde las cosas se hacen bien. Capaz yo esté en ese proyecto otra vez, capaz no, pero de lo que estoy seguro es que siempre querré estar en él como hace casi dos años.
Dani, Javi, Waldo, Perrito, Paula, Ale, Nati, Mati, Fran, Germán, Rafa, Antony, John, Laura, Pablo, Marcos, Martín, Ra, ha sido un placer trabajar con todos ustedes, aún con mi mal humor y los roces, pero también con mis TMI y la increíble buena onda que le ponen, todas las cosas que pasamos juntos... Todos estos recuerdos que menciono muy capaz los olvide, como seguro ya me he olvidado de muchas cosas, pero nunca los voy a olvidar a ustedes ni a este proyecto. Fue excelente mientras duró y espero que se repita.
PD: Carlitox también trabajó en Except, pero se fue muy poco antes de que yo entrara.
La red de la empresa es un quilombo. Tenemos la red de la oficina por un lado, con los desktops en una red privada y los servers en una red pública (parte de la red pública del edificio donde está la oficina). Tenemos dos CoLos, uno en Rotterdam (Verizon; no me pidan comentarios) y otro en Amsterdam (xs4all; parece que le da housing a la mitad de .nl). En el primero tenemos tres rangos públicos y al menos dos privados, y en el otro tenemos sólo un rango público y unos dos o tres privados, incluyendo un cross-over entre los dos firewalls para hacer fail-over. En resumen, 5 redes públicas y vayasabersecuántas privadas desperdigadas.
Para complicar un poco más las cosas, montamos (bueno, yo no tuve nada que ver, pero ya trabajaba acá) una VPN entre los dos CoLos, teniendo ambas puntas en los firewalls (sin contar de que una punta tenemos dos; uno duerme hasta que el otro se cae).
El último ingrediente de esta sopa: graficamos el tráfico con MRTG (si, ya sé de Munin, ya lo sugerí, pero son como 80 servers en total) sacando los datos por SNMP (que, como dicen en todos lados, de simple tiene sólo el nombre). Pero para el caso es simple: un cliente corre en el server graficador, en este caso en Rotterdam, y en el nodo a graficar un servidorcito SNMP; el tráfico es por UDP.
'Bueno, ¿y dónde está la complicación?', se preguntarán. Les cuento.
Esta gente (notar cómo cuando se mandan una 'cagada' me despego :-P) tiene
unos firewalls implementados a mano en bash. No es la típica ristra de
reglas iptables, sino algo un poco más elaborado, con funcioncitas, pero
aún así son 1400 líneas de bash y otras 630 de configuración (en bash
también, obvio; no hay manera más fácil de hacer configuración de scripts
bash que en bash mismo). Ya les comenté de shorewall también, pero
todo a su tiempo.
Entonces me tocó la tarea de poner a andar el SMNP contra los firewalls de Amsterdam. Parece una boludez, sobre todo porque el MRTG tiene scripts con los que crear la configuración automáticamente leyendo lo que hay disponible por el mismo protocolo (lo diseñadores tuvieron la decencia de ponerle 'descubribilidad'). Por simple que parezca, no andaba nipatrásnipadelante. Le dimos quichicientas vueltas y náa.
Lo más raro fue cuando empezamos a usar tcpdump en las interfaces externas
de los firewalls. Filtrando por el puerto 161 (snmp), en el firewall de
Amsterdam veíamos el tráfico entrante pero no el saliente. Eso nos llevó a
pensar que el firewall estaba jodiendo, pero entonces vimos que el tráfico
que generaba el gráfico para el otro firewall, el durmiente, hacía lo mismo:
veíamos el request pero no la respuesta. Pero el gráfico andaba. Y para
complicar las cosas, con IPSec andando no deberíamos ver el tráfico, pues
tcpdump no sabe desencriptar esos paquetes, sino apenas reconocerlos.
Entonces sospechamos.
Probando el tcpdump en el firewall de la red de Rotterdam vimos un
comportamiento simétrico: no veíamos el request pero si la respuesta. Y
sospechamos mas fuerte.
Mirando con mas fuerza me dí con que los scripts de firewall tenían un par
de bugs: la función que seteaba las excepciones para el firewall mismo no
era llamada nunca y además llamaba a iptables con parámetros erróneos.
La conclusión a la que llegamos, basada únicamente en lo que pudimos ver, es que el túnel anda, y que IPSec hace cosas raras con los paquetes; creemos que cuando los termina de procesar un paquete lo inyecta en la interfaz por la que entró, y eso es lo que hace que veamos el tráfico para un lado. Algún día que esté muy aburrido me voy a poner a ver si esta teoría es cierta.
El otro día dí una charlita un poquito larga de ssh/scp y screen en el
IATE, el lugar donde laburo. En la misma
hablo de ssh/scp básico, mas cómo poner claves públicas/privadas y
cómo usar el ssh-agent para administrarlas (algo de lo que ya hablé
en este
glob),
mas otros temas como el X11 forwarding y el agent-forwarding. Además
hablé de screen, una herramineta que se complementa muy bien con
ssh. Dejo las filminas
acá.
En este post veremos cómo crear pares de claves pública/privada con
passphrases, y cómo usar ssh-agent para no tener que andar
tipeándolas a cada rato.
Lo primero es generar el par. Hay dos tipos de pares de claves, RSA y
DSA. Los pares se guardan en nuestro .ssh/, así que antes de
generar un par nos fijamos qué hay allí:
mdione@cobra:~$ ls -l .ssh/
total 28
-rw-r--r-- 1 mdione mdione 190 2008-02-26 15:29 config
-rw------- 1 mdione mdione 1743 2008-09-19 16:55 id_dsa
-rw-r--r-- 1 mdione mdione 394 2008-09-19 16:55 id_dsa.pub
-rw------- 1 mdione mdione 11598 2008-09-02 10:35 known_hosts
-rw------- 1 mdione mdione 9388 2008-06-05 22:59 known_hosts.old
Hay una par DSA (id_dsa e id_dsa.pub), así que creamos un
par RSA para no pisarlo:
mdione@cobra:~$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/mdione/.ssh/id_rsa):
*** Enter passphrase (empty for no passphrase):
*** Enter same passphrase again:
Your identification has been saved in /home/mdione/.ssh/id_rsa.
Your public key has been saved in /home/mdione/.ssh/id_rsa.pub.
The key fingerprint is:
1c:da:2b:a8:97:72:7e:ab:ff:ea:bb:e8:6b:64:4c:93 mdione@cobra
The key's randomart image is:
+--[ RSA 2048]----+
| |
| |
| . . |
| E + . |
| o .. S |
| +. . |
| o... . |
| ..=... |
| .B**B*. |
+-----------------+
Notar que en *** ssh-keygen pide dos veces una passphrase. El
término passphrase viene de la época en que las passwords sólo podían
ser de un maximo de 8 caracteres. La passphrase puede ser de cualquier
longitud; una longitud buena está en los 15-20 caracteres. Se puede
poner una passphrase nula, pero por motivos de seguridad les sugiero que
no lo hagan. Si aprenden bien a usar ssh-agent van a tener que
tipearla poco.
Ahora copiamos la parte pública al servidor al que queremos entrar:
mdione@cobra:~$ ssh-copy-id -i .ssh/id_rsa.pub beetroot.except.com.ar
*** mdione@beetroot.except.com.ar's password:
Now try logging into the machine, with "ssh 'beetroot.except.com.ar'", and check in:
.ssh/authorized_keys
to make sure we haven't added extra keys that you weren't expecting.
Probamos entrar al server para ver que el par ande:
mdione@cobra:~$ ssh beetroot.except.com.ar
*** Enter passphrase for key '/home/mdione/.ssh/id_rsa':
Last login: Fri Sep 19 12:18:16 2008 from ginger.except.com.ar
mdione@beetroot:~$ logout
Connection to beetroot.except.com.ar closed.
Notar que en *** pide la passphrase del par que acabamos de crear.
Ahora a usar ssh-agent. ssh-agent se inicia en toda sesión
en una distro moderna, podemos verlo dando vueltas en nuestro
background:
mdione@cobra:~$ ps fax | grep ssh-agent
2997 ? Ss 0:00 \_ ssh-agent screen
En este caso lo tengo corriendo antes de un screen, pero en un
desktop podemos ver algo de la pinta /usr/bin/ssh-agent
/usr/bin/dbus-launch --exit-with-session x-session-manager.
Una vez que vemos el ssh-agent dando vueltas por ahí, veamos qué
claves tiene:
mdione@cobra:~$ ssh-add -l
The agent has no identities.
Ok, agreguemos identidades al agente:
mdione@cobra:~$ ssh-add /home/mdione/.ssh/id_rsa
*** Enter passphrase for /home/mdione/.ssh/id_rsa:
Identity added: /home/mdione/.ssh/id_rsa (/home/mdione/.ssh/id_rsa)
mdione@cobra:~$ ssh-add -l
2048 1c:da:2b:a8:97:72:7e:ab:ff:ea:bb:e8:6b:64:4c:93 /home/mdione/.ssh/id_rsa (RSA)
En *** ssh-add nos pide la passphrase de la clave. Ok,
probemos entrar al servidor:
mdione@cobra:~$ ssh beetroot.except.com.ar
Last login: Fri Sep 19 20:58:57 2008 from 200.69.231.1
mdione@beetroot:~$
No pidió la passphrase, que es lo que queríamos.
Las passphrases quedan en el ssh-agent por un período determinado
de tiempo. Por defecto duran para siempre, pero con ssh-add -t
<segundos> podemos cambiar eso. También podemos borrar una identidad
con ssh -d <clave privada> o todas las identidades con ssh-add
-D (que molesta costumbre de estas herramientas que tienen nombre de
creación pero con algunas opciones de destrucción; ssh-keygen tiene
una opción -R que no sólo borra claves, sino que lo hace sobre el
.ssh/known-hosts, cuando el comando por sí solo actúa en los pares de
claves).
En otro post mostraré cómo sacar identidades de un agent y ponerlo en otro.
Siguiendo un poco la historia de ayer, un reporte mas detallado. Antes de ir a los bifes, quiero decir que una de las máquinas que ayer dije que estaba infectada no lo estaba. Descartando esa máquina podemos agregar otro factor común que no me gusta ni mierda: yo tengo usuario en todas, pero no en todas tengo sudo. También se agregó otra máquina de mi casa, que tiene Apache, pero no en el puerto 80, no al menos desde fuera.
Como comenté, lo instalado está en /usr/lib/libb/... /. El contenido es el siguiente:
$ ls -laR
.:
total 654
drwxr-xr-x 3 mdione mdione 152 feb 1 09:07 .
drwxr-xr-x 3 mdione mdione 280 feb 1 09:07 ..
-rw-r--r-- 1 mdione mdione 1638 ene 10 2006 bugfalse.c
-rw-r--r-- 1 mdione mdione 2369 ene 10 2006 clear.sh
drwxr-xrwx 3 mdione mdione 984 ene 10 2006 rk
-rw-r--r-- 1 mdione mdione 657610 ene 10 2006 rk2.tgz
./rk:
total 1609
drwxr-xrwx 3 mdione mdione 984 ene 10 2006 .
drwxr-xr-x 3 mdione mdione 152 feb 1 09:07 ..
-rw-r--r-- 1 mdione mdione 382 mar 5 2004 .b
-rw-r--r-- 1 mdione mdione 427 ago 7 2002 brute.sh
-rwxr-xr-x 1 mdione mdione 116352 mar 5 2004 chfn
-rwxr-xr-x 1 mdione mdione 115828 mar 5 2004 chsh
-rw-r--r-- 1 mdione mdione 123 mar 6 2002 desuid.sh
-rw-r--r-- 1 mdione mdione 249 ago 14 2002 dlog
-rwxr-xr-x 1 mdione mdione 54041 mar 5 2004 du
-rwxr-xr-x 1 mdione mdione 57296 mar 5 2004 find
-rwxr-xr-x 1 mdione mdione 137820 mar 5 2004 inetd
-rw-r--r-- 1 mdione mdione 12818 mar 5 2004 jeje
-rwxr-xr-x 1 mdione mdione 21306 mar 5 2004 killall
-rw-r--r-- 1 mdione mdione 54228 jun 7 2001 libshadow.a
-rw-r--r-- 1 mdione mdione 644 jun 7 2001 libshadow.la
-rwxr-xr-x 1 mdione mdione 47730 jun 7 2001 libshadow.so.0.0.0
-rwxr-xr-x 1 mdione mdione 38235 mar 5 2004 locate
-rw-r--r-- 1 mdione mdione 40416 jun 7 2001 login
-rw-r--r-- 1 mdione mdione 205 ago 7 2002 loginc
-rwxr-xr-x 1 mdione mdione 96895 mar 5 2004 ls
-rwxr-xr-x 1 mdione mdione 155494 mar 5 2004 ls2
-rwxr-xr-x 1 mdione mdione 82628 mar 5 2004 lsof
-rwxr-xr-x 1 mdione mdione 54152 mar 5 2004 netstat
-rw-r--r-- 1 mdione mdione 683 ago 14 2002 netstat.c
-rw-r--r-- 1 mdione mdione 4097 ago 14 2002 ovas0n.c
drwxr-xr-x 2 mdione mdione 200 ago 16 2002 pb
-rwxr-xr-x 1 mdione mdione 84568 mar 5 2004 ps
-r-xr-xr-x 1 mdione mdione 48285 mar 5 2004 ps2
-rw-r--r-- 1 mdione mdione 10641 may 20 2002 psf.c
-rwxr-xr-x 1 mdione mdione 12024 mar 5 2004 pstree
-rwxr-xr-x 1 mdione mdione 3758 mar 5 2004 rk.sh
-rw-r--r-- 1 mdione mdione 548 ago 14 2002 solaris
-rw-r--r-- 1 mdione mdione 27816 jun 7 2001 su
-rw-r--r-- 1 mdione mdione 397 abr 7 2003 suid
-rwxr-xr-x 1 mdione mdione 28476 mar 5 2004 syslogd
-rwxr-xr-x 1 mdione mdione 70145 mar 5 2004 top
-rwxr-xr-x 1 mdione mdione 155496 mar 5 2004 vdir
-rwxr-xr-x 1 mdione mdione 17851 ene 13 2004 wipe
-rw-r--r-- 1 mdione mdione 10027 jun 7 2001 wipe.c
./rk/pb:
total 53
drwxr-xr-x 2 mdione mdione 200 ago 16 2002 .
drwxr-xrwx 3 mdione mdione 984 ene 10 2006 ..
-rw-r--r-- 1 mdione mdione 422 jul 1 2001 Makefile
-rw-r--r-- 1 mdione mdione 3463 mar 13 2000 a-p.c
-rwxr-xr-x 1 mdione mdione 13766 jul 26 2001 ap
-rw-r--r-- 1 mdione mdione 4871 mar 13 2000 icmplib.h
-rwxr-xr-x 1 mdione mdione 15004 jul 26 2001 selver
-rw-r--r-- 1 mdione mdione 2567 jul 1 2001 selver.c
Cosas interesantes en él:
bugfalse.c es una reimplementación de /bin/false que encontré andando al menos en el server de mi laburo. Ésta retorna 1 normalmente, pero si rápidamente se le ingresa una password, devuelve un shell como root. Para eso se instala setuid y setgid:
$ ls -l /bin/false
-rwsr-xr-x 1 root root 11612 2004-07-16 08:37 /bin/false
clear.sh fue sacado de "raza mexicana". Es para borrar logs.
a-p.c es un callbacker. Envía un paquete ICMP a una dirección, recibe como respuesta un comando y lo ejecuta.
selver.c es un servidorcito que recibe un paquete ICMP, abre un puerto y enchufa bash en él. El código tiene perlitas como:
if(strstr(buffer, "quit")) {
a++;
exit(0);
}
(la indentación es del original).
brute.sh lanza procesos como para hacer cosas en batch.
jeje es la salida de un strace de una corrida de vdir. En algún momento vemos un hostname "Ginebra-Rulez" en la salida de una llamada a uname(). Sólo encontré referencias al basquet filipino. No le veo más nada interesante.
loginc es un bash script que simula ser el viejo login, pero guarda passwds en /var/tmp/.oracle1.
ovas0n.c lo podemos encontrar por toda la red. Otro servidorcito que arranca bash.
psf.c cambia el comando reportado en las salidas de ps, top y otros. Bastante educativo porque explica exactamente cómo lo hace.
rk.sh es el instalador de todos los otros binarios que vemos con nombres usuales: ls, ps, etc.
wipe.c es otro log cleaner. En particular éste es el que sabe borrar entradas de /var/log/{b,u,w}tmp.
Por último, estuve buscando a otros en la red que le pueda haber mordido esto. Sólo encontré a un ponja (ver entradas del 10/11/2001; sí, 2001) que no le entiendo una goma. Pero si lo traducimos con google o con babelfish sale en un lado la palabra "Argentina", que es de donde parece más le entraron :-|.
En fin, es todo por ahora.
Ayer a la tarde me puse a arreglar un bug rarísimo que veía en uno de mis servidores. screen fallaba como usuario, pero no como root. La falla era que screen no terminaba de arrancar. Mirándolo con mas fuerza encontré que éste creaba un hijo, éste moría y el padre no hacía nada al respecto, dejándolo como zombie. Ya usando rayos X, o sea strace -ff, descubrí que dicho ihjo moría con un SIGSEGV. Usando rayos Γ, o sea las fuentes, la culpable tanto de dicho hijo como de la muerte era la función getspnam.
Comencé primero a sospechar de PAM, pero luego, leyendo bien la manpage, sospeché de /etc/shadow. Allí es donde me dí cuenta que algunos usuarios de sistema tenían passwd, pero no deberían. Estaba hasta las manos. Le pasé un chkrootkit -q que me encontró un rootkit en /usr/lib/libb/.../. Lo metí en un .tar.bz2, lo borré y reinicié la máquina. Me fui a casa pasadas las 21.
Hoy llegué a la oficina y le conté esto al resto. Empezamos a inspeccionar otras máquinas. Cayeron mis dos máquinas en casa, la de GrULiC y la de otros dos GrÚLiCos. Hasta ahora no sabemos mas nada. Yo personalmente no he tenido tiempo de hacer un análisis forense de la situación. El factor común en todas estas máquinas es Debian (sarge, etch y sid) con Apache corriendo. También hay otros Debian con Apache que no han sido comprometodos.
Les dejo una salida típica de aquel comando:
$ sudo chkrootkit -q
The following suspicious files and directories were found:
/usr/lib/libb/...
/usr/lib/libb/... /rk/.b
/usr/lib/games/ufoai/.gamedir
/usr/lib/iceweasel/.autoreg
/usr/lib/xulrunner/.autoreg
/lib/init/rw/.ramfs
/usr/lib/libb/...
Hay veces que también agrega:
Warning: Possible LKM Trojan installed
Hay gente que tambien está usando rkhunter, pero parece que no lo detecta. Eso es todo por ahora.
Esto capaz es una boludez, pero buéh...
En uno de mis laburos (ahora tengo 3) tenemos un server que da DHCP y
DNS a una red interna, un Debian Etch con dnsmasq. El punto es que
dnsmasq concentra muy bien estos dos servicios, haciendo muy simple el
poder resolver nombres de máquinas que tomaron su IP dinámicamente por
DHCP. Esto se logra haciendo que el cliente mande un nombre de máquina,
y según el ip que le asigna agrega una entrada de DNS. Para el entorno
donde estoy trabajando esto viene de pelos.
También toma DNS del /etc/hosts. El problema es que si en la entrada
del 127.0.0.1, además del típico localhost y/o
localhost.localdomain (puaj) hay otro nombre de máquina, y está
primero, antes que ninguna otra máquina, esa entrada queda en el DNS.
Así, si desde dentro de la red preguntás por el nombre del servidor, el
DNS responde que 127.0.0.1. Parrafraseando a un famoso personaje de
una serie televisiva: “D-oh!”.
Esto capaz es una boludez, pero buéh...
En uno de mis laburos (ahora tengo 3) tenemos un server que da DHCP y
DNS a una red interna, un Debian Etch con dnsmasq. El punto es que
dnsmasq concentra muy bien estos dos servicios, haciendo muy simple el
poder resolver nombres de máquinas que tomaron su IP dinámicamente por
DHCP. Esto se logra haciendo que el cliente mande un nombre de máquina,
y según el ip que le asigna agrega una entrada de DNS. Para el entorno
donde estoy trabajando esto viene de pelos.
También toma DNS del /etc/hosts. El problema es que si en la entrada
del 127.0.0.1, además del típico localhost y/o
localhost.localdomain (puaj) hay otro nombre de máquina, y está
primero, antes que ninguna otra máquina, esa entrada queda en el DNS.
Así, si desde dentro de la red preguntás por el nombre del servidor, el
DNS responde que 127.0.0.1. Parrafraseando a un famoso personaje de
una serie televisiva: “D-oh!”.
El otro día dí una charlita un poquito larga de ssh/scp y screen en el
IATE, el lugar donde laburo. En la misma
hablo de ssh/scp básico, mas cómo poner claves públicas/privadas y
cómo usar el ssh-agent para administrarlas (algo de lo que ya hablé
en este
glob),
mas otros temas como el X11 forwarding y el agent-forwarding. Además
hablé de screen, una herramineta que se complementa muy bien con
ssh. Dejo las filminas
acá.
En este post veremos cómo crear pares de claves pública/privada con
passphrases, y cómo usar ssh-agent para no tener que andar
tipeándolas a cada rato.
Lo primero es generar el par. Hay dos tipos de pares de claves, RSA y
DSA. Los pares se guardan en nuestro .ssh/, así que antes de
generar un par nos fijamos qué hay allí:
mdione@cobra:~$ ls -l .ssh/
total 28
-rw-r--r-- 1 mdione mdione 190 2008-02-26 15:29 config
-rw------- 1 mdione mdione 1743 2008-09-19 16:55 id_dsa
-rw-r--r-- 1 mdione mdione 394 2008-09-19 16:55 id_dsa.pub
-rw------- 1 mdione mdione 11598 2008-09-02 10:35 known_hosts
-rw------- 1 mdione mdione 9388 2008-06-05 22:59 known_hosts.old
Hay una par DSA (id_dsa e id_dsa.pub), así que creamos un
par RSA para no pisarlo:
mdione@cobra:~$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/mdione/.ssh/id_rsa):
*** Enter passphrase (empty for no passphrase):
*** Enter same passphrase again:
Your identification has been saved in /home/mdione/.ssh/id_rsa.
Your public key has been saved in /home/mdione/.ssh/id_rsa.pub.
The key fingerprint is:
1c:da:2b:a8:97:72:7e:ab:ff:ea:bb:e8:6b:64:4c:93 mdione@cobra
The key's randomart image is:
+--[ RSA 2048]----+
| |
| |
| . . |
| E + . |
| o .. S |
| +. . |
| o... . |
| ..=... |
| .B**B*. |
+-----------------+
Notar que en *** ssh-keygen pide dos veces una passphrase. El
término passphrase viene de la época en que las passwords sólo podían
ser de un maximo de 8 caracteres. La passphrase puede ser de cualquier
longitud; una longitud buena está en los 15-20 caracteres. Se puede
poner una passphrase nula, pero por motivos de seguridad les sugiero que
no lo hagan. Si aprenden bien a usar ssh-agent van a tener que
tipearla poco.
Ahora copiamos la parte pública al servidor al que queremos entrar:
mdione@cobra:~$ ssh-copy-id -i .ssh/id_rsa.pub beetroot.except.com.ar
*** mdione@beetroot.except.com.ar's password:
Now try logging into the machine, with "ssh 'beetroot.except.com.ar'", and check in:
.ssh/authorized_keys
to make sure we haven't added extra keys that you weren't expecting.
Probamos entrar al server para ver que el par ande:
mdione@cobra:~$ ssh beetroot.except.com.ar
*** Enter passphrase for key '/home/mdione/.ssh/id_rsa':
Last login: Fri Sep 19 12:18:16 2008 from ginger.except.com.ar
mdione@beetroot:~$ logout
Connection to beetroot.except.com.ar closed.
Notar que en *** pide la passphrase del par que acabamos de crear.
Ahora a usar ssh-agent. ssh-agent se inicia en toda sesión
en una distro moderna, podemos verlo dando vueltas en nuestro
background:
mdione@cobra:~$ ps fax | grep ssh-agent
2997 ? Ss 0:00 \_ ssh-agent screen
En este caso lo tengo corriendo antes de un screen, pero en un
desktop podemos ver algo de la pinta /usr/bin/ssh-agent
/usr/bin/dbus-launch --exit-with-session x-session-manager.
Una vez que vemos el ssh-agent dando vueltas por ahí, veamos qué
claves tiene:
mdione@cobra:~$ ssh-add -l
The agent has no identities.
Ok, agreguemos identidades al agente:
mdione@cobra:~$ ssh-add /home/mdione/.ssh/id_rsa
*** Enter passphrase for /home/mdione/.ssh/id_rsa:
Identity added: /home/mdione/.ssh/id_rsa (/home/mdione/.ssh/id_rsa)
mdione@cobra:~$ ssh-add -l
2048 1c:da:2b:a8:97:72:7e:ab:ff:ea:bb:e8:6b:64:4c:93 /home/mdione/.ssh/id_rsa (RSA)
En *** ssh-add nos pide la passphrase de la clave. Ok,
probemos entrar al servidor:
mdione@cobra:~$ ssh beetroot.except.com.ar
Last login: Fri Sep 19 20:58:57 2008 from 200.69.231.1
mdione@beetroot:~$
No pidió la passphrase, que es lo que queríamos.
Las passphrases quedan en el ssh-agent por un período determinado
de tiempo. Por defecto duran para siempre, pero con ssh-add -t
<segundos> podemos cambiar eso. También podemos borrar una identidad
con ssh -d <clave privada> o todas las identidades con ssh-add
-D (que molesta costumbre de estas herramientas que tienen nombre de
creación pero con algunas opciones de destrucción; ssh-keygen tiene
una opción -R que no sólo borra claves, sino que lo hace sobre el
.ssh/known-hosts, cuando el comando por sí solo actúa en los pares de
claves).
En otro post mostraré cómo sacar identidades de un agent y ponerlo en otro.
En este post veremos cómo crear pares de claves pública/privada con
passphrases, y cómo usar ssh-agent para no tener que andar
tipeándolas a cada rato.
Lo primero es generar el par. Hay dos tipos de pares de claves, RSA y
DSA. Los pares se guardan en nuestro .ssh/, así que antes de
generar un par nos fijamos qué hay allí:
mdione@cobra:~$ ls -l .ssh/
total 28
-rw-r--r-- 1 mdione mdione 190 2008-02-26 15:29 config
-rw------- 1 mdione mdione 1743 2008-09-19 16:55 id_dsa
-rw-r--r-- 1 mdione mdione 394 2008-09-19 16:55 id_dsa.pub
-rw------- 1 mdione mdione 11598 2008-09-02 10:35 known_hosts
-rw------- 1 mdione mdione 9388 2008-06-05 22:59 known_hosts.old
Hay una par DSA (id_dsa e id_dsa.pub), así que creamos un
par RSA para no pisarlo:
mdione@cobra:~$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/mdione/.ssh/id_rsa):
*** Enter passphrase (empty for no passphrase):
*** Enter same passphrase again:
Your identification has been saved in /home/mdione/.ssh/id_rsa.
Your public key has been saved in /home/mdione/.ssh/id_rsa.pub.
The key fingerprint is:
1c:da:2b:a8:97:72:7e:ab:ff:ea:bb:e8:6b:64:4c:93 mdione@cobra
The key's randomart image is:
+--[ RSA 2048]----+
| |
| |
| . . |
| E + . |
| o .. S |
| +. . |
| o... . |
| ..=... |
| .B**B*. |
+-----------------+
Notar que en *** ssh-keygen pide dos veces una passphrase. El
término passphrase viene de la época en que las passwords sólo podían
ser de un maximo de 8 caracteres. La passphrase puede ser de cualquier
longitud; una longitud buena está en los 15-20 caracteres. Se puede
poner una passphrase nula, pero por motivos de seguridad les sugiero que
no lo hagan. Si aprenden bien a usar ssh-agent van a tener que
tipearla poco.
Ahora copiamos la parte pública al servidor al que queremos entrar:
mdione@cobra:~$ ssh-copy-id -i .ssh/id_rsa.pub beetroot.except.com.ar
*** mdione@beetroot.except.com.ar's password:
Now try logging into the machine, with "ssh 'beetroot.except.com.ar'", and check in:
.ssh/authorized_keys
to make sure we haven't added extra keys that you weren't expecting.
Probamos entrar al server para ver que el par ande:
mdione@cobra:~$ ssh beetroot.except.com.ar
*** Enter passphrase for key '/home/mdione/.ssh/id_rsa':
Last login: Fri Sep 19 12:18:16 2008 from ginger.except.com.ar
mdione@beetroot:~$ logout
Connection to beetroot.except.com.ar closed.
Notar que en *** pide la passphrase del par que acabamos de crear.
Ahora a usar ssh-agent. ssh-agent se inicia en toda sesión
en una distro moderna, podemos verlo dando vueltas en nuestro
background:
mdione@cobra:~$ ps fax | grep ssh-agent
2997 ? Ss 0:00 \_ ssh-agent screen
En este caso lo tengo corriendo antes de un screen, pero en un
desktop podemos ver algo de la pinta /usr/bin/ssh-agent
/usr/bin/dbus-launch --exit-with-session x-session-manager.
Una vez que vemos el ssh-agent dando vueltas por ahí, veamos qué
claves tiene:
mdione@cobra:~$ ssh-add -l
The agent has no identities.
Ok, agreguemos identidades al agente:
mdione@cobra:~$ ssh-add /home/mdione/.ssh/id_rsa
*** Enter passphrase for /home/mdione/.ssh/id_rsa:
Identity added: /home/mdione/.ssh/id_rsa (/home/mdione/.ssh/id_rsa)
mdione@cobra:~$ ssh-add -l
2048 1c:da:2b:a8:97:72:7e:ab:ff:ea:bb:e8:6b:64:4c:93 /home/mdione/.ssh/id_rsa (RSA)
En *** ssh-add nos pide la passphrase de la clave. Ok,
probemos entrar al servidor:
mdione@cobra:~$ ssh beetroot.except.com.ar
Last login: Fri Sep 19 20:58:57 2008 from 200.69.231.1
mdione@beetroot:~$
No pidió la passphrase, que es lo que queríamos.
Las passphrases quedan en el ssh-agent por un período determinado
de tiempo. Por defecto duran para siempre, pero con ssh-add -t
<segundos> podemos cambiar eso. También podemos borrar una identidad
con ssh -d <clave privada> o todas las identidades con ssh-add
-D (que molesta costumbre de estas herramientas que tienen nombre de
creación pero con algunas opciones de destrucción; ssh-keygen tiene
una opción -R que no sólo borra claves, sino que lo hace sobre el
.ssh/known-hosts, cuando el comando por sí solo actúa en los pares de
claves).
En otro post mostraré cómo sacar identidades de un agent y ponerlo en otro.
¿Se acuerdan de la primera
parte?
Bueno, venía aplicando esto varias veces últimamente (nuevamente tracs y
nuevamente plugins). Sé que mi jefe me va a
retar,
pero la verdad es que lo prefiero así. Generalizé esa idea y lo hice un
script, y para marcar su diferencia con el easy_install, lo llamé
useful_install:
#! /usr/bin/python
__requires__ = 'setuptools==0.6c3'
import sys
path= sys.argv.pop (1)
sys.path.append (path)
sys.argv= [sys.argv[0], '--install-dir', path, '--site-dirs', path ]+sys.argv[1:]
from pkg_resources import load_entry_point
sys.exit(
load_entry_point('setuptools==0.6c3', 'console_scripts', 'easy_install')()
)
Como verán es idéntico al easy_install, salvo que el primer parámetro
es el directorio donde vamos a instalar las cosas y que hace la magia
necesaria de agregarlo al sys.path y armar los argumentos para e_i.
Además, le podemos pasar más parámetros a voluntad y pasan derecho al
load_entry_point del e_i. Que lo disfruten.
Directives are similar to a WikiLink in form, except they
begin with ! and may contain parameters. The general form is:
[[!directive param="value" param="value"]]
This gets expanded before the rest of the page is processed, and can be used to transform the page in various ways.
The quotes around values can be omitted if the value is a simple word. Also, some directives may use parameters without values, for example:
[[!tag foo]]
A directive does not need to all be on one line, it can be wrapped to multiple lines if you like:
[[!directive foo="baldersnatch"
bar="supercalifragilisticexpialidocious" baz=11]]
Also, multiple lines of quoted text can be used for a value. To allow quote marks inside the quoted text, delimit the block of text with triple-quotes:
[[!directive text="""
1. "foo"
2. "bar"
3. "baz"
"""]]
ikiwiki also has an older syntax for directives, which requires a space in
directives to distinguish them from wikilinks. This
syntax has several disadvantages: it requires a space after directives with
no parameters (such as [[pagecount ]]), and it prohibits spaces in
wikilinks. ikiwiki now provides the !-prefixed
syntax shown above as default. However, ikiwiki still supports wikis using
the older syntax, if the prefix_directives option is disabled.
Just a note: from now on some posts will be in English. I just want to make sure some of them are worlwide readable.
During DebConf8 I met John Wright, who works in HP. He packages a couple
of python things, like trac-mercurial (currently in sid only), and he
offered to teach me how to package python things.
I've been trying to do that for a couple of years, but Debian's Python Policy is just too much for me. Call me lazy, $DEITY knows I know I am, but I just can't cope with so much and dense info.
So, I tried to look for automatical tools to do it. Two years ago the
only thing I could find was (WARNING: ugly colors ahead)
packer, but its vitality is rather
low: according to FreshMeat, it was added on Dec 2005 and last updated
on Feb 2006. I started using it, but its interface is not very good, so
realeasing further versions was not an easy task. Also, I think now it's
very out-of-date to Debian Policy.
This week I tried again, now trying to find something that could use
either python-support or python-central to manage the python
package, and also that it used the info from setuptool's setup.py,
but I only could find some incomplete tutorials.
So John explained it to me. It really comes down to using dh_make, the
starting point of debhelper. Before you run it you have to make sure
everything's in place for it. That means to put the code in a directory
which name is the name of the program, followed by a dash, followed by
the version, like psync-0.4.1.
Now you just run dh_make --createorig, who asks what kind of package
you're about to build. Normaly a 'single binary' is enough. It will show
you some info it has gathered from your environment, about who you are
and what package you're building. This will also create a .orig
directory in the parent directory (making if a sibling of the current
one) from the current directory, so make sure no cruft goes in. Here is
the point were if there is no setup.py file, you just add it with the
proper info.
This creates the debian directory with a lot of files on it. Those who
already read about Debian packaging will find familiar files. If you're
not, the best way to figuring out what goes where is the proper Debian
Policy.
The first file you have to edit is
control;
just make sure that you add python and python-support as BuildDeps
and ${python:Depends} as Deps.
The
rules
file is a little more complicated. It's a Makefile with several
targets. configure must have the commands needed to configure the
project prior to building it. Most python programs don't need this or
the next one, which is the build target. This one obviously should
have the commands needed to build the program. The third one is clean,
where you usualy just neet to replace the boilerplate $(MAKE) clean
with python setup.py clean. The install target will need a python
setup.py install --prefix=$(CURDIR)/debian/psync/usr. Just check out
the $(MAKE) invocation and you'll figure it out.
The last one is the binary-arch target. This one has lots of calls to
debhelper functions. If you read it carefully, you'll see a
dh_python call, commented out. Don't use it, use dh_pysupport. This
is the hook for python-support support. This is the part that does all
the magic to make sure that you don't break the Debian Python Policy.
And that's mostly it. You can comment out a couple of dh_ functions,
like dh_strip or dh_shlibdeps (shared libs deps).
Another file to edit, and this might be the last one, is
changelog.
This one has a particular format, so I suggest to use dch from the
devscripts package. The one you'll find is a template the dh_make
left for you to fill. You just need to put the bug number of the
ITP bug. What, you
haven't send an ITP but yet? Well, do
it! Then you can use dch -a to
add new entries to the current version's entries, dch -i to increment
the Debian version and maybe dch -r to update the date at the bottom
of the current version. See its manpage for further options.
Last, there is some junk in the debian directory, most of them the
*.ex files, which are just examples. You can safely get rid of them,
or read them to see if they suit you.
The next step is to build it. This is as easy-peasy as running
dpkg-buildpackage. This will build a .deb file, a .dsc file, a
.orig.tar.gz file, a .diff.gz and a .changes file in the parent
directory. This is the outcome of all the work you've done so far, but
is not finished yet. You better run lintian on the .dsc file and the
.deb file. If you add the -i option you'll get some explanation on
why you failed to give a proper, no-lint package.
So, that's it. It's a longish post, but should get you up packaging
python apps in a few minutes. The are still a few problems: you end up
dup'ing info: in the setup.py file and in various files in the
debian directory. Maybe I'll hack something to workaround this.