El protocolo SMB

Puesto que Samba es, fundamentalmente, una implementacin para Unix del protocolo SMB, quizs la mejor forma de entender Samba es comenzar por describir SMB con un poco ms de detalle. Esta seccin realiza una pequea revisin de este protocolo. SMB es un protocolo de comunicacin de alto nivel que puede implementarse sobre diversos protocolos como TCP/IP, NetBEUI y IPX/SPX, tal como muestra la Figura 4.1, Protocolos sobre los que puede implementarse SMB., junto con la ubicacin de dichos protocolos en los niveles OSI y en la pila TCP/IP. Entre todas esas alternativas, tanto en el caso de Samba como de Windows 2000/XP, SMB se implementa habitualmente encima de NetBIOS sobre TCP/IP (esta alternativa se ha convertido en el estndar de facto para compartir recursos entre sistemas Windows). Sin embargo, no incidiremos ms en los protocolos que soportan SMB o en su implementacin, puesto que todo ello queda fuera del contexto de este tema. Protocolos sobre los que puede implementarse SMB. Histricamente, este protocolo fue desarrollado inicialmente por IBM como el IBM PC Network SMB Protocol o Core Protocol a principios de los aos 80. Desde entonces, diversos fabricantes (especialmente Microsoft) han ido ampliando su funcionalidad progresivamente, creando diferentes variantes (versiones) de SMB. Desafortunadamente, en ocasiones el cambio de versin ha conllevado el rebautizar el propio 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 aos, CIFS (Common Internet File System). Todos ellos, por tanto, hacen referencia a SMB, aunque se diferencien en algunos detalles de su funcionalidad y/o implementacin. Si nos fijamos en su interfaz, SMB es un protocolo de tipo cliente/servidor, donde el ordenador "servidor" ofrece recursos (archivos, impresoras, etc.) que pueden ser utilizados remotamente por los ordenadores "cliente" a travs de la red. Asimismo, es un protocolo de los denominados peticin/respuesta, indicando que las comunicaciones se inician siempre desde el cliente como una peticin de servicio al servidor (dicha peticin se denomina precisamente SMB), que la procesa y retorna una respuesta a dicho cliente. (En realidad, existe un caso en que el servidor enva un mensaje al cliente sin haber recibido una peticin de ste, pero la discusin del protocolo a ese nivel queda fuera del mbito de este texto). La respuesta del servidor puede ser positiva (con el resultado de procesar la peticin del cliente) o negativa (mensaje de error), en funcin del tipo de peticin, la disponibilidad del recurso, el nivel de acceso (permisos) del cliente, etc. El siguiente aspecto relevante de SMB es saber qu mecanismos de autentificacin soporta este protocolo para controlar el acceso del cliente a los recursos compartidos. En concreto, SMB soporta dos modos de autentificacin alternativos, denominados share y user:

Cuando compartimos un recurso en modo share, la proteccin de dicho recurso recae en una contrasea 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 autentificacin por defecto en las implemementaciones de SMB para Windows 9X, por ejemplo). Sin embargo, en modo user, el servidor recibe incialmente del sistema cliente unas credenciales de usuario (nombre, dominio y contrasea), que debe autentificar para autorizar el acceso al recurso. Concretamente, si el dominio de las credenciales es conocido, la autentificacin se delega a algn controlador de dicho dominio; y en caso contrario, el usuario y la contrasea 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 funcin de qu permisos posee sobre dicho recurso el usuario cuyas credenciales se han enviado desde el cliente. En otras palabras, una vez el sistema servidor ha identificado y autentificado al usuario que desea conectarse al recurso, este sistema dispone ya de un SID vlido 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 cuestin 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 autentificacin por defecto en las versiones de SMB de sistemas Windows NT y posteriores.

