UNIVERSIDAD DE BUENOS AIRES FACULTAD DE INGENIERIA

Seminario de Redes de Computadoras

Trabajo Prctico No1 a Analisis de SMTP mediante sniffing

Baglivo Fabricio 80519 Garcia Cceres David 75889 a Docente: Utard Marcelo

Argentina 2007

Contents
1 Introduccin o 1.1 Seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Desarrollo 3 Resultados 3.1 Caso 1 3.2 Caso 2 3.3 Caso 3 3.4 Caso 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 3 5 6 6 14 16 17

66.48

Trabajo Prctico 1 a

Baglivo - Garcia Cceres a

Introduccin o

SMTP (Simple Mail Transfer Protocol) es un protocolo basado en texto utilizado para enviar correo electrnico. Se defini originalmente en el RFC o o 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 aplicacin de correo (Outlook, o Eudora, etc.) o un servidor tipo MTA (Mail Transfer Agent) pueden actuar como cliente. Cuando se utiliza una aplicacin de correo, se debe configurar cul es el servio a dor SMTP que se va a emplear. Al enviar un mail, la aplicacin lo entrega o al servidor SMTP, el cual buscar el registro DNS MX (Mail Exchange) de a cada destinatario y lo reenviar al servidor destino que corresponda. Es decir a que en este caso se estn realizando varias transferencias, una entre la aplia cacin y el servidor SMTP, y una o varias (dependiendo de los destinatarios) o entre el servidor SMTP y los servidores destino. Para realizar una transferencia, el cliente SMTP debe iniciar una conexin o TCP en el puerto 25 del servidor. Una vez establecida la conexin, comienza o la sesin SMTP propiamente dicha. o Durante la sesin, cliente y servidor intercambian comandos y respuestas o (Figura 1). Las respuestas pueden incluir un cdigo numrico de tres d o e 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 un HELO. a

Figure 2: En las respuestas del servidor que contienen nmeros, el primer d u gito indica la categor de la respuesta. Estn definidas como indica la figura 2. a a En el ejemplo de la figura 3 se observa claramente las distintas etapas de la sesin: el saludo o presentacin, el env de la informacin del correo o o o o electrnico (incluyendo remitente, destinatario y cuerpo del mensaje) y el o cierre de sesin. Se observa tambin cmo el servidor avisa que el destinatario o e o especificado en Cc: no existe.

1.1

Seguridad

Una de las limitaciones del standard SMTP original es que no incluye un mecanismo de autenticacin del remitente, lo que favorece diversas prcticas o a dainas como el spam. n Para solucionar este inconveniente, se defini mediante la RFC 2554 la exo tensin SMTP-AUTH para el protocolo ESMTP. Esta extensin implementa, o o entre otras cosas, autentificacin del remitente mediante usuario y contrasea. o n Adems, ambos son enviados al servidor codificados, lo que otorga mayor a nivel de seguridad. El mecanismo de codificacin puede ser negociado entre o 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 contrasea por parte del servidor y el env de estos datos por parte del cliente. n o Una vez que el servidor comprueba la validez de la informacin, responde o que la autenticacin ha sido correcta o 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:

66.48

Trabajo Prctico 1 a

Baglivo - Garcia Cceres a

Desarrollo

Se plante como objetivo monitorear la informacin intercambiada al enviar o o correo electrnico mediante SMTP para lograr una visin global de todos los o o protocolos implicados en una transferencia de este tipo. Para esto, se arm una pequea red de dos PCs y un router con conexin o n o a Internet (ver Figur 5) y se instal un sniffer en una de las computadoras o para monitorear el trfico de la red. a

Figure 5: Topolog de la Red donde se realiz sniffing a o Con este esquema, los pasos que se siguen cada vez que se env un mail a son: Peticin de MAC address del default gateway por parte de la PC o Consulta DNS para saber la IP del servidor SMTP utilizado Establecimiento de la conexin TCP con el puerto 25 del servidor o Sesin SMTP entre cliente y servidor o Finalizacin de la conexin TCP o o Para conocer la respuesta del sistema ante diferentes situaciones, se plantearon cuatro casos de anlisis, a saber: a 5

