DCE/RPC Target-Based Policies
Windows and Samba DCE/RPC implementations differ significantly. For example, all versions of Windows use the DCE/RPC context ID in the first fragment when defragmenting DCE/RPC traffic, and all versions of Samba use the context ID in the last fragment. As another example, Windows Vista uses the opnum (operation number) header field in the first fragment to identify a specific function call, and Samba and all other Windows versions use the opnum field in the last fragment.
There are also significant differences in Windows and Samba SMB implementations. For example, Windows recognizes the SMB OPEN and READ commands when working with named pipes, but Samba does not recognize these commands.
When you enable the DCE/RPC preprocessor, you automatically enable a default target-based policy. Optionally, you can add target-based policies that target other hosts running different Windows or Samba versions. The default target-based policy applies to any host not included in another target-based policy.
In each target-based policy, you can:
-
enable one or more transports and specify detection ports for each
-
enable and specify auto-detection ports
-
set the preprocessor to detect when there is an attempt to connect to one or more shared SMB resources that you identify
-
configure the preprocessor to detect files in SMB traffic and to inspect a specified number of bytes in a detected file
-
modify an advanced option that should be modified only by a user with SMB protocol expertise; this option lets you set the preprocessor to detect when a number of chained SMB AndX commands exceed a specified maximum number
In addition to enabling SMB traffic file detection in the DCE/RPC preprocessor, you can configure a file policy to optionally capture and block these files, or submit them to the Cisco AMP cloud for dynamic analysis. Within that policy, you must create a file rule with an Action of Detect Files or Block Files and a selected Application Protocol of Any or NetBIOS-ssn (SMB).
Note that for SMB connections, a destination port is assigned as the parent port and rule matching is done as per the rules set on the parent port. To explain this further, consider a scenario in which a control channel is formed on the destination port (for example, port 445). After the control channel is formed, a data channel is formed on another destination port. This means that a parent channel and a child channel is formed. Rule matching is done on the parent channel with the destination port as 445. After this is done, rule matching is not done on the child channel as connection rule matching is done only once. This also results in the creation of two events on the Management Center - one for the parent channel and one for the child channel. Both these channels are mapped against the same rule ID to which the parent channel is matched.