Seminario de Redes de Computadoras. Trabajo Práctico N o 2. SMB-NetBIOS-CIFS-Samba

Transcripción

1 UNIVERSIDAD DE BUENOS AIRES FACULTAD DE INGENIERIA Seminario de Redes de Computadoras Trabajo Práctico N o 2 SMB-NetBIOS-CIFS-Samba Baglivo Fabricio Bertamoni Agustn Garcia Caceres David Profesor: Utard Macrelo Argentina 2007

2 1.Introducción SMB (Server message block) es un protocolo que permite compartir archivos, impresoras, puertos series, etc. entre computadoras conectadas en una LAN. SMB es un protocolo tipo cliente-servidor. Una computadora dentro de una red publica los recursos y archivos que tiene disponible para compartir al resto de la red. Cuando otra computadora esté interesada en acceder a alguno de esos recursos, enviará un SMB request convirtiéndose en cliente. La computadora que posee el recurso contestará con un SMB response haciendo las veces de servidor. SMB es un protocolo de capa de aplicación según el modelo TCP/IP. Al ser la última capa del modelo interactúa directamente con el usuario. Es por este motivo que los equipos conectados en la LAN son reconocidos no por su dirección IP, sino por un nombre de equipo. Los clientes se conectaran con los servidores utilizando TCP/IP (RFC 1001, RFC 1002), IPX, NetBEUI. En los primeros dos casos se utiliza NetBIOS como capa de sesión. En esta capa se realizará la traducción entre nombre de máquina y dirección IP. Figura 1. SMB en el modelo de capas. Históricamente, este protocolo fue desarrollado inicialmente por IBM como el IBM PC Network SMB Protocol o Core Protocol a principios de los años 80. Desde entonces, diversos fabricantes (especialmente Microsoft) han ido ampliando su funcionalidad progresivamente, creando diferentes variantes (versiones) de SMB. En ocasiones el cambio de versión ha conllevado el rebautizar el propio 1

3 protocolo. En este sentido, SMB ha recibido, entre otros, los siguientes nombres: Core Protocol, DOS Lan Manager, LAN Manager, NTLM (NT Lan Manager), y en los últimos años, CIFS (Common Internet File System). Todos ellos, por tanto, hacen referencia a SMB, aunque se diferencien en algunos detalles de su funcionalidad y/o implementación. En este trabajo veremos en detalle como se implementa CIFS. En tanto veremos cómo las computadoras con sistema operativo LINUX implementan SAMBA para poder intercambiar recursos con equipos con sistema operativo Windows. 1.1 Métodos de Autenticación. Al ser SMB un protocolo que permite compartir recursos dentro de una LAN encontramos que éste puede generar una gran vulnerabilidad dentro de la misma. Muchas veces solo se quiere compartir recursos con algunos usuarios, y sobre todo evitar que otros usuario tengan acceso a ese recurso. Por esta misma razón SMB soporta dos tipos de autenticación alternativos, denominados modo SHARE y modo USER: Cuando compartimos un recurso en modo SHARE, la protección de dicho recurso recae en una contraseña que asociamos al mismo, de forma que cualquier usuario de un sistema cliente remoto que conozca dicha palabra de paso podrá acceder sin mayores restricciones al recurso (este es el mecanismo de autentificación por defecto en las implemementaciones de SMB para Windows 9X, por ejemplo). En modo USER, el servidor recibe incialmente del sistema cliente unas credenciales de usuario (nombre, dominio y contraseña), que debe autentificar para autorizar el acceso al recurso. Concretamente, si el dominio de las credenciales es conocido, la autentificación se delega a algún controlador de dicho dominio; y en caso contrario, el usuario y la contraseña se autentifican contra la base de datos local del equipo servidor. En cualquier caso, en modo user, el control de acceso sobre el recurso se realiza en función de qué permisos posee sobre dicho recurso el usuario cuyas 2

