1.877.833.1202

Making the FileHold Server Internet Accessible

FileHold has been designed to work inside and outside of private networks. It is common for customers to share documents with users on the internet.

VERY IMPORTANT: There are risks to exposing your systems and documents on the internet. FileHold has been built with security best practices in mind, but we have no way to ensure our customers are completely safe on the internet. We recommend that you engage IT consultants with the appropriate skills and credentials necessary to safely expose your systems and documents to the internet. The information we share in our knowledgebase and documentation is provided for our customers' convenience to assist their IT professionals. We are unable to guarantee its suitability for any specific purpose beyond this information exchange. FileHold Systems Inc. is a software product provider. We do not provide internet security services.

Typical Options to Make FileHold Internet Accessible

There are a variety of methods to access the document management software remotely. Direct access, VPN tunnels, Windows Terminal Services, Windows Remote Desktop Services and Citrix XenApp are some of the most popular methods of secure remote access. The following are a few methods used by customers and resellers listed from most common to least common:

  • Windows Terminal Services / Remote Desktop Services: The desktop client, Microsoft Office, WebClient, etc. are all configured on the Terminal Server. Note that the FileHold server must be installed on a server that is different than the terminal server.

     

  • Citrix XenApp: This technology is very similar to Microsoft Terminal Services.

     

  • 2X Application Server: Various customers use this solution from 2X to deliver applications remotely.

     

  • Virtual Private Network (VPN) Access: This is very common and there are countless VPN solutions to use. A VPN solution allows remote users to access your private network from remote locations as though they were not remote.

     

  • Other Secure Remote Access Products: There are too many to list.

     

  • Secure HTTPS access to the Server: This makes your FileHold server accessible over the internet without the need for any special technology on the client computer. In addition to supporting browser access to our web client users may optionally install our desktop client. There are security risks to publicly exposing any server on the Internet.

     

External Secure HTTPS Access to FileHold on the Public Internet

IMPORTANT: These steps are offered as information only and intended to be interpreted by expert IT personnel. Qualified personnel should have a background in internet security, a strong knowledge of the Windows Server version your FileHold is installed on, and in publicly Hosting Windows servers. FileHold Systems Inc. does not offer these services.

FileHold is a web server based application and it needs to be secured properly when used on the public internet. It will operate well through a variety of correctly configured firewalls including reverse proxies. Your remote users can use the web client, mobile web client, desktop client, or a custom client to access FileHold. All communication with the FileHold server is using the HTTP or HTTPS protocol regardless of which client is used. Starting with FileHold version 14.1 you can configure multiple web client servers as needed.

Here are some of the things you should do to secure the system:

  1. Obtain a strong firewall to protect the FileHold server system.

     

  2. Create an easy to remember name for your server on the internet such as filehold.example.com and map it to the public IP address managed by your firewall. This name will need to be registered with your DNS service provider. The sub-domain filehold is used for this example, but this can be any value that fits your IT environment. It should match the name given to your FileHold server.

     

  3. Port forward Port 80 (HTTP) or Port 443 (HTTPS) in the firewall for all requests from the public IP address to the internal IP address of the FileHold server.

     

  4. Generate an SSL certificate for your domain name such as filehold.example.com and install it on IIS. We recommend using a commercial certificate provider to assure your external users that they are accessing your true FileHold server. An example of installing the SSL certificate is available in Installing SSL on the FileHold Server for Windows 2008 x64 IIS 7 guide.

     

  5. If you are using the secure HTTPS protocol you should run the FileHold Server based FHInstrumentation tool to automatically change all web.config files to enable HTTPS. Restart IIS as stated in the Installing SSL on the FileHold Server for Windows 2008 x64 IIS 7 guide.

     

  6. An IT security expert should perform regular vulnerability tests on your public IP address to identify potential security flaws and apply any recommended hardening practices to your network, Windows and IIS servers.

Configuration examples

A large number of configurations are possible to enable internet access for FileHold. Two examples are shown below. The application can be hosted with on or off premise hardware, a private, or a public cloud.

Configuration example - simple

This example shows a simple single FileHold server configuration that includes SQL server co-located on the same machine. There is one level of security protection from the internet that all client types can access. This configuration would also work for custom clients.

external users simple configuration example

Configuration example - multi-level security with separate web client server

