LiquidFiles Documentation
LiquidFiles Documentation
On This Page

LiquidFiles Security Overview

General info and overall strategy

The LiquidFiles appliance aims to be secure by default, with a reasonable balance between security and convenience. An example of this is the password complexity requirement (Password Policy Documentation). It's easy to turn the security to 11 having very complex password requirements as the default setting. The current default aims to provide a reasonable default which is secure, but not overly complex. And if your policy has more stringent needs, feel free to add your own password policy in the form of a regexp validation in the assigned field.

One of the key differentiators between the LiquidFiles appliance and most of it's competitors is that the LiquidFiles appliance is not a cloud service that is shared with other organisations. All the files remain in your control. With the ISO, VMware or Hyper-V setup, the system will be installed in your premises, within your security parameter, behind your firewall and so on. You control all aspects of the physical and logical separation in regards to the installation.

If you choose to install using the Amazon EC2 or Microsoft Azure installation, you run the virtual appliance in your own private Amazon EC2 or Azure cloud space. Again, this is not shared with other organisations. All files remain within your assigned private cloud space.

Platform Specific Security Features

Operating system and Hosting

  • The operating system used in the ISO or virtual appliance version is minimally installed version of Ubuntu. Only packages necessary for the basic operation of LiquidFiles is installed.
  • The Amazon AWS hosting facilites are certified using most industry standards. Please see http://aws.amazon.com/security/ for a description of the security related to the Amazon AWS hosting facilities.
  • The Microsoft Azure hosting facilities also have an array of security features, improving all the time, outlined here: https://azure.microsoft.com/overview/security/

Builtin Firewall

  • The firewall used is the builtin Ubuntu firewall — Netfilter. Please see: https://ubuntu.com/server/docs/security-firewall for more information. You can if you want run the LiquidFiles appliance without any other firewall.
  • Behind the firewall the system has been configured to only listen to ports that are needed anyway (http and https in the default configuration). Even if the builtin firewall was completely disabled, and your external firewall completely opened up, you still wouldn't be exposed to any vulnerable services. As an example, PostgreSQL is used as the database and has been configured to not listen to any TCP port (the default PostgreSQL port is 5432). Even if the firewall was disabled, it would not be possible to connect to the database from an external system.