Finalmente, revisaremos brevemente el funcionamiento interno del protocolo SMB, utilizando para ello un ejemplo concreto. Supongamos que un sistema cliente desea acceder a una carpeta compartida que exporta el servidor (en modo user). En este escenario, se producira el siguiente intercambio de mensajes entre ellos: 1. Peticin: Sesin NetBIOS. El objetivo de este mensaje es establecer una sesin fiable para subsiguientes mensajes entre los ordenadores cliente y servidor. Es imprescindible que el cliente conozca el nombre NetBIOS del servidor para poder alcanzarlo; el nombre NetBIOS del cliente es parte del mensaje, por lo que ambos saben quin es el otro. 2. Respuesta: Sesin NetBIOS. Si no hay error en el mensaje anterior, el servidor enva un mensaje de reconocimiento (ACK), aceptando la conexin. 3. Peticin: Dialecto SMB. El cliente enva en este mensaje una lista con los dialectos o variantes de SMB que soporta, puesto que es habitual que un sistema Windows soporte varias versiones de SMB simultneamente. 4. Respuesta: Dialecto SMB. El servidor contesta con el dialecto que prefiere para la comunicacin subsiguiente, o un cdigo de error si no soporta ninguna de las alternativas ofrecidas por el cliente. 5. Peticin: Inicio de sesin. El cliente enva las credenciales de usuario (usuario, dominio,contrasea) con las que ste desea conectarse al servidor. Recurdese que por defecto, se emplean las credenciales con las que el usuario se conect interactivamente al sistema cliente, pero se pueden especificar otras explcitamente. 6. Respuesta: Inicio de sesin. El servidor autentifica las credenciales de usuario (ver modo user descrito arriba). Si las credenciales son buenas, el servidor posee ya un SID vlido que le permite, antes que nada, comprobar si el usuario posee el derecho de conectarse al servidor (directiva "tener acceso a este equipo desde la red"). En caso afirmativo, se acepta la conexin y el servidor construye un identificador numrico particular para esa coexin (denominado User ID o UID) que devuelve al

cliente. Los UIDs pueden ser reutilizados durante la vida del sistema, pero son nicos para todas las conexiones simultneas que mantiene el servidor en un momento dado, por lo que identifican unvocamente una conexin (aceptada). Todos los mensajes posteriores del cliente deben contener este identificador para ser aceptados por el servidor. Por otro lado, si las credenciales estaban mal (o si los derechos eran insuficientes), el servidor enva un cdigo de error en lugar del UID. 7. Peticin: Conexin a un recurso concreto. El cliente enva entonces un mensaje que contiene una cadena que identifica el recurso al que desea acceder (por ejemplo, \\pc01\impresora o \\pc01\carpeta). 8. Respuesta: Conexin a un recurso concreto. Si el recurso solicitado por el cliente existe (y el SID asociado a la conexin posee suficientes permisos), el servidor construye un identificador denominado Tree ID o TID, que ser utilizado por el cliente para hacer referencia a dicho recurso en posteriores mensajes de esa conexin. Tras esta secuencia tpica de conexin al recurso (carpeta compartida), y si todo ha fucionado correctamente, el sistema cliente ya est en condiciones de acceder a la carpeta. Mediante el envo de los SMBs correspondientes, el cliente ya puede abrir archivos, leerlos, modificarlos, etc., utilizando siempre los identificadores (UID y TID) que el servidor ha construido durante el intercambio de mensajes inicial.

Captulo 9. Sistema de archivos de red (NFS)

Un Sistema de archivos de red (NFS) permite a los hosts remotos montar sistemas de archivos sobre la red e interactuar con esos sistemas de archivos como si estuvieran montados localmente. Esto permite a los administradores de sistemas consolidar los recursos en servidores centralizados en la red. Este captulo se centra en los conceptos fundamentales de NFS e informacin suplementaria. Para instrucciones especficas con respecto a la configuracin y operacin del software NFS en servidores o clientes, vea el captulo titulado Sistema de archivos de red (NFS) en el Manual de administracin del sistema de Red Hat Enterprise Linux.

9.1. Funcionamiento
Hay tres versiones de NFS actualmente en uso. La versin 2 de NFS (NFSv2), es la ms antigua y est ampliamente soportada por muchos sistemas operativos. La versin 3 de NFS (NFSv3) tiene ms caractersticas, incluyendo manejo de archivos de tamao variable y mejores facilidades de informes de errores, pero no es completamente compatible con los clientes NFSv2. NFS versin 4 (NFSv4) incluye seguridad Kerberos, trabaja con cortafuegos, permite ACLs y utiliza operaciones con descripcin del estado. Red Hat

Enterprise Linux soporta clientes tanto NFSv2, NFSv3 como NFSv4, y cuando monta un sistema de archivos a travs de NFS, Red Hat Enterprise Linux usa NFSv4 por defecto. Todas las versiones de NFS pueden utilizar el Protocolo de control de transmisiones (TCP) ejecutndose sobre una red IP. En el caso de NFSv4, ste lo requiere. NFSv2 y NFSv3 pueden utilizar el Protocolo de datagrama de usuarios (UDP) sobre una red IP para proporcionar conexiones de red sin supervisin (stateless) entre el cliente y el servidor. Cuando se utiliza NFSv2 o NFSv3 con UDP, bajo condiciones normales la conexin UDP desatendida minimiza el trfico de la red, ya que el servidor NFS envia un cookie al cliente despus que este tiene acceso al volumen compartido. Esta cookie es un valor aleatorio guardado en el lado del servidor y es pasado junto con las peticiones RPC desde el cliente. El servidor NFS puede ser reiniciado sin afectar a los clientes y las cookies permanecen intactas. Sin embargo, debido a que UDP es sin supervisin, si el servidor se cae de forma inesperada, los clientes UDP continan saturando la red con peticiones para el servidor. Por esta razn, TCP es el protocolo preferido cuando se conecte a un servidor NFS. Cuando se autentifique utilizando NFSv4, se crea una conexin atenta y, de forma opcional, est disponible la autenticacin de usuarios y grupos con Kerberos. NFSv4 no tiene interaccin con portmapper, rpc.mountd, rpc.lockd y rpc.statd, pues estos han sido incorporados en el kernel. NFSv4 escucha en el puerto TCP 2049.
Nota

TCP es el protocolo por defecto para NFS bajo Red Hat Enterprise Linux. Consulte el captulo llamado Sistema de archivos de red (NFS) en el Manual de administracin del sistema de Red Hat Enterprise Linux para ms informacin sobre la conexin a servidores NFS usando TCP. UDP se puede utilizar para propsitos de compatibilidad si se necesita, pero no es recomendado para uso general. La nica vez que NFS lleva a cabo la autentificacin es cuando el cliente intenta montar un recurso compartido NFS. Para limitar el acceso al servicio NFS, se utilizan envolturas TCP (TCP wrappers). Los TCP wrappers leen los archivos /etc/hosts.allow y /etc/hosts.deny para determinar si a un cliente particular o red tiene acceso o no al servicio NFS. Para ms informacin sobre cmo configurar los controles de acceso con envolturas TCP (TCP wrappers), consulte el Captulo 17. Despus de que al cliente se le permite acceso gracias a un TCP wrapper, el servidor NFS recurre a su archivo de configuracin, /etc/exports, para determinar si el cliente tiene suficientes privilegios para acceder a los sistemas de archivos exportados. Una vez otorgado el acceso, todas las operaciones de archivos y de directorios estn disponibles para el usuario.

Aviso

Si se est utilizando NFSv2 o NFSv3, los cuales no son compatibles con la autenticacin Kerberos, los privilegios de montaje de NFS son otorgados al host cliente, no para el usuario. Por lo tanto, se puede acceder a los sistemas de archivos exportados por cualquier usuario en un host cliente con permisos de acceso. Cuando se configuran las unidades compartidas NFS, tenga mucho cuidado de cules hosts obtienen permisos de lectura/escritura (rw).
Importante

Para que NFS funcione con una instalacin de Red Hat Enterprise Linux con un cortafuegos instalado, se debe configurar IPTables con el puerto predeterminado TCP 2049. Sin una configuracin IPTables, NFS no funcionar correctamente. El script de inicializacin NFS y el proceso rpc.nfsd ahora permiten la vinculacin a cualquier puerto especificado durante el inicio del sistema. Sin embargo, esto puede ser susceptible a errores si el puerto no est disponible o si entra en conflicto con otro demonio.

9.1.1. Servicios requeridos

Red Hat Enterprise Linux utiliza una combinacin de soporte a nivel del kernel y procesos demonio para proporcionar los archivos compartidos con NFS. NFSv2 y NFSv3 confa en las Llamadas de procedimientos remotos ((RPC)) para enrutar peticiones entre clientes y servidores. Los servicios RPC bajo Linux son controlados por el servicio portmap. Para compartir o montar sistemas de archivos NFS, los servicios siguientes funcionan juntos, dependiendo de cul versin de NFS se tenga implementada:

Inicia los procesos RPC apropiados para servir peticiones para los sistemas de archivos compartidos NFS. nfslock Un servicio opcional que inicia los procesos RPC adecuados para permitir que clientes NFS bloqueen archivos en el servidor. portmap El servicio RPC para Linux; responde a las peticiones para servicios RPC y configura las conexiones al servicio RPC solicitado. No se utiliza con NFSv4.
nfs

Los siguientes procesos RPC facilitan los servicios NFS:

Este proceso recibe las peticiones de montaje desde clientes NFS y verifica que el sistema de archivos solicitado est actualmente exportado. Este proceso es iniciado automticamente por el servicio nfs y no requiere de la configuracin del usuario. No se utiliza con NFSv4. rpc.nfsd Este proceso es el servidor NFS. Trabaja con el kernel Linux para satisfacer las demandas dinmicas de clientes NFS, tales como proporcionar hilos
rpc.mountd

