Siguiendo con los artículos dedicados al análisis de protocolos de red, y servicios, como puede ser TCP, IP, UDP, SMTP, problemas de red, etc, en esta ocasión vamos a analizar el servicio FTP.
De forma básica, podemos decir que FTP es un protocolo de red para la transferencia de archivos de un sistema a otro conectados a una red TCP, basado en la arquitectura cliente-servidor y de una forma fiable y eficiente.
Dicho esto, vamos, a continuación, estudiar la captura realizada.
Las primeras lineas que observamos en la captura corresponden al inicio de la comunicación con el servidor FTP. Se trata, como vemos, del establecimiento de conexiónen tres pasos. El número de secuencia incial es relativo y por tanto en este caso 0.
cliente servidor TCP 2203 > 21 [SYN] Seq=0 Win=64512 Len=0 MSS=1460
servidor cliente TCP 21 > 2203 [SYN, ACK] Seq=0 Ack=1 Win=16384 Len=0 MSS=1460
cliente servidor TCP 2203 > 21 [ACK] Seq=1 Ack=1 Win=64512 Len=0
- cliente envia SYN con un número secuencia Seq=0 y Ack=0
- servidor lo recibe, envia SYN-ACK y responde con su propio número de secuencia Seq=0 y con un ACK = al número de secuencia anterior + 1, es decir: Ack=1
- cliente a su vez responde con ACK y número de secuencia inicial (Seq=0) +1 y ACK = número de secuecia anterior (Seq=0) +1, es decir: Ack=1
En la siguiente línea vemos como el servidor responde al cliente con el código 220 que indica servicio preparado para nuevo usuario y nuestra información del software/versión del servidor FTP:
Response: 220-FileZilla Server version 0.9.29 beta
NOTA: En la ventana de detalles del paquete, vemos que wireshark nos proporciona más información sobre el sevidor:
Seguimos. Responde le cliente iniciando el diálogo y sesión FTP con el servidor. USER identifica al usuario para acceder al sistema de ficheros del servidor:
Request: USER xxxxxxxx
El servidor requiere la contraseña del usuario con el código 331 que indica OK al usuario y que necesita contraseña:
Response: 331 Password required for xxxxxxxx
El cliente responde con la contraseña
Request: xxxxXxxxxXX
En la siguiente linea, el servidor responde con código 230 que indica usuario conectado y que continúe con la sesión:
Response: 230 Logged on
El cliente requiere mostrar el directorio de trabajo con la orden PWD:
Request: PWD
El servidor responde a la petición con un código 257 que indica el nombre de la ruta:
Response: 257 «/» is current directory.
El cliente con la siguiente orden PORT n1,n2,n3,n4,n5,n6 indica al servidor el establecimiento del modo activo. Con esta orden, se indica que se espera conexión del servidor en la dirección IP n1,n2,n3,n4, en este caso 192.168.1.5 tal como vemos en la captura gráfica de Wireshar, y en el puerto n5 y n6. El puerto se calcula de la siguiente forma:
n5*256+n6
Así pues, siendo n5=8 y n6=156, 8*256+156=2204. que, como vemos en la captura un poco más a bajo, es el puerto usado por el cliente. el servidor inicia conexión desde el puerto 20 hacian el puerto «resultante» de la orden PORT:
Request: PORT 192,168,1,5,8,156
El servidor responde con un código 200 indicando que la orden es correcta:
Response: 200 Port command successful
El cliente con la orden TYPE A, indica el tipo de representación de los datos A, es decir ASCII. Podría ser también:
- tipo ABCDIC (Código Extendido de Binario Codificado en Decimal)
- tipo imagen
Request: TYPE A
El servidor responde con codigo de orden correcta y establecimiento de tipo de datos en TYPE A:
Response: 200 Type set to A
El cliente cursa orden LIST. Esta orden hace que el servidor envíe una listado de los ficheros a través del proceso de transferencia de datos:
Request: LIST
En las siguientes lineas vemos que se establece comunicación en los puertos especficados en PORT y el puerto 20:
20 > 2204 [SYN] Seq=0 Win=65535 Len=0 MSS=1460
2204 > 20 [SYN, ACK] Seq=0 Ack=1 Win=64512 Len=0 MSS=1460
20 > 2204 [ACK] Seq=1 Ack=1 Win=65535 Len=0
Se transmiten los datos pedidos por LIST por parte del servidor:
FTP Data: 175 bytes
NOTA: En la ventana de detalles del paquete, vemos que Wireshark nos proporciona, en la línea FTP Data: 175 bytes más información sobre el listado LIST:
Más abajo responde el servidor con un código 150 indicando estado del fichero correcto; va a abrirse la conexión de datos:
Response: 150 Opening data channel for directory list.
Se realiza en las siguientes dos trazas el trasiego de datos de apertura de conexión de datos del listado que se pidió y el servidor responde, a su termino con código 226 que cierra la conexión de datos:
Response: 226 Transfer OK
NOTA: Se cerró la conexión y el sistema vuelve a establecer comunicación:
20 > 2204 [SYN] Seq=0 Win=65535 Len=0 MSS=1460
2204 > 20 [SYN, ACK] Seq=0 Ack=1 Win=64512 Len=0 MSS=1460
20 > 2204 [ACK] Seq=1 Ack=1 Win=65535 Len=0
Se repite el proceso en las siguientes líneas. Hasta la línea:
Request: RETR 1.psd
Esta línea de arriba, con la orden RETR, indica petición para transferir una copia del fichero especificado (1.psd).
Se transmiten los datos del fichero a transferir del servidor al cliente:
FTP-DATA FTP Data: 1460 bytes
FTP-DATA FTP Data: 588 bytes
El servidor responde con un código 150 que el estado del fichero correcto; va a abrirse la conexión de datos
Response: 150 Opening data channel for file transfer.
En las líneas siguientes se transfiere el fichero.
servidor cliente FTP-DATA FTP Data: 1460 bytes
servidor cliente FTP-DATA FTP Data: 1460 bytes
cliente servidor TCP 2206 > 20 [ACK] Seq=1 Ack=4969 Win=64512 Len=0
servidor cliente FTP-DATA FTP Data: 1460 bytes
servidor cliente FTP-DATA FTP Data: 1460 bytes
cliente servidor TCP 2206 > 20 [ACK] Seq=1 Ack=7889 Win=64512 Len=0
servidor cliente FTP-DATA FTP Data: 1460 bytes
servidor cliente FTP-DATA FTP Data: 1460 bytes
cliente servidor TCP 2206 > 20 [ACK] Seq=1 Ack=10809 Win=64512 Len=0
…
…
Todo este proceso terminará con un código 226 que cierra la conexión de datos y que la transferencia está completada:
Response: 226 Transfer OK
Observemos las líneas siguientes en las que el cliebnte cursa petición de establecimiento de datos tipo binario (por tratarse de una imagen la trasferencia) y las respuesta OK del servidor:
cliente servidor FTP Request: TYPE I
servidor cliente FTP Response: 200 Type set to I
El las siguientes líneas se cierra la conexión.
—————————————————————–
Seguridad y Redes 
abra en algun lugar de todo el trafico el nombre del archivo descargado?
Si mayra. Un poco más arriba, en el artículo se dice:
Muy bueno el articulo. Lo busque porque quiero saber mas como maneja el ftp lis «windows size» Ejemplo de captura del lado del cliente FTP:
SERVIDOR CLIENTE > FTP-DATA FTP Data: 1436 bytes
SERVIDOR CLIENTE > FTP-DATA FTP Data: 12 bytes
CLIENTE SERVIDOR > TCP 34688 > 17719 [ACK] seq=1 Ack=4333 Win=14592 Len=0 TSV=26603535 TSER=1268500
CLIENTE SERVIDOR > TCP 34688 > 17719 [ACK] seq=1 Ack=4345 Win=14592 Len=0 TSV=26603535 TSER=1268500
Y tambien quisiera saber acerca de este evento capturado del lado del servidor FTP:
SERVIDOR CLIENTE > FTP-DATA [TCP Window Full] FTP Data: 912 bytes
CLIENTE SERVIDOR > TCP [TCP ZeroWindow] 34688 > 17719 [ACK] Seq=1 Ack=430969 Win=0 Len=0
SERVIDOR CLIENTE > TCP [TCP Keep-Alive] 17719 > 34688 [ACK] Seq=430968 Ack=1 Win=5888 Len=0
CLIENTE SERVIDOR > TCP [TCP ZeroWindow] 34688 > 17719 [ACK] Seq=1 Ack=430969 Win=0 Len=0
CLIENTE SERVIDOR > TCP [TCP window update] 34688 > 17719 [ACK] Seq=1 Ack=430969 Win=32768 Len=0
SERVIDOR CLIENTE > FTP-DATA FTP Data:12120 bytes
Le agradeceria mucho y de antemano sus comentarios.
Wilmer, gracias por tu comentario.
Respecto a tus dudas, es necesario, para mejor interprestación, más segmentos (ordenados) de la captura. De todas de puedo comentarte que para cada segmento de datos que se transmiten, se espera en un tiempo razonable que llegue su ACK.
Respecto a «windows size» y otras etiquetas… TCP windows Keep Alive se poduce cuando la ventana está cerrada y se emiten sondas de ventana, el otro lado responde con uno o varios ACK cuando quiere indicar que la ventana sigue a 0 (Zerowindows). mientras esto esté así o se pueden transmitir Datos.
Cuando se vuelve a abrir la ventana update con Win=32768 ), la aplicación FTP vuelve a leer datos y se pueden transmitir datos.
Arriba, windowsfull, lo que pasa, supongo (necesitaría má datos de segmentos) es que la aplicación no está leyendo dato alguno, se ha llenado el buffer de recepción.
¿Hay alguna forma de leer un documento que haya sido enviado a una impresora?
Si yuSaR. Aquí hable de elo. Revisa este artículo que escribí aquí mismo: http://seguridadyredes.nireblog.com/post/2010/03/24/wireshark-tshark-capturando-impresiones-en-red
Pingback: Tshark. Follow TCP Stream en modo CLI mediante estadísticas tshark. | Seguridad y Redes