Getting the IP address of the connecting client in the authorizer

[Jeff Fisher]

Hi,

Is there a way to get the IP address of the connecting client in the
authorizer?

We have a custom authorizer that hands the information off to a daemon
running on another server and it basically returns the information the
authorizer needs or a failure code.

This daemon uses the IP address of the connecting client to spot people
trying to brute force login attempts across all of our FTP servers and
right now we modified pyftpdlib to pass the IP.

Can this be done without a custom modification?

Thanks,
Jeff

[Giampaolo Rodolà]

Mmm no, that's not possible at the moment, but I think you can achieve
the same goal by using a different approach.
0.7.0 version will provide a new on_login_failed() callback, which is
called when client provides wrong credentials.
You can use it in conjunction with handle() which is called when
client connects.
Pseudo code:

class CustomHandler(ftpserver.FTPHandler):

def handle(self):
# called when client connects
if self.authorizer.is_banned_ip(self.remote_ip):
self.respond("530 you're banned")
self.close_when_done()
else:
CustomHandler.handle(self)

def on_login_failed(self, username):
# called on failed login attempt
self.authorizer.ban_ip(self.remote_ip)

Also, you might want to take a look at anti_flood_ftpd.py demo script,
which does a very similar thing:
http://code.google.com/p/pyftpdlib/source/browse/trunk/demo/anti_flood_ftpd.py

Hope this helps,

G.

> --
> You received this message because you are subscribed to the "Python FTP
> server library" project group:
> http://code.google.com/p/pyftpdlib/
> To post to this group, send email to pyft...@googlegroups.com
> To unsubscribe from this group, send email to
> pyftpdlib-...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/pyftpdlib

[Jeff Fisher]

On 01/24/2012 02:26 PM, Giampaolo Rodol� wrote:
> Mmm no, that's not possible at the moment, but I think you can achieve
> the same goal by using a different approach.

Well, I also use the IP for some tracking things on successful logins.

We run our FTP software on 30+ boxes and they all talk to a centralized
daemon that does authentication.

Any chance this could get added as something that is passed in to the
authorizer? I can submit a patch if you want.

Thanks,
Jeff

[Giampaolo Rodolà]

Il 24 gennaio 2012 21:30, Jeff Fisher <je...@thefishers.ca> ha scritto:

> On 01/24/2012 02:26 PM, Giampaolo Rodolà wrote:
>>
>> Mmm no, that's not possible at the moment, but I think you can achieve
>> the same goal by using a different approach.
>
>
> Well, I also use the IP for some tracking things on successful logins.
>
> We run our FTP software on 30+ boxes and they all talk to a centralized
> daemon that does authentication.
>
> Any chance this could get added as something that is passed in to the
> authorizer? I can submit a patch if you want.

Well, point is there's a problem of retro compatibility since passing
a new argument to validate_authentication() means breaking existent
code using a custom authorizer.
We could probably do that for 1.0.0 version, since I'm planning to to
break quite a few things things anyway.

[Jeff Fisher]

> We could probably do that for 1.0.0 version, since I'm planning to to
> break quite a few things things anyway.

Sure, I can wait -- we have a couple of other custom modifications as is.

What are you planning on breaking? :)

[Giampaolo Rodolà]

The most outstanding change will be unicode support (and the python 3
porting which goes with it):
http://code.google.com/p/pyftpdlib/issues/detail?id=198
In terms of compatibilty that means that the filesystem class is going
to accept unicode strings only (whereas now it expects bytes) and
unicode will be used pretty much anywhere in FTPHandler class.

Also I was thinking to change validate_authentication() method in
order to no longer return a bool but instead raise an exception in
case of login failed.
That way you can send custom response strings depending on why the
login failed (e.g. "wrong username", "wrong password", "your IP is
banned", etc..)

Last but not least: add support for kqueue() and epoll().
Right now the internal poller depends on asyncore; as such it can only
use select() and poll() system calls which don't scale/perform well
with thousands of concurrent clients.
As of now I'm not sure how *that* will change compatibility. It will
probably affect serve_forever()'s use_poll argument only.
The change in terms of internal code will be massive though.