4 credenciales se han enviado desde el cliente. Una vez que el sistema servidor ha identificado y autentificado al usuario que desea conectarse al recurso, se dispone ya de un SID válido con el que puede contrastar los permisos que dicho SID posee sobre el recurso. Es conveniente recordar en este punto que si el recurso en cuestión es una carpeta compartida, se tienen en cuenta tanto los permisos del recurso, como los permisos NTFS de la carpeta y sus archivos. El modo user es el mecanismo de autentificación por defecto en las versiones de SMB de sistemas Windows NT y posteriores. 1.2 Dominios y Grupos de Trabajo Conociendo ya los métodos de autenticación utilizados por SMB, podemos introducir dos conceptos prácticos utilizados en la mayoría de las redes LAN. Grupo de Trabajo Un grupo de trabajo es un entorno en el cuál cada equipo es responsable de administrar su seguridad. En este entorno se utiliza el modo SHARE de SMB. Es decir, que para poder accede a un recurso ubicado en un equipo, basta solo con conocer la contraseña que este recurso tiene asociada. Es un entorno peer to peer o cliente con cliente. Es por eso que en este sistema el manejote la seguridad esta distribuido. Normalmente, este tipo de configuración es utilizada en pequeñas redes, donde los recursos a proteger son pocos. Dominio El dominio es un entorno en el cuál la seguridad se rige por un sistema de credenciales de autenticidad. Hay un servidor encargado de administrar el acceso a los recursos. El servidor genera credenciales que deben ser instaladas en los equipos que quieren pertenecer al dominio. Mediante esas credenciales el servidor valida al cliente y se le asignan recursos a los que puede acceder. Desde el servidor de dominio se puede permitir o denegar a un cliente el acceso a un recurso. En este sistema la seguridad esta concentrada 3

5 2. CIFS CIFS (Common Internet File System) es un protocolo de red que se usa principalmente para compartir archivos en una LAN. El protocolo le permite al cliente manipular archivos de la misma manera que lo haría si estuviera en la computadora local. Las operaciones más comunes son soportadas (leer, escribir, crear, borrar, renombrar, etc.), con la única diferencia que los archivos se encuentran en una PC remota. CIFS trabaja enviando paquetes desde el cliente al servidor. Cada paquete es típicamente un request de algún tipo (abrir un archivo, cerrarlo, etc.). El servidor recibe el paquete, verifica que el pedido sea legal y que el cliente tenga los permisos necesarios, y finalmente le devuelve al cliente un paquete con una respuesta adecuada. El cliente examina el paquete y determina si se pudo llevar a cabo la acción o no. CIFS es un protocolo de red de alto nivel, por lo que debe apoyarse en otros protocolos de transporte. El protocolo más usado para este fin es NetBIOS over TCP (NBT), aunque también se pueden utilizar otros. Aunque compartir archivos es el objetivo primario de CIFS, hay otras funciones que también puede realizar. Generalmente, es posible determinar si hay otros servidores CIFS en la red, utilizar impresoras remotas y emplear técnicas de autenticación sofisticadas. CIFS se usa habitualmente con Windows, que incluye las funciones de cliente y servidor. Se podría decir que el núcleo de las funciones de red nativas de Windows está hecho basado en CIFS. 2.1 Historia En 1984 IBM escribió una API que permitía la comunicación básica entre los hosts de una red y la llamó NetBIOS. Al año siguiente, IBM publicó un protocolo de transporte que soportaba esta 4

