 |  |
14.4. Common Internet File System (CIFS) and Server Message Block (SMB)
The Common Internet File System (CIFS) is a general-purpose information-sharing protocol formerly known as Server essage Block (SMB). SMB is a message-based protocol developed by icrosoft, Intel, and IBM. SMB is best known as the basis for icrosoft's file and printer sharing, which is discussed further in Chapter 17, "File Transfer, File Sharing, and Printing". However, SMB is also used by many other applications. The CIFS standard extends Microsoft's usage of 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.4.1. Authentication and SMB
Because SMB runs on a number of machines with different authentication models, it supports several different levels of security. Two different types of authentication are possible, commonly called share level and user level. Samba, which is a popular SMB implementation for Unix, also refers to "server-level" authentication; this is a Samba-specific term used when user-level authentication is in effect but the Samba server is not authenticating users locally. This is not visible to the client. Samba is discussed further in Chapter 17, "File Transfer, File Sharing, and Printing".14.4.1.1. Share-level authentication
In share-level authentication, the initial SMB connection does not require authentication. Instead, each time you attach to a resource, you provide a password for that particular resource. This authentication is meant for servers running under operating systems that don't actually have a concept of users. Since it requires all users who wish to use a resource to have the same password, it's inherently insecure, and you should avoid it. It uses the same mechanisms to exchange passwords that are used for user-level authentication (which are described in detail in Chapter 21, "Authentication and Auditing Services"), but it does the password exchange during the tree connect instead of during session setup.
14.4.1.2. User-level authentication
User-level authentication occurs at the beginning of the SMB session, after dialect negotiation. If the negotiated dialect supports user-level authentication, the client provides authentication information to the server. The authentication information that's provided is a username and password; the method that's used to send it depends on the dialect. The password may be sent in cleartext or established via challenge-response. User-level authentication is discussed in detail in Chapter 21, "Authentication and Auditing Services", because it is used for logon authentication as well as for authenticating users who are connecting to file servers.any SMB servers that do user-level authentication provide guest access and will give guest access to clients that fail to authenticate for any reason. This is meant to provide backward compatibility for clients that cannot do user-level authentication. In most configurations, it will also provide access to a number of files to anybody that is able to ask. You should either disable guest access or carefully control file permissions.
14.4.2. Packet Filtering Characteristics of SMB
SMB is generally done over NetBT session service at TCP port 139. It is theoretically possible to run it over NetBT datagram service at UDP port 138, but this is extremely rare. As of Windows 2000, SMB can also be run directly over TCP/IP without involving NetBT, in which case it uses TCP or UDP port 445 (again, although UDP is a theoretical possibility, it does not appear to occur in practice).| Direction | Source Addr. | Dest. Addr. | Protocol | Source Port | Dest. Port | ACK Set | Notes |
|---|---|---|---|---|---|---|---|
| In | Ext | Int | TCP | >1023 | 139, 445 |
[33]
|
Incoming SMB/TCP connection, client to server |
| Out | Int | Ext | TCP | 139, 445 | >1023 | Yes | Incoming SMB/TCP connection, server to client |
| In | Ext | Int | UDP | >1023 | 138, 445 |
[34]
|
Incoming SMB/UDP connection, client to server |
| Out | Int | Ext | UDP | 138, 445 | >1023 | Incoming SMB/UDP connection, server to client | |
| Out | Int | Ext | TCP | >1023 | 139, 445 | Outgoing SMB/TCP connection, client to server | |
| In | Ext | Int | TCP | 139, 445 | >1023 | Yes | Outgoing SMB/TCP connection, server to client |
| Out | Int | Ext | UDP | >1023 | 138, 445 | Outgoing SMB/UDP connection, client to server | |
| In | Ext | Int | UDP | 138, 445 | >1023 | Outgoing SMB/UDP connection, server to client |
[33]ACK is not set on the first packet of this type (establishing connection) but will be set on the rest.
[34]UDP has no ACK equivalent.Clients of any SMB protocol will often attempt to reach the destination host via NetBIOS name service as well. SMB will work even if these packets are denied, but you may log large numbers of denied packets. You should be aware of this and should not interpret name service requests from SMB clients as attacks. See Chapter 20, "Naming and Directory Services", for more information about NetBIOS name service.
14.4.3. Proxying Characteristics of SMB
SMB is not particularly difficult to proxy, but it is difficult to improve its security with a proxy. Because many things are implemented as general-purpose transactions, it's hard for a proxy to know exactly what effect an operation will have on the end machine. The proxy can't just track requests but also needs to track the filenames those requests refer to. In addition, the protocol allows for some operations to be chained together, so that a single transaction may include a tree connect, an open, and a read (for instance). This means that a proxy that is trying to control what files are opened has to do extensive parsing on transactions to make certain that no inappropriate opens are late in the chain. It is not sufficient to simply check the transaction type.
14.4.4. Network Address Translation Characteristics of SMB
SMB is normally run over NetBT, which includes embedded IP addresses but does not generally use them, as discussed earlier. In Windows 2000, it is also possible to run SMB directly over IP. In this mode, it does not have embedded IP addresses and should function with straightforward network address translation.
|  | |
| 14.3. NetBIOS over TCP/IP |  | 14.5. Common Object Request Broker Architecture (CORBA) and Internet Inter-Orb Protocol |
