FTP Brute Password guessing attacks

FTP Brute Password guessing attacks
FTP brute password guessing attacks are a fairly regular occurrence at the moment. The fact that these are occurring with regularity means that they are still working, so If you have an internet facing FTP server then there are a few things that you might consider doing to help weather the storm. Watch your logs! It is surprising when you work on an incident to see how long an event goes unnoticed. Sometimes months, even though the logs are full of events such as: 09:19:44 211.45.113.143 [2]USER Administrator 331 0 09:19:46 211.45.113.143 [2]PASS - 530 1326 09:19:46 211.45.113.143 [2]USER Administrator 331 0 09:19:46 211.45.113.143 [2]PASS - 530 1326 09:19:46 211.45.113.143 [2]USER Administrator 331 0 09:19:47 211.45.113.143 [2]PASS - 530 1326 09:19:47 211.45.113.143 [2]USER Administrator 331 0 09:19:47 211.45.113.143 [2]PASS - 530 1326 09:19:47 211.45.113.143 [2]USER Administrator 331 0 09:19:48 211.45.113.143 [2]PASS - 530 1326 09:19:48 211.45.113.143 [2]USER Administrator 331 0 09:19:48 211.45.113.143 [2]PASS - 530 1326 It is quite clear what is going on here. a user typing a password multiple times per second? not likely. The log shows very clearly what is going on someone is guessing passwords. In this case it was a Microsoft FTP server which was being attacked, so there is likely to be an administrator account on the system and eventually this attack result in access. Many people don't have their logging enabled. Make sure it is switched on and watched regularly, this is something junior can do on his own. Rename Administrator On windows systems I like renaming the administrator account and then setting up a new user called Administrator, but without any privileges or access on the system. I set the password to something very long and then watch the logs. Even if they eventually manage to guess the password the account is not worth anything. It is a simple thing to do, but can be very effective. The FTP brute password attack above won't work and you may pick something else up as well. Simple but effective. Remove Anonymous Access Should you remove Anonymous access? I guess the answer depends on why there is an FTP server in the first place. Anonymous access is usually abused. When placing a FTP honeypot on the network the first files start getting uploaded, usually within the hour. So unless you really need it, remove it. Restrict Access to FTP In many organisations the actual use of FTP is fairly limited. There is no need for the whole internet to access the FTP server there may be a finite number of locations. Restrict access to FTP to these locations only, either through firewall rules, or on the FTP server itself (or even both). This will limit the opportunity for abuse of your FTP server. The above are a few simple ways to reduce the risk of losing your FTP server to someone else. If you have some nifty tricks that will help protect an FTP service, write a comment or use the contact form. Cheers Mark H	Mark 391 Posts ISC Handler Aug 27th 2010
Subscribe	Aug 27th 2010 9 years ago
I would suggest perform having a strong password policy in place and performing passwords audits against said policy. This also includes checking for weak passwords (dictionary words) that may still meet policy requirements, but is easily guessable. You can also use cewl (http://www.digininja.org/projects/cewl.php) or userpass (http://pauldotcom.com/2010/08/draft---creating-per-user-cust.html) to generate a dictionary that is relevant to an organization. I have given Ron Bowes a list of passwords that were collected from a Honeynet that I run. These passwords were largely collected from FTP password guessing attacks. (http://www.skullsecurity.org/wiki/index.php/Passwords)	Anonymous
Quote	Aug 27th 2010 9 years ago
On my public facing FTP server, I have a few scripts setup to automatically ban/block these IPs that are trying brute force attacks, as well as other scripts to automatically disable stale FTP accounts and remove old data. Seems to be working pretty well so far. My list of banned IPs is growing nicely, and no legitimate FTP users have been affected yet (but we have very few, mainly a few vendors/contractors and only for short periods of time.)	Shawn 29 Posts
Quote	Aug 27th 2010 9 years ago
If you absolutely must have FTP, and you absolutely must have it open to varying IP addresses, then you should consider tools like fail2ban that will block an IP after it exceeds a failed login threshold. If at all possible, look into moving to SFTP, FTPS or even WebDAV over SSL. With any of these, you can even employ client certificates and permanently disable password-only authentication. With any solution, you should still employ the other relevant advice here and make sure the configuration is sound (authentication and authorization, quotas, access and permissions, etc.) and test that everything works [only] as intended.	Shawn 11 Posts
Quote	Aug 29th 2010 9 years ago
With some of my BSD boxen, what I will do is create nologin accts for these often attacked users (admin, administrator) and they add them to /etc/ftpusers - that way they get an outright denial just from sending the user name	Chavez243 15 Posts
Quote	Aug 30th 2010 9 years ago

FTP brute password guessing attacks are a fairly regular occurrence at the moment. The fact that these are occurring with regularity means that they are still working, so If you have an internet facing FTP server then there are a few things that you might consider doing to help weather the storm.

Watch your logs!
It is surprising when you work on an incident to see how long an event goes unnoticed. Sometimes months, even though the logs are full of events such as:

09:19:44 211.45.113.143 [2]USER Administrator 331 0
09:19:46 211.45.113.143 [2]PASS - 530 1326
09:19:46 211.45.113.143 [2]USER Administrator 331 0
09:19:46 211.45.113.143 [2]PASS - 530 1326
09:19:46 211.45.113.143 [2]USER Administrator 331 0
09:19:47 211.45.113.143 [2]PASS - 530 1326
09:19:47 211.45.113.143 [2]USER Administrator 331 0
09:19:47 211.45.113.143 [2]PASS - 530 1326
09:19:47 211.45.113.143 [2]USER Administrator 331 0
09:19:48 211.45.113.143 [2]PASS - 530 1326
09:19:48 211.45.113.143 [2]USER Administrator 331 0
09:19:48 211.45.113.143 [2]PASS - 530 1326

It is quite clear what is going on here. a user typing a password multiple times per second? not likely. The log shows very clearly what is going on someone is guessing passwords. In this case it was a Microsoft FTP server which was being attacked, so there is likely to be an administrator account on the system and eventually this attack result in access.

Many people don't have their logging enabled. Make sure it is switched on and watched regularly, this is something junior can do on his own.

Rename Administrator
On windows systems I like renaming the administrator account and then setting up a new user called Administrator, but without any privileges or access on the system. I set the password to something very long and then watch the logs. Even if they eventually manage to guess the password the account is not worth anything. It is a simple thing to do, but can be very effective. The FTP brute password attack above won't work and you may pick something else up as well. Simple but effective.

Remove Anonymous Access
Should you remove Anonymous access? I guess the answer depends on why there is an FTP server in the first place. Anonymous access is usually abused. When placing a FTP honeypot on the network the first files start getting uploaded, usually within the hour. So unless you really need it, remove it.

Restrict Access to FTP
In many organisations the actual use of FTP is fairly limited. There is no need for the whole internet to access the FTP server there may be a finite number of locations. Restrict access to FTP to these locations only, either through firewall rules, or on the FTP server itself (or even both). This will limit the opportunity for abuse of your FTP server.

The above are a few simple ways to reduce the risk of losing your FTP server to someone else. If you have some nifty tricks that will help protect an FTP service, write a comment or use the contact form.

Cheers
Mark H

Mark

391 Posts
ISC Handler

Aug 27th 2010

I would suggest perform having a strong password policy in place and performing passwords audits against said policy. This also includes checking for weak passwords (dictionary words) that may still meet policy requirements, but is easily guessable.

You can also use cewl (http://www.digininja.org/projects/cewl.php) or userpass (http://pauldotcom.com/2010/08/draft---creating-per-user-cust.html) to generate a dictionary that is relevant to an organization.

I have given Ron Bowes a list of passwords that were collected from a Honeynet that I run. These passwords were largely collected from FTP password guessing attacks. (http://www.skullsecurity.org/wiki/index.php/Passwords)

Anonymous

On my public facing FTP server, I have a few scripts setup to automatically ban/block these IPs that are trying brute force attacks, as well as other scripts to automatically disable stale FTP accounts and remove old data. Seems to be working pretty well so far. My list of banned IPs is growing nicely, and no legitimate FTP users have been affected yet (but we have very few, mainly a few vendors/contractors and only for short periods of time.)

Shawn

29 Posts

If you absolutely must have FTP, and you absolutely must have it open to varying IP addresses, then you should consider tools like fail2ban that will block an IP after it exceeds a failed login threshold.

If at all possible, look into moving to SFTP, FTPS or even WebDAV over SSL. With any of these, you can even employ client certificates and permanently disable password-only authentication.

With any solution, you should still employ the other relevant advice here and make sure the configuration is sound (authentication and authorization, quotas, access and permissions, etc.) and test that everything works [only] as intended.

Shawn
11 Posts

With some of my BSD boxen, what I will do is create nologin accts for these often attacked users (admin, administrator) and they add them to /etc/ftpusers - that way they get an outright denial just from sending the user name

Chavez243

15 Posts