6 API. La API y el protocolo de transporte se unieron en una sola entidad que se llamó NetBIOS Enhanced User Interface (NetBEUI). Más tarde, otros protocolos de transporte se hicieron de uso común, y la API de NetBIOS se implementó en varios de ellos, como DECnet, IPX/SPX y TCP/IP, haciendo a la API cada vez más popular. Poco después, Microsoft e Intel publicaron los lineamientos principales de SMB/CIFS en el Core Protocol. Microsoft e Intel eligieron usar NetBIOS para entregar los paquetes CIFS. Por lo tanto, CIFS usando NetBIOS sobre TCP se convirtió en el mecanismo de red standard para compartir archivos en los sistemas operativos de Microsoft. Muchas opciones han sido agregadas al Core Protocol inicial. En la actualidad, los clientes Windows soportan por lo menos 6 variaciones diferentes de CIFS, con una lista de alrededor de 100 operaciones, donde las más habituales son: Acceso a archivos Cache segura de archivos Notificación de modificaciones a archivos Negociación del protocolo Manejo de atributos extendidos Requests en lotes Soporte para Unicode Sin embargo, este protocolo se está haciendo obsoleto. Las sucesivas extensiones al protocolo hacen que, por ejemplo, varios paquetes CIFS cumplan la misma tarea o tengan opciones indocumentadas. IETF (Internet Engineering Task Force) y SNIA (Storage Networking Industry Association) están intentando solucionar este problema mediante la creación de las especificaciones CIFS 1.0, que tiene una lista de operaciones que es menor que la actual y define con mayor claridad las opciones de los distintos paquetes. 5

7 2.2 NetBIOS Como se mencionó anteriormente, NetBIOS corre sobre varios protocolos de transporte, pero debido a la popularidad de TCP las implementaciones modernas hacen uso de este protocolo. Las técnicas y conceptos para correr NetBIOS sobre TCP/UDP (también conocidos como NBT) fueron documentadas en las RFC 1001 y 1002 en Estos dos documentos son muy completos, RFC1001 cubre los conceptos y métodos mientras que RFC1002 se ocupa de especificaciones detalladas. En estos documentos se describen tres servicios principales: Name Service, Session Service y Datagram Service. A continuación se describirá cada uno de ellos: Name Service Los nombres NetBIOS son nombres legibles para las personas que se asignan a las computadoras de una red. Estos nombres se pueden ver en Windows en el Entorno de Red. Este servicio tiene el mismo propósito que DNS en el mundo TCP/IP, permitiendo que las personas llamen a los hosts mediante un nombre, y tiene un sistema para mapear estos nombre en direcciones de transporte (por ejemplo, una dirección IP). Sin embargo, los métodos para registrar un nombre asociado con una IP y resolver la IP a partir del nombre son muy diferentes a los utilizados por DNS. 2.3 Propiedades de los nombres NetBIOS Resolución de nombres basado en broadcast y/o servidor: los registros y búsquedas de nombres se pueden realizar mediante broadcasting a la LAN y/o utilizando un NetBIOS Name Server (NBNS, o WINS, en la implementación de Microsoft). Debido a esta funcionalidad, el administrador de la red puede configurar cada host para: Sólo broadcast (b-node) Sólo NBNS (p-node) Primero broadcast y luego NBNS, si nadie responde el broadcast (m- node) 6

8 Primero NBNS y luego broadcast si el servidor no responde (hnode) A causa de estas opciones, hay dos descripciones para cada operación con nombres, una con el método de broadcast y otra con el método de servidor. Registro dinámico: DNS y NetBIOS también difieren en cómo crean la asociación entre un nombre y la dirección IP. En DNS, generalmente un administrador tiene que agregar una entrada DNS al servidor una única vez, y el nombre y la IP quedan guardados para siempre. En NetBIOS, la PC registra de manera dinámica la combinación nombre/ip durante el booteo. La PC también puede eliminar el registro de su nombre cuando ya no se lo vaya a utilizar. Sintaxis de nombres: los nombres NetBIOS deben cumplir una serie de reglas. Las principales son las siguientes: Un nombre puede hacer referencia a un único host (unique name) o a múltiples nodos que son parte de un grupo de trabajo (group name) Los nombres no son jerárquicos, a diferencia de DNS. Debido a esto, cada unique name puede ser registrado por solamente un host Los caracteres válidos para los nombres son los rangos a-z, A-Z, 0-9 # $ % ^ & ( ) { }. ~ Los nombres pueden tener un máximo de 15 caracteres 2.4 Procedimientos comunes con nombres en NetBIOS Los dos servicios de nombres más comunes son el registro y la consulta de un nombre. Los registros de nombres asocian un nombre con una IP, mientras que las consultas determinan la IP asociada a un nombre dado. A continuación, describiremos estas operaciones para b- nodes y p-nodes. Para m-nodes y h-nodes, los procedimientos son un mezcla de estos dos. 7

