2

We have:

  • an IIS 8.5 server which accepts FTP connections from whitelisted IP addresses
  • a PHP web app (on a LEMP server) which creates XML files and uploads them to this IIS server over FTP.

Our web app was able to make the connection and upload its XML files. We could also connect via Filezilla.

Directory listing, file upload, folder creation functioned without issue for months.

Recently however, the ability to list or write to the folder stopped working when connecting from certain whitelisted IPs.

See this screenshot for an example.

  • On the left is a command line FTP session I opened up while using my whitelisted residential IP. No issue getting a listing (directory is empty).
  • The session on the right was opened after connecting to my OpenVPN server. Immediately disconnected after DIR.

A similar test (screenshot) with another whitelisted IP yielded the same result - DIR fails in the first attempt (using a different VPN), but succeeds in the second attempt (using residential IP).

This behavior persists when using Filezilla.

Even worse, we're now getting this behavior in our web app's FTP sessions. Here's a screenshot of an FTP session I started from our LEMP server over SSH.

After the dir command, it just hangs indefinitely until I hit Ctrl+C. I noticed the 550 response code there.

550 comes up again when our web app attempts to STOR a file:

Upload attempt by our web app

2019-01-14 17:43:18 [ip removed] DOMAIN\Username 192.168.1.2 21 TYPE A 200 0 0 53e4f879-8616-435f-bef2-4a84ae0d7989 - -
2019-01-14 17:43:18 [ip removed] DOMAIN\Username 192.168.1.2 21 PORT xxx,xxx,xxx,xxx,158,231 200 0 0 53e4f879-8616-435f-bef2-4a84ae0d7989 - -
2019-01-14 17:43:39 [ip removed] DOMAIN\Username 192.168.1.2 21 STOR r4intake-general-testlname-testfname-1547487798.xml 550 4294967295 0 53e4f879-8616-435f-bef2-4a84ae0d7989 /r4intake-general-testlname-testfname-1547487798.xml -

Here's a log of a file upload attempt using Filezilla (from my residential IP). The STOR returns 226.

2019-01-14 17:47:49 [ip removed] DOMAIN\Username 192.168.1.2 21 TYPE A 200 0 0 808bb5b7-4e6a-4950-a204-f59a87f3d7b9 - -
2019-01-14 17:47:49 [ip removed] DOMAIN\Username 192.168.1.2 21 PORT xxx,xxx,xxx,xxx,214,2 200 0 0 808bb5b7-4e6a-4950-a204-f59a87f3d7b9 - -
2019-01-14 17:47:49 [ip removed] DOMAIN\Username 192.168.1.2 21 STOR r4intake-general-testlname-testfname-1547487999-full.xml 226 0 0 808bb5b7-4e6a-4950-a204-f59a87f3d7b9 /r4intake-general-testlname-testfname-1547487999-full.xml -

Same FTP server, same credentials, same folder, same transfer mode - different response.

Observation:

There are five whitelisted IPs we have tested with. Commands succeed with 2 and fail with 3 of these IPs.

Of the three that fail, two belong to Digital Ocean (our LEMP server and my OpenVPN server), and one belongs to a known commercial VPN service.

I typically work with the LEMP stack and know almost nothing about IIS, and have few ideas from this point as to what the cause could be.

Is it possible that IIS does not like certain IP ranges (datacenter, known VPNs, etc.), or that some type of security or group policy could be affecting the ability of certain IP ranges to read/write to the folder despite the fact that said IPs are whitelisted for FTP connection?

Nathan
  • 41
  • 1
  • 6

1 Answers1

1

Make sure the data port, 20 is firewalled correctly on the server and make sure you don’t need PASV mode to work for those clients.

Such problem, list, stor, etc.. open up the data port, thus in active mode like in your case it seem blocked or just filtered

yagmoth555
  • 16,758
  • 4
  • 29
  • 50
  • Thanks, I'll ask the server admin to check port 20. `PASV` shouldn't be a requirement/issue in this case, because I can successfully `list` or `stor` in active mode on the same client (DOS command line FTP client, Ubuntu command line FTP client, Filezilla, etc.) that these operations fail under if using a different IP. – Nathan Feb 07 '19 at 15:20
  • 1
    Client's IT ultimately resolved by fixing passive mode misconfigurations in IIS, which allowed our application to successfully use passive transfers. On the web server side, it turns out that ufw suddenly started blocking data transfer over active mode, though no configuration change was made to ufw. It also doesn't explain why active mode didn't work when using two of our other whitelisted IPs, whose associated servers were not running ufw. They were both VPN servers, so likely an unknown firewall issue there as well. – Nathan Feb 18 '19 at 20:12