FUNDACION

UNIVERSIDAD DE LAS AMERICAS PUEBLA Telecomunicaciones y Redes IS- 510

Network Protocol Analyzer

Ernesto Gutirrez Corona

1. 2. Y 3. Network Protocol Analyzer Un analizador de protocolos de redes (network protocol analizer en ingls), tambien conocido como sniffer o analizador de paquetes (packet analyzer) es un programa que puede interceptar y registrar el trfico que pasa sobre una red informtica o parte de la red [1]. El sniffer captura los paquetes que fluyen a travs de la red, y si es necesario, decodifica los datos crudos del paquete mostrando as los valores de varios campos del paquete y analiza su contenido de acuerdo RFC apropiado. El sniffer ms popular es el conocido como Wireshark. Wireshark es un analizador de protocolos open-source diseado por Gerald Combs y que actualmente est disponible para plataformas Windows, Unix & Mac. Wireshark implementa una amplia gama de filtros que facilitan la definicin de criterios de bsqueda para los ms de 1100 protocolos soportados actualmente (versin 1.6.7); y todo ello por medio de una interfaz sencilla e intuitiva que permite desglosar por capas cada uno de los paquetes capturados. Instalacin de Wireshark La instalacin lgica de Wireshark sera en un servidor para analizar el trfico que pasa por un determinado segmento de la red. Sin embargo, hay mltiples ocasiones en que no es factible hacer esto por razones de acceso al servidor o de seguridad. Existen 4 formas alternativas que se muestran en la siguiente figura:

Modo Hub: Una de las alternativas que tenemos, como se aprecia en la Figura 1- Modos de captura es conectarlo en el mismo segmento de red donde se encuentra el servidor. Al tratarse ahora de un medio compartido, todo el trfico entre el switch y el servidor podr analizarse en el equipo. Modo Port Mirroring: Siempre que se tenga acceso al switch, y soporte esta funcionalidad, ser la manera ms cmoda para capturar el trfico de red. Dicho modo de trabajo permite duplicar el trfico que transcurre por uno o varios puertos del switch y replicarlo al puerto que queramos. Hay que tener en cuenta que el puerto configurado como mirroring tiene que ser tan rpido como el puerto/puertos a monitorizar para evitar prdida de tramas. Este mtodo es empleado por muchos administradores para instalar IDS u otras herramientas de monitorizacin. Modo Bridge: En caso de no tener acceso al switch, podremos utilizar un equipo con dos tarjetas de red para situarnos entre el switch y el servidor, como se observa en la Figura 1. Consiste en un MitM (Man in the Middle), a nivel fsico, donde tendremos un acceso pasivo a todo el caudal de trfico. Modo ARP Spoof: En contadas ocasiones, y en los casos en los que no podamos utilizar los mtodos anteriores, podemos hacer uso de herramientas como Ettercap o similares para llevar a cabo un MitM (Man in the Middle). Es importante entender que se trata de un mtodo bastante ofensivo y que nicamente ser til en entornos no crticos, donde prima cierta necesidad en interceptar trfico entre varias mquinas. En nuestro caso solo es un ejerecicio de ejemplo, lo instalaremos en una computadora y monitorearemos una pgina web Instalacin en Mac (Wireshark version 1.6.7) nicamente se requiere ir a la pgina http://www.wireshark.org/download.html y descargar el descargar el .dmg para Mac y ejecutarlo. Y aparace la pantalla que se muestra en la figura 2.

 Figura 2.Pantalla de Inicio de Wireshark Primera captura Para Mac OS, las interfaces de red que se muestran son en0, fw0, en1, lo0. A continuacin se explica el significado:

Seleccion la interfaz en1:

"lo0": virtual loopback interface "ppp0", "ppp1", etc.: PPP interfaces "en0", "en1", ...: Ethernet or AirPort interfaces "fw0", "fw1", ...: IP-over-FireWire interfaces

 Figura 3. Pantalla de primera captura de wireshark En la figura 3 no se aprecia completamente todos los paquetes que capturo, pero fueron varios los protocolos que capturo entre los que se encuentran TCP/IP, UDP, HTTP, ARP, TLSv1.