9 Registro de nombre: b-node: el host que desea registrar un nombre crea un NetBIOS name registration packet y lo envía con un broadcast mediante UDP al puerto 137. Este paquete contiene el nombre que se desea registrar y la dirección IP asociada. El host repite este operación 3 veces, esperando 250ms entre cada broadcast. Durante este tiempo, el host verifica si alguna otra estación envía un Defense packet. Este paquete es enviado por el host que ya tiene registrado ese nombre. Si no se recibe ningún Defense packet, el host registra exitosamente el nombre. p-node: el p-node también crea un NetBIOS name registration packet, pero hace un unicast directamente al NBNS mediante UDP al puerto 137. El NBNS busca en la base de datos interna, chequea si el nombre ya está registrado y devuelve un Negative name registration response o un Positive name registration response. Consulta de nombres: b-node: el host que desea hacer la consulta crea un Name query request packet y lo envía con un broadcast mediante UDP al puerto 137. Este paquete contiene el nombre NetBIOS del cual se desea conocer la dirección IP. El host repite este proceso 3 veces, esperando 5 segundos entre cada broadcast. Durante este tiempo, el host recibe un Positive name query response, conteniendo la IP asociada, o no recibe nada. p-node: el p-node también crea un Name query request packet, pero hace un unicast al NBNS mediante UDP al puerto 137. El NBNS busca en su base de datos interna y devuelve un Positive name query response, con la IP asociada, o un Negative name query response Session Service La RFC1001 define una sesión como un intercambio confiable de mensajes entre un par de aplicaciones NetBIOS. Las sesiones son full-duplex, secuenciada y confiable. El servicio de sesión de NetBIOS es el medio genérico mediante el cual los hosts intercambian mensajes. Estos mensajes pueden ser de cualquier tipo, el servicio de 8

10 sesión sólo se encarga de que los mensajes sean transferidos entre los hosts de manera confiable y secuencial. La RFC1001 establece también que el puerto 139 de TCP debería ser usado para emular la funcionalidad del servicio de sesión. El servicio de sesión es extremadamente similar a TCP con algunas excepciones. La principal diferencia es que TCP es orientado a stream y no preserva los límites de los mensajes, en contraste con el servicio de sesión que envía a la red un mensaje por vez y espera leer de la red un mensaje por vez. La solución a este problema es bastante simple, cada paquete del servicio de sesión es encapsulado con un pequeño header de 4 bytes que indica el tamaño del mensaje antes de enviarlo. CIFS usa session service para enviar y recibir los comandos de capas superiores, incluyendo operaciones de archivos e impresión. Por lo tanto, el primer paso en cualquier red CIFS es establecer la sesión NetBIOS ente cliente y servidor. El servicio de sesión es definido por un pequeño conjunto de primitivas que se describe a continuación: Call: inicia la sesión NetBIOS. El paquete contiene el nombre NetBIOS del cliente y el nombre NetBIOS del servidor. Es mapeado en TCP mediante la creación de una conexión TCP full-duplex y enviando luego un paquete NetBIOS Call. Listen: espera un comando Call. Es mapeado en TCP como un servidor esperando una session request en el puerto 139. Hang up: finaliza la sesión NetBIOS. Se mapea en TCP encapsulando los datos con un header que contiene el tamaño del mensaje y luego enviándolo sobre el stream TCP. Send: envía un mensaje. Es mapeado en TCP encapsulando los Datos con un header que contiene el tamaño del mensaje y luego enviándolo sobre el stream TCP. Receive: recibe un mensaje. Es mapeado en TCP como la recepción desde el stream TCP del mensaje completo. 9

