UNIVERSIDAD DE BUENOS AIRES FACULTAD DE INGENIERIA Seminario de Redes de Computadoras Trabajo Práctico N o 1 Análisis de SMTP mediante sniffing Baglivo Fabricio 80519 Garcia Cáceres David 75889 Docente: Utard Marcelo Argentina 2007
Contents 1 Introducción 2 1.1 Seguridad............................. 3 2 Desarrollo 5 3 Resultados 6 3.1 Caso 1............................... 6 3.2 Caso 2............................... 14 3.3 Caso 3............................... 16 3.4 Caso 4............................... 17 1
1 Introducción SMTP (Simple Mail Transfer Protocol) es un protocolo basado en texto utilizado para enviar correo electrónico. Se definió originalmente en el RFC 821, pero actualmente se utiliza lo que se conoce como ESMTP (Extended SMTP), definido en el RFC 2821. Este protocolo es de tipo cliente-servidor. Una aplicación de correo (Outlook, Eudora, etc.) o un servidor tipo MTA (Mail Transfer Agent) pueden actuar como cliente. Cuando se utiliza una aplicación de correo, se debe configurar cuál es el servidor SMTP que se va a emplear. Al enviar un mail, la aplicación lo entrega al servidor SMTP, el cual buscará el registro DNS MX (Mail Exchange) de cada destinatario y lo reenviará al servidor destino que corresponda. Es decir que en este caso se están realizando varias transferencias, una entre la aplicación y el servidor SMTP, y una o varias (dependiendo de los destinatarios) entre el servidor SMTP y los servidores destino. Para realizar una transferencia, el cliente SMTP debe iniciar una conexión TCP en el puerto 25 del servidor. Una vez establecida la conexión, comienza la sesión SMTP propiamente dicha. Durante la sesión, cliente y servidor intercambian comandos y respuestas (Figura 1). Las respuestas pueden incluir un código numérico de tres dígitos junto a un texto explicativo (Figura 2). Figure 1: En la actualidad, los clientes de correo inician las sesiones SMTP mediante el comando EHLO en lugar de HELO. Si el servidor responde, significa que soporta ESMTP y sus extensiones. Si el cliente no recibe respuesta luego de EHLO, interpreta que el servidor no soporta ESMTP y envía un HELO. 2
Figure 2: En las respuestas del servidor que contienen números, el primer dígito indica la categoría de la respuesta. Están definidas como indica la figura 2. En el ejemplo de la figura 3 se observa claramente las distintas etapas de la sesión: el saludo o presentación, el envío de la información del correo electrónico (incluyendo remitente, destinatario y cuerpo del mensaje) y el cierre de sesión. Se observa también cómo el servidor avisa que el destinatario especificado en Cc: no existe. 1.1 Seguridad Una de las limitaciones del standard SMTP original es que no incluye un mecanismo de autenticación del remitente, lo que favorece diversas prácticas dańinas como el spam. Para solucionar este inconveniente, se definió mediante la RFC 2554 la extensión SMTP-AUTH para el protocolo ESMTP. Esta extensión implementa, entre otras cosas, autentificación del remitente mediante usuario y contraseńa. Además, ambos son enviados al servidor codificados, lo que otorga mayor nivel de seguridad. El mecanismo de codificación puede ser negociado entre cliente y servidor. En la figura 4 se puede ver un ejemplo del uso de AUTH. Entre las líneas 2 y 5 del ejemplo se produce la solicitud de usuario y contraseńa por parte del servidor y el envío de estos datos por parte del cliente. Una vez que el servidor comprueba la validez de la información, responde que la autenticación ha sido correcta Si bien el uso de estas extensiones evita que cualquier persona pueda enviar correo utilizando direcciones de remitentes falsos (o incluso usando direcciones existentes que no le pertenecen), no es suficiente para solucionar el problema del spam. Para esto hay varias propuestas, algunas que complementan al protocolo SMTP y otras que directamente lo reemplazan. 3
Figure 3: Figure 4: 4
2 Desarrollo Se planteó como objetivo monitorear la información intercambiada al enviar correo electrónico mediante SMTP para lograr una visión global de todos los protocolos implicados en una transferencia de este tipo. Para esto, se armó una pequeńa red de dos PC s y un router con conexión a Internet (ver Figur 5) y se instaló un sniffer en una de las computadoras para monitorear el tráfico de la red. Figure 5: Topología de la Red donde se realizó sniffing Con este esquema, los pasos que se siguen cada vez que se envía un mail son: Petición de MAC address del default gateway por parte de la PC Consulta DNS para saber la IP del servidor SMTP utilizado Establecimiento de la conexión TCP con el puerto 25 del servidor Sesión SMTP entre cliente y servidor Finalización de la conexión TCP Para conocer la respuesta del sistema ante diferentes situaciones, se plantearon cuatro casos de análisis, a saber: 5
Envío de correo electrónico desde la PC1 utilizando el servidor SMTP de Speedy, con todo configurado correctamente. Interrupción del enlace WAN durante el envío de un correo electrónico como el del Caso 1. Envío de correo electrónico con una configuración errónea del servidor SMTP en la aplicación de correo. Envío de correo electrónico teniendo mal configurado el default gateway de la PC. 3 Resultados 3.1 Caso 1 En este caso, se configuraron todos los parámetros de red de forma adecuada y se envió un mail. A las PC s se les configuró la IP del router (192.168.0.1) como default gateway y se empleó el servidor SMTP de Speedy (smtp.speedy.com.ar) para enviar el mail. Las capturas se hicieron utilizando WireShark en la PC desde la que se enviaba el mail. Los resultados obtenidos se uestran a continuación en la figura 6 Figure 6: Resultado de la captura en el caso 1 En la captura se pueden ver todos los pasos que se siguen cuando se hace una sesión SMTP típica. A continuación detallaremos cada paso 6
Linea 1.ARP Request Figure 7: ARP Request La PC hace un ARP Request para averiguar la dirección MAC de la IP 192.168.0.1 que corresponde al router (que está configurado como default gateway de la PC). Este paquete ARP Request contiene la IP de la PC, la MAC de la PC y la IP de la cual se quiere conocer la MAC, y es enviado como broadcast, como se puede ver en el campo Destination. Linea 2. ARP Replay El router devuelve un ARP Reply con su dirección MAC (00:0e:4e:0a:19:39). Este paquete no es broadcast, sino que está dirigido a la PC que hizo el ARP Request (campo Destination). DNS Query La PC hace un DNS Query para conocer la dirección IP del servidor SMTP que tiene configurado, en este caso, smtp.speedy.com.ar. Se puede 7
Figure 8: ARP Replay Figure 9: DNS Query 8
observar que si bien la dirección MAC especificada es la del router, la dirección IP es la del servidor DNS primario que tiene configurado la PC (200.51.211.7). Esto se debe a que para llegar a esa dirección IP, que no se encuentra en la red local, el paquete debe ser enviado al default gateway. Notar que se está haciendo uso de UDP, como se esperaba. En la PC se usa el puerto efímero 1048 y en el servidor el puerto 53 (exclusivo para DNS). En la última línea se observa también que se está solicitando un registro tipo A. DNS Response El servidor DNS devuelve la IP asociada al servidor SMTP que se solicito en el paso anterior (66.119.67.23). Se devuelven también los nombres de los servidores autoritativos (dns2.advance.com.ar y dns1.advance.com.ar) y sus direcciones IP (200.10.122.10 y 200.10.122.11). Como en la Línea anterior, se puede observar el uso de UDP. Figure 10: DNS Response Establecimiento de la conexión TCP. Paso 1 La PC inicia una conexión TCP al puerto 25 del servidor SMTP enviando un segmento SYN, que es el primer paso del 3-way handshake del protocolo 9
Figure 11: Establecimiento de la conexión TCP. Paso 1 TCP. En la captura se pueden ver, además de las direcciones MAC e IP origen y destino, el puerto efímero de la PC (1283), el valor de Seq (0), el Maximum Segment Size (MSS = 1460) y el tamańo de la ventana (65535). Establecimiento de la conexión TCP - Paso 2 El servidor SMTP responde al SYN enviado por la PC enviándole el Acknowledge correspondiente (Ack = 1), su número de secuencia (Seq = 0), el tamańo máximo de segmento (MSS = 1452) y el tamańos de la ventana (Win = 5840). Este sería el segundo paso del 3-way handshake. Además de la información mencionada, también se pueden las direcciones MAC e IP y los puertos origen y destino. Establecimiento de la conexión TCP - Paso 3 La PC devuelve un Acknowledge (Ack = 1) al servidor, finalizando los tres pasos requeridos para estableces la conexión TCP. 10
Figure 12: Establecimiento de la conexión TCP. Paso 2 Figure 13: Establecimiento de la conexión TCP. Paso 3 11
Líneas 8 a 35: Sesión SMTP 01 220 elimba.terra.com ESMTP 02 EHLO nuevita 03 250-elimba.terra.com 04 250-PIPELINING 05 250-SIZE 26214400 06 250-AUTH PLAIN LOGIN 07 250 8BITMIME 08 AUTH LOGIN 09 334 VXNlcm5hbWU6 10 agjhz2xpdm9ac3blzwr5lmnvbs5hcg== 11 334 UGFzc3dvcmQ6 12 MTIzNDU2 13 235 Authentication successful 14 MAIL FROM: <hbaglivo@speedy.com.ar> 15 250 Ok 16 RCPT TO: <baglivofabricio@gmail.com> 17 250 Ok 18 DATA 19 354 End data with <CR><LF>.<CR><LF> 20 Message-ID: <000801c7f666$0abd3e60$0300a8c0@nuevita> 21 From: Hugo Baglivo <hbaglivo@speedy.com.ar> 22 To: <baglivofabricio@gmail.com> 23 Subject: Prueba 24 Date: Thu, 13 Sep 2007 21:27:31-0300 25 MIME-Version: 1.0 26 Content-Type: multipart/alternative; 27.boundary= -= NextPart 000 0005 01C7F64C.E48D95A0 28 X-Priority: 3 29 X-MSMail-Priority: Normal 30 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 31 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 32 This is a multi-part message in MIME format. 33 = NextPart 000 0005 01C7F64C.E48D95A0 34 Content-Type: text/plain; 35.charset= iso-8859-1 36 Content-Transfer-Encoding: quoted-printable 37 Esta es una prueba 38 = NextPart 000 0005 01C7F64C.E48D95A0 39 Content-Type: text/html; 12
40.charset= iso-8859-1 41 Content-Transfer-Encoding: quoted-printable 42 <!DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.0 Transitional//EN > 43 <HTML><HEAD> 44 <META http-equiv=3dcontent-type content=3d text/html; = 45 charset=3diso-8859-1 > 46 <META content=3d MSHTML 6.00.2900.3157 name=3dgenerator> 47 <STYLE></STYLE> 48 </HEAD> 49 <BODY bgcolor=3dffffff> 50 </DIV><FONT face=3darial size=3d2>esta es una = 51 prueba</font></div></body>< /HT M L 52 = NextP art 000 0005 01C7F 64C.E48D95A0 53. 54250Ok : queuedasbf 7CA1BC074 55QU IT 56221Bye La sesión SMTP comienza cuando, una vez que se estableció la conexión TCP, el servidor se presenta (Línea 01). El cliente también se presenta mediante el comando EHLO (Línea 02). Recordemos que este comando se usa para que el servidor envíe las extensiones ESMTP que soporta. Estas extensiones se encuentran entre las Líneas 03 y 07, y especifican, entre otros, que soporta autenticación de usuario y MIME de 8 bits. A continuación, comienza el proceso de autenticación encriptada (Líneas 08 a 13). En cliente envía su nombre de usuario (Línea 10) y contraseńa (Línea 12) encriptados en respuesta a los pedidos del servidor (Líneas 09 y 11 respectivamente). En la Línea 08, se puede apreciar además que el cliente especifica el mecanismo de encriptación que va a usar (LOGIN). Esta encriptación debe ser una de las extensiones que el servidor especificó que soportaba (Línea 06). Una vez que el server verifica que el nombre de usuario y contraseńa son correctos, devuelve un Authentication successful. En caso contrario, la sesión SMTP termina y cae la conexión TCP. Una vez finalizadas la presentación y la autenticación, el cliente comienza a enviar los datos del mail. En la Línea 14 indica la dirección de mail de origen y en la Línea 16 la dirección de mail destino. Para cada uno el servidor responde un Ok (Líneas 15 y 17). A continuación, el cliente indica con DATA que comienza el cuerpo del mensaje (Línea 18) y el servidor le responde que debe finalizarlo con una línea que contenga solamente un punto 13
(Línea 19). Entre las Líneas 20 y 52, el cliente envía el cuerpo del mensaje, que contiene la dirección origen (Línea 21), la dirección destino (Línea 22), el Subject (Línea 23), la fecha y hora (Línea 24) y el cuerpo propiamente dicho en formato MIME (Líneas 25 a 52). En la Línea 53, se envía una línea que contiene solamente un punto, dando así por finalizado el envío de datos. El servidor responde con un Ok y notificando que el mensaje a sido puesto en cola con un determinado número hexadecimal (Línea 54). Concluida esto, el cliente podría enviar otro mensaje, por lo que se repetiría lo sucedido entre las Líneas 14 y 54. En este caso, el cliente da por finalizada la sesión enviando QUIT (Línea 55) y el servidor se despide (Línea 56). Línea 36: Finalización de la conexión TCP Figure 14: Finalización de la conexión TCP Una vez que ha finalizado la sesión SMTP, se da de baja la conexión TCP ente la PC y el servidor SMTP. Para esto, la PC envía el segmento FIN al servidor. Como en los casos anteriores, se pueden observar en la captura los valores de Ack, Seq, el tamańo de la ventana, etc. 3.2 Caso 2 Interrupción del enlace WAN durante el envío del mail 14
Como en el caso anterior, se configuraron todos los parámetros de red de forma adecuada y se envió un mail, pero se interrumpió intencionalmente la conexión WAN mientras se realizaba la comunicación. Los resultados que se obtuvieron fueron los que se muestran en la figra 15 Figure 15: Interrupción del enlace WAN durante el envío del mail Podemos observar que la comunicación sigue los mismos pasos que en el Caso 1, pero que en determinado momento (Línea 38) se comienzan a generar mensajes ICMP debido a la interrupción del enlace. Figure 16: Interrupción del enlace WAN durante el envío del mail La PC no recibe los acknowledge de los segmentos TCP enviados, por lo que reenvía los segmentos. Por cada reenvío, recibe un mensaje ICMP Destination unreachable - Network unreachable que le indica que no se pudo entregar el segmento debido a que no se puede llegar a la red a la que va dirigido. Luego de 5 retransmisiones, la PC da de baja la conexión TCP 15
enviando un segmento FIN al servidor (Línea 55). Como era de esperar, la PC recibió un nuevo mensaje ICMP Destination unreachable - Network unreachable ya que este segmento tampoco pudo ser entregado al servidor destino. Otro aspecto destacable es el tiempo que se espera entre cada retransmisión. Recordemos que en TCP tenemos un timer que comienza a correr cada vez que se envía un segmento. Si al finalizar el timer no se recibió el acknowledge correspondiente al segmento, se produce una retransmisión y el timer es seteado a un valor mayor. En este caso, podemos apreciar que el tiempo que transcurre entre la retransmisión de la Línea 37 y la de la Línea 39 es aproximadamente 2,2 segundos. Entre la Línea 39 y la 41 hay una demora de 4,5 segundos. Entre la Línea 41 y la 43 hay 8,8 segundos, entre la 43 y la 45 hay 17,6 segundos y, entre la 45 y la 47, 30,7 segundos. Se ve que cada tiempo de espera es aproximadamente el doble que el anterior, lo que nos dice que el valor del timer es duplicado cada vez que el cliente debe realizar una retransmisión. 3.3 Caso 3 Configuración errónea del servidor SMTP Como en el caso anterior, se configuraron todos los parámetros de red de forma adecuada, pero se dejó mal configurado el nombre del servidor SMTP (smtp.fibertel.com.ar en lugar de smtp.speedy.com.ar). Al enviar un mail obtuvimos los resultados que se muestran en la figura 17 El proceso comienza de manera similar al Caso 1 y 2. Se producen los ARP Request y Reply y el DNS Query. Como el servidor SMTP especificado es erróneo pero existe, la PC recibe un DNS Response indicándole una dirección IP, la cual será utilizada para realizar la conexión TCP subsiguiente. Todo el proceso se desarrolla de manera habitual hasta que el cliente se debe autenticar ante el servidor SMTP. Para esto, envía su usuario y contraseńa (Líneas 24 a 28), pero estos datos no son válidos para el servidor de Fibertel, sino para el de Speedy. Como consecuencia de esto, la autenticación falla y el servidor comunica esta situación al cliente mediante un Authentication Failed (Línea 30). A continuación, tanto el servidor como el cliente dan de baja la conexión TCP y cada uno envía un segmento TCP FIN (Líneas 31 y 32). 16
3.4 Caso 4 Figure 17: Default Gateway mal configurado Se configuraron todos los parámetros de manera adecuada a excepción del default gateway. En la PC 1 (192.168.0.10) se seteó como default gateway la dirección IP de la PC 2 (192.168.0.2). Se intentó enviar un correo con la PC 1 y se realizó sniffing en ambas PC s. Se muestran los resultados de la PC1 en la figura 18 Figure 18: En este caso, el problema surge cuando la PC 1 hace la consulta DNS 17
para averiguar la dirección IP del servidor SMTP. Como la dirección del servidor DNS no está en la red local, se envía el paquete con el DNS Query a la dirección del default gateway. Aunque no quedó en la imagen tomada de la captura, se pudo observar que los DNS Queries tenían como IP destino las direcciones IP de los servidores DNS y como MAC destino la dirección MAC de la PC 2. En conclusión, los DNS Queries llegan a la PC 2, que descarta los paquetes sin realizar ninguna acción. La PC 1 sigue enviando DNS Queries a las direcciones de los servidores DNS primario y secundario que tiene configuradas, pero nunca recibe una respuesta, por lo que el intento de enviar el mail finaliza. No se genera ningún mensaje ICMP, ya que los paquetes son descartados por la PC 2, por lo que no sería esperable que se produzcan ICMP s de tipo Destination unreachable. El sniffing en la PC 2 dio los resultados de la figura 19 Figure 19: Al analizar la PC 2, se pueden observar los siete DNS Queries recibidos desde la PC 1. Como la IP destino no es la de la PC 2, ésta descarta los paquetes directamente. Este comportamiento es similar a cuando tenemos varias PC s conectadas mediante un hub; todas las PC s reciben los paquetes y determinan si son o no las destinatarias del mensaje analizando el campo IP Destination. Tampoco es esperable que la PC 2 reenvíe los paquetes a su default gateway, ya que el ruteo de paquetes es función de un router y no de un host. 18