4. Anlisis de protocolos HTTP: Hypertext Transport Protocol El protocolo de transferencia de hipertexto (HyperText Transfer Protocol) es un protocolo del nivel de aplicacin usado para la transferencia de informacin entre sistemas, de forma clara y rpida. Un mensaje http consiste en una peticin de un cliente al servidor y en la respuesta del servidor al cliente. Las peticiones y respuestas pueden ser simples o completas. La diferencia es que en las peticiones y respuestas completas se envan headers y un contenido. Este contenido se pone despus de los headers dejando una lnea vaca entre los headers y el contenido. En el caso de peticiones simples, solo se puede usar el mtodo GET y no hay contenido. Si se trata de una respuesta simple, entonces sta slo consta de contenido. Esta diferenciacin entre simples y completas se tiene para que el protocolo HTTP/1.0 pueda atender peticiones y enviar respuestas del protocolo HTTP/0.9. Peticin en http La lnea de peticin comienza indicando el mtodo, seguido de la URI de la peticin y la versin del protocolo, finalizando la lnea con CRLF:
Mtodo SP URI de la peticin SP Versin del protocolo CRLF

Donde SP es un espacio, URI es la URI del recurso al que hace referencia la peticin y CRLF es un retorno de carro y nueva lnea. En el caso del protocolo HTTP/0.9 slo se permite el mtodo GET, con el protocolo HTTP/1.0 GET, POST y HEAD y con el protocolo HTTP/1.1 OPTIONS, GET, HEAD, POST, PUT, DELETE y TRACE Respuesta en http La lnea de estado es la primera lnea de la respuesta y consiste en la versin de protocolo que se utiliza, seguida de una indicacin de estado numrica a la que puede ir asociada una frase explicativa. El formato es el siguiente:
Versin del protocolo SP Cdigo de estado SP Frase explicativa CRLF

El cdigo de estado es un nmero de 3 dgitos que indica si la peticin ha sido atendida satisfactoriamente o no, y en caso de no haber sido atendida, indica la causa. Los cdigos se dividen en cinco clases definidas por el primer dgito del cdigo de estado. As tenemos: 1xx: Informativo; 2xx: xito; 3xx: Redireccin; 4xx: Error del cliente, y 5xx: Error del servidor.

 En esta pantalla se muestra un ejemplo de peticin como se denota en el formato anteriormente descrito.
Mtodo SP URI de la peticin SP Versin del protocolo CRLF POST /es/admin HTTP/1.1\r\n

Y en esta pantalla se muestra todo el paquete, y la parte seleccionada es la parte de los datos en donde descubrimos anteriormente el password

TCP/IP: Transport Control Protocol/IP Las PDU que se intercambian entre dos mdulos TCP se denominan segmentos. El segmento se divide en dos partes, la parte de header y la parte de datos. La parte de datos sigue a la parte de header. Los primeros dos campos del segmento se denominan puerto de fuente y puerto de destino. Esos campos de 16 bits identifican a los programas de aplicacin de nivel superior que utilizan la conexin TCP.