11 2.4.2 Datagram service El RFC1001 establece que el servicio de datagrama es un servicio no confiable, no secuenciado y sin conexión. El datagram service es usado por las aplicaciones NetBIOS como un método rápido, que permite broadcast y con pequeño overhead para transferir datos. Como dice la RFC, la entrega de datagramas no es confiable y pueden llegar fuera de orden. La RFC también establece que el puerto 138 de UDP debería ser usado para implementar el servicio de datagramas de NetBIOS sobre la suite de protocolos TCP/IP. UDP es muy similar al servicio de datagramas de NetBIOS, pero se deben hacer algunas pequeñas modificaciones. Todos los datagramas NetBIOS que van a ser enviados por UDP tienen un header que contiene el nombre NetBIOS del host que envía el paquete y si el datagrama ha sido o no fragmentado antes de enviarse. Con esta información, el service datagram de NetBIOS puede ser completamente emulado mediante UDP. Las implementaciones CIFS generalmente utilizan el service datagram para hacer browsing, que es el proceso mediante el cual se averiguan los nombres NetBIOS de los servidores CIFS que se encuentran en la red (Windows luego muestra esta lista en el Entorno de Red ). Esto no es parte de del protocolo standard CIFS, aunque la mayoría de las implementaciones lo incluyen como un ente separado. Por lo tanto, una implementación CIFS pura no necesitaría implementar el service datagram de NetBIOS, sino solamente el name service y el session service. 2.5 El futuro Muchos fabricantes están analizando retirar de forma paulatina NetBIOS para directamente correr CIFS sobre TCP y UDP. Las especificaciones CIFS 1.0 explícitamente establecen que CIFS no depende de ningún protocolo de transporte y contiene un breve apéndice de cómo correr CIFS de forma nativa sobre TCP. 10

12 NetBIOS todavía existe principalmente por cuestiones de compatibilidad hacia atrás. Si NetBIOS es eliminado, los cambios no serían muy drásticos. DNS y los nombres de dominio reemplazarían el servicio de nombres de NetBIOS. Todos los paquetes requeridos por el servicio de sesión correrían directamente sobre TCP y no habría un header NetBIOS. Todos los paquetes que requieran el service datagram, correrían directamente sobre UDP y, nuevamente, el header sería innecesario. No se puede saber si estos cambios serán finalmente realizados. Microsoft parece estar muy interesado en proveer CIFS sin NetBIOS. Si Microsoft comercializa un sistema operativo que implementa CIFS sin NetBIOS, es muy probable que las demás empresas lo hagan también. 2.6 CIFS en detalle CIFS es un protocolo de red que permite compartir archivos entre nodos de una red. Está basado en la arquitectura cliente-servidor, en la que el cliente envía paquetes request al servidor y éste responde con paquetes response. Cada paquete contiene un header standard y dos campos de longitud variable con información específica del paquete. Cada paquete contiene además un campo Command que indica el propósito que intenta cumplir (login, abrir un archivo, leer un archivo, cerrarlo, etc.) Propiedades del protocolo Cliente-Servidor y Request-Response: como mencionamos antes, CIFS está basado en el modelo cliente-servidor. El protocolo es capaz de tener múltiples request pendientes de forma simultánea. Esto se logra a través del Multiplex ID (MID). Hay un MID por cada request enviado por el cliente. Cuando el servidor responde, el paquete response contiene el MID del request al que está contestando. De esta forma, múltiples request pueden ser enviados al servidor y el cliente solamente tiene que comparar los MID de los responses con los MID de los requests enviados. 11

