14.4. Common Internet File System (CIFS) and Server Message Block (SMB)

SMB is normally run on top of NetBT. Newer implementations also support SMB over TCP/IP directly; in this configuration, it is almost always called CIFS. Note that whatever this protocol is called, it is the exact same protocol whether it is run over NetBT or over TCP/IP directly, and that it was called CIFS even when it did not run over TCP/IP directly. We refer to it as "SMB" here mostly because it is used for a variety of things in addition to file sharing, and we find it misleading to refer to it as a filesystem in this context.

The SMB protocol provides a variety of different operations. Many of these are standard operations for manipulating files (open, read, write, delete, and set attributes, for instance), but there are also specific operations for other purposes (messaging and printing, for instance) and several general-purpose mechanisms for doing interprocess communication using SMB. SMB allows sharing not only of standard files, but also of other things, including devices, named pipes, and mailslots. (Named pipes and mailslots are mechanisms for interprocess communication; named pipes provide a data stream, while mailslots are message-oriented.) It therefore provides suitable calls for manipulating these other objects, including support for device controls (I/O controls, or ioctls) and several general-purpose transaction calls for communication between processes. It is also sometimes possible to use the same file manipulation calls that are used on normal files to manipulate special files.

In practice, there are two major uses for SMB; file sharing and general-purpose remote transactions. General-purpose remote transactions are implemented by running DCE RPC over SMB, through the sharing of named pipes. In general, any application is using DCE RPC over SMB if it says it uses named pipes; if it relies on \PIPE\something_or_other, \Named Pipe\something_or_other, or IPC$; if it requires port 138, 139, or 445; or if it mentions SMB or CIFS transactions. Applications that normally use this include NTLM authentication, the Server Manager, the Registry Editor, the Event Viewer, and print spooling.

Any time that you provide SMB access to a machine, you are providing access to all of the applications that use SMB for transactions. Most of these applications have their own security mechanisms, but you need to be sure to apply those. If you can't be sure that host security is excellent, you should not allow SMB access.

SMB introduces an additional complication for firewalls. Not only do multiple different protocols with very different security implications use SMB (thereby ending up on the same port numbers), but they can all use the very same SMB connection. If two machines connect to each other via SMB for one purpose, that connection will be reused for all other SMB protocols. Therefore, connection-oriented SMB must be treated like a connectionless protocol, with every packet a separate transaction that must be evaluated for security.

For instance, if a client connects to a server in order to access a filesystem, it will start an SMB session. If the client then wants to print to a printer on that server, or run an SMB-based program (like the User Manager or the Event Viewer) on that server, the existing connection will be reused.

In the most common uses of SMB, a client makes a NetBT session connection to a host and then starts an SMB session. At the beginning of the SMB session, the server and the client negotiate a dialect of SMB. Different dialects support different SMB features. Once the dialect has been negotiated, the client authenticates if the dialect supports authentication at this point, and then requests a resource from the server with what is called a tree connect. When the client creates the initial SMB connection and authenticates, it gets an identifier called a user ID or UID. If the client wants another resource, the client will reuse the existing connection and merely do an additional tree connect request. The server will determine whether the client is authorized to do the tree request by looking at the permissions granted to the UID. Multiple resource connections may be used at the same time; they are distinguished by an identifier called a tree ID or TID.

Not all SMB commands require a valid UID and TID. Obviously, the commands to set up connections don't require them, but others can be used without them, including the messaging commands, the echo command, and some commands that give server information. These commands can be used by anybody, without authentication.

14.3. NetBIOS over TCP/IP		14.5. Common Object Request Broker Architecture (CORBA) and Internet Inter-Orb Protocol

---

Copyright © 2002 O'Reilly & Associates. All rights reserved.