To protect against SMB session hijacking, NT supports a cryptographic integrity
mechanism, SMB Signing, to prevent active network taps from interjecting
themselves into an already established session. See KB Q161372. Caution: packet signing will introduce a 10%-15%
performance hit and to be effective, workstations and servers need to be
configured for SMB signing.
Hive: HKEY_LOCAL_MACHINE
Key: SYSTEM\CurrentControlSet\Services\LanManServer\Parameters
Name:
EnableSecuritySignature
Type: REG_DWORD
Value: 1
Key: SYSTEM\CurrentControlSet\Services\Rdr\Parameters
Name:
RequireSecuritySignature
Type: REG_DWORD
Value: 0
If you set RequireSecuritySignature=1 on servers,
the registry setting ensures that the Server communicates with only those
clients that are support message signing. BEWARE:
older clients will fail to connect to servers that have this key configured.
Similarly, the clients with RequireSecuritySignature
set will not be able to connect to servers which do not have message signing
support. A little looser but more reasonable approach is to set RequireSecuritySignature=0 and EnableSecuritySignature=1. Then if both ends of the
converstation have been configured for SMB Signing, it will work and if one or
the other is not configured, communication can still occur. Setting RequireSecuritySignature=1 on either the server or
workstation is for environments with quite sensitive data as a rule.
The need for SMB signing has become less theoretical with the release of the
hacker tool SmbRelay which
automates a man-in-the-middle attack against the SMB protocol.
See also Q199714 – Cannot Join Domain Because of SMB Signing .
