If you're adopting WAFS-type technology, don't forget that - like any WAN traffic - it needs to be secured against hackers.
One of the most important security provisions in Microsoft's ubiquitous Common Internet File System (CIFS) is Server Message Block signing.
SMB signing is a form of packet authentication. After users of a CIFS-based application are authenticated, SMB signing adds a digital signature to each packet transferred between client and server . The signatures verify that the identity of the server matches the credentials expected by the client, and vice versa. By verifying that every packet received comes from an authenticated source, the signature ensures the integrity of all communications.
The hashing algorithm used to create the digital signature adds noticeable computational overhead to the client and the server. On a high-speed LAN , Microsoft estimates this overhead as 10 to15 percent. But this layer of security is considered unnecessary on the LAN, and to maximise throughput, many organisations disable the SMB signing feature of CIFS. Or the server might have SMB signing enabled but not required, meaning any client with SMB signing disabled can still communicate.
The situation is different in the WAN , however, where traffic is vulnerable to man-in-the-middle attacks and hijacking. The need for SMB signing with wide-area file services (WAFS) solutions has been heightened recently with the widespread availability of a hacker tool called SmbRelay that automates a man-in-the-middle attack against the SMB protocol.
Signing protects against SMB session hijacking and other tampering by preventing a network tap from interjecting itself into an established session. SMB signing should therefore be considered a best practice for securing WAFS-based solutions that extend CIFS across the WAN.
There are two problems that the enterprise often encounters with WAFS solutions. The first is their failure to require (vs. merely enable) SMB signing. The second problem occurs after SMB signing is required, and session failures and/or poor WAN performance ensue. The computational overhead is not the culprit here. Rather, the problem results from the inability of some WAFS solutions to compress or otherwise accelerate digitally signed traffic in a fully reversible fashion.
In-line network-acceleration products that rely purely on traffic-interception techniques to implement protocol spoofing and packet compression, for example, can interfere with SMB signing because they don't restore the payload to its precise original contents. A change of just a single bit alters the result of the hashing algorithm that computes the digital signature. Accordingly, this class of products may force organisations to make a trade-off between WAN security and performance.
A more compatible way to implement WAFS for CIFS is a proxy that terminates the CIFS exchange at both ends of the connection. The proxy handles verification of the digital signatures at the source in the LAN, transmits the packets across the WAN, and then re-establishes a CIFS session with SMB signing at the destination. Of course, proxy-based solutions must ensure that packets traversing the WAN are signed or encrypted - or both - to preserve the security afforded by SMB signing.
The proxy approach also benefits the enterprises that deploy WAFS appliances by maintaining compatibility with other CIFS security and integrity features. These features include authentication with a challenge-response handshake, share-level protection and distributed file locking, read/write caching, and journalling and recovery provisions. By supporting Microsoft's CIFS in its native mode, enterprises need not sacrifice WAN security to improve WAN performance.
Mark Urban is director of product marketing at Packeteer.