This example separates the web client server to allow it to be located in a DMZ while the application server remains in a more secure internal network. Since the web client server is the only server exposed to the internet there is no chance for connectivity to the desktop application or custom clients as the application server is hidden from the internet. If needed, certain clients can be disabled in the web-client-only server to further isolate access. For example, the guest portal could be exposed while the mobile and full web client are disabled for internet access.

External users web client only configuration example

Common options for hardening IIS and Windows Server

By default IIS and Windows Server is configured to be suitable for a wide variety of uses such as testing and development. Some of the features needed to support these uses can be disabled when a server is in production to help protect it from outside threats. There are a number of common options that can help to harden your server. This is not intended to be an exhaustive list and each option should be confirmed and implemented by a qualified Windows and IIS administrator. The necessary web config files are located on each FileHold server running the web client (including guest portal), mobile web client, and Courier client.

IMPORTANT: FileHold Systems Inc. does not control the content at the following links.

Tools

There are free and low cost tools to help make sure your server is secure. While we cannot endorse any of them for any specific circumstance, we present them for you to evaluate their effectiveness on your own.

https://www.nartac.com/Products/IISCrypto
https://www.ssllabs.com/ssltest/

Version disclosure

The HTTP header includes the X-AspNet-Version and or the Server attribute. These attributes may be helpful for development, but not for production. They reveal internal details of the system that could be exploited. The following link has information for preventing version disclosure.

http://blogs.msdn.com/b/varunm/archive/2013/04/23/remove-unwanted-http-response-headers.aspx

HTTP options disclosure

The HTTP protocol provides a method for determining the options that are supported by the server. Normal browsing does not make use of this method, but a malicious user might use the method to prepare more advanced attacks on the server. The following links provide information about filtering requests like this.

https://www.iis.net/configreference/system.webserver/security/requestfiltering/verbs
http://www.acunetix.com/blog/articles/8-tips-secure-iis-installation/

Insecure cookies

FileHold uses cookies to maintain the session between the browser and web server. By default the server makes these cookies available for many purposes other than use with FileHold. The HttpOnly flag can be set to limit the cookie from being used in a client side script and thus making it less prone to being stolen in a cross-site scripting attack. The Secure flag can be set to ensure the cookie is only sent over encrypted connections and reduce the chance of it being stolen in a sniffing attack. The following link describes the setting needed to control these flags.

https://msdn.microsoft.com/en-us/library/ms228262%28v=vs.100%29.aspx

Clickjacking

A user interface redress attack inserts links into a web page making it appear as though it is from a known site when really it is a trick to get the user to click on malicious links. The X-Frame-Options header can be added to the HTTP response to tell the browser to allow rendering a page inside a frame or iframe. By setting this option the site can ensure their content is not embedded into a malicious sites. The following link described the steps needed to add this header.

https://support.microsoft.com/en-us/kb/2694329

RC4 cipher weakness

This cipher is used to encrypt data in older security protocols, but there have been well documented methods to use these protocols as an attack vector due to weaknesses in the RC4 cipher. By default this cipher is enabled in many versions of Windows Server / IIS. This cipher can be disabled on your Windows Server, but there is a risk a small number of older clients may be prevented from accessing your server. As these clients are likely insecure for many other reasons, this seems to be a reasonable risk to take.

https://en.wikipedia.org/wiki/RC4
https://blog.qualys.com/ssllabs/2013/03/19/rc4-in-tls-is-broken-now-what
https://support.microsoft.com/en-ca/kb/2868725

SSL3 protocol deprecated

The SSL3 protocol is the subject of a well documented vulnerability called POODLE, but it is enabled by default in older servers. It has been deprecated by the Internet Engineering Task Force (IETF).

https://en.wikipedia.org/wiki/Transport_Layer_Security#SSL_1.0.2C_2.0_and_3.0
https://blog.qualys.com/ssllabs/2014/10/15/ssl-3-is-dead-killed-by-the-poodle-attack​
https://support.microsoft.com/en-ca/kb/187498
https://tools.ietf.org/html/rfc7568

Weak Diffie-Hellman key exchange

This key exchange may be enabled on a server despite having been shown to allow a couple of different types of server attacks. Disabling it should have no adverse impact to clients.

https://weakdh.org/sysadmin.html