FTP Secrutiy Problems...

NightShade03

So a few weeks ago I posted about an FTP server that I was setting up for a client. I setup the FTP server in Windows (Win2k3) using the built-in FTP server. I setup an account for access to the FTP server and gave it a strong password. Opened up the necessary ports on the firewall and everything worked great. I knew that that was waaaay to good to be true.

1 Week later I start seeing huge increases in traffic and sure enough checking the logs I see 4-5 automated FTP Bruteforce attacks happening....(I knew it was only a matter of time). All FTP access is controlled through a single user account in AD, however for security all account in AD have 12-15 character complex passwords. All network resources and the like are locked down as well. My question is, is there a way to hide from these FTP attacks or another way to offer FTP access without making my client's server so vulnerable?

RobertKaucher

The short answer is no. The only way arround this would be to have a firewall that would only allow access from certain IP addresses. But that would defeat the purpose...

You have done everything you can, given the parameters of your previous thread. If the port is not open, your users will not be able to access it. If your port is open, it is open for attack.

dynamik

It might be more convenient (to your users) to continually blacklist IPs you know to be attacking you, but you'll be adding a lot of management overhead. What is the purpose of FTP access? You could just keep it local only and require users to establish a VPN connection first.

veritas_libertas

You might try using a different port number than the standard as well. Out of curiosity are you using FTPS or SFTP?

blargoe

For actual connections, the only other thing I can think of is to put in some kind of IDS/IPS in front of it so these kiddies scanning your ports then trying to brute their way in would be blocked after they try their port scan.

My FTP setup on the server side includes:

Never putting the ftproot on the system drive (in case somehow the server is compromised in a way that allows directory traversal)
Using File Server Resource Manager that was introduced in 2003 R2 to block executable files from being saved the ftp folder
Software Restriction policies to prevent unwanted execution of executables on the system if you do get compromised.
Rename and/or disable local Administrator account.
I prefer to make it so that the user name is not something really generic either, like "ftp", "ftpuser", the name of a department, etc.

If there's a time window that is the only time a valid connection to the server would take place, you could set a logon time window on the AD account so that it would always be denied during that time.

Stotic

I would also advise implementing QoS (Quality of Service) on your network to restrict the greedy behavior of FTP. It won't deny these attacks like an IPS, but it would help control the FTP traffic on your network in general by preventing the protocol from choking your bandwidth.

Paul Boz

FTP has numerous security risks. For one thing its clear-text so if someone wants to they can sniff the wire to grab credentials or intercept the data that is being transferred. I do man in the middle attacks like this all the time. Cain will even automatically filter out the credentials.

Another risk is the fact that FTP uses dynamic ports for data transfer. This means that while you may open port 21 for FTP communications and signalling, you more than likely have to open a range of ports for data transfer. For this reason my company advises customers against allowing FTP on the external network. It's just not a good idea. A better solution would be to filter by IP address if possible. If that isn't an option another solution is to do as Dynamic advised, and place the FTP behind a VPN. Another solution would be to completely segregate the FTP server into its own DMZ protected by its own firewall. Again, if sensitive material is kept on the FTP you should remove it from the external network. There are much more secure methods of file transfer. FTP is outdated and insecure.

Forsaken_GA

Paul has adequately covered the reasons why you don't use FTP unless you absolutely, positively have to.

If you're going to do it anyway, you're going to get brute forced, simple as that. The only thing you can do about it is monitor the connections and then react based off of that. For debian, I use fail2ban, after (I think) 4 authentication failures for either ssh or ftp, the script reacts by banning the IP for 30 minutes from any connection.

You are much better off running FTP only with Kerberos behind it, at least then you can authenticate the connections, or more simply through SFTP (which I highly recommend.. Filezilla makes using the SFTP connection entirely transparent to the user)

NightShade03

The FTP access if for external clients to be able to upload photos and other files to my clients site. Unfortunately they work with businesses all over the world so a time restriction is out of the question. Also they are a small company so I only have 1 server to work with

Changing the FTP port to something non-standard I should have thought of...(thanks veritas_libertas).

The other issue with this setup is that they have a really old and horrible modem that doubles as a poor excuse for a firewall. I will be replacing this shortly with a linux box that will be providing the routing and firewall access.

