Re: Sounds like ftp-anon needs work?

[David Fifield <david () bamsoftware com>]

On Tue, Jun 01, 2010 at 06:55:14PM +0200, Gutek wrote:
> I'm a bit lost between my working copy and those that were already
> proposed to the list, but i'm nearly sure that the line
> socket:send("PASS IEUser@\r\n") has never changed since the beginning
> (i.e: since the original ftp-anon script, in fact !)... that said, about
> the unhandeled 530:
> I only work with -iR for the very reason Rob mentionned about the
> banners, facing both usual ftp configurations and also weird, unusual ones.
> A few hours after posting my last copy of the script I've noticed,too,
> that it warns about unhandeled 530 too many times for very common
> reasons that, indeed, did not worth to mention like "530 Login
> incorrect.". My first bet was to simply exclude the 530-code from the
> return "unhandeled bla bla bla" but, yep... I forgot the case where the
> server has reached the max users allowed. And I agree : this particular
> case *does* matter, the script should deal with it and suggest the
> nmap-user to try again later.
>
> I'm afraid it will be hard (or: I don't know how) to detect this
> max-users-limit-reached, as the 530 code is a very generic failure and
> the message attached can be in any language (i.e: we can't string.match
> on it)
>
> I've got another problem, on another topic: fetching the LIST of
> directories. I may be wrong but we have two ways to do it : PORT (where
> *we* say to the target "send me your list on this port of mine") or PASV
> (where we ask *the target* "open a port of yours where I can grab the list")
> - what (do you think) would be the best way ? PORT or PASV ?
> - in case of PORT, what would be the best way to know *our* IP, so that
> we can socket:send("PORT my,ip,address,and,this,port")
> - in case of PASV...well, anyway I'm also interrested in knowing how to
> achieve the previous question :)

I think we're getting too deep into minutiae and special cases. Can you
or Rob just write a simple version that handles the most common cases,
uses the read_reply function, and doesn't have a looping state machine
structure? I was willing to commit that script a while ago but other
little pieces of it have been continually changing.

Let's get the easy part committed in version control. After that, we can
incrementally add read/write checking and handling for all kinds of
broken servers. Putting everything in one giant patch makes it *less*
likely to be accepted quickly.

David Fifield
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/