Limiting FTP privileges on Windows Server

Question

I currently have a Windows 2012 Server which is acting as a webserver running IIS. I am using Filezilla to host an FTP server to allow some clients FTP access to their own websites.

I have setup the FTP account with ease and they are able to access their website folder. However I really wish to explore this further and actually make this secure. At the moment there is nothing stopping them uploading .exe file and run on the website, to hack my server.

How can I limit the files they upload to just a few desired extensions such as PHP, JS as well as disabling renaming of entities (to stop them changing back the extention to .exe as an example). Additionally, are there any other security measures I could take?

Please tell me if I missed any information. Please do not reply with comments such as "If you don't trust them, dont give access" as this is off topic

Answer 1

First things first -- FTP is a deprecated protocol according to the IETF. It has been deprecated in favor of secure protocols such as SFTP. I recommend using only SFTP and not using FTP, because FTP commands and usernames/passwords are sent in plain text. Anyone monitoring the user's network (e.g. a coffee shop wifi) could obtain their password and easily get into their account.

That said, FileZilla server has a function called "Filename Filters" but this isn't enforced on the server, and can only be used from the client. So, there is no way in FileZilla server according to the documentation that I see to do this. That said, malicious files can easily be javascript files, or simply have no extension or masquerade as a legitimate extension such as .html. If an exploit is run to somehow invoke the code in those files (e.g. being executed through another executable -- like a bug in the filezilla server, so ostensibly filezilla.exe is executing this code), it wouldn't matter what the file extension was, as that code will be executed. Thus, the server's lack of support for this filtering isn't much of a security loss.

So, limiting filename extensions can provide a minor increase in security; but is definitely not a cure-all nor would it prevent a skilled attacker from exploiting your system -- thus probably the reason support isn't implemented in FileZilla server. Instead, think of it as a small part of a comprehensive program of "best practices" to limit access, including using secure protocols such as SFTP, security hardening the server (e.g. CIS hardening standards), installing regular updates, antivirus protection, firewalls and/or intrusion detection, regularly updating the FileZilla server, et cetera.

Answer 2

First of all, I would strongly recommend to block FTP and only allow FTPS/FTPES (FTP over implicit/explicit SSL/TLS). SFTP would be even better, more firewall friendly, inherent forward secrecy... but FileZilla Server does not support SFTP.

This said, I would recommend using a server software that allows you to do two essential things:

1. Prevent file renaming
2. Run your own script upon occurrence of certain events (like file upload)

Look at the following script, for example:

var
  FirstBytes, PEBytes : string;
begin
  FirstBytes := FileReadAsHex(ObjectName, 0, 2);
  PEBytes := FileReadAsHex(ObjectName, 256, 4);
  if ((FirstBytes = '4D5A') and (PEBytes = '50450000')) then
  begin
    // It's an EXE, delete it!
    FileDelete(ObjectName);
  end;
end.

The above simple script can identify a Windows EXE by reading two particular 2-byte locations in its header. If your FTP(S) server could run that script every time a file is uploaded, your server would identify all EXEs, including the ones uploaded with a fake extension, and delete them right away when they are uploaded.

Unfortunately FileZilla Server doesn't have the capability to automatically run scripts upon file upload (or upon occurrence of any event, it basically does not have that functionality) but there are other servers that can do so. Disclaimer: I am the author of one of such servers.

References: http://kb.syncplify.me/how-to-prevent-uploads-of-exe-files/

Answer 3

IMHO you are handling the wrong side of the stick. It is a security problem, so the first question is "what is the threat here?". If I have correctly understood, you want to protect your system from an offensive upload.

You should set up different lines of defense here:

• secure the authentication protocol to refrain hackers to too easily abuse legit accounts. Other answers explained that FTPS (FTP over SSL or TLS) is more secure because credentials are never sent in plain text. IPSEC (over IPv6) is another option equivalent on a securit point of view
• try to limit the possibilities server side to accept only known extensions. Well you should do if your server allowed it, but unfortunately FileZilla is not very feature rich on that point. Maybe you could have a look to ProFTPD which is much richer but requires Cygwin. Anyway, PHP files can hurt a server because they are executed under the server account with all server priviledges - Ok the PHP interpretor can be configured to limit the risks, but flaws used to be common in that part, so IMHO this part is not the more robust
• limit the possibilities of the server itself. I do not know specifically IIS, but good practices recommend that a HTTP server runs under a dedicated non administrative account. So you should ensure that even if the server was to execute arbitrary command, the damage should be limited to the server zone. Here again, I do no use Windows to host HTTP servers so I cannot say much more.

IMHO, the more important lines here are 1 and 3. 3 protects the host system, and 1 allows to know who is responsable for what. Along with correct backup procedures and log analysis, they should be more efficient that 2.

That being said, my advice is that is would be much simpler to build a HTTP server allowing FTPS or SFTP access under a Unix like systems like Linux or a xxxBSD. You will find much more configurable servers there, and probably more references on the WEB (or here...) about how to securely configure them. Of course if IIS is required this is no longer an option, at least for the HTTP part.