You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ftpserver-dev@incubator.apache.org by John Garrould <jo...@gmail.com> on 2007/06/05 21:42:41 UTC

Is the FTP Server Vulnerable to password crackers

Is there a  way to configure the server so that malicious users cannot
try multiple log-in attempts without reconnecting?  Ideally I would
like to be able to configure the connection to be dropped after 3
invalid attempts at the password.

I've just been watching someone hit a server trying to log in as
'admin' with thousands  of different passwords.  Obviously we would
not have obvious user ids but the effect of this is to flood the
server to the extent that regular users are failing to connect.  There
is also a remote possibility that given enough time the cracker could
get lucky and get a real user id / password.

How do you recommend we protect the server against this form of attack?

Thanks

John Garrould

Re: Is the FTP Server Vulnerable to password crackers

Posted by Niklas Gustavsson <ni...@protocol7.com>.
Niklas Gustavsson wrote:
> Dave Roberts wrote:
>> John Garrould wrote:
>>> Is there a  way to configure the server so that malicious users cannot
>>> try multiple log-in attempts without reconnecting?  Ideally I would
>>> like to be able to configure the connection to be dropped after 3
>>> invalid attempts at the password.
>>
>> I don't believe this is currently configurable.  Niklas or Rana can
>> correct me if I'm wrong about this.
> 
> You're correct, it is not currently possible to set. However, I think 
> it's a very good idea, even to have a default value that kicks a user 
> after a certain number of login attempts. I've created a JIRA issue to 
> track this and will have a look at fixing it within the next couple days.
> 
> https://issues.apache.org/jira/browse/FTPSERVER-94

Sorry fir taking such a long time on completing this. However, now it's 
done. I've added two new configurations:
config.connection-manager.max-login-failures

The number of failed logins before a session is disconnected. Set to 3 
by default, set to 0 to allow infinite number of attempts

config.connection-manager.login-failure-delay

A timed delay after a failed login attempt. Set to 500 ms by default. 
Makes brute force password attacks harder.

Please tell me if this solves your troubles!

/niklas


Re: Is the FTP Server Vulnerable to password crackers

Posted by Niklas Gustavsson <ni...@protocol7.com>.
Dave Roberts wrote:
> John Garrould wrote:
>> Is there a  way to configure the server so that malicious users cannot
>> try multiple log-in attempts without reconnecting?  Ideally I would
>> like to be able to configure the connection to be dropped after 3
>> invalid attempts at the password.
> 
> I don't believe this is currently configurable.  Niklas or Rana can
> correct me if I'm wrong about this.

You're correct, it is not currently possible to set. However, I think 
it's a very good idea, even to have a default value that kicks a user 
after a certain number of login attempts. I've created a JIRA issue to 
track this and will have a look at fixing it within the next couple days.

https://issues.apache.org/jira/browse/FTPSERVER-94

/niklas


Re: Is the FTP Server Vulnerable to password crackers

Posted by Dave Roberts <da...@saaconsultants.com>.
John Garrould wrote:
> Is there a  way to configure the server so that malicious users cannot
> try multiple log-in attempts without reconnecting?  Ideally I would
> like to be able to configure the connection to be dropped after 3
> invalid attempts at the password.

I don't believe this is currently configurable.  Niklas or Rana can
correct me if I'm wrong about this.

> How do you recommend we protect the server against this form of attack?

Probably set up a counter in the FtpSession implementation, then
when a login fails, the PASS class can obtain the session through
the Connection class, decrement the number of tries remaining and
drop the connection if the number reaches zero.

Should be pretty straight forward.  You might want to have a try
yourself, if you feel up to it.

In the meantime, please raise a call in JIRA
(http://issues.apache.org/jira) so the issue can be tracked.