Home page logo
/

nmap-dev logo Nmap Development mailing list archives

Re: Ncrack ftp testing - proftpd peculiarities
From: ithilgore <ithilgore.ryu.l () gmail com>
Date: Thu, 25 Jun 2009 04:36:24 +0300

ithilgore wrote:
Upon porting ncrack to Windows I noticed some strange TCP behavior occurring
when testing against a proftpd server. The main issue is that proftpd server
sends the first reply (banner) nearly 10 seconds after the initial 3way
handshake is completed. This happened with the proftpd server running on Linux
and the ftp client (or ncrack) running from Windows (XP SP3). Note that this is
not a ncrack/nsock issue since it also happens with the default Windows ftp
client. I conducted some test cases observing responses for various combinations:

SLOW = almost 10 seconds for first response
NORMAL = normally less than 1 second for first response

Windows client ---> Linux proftpd server  (SLOW)
Windows client ---> FreeBSD proftpd server (SLOW)

Linux client   ---> Linux proftpd server (NORMAL)
FreeBSD client ---> Linux proftpd server (NORMAL)
Windows client ---> Windows Filezilla server (NORMAL)
Windows client ---> Linux vsftpd server (NORMAL)
Linux client   ---> Windows Filezilla server (NORMAL)
Linux client   ---> FreeBSD proftpd server (NORMAL)


As you can see, the only cases that were actually marked as slow were those when
the client was running from Windows and the server was proftpd running either on
Linux or FreeBSD. As I run the windows client against a linux vsftpd server, as
well as against another windows Filezilla server and both cases were normal it
is obvious that it is not an issue of Windows specifically. Additionally,
judging from the fact that vsftpd and filezilla worked successfully, means that
the problem lies with proftpd.

I sniffed the traffic for all cases and the only thing that was noteworthy was
that as a client, Windows usually didn't include a TCP Timestamp option (which
is almost irrelevant) and also didn't include a window scale option (something
which may be of some importance in a way). However, in the windows-windows case
with filezilla, neither of the above options were enabled and it worked just
fine and afaik the windows-scale option shouldn't have that kind of impact
anyway, as it is mainly utilized for LFN (long fat networks).
Linux on the other hand always used window scale option as a client.

I am starting to think that this is just a proftpd peculiarity though. Can you
reproduce this case? If so, do you have any thoughts on the issue?

It is important for Ncrack to know about these extreme corner-cases, because it
needs to be able to adapt to slow responses like the above.


Regards,
ithilgore




[SOLVED]:

I discussed the problem with Fyodor and he suggested that the source of all
troubles might be the fact that some services (like proftpd for example) like to
first try connecting to the peer's identd/auth port 113 before presenting you
with the login banner. That was exactly the case. The difference with Windows
was that because by default the firewall just discarded every packet destined to
113, proftpd tried sending many SYN probes until the identd connection
eventually timed out (after 10 seconds) and then it let you proceed with the
login procedure. On the other hand, the Linux hosts that tried connecting to
proftpd were not firewalled and thus immediately sent an RST back to the identd
connection attempt, allowing to proceed to the next step without delay.

-- ithilgore






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


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault