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:

nfs 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.

Los siguientes procesos RPC facilitan los servicios NFS:

rpc.mountd 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

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 port

100000 2 tcp 111 portmapper

100000 2 udp 111 portmapper

100021 1 udp 32774 nlockmgr

100021 3 udp 32774 nlockmgr

100021 4 udp 32774 nlockmgr

100021 1 tcp 34437 nlockmgr

100021 3 tcp 34437 nlockmgr

100021 4 tcp 34437 nlockmgr

100011 1 udp 819 rquotad

100011 2 udp 819 rquotad

100011 1 tcp 822 rquotad

100011 2 tcp 822 rquotad

100003 2 udp 2049 nfs

100003 3 udp 2049 nfs

100003 2 tcp 2049 nfs

100003 3 tcp 2049 nfs

100005 1 udp 836 mountd

100005 1 tcp 839 mountd

100005 2 udp 836 mountd

100005 2 tcp 839 mountd

100005 3 udp 836 mountd

100005 3 tcp 839 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.