66.48

Trabajo Prctico 1 a

Baglivo - Garcia Cceres a

Env de correo electrnico desde la PC1 utilizando el servidor SMTP o o de Speedy, con todo configurado correctamente. Interrupcin del enlace WAN durante el env de un correo electrnico o o o como el del Caso 1. Env de correo electrnico con una configuracin errnea del servidor o o o o SMTP en la aplicacin de correo. o Env de correo electrnico teniendo mal configurado el default gateway o o de la PC.

3
3.1

Resultados
Caso 1

En este caso, se configuraron todos los parmetros de red de forma adea cuada y se envi un mail. A las PCs se les configur la IP del router o o (192.168.0.1) como default gateway y se emple el servidor SMTP de Speedy o (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 continuacin en la figura 6 o

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 sesin SMTP t o pica. A continuacin detallaremos cada paso o 6

66.48 Linea 1.ARP Request

Trabajo Prctico 1 a

Baglivo - Garcia Cceres a

Figure 7: ARP Request La PC hace un ARP Request para averiguar la direccin MAC de la IP o 192.168.0.1 que corresponde al router (que est configurado como default a 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 direccin MAC (00:0e:4e:0a:19:39). o Este paquete no es broadcast, sino que est dirigido a la PC que hizo el ARP a Request (campo Destination).

DNS Query La PC hace un DNS Query para conocer la direccin IP del servidor o SMTP que tiene configurado, en este caso, smtp.speedy.com.ar. Se puede 7

Figure 8: ARP Replay

Figure 9: DNS Query

66.48

Trabajo Prctico 1 a

Baglivo - Garcia Cceres a

observar que si bien la direccin MAC especificada es la del router, la dio reccin IP es la del servidor DNS primario que tiene configurado la PC o (200.51.211.7). Esto se debe a que para llegar a esa direccin IP, que no o 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 a el puerto ef mero 1048 y en el servidor el puerto 53 (exclusivo para DNS). En la ultima l nea se observa tambin que se est solicitando un registro tipo A. e 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 tambin los nombres de los e 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 conexin TCP. Paso 1 o La PC inicia una conexin TCP al puerto 25 del servidor SMTP enviando o un segmento SYN, que es el primer paso del 3-way handshake del protocolo 9

66.48

Trabajo Prctico 1 a

Baglivo - Garcia Cceres a

Figure 11: Establecimiento de la conexin TCP. Paso 1 o TCP. En la captura se pueden ver, adems de las direcciones MAC e IP a origen y destino, el puerto ef mero de la PC (1283), el valor de Seq (0), el Maximum Segment Size (MSS = 1460) y el tamao de la ventana (65535). n Establecimiento de la conexin TCP - Paso 2 o El servidor SMTP responde al SYN enviado por la PC envindole el Aca knowledge correspondiente (Ack = 1), su nmero de secuencia (Seq = 0), u el tamao mximo de segmento (MSS = 1452) y el tamaos de la ventana n a n (Win = 5840). Este ser el segundo paso del 3-way handshake. a Adems de la informacin mencionada, tambin se pueden las direcciones a o e MAC e IP y los puertos origen y destino. Establecimiento de la conexin TCP - Paso 3 o La PC devuelve un Acknowledge (Ack = 1) al servidor, finalizando los tres pasos requeridos para estableces la conexin TCP. o

10

Figure 12: Establecimiento de la conexin TCP. Paso 2 o

Figure 13: Establecimiento de la conexin TCP. Paso 3 o

11

66.48

Trabajo Prctico 1 a

Baglivo - Garcia Cceres a

L neas 8 a 35: Sesin SMTP o 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 01 220 elimba.terra.com ESMTP EHLO nuevita 250-elimba.terra.com 250-PIPELINING 250-SIZE 26214400 250-AUTH PLAIN LOGIN 250 8BITMIME AUTH LOGIN 334 VXNlcm5hbWU6 aGJhZ2xpdm9Ac3BlZWR5LmNvbS5hcg== 334 UGFzc3dvcmQ6 MTIzNDU2 235 Authentication successful MAIL FROM: <hbaglivo@speedy.com.ar> 250 Ok RCPT TO: <baglivofabricio@gmail.com> 250 Ok DATA 354 End data with <CR><LF>.<CR><LF> Message-ID: <000801c7f666$0abd3e60$0300a8c0@nuevita> From: Hugo Baglivo<hbaglivo@speedy.com.ar> To: <baglivofabricio@gmail.com> Subject: Prueba Date: Thu, 13 Sep 2007 21:27:31 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; .boundary=-= NextPart 000 0005 01C7F64C.E48D95A0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 This is a multi-part message in MIME format. = NextPart 000 0005 01C7F64C.E48D95A0 Content-Type: text/plain; .charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Esta es una prueba = NextPart 000 0005 01C7F64C.E48D95A0 Content-Type: text/html; 12

66.48

Trabajo Prctico 1 a

Baglivo - Garcia Cceres a

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=3Dtext/html; = 45 charset=3Diso-8859-1> 46 <META content=3DMSHTML 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 = N extP art 000 0005 01C7F 64C.E48D95A0 53. 54250Ok : queuedasBF 7CA1BC074 55QU IT 56221Bye La sesin SMTP comienza cuando, una vez que se estableci la conexin o o o TCP, el servidor se presenta (L nea 01). El cliente tambin se presenta mee diante el comando EHLO (L nea 02). Recordemos que este comando se usa para que el servidor env las extensiones ESMTP que soporta. Estas extene siones se encuentran entre las L neas 03 y 07, y especifican, entre otros, que soporta autenticacin de usuario y MIME de 8 bits. o A continuacin, comienza el proceso de autenticacin encriptada (L o o neas 08 a 13). En cliente env su nombre de usuario (L a nea 10) y contrasea n (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 adems que el a cliente especifica el mecanismo de encriptacin que va a usar (LOGIN). Esta o encriptacin debe ser una de las extensiones que el servidor especific que soo o portaba (L nea 06). Una vez que el server verifica que el nombre de usuario y contrasea son correctos, devuelve un Authentication successful. En caso n contrario, la sesin SMTP termina y cae la conexin TCP. o o Una vez finalizadas la presentacin y la autenticacin, el cliente comienza o o a enviar los datos del mail. En la L nea 14 indica la direccin de mail de o origen y en la L nea 16 la direccin de mail destino. Para cada uno el servio dor responde un Ok (L neas 15 y 17). A continuacin, el cliente indica o 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

66.48 (L nea 19).

Trabajo Prctico 1 a

Baglivo - Garcia Cceres a

Entre las L neas 20 y 52, el cliente env el cuerpo del mensaje, que cona tiene la direccin origen (L o nea 21), la direccin destino (L o 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 una l a nea que contiene solamente un punto, dando as por finalizado el env de datos. El servidor responde con un Ok y no o tificando que el mensaje a sido puesto en cola con un determinado nmero u hexadecimal (L nea 54). Concluida esto, el cliente podr enviar otro mensaje, por lo que se repea tir lo sucedido entre las L a neas 14 y 54. En este caso, el cliente da por finalizada la sesin enviando QUIT (L o nea 55) y el servidor se despide (L nea 56). L nea 36: Finalizacin de la conexin TCP o o

Figure 14: Finalizacin de la conexin TCP o o Una vez que ha finalizado la sesin SMTP, se da de baja la conexin TCP o o ente la PC y el servidor SMTP. Para esto, la PC env el segmento FIN al a servidor. Como en los casos anteriores, se pueden observar en la captura los valores de Ack, Seq, el tamao de la ventana, etc. n

3.2

Caso 2

Interrupcin del enlace WAN durante el env del mail o o 14

66.48

Trabajo Prctico 1 a

Baglivo - Garcia Cceres a

Como en el caso anterior, se configuraron todos los parmetros de red de a forma adecuada y se envi un mail, pero se interrumpi intencionalmente la o o conexin WAN mientras se realizaba la comunicacin. Los resultados que se o o obtuvieron fueron los que se muestran en la figra 15

Figure 15: Interrupcin del enlace WAN durante el env del mail o o Podemos observar que la comunicacin sigue los mismos pasos que en el o Caso 1, pero que en determinado momento (L nea 38) se comienzan a generar mensajes ICMP debido a la interrupcin del enlace. o

Figure 16: Interrupcin del enlace WAN durante el env del mail o o La PC no recibe los acknowledge de los segmentos TCP enviados, por lo que reenv los segmentos. Por cada reenv recibe un mensaje ICMP a o, 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 conexin TCP o 15

66.48

Trabajo Prctico 1 a

Baglivo - Garcia Cceres a

enviando un segmento FIN al servidor (L nea 55). Como era de esperar, la PC recibi un nuevo mensaje ICMP Destination unreachable - Network o unreachable ya que este segmento tampoco pudo ser entregado al servidor destino. Otro aspecto destacable es el tiempo que se espera entre cada retransmisin. o Recordemos que en TCP tenemos un timer que comienza a correr cada vez que se env un segmento. Si al finalizar el timer no se recibi el acknowla o edge correspondiente al segmento, se produce una retransmisin y el timer o es seteado a un valor mayor. En este caso, podemos apreciar que el tiempo que transcurre entre la retransmisin de la L o 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 retransmisin. o

3.3

Caso 3

Configuracin errnea del servidor SMTP o o Como en el caso anterior, se configuraron todos los parmetros de red de a forma adecuada, pero se dej mal configurado el nombre del servidor SMTP o (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 errneo pero existe, la PC recibe un DNS Response indicndole una dio a reccin IP, la cual ser utilizada para realizar la conexin TCP subsiguiente. o a o Todo el proceso se desarrolla de manera habitual hasta que el cliente se debe autenticar ante el servidor SMTP. Para esto, env su usuario y contrasea a n (L neas 24 a 28), pero estos datos no son vlidos para el servidor de Fibertel, a sino para el de Speedy. Como consecuencia de esto, la autenticacin falla y o el servidor comunica esta situacin al cliente mediante un Authentication o Failed (L nea 30). A continuacin, tanto el servidor como el cliente dan de baja la conexin o o TCP y cada uno env un segmento TCP FIN (L a neas 31 y 32).

16

66.48

Trabajo Prctico 1 a

Baglivo - Garcia Cceres a

Figure 17:

3.4

Caso 4

Default Gateway mal configurado Se configuraron todos los parmetros de manera adecuada a excepcin del a o default gateway. En la PC 1 (192.168.0.10) se sete como default gateway la o direccin IP de la PC 2 (192.168.0.2). Se intent enviar un correo con la PC o o 1 y se realiz sniffing en ambas PCs. o 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

66.48

Trabajo Prctico 1 a

Baglivo - Garcia Cceres a

para averiguar la direccin IP del servidor SMTP. Como la direccin del o o servidor DNS no est en la red local, se env el paquete con el DNS Query a a a la direccin del default gateway. Aunque no qued en la imagen tomada o o de la captura, se pudo observar que los DNS Queries ten como IP destino an las direcciones IP de los servidores DNS y como MAC destino la direccin o MAC de la PC 2. En conclusin, los DNS Queries llegan a la PC 2, que descarta los pao quetes sin realizar ninguna accin. La PC 1 sigue enviando DNS Queries a o 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 ningn mensaje ICMP, ya que los paquetes u son descartados por la PC 2, por lo que no ser esperable que se produzcan a ICMPs 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 e paquetes directamente. Este comportamiento es similar a cuando tenemos varias PCs conectadas mediante un hub; todas las PCs 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 los paquetes a su e default gateway, ya que el ruteo de paquetes es funcin de un router y no de o un host.

18