The problems with Using IIS as an

Internet Facing FTP Service

microsoft-iisIIS (Internet Information Services) is the Microsoft product integral to Windows which provides web, email and FTP services. Many organisations make use of the FTP server component to transfer files to application servers inside their networks, relying on more dedicated secure file transfer servers for their public FTP services.

IIS as an SSL secured FTP server…
With the introduction of IIS 7.5, it became possible to use IIS as an SSL secured FTP server – until this time, IIS only ran in non-secure mode. Each successive version of IIS has increased its functionality to bring it closer to mainstream products; this raises the question of why not use it as a free alternative to more costly File Transfer Systems?

No SFTP though…
Let’s first consider the security that IIS provides; IIS allows the use of SSL encryption up to 128 bits. This is sufficient to meet most compliance criteria, however at this time it is not easy to improve upon without serious technical tinkering.
IIS FTP cannot provide (nor is it ever likely to) an FTP platform supporting SSH transfers. SFTP (SSH File Transfer Protocol) is a binary protocol using keys rather than certificates, and was developed on and for Unix. SFTP is very popular for internet based file transfers thanks in part to it being firewall friendly (only requiring a single port to function)ftp-server

Possible administration headaches…
Files and folders hosted by IIS FTP are protected by granting limited permissions to users, groups or roles via the IIS Manager (Read, Write, Nothing). The IIS manager does not contain the users or groups however – these are normal local or domain entities. This unfortunately means administration through two separate systems, increasing administration overheads. IIS does not check for existence of users or groups, which can lead to administration headaches from unintentional typos.

Permissions that are set are inherited down from server to site to folder; you can break inheritance and overwrite with your own permissions at each level, however you cannot restore the inheritance without losing all of your changes.

You cannot find all of the permissions set for a single user without checking every folder or exporting the configuration; unlike a more sophisticated solution, it is not possible to simply “grant the same access as Bob has”.

Administration of IIS FTP sites cannot be delegated or devolved, meaning either all administration is centralised, or else everyone has the ability to make any changes they desire in IIS. Configuration changes are logged to the event log (if enabled), however you will require a separate tool to generate reports from the event log.

On the subject of logging, an area of concern is the logging of regular FTP activities. This is done through standard W3C logging in the same way as a website would be logged.

2016-04-22 09:49:26 127.0.0.1 – 127.0.0.1 10020 USER FTPUser 331 0 0 1b3083fe-67a9-461d-926f-795946f267d8 –

2016-04-22 09:49:31 127.0.0.1 RichardWin7\FTPUser 127.0.0.1 10020 PASS *** 230 0 0 1b3083fe-67a9-461d-926f-795946f267d8 /

2016-04-22 09:49:38 127.0.0.1 RichardWin7\FTPUser 127.0.0.1 10020 CWD transfer 250 0 0 1b3083fe-67a9-461d-926f-795946f267d8 /transfer

2016-04-22 09:49:43 127.0.0.1 RichardWin7\FTPUser 127.0.0.1 10020 PORT 127,0,0,1,189,113 200 0 0 1b3083fe-67a9-461d-926f-795946f267d8 –

2016-04-22 09:49:43 127.0.0.1 RichardWin7\FTPUser 127.0.0.1 10019 DataChannelOpened – – 0 0 1b3083fe-67a9-461d-926f-795946f267d8 –

2016-04-22 09:49:43 127.0.0.1 RichardWin7\FTPUser 127.0.0.1 10019 DataChannelClosed – – 5 1 1b3083fe-67a9-461d-926f-795946f267d8 –

2016-04-22 09:49:43 127.0.0.1 RichardWin7\FTPUser 127.0.0.1 10020 STOR test.txt 550 5 1 1b3083fe-67a9-461d-926f-795946f267d8 /transfer/test.txt

Unfortunately, you cannot select the logging level – only the fields to be recorded into the log file. This means that effectively you will always run the FTP site at full logging.

In the same way as permissions are handled, IP Restrictions are placed at the server level and filter down to site level, then the folder/virtual folder level. Similarly, any changes made to inherited restrictions cannot be reverted on a granular level – it’s all or nothing.

IIS offers the notion of “user isolation”…
Finally, IIS offers the notion of “User Isolation”. This allows you to switch between having all users share a common root folder, or have an individual folder per user. Isolating users means locking a user into a single directory (and any subdirectories); the user can never reach someone else’s folder. Unless you select to use the users home directory as specified in Active Directory however, you will still have to manually create the home directory before the user can log on.

So realistically, should you use IIS FTPS sites for secure access from the internet?
The answer is…it depends on your needs. If you only have a very small number of files being transferred by a very small number of users who can all use FTPS, then it makes sense to use it.
If your user base is likely to grow into double figures, your external users need to use SFTP or audit reports are a necessity, then you really need to steer away from IIS. The overheads for administration and support of IIS FTP very quickly offset the cost savings gained from selecting IIS as a secure public facing file transfer platform.