13 Basado en comandos: cada paquete CIFS contiene un campo Command de 1 byte. En la actualidad hay más de 100 comandos disponibles. Las respuestas al cliente siempre tienen el mismo código de comando que el request. Negociación del dialecto del protocolo: hay muchas revisiones del protocolo CIFS desde su primera aparición en Cada versión del protocolo se conoce como dialecto y se le asigna un string único para identificarlo. Cuando un cliente desea acceder a un archivo en un servidor remoto, el primer paquete CIFS enviado es de negociación de protocolo. En este paquete, el cliente envía una lista de todos los dialectos que es capaz de entender. En el paquete response, el servidor le indica con qué dialecto se realizará la comunicación o que no entiende ninguno de los dialectos enviados por el cliente. Seguridad: un share es un servidor (típicamente una carpeta de archivos o una impresora) que está marcada como disponible para compartir para los clientes CIFS. El acceso restringido a un share se logra de dos maneras: User level security: indica que el cliente que desea acceder a un share debe proveer un nombre de usuario y una contraseña. Esto le da al administrador un control preciso sobre quién accedió a un determinado share. Este tipo de seguridad es empleado en Windows NT y Share level security: indica que el propio share requiere una contraseña para acceder, pero no es necesario un nombre de usuario. Esto implica que no se establece la identidad del usuario que accede al recurso. Por ejemplo, se establece la contraseña xxx para usar una impresora. Cualquier usuario que conozca la contraseña xxx puede imprimir, pero no se tiene control acerca de quién exactamente utilizó el recurso. Esto impide además estableces derechos particulares para cada usuario. Este tipo de seguridad es empleada en Windows 95 y 98. Encriptación: para cualquiera de las formas de seguridad descriptas arriba, el password es enviado encriptado al servidor. Hay dos métodos de encriptación que se utilizan habitualmente: el NT style y el Lan Manager style. Ambos métodos usan autenticación challengeresponse, en la que el servidor envía al cliente un string y espera una 12

14 respuesta que pruebe que el cliente conoce el string aleatorio y el password de usuario. Command batching: muchos de los paquetes CIFS soportan piggyback de otros paquetes, lo que permite reducir la latencia de respuesta y un uso más eficiente del ancho de banda. A esta técnica se la conoce como ANDX batching. Oplock: cuando un paquete CIFS pide abrir un archivo, se puede solicitar un opportunistic lock (oplock). Si es permitido por el servidor, el oplock avisa al cliente si no hay otros clientes accediendo al archivo. En este caso, el cliente puede hacer todos los cambios que desee al archivo sin tener que escribirlos en el servidor inmediatamente. Hay varios tipos de oplocks Header de los paquetes Cada paquete request y response de CIFS usa un header como el siguiente: Header: el comienzo de cada paquete CIFS contiene un header de 4 bytes. El primer byte es 0xFF, seguido por la representación ASCII de las letras S, M y B. 13

15 Command: contiene un código de 1 byte indicando el tipo de paquete CIFS. Ejemplos de códigos pueden ser: SMB_COM_READ_ANDX: 0x2E, SMB_COM_TREE_CONNECT: 0x70, SMB_COM_NEGOTIATE: 0x72 Error class: el servidor indica si un request ha sido o no exitoso mediante el campo error class. Cuando no hay error, el campo vale cero. Valores distintos de cero indican error, los que pueden ser: ERRDOS (0x01): error del núcleo del sistema operativo ERRSRV (0x02): error generado por el administrador de archivos del servidor ERRHRD (0x03): error de hardware ERRCMD (0xFF): error en el comando enviado Error code: este campo de 16 bits indica el tipo de error que ha ocurrido. Cuando no hay errores vale cero. Cuando el valor es distinto de cero, este código, en conjunto con el Error class, puede utilizarse para obtener una descripción completa del error, por ejemplo, Bad password o File does not exist. Como en el caso del campo Error class, este campo es modificado solamente por el servidor en respuesta a un comando enviado por el cliente. Flags: la mayoría de los 8 bits en el campo Flags especifican opciones particulares. El más importante es el bit 3, que cuando vale 0 indica que todas las rutas en este paquete son case sensitive, mientras que cuando vale 1, indica que son caseless. Flags2: especifica más opciones. Los bits que son útiles son: Bit 0: si vale 1, indica que el servidor debe devolver nombre largos de archivos en la respuesta. Bit 6: si vale 1, indica que todas las rutas en el request son nombres largos. Bit 16: si vale 1, indica que los strings en el paquete están en Unicode. 14