@dynamik: I thought of blacklisting but there are just to many clients worldwide on dynamic address that they deal with so this is just out of the question.

@blargoe: Thanks for the tips! FTP user is something random and non-obvious, complex password in place, admin account is already renamed and locked down, and the single folder that the FTP grants access to has security in place to not allow .exe files (or for them to break out of that folder either).

I was thinking VPN but then how would I go about distributing access to the external clients? The current setup is with the FTP server running and when a client needs access we email them a zipped file which contains Filezilla FTP Clients and a config file that they just import which auto connects them to the office. When the external client is finished working we change the password to something random on the FTP user for the next external client's use.

@Paul Boz: I hate FTP just as much as you do but I didn't see an easier alternative in this case....

dynamik

I was referring to a solution like Forsaken mentioned. Even if you just do something like a five-minute lockout after five attempts, you're going to slow down the cracking process and reduce bandwidth usage dramatically. Few people will focus on a server that gives them 60 login attempts an hour when they can do more in a minute on another server. I doubt anyone is trying to get into your server specifically; most are just looking for something convenient.

I think changing the port number will help as well. That's a security-through-obscurity approach, but since you seem to be more concerned with the resources of your network and server than security, I think that would help. You're not going to stop someone determined, but you'll avoid a lot of the automated tools/script kiddies that just look for FTP on port 21.

Honestly, I'd install the Filezilla server and ask that your partners/customers download the client and use that. Not only will that allow you to run FTP securely, you'll also be able to create another user database that's separate from AD. I think combining that with a non-standard port to remedy the aforementioned resource issues will be a win for you.

NightShade03

dynamik wrote: »

I was referring to a solution like Forsaken mentioned. Even if you just do something like a five-minute lockout after five attempts, you're going to slow down the cracking process and reduce bandwidth usage dramatically. Few people will focus on a server that gives them 60 login attempts an hour when they can do more in a minute on another server. I doubt anyone is trying to get into your server specifically; most are just looking for something convenient.

I think changing the port number will help as well. That's a security-through-obscurity approach, but since you seem to be more concerned with the resources of your network and server than security, I think that would help. You're not going to stop someone determined, but you'll avoid a lot of the automated tools/script kiddies that just look for FTP on port 21.

Honestly, I'd install the Filezilla server and ask that your partners/customers download the client and use that. Not only will that allow you to run FTP securely, you'll also be able to create another user database that's separate from AD. I think combining that with a non-standard port to remedy the aforementioned resource issues will be a win for you.

Advice taken. I had to play with Filezilla server and the firewall for a little to get it working correctly but I now have the Filezilla server running with FTPS over a non-standard port. I'll keep an eye on the logs the next few days to see if I notice a decrease in the attacks.

Thanks for everyone's advice/help!

veritas_libertas

Paul Boz wrote: »

FTP has numerous security risks. For one thing its clear-text so if someone wants to they can sniff the wire to grab credentials or intercept the data that is being transferred. I do man in the middle attacks like this all the time. Cain will even automatically filter out the credentials.

Another risk is the fact that FTP uses dynamic ports for data transfer. This means that while you may open port 21 for FTP communications and signalling, you more than likely have to open a range of ports for data transfer. For this reason my company advises customers against allowing FTP on the external network. It's just not a good idea. A better solution would be to filter by IP address if possible. If that isn't an option another solution is to do as Dynamic advised, and place the FTP behind a VPN. Another solution would be to completely segregate the FTP server into its own DMZ protected by its own firewall. Again, if sensitive material is kept on the FTP you should remove it from the external network. There are much more secure methods of file transfer. FTP is outdated and insecure.

Out of curiosity Paul, I would think that FTP over SSH would still be fine though. Am I wrong? :

I was just reading an article on FTP from SANS and it made me remember this thread...

GAngel

veritas_libertas wrote: »

Out of curiosity Paul, I would think that FTP over SSH would still be fine though. Am I wrong? :

I was just reading an article on FTP from SANS and it made me remember this thread...

The same vulnerabilities are there it just passes through a tunnel instead of plain text. Most admins think SSH accounts are secure which they leave wide open once you get a hold of a user account with rights.