Archivo de la etiqueta: smtp

Cómo comprobar SMTP autentificado

Siempre me pasa lo mismo, cada vez que hago algún cambio en el servidor de correo (Qmail) me vuelvo tonto para probar que funciona bien ya que con el SMTP autentificado no es tan sencillo como introducir tu usuario y tu contraseña.

Tenemos dos métodos para probarlo, el primero requiere de una sola cadena en base64 con el usuario y la clave del usuario. Para sacarlo utilizamos una pequeña expresión en PERL:

perl -MMIME::Base64 -e 'print encode_base64("00USUARIO00CLAVE")'
AFVTVUFSSU8AQ0xBVkU=

Debes sustituir USUARIO y CLAVE por los datos adecuados. Presta atención a los 00 al inicio de cada parámetro, deben seguir ahí. Si tu usuario lleva el dominio completo debes añadir una barra inversa a la @, por ejemplo [email protected].

Con este dato ya podemos probar el servidor:

[osus@host ~]# telnet dominio.com 25
Trying 10.10.10.10...
Connected to dominio.com (10.10.10.10).
Escape character is '^]'.
220 dominio.com ESMTP
EHLO dominio.com
250-dominio.com
250-AUTH=LOGIN PLAIN
250-PIPELINING
250 8BITMIME
AUTH PLAIN AFVTVUFSSU8AQ0xBVkU=
235 ok, go ahead (#2.0.0)

Como véis, después de saludar al servidor (ehlo dominio.com) le decimos en una sóla línea que queremos autentificarnos y cuales son nuestros datos (AUTH PLAIN tucadenaBase64). Eso es todo. Si la autentificación no fuese correcta recibiríamos la respuesta adecuada.

AUTH PLAIN AFVTVUFSSU8AQ0xBVkU=
535 authorization failed (#5.7.0)

En el segundo método enviamos el usuario y la claves por separado, también en base64.

perl -MMIME::Base64 -e 'print encode_base64("usuario")'
dXN1YXJpbw==
perl -MMIME::Base64 -e 'print encode_base64("clave")'
Y2xhdmU=

Para probarlo debemos enviar por un lado el nombre de usuario y por otro su contraseña:

[osus@servidor ~]# telnet dominio.com 25
Trying 10.10.10.10...
Connected to dominio.com (10.10.10.10).
Escape character is '^]'.
220 dominio.com ESMTP
ehlo dominio.com
250-dominio.com
250-AUTH=LOGIN PLAIN
250-PIPELINING
250 8BITMIME
AUTH LOGIN
334 VXNlcm5hbWU6
dXN1YXJpbw==
334 UGFzc3dvcmQ6
Y2xhdmU=
235 ok, go ahead (#2.0.0)

Como véis es parecido al primer sistema pero aquí enviamos el usuario y la contraseña. Después de saludar (ehlo dominio.com) le indicamos que queremos autentificarnos (AUTH LOGIN). Ahora nos pide el usuario (VXNlcm5hbWU6 es Username: en base64) y la clave (UGFzc3dvcmQ6 es Password:). Hemos terminado.

El resto del protocolo SMTP funciona como si estuviese sin autentificar.

Problemas con checkpassword

Otro de los puntos que suele darme algún tipo de problema es la configuración del sistema que utilizan tanto qmail-smtpd como qmail-pop3d para autentificarse: checkpassword. Por defecto no se puede probar directamente ya que lo importante es el código de error que devuelve. Para comprobar su funcionamiento debemos hacer:

perl -e 'printf"%s%sY123456","USUARIO","CLAVE"' | /bin/checkpassword id 3<&0
uid=511(USUARIO) gid=100(users) groups=100(users)

Si la autentificación es correcta nos devolvera algo similar a lo que se indica, si no, no obtendremos respuesta.

Es importante tener en cuenta que el usuario que ejecuta los demonios de Qmail (normalmente qmaild) debe poder ejecutar checkpasswd y que éste debe tener permiso setuid de manera que se ejecute siempre como root independientemente del usuario que lo haga en realidad. Esto debe ser así ya que tiene que acceder a /etc/passwd.

chmod 4755 /bin/checkpassword

Espero que a alguien le sirvan estos apuntes :P, a mi seguro que me ahorrarán tiempo dentro de algunos meses cuando lo necesite de nuevo.

Error con el smtp autentificado con los clientes de Nokia a través de Qmail

Como os decía hace unos días, recientemente he cambiado el Nokia N70 que llevaba desde hace algo más de dos años por un Nokia E51. La característica más importante de este nuevo terminal es la disponibilidad de conexión WIFI, con lo cual, si tienes un poco de suerte y encuentras un punto de acceso abierto, puedes tener acceso a tu correo desde cualquier punto. No he tenido muchos problemas para encontrar puntos de acceso y habitualmente he podido leer el correo. El problema llega a la hora de enviarlo ya que siempre obtengo un error en el envío. Cansado de no saber qué ocurría y dado que voy a estar unos días fuera de casa, decidí investigar un poco.

Comencé por ver cual era la comunicación del cliente de correo con mi servidor. Para ello lancé un sniffer en mi máquina, en este caso Wireshark, nombre actual del Ethereal de toda la vida. Para no volverme loco con todo el tráfico que iba a ver añadí un filtro, de manera que sólo se mostraría el tráfico que venía desde la IP de mi conexión ADSL (11.22.33.44), así sólo vería lo que estaba generando mi propio móvil.

tshark -i2 -f "src host 111.222.333.444"

Y este fué el resultado:

3.197223 11.22.33.44 -> 55.66.77.88 TCP 49537 > smtp [SYN] Seq=0 Win=64240 Len=0 MSS=1460 TSV=1218449730 TSER=0 WS=0
3.197263 55.66.77.88 -> 11.22.33.44 TCP smtp > 49537 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1460 TSV=389435772 TSER=1218449730 WS=7
3.347274 11.22.33.44 -> 55.66.77.88 TCP 49537 > smtp [ACK] Seq=1 Ack=1 Win=64240 Len=0 TSV=1218663480 TSER=389435772
3.356257 55.66.77.88 -> 11.22.33.44 SMTP Response: 220 servidor ESMTP
3.509426 11.22.33.44 -> 55.66.77.88 SMTP Command: EHLO
3.509451 55.66.77.88 -> 11.22.33.44 TCP smtp > 49537 [ACK] Seq=29 Ack=22 Win=5888 Len=0 TSV=389436084 TSER=1218828105
3.509490 55.66.77.88 -> 11.22.33.44 SMTP Response: 250-servidor
3.663467 11.22.33.44 -> 55.66.77.88 SMTP Command: AUTH CRAM-MD5
3.813384 11.22.33.44 -> 55.66.77.88 SMTP Command: amlxxxxxxWFzIDkxNTM4MxxxxxxyYjVjOTdmYxxxxxxxDFhZDg2MjEw
3.853554 55.66.77.88 -> 11.22.33.44 TCP smtp > 49537 [ACK] Seq=197 Ack=95 Win=5888 Len=0 TSV=389436428 TSER=1219132230
8.817212 55.66.77.88 -> 11.22.33.44 SMTP Response: 535 authorization failed (#5.7.0)

Es decir, me estaba fallando la autentificación a través de CRAM-MD5 a pesar de que en el programa de correo del móvil tenía correctamente introducidos el usuario y la clave y el servidor, obviamente, se presentaba diciendo que soportaba este método.

[osus@servidor ~]# telnet localhost 25
Trying 127.0.0.1...
Connected to localhost.localdomain (127.0.0.1).
Escape character is '^]'.
220 servidor ESMTP
ehlo
250-servidor
250-AUTH LOGIN CRAM-MD5 PLAIN
250-PIPELINING
250 8BITMIME

Investigando un poco averigué que para habilitar la autentificación CRAM-MD5 en Qmail, el MTA de correo que utilizo, además de instalar el parche qmail-smtp-auth es necesario sustituir el original checkpasswd  por cmd5checkpw. Con este argumento caí en la cuenta de que nunca jamás he tenido esta autentificación funcionando en mis servidores 😀 , el servidor indicaba que sí pero la realidad era que no 😛 . Ocho años utilizando Qmail y ahora me doy cuenta de que no funcionaba.

No quería complicarme mucho así que, si hasta ahora no la tenía, tampoco me importaba seguir así. Pensé entonces que, si en vez de responder a los clientes que soportaba CRAM-MD5, no se lo decía, el cliente del E51 escogería el AUTH LOGIN de toda la vida y funcionaría. ¿Cómo hacer esto? Sencillo, Qmail es de código abierto y tenemos el código fuente a nuestra disposición.

Parcheando Qmail

En los fuentes de mi Qmail (con todos sus parches) busqué la cadena en cuestión:

grep  CRAM-MD5 *

Y ahí me apareció el objetivo de nuestro parche, qmail-smtpd.c.

Dicho y hecho, abrimos el archivo con vi y buscamos la cadena en cuestión (:/CRAM-MD5) llegando a:

out("rn250-AUTH LOGIN CRAM-MD5 PLAIN");

Esto va a ser sencillo. Modificamos esa/s línea/s de manera que quede/n:

out("rn250-AUTH LOGIN PLAIN");

De este modo, cuando el cliente pregunte le diremos que soportamos LOGIN y PLAIN, pero no CRAM-MD5. He explicado esto en plural porque es más que probable que tengas dos líneas iguales y no sólo una. Puedes dejar sólo una modificada como he indicado o modificar las dos.

Compilamos ahora con un simple make. Como sólo hemos  modificado este archivo únicamente se compilará este. Hacemos una copia de seguridad de nuestro /var/qmail/bin/qmail-smtpd (por si algo no va bien) y copiamos el nuevo a esta ruta dejando los permisos, owner y group igual que tenía el que había.

Si ahora pruebas a enviar un email desde el Nokia E51 comprobarás que funciona correctamente, el cliente del teléfono escoge otro de los sistemas. Utilizando de nuevo el sniffer verás que ahora escoge AUTH LOGIN como método de autentificación.

Ya puedo enviar correo desde mis servidores con el teléfono. Gracias a un sencillo ejercicio de escucha del tráfico de red hemos averiguado cual era el problema.