16 Pad/Security signature: este campo generalmente se llena con ceros. Tree ID (TID): el TID es un número de 16 bits que indica a qué recurso se está refiriendo el paquete. Cuando los paquetes que se intercambian no hacen referencia a ningún recurso, este número no tiene significado y es ignorado. Si el cliente desea tener acceso a un recurso, envía un paquete CIFS con el campo Command con el valor SMB_TREE_CONNECT_ANDX. Se debe especificar también el nombre del share o de la impresora (por ejemplo, \\SERVER\DIR). El servidor verifica que el recurso exista y que el cliente tenga permisos de acceso, y luego envía un response indicando que la operación fue exitosa. En el paquete de respuesta, el servidor establecerá el TID a un número cualquiera, y a partir de ese momento, si el cliente desea hacer requests específicos para ese recurso, lo hará con un paquete con el TID conteniendo el valor que le fue pasado en un principio. Process ID (PID): este campo de 16 bits identifica el proceso del cliente que está realizando el request. El servidor utiliza este número para verificar distintas cuestiones de concurrencia. User ID (UID): este campo de 16 bits indica el usuario que está haciendo el request. El cliente debe obtener el UID desde el servidor enviando un Session setup request conteniendo nombre de usuario y contraseña. Luego de verificar estos datos, el servidor responde con el UID correspondiente, que es válido solamente para la sesión actual. El cliente usará este UID para todos los request posteriores. Si alguno de estos requests requiere permisos para acceder a un recurso, el servidor controlará que el UID posea los permisos necesarios para realizar la operación. Si un servidor está operando en modo Share level security, el campo UID es ignorado. Multiplex ID (MID): este campo de 16 bits permite la existencia de múltiples request pendientes de respuesta de manera simultánea. Cada vez que un cliente envía un paquete, primero chequea si hay algún request que todavía no ha sido respondido y, en ese caso, le asigna al nuevo request un MID diferente al anterior. Cada vez que el servidor responde, el paquete response debe poseer un MID idéntico al paquete 15

17 request que lo originó. De esta forma, el cliente sabe a que request corresponde el response que está recibiendo. WordCount y Parameter Words: los paquetes CIFS usan estos dos campos para poner datos específicos de los comandos. Los headers CIFS como los de la figura no pueden contener todos los posibles datos de todos los posibles paquetes CIFS. Para remediar esta situación, se creó el campo Parameter Words con longitud variable. El WordCount especifica cuántas palabras de 16 bits contiene el campo Parameter Words. De esta forma, cada paquete CIFS se puede ajustar al tamaño necesario para transportar los datos requeridos por el comando. El WordCount es generalmente constante para cada tipo de paquete y está definido en el borrador de CIFS 1.0. Hay dos WordCounts definidos para cada comando, uno para el request del cliente y otro para el response del servidor. Ambos son necesarios ya que la cantidad de datos requeridos para hacer el request no necesariamente es la misma que para hacer el response. ByteCount y Buffer: estos dos campos son similares a los que acabamos de describir, ya que también contienen una cantidad variable de datos. El campo ByteCount especifica cuántos bytes contiene el campo Buffer. La principal diferencia con los anteriores es el tipo de datos que contienen, porque mientras el campo Parameter Words generalmente contiene unas pocas opciones de paquete, el campo Buffer es llenado con grandes cantidades de raw data (por ejemplo, el contenido de un archivo). 2.7 Ejemplos de secuencias de paquetes A continuación, se presentan dos ejemplos de intercambios CIFS típicos entre cliente y servidor. El primer ejemplo muestra qué paquetes son enviados cuando un cliente inicia una comunicación con el servidor: se establece la sesión NetBIOS, se negocia el dialecto CIFS, se envía el nombre de usuario y contraseña y, finalmente, se conecta a un recurso. El segundo ejemplo examina el paquete requerido para abrir un archivo y leerlo. 16

