Wide Area File Service (WAFS) is used extensively in WAN application acceleration appliances to overcome performance limitations in LAN-oriented protocols like the ubiquitous Common Internet File System (CIFS) from Microsoft. CIFS is an example of an extremely ‘chatty’ protocol that requires many back-and-forth data acknowledgements – or ‘conversations’ - in order to complete tasks like opening a file. Across a Local Area Network (LAN), that is not a problem. If, however, you open files over a Wide Area Network (WAN) connection, the network latency – or time it takes for the data to traverse the WAN link - slows the performance of the application to the point that opening a file over a WAN link can take many minutes, causing severe delays in WAN transactions and greatly impacting worker productivity.
Why is slow file access becoming such an acute issue? The answer is server consolidation. Server consolidation is driven by the need to save money on equipment and software licensing and minimize branch office IT management. The most significant driver, however, is securing corporate data. EU privacy laws and US Sarbanes Oxley legislation along with the understanding that corporate data is the lifeblood of the organization has motivated CIOs to consolidate data to one central location where it can be better secured. It is this centralization of data that creates the performance issues.
Beyond performance, however, there is also another very important issue to consider. Specifically, the issue of data validation, or ensuring that file data is not altered ‘in flight.’
Focus on Data Validation and Its Impact of Acceleration
For CIFS, Microsoft has embedded file security in as Server Message Block (SMB) Signing that protects packets from having their payloads altered by “man-in-the-middle” attacks and hijacking. Inside the firewall on the LAN, this form of protection could be considered optional. But in the WAN, especially when using the Internet, protecting the integrity of packets is of paramount importance.
SMB Signing is a form of packet authentication. After users of a CIFS-based application are themselves authenticated, SMB Signing adds a digital signature to each and every 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 both the client and the server. On a high-speed LAN Microsoft estimates this overhead to be in the range of 10-15 percent. Inside the perimeter protections of the LAN, the additional layer of security afforded by digital signatures is routinely considered to be unnecessary, and to maximize throughput, many organizations disable the SMB Signing feature of CIFS. In the alternate, the server might have SMB Signing enabled but not required, allowing any client with SMB Signing disabled to continue to communicate.
These configurations can cause sever problems across the WAN, however, where traffic is quite vulnerable to man-in-the-middle attacks and hijacking. The need for SMB Signing with 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, now be considered a best practice for securing WAFS-based solutions that extend CIFS across the WAN.
But there are two problems often encountered by the enterprise with WAFS solutions. The first is the failure to require (vs. merely enable) SMB Signing for use with WAFS. Often this occurs inadvertently after an enterprise has safely operated CIFS for years without requiring or enabling (or even intentionally disabling) this feature.
The second problem can occur after requiring SMB Signing, only to experience session failures and/or poor performance in the WAN. 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.
WAFS and SMB Signing – the Right Approach
Certain network acceleration products that rely purely on traffic interception techniques to implement protocol spoofing and packet compression, for example, can interfere with SMB Signing by not restoring 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 organizations to make a tradeoff between WAN security and performance.
A more compatible way to implement WAFS for CIFS is the 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 reestablishes a CIFS session with SMB Signing at the destination. Of course, proxy-based solutions must ensure that packets traversing the WAN are either signed or encrypted—or both—to preserve the security afforded by SMB Signing.
The Proxy approach also gives enterprises deploying WAFS appliances the additional benefit of maintaining compatibility with other CIFS security and integrity features. These include authentication with a challenge/response handshake, share-level protection and distributed file locking, read/write caching, and journaling and recovery provisions. By supporting CIFS in its native mode, enterprises need not sacrifice WAN security to improve WAN performance.
R S S feed