del servidor cada vez que se conecta un cliente NFS. Este proceso corresponde al servicio nfs. rpc.lockd Un proceso opcional que permite a los clientes NFS bloquear archivos en el servidor. Esto corresponde al servicio nfslock. No se utiliza con NFSv4. rpc.statd Este proceso implementa el protocolo RPC Network Status Monitor (NSM) el cual notifica a los clientes NFS cuando un servidor NFS es reiniciado luego de haber sido apagado abruptamente. Este proceso es iniciado automticamente por el servicio nfslock y no requiere configuracin por parte del usuario. No se utiliza con NFSv4. rpc.rquotad Proporciona informacin de cuotas de usuario para los usuarios remotos. Este proceso se inicia automticamente por el servicio nfs y no requiere configuracin por parte del usuario. rpc.idmapd Este proceso proporciona al cliente y servidor NFSv4 llamadas ascendentes (upcalls) que hacen corresponder los nombres NFSv4 (los cuales son cadenas en la forma usuario@dominio) y los UIDs y GIDs locales. Para que idmapd funcione con NFSv4, el /etc/idmapd.conf debe estar configurado. Se requiere este servicio para su uso con NFSv4. rpc.svcgssd Este proceso proporciona al servidor los mecanismos de transporte para el proceso de autenticacin (Kerberos versin 5) con NFSv4. Se requiere este servicio para su uso con NFSv4. rpc.gssd Este proceso proporciona al cliente los mecanismos de transporte para el proceso de autenticacin (Kerberos versin 5). Se requiere este servicio para su uso con NFSv4.

9.1.2. NFS y portmap

Nota

La seccin siguiente solamente aplica para las implementaciones NFSv2 o NFSv3 que requieren del servicio portmap para la compatibilidad hacia atrs. El servicio portmap bajo Linux asigna las peticiones RPC a los servicios correctos. Los procesos RPC notifican a portmap cuando comienzan, revelando el nmero de puerto que ellos estn supervisando y el nmero de programas RPC que esperan servir. El sistema cliente entonces contacta con el portmap del servidor con un nmero de programa RPC particular. Entonces portmap redirecciona al cliente al nmero del puerto apropiado para que se comunique con el servicio solicitado. Como los servicios basados en RPC confian en portmap para hacer todas las conexiones con las peticiones de clientes entrantes, portmap debe estar disponible antes que cualquiera de esos servicios comience.

El servicio portmap puede utilizar TCP wrappers para el control de acceso, y las reglas de control de acceso para portmap afectan a todos los servicios basados en RPC. Alternativamente, es posible especificar reglas de control de acceso para cada demonio RPC NFS. Las pginas man para rpc.mountd y rpc.statd contienen informacin relativa a la sintaxis precisa de estas reglas.
9.1.2.1. Resolucin de problemas de NFS y portmap

Como portmap proporciona la coordinacin entre servicios RPC y los nmeros de puertos usados para comunicarlos, es til poder visualizar el estado de los servicios RPC actuales usando portmap cuando estamos resolviendo algn problema. El comando rpcinfo muestra cada servicio basado en RPC con su nmero de puerto, nmero de programa RPC, versin y tipo de protocolo (TCP o UDP). Para asegurarse que estn activos los servicios NFS basados en RPC para portmap, use el comando siguiente como root:
rpcinfo -p

A continuacin se presenta una muestra de la salida de este comando:

program vers proto 100000 2 tcp 100000 2 udp 100021 1 udp 100021 3 udp 100021 4 udp 100021 1 tcp 100021 3 tcp 100021 4 tcp 100011 1 udp 100011 2 udp 100011 1 tcp 100011 2 tcp 100003 2 udp 100003 3 udp 100003 2 tcp 100003 3 tcp 100005 1 udp 100005 1 tcp 100005 2 udp 100005 2 tcp 100005 3 udp 100005 3 tcp port 111 111 32774 32774 32774 34437 34437 34437 819 819 822 822 2049 2049 2049 2049 836 839 836 839 836 839 portmapper portmapper nlockmgr nlockmgr nlockmgr nlockmgr nlockmgr nlockmgr rquotad rquotad rquotad rquotad nfs nfs nfs nfs mountd mountd mountd mountd mountd mountd

La salida de este comando revela que los servicios NFS correctos se estn ejecutando. Si uno de los servicios NFS no comienza correctamente, portmap puede ser incapaz de corresponder las peticiones RPC de los clientes para ese servicio con sus respectivos puertos. En muchos casos, si NFS no est presente en la salida de rpcinfo, reiniciando

NFS provocar que estos servicios se registren correctamente con portmap y empiecen a funcionar. Para ms instrucciones sobre el inicio de NFS, consulte la Seccin 9.2. Estn disponibles otras opciones tiles para el comando rpcinfo. Para ms informacin, consulte la pgina man de rpcinfo.