18 2.7.1 Ejemplo 1: Inicio de sesión, login y conexión a un recurso Cuando un cliente desea acceder a un recurso en un servidor CIFS, se realiza el siguiente intercambio de paquetes. Primero, se establece una sesión NetBIOS para lograr una secuencia de mensajes confiable. Luego, el cliente y el servidor negocian el dialecto CIFS que se usará en la comunicación. El cliente se identifica al servidor enviando su nombre de usuario y contraseña (en este ejemplo, el servidor opera en modo User level security, lo que significa que el usuario no puede acceder al share si no se identifica correctamente). Finalmente, el usuario se conecta al recurso deseado. Paquete 1: Request, Cliente Servidor Propósito: establecer la sesión NetBIOS Resumen: el cliente, que desea intercambiar paquetes CIFS con el servidor, inicia con éste una sesión NetBIOS (hace un llamado al servidor ). Esto permite una entrega confiable de mensajes entre ambos. Se debe notar que el cliente debe conocer el nombre NetBIOS del servidor para poder llamarlo y, además, debe indicar su propio nombre NetBIOS. Los pasos que se siguen son los siguientes: primero, el cliente establece una conexión TCP full-duplex con el puerto 139. Una vez finalizado esto, el cliente envía un paquete Session request a través de la conexión TCP. Este paquete contiene los nombres NetBIOS del cliente y del servidor y una constante numérica que indica que el propósito del paquete es establecer una sesión NetBIOS. Paquete 2: Response, Servidor Cliente Propósito: confirmación de inicio de sesión NetBIOS Resumen: si los datos enviados anteriormente por el cliente son correctos y están formateados de la manera correcta, el servidor responde con un paquete de 4 bytes llamado Session established acknowledgment, que indica que la sesión se pudo establecer exitosamente o devuelve un código de error. 17

19 Paquete 3: Request, Cliente Servidor Propósito: negociación del dialecto CIFS Resumen: una vez que se estableció la sesión NetBIOS, el cliente puede enviar el primer request real, enviando el comando SMB_COM_NEGOTIATE e incluyendo la lista de dialectos CIFS soportados. Paquete: Command: SMB_COM_NEGOTIATE (0x72) TID: ignorado PID: ID del proceso del cliente que envía el paquete UID: ignorado MID: un número único cualquiera WordCount: 0 Parameter Words: vacío, ya que WordCount es cero. ByteCount: 119 (valor variable, dependiendo de cuántos dialectos CIFS entienda el cliente) Buffer: contiene 119 bytes de diferentes descripciones de dialectos, por ejemplo: PC NETWORK PROGRAM 1.0, MICROSOFT NETWORKS 3.0, NT LM Paquete 4: Response, Servidor Cliente Propósito: elección del dialecto CIFS Resumen: el servidor responde al request anterior seleccionando el dialecto que desea para la comunicación. Paquete: 18

20 Command: SMB_COM_NEGOTIATE (0x72) TID: ignorado PID: ignorado UID: ignorado MID: un número igual al MID del request enviado por el cliente WordCount: depende del dialecto que se haya elegido. En este ejemplo, asumiremos que el servidor eligió NT LM 0.12, por lo que WordCount será igual a 17. Parameter Words: los 17 bytes de este campo indican el dialecto elegido y varias propiedades del servidor, como MaxMpxCount (cantidad máxima de request sin respuesta que puede iniciar el cliente) y algunos flags que indican si se soportan Unicode, nombres largos de archivos, comandos NT, etc. ByteCount: variable, usualmente mayor a 8. Buffer: generalmente contiene un string aleatorio de 8 bytes que el cliente utiliza en el siguiente paquete para encriptación. Paquete 5: Request, Cliente Servidor Propósito: login de usuario Resumen: el cliente envía su nombre de usuario y contraseña para obtener su User ID (UID). Este paquete, además, se usa para transmitir al servidor las propiedades del cliente, por lo que el paquete debe ser enviado aunque el servidor esté en Share level security. Paquete: Command: SMB_COM_SESSION_SETUP_ANDX (0x73) TID: ignorado 19