Preparing the FileHold Server for Internet accessibility
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.
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 knowledge base 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:
- 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.
- 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.
- 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.
- Other Secure Remote Access Products: There are too many to list.
External secure HTTPS access to FileHold on the public Internet
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. only offers these services for our hosted customers.
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:
- Obtain a strong firewall to protect the FileHold server system.
- 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.
- Port forward port 443 (HTTPS) in the firewall for all requests from the public IP address to the internal IP address of the FileHold server and block requests to port 80 (HTTP).
- Generate an SSL certificate for your domain name such as filehold.example.com and install it on IIS. We recommend using a credible commercial certificate provider to assure your external users that they are accessing your true FileHold server.
- Determine if you will use HTTPS for communications between FileHold processes on the application server. This is generally unnecessary and will reduce performance slightly, but if it is required you should run the FileHold Server based FHInstrumentation tool to automatically change all web.config files to enable HTTPS. If your external and internal server names are different you will need to be running on Windows Server 2012 or higher and configure SNI. Make sure you remove the port 80 HTTP binding before you are done. https://www.filehold.com/blog/configuring-different-internal-and-external-server-names-filehold
- 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.
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.
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 anonymous portal could be exposed while the mobile and full web client are disabled for internet access.
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 anonymous portal), mobile web client, and Courier client.
FileHold Systems Inc. does not control the content at the following links.
OWASP TOP 10
The Open Web Application Security Project (OWASP) publishes a top 10 list of most critical web application security risks at www.owasp.org. These are useful in planning the security for your system. FileHold has created a white paper to help put the OWASP recommendations in context of application versus overall system requirements.
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.
Enable TLS 1.2 or TLS 1.3 as the only secure protocol and disable all others
This is easy with current Windows server versions like 2022 and 2019. You will need at least version 17.0 of FileHold to use TLS 1.3 with the FDA. Windows Server 2008R2 requires updates to use TLS 1.2. In addition all server versions require additional registry configuration for dot net in order to enable TLS 1.2 with versions of FileHold less than 16.0. Information is available at the following links related to enabling TLS 1.2 with dot net 2.x and 4.x. Workstations with the FDA will require the 32 bit settings for 4.x. The application server will require both the 64 bit 2.x and 4.x settings.
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. Note that limitations in Windows Server may prevent HTTP header information from being changed in some cases.
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.
A more recent attributed called SameSite can be updated to improve security and might be necessary to change for web sites that integrate FileHold into their pages.
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.
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.
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).
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.