While there are many SaaS based file storage solutions on the market, sometimes it is preferable to stick with corporate approved file storage. But what if you need to deploy a standard Windows 2008 file server and still take advantage of cheap storage in public cloud? What if you want to do it securely? In this blog entry I’ll outline a couple of ways you can leverage Halo to safely share files via a Windows server located in a public cloud. While this process was tested using Amazon AWS, it should work just as nicely in Rackspace, GoGrid or any other public IaaS cloud.
How Much Security Do You Need?
In this walkthrough we’ll use Halo GhostPorts to secure access to your Windows 2008 file server. This will ensure that evil folks on the Internet cannot try to brute force your accounts. In addition, there are two options available for setting up our file shares, both of which have benefits and drawbacks.
Straight Windows File Sharing
One possibility is to setup plain old Windows file sharing. On the plus side, this method is easy to deploy and is familiar to both Administrators and users. You can map drive shares, same as you would for an internal server. On the downside, Windows file sharing does not provide any data privacy. This means that anyone along the link can sniff the packets and see the contents of the files you are moving to and from the file server. Further, the session is vulnerable to connection hijacking and pass the hash attacks. So this is the least secure method of the two, but the easiest to deploy.
If you use this method to share files, you will be using GhostPorts to open TCP port 445 to your file server.
File Share Via WebDAV
Another possibility is to leverage Windows WebDAV to tunnel the file sharing session over HTTPS. On the plus side, HTTPS provides both data privacy and per packet authentication. This means an attacker sniffing the connection will only see encrypted data, and there are protections in place to prevent connection hijacking. Also, WebDAV has been implemented on multiple platforms so it is possible to make files available to more operating systems than just Windows. On the down side, setting up WebDAV via IIS takes a bit more time and effort. File sharing does not work quite the same way that it does for an internal file server. So this option is the most secure and versatile, but also the most difficult to implement.
If you use this method to share files, you will be using GhostPorts to open TCP port 443 to your file server.
Setting Up GhostPorts
There are multiple blog entries on setting up GhostPorts as well as deploying a firewall policy on Windows. I’ll skip the basic steps and jump right into showing you what the final firewall policy will look like:
Edit Firewall Policy Screen
In the first line of the firewall policy, I’ve setup the user “cbrenton-cp” with Remote Desktop Access. In the last two lines, I’ve setup the users “cbrenton-cp” and “tatiana” with GhostPort access to the file server.
Note that I’ve chosen to implement WebDAV via TCP port 443. If you decide to do simple file sharing instead, select “Add a new port” from the Service drop down menu. Name the port “SMB”, and define it as using TCP port 445. Use this newly created service instead of “https (tcp/443)”.
How It Will Work
To the Internet at large, the file server will appear to have no open ports. If the user “cbrenton-cp” properly authenticates to Halo GhostPorts, the TCP ports 3389 and 443 will now be accessible from cbrenton-cp’s source IP address. If the user “tatiana” properly authenticates to Halo GhostPorts, TCP port 443 will now be accessible from tatiana’s source IP address. In both cases, they will still need an account on the Windows server and they will still need to properly authenticate with the system. All GhostPorts is doing is ensuring that only validated users are able to access the appropriate TCP ports on the file server.