Web Server, SSL and transmit encryption

  • The web server used is Nginx (Please see: http://nginx.org/en/security_advisories.html for security advisories related to Nginx). Nginx is built with security in mind from the start and there's been very few security related issues relating to Nginx over the years.
  • Nginx has been configured to only accept strong TLS connections with only Strong Encryption Algorithms enabled. On default LiquidFiles requires TLS v1.2 or v1.3 connections and traffic will use AES 256 bit encryption.

Web Application Framework

  • The web application framework used is Ruby on Rails. Rails has been designed with security in mind and offers builtin protection for normal web security problems like SQL Injection, Cross Site Scripting (XSS) and Cross Site Request Forgery (CSRF). An outline of the security features and protections in Rails is available here: http://guides.rubyonrails.org/security.html.

LiquidFiles Application Specific Security Features

Randomized Tokens

  • Downloads are protected with randomized tokens. When downloading a file, three tokens are used. A unique token for each message, a unique token for each attachment within that message, and a download token which is unique for every download. Each token is generated using the OpenSSL random function with an entropy of minimum 128 bits. To successfully forge the download of a message, an attacker would have to guess effectively a 384 bit random string.

Users, signup and password resets

  • No password is ever sent in cleartext in mails sent from the system. When a user requests a download, signups to the site or issues a password reset, a randomized string (128 bit entropy with a short lifespan) is sent to the user for them to take action. It is possible to turn off the user signup for a private system. It is also possible to send files to external users that can authenticate themselves without needing an account on the system. This is possible using an email loop where a user first gets a link to download a file, this link is the same for each recipient. When the user authorizes themselves, they will get another link emailed to them to uniquely identify them as the recipient.

Strong / Two Factor Authentication

  • For enhanced security, two factor authentication can be configured, with either Time Based One-Time Password (TOTP) — or App based two-factor authentication, using SMS or using the Duo two factor authentication system. The two factor authentication can be setup to automatically required strong two factor authentication automatically based on group belongings.
  • LiquidFiles also supports SAML2 authentication so you can further integrate LiquidFiles with other multi-factor authentications using SAML2.

Spam Protection

Every so often we get requests to include some form of CAPTCHA on the dropbox and signup pages to prevent bots from auto-generating accounts. We don't like CAPTCHAs. As in - we really, really don't like CAPTCHAs.

Instead, there's actually already spam protection built in to LiquidFiles in the form of hidden form tags, that is hidden from users using CSS, but not hidden from bots that don't read CSS. If any of the hidden fields are filled in, this will indicate that it's a bot making the request and not a user and the request will be blocked. A much more elegant solution as it's completely invisible to the end user (and why we get requests as there's no apparent, visible, protection).

Since this is a transfer system as opposed to a web publishing system, the impact of a fake account is also not as great. If a bot is using the LiquidFiles appliance to target your users, they would have to target individual users with their email addresses in pretty much the same fashion as they would with individual emails by attacking your mail server. It would still be annoying to be the target of an attack, but it's not like someone would be able to push bot download links via a comment thread in a forum, which is where usually CAPTCHA type checking is implemented, and where they provide actual security improvements. There has also been no reports of spam by using the LiquidFiles appliance. Please open a support ticket should that happen and we'll build something that will combat the actual problem, instead of the perceived one. It's very unlikely that the solution would be to implement a CAPTCHA system.

Password guessing/Brute Force Protection

The default setting is to block any ip address for 15 minutes after 5 unsuccessful password guessing attempts within 5 minutes. This will make any form of automated password guessing attempt impractical to the point of impossible. The system also doesn't care if the incorrect guessing happens on the login page or password reset page (for email guessing). Any incorrect attempt from any unauthenticated page is counted. Feel free to change the defaults to anything else as you suit your needs. You can also whitelist certain hosts or networks from never being blocked.

Password Storage, Password Policy & Expiration

Network restrictions

  • You can configure that a certain group of users can only login from a certain network ranges.
  • You can also configure that admin pages can only be reached from certain hosts or networks.

Logging and Auditing

All uploads, downloads, any login activity and all admin activity are being logged. It's visible in the Admin → System Log and the last month of activity is kept in the database on the system. If you need to keep any of the logs for longer, please enable syslog and send the logs to an external syslog server where you can keep the logs for as long as you need.

The message log (Admin → Message Log) can be configured to only deleted after a certain time, defaults to 365 days.

LDAP/Active Directory Authentication

It's possible to use a centralised database using LDAP. You can configure as many LDAP servers as you need and they will be searched in the order you specify. You can restrict logins to certain AD groups and automatically assign users to groups based on LDAP group.

Antivirus protection

ClamAV is used and the default is to scan all files for viruses. ClamAV will update it's signatures every two hours. It's also possible to build custom file scanning protections. Please see the: Custom File Scanning Documentation for an example of integrating another AV scanner into the LiquidFiles appliance.

Branding and white labeling

While not strictly security, a fairly common question is if it's possible to remove any of "our" branding for brand protection. And the answer is yes, to your users. There's a copyright message that is only displayed in the footer to system administrators but never displayed to any of your users.

Security Audits and Compliance

Please feel free to let your security auditors free reigns to your LiquidFiles appliance. And should they pick something up, please open up a support ticket. Bear in mind though that security audits is not an exact science and we've gotten conflicting reports from different audits being made. Some complain that external users are required on the system because it's an "open hole" in to the environment. Some complain that it's possible to download files without a user account because it's "more secure" to have accounts than randomised strings. So effectively we've gotten reports that external users having accounts and not having accounts both are more secure than the other and should be the default setting for everyone, all in the name of security. Obviously it's not possible to please everyone and that certainly includes auditors.

The most common request we get from auditors though is to remove any helpful error message because of information leakage. The auditors wet dream seems to be a system that only displays "error" as the error message, regardless if it's because the user typed the wrong email address, wrong password, wrong file extension, no subject line, forgot to add files or recipients to a message and so on. Obviously a system like this would be massively unhelpful and hard to use. But it wouldn't "leak information". We will never make this kind of generic error messages and rely on other protection mechanisms instead, like the password guessing timeout listed above. If you really want to go down this path, and we strongly recommend against it, you can edit the locale in Admin → Locales and all strings, including error messages are in there to make all errors messages read "error".