Campo nmero de secuencia: Este campo contiene el nmero de secuencia del primer octeto del campo de datos de usuario. Campo nmero de aceptacin: permite aceptar los datos previamente recibidos. Este campo contiene el valor del nmero de secuencia del siguiente octeto que se espera recibir del transmisor. Campo de desplazamiento de datos: especifica el nmero de palabras alineadas de 32 bits de que consta la cabecera de TCP.. Los seis bits siguientes se denominan flags. Son bits de control de TCP URG indica que el campo de puntero de urgencia es significativo. ACK indica si el campo de aceptacin es significativo. PSH significa que el mdulo va a utilizar la funcin push. RST indica que la conexin se va a inicializar. SYN indica que se van a sincronizar los nmeros de secuencia; se utiliza en los segmentos de establecimiento de conexin como indicacin de que se van a realizar algunas operaciones de preparacin. FIN indica que el remitente no tiene ms datos para enviar. Es comparable a la seal de fin de transmisin (EOT) en otros protocolos. Campo ventana: se pone a un valor que indica cuntos octetos desea aceptar el receptor. Campo de checksum :contiene el complemento de 1 a 16 bits del complemento a 1 de la suma de todas las palabras de 16 bits del segmento. Puntero de urgente: se utiliza slo si el indicador de URG est a 1 uso bastante limitado. Campo de relleno: asegura que la cabecera TCP ocupa un mltiplo par de 32 bits. Finalmente siguen los datos de usuario.

 En la pantalla se muestra un paquete TCP y se muestran los datos como en el diagrama anterior de el puerto fuente (56831) y destino (80) as como el nmero de secuencia (888), nmero de aceptacin (217), desplazamiento de datos (20 bytes). En el campo reservado se nota que es de ACK, tambin viene el tamao de la ventana (65535), el campo de checksum y los campos que son opcionales no se muestran porque no hay datos. User Datagram Protocol (UDP) Es un protocolo del nivel de transporte basado en el intercambio de datagramas (Encapsulado de capa 4 Modelo OSI). Permite el envo de datagramas a travs de la red sin que se haya establecido previamente una conexin, ya que el propio datagrama incorpora suficiente informacin de direccionamiento en su cabecera. Tampoco tiene confirmacin ni control de flujo, por lo que los paquetes pueden adelantarse unos a otros; y tampoco se sabe si ha llegado correctamente, ya que no hay confirmacin de entrega o recepcin. Su uso principal es para protocolos como DHCP, BOOTP, DNS y dems protocolos en los que el intercambio de paquetes de la conexin/desconexin son mayores, o no son rentables con respecto a la informacin transmitida, as como para la transmisin de audio y vdeo en tiempo real, donde no es posible realizar retransmisiones por los estrictos requisitos de retardo que se tiene en estos casos.

 En realidad este protocolo es muy simple y lo podemos ver con el sniffer:

5. Descifrado de password Se intento descifrar el password de una cuenta en un foro de electnica. http://www.forosdeelectronica.com/

Explicacin: en mi computadora estaba ejecutndose un programa de descarga de archivos conocido como utorrent, y la cantidad de peers, seeders y leechers era demasiada, as que tuve que aplicar un filtro de captura como se muestra en la siguiente pantalla:

Y el paquete http: contena la siguiente informacin:

A pesar de que muestra al usuario y los bytes del password algn mtodo del servlet hace un tipo de cifrado, se puede leer pero no se entiende el password.
vb_login_username=nugrem&vb_login_password=&s=&securitytoken=guest&do=login&vb_login_md 5password=4ea02ea3517bec6d7d406711977fb390&vb_login_md5password_utf=4ea02ea3517bec6d7d40 6711977fb390

Segundo intento de descubrir un password Ahora la pgina objetivo fue http://elpatitoeditorial.com en donde me haba registrado anteriormente.

Ese esta pantalla se muestra el paquete capturado con el mtodo POST, del cual vamos a ver el contenido

 Y vemos el contenido name=nugrem&pass=mgrmda&form_build_id=form91d86b65ef877ea4b0b5d2cc8b14 bf2f&form_id=user_login&op=Iniciar+sesi%C3%B3n Y XITO ya descubrimos el password TCP/IP suit desde el punto de vista de seguridad

Desde el punto de vista de seguridad el protocolo TCP/IP me parece vulnerable ya que pudiera tener problemas de autenticidad, confidencialidad e integridad. Por la posibilidad de acceso y modificacin Protecting company network Aunque an no llevo el curso de seguridad informtica, me parece que el cifrado de informacin confidencial es la clave adems de usar protocolos ms seguros como https.